설계의 경제학

코드 정리를 "왜" 하는지, 감성이 아니라 경제학으로 설명할 수 있어야 하지. Part 3는 그 이론적 토대를 깔아주는 파트야.

켄트 벡은 소프트웨어 설계를 "요소들을 유익하게 관계 맺는 일"이라고 정의하거든. 짧지만 깊은 말이야. 요소들 — 함수, 클래스, 모듈, 서비스 같은 구성 단위. 관계 맺는 — 호출, 의존, 포함 같은 관계를 만드는 것. 유익하게 — 그 관계가 나중에 변경하기 쉬운 방향이어야 한다는 거지. 설계는 코드를 짜는 행위 자체에 이미 녹아 있어. 함수를 나누고, 파일을 분리하고, 인터페이스를 정의하는 모든 순간이 설계야. 별도의 "설계 단계"가 따로 필요한 게 아니거든. 코드 정리는 이 관계를 더 유익하게 만드는 작업이고, Part 1에서 배운 모든 기법이 결국 요소들 사이의 관계를 개선하는 거였지.

소프트웨어는 두 가지 방식으로 가치를 만들어. 동작 — 소프트웨어가 오늘 하는 일이야. 사용자가 버튼 누르면 결과가 나오는 것. 이게 당장의 돈을 벌지. 구조 — 소프트웨어가 내일 할 수 있는 일의 가능성이야. 코드가 잘 정리되어 있으면 새 기능을 빠르게 추가할 수 있거든. 이건 미래의 돈을 벌게 해줘. 동작은 현재 가치, 구조는 미래 가치. 둘 다 중요한데, 문제는 동작만 보는 시각이 지배적이라는 거야. "일단 돌아가게 만들어" — 이 말이 반복되면 구조는 점점 무너지잖아. 그러다 어느 순간 "왜 이렇게 개발이 느려?" 하는 질문이 나오지. 구조가 망가졌기 때문이야. 코드 정리는 동작을 바꾸지 않으면서 구조를 개선하는 일이야. 현재 가치를 건드리지 않으면서 미래 가치를 높이는 거지.

이걸 경제학으로 풀어보면, 두 가지 개념이 필요해. 시간 가치(Time Value of Money) — 오늘의 1달러가 내일의 1달러보다 가치 있다는 거야. 돈은 빨리 벌수록 좋고, 비용은 늦게 쓸수록 좋지. 선택 가능성(Optionality) — 미래에 선택할 수 있는 폭이 넓을수록 가치 있다는 거야. 옵션이 많으면 좋은 기회가 왔을 때 잡을 수 있잖아. 구조가 좋으면 미래의 선택지가 넓어지거든. 잘 정리된 코드는 새 기능을 빠르게 추가할 수 있고(시간 가치), 다양한 방향으로 확장할 수 있지(선택 가능성).

소프트웨어에 시간 가치를 적용하면 이래: 돈을 버는 기능은 빨리 출시하고, 비용이 드는 작업은 미룰 수 있으면 미뤄라. 코드 정리는 당장 돈을 벌지 않잖아. 그러면 정리를 미뤄야 하는 걸까? 꼭 그렇지는 않아. 정리를 먼저 하면 동작 변경이 빨라질 수 있거든. 정리 비용이 1시간인데 그 덕분에 기능 구현이 3시간 단축된다면? 정리를 먼저 하는 게 경제적이지. 정리를 먼저 할지 말지는, 정리 비용과 그로 인한 시간 절약을 비교해서 판단하면 돼.

금융에서 옵션은 **미래에 무언가를 할 수 있는 권리(의무가 아닌)**야. 소프트웨어의 구조도 일종의 옵션이지. 잘 정리된 코드는 미래에 다양한 기능을 추가할 수 있는 권리를 만들어줘. 구조가 엉망이면 그 권리가 없어. 새 기능 추가하려면 먼저 대규모 리팩터링부터 해야 하거든. 옵션의 가치는 불확실성이 클수록 높아져. 미래에 뭘 해야 할지 모를수록 유연한 구조의 가치가 커지고, 반대로 앞으로 뭘 할지 이미 확실하다면 구조에 과잉 투자할 필요가 없지. 코드 정리는 옵션을 사는 거야. 작은 비용을 들여서 미래에 더 빠르게 움직일 수 있는 가능성을 확보하는 것.

그러면 실제로 어떻게 판단하냐면, 두 가지 렌즈로 볼 수 있어. 현금흐름 관점 — 정리 비용 vs 정리로 인한 시간 절약이야. 정리에 30분 투자해서 기능 구현 시간이 2시간 줄면 순이익이지. 옵션 관점 — 정리가 미래의 선택지를 얼마나 넓히는가야. 당장은 이득이 안 보여도 나중에 큰 기회를 잡을 수 있게 해주는가. 현금흐름만 보면 "당장 필요한 정리만 해라"가 답이야. 옵션까지 고려하면 "조금 더 정리해둘 가치가 있을 수 있다"가 되지. 대부분의 코드 정리는 현금흐름 관점으로 충분해. 지금 하려는 동작 변경이 쉬워지는 정리를 먼저 하면 돼. 하지만 가끔은 옵션 관점에서 "이건 정리해두면 나중에 크게 도움이 될 거다"라는 판단도 필요하고.

마지막으로, 코드 정리의 위험 부담이 낮은 이유가 있어. 의사결정에는 되돌릴 수 있는 결정과 되돌릴 수 없는 결정이 있잖아. 코드 정리는 대부분 되돌릴 수 있는 구조 변경이야. 변수 이름을 바꿨는데 마음에 안 들면 다시 바꾸면 되고, 함수를 추출했는데 별로면 다시 인라인하면 돼. 버전 관리 시스템이 있으니 언제든 되돌릴 수 있지. 되돌릴 수 있는 결정은 빨리 내리는 게 좋아. 고민하는 시간 자체가 비용이니까. 반면 동작 변경 중에는 되돌리기 어려운 것들이 있어. API를 공개하거나, 데이터 형식을 바꾸거나, 사용자에게 배포하거나. 이런 건 신중해야 하지. 코드 정리는 되돌릴 수 있으니 가볍게 시도해. 완벽한 설계를 고민하느라 시간 쓰기보다, 일단 정리해보고 아니면 되돌리는 게 나아.

---

정리

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

1. 소프트웨어 설계는 요소들을 유익하게 관계 맺는 일이야. 동작(현재 가치)을 유지하면서 구조(미래 가치)를 개선하는 게 코드 정리지
2. 시간 가치와 옵션이라는 경제학 프레임워크로 정리 판단을 내릴 수 있어. 현금흐름 관점(정리 비용 vs 시간 절약)이 기본이고, 옵션 관점(미래 유연성)은 보조야
3. 코드 정리는 되돌릴 수 있는 결정이니까 고민보다 실행이 경제적이야. 작게 시도하고, 아니면 되돌리면 돼