1인 스타트업 실행 (6): 혼자 일 나누기 — 사람이 스케줄러가 될 때#

실행 편의 마지막 장은 기술이 아니라 사람에 대한 이야기입니다. 아이디어를 고르고, 에이전트와 제품을 만들고, AI 기능을 넣고, 운영하고, 알리는 일을 혼자서 한다면, 그 “혼자"의 하루는 어떤 모양일까요. 서론에서 1인 스타트업의 “1인"은 의사결정자 한 명과 여러 에이전트 작업자로 이루어진 조직이라고 했습니다. 이 장은 그 조직의 사람 쪽이 어떻게 일해야 하는지를 다룹니다. 필자가 에이전트 여러 개와 동시에 일하면서 겪은 피로의 원인을 조사하고, 실제로 채택한 규칙을 정리한 것입니다.

새로운 병목: 이번에는 사람입니다#

에이전트가 최종 작업을 대신 수행하면서 사람은 동시에 여러 일을 진행할 수 있게 되었습니다. 그런데 필자는 이상한 피로를 느꼈습니다. 에이전트 두세 개와 동시에 대화하며 작업을 진행하다 보면, 손은 바쁘지 않은데 머리가 계속 헛도는 느낌이었습니다. 응답 알림이 올 때마다 즉시 그 세션으로 전환해 확인하는데, 정신은 없고 전체 성과는 오히려 떨어지는 것 같았습니다.

구조를 뜯어보면 이렇습니다. 에이전트는 필자의 머리에 직접 연결되어 있지 않으므로 원하는 바를 전달하려면 대화가 필요하고, 그 대화는 작업 중에도 계속 발생합니다. 에이전트의 응답은 몇 분씩 걸립니다. 그 몇 분을 그냥 기다리는 것은 비효율이니 자연스럽게 다른 작업을 병행하고, 세션이 두 개, 세 개로 늘어납니다. 여기까지는 합리적인 선택의 연속입니다. 문제는 그다음입니다. 세션 사이를 오갈 때마다 “이 세션에서 뭘 하고 있었더라"를 다시 파악하고 그 맥락을 머리에 다시 올리는 데 생각보다 오래 걸립니다. 응답 주기 몇 분짜리 세션이 두세 개 겹치면 전환이 몇 분 단위로 강제되고, 사람은 운영체제의 스케줄러처럼 끊임없이 프로세스를 갈아 끼우는 역할을 떠안게 됩니다. 차이가 있다면 운영체제의 컨텍스트 스위칭은 마이크로초 단위인데 사람의 것은 분 단위라는 점입니다.

이 피로가 기분 탓이 아니라는 근거는 오래전부터 쌓여 있었습니다. 작업 A에서 B로 전환해도 A에 대한 인지 활동이 완전히 꺼지지 않고 남아 B의 수행 성능을 떨어뜨리는 주의 잔류는 이전 작업이 미완결 상태일 때 가장 강하게 남는데, 에이전트와의 대화는 응답을 기다리는 열린 루프이므로 구조적으로 항상 미완결 상태에서 전환됩니다. 중단된 뒤 원래 수준의 몰입으로 돌아오는 데는 평균 20분이 넘게 걸린다는 연구가 있고, 응답 주기 몇 분짜리 대화를 알림 기반으로 오가면 수학적으로 몰입에 도달하는 것 자체가 불가능합니다. 그리고 중단된 작업을 재개할 때 걸리는 시간은 떠나기 직전에 “돌아오면 무엇부터 한다"는 목표를 새겨 두고 눈에 띄는 재개 단서를 준비해 두면 크게 줄어듭니다.

정리하면, 알림이 올 때마다 즉시 전환하는 방식은 미완결 상태의 전환(잔류 최대화)을 몇 분 간격으로(회복 불가능) 아무 단서 없이(재개 지연 최대화) 반복하는 것입니다. 나쁜 조건만 골라서 조합한 셈이니 정신이 없는 게 당연했습니다.

필자가 채택한 세 가지 규칙#

규칙 1. 알림 즉시 전환 금지, 코루틴 방식으로#

알림이 와도 바로 넘어가지 않고, 지금 보고 있는 세션의 작은 태스크 단위를 마무리한 뒤에 전환합니다. 작은 태스크 단위란 “응답을 다 읽고 다음 질의를 보냈다” 정도의 완결 지점입니다. 프로그래밍에 비유하면 멀티스레딩이 아니라 코루틴입니다. 멀티스레딩에서는 스케줄러가 아무 때나 실행을 끊고 다른 스레드로 넘기지만(선점형), 코루틴은 각 작업이 스스로 “여기서 멈춰도 안전하다"는 지점에서만 차례를 양보합니다(협력형). 알림 즉시 전환은 내 머리를 선점형으로 운영하는 것이고, 태스크 완결 후 전환은 협력형으로 운영하는 것입니다.

이 비대칭을 기억해 두면 마음이 편해집니다. 에이전트는 기다려도 아무 비용이 없습니다. 응답이 몇 분 늦게 읽혀도 손해는 0인데, 사람의 생각이 중간에 끊기는 비용은 실측된 값이 있습니다. 그러니 항상 사람의 리듬이 우선입니다.

