Claude Code의 핵심 설정과 병렬 작업 환경
이번 시연에서 핵심적으로 다뤄진 도구는 CLI 기반의 Claude Code다. 가장 먼저 눈에 띄는 변화는 단일 세션의 한계를 넘기 위해 `worktree`를 도입했다는 점이다. 로컬 저장소에서 여러 개의 Claude 세션을 동시에 실행할 경우 작업 내용이 서로 덮어씌워지는 충돌이 발생하는데, 이를 해결하기 위해 저장소의 격리된 복사본을 만드는 `worktree` 방식을 사용한다. 사용자가 `claude --worktree` 명령어를 실행하면 자동으로 새 브랜치가 체크아웃되며, 이를 통해 엔지니어는 4~5개의 Claude 세션을 병렬로 운영하며 서로 다른 기능을 동시에 개발할 수 있다.
성능과 속도 측면에서는 Opus 1M(100만 컨텍스트 윈도우) 모델과 `fast mode`를 조합해 사용한다. 이는 대규모 코드베이스를 한 번에 참조하면서도 응답 지연시간을 줄여 데모와 같은 고속 작업 환경을 구축하기 위함이다. 또한, 반복적인 승인 절차를 제거하기 위해 `auto mode`를 적용했다. `auto mode`는 내부 분류기(classifier)가 동작의 위험 여부를 실시간으로 감지하여, 안전하다고 판단되는 작업에 대해서는 사용자가 매번 "Yes, accept"를 누르지 않아도 자동으로 실행하게 만든다.
/prototype 스킬과 자가 검증 파이프라인
구현 단계에서 가장 먼저 활용되는 것은 `/prototype` 스킬이다. 이는 사용자가 프롬프트를 통해 직접 생성한 슬래시 명령어(slash command)로, 특정 기능에 대해 기본 5개 이상의 서로 다른 구현안을 동시에 생성하도록 설계되었다. 생성된 각 안은 HTML 파일 형태로 미리보기가 가능하며, 사용자는 이 중 최선안을 선택하거나 수정 요청을 반복한다. 이때 "Loop"라는 표준 프롬프트를 사용하여 작업이 완전히 완료될 때까지 AI가 스스로 반복 수행하게 하는 루프 구조를 가진다.
코드 구현 이후의 검증은 Claude가 직접 Chrome 브라우저를 제어하는 방식으로 이루어진다. 프론트엔드 변경 사항이 발생하면 Claude가 Chrome을 열어 동작을 테스트하고, 그 과정을 일련의 GIF 스크린샷으로 기록한다. 이렇게 생성된 시각적 증거는 PR(Pull Request)에 함께 첨부되어, 리뷰어가 코드를 읽기 전 동작을 먼저 확인하게 만든다.
비코딩 업무의 자동화 범위는 PR 머지 단계까지 확장된다. `simplify`와 `code review`라는 내부 도구를 통해 코드베이스를 정리(prune)하고, Slack과 연동하여 코드 리뷰어나 온콜(on-call) 담당자에게 자동 DM을 보내는 파이프라인을 구축했다. 특히 모든 저장소의 프론트엔드 변경 사항을 스크랩하여 디자이너의 참여 여부를 확인하고, 미참여 시 플래그를 세우거나 반대 관점의 디자인(adversarial design) PR 초안을 작성하는 예약 루틴(routine)을 통해 품질 관리 체계를 자동화했다.
실무 도입 시 고려해야 할 제약과 운영 관점
실무자가 가장 먼저 조정해야 할 지점은 AI의 역할 범위다. 이번 워크플로우의 전제는 "LLM은 아직 디자인 판단에 약하다"는 한계를 인정하는 것이다. 따라서 세부적인 크래프트(craft)와 최종 의사결정은 사람이 담당하고, AI는 다수의 구현안을 빠르게 생성하고 검증하는 보조 도구로 제한한다. AI가 디자인을 결정하게 하는 것이 아니라, AI가 만든 여러 선택지를 사람이 빠르게 훑고 결정하는 구조로 설계해야 품질 저하를 막을 수 있다.
운영 관점에서는 "누구나 코드를 만들 수 있는 시대에는 배포 기준을 더 엄격하게 자동화해야 한다"는 점에 주목해야 한다. AI로 인해 코드 생산 속도가 비약적으로 상승하면, 병목 현상은 코딩이 아니라 리뷰와 검증 단계에서 발생한다. 따라서 단순한 코드 생성 도구 도입에 그치지 않고, 이번 사례처럼 Chrome 기반의 자가 테스트, GIF 기반의 PR 리포팅, 디자인 참여 여부 자동 체크와 같은 '검증 시스템'을 먼저 구축하는 것이 우선이다.
결과적으로 개발자와 디자이너는 개별 기능을 구현하는 작업에서 벗어나, AI가 생성한 결과물을 어떻게 효율적으로 필터링하고 프로덕션 수준으로 끌어올릴 것인지에 대한 파이프라인 설계자로 역할이 전환되어야 한다. 이는 단순한 도구의 변경이 아니라, 제품 개발의 전체 생명주기를 자동화된 시스템으로 확장하는 운영 전략의 변화를 의미한다.
