AI로 코딩은 빨라졌는데 배포는 누가 책임지나: 인포그랩 Next Delivery Stack 2026 후기

"AI 도구는 누구나 도입합니다. 그런데 회사가 AI로 운영되는 경우는 드뭅니다." 9월 1일 인포그랩의 3rd 유저 컨퍼런스 Next Delivery Stack 2026(NDS 2026) 마지막 세션에서 띄운 문장입니다. 이날 무대에 오른 네 팀은 모두 같은 지점을 이야기했습니다. 코드와 자동화는 AI 덕분에 빨리 만들어지는데, 그걸 검증하고 현업에 퍼뜨리고 책임지는 구조는 그대로라는 점입니다. 현장에서 찍은 사진과 함께, 네 세션에서 가져온 내용을 "우리 팀에 적용하는 순서"로 다시 묶었습니다.

이 글은 이런 분께 필요합니다

• 사내에 AI 코딩 도구나 n8n 같은 자동화 도구를 깔았는데, 현업이 실제로 쓰는지 확신이 없는 팀 리드
• AI가 만든 코드와 자동화가 늘면서 리뷰, 보안, 배포 승인 기준을 다시 짜야 하는 플랫폼·DevOps 담당자
• "AI 도입 효과를 숫자로 보여 달라"는 요청을 받았지만 무엇을 재야 할지 모르는 실무자

사전 지식은 필요 없습니다. 각 단계 끝에 우리 팀에 적용하기 항목을 붙여 두었으니, 행사에 가지 않았어도 순서대로 따라 해 볼 수 있습니다.

행사 한눈에 보기

항목	내용
행사명	인포그랩 3rd 유저 컨퍼런스 Next Delivery Stack 2026
일시	2026년 9월 1일(화) 14:00–18:00
장소	서울 서초구 양재 엘타워 5F 오르체홀
올해의 질문	"AI가 코드를 짜는 시대, 우리는 무엇을 믿고 배포할 것인가"
세션	SK쉴더스, 콜마홀딩스, CJ올리브네트웍스, 인포그랩 4개
후원	GitLab, n8n, Teleport
참가 방식	무료, 신청자 중 추첨 초청(초청 규모 230명)

2024년 GitLab 유저 컨퍼런스, 2025년 DevSecOps 유저 컨퍼런스에 이은 세 번째 행사입니다. 작년까지는 GitLab과 DevSecOps가 중심이었다면, 올해는 제목부터 "딜리버리"로 바뀌었습니다. 만드는 속도보다 내보내는 과정에 초점을 맞췄다는 뜻입니다.

양재역 9번 출구에서 걸어서 3분 거리입니다. 엘타워 로비에는 같은 날 열린 다른 행사 배너도 함께 서 있어서, NDS 2026 배너를 확인하고 5층으로 올라갔습니다.

Step 1. AI가 만든 변경을 무엇으로 증명할지 먼저 정합니다

첫 세션은 SK쉴더스 ERP개발팀 신익훈 선임의 **"AI가 만든 변경, 운영 숫자로 증명하기"**였습니다. GitLab과 AI 개발·DevOps 분석 솔루션 Mantis를 바탕으로, AI 시대 DevSecOps에서 무엇을 보고 그것을 운영 성과와 KPI로 어떻게 설명했는지를 다룬 세션입니다.

이 세션은 슬라이드 사진을 남기지 못해 세부 수치는 옮기지 않겠습니다. 다만 세션 제목 자체가 이날 행사 전체의 출발점이었습니다. AI 도입 효과를 "빨라진 것 같다"는 느낌이 아니라 운영 지표로 말해야 위에서 투자를 이어 간다는 것입니다. 마지막 인포그랩 세션도 "무엇을 성과로 볼 것인가"가 가장 안 지켜진다고 짚었습니다(Step 5).

우리 팀에 적용하기

