#8 Before the Project
8장 프로젝트 전에
Topic 45. 요구 사항의 구렁텅이
요약
요구 사항 분석은 프로젝트 초기에 이루어지는 핵심 단계지만, 실제로는 모호함·오해·정치적 상황 등으로 인해 명확하지 않은 경우가 많다. 사람들은 자신이 무엇을 원한다고 생각하지만 실제로는 정확히 설명하지 못하고, 개발자는 이 모호한 상태에서 요구 사항을 해석해 해결해야 하는 상황에 놓인다. 이 과정은 단순한 문서 작성이 아니라, 이해 관계자와의 지속적인 대화·탐구·피드백을 통해 구체적인 문제를 발견하고 해결해 나가는 창의적 과정이다.
아래 내용은 책의 흐름에 맞추어 요구 사항 미신, 요구 사항을 발견하는 과정, 요구 사항 문서의 한계, 요구 사항은 계획을 위한 것, 지나치게 자세한 명세의 위험, 용어 사전의 중요성까지 체계적으로 정리한 글이다.
요구 사항의 구렁텅이란 무엇인가
많은 문헌과 튜토리얼은 프로젝트 초기에 ‘요구 사항 수집’이 이루어진다고 말한다. 그러나 현실에서는 요구 사항이 이미 완벽한 형태로 존재하는 경우는 드물다. 요구 사항을 마치 가을에 과일을 바구니에 담듯 수확할 수 있다고 생각하지만, 이는 잘못된 환상이다.
대부분의 경우 요구 사항은 처음부터 명확하게 존재하지 않으며, 오히려 오해와 조직 내부의 정치적 상황이 개입되어 더 모호하다. 심지어 요청자조차도 자신의 욕구를 정확히 이해하지 못한 경우도 많다.
요구 사항 미신
소프트웨어 산업 초기, 개발은 기계가 해야 할 일을 정확히 기술하고 설계 문서를 만들며 그 결과를 코딩하는 방식으로 진행되었다. 하지만 곧 사람들은 깨달았다. 사람들은 자신이 원하는 것을 정확히 이야기하지 못한다는 사실을.
초기 컴퓨터는 기능이 부족해 자연스럽게 자동화할 수 있는 범위가 좁았지만, 오늘날 시스템은 훨씬 복잡하다. 현실 세계는 훨씬 더 복잡하며 사람들이 원하는 바는 더 다양하고 미묘하다.
따라서 프로그래머의 역할은 단순한 해결사가 아니라, 사람들이 진짜 원하는 바를 계속해서 탐구하는 역할로 확장된다.
상업 치료로서의 프로그래밍
요청을 가져오는 사람은 ‘의뢰인’이다. 그러나 프로그래머가 해결해야 할 것은 의뢰인이 말한 표면적 요청이 아니라, 그 아래 숨어 있는 실제 문제이다.
의뢰인은 종종 다음과 같은 형태의 요청을 한다.
당장 발생한 문제 해결
기존 시스템 변경
새로운 기능 의뢰
그러나 많은 경우 이는 진짜 요구 사항이 아니다. 의뢰인의 말은 단지 상황의 단편적 표현이며, 그들이 왜 그런 요청을 하는지 를 개발자가 해석해야 한다.
요구 사항을 발견하는 과정
개발자는 의뢰인과 함께 요구 사항의 의미를 탐색해 나가야 한다. 예를 들어 어떤 온라인 상점에서 다음과 같은 요구 사항을 받았다고 하자.
5만 원 이상 모든 주문은 배송비가 무료입니다.
겉보기에는 단순한 문장이다. 그러나 실제로는 많은 질문이 생긴다.
5만 원은 세금 포함인가
고객이 선택한 배송 방식에 따라 달라지는가
국제 배송에도 적용되는가
디지털 상품에도 적용되는가
이처럼 요구 사항은 겉보기보다 훨씬 더 많은 해석과 상황 이해가 필요하다. 따라서 개발자는 의뢰인이 말한 문장의 숨은 의미를 분석하고, 구체적인 시나리오로 펼쳐 보이며, 다시 의뢰인과 대화해야 한다.
Tip 77: 요구 사항은 피드백을 반복하며 알게 된다.
좋은 개발자는 질문한다
개발자의 임무는 의뢰인이 제시한 문장을 맹목적으로 구현하는 것이 아니라, 문장의 의도를 분석해 본질적 문제를 해결하는 것이다.
의뢰인이 스스로 인지하지 못한 맥락
의사결정에 영향을 주는 조건
사용자 경험 관점의 고려 요소
이 모든 것을 함께 탐구해야 한다.
의뢰인의 예시 응답:
“아, 그건 제가 의도한 것이 아니네요.”
이 순간이 바로 요구 사항 탐색 과정이 시작되는 지점이다.
의뢰인의 입장에서 보라
의뢰인의 말에는 종종 감춰진 동기나 상황이 있다. 예를 들어 매장 직원이 사용하는 재고 시스템의 자동화가 불편해 보인다면, 실제로 그들이 원하는 것은 더 예측 가능한 사용 경험일 수 있다.
Tip 78: 사용자처럼 생각하기 위해 사용자와 함께 일하라.
요구 사항 대 정책
요구 사항과 정책은 다르다. 정책은 조직의 규칙이고, 요구 사항은 시스템이 충족해야 할 기대다. 예를 들어, “입사자의 기록을 인사팀만 열람할 수 있다”라는 정책이 있다고 가정해 보자. 이 정책을 시스템 요구 사항으로 착각하면, 개발자는 잘못된 기준으로 시스템을 구현하게 된다.
Tip 79: 정책은 메타데이터이다.
요구 사항 대 현실
실제 사례로 음악가 브라이언 이노의 믹싱 보드 이야기가 나온다. 음악가들은 더 많은 기능을 원한다고 말하지만, 실제로는 더 많은 기능이 창작 과정을 방해하기도 한다.
이노는 믹싱 콘솔에서 여러 기능을 제거하고 오히려 단순화된 시스템을 만들었다. 결과적으로 창조성은 더 크게 발휘되었다.
이는 소프트웨어 개발에서도 동일하다. 요구 사항이 많다고 해서 좋은 결과가 나오지 않는다.
요구 사항 문서는 의뢰인을 위한 것이 아니다
요구 사항 문서는 의뢰인이 원하는 것을 정리하는 문서가 아니다.
그 목적은 다음과 같다:
의뢰인의 발언을 바탕으로 함께 문제를 분석하기 위한 도구
개발자가 설계와 구현을 진행할 수 있도록 문제를 구조화하는 도구
따라서 요구 사항 문서를 그대로 시스템으로 구현하는 방식은 위험하다. 문서는 계획을 위한 것이며, 실제 개발 과정에서는 계속 변화한다.
요구 사항 문서는 계획을 위한 것이다
요구 사항 문서는 스토리 카드, 인덱스 카드, 화이트보드 등 다양한 형태가 가능하다. 현대 개발 방식에서는 한 번도 변하지 않는 완전한 문서를 만드는 것이 목표가 아니다.
목표는 다음에 있다:
팀이 동일한 이해를 공유할 것
우선순위를 정할 것
의사결정을 돕는 정보 구조를 마련할 것
지나치게 자세한 명세의 위험
요구 사항 문서를 만들다가 발생하는 큰 문제 중 하나는 지나치게 자세히 작성하는 것이다. 요구 사항은 기술적 명령이 아니라, 해결해야 할 사용자 요구의 표현이어야 한다.
책의 표현을 빌리면,
“좋은 요구 사항은 추상적이다.”
지나친 상세화는 오히려 창의성을 방해하고, 설계 옵션을 제한하며, 개발자에게 불필요한 제약만 남긴다.
용어 사전 관리하기
요구 사항에서 가장 자주 발생하는 오해 중 하나는 동일한 단어가 다른 의미로 사용되는 경우이다.
예를 들어 “고객”이라는 용어가
영업팀,
개발팀,
지원팀
각각에게 다른 의미를 갖는다면 프로젝트는 혼란에 빠진다.
Tip 80: 프로젝트 용어 사전을 사용하라.
마무리
요구 사항 분석은 수집 작업이 아니라 창의적 탐구 과정이다. 의뢰인의 말 속에 숨어 있는 의도와 문제를 발견하고, 이를 반복적인 피드백을 통해 구체화하는 것이 개발자의 역할이다. 요구 사항 문서는 절대 완성품이 아니며, 설계와 대화의 기반일 뿐이다. 따라서 좋은 개발자는 문장을 그대로 구현하는 것이 아니라, 그 너머에 있는 진짜 의미를 찾아가는 사람이다.
Topic 46. 불가능한 퍼즐 풀기
요약
개발 과정에는 겉보기엔 너무 어려워 보이거나 도저히 해결할 수 없다고 느껴지는 문제가 자주 등장한다. 그러나 많은 경우 문제의 난이도는 ‘문제 자체’가 아니라 우리가 붙잡고 있는 잘못된 전제나 규칙 때문에 발생한다. 문제를 풀기 위해 필요한 것은 기발한 해법이 아니라, 제약 조건을 의심하고, 본질적 제약과 잘못된 제약을 구분하며, 문제를 바라보는 방식을 바꾸는 능력이다. 이 글은 고르디우스의 매듭 이야기, 실제 퍼즐 사례, 자유도 확장, 자신만의 방법에 사로잡히는 위험 등을 통해 문제 해결의 핵심을 설명한다.
고르디우스의 매듭과 잘못된 해석
그리스 신화의 ‘고르디우스의 매듭’은 누구도 풀 수 없는 난제였다. 그러나 알렉산더 대왕은 매듭을 칼로 끊어 버렸다. 이 사건의 핵심은 “문제에 대한 해석을 달리하면 해결이 가능하다”는 점이다.
문제 해결에서 중요한 것은 문제를 정확히 이해하고 있는가, 우리가 스스로 만든 제약에 갇혀 있지 않은가를 점검하는 일이다.
어려운 퍼즐은 실제로도 정말 어려운가
프로젝트에서는 복잡한 퍼즐 같은 문제가 종종 등장한다.
엔지니어링적으로 난해한 문제
이상하게 작성된 코드
해결 방법이 도저히 떠오르지 않는 난제
그러나 많은 경우 이 난제는 실제로 어려워서가 아니라 잘못된 조건을 붙잡고 있기 때문이다.
잘못된 조건을 버리기
성탄절 선물이나 장난감 조립 설명서를 떠올려보자. 사람들은 그림을 보고 그대로 따라 하려고 애쓰지만, 그 그림이 실제 조건을 정확히 반영하지 않는 경우도 많다.
문제를 푸는 핵심은 ‘보이는 조건’이 아니라 ‘실제 조건’을 파악하는 일이다.
어떤 조건은 단순한 지레짐작에 불과하며, 절대적 조건처럼 보이는 것들도 사실은 문제 해결에 전혀 필요하지 않을 수 있다. 알렉산더의 매듭도 마찬가지였다. 그는 ‘매듭을 풀라’는 지시를 ‘매듭을 없애라’는 다른 방식으로 해석했고, 문제는 즉시 해결되었다.
Tip 81: 생각의 틀을 벗어나지 말고, 틀을 찾아라.
자유도: 해결을 가로막는 보이지 않는 벽
문제를 풀기 어렵게 만드는 가장 흔한 이유는 ‘자유도(freedom degree)’가 부족한 것이다.
문제를 풀기 위해 주어진 조건을 그대로 사실로 받아들인다
특정 동작 방식만 가능하다고 가정한다
한 가지 방법이 실패하면 전체가 막힌다고 생각한다
그러나 문제 해결에서 중요한 것은 그 조건이 진짜 제약인지, 우리가 만들어낸 가짜 제약인지를 구분하는 일이다.
예를 들어 GUI 애플리케이션의 모달 창에서 기존 창 접근이 불가능하다고 생각해버리면 해법이 막힌다. 하지만 이는 많은 경우 기술적 제한이 아니라 설계상의 선택일 뿐이다.
자신만의 방법에 빠져 나오라
문제를 해결하지 못할 때 사람들은 종종 다음과 같은 오류에 빠진다.
지금의 접근 방식이 틀릴 수 있다는 생각을 하지 않는다
더 쉬운 방법이 있을 가능성을 고려하지 않는다
기존 해결 경험 때문에 문제를 새로운 방식으로 보지 못한다
문제 해결에서는 때때로 잠시 멈추고 문제를 내려놓는 판단도 필요하다. 산책하거나 다른 일을 하다 보면 무의식이 문제 해결을 돕는 경우도 많다.
의식적 노력보다 무의식의 힘
문체심리학 연구에 따르면, 문제를 지나치게 의식적으로 붙잡는 것보다 잠시 놓았다가 무의식이 연결을 형성하도록 두는 것이 더 효과적일 때가 많다.
의식은 좁고 논리적이지만
무의식은 폭넓게 패턴을 연결하며
해결의 실마리를 떠올릴 확률을 높인다
결국 자연스럽게 깨닫게 되는 경우가 많으며, 이것이 ‘유레카’ 순간이다.
해결 경로를 열어 주는 질문들
문제가 막혔다면, 다음 질문을 스스로에게 던져보아야 한다.
***- 왜 이 문제를 풀고 있는가?
문제를 풀어서 얻는 가치는 무엇인가?
굳이 이 문제를 지금 풀어야 하는가?
더 단순한 문제부터 풀 수는 없는가?
관련된 문제 중 더 해결하기 쉬운 것은 없는가?
실제로 존재하지 않는 제약을 적용하고 있지는 않은가?***
이 질문들은 불필요한 제약을 걷어내고 문제 해결의 새로운 방향을 열어 준다.
행운은 준비된 사람에게 찾아온다
루이 파스퇴르는 “우연은 준비된 사람에게 찾아온다”라고 말했다. 문제를 해결하기 위한 원리는 다음과 같다.
경험을 통해 얻은 직관을 존중하라
일상적인 작업 속에서 ‘이상한 점’을 발견하라
기록을 통해 반복 패턴을 찾아라
잘못된 가정, 잘못된 제약을 명확히 제거하라
이 과정이 바로 문제 해결 능력을 키우는 핵심이다.
Topic 47. 함께 일하기
요약
이 챕터는 “불가능해 보이는 프로젝트”를 해결하기 위해 사람들이 함께 일하는 방식 자체를 재설계해야 한다는 메시지를 전달합니다. 단순히 협업하자는 말이 아니라, 실제 코드를 함께 보는 방식(Pair Programming, Mob Programming), 의사결정 구조, 팀의 소통 패턴 등 전반적인 협업 메커니즘을 바꾸어야 한다는 점을 강조합니다.
특히 다음과 같은 통찰을 제공합니다:
복잡하고 위험한 프로젝트일수록 더 많이 함께해야 한다.
함께 일한다는 것은 회의를 더 하는 것이 아니라 실제 코드를 함께 작성하고 판단하는 것이다.
관점 공유, 책임 공유, 배움 공유는 장기적으로 생산성과 품질을 높인다.
이제 챕터의 세부 내용을 블로그 형식으로 정리합니다.
프로젝트의 시작: “불가능한 프로젝트”
저자들은 수명이 다해가는 시스템, 문서화되지 않은 기능, 하드웨어 폐기 등 혼란스러운 환경에서 새로운 시스템을 ‘정확하게 똑같이’ 재구현해야 하는 프로젝트에 투입됩니다.
이는 다른 사람들의 생계가 걸린 시스템을 고쳐야 하는 일이었고, 운영 중단 시간을 월 단위로 계산해야 할 만큼 부담이 매우 큰 일이었습니다.
사용자와 함께, 그리고 서로 함께 일하기
이 프로젝트에서 저자들은 사용자와 밀접하게 협력해야 했습니다. 이미 존재하는 기능을 새로운 시스템에서 재현해야 하기 때문에 사용자의 경험, 기억, 실제 행동을 함께 관찰하는 과정이 꼭 필요했습니다.
또한 개발자끼리는 짝 프로그래밍(pair programming) 또는 **몹 프로그래밍(mob programming)**을 통해 문제를 해결했습니다.
한 명 혹은 여러 명이 함께 코드를 보며 오류를 잡고
문제를 정의하고
테스트를 작성하며
다음 진행을 결정했습니다
이런 방식은 회의보다 효율적이고, 문서보다 유용했습니다.
짝 프로그래밍
짝 프로그래밍은 XP(eXtreme Programming)의 핵심 기법 중 하나이지만, 특정 방법론에 얽매이지 않아도 사용할 수 있는 유연한 실천법입니다. 핵심은:
두 사람이 한 키보드를 기준으로 함께 문제를 해결하는 것
서로 다른 배경, 관점, 경험이 결합되면서 더 나은 해결책을 만들 수 있음
문제의 집중도가 높아지고, 코드 품질이 자연스럽게 개선됨
실수를 줄이고, 설계 의도를 공유하게 되어 팀 전체의 개발 역량이 균일해짐
짝 프로그래밍의 중요한 특징:
서로의 스타일을 존중하면서 새로운 방법을 시도해야 한다
“틀렸다”고 비난하기보다 “이 부분을 이 방식으로 해보는 건 어떨까요?”가 더 효과적
여러 팀이 있다면 교차 짝 프로그래밍을 통해 팀 간 지식을 공유할 수 있다
몹 프로그래밍
몹 프로그래밍은 더 큰 규모의 협업 방식입니다. 여러 명이 한 문제에 동시에 몰입하여, 실시간으로 의견을 교환하며 빠르게 문제를 풀어냅니다.
테스트 작성, 사용자 인터뷰, 운영 환경 분석 등 개발 외적인 요소까지 합쳐 문제를 해결할 수 있음
복잡한 문제를 더 빠르게 분석하고 해결 가능
지식이 한 사람에게 집중되는 것을 방지하고 팀 전체로 확산시킴
저자들은 실제로 몹 프로그래밍을 통해 생각보다 작은 규모의 팀이지만 폭발적인 협력 효과를 경험했다고 말합니다.
짝 프로그래밍을 하고 있다면
한 번에 몇 시간을 넘어가는 긴 세션보다 2주간 여러 번 짧게 시도해 보라
새로운 아이디어를 테스트하거나 문제를 분석할 때 특히 효과적
서로의 관점, 스타일, 경험을 배우는 과정이 중요
몹 프로그래밍을 하고 있다면
처음에는 소규모(예: 3명 정도)로 시작
필요할 때 더 많은 사람을 초대
주어진 문제 외에도 배경, 사용자 경험, 운영 이슈 등 넓은 범위를 함께 살펴볼 수 있음
함께 일할 때 고려해야 할 점
코드 작성이 목표가 아니라 문제를 함께 해결하는 과정이 핵심
서로의 의견을 비난하지 말고 이해하려 노력
회고를 자주 하고, 다음 세션에서 개선점을 적용
혼자, 둘, 팀 전체 등 다양한 규모의 협업 방식을 시도해 보라
특히 까다로운 문제일수록 여러 명이 같이 해결하는 것이 효과적
Topic 48. 애자일의 핵심
요약
이 챕터는 애자일(Agile)의 본질이 **“어떤 명세나 절차가 아니라, 변화를 다루는 방식 그 자체”**라는 점을 강조합니다. 애자일은 특정 프레임워크(Scrum, XP 등)나 회의 방식이 아니라, 어떻게 일하고, 어떻게 반응하고, 어떻게 개선할 것인지에 대한 태도입니다.
핵심은 다음 세 가지입니다.
**애자일은 명사(형식)가 아니라 동사(행동 방식)**이다.
애자일 선언문에서 중요한 것은 왼쪽/오른쪽 항목의 단순 비교가 아니라 우선순위에 대한 관점이다.
애자일 방식의 목적은 팀이 불확실성 속에서 지속적으로 적응하고 학습하는 구조를 만드는 것이다.
이제 챕터의 내용을 블로그 문서 형식으로 상세히 정리합니다.
애자일이란 무엇인가
애자일은 ‘기민하게 움직인다’는 의미의 형용사에서 왔다. 다시 말해, 애자일은 무엇인가를 하는 방식이다. 특정 도구나 문서 템플릿을 가지고 있다고 해서 애자일 팀이 되는 것이 아니라, 문제를 어떻게 접근하고 해결하는지가 애자일의 실체다.
책에서는 다음과 같이 강조한다:
“애자일은 명사가 아니다. 애자일은 무언가를 하는 방식이다.”
즉, ‘애자일을 도입한다’가 아니라 ‘우리는 애자일하게 일한다’가 되어야 한다.
애자일 선언문이 말하는 가치
저자들은 애자일 선언문을 단순 텍스트가 아니라 20년의 실전 경험을 통해 정리된 핵심 원칙으로 소개한다.
대표적인 네 가지 가치는 다음과 같다:
공정과 도구보다 개인과 상호작용
포괄적인 문서보다 작동하는 소프트웨어
계약 협상보다 고객과의 협력
계획을 따르기보다 변화에 대응하기
왼쪽 항목도 모두 중요하지만, 오른쪽 항목에는 더 높은 가치가 있다는 점이 핵심이다.
애자일을 오해하는 사람들은 왼쪽 항목을 버리라고 생각한다. 하지만 실전에서 중요한 것은 둘 다 갖되, 어떤 상황에서 무엇을 우선순위로 둘 것인가를 판단하는 능력이다.
애자일 프로세스라는 것은 존재하지 않는다
정해진 애자일 절차는 없다. “이렇게 하면 애자일입니다”라는 말은 진실이 아니다. 실제 현장에서 애자일하게 일한다는 것은 다음과 같다:
변화가 생기면 즉시 대응
계획보다 현실의 흐름을 따름
고객의 요구 변화에 기민하게 반응
일의 방향을 주기적으로 재평가
애자일은 변화에 대응하는 행동 패턴의 총합이며, 어떤 회사, 어떤 팀, 어떤 바운더리에서도 일정한 형태가 존재할 수 없다.
우리는 무엇을 해야 하는가?
책은 “무엇을 하라”고 정답을 제시하지 않는다. 대신 올바른 사고방식을 갖추는 방법을 제안한다.
여러분이 해야 할 것
여러분이 어디에 있는지 알아라. 현재 상황, 경계, 위험 요소, 이해관계자, 제약을 명확히 파악해야 한다.
도달하고 싶은 목표를 향해 의미 있는 변화를 시도하라. 지금 가능한 가장 작은 개선을 선택하라.
어디에 도달했는지 평가하고, 목표를 향해 계속 반복하라. 즉, 애자일은 작은 단위의 실험과 피드백의 반복이다.
실전 예시: 피드백 고리(feedback loop)
애자일의 핵심 실천 중 하나는 지속적인 피드백이다. 책에서는 계좌(account)에 이메일 기능을 추가하는 예시 코드를 통해 설명한다.
아래는 책의 흐름과 의미를 유지하면서 Kotlin 스타일로 재구성한 코드 예시다.
Kotlin 예시
이 예시는 코드 계층과 책임 구조를 피드백을 통해 점진적으로 수정해가는 과정을 보여준다. 애자일은 이렇게 작은 실험 → 관찰 → 개선의 사이클을 빠르게 반복하는 것이다.
피드백 고리의 효과
피드백 고리는 특히 다음과 같은 경우에 집중적으로 사용된다:
요구사항이 계속 변하는 환경
고객이 즉시 응답하기 어려운 상황
초기 설계가 불완전하거나 불명확한 프로젝트
애자일 선언문이 중요한 이유는 피드백을 기반으로 한 빠른 학습 능력이 성공을 좌우하기 때문이다.
Last updated