지난 5월 27일과 6월 10일, 요즘IT는 '클코나잇 2' 웨비나를 개최했습니다. 지난해 진행한 클코나잇 시즌 1에 이어, 이번 웨비나에서는 개발자와 비개발자를 포함한 다양한 직군의 실무자들이 클로드 코드(Claude Code)를 업무에 활용한 경험을 공유했는데요. 참가자들은 "고수의 경험을 나눠 받을 수 있는 기회", "찐 실무자의 현장감 넘치는 사례", "다음에 또 오고 싶은 웨비나" 등의 반응을 보였습니다. 이번 글에서는 아쉽게도 참석하지 못한 분들을 위해, 웨비나의 핵심 내용만 모아 콘텐츠로 정리했습니다.

클코나잇 2 웨비나에서 '클로드 코드로 5일 만에 웹 포털 런칭한 방법'을 정리한 것입니다. 발표 자료는 요즘IT 디스코드에서 다운로드 받을 수 있습니다.

안녕하세요. 클코나잇 2 두 번째 연사로 함께하게 된 이현입니다. 오늘 발표할 주제는 비개발자 기획자였던 제가 어떻게 현업에서 돌아가는 웹 포털을 5일 만에 런칭하고 운영할 수 있었는가에 대한 이야기입니다.

간단히 제 소개를 먼저 드리면, 저는 이전에 IT 기업 DX 전략팀을 거쳐 현재는 교육기업에서 AX 전략팀 기획자로 근무하고 있습니다. 주로 스레드나 뉴스레터로 간간이 AX에 대한 생각과 경험을 공유하고 있습니다. 오늘 전해드릴 이야기는 크게 클로드 코드로 웹 시스템을 만드는 것, 운영하는 것, 그리고 지속 가능하게 하는 것, 이 세 가지 파트로 나눠 말씀드리려고 하는데요.

그중에서도 만드는 것을 넘어 운영 단계에서 마주친 어려움과, 그 이슈 또한 클로드 코드로 해결해 나간 이야기를 중점적으로 전달드리고자 합니다.

첫 AX 과제: 슬랙 기반 정산 비효율

먼저 이 프로젝트의 배경이 궁금하실 텐데요. 이 일은 제가 AX 전략팀에서 일하고 있다 보니 첫 AX 과제로 진행하게 된 일이었습니다. 제가 해결해야 했던 과제는 슬랙 기반의 정산 비효율을 해결하는 것이었는데요. 이 배경을 더 깊게 설명드리기 전에, 제가 생각하는 AI 활용의 스펙트럼을 먼저 언급할 필요가 있을 것 같습니다. 저는 개인적으로 이 스펙트럼을 세 단계로 구분하고 있습니다.

1단계, 채팅형 활용: 챗봇 형태로 쓰면서 업무에 간헐적인 도움을 받는 단계입니다.
2단계, 에이전트 활용: 클로드 코드 같은 에이전트로 조직이 함께 쓸 수 있는 업무 시스템을 만들거나 자동화해 보는 단계입니다.
3단계, 동료로서의 AI: 궁극적인 단계로, AI가 조직의 맥락 전체를 아는 상태에서 회사의 업무 흐름에 얼라인되어 정말 저희의 동료로서 역할할 수 있는 단계라고 생각합니다.

이번 프로젝트는 이 중 두 번째 단계, 즉 바이브 코딩을 통해 AI 코딩 에이전트로 문제를 해결해 보는 접근이었다고 이해해 주시면 됩니다.

그러면 슬랙 기반의 정산 업무 비효율이 어떤 문제이길래, 클로드 코드로 해결하려고 생각하게 됐을까요? 저희 회사는 전국적으로 30개 이상의 캠퍼스를 운영하고 있는데요. 분기마다 정산 업무가 돌아오는데, 그게 업무의 병목이 많이 되는 형태였습니다.

전체 현황 파악 불가: 캠퍼스마다 슬랙 채널을 따로 운영하고 있어 전체 현황을 한눈에 파악할 수 없었습니다.
수동 계산의 오류 위험: 사람이 직접 계산하다 보니 오류 위험이 상존했습니다.
반복적인 이의제기: 정산 결과를 두고 이의제기가 반복적으로 발생했습니다.
진행 상태 추적 어려움: 히스토리로 관리되지 않다 보니 진행 상태를 추적하기 어려웠습니다.

진짜 병목은 워크플로우 그림 밖에 있었다

가장 먼저 진행한 일은 피그잼(FigJam)으로 as-is 워크플로우를 그리면서 병목 구간을 발견해 보는 것이었는데요. '정산 자동화니까 간단하게 AI로 해볼 수 있지 않을까' 싶은 업무도, 실제로 업무 플로우를 뜯어보면 그렇지 않은 경우가 더 많았습니다. 발표에서 제가 피그잼으로 분석한 워크플로우 화면을 캡처해 보여드렸는데, 화면 자체를 설명드리려는 목적이라기보다는 하나의 업무가 AI 전환을 하기 위해서는 얼마나 복잡하게 얽혀 있는지, 이걸 분석하고 파악하는 게 얼마나 중요한지에 대한 예시로 봐주시면 좋겠습니다.

