AI 시대에 익스트림 프로그래밍(XP)을 다시 돌아봐야 할까?
(hyperact.co.uk)- AI 코드 생성과 플랫폼 혁신 덕분에 개발 속도는 폭발적으로 증가했지만, 여전히 프로젝트 성과는 저조하고 실패율이 높음
- 문제는 속도가 아니라 검증과 정렬의 부재이며, XP는 의도적 제약을 통해 학습·정렬·품질 향상을 유도함
- 특히 AI 에이전트가 코드 생성·수정·배포를 가속화할수록, 검증 없는 복잡성 증가와 취약성이 심각해짐
- XP는 단순성, 의사소통, 피드백, 존중, 용기 같은 인간 중심 가치와 작은 배치·지속적 통합·자동화 테스트를 강조함
- 빠른 출력이 당연해진 시대에, XP는 소프트웨어는 결국 사람을 위한 것이라는 원칙을 다시 상기시키는 방법론임
소프트웨어 생산 속도의 가속과 한계
- 최근 AI 도구와 다양한 개발 플랫폼의 혁신으로 코드 생성의 장벽이 매우 낮아지고 속도가 크게 향상됨
- 몇 번의 프롬프트나 API 호출만으로 제품·기능·인프라 전체가 빠르게 생성
- 그러나 높아진 생산성에도 불구하고 전체 프로젝트 성공률은 현저히 개선되지 않는 문제가 있음
- IT 프로젝트 대부분이 실패하거나 예산 초과로 이어지는 사례가 여전히 빈번하다고 Standish Chaos 보고서 및 McKinsey 리포트 등에서 지적
- 단순 코드 생성 속도가 개선된다고 해서 소프트웨어 제공 성과가 자동으로 올라가지 않는 현상 확인
출력(output)이 진짜 문제가 아닌 이유
- 소프트웨어 개발의 병목이 코드 입력·출력 속도가 아님을 반복적으로 증명
- 고수준 언어 도입, 프레임워크와 패키지 매니저 대중화, DevOps·서버리스 확대, 개발 플랫폼 발전, 그리고 AI 코드 생성 등 연이은 가속화 물결 존재
- Chaos 리포트에 따르면 출력 가속에도 불구하고 최종 결과는 일관성 없고 기대 미달되는 문제 지속
- 단순 가속화의 해답이 아닌, 더 똑똑한 ‘제약’이 중요함을 강조
- XP는 서두르지 않고 학습, 정렬, 의도 있는 개발을 통해 올바른 방향을 유도하는 실천법임
XP의 역할: 속도에 대한 카운터웨이트
- 무제한적인 가속은 학습, 실수 발견, 방향 수정의 기회를 박탈하는 문제 유발
- 익스트림 프로그래밍(XP)은 의도적 마찰·제약을 도입해 팀이 올바른 방향으로 움직이도록 설계
- 대표적 실천: 페어 프로그래밍은 일부러 산출량을 절반으로 줄임
- 페어 프로그래밍은 산출물은 절반으로 줄일 수 있지만 공유 이해도, 신뢰, 품질, 팀 내 역량 향상 등 긍정적 효과 두 배로 제공
- XP는 협업 방식 자체를 바꾸고, 팀 역량 강화와 방향성 제공에 투자
AI와 함께 더 심화되는 XP의 문제 인식
- AI가 코드 생성을 무 effort로 만들어줌에 따라, 제대로 검증되지 않은 소프트웨어의 대량 생산 위험이 커짐
- 특히 복수의 에이전트가 코드를 자동 생성·개선·배포하는 agentic AI 시스템에서 리스크가 급격히 커짐
- 제약 없는 자동화 시스템이 미검증 로직을 다층적으로 쌓아 복잡성과 취약성 악화
- 최근 연구에선 LLM의 컨텍스트 창이 길어질수록 정확도가 악화됨을 증명
- 처음과 끝은 잘 처리하지만 중간은 오히려 일반화·오류에 취약
- 결과적으로 유지보수 비용이 높고 쉽게 깨지는 코드로 이어지며, XP는 이러한 무질서한 엔트로피를 방지하기 위해 태동
소프트웨어는 여전히 사람의 영역
- AI가 발전해도 소프트웨어는 사람이 사람을 위해, 조직 내 소통과 문화 속에서 만드는 본질 변하지 않음
- 주요한 전달 장애 요소는 자동화도가 아니라 정렬, 공유 맥락, 명확한 결과, 사용자 검증 등 인간 기반 요소임
- XP의 핵심 가치:
- Simplicity: 복잡성 감소
- Communication: 팀 결속 유지
- Feedback: 학습 및 적응 주도
- Respect: 신뢰와 안전 구축
- Courage: 투명성과 변화 가능성 지원
기능공장(feature factory)에서 진짜 가치 전달로
- 성공적인 팀은 속도 그 자체보다 흐름(flow)과 피드백 우선
- XP의 소규모 배치, 지속적 통합, 자동 테스트, 공동 소유 등 실천이 적응성과 사용자 중심성에 기여
- 앞으로 코드 생산이 더 빨라질수록 이러한 방법들이 품질, 리스크, 의도 관리에 필수적
과거의 교훈
- CHAOS 보고서 통계:
- 1994년: 정시에 예산 내로 성공한 프로젝트 16%
- 2012년: 37%로 개선
- 2020년: 다시 31%로 하락
- 20년 넘는 혁신과 변화(agile, DevOps, 클라우드 네이티브, AI 등) 이후에도 전반적 신뢰도는 단 14%포인트 상승
- 툴체인만으로는 문제 해결 불가
- 올바른 방법론의 중요성 재확인
앞으로 무엇이 필요한가
- 1. 출력이 더는 제약이 아님: 코드 생산력은 검증·정렬 속도를 앞지름
- 2. 성과 중심 역량 강화: 피드백, 명확한 제품 방향, 강한 협업, 우수한 설계 등이 필수
- 3. 더 인간적인 프로세스 필요: AI가 발전해도 지속적 전달은 협업에 의존
- 실제로 효과적인 Product Operating Model은 사람—협업, 명확성, 흐름—중심의 운영에서 나온다는 점 강조
- 기술적 혁신(플랫폼)보다 팀 전략, 운영 리듬, 엔지니어링 관행을 빈틈없이 정렬할 때, AI 시대의 지속가능한 소프트웨어 제공 환경 구성 가능
결론: AI 시대, XP는 필요한가?
- 그렇다
- 더 강력해지는 도구 속에서 사람-중심적 실천을 고정시켜줄 프레임워크 필요
- XP는 팀 중심, 공감능력, 공유 이해, 올바른 목표 지향을 동시에 제공
- 단순 출력 속도가 아닌 의미 있는 방향성과 팀 내 정렬에 집중
- AI의 가속과 제한 없는 생산 시대에, XP는 소프트웨어는 사람의 일임을 상기시켜주는 드문 방법론임
Hacker News 의견
-
Kent Beck(Extreme Programming의 창시자)이 AI 코딩과 관련해 다양한 실험을 하고 있음
Augmented Coding Beyond the Vibes와 같은 글에서 AI가 프로그래밍에 어떻게 활용될 수 있는지 고민하는 중임
ChatGPT가 코딩에 유용하게 쓰이기 시작할 때, 자신의 기술 90%가 이제는 쓸모없어졌고 나머지 10%는 그만큼 더 가치 있게 되었다고 말했던 기억이 있음
90% of my skills are now worth 0 -
XP만이 진짜 애자일 방법론이라고 생각함
애자일은 시간이 지날수록 의미 없이 변질되어버림
AI 프로그래밍은 피드백 루프를 빠르게 닫아주는 역할을 해주지만, 모든 코드에 방대한 단위 테스트가 필요하다고 생각하지는 않음
사람들이 XP의 핵심(나에게는 피드백 루프임)을 다시 이해하고, LLM 기반 에이전트 시스템을 통해 더 타이트하게 피드백 루프를 만드는 게 가능하다면, 소프트웨어 엔지니어링에 큰 발전이 될 것 같음-
XP로 시작해서 XP를 집요하게 실천한 경험이 있어서, 이제는 SCRUM 스타일의 조직에서는 일하기 힘듦
SCRUM은 주로 XP에서 유래했으나 이제는 의미 없는 관행만 남아있는 느낌임 -
이상적인 시나리오는 두 명의 개발자가 같은 브랜치에서 AI 에이전트들과 함께 페어 프로그래밍을 하는 것이라고 생각함
페어 플래닝, 리뷰, 개발, 테스트가 자연스럽게 반복되는 이상적인 피드백 루프임 -
XP 시대의 단위 테스트와 지금의 테스트는 차이가 있음
그땐 기능 단위 테스트였고, 메서드별 테스트가 아니었음 -
AI가 피드백 루프를 얼마나 정확하게 닫아줄 수 있는지에 따라 달라짐을 느낌
-
코드 절반을 사용자에게 전달(=프로덕션에 전달)하지 않는 것은 애자일이 아니라고 생각함
-
-
우리 팀은 전원이 ex-Pivots와 Thoughtworks 출신으로 구성됨
페어 프로그래밍, TDD, 고객 상주가 기본임
IDE에서 AI도 2년 넘게 적극 활용 중임
그런데 올해 놀랍게도, 'AI와 각자 분리해서 일하는' 형태가 아니라 오히려 전원(4명)이 한 프로젝트에서 싱크 맞춰 한 가지 일에 몰입하는 '모빙(mobbing)'을 하기 시작함
Claude Code가 타이핑을 도와주면서, 네 명이 동시에 실시간으로 협력함
XP와 AI가 절묘하게 결합된 가장 재미있고, 집중도 높고, 효과적인 경험이었음- 이런 협업을 쉽게 만들어주는 도구로 무엇을 쓰는지 궁금하다는 질문을 받음
-
XP를 완전히 잊고 있었음
일부는 요즘 일상화되었고, 나머지 부분들은 지금 기준에선 엄청나게 낯설게 여겨질 듯함- 실제로 XP의 많은 부분이 현대 워크플로에 통합된 것 같음(더 잘 됨)
특히 LLM을 써서 별 생각 없이 1000줄 넘는 코드를 내보내기 전에 반드시 한 번 생각해야 함을 강조하고 싶음
개인적으로 XP에서 가장 낯선 부분이 무엇이라 생각하는지 궁금함
- 실제로 XP의 많은 부분이 현대 워크플로에 통합된 것 같음(더 잘 됨)
-
모두가 AI와 페어 프로그래밍을 해야 한다는 의미로 받아들이면 안 됨
팀원과 페어 프로그래밍을 하면 서로의 사고방식과 코드의 맥락을 공유하게 됨
하지만 AI와 페어 프로그래밍을 하면, 프롬프트를 닫는 순간 AI는 모든 것을 잊어버림
그래서 여기서 논의 중인 XP는 1990년대처럼 여전히 '사람끼리' 하는 XP임
AI가 일부 들어갈 수 있지만 핵심은 사람이 중심임-
결과물을 명시적으로 남기지 않으면 그렇게 됨
문서가 충분히 없는 새로운 코드를 탐구할 때 LLM과 함께 학습한 내용을 문서나 에이전트 파일로 저장소에 남긴다면 의미 있을 수 있음 -
나는 오히려 AI와 페어 프로그래밍을 하지 않으면 잘못된 방식으로 하고 있다고 생각함
사실 사람들끼리 페어 프로그래밍을 해도, 미래의 나는 지금의 기억을 다 잊어버리는 경우가 많음
문서화에 초점을 맞춘 페어로 가야 함
요약하자면 LLM과 함께 XP 페어 프로그래밍을 반드시 실천해야 함
-
-
Extreme Vibing(XV) 강좌를 팔려는 사람도 분명 있을 것 같음
- 그것이야말로 onlyfans가 추구하는 바임
-
Extreme Programming은 여러 독립적으로 쓸 만한 개념(예: TDD, 페어 프로그래밍, CI, 피드백)을 한데 묶은 패러다임임
각각은 상황에 따라 유용하지만, 모든 부분을 항상 동시에 쓸 필요는 없다고 생각함
이런 맥락 때문에 XP가 하나의 완성된 개념으로서 힘을 잃는다고 봄
오늘날 대부분의 팀은 XP의 일부만 실천 중이고, 거의 모든 조직은 진짜 XP 전체를 적용하지는 않음
애자일의 경우, 대기업들이 대부분 90% 이상의 관행을 70% 정도 충실하게 구현하는 편임
실제로는 애자일 매니페스토에서 설명하는 방식을 100%로 구현하는 회사는 단 한 곳도 없었고, 가장 잘 지켰던 곳도 90% 정도였음
하지만 핵심 관행이 모두 하나의 패러다임에 묶여있다 보니, 조직들은 스스로를 '애자일'이라 부르기 쉬웠음
그래서 단순히 “애자일로 전환한다"고 선언하는 게 훨씬 쉬워진 것임-
XP 책이 철학적, 원칙, 실천단계로 구분되는 이유가 여기 있음
해당 책에서 가장 인상적인 문장은 실천 없는 가치는 죽은 것이며, 가치 없는 실천 또한 공허하다는 점임
결국 베스트 프랙티스보다는 팀에게 주도권을 주고, 스스로 프로세스를 정해서 잘 설계된 신뢰할 만한 소프트웨어를 만들어내는 것이 궁극적인 목적임
XP가 다소 '잡다한 툴킷'처럼 보이는 것도 실제로 그런 능동적인 팀이 골라 쓰는 것들이기 때문임 -
나는 실제로 위에서 언급한 실천(TDD, 페어 프로그래밍, CI, 피드백)을 프로덕션 코드에서는 항상 하고 있음(여건이 된다면)
어떤 상황에서 이런 실천이 '잘못됐다'고 볼 수 있는지 궁금함 -
90년대의 강박적 애자일을 거쳐서 여기까지 상당히 발전했다고 생각함
지금은 AI가 적용된 워크플로가 많아져서, 그저 결과물의 양만 늘리는 방식이 아니라 진짜 유저의 결과 확률을 높이는 방향으로 소프트웨어 프로세스를 들여다볼 필요가 있다는 점에 더 집중해야 함
XP가 그 출발점으론 좋다고 생각함(꼭 끝은 아님)
-
-
Extreme Programming(XP)은 짧은 반복, 빠른 피드백, 단순한 설계에 초점을 두고 페어 프로그래밍, TDD, CI같은 실천을 기반으로 변화에 빠르게 적응하는 애자일 방법론임
최대한 작게, 빠르게 만들어서 고객과 함께 반복하는 학습과 품질 최적화를 우선시함
~ GPT5 in perplexity -
요즘 AI와 함께 워터폴이 다시 부상하는 것 같다는 생각을 함
-
원래 워터폴은 사라진 적도 없었음
-
워터폴이 돌아온 건 유감스러운 일임
워터폴은 대부분의 경우에 옳지 않은 접근임
-
-
전 Pivot 출신 & XP에 열광하는 나로선 동의함
- 뉴욕 Pivot임
아래 내 댓글도 참고 바람
아직도 XP를 실천하고 있음
- 뉴욕 Pivot임