개발팀 AX의 첫 과제는 코드가 아니라 정책이다

코드는 AI가 쓰는데 개발팀은 여전히 기다립니다

최근 한 스타트업 개발팀의 AX 프로그램을 진행하면서 이 팀을 두 번 방문했습니다. 첫 방문에서는 개발자 전원과 1:1로 면담했고, 둘째 방문에서는 팀 전체와 공동 대화를 한 뒤 팀별로 미팅을 했습니다. 이 글은 그 두 번의 방문에서 본 것과 제가 내린 판단을 기록한 것입니다.

1:1 면담에서 먼저 물은 것은 AI를 어떻게 쓰는지와 코드를 직접 보거나 고치는 비율이었습니다. 두 구성원은 직접 보거나 수정하는 비율을 약 20%라고 답했습니다. 면담 응답이어서 측정한 값은 아니지만, AI가 코드의 상당 부분을 쓰고 있다는 점은 여러 면담에서 확인됐습니다.

그런데 구성원들은 개발은 빨리 끝나고 그 앞단이 느리게 돌아간다고 말했습니다. 한 구성원은 기능 하나가 필요한 것이 모두 갖춰졌다는 전제라면 일주일 걸리는데 실제로는 3주가 걸렸다고 설명했습니다. 3주와 일주일의 차이를 만드는 변수로는 기획과 디자인의 차이, 정책 부족을 들었습니다.

정책이 구체화되지 않아 한 기능을 한 번 다시 만든 사례도 나왔습니다. 정책이 부족해 막힐 때마다 담당자를 찾아가 물어봤다는 말도 있었습니다. 이 진술들은 코드를 쓰는 속도가 아니라 코드를 쓰기 전에 필요한 것이 일정을 정한다는 쪽을 가리켰습니다.

이 글의 논지는 AI로 구현이 빨라진 개발팀에서는 병목이 구현 앞단의 정책으로 옮겨간다는 것입니다. 앞서 제품팀의 생산성은 AI 활용이 아니라 역할 분배에 달려있다에서는 누가 함께 일하느냐를 다뤘고, 이번 글은 개발이 무엇을 기준으로 일하느냐, 곧 정책과 명세를 다룹니다. 이어서 둘째 방문에서 병목을 확인한 과정, 팀별로 잡은 첫 과제, 개입의 범위, 아직 확인되지 않은 것을 차례로 정리하겠습니다.

병목은 구현이 아니라 구현 앞단의 정책에 있습니다

둘째 방문의 공동 대화에서는 구성원들이 팀이 겪는 문제를 각자 이야기했습니다. 제기된 문제는 구현 앞단의 지연, 개발팀의 역할에 대한 외부의 인식, 방향 변경, 반복 확인 등으로 갈렸습니다. 저는 이 가운데 가장 많이 겹친 내용을 한 줄로 모았습니다.

상위 기획이 더 디테일하게 정리돼야 한다

전원이 이 문장에 공감했습니다. 한 구성원은 디테일보다 가치와 배경이 담긴, 더 잘 만들어진 기획이 핵심이라고 보완했습니다. 저는 두 의견이 같은 방향이라고 읽었습니다. 개발자가 구현하면서 마주치는 빈칸을 구현 앞단에서 미리 채워야 한다는 것입니다.

모바일 팀은 이 문제를 문서 불일치로 설명했습니다. 문서 도구, 디자인 파일, 코드가 서로 다르고 정책이 바뀐 이력은 어디에도 반영되지 않는다는 것입니다. 그래서 정책을 맞출 때마다 "이거 맞아요?"를 반복해서 확인하게 된다고 했습니다.

백엔드 팀에서는 개발팀이 구현 앞단을 기다리는 시간이 밖에서는 개발팀의 속도로 읽힌다는 진술이 나왔습니다. 구성원들이 보기에는 정책 정리를 기다리는 시간 때문에 일정이 늘어나는데, 밖에서는 그 원인을 개발팀에서 찾는다는 뜻입니다. 이 진술은 개발팀이 구현을 마친 뒤에도 일정이 줄었다고 인정받기 어려운 이유를 설명합니다.

