AI 생성 코드로 초기 프레임워크 락인 줄이기

초기 제품에서 프레임워크 락인이 의미하는 것

프레임워크 락인은 제품이 특정 프레임워크(또는 벤더 플랫폼)에 너무 깊이 묶여 나중에 변경하는 것이 회사 전체를 재작성하는 것처럼 느껴지는 상태를 말합니다. 단순히 “우리는 React를 쓰고 있다” 또는 “Django를 선택했다”를 넘어, 프레임워크의 관습이 비즈니스 규칙, 데이터 접근, 백그라운드 작업, 인증, 파일명 규칙 등 모든 곳에 스며들어 결국 프레임워크 자체가 애플리케이션이 되는 상황입니다.

평범한 말로 락인이 어떤 모습인지

락인된 코드베이스는 비즈니스 결정이 프레임워크 특유의 클래스, 데코레이터, 컨트롤러, ORM, 미들웨어에 박혀 있는 경우가 많습니다. 그 결과: 다른 웹 프레임워크로 이전하거나 데이터베이스 계층을 바꾸거나 서비스를 분리하는 것과 같은 작은 변경조차도 거대한, 위험한 프로젝트가 됩니다.

락인은 보통 초기에는 “프레임워크를 따라가는 것이 가장 빠르다”는 이유로 발생합니다. 프레임워크를 쓰는 것이 속도를 높이는 것은 맞지만, 문제는 프레임워크 패턴이 구현 세부 사항으로 남지 않고 제품 설계 그 자체가 될 때 시작됩니다.

왜 초기 단계 제품이 가장 취약한가

초기 제품은 압박 속에서 만들어집니다: 아이디어를 검증하려고 경쟁하고, 요구사항은 주 단위로 바뀌며, 작은 팀이 온보딩부터 청구까지 모든 것을 처리합니다. 이런 환경에서는 패턴을 복사해 붙이고, 기본값을 수용하고, 스캐폴딩이 구조를 지시하게 하는 것이 합리적입니다.

하지만 이런 초기 단축이 빠르게 누적됩니다. ‘MVP-플러스’ 단계에 이르렀을 때 핵심 요구사항(멀티테넌트 데이터, 감사 로그, 오프라인 모드, 새로운 통합 등)이 원래 프레임워크 선택에 맞지 않는다는 것을 발견할 수 있습니다.

진짜 목표: 되돌릴 수 없는 결정을 미루는 것

프레임워크를 영원히 피하려는 것이 목적은 아닙니다. 목표는 제품이 실제로 무엇을 필요로 하는지 배울 수 있을 만큼 옵션을 열어두는 것입니다. 프레임워크는 교체 가능한 컴포넌트여야 하며, 핵심 규칙이 머무는 장소가 되어서는 안 됩니다.

AI 생성 코드가 들어맞는 곳(그리고 들어맞지 않는 곳)

AI 생성 코드는 인터페이스, 어댑터, 검증, 테스트 같은 깔끔한 이음(seams)을 스캐폴드하는 데 도움을 줘 초기 프레임워크 결정을 “굳히지” 않고도 빠르게 작업할 수 있게 해주므로 락인을 줄이는 데 기여할 수 있습니다.

하지만 AI가 아키텍처를 대신 선택해주지는 않습니다. “기능을 만들어줘”라고만 요청하면 AI는 종종 프레임워크의 기본 패턴을 따라갈 것입니다. 따라서 방향을 정하는 것은 여전히 당신의 몫입니다: 비즈니스 로직을 분리하고, 의존성을 격리하며, 변화를 염두에 두고 설계하되 빠르게 배포하세요.

AI 개발 환경(단순 에디터 보조가 아니라)을 사용 중이라면 이런 제약을 더 쉽게 강제할 수 있는 기능을 찾으세요. 예를 들어 Koder.ai는 미리 경계를 명시할 수 있는 플래닝 모드를 제공하고(예: “core는 프레임워크 임포트 없음”), 소스 코드 내보내기를 지원해 포터블성을 유지하고 툴링 결정에 묶이지 않도록 도와줍니다.