• AI 도입 전후로 비교할 지표를 2–3개만 정합니다. 예: 리뷰 대기 시간, 배포 빈도, 장애·롤백 건수
• 도입 전 기준값을 지금 기록해 둡니다. 기준값이 없으면 나중에 효과를 증명할 방법이 없습니다

Step 2. 도구 도입이 아니라 '확산 프로그램'을 설계합니다

두 번째 세션은 콜마홀딩스 DX전략2팀 김욱 팀장의 **"자동화가 늘어날수록, 운영의 눈이 필요하다"**였습니다. 첫 슬라이드의 질문이 날카로웠습니다.

혹시 n8n을 도입하셨나요? 그렇다면, 현업은 실제로 움직이고 있나요?

콜마홀딩스는 AI 활용을 실제 업무로 연결하려고 n8n을 선택했고, 그 과정을 도입(환경과 도구 준비) → 활성화(현업의 직접 사용) → 확산(팀과 조직으로 경험 전이) → 운영(지속 가능한 체계로 관리) 4단계로 나눠 설명했습니다.

핵심은 "확산을 프로그램으로 설계했다"는 슬라이드였습니다. 활성화를 일회성 교육으로 끝내지 않고, 참여가 실행으로 이어지고 다시 퍼지는 구조로 만들었다는 내용입니다.

단계	내용	의도
1. 교육	신규 도입 툴에 대한 교육	변화 관리의 출발점
2. 챌린지랩	공모형, 현업이 직접 과제 발굴	스스로 만드는 구조
3. 오픈랩	미선정 팀까지 4주 교육·멘토링	선정 밖의 열기까지 흡수해 제작자 확대
4. 지속	운영 시스템으로 전환	랩이 끝난 뒤에도 계속 유입되는 구조

실제 결과물로는 생산기록서 관리 자동화 시스템을 보여 줬습니다. 수작업에 의존하던 기록서 검토를 n8n 워크플로(Azure OCR, GPT 4.1 등)로 바꾼 사례입니다.

• Before: 수작업 의존 기록서 검토, 연간 작성 업무 소요시간 5,708시간, 재작성 등에 드는 연간 비용 약 1.5억 원, 육안 대조로 인한 휴먼 에러 리스크
• After: n8n과 GPT 4.1로 업무 자동화, 처리 시간 최대 6일 → 2일 단축, 출고 프로세스 향상, 재작성 편의성과 검토 효율 증대
• 공식: 현업의 업무 이해도 + AI 도구의 활용 + IT 부서의 구현 지원 = 실제 업무 활용도와 만족도 극대화

세션 후반부는 자동화가 늘어난 뒤의 운영 문제였습니다. 워크플로가 수십, 수백 개로 늘면 누가 무엇을 돌리는지 보이지 않게 되는데, 콜마홀딩스는 이를 n8n 운영 관리 플랫폼 Nelper로 관리하는 경험을 공유했습니다. 자동화 교육 관점에서 이 세션의 메시지는 분명했습니다. 교육은 1단계일 뿐이고, 현업이 직접 과제를 내고 만들고, 뽑히지 않은 팀까지 끌어안는 장치가 있어야 실제로 퍼진다는 것을 실제 수치와 함께 보여 줬습니다.

우리 팀에 적용하기

• 도입 교육 다음 단계를 미리 정합니다. "현업이 직접 과제를 내는 자리"가 없으면 교육만 하고 끝납니다
• 과제를 뽑을 때 떨어진 팀을 위한 경로(오픈랩 같은 짧은 멘토링)를 같이 만듭니다
• 자동화가 20개를 넘기 전에 목록, 담당자, 실행 상태를 한곳에서 보는 방법을 정합니다

Step 3. 파괴적 작업 앞에 사람 승인 게이트를 박아 둡니다

세 번째 세션은 CJ올리브네트웍스 품질혁신센터 조대휘 책임의 **"AI는 코드를 만들고, 플랫폼은 변화를 안착시킨다"**였습니다. CJ OliveNetworks DevOps Platform 위에서 AI-DLC(AI 기반 개발 생애주기)를 확산해 온 과정을 다뤘습니다.

