엔지니어링 팀은 무슨일을 하는가?

새해에는 측정하는 한해 되세요!

올해의 첫 글인데, 색다른 새해 인사를 남겨볼까 합니다.

"측정하는 한 해 되세요."

이번 글에서는 최근 9개월간 엔지니어링에 대해 쌓아올린 질문과 생각들을 나누어 보려고 합니다. 몇 개월동안 스스로에게 지속적으로 했던 질문은 두 가지 였습니다.

- "엔지니어링은 무엇인가?" (What)

- "어떤 엔지니어링을 해야하는가?" (How)

이 질문에 대한 답을 얻는다면 무엇을 어떻게 해야하는지가 확고해지므로

팀이 엔지니어링을 대하는 태도, 다시 말해 일하는 방식이 정해질거라 생각했습니다.

또한 우리가 어떤 유형의 엔지니어를 채용하길 원하고,

새로 합류한 사람과 기존의 팀이 어떻게 섞여 나갈지도 논의 해볼 수 있을것 같았습니다.

저는 이 것이 비즈니스와 문제를 대하는 자세, 팀이 커뮤니케이션 하는 방식, 채용 대상과 프로세스, 그리고 기업의 문화를 관통하는 가장 중요한 질문이라고 생각합니다.

또한 이 질문에 대해 모든 엔지니어링 팀이 자신들만의 답안을 가져야 한다고 생각합니다.

"Defining Your Engineering Team Principles" [0] 에서는 팀이 추구하는 가치 (Value) 와 지켜야할 원칙 (Principle) 그리고 실행 가능한 방법 (Practice) 간의 관계에 대해 설명합니다.

지난 9개월보다 더 대과거로 돌아가 "엔지니어링" 에 대한 제 생각을 살펴보면

- 2021년 3월경에 엔지니어링은 주어진 문제를 푸는것을 넘어, 문제를 살펴보고 해결하는 과정에서 비즈니스 가치 (Value) 를 만들어내는게 아닐까 [1] 라고 생각했었고

- 2022년 8월에는 엔지니어링은 얻고자 하는 결과에 대한 노동 시간과 물리 비용의 교환 [2], 다시 말해 무엇을 Trade-off 할 것인가에 대한 결정이라고 생각했던 것 같습니다.

둘 다 여전히 동의하는 문구 이지만, 이것은 "어떤 엔지니어링을 해야하는가?" (How) 에 대한 답변일 뿐, "엔지니어링은 무엇인지?" (What) 대한 것은 아니라고 느껴졌습니다.

2023년 1월 28일 새벽까지 가지고 있는 생각을 바탕으로 엔지니어링이 무엇인지 정리해보면, 아래와 같습니다.

"비즈니스 메트릭을 측정하고
이들의 구성 요소를 찾아
확률에 근거해 개선하는
Daily Execution"

이 문장의 각 요소들을 하나씩 부연 설명해보자면..

- 비즈니스 메트릭을 측정:

엔지니어링 팀은 비즈니스 메트릭이거나 적어도 비즈니스 메트릭에 영향을 주는것을 측정해야 합니다.

이 문장은 두 가지를 내포하는데, 엔지니어링 팀의 작업은 항상 "측정" 되어야 한다는 것이며 비즈니스와 연관성이 없는 작업을 하는 것은 무의미하다는 의미입니다.

- 구성요소를 찾아:

비즈니스 메트릭은 매출 혹은 사용자 수 증가와 같은 최종적인 결과 (방정식의 Y 값) 입니다.

이것을 구성하는 요소 (Xa, Xb) 를 찾아 개선해야 한다는 의미입니다. AWS Region 다운이나 환율과 같이 엔지니어링 팀이 조절할 수 없는 레버들은 개선 대상이 아니어야 합니다.

- 확률에 근거해 개선

엔지니어링 팀은 Y 값을 구성하는, 개별 컴포넌트의 특질을 자세히 살펴봐야 합니다.

개선 대상인 비즈니스 메트릭이 Y = 0.5Xa + 3Xb 라면, 효과가 6배처럼 보이는 Xb 를 개선하는 편이 낫습니다.