락인은 보통 어떻게(사고로) 발생하는가

프레임워크 락인은 의도적인 선택으로 시작하는 경우가 드뭅니다. 보통은 “그냥 배포하자”는 작은 결정들이 수십 개 쌓여 조용히 코드베이스의 가정으로 굳어지면서 생겨납니다.

흔한 촉발 패턴

자주 반복되는 패턴은 다음과 같습니다:

• 타이트한 결합: 비즈니스 규칙이 프레임워크 헬퍼(requests, sessions, ORM 모델 등)를 직접 호출하고 자체 얇은 추상화를 사용하지 않음
• 벤더 특정 API 사용: 큐, 인증, 스토리지, 분석 같은 내장 솔루션을 경계 없이 바로 사용함
• 붙박이 된 임시 해결책: 프로토타입의 단축이 ‘임시 프로덕션’이 되고, 작동하니까 아무도 손대지 않음

AI 생성 코드는 이런 사고 과정을 가속화할 수 있습니다: “작동하는 코드”를 요청하면 종종 가장 관용적인 프레임워크-네이티브 구현을 만들어주므로 속도는 빨라지지만 의존성도 예상보다 빨리 굳어질 수 있습니다.

락인은 어디에 숨는가(예시와 함께)

락인은 몇몇 고중력 영역에 자주 형성됩니다:

• 라우팅과 컨트롤러: 라우트 파라미터와 미들웨어 가정이 곳곳으로 퍼짐(예: “모든 곳에서 request 객체에 접근 가능”).
• 인증/권한: 특정 제공자의 개념에 묶인 역할, 세션, 가드가 미래 변경을 어렵게 만듦.
• 데이터 모델: ORM 모델 안에 비즈니스 로직이 들어가면 그 ORM에 암묵적으로 묶임.
• UI 컴포넌트 시스템: 화면들이 특정 컴포넌트 라이브러리의 스타일과 상태 패턴에 의존하면 교체가 재작성 수준이 됨.

우발적 락인 vs 의도적 락인

락인이 항상 나쁜 것은 아닙니다. 속도가 중요할 때 프레임워크를 선택하고 그것에 기대는 것은 합리적인 트레이드오프일 수 있습니다. 문제는 우발적 락인—의도치 않게 커밋해버렸고, 코드에 다른 프레임워크나 모듈이 끼어들 수 있는 깔끔한 이음(seams)이 남아있지 않은 경우입니다.

AI 생성 코드가 할 수 있는 것(그리고 할 수 없는 것)

AI 생성 코드는 보통 프롬프트로부터 함수, 파일 스캐폴드, 테스트, 리팩터 제안, 작은 기능을 만들어내는 도구들(예: ChatGPT 또는 에디터 내 보조 도구)을 말합니다. 빠른 패턴 매칭과 제공한 컨텍스트를 결합해 결과물을 내주지만, 마법같지는 않습니다.

초기 단계에서 잘하는 것

프로토타입에서 MVP로 넘어갈 때 AI는 제품을 정의하지 않는 반복적 작업에서 가장 유용합니다:

• 스캐폴딩: 폴더 구조, 기본 CRUD 엔드포인트, 간단한 UI 컴포넌트, 설정 파일, 보일러플레이트
• 글루 코드: 모듈 간 데이터 매핑, 서비스 연결, 작은 어댑터 작성, 반복 변환 처리
• 리팩터 보조: 이름 바꾸기, 헬퍼 추출, 파일 분리, 중복 정리—특히 방향이 이미 명확할 때

이렇게 사용하면 AI는 경계(비즈니스 규칙 대 프레임워크 글루)에 집중할 시간을 벌어주어 락인 압박을 줄여줍니다.

할 수 없는 것(그리고 락인이 숨어드는 곳)

AI는 신뢰할 수 있게 다음을 수행하지 못합니다:

