AI 에이전트 시대의 팀 개발이라 하더라도 팀 개발의 근본은 변하지 않는 것 아닐까?

여러분도 비슷한 감각을 가지고 계시리라 생각합니다만, 최근에는 AI 에이전트가 코드의 상당 부분을 작성하게 되면서 실제로 코드를 작성할 기회가 상당히 줄어들었다고 느낍니다.

많은 팀이 시도하고 있으며 아직 발전 단계에 있는 '팀으로서 어떻게 개발을 진행할 것인가'라는 테마에 대해, 현시점에서의 저 개인적인 생각을 정리해 보고자 합니다.

덧붙여, 이 글을 쓰게 된 배경으로는, 주관적이긴 하지만 AI를 활용하려고 하면 할수록, 기존의 팀 개발 지식(Knowledge)이 더욱 유효해진다고 느끼고 있기 때문입니다. 변하는 것은 구현의 주체일 뿐, 팀으로서 가치를 전달하는 활동의 근본은 변하지 않는다는 감각이 있기 때문입니다.

※ 이후의 내용은 정량적인 계측에 기반한 것이 아니라, 여러 현장에서 개발을 진행해 온 과정에서의 개인적인 체감과 견해입니다. 어디까지나 한 개인의 의견으로서 가볍게 읽어주시기 바랍니다.

중심에 있는 것은 '인간과 AI의 역할 분담'이며, 이를 성립시키기 위한 토대로서 하네스 엔지니어링(Harness Engineering)이 있고, 여기에 아키텍처와 팀의 형태가 올라가며, 마지막으로 이들을 회전시키는 메커니즘으로서 팀 개발의 이벤트가 작용한다고 생각합니다. (구체적인 프레임워크가 있으면 이해하기 쉬우므로, 제가 자주 채택하는 스크럼(Scrum) 프레임워크를 베이스로 작성하겠습니다.)

AI에게 구현을 맡길 수 있는 이유는 그 출력이 신뢰할 수 있는 상태가 되어 있기 때문입니다. 그 상태를 만드는 것이 하네스 엔지니어링(Harness Engineering)입니다. 저는 이것을 AI 주도 개발(AI-Driven Development)을 위한 발판 만들기, 즉 Dockerfile이나 CI를 정비하는 것과 같은 레이어의 작업이라고 파악하고 있습니다. AI 에이전트의 실행 환경을 정비하는, 개발의 토대입니다.

구성 요소는 대략 다음의 3가지가 될 것이라고 생각합니다.

권한·가드레일 층 (Permission/Guardrail Layer) — settings.local.json의 allow/deny 등, AI에게 허용할 조작과 금지할 조작의 정의
가이던스 층 (Guidance Layer) — CLAUDE.md나 개발 규칙, AI에게 전달할 컨텍스트(Context)와 메모리(Memory)의 설계
자동화·검증 층 (Automation/Verification Layer) — CI에 포함된 AI 리뷰, 자동 PR 생성, 테스트 루프

하네스의 토대가 갖춰지면 엔지니어는 구현 작업 그 자체에서 벗어날 수 있습니다. 기본 방침으로서, 엔지니어는 코드를 쓰는 역할이 아니라 AI 에이전트의 지휘자(Flag-bearer) 역할에 철저해야 합니다. 인간이 집중해야 할 것은 판단, 문제의 발견, 그리고 AI에게 전달할 컨텍스트(Context)의 정비입니다.

여기서 중요해지는 것이 상류(Upstream)의 디자인 스킬입니다. 프로덕트 로드맵, 기술 전략, 아키텍처 설계, 스토리 디자인. 이것들은 품질이 높을수록 AI에 대한 양질의 인풋(Input)이 되며, 그대로 아웃풋(Output)의 품질로 직결됩니다. AI가 구현을 담당할수록 인간의 가치는 '무엇을, 어떤 제약 조건으로 만들 것인가'를 정의하는 쪽으로 옮겨갑니다.

