
「사람을 늘리는 것 = 분업」은 이제 옛말? AI 에이전트를 전제로 한 개발 팀을 5개월간 운영하며 느낀 점
요약
AI 에이전트를 활용한 6인 규모의 개발 팀 운영 경험을 바탕으로, AI 시대의 분업 구조 변화를 분석합니다. 단순 작업 분담보다는 AI의 결과물을 평가하고 가이드라인을 준수할 수 있는 숙련된 인력의 중요성을 강조합니다.
핵심 포인트
- AI 에이전트 도입 시에도 성과는 도구가 아닌 사용자의 역량에 따라 결정됨
- 전통적인 '인력 충원 = 분업 확대'라는 공식이 AI 시대에는 유효하지 않음
- AI가 구현을 담당함에 따라 설계와 결과물을 검토할 수 있는 리뷰어 역량이 필수적임
- 기초 지식과 표준(Standard)에 대한 이해가 AI 활용 능력의 핵심 차이를 만듦
서론
「태스크를 할당하는 개발은 끝났다」라는 기사를 읽고, 깊이 공감하는 부분이 많았습니다.
그 기사의 테마는 「AI 에이전트 시대에, 사람을 늘리는 것(=분업)의 의미는 어떻게 변하는가」입니다.
그 기사가 「업계 전체의 구조가 어떻게 변하는가」라는 매크로(Macro)한 관점에서 쓰인 것에 반해, 본 기사는 최근 SES 프로젝트의 6명 즉석 팀 현장에서 실제로 어떤 일이 일어났는가라는 마이크로(Micro)한 관점에서 느낀 내용입니다.
마침 저 자신도 지난 5개월간 바로 그 테마의 당사자였습니다. 본 기사는 그 실체험을 바탕으로 한 현장에서의 고찰입니다. 앞으로의 팀 형태를 생각하기 위한 '초안'으로서 읽어주시면 감사하겠습니다.
내가 처해 있던 환경
먼저 전제가 되는 상황을 공유하겠습니다.
프로젝트: 0→1, 즉 풀 스크래치(Full-scratch) 시스템 구축 -
체제: 자사 직원 없는 즉석 SES 6명 (나 포함) -
멤버 구성: 외국인 국적의 구성원도 재직 중이며, 커뮤니케이션에 약간의 어려움이 있었음 -
배포 도구: Claude (Team 플랜) 및 GitHub Copilot
이 「즉석 팀 × 풀 스크래치 × AI 에이전트 배포」라는 조건이 이번 고찰의 토대가 됩니다.
내가 먼저 정비한 것
셋업에 있어 저는 다음과 같은 것들을 준비했습니다.
- 가이드라인·규칙
- 기반 (아키텍처의 토대) 구축
- 설계 템플릿
그 후에, 설계·구현·UT (단위 테스트)·IT (통합 테스트)의 각 페이즈를 각 멤버가 각자 AI 에이전트를 활용하며 진행하는 방식을 채택했습니다.
일어난 일: 같은 도구라도 사람에 따라 결과가 갈린다
같은 가이드라인, 같은 AI 도구를 배포해도 결과물은 눈에 띄게 차이가 났습니다.
| 관점 | 한 사람 | 다른 사람 |
|---|---|---|
| Issue 소화 | 많이 소화함 | 적음 |
| ... |
중요한 점은, 차이를 만든 것은 AI 도구의 성능이 아니라 사용하는 사람 쪽이었다는 점입니다.
같은 에이전트를 전달받아도 구현 실수나 설계 실수를 그냥 지나치는 사람이 있는가 하면, 다른 담당 영역의 실수도 찾아내는 사람이 있습니다. 가이드라인을 무시하는 사람이 있는가 하면, 일부러 지적하여 품질을 끌어올리는 사람이 있습니다.
원문 기사에서는 Spotify의 사례 등을 통해 「에이전트가 구현을 돌리는」 큰 흐름이 소개되었습니다.
다만 그것을 현장의 해상도로 보면, 같은 도구를 배포해도 성과는 사람에 따라 크게 갈린다는, 수치만으로는 보이지 않는 변수가 남습니다.
「할당하는 공정이 사라지는 것」은 사실이라 할지라도, 사라진 자리에서 가치를 낼 수 있을지는 여전히 사람에게 강하게 의존하고 있었습니다.
결론: 「사람을 늘리는 것 = 분업」이라는 편리함이 흔들리고 있다
여기서 제가 얻은 결론은 심플합니다.
「사람을 늘리면 그만큼 작업을 분담할 수 있다」라는 근본적인 편리함이 변하고 있습니다.
기존에 사람을 늘리는 것의 가치 중심은 「분업」이었습니다.
【태스크를 잘라내어 다른 사람에게 넘기면 그만큼 병렬로 진행된다】라는 전제입니다.
하지만 AI 에이전트가 구현층을 담당할 수 있게 되면 이야기가 달라집니다. 「작업을 돌리는 것」만이라면 에이전트라도 돌릴 수 있기 때문입니다. 그렇게 되면 사람을 늘리는 것 자체의 가치는 단순한 분업량으로는 측정할 수 없게 됩니다.
그렇다면 앞으로 요구되는 사람이란
제가 현장에서 「효과가 있었다」고 느낀 것은 다음과 같은 자질을 가진 사람이었습니다.
- Web 영역의 최신 동향이나 실천적 지식을 가지고 있다
- 기초 지식이 탄탄하다
- 경험이 있고, 스탠다드(Standard, 정석)를 이해하고 있다
- 그리고 그것들을 사용하려는 자세를 가지고 있다
이러한 것들을 겸비한 사람이야말로 사실상 리뷰를 담당할 수 있는 사람이라고 생각합니다. AI가 내놓은 설계·구현을 평가하고, 가이드라인에 비추어 보며, 타인의 영역의 실수까지 찾아낼 수 있습니다. 이 역할이야말로 희소해질 것이라고 느껴졌습니다.
반면, 지식이 적고 경험이 부족한 사람의 공헌은 앞으로 보이지 않게 될지도 모릅니다. AI가 뒷받침하는 영역과 겹치기 때문입니다.
이는 냉정한 이야기지만, 현장에서 느낀 현실입니다. 원문 기사에서도 「주니어 층의 수요가 줄어드는 반면 시니어 층은 황금기를 맞이한다」는 비대칭성이 지적되었는데, 제 현장의 체감도 이와 일치했습니다.
평가·리뷰할 수 있는 쪽에 설 수 있느냐에 따라 가치의 발현 방식이 명확하게 갈리게 됩니다.
중요도가 높아지는 영역
이번 경험을 통해 앞으로 비중이 늘어날 것이라고 느낀 영역을 정리합니다.
1. 파이프라인·워크플로우 (Pipeline/Workflow) 구축
각자가 에이전트를 '돌려 쓰는' 단계를 넘어, 누가 해도 일정 품질이 유지되는 파이프라인/워크플로우를 어떻게 설계할 것인가. 이 점이 앞으로 더욱 중요해질 것이라고 느꼈습니다. 가이드라인이나 템플릿은 그 첫걸음에 불과합니다.
원문에서는 이를 '루프 엔지니어링 (Loop Engineering)' — 개별 프롬프트를 매번 입력하는 것이 아니라, 에이전트가 목적에 따라 계속해서 실행되는 메커니즘 자체를 설계하는 것 — 이라고 표현했습니다.
사람의 개입 방식 또한 모든 공정에 달라붙는 형태에서, 요점만을 감독하는 human-on-the-loop적인 형태로 무게 중심이 이동한다고 정리되어 있었습니다.
최근 프로젝트에서도 개발 멤버에게 프로그래밍 작업 자체를 담당시키지 않고, 리뷰에 철저히 집중한다는 전제로 워크플로우를 구성했습니다. 커버리지(Coverage)를 모두 통과하여 90% 이상으로 만드는 것뿐만 아니라, "그 UT(Unit Test)가 정말 의미 있는 테스트인가", "커버리지를 채우기 위한 위한 이상한 테스트가 아닌가"를 꿰뚫어 보는 관점을 공유하며, 요점만을 사람이 감독하는 형태로 맞추었습니다.
제 현장에서 "가이드라인과 템플릿을 정비했다"는 것은, 바로 이 루프의 토대를 만드는 입구였음을 나중에 깨달았습니다.
덧붙이자면, 에이전트는 작업 시간이 길어질수록 실패하기 쉬운 경향이 있습니다 (원문에서는 인간이 수행해도 35분을 초과하는 긴 태스크가 되면 성공률이 급격히 떨어진다는 관측을 "35분 문제"로 소개했습니다).
그렇기에 태스크를 적절한 입도(Granularity)로 나누고, 검증 포인트를 삽입하는 — 이러한 설계 자체가 사람이 담당하는 가치가 되어갑니다.
2. 프로그래밍 계층은 「맡기는」 방향으로
수년 전부터 OpenAI나 Claude Code를 이용하고 있지만, AI의 지능 수준은 시간이 흐를수록 높아지고 있습니다.
프로그래밍 작업 자체는 이제 에이전트에게 맡길 수 있는 수준이 되었습니다.
3. 사람이 담당하는 비중이 높아지는 영역
그만큼 인간 측의 무게 중심은 상류(Upstream) 및 횡단(Cross-cutting) 영역으로 이동합니다.
비즈니스(업무)의 이해
시스템이 「동작해야 할 사양(Specification)」의 이해
부하·튜닝 (Tuning)
리팩터링 (Refactoring)의 중요도 판단
"올바르게 동작하는 코드를 쓰는 것"보다 "무엇이 옳은지를 정의하고 평가하는" 쪽의 가치가 높아지고 있다는 감각입니다.
그 너머에 있는 질문: 사람에게 태스크를 부여하는 행위조차 사라질 것인가
마지막으로 조금 미래의 이야기를 하겠습니다.
에이전트의 수준은 앞으로도 계속 높아질 것이라고 생각합니다. 나아가, 프로젝트에 맞춰 지식을 재구축할 수 있는 메커니즘 — 이른바 "프로젝트 전용으로 성장하는 에이전트"가 일반화되었을 때, 어떤 일이 벌어질까요.
실제로 현재 저는 Hermes Agent를 로컬 환경에서 구동하며 Slack 연동을 포함해 검증하고 있습니다. 프로젝트에 맞춰 동작을 최적화할 수 있다고 합니다.
앞으로는 이러한 애플리케이션이나 유사한 방향성의 툴이 늘어날 가능성도 충분히 고려할 수 있습니다.
그렇게 되면, 「사람에게 태스크를 부여한다」는 행위 자체가 사라지는 시대가 올지도 모릅니다. 분업의 단위가 「사람」에서 「에이전트」로 옮겨가면 매니지먼트의 대상도 바뀝니다.
물론 이것은 극단적인 시나리오입니다. 다만, 5개월간의 현장을 거치며 그 방향으로 조금씩 바늘이 움직이고 있는 것은 확실하다고 느꼈습니다.
마치며
정리하자면, 제가 현장에서 얻은 배움은 다음과 같습니다.
- 같은 AI 툴을 배포해도 결과는 사람에 따라 갈린다. 차이를 만드는 것은 사용자의 지식·경험·태도 — 「사람을 늘린다 = 분업」이라는 기존의 편리함은 흔들리고 있다.
- 앞으로 희소한 것은 AI의 결과물을 평가·리뷰할 수 있는 사람 — 중요도가 높아지는 것은 파이프라인 구축·업무 이해·사양 정의·비기능(부하/튜닝/리팩터링) — 그 너머에는 태스크의 대상이 사람에서 에이전트로 옮겨가는 미래가 있을지도 모른다.
「사람을 늘릴 것인가」가 아니라 「어떤 메커니즘과 어떤 역할을 하는 사람을 배치할 것인가」. 즉석 팀으로서의 5개월은 그 질문을 던져주는 시간이었습니다. 비슷한 현장에 계신 분들에게 생각의 계기가 되기를 바랍니다.
Discussion

AI 자동 생성 콘텐츠
본 콘텐츠는 Zenn AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기