# Labor0를 만든 이유

## 사람이 병목이 되는 횟수를 줄이기

AI 에이전트 세션을 많이 실행하는 것 자체는 어렵지 않다. 내가 해결하고 싶었던 문제는 세션이 늘어날 때마다 사람이 모든 진행 상황을 확인하고 관리해야 한다는 점이었다.

사람을 병목에서 완전히 빼는 게 목표는 아니다. 사람은 여전히 병목이다. 대신 사람이 개입해야 하는 횟수를 줄이고, 실제로 결정이 필요한 순간에만 사람을 부르는 구조를 만드는 게 중요하다.

나는 이를 위한 작업 체계를 만들었고, 그 중심에 [Labor0](https://labor0.com)가 있다. 한때 50개가 넘는 세션이 돌아갈 때도 내가 느끼는 인지 부하는 거의 없었다.

큰 작업을 맡기면 AI가 먼저 적당한 크기로 나누고, 나뉜 작업의 진행을 주도했다. 작업을 적절한 크기로 나누는 것은 중요하다. PR이 너무 크면 제목만 보고 내용을 파악하기 어렵고, 사람이 직접 리뷰하기도 힘들다. Codex 자동 리뷰의 성능도 떨어진다.

나는 작업이 진행되는 모든 과정에 개입하지 않았다. 결정이 필요한 순간에만 호출받았고, Labor0의 PR 처리와 Codex 자동 리뷰가 모두 끝난 뒤에 PR을 확인했다.

여기서 PR 처리란 CI 실패 수정, 머지 충돌 해결, 리뷰 내용 반영을 말한다. 일부 PR은 나도 코드를 직접 리뷰했다.

안정성을 확보하기 위해 자동화 테스트에도 집중했다. 자동화 테스트에 빈틈이 없는지는 Codex를 활용해 다시 검증했다.

## 에이전트가 이어서 일할 수 있는 이슈 만들기

모든 프로젝트에서는 GitHub를 이슈 관리 도구로 사용했다. 이슈를 만드는 일도 에이전트에 맡겼다.

이를 위해 `add-issue`라는 전용 스킬을 만들었다. GitHub 이슈만 읽어도 문제를 고칠 수 있을 만큼 상세하게 작성하는 것이 이 스킬의 핵심이었다.

`add-issue`는 같은 내용의 이슈가 이미 있는지 확인하고, `main` 브랜치와 배포된 버전도 검사한다. 최신 `main`에서도 아직 고쳐지지 않은 문제일 때만 이슈를 남긴다. 개인정보 등이 이슈에 노출되지 않도록 가리는 기능도 넣었다.

이슈를 남길 때는 Codex 데스크톱 앱의 워크트리 기능을 활용했다. 여러 작업을 서로 다른 워크트리에서 병렬로 진행해 이슈를 동시에 만들었다.

이런 방식으로 작업 속도를 높이는 데에는 많은 토큰이 필요했다. 토큰 사용량은 상당했지만, 토큰 비용은 인건비와 비교하면 매우 저렴하다고 생각한다. 같은 업무를 사람만으로 처리했다면 비용이 30배는 더 들었을 것으로 본다.

## 프로덕션 장애로 확인한 차이

Labor0를 개발하다가 실수로 프로덕션을 중단시킨 적이 있다. 당시에는 어쩔 수 없이 로컬 Codex를 사용해 복구에 필요한 작업을 처리했다.

이 과정에서 Labor0로 일할 때가 로컬 Codex를 직접 사용할 때보다 작업 처리 속도가 훨씬 빠르다는 사실을 확인했다. 이제는 Labor0 없이 Codex만 직접 사용하던 방식으로 돌아가기 어렵다.

그만큼 Labor0의 프로덕션 안정성이 중요해졌다. 지금은 그래프 기반 작업 관리자와 러너처럼 Labor0의 기반을 이루는 구성 요소들의 안정성을 높이는 데 많은 투자를 하고 있다. E2E 테스트를 계속 추가하고 있으며, Codex를 활용해 테스트에 남아 있는 허점도 찾고 있다.

## PR 기반 작업에서 보편적인 작업으로

현재 Labor0가 관리하는 세션은 PR 기반 작업 흐름에 묶여 있다. `CodingTask`의 성공 기준도 PR이다.

다만 내부 구조는 이미 `CodingTask`와 `AgentTask`로 나뉘어 있다. `AgentTask`는 아직 내부에만 존재하는 개념으로, 에이전트가 수행할 수 있는 모든 종류의 작업을 나타낸다. PR을 기준으로 하는 `CodingTask`와 달리 별도의 성공 조건을 가진다.

앞으로는 Labor0가 관리하는 세션을 PR 기반 코딩 작업에서 더 보편적인 작업으로 확장할 계획이다.

러너의 지원 범위도 넓히고 있다. 현재 클라우드에서 호스팅되는 Labor0 러너는 리눅스만 지원한다. 로컬 러너를 이용하면 이미 다른 운영체제의 러너를 사용할 수 있으며, 다른 운영체제를 기반으로 하는 클라우드 러너도 고려하고 있다.

시스템이 관리하는 작업 외에 직접 세션을 확인해야 하는 경우도 있었다. 이런 작업 때문에 Codex 데스크톱을 사용해야 했고, 이를 Labor0 안에서 처리하기 위해 `Direct Task` 기능을 만들었다.

`Direct Task`는 시스템이 관리하지 않는 세션을 직접 만드는 기능이다. 현재 알파 단계이며 아직 공개하지 않았다.

작업이 빠르게 진행되면서 그동안 무엇이 바뀌었는지 파악하기 위한 기능도 필요해졌다. 그래서 만든 것이 `Catch-up`이다.

`Catch-up`은 내가 마지막으로 업데이트를 확인한 시점부터 현재까지 무엇이 바뀌었는지를 AI가 요약해 주는 기능이다. 이 기능도 현재 알파 단계다.

## 사람이 입력하던 프롬프트까지 자동화하기

지금은 `"labor0" 라벨이 붙은 모든 이슈를 고쳐줘` 같은 프롬프트를 내가 반복해서 입력해야 한다.

다음 단계는 이런 프롬프트를 직접 입력하는 일까지 줄이는 것이다. 현재 구상하는 방식은 GitHub 이벤트를 감지하고, 특정 검색 조건을 만족하는 이슈를 Labor0의 작업 그래프에 자동으로 추가하는 것이다.

회사와 프로젝트마다 일하는 방식이 크게 다르기 때문에 특정한 작업 방식에만 맞추지는 않을 생각이다. 각 사용자가 자신의 작업 방식에 맞게 조정할 수 있도록 범용적인 형태로 설계할 계획이다.

이 구조는 GitHub 이슈 외의 신호에도 적용할 수 있다. Grafana나 Sentry 같은 런타임 모니터링 도구에서 문제가 발생하면 작업 그래프에 자동으로 작업을 추가할 수 있다.

슬로 쿼리 로그를 분석해 최적화 작업을 만들거나, 메인 브랜치의 CI가 깨졌을 때 이를 고치는 작업을 생성하는 기능도 추가할 예정이다. 필요한 문서 업데이트 작업도 자동으로 만들 계획이다.

이벤트가 발생했을 때뿐만 아니라 정해진 주기에 맞춰 작업을 반복 실행하는 기능도 있다. 이 기능은 현재 알파 단계다.

## QA도 같은 흐름으로

회사 블로그에는 [Codex Desktop으로 매시간 PR QA를 자동화한 과정](https://theaiplatform.app/blog/automating-pull-request-qa-with-codex-desktop/)을 정리한 글도 썼다.

Codex 데스크톱이 매시간 PR 하나를 골라 빌드하고, 실제 앱을 조작해 변경된 흐름을 검사한 뒤, 스크린샷과 함께 GitHub 리뷰를 남기도록 만든 작업이다. 이것도 Codex 데스크톱으로 직접 구성했다.

앞으로는 이런 QA 작업도 Labor0에서 더 쉽게 만들 수 있도록 지원할 예정이다. 이를 위해 준비하고 있는 기능이 `Chatty QA`다.

`Chatty QA`는 명백히 잘못된 부분을 발견하면 작업 그래프에 추가해 에이전트가 고치게 한다. 디자인에 관한 결정이 필요하면 스크린샷 등 판단에 필요한 자료와 함께 사용자에게 질문한다. 이 기능도 현재 알파 단계다.

## 목표

우선은 내가 해야 했던 일 가운데 디자인에 관한 결정을 제외한 나머지를 Labor0를 통해 자동화하는 것이 목표다.

더 장기적으로는 지금까지 Codex 데스크톱을 사용해야 했던 작업과 번거롭지만 직접 처리해야 했던 대부분의 작업을 Labor0 안에서 훨씬 편하게 처리할 수 있도록 만들 생각이다.

사람을 작업 과정에서 없애려는 것이 아니다. 에이전트가 처리할 수 있는 일은 계속 진행하게 하고, 사람의 결정이 필요한 순간에만 사람을 부르는 시스템을 만드는 것이 목표다.