테크니컬 PO: 제품 팀을 재정의할 프로필

Claude Code 또는 이와 유사한 에이전트형 AI (Agentic AI) 도구를 갖춘 숙련된 개발자는 오늘날 데이터 모델, API, 프론트엔드, 로그, 분석에 이르기까지 기능 전체를 구현할 수 있습니다. 과거에는 여러 전문가의 협업이 필요했던 작업이 이제는 단 한 명에 의해 수행될 수 있습니다. 하지만 이러한 실행 능력은 무엇을 왜 만드는지에 대한 깊은 이해 없이는 가치가 없습니다. 바로 이 지점에서 아직 잘 알려지지 않은 프로필인 '테크니컬 PO (Technical PO)'가 상당한 중요성을 갖게 될 것입니다.

에이전트형 AI (Agentic AI) 상세 정보

에이전트형 AI가 개발자의 일상을 어떻게 변화시키는지, 그리고 AI 활용의 3단계 수준을 이해하려면,
IA au service de la DX : bien plus que de la complétion de code를 참조하세요.

두 가지 역량, 매우 다른 두 가지 경로

역량	현재	에이전트형 AI와 함께하는 미래
기술적 반사 신경 (테스트, 아키텍처, 엔드포인트)	필수적이며, 수년에 걸쳐 습득됨	내장된 기술과 베스트 프랙티스(Best Practices)의 지원을 받음
...

기술적 반사 신경: 낮아지는 장벽

오늘날 개발자가 엔드 투 엔드 (end-to-end) 기능을 구현할 때, 그는 일련의 기술적 반사 신경을 숙달해야 합니다. 깔끔한 엔드포인트 (endpoint) 설계, 시작 단계부터 자동화된 테스트 (automated tests) 고려, 아키텍처 (architecture)가 시스템의 나머지 부분과 일관성을 유지하는지 검증, 그리고 엣지 케이스 (edge cases) 예측 등이 그것입니다. 이러한 반사 신경은 수년간의 실무를 통해 습득되며, 주니어 개발자와 숙련된 개발자를 구분 짓는 요소가 됩니다. 하지만 Claude Code와 같은 도구에서 전용 스킬 (skills)이 등장함에 따라 이러한 장벽은 상당히 낮아지고 있습니다. 이 스킬들은 몇 년 전의 Docker 컨테이너 (containers)와 유사하게 작동합니다. 예전에는 직접 구축하는 데 며칠이 걸렸을, 우리가 필요로 하는 정확한 베스트 프랙티스 (best practices)를 담은 블록을 선반에서 바로 꺼내 쓰는 것과 같습니다. 올바른 패턴을 갖춘 REST API를 생성해야 하나요? 특정 스킬이 이를 담당합니다. 엣지 케이스를 커버하는 단위 테스트 (unit tests)를 추가해야 하나요? 마찬가지입니다.

이러한 기술적 반사 신경이 완전히 사라지지는 않을 것입니다. 생성된 코드가 제대로 작동하는지, 아키텍처가 탈선하지 않는지, 기술 부채 (technical debt)가 통제 가능한 수준인지 검증할 수 있는 사람은 여전히 필요할 것입니다. 하지만 올바르고 잘 구조화된 코드를 생산하기 위한 진입 장벽은 상당히 낮아질 것입니다. 저는 이러한 스킬들이 결국 LLM이나 CLI와 같은 엔진 자체에 직접 통합되어, 이러한 베스트 프랙티스들을 선택 사항이 아닌 자동화된 사항으로 만들 것이라고 해도 놀랍지 않습니다. 이러한 맥락에서 순수한 기술적 역량은 희소성을 잃게 될 것입니다. 그리고 과거에 개발자의 주요 가치 기준이었던 요소들은 점차 다른 무언가에게 자리를 내어줄 것입니다.

여전히 필수적인 것: 무엇을 만드는지 이해하는 것

에이전틱 AI (Agentic AI)의 속도로 기능을 구현하는 것은 인상적입니다. 하지만 올바른 이유로, 올바른 방식으로, 올바른 기능을 구현하는 것은 전혀 다른 차원의 문제입니다. 그리고 바로 이 지점에서 제품 이해도 (Product Understanding)가 진정한 차별화 요소가 됩니다. 이는 단순히 구현해야 할 화면이나 사용할 디자인 시스템 (design system) 구성 요소를 이해하는 것만을 의미하지 않습니다. 왜 이 기능이 존재하는지, 사용자가 실제로 무엇을 기대하는지, 그 영향을 측정하기 위해 하류(downstream)의 데이터 분석 (Data Analyse) 팀이 무엇을 필요로 할지, 그리고 구현 선택에 영향을 미칠 프로덕션 인프라의 제약 사항이 무엇인지를 이해해야 합니다. 이 모든 것을 이해하는 개발자는 단순히 명세서 (spec)를 구현하는 데 그치는 개발자보다 근본적으로 훨씬 더 나은 결과물을 만들어낼 것입니다.

