AI 에이전트 시대, 제품 개발 프로세스는 어떻게 바뀌어야 하는가#

2026-05-10

AI 에이전트와 하네스 기반 제품 개발

최근 회사의 업무 프로세스가 AI 에이전트 도입으로 빠르게 바뀌고 있습니다. 필자가 속한 회사는 기술 기반 광고 운영 회사이고, 크게 광고 운영 조직과 프로덕트 개발 조직으로 나뉩니다.

광고 운영 조직은 고객사의 광고를 대행하여 운영합니다. 최근 이 조직은 GitHub 기반으로 광고 운영 지침, 스킬, 브랜드 데이터를 프로젝트화하고, Claude Code 또는 Hermes 같은 AI 에이전트와 대화하며 업무를 처리하는 방식으로 전환했습니다. 이 변화는 비교적 자연스럽게 받아들여졌습니다.

이유는 명확합니다. 광고 운영자는 각자 담당 브랜드를 나누어 맡고, 자신이 맡은 브랜드의 광고 운영을 A부터 Z까지 책임집니다. AI 에이전트는 이 구조에서 기존 담당자의 실행력을 증폭시키는 도구로 작동했습니다. 공통 업무는 스킬로 정리되고, DB 및 시스템 연동은 에이전트를 통해 처리할 수 있게 되었습니다. 각 운영자 입장에서는 기존 책임 범위가 크게 흔들리지 않았습니다.

반면 프로덕트 개발 조직은 상황이 다릅니다. 이 조직은 기획자, 디자이너, 개발자로 구성되어 있으며, 하나의 기능을 만들 때 여러 사람이 하나의 흐름에 참여합니다. 이 구조에서는 AI 에이전트가 단순히 개인의 실행력을 높이는 데서 끝나지 않습니다. 기획, 디자인, 개발 사이의 역할 경계와 책임 구조를 동시에 흔듭니다.

문제는 코드가 아니라 의도 전달입니다#

기존 제품 개발 프로세스는 전형적이었습니다. 기획자가 기획서를 작성하여 요구사항을 전달하고, 디자이너가 화면을 설계한 뒤, 개발자가 구현하고 배포했습니다.

그런데 기획자가 Claude Code를 이용해 프론트엔드 프로젝트에서 직접 화면 변경과 기능 추가를 시도할 수 있게 되면서 상황이 바뀌었습니다. 기획자는 별도 브랜치에서 리뉴얼 방향을 직접 구현했습니다. 기존 API를 그대로 사용할 수 있는 부분은 실제 동작까지 구현했고, API 변경 또는 추가가 필요한 부분은 mock 데이터나 fake 데이터를 이용해 화면을 구성했습니다.

이 방식은 매우 강력합니다. 기획자는 기획서를 쓰는 데서 멈추지 않고, 실제로 움직이는 화면을 만들 수 있습니다. 하지만 동시에 문제가 생겼습니다. 내부 모듈 재사용, 기존 구조와의 정합성, API 경계, 상태 관리, 유지보수성 같은 개발적 고려가 충분히 반영되지 않았습니다. 결과적으로 코드 변경량은 사람이 정상적으로 리뷰하기 어려운 수준으로 커졌습니다.

겉으로 보면 기획자가 직접 구현한 화면은 기존 기획서보다 더 구체적인 산출물처럼 보일 수 있습니다. 화면이 있고, 버튼을 누르면 동작이 보이고, 일부 기능은 실제 API와 연결되어 있습니다. 그러나 이것이 곧 의도 전달이 더 좋아졌다는 뜻은 아닙니다.

기존 기획서에는 화면 구성뿐 아니라 왜 그렇게 구성했는지, 어떤 버튼을 눌렀을 때 어떤 동작을 해야 하는지, 어떤 사용자 흐름을 의도했는지가 적혀 있었습니다. 반면 코드 변경과 그 변경을 기반으로 AI 에이전트가 작성한 텍스트 문서는 사람에게 의도를 전달하는 데 충분하지 않을 수 있습니다.

화면은 “무엇이 바뀌었는가"를 보여줍니다. 그러나 “왜 그렇게 바뀌었는가”, “어떤 대안이 있었는가”, “무엇을 포기했는가”, “정상 동작의 기준이 무엇인가"는 화면만으로 알기 어렵습니다. 특히 AI 에이전트가 변경된 코드를 보고 작성한 문서는 기획자의 원래 의도라기보다, 이미 만들어진 결과를 그럴듯하게 해석한 사후 설명이 될 위험이 있습니다.

이 경우 개발자는 기획 의도를 전달받는 것이 아니라, diff와 화면 동작을 보며 의도를 역추론해야 합니다. 이것은 협업이라기보다 고고학에 가깝습니다.

코드는 기획서를 대체할 수 없습니다#

기획자의 코드 변경은 가치가 큽니다. 하지만 그것이 기획서를 완전히 대체할 수는 없습니다.

