비개발자가 AI로 만든 화면을 운영에 올리기 전: 아정당의 격리 구조

아정당 플랫폼 FE챕터 리드 장순우 님은 2026년 9월 9일 아정당 기술 블로그(Medium)에 "코드를 모르는 동료에게 서비스를 통째로 맡겼습니다"라는 글을 올렸습니다. 'AI Native Process 구축기' Part 1로, 개발자가 아닌 직원이 AI로 만든 화면을 매일 운영 사이트에 올릴 수 있게 하려고 개발팀이 먼저 만든 격리 구조를 설명합니다. 아래 사례와 수치는 모두 아정당과 저자의 것이고, 마지막 부분에 AX 교육 관점의 제 해석을 덧붙였습니다.

문구 한 줄에 최소 1주가 걸리던 구조

저자에 따르면 아정당 웹사이트는 1주나 2주에 한 번 정기배포를 했고, 그 사이의 변경은 아무리 작아도 다음 배포를 기다렸습니다. 문구 한 줄을 바꾸는 데에도 요청자, 기획자, 디자이너, 개발자, QA 엔지니어까지 최소 5명이 필요했다고 적었습니다. 저자는 이 주기를 하나의 앱에서 안정성을 지키려는 선택으로 설명했고, 병목은 개발 실력이나 코드 품질보다 이해관계자의 업무 시간 부족에 있었다고 봤습니다.

AI 빌더, 호스트, 리모트

글에 나오는 'AI 빌더'는 개발자가 아니고 코드를 직접 쓰지 않는 직원입니다. 저자는 이들이 터미널에서 Claude와 대화하며 앱을 만든다고 설명했습니다. 게시일 기준으로 이사, 청소, 인테리어, 상조, 보험 5개 서비스의 화면이 이 방식으로 운영되고 있다고 밝혔습니다.

'호스트'는 아정당 웹사이트를 운영하는 기존 앱입니다. 도메인, 로그인, 결제, 상담 접수, 검색 색인, 전역 트래킹이 모두 여기에 있습니다. '리모트'는 AI 빌더가 만드는 앱으로, 서비스 하나에 앱 하나씩 별도 저장소와 별도 도메인으로 배포됩니다. 저자는 이 구조를 MFE(Micro Frontend, 프론트엔드를 독립 배포 가능한 단위로 쪼개는 아키텍처)라고 불렀습니다. 저자는 이렇게 되면 개발팀의 역할이 기능을 직접 추가하는 일에서 기능을 만들 수 있는 환경을 구축하는 일로 옮겨 간다고 썼습니다.

리뷰 대신 구조로 막는 격리

저자는 개발자와 AI 빌더 사이에 리뷰 과정이 없기 때문에 실수를 막는 일을 사람 대신 프로세스에 맡겨야 한다고 설명합니다. 그래서 먼저 만든 장치가 격리입니다. 규칙 문서에 하지 말라고 적는 방식을 쓰지 않고, 하려고 해도 안 되게 만드는 쪽을 골랐다고 했습니다.

운영 사이트에 올리기 전 장치. 각 상자의 내용은 장순우 님 글(아정당 기술 블로그, 2026년 9월 9일)에 나온 설명이고, 격리·계약·검증으로 나눠 묶은 구성은 작성자가 정리했습니다.

저자 팀이 고른 방식은 서버가 HTML 조각을 받아 합성하는 방식입니다. 여러 HTML 조각을 서버에서 합쳐 화면을 만드는 방식은 Cam Jackson이 2019년 martinfowler.com에 정리한 마이크로 프론트엔드 통합 방식에도 나옵니다. 격리에는 브라우저 표준 기능을 썼습니다. 리모트 화면을 Custom Element와 Shadow DOM 안에 넣어 브라우저가 경계를 강제하게 하고, Declarative Shadow DOM으로 서버 렌더링과 검색 노출을 지켰다고 합니다. web.dev 설명에 따르면 Shadow DOM은 CSS 스타일 적용 범위를 특정 하위 트리로 한정해 문서의 나머지 부분과 격리합니다. Google Search Central 문서는 Google이 페이지를 렌더링할 때 shadow DOM과 light DOM 내용을 평평하게 합쳐 보고, 렌더링된 HTML에 보이는 내용만 색인한다고 설명합니다.

