요즘 내가 AI와 코딩하면서 생각하는 것들

AI는 혁신적으로 우리의 삶을 바꿔놓고 있다. 특히 개발자들은 매주 새로운 도구로 일하게 되는 환경을 마주하고 있는 것 같다.

그 과정에서도 아직까지는 변하지 않는 것들이 있다. 우리는 지속가능한 코드를 생성해야 하고, 사람이 보기 쉬운 코드를 작성해야 한다. 우리가 이해하기 어려운 코드는 마찬가지로 AI도 이해하지 못한다.

AI가 잘 못해주고 있다면, 그것은 기존 브라운필드의 문제를 의심해야 하고, 팀에서 잘못된 방식으로 개발하고 있지 않나 의심해봐야 되는 시점까지 온 것 같다.

바이브코딩은 없다

바이브코딩이란 단어가 나온 지 이제 1년이 넘은 듯하다. 처음에는 바이브코딩으로 나오는 결과물들을 보며 주변 친구나 동료들과 "그냥 농사지으러 가자"는 등의 농담을 하곤 했다.

하지만 결과는 어떤가. 현재로서는 확실히 말할 수 있는 것 같다. 바이브코딩으로 지속가능한 서비스가 출시될 수는 없다.

AI에게 어떤 앱을 만들 거야, 어떻게 할 거야, 기획 등을 설명하고 개발을 시켜놓으면 절대 한 번에 잘 되지 않는다. "이건 이게 아니지" 욕도 하며 수정을 반복하게 된다. 반복된 수정은 context가 길어지고, 점점 이전 맥락을 잃고, 겉잡을 수 없는 버그를 계속 만들어낸다. 우리는 그제야 구성해놓은 코드를 보고, 수없이 욕을 한다.

바이브코딩은 있을 수 없다. 이건 미래에도 불가능하다고 할 수 있다. 단순히 "해줘"는 수많은 데이터에서 우리가 원하는 방식을 100% 이해시킬 수 없다. LLM은 빈칸채우기인데, 우리가 원하는 기능을 그냥 시킬 수 있을 리가 없다.

그렇다면 개발자는 어떻게 지속가능한 코딩을 AI와 할 수 있을까? 이 시대에 개발자의 역할은 무엇일까?

개발자의 역할

더 이상 직접 개발하는 것이 아니라, LLM이 내가 원하는 코딩을 할 수 있도록 제한해주고, 그런 환경을 코딩해야 된다는 말을 많이 듣고 있다. 반복되게 명령하는 것은 skill과 에이전트를 구성하고, 플로우를 구축하는 것이 개발자의 역할이라는 것이다.

이제 LLM을 의심하는 단계는 지나갔다. 우리 개발자는 LLM이 일을 잘할 수 있는 환경을 만들어주는 것을 목표로 일해야 한다.

하네스 엔지니어링

OMC, OMO, OMX 같은 수많은 오픈소스 하네스 환경이 최근에 아주 큰 인기를 얻고 있다. LLM 모델이 아무리 발전해도 우리가 원하는 것을 명확히 설명해줘야 되기 때문이다. 알아서 해주는 부분을 최소화하고 모호함을 줄여야 한다.

이런 하네스 오픈소스들은 개발자의 자유를 제한하고, 하네스 환경에서 제공된 플로우를 통해 강제로 모호함을 줄이고, 명확히 나눠진 context를 서브에이전트가 병렬로 작업하게 해준다. 개발자가 직접 하나하나 플로우를 구축하지 않아도 강제성을 부여하여 좋은 결과물을 만들어준다.

하지만 이 하네스 환경도 결국에는 우리 팀을 위한 것이 아니다. 우리 팀의 컨벤션, 디자인 시스템, 배포 파이프라인을 모르는 범용 하네스로는 한계가 있었다. 팀이나 개인에 맞는 하네스를 직접 구성해야 한다는 결론에 도달했다.

나의 워크플로우

주변에서 일하는 방식들을 들어봤을 때 결국은 동일한 문제를 겪고 비슷한 방식으로 일하고 있는 듯했다. AI에게 위임할 수 있는 것과 없는 것을 구분하고, 사람이 개입해야 되는 단계는 확실히 해야 한다고 느꼈다.

위임이 가능한 영역

코드 생성, 리팩토링, 테스트 작성, 문서화, 커밋 메시지 생성, PR 생성 같은 반복적이고 패턴이 명확한 작업들은 AI에게 위임이 가능했다. 레퍼런스만 잘 잡아주면 충분히 의도대로 결과가 나왔다.

위임이 불가능한 영역

설계 판단, 요구사항 해석, 코드 리뷰에서의 최종 판단, 사용자 경험에 대한 감각적 판단은 아직 사람이 해야 했다. AI가 만든 결과물이 "동작하는가"와 "올바른가"는 다른 문제였다.

