AI 개발 팀 관리 7일간의 기록

첫날, 저는 아홉 가지 작업을 계획했습니다. 그중 세 가지만 완료되었습니다.

나머지 여섯 가지 작업은 익숙한 문제에 부딪혔습니다: 저에게 결정이 필요한 부분, 제가 로컬 GUI에 복사해야 하는 프롬프트들, 그리고 실제로 무엇이 진행되고 있는지에 대한 불확실성이었습니다. 저는 업무를 위임했지만 여전히 많은 조정 작업을 직접 수행하고 있었습니다.

2026년 10월 1일부터 7일까지, 저는 개인 프로젝트를 위해 작은 AI 팀을 운영한 일일 기록을 남겼습니다. 저는 'Docchee'라고 부르는 ChatGPT dots를 코디네이터로 사용했고, 다른 AI 도구들이 구현, 검토, 연구를 담당했습니다.

7일째 되던 날, 저는 팀에게 긴급하게 준비해야 할 애플리케이션 작업의 우선순위를 변경하도록 요청했습니다. 이 두 시점 사이에서, 저는 예상했던 것보다 핸드오프(handoffs), 승인(approvals), 그리고 가시성(visibility)에 대해 더 많이 배웠습니다.

이것은 한 사람의 워크플로우에서 나온 현장 보고서입니다. 모델 벤치마크나 이 설정이 프로덕션 사고를 안전하게 처리할 수 있다는 증거는 아닙니다.

제가 운영하려 했던 팀

저는 클라우드 엔지니어링 분야에 종사하지만, 이번 실험을 위해 제품 책임자(Product Owner) 역할을 맡았습니다. 목표 정의, 우선순위 선택, 결과적인 조치 승인, 그리고 결과가 유용한지 테스트하는 것이었습니다.

작업 분담은 다음과 같았습니다:

역할	책임 범위
저	목표, 우선순위, 승인 및 인수 테스트
...
이것들은 완전히 자동화된 라우팅 아키텍처가 아니라 실제 작동하는 역할들이었습니다. 할당되는 업무는 작업의 종류, 사용 가능한 사용량(usage allowance), 그리고 적절한 환경에 대한 접근성에 따라 변경되었습니다. 저는 전체적인 워크플로우를 multi-ai-workflow에서 확인할 수 있습니다.

1~2일차: 핸드오프가 저의 문제였습니다

저의 초기 가정은 더 많은 작업을 분배하면 더 많은 업무가 진행될 것이라는 것이었습니다. 하지만 실제로는 누군가의 입력이 필요한 장소만 더 많이 만들어냈습니다.

처음에는 제가 인터페이스들 사이를 프롬프트를 수동으로 옮겨야 했습니다. CLI 접근은 준비되지 않았습니다. 어떤 작업들은 제가 명시적으로 결정하지 않은 판단을 필요로 했고, 다른 작업들은 그 시점에 저만이 수행할 수 있는 로컬 조치를 필요로 했습니다.

가장 유용했던 첫 번째 조정은 간단했습니다. 최종 목표를 더 명확하게 만들고, 제가 반복적으로 물어보는 대신 Docchee가 무엇이 남아있는지 알려주게 한 것입니다.

2일째가 되자 작동 가능한 리듬이 생겨나기 시작했습니다. 인간 개입형(Human-in-the-loop) 승인은 여전히 어려웠습니다. 저는 일상적인 작업들이 중단 없이 진행되기를 원했지만, 출판, 권한 부여 및 기타 중요한 조치에 대해서는 의미 있는 통제권을 유지하고 싶었습니다.

이를 위해서는 더 정밀한 작업 경계가 필요했습니다. '계속 진행'이라는 정보만으로는 모든 다음 단계를 위한 충분한 정보가 아니었습니다.

3~4일차: 로컬 접근성은 개선되었으나 승인 경계는 여전함

3일차에는 팀을 제 Windows 환경에 통합하고 CLI(Command Line Interface) 기반 워크플로우를 준비하는 데 집중했습니다. 수동 복사-붙여넣기 작업을 줄이는 것은 실질적인 개선이었습니다.