저자 팀은 다른 방식도 검토했습니다. iframe은 격리만 보면 가장 좋지만 서버 렌더링과 검색 노출 요구를 맞추지 못했다고 했습니다. Module Federation은 PoC까지 했지만, 저자 팀이 검토할 당시 공식 Vite 플러그인의 Nuxt SSR 지원이 로드맵 항목이었고, 런타임 의존성을 공유하는 방식이라는 점도 걸려 채택하지 않았다고 밝혔습니다. 최종 선택 이유로는 성능이나 코드의 깔끔함보다, 이미 운영 중인 호스트에서 고칠 곳이 가장 적다는 점을 들었습니다.

계약과 검증

리모트가 호스트와 주고받을 수 있는 통로는 클릭 트래킹, 화면 이동, 폼 접수, 상담 신청, A/B 노출, 외부 링크 열기, 에러로 정해져 있고, AI 빌더가 새 통로를 만들 방법은 없다고 합니다. 계측은 호스트만 하고, 신뢰 경계에서는 허용 목록(화이트리스트)을 기본값으로 둡니다. 검색 결과의 대표 주소를 정하는 canonical 값은 리모트가 실수로 채워 보내도 공통 모듈이 응답 직전에 잘라 냅니다. 리모트 서버가 보내는 응답은 html, seo, entryUrl, version, setCookieDirectives, layoutHints 6항목으로 정해 두었습니다.

장치	아정당 구현(저자 설명)	막는 문제
격리	Custom Element·Shadow DOM, 서비스별 별도 배포	리모트 실수가 호스트 화면·기능에 번지는 일
통로 제한	정해진 이벤트 채널만 허용	임의의 데이터 전달, 계측 중복
응답 계약	6항목 응답, canonical 제거	검색 설정·쿠키를 리모트가 마음대로 바꾸는 일
배포 검증	PR마다 프리뷰 배포, CI가 빌드와 규칙 위반 검사	규칙을 어긴 코드가 운영에 나가는 일

검증 단계는 PR마다 프리뷰 배포를 하고 CI가 빌드와 규칙 위반을 검사하는 방식입니다. PR을 머지하면 바로 운영에 배포되고, 저자는 이로써 글 첫머리의 "최소 1주"가 사라진다고 썼습니다. 변경 뒤 반영까지 걸리는 시간 수치는 원문에 없습니다. 저자는 대가도 밝혔습니다. 호스트가 리모트 안쪽 요소에 직접 리스너를 걸 수 없으므로, 호스트가 전역 클릭 리스너로 감지하던 동작이 있었다면 더 이상 동작하지 않는다고 설명합니다. 규모로는 사이트맵에 올라간 리모트 URL이 약 1,340개이고, 그중 사람이 직접 등록한 경로는 4개라고 적었습니다. 검색 색인용 사이트맵을 켠 리모트만 센 숫자이며 집계 시점은 원문에 없습니다.

제가 보기에는

비개발자 대상 바이브코딩 교육은 보통 화면을 만들어 공개 주소에 올리는 데서 끝납니다. 아정당 사례는 그 화면을 회사 운영 사이트에 올리려면 개발팀이 격리, 정해진 주고받기 형식, 자동 검사를 먼저 준비했다는 점을 보여 줍니다. 저자가 정기배포를 비판하지 않고 안정성을 위한 선택으로 설명한 점도 눈여겨볼 만합니다. 사내에서 "직원이 AI로 만든 화면을 운영에 바로 올리자"는 이야기가 나오면, 도구 교육보다 격리·계약·검증 장치를 누가 만들고 관리할지부터 정해야 한다고 봅니다. 원문은 Part 1이고, 개인정보와 에러 알림 처리는 저자가 다음 글에서 다루겠다고 예고했습니다.

이번 주에 해 볼 첫 단계

AI로 만들어 운영에 올리고 싶은 사내 화면 1개를 골라, 그 화면이 기존 시스템에서 필요로 하는 것(로그인 정보, 결제, 개인정보, 방문 기록 수집)을 적어 보십시오. 그다음 화면이 기존 시스템과 주고받아야 할 항목만 표로 정리하고, 표에 없는 것은 주고받지 못하게 하려면 무엇이 필요한지 개발 담당자와 이야기해 보면 됩니다. 배포 전에 자동으로 확인할 규칙도 3개만 먼저 정해 두십시오.