AI-DLC의 정의는 한 문장이었습니다. 설계부터 운영까지 전 개발 생애주기에 AI Agent를 적용하고, 핵심 결정은 사람이 승인하는 개발 방법론입니다. 단계는 설계(Spec) → 개발(코드리뷰) → 테스트 → 오픈 전(품질·보안) → 운영(지식 자산화)이고, 원칙은 Human-in-the-loop: 파괴적 작업은 반드시 사람의 승인을 거친다였습니다.

실제 워크플로 도식을 보면 이 원칙이 어디에 들어가는지 정확히 보입니다.

• 승인 게이트는 설계, 머지, 프로덕션 배포 세 곳입니다. 나머지 구간은 에이전트가 진행합니다
• 테스트나 리뷰가 실패하면 Code Agent로 돌아가 자동 재작업하고, 정해진 횟수를 넘기면 운영자에게 에스컬레이션합니다
• 모든 에이전트의 LLM 호출은 LiteLLM을 거쳐 Langfuse로 자동 수집되고, 단계별 소요 시간·토큰 비용·테스트/보안 지표·배포 결과가 대시보드로 모입니다
• 에이전트가 Jira, GitLab, SonarQube, ArgoCD 같은 도구를 쓸 때는 MCP Gateway를 거치며, Secret Vault에서 최소 권한 토큰만 주입받습니다

사례로는 AWS 기반 LLM 게이트웨이 아키텍처도 공개했습니다. SSO(WorkSpaces·Direct Connect)로 들어온 요청이 EKS/Fargate 게이트웨이를 거쳐 Bedrock의 Anthropic 모델로 가고, Aurora·Valkey·Athena로 사용량을 관측하는 구조입니다.

우리 팀에 적용하기

• 지금 AI가 손대는 작업 중 되돌리기 어려운 것(프로덕션 배포, 강제 푸시, 데이터 삭제)을 적고, 그 앞에만 사람 승인을 둡니다
• AI 호출을 한 경로(게이트웨이)로 모아야 비용과 품질을 잴 수 있습니다. Step 1의 지표가 여기서 나옵니다
• 에이전트에게 주는 토큰은 작업별 최소 권한으로 나눕니다

Step 4. 우리 팀이 AI 활용 사다리 어디에 있는지 진단합니다

마지막은 인포그랩 신철호 CTO(Dexter)의 **"AI 에이전트가 제품을 딜리버리하는 루프"**였습니다. 표지 사진의 "AI 도구는 누구나 도입합니다" 문장이 이 세션의 시작입니다.

먼저 AI 활용 단계를 사다리로 보여 줬습니다(수치 출처는 AWS Clare Liguori의 "From AI-Assisted to AI-Native: Building a Frontier Development Team").

단계	이름	생산성
L0	대화형 보조 (AI Assistant)	L0–L3: 10–20% 향상
L1	맥락·도구 설정 (Context Engineering)
L2	도구·흐름 연결 (Agentic Workflow)
L3	코드·테스트 실행 (Agentic Coding)
L4	역할·게이트 설계 (Agentic Engineering)	L4–L5: 4.5배, 일부 팀 10배 이상
L5	루프 운영·결정 (Agentic Ops)

사다리를 오를수록 답해야 할 질문이 늘어납니다. 역할 정의와 대체 가능성에서 시작해, 업무 목록·시간 배분·입출력·협업·성과 기준, 그다음엔 기술 매핑·가드레일·성장 방향까지 가야 합니다. 슬라이드 하단의 빨간 문장이 이 단계의 핵심 질문이었습니다. "이 에이전트의 책임자는 누구이며, 보안과 통제를 어떻게 할 것인가."

사다리를 오를 때 부딪히는 세 가지도 정리했습니다.

