변화를 전제로 설계하기

AI 요약

소프트웨어 개발에서는 코드 변경이 잦으면 결함이 많다는 인식이 오래 이어졌습니다. Microsoft 연구는 상대적인 코드 변경량과 결함 밀도의 연관성을 보였고, Adam Tornhill은 복잡하면서 자주 바뀌는 파일을 문제의 징후로 다뤘습니다. GitClear는 AI 보조 도구가 작성 후 2주 안에 다시 쓰이는 코드 비중을 두 배로 늘릴 것으로 전망하며 품질 저하 압력을 지적했습니다. 하지만 글쓴이는 이런 관점이 코드 작성에 많은 비용이 들던 시기의 기준이라고 봅니다. 기능을 구현하는 비용이 낮아지면 기존 코드를 세심하게 보존하는 것보다 다시 쓰는 편이 저렴해질 수 있습니다.

건물은 오래 서 있도록 짓지만 코드베이스는 정원에 비유할 수 있다고 설명합니다. 계절마다 다시 심는 한해살이 식물처럼 자주 바뀌는 코드는 교체를 전제로 만들어도 됩니다. 정원에서 중요한 투자는 흙과 화단, 관개 시설처럼 계속 쓰이는 기반입니다. 소프트웨어에서도 구조가 좋아야 코드를 쉽게 다시 심을 수 있습니다. 교체 가능한 코드도 맡은 일을 해야 하고, 경계 조건을 테스트해야 하며, 주변을 무너뜨리지 않고 제거할 수 있어야 합니다.

글쓴이는 Forem의 최근 6개월간 커밋 563개를 살펴봤습니다. 가장 많이 바뀐 파일은 app/models/article.rb로 37개 커밋에서 수정됐고, 스팸 처리기도 13개 커밋에 등장했습니다. 스팸 처리기는 스패머의 전술에 맞춰 자주 바뀌어도 괜찮은 영역입니다. 반면 article.rb는 핵심 모델이라는 점에서 나무에 비유합니다. 새 기능을 넣기 편하다는 이유로 핵심 모델을 매주 파헤친다면 구조가 타협되고 있다는 신호입니다. 문제는 변경 자체보다 하중을 지탱하는 영역에서 계획 없이 변경이 반복되는 상황입니다.

변경을 설계에 드러내기

글쓴이는 코드 영역을 자주 교체할 부분과 오래 유지할 부분으로 구분하자고 제안합니다. Forem의 AGENTS.md는 핵심 인증, 피드 정렬, 캐시 파이프라인을 AI 도구가 조심해서 다루도록 안내합니다. 글쓴이는 이런 주의 문구를 넘어 그 구분이 코드베이스 구조 자체에 반영돼야 한다고 말합니다.

인터페이스, 스키마, API 명세, 구현 방식이 아니라 동작을 고정하는 테스트는 경계의 기반이 됩니다. 그 뒤에 놓인 구현은 사람이나 AI 에이전트가 자유롭게 다시 쓸 수 있습니다. 자주 바뀔 코드는 주변 코드에 깊이 얽히지 않도록 해 제거 비용을 낮춰야 합니다. 변경량도 계층별로 봐야 합니다. 빠르게 바뀌는 영역의 높은 변경량은 건강한 신호일 수 있지만, 천천히 바뀌어야 할 영역의 높은 변경량은 경고 신호입니다.

글쓴이는 AI가 코드 변경 속도를 높인 지금, 변경을 품질 문제의 증상으로만 보지 말고 설계 조건으로 삼아야 한다고 주장합니다. 끝에서는 자신의 경험상 변경을 피하는 것이 좋은 결과를 낳지 않았다고 덧붙이며, 코드베이스의 품질과 경직성이 변경량과 양의 상관을 보인다는 입장을 밝힙니다.

dev.to 반응

• @alexshev — 구현 비용이 낮아지면 선택의 균형은 달라지지만, 탐색을 위한 변경과 불안정성은 구분해야 합니다. 통과한 계약 테스트나 통합 테스트가 마지막으로 성공한 시점과 변경량을 함께 보는 지표가 유용할 수 있습니다. 안정된 계약 뒤에서 자주 바꾸는 경우와 호출자를 계속 깨뜨리며 바꾸는 경우는 위험이 다릅니다.
• @jabinpou — 스팸 처리기와 article.rb의 대비가 계층 구분을 구체적으로 보여줍니다. 한해살이 영역의 변경이 핵심 모델 수정으로 얼마나 자주 이어지는지도 살펴보겠습니다. 결함이 나타나기 전에도 경계가 새고 있다는 신호가 될 수 있습니다.
• @marcusykim — 제거 테스트에는 저장 데이터도 포함해야 합니다. 빠르게 바뀌는 기능이 열을 추가하거나 새 레코드 유형을 쓰면 코드를 지운 뒤에도 이후 버전의 article.rb가 그 데이터를 계속 책임질 수 있습니다. 정리 또는 호환성 경로를 기능 계약에 포함하고 데이터가 있는 데이터베이스에서 제거를 테스트하겠습니다. 그래야 교체 가능한 구현과 새로 설치할 때만 쉽게 교체되는 구현을 구분할 수 있습니다.
• @anne_jacobs_ac166227aa92b — 변화를 바라보는 관점을 잘 설명한 글입니다. 건물 비유는 정말 약해지고 있습니다. 코드 작성 비용이 높을 때는 오래 유지하는 것이 합리적인 목표였습니다. 이제는 꼼꼼히 보존하는 것보다 다시 쓰는 편이 저렴한 경우가 많으니 모든 코드가 수년간 지속돼야 한다고 여기는 것이 더 비싼 선택이 됩니다. 한해살이와 여러해살이의 구분이 특히 유용합니다. 변경량이 많다는 사실 자체가 나쁜 것은 아니며, 하중을 지탱하는 부분에서 계획 없이 변경이 반복되는 것이 문제입니다. 스팸 처리는 계속 바뀌어야 합니다. 핵심 모델과 인증은 편하다는 이유로 가장 손쉬운 변경 경로가 되어서는 안 됩니다. "제거를 쉽게 하라"는 실용적인 기준입니다. 임시로 둘 코드는 다른 모든 곳에 뿌리를 내리지 않아야 합니다. 저도 정원을 가꾸는 편을 택하겠습니다. 모든 변경량을 품질 문제로 보는 낡은 직감은 이제 구식 비용 모델처럼 보입니다.

원문: dev.to / 번역·요약: Trawling