전체 글 목록인사이트

AI에게 매니저 자리를 맡긴다는 것 — ClickEye가 만드는 개발 문화의 변화

발행일: 2026-06-08·8 분 읽기

AI 시대에 개발이 빨라진 이유는 무엇인가? 흔한 답인 “모델이 더 잘한다”는 정답이 아니다. 단일 AI 한 종에 모든 일을 맡기면 오히려 새로운 병목이 생긴다. 진짜 동력은 다른 곳에 있다 — AI에게 프로젝트 매니저 자리를 맡기고, 영역마다 가장 잘하는 AI에게 자동으로 일이 위임되고, 그 위를 경험 있는 인간 리더가 관장하는 다층 협력 구조가 그 답이다. 이 글은 그 구조가 어떻게 작동하는지를, 우리가 ClickEye 방식으로 개발 중인 자사 제품 Hawkeye에서 일어난 세 가지 사건으로 보여준다. 같은 규모의 시스템을 전통적인 방식으로 만들었다면 15-20명 팀이 12-18개월 걸렸을 일을, ClickEye 방식은 소수의 핵심 인력으로 3-4개월에 옮기는 메커니즘 — 그게 이 글의 주제다.

0. Hawkeye는 어떤 제품인가

본문에 들어가기 전에 사례의 무대를 짧게 소개한다. Hawkeye는 ClickEye가 자사 인큐베이션으로 개발 중인 대규모 GPU 데이터센터를 위한 AI 운영 플랫폼이다. 클라우드 사업자와 AI 인프라 운영자가 가진 가장 큰 고민은 동일하다 — 수천 대의 GPU 서버에서 끊임없이 발생하는 이벤트(과열, 성능 저하, 작업 실패, 네트워크 이상)를 사람의 손으로 따라잡을 수 없다는 것이다. Hawkeye는 그 이벤트를 자동으로 수집·분석·판단하고, 필요한 경우 AI가 직접 조치를 수행한다. 그 과정에서 책임이 큰 결정은 운영자가 최종 승인한다(human-in-the-loop). 기존의 단순 모니터링 도구가 “무엇이 문제인지 보여주는 데서 끝”이라면, Hawkeye는 “무엇이 문제이고, 어떻게 해야 하며, 누구 승인이 필요한지를 함께 제시하고 자동으로 실행하는” 시스템이다.

실 운영 규모로 5,000대 이상의 GPU 디바이스, 초당 5만 건의 이벤트, 3,300개 이상의 탐지 규칙을 동시에 다루도록 설계되어 있다. 이런 규모의 시스템을 전통 SI로 구축하면 팀 15-20명이 12-18개월에 걸쳐 만드는 게 표준이다. ClickEye가 자사 방식으로 이 시스템을 60일 가까운 시간에 운영 가능 상태로 수렴시킨 과정이 이 글의 사례다. 같은 방식은 ClickEye가 고객 프로젝트에도 그대로 적용한다.

1. 빠름을 만드는 네 층

ClickEye 방식의 핵심은 단일 모델이 아니라 다음 네 층이 함께 움직이는 데 있다.

  1. 경험 있는 인간 리더가 전략 layer에 위치해 제품 방향·범위·최종 게이트만 잡는다.
  2. 프로젝트 매니저 역할을 하는 AI(Google의 Gemini로 구동)가 모든 작업을 중앙에서 분류하고, 각 작업의 난이도에 따라 어떤 AI가 그것을 다룰지 자동 결정한다. 이 AI 매니저는 직접 코드를 짜지 않는다 — 오직 분배만 한다.
  3. 영역별 특화 AI들이 이 AI 매니저의 분배를 받아 동시에 작동한다. 코드 리뷰와 테스트는 OpenAI의 코드 전문 AI(Codex), 아키텍처와 데이터베이스·운영 안정성·도메인 검증은 Anthropic의 고급 AI(Claude Opus) — 영역마다 가장 잘하는 AI가 들어간다.
  4. ClickEye 워크플로우(Harness)가 위 세 층을 하나의 실행 가능한 체계로 묶는다. 팀이 따라야 할 약속, 누가 언제 무엇을 검토하는지의 역할 정의, 자동화된 호출 흐름 — 이 세 가지가 한 곳에 보관되어 다음 프로젝트에 그대로 복제 가능하다.

