제품팀의 생산성은 AI 활용이 아니라 역할 분배에 달려있다

팀원 모두 AI를 쓰는데 한 사이클은 여전히 오래 걸립니다

최근 한 금융사의 제품팀에서 AX 세션을 진행하고 코칭했습니다. 이 팀에는 기획자, 디자이너, 개발자가 함께 있고, 모두 AI로 각자의 일을 하고 있었습니다. 기획 쪽에는 요구사항과 와이어프레임과 위키가 만들어져 있었고, 개발 쪽에서는 DB, 백엔드, 프론트가 어느 정도 동작하는 첫 앱이 나와 있었습니다. 디자인 쪽은 그 앱 전체 화면에 디자인을 적용하고 다듬는 중이었습니다.

준비된 것은 많았는데 팀이 가장 먼저 꺼낸 이야기는 속도였습니다. 한 번의 개발 실행에 15시간가량 걸린 사례가 제시됐고, 기획 쪽에서는 한 사이클을 돌릴 때 기능 구현이 너무 오래 걸려 기대하던 AX 프로세스와 다르다고 했습니다. 현장에서 받아 적은 메모에는 이렇게 남아 있습니다.

순환 속도가 기대만큼 빠르지 않다

결과물은 전보다 빨리 나오지만, 한 사이클이 도는 속도는 기대만큼 빠르지 않다는 뜻입니다. 저장소와 위키와 스킬을 갖췄는데도 기능 하나가 끝나는 시간이 줄지 않으면, AX를 이끄는 리더는 다음에 무엇을 바꿔야 하는지 찾기 어렵습니다.

저는 이 팀의 생산성이 AI를 얼마나 활용하느냐가 아니라 역할 분배에 달려 있다고 봤습니다. 이 글에서 역할 분배는 일을 직군별로 나눠 맡길지, 기능별로 나눠 맡길지를 말합니다.

이어서 지연이 어디서 생기는지 먼저 설명하고, 역할 분배의 단위를 직군에서 기능으로 바꾸는 방식과 그렇게 일하기 위해 필요한 세 가지를 살펴보겠습니다. 코드 생성 속도와 팀 생산성의 차이는 코드 생성이 빨라져도 개발팀이 빨라지지 않는 이유에서 외부 기업 사례로 다뤘고, 이번 글은 제품팀 한 곳의 현장 기록을 다룹니다.

지연은 직군 사이 인계에서 생깁니다

이 팀은 처음에 직군 순서로 작업했습니다. 기획이 요구사항을 쓰고, 그다음 프론트, 그다음 서버 순서로 이어지는 직군별 직렬이었습니다. 프론트 쪽에서는 직렬로 진행한 이유가 문서 동기화가 깨졌기 때문이라고 설명했습니다. 영역을 나누려다 오히려 더 오래 걸린 부분도 있었다고 했습니다.

직군을 넘어갈 때마다 문서가 인계 수단이 되고, 인계받는 직군은 그 문서를 기준으로 다시 작업합니다. 그래서 앞 직군이 문서를 바꾸면 뒤 직군의 결과물과 어긋납니다. 이 팀에서는 첫 동작 앱이 기존 HTML 프로토타입과 달라서 요구사항을 다시 반영해야 했습니다.

개발 쪽 사정도 비슷했습니다. 백엔드에서는 테이블 설계를 개발자가 직접 리뷰했고, 테이블 변경사항을 따라가는 것이 버거웠다고 했습니다. 전체가 함께 진행할 프로세스가 잡혀 있지 않다는 말도 나왔습니다.

세션에서는 별도의 API 명세도 직군 사이 인계 때문에 생긴 관리 지점이라고 분석했습니다. 직군마다 따로 작업하니 화면과 서버 사이의 약속을 문서로 따로 적어 두어야 하고, 그 문서를 계속 최신으로 유지해야 합니다. 이 관리가 별도의 일거리가 됩니다.