그러나 Xb 를 개선하는 과정에서 인프라 비용이 회사가 허용할 수 있는 한도보다 많이 들어가거나 시간이 4배나 걸린다면 당장은 Xa 을 하는편이 빠를 수 있습니다.

여기에서 알 수 있는 사실은 "확률" 은 우리가 처한 시장 환경과 가용한 리소스에 따라 다를수도 있다는 사실입니다.

엔지니어는 기술적 결정을 위해 자신이 투입 가능한 시간 / AWS 물리 비용 / 앞으로의 운영 부담 / 채용 등 모든 것들을 고려할때 "현재 상태" 를 포함해야 합니다.

- Daily Execution:

엔지니어링 활동은 매일, 매주, 매월 일어나는 반복적인 작업입니다.

자신이 담당하는 컴포넌트의 Y 값이 줄어들었거나 더 개선해야한다면 원인을 찾고, 조절 가능한 레버인 구성 요소를 확인해 투입 가능한 리소스와 해결 가능성이 높은 방안을 도출한 뒤 개선해 내는 지속적인 작업으로, 1회성이 아닙니다.

엔지니어링 팀은 지표들을 추적하면서 문제가 있는지 주기적으로 논의해야 하고, 해결하기 위한 방법과 도구들을 누적해가야 합니다.

예를 들어, 이번에는 Xa 를 조절해 해결했지만, 비용과 시간 문제로 조절하지 못했던 다른 요소 Xb 어떻게 수정할 수 있을지 자산으로 만들어 Xa 가 조절 불가능한 임계점이 올 때를 대비해야합니다.

위의 메세지를 엔지니어가 수행해야 할 행동 지침으로 바꾸어 보면 다음과 같습니다.

1. 비즈니스에 영향을 줄 수 없는 일은 하지 않아야 합니다. 적어도 우선순위가 높을 수 없습니다.

만약 개별 엔지니어가 당장 개선해야 한다고 "굳건히" 믿는 작업이 있다면, "얼마나 급한지" 를 수치화 해 가져올 수 있어야 합니다.

만약 이미 측정되고 있다면 팀은 그것이 당장 해결해야 하는, "큰 문제" 라는 것에 빠르고 쉽게 합의할 수 있습니다.

2. 무슨 작업을 하는지에 상관 없이 그 결과가 측정될 수 있어야 합니다. 측정하지 않으면서 영향도를 파악할 수 있는 방법은 없기 때문입니다.

3. 무엇을 개선하면 Y 값을 가장 빠르게 그리고 크게 높일 수 있을지 그 방안을 매 순간 고민해야 합니다.

예를 들어, 엔지니어는 개선 과정에서 Xa, Xb 중 어떤 변수를 개선할지 결정해야 합니다.

이 과정에는 긴급성, 작업 시간, 물리 비용, 기대하는 개선 정도 등 결정에 필요한 정보들이 수치화 되어 포함되어 있어야 합니다. (주의: 완벽해야 한다는 것이 아니라, 이러한 행동을 팀이 추구해야 한다는 의미입니다.)

"시간" 과 같은 어떤 수치는 복구가 불가능한 자원일 수 있습니다. 반면 "AWS 비용" 과 같은 리소스는 잠깐 동안 적자를 보는 등 희생 가능할 수 있습니다.

이는 자원은 모두 같지 않으며, 가중치가 다르다는 뜻입니다. 만약 여러분의 비즈니스가 빠른 시간 내에 경쟁자들을 압도하고 빠르게 성장해야 하는 비즈니스라면, 어떤 리소스를 투입해 어느 레버를 조절할지도 달라질 수 있습니다.

리더십이 아니라도, 이쯤에 다다르면
개별 엔지니어는 측정하지 않는 것에 대해 이상함을 느끼고 질문해야 합니다.

Q1. 성과를 측정할 수 없는 일이 있는가?

Q2. 성과를 측정할 수 없는 일이 있다고 하면, 그걸 측정할 수 없으므로 중요도를 알 수가 없는데 무슨 연유로 그 일을 해야한다고 주장하는가?

Q3. 상대방은 그걸 왜 받아주는가? 다시 말해, 상위 직책자는 왜 그 일을 승인해 주는 것이며 해당 팀의 퍼포먼스는 어떻게 평가할 것인가?