• 아키텍처를 대신 선택하거나 장기 유지보수 트레이드오프를 이해하지 못함
• 미묘한 결합(예: ORM 모델에 박혀 있는 비즈니스 로직, 곳곳에 퍼진 프레임워크 전용 데코레이터)을 쉽게 포착하지 못함
• 성장하는 코드베이스에서 패턴을 일관되게 유지시키지 못함(강력한 지침 없이는)

일반적인 실패 모드는 ‘동작한다’는 이유로 편리한 프레임워크 기능을 많이 사용하는 코드가 만들어져 나중에 조용히 마이그레이션을 어렵게 만드는 것입니다.

올바른 마음가짐: AI 출력은 초안이다

AI 생성 코드를 주니어 동료의 첫 시도라고 생각하세요: 유용하지만 검토가 필요합니다. 대안들을 요청하고, 프레임워크-불가지론(agnostic) 버전을 요구하며, 병합 전에 핵심 로직이 포터블(portable)한지 확인하세요.

비즈니스 로직을 프레임워크와 분리하라

유연성을 유지하려면 프레임워크(Next.js, Rails, Django, Flutter 등)를 전달층(delivery layer) 으로 취급하세요—HTTP 요청 처리, 화면, 라우팅, 인증 연결, 데이터베이스 배관을 담당하는 부분입니다.

당신의 핵심 비즈니스 로직은 배달 방식이 바뀌어도 변하지 않아야 할 것들입니다: 가격 규칙, 인보이스 계산, 자격 확인, 상태 전이, “관리자만 인보이스를 취소할 수 있다” 같은 정책. 이런 로직은 웹 컨트롤러, 모바일 버튼, 백그라운드 작업 등 무엇에 의해 트리거되는지 알 필요가 없어야 합니다.

가장 단순한 경계: 프레임워크 코드가 당신의 코드를 호출하게 하라

결합을 방지하는 실용적인 규칙은:

프레임워크 코드가 당신의 코드를 호출하고, 그 반대는 아니어야 한다.

따라서 컨트롤러가 규칙으로 가득 찬 대신, 컨트롤러는 얇게 유지하세요: 입력 파싱 → 유즈케이스 모듈 호출 → 응답 반환.

유즈케이스 기반 모듈(그리고 AI의 도움)

AI 보조자에게 비즈니스 로직을 제품이 수행하는 행동 이름을 가진 평범한 모듈로 생성하라고 요청하세요:

• CreateInvoice
• CancelSubscription
• CalculateShippingQuote

이 모듈들은 평범한 데이터(DTO)를 받고 결과나 도메인 오류를 반환해야 합니다—프레임워크의 request 객체나 ORM 모델, UI 위젯에 대한 참조는 없어야 합니다.

AI 생성 코드는 이미 핸들러 안에 난잡하게 섞여 있는 로직을 순수한 CreateInvoice 서비스로 추출하는 데 특히 유용합니다. 지저분한 엔드포인트를 붙여넣고: “입력 검증과 명확한 반환 타입을 가진 순수 CreateInvoice 서비스로 리팩터해; 컨트롤러는 얇게 유지”라고 요청해 보세요.

빠른 냄새 테스트

비즈니스 규칙이 프레임워크 패키지를 임포트한다면(라우팅, 컨트롤러, React 훅, 모바일 UI 등) 계층이 섞여 있는 것입니다. 반대로 생각하세요: 의존성이 프레임워크 쪽으로 흐르도록(프레임워크가 코어를 호출) 유지하면 코어 로직을 교체하기 쉬워집니다.

옵션을 열어두는 어댑터와 인터페이스 사용

어댑터는 애플리케이션과 특정 도구/프레임워크 사이에 위치하는 작은 번역기입니다. 코어는 당신이 소유한 인터페이스(예: EmailSender 또는 PaymentsStore)와 통신하고, 어댑터가 프레임워크가 그 작업을 어떻게 수행하는지의 세부 사항을 처리합니다.

이 방식은 도구 교체를 집중적인 변경으로 줄여줍니다: 전체 제품을 바꾸는 것이 아니라 어댑터만 교체하면 됩니다.

