로봇은 준비됐다. 그런데 요구사항은 누가 제공할까?

에이전트 기반 코딩이 도메인 지식과 의사결정의 공급, 엔지니어링 역할, 제품 개발 조직까지 바꿀 수 있는 이유입니다.

설비는 현대화했지만 자재가 없는 공장

여러 해 동안 일정한 생산 속도에 맞춰 운영해 온 공장을 떠올려 봅니다. 직원들이 만들 수 있는 제품 수는 기계, 작업 절차, 가용 근무 시간에 의해 정해져 있었습니다. 자재 공급과 생산 계획, 품질 관리도 그 처리량에 맞춰 자리 잡았습니다. 아주 빠른 시스템은 아니었을지 몰라도 각 부분은 어느 정도 서로 맞물려 돌아갔습니다.

그러다 회사가 새로운 로봇에 투자합니다. 갑자기 여러 공정을 동시에 진행할 수 있고, 반복 작업은 자동화되며, 실제 생산에 필요한 사람의 개입도 크게 줄어듭니다. 예상대로 첫 논의는 새 기계의 생산성에 집중됩니다. 그리고 얼마 지나지 않아 앞으로 직원이 몇 명이나 필요할지 이야기하기 시작합니다.

그런데 자재 공급은 아무도 조정하지 않았습니다.

새 생산 라인의 생산 능력은 훨씬 커졌지만, 쓸 수 있는 자재가 그만큼 더 들어오지는 않습니다. 설비의 성능은 인상적입니다. 그렇다고 공장이 하나의 생산 시스템으로서 저절로 더 높은 생산성을 내는 것은 아닙니다.

최근 코딩 에이전트에 관한 논의를 접할 때마다 저는 이 장면을 떠올립니다. 코드를 얼마나 빨리 생성할 수 있는지, 얼마나 많은 작업을 병렬로 실행할 수 있는지, 예전에는 개발팀 전체가 매달리던 일을 무엇까지 해낼 수 있는지 많이 이야기합니다. 반면 그다음 질문은 훨씬 드물게 들립니다. 조직은 새로 생긴 구현 능력이 올바른 문제를 다루도록 어떻게 보장할까요?

물론 소프트웨어는 조립 라인에서 나오는 제품이 아닙니다. 요구사항도 앞에서 집어넣으면 뒤에서 완성된 기능으로 나오는, 서로 교환 가능한 원자재가 아닙니다. 특히 복잡한 제품에서는 문제에 대한 이해와 해결책이 함께 발전하는 경우가 많습니다. 그래도 이 비유는 새로운 병목의 가능성을 드러내는 데 도움이 됩니다. 생산은 자동화하면서도 도메인 지식과 의사결정을 공급하는 일은 그에 대한 요구가 전혀 달라지지 않은 것처럼 취급하고 있는 것은 아닐까요?

구현 능력이 커진다고 처리량도 저절로 늘지는 않습니다. 공장은 비유이며, 요구사항과 해결책은 피드백을 통해 함께 발전합니다.

원본 크기로 그래픽 보기

작업 흐름 세 개가 새로운 도메인 세 개는 아닙니다

개인 개발 작업에서는 여러 코딩 에이전트를 어떻게 합리적으로 병렬 활용할 수 있을지 의식적으로 실험하고 있습니다. 예를 들어 서로 다른 작업 흐름 세 개를 진행합니다. 한 기능은 마무리 단계에 있고, 두 번째 기능은 도메인과 시각적 콘셉트를 다듬으며 첫 구현을 시작합니다. 또 다른 영역에서는 새로운 테마를 정의하고 여러 변형을 비교합니다.

이 방식이 가능한 이유는 각 작업이 제 주의력을 요구하는 방식이 매우 다르기 때문입니다. 기능의 핵심 결정이 이미 내려졌다면 에이전트는 비교적 독립적으로 구현하거나 수정할 수 있습니다. 그동안 저는 UX 아이디어를 생각하거나, 설계안을 검토하거나, 다음 도메인 결정을 준비할 수 있습니다. 낯선 도메인 세 개를 동시에 이해하려는 것이 아닙니다. 제한된 제 주의력을 잘 배분해 에이전트가 저를 기다리는 시간을 줄이려는 것입니다.