이 내용을 모으면 제 해석은 이렇습니다. 각 직군의 작업은 빨라졌지만 직군 사이 인계는 그대로 남았고, 이 팀의 지연은 그 인계에서 생겼다고 봅니다. 세션에서 확인된 상태를 영역별로 정리하면 다음과 같습니다.

표의 개발 행에 있는 문서 동기화와 재작업이 앞에서 설명한 인계 지점입니다. 협업 행의 남은 문제도 같은 방향을 가리킵니다. 기능을 누가 결정하고 어디까지 맡는지가 정해져 있지 않으면 직군 사이에서 확인이 멈춥니다.

역할 분배의 단위를 직군에서 기능으로 바꿉니다

세션에서 논의한 방식은 역할 분배의 단위를 직군에서 기능으로 바꾸는 것입니다. 기획자와 개발자가 기능 하나를 짝지어 요구사항부터 DB, 백엔드, 프론트, 검증까지 이어서 작업합니다. 이때 화면의 변경과 누락을 먼저 결정하고, 필요한 기술 명세와 DB·백엔드·프론트 변경을 이어서 반영합니다.

병렬로 진행할 때도 기준이 달라집니다. 직군별 병렬보다 기능별 병렬이 적합하다는 설명이 세션에서 이어졌습니다. 기능마다 기획자와 개발자 짝이 맡아 각자 요구사항에서 검증까지 진행하고, 서로 다른 기능은 동시에 진행합니다.

flowchart TB
    subgraph SERIAL["직군별 직렬"]
        direction LR
        P["기획<br/>요구사항"] -- "문서 인계" --> F["프론트"]
        F -- "문서 인계" --> S["서버"]
    end
    subgraph PARALLEL["기능별 병렬"]
        direction LR
        A["기능 A<br/>기획자와 개발자가 함께<br/>요구사항 → 구현 → 검증"]
        B["기능 B<br/>기획자와 개발자가 함께<br/>요구사항 → 구현 → 검증"]
        C["기능 C<br/>기획자와 개발자가 함께<br/>요구사항 → 구현 → 검증"]
    end
    A ~~~ B ~~~ C
    SERIAL ~~~ PARALLEL
    style P fill:#e5e7eb,stroke:#6b7280,color:#1f2937
    style F fill:#e5e7eb,stroke:#6b7280,color:#1f2937
    style S fill:#e5e7eb,stroke:#6b7280,color:#1f2937
    style A fill:#dbeafe,stroke:#3b82f6,color:#1f2937
    style B fill:#dbeafe,stroke:#3b82f6,color:#1f2937
    style C fill:#dbeafe,stroke:#3b82f6,color:#1f2937

기능 단위가 인계를 줄이는 이유를 저는 이렇게 설명합니다. 한 기능을 기획자와 개발자가 끝까지 함께 보면, 요구사항을 쓴 사람이 구현 단계에서도 같은 자리에 있습니다. 문서를 거쳐 인계하는 횟수가 줄어들고, 화면이 바뀌면 같은 자리에서 서버 변경까지 이어서 반영할 수 있습니다.

앞에서 지연의 원인으로 꼽은 문서 동기화와 별도 API 명세도 같은 논리로 설명됩니다. 둘 다 직군마다 따로 작업하기 때문에 생기는 관리 지점이므로, 한 짝이 한 기능을 이어서 작업하면 그만큼 적게 필요합니다. 다만 이것은 세션의 분석에 제가 붙인 설명이고, 이 팀에서 실제로 줄었는지는 아직 확인되지 않았습니다.

이 방식은 세션에서 논의하고 제안한 단계입니다. 기획자와 개발자가 작은 기능 하나를 골라 요구사항, 정책과 예외, 구현, 테스트를 함께 확인하는 작업을 세션 중에 시작했고, 그 작업이 끝난 시점은 확인되지 않았습니다.

기능 단위로 일하려면 세 가지가 필요합니다

