개발자가 아니라 조직이 빨리 결정하게 만드는 AX

AI 시대에도 개발자 비율이 가장 높은 제품팀

제품팀의 인원 구성을 보면 대부분 개발자가 가장 많습니다. 기획자 한두 명, 디자이너 한 명에 개발자가 여섯에서 열 명인 구성이 흔합니다. 이 비율은 우연이 아니라 개발이 가장 큰 병목이던 시절에 맞춰진 결과입니다.

과거에는 기능 하나를 만드는 데 가장 오래 걸리고 가장 비싼 단계가 구현이었습니다. 그래서 기획과 디자인은 소수가 앞단에서 문서로 정리해 넘기고, 다수의 개발자가 그 문서를 받아 구현하는 구조가 자리를 잡았습니다. 순차적인 인계와 단계별 승인도 구현이 느린 환경에서는 합리적인 선택이었습니다.

지금은 전제가 달라졌습니다. 최근 제가 함께 일한 한 스타트업 제품팀에서는 개발자들이 코드의 상당 부분을 AI에게 맡기고 있었고, 구현 속도는 더 이상 문제가 아니었습니다. 그런데 인원 구성과 협업 방식은 여전히 구현이 병목이던 시절의 것이었습니다.

이 상태에서 AI만 더 도입하면 어떻게 될까요. 잘못된 요구사항이 더 빨리 구현되고, 확정되지 않은 정책을 전제로 한 코드가 더 많이 만들어집니다. 그래서 저는 AI를 도입하기 전에 제품팀의 구조부터 다시 봐야 한다고 판단했습니다. 이 글은 그 판단에서 출발해 조직, 역할, 프로세스, 업무 맥락 시스템을 차례로 바꾼 기록이며, 마지막에 다른 제품팀이 자기 팀을 점검할 질문과 방향을 정리합니다.

병목이 개발에서 기획·디자인·의사결정으로 이동했습니다

개발자들이 AI로 구현 속도를 올린 뒤에 제품팀 전체가 겪은 변화는 이렇습니다. 코드는 빨리 나오는데 기능이 출시까지 가는 시간은 거의 줄지 않았습니다. 개발자들은 요구사항이 모호해 다시 묻고, 정책이 확정되지 않아 기다리고, 디자인이 나올 때까지 기다리는 시간이 늘었다고 말했습니다.

이 현상은 앞서 쓴 개발팀 AX는 구현이 아니라 구현 앞단에서 시작한다에서 자세히 다뤘습니다. 요점은 AI가 구현 비용을 낮추면 병목이 코드 작성에서 구현 앞단의 결정으로 옮겨간다는 것입니다. 구현 앞단의 결정은 정책, 명세, 설계처럼 코드를 쓰기 전에 정해져 있어야 하는 것을 말합니다.

개발 생산성과 제품팀 생산성은 다른 것입니다. 개발자 한 명이 하루에 쓰는 코드의 양은 늘었지만, 제품팀이 한 달에 출시하는 기능의 수는 그대로일 수 있습니다. 병목이 개발 밖으로 나갔기 때문에, 개발자를 더 빠르게 만드는 투자는 제품팀 전체의 속도에 거의 영향을 주지 못합니다.

따라서 최적화의 대상을 바꿔야 합니다. 개발자의 생산성이 아니라 제품팀 전체의 생산성, 더 정확히는 조직의 결정 속도가 대상입니다. 이 글의 나머지는 결정 속도를 올리기 위해 무엇을 바꿨는지 네 층위로 설명합니다.