코드는 실행 가능한 초안입니다. 기존 기획서보다 화면과 상호작용을 생생하게 보여줄 수 있습니다. 그러나 코드는 의도 자체를 보존하지 않습니다. 무엇이 왜 중요한지, 어떤 기준으로 결정을 내렸는지, 어떤 부분이 확정이고 어떤 부분이 임시인지는 코드에 자동으로 남지 않습니다.

따라서 기획자의 코드 브랜치가 제대로 활용되려면 다음 정보가 함께 제공되어야 합니다.

이 화면 구조가 필요한 이유
해결하려는 사용자 문제
기존 흐름에서 불편했던 지점
버튼, 상태, 예외 케이스별 기대 동작
mock 데이터와 fake 데이터가 남아 있는 위치
실제 API가 가져야 하는 계약
이번 변경에서 확정된 결정과 아직 미정인 부분

이런 정보 없이 코드만 전달되면, 개발자는 제품 의도를 이해하기보다 구현 결과를 해석하는 데 많은 시간을 쓰게 됩니다.

프로토타입과 프로덕션의 경계가 필요합니다#

이 상황에서 가장 중요한 구분은 기획자의 코드 변경을 무엇으로 볼 것인가입니다.

기획자의 코드 변경을 “프로덕션에 넣을 코드"로 보면 문제가 커집니다. 코드 품질, API 경계, 재사용성, 보안, 성능, 장애 대응, 유지보수성은 화면 동작만으로 판단할 수 없습니다. 특히 대규모 리뉴얼처럼 변경량이 클수록, 프로토타입의 코드가 그대로 제품 코드가 되었을 때 장기 비용이 커질 수 있습니다.

반대로 기획자의 코드 변경을 “실행 가능한 초안"으로 보면 매우 강력합니다. 기획자는 자신의 의도를 화면으로 빠르게 검증할 수 있고, 개발자는 정적인 문서보다 더 구체적인 출발점을 얻을 수 있습니다. 문제는 이 초안을 어떻게 프로덕션 품질로 승격시킬 것인가입니다.

따라서 필요한 것은 기획자 브랜치를 그대로 머지할지 말지의 문제가 아닙니다. 필요한 것은 프로토타입을 프로덕션으로 승격시키는 경로입니다.

이 경로에는 최소한 다음 단계가 있어야 합니다.

제품 의도 검토
디자인 정합성 검토
API 및 데이터 계약 정리
mock 및 fake 데이터 제거 계획
개발 통합
하네스 검증
staging 확인
배포 및 rollback 계획

이 흐름에서 개발자의 역할은 모든 코드를 한 줄씩 검열하는 사람이 아닙니다. 개발자는 시스템 경계, 데이터 흐름, 배포 가능성, 장기 유지보수성을 책임지는 사람이어야 합니다.

리뷰는 사라지는 것이 아니라 바뀝니다#

AI 에이전트 기반 개발 흐름에서 중요한 질문은 “리뷰를 할 것인가 말 것인가"가 아닙니다. 더 중요한 질문은 “무엇을 리뷰할 것인가"입니다.

기존 방식처럼 사람이 모든 diff를 읽고 모든 구현 세부사항을 판단하는 방식은 오래 지속되기 어렵습니다. AI 에이전트가 만드는 변경량은 사람의 수동 리뷰 능력을 쉽게 넘어섭니다. 따라서 리뷰는 코드 중심에서 의도, 계약, 위험, 하네스 결과 중심으로 이동해야 합니다.

사람이 검토해야 할 것은 다음과 같습니다.

이 기능이 어떤 사용자 흐름을 바꾸는가
어떤 API가 필요하고 기존 API와 무엇이 달라지는가
어떤 데이터 상태와 DB 테이블에 영향을 주는가
인증, 권한, 과금, 리포트에 영향이 있는가
mock 데이터와 fake 데이터가 어디에 남아 있는가
실패했을 때 rollback 가능한가
테스트, 타입체크, e2e 테스트, visual regression이 무엇을 보증하는가

이런 검토는 AI 개발을 막기 위한 절차가 아닙니다. 오히려 앞으로 하네스가 대신 판단해야 할 기준을 사람이 먼저 명확히 하는 과정입니다.

하네스는 정답을 스스로 만들지 못합니다#

반대편 의견은 AI 에이전트와 하네스를 더 믿고, 일단 기획자의 변경사항을 반영한 뒤 잘못된 부분을 개선하자는 방향이었습니다. 사람이 현재 프로젝트 구조를 자세히 몰라도 되도록 테스트 케이스, 스킬, 하네스를 강화하자는 관점입니다.

이 의견에는 분명한 진실이 있습니다. 사람이 기존 방식의 리뷰와 설계 통제에 계속 매달리면 AI 에이전트를 통한 개발 퍼포먼스의 혁신은 늦어질 수 있습니다. 변화량이 커지는 시대에 사람이 모든 코드를 수동으로 이해하고 승인해야 한다는 전제는 곧 병목이 됩니다.

