AI 코딩 시대에 재평가되는 “변경 경계”

최근의 AI 코딩 도구는 상당히 똑똑해지고 있습니다.

이전처럼,

모든 것을 page.tsx에 작성한다

와 같은 코드를 대량으로 생성하는 일은 줄어들었습니다.

오히려 최근에는 자연스럽게,

components/
hooks/
lib/
...

와 같은 구성으로 분리해 나갑니다.

하지만 실제로 사용하다 보면 다른 문제가 발생합니다.

수정의 영향 범위(Impact Scope)가 넓다는 문제입니다.

예를 들어 본래 몇 줄 정도의 수정으로 끝날 내용이라도,

• 타입 정의 (Type Definition) 업데이트
• 관련 부분의 추종
• import 정리
• 명명(Naming) 수정
• 가벼운 리팩토링 (Refactoring)
• 불필요한 코드 삭제

까지 동시에 수행되어, 차이점(Diff)이 수백 줄에 달하는 경우가 있습니다.

이는 「분리되지 않았다」기보다,

변경하는 경계(Boundary)가 모호한 것이 원인이라고 느끼고 있습니다.

이는 중요한 지점인데, 최근의 AI는 평범하게 책임 분리 (Separation of Concerns)를 시도합니다.

예를 들어:

• UI → components
• state → hooks
• utility → lib
• 타입 → types

와 같은 정리는 상당히 자연스럽게 수행합니다.

따라서 문제는 「분할되지 않았다」가 아닙니다.

실제로는 「변경 목적에 대해, 필요 최소한의 차이점(Diff)에서 멈추는 것」을 아직 어려워합니다.

예를 들어 구성이 깔끔하더라도,

components/
hooks/
lib/
...

실제로는:

• hooks가 API를 직접 호출함
• components가 localStorage를 건드림
• lib가 React에 의존함
• types가 비즈니스 로직을 가짐

이라는 상태가 흔히 발생합니다.

즉, 디렉토리가 나누어져 있는 것과 변경 경계가 분리되어 있는 것은 별개입니다.

AI는 구조를 흉내 내는 것은 잘하지만, 「어디까지 변경해도 되는가」라는 변경의 국소성(Locality)을 유지하는 것은 아직 서툽니다.

그렇기 때문에 연관성을 넓게 해석하여 변경이 파급되기 쉽습니다.

여기서 예전부터 있던 설계 원칙이 효과를 발휘합니다.

• Separation of Concerns (관심사의 분리)
• SRP (단일 책임 원칙)
• 느슨한 결합 (Loose Coupling)
• 모듈 경계 (Module Boundary)
• Interface / Contract 설계

등입니다.

다만, AI 시대에는 목적이 조금 바뀌었다고 생각합니다.

기존에는:

• 인간이 이해하기 쉽도록
• 유지보수하기 쉽도록
• 팀 개발을 하기 쉽게

하기 위한 설계였습니다.

반면 AI 시대에는 「변경 영향 범위를 제어하기 위한」 의미가 상당히 강해지고 있습니다.

예를 들어:

type EditorDocument = {
nodes: Node[]
}

와 같은 공통 계약 (Contract)을 정의합니다.

그러면:

• UI
• 저장 (Save)
• export
• API
• AI 생성

등이 이 타입을 경계로 하여 연결됩니다.

즉, 「내부 구현은 바꿔도 좋지만, 이 계약은 깨뜨리지 않는다」라는 제약을 만들 수 있습니다.

AI 코딩에서는 이 「깨뜨려서는 안 되는 경계」가 상당히 중요해집니다.

반대로 경계가 모호하면:

타입 변경
↓
저장 형식 변경
...

와 같이 변경이 전파되기 쉽습니다.

처음에는,

이 파일 이외에는 변경 금지

와 같이 제약하고 싶어집니다.

하지만 실제로는 이렇게 하면 import/export 조정조차 할 수 없어 오히려 파탄 나기 쉽습니다.

따라서 최근에는 「파일 단위」가 아니라 「책임 단위」로 제약하는 편이 안정적이라고 느낍니다.

예를 들어:

이번 변경은 표시 책임(Display Responsibility)만 해당.
허용:
- UI 컴포넌트
...

와 같이 「어느 책임까지 변경 가능한가」를 제한하는 것입니다.

이는 인간 사이의 리뷰 관점과도 상당히 유사하다고 생각합니다.

다만 실제로는 처음부터 깔끔한 경계를 만드는 것은 어렵습니다.

AI는 개발 속도가 매우 빠르기 때문에,

일단 page.tsx에 작성한다
↓
나중에 분리하자
...

는 흔히 일어납니다.

그러므로 실제로는,

• 매번 차이점(Diff)이 폭발하는 곳
• AI가 관계없는 부분까지 건드리는 곳
• import/export가 깨지기 쉬운 곳
• 리뷰가 힘든 곳

부터 사후에 경계화해 나가는 것이 현실적입니다.

최근의 AI는 어느 정도의 책임 분리나 구조화는 평범하게 수행합니다.

하지만 한편으로 「변경 목적에 대해, 필요 최소한의 차이점(Diff)에서 멈추는 것」은 아직 어려워합니다.

그렇기 때문에 예전부터 있던

• 관심사의 분리 (Separation of Concerns)
• Interface / Contract
• 모듈 경계 (Module Boundary)
• 느슨한 결합 (Loose Coupling)

과 같은 설계 원칙이 「AI의 변경 영향 범위를 제어하기 위해」 다시금 중요해지고 있다고 느낍니다.