> For the complete documentation index, see [llms.txt](https://wonjoon.gitbook.io/joons-til/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://wonjoon.gitbook.io/joons-til/books/the-pragmatic-programmer/8-before-the-project.md).

# #8 Before the Project

## Topic 45. 요구 사항의 구렁텅이

#### 요약

요구 사항 분석은 프로젝트 초기에 이루어지는 핵심 단계지만, 실제로는 모호함·오해·정치적 상황 등으로 인해 명확하지 않은 경우가 많다. 사람들은 자신이 무엇을 원한다고 생각하지만 실제로는 정확히 설명하지 못하고, 개발자는 이 모호한 상태에서 요구 사항을 해석해 해결해야 하는 상황에 놓인다. 이 과정은 단순한 문서 작성이 아니라, 이해 관계자와의 지속적인 대화·탐구·피드백을 통해 구체적인 문제를 발견하고 해결해 나가는 창의적 과정이다.

아래 내용은 책의 흐름에 맞추어 **요구 사항 미신**, **요구 사항을 발견하는 과정**, **요구 사항 문서의 한계**, **요구 사항은 계획을 위한 것**, **지나치게 자세한 명세의 위험**, **용어 사전의 중요성**까지 체계적으로 정리한 글이다.

***

#### 요구 사항의 구렁텅이란 무엇인가

많은 문헌과 튜토리얼은 프로젝트 초기에 ‘요구 사항 수집’이 이루어진다고 말한다. 그러나 현실에서는 ***요구 사항이 이미 완벽한 형태로 존재하는 경우는 드물다***. 요구 사항을 마치 가을에 과일을 바구니에 담듯 수확할 수 있다고 생각하지만, 이는 잘못된 환상이다.

대부분의 경우 요구 사항은 처음부터 명확하게 존재하지 않으며, 오히려 오해와 조직 내부의 정치적 상황이 개입되어 더 모호하다. 심지어 요청자조차도 자신의 욕구를 정확히 이해하지 못한 경우도 많다.

***

#### 요구 사항 미신

소프트웨어 산업 초기, 개발은 기계가 해야 할 일을 정확히 기술하고 설계 문서를 만들며 그 결과를 코딩하는 방식으로 진행되었다.\
하지만 곧 사람들은 깨달았다. **사람들은 자신이 원하는 것을 정확히 이야기하지 못한다**는 사실을.

초기 컴퓨터는 기능이 부족해 자연스럽게 자동화할 수 있는 범위가 좁았지만, 오늘날 시스템은 훨씬 복잡하다. 현실 세계는 훨씬 더 복잡하며 사람들이 원하는 바는 더 다양하고 미묘하다.

따라서 프로그래머의 역할은 단순한 해결사가 아니라, ***사람들이 진짜 원하는 바를 계속해서 탐구하는 역할***로 확장된다.

***

#### 상업 치료로서의 프로그래밍

요청을 가져오는 사람은 ‘의뢰인’이다. 그러나 프로그래머가 해결해야 할 것은 의뢰인이 말한 표면적 요청이 아니라, 그 아래 숨어 있는 **실제 문제**이다.

의뢰인은 종종 다음과 같은 형태의 요청을 한다.

* 당장 발생한 문제 해결
* 기존 시스템 변경
* 새로운 기능 의뢰

그러나 많은 경우 이는 진짜 요구 사항이 아니다. 의뢰인의 말은 단지 상황의 단편적 표현이며, ***그들이 왜 그런 요청을 하는지*** 를 개발자가 해석해야 한다.

***

#### 요구 사항을 발견하는 과정

개발자는 의뢰인과 함께 요구 사항의 의미를 탐색해 나가야 한다.\
예를 들어 어떤 온라인 상점에서 다음과 같은 요구 사항을 받았다고 하자.

> 5만 원 이상 모든 주문은 배송비가 무료입니다.

겉보기에는 단순한 문장이다. 그러나 실제로는 많은 질문이 생긴다.

* 5만 원은 세금 포함인가
* 고객이 선택한 배송 방식에 따라 달라지는가
* 국제 배송에도 적용되는가
* 디지털 상품에도 적용되는가

이처럼 ***요구 사항은 겉보기보다 훨씬 더 많은 해석과 상황 이해가 필요하다***.\
따라서 개발자는 의뢰인이 말한 문장의 숨은 의미를 분석하고, 구체적인 시나리오로 펼쳐 보이며, 다시 의뢰인과 대화해야 한다.

Tip 77: 요구 사항은 피드백을 반복하며 알게 된다.

***

#### 좋은 개발자는 질문한다

개발자의 임무는 의뢰인이 제시한 문장을 맹목적으로 구현하는 것이 아니라, ***문장의 의도를 분석해 본질적 문제를 해결하는 것***이다.

* 의뢰인이 스스로 인지하지 못한 맥락
* 의사결정에 영향을 주는 조건
* 사용자 경험 관점의 고려 요소

이 모든 것을 함께 탐구해야 한다.

의뢰인의 예시 응답:

> “아, 그건 제가 의도한 것이 아니네요.”

이 순간이 바로 요구 사항 탐색 과정이 시작되는 지점이다.

***

#### 의뢰인의 입장에서 보라

의뢰인의 말에는 종종 감춰진 동기나 상황이 있다.\
예를 들어 매장 직원이 사용하는 재고 시스템의 자동화가 불편해 보인다면, 실제로 그들이 원하는 것은 **더 예측 가능한 사용 경험**일 수 있다.

Tip 78: 사용자처럼 생각하기 위해 사용자와 함께 일하라.

***

#### 요구 사항 대 정책

요구 사항과 정책은 다르다. 정책은 조직의 규칙이고, 요구 사항은 시스템이 충족해야 할 기대다.\
예를 들어, “입사자의 기록을 인사팀만 열람할 수 있다”라는 정책이 있다고 가정해 보자.\
이 정책을 시스템 요구 사항으로 착각하면, 개발자는 잘못된 기준으로 시스템을 구현하게 된다.

Tip 79: 정책은 메타데이터이다.

***

#### 요구 사항 대 현실

실제 사례로 음악가 브라이언 이노의 믹싱 보드 이야기가 나온다.\
음악가들은 더 많은 기능을 원한다고 말하지만, 실제로는 더 많은 기능이 창작 과정을 방해하기도 한다.

이노는 믹싱 콘솔에서 여러 기능을 제거하고 오히려 단순화된 시스템을 만들었다.\
결과적으로 창조성은 더 크게 발휘되었다.

이는 소프트웨어 개발에서도 동일하다. **요구 사항이 많다고 해서 좋은 결과가 나오지 않는다.**

***

#### 요구 사항 문서는 의뢰인을 위한 것이 아니다

요구 사항 문서는 의뢰인이 원하는 것을 정리하는 문서가 아니다.

그 목적은 다음과 같다:

1. ***의뢰인의 발언을 바탕으로 함께 문제를 분석하기 위한 도구***
2. 개발자가 설계와 구현을 진행할 수 있도록 ***문제를 구조화하는 도구***

따라서 요구 사항 문서를 그대로 시스템으로 구현하는 방식은 위험하다.\
문서는 계획을 위한 것이며, 실제 개발 과정에서는 계속 변화한다.

***

#### 요구 사항 문서는 계획을 위한 것이다

요구 사항 문서는 스토리 카드, 인덱스 카드, 화이트보드 등 다양한 형태가 가능하다.\
현대 개발 방식에서는 ***한 번도 변하지 않는 완전한 문서***를 만드는 것이 목표가 아니다.

목표는 다음에 있다:

* 팀이 동일한 이해를 공유할 것
* 우선순위를 정할 것
* 의사결정을 돕는 정보 구조를 마련할 것

***

#### 지나치게 자세한 명세의 위험

요구 사항 문서를 만들다가 발생하는 큰 문제 중 하나는 ***지나치게 자세히 작성하는 것***이다.\
요구 사항은 기술적 명령이 아니라, 해결해야 할 사용자 요구의 표현이어야 한다.

책의 표현을 빌리면,

> “좋은 요구 사항은 추상적이다.”

지나친 상세화는 오히려 창의성을 방해하고, 설계 옵션을 제한하며, 개발자에게 불필요한 제약만 남긴다.

***

#### 용어 사전 관리하기

요구 사항에서 가장 자주 발생하는 오해 중 하나는 **동일한 단어가 다른 의미로 사용되는 경우**이다.

예를 들어 “고객”이라는 용어가

* 영업팀,
* 개발팀,
* 지원팀

각각에게 다른 의미를 갖는다면 프로젝트는 혼란에 빠진다.

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 등)나 회의 방식이 아니라, **어떻게 일하고, 어떻게 반응하고, 어떻게 개선할 것인지에 대한 태도**입니다.