어댑터가 특히 중요한 곳

락인이 초기 단계에서 자주 스며드는 곳은:

• 데이터베이스 접근: ORM이나 데이터베이스 클라이언트를 래핑하여 코어가 쿼리 문법이나 모델에 의존하지 않게 함
• HTTP 클라이언트: 벤더 SDK나 특정 HTTP 라이브러리를 HttpClient / ApiClient 뒤에 숨김
• 큐와 백그라운드 작업: SQS, RabbitMQ, Redis 큐, 또는 프레임워크 전용 잡 러너 중 무엇을 쓰든 숨김
• 파일/스토리지: 로컬 디스크 vs S3/GCS의 인증, 경로, 업로드 의미를 추상화

이 호출들이 코드베이스에 흩어져 있을 때 마이그레이션은 “전부 건드리기”가 되지만, 어댑터를 쓰면 “모듈 하나 교체”로 줄어듭니다.

AI의 도움: 페어를 빠르게 생성

AI는 여기 필요한 반복적 스캐폴딩(인터페이스 + 구체 구현 한 쌍)을 만들어내는 데 훌륭합니다.

예: 다음을 생성하도록 프롬프트하세요:

• 필요한 메서드(publish(), subscribe())를 가진 인터페이스(Queue)
• 선택한 라이브러리를 사용하는 구현(SqsQueueAdapter)
• 테스트용 ‘페이크’ 구현(InMemoryQueue)

설계는 당신이 검토하지만, AI는 보일러플레이트로 몇 시간을 절약할 수 있습니다.

어댑터는 얇고 교체 가능하게 유지하라

좋은 어댑터는 지루합니다: 최소한의 로직, 명확한 오류, 비즈니스 규칙 없음. 어댑터가 너무 똑똑해지면 락인을 다른 장소로 옮긴 것뿐입니다. 비즈니스 로직은 코어에 두고 어댑터는 교체 가능한 배관으로 유지하세요.

먼저 계약을 생성하라: 스키마, 타입, 검증

프레임워크 락인은 종종 단순한 단축에서 시작합니다: UI를 만들고 편리한 데이터/API 형태에 바로 연결한 뒤 나중에 모든 화면이 동일한 프레임워크-특정 데이터 모델을 가정하게 되는 상황입니다.

“계약 우선” 접근법은 그 순서를 뒤집습니다. 엔드포인트를 연결하기 전에 제품이 의존할 계약들(요청/응답 형태, 이벤트, 핵심 데이터 구조) 을 정의하세요. 예를 들어 “CreateInvoice의 입력은 무엇인가?” 또는 “Invoice가 보장해야 하는 것은 무엇인가?” 같은 질문을 먼저 던지세요, ‘프레임워크가 이를 어떻게 직렬화하는가’가 아니라.

컨트롤러가 아니라 스키마로 시작하라

OpenAPI, JSON Schema, GraphQL 스키마 같은 포터블한 형식을 사용하세요. 이는 제품의 안정적인 중심축이 됩니다—UI가 Next.js에서 Rails로 바뀌더라도, API가 REST에서 다른 방식으로 바뀌더라도 말이죠.

AI에 단조로운(하지만 중요한) 글루를 생성하게 하라

스키마가 존재하면 AI는 다음과 같은 일관된 산출물을 생성하는 데 특히 유용합니다:

• 스키마에서 파생된 타입/인터페이스(TypeScript 타입, Kotlin 데이터 클래스 등)
• 런타임 검증기(예: Zod/Ajv 규칙)로 잘못된 데이터를 초기에 거부
• 테스트 픽스처: 유효/무효 페이로드 예시와 당신이 생각하지 못한 엣지 케이스

이렇게 하면 비즈니스 로직이 프레임워크 요청 객체가 아니라 내부 타입과 검증된 입력에 의존하게 되어 프레임워크 결합을 줄일 수 있습니다.

점진적 변화를 가능하게 하는 버전 관리