그러면 어디에서 사람이 개입해야 하는가?

이 두 영역을 나누고 보니 판단이 필요한 순간이 명확해졌다.

1. 요구사항을 해석할 때,
2. PRD를 승인할 때,
3. 코드 리뷰를 할 때

이 세 지점에서 사람이 확인하고, 나머지는 AI가 실행하는 구조가 필요했다.

그래서 각 단계를 독립적인 스킬로 만들고, /haejo라는 오케스트레이션 스킬이 이 전체 플로우를 체이닝하도록 만들었다. "로그인 페이지 개발해줘"라고 입력하면 아래 단계를 순서대로 실행하며, 각 단계가 끝날 때마다 "진행할까요?"를 물어본다. 사람이 판단해야 할 순간에 멈추고, AI가 잘하는 실행은 AI에게 맡기는 구조다.

/haejo "로그인 페이지 개발해줘"

Step 1: /prd-gen ── 모호함 줄이기 + PRD 분리
   ✅ 완료 → "진행할까요?"

Step 2: /prd-exec ── PRD별 구현 + 셀프 리뷰
   ✅ 완료 → "진행할까요?"

Step 3: /create-pr ── PR 생성
   ✅ 완료 → "Slack 리뷰 요청도 보낼까요?"

Step 4: /review-request ── Slack 알림 (선택)

각 단계를 자세히 살펴보자.

Step 1: 모호함 줄이기 — /prd-gen

Feature 개발에서 가장 먼저 하는 일은 관련 컨텍스트(Jira 티켓, Slack 스레드, Figma 디자인, 컨플루언스 스펙)를 수집해서 /prd-gen에 넣는 것이다.

/prd-gen은 내부적으로 /deep-interview를 호출한다. 소크라틱 인터뷰 방식으로 질문-응답을 반복하며 모호함을 수치화하고, 모호성이 20% 이하로 떨어질 때까지 계속 질문한다. "이 기능이 오프라인에서도 동작해야 하나요?", "기존 인증 미들웨어를 확장하나요, 별도 플로우를 만드나요?" 같은 질문들이 나오는데, 이 과정에서 내가 미처 생각하지 못한 가정들이 드러난다.

인터뷰가 끝나면 결과를 최소 단위 PRD로 분리한다. 하나의 PRD는 PR 하나로 리뷰 가능한 크기여야 하고, 공통 컴포넌트나 훅은 별도 PRD로 나눈다. 의존성 그래프도 함께 생성되어 어떤 PRD를 먼저 작업해야 하는지, 어떤 것들을 병렬로 돌릴 수 있는지가 명확해진다.

Step 2: PRD별 구현 — /prd-exec

PRD가 확정되면 /prd-exec이 의존성 순서대로 실행한다. 각 PRD마다 아래 과정을 반복한다:

1. Deep Interview 한 번 더 — PRD 단위로 추가 명확화. 전체 스펙에서는 드러나지 않았던 세부 사항을 잡아낸다.
2. 서브 브랜치 생성 — feature 브랜치에서 PRD별 서브 브랜치를 만든다.
3. 레퍼런스 라우팅 — .tsx 파일을 수정하면 UI 구현 체크리스트를 자동으로 읽고, Form 관련 작업이면 Form 아키텍처 가이드를 추가로 읽는다. 이 레퍼런스들이 Claude가 우리 팀의 컨벤션대로 코드를 작성하게 만드는 핵심이다.
4. 구현 — PRD의 Acceptance Criteria를 기준으로 코드를 작성한다. 의존성이 없는 PRD들은 별도 워크트리에서 병렬로 동시 구현된다.
5. 셀프 리뷰 — 구현한 에이전트와 별도 컨텍스트에서 코드 리뷰 에이전트가 검증한다. 자기 코드를 자기가 리뷰하면 관대해지기 때문에 반드시 분리한다. 문제가 발견되면 수정 → 재검증을 최대 3회 반복한다.
6. PR + 유저 리뷰 — 서브 브랜치에서 feature 브랜치로 PR을 올리고, 내가 직접 리뷰한다. 승인하면 머지하고 다음 PRD로 넘어간다.

레퍼런스 라우팅은 처음에 CLAUDE.md 하나에 모든 규칙을 넣었다가 341줄까지 불어난 경험에서 나왔다. 상세 규칙은 .claude/ref/ 아래에 카테고리별로 분리하고, 라우팅 테이블로 "어떤 파일을 작업할 때 어떤 ref를 읽어라"는 매칭 조건만 관리한다. 지시문만으로는 누락되는 경우가 있어서 Hook으로 이중 안전장치도 걸어두었다.

