Medium 기사 "Agile is Out, Architecture is Back"의 요약 및 전체 번역
요약 및 핵심 정리
개요
애자일(Agile) 방식이 소프트웨어 개발의 시대적 중심이었으나, AI가 자동으로 코드를 작성하는 시대에 접어들면서 설계(아키텍처)의 중요성이 다시 부각되고 있습니다.
앞으로의 개발자는 단순한 코더가 아니라, 시스템을 설계하고 패턴과 구조를 만드는 '아키텍트' 역할이 중심이 됩니다.
중요한 변화
AI 코딩 도구의 발전으로 반복적이고 전술적인 코딩은 자동화되고, 전략적인 디자인(아키텍처)이 개발자 역할의 핵심이 됩니다.
코드를 빠르게 만들어내는 것보다, 장기적으로 견고하고 확장 가능한 시스템을 설계하는 능력이 더 중요해졌습니다.
앞으로의 소프트웨어는 '인간'만이 아니라 'AI'를 위한 명확한 구조와 예시를 포함해야 하므로, 시스템적 설계와 문서화가 다시 중요해집니다.
개발자의 새로운 역할
좋은 설계와 시스템 구조, 명확한 네이밍, 일관성, 강제 패턴(타입, 린터, 테스트 등)을 갖춘 환경을 구축해야 함.
코드를 직접 작성하는 역할에서 벗어나, AI가 올바르게 동작할 수 있도록 가이드하는 설계자가 되어야 함.
개발자 개인의 역량보다, 잘 구조화된 시스템이 다양한 참여자—특히 AI—가 안정적으로 협업할 수 있게 만드는 것이 더욱 중요해짐.
실질적 지도원칙
코드가 아닌 '시스템' 단위로 사고하기
기능뿐 아니라 안전장치(가드레일) 구축하기
AI와 인간 모두가 학습할 수 있는 뛰어난 예시 큐레이팅하기
코드 품질 및 일관성의 총괄자가 되기
천재 개발자에 집착하지 않고, 문제 발생 자체를 구조적으로 예방하는 방식을 추구하기
미래 전망
빠른 기능 구현보다, '방향'이 중요해진다.
기술은 계속 빨라지지만, 구조와 원칙이 없는 속도는 결국 기술부채로 이어진다.
앞으로는 AI가 코딩을 주도하는 환경에서, 사람이 설계와 방향성을 제시하며 머신과 협업하는 시대가 펼쳐질 것이다.
핵심 메시지: 속도, 반복, 단기적 결과 중심에서 벗어나, AI와 함께 장기적이고 견고한 소프트웨어를 만들기 위한 '아키텍처'적 사고와 시스템 설계가 미래 개발자의 가장 중요한 역량이 된다.
아래는 Medium 기사 "Agile is Out, Architecture is Back"의 전체 번역입니다.
애자일은 끝났다, 아키텍처가 돌아왔다
다음 세대의 소프트웨어 개발자는 코더가 아닌 '아키텍트'가 될 것이다.
출렁이는 추
소프트웨어 개발은 늘 극단 사이에서 정의되어 왔다. 초기에는 모든 것을 계획했다. 스펙은 신성했고, 아키텍처 다이어그램이 코드 한 줄보다 먼저 나왔다. 변화엔 시간이 오래 걸렸고, 거의 화물선을 운전하는 느낌이었다—느리고, 관료적이며, 과도하게 문서화됐다.
그러다 애자일이 등장하며 출렁임은 완전히 반대가 된다. 속도, 반복, 미완성에 집중했다. “포괄적 문서보다 작동하는 소프트웨어”가 새로운 구호가 됐다. 빠르게 배포하는 것이 처음부터 제대로 하는 것보다 더 중요했다. 이 변화는 엄청난 생산성 향상을 가져왔고, 소프트웨어 문화도 영원히 변했다.
이제 우리는 새로운 시대에 진입하고 있다—인공지능(AI) 툴이 문장 하나로 코드를 만들어내는 시대다. GitHub Copilot, Claude Code 같은 툴은 개발자의 정의를 다시 쓰고 있다. 코드를 쓰는 것뿐 아니라 '코드가 작성되는 환경'을 설계하는 것이 중요해졌다.
출렁이는 추는 다시 되돌아오고 있다.
워터폴(waterfall)로 완전히 돌아가는 것은 아니지만, 디자인과 문서화가 다시 중요해지는 방향이다—새로운 인턴이나 다음 엔지니어가 아니라, 앞으로 1만 줄의 코드를 생성할 머신을 위해서다. 우리는 "바이브 코더(vibe coder)"—의미를 제대로 이해하지 못한 채 프롬프트 입력만으로 결과물을 내는 개발자—의 시대를 지나, 사려 깊고 인간 중심의 아키텍처가 고품질 소프트웨어의 초석이 되는 세상으로 간다.
예전에 CTO 아래에서 일할 때, 그는 소프트웨어 전달에 사전 고민이 거의 없다는 사실을 놀라워했다. 백 명이 넘는 개발자 팀에서 그는 나에게 "개발자가 타이핑을 시작하기 전에 좀 더 생각하도록 만들 것"을 부탁했다. 당시엔 애자일의 흐름에 역행하는 것처럼 느껴졌지만, 현재 AI가 대부분의 코드를 생성하고 개발자가 시스템 디자인과 감독 역할로 이동하는 산업 트렌드를 보면, 그는 안도했을 것이다. 출렁임은 마침내 신중함으로 돌아왔다.
머신에게 자유롭게 프롬프트만 던진다면 우리는 곧 기술부채에 파묻힐 것이다. 그러나 시스템을 우리가 설계한다면, 더 빠르고 더 나은 확장이 가능하다.
바이브 코딩과 프롬프트 엔지니어링
“그냥 바이브해(vibe it).”
이 문장은 Andrej Karpathy가 대중화시킨 것으로, AI가 개발을 주도하는 새로운 흐름을 상징한다. 리액트 컴포넌트 필요해? 프롬프트만 치면 된다. API 연동? 프롬프트. CRUD와 페이징, 에러 처리, 로딩 상태까지? 좋은 프롬프트 하나면 80%는 완료된다.
바이브 코딩은 자연어 프롬프트, AI 기반 뼈대 작성, 빠른 반복이 합쳐진 현상이다. 마법처럼 느껴진다. 특히 신입 개발자에겐 이것이 코딩의 전부일지도 모른다.
그 매력은 분명하다. 바이브 코딩은 마찰을 없애고, 보일러플레이트를 건너뛰며, 속도를 크게 높인다. 몇 년 전 팀이 며칠 걸릴 일도 오후에 완성할 수 있다.
하지만 문제는 있다: 생각의 속도만큼 작성된 코드는 시간이 흐르면 쉽게 망가진다.
바이브 코딩은 얕은 이해를 조장한다. 당장의 올바름에 집중하며 6개월 후 버틸 수 있을지 고민하지 않는다. 아키텍처 결정은 모델이 암묵적으로 내린다. 패턴은 검토 없이 코드베이스에 들어오고, 곧 누가 무엇을 했는지 아무도 모르는 복잡성이 쌓인다.
책임 있게 사용하면 바이브 코딩은 슈퍼파워다. 무분별하게 사용하면, 기술부채 지옥행 티켓이다.
해결책은 느려지는 게 아니라, 누가 운전대를 잡을 것인가에 있다. 더 많은 바이브 코더가 아니라, 시스템을 고민하는 사람이 필요하다. AI의 힘을 통제하는 아키텍트가 필요하다.
함수가 아니라 프레임워크를 설계한다
개별 함수를 쓰는 작업은 자동화되고 있다. 이는 추측이 아니라 현실이다. AI는 타입스크립트 리졸버, 그래프QL 스키마, 플러터 위젯을 몇 초 만에 만든다. 결과적으로 개발의 전술적 레이어는 상품화되고 있다.
하지만 전략적 레이어는 여전히 인간의 영역이다.
현대의 소프트웨어 개발자는 단순한 빌더가 아니라 ‘아키텍트’가 되어가고 있다. 직책이 아니라 실제 의미에서 말이다. 그들은 소프트웨어가 생성되는 구조를 설계한다. 라이브러리 선정, 경계 구분, 패턴 정의 등 AI 생성 코드가 깨끗하게 통합되고 지속적으로 확장될 수 있도록 설계한다.
진짜 미래형 개발자는 컴포넌트를 그리는 코드 루프가 아니라, 그 컴포넌트의 존재 이유와 시스템과의 상호작용, 그리고 시스템의 구조적 결정을 고민한다.
이 변화는 미묘하지만 강력하다.
“이 엔드포인트의 최적 구현 방법은?”에서 “이 부분의 시스템 인터페이스(계약)는 어떻게 하면 가장 깔끔하게 만들 수 있을까?”로 질문의 관점이 변한다.
“이 버그를 어떻게 고칠까?”에서 “이런 종류의 버그가 구조적으로 발생하지 않도록 어떻게 방지할까?”로 고민이 옮겨간다.
파일 리팩토링에 시간을 쓰기보다, 나쁜 패턴 자체가 나타나지 않도록 제약을 건다.
새 패러다임에서 가장 가치 있는 개발자는 가장 많은 코드를 쓰는 사람이 아니라, 코드가 살아갈 최고의 시스템을 만드는 사람이다. AI가 명확하게 동작할 수 있도록 프레임워크, 뼈대, 패턴, 안전장치를 만드는 사람이 중요하다.
일은 머신을 능가하는 게 아니라, 머신보다 더 깊게 생각하는 것이다.
새로운 청중
예전엔 다음 개발자, 혹은 미래의 나를 위해 클린 코드와 꼼꼼한 문서를 썼다. 좋은 주석, 명확한 구조, 직관적인 네이밍이 중요했다.
이제 다음 “개발자”는 AI다.
이 변화는 모든 걸 바꾼다. 신입 개발자가 쉽게 적응하길 바라는 게 아니라, 몇 초 만에 500줄 코드를 만들어낼 수 있는 모델을 위한 토대를 쌓는다. AI는 패턴을 인식하는 머신이다. 인간처럼 추론하지 않는다. 명확히 물어보지도 않는다. 구조, 네이밍, 예시가 가르치는 대로 동작한다—그게 의도한 것과 상관없이.
따라서 시스템은 머신이 이해할 수 있도록 만들어야 한다.
예측 가능한 패턴—AI가 ‘올바른 것’을 인식할 수 있도록.
타이트한 제약—위험한 영역으로 넘어가지 않도록.
큐레이팅된 예시—AI가 보여준 것만 반복하게 되므로.
명확한 추상화—사람뿐 아니라, 다양한 파일을 연산하는 모델을 위해서.
이제 우리는 코드만 쓰는 게 아니라, 미래의 파트너(AI)를 위한 트레이닝 데이터를 설계하는 중이다. 좋은 함수, 잘 명명된 타입, 엄격하게 관리된 경계 하나하나가 추후 AI가 빈 부분을 채울 때 따라갈 Breadcrumb이 된다.
이건 단순히 엔지니어링 위생이 아니라, 속도의 핵심이기도 하다.
그래서 여전히 네이밍, 일관성, 인터페이스가 중요하다. 인간의 온보딩을 위해서만이 아니다. 이제는 머신 파트너가 100개의 새로운 기능을 혼돈 없이 만들게 돕기 위해서다.
앞으로의 개발자의 진짜 일: 그냥 돌아가게 만드는 게 아니라, 머신이 명확하게, 재현 및 확장 가능하게 만들게 하는 것이다.
새로운 매니페스토
20년간 애자일 매니페스토는 소프트웨어 팀에 큰 영향을 끼쳤다. 덕분에 과도한 스펙, 18개월짜리 워터폴 프로젝트에서 벗어났다. 워드 문서 쓰기를 그만두고, MVP를 빠르게 배포했다. 엄청난 개선이었다.
하지만 지나치게 한쪽으로 기울었다.
애자일은 “포괄적 문서보다는 작동하는 소프트웨어”를 강조했다. 괜찮은 접근이었다—'작동하는 소프트웨어'가 "그냥 끝내자"와 동일시 되기 전까지는. 바이브 코딩과 AI 기반 프롬프트 시대에는 이 원칙이 흔들린다.
소프트웨어가 작동한다 해도… 반드시 이해되는 것은 아니다.
AI가 점점 더 많은 코드를 만드는 시대에, 추는 다시 움직인다. 문서화, 사양 정의, 안전장치의 가치가 다시 부각된다. 인간을 위해서만이 아니라, AI 동료를 위해서다.
애자일의 핵심 가치가 무효화된 건 아니지만, 일부는 해석이 바뀌어야 한다. 새로운 시대에서는:
우리는 작동하는 소프트웨어보다 포괄적 구조를 중시해야 할지도 모른다—당장 되는 소프트웨어가 내일 무너진다면 문제다.
개인과 상호작용보다 큐레이팅된 시스템을 더 중시해야 할지도 모른다—개인이 점차 머신이 되고 있으므로.
변화에 대응하는 것보다 맥락에 대응하는 것이 더 중요할 수 있다—안정성과 재현성이 빠른 반복을 가능하게 하므로.
이건 관료주의로 돌아가자는 게 아니다. 신중한 제약, 튼튼한 아키텍처, 머신이 최적화할 수 있는 뼈대 위의 새로운 애자일 시대다.
2005년에는 속도가 병목이었다. 2025년에는 방향이 병목이다.
애자일은 우리를 움직이게 했다. 이제 지도(map)가 필요하다.
다음 세대
당신이 시니어 개발자나 테크 리드라면 이미 역할이 변화하고 있다—타이틀만 아직 따라오지 않았을 뿐.
단순히 기능을 만드는 데서 벗어나, 그 기능들이 만들어지는 환경을 정의하는 역할로 이동 중이다. 아키텍처를 소유하고, 패턴을 강제하며, 인간 팀뿐 아니라 점점 더 많은 AI 협업자를 안내할 시스템을 설계해야 한다.
이 새로운 환경에서 리더십을 위해선 아래에 집중하라:
1. 코드 조각이 아닌 시스템으로 사고할 것 코드를 잘 쓰는 것만으론 부족하다. 시스템을 설계해야 한다.
경계는 어디에 둘 것인가?
일괄적으로 결정해서 코드에 녹여야 할 판단은?
어느 추상화가 시간이 갈수록 변화/소모를 줄일 것인가?
코드베이스는 그 어느 때보다 빠르게 커진다. 약한 구조는 급격한 붕괴로 이어진다.
2. 기능만이 아닌 가드레일(안전장치)를 구축할 것 사람과 머신 모두 안전하게 따를 수 있는 패턴을 정하라. 타입, 린터, 테스트 슈트, 스키마 등으로 올바른 동작을 강제할 뿐 아니라 의도를 커뮤니케이션하라.
자동화로 강제할 수 없는 행동은 명확하고 반복 가능한 구조로 강제하라. 라이브러리가 아니라 프레임워크를 만들어라.
3. 예시를 큐레이팅하라 AI 툴은 패턴 인식에 의존한다. 좋은 예시는 좋은 결과를 낳고, 나쁜 예시는 혼란을 증폭시킨다.
코드베이스가 학습 환경이 되었다. 스타일이 상충하는 코드를 제거하고, 의도가 중요할 땐 문서화하라. 트레이닝 데이터를 준비하는 마음으로 관리하라—실제로 그렇게 되는 것이다.
4. 리뷰 레이어를 소유하라 AI는 기능적 코드를 만들 수 있다. 아직 할 수 없는 것은 심도 있는 아키텍처적 선택이다.
그게 당신의 역할이다. 일관성, 품질 큐레이터가 되어라. 장기적 복잡성을 만들어내는 패턴을 찾고 제거하라. 단순히 버그만 검수하지 마라.
5. 천재 개발자가 되지 마라 최고로 똑똑한 사람은 문제를 가장 많이 해결하는 사람이 아니다—문제가 생기지 않게 하는 사람이다.
리더십은 개인의 노력 너머로 확장 가능한 시스템을 구축하는 것이다. 판단을 시스템에 녹여야 한다—머릿속에만 놔두지 말고 코딩하라.
다음 세대 개발자는 얼마나 빨리 코드를 배포할 수 있는지가 아니라, 얼마나 안전하고 지속 가능하며, 지능적으로 다른 사람들이 배포할 수 있도록 시스템을 만드는지가 기준이 된다.
요약(TL;DR)
앞으로의 소프트웨어 개발은 누가 가장 빨리 타이핑하는가로 정의되지 않는다. 그 경주는 이미 끝났고, 머신이 이겼다.
우리는 일자리를 잃은 게 아니다. 단지 역할이 바뀐 것이다.
향후 10년간 가장 가치있는 개발자는 바이브 코더가 아니라, 장기적인 시스템 디자이너—AI의 힘을 깨끗하게 harness(제어)하고, 명확함, 응집력, 방향성을 유지할 수 있는 아키텍트다.
출렁이는 추는 또 움직이고 있다. 과도한 문서화에서 “그냥 배포” 혼돈으로, 이제 새로운 중심—의도적 시스템 설계, 인간과 AI 협업 모두에 최적화된 방향으로—으로 가고 있다. 옛 방식으로 돌아가지 않는다. 더 정교하고, 더 강력한 방식으로 앞으로 나아간다. 통제력을 잃지 않고 확장할 수 있으니까.
이제도 속도는 중요하다. 하지만 방향이 더 중요하다. 구조가 더 중요하다. 원칙이 더 중요하다.
그러니—빠르게 배포하라. 그러나 똑똑하게 배포하고, 지속적으로 남을 시스템을 구축하라. 다음 세대의 개발자는 인턴이나 동료가 아니라, 당신의 리드를 따라 최선을 다하는 지능형 머신이다.
앞으로의 소프트웨어는 더 이상 '쓰기'만 하는 것이 아니다. '설계'하는 것이다.