코드가 빨라져도 출시가 늦는 팀, 어디서부터 바꿨나

출발점: 개발 속도가 아니라, 출시까지의 대기

이 팀의 첫 질문은 제품 개발이 왜 느린가였습니다. AI로 코드를 작성하고 있었지만, 정책과 요구사항을 다시 확인하고 변경된 내용을 맞추는 데 시간이 들었습니다. 도구를 얼마나 잘 쓰는지보다 요청이 들어와 제품이 나오기까지 어디서 기다리는지를 먼저 살폈습니다.

먼저 전원의 이야기를 듣고, 팀별 첫 과제를 나눴습니다

첫 방문에서는 개발자 전원과 1:1로 면담해 현재 일하는 방식과 어려움, 프로그램에서 바라는 것을 들었습니다. 다음 방문에서는 공동 대화와 팀별 미팅을 진행했습니다. 이후 기획 쪽의 상황도 듣고, 같은 기능을 두고 서로 다른 문서와 판단 기준을 보고 있지는 않은지 확인했습니다.

1:1 진단 → 공동 대화 → 팀별 첫 과제 → 다음 회차에서 진행 상황과 기준 점검

• 모바일: 흩어진 정책을 한곳에서 확인할 수 있도록 정책·명세 저장소를 첫 과제로 정했습니다. 이미 정해진 정책과 아직 결정되지 않은 질문을 구분하는 데 초점을 뒀습니다.
• 프론트엔드: 각자 쓰던 명세 작성 방식을 공유하고 팀이 검토할 기준을 정하도록 했습니다. 코드가 나온 뒤에만 검토하는 대신, 구현 전에 요구사항과 완료 조건을 확인하는 방향입니다.
• 백엔드: 리팩토링을 시작하기 전에 왜 지금 필요한지, 어떤 책임과 경계를 바꿀지 설명하도록 했습니다. 코드 작성량보다 설계 이유와 작업 계획을 먼저 검토하는 데 집중했습니다.

후속 점검에서 드러난 것: 문서 제출만으로는 부족했습니다

다음 회차에도 정책이 여러 도구에 흩어진 문제와 디자인·기능 검증의 기준이 맞지 않는 문제가 남아 있었습니다. 명세를 작성하는 일 자체보다 팀이 작성 방식과 검토 순서에 합의하는 일이 먼저라는 점을 다시 짚었습니다. 기획 쪽에서도 산출물과 업무 흐름을 협의하고 있었기에, 개발팀에 새 양식을 주는 것만으로 해결할 수 있는 문제가 아니었습니다.

이 기록에서 확인할 수 있는 진전은 병목을 정책·명세·설계로 나누고, 각 팀이 다음에 무엇을 확인할지 구체화했다는 점입니다. 정책 저장소의 정착이나 검토 절차의 효과까지 확인한 것은 아닙니다. 제안, 과제 합의, 실제 운영 결과를 구분해 계속 점검해야 합니다.

같은 상황의 팀이 먼저 확인할 질문

• 최근 늦어진 기능 하나에서 실제로 기다린 것은 코드였나, 정책·명세·설계의 결정이었나?
• 정책이 바뀌면 누가 어디에 기록하고, 기획·디자인·개발은 같은 내용을 확인하는가?
• 새 문서를 만들었는가에 그치지 않고, 누가 언제 검토해 다음 단계로 넘길지 합의했는가?

아직 성과로 말하지 않는 것

현재 공개할 수 있는 기록에는 비슷한 난이도의 기능을 대상으로 측정한 전후 리드타임, 재작업률, 배포 빈도의 비교값이 없습니다. 개발 속도 향상이나 매출 증가를 이 과정의 성과로 제시하지 않습니다. 다음 단계에서는 요청·결정·구현·검토·배포 시점을 같은 기준으로 남기고, 실제 운영 결과를 비교해야 합니다.