저는 이런 병렬 작업이 무척 좋습니다. 하지만 인지 능력이 마법처럼 늘어나는 것은 아닙니다. 에이전트 세 개는 동시에 코드를 수정할 수 있습니다. 저는 복잡한 결정 세 개를 같은 깊이로 동시에 생각하고, 결과 세 개를 모두 신뢰할 수 있게 검수할 수 없습니다. 그래서 작업 흐름의 수보다 어떤 작업 흐름을 고르느냐가 거의 더 중요합니다.

직장에서는 가끔 정반대의 상황을 경험합니다. 유지보수와 추가 개발이 필요한 제품은 여러 개인데, 도메인 관점에서 충분히 명확해지고 우선순위까지 정해진 요구사항이 들어오지 않습니다. 그때는 아키텍처를 개선하거나 기술 부채를 줄이거나 기존 구조를 정리할 수 있습니다. 의미 있는 일이고 저도 즐겁게 합니다. 다만 그것만으로 제품의 도메인 로드맵이 생기지는 않습니다.

이런 상황에서는 가끔 이런 말을 듣습니다. “도메인만 제대로 이해하면 되잖아요. 그러면 요구사항도 직접 정의할 수 있죠.”

저에게는 바로 여기서 핵심적인 사고의 오류가 시작됩니다. 개발자가 도메인을 이해하지 말아야 해서가 아닙니다. 도메인 문제를 이해하는 일, 해결책을 함께 만드는 일, 어떤 업무 규칙을 적용할지 구속력 있는 결정을 내리는 일을 자주 하나로 묶기 때문입니다. 이 일들은 연결되어 있습니다. 하지만 전제 조건과 전문성, 책임까지 자동으로 같아지는 것은 아닙니다.

지리정보 전문가가 아니어도 가능했던 여덟 날의 개발

최근 프로젝트에서 이런 전제가 갖춰지면 무엇이 가능한지 경험했습니다. 기존 애플리케이션에 복잡한 지리정보 기능을 구현해야 했습니다. 도형, 벡터, 지리적 경계, 계산, 그리고 이를 지도에 표현하는 일이었습니다. 단순히 CRUD 화면 하나를 추가하는 작업이 아니었습니다. 제가 익숙하지 않은 도메인 지식과 수학적 관계를 다뤄야 했습니다.

지리정보학은 독립된 전문 분야입니다. 독일 경제연구소가 2025년에 발표한 연구에 따르면, 2023년 독일에서 좁게 분류된 직업군인 “지리정보학 — 전문가(석사/Diplom)”에 속하는 사회보험 가입 피고용자는 정확히 1,694명이었습니다. 그렇다고 독일에서 이런 소프트웨어를 구현할 수 있는 사람이 1,694명뿐이라는 뜻은 아닙니다. 이 수치는 통계상 직업 분류를 설명하며, 역량을 갖춘 개발자의 수를 세는 것이 아닙니다. 다만 이 작업에 필요한 도메인 전문성을 당연하게 여길 수 없었던 이유는 보여 줍니다.

저는 소프트웨어 아키텍트이지 지리정보 전문가는 아닙니다. 솔직히 시작할 때는 의도한 방식으로 문제를 풀 수 있을지 상당히 의심했습니다.

다행히 우리에게는 드물게 잘 작성된 상세 요구사항 명세서가 있었습니다. 도메인에서 기대하는 바가 매우 정확하게 기술되어 있어서, 먼저 지리적 규칙을 만들어 내거나 모호한 예시로 원하는 결과를 추측할 필요가 없었습니다. 대신 기존 구현과 요구사항을 체계적으로 비교하고, 부족한 부분을 찾고, 관련 데이터 모델과 계산 모델을 이해한 뒤 실행 가능한 계획을 세울 수 있었습니다.

실제 결과는 저도 놀라웠습니다. 계획 이틀, 에이전트 기반 구현 이틀, 리뷰 이틀, 최종 검수 이틀이었습니다. 총 여덟 근무일로 이루어진 이 과정에서 최종 검수에서 발견된 것은 사소한 렌더링 오류 하나뿐이었습니다.

규모를 조금 설명하자면, 최종적으로 도메인 구현 코드가 5,000줄에 조금 못 미쳤고 테스트 코드는 약 10,000줄이었습니다. 특히 인상적이었던 것은 도메인 요구에 근거해 만든 약 800개의 테스트였습니다. 기술된 요구사항과 관련 시나리오 다수를 이 테스트로 확인할 수 있었습니다. 모두 개인 경험에서 얻은 수치를 반올림해 표현한 것이며, 정밀한 과학적 측정값은 아닙니다.

