[PMB 8기] 기획자의 우아한 형제들 기술 블로그 탐험 일기

'글'은 더 이상 강력한 정보전달 도구가 아니다. 사진, 영상의 시대에서 세심하게 글을 읽는 이들도 사라지고 있다. 그럼에도 불구하고 '글'은 중요하다. 글을 쓰는 사람은 자신의 생각을 구조적으로 정리할 수 있고, 글을 읽는 사람은 이해를 위해 구조적 사고를 거쳐야 하기 때문이다. 

내가 블로그에 글을 쓰는 이유 또한 내가 아는 것을 구조적으로 표현하기 위해, 그리고 나의 사고 흐름을 자세히 보여주기 위함이다. 이런 이유 때문인지, 브런치를 중심으로 우리나라를 이끌어가는 많은 IT 업계의 전문가들이 글을 활용하여 지식을 공유하고 있다. 

 

많은 IT 전문가들이 그러한 것처럼, 여러 기업들도 기술 블로그를 만들어 기업 내부의 기술 관련 지식이나 프로젝트, 현황 등을 공유하고 있다. 네이버, 당근 마켓, 토스, 배달의 민족 등이 그러하다. 

 

앞서 언급한 여러 기업들의 기술 블로그를 돌아본 결과 솔직한 이야기로 기획자가 이해하기에는 한계가 있었다. 그럼에도 불구하고 단편적이지만 개발자가 일하는 방식, 기술 스택 등을 알 수 있는 점은 굉장히 좋았다. 무엇보다 코드를 지속적으로 개선하는 과정에서 기능의 구현이 가능한가 아닌가만이 목적이 아니라, 깨끗하고 효율적인 코드를 쓰기 위해 여러 번의 코드 리뷰 등을 거친다는 것이 인상 깊었던 것 같다. PM으로서의 관점을 좀 더 확장할 수 있는 계기였다. 

 

 

우아한 형제들 기술 블로그 글 탐험해보기

여러 기업들의 기술 블로그를 읽으면서 가장 흥미롭게 읽은 글을 소개해보려고 한다. 해당 글을 읽으면서 기획자의 관점에서 이해한 바에 따라 간략히 정리하고 간단한 설명을 달면서 글을 소개한다. 즉, 필자가 이해한 바를 최대한 표현하려고 한다. (그 이유는 글의 마지막에....) 해당 글은 아래 링크에서 볼 수 있다. 

 

※ 주의: 전문지식 없이 제멋대로 리서치를 해보며 기술 블로그 내의 글을 해석해본 글이므로 틀린 점이 다수 있을 수 있음.

https://techblog.woowahan.com/2718/

검색을 위한 데이터 다루기 | 우아한형제들 기술블로그

 

탐험(?)해볼 글은 배달의 민족 검색시스템에서 근무하시고 계신 '정철'님의 글이다. 검색시스템의 주요 기능을 개발하는 과정 상, 생긴 문제를 해결하는 과정을 설명하고 있다. 검색시스템은 주문하고 싶은 가게나 메뉴를 빠르게 찾을 수 있는 기능들의 집합이라고 볼 수 있다. 우리가 흔히 볼 수 있는 검색 기능, 인기 검색어, 배달 빠른 순, 배달 팁 낮은 순과 같은 정렬이나 최소 주문금액과 같은 기준에 따른 필터링 기능 등이 있다. 

 

source: 우아한 형제들 기술 블로그

소비자에 입장으로 너무도 쉽게 쓸 수 있었던 이 기능은 실시간으로 광고, 리뷰, 가게 상황, 주문자의 위치에 따른 가게별 거리, 평균 조리 시간 등 수많은 데이터를 실시간으로 동기화해야만 구현되는 복잡한 기능이었다. 초기 시스템 설계 시에는 수집할 데이터 양이 많지 않았기에 문제가 없었지만, 배달의 민족 앱이 슈퍼앱이 되어가면서 데이터량이 급격하게 늘어나는 데에 따른 몇 가지 병목 현상이 발생하게 되었다고 한다. 

 

 

source: 우아한형제들 기술 블로그

 

가게나 리뷰 등에서 발생하는 이벤트(변경사항 정도로 이해할 수 있음)를 건 바이 건으로 수집하는 방법은, 데이터가 과도하게 몰리는 경우에 수많은 이벤트 수신으로 Elasticsearch Writer Thread Pool에 과부하를 만든다. 그에 따라 데이터를 추가하는 요청(Request)이 거절되거나 Disk I/O 문제로 CPU 수치가 급격하게 올라가는 문제가 발생했다고 한다.

 

Elasticserch : 오픈소스 분산 검색 엔진으로 검색 엔진을 구동하는 프로그램 정도로 이해할 수 있음.
Disk I/O : 물리적 HDD에 데이터가 Input(입력)/Output(출력) 되는 과정, 지표, 기기. 여기서는 과정으로 볼 수 있음.
Writer Thread Pool: Elasticsecrch의 주요 기능들을 thread pool의 형태로 생성하여 관리하는 것.
Thread: 프로그램에서 실행되는 흐름의 단위, 프로세스 내에서 작업을 수행하는 세부 기능을 지칭하는 말, 블로그 글쓰기 기능 안에는 글자 입력 스레드, 맞춤법 교정 스레드 등이 있을 수 있음.

 

