Source: Dev.to

안녕하세요, 저는 airCloset의 CTO인 Ryan입니다.
Disclaimer: 이 글에서 말하는 “cortex”는 airCloset 내부에서 자체 개발한 AI 플랫폼의 코드명이며, Snowflake Cortex나 Palo Alto Networks Cortex와 같은 기존 상용 서비스와는 무관합니다.

Part 1(시리즈 소개)에서는 cortex의 하네스가 비엔지니어(비즈니스 측 매니저, PMO 등)도 프로덕션 레포지토리에 PR을 열 수 있을 정도로 성숙했다고 언급했습니다. 여기서 하네스는 프로덕션 AI를 위한 런타임 기반으로, 지식 그래프, Auto Review, Self‑Healing, Recurrence Prevention을 결합한 것으로 Part 1~4에서 다루었습니다.

Part 5에서는 그 하네스가 이제 코드를 실제로 작성하는 단계에 도달했음을 다룹니다.
“엔지니어가 뒤에서 꼭 검토하겠죠?” 라는 질문을 많이 받겠지만, 이 글은 먼저 구체적인 예시 하나를 제시하고 시작합니다.

Part 5에서 다루는 내용

• 실제로 배포되는 PR 종류 – 최근 두 건을 상세히 살펴봄
• 잘 되는 점과 안 되는 점 – 기존 스택 위에 추가하는 것과 새로운 인프라를 구축하는 것 사이의 경계
• 비엔지니어에게도 적용 가능한 이유 – Part 1‑4의 네 메커니즘이 어떻게 작동하는지
• 다음 단계 – toC 서비스로의 확장, 소비자 대상 규모 확장의 방향

깊이 있는 toC 구현 이야기는 별도 포스트에 올릴 예정이며, 여기서는 전체적인 프레임과 방향만 제시합니다.

Theme

Key scene

Article

1 + 1,742 라인 / 41 파일 PR이 내부 대시보드 웹앱에 착륙

제목: “PL dashboard ver.2”. 이번 변경으로 여러 비즈니스 유닛의 매니저와 팀 리드가 프로젝트 가시성을 확보하게 되며, 각 사람은 자신의 부서·팀에 맞는 뷰만 보게 됩니다. 공유 타입 패키지에 SSoT를 추가하고, API 서버에 INNER JOIN·LEFT JOIN을 포함한 새로운 라우트를 만들고, 웹앱에 새로운 페이지와 뷰‑스테이트, 개인 설정 화면을 추가했습니다 – 실제 기능을 구현할 때 기대하는 전체 스택입니다.

핵심은 이게 단순한 오타 수정이나 문자열 교체가 아니라는 점입니다. 엔티티, 레포지토리, API 라우트, 화면, 필터, 개인 설정 – 기능을 위해 건드려야 할 모든 레이어가 손대졌습니다. 숙련된 엔지니어가 며칠 동안 작업한 규모와 같습니다.

리뷰‑수정 사이클

PR open (+1,742 / 41 files)
auto‑review pass 1: 주요 이슈 (권한‑스코프 누락 – 다른 부서 데이터가 보기에 새어 나옴) + 소수의 Minor 항목
author bot push: 스코프 누락을 닫고 Minor 항목 해결
auto‑review pass 2: 남은 Nit 항목 + lint 경고 (no‑empty‑function)
author bot push: lint 클린
auto‑review pass 3: 아직 COMMENTED nit 남아 있음, 아직 APPROVE 안 됨
author bot push (iteration 2): 로딩 스켈레톤 강화, 불필요한 JSDoc 수정 되돌림
auto‑review pass 4: APPROVED → CI green + APPROVE 모두 충족 → auto‑merge → production

PR 오픈부터 머지까지 4번의 리뷰‑수정 라운드, 3번의 author‑bot 푸시, 인간 리뷰어 0명. 리뷰는 auto‑review 봇이, 수정은 PR 작성자가 로컬에서 실행 중인 author‑bot이 담당하고, 최종 APPROVE는 AI가 제출합니다. 자동 머지 스크립트는 CI가 green 되는 즉시 머지를 수행합니다. 프로덕션은 56/56 공유 타입 체크(SSoT), 2,284/2,284 API 테스트, 1,113/1,113 웹 스펙, lint 오류 0으로 배포됩니다. (cortex는 lint 작업을 oxlint(일반 체크)와 @graph‑* 규칙을 위한 커스텀 eslint 플러그인으로 나눕니다.)