코드의 양 자체는 품질 척도가 아니며, 테스트가 많다고 도메인 관점의 정확성이 보장되는 것도 아닙니다. 다만 이 규모는 기술 구현의 작업량이 상당했다는 점을 보여 줍니다. 정밀한 명세서가 있었기에 복잡한 문제를 체계적으로 모델링하고, 에이전트로 구현하고, 도메인 요구에 근거한 수많은 테스트로 확인할 수 있었습니다. 도메인 전문가의 최종 검수는 여전히 필수였습니다.

이 경험을 생산성 벤치마크로 만들 생각은 전혀 없습니다. 명세서를 작성한 노력은 이 여덟 날에 포함되지 않았습니다. 요구사항과 현 상태를 비교할 수 있는 애플리케이션도 이미 존재했습니다. 같은 작업을 코딩 에이전트 없이 했다면 얼마나 걸렸을지 통제된 비교 실험을 한 것도 아닙니다.

그래도 시간의 분포는 흥미롭습니다. 여덟 날 중 에이전트 기반 구현은 이틀뿐이었고, 나머지 엿새는 계획과 리뷰, 최종 검수에 들었습니다. 도메인 명세서는 앞서 투입된 작업의 결과물이었습니다. 실제 엔지니어링은 그것을 안정적인 해결책으로 옮기는 일이었지, 지리정보학이라는 학문을 틈틈이 새로 배우는 일이 아니었습니다.

이 경험은 좋은 분업이 얼마나 효과적일 수 있는지 보여 주는 강한 개인적 근거가 되었습니다. 필요한 도메인 지식이 이해 가능한 규칙과 제약 조건, 검증 가능한 기대로 제공된다면, 경험 있는 엔지니어가 모든 학문을 통달할 필요는 없습니다. 다만 명세서가 어디까지 설명하는지, 아직 어떤 기술적 질문이 남아 있는지, 언제 다시 진짜 도메인 전문가가 결정해야 하는지는 알아야 합니다.

관찰한 시간 분포는 2 + 2 + 2 + 2 근무일입니다. 명세서 작성 노력은 제외되며, 단일 실무 경험이지 벤치마크가 아닙니다. 경험에서 얻은 대략적인 규모는 5,000줄에 조금 못 미치는 도메인 구현 코드, 약 10,000줄의 테스트 코드, 도메인 요구에 근거한 약 800개의 테스트입니다. 최종 검수에서는 사소한 렌더링 오류 하나를 발견했습니다. 코드량과 테스트 수가 도메인 관점의 정확성을 보장하지는 않습니다.

원본 크기로 그래픽 보기

“그냥 이것만 하면 되잖아요…”

이 말에는 이제 저에게 거의 더 중요해진 두 번째 문제가 들어 있습니다. 조직이 처음부터 모든 개발자에게 모든 분야를 통달하라고 요구하는 경우는 드뭅니다. 기대는 대개 합리적으로 들리는 작은 요구를 통해 조금씩 커집니다.

도메인을 조금만 더 이해하면 됩니다. 파이프라인만 고치면 됩니다. 배포도 잠깐 챙기면 됩니다. 물론 보안도 처음부터 고려해야 합니다. UX도 함께 설계할 수 있겠지요. 이왕 하는 김에 Kubernetes도 좀 보면 좋겠습니다.

요청 하나하나는 타당할 수 있습니다. 하지만 전부 합치면 한 사람이 완전히 충족하기는 어려운 역량 목록이 됩니다. 소프트웨어 엔지니어링 자체도 수많은 독립된 지식 분야로 이루어져 있습니다. 프론트엔드, 백엔드, 분산 시스템, 데이터베이스, 플랫폼 엔지니어링, 클라우드 인프라, 보안, 관측 가능성, 테스트 자동화, 소프트웨어 아키텍처를 모두 전문가 수준으로 무한히 더할 수는 없습니다. 엔지니어링을 이제 어느 정도 이해했다고 생각할 때마다 Kubernetes 같은 것이 나타나 아직 배울 것이 남았다고 알려 줍니다.

그런데 이제는 모든 개발자가 도메인 전문가까지 되어야 할까요?