계약을 제품 기능처럼 다루세요: 버전 관리하세요. 가벼운 버전 관리(/v1 vs /v2 또는 invoice.schema.v1.json)만으로도 필드를 대규모로 한 번에 바꾸지 않고 진화시킬 수 있습니다. 전환 기간 동안 두 버전을 모두 지원하고 소비자를 점진적으로 마이그레이션하세요.

AI로 테스트 안전망을 구축하라

테스트는 초기 단계에서 락인을 막는 최고의 도구 중 하나입니다—좋은 테스트는 구현이 아니라 동작을 설명하기 때문입니다. 테스트 스위트가 “이 입력이 들어오면 우리는 이 출력을 만들어야 한다”고 분명히 명시하면, 프레임워크를 나중에 바꾸더라도 훨씬 적은 두려움으로 교체할 수 있습니다.

테스트가 락인을 줄이는 이유

프레임워크 락인은 비즈니스 규칙이 프레임워크 관습과 얽힐 때 자주 발생합니다. 강한 단위 테스트 세트는 이 규칙들을 드러내고 포터블하게 만들어 줍니다. 마이그레이션(또는 리팩터)할 때 테스트가 계약이 되어 동작을 유지했음을 증명해줍니다.

AI가 올바른 테스트를 생성하는 방법

AI는 특히 다음을 생성하는 데 유용합니다:

• 비즈니스 규칙(가격, 자격, 권한, 상태 전이)에 대한 단위 테스트
• 빠르게 진행할 때 놓치기 쉬운 엣지 케이스(빈 입력, 타임존, 반올림, 중복 제출 등)
• 버그 리포트로부터의 회귀 테스트(“이전에는 실패했음; 다시는 실패하면 안 됨”)

실무 워크플로: 함수와 그 규칙에 대한 짧은 설명을 붙여넣고 AI에게 경계값과 ‘이상한’ 입력을 포함한 테스트 케이스를 제안하라고 하세요. 제안된 케이스를 검토하면 AI가 빠르게 범위를 넓혀줍니다.

테스트 피라미드를 지향하라(테스트 탑이 아니라)

유연성을 유지하려면 많은 단위 테스트, 적은 수의 통합 테스트, 그리고 소수의 E2E 테스트를 권장합니다. 단위 테스트는 빠르고 저렴하며 특정 프레임워크에 덜 묶입니다.

가능한 한 프레임워크 무거운 테스트 헬퍼는 피하라

테스트가 전체 프레임워크 부팅, 커스텀 데코레이터, 특정 에코시스템의 무거운 모킹 유틸리티를 필요로 하면 테스트가 또 다른 락인이 됩니다. 순수 함수와 도메인 서비스에 대한 평범한 어설션을 선호하고, 프레임워크 특화 와이어링 테스트는 최소화하세요.

스택을 굳히지 않고 더 빠르게 프로토타입하라

초기 제품은 실험처럼 행동해야 합니다: 작게 만들고, 측정하고, 배운 것에 따라 방향을 바꾸라. 위험은 첫 프로토타입이 조용히 ‘제품’이 되어버려 초기의 프레임워크 선택이 되돌리기 어려운 비용이 되는 것입니다.

프로토타입을 폐기 가능한 실험으로 다뤄라

AI 생성 코드는 다양한 옵션을 빠르게 탐색하는 데 이상적입니다: React로 간단한 온보딩 흐름을 만들어보거나 서버 렌더링 버전을 비교해보거나, 두 결제 제공자를 시험해보고, 같은 기능에 대해 다른 데이터 모델을 시도해볼 수 있습니다. AI는 몇 분 안에 작동 가능한 스캐폴딩을 만들어주므로 처음 배포된 스택에 회사의 운명을 걸지 않고도 선택지를 비교할 수 있습니다.

핵심은 의도입니다: 프로토타입에 대해 임시라고 라벨을 붙이고, 미리 무엇을 검증할지 결정하세요(예: “사용자가 3단계를 완료하는가?” 또는 “이 워크플로는 이해하기 쉬운가?”). 답을 얻으면 프로토타입은 본연의 역할을 한 것입니다.