다만 이렇게 플로우 차트로 업무 병목 파악이 용이해지더라도, 여전히 알 수 없는 것이 하나 있었는데요. 바로 '이 프로세스에서 정말 문제가 되는 핵심 병목은 무엇인가'였습니다.

저는 이걸 현장의 데이터를 확인하는 과정을 통해 파악할 수 있었습니다. 데이터 확인 결과, 핵심 병목은 본사가 통보한 정산 결과값에 대한 이의제기와 확인 절차였습니다. 혹시 사내에서 AX를 시도하고 계신 분들이 있다면, 업무 프로세스 맵 그리기 자체에 몰두하시기보다는 현장의 목소리와 데이터를 면밀히 들여다보시길 추천하고 싶습니다.

그래서 제가 기획적으로 해결을 시도한 부분이 '정산 미리 보기' 기능이었는데요. 이의제기 자체가 생길 수 없는 구조를 만든 겁니다. 가맹점주가 데이터를 직접 입력하고 납부 예정 금액을 미리 볼 수 있게 했죠. 본인이 입력하고, 납득하고, 제출하는 구조로 바뀌면 '왜 이런 정산값이 나왔는지' 본사에 이의제기하기 어려운 구조가 됩니다.

정리하자면, 클로드 코드 같은 AI 툴로 무언가를 빠르게 구현해 보는 것은 이제 쉬운 일이 된 것 같은데요. 하지만 올바른 문제에 겨냥하고 그 AI 툴로 문제를 풀어나가는 것은 여전히 사람의 몫이라는 점을 꼭 짚어드리고 싶습니다. 또 하나 더 말씀드리면, 기술적으로 무언가를 실험해 보겠다는 게 아니라, 일반 비개발자 입장에서 내 업무를 AI로 바꿔보고 싶다는 목적이라면, 저는 기획의 중요성을 너무나도 강조하고 싶습니다.

두 번의 피벗이 만든 5일 런칭

다음은 두 번째 파트로, 클로드 코드로 포털을 만들면서 어떤 과정을 거쳤는지 그 여정에 대한 이야기입니다. 저는 사내 AX를 진행할 때 항상 염두에 두는 것이 있는데요. 시스템을 만들기 전에 MVP를 먼저 찾는 것입니다. 이번에도 MVP를 찾는 과정을 진행했습니다.

1차 시도, 슬랙 안에서 해결: 슬랙 기반의 정산 비효율이다 보니 슬랙 안에서 해결하고자 가설을 세웠습니다. 그런데 막상 현장 반응을 보니 슬랙을 공지나 DM 용도로 쓰는 분들이 많았고, 어려워 보인다는 피드백이 있었습니다. 이를 통해 '웹 기반의 단일 채널이 필요하구나'라는 걸 알게 되었습니다.
2차 시도, 노코드 툴 조합: 노코드 툴을 조합해 연결하면 되지 않을까라는 가설이었는데요. 진행해 보니 툴 간 의존성이 생기고 하드코딩 이슈가 생기는 등 UI 흐름 제어에 한계가 있었습니다. 나중에 미납금 관리 같은 기능 추가를 고려했을 때도 노코드로는 풀 수 없는 한계가 보였습니다.
최종 피벗, 클로드 코드: 마지막으로 클로드 코드로 만들기로 결정했습니다.

사실 앞선 두 번의 피벗 덕분에 오히려 '무엇을 만들어야 하는지' 기획 단계를 정확하게 다질 수 있었고, 이것이 5일 만에 런칭하게 된 기반이 되었습니다. 이 경험을 기반으로 마스터 PRD 프롬프트를 작성하고, 클로드 코드에 주입해 5일 만에 런칭을 시도할 수 있게 되었습니다.

실제로 이 5일을 어떻게 썼는지도 궁금하실 것 같은데요. 첫째 날은 마스터 프롬프트로 첫 결과물을 뽑는 데 썼습니다. 기존 피벗 경험으로 무엇을 만들어야 할지가 명확해지다 보니 빌드에는 하루면 충분했습니다. Day 2부터는 검증하고 리뷰하는 단계를 진행했고, Day 4에 사용자 교육까지 진행한 뒤, 마지막 검토를 완료하고 5일째에 배포하게 된 케이스입니다.

이 프로젝트를 진행하면서 하나 더 깨달은 부분이 있습니다. AI가 낮춰준 건 기술 장벽만이 아니라, 전환을 결정하는 심리적 비용도 낮춰줬다는 점입니다. 실패해도 빠르게 다시 시도할 수 있다는 생각이, 매몰 비용에 빠지기보다 새로운 기술 스택을 시도해 볼 수 있는 토대가 되어주었습니다.