사용 허용 범위 또한 작업 할당의 일부가 되었습니다. 까다로운 디자인이나 검토는 더 강력한 모델을 정당화할 수 있었고, 다른 작업은 가용 용량이 더 많은 다른 도구로 이동할 수 있었습니다.

저는 일일 게시물에서 이를 '토큰 인식 조정(token-aware coordination)'의 시작이라고 설명하며 흥분했습니다. 실제 상태는 좀 더 소박했습니다. 우리는 할당 결정을 내리기 위해 사용 가능한 디스플레이와 보고서를 활용하고 있었습니다. 지속적인 사용량 수집과 동적 라우팅은 아직 목표였을 뿐, 완성된 제어 시스템은 아니었습니다.

4일차에는 또 다른 경계가 드러났습니다. ChatGPT나 Codex로 전달되는 작업이라도 별도의 승인을 위해 멈출 수 있었습니다. 동일한 제공업체의 도구를 사용한다고 해서 전체 워크플로우가 하나의 권한 상태를 공유하는 것은 아니었습니다.

유용한 질문은 다음과 같았습니다. 정확히 어떤 작업이, 어떤 환경에서 차단되었으며, 무엇을 하면 진행될 수 있을까? '승인 대기 중'이라는 일반적인 라벨은 제가 복구해야 할 너무 많은 작업을 남겼습니다.

5일차: 음성 지시와 30분 간격의 주기적 점검이 효과적이었음

5일차에는 워크플로우의 대부분을 음성 입력으로 실행했습니다. 저에게는 명령어 또는 검토 요청을 타이핑하는 것보다 말로 하는 것이 훨씬 빠를 때가 많았습니다.

또한 병렬 작업 전반에 걸쳐 30분마다 상태 업데이트를 도입했습니다:

목표와 우선순위를 설정했습니다.
Docchee가 작업을 정리하고 할당했습니다.
다음 점검 시 진행 상황과 장애 요소를 검토했습니다.
결정 사항, 수정 사항 또는 새로운 요청을 전달했습니다.
작업이 계속되었습니다.

번호가 매겨진 항목들은 “2번 항목 우선순위 지정”이나 “3번 항목 재개”와 같이 말로 표현하기 쉽게 만들었습니다. 하지만 문제가 있었습니다. 완료된 항목들이 사라지고 목록의 번호가 다시 매겨지면, 숫자는 더 이상 안정적인 작업 식별자가 아니었습니다. 따라서 작업 이름과 최근 맥락을 통해 확인해야 했습니다.

저는 완료된 항목들은 한 번만 보고하고 제거해 줄 것을 요청했습니다. 그렇게 하면 다음 보고는 진행 중인 작업과 결정 사항에 집중할 수 있었습니다.

30분이라는 시간 간격은 보편적인 권장 사항이 아닙니다. 그저 제 워크플로우에 맞았을 뿐입니다. 이로 인해 각 도구를 지속적으로 모니터링해야 하는 부담 없이 점검하는 노력을 줄일 수 있었습니다.

Claude Code, Antigravity, 그리고 ChatGPT를 거쳐 작업을 위임하는 것 또한 더 실용적이 되었습니다. 제가 처리할 수 있는 조정의 양은 여전히 각 환경에서의 접근 권한과 승인에 달려 있었습니다.

6일차: 다양한 종류의 작업이 의미하는 더 많은 보이지 않는 상태

범위는 코딩 및 문서화를 넘어 웹사이트 온보딩, 프로필 업데이트, 짧은 비디오 에셋 등으로 확장되었습니다. 에이전트가 페이지를 검사하고 양식 필드를 처리하도록 하는 것은 반복적인 노력을 많이 줄여주었습니다.

어려운 부분은 중단된 백그라운드 작업을 이해하는 것이었습니다.

저는 보이는 채팅이나 브라우저 창에서 작업의 진행 상황을 추적할 수 있었습니다. 하지만 CLI 프로세스나 백그라운드 활동은 검사하기가 더 어려웠습니다. 만약 두 개의 작업 모두 진행되고 있다고 보고했지만 결과가 돌아오지 않는다면, 어떤 것이 실행 중인지, 어떤 것이 대기 중인지, 아니면 서로 간섭하고 있는지 알 수 없었습니다.