Q3. 측정할 수 없으면 이후에 개선의 효과는 어떻게 보는가?

Q4. 측정할 수 없어 효과를 못 본다면, 일을 하기는 한 것인가? 어쩌면 회사의 자원을 낭비한 것이 아닐까? (어쩌면, 아무것도 안 하는 편이 더 낫지 않았을까?)

Q5. 이게 습관이 된 문화를 어떻게 고쳐야 하는가?

Q6. 만약 문화를 개선한다면, 개별 엔지니어는 무엇을 측정하고 관리해야 하는가? 그리고 개별 엔지니어의 지표를 비즈니스와 묶을 수 있도록 지원한다면, 시스템 및 문화 차원에서 어떤것들을 제공해야 하는가?

이는 리더십 영역으로 갈 수록 더 당연해집니다.

- 측정하지 못하면서 일을 해야 하는 근거를 댈 순 없습니다. 이는 상대편을 설득하지 못한다는 것입니다. 그 결과로 원하는 만큼 리소스를 할당 받지 못하여 일이 진행되지 않을 경우가 더 많게 됩니다.

- 측정하지 못하면, 일을 하고 나서 성과를 증명할 순 없습니다. 팀의 성과가 없는데 팀원들이 어떤 일을 얼마나 했는지 보여줄 수 없습니다.

- 측정하지 않는다면, 무엇이 더 중요한지 판별할 수 없어 현재에 머무르거나 후퇴하게 됩니다. 어쩌다 한번씩은 감으로 때려맞출지 몰라도 지속적인 성공을 이룰 수 없습니다. 확률이 높은 선택을 할 수 없기 때문입니다.

아래는 인터넷을 탐색하면서 찾은 몇 가지 좋은 사례입니다.

먼저, "쿠팡이츠의 인하우스 지도 서비스 구축하기" [3] 에 나오는 사례입니다.

* 타사 서비스에서 인하우스 길찾기 서비스로 전환 후 다음과 같은 성과가 있었습니다.

* 엔지니어링 비용이 연간 약 2백만 달러 정도 감소했습니다

* 길찾기 서비스의 P99 대기시간(latency)이 350ms에서 100ms로 70% 감소했습니다.이후 이어진 최적화 작업을 통해, P99를 50ms 미만으로 개선했습니다.

* 시스템 확장 시 발생하던 병목 현상이 해결되었습니다. 현재 저희의 길찾기 서비스는 50ms 미만의 P99 대기시간으로 이전보다 10배 더 많은 트래픽을 처리하고 있습니다.

* 총 배달 시간, EDP의 음식 대기 시간, 운영 비용과 같은 비즈니스 지표 모두가 개선되었습니다. 사용자 경험 관련 측정 지표들도 개선되었습니다.

다음은 "디스콰이엇 Pre A 회고: 프로덕트 - 3" [4] 에 나오는 사례입니다.

* 디스콰이엇의 경우 월 포스트 생산수와 MAU 상관계수를 측정했고 이를 토대로 'MAU = 기울기 × 포스트 생산 수 + 상수' 라는 모델을 만들었습니다.

* 월 포스트 증가율을 어떻게 정하느냐에 따라 어느 시점에 어느 정도의 MAU, 가입자 수가 결정됩니다. 원하는 목표에 따라 실행할 수 있는 방안을 다르게 가져갈 수 있습니다.

* 앞의 과정을 거치고 나면 팀의 목표가 명확해집니다. 각 팀원들은 “내가 하고자 하는 일이 포스트 생산수를 주 5%씩 늘리게 하는 일인가?”를 바탕으로 해야될 일과 하지말아야 되는 일을 스스로 판단하면서 실행할 수 있습니다.

이와 관련 없는 일이라면 일단 과감히 서랍에 넣어두고 나중에 때가 왔을때 다시 꺼내면 됩니다. 간혹 중간 중간에 너무 UX가 불편해서 이와 같은 전략을 알고 있는 우리도 짜증난다라는 생각이 드는 것들이 있으면 당장 포스트 생산수와 직접적인 연관이 없어도 개발을 했습니다. 사이트내 검색기능 개발, 모바일 속도 개선 등이 이런 형태의 작업이었습니다.