이 절의 내용은 개발팀 구성원이 말한 것이며 기획 쪽의 입장이나 측정한 결과가 아닙니다. 그 한정 안에서 제 해석은 이렇습니다. 구현이 빨라지자 병목이 구현 앞단의 정책으로 옮겨갔습니다.

flowchart LR
    P["구현 앞단<br/>정책 확인과 반복 질문<br/>그대로 남음"] --> B["구현<br/>AI로 빨라짐"]
    B --> D["완료"]
    B -. "정책이 비어 있으면<br/>되돌아가 확인" .-> P
    style P fill:#fee2e2,stroke:#ef4444,color:#1f2937
    style B fill:#dcfce7,stroke:#22c55e,color:#1f2937
    style D fill:#e5e7eb,stroke:#6b7280,color:#1f2937

구현 구간이 짧아져도 그 앞의 정책 확인과 반복 질문 구간이 그대로 남아 있으면 전체 기간은 줄지 않습니다. 기획 쪽이 정책을 어떻게 정리하는지는 이 방문에서 확인하지 못했으므로, 지연의 원인을 기획 쪽에서 찾는 것은 근거가 없습니다. 저는 이것을 정책이 한곳에 모여 있지 않고 문서마다 다르게 적혀 있는 구조의 문제로 봤고, 개발팀이 정책 정리에 함께 참여하는 방향으로 과제를 잡았습니다.

첫 과제는 코딩 도구가 아니라 정책과 명세였습니다

병목이 구현 앞단에 있다는 확인을 바탕으로 모바일 팀, 백엔드 팀, 프론트 팀과 각각 미팅을 했습니다. 각 팀의 사정이 달라 과제도 다르게 잡았지만, 기준은 같았습니다. 코드를 더 빨리 쓰게 하는 도구가 아니라 구현 앞단의 정책과 명세를 다루는 일에서 시작한다는 것입니다. 세 팀의 과제와 합의 수준은 다음과 같습니다.

정책을 한곳에 모읍니다

모바일 팀과 합의한 첫 단계는 정책 전용 저장소를 만드는 것입니다. 이 저장소를 각 앱의 코드 저장소에, 가능하면 서버까지 git 서브모듈로 연결하고, 정책을 마크다운으로 관리하는 단일 기준에서 시작하기로 했습니다. 서브모듈로 연결하면 앱과 서버가 같은 정책 파일을 보게 됩니다.

적용은 한 기능부터 합니다. 다음 방문까지의 과제도 크지 않게 잡았습니다. 이미 나온 정책을 마크다운으로 옮기는 정도입니다.

기존에 쓰던 문서 도구는 버리지 않고 동기화하기로 했습니다. 현재 정책이 적힌 곳을 없애면 그 자체로 새 혼란이 생기기 때문입니다. 기획 쪽이 정책 저장소를 직접 수정하는 것은 제가 가진 장기 구상이고, 이번에 합의한 범위는 아닙니다.

flowchart TB
    DOC["기존 문서 도구"] <-. "동기화" .-> POL["정책 저장소<br/>마크다운, 단일 기준"]
    POL -- "서브모듈" --> IOS["iOS 코드 저장소"]
    POL -- "서브모듈" --> AND["안드로이드 코드 저장소"]
    POL -- "서브모듈, 가능하면" --> SRV["서버 코드 저장소"]
    style POL fill:#dbeafe,stroke:#3b82f6,color:#1f2937
    style DOC fill:#e5e7eb,stroke:#6b7280,color:#1f2937
    style IOS fill:#ffffff,stroke:#6b7280,color:#1f2937
    style AND fill:#ffffff,stroke:#6b7280,color:#1f2937
    style SRV fill:#ffffff,stroke:#6b7280,color:#1f2937

코드보다 명세를 먼저 검토합니다