솔직히 말해서, 코드에만 관심을 두고 제품에는 관심이 없는 개발자는 향후 몇 년 동안 가치가 크게 하락할 것입니다. 에이전틱 AI (Agentic AI)가 코딩 속도를 10배 더 빠르게 만들어줄 때, "코딩하는" 부분은 더 이상 가장 큰 가치를 창출하는 요소가 아닙니다. 차이를 만드는 것은 바로 "무엇을 코딩할지 아는" 부분입니다. 비즈니스 이슈를 이해하고, 사용자의 니즈를 예측하며, 영업(Sales) 및 지원(Support) 팀과 소통하여 실제 페인 포인트 (pain points)를 파악하는 개발자 — 바로 이런 사람이 대체 불가능한 존재가 될 것입니다. 반면, 상세한 명세서 (spec)가 주어지기만을 기다리며 업무를 시작하는 사람은, 그가 떠나더라도 아마 대체되지 않을 것입니다.

테크니컬 PO (Le PO Technique): 이미 존재하는 프로필

제품에 대한 깊은 이해를 갖춘 이 개발자 프로필은 이론적인 발명품이 아닙니다. 저는 고객사에서 다양한 명칭으로 이들을 정기적으로 마주합니다. 이들은 기술과 제품 사이의 연결 고리를 만드는 과정에 매료된 숙련된 개발자들—확립된 전문가 또는 시니어(Senior)급—입니다. 종종 이들은 인접한 역할인 Scrum Master, Delivery Owner, 또는 특정 조직에서의 프록시(Proxy) Product Owner로 시작하기도 했습니다. 엔지니어링(Engineering) 팀 출신인 이들은 제품의 구축 초기 단계부터 참여했기 때문에 제품에 대해 매우 명확한 시야를 가지고 있습니다. 이들은 기술적 제약 사항을 알고, 아키텍처(Architecture) 선택을 이해하며, 동시에 사용자와 고객의 니즈에 관심을 가짐으로써 진정한 제품 문화(Product Culture)를 발전시켜 왔습니다.

하지만 지금까지 이러한 프로필은 역설적으로 충분히 활용되지 못했습니다. 시간과 대역폭(Bandwidth)의 부족으로 인해, 이들은 사용자 스토리(User Stories) 작성, 이해관계자(Stakeholders)와의 논의, 기능 테스트, 백로그(Backlog) 우선순위 지정과 같은 전통적인 제품 책임자(Product Owner)의 업무에 국한되어 있었습니다. 프로세스의 마지막 단계에서 이들은 기술 팀이 즉시 실행 가능한 명세서(Spec)를 전달했습니다. 이것만으로도 이미 상당한 기여입니다. 이러한 명세서의 품질은 기술적 배경이 없는 PO의 명세서보다 훨씬 뛰어난 경우가 많기 때문입니다. 그러나 명세서와 구현(Implementation) 사이에는 여전히 지연(Latency)과 정보 손실, 세부 사항을 명확히 하기 위한 반복적인 피드백 과정이 남아 있었습니다. 에이전틱 AI(Agentic AI)와 함께라면 이러한 마찰은 사라집니다. 이들은 중간 매개자 없이 제품에 대해 이해한 바를 직접 그리고 자율적으로 실행에 옮길 수 있게 될 것입니다.

30명 대신 3명

잘 정립된 제품 팀의 일반적인 비율은 개발자 7~10명당 약 1명의 Product Owner입니다. 3명의 PO와 25명의 개발자로 구성된 전형적인 팀은 일정 수준의 속도로 결과물을 인도합니다. 이 팀을 에이전틱 AI (Agentic AI) 도구를 갖춘 3명의 테크니컬 PO (Technical PO)로 교체하면 그 결과는 놀랍습니다. 최근 제가 지원하는 한 팀과 함께 완전한 백오피스 (Back-office) 구축을 테스트해 볼 수 있었습니다. 클래식한 워크플로 (Workflow)를 사용하는 팀이 내놓은 초기 추정치는 약 40인일 (man-days)에 육박했습니다. 하지만 모든 작업은 2인일 (man-days) 만에 완료되었으며, 심지어 처음에 계획했던 범위를 조금 더 넘어섰습니다. 이는 인위적인 벤치마크가 아닌, 실제 기능 (Feature) 구현에서 나타난 20배의 차이입니다.

