Vibe Coding을 개인 실험이 아니라 조직의 개발 방식으로 인정하려면 “AI가 얼마나 잘 만드는가”보다 “잘못 만들었을 때 어디에서 막을 것인가”를 먼저 정해야 한다. 특히 안정성과 책임 추적이 중요한 서비스에서는 자연어 요청이 곧바로 임의의 코드 변경으로 이어지는 구조를 받아들이기 어렵다.

뱅크샐러드는 기술 블로그에서 자유도와 안정성을 동시에 확보하기 위한 방법으로 Salad Game DSL을 소개했다. 제공된 자료만으로 DSL의 문법이나 내부 구현을 단정할 수는 없지만, AI가 다룰 수 있는 문제 공간을 도메인 언어로 제한한다는 방향 자체는 프로덕션 AI 도입에 중요한 시사점을 준다.

Vibe Coding이 조직 안에서 ‘합법’이 되려면

여기서 합법은 법률적 판단이라기보다 조직이 승인한 개발 경로라는 의미에 가깝다. 어떤 작업을 AI에 맡길 수 있는지, 어떤 검증을 통과해야 하는지, 누가 최종 책임을 지는지, 장애가 발생하면 어떻게 되돌릴지를 합의해야 한다.

단순히 “AI 도구 사용 가능”이라는 정책만 선언해서는 부족하다. 도구가 저장소 전체를 수정하거나 외부 서비스와 자격 증명에 접근할 수 있다면, 문서상의 제한과 실제 권한 사이에 큰 간극이 생긴다. 허용 범위는 실행 가능한 규칙으로 내려가야 한다.

따라서 Vibe Coding의 운영 모델에는 최소한 변경 대상의 경계, 기계적으로 검사할 수 있는 산출물, 필수 리뷰 단계, 테스트와 롤백이 포함돼야 한다. 지원 범위를 넘어선 요구는 AI가 임의로 해결하는 대신 담당 엔지니어에게 넘기는 것이 안전하다.

DSL은 어떻게 통제 지점이 되는가

DSL은 특정 도메인에 필요한 개념과 동작만 표현하는 언어다. 범용 프로그래밍 언어보다 표현 공간이 작기 때문에, AI가 생성할 수 있는 결과의 형태를 줄이고 조직이 예상 가능한 단위로 리뷰하기 쉬워진다.

일반적인 구조를 가정하면 사람은 의도를 제시하고, AI는 허용된 DSL 표현을 작성하며, validator는 유효하지 않거나 금지된 조합을 거부한다. 이후 조직이 관리하는 실행 계층이 승인된 표현을 실제 동작으로 연결한다. 이는 DSL 기반 접근을 설명하기 위한 일반 모델이며, Salad Game DSL의 구체적인 내부 구조를 설명하는 것은 아니다.

이 방식의 장점은 생성 모델과 실행 권한을 분리할 수 있다는 점이다. AI에는 승인된 요소를 조합할 자유를 주되, 새 의존성 추가나 비밀 정보 접근, 배포 설정 변경처럼 위험도가 높은 작업은 언어 자체에서 표현하지 못하게 설계할 수 있다.

그러나 DSL이라는 이름만으로 안전성이 확보되지는 않는다. 임의 코드를 실행하는 우회 기능이 있거나 validator가 의미적 오류를 잡지 못한다면 위험은 그대로 남는다. parser, runtime, 리소스 권한, 버전 호환성까지 하나의 플랫폼으로 관리해야 한다.

안전한 생성부터 배포까지 필요한 단계

공개된 요약만으로 뱅크샐러드의 실제 배포 파이프라인을 재구성할 수는 없다. 아래 단계는 같은 접근을 검토하는 팀이 사용할 수 있는 권장 프레임이며, 뱅크샐러드의 내부 운영 절차에 대한 사실 설명은 아니다.