핵심은 다음 세 가지입니다.

1. \*\*애자일은 명사(형식)가 아니라 동사(행동 방식)\*\*이다.
2. 애자일 선언문에서 중요한 것은 왼쪽/오른쪽 항목의 단순 비교가 아니라 **우선순위에 대한 관점**이다.
3. 애자일 방식의 목적은 팀이 불확실성 속에서 **지속적으로 적응하고 학습하는 구조를 만드는 것**이다.

이제 챕터의 내용을 블로그 문서 형식으로 상세히 정리합니다.

***

#### 애자일이란 무엇인가

애자일은 ‘기민하게 움직인다’는 의미의 형용사에서 왔다. 다시 말해, **애자일은 무엇인가를 하는 방식**이다. 특정 도구나 문서 템플릿을 가지고 있다고 해서 애자일 팀이 되는 것이 아니라, **문제를 어떻게 접근하고 해결하는지**가 애자일의 실체다.

책에서는 다음과 같이 강조한다:

> “애자일은 명사가 아니다. 애자일은 무언가를 하는 방식이다.”

즉, ‘애자일을 도입한다’가 아니라 ‘우리는 애자일하게 일한다’가 되어야 한다.

***

#### 애자일 선언문이 말하는 가치

저자들은 애자일 선언문을 단순 텍스트가 아니라 **20년의 실전 경험을 통해 정리된 핵심 원칙**으로 소개한다.

