운영 요구에 large 구성이 필요한데 사용자가 small을 골라도 배포해도 될까요. 반대로 저장소에 이미 Dockerfile이 있는데 모델이 새 파일부터 만들 필요가 있을까요. Shakedown에서 저장소를 받아 이미지와 배포 구성으로 연결하면서, 생성 품질보다 먼저 이런 실행 규칙을 정해야 했습니다.
저는 Dockerfile 생성에는 규칙을 먼저 쓰고, 인프라 선택에는 서버가 검사할 수 있는 카탈로그를 두었습니다. 실제 호출에서는 규칙이 처리하지 못한 Flask 입력을 3.679초 응답 뒤 빌드·HTTP 200까지 연결했고, large 요구에서 small을 고른 요청은 400으로 거부했습니다. 두 결과는 각각 생성 경로와 실행 전 검사가 작동했는지 확인한 근거입니다.
SoftBank Hackathon의 Emerald 팀에서 만든 Shakedown은 저장소 분석, 이미지 생성, 배포, HTTP 시운전을 연결하는 서비스입니다. 저는 PostgreSQL 샘플과 로컬 Target API에서 시작해 엔진 통합, 이미지 생성 순서, 선택한 AWS 계획의 적용과 복구 검증을 맡았습니다. 여기서는 예측 가능한 부분은 규칙으로 처리하고, AI의 판단을 허용된 선택지 안으로 제한한 과정을 설명합니다.
Dockerfile이 있는데도 모델부터 호출할 필요는 없었습니다
생성 순서는 기존 Dockerfile, 지원 스택 규칙, 규칙 실패 때 Claude 1회, 생성 결과 검증, 별도 소스 복사본에서 빌드로 정했습니다. 기존 입력이나 규칙으로 처리할 수 있는 저장소까지 처음부터 모델에 맡기지 않았습니다.
| 단계 | 맡기는 일 | 다음 단계로 넘어가는 조건 |
|---|---|---|
| 기존 Dockerfile | 저장소가 제공한 빌드 방법 사용 | 기존 파일이 없는 경우 규칙 검토 |
| 지원 스택 규칙 | 알려진 구성에서 생성 | 규칙으로 처리하지 못한 이유 확보 |
| Claude fallback | 실패 진단과 제한된 분석 정보로 보완 | 허용 형식과 검증 조건 충족 |
| 결과 검증·빌드 | 실제 빌드 가능성 확인 | 원본을 덮어쓰지 않는 별도 복사본 사용 |
규칙이 실패한 다음에는 실패 이유가 모델의 입력이 됩니다. 모델에 원본 코드·README·환경변수 전체를 보내는 대신 제한된 분석 정보와 실패 진단을 전달했습니다. 근거가 부족한 상황에서 반드시 파일을 만들어 내게 하면 추측이 실행 대상으로 넘어갈 수 있어 null도 허용했습니다. 출력이 생겨도 검증과 별도 복사본의 빌드를 거쳐야 합니다. 이 순서는 이미지 생성 PR #11에 포함됐습니다.
소스 코드만으로 운영 요구를 알아낼 수는 없었습니다
코드가 같아도 피크 트래픽과 허용 중단 시간은 다를 수 있습니다. 저장소 분석만으로 이를 추정해 정답처럼 실행하지 않도록 사용자 운영 입력을 받았습니다. 먼저 규칙으로 최소 등급을 정하고, 모델은 소·중·대 템플릿과 근거 ID 안에서 판단하게 했습니다.
이 방식은 임의의 IaC를 생성하는 것보다 지원 범위가 좁습니다. 대신 모델이 제안할 수 있는 자원·권한·비용의 범위와, 서버가 실행 전에 다시 검사할 항목을 정할 수 있습니다. 카탈로그는 실행 가능한 선택지이지, 적힌 등급이 특정 처리량을 보장하는 시험 성적표는 아닙니다.
생성 성공과 잘못된 선택의 거부를 따로 확인했습니다
2026년 10월 9일 실제 AI 호출 보고서에서 규칙이 지원하지 않는 Flask 입력을 fallback으로 처리했습니다. 각 시간은 단일 호출의 관측값입니다.
| 시험 | 관측 |
|---|---|
| Flask fallback 1회 | 응답 3.679초, Docker 빌드와 HTTP 200 확인 |
| small 판단 1회 | 3.876초 |
| medium 판단 1회 | 4.551초 |
| large 판단 1회 | 4.434초 |
| large 요구에서 small 선택 | 400으로 거부 |
| 같은 요구에서 large 선택 | 200으로 수용 |
Flask 시험은 규칙 밖의 입력도 제한된 fallback으로 빌드까지 갈 수 있음을 보여 줬습니다. 반면 small/large 대조는 추천 결과를 보여 주는 것과 실행을 허용하는 것이 분리돼 있음을 확인했습니다. 모델이 답했더라도 서버가 허용하지 않는 선택은 배포로 넘어가지 않았습니다.
시간은 각 1회의 관측값이므로 속도 개선율이나 모델 품질을 비교하는 수치는 아닙니다. 생성 파일의 형식과 금지 요소를 검사하는 것 또한 실행 샌드박스를 제공하는 것은 아닙니다.
팀 기반 위에서 맡은 경계
HTTP 시운전과 규칙·Claude 원인 보고서는 김태현, 초기 ECS·ALB·RDS 어댑터와 공유 세션 기반은 김재환, 초기 보안 게이트와 다국어 기본 보완은 김도경의 기여입니다. 저는 이 기반을 연결하면서 기존 파일→규칙→모델의 순서, 운영 요구의 입력, 서버가 거부할 선택을 정하고 실제 호출·배포 경로로 확인했습니다. 조사·구현·실험 실행에는 AI를 활용했습니다. 고정 커밋의 작업 회고에서 범위를 확인할 수 있습니다.
개인 PR #2·#5·#10·#11·#12·#29·#31은 2026년 10월 15일 기준 팀 저장소에 병합됐습니다. 이는 외부 오픈소스의 정식 릴리스 성과와 다른 종류의 결과이며, UI부터 검사·LLM·AWS까지 하나로 이어진 전체 E2E 성공을 의미하지도 않습니다.
이 구조에서는 모델의 출력만으로 실행 권한이 생기지 않습니다. 기존 파일과 규칙으로 처리할 수 있는 작업은 그 경로를 사용하고, 부족한 부분만 모델에 묻습니다. 운영 요구를 만족하지 않는 선택은 서버가 거부합니다. 덕분에 생성 결과를 검토할 범위와 실패 시 멈출 위치를 구체적으로 정할 수 있었습니다.