이 글의 원문은 당근 팀 블로그 '프로덕트에 진심인 엔지니어는 어떻게 일할까? ② - 프로덕트를 성장시키는 엔지니어링, 행동하는 법부터 협업하는 법까지’에서 확인할 수 있습니다.

이번 글에서는 이런 내용을 확인할 수 있어요! ☑️

• 적정 엔지니어링을 실현하기 위한 세 단계의 방법
• 사업가적 마인드로 엔지니어링을 회고하는 방법
• 프로덕트를 중심으로 팀원들과 관계 맺고 협업하는 방법

이런 분들에게 도움이 돼요! ‍🙋

• 적정 엔지니어링의 철학과 실질적인 적용법을 알고 싶은 분
• 프로덕트 조직에서 엔지니어로서의 역량 성장을 고민하는 분
• 프로덕트 단계에 맞는 팀의 협업 방식이 궁금한 분

안녕하세요. 당근알바팀의 Kit이에요. 지난 글에서는 프로덕트 엔지니어들이 어떤 사고방식과 결정 기준을 가지고 있는지 소개했는데요. 이번 글을 통해서는 본격적으로 프로덕트 엔지니어들이 어떻게 행동하고 회고하는지, 또 다른 팀원들과는 어떻게 협업하는지 설명해 드릴게요. 당근의 엔지니어들이 프로덕트 중심으로 어떻게 일하는지 궁금한 분들에게 이 글이 도움이 되기를 바라요.

Step 3. 프로덕트 관점에서 행동하기: 가자, 적정 엔지니어링의 세계로

프로덕트 엔지니어들은 문제에 어떻게 접근할까요? 저는 적정 엔지니어링을 지향하는 접근법이 필요하다고 보는데요. 적정 엔지니어링이란 완벽한 기술적 완성도를 갖추기보다는 최소한의 노력과 시간으로 프로덕트에 필요한 만큼만 효율적으로 기술을 구현하는 것을 말해요. 필요 이상의 복잡도를 피하고 급변하는 시장 변화에 빠르게 대응할 수 있어 프로덕트 엔지니어에게 꼭 필요한 접근법이죠.

그러나 적정 엔지니어링을 찾아가는 여정은 쉽지 않아요. 일반적으로 가지고 있는 “좋은 코드”, “엔지니어의 역할”에 대한 생각을 깨는 데 시간이 오래 걸리거든요. 저도 그랬고요. 제가 어떻게 기존의 지식을 하나씩 지워가며 적정 엔지니어링을 실현할 수 있었는지 소개해드릴게요.

1단계: 클린코드는 책장에만 꽂아두고

엔지니어는 클린 코드를 작성해야 한다는 말이 있어요. 다른 엔지니어들도 이해하기 쉽게 코드를 명확하고 직관적으로 작성해야 한다는 거예요. 저도 한때는 그렇게 깔끔하게 작성된 코드가 퀄리티가 높은 거라고 생각했어요. 그런데 프로덕트 관점에서 보면 코드 퀄리티의 기준은 달라질 수도 있어요. 코드의 가독성과 구조적 완성도에 대한 지나친 집착은 프로덕트의 성공에 걸림돌이 될 수도 있기 때문이에요. 언뜻 보면 지저분해 보이는 코드가 더 유용할 때가 있는 거예요.

저는 처음 팀에 합류해 코드를 살펴봤을 때, 제가 생각했던 클린 코드와는 거리가 많이 멀어서 당황스러웠어요. 한 페이지를 구성하는 코드는 몇백 줄에 달했고, 세부 동작이나 기능을 담당하는 코드들이 정리되지 않은 채 처리되고 있었어요. 결정적으로 기능이 거의 동일한 컴포넌트들이 여러 곳에 복사되어 있는 걸 발견했을 때, 아무리 코드 품질보다 개발 속도가 중요하다 해도 이건 아니다 싶었죠. 그런 부분들을 필요할 때마다 재사용할 수 있도록 공통 컴포넌트로 만들자고 팀에 제안했고, 깔끔해진 인터페이스를 보며 만족스러워했어요.

그런데 어느 날 프로덕트 디자이너가 “이 컴포넌트는 다시 쪼개야 할 거 같아요”라고 얘기했어요. 점차 페이지가 많아지고 유저의 특성과 사용 패턴이 다양해지면서, 하나의 공통 컴포넌트로는 뾰족하게 대응하기가 어려워진 거죠. 공통 컴포넌트를 다른 곳에서 예외적으로 처리할 수 있도록 수정하니, 서로 독립적이었던 코드들 사이에 의존성이 생기면서 전체적인 복잡도가 높아졌어요. 그러자 실수도 잦아지고 작업시간도 늘어났죠. 원래대로 한 페이지 안에 풀어서 작성했다면, 이 작업이 훨씬 쉬웠을 거예요.

