교육 운영 매니저와 디자이너가 Slack에서 자연어로 랜딩 페이지 수정 요청을 남기면, 엔지니어 개입 없이 코드 수정, PR 생성, 프리뷰 배포, 결과 확인까지 이어지는 파이프라인을 구축한 프로젝트입니다. 단순히 AI로 코드를 고치는 것이 아니라, 반복적인 운영 요청이 매번 엔지니어에게 전달되던 구조를 바꾸는 것이 목표였습니다.
| 항목 | 내용 |
|---|---|
| 문제 | 랜딩 페이지의 반복 수정 요청이 모두 엔지니어를 거치던 구조 |
| 역할 | Slack 요청 인터페이스, 코드 수정·PR·프리뷰 배포 파이프라인, 자기 보완 루프 설계 |
| 핵심 성과 | 엔지니어 컨텍스트 스위칭 감소, 비엔지니어의 실제 운영 작업 자율 처리 검증 |
| 핵심 포인트 | 비엔지니어가 안심하고 요청하고 직접 확인할 수 있는 엔드투엔드 운영 흐름 구축 |
랜딩 페이지의 텍스트 수정, 이미지 교체, 강의자 정보 변경, 섹션 숨김 처리 같은 작업은 기술적으로 단순했습니다. 하지만 기존에는 모두 엔지니어에게 요청해야 했습니다. 특히 랜딩 페이지 오픈 직전과 직후에는 하루에도 수시로 수정 요청이 들어왔고, 엔지니어는 본래 업무를 멈추고 운영성 수정에 대응해야 했습니다.
문제는 개별 수정 작업의 난이도가 아니라 요청 처리 구조에 있었습니다. 요청자는 수정 결과를 확인하고 싶을 뿐이었지만, 그 확인 경로를 만들기 위해 매번 엔지니어의 손이 필요했습니다. 잦은 컨텍스트 스위칭이 누적되면서 엔지니어 생산성을 깎아먹는 구조적 문제로 보였습니다.
겉으로 보면 문제는 비개발 직군이 코드를 직접 고칠 수 없다는 점처럼 보였습니다. 하지만 실제로는 코드 수정 능력보다, 안심하고 요청하고 결과를 직접 확인할 수 있는 엔드투엔드 파이프라인이 없다는 점이 핵심이라고 보았습니다.
그래서 이 프로젝트는 비개발 직군에게 GitHub나 배포 도구를 직접 사용하게 만드는 방향이 아니라, 익숙한 Slack 안에서 요청을 시작하고 같은 대화 흐름 안에서 결과를 확인할 수 있는 운영 경로를 만드는 방향으로 설계했습니다.
교육 운영 매니저나 디자이너가 Slack에서 수정을 요청하면, 코드 수정, PR 생성, 프리뷰 배포, 결과 확인까지 자동으로 이어지도록 구성했습니다. 핵심은 요청 인터페이스를 쉽게 만들고, 배포 결과를 요청자가 직접 확인할 수 있게 하며, 처리하지 못한 패턴을 계속 보완하는 구조를 만드는 일이라고 보았습니다.
인턴 개발자 구르미Claude Code로 전달됩니다. Claude Code가 요청을 해석해 코드를 수정하고 PR을 만들면, GitHub Actions와 Vercel CLI가 프리뷰 배포를 실행합니다. 배포가 끝나면 프리뷰 URL을 원래 Slack 스레드로 돌려보내 요청자가 직접 결과를 확인할 수 있게 했습니다.skill과 instruction으로 내재화했습니다. 문구 변경, 이미지 교체, 강의자 정보 숨김, 섹션 노출 변경처럼 반복되는 요청을 기준으로 작업 기준을 보완해, 같은 유형의 다음 요청은 더 적은 엔지니어 개입으로 처리되도록 했습니다.skill과 instruction으로 축적되면서, 시간이 갈수록 엔지니어 개입 빈도가 줄어드는 구조가 자리잡았습니다.이 경험에서 확인한 것은 자동화의 핵심이 AI의 코드 생성 능력 자체는 아니라는 점이었습니다. 실제 운영 도구가 되려면 요청, 수정, 프리뷰 배포, 확인, 피드백이 하나의 사이클로 닫혀 있어야 한다고 생각합니다. 사용자가 그 흐름을 반복적으로 경험하며 신뢰할 수 있어야 비로소 업무 방식이 바뀝니다.
이 프로젝트의 의미는 자동화를 기능으로 붙인 데 있지 않았다고 생각합니다. 비개발 직군이 스스로 운영 요청을 시작하고 결과를 확인할 수 있는 장치를 만들고, 그 과정에서 반복 요청의 패턴을 시스템 안에 축적하는 운영 구조를 만든 데 의미가 있다고 봅니다.