코딩 속도가 빨라도 여전히 출시가 지연되는 이유: 90일 엔지니어링 재설정

AI 도구는 개발자가 코드를 더 빠르게 생산하도록 도울 수 있습니다. 하지만 팀이 풀 리퀘스트(pull requests)를 더 많이 완료하고, 성공적인 데모를 진행하더라도, 고객에게 다음으로 어떤 기능이 제공될지 설명하는 데 어려움을 겪을 수 있습니다.

바로 이 격차가 GeekyAnts가 Santhosh Murthy를 초청하여 발행한 AI Thoughtmakers 대화 Faster Code, Late Releases: The 90-Day Engineering Reset의 핵심 주제입니다.

이 논의는 친숙한 엔지니어링 문제, 즉 눈에 보이는 활동은 건강해 보이지만 실제 배포(delivery)는 예측하기 어려운 상황을 검토합니다. 제안된 해결책은 우선순위, 소유권, 작업 프로세스를 집중적으로 재설정하는 것입니다.

개발자와 엔지니어링 리드에게 유용한 출발점은 코드가 작성된 후 작업이 어디서 대기하고 있는지 이해하는 것입니다.

녹색 대시보드는 미완성된 배포를 숨길 수 있다

Murthy는 이 대화에서 스프린트 계획, 데모, 대시보드가 건강해 보였던 팀을 설명합니다. 문제는 리더십이 분기 말까지 고객에게 무엇이 제공될지 물었을 때 드러났습니다.

팀은 명확하게 답할 수 없었습니다.

완료된 작업이나 증가한 풀 리퀘스트 활동을 보여주는 대시보드는 개발의 개별 단계에 대한 질문에는 답변할 수 있습니다. 하지만 더 큰 배포(delivery)에 대한 질문은 해결되지 않은 채로 남겨둘 수 있습니다.

기능이 구현될 수는 있지만, 여전히 검토, 통합, 테스트 또는 출시 조정(release coordination)을 기다릴 수 있습니다. 이를 진행 상황으로 보고하는 것은 고객이 사용할 수 있기까지 얼마나 많은 작업이 남아 있는지 설명해주지 못합니다.

따라서 유용한 배포 논의는 각 우선순위를 세 가지 요소와 연결해야 합니다:

• 그것이 지원하는 고객 결과(customer outcome).
• 이를 앞으로 나아가게 할 책임자(accountable person).
• 출시 전 남은 단계들(remaining steps)입니다.

이러한 연결고리 없이는, 팀들은 바쁘게 움직이고 있는 것처럼 보이지만 약속을 예측하기 점점 더 어려워지게 됩니다.

더 빠른 코딩은 병목 현상을 리뷰 단계로 옮길 수 있다

스크립트에서 가장 명확한 예시 중 하나는 풀 리퀘스트 검토(pull request reviews)에 관한 것입니다.

머티는 코딩 생성(code creation)이 이전에 상당한 시간을 소모했음을 설명합니다. AI가 해당 단계를 가속화함에 따라, 검토(review) 과정이 더욱 눈에 띄는 제약 사항이 되었습니다.

그는 엔지니어들과의 대화와 AI 지원을 통한 6개월 분량의 백로그(backlog) 기록 검토를 통해 이 문제를 조사했습니다. 검토 단계에서 오랜 기간 머무르는 티켓들이 팀이 제기한 우려 사항들을 뒷받침했습니다.

교훈은 명확합니다. 한 단계를 개선하는 것이 전체 전달(delivery) 프로세스가 개선되었음을 의미하지는 않습니다.

실질적인 조사는 다음을 검토할 수 있습니다:

이러한 질문들은 변경 사항을 능동적으로 진행하는 데 사용된 시간과 기다리는 데 사용된 시간을 구별하는 데 도움이 됩니다.

또한 이는 프로세스 논의를 개발자들에게 더 빨리 일하라고 요청하는 일반적인 요구보다 더욱 구체적으로 만듭니다.

첫 30일: 반복되는 병목 현상(blockers)을 가시화하기

이 기록은 중요한 전달 작업이 계속되는 동안 장애물(roadblocks)을 이해하는 기간으로 첫 한 달을 설명합니다.

재설정 과정이라고 해서 모든 프로젝트가 중단되어야 하는 것은 아닙니다. 기존 고객 약속들은 여전히 주의를 기울여야 하며, 리더십은 어떤 작업에 보호가 필요한지 결정해야 합니다.

머티는 엔지니어들에게 매주 그들의 작업을 반복적으로 늦추거나 시간을 낭비하게 만드는 것이 무엇인지 물어보라고 제안합니다.