규칙 2. 떠나기 전, 입력란에 재개 메모를 남깁니다#

여러 개의 창에 여러 에이전트 세션을 열어 두고 일하면 가장 자주 겪는 문제가 “이 세션에서 뭘 하고 있었더라"입니다. 세션을 떠나기 전에 20초만 들여 그 세션의 질의 입력란에 현재 맥락과 다음에 할 일을 짧게 적어 둡니다. 입력란은 돌아왔을 때 가장 먼저 시선이 가는 곳이므로, 별도 메모 도구 없이 그 자체로 재개 단서가 됩니다. 한 단계 더 나아가면 이 역할을 에이전트에게 위임할 수도 있습니다. 자리를 비우기 전에 “내가 돌아오면 현재 상태 요약과 나에게 필요한 결정 사항을 맨 위에 정리해 달라"고 요청해 두면, 재개 단서가 화면에 자동으로 준비됩니다. 맥락 저장소 역할을 사람의 머리가 아니라 에이전트가 맡게 됩니다.

규칙 3. 대화형 작업은 동시에 두 개까지#

병행 중인 작업을 두 종류로 나눕니다. 몇 분 간격으로 사람의 판단을 요구하는 대화형과, 한 시간 이상 혼자 진행하는 장기 자율형입니다. 장기 자율형은 몇 개가 돌아도 무방합니다. 전환이 예정된 시점에만 발생하기 때문입니다. 문제는 대화형이고, 필자는 동시 진행 수를 두 개 전후로 제한하기로 했습니다. 숫자 자체는 상황에 따라 조정할 수 있지만, 대화형 작업의 동시 진행 수에 상한을 둔다는 원칙이 핵심입니다. 다수의 에이전트를 병행 운용해 본 사람들의 경험담도 비슷한 지점으로 수렴합니다. 서너 개 이상은 인지적으로 감당되지 않는다는 것입니다.

여기에 덧붙일 재해석이 하나 있습니다. 작업의 “깊이"는 작업의 속성이 아니라 국면의 속성입니다. 같은 작업도 설계를 고민하는 국면에서는 깊고, 에이전트가 혼자 구현하는 국면에서는 얕습니다. 그렇다면 규칙은 “깊은 작업을 하나만 두라"가 아니라 “두 작업의 깊은 국면이 겹치지 않게 위상을 어긋나게 배치하라"가 됩니다. 한 작업이 설계 국면일 때 다른 작업은 구현 국면에 있도록 배치하는 것입니다.

가장 레버리지가 큰 개입은 전환을 잘하는 것이 아니라 전환할 일 자체를 줄이는 것입니다. 본 작업 전에 “구현하지 말고 내가 결정해야 할 사항을 먼저 조사해서 목록으로 가져와 달라"는 탐색 패스를 한 번 돌리거나, “막히는 것은 모아 뒀다가 단계가 끝날 때 한꺼번에 물어봐 달라"고 지시해 질문의 도착 간격을 넓히는 방식입니다. 에이전트가 한 번의 지시로 더 오래, 더 멀리 갈수록 사람의 컨텍스트 스위칭 문제는 자연히 완화됩니다.

노트북을 닫아도 일하는 에이전트#

대화형 작업의 수를 제한했다면, 나머지 일은 장기 자율형으로 보내야 합니다. 그런데 에이전트의 실행 환경이 노트북에 묶여 있으면 노트북을 접는 순간 에이전트도 멈춥니다. 에이전트를 쓰는 이유는 사람이 자리를 비운 동안에도 일을 맡기기 위해서인데, 이동 중에는 확인만 할 수 있고 실제 작업은 이어 가기 어렵습니다. 긴 테스트, 의존성 설치, 저장소 분석처럼 시간이 걸리는 작업은 특히 그렇습니다.

그래서 필자는 방향을 바꿨습니다. 에이전트는 항상 켜져 있는 원격 서버에 두고, 어디서든 메시지로 지시하는 구조입니다. 상주형 에이전트를 작은 클라우드 인스턴스에 올리고, 실제 명령 실행은 그 안의 컨테이너에서 이루어지게 하고, 메신저 앱을 운전석으로 씁니다.

구성에서 중요한 것은 세 가지였습니다. 첫째, 인스턴스는 작고 단순하게. 대규모 서비스 운영이 아니라 개인용 실행 환경이므로, 복잡한 클라우드 구성보다 인스턴스, 고정 IP, 방화벽, 스냅샷 정도만 이해하면 되는 단순한 서비스가 충분했습니다. 방화벽은 SSH만 내 IP로 제한하고, 에이전트의 API나 대시보드 포트는 외부에 열지 않습니다. 둘째, 실행은 컨테이너 안에서. 에이전트가 호스트의 설정 파일, SSH 키, 환경변수 같은 민감 파일을 건드리지 못하도록 작업 공간을 분리합니다. 컨테이너에 마운트하지 않은 폴더는 에이전트에게 존재하지 않습니다. 셋째, 비밀값은 공개 문서에 절대 남기지 않기. 모델 API 키, 메신저 봇 토큰, 저장소 토큰(필요한 저장소만 접근 가능한 세분화된 토큰), 서버 키는 호스트의 설정 파일에만 두고, 채팅 로그나 글에는 자리표시자로만 적습니다.

