AI 코딩 데모는 대개 빈 폴더에서 시작합니다. 새 프로젝트, 최신 프레임워크, 로컬에 있는 파일들.
현실의 많은 개발은 그렇지 않습니다. 코드가 서버 안에 있고, 설정은 GUI 화면에서 하고, 팀만 아는 규칙이 수십 년 쌓여 있습니다. 이런 곳에서도 바이브 코딩이 될까요?
AWS for SAP 블로그에 올라온 아모레퍼시픽 사례는 이 질문에 대한 꽤 구체적인 답입니다. 2026년 10월 21일 자 글이고, 원래 AWS 코리아 기술 블로그에 한국어로 먼저 실렸습니다.
출발점: AI가 손댈 수 없는 것들
아모레퍼시픽 ERP 플랫폼 기획팀의 시스템은 SAP ECC 6.0 EHP7, NetWeaver 7.40 위에서 돕니다. 개발자는 SAP GUI에서 ABAP을 쓰고, 프런트엔드는 SAPUI5로 만듭니다.
글은 AI 코딩 도구를 막는 장벽을 하나씩 꼽습니다.
- SAP 작업의 상당 부분이 SE11, SPRO, PFCG 같은 GUI 기반 설정이라 AI 코딩 도구가 자동화할 수 없습니다.
- ABAP 코드가 로컬 파일이 아니라 SAP 서버에 있습니다.
- 프로젝트를 시작한 2025년 8월에는 공식 SAP MCP 서버가 없었습니다.
- ECC는 S/4HANA보다 ADT 지원이 제한적이라, 생성한 코드를 시스템에 다시 써넣는 일이 기술적으로 까다롭습니다.
- SAPUI5 프런트엔드는 표준이 아닌 사내 프레임워크입니다.
목록을 보면 '프롬프트 하나로 앱 만들기'와는 거리가 멉니다. 모델이 아무리 똑똑해도 이 맥락을 모르면 엉뚱한 코드를 만듭니다.
왜 스펙이었나
팀이 Kiro를 고른 주된 이유는 스펙 기반 개발이었습니다. 이 팀은 원래 코드보다 기능 명세서(FS)와 기술 명세서(TS)를 먼저 쓰는 순서로 일해 왔습니다. 그 순서와 맞았기 때문에, Jira 기반의 기존 업무 흐름을 바꾸지 않고 AI를 들일 수 있었다고 합니다.
새 도구에 맞춰 일하는 방식을 바꾼 게 아니라, 일하는 방식에 맞는 도구를 고른 셈입니다.
Kiro 문서가 말하는 스펙은 세 파일입니다. 무엇을 만들지 적는 requirements.md, 기술 구조를 적는 design.md, 실행 가능한 작업 목록인 tasks.md입니다. 작업을 한꺼번에 돌리면 Kiro가 의존성 그래프를 만들어 서로 독립적인 작업을 '웨이브'로 묶어 동시에 실행한다고 적혀 있습니다.
두 모드의 분업
이 사례에서 가장 배울 만한 부분은 모드를 나눈 기준입니다.
스펙 모드는 새 프로그램과 복잡한 기능에 씁니다. Jira 티켓과 FS/TS 문서를 입력으로, 요구사항 → 설계 → 작업의 3단계를 거쳐 스펙 문서 세 개와 ABAP·SAPUI5 코드를 냅니다.
바이브 모드는 기존 프로그램의 변경과 버그 수정에 씁니다. 개발자가 채팅으로 바꿀 내용을 설명하면 Kiro가 기존 스펙 문서를 참고해 고칩니다. 그래서 바이브 모드에는 조건이 붙습니다. 스펙 문서가 이미 있어야 합니다.
이 조건이 핵심입니다. 바이브 코딩이 큰 코드베이스에서 약하다는 건 Kiro도 스스로 인정하는 부분입니다. 복잡한 작업이나 큰 코드베이스 위에서는 너무 많은 안내가 필요할 수 있다고요. 이 팀은 그 약점을 스펙으로 메웠습니다. 한 번 스펙을 만들어 두면 그 뒤의 변경은 가벼운 대화로 처리합니다.
맥락은 두 갈래로 넣었다
모델이 SAP 환경과 팀 규칙을 알게 하는 장치는 두 가지였습니다.
하나는 SAP 전용 MCP 서버입니다. 공식 서버가 없던 시기라 AWS 솔루션 아키텍트가 만든 서버를 썼고, 고른 이유로 안정성과 장기 유지보수를 들었습니다. 사내 RFC 함수 모듈, 명명 규칙, SAPUI5 프레임워크 패턴을 모델에 넘겨줍니다.
다른 하나는 스티어링 파일입니다. 팀의 코딩 표준을 담았습니다. TOP·F01·C01 인클루드 패턴, ALV 리포트 뼈대, 선택 화면 정의, SAPUI5의 IIFE 패턴 같은 것들입니다.
MCP 서버가 '시스템이 어떻게 생겼나'를, 스티어링 파일이 '우리는 어떻게 쓰나'를 맡은 셈입니다. 이 연재 3편의 표현을 빌리면, 둘 다 모델이 저장소를 읽어서는 알 수 없는 것들입니다.
숫자는 어떻게 읽을까
결과로 제시된 숫자는 이렇습니다. 네 개 프로젝트에서 생산성이 최대 72% 올랐고, 문서화 시간은 80% 줄었습니다.
이 숫자 옆에 놓인 비교 대상이 흥미롭습니다. 프로젝트 전에 팀이 직접 분석한 추정치는 SAP 맥락과 팀 규칙 없이 AI 코딩 도구만 쓸 경우 20~30% 향상이었습니다.
그러니 이 사례가 말하는 건 "AI 도구를 쓰면 72%가 오른다"가 아닙니다. 도구만으로는 20~30%였을 것을, 맥락을 넣어서 끌어올렸다에 가깝습니다. '최대'라는 단어도 놓치면 안 됩니다. 네 프로젝트의 값이 모두 72%였다는 뜻은 아닙니다. 그리고 이 숫자들은 고객과 AWS가 함께 낸 글에 실린 자체 측정치입니다.
개발자의 역할은 "요구사항을 정의하고 생성된 코드를 리뷰하는" 쪽으로 옮겨 갔다고 적혀 있습니다. 레거시 현대화에서 AI가 대신해 주는 건 타이핑이고, 맥락을 정리하는 일은 오히려 늘어납니다. 그 정리가 문서로 남는다는 점이 이 사례의 진짜 소득일지도 모릅니다.