실제로 업무 위탁으로 일을 맡고 있는 어느 회사에서는, 프로덕트 로드맵 정리와 스토리 작성법을 PO(Product Owner) 역할을 담당하는 분에게 코칭하여 인풋(Input)의 품질을 높였습니다. 그 결과 제가 실제로 개발을 진행할 때는 그 스토리를 그대로 집어넣어 구현하고, 그 아웃풋(Output)을 리뷰하는 흐름이 만들어졌기에, 더욱이 이러한 컨텍스트(Context) 정비가 중요하다고 생각하고 있습니다.

AI가 읽게 하기 위해 최근에는 모노레포(Monorepo)로 회귀하는 움직임도 강해지고 있습니다만, 모노레포이든 마이크로서비스(Microservices)이든, 그 방침을 결정하는 변수 중 하나는 조직 규모라고 생각합니다.

엔지니어가 몇 명뿐인 조직이라면 마이크로서비스화는 오히려 비용 증가가 되는 경우가 많을지도 모른다고 느낍니다.

분산 트랜잭션이나 운영의 복잡성은 AI가 대신해 주지 못하는 영역이 크기 때문에, 솔직히 모노레포를 선택하는 편이 결과적으로 속도가 빠르다고 느낍니다. 반면, 수백 명에서 수천 명 규모가 되면 서비스별 배포 독립성이나 디렉토리 권한 관리와 같은 기존의 요구사항이 작용하여 마이크로서비스화의 장점이 앞서게 됩니다. 물론 너무 많이 분할하면 관리 비용이 급증하므로, 이 부분은 엔지니어의 균형 감각이 요구된다고 느낍니다.

그리고 여기에 AI 주도 개발이 더해짐으로써, AI가 컨텍스트(Context)로서 읽는 범위라는 변수가 늘어났다고 생각합니다. 읽는 범위를 좁히는 편이 정확도와 속도도 내기 쉽습니다. 이는 컨텍스트 엔지니어링(Context Engineering, 규칙으로 읽기 범위를 좁히는 것)으로도, 물리적인 분할(마이크로서비스화)로도 실현할 수 있다는 점은 이해하고 있습니다.

다만, AI 주도 개발은 프로젝트 배경이나 프로덕트 전체상에 대한 인풋(Input)이 있어야 기능합니다. 거기서 유효한 것이, 물리적인 분할과 논리적인 읽기 범위를 분리하여 설계하는 것입니다.

서비스를 분할하면서도 전체를 이해시키고 싶을 때는 상위 디렉토리에 각 리포지토리(Repository)를 배치하여 그곳을 기점으로 읽게 합니다.

전체상을 이해시키는 수단으로는, 코드를 일일이 다 읽게 하기보다 이미 전체 구성을 표현하고 있는 결과물을 입구로 삼는 것이 더 빠르다고 생각합니다. docker-compose나 Dockerfile, k8s의 매니페스트(Manifest) 등은 오케스트레이션(Orchestration)의 정의 그 자체이므로, 아키텍처 전체를 빠르게 파악할 수 있습니다.

이 부분은 정량적으로 비교한 것은 아니며 체감 기반이지만, docker-compose / Dockerfile / k8s의 YAML을 읽게 하면 AI의 이해 정밀도가 올라간다고 느끼고 있습니다. 이러한 파일들은 운용을 위해 반드시 유지보수되므로, README나 아키텍처 도표와 달리 진부해지기 어렵다는 부차적인 이점도 있습니다.

팀 규모는 너무 크지도 작지도 않게 유지합니다. 인간 사이의 커뮤니케이션 패스(Communication Path)는 인원수에 대해 $n(n-1)/2$로 증가하기 때문에, 인원이 많아질수록 커뮤니케이션 비용이 부풀어 올라 속도가 떨어집니다. 스크럼 가이드(Scrum Guide)가 제시하는 것처럼, 엔지니어뿐만 아니라 프로젝트 추진에 필요한 각 직능을 포함하여 10명 이하를 하나의 기준으로 삼고 있습니다.

여기서 AI 에이전트(Agent)를 멤버로 포함할 것인가 하는 점도 검토해야 하겠지만, 저는 포함하지 않고 있습니다.