.claude/
├── CLAUDE.md (라우팅 테이블 + 공통 규칙)
└── ref/
    ├── ui/
    │   ├── ui-implementation.md (프리미티브, Props, CSS 정책)
    │   └── figma-workflow.md (Figma→코드 4단계)
    └── patterns/
        ├── form-architecture.md (Self-Contained Atomic Field)
        ├── feature-api.md (Mutation Hook 패턴)
        └── api-error-handling.md (ApiException 패턴)

Step 3: PR 생성 — /create-pr

모든 PRD가 머지되면 /create-pr이 feature → main PR을 생성한다. 미커밋 변경사항이 있으면 논리적 단위별로 분류하여 커밋을 분리하고, main 브랜치에서 작업 중이면 자동으로 feature 브랜치를 생성해준다.

리뷰어가 선택되면 자동으로 "Slack 리뷰 요청도 보낼까요?"를 질문한다. "예"이면 /review-request가 Slack으로 @mention 포함 리뷰 요청 메시지를 전송한다. 리뷰가 필요 없으면 스킵하면 된다.

Bug 수정 플로우

Bug 수정은 Feature보다 단순하다. /haejo를 거치지 않고 직접 스킬을 호출한다.

1. 컨텍스트 수집 — Jira 티켓 + Slack 스레드 + 관련 논의 내용
2. /deep-interview — 버그 스펙 명확화 (간단하면 스킵)
3. /ralph — PRD 기반 자동 구현 + 검증 루프
4. /create-pr → /review-request

/ralph은 코드 작성 → 테스트 → 수정을 완료될 때까지 반복하는 스킬이다. Bug는 PRD를 여러 개로 나눌 필요가 거의 없어서 /prd-gen 없이 바로 구현에 들어간다.

사용하고 있는 주요 스킬들

노션 기반 태스크 관리

지금 회사에서는 Jira를 거의 사용하고 있지 않아서, 개인 노션으로 태스크를 관리하고 있다. 작업을 시작할 때는 항상 연동할 노션 카드를 지정하거나 새로 생성했고, PR을 올릴 때는 /task-record로 작업한 세션의 내용을 정리해서 노션 카드에 기록한다.

이렇게 하니 두 달 사이에 쌓인 노션 카드가 130개가 넘어가고 있었다. 내가 두 달 동안 날마다 어떤 일을 했는지 자동으로 기록이 되어서 좋았다. 별도로 회고를 위해 시간을 들이지 않아도, 카드를 쭉 훑어보면 어떤 작업을 했고, 어디서 막혔고, 어떤 판단을 내렸는지가 남아있었다.

마무리

어느 팀이나 아직은 AI를 100% 신뢰하면서 일을 할 수는 없다.

하지만 분명 대부분의 일은 AI에게 위임할 수 있을 것이다.

최근에는 팀에서도 "SOTA급 개발자 되기"라는 이름으로 AI 워크플로우 표준화를 시작했다.

빠르게 적용하기 위해 내가 사용하고 있던 플로우를 먼저 팀 레포에 올리고, 팀원들이 리뷰하면서 고도화하는 방식을 택했다. OMC(oh-my-claudecode)를 공통 하네스로 채택하고, Claude Code 사용자 기준으로 스킬과 레퍼런스를 구성했다.

각자의 방식을 공유해보니 도달하는 결론은 비슷했고, CLAUDE.md·스킬·서브에이전트의 역할 분리, 팀 공유와 개인 설정을 나누는 git 전략, 스킬 검증을 데이터 기반으로 하자는 방향에 합의했다.

레퍼런스 문서들(Figma 워크플로우, 코드 패턴 가이드 등)은 아직 내 사견으로 들어가 있다. 팀원들이 각자 사용하고 있는 레퍼런스를 자유롭게 올리면서 리뷰하는 과정을 거칠 예정이다.

아직 구축 중이고, 테스트코드의 한계, 토큰 최적화, AI를 안 쓰는 팀원에게 가치를 어떻게 보여줄지 같은 고민도 계속되고 있다.

신뢰할 수 없는 부분을 명확히 인지하고, 내가 할 수 있는 것과 AI가 할 수 있는 것을 팀에서 나누며, 올바른 플로우를 구축하는 것을 목표로 해야 한다.

아직 갈길은 멀다.

테스트코드의 한계, 토큰 최적화, 수치화가 애매하고, 어떻게 효율적으로 리뷰를 할 수 있을까, AI를 사용하지 않는 팀원에게 어떻게 가치를 보여줄 수 있을까. 등 다양한 고민이 끊이질 않는다.

한번씩 생각하고있는게 업데이트되면 또 올리지 않을까..? 싶다.