기능 단위로 역할을 분배하려면 기능 밖에서 갖춰 둘 것이 있습니다. 세션에서 나온 논의를 세 가지로 정리했습니다. 기반 작업을 기능 제작과 분리하는 것, 정해지지 않은 정책을 사람이 답하는 것, 기능을 작게 쪼개는 것입니다.

기반 작업을 기능 제작과 분리합니다

세션에서는 기반 작업과 제품 기능 제작을 구분했습니다. 기반 작업은 위키, 개발 보일러플레이트, 디자인 시스템이고, 제품 기능 제작은 그 위에서 기능 하나씩 만드는 일입니다.

flowchart TB
    subgraph FEATURE["제품 기능 제작"]
        direction LR
        FA["기능 A"]
        FB["기능 B"]
        FC["기능 C"]
    end
    subgraph BASE["기반 작업"]
        direction LR
        W["위키"]
        BP["개발 보일러플레이트"]
        DS["디자인 시스템"]
    end
    FA ~~~ FB ~~~ FC
    W ~~~ BP ~~~ DS
    FEATURE -- "같은 기반을 사용" --> BASE
    style FA fill:#dbeafe,stroke:#3b82f6,color:#1f2937
    style FB fill:#dbeafe,stroke:#3b82f6,color:#1f2937
    style FC fill:#dbeafe,stroke:#3b82f6,color:#1f2937
    style W fill:#dcfce7,stroke:#22c55e,color:#1f2937
    style BP fill:#dcfce7,stroke:#22c55e,color:#1f2937
    style DS fill:#dcfce7,stroke:#22c55e,color:#1f2937

이렇게 나누는 이유는 기능마다 같은 것을 다시 만들지 않기 위해서입니다. 위키가 없으면 기능마다 정책을 처음부터 다시 조사하고, 보일러플레이트가 없으면 기능마다 프로젝트의 기본 구조를 새로 만듭니다. 디자인 시스템이 없으면 기능마다 화면의 기본 요소를 다시 정합니다. 기능별로 병렬로 일할수록 이런 중복은 기능 수만큼 늘어납니다.

저는 AX 리더가 맡는 일이 이 기반 작업이라고 해석합니다. 기능은 팀원들이 짝지어 만들고, 리더는 그들이 같은 기반 위에서 일하도록 위키와 개발 구조와 디자인 시스템을 갖추고 고쳐 갑니다. 세션에서도 기반 시스템의 개선은 실제 사례를 겪으며 계속해야 한다고 정리했습니다.

정해지지 않은 정책은 모델이 아니라 사람이 답합니다

기능을 처음부터 끝까지 이어서 작업하면 기획서에 없는 정책과 예외 조건이 나옵니다. 세션에서는 이런 정책을 모델이 임의로 정하지 않도록 질문을 모으고 사람이 답하는 방식을 논의했습니다. 모델이 구현 중에 빈칸을 스스로 채우면 기획자가 의도하지 않은 정책이 코드에 들어가기 때문입니다.

이를 위해 새 기능에 필요한 결정을 사람에게 되묻는 스킬이 소개됐습니다. 사람에게 직접 묻는 방식이 있고, 기존 위키에 정보가 충분할 때는 위키를 참고하는 방식이 있습니다. 위키에 이미 적힌 정책까지 사람에게 다시 묻지 않게 하려는 구분입니다.

단계마다 문서와 동작 결과도 확인합니다. 요구사항 문서를 확인하고, 구현한 뒤에는 동작하는 화면을 확인하는 식으로 중간 산출물을 점검합니다. 이 확인이 있어야 기능 하나 안에서 잘못된 결정이 뒤 단계까지 이어지지 않습니다.

남은 문제도 있습니다. 표의 협업 행에서 보았듯이 기능의 의사결정권과 담당 범위, 중간 산출물을 확인하는 시점은 더 명료하게 해야 하는 상태입니다. 정책에 누가 답하는지가 정해져 있지 않으면 질문을 모아도 답이 돌아오지 않습니다.