인간과 에이전트의 관계는 기본적으로 1대 1의 지시와 응답이며, 에이전트끼리 멋대로 주고받는 일은 없기 때문입니다. 즉, "인간은 10명 이하로 유지하면서, 각자가 여러 명의 에이전트를 거느리는" 구조라면, 커뮤니케이션 비용의 폭발을 피하면서 팀의 실효적인 생산 능력을 높일 수 있다고 생각합니다.

다만 AI 주도 개발(AI-Driven Development)에서의 팀 매니지먼트(Team Management) 시 주의해야 할 요소 중 하나는, 각자가 제각각의 도구를 사용하게 되는 상황이 발생하지 않도록 하고 싶다는 점입니다.

"A 씨는 Gemini CLI의 Flash 모델로 코드만 AI에게 맡긴다. B 씨는 Codex를 사용하여 설계나 작업 기록까지 md 파일로 쓰게 한다"와 같이, 사용법은 내버려 두면 각자의 로컬 환경에서 흩어지게 됩니다. 이를 방치하면 팀으로서의 일관성이 상실되므로, AI 사용법의 큰 틀은 맞춰두고 싶습니다. 다만, 너무 엄격하게 규정하면 엔지니어가 역량을 발휘하기 어려워지므로, 지나치게 구속하지 않는 균형이 필요하다고 생각합니다. 이 "큰 틀은 맞추되, 너무 구속하지 않는" 것을 실현하는 메커니즘이, 예를 들어 스크럼 이벤트(Scrum Event)와 같은 애자일(Agile)적인 사고방식에 있다고 생각합니다.

AI가 멤버처럼 가세하더라도, 팀 개발을 운영하는 이벤트 그룹은 불필요해지기는커녕 오히려 중요성이 높아지고 있다고 실제 팀 개발을 진행하며 느끼고 있습니다.

왜냐하면, AI의 불확실성을 다루고, 사용법의 큰 틀을 맞추며, 지속적으로 개선하기 위한 장(場)으로서 기능하기 때문입니다. 각 이벤트는 AI 주도 개발에서 다음과 같이 파악할 수 있다고 생각합니다.

Refinement— 기존의 "스토리를 이해 가능한 입도로 분해하는 장"에 더해, AI에게 읽힐 컨텍스트(Context)를 정비하는 장이 됩니다. 스토리, 수락 조건(Acceptance Criteria), 참조해야 할 설계 정보의 품질이 그대로 AI의 출력 품질로 이어집니다.

Sprint Planning— 인간과 AI 에이전트의 작업 분담을 계획하는 장. 어디를 사람이 판단하고, 어디를 AI에게 맡길 것인가.

Daily— 해야 할 일 자체는 크게 변하지 않지만, 여기서 나온 정보가 AI에 대한 피드백의 기점이 됩니다. "A 화면의 API 호출이 너무 많아서 특정 티켓의 블로커(Blocker)가 되고 있다"는 것을 알게 되면, 그 조사나 수정을 AI에게 던집니다. 즉, 인간이 문제를 발견하고 AI에게 해결을 위임하는 형태로 변모하고 있다고 생각합니다.

Retrospective— 회고의 대상에 팀 활동과 더불어 AI 사용법이나 하네스(Harness) 자체의 개선이 추가됩니다. 토대는 한 번 만들고 끝나는 것이 아니라, 여기서 지속적으로 개선해 나갑니다.

이벤트의 형태는 변하지 않습니다. 변하는 것은 그 안에서 인간과 AI가 어떻게 역할을 나누느냐입니다.

변한 것은 구현의 담당자와 코드를 쓰는 속도입니다. 변하지 않는 것은 팀으로서 가치를 전달하기 위해 무엇을 만들지 정의하고, 계획하고, 회고하며 개선하는 활동의 근본입니다. AI라는 강력한 도구가 들어왔기에, 그 도구를 팀으로서 안정적으로 다루기 위해 기존의 팀 개발 지견이 효과를 발휘합니다. 이것이 현시점에서의 개인적인 결론입니다.