애자일은 부족한 설계의 변명이다

작성일: 2025/10/15

안녕하세요! 일단은 제목 어그로를 좀 끌어봤습니다.

1세미나 때도 객체지향을 소개하면서 애자일에 대한 작은 소개를 들었는데요. 저는 애자일이란 단어을 듣고 pm분이 유튜브에서 애자일에 대해 비판하던 영상이 떠오르더라고요.

이번 아티클에서는 좀 더 깊게 애자일이 무엇인지, 애자일은 꼭 좋기만 한 것인지에 대한 내용을 다루려고 합니다!

애자일이란?

애자일의 탄생

전통적인 폭포수 모델(Waterfall)은 프로젝트 초기에 모든 것을 계획하고 설계 → 개발 → 테스트 순으로 진행했습니다. 문제는 시장이 빠르게 변하는데 이 방식은 너무 경직되어 있었다는 것입니다.

2001년, 17명의 개발자들이 모여 '애자일 선언문'을 발표했습니다.

https://agilealliance.org/agile101/the-agile-manifesto/

애자일의 4가지 핵심 가치

이것보다는 이것을

프로세스와 도구	개인과 상호작용
포괄적인 문서화	작동하는 소프트웨어
계약 협상	고객과의 협업
계획 따르기	변화에 대응

여기서 중요한 점은, 우측 항목이 더 중요하다는 것이지 좌측 항목이 필요 없다는 게 아닙니다.

가장 중요한 원칙

"기술적 탁월성과 좋은 설계에 대한 지속적 관심이 민첩성을 높인다"

애자일은 빠르게 개발하는 게 아니라, 변화에 유연하게 대응할 수 있는 기반을 만드는 것입니다.

2. 왜 사람들은 애자일에 열광할까요?

애자일의 장점

빠른 피드백 2-4주 단위로 결과물을 만들고 사용자 반응을 확인, 6개월 뒤에 "이거 아닌데..."라고 깨닫는 것보다 훨씬 빠르다.

고객 중심 고객이 원하는 것을 추측하지 않고 지속적으로 소통하며 개발

팀 협업 기획자, 디자이너, 개발자가 따로 일하다 합치는 게 아니라 함께 문제를 해결

애자일의 한계와 단점

문화 충돌

애자일은 팀의 자율성을 강조합니다. 하지만 조직이 여전히 통제를 유지하려 하면 문제가 생깁니다.

"팀이 알아서 결정하세요" 하면서도 "왜 계획과 다르죠?"라고 물으면 애자일이 아닙니다.

확장의 어려움

10명 팀에서는 잘 돌아가던 애자일이 100명 조직으로 확장하면 복잡해집니다. 모든 팀이 같은 방식으로 일해야 할까요? 각자 다른 방식을 쓰면 협업은 어떻게 할까요?

정답은 없고 조직마다 적절한 균형점을 찾아야 합니다.

가짜 애자일

형식만 따르는 애자일

가장 흔한 문제입니다. 스프린트를 돌리고, 데일리 미팅을 하고, 회고를 하는데... 뭔가 이상합니다.

• 미팅은 문제 해결이 아닌 진행 보고가 됨
• "작동하는 소프트웨어"보다 "미팅 참석"이 더 중요
• 개선 방법을 논의하는 대신 계획 준수만 확인

겉으로는 애자일인데 실제로는 전통적인 방식 그대로입니다.

속도만 강조하는 애자일

"이번 스프린트에 기능 몇 개 넣었어요?" "벨로시티가 지난주보다 떨어졌는데요?"

품질이나 리팩토링은 "속도를 늦추는 것"으로 취급됩니다. 하지만 애자일 선언문은 분명히 말합니다:

"기술적 탁월성이 민첩성을 높인다"

기술 부채의 늪

기술 부채는 "지금 빠르게" 만들기 위해 치르는 미래의 비용입니다.

"일단 돌아가게 만들고 나중에 고치자"
→ "다음 스프린트에 리팩토링하자"
→ "다음 스프린트에는 새 기능이 급해서..."
→ (6개월 후) "아무도 이 코드를 못 건드려요"

단기 속도를 위해 품질을 희생하면 결국 시스템이 경직되어 변경이 불가능해집니다. 민첩성이 사라지는 거죠.

부채 종류 어떻게 생기나 무엇이 문제인가

코드 부채	중복 코드, 표준 무시	유지보수 지옥
설계 부채	확장성 고려 안 함	새 기능 추가 불가
테스트 부채	테스트 생략	수정할 때마다 불안
문서 부채	문서화 안 함	아무도 이해 못함

진짜 애자일로 가는 길

기술 부채 관리하기

기술 부채는 나쁜 게 아닙니다. 관리하지 않는 게 나쁜 겁니다.

• 리팩토링을 "나중에 할 일"이 아닌 "지속적인 활동"으로 인식
• 코드 리뷰 문화로 품질 표준 유지
• 가끔은 "이번 스프린트는 기술 부채 정리"도 필요

유연한 설계

애자일은 "설계하지 말자"가 아닙니다. "변경에 강한 설계"를 하자는 겁니다.

• 과도한 설계(오버 엔지니어링)도 문제
• 아예 설계 안 하는 것도 문제
• 적절한 균형: 지금 필요한 만큼만, 하지만 확장 가능하게

스프린트를 아무리 빠르게 돌려도 시스템 구조가 경직되어 있으면 의미가 없습니다.

개발자의 역할

"최고의 아키텍처는 자기 조직적인 팀에서 창발한다" -Agile 선언문 11번-

개발자는 코드만 작성하는 사람이 아닙니다. 설계 논의에 참여하고 기술적 의사결정을 하고 개선 방향을 제안하는 주체입니다.

맺음말

애자일은 빠른 개발이 아니라 유연한 대응입니다.

그 유연성의 토대는 기술적 품질입니다. 좋은 설계, 관리된 기술 부채 위에서만 진정한 민첩성이 가능합니다.

제목처럼 "애자일은 부족한 설계의 변명"이 되어서는 안 됩니다. 오히려 애자일은 더 나은 설계를 지속적으로 추구하는 과정입니다.

우리는 정말 진짜 애자일을 하고있을까요?

---

참고자료

https://youtu.be/pdZNjNTyr8Q?si=PHzKMv0YaEqfaOx-

https://www.redhat.com/ko/topics/devops/what-is-agile-methodology

https://learn.microsoft.com/ko-kr/devops/plan/what-is-agile

http://youtu.be/EuF4gWg7SG0?si=kr7_x_6LKYZYQkHw

https://www.youtube.com/watch?v=-dlDpyy6WhM

https://www.cio.com/article/3594947/칼럼-애자일-전환이-실패하는-이유-5가지.html

https://medium.com/@nightfog95/it-스타트업의-애자일은-왜-실패할까-b9c5231d19a9

애자일 실패 패턴

제목 어그로 아래 글에서 영감 받았습니다

https://www.reddit.com/r/SoftwareEngineering/comments/1jlthaq/agile_is_an_excuse_for_poor_planning/?tl=ko

아티클 편집 & 확장 : gemini & claude