대표적인 네 가지 가치는 다음과 같다:

* **공정과 도구보다 개인과 상호작용**
* **포괄적인 문서보다 작동하는 소프트웨어**
* **계약 협상보다 고객과의 협력**
* **계획을 따르기보다 변화에 대응하기**

왼쪽 항목도 모두 중요하지만, 오른쪽 항목에는 **더 높은 가치가 있다**는 점이 핵심이다.

애자일을 오해하는 사람들은 왼쪽 항목을 버리라고 생각한다. 하지만 실전에서 중요한 것은 둘 다 갖되, **어떤 상황에서 무엇을 우선순위로 둘 것인가**를 판단하는 능력이다.

***

#### 애자일 프로세스라는 것은 존재하지 않는다

정해진 애자일 절차는 없다. “이렇게 하면 애자일입니다”라는 말은 진실이 아니다. 실제 현장에서 애자일하게 일한다는 것은 다음과 같다:

* 변화가 생기면 즉시 대응
* 계획보다 현실의 흐름을 따름
* 고객의 요구 변화에 기민하게 반응
* 일의 방향을 주기적으로 재평가

애자일은 **변화에 대응하는 행동 패턴의 총합**이며, 어떤 회사, 어떤 팀, 어떤 바운더리에서도 일정한 형태가 존재할 수 없다.

***

#### 우리는 무엇을 해야 하는가?

책은 “무엇을 하라”고 정답을 제시하지 않는다. 대신 **올바른 사고방식**을 갖추는 방법을 제안한다.

#### 여러분이 해야 할 것

1. **여러분이 어디에 있는지 알아라.**\
   현재 상황, 경계, 위험 요소, 이해관계자, 제약을 명확히 파악해야 한다.
2. **도달하고 싶은 목표를 향해 의미 있는 변화를 시도하라.**\
   지금 가능한 가장 작은 개선을 선택하라.
3. **어디에 도달했는지 평가하고, 목표를 향해 계속 반복하라.**\
   즉, 애자일은 작은 단위의 실험과 피드백의 반복이다.

***

#### 실전 예시: 피드백 고리(feedback loop)

애자일의 핵심 실천 중 하나는 **지속적인 피드백**이다. 책에서는 계좌(account)에 이메일 기능을 추가하는 예시 코드를 통해 설명한다.

아래는 책의 흐름과 의미를 유지하면서 **Kotlin 스타일로 재구성한 코드 예시**다.

**Kotlin 예시**

```kotlin
// 계좌 주인 정보를 가져오는 함수
fun accountOwner(accountId: String): User {
    // 실제 구현은 데이터베이스 조회라고 가정
    return findUserByAccountId(accountId)
}

// 이메일 객체 생성
fun emailOfAccountOwner(accountId: String): Email {
    val owner = accountOwner(accountId)
    return Email(owner.emailAddress)
}

// 피드백 고리에 따라 이름 변경, 책임 이동 등을 단계적으로 개선해 나가는 방식
fun processAccountEmail(accountId: String) {
    val owner = accountOwner(accountId)
    val email = emailOfAccountOwner(accountId)

    // 다음 단계에서 실제 이메일 발송 로직이 다듬어진다고 가정
    sendEmailToOwner(owner, email)
}
```

이 예시는 코드 계층과 책임 구조를 **피드백을 통해 점진적으로 수정해가는 과정**을 보여준다.\
애자일은 이렇게 **작은 실험 → 관찰 → 개선**의 사이클을 빠르게 반복하는 것이다.

***

#### 피드백 고리의 효과

피드백 고리는 특히 다음과 같은 경우에 집중적으로 사용된다:

* 요구사항이 계속 변하는 환경
* 고객이 즉시 응답하기 어려운 상황
* 초기 설계가 불완전하거나 불명확한 프로젝트

애자일 선언문이 중요한 이유는 **피드백을 기반으로 한 빠른 학습 능력**이 성공을 좌우하기 때문이다.