이때 기능이 비슷한 코드를 모듈화해서 가독성을 높이는 게 능사가 아니라는 걸 배웠어요. 그보다는 각각의 코드가 프로덕트 내에서 어떤 배경과 목적을 가지고 있는지, 또 앞으로 어떻게 수정될 가능성이 있는지를 종합적으로 판단해야 했던 거죠. 그래야 코드의 재사용성을 제대로 확보할 수 있고, 추후에 더 빠르게 수정할 수 있어요. 당장은 코드가 지저분해 보이긴 해도, 프로덕트의 생존을 위해 사용자 반응에 맞춰 기능을 발 빠르게 추가하고 없애는 게 가능해지는 거죠.

2단계: 임팩트를 예측해 경제적으로 일하라

다음 단계는 사전에 임팩트를 예측해 적절한 리소스를 투입하는 거예요. 단순히 “얼마나 빠르게 처리할지”가 아니라 “각각의 문제들을 몇 시간 안에 풀어야 효용이 맞을지”를 고려하는 거죠. 프로덕트 팀에서는 다양한 문제들을 다루면서 한정된 리소스로 최상의 결과를 만들어야 하거든요. 어떤 문제를 더 빠르게 해결하고 어떤 문제를 더 천천히 다룰지, 경제적인 의사 결정을 내릴 수 있어야 해요.

저희 팀에서는 기능을 내보내기 전에 다 같이 작업 리뷰를 해요. 각자가 투입한 리소스를 공유하고, 새로운 기능이 가져올 임팩트를 예측하죠. 기대치가 작은 일에 리소스를 과하게 투입하지는 않았는지 회고하기도 하고, 추후 실제 임팩트와 예측치 사이의 갭을 분석하면서 사용자에 대한 직관을 키우기도 해요. 처음에는 임팩트를 예측하는 일이 생소하게만 느껴졌는데, 시간이 지나면서 구체적인 근거들이 생기더라고요.

일례로 알바팀에서 근무 당일 임금 지급을 약속한 공고에 배지 UI를 달아 전환 성과를 높이는 실험을 한 적이 있는데요. 실험을 위해 빠르게 개발하면 두 시간이 걸리지만, 실험이 성공할 경우 배포 전에 추가로 두 시간을 들여 기능을 개선해야 했어요. 그런데 이 기능이 분명히 유의미한 임팩트를 낼 거라고 판단해, 애초에 네 시간을 써서 높은 완성도로 구현했어요. 실험 결과는 예측대로 성공적이었고, 기능을 곧바로 전국 배포하는 데 단 5분도 걸리지 않았어요.

3단계: 엔지니어가 데이터를 다룬다면

데이터 분석은 엔지니어에게 생소한 영역이겠지만, 적정 엔지니어링에 한 걸음 더 가까워질 수 있는 수단이기도 해요. 데이터로 사용자의 서비스 이용 패턴과 행동 변화를 파악하면, 문제의 심각성을 더 정확히 인지할 수 있거든요. 별이 뜨고 지는 것을 막을 수 없듯이 프로덕트에도 자연스럽게 사용이 늘어나는 기능과 줄어드는 기능이 있는데요. 이 변화를 파악해서 사용성이 높아지는 기능들 먼저 문제를 해결하고, 트래픽이 낮거나 다운 트렌드인 기능의 문제는 우선순위를 낮출 수 있어요. 

최근에도 데이터 분석을 통해 문제의 심각성을 다시 보게 된 경험이 있어요. 서버의 특정 API 응답 리소스가 0개인 경우에 사용자의 화면에 디자인 오류가 발생하는 이슈였는데, 그런 경우는 극히 희박할 것이라 생각해서 넘어갔었거든요, 그런데 이번에 데이터를 직접 쿼리해 보니 하루에 500명 이상의 사용자가 겪고 있던 문제였죠. 우선순위를 Low(분기에 해결하지 않음)에서 Middle(분기 중에 해결)로 올려서 빠르게 대처했어요. 

그런데 엔지니어에게 개발만이 전부는 아니에요. 개발을 마친 후에는 회고도 해야 하고, 그 과정에서 지속적으로 팀원들과 협업도 해야 하죠. 프로덕트 관점에서 스스로의 엔지니어링을 회고하고, 나아가 팀원들과 관계 맺는 방법이 궁금하다면,💡어바웃당근 블로그에서 지금 바로 콘텐츠 전문을 확인해보세요!