제품을 만드는 방법에 대한 고찰 과 코드를 작성하는 방법에 대한 고찰 에서 이어 지는 내용입니다.
(Claude Opus 4.5의 도움을 받아 작성되었습니다.)
컨셉이 뒤섞여 있다는 것은 대화에서 드러난다. 같은 단어를 서로 다른 뜻으로 여러 번 사용하거나, 미묘하게 핀트가 조금씩 나가있다는 느낌이 든다.
디자인을 코드로 전환하거나, 클라이언트와 서버를 연동하는 등 서로 다른 팀원이 만든 결과물을 볼 때도 드러난다. 의문점이 생기고, 그 의문점이 단순한 실수가 아니라 근본적인 부분부터 잘못되었다는 느낌이 들면 컨셉이 정렬되지 않은 것이다.
문제를 드러내고, 같이 일하는 동료 모두가 컨셉이 뒤섞여 있다는 것을 인정하는 것이 시작이다.
하지만 이 경우라면 기획부터 디자인, 클라이언트 코드, 서버 코드까지 각각의 영역에서 자신이 이해하고 있는 컨셉으로 이미 작업을 했을 것이다. 정렬된 컨셉대로 다시 만드는 것은 쉽지 않다.
컨셉이 정렬되지 않았다는 것은 구조 개선이 필요할 가능성이 높다. 대대적으로 고치는 것이 가장 좋겠지만, 실제로 해야 하는 일을 하면서 그러기는 쉽지 않다. 그래서 일의 크기에 따라 할 수 있는 것을 나눠서 생각해야 한다.
새로 만드는 것부터는 정렬된 컨셉을 따르도록 한다. 기존 코드가 뒤섞여 있더라도, 새로운 기능만큼은 명확한 컨셉과 경계를 가지도록 만든다. 정렬되지 않은 컨셉의 결과물이 더 이상 늘어나지 않게 하는 것이 첫 번째다.
새로운 기능을 추가하면서 기존 코드를 수정해야 할 때, 그 부분을 조금씩 정렬된 컨셉에 맞게 고친다. 한 번에 전체를 바꾸지 않는다.
변경을 작게 만드는 방법은 큰 컨셉을 작은 컨셉으로 쪼개는 것이다. 예를 들어 "결제"라는 컨셉이 기존 코드에서 청구 생성, 금액 계산, 실제 지불, 영수증 발행까지 전부 담당하고 있다면, 이것을 한 번에 정리하는 것은 너무 크다. "결제"를 "청구", "지불", "영수증"으로 쪼개고, 하나씩 분리해나간다.
컨셉은 프랙탈 구조로 존재한다. 컨셉 안에 더 작은 컨셉이 있고, 그 안에 또 더 작은 컨셉이 있다. 계속 쪼개다 보면 더 이상 쪼갤 수 없는 순수한 무언가에 도달한다. 그 지점은 누가 봐도 의미가 명확해서 의견이 다를 여지가 없다.
작은 컨셉은 경계가 명확하다. 경계가 명확하면 정렬하기 쉽고, 변경도 작고, 안전하다.
구조 개선을 위해 대대적으로 고치는 것은 가장 확실한 방법이다. 하지만 이것은 앞선 단계들이 충분히 이루어지고, 팀 전체가 정렬된 컨셉에 대해 동일하게 이해하고 있을 때 한다.