프론트 팀과는 코드를 생성하기 전에 요구사항을 기술 명세로 쓰고, 그 명세를 팀이 함께 검토하는 방식을 이야기했습니다. 팀은 명세를 쓰지 않았던 것이 아니라고 설명했습니다. 각자 쓰던 방식이 있었지만 서로 공유하지 않았고, 팀 안에서 검토하지도 않았다는 것입니다.

그래서 과제는 새로운 양식을 만드는 것이 아니라 각자 쓰던 방식을 공유하고, 명세 작성과 검토 방식의 1차 합의안을 다음 방문 전까지 정리하는 것으로 잡았습니다. 가능하면 그 전에 초안을 먼저 공유하기로 했습니다.

이것은 기존의 리뷰 봇을 폐기하거나 코드 검증을 중단하자는 합의가 아닙니다. 코드를 검증하는 일은 그대로 두고, 그 앞에 명세를 검토하는 단계를 추가하는 것입니다. 명세 양식과 검토 절차는 아직 정해지지 않았습니다.

완성된 코드가 아니라 작업 계획을 먼저 검토합니다

백엔드 팀에는 리뷰를 풀 리퀘스트 이후가 아니라 작업 계획을 먼저 받는 방식으로 하라고 안내했습니다. 코드가 완성된 뒤에 방향을 고치면 이미 쓴 코드를 함께 고쳐야 하기 때문입니다. 작업 계획을 먼저 검토하면 방향이 어긋난 것을 코드가 쓰이기 전에 확인할 수 있습니다.

코딩 컨벤션에 대한 지적은 사람이 하지 않고 린트와 정적 검사, 문서화된 규칙과 LLM 리뷰로 자동화하는 방안을 검토하기로 했습니다. 사람의 검토 시간은 설계에 쓰자는 취지입니다. 남길 것은 설계가 어떻게 되어 있고 왜 그렇게 결정했는지에 대한 기록입니다.

백엔드 팀에는 전환 과제도 하나 제안했습니다. 기존 서비스를 멈추지 않고 새 구조로 옮기되, 사람은 제약과 설계에 집중하고 코드는 AI로 생성하는 과제입니다. 이 과제의 범위는 팀 리드가 정해 주도하기로 했습니다.

세 과제는 서로 다른 지점을 다룹니다. 모바일 팀의 과제는 정책이 적힌 곳이 여러 곳이라는 문제를, 프론트 팀의 과제는 명세가 팀 안에서 공유되지 않는다는 문제를, 백엔드 팀의 과제는 검토가 완성된 코드에 몰려 있다는 문제를 다룹니다. 세 과제 모두 코드를 쓰기 전에 무엇을 기준으로 삼을지를 먼저 정한다는 점은 같습니다.

기획을 다시 하자는 것이 아닙니다

첫 방문을 마치고 이 프로그램의 범위를 정했습니다. 이미 결정된 방향의 기획 자체를 다시 검토하지 않고, 그 방향을 구현하는 과정에서 생기는 질문과 누락을 보완하는 데 집중하는 것입니다. 개발팀이 정책 저장소에 정책을 모으는 일도 이 범위 안에 있습니다. 새 정책을 정하는 일이 아니라 이미 나온 정책을 모으고 빈칸을 드러내는 일이기 때문입니다.

이 범위는 이 팀의 사정에 맞춘 것이며, 모든 팀에 같은 범위를 권하는 것은 아닙니다.

둘째 방문에서는 개발자가 기획에 참여하고 싶은지도 물었습니다. 의견이 갈렸습니다. 적극적으로 관여하겠다는 구성원부터 조건이 맞으면 참여하겠다는 구성원, 기획을 별도의 전문 영역으로 존중하겠다는 구성원까지 있었습니다.

기획에 더 참여하고 싶다고 답한 구성원들도 맡을 범위와 다음 작업의 우선순위는 아직 정리되지 않은 상태였습니다. 기획 참여는 이전에도 몇 번 논의됐으나 개발 공수가 부족해 이어지지 못했다는 설명도 있었습니다.