1. 검증 비용: "거의 맞지만 틀린 답"이 가장 큰 좌절이라고 답한 비율 66%, AI 코드를 디버깅하는 데 더 걸린다는 응답 45%(Stack Overflow 2025). 요약하면 검증할 기준이 없다는 것
2. 컨텍스트: AI는 문제를 풀지만, 무엇이 문제인지는 정하지 못합니다. 결과는 할루시네이션과 오작성
3. 리뷰 형식화: 승인율 27.9% → 42.4%, 인라인 코멘트 -22%, 대기 시간 3.5배(독립 관찰연구 400명, 11,429건). 리뷰가 통과 절차가 되면서 품질 게이트 역할을 잃는다는 뜻

그리고 "이 셋은 도구를 하나 더 도입한다고 풀리지 않았습니다. 저희도 그렇게 해봤습니다."라는 말로 넘어갔습니다.

우리 팀에 적용하기

• 팀원 각자가 지금 L0–L5 중 어디에서 AI를 쓰는지 적어 봅니다. 대부분 L0–L1에 몰려 있다면 도구보다 맥락(문서, 규칙, 예시) 정리가 먼저입니다
• AI가 만든 MR의 승인율과 코멘트 수를 도입 전과 비교합니다. 승인율만 오르고 코멘트가 줄었다면 리뷰가 형식화되고 있다는 신호입니다

Step 5. 단계 자동화를 루프로 바꾸고, 사람 자리를 표로 적습니다

인포그랩이 말한 변화는 "단계 자동화에서 루프로"입니다. 예전에는 사람이 각 단계를 전달하고 AI가 한 단계씩 도왔다면, 이제는 하나의 에이전트가 이슈를 읽고, 코드를 쓰고, 실패를 확인하고, 다시 고치는 여러 단계를 이어서 수행합니다. 그래서 사람의 자리는 전달 관리에서 기준 설계로 옮겨 간다고 설명했습니다.

인포그랩의 루프는 두 축입니다. 만드는 축(발굴 → 검증 → 리뷰 → 개발 → 리뷰 게이트 → 배포)이 제품을 만들고, 닿게 하는 축(퍼블리싱 → 측정 → 학습)이 그 제품을 사용자에게 옮깁니다. 배포된 것만 닿게 하는 축으로 넘어가고, 학습 결과는 다음 실험으로 돌아갑니다.

가장 실용적이었던 슬라이드는 단계별로 사람과 에이전트의 몫을 나눈 표입니다.

단계	사람이 판단하는 것	에이전트가 하는 것
발굴·명세	문제, 최신성, 범위, 책임 경계	근거, 반대 근거, 중복, 준비도
설계	방향과 데이터, 비용의 경계, 조건부	옵션, 추천, 산출물 연결
개발	정책 예외가 없으면 자율	구현, 테스트, MR, 재작업
검증	조건부 정책, 위험 판단	기능·디자인·교차모델 QA
배포	밖으로 내보낼지 결정하는 책임	커밋 대조, 병합, 프로덕션 확인
관측	계속, 수정, 중단	D+7, D+30 증거 수집

"개발 단계에서는 사람의 역할이 더 줄어들고 있습니다"라는 설명처럼, 사람이 붙잡고 있어야 할 곳은 개발이 아니라 앞단의 문제 정의와 뒷단의 배포·관측 결정이었습니다.

실제 운영 화면도 보여 줬습니다. 에이전트들의 성공률과 유지관리 이력을 보는 Onramp("에이전트를 관리하는 에이전트")는 장애를 감지하면 원인을 판별하고 게이트웨이를 재기동해 복구한 뒤 Slack에 결과를 남깁니다.

Slack 스레드에서 에이전트에게 행사 오프닝 영상을 맡긴 사례도 있었습니다. 에이전트가 먼저 비용과 원본 권리 범위를 확인하고, 컷별 예상 비용 합계를 계산해 보고한 다음 제작에 들어갔습니다. "만들기 전에 기준부터 확인한다"는 앞의 표가 실제로 어떻게 돌아가는지 보여 주는 장면이었습니다. 덧붙이면 발표 자료 자체도 슬라이드 파일이 아니라 브라우저에 띄운 로컬 웹페이지였습니다.