메신저 선택도 의외로 중요했습니다. 팀 공용 봇과 업무 채널 통합에는 회사 메신저가 맞지만, 개인용 원격 개발 에이전트로는 개인 서버를 하나 만들어 전용 채널로 대화하는 쪽이 더 단순했습니다. 긴 작업 로그와 팀 대화가 한 공간에 섞이지 않고, 모바일에서 개인 에이전트와 팀 커뮤니케이션이 분리됩니다.

이 환경이 생기자 일의 배치가 달라졌습니다. 노트북 앞에서는 대화형 작업 두 개를 돌리고, 긴 테스트나 저장소 분석이나 야간 집계 같은 장기 자율형 작업은 원격 에이전트에게 메시지로 넘깁니다. 이동 중에 결과를 확인하고 다음 지시를 남기면, 돌아왔을 때 결과가 준비되어 있습니다.

역할이 아니라 영역의 오너로#

마지막으로, 혼자서 여러 에이전트와 일하는 것은 결국 작은 조직을 운영하는 일입니다. 그리고 그 조직을 나누는 기준은 전통적인 직군이 아닙니다. 회사에서 관찰한 변화가 이 점을 분명히 보여 주었습니다. AI 도구와 에이전트 환경이 발전하면서 한 사람이 기획, 디자인, 개발을 모두 직접 시도하는 장면이 흔해졌고, 직군보다 누가 어떤 영역의 목표와 결과를 책임지는가가 더 중요해졌습니다. 인간은 목표, 우선순위, 제약, 책임을 정의하는 쪽으로 이동하고, AI는 실제 작업을 수행하는 쪽으로 이동합니다.

1인 스타트업에서는 이것이 더 선명합니다. 창업자는 모든 영역의 오너이고, 각 영역에 에이전트를 배치합니다. 제품 영역에는 코딩 에이전트를, 콘텐츠 영역에는 글쓰기와 번역 스킬을, 운영 영역에는 상주 에이전트의 크론 작업을, 분석 영역에는 조회 스킬을 둡니다. 영역마다 창업자가 정해야 할 것은 같습니다.

• 무엇을 목표로 할지
• 어떤 제약 안에서 움직일지
• 어디까지 자동 반영해도 되는지, 어떤 변경은 반드시 사람의 확인이 필요한지
• 무엇을 성공으로 볼지
• 문제가 생기면 어떻게 되돌릴지

이 기준이 명확한 영역은 에이전트에게 넘길 수 있고, 명확하지 않은 영역은 아직 사람이 들고 있어야 합니다. 그리고 가장 위험한 일은 실험과 운영을 섞는 것입니다. 에이전트가 빠르게 만든 실험 결과를 그대로 운영에 넣으면 검토 비용과 장애 비용이 뒤로 미뤄질 뿐입니다. 실험은 자유롭게, 운영 반영은 작고 명확한 단위로. 제품 장에서 말한 원칙이 조직 운영에도 그대로 적용됩니다.

에이전트를 잘 쓰는 능력이 중요해진 시대라고들 합니다. 필자는 그 능력의 절반이 프롬프트가 아니라 사람 쪽 스케줄링에 있다고 느낍니다. 에이전트의 성능은 계속 좋아지고 있으니, 남는 병목은 여러 세션 사이를 오가는 사람의 머리입니다. 이 병목은 도구를 바꾼다고 해결되지 않고, 전환의 주도권을 회수하고, 열린 루프의 수를 제한하고, 열린 루프마다 재개 단서를 붙이고, 긴 일은 원격에 넘기는 습관의 문제입니다. 어쩌면 이 규칙들은 에이전트의 자율 실행 능력이 충분히 좋아질 때까지의 과도기를 버티는 기술일지도 모릅니다. 다만 그 과도기가 생각보다 길 수 있으니, 버티는 기술도 제대로 갖춰 둘 가치가 있습니다.

체크리스트#

1. 알림이 아니라 내가 전환 시점을 정합니다. 작은 태스크를 완결한 뒤에 넘어갑니다.
2. 세션을 떠나기 전 입력란에 재개 메모를 남기거나, 에이전트에게 상태 요약을 준비시킵니다.
3. 대화형 작업은 동시에 두 개까지. 장기 자율형은 제한 없이.
4. 본 작업 전에 탐색 패스를 돌려 결정 사항을 앞으로 모으고, 질문은 단계 끝에 모아 받습니다.
5. 긴 작업은 항상 켜져 있는 원격 에이전트에게 메시지로 넘깁니다.
6. 원격 에이전트는 컨테이너 안에서 일하고, 비밀값은 호스트에만, 공개 포트는 SSH 하나만.
7. 영역마다 목표, 제약, 자동 반영 범위, 성공 기준, 롤백 방법을 정하고, 명확한 영역부터 에이전트에게 넘깁니다.