%%{init: {"flowchart": {"subGraphTitleMargin": {"top": 12, "bottom": 12}}}}%%
flowchart TB
    subgraph BEFORE["AI 도입 전: 대기는 개발에 쌓인다"]
        direction LR
        A1["기획·정책 확정"] --> A2["디자인"] --> A3["개발<br/>대기가 쌓이는 곳"] --> A4["검증·출시"]
    end
    BEFORE ~~~ AFTER
    subgraph AFTER["AI 도입 후: 대기는 구현 앞단에 쌓인다"]
        direction LR
        B1["기획·정책 확정<br/>대기가 쌓이는 곳"] --> B2["디자인<br/>대기가 쌓이는 곳"] --> B3["개발<br/>AI로 빨라짐"] --> B4["검증·출시"]
    end
    style A1 fill:#e5e7eb,stroke:#6b7280,color:#1f2937
    style A2 fill:#e5e7eb,stroke:#6b7280,color:#1f2937
    style A3 fill:#fee2e2,stroke:#ef4444,color:#1f2937
    style A4 fill:#e5e7eb,stroke:#6b7280,color:#1f2937
    style B1 fill:#fee2e2,stroke:#ef4444,color:#1f2937
    style B2 fill:#fee2e2,stroke:#ef4444,color:#1f2937
    style B3 fill:#dcfce7,stroke:#22c55e,color:#1f2937
    style B4 fill:#e5e7eb,stroke:#6b7280,color:#1f2937

첫 번째 변화: 기능 조직에서 목적 조직으로

이 제품팀은 플래닝팀과 개발팀으로 나뉘어 있었습니다. 플래닝팀이 기획과 디자인을 정리해 넘기면 개발팀이 구현하는 순서였고, 두 팀의 일정과 우선순위는 따로 관리됐습니다. 이 구조에서는 개발팀이 질문을 던지면 답이 플래닝팀의 다음 회의까지 기다려야 돌아왔고, 결정 하나가 양쪽 팀의 일정에 끼어들어야 했습니다.

저는 두 팀을 제품팀 하나로 묶고, 그 안에서 목표 단위의 작은 미션 스쿼드를 꾸리는 방향을 제안했습니다. 미션 스쿼드는 하나의 목표를 위해 PO(프로덕트 오너), PD(프로덕트 디자이너), 프론트엔드, 백엔드, iOS, Android 담당이 함께 모인 단위입니다. 직무별로 팀을 고정하지 않고 미션에 따라 구성원을 모으고, 미션이 끝나면 다시 구성합니다.

스쿼드에는 목표 달성에 필요한 결정 권한을 함께 줍니다. 요구사항의 세부 사항, 정책의 공백을 메우는 판단, 출시 범위의 조정은 스쿼드 안에서 결정하고, 조직 전체에 영향을 주는 결정만 위로 올립니다. 결정이 스쿼드 안에서 끝나야 결정 속도가 오르기 때문입니다.

이 변화의 요점은 조직의 중심을 직무에서 목적과 성과로 옮긴 것입니다. 기능 조직은 같은 직무끼리 모여 전문성을 관리하기에 좋지만, 기능 하나가 여러 직무를 거쳐야 하는 제품 개발에서는 인계 지점마다 대기가 생깁니다. 목적 조직은 인계 자체를 줄입니다.

%%{init: {"flowchart": {"subGraphTitleMargin": {"top": 12, "bottom": 12}}}}%%
flowchart TB
    subgraph FUNC["기능 조직: 직무별 인계"]
        direction TB
        F1["플래닝팀<br/>기획·디자인을 문서로 정리"] -->|"문서 인계<br/>다음 회의까지 대기"| F2["개발팀<br/>FE·BE·iOS·Android가 구현"]
        F2 -->|"질문을 보내고<br/>답을 기다림"| F1
    end
    FUNC ~~~ SQUAD
    subgraph SQUAD["미션 스쿼드: 한 목표 아래 공동 해결"]
        direction TB
        S1["미션 목표 하나"] --> S2["PO · PD · FE · BE · iOS · Android<br/>하나의 스펙을 함께 작성"]
        S2 --> S3["스쿼드 안에서 결정하고 실행<br/>조직 전체에 영향 주는 결정만 위로"]
    end
    style F1 fill:#e5e7eb,stroke:#6b7280,color:#1f2937
    style F2 fill:#e5e7eb,stroke:#6b7280,color:#1f2937
    style S1 fill:#dbeafe,stroke:#3b82f6,color:#1f2937
    style S2 fill:#dcfce7,stroke:#22c55e,color:#1f2937
    style S3 fill:#dcfce7,stroke:#22c55e,color:#1f2937

두 번째 변화: 개발자의 역할을 기획까지 확장했습니다