제 가설은 일부 작업들이 공유 브라우저 세션이나 실행 리소스를 두고 경쟁하는 것이라는 것이었습니다. 하지만 저는 이것을 모든 정체의 근본 원인으로 확립하지는 못했습니다. 제가 관찰한 것은 불충분한 가시성과 수동 개입의 필요성이었습니다.

다음 반복에서는 각 활성 작업이 다음 사항들을 노출하기를 바랍니다:

현재 소유자 및 실행 환경
마지막으로 확인된 진행 상황 및 타임스탬프
실행 중인지 또는 대기 중인지 여부
다음으로 필요한 특정 입력, 권한 또는 리소스

이것은 이미 완성되었다고 주장할 수 있는 대시보드가 아니라 설계 목표입니다. 공유 데스크톱 제어는 특별한 주의가 필요합니다. 병렬 연구는 유용할 수 있지만, 동일한 인터페이스에서의 동시 편집은 충돌을 일으킬 수 있습니다.

Day 7: 긴급 요청이 큐를 변경하다

마지막 날에는 중단(interrupt)이 있었습니다. Anthropic의 CVP 신청 준비에 우선순위를 두고 싶었습니다. 여기에는 기존 작업 검토, 보안 검증 증거 개발, 그리고 OSS 기여가 포함되었습니다.

저는 Astra에게 긴급 작업을 명시적으로 할당했습니다. 진행 속도가 빠르다고 느껴졌습니다. 하지만 개선된 점을 모델 자체의 공로로만 돌리는 것은 오해를 불러일으킬 것입니다. 우선순위, 작업 정의, 그리고 주변 워크플로우 자체가 바뀌었기 때문입니다. 저는 통제된 비교 실험을 수행하지 않았습니다.

구체적인 결과물 중 하나는 기존 Mattermost 풀 리퀘스트에 대한 검증 보고서였습니다. 저는 비교 결과를 담은 댓글을 게시했습니다. 이것은 테스트 기여였으며, 제 코드를 업스트림 병합한 것은 아니었습니다.

병행하여 Mattermost와 Docchee 간의 읽기 전용 연결을 준비했습니다. 짧은 터널 시작 및 종료 시험이 수행되었지만, 작성 시점에는 해당 경로를 통해 실제 게시물을 읽는 것이 검증되지 않았습니다. 통합 작업은 여전히 미완성이었습니다.

CVP 신청서 역시 아직 준비 중이었습니다. 유용한 포트폴리오 작업이 곧바로 신청서가 요구하는 자격 증거를 확립해 주지는 않습니다. 저는 계획된 작업이나 일반적인 OSS 활동을 지원되지 않는 자격으로 변질시키지 않으면서, 제가 실제로 무엇을 했는지 설명하고 싶습니다.

Day 7을 통해 저에게 입증된 것은 시간 압박 속에서 개발 워크플로우를 재지정하는 능력입니다. 프로덕션 인시던트 대응은 별도로 테스트해야 하는 역량으로 남아 있습니다.

유지하고 싶은 운영 습관

작업에 관찰 가능한 완료 지점을 부여하기

저는 이 핸드오프(handoff) 형식이 유용하다고 생각합니다:

Goal: 무엇이 가능해져야 하는가?
Scope: 무엇이 변경될 수 있는가?
Out of scope: 무엇은 그대로 두어야 하는가?
...

이는 팀이 시작하기 전에 모호성을 줄여줍니다. 또한 전체 대화를 다시 읽지 않고도 결과를 평가하기 쉽게 만듭니다.

구현과 검토를 분리하기

저는 타임아웃(timeouts), 취소(cancellation), 재시작(restart), 정리(cleanup)와 같은 실패 경로를 포함하여 변경 사항에 대해 별도의 검토자를 사용합니다. 발견된 내용은 증거 또는 재생 단계와 함께 돌아와야 구현 에이전트가 이를 처리할 수 있습니다.