답변에는 지연된 검토, 불분명한 출시 일정, 상충하는 팀 우선순위 또는 소유권에 대한 불확실성이 나타날 수 있습니다. 논의된 예시에서는 검토 지연과 출시 조정이 우려 사항으로 부상했습니다.

그러한 대화는 문제에 대한 서면 기록으로 이어져야 합니다:

• 작업은 어디에서 막히는가?
• 그 발견을 뒷받침하는 증거는 무엇인가?
• 어떤 사람이 제약을 해결할 수 있는가?
• 진행 상황이 관찰 가능한 변경 사항은 무엇인가?

목적은 다른 프로세스를 도입하기 전에 전달 문제에 대한 공유된 이해를 확립하는 것입니다.

나머지 60일: 우선순위 보호 및 소유권 명확화

병목 현상(blockers)이 가시화되면, 재설정 과정에는 결정이 필요합니다.

대화에서 나온 권장 사항 중 하나는 새로운 작업을 자동으로 수용하는 것을 멈추는 것입니다. 이를 위해서는 리더십이 명시적인 트레이드오프(trade-off)를 해야 합니다.

예를 들어, 이미 네 가지 우선순위(four priorities)를 처리하고 있는 팀은 결과 없이 다섯 번째 것을 흡수할 수 없습니다. 그 결정은 기존 약속 중 무엇이 이동하는지, 어떤 마감일이 변경되는지, 또는 어떤 요청이 대기해야 하는지를 식별해야 합니다.

그렇지 않으면, 주의가 다른 곳으로 옮겨지는 동안 원래의 우선순위는 서류상에만 남아 있게 됩니다.

오너십(Ownership) 역시 비슷한 명확성이 필요합니다. 각 중요한 기능(feature)은 그 진행 상황, 의존성(dependencies), 그리고 해결되지 않은 결정들을 조정할 책임이 있는 사람이 있어야 합니다.

이것은 한 사람이 모든 작업을 수행한다는 의미가 아닙니다. 팀이 누가 그 기능의 상태를 설명하고 막힌 결정을 앞으로 나아가게 할 수 있는지 아는 것을 의미합니다.

Murthy는 또한 의견 불일치(disagreements)가 논의할 가치가 있지만, 책임 있는 제품 의사결정자(product decision-maker)는 궁극적으로 상충되는 우선순위(competing priorities)를 해결해야 한다고 강조합니다.

재설정(reset)은 그러한 결정들이 작업의 진행 방식을 바꿀 때 유용해집니다.

의사결정 기록(Decision logs)이 추론 과정을 보존하는 데 도움을 줍니다

팀이 왜 그 결정이 내려졌는지 기억하지 못한 채 반복적으로 결정을 재검토할 때 우선순위는 불안정해질 수 있습니다.

대화에서는 스토리나 기능별로 의사결정 기록을 유지할 것을 권장합니다. 이는 무엇이 우선순위가 지정되었거나 연기되었는지, 결정이 언제 이루어졌는지, 그리고 그 배경에 있는 추론(reasoning)을 기록합니다.

간단한 항목은 다음과 같을 수 있습니다:

결정: 보고서 개선 기능(reporting enhancement)의 연기.

이유: 고객 대면 출시가 통합 작업 완료에 의존하기 때문입니다.

담당자: 제품 리드(Product lead).

재검토 조건: 통합 작업이 합의된 출시 마일스톤에 도달할 때.

이 예시 형식은 향후 논의에 시작점을 제공합니다. 변경된 우선순위는 이후 변화된 상황을 바탕으로 평가될 수 있습니다.

90일 후에 무엇이 개선되어야 할까요?

대화에서 설명된 결과는 명확성(clarity)입니다.

팀원들은 자신의 책임, 자신이 지원하는 기능들, 그리고 그 기능들이 고객에게 무엇을 제공할지 이해해야 합니다.

그 명확성을 유지하는 습관에는 주간 우선순위 점검(weekly priority checks), 기록된 의사결정(recorded decisions), 그리고 집중적인 작업을 방해하는 회의를 줄이는 것이 포함됩니다.

이 논의는 또한 스타트업을 위한 소유권 경고 신호도 식별합니다. 즉, 다른 사람들이 맥락(context)을 갖지 못한 반면, 매번 발생하는 장애(incident)나 출시(release) 대화에 항상 같은 두세 사람이 등장하는 경우입니다.

유용한 재설정(reset)은 책임뿐만 아니라 이해도 또한 분배합니다.

코딩 속도가 빨라지면 전달(delivery)을 개선할 기회가 생깁니다. 그 기회를 실현하려면 구현 이후에 발생하는 검토(reviews), 의사결정(decisions), 그리고 인수인계(handoffs)에 주의를 기울여야 합니다.