이 수치는 마법이 아닙니다. 조직 내의 모든 지연 시간 (Latency)을 제거함으로써 설명됩니다. PO와 개발자 사이의 핸드오프 (Handoff)가 더 이상 필요 없고, 우선순위 결정을 기다릴 필요도 없으며, 사양 (Spec)을 명확히 하기 위한 반복적인 피드백 과정도 사라집니다. 테크니컬 PO는 요구사항을 이해하고, 이를 공식화하며, 연속적인 흐름 속에서 직접 구현합니다. 물론 이것이 모든 기능이 이 운영 방식에 적합하다는 의미는 아닙니다. 기술적 또는 아키텍처 (Architecture) 복잡도가 높은 주제는 여전히 전문 개발자를 필요로 할 것입니다. 하지만 백로그 (Backlog)의 상당 부분, 즉 백오피스, 통합 (Integrations), CRUD, 대시보드 (Dashboards) 등에는 이 운영 방식이 무시무시할 정도로 효율적입니다. 그리고 이는 우리가 제품 및 기술 팀을 어떻게 규모화하고 구조화할지에 대한 판도를 기계적으로 뒤흔들 것입니다.

CTO와 CPO에게 미치는 변화

그 영향은 매우 심오합니다. 우선 채용 측면에서 보면, 주로 순수 기술 역량만을 평가하던 프로세스 (processus)가 진화해야 할 것입니다. 후보자에게서 찾아내야 할 것은 제품에 대한 열망 (appétence produit), 비즈니스 니즈를 이해하는 능력, 그리고 사용 사례에 대한 호기심입니다. 기술적으로는 평범하지만 제품 이해도가 뛰어난 개발자가, 자신이 무엇을 만드는지에 관심이 없는 뛰어난 기술자가 되는 것보다 더 높은 가치를 지니게 될 것입니다. 이는 선발 기준의 중대한 역전입니다.

다음으로 조직 측면에서는, 제품 팀과 기술 팀 사이의 경계가 계속해서 모호해질 것입니다. 테크니컬 PO (Technical PO)는 이러한 융합의 선구자이지만, 변화하는 역할은 이들뿐만이 아닙니다. 시니어는 아키텍트-리뷰어 (architecte-reviewer)가 되고, 주니어는 더 빠르게 역량을 쌓으며, 매니저는 집중하는 지점이 달라집니다. 저는 이러한 모든 변화를 AI로 강화된 기술 팀의 새로운 역할들 (les nouveaux rôles dans une équipe tech augmentée par l'IA)에서 지도화해 두었습니다. 실제로 이러한 프로필을 가진 이들은 이후에 훌륭한 매니저가 되는 경우가 많습니다. 그들의 이중 문화 (double culture) 덕분에 제품 경영진은 물론 엔지니어링 팀과도 원활하게 소통할 수 있기 때문입니다. 이들은 자연스럽게 Head of Product 또는 CPO 직책으로 올라갑니다. 조직 내에서 이들을 조기에 식별하고, 제품 역량 강화를 지원하며, 그들이 잠재력을 최대한 발휘할 수 있는 도구를 제공하는 것이 향후 몇 년간 주요한 경쟁 우위가 될 것입니다.

요약

에이전트형 AI (Agentic AI)가 개발자를 쓸모없게 만드는 것은 아닙니다. 대신, 개발자가 자신이 무엇을 만드는지 이해하지 못한 채 단순히 코딩만 해도 된다는 생각을 쓸모없게 만듭니다. 엔지니어링 배경을 바탕으로 진정한 제품 문화 (Product Culture)를 갖춘 하이브리드 프로필인 '테크니컬 PO (Technical PO)'가 바로 이러한 도구들을 가장 잘 활용할 사람입니다. 요구사항에 대한 이해와 자율적인 실행 능력을 결합함으로써, 이러한 프로필을 가진 소규모 팀은 이전에는 수십 명의 인원이 필요했던 결과물을 만들어낼 것입니다. 이들을 차별화하는 것은 마법 같은 도구가 아니라, 프레이밍 (Framing)부터 결정론적 테스트 (Deterministic Testing)에 이르기까지 제품 빌더의 모든 도구 상자 (Product Builder's entire toolbox)를 다루고 상황에 따라 어떤 도구를 꺼내 써야 할지 아는 능력입니다. CTO와 CPO에게 과제는 명확합니다. 이러한 프로필을 식별하고, 이들을 성장시키며, 이 새로운 현실을 중심으로 조직을 재설계하는 것입니다.

기술 및 제품 조직을 재설계하고 싶으신가요?

에이전트형 AI 컨설팅 (Agentic AI coaching)을 통해, 적합한 인재를 식별하고, 채용 프로세스를 조정하며, 에이전트형 AI를 활용할 수 있도록 팀을 구조화하는 데 도움을 드립니다.