AI 시대의 프로그래밍 원칙: DRY

Source: Dev.to

이 글은 AI‑지원 개발이라는 관점에서 프로그래밍 원칙을 재검토하는 일련의 사고 실험 시리즈의 첫 번째 기사입니다. 분명히 우리는 패러다임 변화의 한가운데에 있지만 그 결과가 어디로 향할지는 아무도 확신하지 못합니다. 따라서 저는 미래를 예측하려는 것이 아니라, 강력한 시나리오에 대해 가정을 스트레스 테스트하여 무엇이 지속되는지를 확인하려 합니다. 전체 시리즈에 걸쳐 우리는 AI가 도구로 사용될 것이라는 보다 가능성이 높은 예측에 근거해 판단합니다. AI가 감각을 가진 동료나 유토피아적 특이점 탄생 신이 아니라는 점을 전제로 합니다.

Source: …

DRY (Don’t Repeat Yourself)

DRY는 The Pragmatic Programmer (Hunt & Thomas, 1999)에서 유래되었습니다. 실제로 사람들은 이를 “메서드 추출” 패턴으로 사용합니다: 코드 중복이 발견되면 공통된 곳으로 추출하여 재사용하도록 합니다.

많은 사람들은 이를 Uncle Bob이 제시한 단일 책임 원칙과 연결짓지만, Clean Architecture를 주의 깊게 읽는 독자는 모순을 발견할 수 있습니다; 이 부분은 향후 글에서 다루겠습니다.

DRY의 원래 정의는 대부분의 사람들이 생각하는 것보다 넓습니다:

“시스템 내의 모든 지식은 단 하나의, 모호함이 없고, 권위 있는 표현을 가져야 한다.”

이 글에서는 원칙의 핵심이 지식 중복에 관한 것이지 코드 중복에 관한 것이 아니라는 점을 강조하고자 합니다. 코드 중복은 지식 중복의 결과일 뿐, 이유가 아닙니다.

왜 DRY가 중요한가

DRY는 특정 문제를 해결합니다: 사람은 중복을 추적하는 데 신뢰할 수 없다는 점입니다.

세 개의 서비스에 동일한 세금 계산 로직이 있습니다. 요구사항이 바뀌고, 두 개는 업데이트했지만, 세 번째는 조용히 잘못된 상태로 남아 있습니다. 고객이 4개월 뒤에 불만을 제기할 때까지 말이죠.

이 추상화는 개발자가 복사본이 어디에 있는지 잊어버리는 상황에 대한 우회책입니다.

다시 말해, DRY는 컨텍스트 관리 전략입니다. 인간 개발자는 제한된 정신적 컨텍스트 안에서 작업합니다: 기억할 수 있는 것, 화면에 보이는 것, 최근에 검토한 것 등. DRY는 각 지식 조각이 정확히 한 곳에 존재한다는 보장을 통해 유지해야 할 컨텍스트 양을 줄여줍니다. 복사본이 없으면 복사본이 어디에 있는지 기억할 필요가 없습니다.

이러한 관점은 우리가 답하려는 질문을 재구성합니다.

질문은 “중복이 나쁜가?”(그렇다) 가 아니라, “코드를 유지하는 주체가 자신의 컨텍스트를 관리하기 위해 DRY가 필요한가?” 입니다. 그리고 이는 전적으로 그 주체가 가지고 있는 컨텍스트의 양에 달려 있습니다.

Source: …

DRY가 잘못될 때

AI를 도입하기 전에, DRY는 이미 너무 과감하게 적용될 때 잘 알려진 실패 모드가 있습니다. 이는 인간에게도 원칙에 한계가 있음을 보여주기 때문에 탐구할 가치가 있습니다.

예시: 이메일 검증

// Service A
public bool ValidateEmail(string email)
{
    return Regex.IsMatch(email, @"^[^@\s]+@[^@\s]+\.[^@\s]+$");
}

// Service B – identical
public bool ValidateEmail(string email)
{
    return Regex.IsMatch(email, @"^[^@\s]+@[^@\s]+\.[^@\s]+$");
}

DRY 리팩터링을 통해 이를 공유 라이브러리로 추출합니다:

// SharedLib.Email
public static bool ValidateEmail(string email)
{
    return Regex.IsMatch(email, @"^[^@\s]+@[^@\s]+\.[^@\s]+$");
}

6개월 후:

• Service A는 플러스 주소(user+tag@domain.com)를 허용해야 합니다.
• Service B는 플러스 주소를 허용하지 않음을 명시합니다. 이는 플러스 주소가 사기 방지 파이프라인에서 위험 신호이기 때문입니다.

이제 매개변수 증가, 전략 패턴 적용, 혹은 다시 중복 구현 중 하나를 선택해야 합니다. 공유 라이브러리는 6개월간 일관성을 제공했지만 결국 결합 부채가 되었습니다.

같은 코드를 같은 지식으로 취급할 때 발생하는 일입니다. 두 서비스는 우연히 같은 코드를 가지고 있었을 뿐, 같은 비즈니스 규칙을 공유했기 때문이 아닙니다. 이를 “잘못된 추상화” 또는 “우연한 중복”이라고 부르며, 서비스가 서로 다른 속도로 진화하는 마이크로서비스 아키텍처에서는 사람들이 인정하는 것보다 더 자주 일어납니다.

AI‑지원 중복 관리

귀하의 개발 환경에 코드베이스의 semantic index를 구축할 수 있는 AI 도구가 있다고 가정해 보세요. 이 도구는 구문적으로 동일한 코드뿐만 아니라 기능적으로 동등한 코드까지 매핑합니다. 하나의 인스턴스를 변경하면 관련된 모든 인스턴스를 식별하고 context‑appropriate diffs를 생성하여 영향을 받는 각 서비스에 대해 PR을 열고, 해당 서비스의 구체적인 제약에 맞게 변경 사항을 적용합니다.

이러한 세계에서는 이메일 예제가 다르게 전개됩니다. AI는 세 개의 validator를 모두 찾아내고, 이들이 plus‑addressing에서는 의도적으로 다르게 동작하지만 동일한 domain‑validation 로직을 공유한다는 것을 이해한 뒤, plus‑addressing 동작을 건드리지 않고 domain 검증만 업데이트하는 세 개의 서로 다른 패치를 생성합니다. 각 서비스는 자체 validator를 유지합니다. 공유 라이브러리도 없고, 버전 결합도 없으며, 배포 의존성도 없습니다. 다만 일관성을 유지해야 하는 부분에서는 일관성을 확보합니다.

AI가 DRY를 덜 필요하게 만들까?

겉보기에는 DRY(중복 최소화)가 덜 필요해 보입니다. AI가 코드베이스 전반에 걸친 중복을 추적하고 동기화할 수 있다면, 공유 추상화를 추출할 필요가 없지 않을까요? 각 서비스가 자체 복사본을 가지고, 도구가 일관성을 담당하게 하면 됩니다. 그러면 다음과 같은 장점이 있습니다:

• 로컬 가독성
• 평탄한 의존성 그래프
• 독립적인 배포
• CI 시점에 AI‑검증된 일관성

매력적으로 들리지만 구조적인 문제가 있습니다.

중복 추적을 가능하게 하는 동일한 AI 기능은 코드 생성 속도도 가속화합니다. AI가 중복을 동기화할 정도로 코드베이스를 잘 이해한다면, 새로운 기능도 더 빠르게 생성할 수 있습니다. 개발자는 더 짧은 시간에 더 많은 코드를 배포하게 됩니다. 사람이 직접 작성하기는 어려운 보일러플레이트도 마진 비용이 거의 제로에 가깝기 때문에 자동으로 생성됩니다. 코드베이스가 성장합니다.

그리고 여기서 논증이 순환하게 됩니다: 성장한 코드베이스는 결국 AI의 컨텍스트 윈도우를 초과하게 됩니다. 중복을 추적하도록 설계된 도구조차도 한 번에 모든 중복을 볼 수 없게 되는 것이죠.

이것은 이론적인 문제가 아닙니다. 현재 LLM의 컨텍스트 윈도우는 수만~수십만 토큰 수준으로 측정됩니다. 규모가 큰 마이크로서비스 아키텍처는 수백만 개의…

(다음 편에서 이어집니다.)

컨텍스트, DRY, 그리고 AI

코드베이스와 AI 컨텍스트 윈도우의 성장으로 “중복을 피하라(DRY)” 원칙이 어떻게 재구성되는가.

1. 핵심 긴장

“RAG, 임베딩, 그리고 의미 검색을 사용하더라도, AI가 동시에 추론할 수 있는 양에는 확실한 한계가 있다. 효과적인 컨텍스트를 확장하기 위한 모든 기법은 정밀도와 신뢰성 사이에 트레이드‑오프를 동반한다.”

불편한 현실은 DRY에 반대하는 논거가 스스로를 무력화한다는 점이다:

• DRY를 약화시키는 힘(더 나은 AI, 더 큰 컨텍스트)은 동시에 DRY를 강화시키는 조건(더 많은 코드, 더 큰 코드베이스, 컨텍스트 오버플로우)을 만든다.

2. 확대해서 보기: 컨텍스트 vs. 코드베이스

질문: 컨텍스트 윈도우가 코드베이스보다 더 빠르게 성장하고 있는가?

역사적 추세는 명확하다:

• 코드베이스는 수십 년 동안 계속 커져 왔다.
• IDE, 프레임워크, 패키지 매니저, CI/CD, 그리고 이제 AI‑지원 개발과 같은 모든 생산성 향상은 코드를 더 많이 만들게 했다, 적게가 아니라.
• 업계는 생산성 향상에 대응해 코드를 적게 쓰지 않았다; 우리는 더 빠르고, 더 많이 쓰며 더 야심찬 목표를 추구한다.

3. 컴퓨팅 자원과의 평행

파킨슨 법칙을 소프트웨어에 적용하면: 코드는 가용한 컨텍스트를 채우기 위해 확장된다.

이 패턴이 지속되고(그리고 이를 부정할 강력한 이유가 없다고 가정하면), AI는 완전히 이해할 수 있는 경계 근처에서 항상 작동하게 된다. 인간보다 중복을 찾고 추적하는 데 훨씬 뛰어나지만, 전지전능이라는 사치를 누릴 수는 없다. 제한된 컨텍스트 내에서 코드베이스를 관리하기 위한 전략으로서 DRY는 여전히 의미가 있다—그 컨텍스트가 인간이든 기계이든 관계없이.

4. 무엇이 변하는가?

1. 임계값이 이동한다.

   • AI는 인간보다 더 많은 중복을 추적할 수 있으므로, 중복이 위험해지는 시점이 외곽으로 이동한다.
   • 작은 유틸리티 중복(예: 문자열 포맷팅, 기본 검증)은 AI 도구가 일관성을 검증해줄 수 있다면 추출할 가치가 없을 수도 있다.

2. 검증이 가능해진다.

   • 중복을 선택하더라도 AI가 다음과 같이 알려줄 수 있다:

     “이 다섯 메서드는 동일한 비즈니스 규칙을 구현하고 있으며 그 중 두 개는 이미 흐트러졌다.”

   • 이는 버그를 통해 발견하는 대신 중복에 대한 정보에 기반한 의사결정을 가능하게 한다.

3. 원칙의 전환.

   • “절대 중복하지 말라” → “의식적으로 중복하고, 가시성을 확보하라.”

4. 지식 vs. 코드 중복.

   • Hunt와 Thomas는 원래 정의에서 두 개념을 구분했지만, 업계는 이를 거의 무시했다.
   • AI 도구는 이제 지식 수준에서 DRY를 강제하면서 코드 수준의 중복은 허용할 수 있다—이는 원칙이 항상 의미했던 바와 일치한다는 주장도 가능하다.

5. 실용적인 가이드

공유 메서드나 라이브러리를 추출하려 할 때, 스스로에게 두 가지 질문을 던져라:

1. 비즈니스 개념 질문

   이것들을 추출하는 이유가 실제로 동일한 비즈니스 개념을 표현하기 위함인가, 아니면 현재 코드가 우연히 비슷해 보여서인가?

2. 컨텍스트 관리 질문

   이 추상화가 설계를 진정으로 개선하기 위함인가, 아니면 제한된 컨텍스트 내에서 동기화를 유지하기 위한 메커니즘이 필요해서인가?

• 첫 번째 질문은 언제나 올바른 질문이다.
• 두 번째 질문이 AI에 의해 계산이 바뀌는 부분이며, 이는 점진적으로, 그리고 도구가 실제로 볼 수 있는 범위 내에서만 변한다.

6. 결론

현재로서는 DRY가 실용적인 기본값으로 남아 있다—그 이유는 원칙 자체가 좋기 때문이 아니라, 한정된 컨텍스트(인간이든 기계이든) 안에서 코드를 관리하기 위한 가장 현실적인 전략이기 때문이다.

cred principle, but because 맥락은 인간이든 인공이든 항상 유한합니다. 유한한 한, 우리는 그 한계 내에서 작업하기 위한 전략이 필요합니다. AI는 복제의 임계값과 가시성을 이동시키지만, 사려 깊은 추상화의 필요성을 없애지는 못합니다.