업무 프로세스에 열정을 가진 사람들을 알고 있습니다. 사용자와 함께 일하기를 좋아하고 업무 규칙을 이해하고 싶어 하며, 제품과 맞닿는 지점에서 가장 큰 강점을 발휘합니다. 이런 사람들은 적극적으로 지원해야 합니다. 반면 소프트웨어 엔지니어링 자체에 더 큰 흥미를 느끼는 사람들도 있습니다. 복잡한 기술 문제를 풀고, 시스템을 설계하고, 알고리즘을 이해하고, 명료한 추상화를 만들고 싶어 합니다. 이들도 그 방향으로 성장할 수 있어야 합니다.

두 가지를 모두 좋아하는 사람들에게는 특히 조심스러워집니다. 그 조합이 잘못되어서가 아닙니다. 팀에 대단히 소중한 역량일 수 있습니다. 하지만 바로 그런 사람들이 호기심 때문에, 할 수 있기 때문에, 돕고 싶기 때문에, 처음에는 잘 돌아가기 때문에 점점 더 많은 일을 떠맡기 쉽습니다. 조직은 다음에 답이 없는 질문이 생겨도 같은 사람을 찾으면 된다는 것을 금세 배웁니다.

어느 순간 모든 결정이 그 사람을 거쳐야 합니다. 남다른 헌신이 단일 장애 지점이 된 것입니다. 모두가 불균형을 알아차리기 훨씬 전에 열정은 과부하로 변할 수 있습니다.

어쩌면 제 안의 아버지 같은 마음이 조금 드러나는 것 같습니다. 새로운 것을 배우고 자신의 경계를 넘어 성장하는 즐거움을 빼앗고 싶지는 않습니다. 하지만 배우려는 의지는 무한한 자원이 아니며, 두 분야에 열정을 가졌다는 것이 두 분야의 모든 책임을 영구히 떠맡겠다는 동의는 아닙니다.

그래서 저에게 교차 기능적이라는 말은 팀이 함께 필요한 역량을 갖춘다는 뜻입니다. 모든 개인이 모든 일을 할 줄 알아야 한다는 뜻이 아닙니다. Scrum Guide가 설명하는 교차 기능 팀의 기본 생각도 같습니다. 자기관리가 서로 다른 책무를 없애 주지는 않습니다. 한 사람이 지속해서 감당할 수 있는 한계는 더더욱 없애 주지 않습니다.

명세서는 협업을 대신하지 않습니다

GIS 사례만 보면 제가 업무 부서와 IT 사이의 전통적인 인수인계로 돌아가고 싶어 한다고 생각할 수도 있습니다. 현업에서 완벽한 명세서를 쓰고, 요구사항이 개발팀 안으로 사라졌다가 몇 달 뒤 결과로 돌아오는 방식 말입니다.

그렇다면 오해입니다. 좋은 명세서는 반드시 길어야 하지도 않고, 첫 구현 전에 최종 확정되어야 하지도 않습니다. 복잡한 요구사항일수록 함께 만드는 모델과 질문, 프로토타입, 초기 결과를 통해서야 제대로 이해되는 경우가 많습니다. 지리정보 사례에서도 먼저 현 상태를 대조하고 부족한 부분을 찾아야 했습니다. 가능했던 이유는 믿을 만한 기준점이 있었기 때문이지, 상상할 수 있는 모든 질문에 영원히 유효한 답이 준비되어 있었기 때문이 아닙니다.

요구공학은 바로 이런 학제 간 협업을 다룹니다. ISO/IEC/IEEE 29148:2018은 시스템 생명주기 전반에서 요구사항을 도출하고, 분석하고, 검증하고, 타당성을 확인하고, 소통하고, 관리하는 일을 다룹니다. 이 표준은 요구사항이 잘 작성되어 있는지와 이해관계자가 의도한 시스템을 실제로 기술하는지를 구분합니다. 이후 구현된 시스템이 명시된 요구사항을 만족하는지 확인하는 기술적 검증은 또 별개의 문제입니다.

그렇다고 관료적 절차를 더 늘리자는 주장은 아닙니다. 오히려 구현이 빨라질수록 짧고 정확하며 검증 가능한 결정의 가치가 커집니다. 명확한 규칙 하나, 좋은 예시 데이터, 이해 가능한 검수 기준, 연락 가능한 도메인 담당자가 미해결 표현으로 가득한 두꺼운 문서보다 훨씬 유용할 수 있습니다.