실제로 만든 화면도 간략하게 소개드리면, 사용자 화면으로는 정산을 입력하는 가맹점주분들이 보는 대시보드가 있고요. 정산 입력 상세 페이지에서는 자동 계산 값이 추출되면 마지막으로 확인 체크를 하고 정산 최종 값을 제출하는 프로세스로 구성했습니다. 관리자 화면에서는 가맹점주분들이 제출한 데이터를 대시보드 형태의 리스트 하나로 확인할 수 있게 했습니다.

만드는 것과 운영하는 것은 다르다

마지막 세 번째 파트는, 만드는 것과 운영하는 것은 다르다는 걸 깨달은 시행착오에 대한 이야기입니다. 배포 다음 날, "로그인이 많이 느린 것 같다"라는 피드백이 하나 들어왔습니다. 처음에는 '네트워크 문제겠지'라고 생각했는데, 원인은 인프라의 기본값에 있었습니다.

수파베이스(Supabase)를 사용했는데 데이터베이스 리전이 한국이 아니었고, 버셀(Vercel) 네트워크 리전도 북아메리카가 기본값으로 설정되어 있었습니다. 로그인 인증을 거치면서 여러 리전을 경유하느라 수 초씩 걸리는 이슈가 생긴 것이었고, 이 부분을 보완하는 과정을 거치게 되었는데요.

여기서 깨달은 점은, AI가 작성한 코드에는 문제가 없어도 문제는 코드 밖 인프라 설정의 기본값에 있을 수 있다는 것이었습니다. 이 부분은 비개발자분들이라면 더욱 함정에 빠지기 쉬운 내용 같은데요. '작동하는 것이 꼭 완성된 것은 아니구나'라는 점을 시행착오를 통해 깨닫게 되었습니다.

관련 내용을 찾아보니 이미 만들어진 DB 서버의 리전을 옮길 수는 없었고, 새로운 DB를 만들어 마이그레이션해야 하는 이슈로 부상하게 되었는데요. 이걸 해결하는 과정도 흥미로웠습니다. 클로드 코드와 함께 토론하며 명확한 방향을 정할 수 있었는데요. 처음 클로드 코드에게 물어봤을 때는 "이번 분기를 지나 서비스 사용이 안정적일 때 시스템 공지 후 진행하자"라는 답변을 받았습니다.

하지만 제가 알고 있는 도메인 지식과 DB에 대한 지식을 기반으로 역제안을 해볼 수 있었습니다. 새 리전 DB로 데이터를 옮긴 뒤 무중단 마이그레이션하는 방법을 제안했고, 클로드 코드가 이를 검증해 주면서 이 방법으로 진행하게 되었습니다. 결과적으로 API를 통해 새 리전 DB로 이관했고, 로그인 속도가 80% 개선되는 결과를 얻었습니다.

마지막으로, 클로드 코드로 만든 결과물을 지속 가능하게 운영하기 위해 문서화 부분도 빼먹지 않도록 클로드 코드와 같이 진행했습니다. 최종적으로 분기당 업무 시간 절감, 연간 시간 절감, 로그인 속도 개선까지, 운영 단계 이슈를 해결한 것까지 포함해 결과값이 나오면서 AX 과제를 잘 마무리할 수 있었습니다.

올바른 문제에 겨냥하는 것은 여전히 사람의 몫이다

이 경험에서 배운 세 가지를 말씀드리면서 마무리하겠습니다.

올바른 문제에 겨냥하는 것은 여전히 사람의 몫입니다. AI는 잘못된 문제도 빠르게 풀어주고, 방향이 틀렸어도 그럴싸한 결과물이 나옵니다. 그만큼 사람이 그 강력한 도구를 올바른 문제에 겨냥하는 것이 중요하다고 생각했고, 이것이 AI 시대의 빌더이자 기획자의 역할이라고 생각합니다.
탐색은 낭비가 아닙니다. 각 피벗은 실패가 아니라 MVP를 좁혀나가는 과정이었습니다. AI는 잘못된 선택의 비용을 낮춰주기 때문에, 매몰 비용에 빠지기보다 전환을 시도하는 과감한 결정이 과거보다 수월해졌다는 것을 깨달았습니다.
만드는 것과 운영하는 것은 다릅니다. 배포 기본값 문제로 로그인이 느려진 이슈를 해결하면서, 운영을 위해서는 인프라에 대한 파악과 판단도 여전히 사람이 해야 하는 부분이라는 점을 깨달았습니다.

이상으로 발표 마치겠습니다. 저처럼 비개발자임에도 촉박한 시간 내에 AI로 프로젝트를 진행시켜야 하는 분들에게 도움이 되길 바랍니다. 감사합니다.

첫 AX 과제: 슬랙 기반 정산 비효율

진짜 병목은 워크플로우 그림 밖에 있었다

두 번의 피벗이 만든 5일 런칭

만드는 것과 운영하는 것은 다르다

올바른 문제에 겨냥하는 것은 여전히 사람의 몫이다

▶발표 영상 유튜브에서 보기