AI는 직무 사이의 업무량 균형을 바꿨습니다. 구현에 드는 시간은 줄었는데 요구사항을 구체화하고 정책을 검토하는 시간은 그대로이거나 오히려 늘었습니다. 소수의 기획자가 다수 개발자의 질문에 답해야 하는 구조에서는 기획자가 새로운 병목이 됩니다.

그래서 개발자가 코딩만 담당하는 역할 구분을 바꿨습니다. 개발자도 고객 문제를 정의하고, 요구사항을 구체화하고, 정책을 검토하는 일에 참여합니다. 구현 앞단의 결정을 기획자에게 묻고 기다리는 대신, 스쿼드 안에서 개발자가 초안을 쓰고 PO가 확인하는 방식으로 바꾸는 것입니다.

PO와 PD의 역할도 함께 바뀝니다. PO는 기획 문서를 작성해 넘기는 전달자가 아니라 문제 해결과 성과를 책임지는 사람이 됩니다. PD는 디자인 산출물을 넘기는 데서 끝나지 않고, 실제로 동작하는 화면에서 경험을 검증하는 사람이 됩니다. 각자의 전문성은 그대로 두되, 역할의 경계를 옆으로 넓히는 것입니다.

이 방식의 장점은 인력 구성을 당장 바꾸지 않아도 된다는 점입니다. 개발자 비율을 낮추고 기획자를 뽑는 데는 시간이 걸리고, 그동안 병목은 그대로 남습니다. 역할과 책임을 다시 쓰면 지금 있는 사람으로 조직 역량을 재배치할 수 있습니다. 저는 AI 시대에는 인력 구성보다 역할과 책임의 재설계가 먼저라고 봅니다. 이 원리는 제품팀의 생산성은 AI 활용이 아니라 역할 분배에 달려있다에서 다른 제품팀의 사례로도 확인했습니다.

세 번째 변화: 프로세스를 최대한 단순하게 만들었습니다

조직과 역할을 바꾸면 프로세스도 따라 바뀌어야 합니다. 기존 프로세스는 단계별 승인, 팀 간 인수인계, 진행 상황 관리로 이루어져 있었고, 각 단계가 결정을 한 번씩 멈추게 했습니다. 작은 스쿼드가 스스로 판단하고 실행하려면 이 단계들을 줄여야 했습니다.

새 프로세스는 다섯 단계로 정리했습니다. 미션(Mission)에서 목표를 정하고, 스펙(Spec)에서 무엇을 만들지 적고, 실행(Execution)에서 만들고, 검증(Verification)에서 확인하고, 결과(Outcome)에서 목표 달성 여부를 봅니다. 완성된 기획서를 기다렸다가 개발을 시작하는 대신, 스펙을 작은 단위로 쪼개 만들고 검증하기를 반복합니다.

스펙은 PO, PD, 개발자가 하나의 문서를 함께 쓰고 발전시킵니다. 기획서, 디자인 문서, 기술 문서가 따로 있고 서로 어긋나는 상태를 없애는 것이 목적입니다. 그래서 업무 관리의 중심을 Jira 같은 티켓 도구에서 스펙 문서, Git, Markdown으로 옮기는 방향을 잡았습니다. 코드와 스펙이 같은 저장소에 있으면 무엇이 결정됐고 무엇이 구현됐는지 한곳에서 볼 수 있습니다.

관리 회의와 반복적인 진행 상황 보고도 최소화합니다. 진행 상황은 스펙과 Git 기록에 남아 있으므로 사람이 모여 보고할 필요가 줄어듭니다. 이 변화에서 제가 배운 것은, AI가 빨리 일하게 만드는 것보다 조직이 빨리 결정할 수 있게 만드는 것이 더 중요하다는 점입니다. 프로세스가 단순할수록 결정이 멈추는 지점이 줄어듭니다.

