AI를 사용한 작은 변경 시 아키텍처 드리프트 감소
Source: Dev.to
위에 제공된 링크만으로는 번역할 실제 본문을 확인할 수 없습니다. 번역을 원하는 텍스트(본문)를 그대로 복사해서 알려주시면, 요청하신 대로 마크다운 형식과 코드 블록, URL은 그대로 유지하면서 한국어로 번역해 드리겠습니다.
배경
이전 게시물에서 저는 아키텍처 드리프트와 AI가 전달 속도를 높이면서도 시스템을 원래 의도와 멀어지게 할 수 있다는 점을 논의했습니다. 이 글은 드리프트를 해결한다는 주장이 아니라, 드리프트가 불가피하다면 AI를 사용해 작은 일상적인 변경 요청을 할 때 어떻게 줄일 수 있는지에 대한 보다 실용적인 질문을 탐구합니다.
아래 관찰은 제가 눈여겨 본 패턴에서 나온 것으로, 무엇이 잘못되는지, 무엇이 조금 도움이 되는지, 그리고 최소한 손상을 더 빨리 눈에 띄게 하는 것이 무엇인지에 대한 내용입니다.
여기서 “아키텍처”가 의미하는 바
아키텍처는 다이어그램이나 방대한 문서에 관한 것이 아니다. 변화가 안전하도록 만드는 결정에 관한 것이다:
- 경계가 존재하는 위치
- 누가 어떤 책임을 소유하는지
- 데이터 흐름 방식
- 시스템이 조용히 의존하여 예측 가능하게 동작하도록 하는 가정들
이러한 결정들이 보존되지 않으면, AI가 시스템을 즉시 망가뜨리는 것이 아니라, 전역적인 형태가 더 이상 의미가 없어질 때까지 지역적으로 최적화할 뿐이다.
사고방식의 전환
AI를 코드를 더 빠르게 생성하는 수단으로 여기기보다는, 도움이 되기 위해서는 제한되어야 하는 것으로 간주합니다. 실제 시스템에서 AI‑지원 변경은 대부분 작지만, 아키텍처에 대한 인식 없이 반복되는 작은 변경이 누적되어 드리프트를 일으킵니다. 따라서 목표는 “올바른 출력을 얻는 것”에서 “변경을 수행하면서 형태를 유지하는 것”으로 전환됩니다.
비협상적 제약 조건
These are not suggestions; they are hard constraints that must hold true regardless of the change being requested:
- 새로운 서비스 경계를 도입하지 마십시오.
- 비즈니스 로직을 중복하지 마십시오.
- 데이터 계약을 변경하지 마십시오.
- 아키텍처 계층을 넘어서지 마십시오.
When these constraints are left implicit, AI fills the gaps with assumptions that feel reasonable in isolation but become harmful in aggregate.
제약 조건이 위치해야 할 곳
Constraints must be part of the original prompt, not an afterthought. Each change request should start with the same foundation, explain the impact first, and only then move toward implementation. Applying a change on shaky intent almost always costs more to fix later.
코드 중복: 미묘한 실패 모드
AI는 논리를 약간 더 깔끔하게 재구현하는 데 매우 능숙합니다. 명시적인 지시가 없으면 겉보기에 괜찮아 보이지만 점차 행동을 분산시키는 병렬 경로를 만들게 됩니다. 재사용이 중요하다면—대부분의 경우 그렇습니다—명확히 밝혀야 합니다:
- “기존 로직을 재사용하십시오.”
- “병렬 구현을 만들지 마십시오.”
- “복제하지 말고 확장하십시오.”
이러한 지시사항은 모델이 스스로 신뢰성 있게 추론하지 못합니다.
Managing Context Windows
AI는 현재 보고 있는 것에 대해서만 추론할 수 있습니다. 큰 파일이나 전체 리포지토리를 입력하면 초기 제약 조건이 조용히 범위에서 벗어나 역효과가 발생하는 경우가 많습니다. 보다 현실적인 접근 방식은 모델이 소수의 파일만 볼 수 있다고 가정하고, 그 파일들을 명시적으로 지정하는 것입니다. 이렇게 하면 아키텍처가 문서 덤프가 아니라 간결한 작업 컨텍스트가 됩니다.
도움이 되는 프롬프트 구조
- 비협상 항목을 먼저 명시하십시오.
- 가정된 범위 정의 (컨텍스트에 포함된 파일).
- 코드를 작성하기 전에 모델에게 아키텍처에 미치는 영향을 설명하도록 요청하십시오.
이는 AI를 더 똑똑하게 만들지는 않지만, 실행 전에 일시 정지를 강제합니다. 그 일시 정지만으로도 우발적인 흐름 이탈을 줄여줍니다.
Limitations
None of this is a cure.
이것이 치료법은 아닙니다.
Architectural drift is a natural property of evolving systems.
아키텍처 드리프트는 진화하는 시스템의 자연스러운 특성입니다.
The goal isn’t to prevent change, but to ensure change happens deliberately rather than by inference.
목표는 변화를 방지하는 것이 아니라, 추론에 의해 발생하는 것이 아니라 의도적으로 변화가 일어나도록 하는 것입니다.
These practices don’t eliminate risk; they make it visible earlier, while correction is still possible.
이러한 관행은 위험을 없애지는 않지만, 수정이 아직 가능한 시점에 위험을 더 일찍 드러나게 합니다.
AI is exceptionally good at moving systems forward.
AI는 시스템을 앞으로 나아가게 하는 데 매우 뛰어납니다.
Architecture exists to make sure we don’t move forward blindly.
아키텍처는 우리가盲目하게 앞으로 나아가지 않도록 보장하기 위해 존재합니다.
If architectural intent isn’t carried explicitly into our prompts, the system will still evolve—just not in a direction we consciously chose.
아키텍처 의도가 우리의 프롬프트에 명시적으로 반영되지 않으면, 시스템은 여전히 진화하지만 우리가 의식적으로 선택한 방향이 아닌 방향으로 진화하게 됩니다.
예시 아키텍처 제약 변경 요청 프롬프트
You are implementing a small, incremental change to an existing system.
The following architectural constraints are non‑negotiable and must be preserved:
- The system follows a layered architecture.
- Business logic resides exclusively in the domain layer.
- Adapters are responsible only for data translation, not decision‑making.
- Existing service boundaries and data contracts must remain unchanged.
- No new abstractions, services, or parallel implementations may be introduced.
Assume your effective context is limited to the following files:
OrderService.py, OrderValidator.py, OrderRepository.py.
Do not infer, recreate, or duplicate logic that may exist outside this scope.
Change request:
Add validation for a new optional field in the order payload.
Reuse existing validation mechanisms wherever applicable.
Avoid duplication and ensure behavior remains centralized.
Before implementing the change, explicitly state:
- the architectural layer where the change belongs
- whether the change risks violating any constraint listed above
If a violation is identified, stop and explain the risk.
If no violation exists, implement the minimal code change required, ensuring the system’s architectural shape remains intact.