저는 이 결과를 문제로 보지 않았습니다. 모든 개발자가 기획에 반드시 참여해야 하는 것은 아니기 때문입니다. 제가 설명한 것은 개발자를 빼자는 것이 아니라, 개발자의 역할이 상위의 설계와 규칙 쪽으로 올라간다는 점입니다.

아직 확인되지 않은 것과 이 사례에서 얻은 원리

앞에서 정리한 과제들은 모두 합의하거나 논의한 단계입니다. 이행 결과는 아직 없습니다. 정책을 마크다운으로 옮기는 작업, 명세 방식의 1차 합의안, 백엔드 팀의 설계 기록은 모두 다음 방문 이후에 확인할 일입니다. 정책 저장소가 실제로 단일 기준이 됐는지, 명세 검토가 재작업을 줄였는지, 작업 계획 먼저 검토가 효과가 있었는지는 확인하지 못했습니다.

제가 제안한 목표는 있습니다. 5주 뒤에 기획 쪽 노트북에 저장소를 설치하고, 자연어로 프로토타입 기능을 붙여 실행해 볼 수 있는 상태입니다. 이것은 기획 단계의 프로토타입이고, 개발팀을 거치지 않은 배포를 뜻하지 않습니다. 목표는 제안이며 달성된 성과가 아닙니다.

프로그램 기간에 대한 질문에는 기술적인 부분은 5주로 가능하지만 근본적인 변화는 그 기간으로 어려울 수 있다고 답했습니다. 정책을 모으는 도구는 5주 안에 세울 수 있어도, 정책을 한곳에서 관리하는 방식이 팀의 일하는 방식으로 바뀌는 데는 더 걸린다고 봤기 때문입니다.

이 한 팀의 두 번의 방문에서 제가 얻은 원리는 다음과 같습니다. AI로 구현이 빨라진 개발팀에서는 병목이 구현 앞단의 정책과 명세로 옮겨가므로, 개발팀 AX의 첫 과제는 코딩 도구가 아니라 정책을 한곳에 모으고 명세를 코드보다 먼저 검토하는 일입니다.

이 원리는 한 팀의 사례에서 나온 것입니다. 다른 팀에서 같은 병목이 나타나는지는 그 팀에서 확인해야 합니다. 코드 생성에 관한 외부 기업 사례와 모델은 코드 생성이 빨라져도 개발팀이 빨라지지 않는 이유에서 다뤘습니다.

마치며: AX 리더가 팀에서 확인할 것

자기 팀의 병목이 구현 앞단에 있는지는 세 단계로 확인할 수 있습니다. 먼저 구성원과 1:1로 만나 AI를 어떻게 쓰는지, 코드를 직접 보는 비율이 어느 정도인지, 일정이 늘어나는 곳이 앞단의 정책인지 구현인지를 묻습니다. 그다음 팀 앞에서 공통 문제를 한 줄로 모아 전원에게 확인합니다.

마지막으로 그 문제를 풀 첫 과제를 팀별로 정합니다. 정책이 흩어져 있는 팀은 정책을 한곳에 모으는 일, 명세를 각자 쓰는 팀은 명세를 함께 검토하는 일, 검토가 완성된 코드에 몰려 있는 팀은 작업 계획을 먼저 검토하는 일이 후보가 됩니다. 이 순서는 한 팀의 두 번의 방문에서 정리한 것이며, 다른 팀에서는 질문과 과제가 달라질 수 있습니다.

확인한 결과 병목이 구현 앞단에 있다면, 리더가 먼저 할 일은 새 코딩 도구를 도입하는 것이 아닙니다. 팀의 정책이 어디에 적혀 있는지부터 파악하고, 개발자가 구현하면서 반복해서 묻는 질문을 모으는 것입니다. 그 질문이 곧 정책 저장소에 가장 먼저 적을 항목이 됩니다.