이런 분이 읽으면 좋습니다
요약: 개발 프로세스는 결국 두 문제를 해결하기 위해 존재한다 — 개인의 인지 한계 극복과, 여러 사람이 함께 일할 때의 조정 비용 감소. AI Agent가 현장에 본격 진입하면서 이 두 전제가 동시에 흔들린다. 이 글은 Waterfall·Agile·DevOps를 비판적으로 돌아보고, 현업에서 실제로 작동하는 협업 방식을 점검한 뒤, AI Agent 시대에 유효한 6가지 원칙을 제시한다. “방법론”이 아니라 “원칙”인 이유는, 방법론은 맥락을 벗어나면 의례가 되지만 원칙은 맥락에 맞게 해석되기 때문이다.
이 글은 개발팀을 이끄는 리더·테크리드·시니어 개발자, 그리고 AI Agent 도입이 팀 구조와 개발 프로세스에 어떤 영향을 줄지 고민하는 실무자를 위해 썼다. 특정 도구나 프레임워크 가이드가 아니라, 시대 전환기에 의사결정의 축을 잡기 위한 견해다.
서론
개발 프로세스는 결국 두 가지 문제를 해결하기 위해 존재한다. 첫째는 인간 개인의 인지적 한계를 극복하기 위한 구조이고, 둘째는 여러 사람이 함께 일할 때 발생하는 조정 비용(coordination cost)을 줄이기 위한 장치다. Waterfall부터 Agile, DevOps에 이르기까지 모든 방법론은 결국 이 두 문제에 대한 서로 다른 답변이었다.
AI Agent가 개발 현장에 본격적으로 들어오면서, 이 두 전제가 동시에 흔들린다. 개인의 인지적 한계는 도구에 의해 크게 확장되고, 조정의 주체는 더 이상 인간들만이 아니다. 이 글은 지금까지의 개발 프로세스를 비판적으로 돌아보고, AI Agent 시대에 어떤 협업 방식이 실제로 작동할지에 대한 견해를 정리한 것이다.
1부. 개발 프로세스의 진화, 다시 읽기
Waterfall은 자주 조롱의 대상이 되지만, 그 발상 자체는 건전했다. “설계 후에 구현한다”는 것은 건축과 제조업에서 성공한 방식이었고, 그것을 소프트웨어에 이식하려 한 것이다. 문제는 이식 자체가 아니라, 소프트웨어의 본질이 그것들과 다르다는 점을 너무 늦게 깨달았다는 데 있다. 소프트웨어는 “실행되어야만 드러나는 요구사항”을 다룬다. 설계가 완료되는 순간은 존재하지 않으며, 실행을 통한 학습만이 설계를 완성한다.
Agile은 이 통찰에서 출발했다. 짧은 주기로 실행하고, 피드백을 받고, 다시 수정하는 루프가 본질이다. 그러나 Agile은 도입 과정에서 의례(ritual)로 변질되는 경우가 많았다. 스크럼 미팅, 스프린트 플래닝, 회고(retrospective)가 “학습을 위한 도구”가 아니라 “해야 하는 행사”가 되는 순간 Agile의 정신은 사라진다. 현업에서 관찰해 온 바로는, Agile을 잘하는 팀과 못하는 팀의 차이는 프로세스 준수 여부가 아니라 의사결정의 지연 시간에 있었다. 빠르게 결정하고, 빠르게 실행하고, 빠르게 수정하는 팀만이 진짜 Agile하다. AI 에이전트 시대의 Agile에 대해서는 AI 에이전트 시대에 애자일은 살아남는가에서 더 깊이 다뤘다.
DevOps는 개발과 운영 사이의 벽을 허무는 문화적 운동이었지만, 기술적 본질은 피드백 루프를 자동화하는 것이었다. CI/CD 파이프라인, Infrastructure as Code, 관측 가능성(observability)은 모두 “사람이 중간에 끼지 않아도 시스템이 자신에 대해 말해주는 구조”를 만들기 위한 장치다. 이 관점이 중요한 이유는, AI Agent 시대에 이 자동화된 피드백 루프가 곧 Agent의 작동 기반이 되기 때문이다. Agent는 테스트가 실패하면 알고, 배포가 롤백되면 알고, 에러 로그를 스스로 읽을 수 있다 — 단, 그런 신호가 이미 자동화되어 있을 때만.
2부. 협업 방식 — 무엇이 실제로 작동했는가
현업에서 가장 효과가 검증된 협업 방식은 의외로 소박하다.
코드 리뷰는 거의 모든 팀이 채택하지만, 실제로 제대로 작동하는 경우는 드물다. 좋은 코드 리뷰는 “버그 찾기 게임”이 아니라 “맥락 공유”다. PR이 머지되는 순간 최소 두 사람이 그 변경을 이해한다는 것이 핵심 가치다. 이 관점에서 보면 “LGTM”만 남기는 리뷰는 리뷰가 아니다.
페어 프로그래밍은 많은 조직에서 “비효율적”이라는 이유로 배척되지만, 복잡한 설계 결정을 내릴 때나 새로 합류한 사람이 맥락을 익혀야 할 때 그 진가를 발휘한다. 두 사람이 키보드 하나 앞에 앉아 있는 동안, 그들은 단순히 코드를 쓰는 것이 아니라 사고 모델을 공유하고 있는 것이다. 이렇게 공유된 사고 모델은 이후 몇 달간의 커뮤니케이션 비용을 낮춘다.
**트렁크 기반 개발(Trunk-Based Development)**과 **기능 플래그(Feature Flag)**는 브랜치 전략의 복잡성을 줄이고 통합 지점을 현재 시점으로 당긴다. 긴 수명의 브랜치가 야기하는 머지 지옥(merge hell)을 피하는 가장 단순한 방법은 브랜치를 오래 살려두지 않는 것이다.
문서화는 보통 저평가된다. 하지만 경험상 “왜 그렇게 결정했는가”를 기록하는 팀(ADR, Architecture Decision Record를 남기는 팀)은 몇 년이 지난 후에도 방향을 잃지 않는다. 코드는 “무엇을 하는가”를 말해주지만, 문서만이 “왜 그렇게 하는가”를 말해준다.
3부. AI Agent가 흔드는 전제들
AI Agent가 개발 팀에 합류하면서 바뀌는 것은 단순히 “코드를 더 빨리 쓴다”가 아니다. 훨씬 근본적인 변화가 일어난다.
첫째, 코드 생산은 더 이상 병목이 아니다
이것이 가장 큰 지각 변동이다. 과거 수십 년간 소프트웨어 공학의 거의 모든 프로세스는 “코드를 쓰는 것이 비싸다”는 전제 위에 세워졌다. 신중한 설계, 재사용, 추상화, DRY 원칙 — 이 모두는 “쓰는 시간”을 최소화하려는 노력이었다.
둘째, 명세(specification)의 가치가 극적으로 올라간다
Agent에게 일을 시키려면 무엇을 원하는지 정확히 말해야 한다. 애매한 요구사항은 애매한 결과물로 돌아온다. 여기서 역설이 발생한다 — 사람에게 일을 시킬 때도 이것은 항상 사실이었지만, 사람은 애매함을 스스로 해결하려는 암묵적 노력을 기울였다. Agent는 그런 노력을 덜 한다(혹은 잘못된 방향으로 한다). 따라서 “요구사항을 명확히 하는 능력”은 AI 시대에 더 이상 선택이 아니라 핵심 기량이다.
셋째, 신뢰 경계(trust boundary)가 이동한다
지금까지 코드 리뷰는 어느 정도 “이 사람의 코드는 믿을만한가”의 문제였다. 앞으로는 “이 변경은 그 자체로 믿을만한가”의 문제가 된다. Agent가 작성한 코드에는 인간 저자의 평판이 없고, 시니어 개발자의 코딩 스타일이 남기는 신호도 없다. 따라서 모든 변경은 독립적으로 검증되어야 한다. 이는 코드 리뷰, 테스트, 정적 분석의 역할이 줄어드는 것이 아니라 오히려 커진다는 것을 의미한다. 이 신뢰 경계를 런타임 차원에서 설계하는 방법이 하네스 엔지니어링이다.
넷째, 조정 비용의 구조가 바뀐다
Brooks의 법칙(“지연된 프로젝트에 사람을 더 투입하면 더 지연된다”)은 인간 간 커뮤니케이션 비용이 인원 수 제곱에 비례해 증가한다는 관찰에 기반한다. Agent는 이 공식에 새로운 변수를 추가한다. Agent는 지치지 않고, 맥락을 잊지 않으며(적어도 원리적으로는), 동시에 여러 작업을 할 수 있다. 그러나 Agent 간의 조정, 그리고 Agent-인간 간의 조정은 새로운 형태의 오버헤드를 만든다. 특히 Agent가 서로 모순되는 변경을 동시에 일으킬 때, 혹은 인간이 Agent의 작업을 따라잡지 못할 때.
4부. AI Agent 시대에 효율적인 방식 — 여섯 가지 원칙
지금까지의 분석을 바탕으로, 다음 원칙들이 새로운 시대에 유효하다고 본다. 방법론이 아니라 원칙으로 제시하는 데에는 이유가 있다. 방법론은 맥락을 벗어나면 의례가 되지만, 원칙은 맥락에 맞게 해석될 수 있기 때문이다.
원칙 1. 명세를 코드로, 검증을 자동화로
사람이 써야 할 가장 중요한 인공물은 실행 가능한 명세다. 테스트, 타입, 계약(contract), 불변식(invariant)은 Agent에게 “무엇을 원하는지”를 알려주는 언어이자, 그 결과물을 검증하는 수단이다. TDD는 한때 종교적 신념의 영역에 있었지만, AI Agent 시대에는 실용적 필수로 부상한다. 테스트를 먼저 쓰고 Agent에게 구현하게 하면 검증과 생산이 자연스럽게 분리된다.
원칙 2. 작고, 독립적이고, 검증 가능한 단위로 나눠라
Agent가 잘 작동하는 작업의 특징은 세 가지다. 맥락이 작고, 의존성이 명확하고, 결과를 검증할 수 있다. 이것은 좋은 소프트웨어 설계의 원칙과 정확히 같다. 느슨한 결합, 높은 응집도, 명확한 인터페이스. 차이라면, 과거에는 “사람이 이해하기 쉽도록” 이렇게 설계했다면, 앞으로는 “Agent가 정확히 작업할 수 있도록” 이렇게 설계해야 한다는 것이다. 다행히 두 목적은 일치한다. 좋은 설계가 AI 시대에 더 보상받는 구조다.
원칙 3. 인간의 시간은 리뷰와 판단에 써라
Agent가 코드를 생산할 수 있다면, 인간 개발자의 가장 희소한 자원은 판단력이다. 무엇을 만들 것인가, 어떤 트레이드오프를 받아들일 것인가, 이 코드가 정말 문제를 해결하는가 — 이 질문들에는 Agent가 답할 수 없다. 적어도 답해서는 안 된다. 따라서 팀의 구조는 “많은 주니어 + 몇 명의 시니어”에서 “소수의 판단 능력 있는 개발자 + 다수의 Agent”로 이동할 가능성이 높다. 이것이 주니어 개발자에게 나쁜 소식은 아니다. 판단력은 훈련되는 것이며, Agent와 함께 일하면서 오히려 훈련 속도가 빨라질 수 있다. 다만 훈련의 내용은 바뀐다 — “타이핑 속도”가 아니라 “문제 정의”와 “결과 평가”를 훈련해야 한다. 경험 수준별로 에이전트를 어떻게 활용할지는 개발자 경험 수준별 AI 에이전트 전략에서 따로 정리했다.
원칙 4. 작은 팀, 빠른 루프
AI Agent 시대의 가장 큰 역설은, 개인의 생산성이 올라갈수록 작은 팀의 가치가 커진다는 것이다. 조정 비용은 여전히 인원 수 제곱에 가깝게 증가하고, Agent까지 감안하면 오히려 더 복잡해진다. 따라서 “2~3명 + Agent들”의 조합이, 과거에 10명이 했던 일을 더 빠르게 해낼 수 있다. Amazon의 two-pizza team 원칙은 AI 시대에 더욱 유효해진다. 오히려 one-pizza team, 혹은 one-person + agents 시대가 올 수도 있다.
원칙 5. 가드레일을 먼저, 자유를 나중에
Agent에게 권한을 주는 것은 신입 개발자에게 프로덕션 데이터베이스 접근 권한을 주는 것과 비슷하다. 능력은 있지만 맥락이 부족하다. 따라서 가드레일 — 권한 분리, 샌드박스, 롤백 가능한 배포, 관측 가능성 — 이 먼저다. 가드레일이 충분히 튼튼하면 Agent에게 더 많은 자유를 줄 수 있고, 자유가 많을수록 Agent의 효용은 커진다. “Agent가 망가뜨려도 큰일 나지 않는 환경”을 만드는 것이 Agent 활용의 상한을 결정한다.
원칙 6. 문서는 인간이 아니라 Agent를 위해서도 쓴다
앞으로 문서는 두 청중을 가진다. 인간과 Agent. 좋은 소식은 두 청중이 원하는 것이 거의 같다는 점이다. 명확한 맥락, 결정의 근거, 예외와 제약. 나쁜 소식은 많은 팀이 아직 이것을 제대로 하지 못한다는 점이다. README, ADR, 시스템 다이어그램 — 이것들은 이제 “있으면 좋은 것”이 아니다. Agent가 기존 코드베이스에 어떻게 기여할 수 있을지는 거의 전적으로 문서의 질에 달려있다. 맥락 없는 코드베이스에서 Agent는 평범한 결과밖에 내지 못한다.
결론: 방법론이 아니라 원칙을
“AI 시대의 새로운 방법론”을 제안할 생각은 없다. Scrum 2.0이나 Agile-with-AI 같은 이름표는 곧 나타날 것이고, 대부분은 지난 방법론들이 그랬듯 의례로 변질될 것이다. 컨설턴트들이 자격증을 팔기 시작하면 이미 그 방법론은 생명력을 잃은 것이다.
대신 원칙을 기억하는 편이 낫다. 소프트웨어 개발의 본질적 어려움은 바뀌지 않았다.
따라서 효율적인 방식이란, 인간이 본질에 집중하고 Agent가 우연을 처리하도록 일의 경계를 다시 긋는 것이다. 무엇이 본질이고 무엇이 우연인지 구분하는 능력 — 이것이 개발자의 새로운 핵심 역량이다. 도구는 새로워졌지만, 그것을 잘 쓰는 것은 여전히 오래된 미덕 — 명확한 사고, 정직한 피드백, 빠른 학습 — 에 달려있다.
Agent는 우리의 경쟁자가 아니라 증폭기다. 훌륭한 판단은 더 훌륭해지고, 어설픈 판단은 더 어설퍼진다. 이 시대에 이기는 팀은 새로운 도구를 가장 먼저 쓰는 팀이 아니라, 자신들이 정말로 무엇을 만들고 싶은지 가장 잘 아는 팀일 것이다.