이상적인 AI 네이티브 제품 팀을 상상하다
2026년 1월 기준으로 코르카가 생각하는 이상적인 AI 네이티브 제품 팀, 즉 '좋은 에이전틱 엔지니어링 프로세스와 프랙티스가 정착된 팀'이 일하는 모습을 묘사해봤습니다. 코르카 내부 팀은 이 방향으로 빠르게 변하고 있으며, 코르카가 진행하는 AX 코칭/컨설팅도 '고객사의 제품 팀이 이러한 모습으로 변하기 위한 씨앗 심기'를 주된 목적으로 삼습니다.
1. AI와 협업하는 방식
프롬프트 리뷰와 짝 프롬프팅
인간이 직접 하는 코드 리뷰 시간은 줄어든다. 대신 스펙 프롬프트를 리뷰하는 시간과 짝 프롬프팅에 투자하는 시간이 늘어난다. "이 프롬프트로 에이전트에게 요청하면 어디서 실수할까?"를 함께 고민한다.
짝 프롬프팅은 다양한 상황에서 활용된다:
- 스펙 작성: 복잡한 요구사항을 정리할 때 둘이 함께 프롬프트를 다듬으며 빠진 부분을 찾는다.
- 문제 해결: 에이전트가 예상대로 동작하지 않을 때 함께 원인을 분석하고 프롬프트를 개선한다.
- 온보딩: 새 팀원이 기존 팀원과 함께 프롬프팅하며 도구와 워크플로우를 익힌다.
- 학습: 서로의 프롬프팅 방식을 관찰하며 새로운 기법을 배운다.
팀 지식의 자산화
각자 사용하는 프롬프트가 코드베이스 내에 자산화된다. 새로운 도구와 방법론을 실험하고 공유하는 문화가 자리 잡는다. 매주 슬랙에 이번 주 실험해본 도구, 프로세스, 워크플로우가 공유되고, 누적된다.
자산화의 범위는 프롬프트에 그치지 않는다:
- 프롬프트와 스킬: 반복 사용되는 프롬프트는 스킬로 정리되어 팀 전체가 활용한다.
- 회고 기록: 에이전트와의 시행착오, 개선 과정이 GitHub 이슈, PR description, 커밋 로그에 남는다.
- 의사결정 맥락: "왜 이렇게 했는지"가 기록되어 나중에 같은 문제를 만났을 때 참고할 수 있다.
AI의 한계와 인간의 역할
AI가 잘하는 영역과 인간이 반드시 개입해야 하는 영역을 구분한다. 최종 비즈니스 의사결정, 윤리적 판단, 고객·이해관계자와의 감정적 소통은 (아직까지는) 인간의 몫이다. 에이전트가 같은 문제로 반복 실패하거나 예상치 못한 방향으로 갈 때 개입하는 기준을 팀 내에 공유한다.
스펙-구현-회고 싸이클
자료 조사 → 스펙 작성 → 스펙 정교화 → 스펙 리뷰 → 구현 지시 → 회고 → 코드 리뷰 싸이클이 정착된다.
- 자료 조사: 스펙을 작성하기 위해 필요한 회사 내부/외부의 정보들이 이미 LLM이 읽기 좋은 형태로 준비되어 있거나, 정보를 취합하는 도구들(MCP, 스크립트, 커스텀 프롬프트 등. 예: slack-to-md skill)이 준비되어 있다. 이러한 기초 자료들을 리서치 에이전트에게 던져 보고서를 받는다.
- 스펙 작성: 보고서를 가공한 스펙을 Jira 티켓/Github 이슈 등에 (가능하면 짝 작업으로) 작성한다.
- 스펙 정교화: 스펙을 정교하게 만드는 도구(예: Clarify skill)가 준비되어 있다. 이를 로컬에서 직접 실행하거나 GitHub Action 등으로 자동화한다. (가능하면 동료와 함께) 이 도구와 대화하며 스펙을 다듬는다.
- 스펙 리뷰: 정교화된 스펙을 검토하여 최종 버전을 만든다. 스스로 검토할 역량이 부족하다면 적극적으로 학습한다. AI와 함께, 동료와 함께 도메인 지식, 코드베이스에 대한 이해, 의사결정 근거에 대한 이해 등을 높인다.
- 구현 지시: 최종 스펙을 코딩 에이전트에게 전달하여 구현시킨다. 좋은 PLAN 문서와 테스트 케이스가 있다면 한 턴 만에 원하는 기능이 나올 수 있다는 걸 믿으며, 이를 실현하기 위해 노력한다.
- 회고: 원하는 결과가 한 번에 나오지 않았다면 회고한다. 에이전트에게 "이러저러한 이유로 원하는 대로 되지 않았는데, 처음에 어떻게 했으면 원하는 대로 나왔을까?" 묻고, 그 응답대로 다시 구현하는 걸 실험해본다. 이 과정은 팀 지식으로 자산화된다.
- 코드 리뷰: 구현 완료 후에는 코드 리뷰 에이전트(CodeRabbit 또는 GitHub Action + Claude Code 등으로 직접 구축)에게 사전 리뷰를 받음으로써 인간이 직접 리뷰할 부분을 최소화한다. 잘못 구현한 부분(False Positive)과 빠뜨린 부분(False Negative) 모두에 대해 회고하고, "처음에 어떻게 했어야 이 실수를 하지 않았을까"를 배운다.
2. 조직 문화의 변화
직군의 경계가 흐려진다
기획자와 디자이너가 코드를 짜서 Working Prototype을 보여주거나, 직접 PR을 작성한다. 개발자는 프론트엔드, 백엔드, DB, 인프라 모든 곳에 개입하며, 나아가 기획과 마케팅까지 제품 개발의 전 영역을 다룬다. 직군 간 학습과 대화가 매우 빈번하게 일어난다.
모든 일은 자동화할 수 있다
사람이 컴퓨터로 직접 하는 모든 일은 코드나 LLM으로 대체할 수 있다고 믿는다. 일상적으로 하는 일을 일부라도 대체하기 위해 적극적으로 노력한다. 권한이나 보안 문제로 처음부터 완전 자동화는 어려우나, 사람이 파일을 올려주거나 내용을 복사해주는 방식으로 접착제 역할을 해준다면 생각보다 아주 많은 일이 가능해짐을 인식한 채로 움직인다.
한 사람이 처음부터 끝까지
레거시 의존성이 적은 새 프로젝트는 되도록 한 사람이 메인 오너십을 가지고 처음부터 끝까지 E2E로 담당한다. 단, 개인 오너십과 짝 작업은 상호 배타적이지 않다:
- 개인 오너십: 의사결정의 최종 책임, 전체 진행 상황 파악, 일정 관리는 한 사람이 맡는다.
- 짝 작업 시점: 자료 조사, 디자인, 마케팅, 법무 검토 등 전문성이 필요한 단계, 또는 복잡한 스펙을 다듬을 때는 적극적으로 짝 작업을 요청한다.
즉, "혼자 다 하는 것"이 아니라 "한 사람이 오케스트레이션하되 필요할 때 협업하는 것"이다.
실패를 두려워하지 않는다
새로운 도구, 프롬프트, 워크플로우 실험이 실패해도 괜찮다. 실패 사례도 성공 사례만큼 적극적으로 공유하고, "왜 안 됐는지"를 함께 분석한다. 에이전트가 예상대로 동작하지 않는 것은 자연스러운 일이며, 이를 통해 팀 전체가 학습한다.
새 팀원의 온보딩
AI 네이티브 방식에 익숙하지 않은 새 팀원은 짝 프롬프팅을 통해 학습하고, 자산화된 프롬프트와 스킬을 활용하며 점진적으로 익숙해진다. 처음에는 작은 범위의 작업부터 시작해 단계적으로 책임 범위를 넓혀간다.
3. 기술적 실천
코드 품질에 투자한다
메인 제품의 코드 품질에 모두가 적극적으로 투자한다. 코드베이스의 품질이 높아질수록 코딩 에이전트가 더 잘 일한다는 사실을 모두가 이해한다. 코드 품질 지표가 대시보드로 관리되고, 우상향하는 프랙티스가 정착된다(매일 tidying 등). E2E 테스트가 잘 갖춰져 있어서 대규모 리팩토링이 두렵지 않은 상태가 된다.
Papercut을 해결한다
코드 품질을 높이는 도구를 비롯하여, 기존에는 "구현하기만 했다면 팀의 효율을 높였겠지만 우선순위가 밀려서 구현하지 않았던" 많은 papercut work이 실제로 구현된다. 백오피스 어드민, 다양한 린터 룰, 테스트 코드, 정적 분석 스크립트 등.
Evaluation Set이 최우선이다
자동화된 검증이 가능하다면 에이전트가 얼마든지 반복하며 결과를 개선할 수 있으니, 우선 Evaluation set을 확보함으로써 에이전트가 오래 일하며 신뢰할만한 결과를 내는 환경을 만들어주는 데 집중한다. 새로운 기능을 구현할 때 "이걸 어떻게 자동으로 검증할 수 있을까?"를 먼저 묻는다.
토큰은 절약보다 낭비가 낫다
AI 네이티브 팀에서 "효율성"은 사람 시간의 최적화를 의미한다. 토큰 비용은 전기료 수준으로 싸질 것이라 믿는다. 사람이 개입해 토큰을 아끼는 데 시간과 노력을 들이기보다 에이전트를 더 오래, 더 많이 일하게 만들 방법을 고민한다. 어차피 토큰 일부러 쓰려고 해도 쓰기 어렵다. 최대한 충분한 정보를 주고, 검증-재시도 루프를 넉넉히 돌린다.
4. 프로세스 자체를 개선한다
이 문서에 적힌 프로세스는 특정 시점의 스냅샷에 불과하다. 정기적으로 현재 워크플로우를 점검하고, 더 나은 방법이 있는지 논의한다. 새로운 AI 도구나 기능이 나오면 기존 프로세스에 어떻게 녹일 수 있을지 실험한다. 프로세스 개선 제안은 누구나 할 수 있으며, 실험 결과를 바탕으로 채택 여부를 결정한다.
Member discussion