기능을 작게 쪼갭니다

세션에서는 한 관리 기능을 조회, 해지, 정보 변경 같은 작은 기능으로 나눠 각각의 조건을 결정해야 한다고 봤습니다. 하나의 큰 기능으로 두면 조건이 한꺼번에 얽혀서 결정할 것이 많아집니다.

작게 쪼개야 하는 이유는 기획자와 개발자 짝이 한 기능을 끝까지 함께 볼 수 있어야 하기 때문입니다. 기능이 크면 짝이 중간에 갈라져 각자 맡은 부분만 보게 되고, 그러면 다시 직군 사이 인계가 생깁니다.

앞에서 언급한 15시간 사례처럼 이 팀에서는 긴 실행 시간이 병목으로 언급됐고, 기능을 작게 나누자는 논의가 있었습니다. 다만 기능을 쪼개면 실행 시간이 줄어든다고 확인된 것은 아닙니다.

기능 단위로도 풀리지 않은 것: 디자인

기능 단위로 바꿔도 디자인은 답이 나오지 않은 상태로 남았습니다. 이 팀은 AX로 디자인 시스템을 만들면 모듈화돼서 레고 블록처럼 조립할 수 있을 줄 알았다고 했습니다.

손이 너무 많이 들어간다

미감을 끌어올리기 쉽지 않고, 규격화할 수 있는 것이 많지 않아 결국 커스터마이징을 해야 한다는 말도 나왔습니다. 기획서를 넣는다고 디자인이 컴포넌트로 나오지는 않는다고 했습니다.

세션에서 본 시안과 실제 화면의 차이도 이와 같은 맥락입니다. 레퍼런스에서 만든 초기 시안의 인상은 좋지만, 실제 요구사항에 맞추고 여백과 색과 구성을 다듬는 단계에서 품질이 떨어졌습니다. 프로덕션 수준까지 올리는 단계에는 결국 사람 손이 마무리에 들어가고, 그 공수가 얼마나 줄었는지와 마지막 품질을 시스템화할 수 있는지가 팀의 고민이었습니다.

시도 중인 방향은 세 가지입니다. 레퍼런스에서 시안을 만드는 일과 실제 화면에 적용하는 일을 분리해서 점검하고, 디자인 원칙 문서에는 핵심 원칙만 간결하게 남기며, 기본 컴포넌트와 화면 구성 규칙의 역할을 나눕니다. 결과가 어긋나면 입력한 기획 의도와 디자인 규칙을 점검합니다.

저도 이 부분은 답을 찾지 못했습니다. 기획과 개발 쪽에는 이 프로그램이 주는 가치를 비교적 분명하게 말할 수 있었지만, 디자인 직군에는 어떤 가치를 보여줄지 아직 모르겠습니다. 시안과 실제 화면의 품질 차이를 다루려면 디자인 사이클에 대한 제 관점이 필요한데, 재사용할 수 있는 정본도 아직 없습니다.

마치며

이 사례에서 제가 내린 결론은 제품팀의 생산성이 AI 활용보다 역할 분배에 달려 있다는 것입니다. 이 팀의 지연은 각 직군의 작업 속도가 아니라 직군 사이 인계에서 생겼고, 세션에서는 역할 분배의 단위를 직군에서 기능으로 바꾸자고 논의했습니다. 기능 단위로 일하려면 기반 작업의 분리, 정해지지 않은 정책에 사람이 답하는 방식, 기능을 작게 쪼개는 일이 필요합니다. 이 팀이 역할 분배를 실제로 바꿨는지, 바꾼 뒤 속도가 어떻게 달라졌는지는 아직 확인되지 않았습니다.

AX 리더가 자기 팀에서 확인할 질문은 세 가지입니다. 지연이 어느 인계에서 생기는지, 기능 하나를 끝까지 함께 볼 기획자와 개발자 짝이 있는지, 정해지지 않은 정책에 누가 답하는지입니다.