flowchart TB
    M["미션 Mission<br/>목표를 정한다<br/>결정 주체: 스쿼드"] --> S["스펙 Spec<br/>무엇을 만들지 적는다<br/>작성 주체: PO·PD·개발자 공동"]
    S --> E["실행 Execution<br/>만든다<br/>주체: 개발자와 AI"]
    E --> V["검증 Verification<br/>확인한다<br/>주체: PD·개발자"]
    V -->|"작은 단위로 반복"| S
    V --> O["결과 Outcome<br/>목표 달성 여부를 본다<br/>주체: 스쿼드"]
    style M fill:#dbeafe,stroke:#3b82f6,color:#1f2937
    style S fill:#dcfce7,stroke:#22c55e,color:#1f2937
    style E fill:#e5e7eb,stroke:#6b7280,color:#1f2937
    style V fill:#fef3c7,stroke:#f59e0b,color:#1f2937
    style O fill:#dbeafe,stroke:#3b82f6,color:#1f2937

핵심 설계: 과거·현재·미래로 나눈 업무 맥락 시스템

조직, 역할, 프로세스를 바꿔도 업무 맥락은 여전히 사람의 기억과 대화에 남아 있습니다. 왜 그렇게 결정했는지, 지금 무엇이 확정인지, 다음에 무엇을 해야 하는지를 알려면 누군가에게 물어야 하고, 그 사람이 자리에 없으면 결정이 멈춥니다.

그래서 업무 맥락을 세 개의 층으로 나눠 시스템에 두기로 했습니다. 시간 축을 기준으로 과거, 현재, 미래입니다.

• 과거는 에이전트 세션 DB — 우리가 무엇을 했고 왜 그렇게 했는지에 답합니다. AI 에이전트와 주고받은 작업 기록과 대화, 실행 과정, 시행착오가 여기에 쌓입니다.
• 현재는 LLM 위키 — 지금 무엇이 사실이고 무엇이 결정되어 있는지에 답합니다. 확정된 정책, 의사결정, 현재 유효한 조직과 제품 지식을 LLM이 읽고 쓸 수 있는 문서로 유지합니다.
• 미래는 Beads — 앞으로 무엇을 해야 하는지에 답합니다. Beads는 작업과 의존 관계, 우선순위, 실행 계획을 기록하는 작업 추적 도구입니다.

세 층을 나누는 이유는 과거의 실행 기록과 현재의 확정 지식이 성격이 다르기 때문입니다. 실행 기록은 시행착오까지 포함해 많고 지저분하지만 "왜"를 알려줍니다. 확정 지식은 적고 정리되어 있어야 하며 "지금 무엇이 맞는가"를 알려줍니다. 둘을 한곳에 섞으면 에이전트도 사람도 무엇이 현재 유효한지 가려내기 어렵습니다.

이 구조의 목적은 에이전트가 스스로 업무 맥락을 파악하게 하는 것입니다. 사람에게 진행 상황을 묻는 대신 에이전트에게 묻고, 에이전트는 세 층을 읽어 답합니다. 세 시스템이 연결되면 에이전트가 맥락을 이해하고 이어서 실행하는 자동화의 기반이 됩니다. 요약하면, 사람이 업무를 기억하고 전달하던 구조에서 에이전트가 맥락을 이해하고 이어서 실행할 수 있는 구조로 옮겨 가고 있습니다.

flowchart TB
    H["사람<br/>진행 상황을 에이전트에게 묻고<br/>중요한 결정과 검증을 맡는다"]
    A["AI 에이전트<br/>세 저장소를 읽고 쓰며<br/>맥락을 이어서 실행한다"]
    H -->|"묻는다"| A
    A -->|"결정·검증을 요청한다"| H
    A --> P["과거: 에이전트 세션 DB<br/>무엇을 왜 했는가<br/>작업 기록·대화·시행착오"]
    A --> C["현재: LLM 위키<br/>지금 무엇이 사실이고 결정인가<br/>확정 정책·의사결정·조직 지식"]
    A --> F["미래: Beads<br/>앞으로 무엇을 해야 하는가<br/>작업·의존 관계·우선순위"]
    style H fill:#fef3c7,stroke:#f59e0b,color:#1f2937
    style A fill:#dcfce7,stroke:#22c55e,color:#1f2937
    style P fill:#e5e7eb,stroke:#6b7280,color:#1f2937
    style C fill:#dbeafe,stroke:#3b82f6,color:#1f2937
    style F fill:#e0e7ff,stroke:#6366f1,color:#1f2937

