*이 글은 AB180 CEO 남성필 대표님이 지난 2~3개월 간 Claude Code와 Codex로 2개의 프로덕트 개발을 리드하면서 느낀 인사이트를 직접 정리한 수기입니다.
지난 두 달 동안 우리 팀은 Claude Code와 Codex로 두 개의 프로덕트를 함께 만들어왔다. 하나는 글로벌 다섯 개 로케일에서 운영되는 Airbridge 웹사이트이고, 다른 하나는 우리 마케팅 팀의 일을 자동화하는 Internal Marketing Engine이다. 그렇게 누적된 PR(Pull Request, 코드 변경을 검토하고 반영하는 단위)이 700개를 넘어섰다.
비개발자, 특히 마케팅 + BX 팀원들이 직접 했다는 점이 중요하다. 그 과정에서 얻은 5가지 배움을 정리해 보려고 한다. 거창한 방법론이 아니라, 우리가 실제로 부딪치고 풀어낸 이야기다. 마지막에는 내가 아직 답을 못 찾고 있는 3가지 질문도 함께 남기려고 한다.
예전에 코딩을 공부할 때 Team Treehouse라는 서비스가 있었다. 거기엔 완강 할 때마다 쌓이는 누적 점수라는 게 있었는데, 나는 정말 열심히 해서 8천 점에서 한참 머물렀다. 그런데 내 주변에 그 점수를 단 두 달 만에 10,000점 이상으로 끌어올린 친구가 있었다.
완전 불가능한 숫자도 아니지만, 정말 열심히 공부한 사람만이 그 정도 시간 안에 도달할 수 있는 숫자였다. 그런데 몇 년 뒤에 다시 만나서 "그때 공부한 코딩, 지금도 쓰니?"라고 물었더니 "다 잊어버렸다"고 답했다. 그 친구는 그때 배운 것으로 서비스를 처음부터 끝까지 만들어 본 적이 없었기 때문이다.
Claude Code도 똑같았다. 강의를 듣거나 가이드를 한 번 훑어보는 것만으로는 손에 붙지 않는다. 자기가 책임지는 산출물을 처음부터 끝까지 자기 손으로 끝내본 경험이 있어야 비로소 누적된다.
실제로 우리 팀에서는 비개발자 팀원이 Claude Code를 설치하고 첫 PR을 올리기까지 하루밖에 걸리지 않았다. 하지만 그 하루가 중요한 게 아니라, 그 뒤에 자기 이름으로 된 페이지가 라이브에 올라가는 경험을 반복하면서 실력이 누적되는 것이 중요했다.
우리 팀원들이 Claude Code로 웹사이트를 직접 처음부터 끝까지 만들어 본 경험이 결정적이었다. 단순히 튜토리얼을 따라가는 시간과 내가 책임지는 페이지를 라이브에 띄우기 위해 씨름하는 시간 사이의 학습 격차는, 시간이 갈수록 기하급수적으로 벌어진다.
과거에 스크럼이라는 방법론이 생겨났을 때, 스크럼 마스터라는 직책이 있었다. (그리고 지금도 정석대로 하는 많은 조직에서도 그렇다.) 스크럼 마스터는 개발 방법론에 익숙하지 않은 팀원들에게 코칭을 해주고, 프로젝트 진행을 가로막는 블로커를 찾아서 구조적으로 풀어주고, 스토리 포인트 산정이나 리뷰 같은 다양한 절차에 윤활유 역할을 해주고, 그렇게 합의한 원칙들이 흐트러지지 않게 지켜보는 역할을 했다.
Scrum Guide의 공식 정의를 빌리면, 팀의 효과성에 책임지는 servant leader(팀을 지시하는 것이 아니라 팀이 잘 돌아가도록 봉사하는 리더)이고, 팀과 제품 책임자와 조직 세 군데 모두를 위해 봉사하는 사람이다.
비개발자 직군의 팀원들과 함께 AI로 프로덕트를 만들려면 이런 스크럼 마스터처럼 AI 마스터라는 역할을 맡는 사람이 반드시 있어야 한다는 생각을 했다. 명령하는 사람이 아니라 팀의 효과성을 위해 봉사하는 사람이라는 점이 핵심이다.
AI 마스터는 일단 기본적으로 개발을 어느 정도 알고 있는 사람으로서, 팀이 일할 인프라를 미리 띄워주는 일부터 시작한다. Airbridge 웹사이트는 Next.js와 Tailwind 기반으로 Vercel 위에 올라가 있고, Sentry로 클라이언트와 서버와 엣지 세 영역의 에러를 모두 추적한다.
Supabase로 데이터베이스를 띄웠고, 여기에 이미지와 같은 각종 오브젝트를 올려서 CDN(콘텐츠를 전 세계에 빠르게 전달하는 네트워크)으로까지 활용한다. 이런 것들을 처음부터 셋업해줘야만 프로젝트가 빠르게 시작될 수 있다.
그 다음으로 중요한 것은 하네스 엔지니어링(AI 에이전트가 지켜야 할 룰, 호출할 수 있는 스킬, 참고할 지식을 미리 설계해두는 작업)이다. Claude.md 파일, 그리고 지켜야 할 룰과 사용할 수 있는 스킬, 기본 지식 체계 등을 미리 만들어두면, 팀원들은 이미 깔린 길 위에서 훨씬 빠르게 달릴 수 있다.
예를 들어서 TDD(테스트를 먼저 작성하고 코드를 만드는 개발 방식), Git을 사용하는 기본 원칙, 코딩 시 절대로 주의해야 할 점 등이 그런 것들이다. 지금 Airbridge 웹사이트 레포(repository, 코드가 모여 있는 저장소)에는 14개의 룰과 17개의 스킬이 누적되어 있다.
한 사람이 만든 스킬을 다음 사람이 그대로 호출해서 쓰고, 한 번 박힌 룰은 모든 사람의 작업에 자동으로 적용된다. 시간이 갈수록 이 자산이 두꺼워지면서 팀 전체의 평균 산출물 품질이 자연스럽게 올라간다.
무엇보다 보안 관련 세팅이 중요하다는 점을 빼놓을 수 없다. 환경 변수를 잘 관리하는 부분, 1Password 같은 시크릿 매니저와 로컬 환경과 프로덕션 환경 사이의 정합성을 검증하는 부분이 그렇다. 우리는 1Password에서 끌어온 시크릿이 로컬의 .env.local과 Vercel 프로덕션의 환경 변수와 모두 일치하는지를 audit 스크립트로 검증한다.
더 나아가서, 클라이언트에 노출되어도 되는 NEXT\PUBLIC\ 접두사가 붙은 환경 변수와 그렇지 않은 환경 변수들을 구분해서 실수로 키가 새는 일을 막는다. 이런 가드레일이 사람의 주의력에만 의존하지 않게끔 시스템에 박아두는 일은 정말 보람이 있는 작업이다.
마지막으로, 보안을 해치지 않는 선에서 사람들이 활용할 수 있는 다양한 도구들을 안전하게 개방해주는 일도 의외로 큰 차이를 만들었다. API 키들을 만들어서 권한을 안전하게 제약해 놓은 다음에 환경변수에 넣고 사람들이 쉽게 꺼내갈 수 있게끔 했는데, 이 단순한 과정이 실제로 팀원들이 Google Workspace, Amplitude, Mixmax, 1password CLI 같은 다양한 도구를 보안에 대한 걱정 없이 활용할 수 있게 하는 데 큰 도움을 줬다. 안전하게 좁힌 다음에 쉽게 쓸 수 있게 풀어주는 것, 이 두 단계 모두를 빼먹지 않는 것이 결국 핵심이었다.
여러 사람이 한 레포를 동시에 만지다 보니, 소스 코드의 충돌과 문서화가 상당한 문제가 됐다. Git에 대한 각종 룰을 세팅해 놨음에도 불구하고, 작업하는 사람들이 에이전트에게 기존 코드에 대한 지식 없이 일을 시키다 보니 충돌이 잦았다. 그 충돌 해결마저 에이전트에 의존하다 보니, 기존 작업을 무심코 덮어쓰는 일이 정말 많이 발생했다. 이 부분은 3가지 방식으로 어느 정도 풀 수 있었다.
첫째는 원칙의 명문화다. 지금 내가 만지고 있는 영역은 내 작업이 우선이고, 내가 지금 만지지 않는 영역에 대해서는 기존 사람들이 한 작업을 존중하라는 원칙을 Claude.md 등 각종 룰에 명시적으로 추가했다. 단순한 원칙인데도, 룰로 박아두고 나니 사고가 눈에 띄게 줄었다.
둘째는 강력한 오디팅 시스템을 갖추는 것이다. 우리가 지키고 싶은 것들을 가능한 한 많이 룰로 만들어 놓고, 빌드가 될 때나 PR을 머지하기 전에 자동으로 검증되게 만들었다. 지금 Airbridge 웹사이트 레포에는 audit 스크립트(코드나 콘텐츠가 정해진 규칙을 지키는지 자동으로 검사하는 프로그램)가 9종이 돌아간다. 콘텐츠 audit, 구조 audit, 깨진 링크 audit, 동적 콘텐츠 audit, 페르소나 audit, 인용 audit, 번역 품질 audit 등이다. 몇 가지 실제 사례를 들어보면 이렇다.
이런 audit들은 GitHub Actions(코드가 변경될 때마다 자동으로 검증 작업을 실행해주는 도구)의 pr-audit.yml 워크플로우에서 모든 PR마다 자동으로 돌아가고, 위반 사항을 표 형식으로 PR에 코멘트로 달아준다. CRITICAL 위반은 머지 자체를 차단한다. 한 번 통과한 룰은 그 이후의 모든 변경에 자동으로 적용되기 때문에, 시간이 갈수록 콘텐츠와 코드의 품질이 자연스럽게 올라간다.
마지막으로, 일을 MECE적(Mutually Exclusive, Collectively Exhaustive — 서로 겹치지 않으면서 빠짐없이 나누는 것)으로 나누는 방법이 있다. 하나의 웹사이트를 여러 명이 동시에 작업하다 보면 같은 페이지나 같은 컴포넌트를 여러 사람이 동시에 만지는 일이 생기는데, 그러면 충돌이 발생할 수밖에 없다. 우리는 Airbridge 웹사이트에서 최대한 겹치지 않게 일을 조정하려고 노력했다.
그 다음으로 우리에게 어려웠던 것은 에이전트를 활용하는 방법을 이해하는 것이었다. 에이전트를 활용한다는 것은 단순하게 "이걸 해"라고 말하는 것에서 그치지 않는다. 우선 내가 원하는 것이 명료하게 정의되어야 하는데, 다행인 것은 우리가 Superpowers나 Ouroboros 같은 좋은 라이브러리들을 갖고 있다는 점이다. 이런 것들 위에서 작업하면 기획과 실행과 검증의 루프가 어느 정도 강제된다.
만약 이런 라이브러리를 매번 끌어 쓰기가 부담스럽다면, AI한테 원하는 바를 두루뭉술하게 말하고 함께 발전시켜나가도 된다. "내가 하고자 하는 것이 지금 두루뭉실한데, 일단 생각한 것까지를 말할테니 네가 나한테 계속 질문을 던져서 네가 생각했을 때 명료하다고 느껴질 때까지 이 기획을 보강해 달라"라고 부탁하는 방식이 의외로 잘 통한다.
구조적으로 문제가 됐을 때 당장 롤백할 수 있는 환경을 만들거나, 문제를 문서화해서 캐치하는 것도 고민해야 한다. Superpowers나 Ouroboros를 쓰면 이런 문제가 어느 정도 해결되긴 한다. 그럼에도 불구하고 내가 가장 강하게 권장한 것은 중간중간 AI와 적극적으로 소통하는 방식이었다.
핵심은 결국 내가 AI에게, 그리고 AI가 나에게 서로 명료하게 설명할 수 있을 때까지만 다음 스텝으로 넘어가는 것이다. 그리고 한 번 부딪힌 문제는 반드시 하네스 엔지니어링으로 룰이나 훅이나 스킬에 박아넣어서 다시는 같은 문제를 겪지 않게 만드는 피드백 루프가 정말 중요했다.
앞에서 AI 마스터가 인프라를 깔고, 하네스를 설계하고, 보안을 시스템화하고, 도구를 개방하는 역할을 설명했다. AI 마스터가 아무리 잘 깔아줘도, 그 위에서 달리는 사람이 직접 쌓아야 하는 층이 있다. 마지막으로 내가 느꼈던 것은 바로 그 층, 비개발자분들 본인의 기본기를 더 두껍게 만들어야 한다는 점이었다.
Claude Code를 통해서 다양한 일들을 만들 수 있고, 그걸 스킬화하거나 심지어 업무 생산성 자체를 혁신할 수 있다고 생각한다. 그러나 그런 것들을 더 높은 스케일로 만들어가고, 보안적인 기준을 충족시키고, 다른 사람들에게 전파하고, 하네스 엔지니어링의 원칙으로 계속 보강해 나가는 일은 결국 신뢰할 수 있고 안정적인 프로덕트를 만드는 과정과 동일하다.
그래서 가장 먼저 두껍게 쌓여야 한다고 느낀 것은 AI와 일하는 법, 그리고 하네스 엔지니어링의 기본 원리였다. 내가 AI에게 최대한 명료하게 설명하기 위해 AI가 나에게 질문을 던지게 하고, 또 내가 AI에게 계속 질문을 던지면서 그가 하는 일을 명료하게 이해하는 그 원칙이 모든 디테일한 테크닉의 출발점이다.
거기에 더해서, 한 번 부딪힌 문제를 다시 겪지 않도록 룰이나 훅이나 스킬에 박아넣는 하네스 엔지니어링의 감각을 같이 익혀야 한다. 이 2가지가 다른 모든 기본기에 우선한다는 생각이 들었다.
그 다음으로 필요한 기본기는 GitHub의 기본 작동 방식과 Claude의 다양한 플러그인, 그리고 스킬에 대한 이해 같은 부분이다. Superpowers나 Ouroboros, 그리고 BX분들에게 매우 도움이 되는 Agentation 같은 라이브러리들에 대해서 잘 알고 있어야 하고, 무엇보다 코드와 산출물이 어떻게 버전 관리되고 어떻게 자동으로 검증되는지를 손으로 익혀야 하네스 엔지니어링의 감각이 실제 작업에 닿는다.
거기서 한 단계 더 나아가면 Vercel 같은 호스팅 서비스, CDN, DNS(도메인 이름을 서버 주소로 연결해주는 시스템), API, MCP(Model Context Protocol, AI 에이전트가 외부 도구를 호출할 수 있게 해주는 규격) 같은 조금 더 높은 단위의 인프라 지식이 필요하다. 이 단계까지 도달하면 비개발자분들도 자신의 작업이 라이브에서 어떻게 동작하고, 어디서 깨질 수 있고, 어떻게 모니터링해야 하는지를 스스로의 머릿속 모델로 가질 수 있게 된다.
이 세 단계의 기본기가 어느 정도 갖춰져야, Claude Code가 단순한 도구를 넘어 비개발자분들 본인의 일하는 방식 자체로 자리잡는다는 것이 솔직한 결론이다.
5가지를 배웠지만, 솔직히 말하면 아직 답을 못 찾은 질문이 더 많다. 3가지 모두 어느 정도 1차 해법은 시도해봤지만, 그 너머에 더 어려운 문제가 남아 있다는 것을 깨달은 영역들이다.
각자 자기 컴퓨터에서 자기 Claude Code를 띄워서 일하지만, 적어도 기본적인 업무 사항들은 모두 공통 레포지토리 안에서 작업하고 그 레포의 스킬이나 기능을 쌓아가는 방식으로 풀려고 하고 있다. 그래서 한 사람이 만든 스킬을 다음 사람이 그대로 호출해서 쓸 수 있고, 한 번 박힌 룰은 모든 사람의 작업에 자동으로 적용된다. 이 구조 자체는 어느 정도 작동하고 있다.
문제는 그 아래에서 각자가 어떤 일을 하고 있는지가 여전히 보이지 않는다는 점이다. 옆자리 동료가 지금 어떤 프롬프트로 씨름하고 있는지, 어떤 막다른 길에 들어섰다가 어떻게 돌아 나왔는지, 무엇을 시도해봤다가 폐기했는지 같은 흐름이 실시간으로 공유되지 않는다. 모든 작업을 티켓으로 끊어서 기록하자니 시간이 너무 많이 들고, 작은 시도들까지 일일이 티켓화하는 것은 본질적으로 의미가 없다.
그래서 진짜 질문은 이렇게 좁혀진다. 시험삼아서 해보는 자잘한 작업들을, 혹은 점진적 개선을 이뤄나가는 그 과정 자체를 자연스럽게 서로에게 보이게 만드는 구조는 무엇일까.
이 질문은 사실 두 개의 문제가 겹쳐 있다.
첫째는 기존 시스템과의 정합성이다. Jira처럼 회사가 이미 잘 운영하고 있는 도구들이 있고, AI 기반의 새로운 일하는 방식이 그 안에서 함께 보이고 검토 가능해져야 한다. 그렇지 않으면 두 개의 세상이 평행으로 굴러가게 된다. 우리가 지금 하는 작업의 진척과 결정과 산출물이, 기존 시스템 안에서도 자연스럽게 가시화되도록 만드는 방법을 고민하고 있다.
둘째는 보안적으로 안전하면서도 이걸 전사에 배포하는 문제다. 우리 팀이 작은 그룹 안에서 안전하게 시도해본 것을, 보안 기준을 흐트러뜨리지 않고 더 큰 조직으로 확산하는 일은 차원이 다른 작업이다. API 키 권한, 시크릿 관리, 데이터 접근 범위, 사고 시 차단 절차 같은 모든 항목의 위험 표면이 인원이 늘면 함께 늘어나기 때문이다. 결국 이 질문은 빠르게 퍼뜨리고 싶은 욕망과 안전하게 운영해야 하는 책임을 동시에 충족시키는 배포 전략이 무엇인가로 모인다.
이게 가장 어려운 질문이다.
앞에서 말한 5가지 배움은 결국 "AI에게 명료하게 설명하고, AI가 나에게 명료하게 설명하게 한다"는 원칙으로 수렴했다. 하지만 어떤 종류의 지식은 그 원칙만으로는 닿지 않는다. 예를 들어 Sentry로 장애를 추적할 때 발휘되는 직관, DNS와 CDN의 동작 원리, 웹사이트를 더 빠르게 만들기 위한 구조적인 선택, 우리 서비스의 API를 더 간결하게 설계하는 감각 같은 것들이다. 이런 것들은 단순히 AI에게 잘 묻는다고 해결되지 않는다. 어느 정도 누적된 실전 경험과 시스템적 사고가 필요하고, 비개발자가 단기간에 익히기에는 본질적으로 까다롭다.
그래서 남는 질문은 두 갈래다. 이런 깊이의 지식을 어떻게 효율적으로 팀에 전수할 것인가가 첫째이고, 전수가 어렵다면 깊이가 있는 사람과 없는 사람이 어떻게 페어링되어 일해야 결과물이 안전하게 유지될 것인가가 둘째다. 후자에 대한 우리 팀의 잠정적인 답이 결국 앞서 말한 AI 마스터 역할인데, 이 역할이 한 명에게만 의존하지 않고 조직적인 메커니즘으로 굳어지게 만드는 것이 다음 숙제다.
팀원들과 함께 700개 PR을 만들고 풀어내면서 정말 많은 것들을 배웠고, 솔직히 말해서 정말 재밌었다.
솔직하게 말하면, Claude Code나 Codex 같은 도구로 일하는 것 자체는 어렵지 않다. 진짜 어려운 일은 그 위에서 만들어지는 결과물을 제품 개발자적인 사고로 끌어올려서 조직화하는 것, 그리고 그렇게 만들어진 시스템이 조직 전체에 진짜 임팩트를 내게 하는 것이다. 이 어려운 부분을 함께 풀어나갈 동료가 우리에게는 정말 많이 필요하다.
우리는 세일즈, CSM, 파트너십, 개발, PM, 보안, 그리고 그 외의 모든 직군에서 이 과정을 함께 할 사람들을 찾고 있다. 우리가 이미 푼 5가지만큼이나 아직 못 푼 3가지가 매력적으로 느껴지는 사람이라면, 직군과 무관하게 함께 일하고 싶다.