* 이렇게 해서 우리팀은 지난 1년간 월평균 23%씩 포스트 생산수를 성장시켜 왔습니다.

다음은 "etsy - Understanding the collective impact of experiments" [5] 에 나오는 사례입니다. (원문)

* This estimation helps us keep a pulse on the health of the company, and also helps our leadership make strategic decisions regarding questions such as

* “what resources should we invest in X?” or “given that Y is expected, how much should we spend on Z?” (무엇을 X 에 투자해야 하는지, Y 를 기대할 때 Z 를 얼마나 더 지출해야 하는지)

* These experiments enable us to estimate the incremental business value Etsy can expect from the ensemble of changes we deploy every quarter, which ultimately leads to more informed financial planning.

위에서 나온 사례와, 지금까지의 이야기를 종합해보면 다음과 같습니다.

1) 우리는 가진 기술로서 Data Engineer, Backend Engineer 등으로 분류되는 것이지 본질적으로 하는 일은 Product Engineer 입니다.

- 따라서 엔지니어가 아닌 다른 직무와 다를 바 없습니다. 다시 말해, 엔지니어는 Input 지표의 (Xa, Xb) 변경을 통해 Output (Y값) 지표를 높이는 생산직이라는 의미입니다.

- Y = K * X1 + N 에서 Output 지표인 Y 값을 늘릴 수 있는 효율적인 X 를 찾아 기술로 풀어내고, 그 X 와 Y 값들을 측정하고 꾸준히 관리하는 것이 엔지니어의 역할입니다.

예를 들어, 내가 속한 도메인이 물류 커머스이며 배송 박스 부피당 이익이 Y 값이라면, Y 를 구성하는 X 를 개선할 수 있습니다.

- 이를테면 부피가 작고 단가가 높은 상품을 위주로 카탈로그 추천을 만들어 판매를 높일수도 있고

- 또는 동일 면적에 더 많은 부피를 담을 수 있도록 적재를 효율화 하거나 배송 루트를 최적화 해 동일 시간 내에 산출되는 Y 를 더 높일 수 있습니다.

"기술" 을 사용해 해결하는게 중요하지 않을 수 있습니다. 만약 추가적인 리소스 투입 없이 Y 값만 높일 수 있는 방법을 찾아낸다면, 그것보다 더 좋은 솔루션은 없습니다.

기술로 문제를 해결한다면 고민해야 할 부분이 많습니다. 예를 들어 새로운 스토리지를 도입해야 할 때 단순히 장단점을 나열하는것은 도움이 되지 못합니다.

장점 1개가 단점 1개를 상쇄하는 구조로 동작하지 않기 때문입니다. 각각의 가능성과 크기를 살펴봐야 합니다.

이를테면

1. 새로운 스토리지를 도입해서 모르는 장애를 마주칠 횟수

2. 시장에서 잘 쓰이지 않는 스토리지라서 운영해줄 인력을 찾아 채용할 수 없는 경우

3. 혹은 현재 해당 스토리지를 운영하는 현재 담당자가 장기 근속하지 못할 경우

4. 해당 스토리지가 인프라 비용이 많이 들어갈 경우

이 모든 상황을 고려하고 나서도, 새로운 기술이 비즈니스 가치를 만들 수 있다고 팀이 합의한다면 도입해야 하는 것이 당연합니다.

2) 우리는 보통 "데이터 를 보자" 고 이야기 합니다. 그러나, 데이터를 보자고 말하는 것은 "정답" 을 보자는 이야기가 아닙니다.

정답은 누구도 모릅니다. 우리가 예측한 것은 성공적이지 못할 수 있습니다.

예를 들어 계획했던 Migration 은 다양한 이유로 일정을 못지켜 실패할 수 있고 일정을 지켜도 기대했던 만큼 성능이 안나올지도 모릅니다.

다만 확률을 가지고 이야기를 했고 우선순위를 세워 작업을 했다면 그 중에서 가장 성공하리라 믿었던 Task 를 수행한 것이고 그 다음으로 성공할 확률이 높은 Task 를 실행하면 됩니다. 

우리가 옳은 방식으로 측정했고, 해결 방안 또한 합리적으로 세웠다면 우리는 질 수 없습니다.