이 구조의 어디서 속도가 나오는지 사례로 풀어보자.

2. AI 프로젝트 매니저가 중심에 앉으면 일어나는 일

Hawkeye에서 가장 결정적인 설계 한 가지는 프로젝트 매니저 역할 자체를 사람이 아닌 AI에게 맡긴 것이다. Gemini로 구동되는 이 AI 매니저가 하는 일을 풀면 이렇다.

  • 제품의 방향과 요구사항을 정리해 작업 단위로 쪼갠다.
  • 쪼갠 각 작업에 난이도 등급(1·2·3)을 자동 부여한다. 1등급은 단순·반복 작업, 2등급은 설계 민감도 있는 중간 난이도, 3등급은 고복잡·크로스도메인·고위험 작업. 데이터베이스 작업은 무조건 3등급, 보안 관련도 무조건 3등급이라는 규칙이 매니저 AI 안에 박혀 있다.
  • 난이도에 따라 어떤 AI가 그 작업을 처리할지 자동 매칭한다 — 1등급은 가볍게, 3등급은 가장 강한 AI(Claude Opus 확장 모드)로.
  • 모든 기획·요구사항 산출물은 코드 전문 AI(Codex)와 이중으로 검토한다.

결과적으로 사람이 매번 “이 작업은 어떤 AI로 가자”를 결정하지 않는다. AI 매니저가 도메인을 읽고 자동으로 결정한다. 사람의 일은 그보다 한 단계 위로 올라간다 — 시장 컨텍스트, 우선순위, scope 동결, 최종 승인. 이게 ClickEye의 슬로건 Execution by Experience가 가리키는 ‘경험’이다. 경험은 정책으로 코드화되고, 집행은 AI 매니저가 위임받는다.

3. 영역마다 가장 잘하는 AI에게 자동 위임된다

AI 매니저가 분배하면, 그 작업이 즉시 그 영역의 챔피언 AI에게 자동으로 넘어간다. Hawkeye 프로젝트에는 14개의 전문 역할이 정의돼 있고, 각 역할마다 가장 잘하는 AI가 의도적으로 다르게 배정돼 있다.

  • 프로젝트 매니저 / 작업 분해 담당 → Google의 Gemini (대규모 컨텍스트와 광범위 계획에 강점)
  • 코드 리뷰 / 테스트 / 품질 보증 → OpenAI의 Codex (코드 정확성과 변경 단위 추론에 강점)
  • 아키텍처 / 데이터베이스 / 운영 안정성(SRE) / 도메인 전문가 → Anthropic의 Claude (특히 데이터베이스 작업은 가장 강한 Claude Opus 필수). 장기적인 추론과 도메인 trade-off 설계에 강점.

4개 핵심 역할(매니저, 작업 분해, 코드 리뷰, QA)은 모든 요구사항과 모든 코드 변경이 반드시 통과해야 하는 필수 게이트다. 나머지 10개 — 아키텍트, 데이터 파이프라인, 인텔리전스, 플랫폼, 인프라, 보안, UI/UX, 기술 문서, 모니터링 등 — 은 해당 도메인이 만나는 순간 자동으로 호출되는 전문가 패널이다. 한 사람이 모든 단계를 직렬로 통과시키는 SI 모델과 달리, AI 매니저가 분배하는 순간 14개의 전문 AI가 동시에 움직인다.

4. ClickEye 워크플로우(Harness)가 묶는다

모델 배정만으로는 부족하다. 어떤 약속 위에서 어떤 순서로 모델들이 협업할지가 정의되어야 한다. ClickEye가 말하는 AI Workflow Execution System의 실체가 그 정의다. 세 묶음으로 구성된다.

  • 팀의 약속 — 팀이 따르겠다고 선언한 18개의 원칙이 정책으로 박혀 있다. 가장 결정적인 다섯 가지: 사용성 우선(백엔드가 아무리 정확해도 운영 화면이 이상하면 가치 0), 미루기 금지(‘Phase 2에서 한다’는 표현으로 1차 release를 부분 기능으로 내보내는 것 금지), 설계 우선(전문가 검증을 통과하기 전 코드 작성 금지), 최신 소스 배포(매 배포는 main 브랜치 최신 상태에서 시작), 근거 추적(GPU 사양 같은 수치는 반드시 제조사 데이터시트와 측정 근거로 추적). 이건 문서가 아니라 위반 시 코드 제안 자체가 차단되는 정책이다.
  • 역할 정의 — 위의 14개 역할이 각각 어떤 AI로 작동하는지, 무엇을 검토하는지가 미리 적혀 있다. ‘감으로’ 품질을 판단하는 단계가 제거된다.
  • 자동화 흐름 — 도구 호출 전 환경 검증, 모델 자동 라우팅, 정형 작업의 재현 가능한 스크립트화.