개발자는 도메인의 관계를 이해하고, 모순을 발견하며, 해결책을 찾는 데 적극적으로 참여해야 합니다. 하지만 도메인 결정의 정당한 권한은 그 결정을 전문적으로 내릴 수 있고 구속력 있게 확정할 권한도 있는 사람과 역할에 남아 있어야 합니다. 개발자가 기반 데이터 모델을 이해한다고 의학적 전문 판단이 생기는 것은 아닙니다. 통과한 테스트도 잘못 지정된 업무 규칙을 옳게 바꿔 주지는 않습니다.

따라서 협업은 더 긴밀해져야 합니다. 서로를 더 엄격하게 분리하자는 뜻이 아닙니다. 제가 비판하는 것은 다른 현상입니다. 조직에 도메인 책임을 맡을 역할이 없으면 그 책임이 지금 기능을 기술적으로 구현할 수 있는 사람에게 조용히 넘어가는 일입니다.

코딩 에이전트는 공급 과정에서 무엇을 바꾸는가

오래된 이 질문이 왜 하필 지금 더 절실해질까요? 기술 구현은 빨라질 수 있지만, 도메인 문제를 명확히 하는 일도 자동으로 같은 비율로 빨라지는 것은 아니기 때문입니다.

에이전트는 설명만으로 그럴듯한 데이터 모델, 사용자 인터페이스, 서비스, 테스트, 여러 파일에 걸친 완전한 변경을 만들어 낼 수 있습니다. 인상적이며 많은 경우 매우 유용합니다. 하지만 책임 있는 사람의 확인을 한 번도 받지 않은 도메인 가정을 덧붙일 수도 있습니다. 기술적으로 일관된다는 것이 도메인 관점에서 승인되었다는 뜻은 아닙니다.

연구에서도 이 구분에 관한 초기 단서가 나오고 있습니다. Fang과 동료들이 2026년에 공개한 프리프린트 ClarifyCodeBench는 여섯 모델을 대상으로 하는 대화형 벤치마크를 통해, LLM이 모호한 요구사항을 스스로 발견하고 질문으로 명확히 하는 능력을 살펴봅니다. 결과는 코드 생성 능력이 좋다고 요구사항 명확화 능력도 자동으로 좋은 것은 아님을 시사합니다. 추론에 더 많은 계산을 투입해도 모호성을 찾아내는 능력의 개선은 제한적이었으며, 특히 여러 불명확한 조건이 겹칠 때 그랬습니다.

Hamblin과 동료들의 2026년 연구 SpecBench는 연관되지만 다른 능력을 살펴봅니다. Kubernetes, React, Rust, TVM, vLLM의 실제 RFC 과정에서 나온 설계 제안의 누락, 모순, 잘못된 가정을 에이전트가 찾아내는 과제입니다. 평가된 에이전트 중 최고 성적은 정확도 44.4%였습니다. 이것은 프로덕트 오너십의 일반적인 오류율이 아니며, 미래 모델이 더 잘할 수 없다는 근거도 아닙니다. 명세서를 검토하는 일은 여전히 그 자체로 어려운 과제이며, 좋은 코딩 결과만으로 그 능력을 추정할 수 없다는 점만 보여 줍니다.

물론 AI는 공급 과정도 개선할 수 있습니다. 저도 도메인 질문을 구조화하고, 여러 UX 접근법을 비교하고, 불명확한 부분을 드러내고, 확정된 결정에서 구체적인 구현 과제를 도출하는 데 활용합니다. 흥미로운 경계는 “AI는 구현해도 된다”와 “AI는 요구사항을 다루면 안 된다” 사이에 있지 않습니다. 제안을 만들어 내는 일과 그 제안이 도메인 관점에서 유효한지 구속력 있게 결정하는 일 사이에 있습니다.

DORA 2025 보고서는 AI를 조직의 강점과 약점을 증폭하는 도구로 설명합니다. 제 관찰과 맞지만, 코딩 에이전트를 사용하는 기업에서 반드시 프로덕트 오너십이 새로운 병목이 된다는 증거는 아닙니다. 바로 그 추가적인 추론이 제 가설입니다.

프로덕트 오너의 수보다 의사결정 능력

예전에는 성숙도와 제품, 복잡성에 따라 프로덕트 오너 한 명이 여러 개발자나 둘 이상의 팀을 지원할 수 있었습니다. 기술 쪽에 구현 작업이 많을수록 새로운 요구사항을 준비하고 기존 결정을 조율할 시간도 더 있었습니다.