1. 도메인 한정: 반복적이고 결과를 쉽게 확인할 수 있는 작업부터 고르고, 민감한 작업은 명시적으로 제외한다.
2. DSL 초안 생성: AI가 범용 코드를 직접 변경하지 않고 승인된 표현만 만들도록 제한한다.
3. 정적 검증: 잘못된 구조, 존재하지 않는 참조, 금지된 조합과 지원하지 않는 버전을 실행 전에 차단한다.
4. 동작 검증: 테스트나 격리된 프리뷰를 사용해 결과를 확인한다. 문법적으로 유효하다는 사실은 기능이 올바르다는 뜻이 아니다.
5. 책임 있는 승인: 리뷰어, DSL 버전, 생성 조건, 테스트 결과와 배포 결정을 추적 가능하게 기록한다.
6. 관측과 복구: 배포 후 실제 동작을 살피고 즉시 되돌릴 수 있는 경로를 유지한다.

프롬프트가 의도를 전달한다면 권한과 검증, 복구 체계는 그 의도가 안전하게 실행되도록 만든다. 이는 웹 AI 에이전트의 프로덕션 통제에서도 동일하게 적용되는 원칙이다.

오류의 출처도 구분해야 한다. 모델이 부적절한 표현을 제안한 경우, DSL 명세가 필요한 기능을 담지 못한 경우, validator에 결함이 있는 경우, runtime이 실패한 경우는 해결 방법이 모두 다르다. 이를 전부 AI 오류로 묶으면 개선해야 할 계층을 찾을 수 없다.

도입 전에 확인해야 할 비용과 실패 조건

DSL은 복잡성을 없애기보다 다른 위치로 옮긴다. 문법, 문서, 편집 도구, 오류 메시지, 테스트, 실행 엔진과 호환성 정책을 지속해서 관리할 팀이 필요하다. 대상 도메인이 자주 바뀌거나 예외가 너무 많다면 범용 코드보다 유지 비용이 커질 수 있다.

• 표현력: 주요 작업을 우회 기능 없이 표현할 수 있는가?
• 예측 가능성: 승인된 표현이 항상 테스트 가능한 동작으로 이어지는가?
• 진단성: 오류 메시지를 개발자와 AI가 실제 수정에 활용할 수 있는가?
• 호환성: 언어가 바뀌었을 때 기존 산출물은 어떻게 처리되는가?
• 권한: runtime이 접근할 수 있는 데이터와 서비스, 부수 효과는 무엇인가?
• 소유권: 명세와 실행 계층, 장애 대응을 어느 팀이 맡는가?

효과 역시 생성 속도만으로 평가해서는 안 된다. 검증 단계의 거부율, 리뷰에서 발견된 결함, 배포 실패, 복구 시간과 유지보수 비용을 함께 봐야 한다. 웹 시스템의 성능을 판단할 때도 메모리·스토리지·비용을 측정 가능한 기준으로 다루는 것처럼, Vibe Coding도 운영 데이터로 판단해야 한다.

첫 적용 범위는 작고 되돌릴 수 있어야 한다. 출력 결과를 즉시 프리뷰할 수 있고 실패 영향이 제한적인 도메인에서 검증한 뒤, 통제 장치가 실제 결함을 잡는다는 근거가 쌓일 때만 확장하는 편이 합리적이다.

결론

• 뱅크샐러드는 Salad Game DSL로 Vibe Coding의 자유와 안정성을 함께 다루는 방향을 제시했다.
• DSL의 핵심 가치는 AI 산출물의 표현 범위를 줄이고 검증 가능한 형태로 만드는 데 있다.
• DSL만으로 정확성이나 보안이 보장되지는 않으며 테스트, 리뷰, 권한 통제와 롤백이 필요하다.
• 작은 도메인에서 시작해 운영 지표를 확인한 뒤 범위를 넓혀야 한다.

관련 글

• 브라우저 네이티브 API가 인터랙티브 웹 개발을 바꾸고 있다
• 웹 캐시 최적화의 기준이 메모리·스토리지·비용 측정으로 바뀐다
• 웹 AI 에이전트의 프로덕션 운영에 프롬프트 외 무엇이 필요한가

참고 자료

뱅크샐러드에서 합법적으로 Vibe Coding 하는 법