실제 제품팀 AX에서 마주한 현실적인 제약

여기까지가 설계라면, 현장에서는 설계대로 되지 않는 지점이 여럿 있었습니다. 이 글이 성공 사례로 읽히지 않도록 제약을 그대로 적습니다.

첫째, 플랫폼별 인력이 한 명씩입니다. iOS와 Android 담당이 각각 한 명이어서 모든 모바일 기능이 이 두 사람을 거칩니다. 미션 스쿼드를 여러 개 만들어도 모바일 담당은 모든 스쿼드에 들어가야 하므로, 스쿼드 수가 늘수록 이 두 사람이 공통 병목이 됩니다.

둘째, 기능 하나가 여러 플랫폼에 걸쳐 있습니다. 웹, 백엔드, iOS, Android를 모두 고쳐야 하는 기능은 각 부분의 구현이 빨라져도 통합 검증과 배포에서 다시 기다립니다. AI가 코드를 빨리 써도 네 플랫폼의 결과를 맞춰 보고 함께 배포하는 일은 그만큼 빨라지지 않았습니다.

셋째, 에이전트가 만든 코드의 검증과 최종 책임이 누구에게 있는지 정해야 합니다. 개발자가 코드를 직접 보는 비율이 낮아질수록 검증의 기준과 책임 주체를 명시하지 않으면 품질 문제가 뒤늦게 드러납니다. 이 부분은 아직 규칙을 만들어 가는 중입니다.

이 운영 모델은 완성된 정답이 아닙니다. 병목을 하나 옮기면 다음 병목이 다른 곳에서 드러났습니다. 구현이 빨라지자 결정이 병목이 됐고, 결정이 빨라지면 디자인과 통합 검증이 병목이 될 것으로 예상합니다. AI Native 전환은 모든 병목을 없애는 것이 아니라 새로 생기는 병목을 계속 발견하고 해결하는 과정입니다.

앞으로의 실험: 에이전트가 업무를 관리하고 실행하는 조직으로

지금까지의 변화는 사람이 결정하고 에이전트가 돕는 구조 안에서 결정 속도를 올린 것입니다. 다음 실험은 업무 관리 자체를 에이전트에게 옮기는 것입니다. 현재는 스펙, Git, Markdown을 중심으로 운영 체계를 만드는 단계이고, 그 위에서 다음을 시도하려 합니다.

• Beads로 작업 의존성과 실행 상태를 관리 — 어떤 작업이 어떤 작업을 기다리는지, 무엇이 지금 가능한지를 사람의 보고가 아니라 Beads 기록으로 봅니다.
• 에이전트 세션 DB와 LLM 위키를 연결해 맥락을 활용 — 에이전트가 새 작업을 시작할 때 과거의 결정 이유와 현재의 확정 지식을 스스로 읽습니다.
• 에이전트가 다음 작업을 식별하고 실행 — 사람이 작업을 배정하는 대신, 에이전트가 Beads에서 가능한 작업을 찾아 실행하고 결과를 기록합니다.
• 사람은 결정과 검증에 집중 — 진행 상태를 보고받는 대신 중요한 의사결정과 결과 검증에 시간을 씁니다.

장기적으로는 여러 에이전트를 조율하는 에이전트 오케스트레이션과 자동화의 범위를 넓히려 합니다. 요약하면, 업무 관리 시스템 안에서 AI를 쓰는 것이 아니라 AI가 업무를 관리하고 실행하는 시스템으로 발전시키는 것이 방향입니다.

이 실험들은 아직 진행 중이며, 제품 개발 속도가 실제로 얼마나 달라졌는지는 측정 전입니다. 결과가 확인되면 실패한 가설까지 포함해 후속 글로 쓰겠습니다.