코딩 에이전트가 그 구현 시간의 일부를 크게 줄이면 도메인 준비와 기술 구현 사이의 균형이 달라질 수 있습니다. 처음에는 프로덕트 오너 한 명에 개발자 열 명 정도였던 비율이 어떤 상황에서는 훨씬 가까워질 수 있겠다는 직감이 들었습니다. 하지만 여기서 일대일이나 일대삼이라는 새로운 목표 비율을 도출하지는 않겠습니다. 프로덕트 오너가 요구공학, UX, 도메인 전문성, 최종 검수를 모두 합친 역할과 같지는 않기 때문입니다.

제가 관심을 두는 것은 동시에 진행 중인 작업 흐름 하나당 제공할 수 있는 의사결정 능력입니다. 조직은 도메인 질문 몇 개에 제때 답할 수 있을까요? UX 콘셉트 몇 개를 전문적으로 평가할 수 있을까요? 구현한 뒤 검증 가능한 기대에 맞춰 검수할 만큼 구체적인 요구사항은 몇 개일까요? 질문에서 구속력 있는 답변까지 얼마나 기다려야 할까요?

개발팀이 명확해진 요구사항을 받지 못해 주로 자기 일을 찾아다닌다고 해서 자동으로 개발자의 잘못이 되는 것은 아닙니다. 코딩 에이전트를 더 늘려도 그 공백이 저절로 메워지지는 않습니다. 추가 생산 능력이 가치를 만들려면 우선 어떤 가치를 만들어야 하는지가 명확해야 합니다.

따라서 에이전트마다 프로덕트 오너를 한 명씩 채용하는 것이 답일 필요는 없습니다. 비즈니스 분석가가 부족할 수도 있고, UX 역량이나 진짜 도메인 전문가, 결정할 수 있는 제품 책임자가 부족할 수도 있습니다. 단지 제품이 달성할 과제가 불분명할 수도 있습니다. 역할을 아무리 잘 나눠도 도메인 모순에 최종 결정을 내릴 사람이 연락되지 않으면 소용이 없습니다.

때로는 더 이상 코드를 생성하지 않는 것이 실제로 올바른 결정입니다. 좋은 제품 조직의 목표는 모든 에이전트를 늘 바쁘게 만드는 것이 아닙니다. 올바른 변경을 전달하고 잘못된 변경을 피하는 것입니다.

화살표는 각 책임을 연결하고 발견한 내용을 요구사항으로 돌려보냅니다. 구현 전의 잠재적 병목은 여전히 가설이며, 고정된 인력 비율이나 폭포수 과정을 뜻하지 않습니다.

원본 크기로 그래픽 보기

공장 비유 뒤에 있는 가설

이 경험에서 저는 아직 직접 입증되지 않은 가설을 도출합니다. 코딩 에이전트가 기술 구현을 더 크게 가속할수록, 제품 조직의 전체 처리량은 도메인 관점에서 타당성이 확인된 요구사항과 적시에 내려지는 결정을 제공하는 능력에 더 크게 좌우될 수 있다는 것입니다.

그 결과가 반드시 특정 자리에 인력을 더 뽑는 것이어야 하지는 않습니다. 더 의식적인 제품 탐색, 더 전문적인 요구공학, 더 나은 기술 모델링, 더 이른 UX 피드백, 책임이 명확한 도메인 검수처럼 일을 다르게 배분하는 것일 수 있습니다. AI는 이런 활동도 지원하여 일부 병목을 줄일 수 있습니다. 그로 인해 사람이 더 필요한지 덜 필요한지는 각 조직의 구체적인 상황에서만 판단할 수 있습니다.

저에게는 사람에 관한 두 번째 차원도 중요합니다. 열정적인 개발자가 이미 프론트엔드, 백엔드, 아키텍처, 배포를 맡고 있다면, 구현에서 절약한 시간을 이유로 모든 도메인 결정과 UX 질문, 규제 준수 입증까지 맡겨서는 안 됩니다. 그렇게 되면 생산 라인은 자동화했지만 그 모든 의존 관계는 한 사람에게 집중한 셈입니다.