이에 대한 원인은 Elasticserach의 정보처리 방식 때문이다. 

 

source: 우아한형제들 기술 블로그

 

Elasticserch의 Index(정보를 쌓는 구조 정도로 이해)는 Lucene(검색을 위한 라이브러리)를 기반으로 여러 개의 하위 Segment(데이터의 단위 정도로 이해)로 이루어진다. 이 segment는 검색 요청을 빠르게 처리하기 위해 각 데이터마다 여러 개가 생성되어 해당 요청을 처리한다. 하지만 segment는 생성 후 그 상태를 바꿀 수 없는 특징이 있는데, 그에 따라 기존 정보를 업데이트(정보를 추가) 해야 할 시 기존 segment에 표시만 하고 계속해서 segment를 생성한다. 만약 수백만 개의 데이터가 업데이트되면 그에 준하는 양의 Segment가 생성되고, 이를 처리하기 위해 Disk I/O가 급격히 증가, 그 결과로 CPU가 과부하 되게 된다. 

 

쉽게 말해 PPT를 만들 때 장표 하나하나마다 PPT 파일을 계속 생성하는 것과 비슷하다. 

source: 우아한형제들 기술 블로그

Elasticsearch에서는 Writer thread pool이 한계상태가 되면 각 thread pool 별로 가지고 있는 queue(부가적인 데이터 처리 장소)에 요청을 넣어 해결하는데 이 마저 한계일 경우에는 업데이트 요청이 거절된다. 이는 앞서 말한 이벤트 데이터를 건 바이 건으로 수집하는 방법에 의해 발생한 문제이다. 

 

source: 우아한형제들 기술 블로그

 

위의 나타나는 문제를 해결하기 위해 들어오는 이벤트를 묶어서(bulk) 처리하는 API를 사용했다고 한다. 데이터 변경 request를 모아 buffer(요청을 모아 놓는 임시 저장소 정도로 이해)에서 일정한 기준에 맞게 데이터를 처리하여 해당 문제를 해결하기 때문에 기존의 건 바이 건 request 보다 리소스를 덜 쓰면서 데이터를 처리할 수 있다. 

 

source: 우아한형제들 기술 블로그

이러한 방법을 통해 위와 같은 성과를 낼 수 있었다는 점을 블로그 글에서 소개하고 있다. 

 

 

탐험과정을 글로 써 본 이유

PM에게 기술에 대한 이해는 왜 필요한가? 무엇보다 모든 디자이너, 개발자들이 PM에게 가장 강조하는 커뮤니케이션 역량 때문이다. 기술에 대한 이해가 있을 때 커뮤니케이션의 기본을 갖출 수 있다. 그렇다면 내가 만약 배달의 민족의 PM으로 일을 한다면 아래와 같은 배달의 민족의 기술 스택을 모두 이해하여야 할까? 

데이터베이스만 해도 이렇게 많은 기술 스택을 가지고 있다면, 겉핥기식으로 기술들을 이해한다고 해도 오랜 시간이 걸릴 것이다. 차라리 그 시간에 문제 정의를 위한 학습을 더 하는 것이 나을 수 있겠다는 생각도 든다.

 

개인적으로 내린 결론은 '빠르게 지식을 배울 수 있는 흡수력'과 '리서치 능력'으로 기술 스택을 공부하는 것을 대신해야겠다는 생각이다. 위처럼 글을 분석해본 것도 해당 부분을 연습해보고 싶어서였다. 만약 앞선 글과 같이 검색 시스템에서 생긴 문제에 대한 문서를 이해할 수 있다면 분명 개발자와의 커뮤니케이션도 원활하게 수행할 수 있다. 그렇기 때문에 관련 지식을 빠르게 리서치하여 해당 기술 지식을 빠르게 흡수할 수 있는 능력이 있다면, PM으로서 커뮤니케이션에 참여할 수 있는 기본은 쌓을 수 있을 것이라 생각된다. 

 

오늘 커뮤니케이션 역량 강화를 위해 토론 세션에서 각자 pm, 개발자, 디자이너로 역할을 맡아 가상의 회의를 해보았다. 토론 세션에서 저번에 배운 API의 URI, URL 개념을 알고 있었기에 주어진 문제의 해결 실마리를 간략하게나마 제시할 수 있었다. 즉, '아는 것만큼 보인다.' 고 문제 해결의 결정적인 역할은 하지 못해도 실마리라도 던질 능력을 갖추기 위해서는 최대한 많이 아는 것이 중요하다. 모든 지식을 다 쌓을 순 없지만 리서치 능력, 지식을 빠르게 흡수하는 능력을 강화하여 PM으로 커뮤니케이션 역량을 향상할 수 있을 것이다.