시간 상자를 정하고 의도적으로 폐기하라

짧은 시간 제한(보통 1–3일)을 정해 프로토타입을 만들고 테스트하세요. 시간 상자가 끝나면 선택하세요:

• 버리기: 코드 대신 학습만 보관
• 다시 빌드: 선택한 접근법을 참고용으로 삼아 깔끔하게 재구축

이렇게 하면 ‘프로토타입 글루’(임시 해결, 복사-붙여넣기, 프레임워크 특유의 단축)가 장기적인 결합으로 바뀌는 것을 막을 수 있습니다.

반복하면서 결정 기록하기

코드를 생성하고 조정할 때는 가벼운 결정 로그를 남기세요: 시도한 것, 측정한 것, 왜 선택(또는 거부)했는지. 제약 조건도 캡처하세요(예: “기존 호스팅에서 실행되어야 함”, “향후 SOC2 필요”). /docs나 프로젝트 README의 간단한 페이지면 충분하며, 미래 변경을 계획된 반복처럼 느껴지게 해줍니다.

깊은 결합을 막기 위해 조기에 그리고 자주 리팩터하라

초기 제품은 주 단위로 바뀝니다: 명명, 데이터 형태, ‘사용자’의 의미까지도. 성장 후에 리팩터를 미루면 프레임워크 선택이 비즈니스 로직으로 굳어집니다.

AI 생성 코드는 이름 변경, 헬퍼 추출, 파일 재구성, 경계 뒤로 코드 이동 같은 반복적이고 위험이 적은 편집에 능하므로 조기에 리팩터하는 데 도움을 줍니다. 잘 사용하면 구조적 결합이 생기기 전에 결합을 줄일 수 있습니다.

높은 가치의 리팩터 대상(락인이 숨어있는 곳)

먼저 변경하세요—나중에 제품을 이동하기 쉽게 만드는 부분들:

• 서비스 경계: 비즈니스가 하는 일을 BillingService, InventoryService처럼 컨트롤러, ORM 모델, 프레임워크 요청 객체를 임포트하지 않는 서비스로 추출
• DTO / 뷰 모델: 프레임워크 모델을 곳곳에 전달하지 말고 입력/출력의 평범한 데이터 형태를 도입하고 매핑은 경계에서 수행
• 오류 처리: 코드베이스 전반에 흩어진 프레임워크 특정 예외를 NotFound, ValidationError 같은 자체 오류 타입으로 대체하고 경계에서 변환

작은 되돌릴 수 있는 단계(각 단계마다 테스트)

되돌릴 수 있는 증분으로 리팩터하세요:

1. 변경할 동작에 대한 테스트를 추가하거나 업데이트
2. AI에게 하나의 변경(이름 바꾸기, 추출, 이동)을 요청하고 diff를 설명하게 함
3. 즉시 테스트 실행; 통과하면 다음 단계로 진행

이 ‘한 번의 변경 + 녹색 테스트’ 리듬은 AI를 유용하게 쓰되 제어권을 잃지 않게 도와줍니다.

대규모 재작성은 피하라

전체 리포지토리에 걸친 “아키텍처 현대화” 같은 대규모 생성 리팩터를 AI에게 요구하지 마세요. 큰 생성 디프는 스타일 변경과 동작 변경을 섞어 버려 버그를 찾기 어렵게 만듭니다. 검토할 수 없을 만큼 큰 diff는 신뢰할 수 없습니다.

실제로 마이그레이션을 계획하라(실제로 마이그레이션하지 않더라도)

마이그레이션을 계획하는 것은 비관적 태도가 아니라 보험입니다. 초기 제품은 빠르게 방향을 바꿀 수 있습니다: 프레임워크를 바꾸거나 모놀리스를 분리하거나 인증을 컴플라이언스 가능한 방식으로 전환할 수도 있습니다. 퇴로(exit)를 염두에 두고 설계하면 보통 더 깔끔한 경계가 생기며 설사 그대로 남더라도 이득입니다.