어쩌면 전문가들이 잘 협력하게 하는 능력이 에이전트 기반 작업의 가장 중요한 성공 요인 중 하나가 될지도 모릅니다. 도메인 전문가는 각 분야의 깊이를 제공합니다. 소프트웨어 엔지니어는 그 깊이를 모델과 믿을 수 있는 시스템으로 옮깁니다. 코딩 에이전트는 결과의 범위를 충분히 제한하고 검증할 수 있는 일을 맡습니다. 참여자들은 필요한 피드백을 통해 계속 연결되어 있습니다.

이것은 폭포수 방식으로 돌아가자는 말이 아닙니다. 책임을 불분명하게 만드는 대가로 속도를 얻지 않도록 전체 가치 흐름을 조직하려는 시도입니다.

맺음말: 공장은 전체가 함께 작동해야 합니다

지리정보 사례가 놀라웠던 이유는 좋은 명세서와 에이전트의 지원이 있을 때 경험 있는 엔지니어링이 어디까지 해낼 수 있는지 보여 줬기 때문입니다. 구현자가 그 분야의 전문 과학자일 필요도 없었습니다. 반대로 요구사항이 부족했던 직장 경험에서는 도메인 관점에서 다음에 무엇을 만들어야 하는지가 불분명하면, 뛰어난 기술 생산 능력도 별다른 힘을 쓰지 못한다는 사실을 봅니다.

그러니 코딩 에이전트가 앞으로 개발자 몇 명을 대체할지로만 논의를 좁혀서는 안 됩니다. 어떤 전제 조건이 더 중요해지는지, 프로덕트 오너십과 현업, 요구공학, UX, 아키텍처, 구현 사이에서 일의 분배가 어떻게 달라지는지도 살펴야 합니다.

자신의 전문 분야 밖을 기꺼이 살펴보는 사람을 모든 조직적 공백의 만능 해결책으로 삼지 않도록 주의해야 합니다. 교차 기능 팀은 많은 일을 할 수 있습니다. 개발자 한 사람이 의사이자 지리정보 전문가, UX 디자이너, 플랫폼 엔지니어, 소프트웨어 아키텍트일 필요는 없습니다.

코딩 에이전트의 새로운 가능성은 인상적입니다. 바로 그렇기 때문에 다음 구현을 얼마나 빨리 만들어 내는지만으로 성공을 평가하고 싶지 않습니다. 도메인 지식, 구속력 있는 결정, 좋은 엔지니어링을 조직이 얼마나 안정적으로 올바른 소프트웨어로 바꾸는지가 점점 더 궁금해집니다.

로봇은 준비되어 있습니다. 이제 공급과 생산 계획, 품질 관리도 이야기할 때가 된 것 같습니다.

출처와 해석 범위

이 글은 개인적 실무 경험(GIS 프로젝트: 계획 이틀, 에이전트 기반 구현 이틀, 리뷰 이틀, 최종 검수 이틀, 사소한 렌더링 오류 하나), 관련 연구, 그리고 명시적으로 열린 조직적 가설을 구분합니다. 여덟 날에는 도메인 명세서를 작성한 노력이 포함되지 않으며, 비교 생산성 연구도 아닙니다.

Burstedde, Alexander & Tiedemann, Jurek (2025): Kompetenzbarometer – Fachkräftesituation in Digitalisierungsberufen bis 2028. 독일 경제연구소, 표 3-1(2023년 피고용자: 지리정보학 — 전문가, 1,694명). 연구.

ISO/IEC/IEEE 29148:2018: Systems and software engineering – Life cycle processes – Requirements engineering. 표준.

Fang, Zheng et al. (2026): ClarifyCodeBench: Evaluating LLMs on Clarifying Ambiguous Requirements for Code Generation. 프리프린트.

Hamblin, Grant et al. (2026): SpecBench: Evaluating Specification-Level Reasoning for Software Engineering LLM Agents. 프리프린트.

DORA / Google Cloud (2025): State of AI-assisted Software Development.

Schwaber, Ken & Sutherland, Jeff (2020): The Scrum Guide.

시리즈에서 이어 읽기: 프롬프트 엔지니어링은 프롬프트를 쓰기 전에 시작됩니다 · 생성은 저렴하고, 검증은 비싸다 · Agentic Work의 경제학 · 소프트웨어 엔지니어링은 결코 코딩만이 아니었다 · AI는 우리가 Big Ball of Mud로 향하는 속도를 높인다 – 하나의 가설.