2025년 10월 30일·7분
AI 생성 코드로 초기 프레임워크 락인 줄이기
AI 생성 코드를 이용해 핵심 로직을 분리하고 실험을 빠르게 하며 나중의 마이그레이션 비용을 낮춰 초기 프레임워크 락인을 줄이는 방법을 알아보세요.
AI 생성 코드를 이용해 핵심 로직을 분리하고 실험을 빠르게 하며 나중의 마이그레이션 비용을 낮춰 초기 프레임워크 락인을 줄이는 방법을 알아보세요.
프레임워크 락인은 제품이 특정 프레임워크(또는 벤더 플랫폼)에 너무 깊이 묶여 나중에 변경하는 것이 회사 전체를 재작성하는 것처럼 느껴지는 상태를 말합니다. 단순히 “우리는 React를 쓰고 있다” 또는 “Django를 선택했다”를 넘어, 프레임워크의 관습이 비즈니스 규칙, 데이터 접근, 백그라운드 작업, 인증, 파일명 규칙 등 모든 곳에 스며들어 결국 프레임워크 자체가 애플리케이션이 되는 상황입니다.
락인된 코드베이스는 비즈니스 결정이 프레임워크 특유의 클래스, 데코레이터, 컨트롤러, ORM, 미들웨어에 박혀 있는 경우가 많습니다. 그 결과: 다른 웹 프레임워크로 이전하거나 데이터베이스 계층을 바꾸거나 서비스를 분리하는 것과 같은 작은 변경조차도 거대한, 위험한 프로젝트가 됩니다.
락인은 보통 초기에는 “프레임워크를 따라가는 것이 가장 빠르다”는 이유로 발생합니다. 프레임워크를 쓰는 것이 속도를 높이는 것은 맞지만, 문제는 프레임워크 패턴이 구현 세부 사항으로 남지 않고 제품 설계 그 자체가 될 때 시작됩니다.
초기 제품은 압박 속에서 만들어집니다: 아이디어를 검증하려고 경쟁하고, 요구사항은 주 단위로 바뀌며, 작은 팀이 온보딩부터 청구까지 모든 것을 처리합니다. 이런 환경에서는 패턴을 복사해 붙이고, 기본값을 수용하고, 스캐폴딩이 구조를 지시하게 하는 것이 합리적입니다.
하지만 이런 초기 단축이 빠르게 누적됩니다. ‘MVP-플러스’ 단계에 이르렀을 때 핵심 요구사항(멀티테넌트 데이터, 감사 로그, 오프라인 모드, 새로운 통합 등)이 원래 프레임워크 선택에 맞지 않는다는 것을 발견할 수 있습니다.
프레임워크를 영원히 피하려는 것이 목적은 아닙니다. 목표는 제품이 실제로 무엇을 필요로 하는지 배울 수 있을 만큼 옵션을 열어두는 것입니다. 프레임워크는 교체 가능한 컴포넌트여야 하며, 핵심 규칙이 머무는 장소가 되어서는 안 됩니다.
AI 생성 코드는 인터페이스, 어댑터, 검증, 테스트 같은 깔끔한 이음(seams)을 스캐폴드하는 데 도움을 줘 초기 프레임워크 결정을 “굳히지” 않고도 빠르게 작업할 수 있게 해주므로 락인을 줄이는 데 기여할 수 있습니다.
하지만 AI가 아키텍처를 대신 선택해주지는 않습니다. “기능을 만들어줘”라고만 요청하면 AI는 종종 프레임워크의 기본 패턴을 따라갈 것입니다. 따라서 방향을 정하는 것은 여전히 당신의 몫입니다: 비즈니스 로직을 분리하고, 의존성을 격리하며, 변화를 염두에 두고 설계하되 빠르게 배포하세요.
AI 개발 환경(단순 에디터 보조가 아니라)을 사용 중이라면 이런 제약을 더 쉽게 강제할 수 있는 기능을 찾으세요. 예를 들어 Koder.ai는 미리 경계를 명시할 수 있는 플래닝 모드를 제공하고(예: “core는 프레임워크 임포트 없음”), 소스 코드 내보내기를 지원해 포터블성을 유지하고 툴링 결정에 묶이지 않도록 도와줍니다.
프레임워크 락인은 의도적인 선택으로 시작하는 경우가 드뭅니다. 보통은 “그냥 배포하자”는 작은 결정들이 수십 개 쌓여 조용히 코드베이스의 가정으로 굳어지면서 생겨납니다.
자주 반복되는 패턴은 다음과 같습니다:
requests, sessions, ORM 모델 등)를 직접 호출하고 자체 얇은 추상화를 사용하지 않음AI 생성 코드는 이런 사고 과정을 가속화할 수 있습니다: “작동하는 코드”를 요청하면 종종 가장 관용적인 프레임워크-네이티브 구현을 만들어주므로 속도는 빨라지지만 의존성도 예상보다 빨리 굳어질 수 있습니다.
락인은 몇몇 고중력 영역에 자주 형성됩니다:
락인이 항상 나쁜 것은 아닙니다. 속도가 중요할 때 프레임워크를 선택하고 그것에 기대는 것은 합리적인 트레이드오프일 수 있습니다. 문제는 우발적 락인—의도치 않게 커밋해버렸고, 코드에 다른 프레임워크나 모듈이 끼어들 수 있는 깔끔한 이음(seams)이 남아있지 않은 경우입니다.
AI 생성 코드는 보통 프롬프트로부터 함수, 파일 스캐폴드, 테스트, 리팩터 제안, 작은 기능을 만들어내는 도구들(예: ChatGPT 또는 에디터 내 보조 도구)을 말합니다. 빠른 패턴 매칭과 제공한 컨텍스트를 결합해 결과물을 내주지만, 마법같지는 않습니다.
프로토타입에서 MVP로 넘어갈 때 AI는 제품을 정의하지 않는 반복적 작업에서 가장 유용합니다:
이렇게 사용하면 AI는 경계(비즈니스 규칙 대 프레임워크 글루)에 집중할 시간을 벌어주어 락인 압박을 줄여줍니다.
AI는 신뢰할 수 있게 다음을 수행하지 못합니다:
일반적인 실패 모드는 ‘동작한다’는 이유로 편리한 프레임워크 기능을 많이 사용하는 코드가 만들어져 나중에 조용히 마이그레이션을 어렵게 만드는 것입니다.
AI 생성 코드를 주니어 동료의 첫 시도라고 생각하세요: 유용하지만 검토가 필요합니다. 대안들을 요청하고, 프레임워크-불가지론(agnostic) 버전을 요구하며, 병합 전에 핵심 로직이 포터블(portable)한지 확인하세요.
유연성을 유지하려면 프레임워크(Next.js, Rails, Django, Flutter 등)를 전달층(delivery layer) 으로 취급하세요—HTTP 요청 처리, 화면, 라우팅, 인증 연결, 데이터베이스 배관을 담당하는 부분입니다.
당신의 핵심 비즈니스 로직은 배달 방식이 바뀌어도 변하지 않아야 할 것들입니다: 가격 규칙, 인보이스 계산, 자격 확인, 상태 전이, “관리자만 인보이스를 취소할 수 있다” 같은 정책. 이런 로직은 웹 컨트롤러, 모바일 버튼, 백그라운드 작업 등 무엇에 의해 트리거되는지 알 필요가 없어야 합니다.
결합을 방지하는 실용적인 규칙은:
프레임워크 코드가 당신의 코드를 호출하고, 그 반대는 아니어야 한다.
따라서 컨트롤러가 규칙으로 가득 찬 대신, 컨트롤러는 얇게 유지하세요: 입력 파싱 → 유즈케이스 모듈 호출 → 응답 반환.
AI 보조자에게 비즈니스 로직을 제품이 수행하는 행동 이름을 가진 평범한 모듈로 생성하라고 요청하세요:
CreateInvoiceCancelSubscriptionCalculateShippingQuote이 모듈들은 평범한 데이터(DTO)를 받고 결과나 도메인 오류를 반환해야 합니다—프레임워크의 request 객체나 ORM 모델, UI 위젯에 대한 참조는 없어야 합니다.
AI 생성 코드는 이미 핸들러 안에 난잡하게 섞여 있는 로직을 순수한 CreateInvoice 서비스로 추출하는 데 특히 유용합니다. 지저분한 엔드포인트를 붙여넣고: “입력 검증과 명확한 반환 타입을 가진 순수 CreateInvoice 서비스로 리팩터해; 컨트롤러는 얇게 유지”라고 요청해 보세요.
비즈니스 규칙이 프레임워크 패키지를 임포트한다면(라우팅, 컨트롤러, React 훅, 모바일 UI 등) 계층이 섞여 있는 것입니다. 반대로 생각하세요: 의존성이 프레임워크 쪽으로 흐르도록(프레임워크가 코어를 호출) 유지하면 코어 로직을 교체하기 쉬워집니다.
어댑터는 애플리케이션과 특정 도구/프레임워크 사이에 위치하는 작은 번역기입니다. 코어는 당신이 소유한 인터페이스(예: EmailSender 또는 PaymentsStore)와 통신하고, 어댑터가 프레임워크가 그 작업을 어떻게 수행하는지의 세부 사항을 처리합니다.
이 방식은 도구 교체를 집중적인 변경으로 줄여줍니다: 전체 제품을 바꾸는 것이 아니라 어댑터만 교체하면 됩니다.
락인이 초기 단계에서 자주 스며드는 곳은:
HttpClient / ApiClient 뒤에 숨김이 호출들이 코드베이스에 흩어져 있을 때 마이그레이션은 “전부 건드리기”가 되지만, 어댑터를 쓰면 “모듈 하나 교체”로 줄어듭니다.
AI는 여기 필요한 반복적 스캐폴딩(인터페이스 + 구체 구현 한 쌍)을 만들어내는 데 훌륭합니다.
예: 다음을 생성하도록 프롬프트하세요:
publish(), subscribe())를 가진 인터페이스(Queue)SqsQueueAdapter)InMemoryQueue)설계는 당신이 검토하지만, AI는 보일러플레이트로 몇 시간을 절약할 수 있습니다.
좋은 어댑터는 지루합니다: 최소한의 로직, 명확한 오류, 비즈니스 규칙 없음. 어댑터가 너무 똑똑해지면 락인을 다른 장소로 옮긴 것뿐입니다. 비즈니스 로직은 코어에 두고 어댑터는 교체 가능한 배관으로 유지하세요.
프레임워크 락인은 종종 단순한 단축에서 시작합니다: UI를 만들고 편리한 데이터/API 형태에 바로 연결한 뒤 나중에 모든 화면이 동일한 프레임워크-특정 데이터 모델을 가정하게 되는 상황입니다.
“계약 우선” 접근법은 그 순서를 뒤집습니다. 엔드포인트를 연결하기 전에 제품이 의존할 계약들(요청/응답 형태, 이벤트, 핵심 데이터 구조) 을 정의하세요. 예를 들어 “CreateInvoice의 입력은 무엇인가?” 또는 “Invoice가 보장해야 하는 것은 무엇인가?” 같은 질문을 먼저 던지세요, ‘프레임워크가 이를 어떻게 직렬화하는가’가 아니라.
OpenAPI, JSON Schema, GraphQL 스키마 같은 포터블한 형식을 사용하세요. 이는 제품의 안정적인 중심축이 됩니다—UI가 Next.js에서 Rails로 바뀌더라도, API가 REST에서 다른 방식으로 바뀌더라도 말이죠.
스키마가 존재하면 AI는 다음과 같은 일관된 산출물을 생성하는 데 특히 유용합니다:
이렇게 하면 비즈니스 로직이 프레임워크 요청 객체가 아니라 내부 타입과 검증된 입력에 의존하게 되어 프레임워크 결합을 줄일 수 있습니다.
계약을 제품 기능처럼 다루세요: 버전 관리하세요. 가벼운 버전 관리(/v1 vs /v2 또는 invoice.schema.v1.json)만으로도 필드를 대규모로 한 번에 바꾸지 않고 진화시킬 수 있습니다. 전환 기간 동안 두 버전을 모두 지원하고 소비자를 점진적으로 마이그레이션하세요.
테스트는 초기 단계에서 락인을 막는 최고의 도구 중 하나입니다—좋은 테스트는 구현이 아니라 동작을 설명하기 때문입니다. 테스트 스위트가 “이 입력이 들어오면 우리는 이 출력을 만들어야 한다”고 분명히 명시하면, 프레임워크를 나중에 바꾸더라도 훨씬 적은 두려움으로 교체할 수 있습니다.
프레임워크 락인은 비즈니스 규칙이 프레임워크 관습과 얽힐 때 자주 발생합니다. 강한 단위 테스트 세트는 이 규칙들을 드러내고 포터블하게 만들어 줍니다. 마이그레이션(또는 리팩터)할 때 테스트가 계약이 되어 동작을 유지했음을 증명해줍니다.
AI는 특히 다음을 생성하는 데 유용합니다:
실무 워크플로: 함수와 그 규칙에 대한 짧은 설명을 붙여넣고 AI에게 경계값과 ‘이상한’ 입력을 포함한 테스트 케이스를 제안하라고 하세요. 제안된 케이스를 검토하면 AI가 빠르게 범위를 넓혀줍니다.
유연성을 유지하려면 많은 단위 테스트, 적은 수의 통합 테스트, 그리고 소수의 E2E 테스트를 권장합니다. 단위 테스트는 빠르고 저렴하며 특정 프레임워크에 덜 묶입니다.
테스트가 전체 프레임워크 부팅, 커스텀 데코레이터, 특정 에코시스템의 무거운 모킹 유틸리티를 필요로 하면 테스트가 또 다른 락인이 됩니다. 순수 함수와 도메인 서비스에 대한 평범한 어설션을 선호하고, 프레임워크 특화 와이어링 테스트는 최소화하세요.
초기 제품은 실험처럼 행동해야 합니다: 작게 만들고, 측정하고, 배운 것에 따라 방향을 바꾸라. 위험은 첫 프로토타입이 조용히 ‘제품’이 되어버려 초기의 프레임워크 선택이 되돌리기 어려운 비용이 되는 것입니다.
AI 생성 코드는 다양한 옵션을 빠르게 탐색하는 데 이상적입니다: React로 간단한 온보딩 흐름을 만들어보거나 서버 렌더링 버전을 비교해보거나, 두 결제 제공자를 시험해보고, 같은 기능에 대해 다른 데이터 모델을 시도해볼 수 있습니다. AI는 몇 분 안에 작동 가능한 스캐폴딩을 만들어주므로 처음 배포된 스택에 회사의 운명을 걸지 않고도 선택지를 비교할 수 있습니다.
핵심은 의도입니다: 프로토타입에 대해 임시라고 라벨을 붙이고, 미리 무엇을 검증할지 결정하세요(예: “사용자가 3단계를 완료하는가?” 또는 “이 워크플로는 이해하기 쉬운가?”). 답을 얻으면 프로토타입은 본연의 역할을 한 것입니다.
짧은 시간 제한(보통 1–3일)을 정해 프로토타입을 만들고 테스트하세요. 시간 상자가 끝나면 선택하세요:
이렇게 하면 ‘프로토타입 글루’(임시 해결, 복사-붙여넣기, 프레임워크 특유의 단축)가 장기적인 결합으로 바뀌는 것을 막을 수 있습니다.
코드를 생성하고 조정할 때는 가벼운 결정 로그를 남기세요: 시도한 것, 측정한 것, 왜 선택(또는 거부)했는지. 제약 조건도 캡처하세요(예: “기존 호스팅에서 실행되어야 함”, “향후 SOC2 필요”). /docs나 프로젝트 README의 간단한 페이지면 충분하며, 미래 변경을 계획된 반복처럼 느껴지게 해줍니다.
초기 제품은 주 단위로 바뀝니다: 명명, 데이터 형태, ‘사용자’의 의미까지도. 성장 후에 리팩터를 미루면 프레임워크 선택이 비즈니스 로직으로 굳어집니다.
AI 생성 코드는 이름 변경, 헬퍼 추출, 파일 재구성, 경계 뒤로 코드 이동 같은 반복적이고 위험이 적은 편집에 능하므로 조기에 리팩터하는 데 도움을 줍니다. 잘 사용하면 구조적 결합이 생기기 전에 결합을 줄일 수 있습니다.
먼저 변경하세요—나중에 제품을 이동하기 쉽게 만드는 부분들:
BillingService, InventoryService처럼 컨트롤러, ORM 모델, 프레임워크 요청 객체를 임포트하지 않는 서비스로 추출NotFound, ValidationError 같은 자체 오류 타입으로 대체하고 경계에서 변환되돌릴 수 있는 증분으로 리팩터하세요:
이 ‘한 번의 변경 + 녹색 테스트’ 리듬은 AI를 유용하게 쓰되 제어권을 잃지 않게 도와줍니다.
전체 리포지토리에 걸친 “아키텍처 현대화” 같은 대규모 생성 리팩터를 AI에게 요구하지 마세요. 큰 생성 디프는 스타일 변경과 동작 변경을 섞어 버려 버그를 찾기 어렵게 만듭니다. 검토할 수 없을 만큼 큰 diff는 신뢰할 수 없습니다.
마이그레이션을 계획하는 것은 비관적 태도가 아니라 보험입니다. 초기 제품은 빠르게 방향을 바꿀 수 있습니다: 프레임워크를 바꾸거나 모놀리스를 분리하거나 인증을 컴플라이언스 가능한 방식으로 전환할 수도 있습니다. 퇴로(exit)를 염두에 두고 설계하면 보통 더 깔끔한 경계가 생기며 설사 그대로 남더라도 이득입니다.
마이그레이션은 가장 얽혀 있는 부분들이 곳곳에 퍼져 있을 때 실패하거나 비용이 커집니다:
이 영역들은 많은 파일을 건드리기 때문에 작은 불일치가 증폭되어 매우 끈적거리는 문제가 됩니다.
AI 생성 코드는 ‘마이그레이션을 수행’하기보다는 구조를 만드는 데 유용합니다:
/blog/migration-checklist에 두세요.핵심은 코드가 아니라 단계와 불변 조건(invariants) 을 요구하는 것입니다.
모든 것을 다시 쓰는 대신 새 모듈을 기존 것 옆에 두고 실행하세요:
이 접근법은 이미 명확한 경계가 있을 때 가장 잘 작동합니다. 예제와 패턴은 /blog/strangler-pattern 및 /blog/framework-agnostic-architecture를 참고하세요.
마이그레이션을 하지 않더라도 얻는 이점: 숨은 의존성 감소, 더 명확한 계약, 놀라운 기술 부채 감소입니다.
AI는 많은 코드를 빠르게 내줄 수 있고, 동시에 프레임워크의 가정을 코드 전반에 퍼뜨릴 수도 있습니다. 목표는 “덜 신뢰하라”가 아니라 검토하기 쉽게 하고 핵심 제품이 특정 스택에 우연히 결합되지 않도록 만드는 것입니다.
AI 보조 코드가 포함된 모든 PR에 반복 가능한 짧은 체크리스트를 사용하세요:
Request, DbContext, ActiveRecord, Widget 등 금지). 코어 코드는 도메인 용어로 말해야 합니다: Order, Invoice, UserId.강제 가능한 수준으로 단순하게 유지하세요:
core/, adapters/, app/ 같은 폴더 경계를 정의하고 규칙을 둡니다: “core는 제로 프레임워크 임포트.”*Service(비즈니스 로직), *Repository(인터페이스), *Adapter(프레임워크 글루).AI에게 코드를 요청할 때는 다음을 포함하세요:
/core에 생성, 프레임워크 임포트 금지”),AI 플랫폼의 ‘계획 후 생성(plan then build)’ 워크플로우가 있는 경우, 플래닝 모드에 이런 제약을 적어두면 생성된 변경을 스냅샷/롤백하면서 검토하기 쉬워집니다(예: Koder.ai).
포매터/린터와 기본 CI 검사(간단한 “lint + test” 파이프라인)를 하루 이내에 설정하세요. 결합을 바로 잡아 초기 습관으로 굳는 것을 방지합니다.
프레임워크에 묶이지 않는 것은 프레임워크를 피하는 것이 아니라 속도를 위해 사용하되 퇴로(exit)의 비용을 예측 가능하게 유지하는 것입니다. AI 생성 코드는 빠르게 움직이게 도와주지만, 유연성은 당신이 이음(seams)을 어디에 두느냐에 달려 있습니다.
초기부터 다음 네 가지 전술을 염두에 두세요:
이 단계가 커지기 전에 다음을 완료하는 것을 목표로 하세요:
/core(또는 유사 폴더)를 만들어 비즈니스 로직을 보관하고 프레임워크 임포트 없음을 지키세요.매 1–2주마다 경계를 재점검하세요:
프로토타입에서 MVP로 이동하면서 포터블한 상태를 유지할 방법을 찾고 있다면 /pricing에서 계획과 제약을 검토할 수 있습니다.
프레임워크 락인(혹은 종속성)은 제품의 핵심 동작이 특정 프레임워크나 벤더의 관습(컨트롤러, ORM 모델, 미들웨어, UI 패턴 등)과 분리할 수 없게 된 상태를 말합니다. 이 단계가 되면 프레임워크를 바꾸는 것이 단순한 교체가 아니라 비즈니스 규칙이 프레임워크 개념에 의존하게 되어 사실상 재작성(rewrite)이 됩니다.
다음과 같은 징후들이 보이면 락인이 진행 중일 가능성이 큽니다:
Request, ORM 베이스 모델, UI 훅 등)마이그레이션이 “모든 파일을 건드려야 하는 작업”처럼 느껴진다면 이미 락인된 상태일 가능성이 높습니다.
초기 팀은 불확실성 속에서 속도를 최우선으로 합니다. 가장 빠른 길은 보통 프레임워크의 기본 방식을 따르는 것이고, 그 결과 프레임워크 관습이 제품 설계 자체가 되어버릴 수 있습니다. 이런 단축은 누적되기 쉬워서 MVP를 넘긴 시점에 새로운 요구사항이 기존 선택에 맞지 않는 것을 발견하곤 합니다.
네—적절하게 사용하면 락인을 줄일 수 있습니다. 핵심은 AI를 경계(seams)를 만드는 도구로 활용하는 것입니다:
AI는 프레임워크를 가장자리에 두고 규칙을 코어에 남기도록 지시할 때 가장 큰 도움을 줍니다.
AI는 보통 가장 관용적인(idiomatic) 프레임워크 네이티브 구현을 제안하는 경향이 있어 제약을 주지 않으면 프레임워크 고착화를 가속할 수 있습니다. 이를 피하려면 다음처럼 제약을 명확히 하세요:
/core에 생성하되 프레임워크 임포트 없음”그 후 ORM 모델, 데코레이터, Request/Session 사용 등 숨은 결합을 검토하세요.
간단한 규칙 하나를 따르세요: 프레임워크 코드는 당신의 코드를 호출해야지, 그 반대가 되어서는 안 된다.
실무적으로는:
CreateInvoice, CancelSubscription 같은 모듈에 규칙을 두세요코어 로직이 프레임워크를 부팅하지 않고도 스크립트로 실행될 수 있다면 올바른 방향입니다.
어댑터는 코드와 특정 툴/프레임워크 사이의 작은 번역기입니다. 코어는 당신이 정의한 인터페이스(예: EmailSender, PaymentsGateway, Queue)에 의존하고, 어댑터가 벤더 SDK나 프레임워크 API로 이를 구현합니다.
이렇게 하면 마이그레이션은 전체 비즈니스 로직을 고치는 대신 특정 어댑터만 교체하면 됩니다.
먼저 안정적인 계약(요청/응답, 이벤트, 도메인 객체의 스키마/타입)을 정의한 뒤 그에 따라 생성하는 방법입니다. 구체적으로:
이렇게 하면 UI/API가 ORM 모델이나 프레임워크 직렬화에 직접 결합되는 것을 피할 수 있습니다.
테스트는 동작(behavior) 를 서술하므로 리팩터나 마이그레이션을 안전하게 해줍니다. 우선순위는:
모든 테스트가 프레임워크 전체를 부팅해야만 수행된다면 테스트 자체가 또 다른 락인이 될 수 있으니 피하세요.
AI로 생성된 코드가 숨은 락인을 늘리지 않게 하려면 PR에서 다음 가드레일을 점검하세요:
또한 생성된 변경이 너무 크면 분할해 제출하세요—대규모 AI 리팩터는 동작 변경을 감추기 쉽습니다.