AI가 쓴 코드를 먼저 돌려볼 곳: 테스트 월드와 체크 사용법
플림솔(Plimsoll)이라는 Show HN 글이 올라왔다. AI 에이전트가 쓴 코드를 돌려보는 셀프호스팅 샌드박스다. 해커뉴스 사람들은 한 줄 설명만 보고 바로 이해했다. 에이전트는 사람이 읽는 속도보다 빠르게 코드를 쓰니까, 내 노트북이 아닌 곳에서 먼저 돌려보자는 얘기다.
근데 노트북을 격리하는 건 쉬운 쪽이다. 어려운 건 그다음이다. 코드가 괜찮아 보여서 배포된 다음. 에이전트가 기능을 만들고 한 시간 뒤에 돈 내는 고객에게 그대로 나간다면, 샌드박스는 가장 필요한 순간에 사라진 셈이다.
돈코드에서 그 두 번째 샌드박스가 테스트 월드다. 실제로 어떻게 쓰는지 정리했다.
1. 기능은 하나씩 빌드한다
Features 페이지를 연다. 모든 기능에 상태가 붙어 있다. 계획됨, 빌드 중, 완료. 계획된 항목 하나만 골라서 Build를 누른다. 다섯 개가 아니라 하나. 빌드 하나는 읽을 거리도 하나라서, 체크가 실패했을 때 원인이 바로 보인다.
2. 같이 써진 체크를 읽는다
기능이 만들어지는 동안 인사이트가 평범한 문장으로 체크를 쓰고, 그 기능 아래에 붙여둔다. 코드가 아니라 문장이다. "로그인하지 않은 방문자가 문의 폼을 보낼 수 있다." "스태프가 주문을 환불할 수 있다."
문장 앞부분을 보자. 모든 체크는 누구로 실행되는지 이름을 갖는다. 앱의 역할 중 하나, 아니면 로그아웃 상태의 방문자. 대충 넘기기 쉬운 부분인데, 실제로 일하는 부분이 여기다.
3. 그 사람으로 앱을 열어본다
Features 페이지 상단의 역할 칩이 에디터에서 가장 빠른 버튼이다. 하나 누르면 실제 앱이 새 탭에서 열린다. 테스트 월드에서, 그 역할로 로그인된 상태로.
테스트 월드는 데이터의 별도 사본이다. 앱의 실제 페이지를 보고 만든 샘플 데이터가 들어가 있고, 실행 전마다 그 상태로 초기화된다. 지워도 되고, 가짜 주문을 환불해도 되고, 회원가입을 일부러 망가뜨려도 된다. 실제 사용자나 실제 데이터에는 아무것도 닿지 않는다. 체크가 돌아가는 곳도 정확히 여기라서, 내가 보는 화면이 체크가 보는 화면이다.
4. 빌드가 막히는 걸 한 번 겪어본다
여기가 핵심이다. 모든 빌드는 라이브로 가기 전에 테스트 월드에서 검사된다. 체크가 실패한 변경은 정해진 횟수만큼 수리를 시도하고, 그래도 실패하면 Live 앞에서 멈춘다. 라이브 앱은 그대로 유지된다. History의 Checked 단계에 실패한 체크 문장이 그대로 뜨니까, 스택 트레이스가 아니라 "스태프가 다른 고객의 주소를 볼 수 없다"를 읽게 된다.
아무도 쓰지 않아도 항상 검사되는 것들도 있다. 앱이 빌드되는지, 모든 페이지가 열리는지, 쓰고 있는 서비스가 응답하는지.
5. 새 체크는 사람이 정한다
첫 실행부터 실패한 체크는 빌드를 막지 않고 "확인 필요"로 간다. 실패한 그 커밋을 보고 쓰인 체크라서 그렇다. Keep이나 Stop checking을 누르면 된다. 중단하려면 이유를 적어야 하고, 그 이유는 그 줄에 남는다. 인사이트는 체크를 쓰고 결과를 읽을 수 있지만, 지울 방법은 없다. 이 비대칭이 설계의 전부다.
써보고 생긴 의견 하나. 쓸 가치가 있는 체크는 부정형이다. "고객이 자기 주문을 볼 수 있다"도 좋지만, 나를 구해주는 건 "고객이 남의 주문을 볼 수 없다"다. 에이전트는 기능을 동작시키는 데는 능숙하고, 그 기능에 누가 또 닿을 수 있는지에는 무심하다.
체크와 테스트 월드는 인사이트 프로젝트의 Pro, Enterprise 기능이다. 자세한 내용은 체크 문서와 테스트 월드 문서에 있고, 전체 기능 목록은 /ko/docs/features에 있다.