두 번째 리뷰 패스가 중요한 이유

“Scope fall‑through”는 다소 기술적인 이슈로, 권한 필터에 구멍이 있어 다른 부서 데이터가 내 뷰에 새어 나올 수 있다는 뜻입니다. 내부 대시보드이기 때문에 외부 유출 사고는 아니지만, “내가 볼 수 있는 것만 보여줘야 한다”는 대시보드의 핵심 목적을 무너뜨리는 문제입니다. 이런 문제는 실수로 머지되면 생산 환경에서 바로 눈에 띄기 어렵고, 사용자에게 불필요한 노이즈를 제공하게 됩니다. auto‑review가 첫 번째 패스에서 이를 잡아내고 작성자에게 되돌려준 덕분에 비엔지니어도 이 흐름을 안전하게 이용할 수 있습니다. 이런 루프가 없었다면 비엔지니어가 만든 이 정도 규모의 PR은 위험한 베팅이었을 겁니다.

그리고 이 PR의 작성자는 엔지니어가 아닙니다. 비즈니스 측 팀원이 기능 설명을 Claude Code에 전달하고, Part 2에서 다룬 지식 그래프를 활용해 관련 기존 코드를 끌어온 뒤, 1,742줄 PR이 자동으로 생성되었습니다. 위 네 번의 리뷰‑수정 라운드가 바로 그 뒤에 일어난 일입니다.

핵심 주장: 비즈니스 요구사항을 가장 잘 아는 사람이 이를 정리해 엔지니어에게 넘기는 대신, Claude Code에 직접 넘겨 프로덕션까지 가져가는 흐름이 바로 이 설정입니다.

“작성”에 대한 빠른 정리

이 글에서 “작성한다(write)”는 에디터에 한 줄씩 타이핑한다는 뜻이 아니라, 비즈니스 요구사항을 Claude Code에 전달하고, 생성된 diff와 AI 리뷰 코멘트를 도메인 지식으로 판단한 뒤, 프로덕션 머지까지 이끌어가는 전체 과정을 의미합니다. 실제 diff 대부분은 Claude Code가 작성하고, 리뷰 피드백은 author‑bot이 처리합니다. 인간이 하는 일은

1. 원하는 내용을 말로 정리하기,
2. 진행 중 판단(“이게 맞는가?, 이게 틀린가?”)을 내리기,
3. 머지 준비가 되면 승인하기,
   이 세 가지입니다. 기술적인 구현 작업은 전혀 아닙니다.

물론 학습 곡선은 존재합니다 – Claude Code에 어떤 프롬프트를 주고, 어떤 컨텍스트를 제공할지 등. 하지만 이것은 프로그래밍을 배우는 것이 아니라 “내가 원하는 바를 명확히 표현하는 능력”이 필요합니다.

하네스가 품질을 보장하므로, 1,742줄 / 41파일이라도 정상 작동합니다.

범위 외 내용

이 포스트는 비엔지니어가 샌드박스 환경에 자유롭게 앱을 배포하는 흐름은 다루지 않습니다. 그 메커니즘은 이전 포스트 “Bridging ‘I Want to Build’ and ‘I Want to Publish Safely’ for Non‑Engineers with a Custom Sandbox MCP”에서 설명했습니다. 여기서는 프로덕션 레포에 PR을 여는 전통적인 엔지니어‑전용 문을 비엔지니어가 직접 통과하는 경우에 초점을 맞춥니다.

이전 섹션 요약

• 변경이 필요하면 엔지니어에게 플래그를 걸지 않고 스스로 해결한다.
• 이 방식이 적용되면 다음과 같은 작업이 가능해진다:
  • “대시보드에 새로운 메트릭을 추가하고 싶다”
  • “집계 필터가 실제 비즈니스 운영 방식과 맞지 않는다”
  • “프로덕션