반복과 피드백

반복과 피드백은 별개가 아니라, 하나의 학습 엔진을 구성하는 두 축이야. 반복이 "우리가 틀릴 수 있다"는 전제를 설계에 내장하는 거라면, 피드백은 그 틀림을 빠르게 발견하고 수정하는 메커니즘이지.

워터폴 방식은 "우리의 분석이 맞다"는 전제 위에 서있어. 근데 솔직히, 초기 요구사항이 최종까지 그대로 유지되는 경우가 얼마나 돼? 요구사항 변경은 예외가 아니라 규칙이잖아. 반복 방식은 이 현실을 인정하고, "우리 가정이 틀릴 수 있으니 빠르게 확인하고 수정하자"는 전제 위에 서있어. 이건 단순한 개발 방법론이 아니라 **방어적 설계 전략(Defensive Design Strategy)**이야. 변경을 "방해 요소"로 보는 게 아니라, 변경에 잘 적응할 수 있는 구조를 만드는 거지.

여기서 빠지기 쉬운 함정이 있어 — 계획이라는 유혹이야. 프로젝트 시작 전에 모든 요구사항을 분석하고, 상세 설계를 하고, 간트 차트를 그리고. 이게 "프로페셔널"해 보이거든. 근데 소프트웨어 개발은 **복잡계(Complex System)**야. 6개월 뒤의 요구사항을 지금 정확하게 예측하는 건, 날씨를 6개월 뒤까지 예측하는 것만큼 어려워. 아이젠하워의 말이 정확해 — "계획은 쓸모없지만, 계획하는 행위는 필수적이다." 장기적 방향성은 필요하지만, 상세한 구현 계획은 짧은 주기로 세워야 해.

그래서 실제로 어떻게 하냐고? 핵심은 세 가지야. 첫째, 작은 단위로 작업해. "이 기능은 나눌 수 없어요"라고 말하는 순간이 있는데, 거의 대부분 나눌 수 있어. 나누는 능력 자체가 소프트웨어 엔지니어의 핵심 역량이야. 둘째, 각 반복마다 동작하는 소프트웨어를 만들어. "80% 완성"은 소프트웨어에서 의미가 없어 — 동작하거나, 안 하거나 둘 중 하나야. 셋째, 그리고 이게 가장 중요한데, 반복의 결과로부터 배워. 각 반복에서 "뭘 배웠는가?"를 의식적으로 확인하고, 그 배움이 다음 반복의 방향을 결정해야 해. 그렇지 않으면 반복은 그냥 같은 실수를 여러 번 하는 거야.

그 배움을 만들어내는 원천이 바로 피드백이야. 항공 산업을 생각해봐. 비행기 사고가 나면 원인을 철저히 조사하고, 결과를 전 산업에 공유하고, 시스템을 개선해. 이 피드백 루프 덕분에 항공은 점점 더 안전해졌어. 반면 소프트웨어 업계는? 장애 나면 "누가 실수했나" 찾고, 핫픽스 넣고, 다음에 또 같은 유형의 장애가 반복되잖아. 차이는 피드백을 체계적으로 활용하느냐 마느냐야.

Farley는 피드백을 코드 리뷰 수준이 아니라, 모든 층위에서 작동하는 의사결정 메커니즘으로 봐. 컴파일러가 타입 에러를 초 단위로 잡아주고, 단위 테스트가 분 단위로 동작을 검증하고, CI 파이프라인이 시간 단위로 통합 문제를 찾아주고, A/B 테스트와 카나리 릴리스가 제품이 사용자에게 실제로 가치를 주는지 확인해줘. 각 층위에서 피드백이 빠를수록, 문제를 작을 때 잡을 수 있어.

특히 재밌는 건 설계 피드백이야. 테스트하기 어려운 코드는 거의 항상 설계가 나쁜 코드거든. 과도한 mock이 필요하다면 결합도가 너무 높다는 신호야. 작은 기능 하나 바꿨는데 10개 파일을 수정해야 한다면 관심사의 분리가 안 된 거지. 테스트를 짜는 행위 자체가 설계에 대한 피드백을 주는 거야.

여기서 진짜 중요한 포인트가 있어. 피드백이 느려지면 행동이 달라진다. 단위 테스트가 10분 걸리면 개발자는 테스트를 안 돌리게 돼. CI가 1시간 걸리면 하루에 1-2번만 푸시하게 돼. 빌드 시간을 10분에서 2분으로 줄이면, 그 8분이 하루에 수십 번 누적돼서 엄청난 생산성 향상으로 이어져. 피드백 루프를 줄이는 데 투자하는 것은 거의 항상 가치가 있어.

근데 이 모든 피드백이 흐르려면 전제 조건이 하나 있어 — **심리적 안전(Psychological Safety)**이야. "이 코드에 버그가 있는 것 같아요"라고 말했다가 "네가 못 이해한 거 아니야?"라는 반응이 오면, 다음부터는 말을 안 하게 돼. 실수를 비난하는 문화에서는 피드백이 숨겨지고, 피드백이 숨겨지면 조직은 학습을 멈춰. 비난 없는 문화가 피드백의 전제 조건이야.

---

정리

3장 읽고 기억할 거 세 가지:

1. 반복은 "틀릴 수 있다"는 전제를 설계에 내장하는 방어적 전략이야. 작은 단위로 작업하고, 각 반복에서 배우고, 그 배움으로 다음 방향을 결정해.
2. 피드백은 모든 층위에서 빠르게 돌아야 해. 컴파일러부터 A/B 테스트까지, 피드백 루프의 속도가 곧 개발 효율이야. 줄이는 데 투자하는 건 거의 항상 가치가 있어.
3. 피드백이 흐르려면 심리적 안전이 전제되어야 한다. 실수를 비난하는 문화에서는 피드백이 숨겨지고, 조직은 학습을 멈춰.