슬로건은 회의록에 남고 잊힌다. 이 체계는 약속을 다음 프로젝트에 그대로 복제 가능한 형태로 보관한다. 마케팅에서 말하는 “검증된 Workflow 재사용”이 추상이 아닌 이유다.

5. 세 사건으로 본 작동의 모양

사건 ① — 운영 화면이 0/0/0으로 보였을 때

AI 운영 대시보드의 핵심 지표 세 칸이 영원히 0/0/0으로 표시되는 사건이 발생했다. 백엔드는 신뢰도 점수를 정확하게 계산하고 있었지만, 운영자가 보는 화면은 거짓말처럼 0만 보였다. 전통적 SI 응답은 둘 중 하나다 — “설계 문서에 분리되어 있어 의도된 동작” 또는 “Phase 2에서 보강”. 사용성 우선 약속이 두 응답을 모두 금지한다. 인간 리더가 이 사건을 최우선 티켓으로 AI 매니저에게 던졌고, AI 매니저는 이를 ‘3등급 크로스도메인’으로 분류해 다섯 명의 전문가 AI — 아키텍트, 인텔리전스, UI/UX, 모니터링, 플랫폼 전문가 — 를 동시에 호출했다. 결과는 백엔드 설계의 의미를 다시 정의하고 UI를 재설계한 것. 인간 리더가 게이트를 잡고, AI 매니저가 라우팅하고, 다섯 개의 전문가 AI가 도메인별 검수를 병렬로 수행한 모양이다.

사건 ② — 통지 시스템이 부분 release로 나가지 않았다

시스템 운영자에게 알림을 보내는 통지 기능은 SI 프로젝트가 가장 자주 ‘Phase 2’로 미루는 영역이다. 1차 release에 이메일만 넣고, 슬랙은 다음 사이클로, 단계별 에스컬레이션은 v2.0으로, 감사 로그는 시간 나면 — 이게 표준이다. Hawkeye는 그 표준을 깼다. 미루기 금지 약속이 부분 release를 차단하는 동안, AI 매니저가 작업을 분해하고 각 영역의 전문 AI들이 동시에 작업했다. 한 release에 이메일·Slack·Teams·Webhook·SMS 다섯 채널, 채널별 재시도, 사용 기관별 일·월 할당량, 다단계 에스컬레이션, 사용 추적, 서비스 수준 위반 보고가 모두 운영 가능 상태로 묶여 나왔다. 여러 AI가 각자 영역에서 동시에 작동했지만 release는 한 점에 수렴했다.

사건 ③ — 5개의 누락이 같은 주에 닫혔다

GPU 클러스터의 각 서버에서 권한을 가지고 동작하는 작은 프로그램(에이전트)을 만드는 작업이 있었다. 보안 관련이라 AI 매니저가 자동으로 최고 난이도(3등급)로 분류했고, 아키텍트와 플랫폼 전문가 AI(둘 다 Claude Opus)가 공식 설계 결정 문서를 작성하면서 같은 코드 제안 묶음에 실제 코드 뼈대를 함께 commit했다(설계 우선 + 설계와 코드를 같은 묶음으로 결합하는 약속이 동시에 작동한 모양). 일주일 뒤 플랫폼 전문가 AI가 검수해서 5개의 누락을 찾았다 — 호출자가 없는 dead code 한 라이브러리, 충돌 후 복구 로직 누락, 헬스체크 스키마에 종료 상태 컬럼 누락 등. 전통 SI 응답은 “다음 사이클 백로그”다. 여기서는 AI 매니저가 각 누락을 새 티켓으로 환산하고 난이도를 재배정했고, 같은 주에 세 번의 PATCH 버전이 차례로 release 됐다. 전문가 검수가 AI 매니저의 다음 라운드 티켓으로 즉시 환산되는 흐름이다. 되돌이 작업이 사이클 단위로 길게 늘어지지 않는다.