두 번째 모델의 동의만으로는 충분한 증거가 되지 않습니다. 유용한 부분은 그것이 수행하는 추가적인 검사 및 테스트입니다.

실제 완료 단계를 보고하기

구현됨, 모의 테스트 통과, 대상 환경에서 작동함, 사용자 승인 등은 서로 다른 마일스톤(milestone)입니다.

브라우저 작업에도 동일하게 적용됩니다. 파일을 업로드하는 것, 초안을 저장하는 것, 페이지를 게시하는 것은 별개의 결과물입니다. 저는 어떤 것이 일어났는지 알려주는 상태 보고서가 필요합니다.

이것은 팀이 더 많은 종류의 작업을 처리함에 따라 특히 중요해졌습니다. 광범위한 '완료'는 제가 여전히 확인해야 할 정확한 단계를 숨길 수 있기 때문입니다.

짧은 음성 브리핑으로 하루 마무리하기

가장 유용했던 루틴은 하루를 마칠 때의 10분간의 대화였습니다.

저는 제가 어디서 기다렸는지, 무엇이 더 쉬워졌는지, 그리고 다음에 무엇을 시도하고 싶은지에 대해 이야기했습니다. 6일차의 가시성 문제와 7일차의 인시던트 대응 아이디어 모두 이러한 대화를 통해 더욱 명확해졌습니다.

짧은 지침은 제가 낮 동안 작업을 진행하는 데 도움이 되었습니다. 더 긴 대화는 저 자신에게 워크플로우 자체를 성찰할 기회를 주었습니다. 이 두 가지 조합이 저에게 실용적인 인간 참여형 루프(human-in-the-loop) 운영 방식이었습니다.

다음 단계: 실험실에서 비상 워크플로우 테스트하기

저의 다음 질문은 클라우드 엔지니어링 배경에서 비롯됩니다. 이 팀이 서버 장애, 보안 사고 또는 재해 복구 시나리오에 어떻게 대응할까요?

저는 AWS, Azure, Google Cloud 전반에 걸쳐 기존 SRE-agent 접근 방식을 조사하고 실험을 설계하고 싶습니다. 아직 그 실험들은 시작되지 않았습니다.

계획은 정의된 권한과 복구 조건이 있는 통제 환경(controlled environments)을 사용하는 것입니다. 저는 초기 평가 시간과 복구 시간을 측정하고 싶지만, 잘못된 조치, 불필요한 변경 사항, 승인 지연, 그리고 누락된 증거까지도 측정하고 싶습니다.

병렬적인 조사(Parallel investigation)가 도움이 될 수 있습니다. 동일한 리소스에 대한 변경 사항에는 조정이 필요하며, 복구는 선택한 조치가 상황을 악화시킬 경우 되돌아갈 방법이 필요합니다. 이들은 자율적인 사고 처리(autonomous incident handling)에 대해 주장하기 전에 검증해야 할 것들입니다.

1주일 후 달라진 점

저는 과제(tasks)를 세는 것으로 시작했습니다. 주말이 끝날 무렵에는 그 과제들 사이의 인수인계(handoffs)에 더 많은 주의를 기울이게 되었습니다.

개별 과제가 빨라지면서, 주변 제약 조건들이 더 쉽게 눈에 들어오기 시작했습니다: 승인 절차, 공유 리소스, 사용 허용 범위, 그리고 수락 기준(acceptance criteria)입니다. 저 자신의 결정 또한 그 시스템의 일부로 남아 있었습니다.

30분간의 점검 회의와 일일 음성 브리핑은 유지할 가치가 있습니다. 다음으로는 작업이 중단된 상황에 대한 더 나은 가시성과, 무언가 실패했을 때 팀이 어떻게 행동하는지에 대한 더 강력한 증거를 얻고 싶습니다.

7일은 짧은 실험 기간이었습니다. 하지만 2주 차에 무엇을 테스트해야 할지 훨씬 명확하게 파악하기에는 충분했습니다.

본 기사는 2026년 10월 7일 기준의 저의 개인 프로젝트를 반영합니다. 글을 구성하고 편집하는 데 AI 도움을 받았습니다.