%%{init: {"flowchart": {"subGraphTitleMargin": {"top": 12, "bottom": 12}}}}%%
flowchart TB
    subgraph NOW["지금: 사람이 관리하고 에이전트가 돕는다"]
        direction LR
        N1["사람<br/>작업 배정·진행 파악·결정"] -->|"지시"| N2["AI 에이전트<br/>구현 보조"]
        N2 -->|"보고"| N1
    end
    NOW ~~~ NEXT
    subgraph NEXT["다음: 에이전트가 관리하고 사람이 결정·검증한다"]
        direction LR
        X1["AI 에이전트<br/>Beads에서 다음 작업 식별<br/>세션 DB·위키를 읽고 실행·기록"] -->|"결정 요청·결과 제출"| X2["사람<br/>중요한 결정·결과 검증"]
        X2 -->|"결정·승인"| X1
    end
    style N1 fill:#fef3c7,stroke:#f59e0b,color:#1f2937
    style N2 fill:#e5e7eb,stroke:#6b7280,color:#1f2937
    style X1 fill:#dcfce7,stroke:#22c55e,color:#1f2937
    style X2 fill:#fef3c7,stroke:#f59e0b,color:#1f2937

그럼 우리 팀에는 무엇을 어떻게 적용하면 좋을까

위의 변화는 한 제품팀의 사정에 맞춘 것이므로 다른 팀이 그대로 따를 필요는 없습니다. 대신 자기 팀의 병목이 어디에 있는지 먼저 진단하고, 그 병목에 맞는 층위부터 바꾸는 순서를 제안합니다. 진단은 질문 네 개로 시작할 수 있습니다.

• 지난 분기 출시 지연의 원인은 코드였는가, 결정이었는가 — 지연된 기능을 몇 개 골라 기다린 시간이 구현 때문이었는지, 요구사항이나 정책이나 디자인 확정 때문이었는지 나눠 봅니다.
• 요구사항을 최종 확정하는 사람은 누구이고, 그 사람은 몇 명의 요청을 받고 있는가 — 소수의 기획자가 다수 개발자의 질문을 받고 있다면 그 사람이 병목입니다.
• 개발자가 정책 질문을 던지고 답을 받기까지 평균 며칠 걸리는가 — 하루 안에 답이 오지 않는다면 결정이 팀 밖에서 이루어지고 있다는 뜻입니다.
• 진행 상황을 사람에게 묻고 있는가, 시스템에서 읽을 수 있는가 — 진행 상황 회의가 많을수록 업무 맥락이 사람에게 묶여 있습니다.

답에 따라 먼저 바꿀 층위가 달라집니다. 인계에서 기다린다면 조직 단위부터, 결정권자가 적어 기다린다면 역할 경계부터, 승인과 보고에서 기다린다면 프로세스부터, 맥락 전달에서 기다린다면 업무 맥락 시스템부터 바꾸는 것이 맞습니다. 다만 어디서 시작하든 그 전에 현재 업무 분장과 책임 주체를 명확히 하는 일이 먼저입니다. 누가 무엇을 책임지는지 모르는 상태에서 조직이나 도구를 바꾸면 책임의 공백이 다른 자리에서 다시 생깁니다.

공통으로 제안할 수 있는 것은 세 가지입니다. 첫째, 인력 비율을 바꾸기 전에 역할과 책임을 먼저 다시 씁니다. 지금 있는 사람으로 재배치할 수 있는 여지가 생각보다 큽니다. 둘째, 완성된 기획서를 기다리는 대신 PO, PD, 개발자가 하나의 스펙을 함께 쓰는 기능을 하나 골라 시작합니다. 전체 프로세스를 한 번에 바꾸지 않아도 한 기능에서 결정 속도의 차이를 볼 수 있습니다. 셋째, 성과 목표는 팀마다 다르므로 남의 목표를 빌리지 않습니다. 문제 발견부터 출시까지 자기 팀의 리드타임을 먼저 재고, 그 수치를 기준으로 목표를 세웁니다.

저는 AI 시대 제품팀의 과제가 개발자를 더 빠르게 만드는 것이 아니라 조직이 더 빨리 결정하게 만드는 것이라고 생각합니다. 그 결정 속도는 도구가 아니라 조직 단위, 역할 경계, 결정 절차, 업무 맥락 시스템을 어떻게 설계하느냐에서 나옵니다. 자기 팀에서 결정이 멈추는 지점 하나를 찾아 그곳부터 바꾸는 것이 가장 현실적인 시작입니다.