LLM 지원 배포: 타이핑은 절약돼도 사고는 절약되지 않는다

발행: (2026년 6월 6일 PM 10:24 GMT+9)
7 분 소요
원문: Dev.to

Source: Dev.to

TL;DR

LLM이 배포 스크립트를 약 한 시간 만에 만들어 주었지만, 배포 자체를 모델에게 맡기지는 않았기 때문에 가능한 일이었다.
나는 배포 스크립트를 어떻게 쓰는지 안다. 이론적인 수준이 아니라 여러 차례 직접 작성해 봤고, 보통은 앉아서 바로 코딩한다.
이번에 문제가 된 것은 **‘어떻게 쓰느냐’**가 아니라 **‘시간’**이었다. 그리고 나는 과정 중에 뭔가를 망가뜨리는 걸 전혀 원하지 않았다.
그래서 “LLM이 깔끔하게 다 만들어 줄 거야”라는 게임을 하지 않았다. 반자동 배포에서는 그게 오히려 최악의 선택이다. 아름다운 결과 대신 바닥에 부서진 사이트가 놓여 있게 된다.
나는 다른 방법을 택했다.

  1. 스크립트 구조를 직접 정의했다. 이전 경험을 바탕으로 배포가 해야 할 일, 경계, 제어 포인트, 성공 기준, 진행을 멈춰야 할 상황을 모두 적어 놓았다.
  2. 그 텍스트를 LLM에 입력해 bash 스크립트를 작성하도록 했다.

즉, 모델이 도와준 부분은 오류 비용이 상대적으로 낮은 영역, 즉 코드를 타이핑하는 작업이었다.
가격이 붙는 모든 작업—결정, 리뷰, 로직 검증, 안전한 환경에서 실행—은 여전히 수동으로 진행했다.

결과적으로 두 개의 스크립트를 얻었다: deploy-preprod.shdeploy-production.sh.

이 구분은 나에게 의미가 있었다. 프로덕션은 바로 “go” 하면 안 된다. 먼저 프리프로덕션 게이트를 통과하고, 그 다음에 프로덕션으로 넘어가야 한다. 또한 나는 프로덕션 배포 확인을 위해 텍스트 캡차 같은 트릭을 유지한다. 스크립트가 콘솔에 무작위 코드를 출력하고, 사용자가 직접 입력하기 전까지는 아무 일도 진행되지 않는다. 이는 악의적인 해커를 막기 위한 것이 아니라, “그냥 바로 배포하자”는 과도하게 쉬운, 기계적인 충동을 방지하기 위한 것이다.

네 번의 반복을 거쳤다. 이는 접근 방식이 나쁘다는 뜻이 아니라, 오히려 좋은 징후다.

반복 과정에서 나타난 문제들은 전형적인 배포 위험 요소였다: 오타, 잘못된 변수, 로그 파싱 오류 등. 개념적으로 흥미로운 부분은 없었고, 코드는 꽤 간결했다. 아이러니하게도 코드는 LLM이 작성했는데, 마치 세계 정복에 집중하느라 급하게 만든 듯했다.

내 검증 방식도 “괜찮아 보인다” 수준이 아니었다. 컨테이너가 시작된 뒤에는 docker‑compose 로그를 자동으로 스캔해 명백한 오류 신호를 찾고, 이후 수동으로 스모크 체크—로그인 후 주요 흐름을 직접 확인—를 수행했다. e2e 테스트도 고려했지만 이번 작업에는 과도하다고 판단했다. 내가 필요했던 것은 완벽한 자동화가 아니라, 명시적인 제어 포인트와 예측 가능한 실패 동작을 가진 재현 가능한 배포였다.

스크립트를 구체적으로 보면 “가속”과 “제어권 위임” 사이의 경계가 명확해진다:

  • 프리프로덕션은 배포 전 정확히 프로덕션 사이트와 동일한 복사본을 만든다(사이트가 작기 때문에 가능).
  • 프로덕션은 최신 버전으로 실행되지 않는다.
  • 동일한 태그에 대해 무작위 배포(no‑op)는 허용되지 않는다.
  • 프로덕션 전에 프리프로덕션 게이트가 실행되고, 프리프로덕션이 불만이면 실패한다.
  • Postgres가 올라오지 않으면 명시적으로 실패한다.
  • 로그에서 error, exception, traceback, panic, fatal 등을 검사한다.
  • 프로덕션 전에는 수동 확인이 필요하다.

따라서 LLM이 “배포를 수행한” 것이 아니라, 내가 정의한 구조와 제약 조건에 맞춰 코드를 조립하도록 도와준 것이다.

전체 소요 시간은 약 한 시간 정도였다.

LLM은 시간을 절약해 주었지만, 많은 사람들이 기대하는 책임, 엔지니어링 결정, 검증 영역에서는 절대 대체하지 못한다. 초안 단계—키보드를 두드리는 작업—만을 압축했을 뿐이다. 핵심적인 부분은 여전히 수동적인 엔지니어링 작업이었다.

이와 같은 작업에 적합한 건전한 LLM‑보조 모드는 다음과 같다: 위험을 모델에 위임하지 말고, 기계적인 부분을 없애는 데 활용해 아키텍처와 실수 비용이 큰 제어 포인트에 더 많은 주의를 기울이자.

한 분의 생각이 한 시간의 가동 시간을 늘린다.

0 조회
Back to Blog

관련 글

더 보기 »

모바일 한여름 열풍

!Cover image for Mobile Midsommer Madnesshttps://media2.dev.to/dynamic/image/width=1000,height=420,fit=cover,gravity=auto,format=auto/https%3A%2F%2Fdev-to-uploa...