AI도 이건 못해… 기술 부채를 ‘팀의 문제’로 만든 경험

시작하며

안녕하세요, 레몬베이스의 Frontend Engineer, Finn입니다.

AI 시대가 도래하며 많은 문제를 AI를 활용해 해결할 수 있게 되었습니다. 하지만, 기술 부채의 관리는 여전히 ‘사람’의 역할이 큽니다. 조직의 맥락을 이해하고, 복잡하게 얽힌 구조 속에서 어디서부터 어떤 선택을 해야 할지 판단하는 일, 무엇보다 서로 다른 관점의 팀원들과 문제를 꺼내놓고 의견을 조율하는 과정은 결국 ‘사람’을 중심으로 이루어지기 때문입니다.

저 또한 기술 부채로 인해 문제를 겪었지만, 개인의 노력만으로는 개선이 쉽지 않았는데요. 이를 ‘팀의 문제’로 만듦으로써 효과적인 개선을 할 수 있었습니다. 이 글에서는 그 경험을 통해 얻은 인사이트를 소개하려고 합니다. 비슷한 고민을 가진 분들에게 조금이나마 도움이 되길 바라며 글을 작성했습니다.

목차

• 시작하며
• 첫 번째, 기술 부채에 대한 팀과의 이해도 맞추기
• 두 번째, 문제 분해하기
• 세 번째, 기술 부채 관리를 팀의 시스템으로 만들기
• 마치며

첫 번째, 기술 부채에 대한 팀과의 이해도 맞추기

기술 부채로 인한 고통은 기술 부채와 가까운 엔지니어만 정확히 알 수 있습니다. 반대로 팀 관점에서는 그로 인한 문제가 직관적으로 보이지 않을 것입니다. 이런 상황에서 기술 부채 문제에 대해 팀과 이해도를 맞추려면 어떻게 소통해야 할까요?

바로, 이 문제가 왜 중요한지에 대해 팀의 관점에서 이야기하는 것입니다. 저는 기술 부채로 인한 문제 상황을 비즈니스 리스크로 이야기했습니다. 단순히 개발이 어렵다고 하는 것이 아니라, 연간 전사 전략으로 세운 핵심 과제에서 기술 부채로 인해 문제가 될 부분을 구체적으로 짚으며 소통했습니다. 이에 더해, 기술 부채를 개선하지 않으면 어떤 악순환이 발생하는지 조직 내 비즈니스 프로세스 기반으로 설명했습니다. 그리고 이를 전달하는 소통 수단을 팀의 관점에 맞췄습니다. 회사 내에서 여러 직군에게 두루 익숙한 양식인, PO들이 사용하는 Pager 형식을 통해 문제 상황을 전달했습니다. 상대방이 이해하기 쉬운 언어와 형식을 통해 문제의 본질에 더욱 집중할 수 있도록 한 것이죠. 이를 통해 문제에 대한 팀의 이해도를 맞춘 상황에서 함께 문제에 대해 평가하고, 해결책에 대해 논의할 수 있었고, 실제 개선 실행까지 빠르게 이어질 수 있었습니다.

작성했던 Pager의 도입부. (제품의 구체적인 맥락은 OO로 대체했습니다.)

두 번째, 문제 분해하기

복합적인 문제가 얽히고설킨 기술 부채를 한 번에 해결하려 하거나, 눈에 보이는 문제부터 해결하려 한다면 변경 범위가 걷잡을 수 없이 커지고 운영 중인 제품의 안정성을 해칠 수 있습니다. 그렇기 때문에 문제를 작게 분해해야 합니다. 문제를 작게 분해하면 우선순위에 따라 선별적으로 작업을 진행할 수 있고, 다른 엔지니어가 이해하기도 수월해져 팀의 일로 만드는 것의 난이도가 낮아집니다. 즉, 기술 부채가 관리 가능한 상태가 되는 것이지요.

제가 해결하려고 했던 기술 부채 영역은 여러 단계로 나뉜 페이지의 데이터를 모아 처리해야 하는 멀티 스텝 폼 페이지였습니다. 여러 문제가 혼재되어 무엇부터 해야 할지 방향을 잡기 어려운 상태였으나, 문제를 분해하여 우선순위를 세울 수 있었습니다.

예를 들어, 가장 우선으로 진행한 작업은 타입 안전하지 못했던 폼 데이터 타입 관리 방식을 개선한 것입니다. 첫 개선 작업이었기 때문에 가장 변경하기 까다로운 상황에서, 제품 운영의 안정성에 영향이 없으면서 개선 임팩트가 큰 일이 무엇일지 고민했기 때문에 내린 결정입니다. 또, 기존에는 antd Form을 react-hook-form으로 전환하는 작업이 매우 큰 작업으로 예상되어 우선순위를 낮춰두었지만, 세부 태스크로 쪼개어 보니 일부 영역만 점진적으로 전환해도 큰 개선 효과를 기대할 수 있어서 먼저 진행하게 되었습니다. 결과적으로 한정된 시간 동안 안정적이면서 효과적인 개선을 통해 ‘첫 번째, 기술 부채에 대한 팀과의 이해도 맞추기’에서 언급한 전사 핵심 과제에서 문제가 예상됐던 부분을 회피할 수 있었습니다.

‘타입 안전성 문제’에서 최대한 문제를 작게 분해했던 사례.

세 번째, 기술 부채 관리를 팀의 시스템으로 만들기

기술 부채에 대해 팀과의 이해도를 맞추고, 문제를 분해해 관리 가능한 상태로 만들었더라도, 관리의 지속성이 없다면 문제가 반복될 수 있습니다. 그렇기 때문에 반복 가능한 시스템이 필요합니다. 시스템이 있으면 일시적으로 기술 부채 관리를 하지 못하더라도 필요할 때 바로 관리에 돌입할 수 있다는 장점도 있죠.

저는 기술 부채의 시스템화를 위해 ‘첫 번째, 기술 부채에 대한 팀과의 이해도 맞추기’에서 언급한, 문제 상황 전달을 위한 문서를 비슷한 상황이 있을 때 재사용하거나 기록을 누적해 나갈 수 있도록 했습니다. 또한, 팀의 주간 미팅을 통해 기술 부채를 정기적으로 재검토하고 우선순위를 판단하여 문제가 적절한 때에 다루어질 수 있도록 했습니다. 상황에 따라 이 시스템을 실행하지 못하는 시기도 있었지만, 꾸준히 기술 부채를 기록하며 다시 여유가 생겼거나 필요한 순간에 시스템을 재개할 수 있었습니다.

팀 내 기술 부채 관리를 위한 노션 페이지.

마치며

지금까지 기술 부채 개선을 ‘팀의 일’로 만들고, 문제를 분해하여 꼭 필요한 문제를 해결하고, 이를 반복할 수 있도록 한 경험을 소개했습니다. 가장 중요한 것은 기술 부채를 ‘팀의 문제’로 만드는 일입니다. 기술 부채 문제가 아니더라도, 이처럼 팀 안에서 복잡한 문제를 정의하고, 팀과의 이해도를 맞춰 함께 해결해 나가는 것은 다양한 문제 상황에서 중요한 과정입니다. 그리고 이러한 경험과 역량은 앞으로 AI 시대에 개발자에게 주어진 중요한 역할일 것입니다. 비슷한 고민을 가진 독자분들께 이 글의 판단 기준과 경험이 도움이 되길 바랍니다!