6. 그래서 왜 3-4개월에 수렴되는가

전통 SI에서 속도를 잡아먹는 두 가지 — 병목과 되돌이 작업 — 가 이 구조에서 구조적으로 차단된다.

  • 병목 차단 — AI 매니저가 분배하는 순간 14개의 전문 AI가 동시에 움직인다. 한 사람이 모든 단계를 차례로 통과시키는 직렬 구조와 다르다.
  • 되돌이 작업 차단 — 설계 우선이 설계 누락을 막고, 설계와 코드를 같은 묶음으로 결합하는 약속이 사양과 코드의 괴리를 막고, 사용성 우선이 백엔드와 화면의 불일치를 막고, 미루기 금지가 부분 release로 인한 미래 손실을 막는다. 다시 돌아가서 고치는 일이 발생할 수 있는 지점마다 약속이 그 발생을 미리 막는다.

ClickEye의 비교 카피 — “인력 중심·확장 비효율” vs “자동화 중심·즉시 확장”, “일정 지연 빈번” vs “기존 대비 ~3배 빠른 납품”, “매번 새로 개발” vs “검증된 Workflow 재사용” — 은 이 구조가 만들어내는 결과다. Hawkeye 60일이 보여준 건 그 메커니즘이 실제 프로젝트에서 어떻게 발동되는지의 모양이다.

7. 다음 프로젝트에 가지고 가는 것

Hawkeye가 끝나도 ClickEye에는 자산이 남는다. 18개의 약속, 14개 역할의 정의, AI 매니저의 난이도 배정 정책, 자동화 흐름은 다음 프로젝트의 첫날 그대로 옮겨갈 수 있는 형태로 보관되어 있다. 마케팅에서 말하는 “검증된 Workflow 재사용”이 추상이 아닌 이유다.

요약하면 ClickEye 방식은 네 층의 협력이다.

  1. 전략 layer — 인간 리더가 제품 방향·역할 설계·범위 동결·최종 게이트를 잡는다.
  2. 오케스트레이션 layer — AI 매니저(Gemini)가 모든 작업을 분배한다. 코드는 짜지 않고 분배만 한다.
  3. 실행 layer — 영역별 특화 AI들(Codex, Claude Opus 등)이 동시에 작업한다.
  4. 통합 체계(Harness) — 약속·역할·자동화가 하나로 묶여 위 세 layer를 연결한다.

8. 마치며

AI 시대의 진짜 혁신은 단일 AI 한 종에서 나오지 않는다. AI 매니저가 중앙에서 분배하고, 영역별 특화 AI가 자동으로 위임을 받고, ClickEye 체계가 약속을 하나로 묶고, 경험 있는 인간 리더가 그 위 전략 layer에 위치하는 다층 구조 자체가 자산이다. Hawkeye 60일은 그 구조가 실제로 작동했음을 보여주는 사례이고, ClickEye가 시장에 약속하는 속도·비용·신뢰성은 그 구조의 결과다.

비슷한 규모의 시스템을 비슷한 신뢰도로 만들어야 한다면, 우리는 같은 정책과 같은 체계에서 시작한다. 다른 SI가 인력 견적 부터 시작하는 곳에서, 우리는 AI 매니저와 그 분배 정책을 첫날 그대로 가져오는 것에서 시작한다. 그래서 같은 결과를, 더 적은 비용과 더 짧은 시간에 만든다.

본 글의 사례·약속·역할 매핑은 ClickEye 워크플로우 방식으로 진행 중인 내부 프로젝트(Hawkeye)의 실제 내부 문서·설계 결정 기록에서 직접 추출했다. 코드 라인 수, 변경 commit 수 같은 raw 수치는 자동 생성 코드와 보일러플레이트가 섞이는 vanity metric이라 본문에서 의도적으로 제외했다. 전통 SI의 15-20명·12-18개월 견적은 동일 규모(GPU 5,000대 이상·초당 5만 건 이벤트·3,300 탐지 규칙) NOC 시스템에 대한 일반 산업 통념이며, 정확한 수치는 프로젝트마다 다르다.