시간이 지난다면 앞으로 나아갈 것이고 그 속도는 남들보다 빠를것이기 때문입니다.

환경이 변화해 문제가 (Y 값) 달라지거나, 구성 요소 (Xa, Xb) 가 가진 특질이 뒤바뀌었다 해도

우리는 비즈니스 메트릭을 측정하고 이들의 구성 요소를 찾아 확률에 근거해 개선하는 것을 Daily Execution 으로 해내면 될 뿐입니다.

이것은 방학 숙제 (혹은 인생) 을 결과로 바라보는지 아니면 과정을 통해 완수할 것인지와 동일한 문제입니다.

- 방학이 끝나는 마지막 날 숙제를 몰아서 FALSE 를 TRUE 로 만드는것과

- 매일 매일 조금씩 쌓고, 실패해 TRUE / TRUE / FALSE / TRUE / FALSE / TRUE 최종적으로 TRUE 를 만드는 것의 차이입니다.

- 그러고 나면 우리가 깨닫는 사실은, 그 하루 하루가 TRUE / FALSE 와 같은 Binary 가 아니라 0.67, -0.13, 0.80 과 같이, 각각 차이가 존재하는 숫자였다는 것이며

- 그로 인해 개학 당일 우리가 해낸 방학 숙제도 단순히 완료 (TRUE) 와 미완료 (FALSE) 로 나뉘지 않고, 결과값이 1.2, 3.5, 9.9 처럼 크고 작은 차이를 만들었다는 것입니다.

엔지니어링 팀이 가진 시스템과 문화에 따라서
결과의 차이를 만들 수 있다고 믿습니다.
 
결과의 크기 뿐만 아니라
결과를 만들어 내는 속도,
결과를 만들어 내는 방향까지.

마지막으로.. 이 긴 글을 네 문장으로 요약해보면

측정하지 않으면 현재를 모릅니다.

현재를 모르면 개선할 수 없습니다.

개선후 측정이 없는 것은

개선이 아니라 개악일지도 모릅니다.

(개악: 본디보다 도리어 나쁘게 고치는 것.)

etsy - Understanding the collective impact of experiments [5]

첨부한 스크린샷은 [5] 아티클에 나오는 Holdout 과 Site-wide Impact 관련된 사진입니다.

측정한다면,

1. 개별 개선의 효과가 진짜인지

2. 그 크기가 회사 차원에서 놓고 보면 전체적으로 얼마나 큰지를

파악하길 원할것이라는 맥락 하에 넣어봤습니다. ^^

새해복 많이 받으시고 올 한해는 측정하는 한해가 되셨으면 좋겠습니다.

[0] (Defining Your Engineering Team Principles) https://shekhargulati.com/2020/12/26/engineering-strategy-2-defining-your-engineering-team-principles/

[1] (Facebook 지난 글, 2021 년 3월) https://www.facebook.com/1ambda/posts/pfbid02b8rGwKHANMdYvjHzbEKrHEmuDr4Yngrzxq6sjokHjVt8Cjp47ejPYQVEDnDeqConl

[2] (Facebook 지난 글, 2022 년 8월) https://www.facebook.com/1ambda/posts/pfbid0eCRhQqjmVMv4scWGP3PaH3gNL335cjTvuS6ioj5ZrqYsCEWSa3Ztuh5VxRJpbigyl

[3] 쿠팡이츠의 인하우스 지도 서비스 구축하기 https://medium.com/coupang-engineering/%EC%BF%A0%ED%8C%A1%EC%9D%B4%EC%B8%A0%EC%9D%98-%EC%9D%B8%ED%95%98%EC%9A%B0%EC%8A%A4-%EC%A7%80%EB%8F%84-%EC%84%9C%EB%B9%84%EC%8A%A4-%EA%B5%AC%EC%B6%95%ED%95%98%EA%B8%B0-ca1f356db484

[4] (디스콰이엇 Pre A 회고: 프로덕트 - 3) https://disquiet.io/@hpark0011/makerlog/3612

[5] (etsy - Understanding the collective impact of experiments) https://www.etsy.com/codeascraft/understanding-the-collective-impact-of-experiments