나중에 옮기기 어려운 부분들

마이그레이션은 가장 얽혀 있는 부분들이 곳곳에 퍼져 있을 때 실패하거나 비용이 커집니다:

• 상태 관리: UI 상태가 비즈니스 규칙으로 스며들거나 프레임워크 특정 저장소가 소스 오브 트루스로 되는 경우
• 데이터 레이어: ORM 모델이 API 계약을 동시에 담당하고, 쿼리가 화면에 흩어져 있으며 마이그레이션이 프레임워크 관습에 묶일 때
• 인증 및 권한: 세션 처리, 미들웨어, 권한 체크가 컨트롤러/컴포넌트에 흩어져 있을 때

이 영역들은 많은 파일을 건드리기 때문에 작은 불일치가 증폭되어 매우 끈적거리는 문제가 됩니다.

현실적인 마이그레이션 계획을 AI로 초안 작성하기

AI 생성 코드는 ‘마이그레이션을 수행’하기보다는 구조를 만드는 데 유용합니다:

• 스택에 맞춘 마이그레이션 체크리스트 초안 작성(라우트, 상태, 데이터 모델, 인증 흐름). 템플릿을 /blog/migration-checklist에 두세요.
• 증분 시퀀스 제안(“먼저 인증을 옮기고, 그다음 데이터 접근, 마지막으로 UI”)과 안정시킬 것들(계약, ID, 이벤트 이름)
• 리스크 표 생성(무엇이 깨질 수 있는지, 어떻게 감지할지, 롤백 단계)

핵심은 코드가 아니라 단계와 불변 조건(invariants) 을 요구하는 것입니다.

‘스트랭글러’ 패턴으로 실행하기

모든 것을 다시 쓰는 대신 새 모듈을 기존 것 옆에 두고 실행하세요:

• 동일한 외부 계약(스키마, 엔드포인트, 이벤트)을 가진 새 서비스/모듈을 만듭니다.
• 트래픽의 작은 비율이나 단일 기능만 새 경로로 라우팅합니다.
• 범위를 확장해 구형 모듈이 얇은 셸이 될 때까지 진행합니다.

이 접근법은 이미 명확한 경계가 있을 때 가장 잘 작동합니다. 예제와 패턴은 /blog/strangler-pattern 및 /blog/framework-agnostic-architecture를 참고하세요.

마이그레이션을 하지 않더라도 얻는 이점: 숨은 의존성 감소, 더 명확한 계약, 놀라운 기술 부채 감소입니다.

AI 생성 코드에 대한 실용적 가드레일

AI는 많은 코드를 빠르게 내줄 수 있고, 동시에 프레임워크의 가정을 코드 전반에 퍼뜨릴 수도 있습니다. 목표는 “덜 신뢰하라”가 아니라 검토하기 쉽게 하고 핵심 제품이 특정 스택에 우연히 결합되지 않도록 만드는 것입니다.

숨은 락인을 방지하는 리뷰 체크

AI 보조 코드가 포함된 모든 PR에 반복 가능한 짧은 체크리스트를 사용하세요:

• 코어 모듈에 프레임워크 타입 없음 (Request, DbContext, ActiveRecord, Widget 등 금지). 코어 코드는 도메인 용어로 말해야 합니다: Order, Invoice, UserId.
• 전역과 싱글톤 최소화. 파라미터로 구성할 수 없는 객체는 테스트하기 어렵고 이동하기 힘듭니다.
• 의존성은 안쪽을 향함. UI/API 레이어가 코어를 임포트할 수는 있지만 코어는 UI/API/프레임워크 패키지를 임포트하면 안 됩니다.
• 직렬화는 가장자리에. JSON/HTTP/폼 데이터 변환은 어댑터에서 처리하고 비즈니스 로직에서는 피하세요.

AI가 따를 수 있는 가벼운 표준

강제 가능한 수준으로 단순하게 유지하세요:

• core/, adapters/, app/ 같은 폴더 경계를 정의하고 규칙을 둡니다: “core는 제로 프레임워크 임포트.”
• 의도를 드러내는 명명법 사용: *Service(비즈니스 로직), *Repository(인터페이스), *Adapter(프레임워크 글루).
• 금지된 임포트를 발견하면 빌드를 실패시키는 작은 스크립트나 의존성 규칙 도구를 추가하세요.

프롬프트 청결: 제약을 명시하라

AI에게 코드를 요청할 때는 다음을 포함하세요:

• 대상 폴더(예: “/core에 생성, 프레임워크 임포트 금지”),
• 허용된 의존성,
• 선호하는 인터페이스 스타일의 작은 예시.

AI 플랫폼의 ‘계획 후 생성(plan then build)’ 워크플로우가 있는 경우, 플래닝 모드에 이런 제약을 적어두면 생성된 변경을 스냅샷/롤백하면서 검토하기 쉬워집니다(예: Koder.ai).

초기에 자동 검사를 도입하라

포매터/린터와 기본 CI 검사(간단한 “lint + test” 파이프라인)를 하루 이내에 설정하세요. 결합을 바로 잡아 초기 습관으로 굳는 것을 방지합니다.

체크리스트: 첫 90일 동안 유연성 유지하기

프레임워크에 묶이지 않는 것은 프레임워크를 피하는 것이 아니라 속도를 위해 사용하되 퇴로(exit)의 비용을 예측 가능하게 유지하는 것입니다. AI 생성 코드는 빠르게 움직이게 도와주지만, 유연성은 당신이 이음(seams)을 어디에 두느냐에 달려 있습니다.

락인을 지연시키는 핵심 전술

초기부터 다음 네 가지 전술을 염두에 두세요:

• 비즈니스 로직을 프레임워크와 분리: 가격 규칙, 온보딩 규칙, 권한 등을 프레임워크 특정 패키지를 임포트하지 않는 평범한 모듈/서비스에 둡니다.
• 어댑터와 인터페이스 사용: 프레임워크, 데이터베이스, 큐, 인증, 이메일은 교체 가능한 ‘플러그’로 대우합니다. 앱은 인터페이스를 호출하고 어댑터가 구현합니다.
• 먼저 계약 생성: 엔드포인트를 연결하기 전에 스키마/타입/검증을 정의합니다(AI는 일관된 타입과 검증기를 생성하는 데 탁월함).
• AI로 테스트 안전망 구축: 비즈니스 규칙에 대한 고신호 단위 테스트와 중요한 흐름에 대한 소수의 통합 테스트는 리팩토링과 마이그레이션을 현실적으로 만듭니다.

1주차 체크리스트(빠르고 실용적)

이 단계가 커지기 전에 다음을 완료하는 것을 목표로 하세요:

1. /core(또는 유사 폴더)를 만들어 비즈니스 로직을 보관하고 프레임워크 임포트 없음을 지키세요.
2. API 및 도메인 계약(스키마/타입)을 정의하고 검증기를 생성하세요.
3. 스토리지, 인증, 이메일, 결제에 대한 인터페이스를 정의하고 첫 어댑터를 구현하세요.
4. AI에게 상위 5개 규칙(결제, 권한, 자격 등)에 대한 단위 테스트를 생성하게 하고 CI에서 실행하세요.
5. 규칙을 정하세요: 프레임워크 코드는 가장자리에(컨트롤러/라우트/뷰), 코어 로직 안에 있지 않게 합니다.

90일 동안(퇴로를 합리적으로 유지)

매 1–2주마다 경계를 재점검하세요:

• 중복 로직을 코어 서비스로 리팩터하세요.
• 어댑터를 얇게 유지하고 “한 번의 임시 해결”이 프레임워크 객체를 코어로 새지 않도록 하세요.
• AI가 코드를 생성할 때 계약과 인터페이스를 따르게 요구하고 직접 결합하는 코드는 거부하세요.

프로토타입에서 MVP로 이동하면서 포터블한 상태를 유지할 방법을 찾고 있다면 /pricing에서 계획과 제약을 검토할 수 있습니다.