장기적으로는 많은 개발 판단이 하네스와 에이전트에 의해 자동화될 가능성이 높습니다. 사람은 프로젝트의 모든 세부 구현을 머릿속에 들고 있지 않아도 되는 방향으로 가야 합니다.

그러나 여기에는 중요한 전제가 있습니다. 하네스는 명시된 것만 검증합니다. 테스트는 정답을 스스로 만들지 못합니다. 무엇이 정상 동작인지, 어떤 UX가 의도인지, 어떤 데이터 상태가 깨지면 안 되는지는 누군가 먼저 정의해야 합니다.

이 정의가 약한 상태에서 “일단 반영 후 개선"으로 가면, 하네스가 강화되는 것이 아니라 잘못된 동작을 정상으로 고정하는 테스트가 생길 수 있습니다. 자동화가 아니라 책임의 공백이 생길 위험이 있습니다.

과도기의 원칙#

필자는 이 문제의 해법이 양쪽 중 하나를 단순히 선택하는 데 있지 않다고 생각합니다.

AI 에이전트를 적극적으로 쓰자는 방향은 맞습니다. 기획자가 직접 실행 가능한 초안을 만들 수 있게 된 것은 되돌릴 수 없는 변화입니다. 이 능력은 제품 개발 속도와 실험 밀도를 크게 높일 수 있습니다.

하지만 그 초안을 프로덕션 코드로 즉시 인정하는 것은 별개의 문제입니다. 기획자의 코드 변경은 실행 가능한 기획안으로 인정해야 합니다. 그리고 개발 조직은 그것을 처음부터 다시 손으로 구현하는 것이 아니라, AI 에이전트와 하네스를 이용해 프로덕션으로 승격시키는 책임을 가져야 합니다.

이 과도기에서 중요한 원칙은 다음과 같습니다.

큰 변경을 사용자 흐름, 페이지, API 단위로 쪼갭니다.
기획자의 코드 변경에는 의도, 우선순위, 예외 케이스, 성공 기준을 함께 남깁니다.
mock 데이터와 fake 데이터는 명시적으로 목록화하고 실제 API 개발 과제로 전환합니다.
개발자의 리뷰는 전체 코드 검열이 아니라 시스템 계약과 위험 지점 검토로 재정의합니다.
하네스는 타입, 테스트, API contract, visual regression, staging 검증, feature flag, rollback까지 포함해야 합니다.
사람이 리뷰하던 판단 기준을 점진적으로 테스트, 스킬, 문서, contract로 옮깁니다.

설득의 프레임#

이 논쟁을 설득하려면 “AI 개발을 받아들일 것인가 말 것인가"의 구도로 두면 안 됩니다. 그 프레임에서는 한쪽은 혁신을 막는 사람처럼 보이고, 다른 한쪽은 품질을 무시하는 사람처럼 보입니다.

더 나은 프레임은 다음과 같습니다.

AI 에이전트를 더 적극적으로 쓰자는 방향에는 동의합니다. 다만 지금 필요한 것은 속도를 늦추자는 것이 아니라, 기획자의 실행 가능한 초안을 프로덕션 품질로 승격시키는 경로를 명확히 하는 것입니다.

개발자의 리뷰는 AI가 만든 코드를 사람이 다시 예전 방식으로 검열하는 리뷰가 아닙니다. 앞으로 하네스가 대신 판단할 기준을 사람이 먼저 명확히 하는 리뷰입니다.

이렇게 정리하면 논쟁은 “리뷰를 할 것인가 말 것인가"에서 “어떤 판단을 자동화 가능한 기준으로 바꿀 것인가"로 이동할 수 있습니다.

결론#

AI 에이전트는 제품 개발 조직의 역할 구조를 근본적으로 바꾸고 있습니다. 기획자는 더 이상 문서만 작성하는 사람이 아니며, 개발자는 더 이상 기획서를 받아 구현만 하는 사람이 아닙니다. 하지만 그렇다고 해서 의도 전달과 책임 판단이 사라지는 것은 아닙니다.

오히려 지금은 의도, 계약, 위험, 정상 동작의 기준을 더 명시적으로 다루어야 하는 시기입니다. 하네스가 충분히 강해지기 전까지는 사람이 판단해야 할 영역이 남아 있습니다. 그리고 그 판단을 잘 정리해 하네스로 옮기는 과정이 바로 과도기의 핵심 작업입니다.

기획자의 코드 변경은 프로덕션 코드가 아니라 실행 가능한 초안입니다. 그 초안을 빠르게 만들 수 있게 된 것은 큰 진전입니다. 이제 필요한 것은 그 초안을 안전하게 제품으로 승격시키는 체계입니다.

AI 에이전트 시대의 제품 개발 프로세스는 단순히 더 많은 코드를 더 빨리 만드는 방향으로만 진화해서는 안 됩니다. 사람의 의도와 시스템의 품질 기준을 자동화 가능한 형태로 바꾸는 방향으로 진화해야 합니다.