마지막으로 두 축에서 사람이 지켜야 할 질문을 세 개씩 정리했습니다.

• 만드는 쪽: 만들 가치가 있나, 내보내도 되는 품질인가, 어디까지 열 것인가
• 닿게 하는 쪽: 무엇을 주장할 것인가, 작업 예산은?, 무엇을 성과로 볼 것인가

"한쪽이 비어 있으면, 그 비용은 반드시 나중에 청구됩니다. 가장 안 지켜지는 것은 오른쪽 세 번째입니다." Step 1의 SK쉴더스 세션 제목과 정확히 이어지는 지점입니다.

우리 팀에 적용하기

• 위 표를 복사해 우리 팀 업무 단계로 바꿔 채웁니다. "사람이 판단하는 것" 칸이 비어 있는 단계가 사고가 날 단계입니다
• 배포 후 D+7, D+30에 무엇을 확인할지 미리 적어 둡니다. 관측 기준이 없으면 계속·수정·중단을 결정할 수 없습니다
• 새 자동화를 시작할 때 3+3 질문 여섯 개에 한 줄씩 답한 뒤 착수합니다

마무리: 인포그랩이 정리한 다섯 문장

1. 생성은 싸졌고, 병목은 검증으로 옮겨졌습니다. 그런데 열에 일곱은 그 영향을 측정하지 않습니다
2. 질문이 바뀝니다. 무엇을 자동화할까에서, 어디서 멈추게 할까로
3. 저희의 경우, 루프는 만드는 축과 닿게 하는 축입니다. 루프는 업무에 따라 여러 축으로 설계할 수 있습니다
4. AI가 많은 일을 쉽게 해 줄수록, 이유와 책임을 세워야 합니다
5. 실패로 생긴 산출물은 고친 기준입니다. 다음 실행에서 어디서 멈출지를 더 분명히 합니다

네 세션을 이어 보면 순서가 생깁니다. 무엇으로 증명할지 정하고(SK쉴더스), 현업이 직접 만드는 확산 구조를 짜고(콜마홀딩스), 되돌릴 수 없는 작업 앞에 사람 승인을 두고(CJ올리브네트웍스), 남은 사람의 자리를 기준 설계로 옮기는 것(인포그랩)입니다. AI 도구를 하나 더 들이기 전에 이 네 가지 중 비어 있는 칸부터 채우는 편이 빠릅니다.

자주 막히는 지점과 행사에서 본 해법

증상	원인	행사에서 본 해법
도구는 깔았는데 현업이 안 씀	교육으로 끝나고 직접 만들 기회가 없음	챌린지랩·오픈랩처럼 현업이 과제를 내고 만드는 프로그램 (Step 2)
자동화가 늘수록 누가 뭘 돌리는지 모름	운영 관리 체계 없이 확산	목록·담당자·실행 상태를 한곳에서 관리 (Step 2)
AI가 만든 MR이 그냥 승인됨	리뷰 형식화, 검증 기준 부재	승인율·코멘트 수 비교, 리뷰 게이트를 기준으로 재정의 (Step 4)
AI가 프로덕션을 건드릴까 불안함	승인 지점이 정해지지 않음	설계·머지·Prod 3개 사람 승인 게이트 (Step 3)
AI 도입 효과를 설명 못 함	도입 전 기준값, 관측 경로 없음	LLM 호출 단일 경로 수집, 운영 지표로 보고 (Step 1, 3)
배포 후 계속할지 판단이 안 섬	관측 기준 부재	D+7, D+30 증거 수집 기준을 미리 정함 (Step 5)

발표 자료와 영상은 행사 후 발표자 동의 범위 안에서 인포그랩 공식 홈페이지에 공개될 예정이라고 안내됐습니다. 행사 정보는 Next Delivery Stack 2026 공식 페이지에서 볼 수 있습니다.