TL;DR — 혼자 AI 에이전트 여러 대를 데리고 회사를 굴립니다. 할 일 목록 맨 위에 몇 주째 같은 항목이 붙어 있었어요. 매일 아침 보고서에 그대로 이월했죠. "이거 아직이지." 그런데 어느 날, 넘기는 대신 실제 코드를 열어봤습니다. 이미 다 되어 있더라고요. 언젠가 끝난 일을 저는 계속 "미결"이라는 이름으로 이고 다녔던 겁니다. 이 글은 그 하나의 유령 항목을 지운 기록이자, 백로그가 왜 이런 부채를 조용히 쌓는지, 그리고 그걸 막는 규율이 얼마나 단순한지에 관한 이야기예요.

저는 사진 일을 20년 했고, 지금은 어쩌다 AI 에이전트 여러 대를 데리고 혼자 회사를 굴립니다. 설계하는 에이전트, 코딩하는 에이전트, 검증하는 에이전트가 나뉘어 있고, 저는 주로 보고를 받고 결정을 합니다. 그러다 보니 매일 아침 제 앞에 오는 건 "오늘의 할 일 목록"이에요. 어제 못 끝낸 것들이 위로 올라오고, 새로 생긴 것들이 아래에 붙죠.

그 목록 맨 위에, 몇 주 동안 같은 항목이 붙어 있었습니다. 편의상 "그 결제 기능, 아직 완전히 안 붙었음"이라고 해 둘게요. 매일 아침 저는 그걸 봤고, 매일 아침 "아 그거 아직이지" 하고 다음 날로 넘겼습니다. 넘기는 데 걸린 시간은 3초. 그게 몇 주였어요.

그러다 어느 날, 다른 일 때문에 그 근처 코드를 실제로 열어볼 일이 생겼습니다. 그리고 봤어요.

이미 다 되어 있었습니다.

기능은 완성돼 있었고, 심지어 라이브로 돌고 있었어요. 언제부턴가 끝나 있었던 겁니다. 그런데 제 할 일 목록에서는 그게 몇 주째 "아직 안 된 일"이었어요.

1. 유령은 조용합니다

처음엔 좀 허탈했어요. "몇 주 동안 대체 뭘 이고 다닌 거지?"

그런데 가만 보니, 이건 게으름의 문제가 아니었습니다. 구조의 문제였어요.

할 일 목록에 항목을 올리는 건 누구나 합니다. 새 일이 생기면 적죠. 그런데 항목을 내리는 건, 누군가 "이거 끝났어"라고 명시적으로 선언해야만 일어납니다. 그리고 그 선언은 자주 누락돼요. 특히 그 일이 다른 일을 하다가 곁다리로 끝났을 때 그래요. 나는 A를 하러 갔는데, 하다 보니 B도 자연스럽게 해결됐어요. A는 성취감 있게 목록에서 지웁니다. B는? B는 그날의 주인공이 아니었으니까, 아무도 그걸 지우겠다고 생각하지 않아요.

그렇게 B는 유령이 됩니다. 현실에서는 죽었는데, 장부에서는 살아 있는 항목.

유령의 무서운 점은 시끄럽지 않다는 거예요. 잘못된 코드는 에러를 뱉습니다. 죽은 서버는 알림을 보내죠. 그런데 "이미 끝났는데 미결로 남아 있는 항목"은 아무 소리도 안 냅니다. 그냥 매일 아침 목록에 얌전히 앉아서, 당신의 주의력을 3초씩, 그리고 더 중요하게는 우선순위 판단을 조용히 왜곡합니다.

2. 유령이 청구하는 진짜 비용

3초짜리 항목이 뭐 대단하냐 싶겠지만, 청구서는 다른 데서 날아옵니다.

첫째, 판단이 오염됩니다. 저는 매일 "오늘 뭐가 제일 급한가"를 그 목록을 보고 정했어요. 그런데 목록 맨 위에 (사실은 끝난) 그 항목이 "미결"이라는 얼굴을 하고 앉아 있으면, 제 우선순위 감각은 계속 거기에 끌려갑니다. "저것부터 챙겨야 하는데..." 실제로는 이미 된 일을 향해, 몇 주 동안 정신적 자원을 배정하고 있었던 거예요.

둘째, 신뢰가 새어 나갑니다. 이건 좀 아팠던 부분인데 — 저는 그 항목을 보고서에도 계속 "미결"로 적어 넘겼어요. 남한테 공유되는 문서에요. 즉 저는 몇 주 동안, 틀린 상태를 사실인 양 반복 보고하고 있었던 겁니다. 악의는 없었죠. 그냥 확인을 안 했을 뿐. 그런데 결과물로 보면, 저는 제 시스템의 상태를 잘못 알고 있었고, 잘못 알린 셈이에요. 혼자 하는 회사에서 이건 특히 위험합니다. 나를 교정해 줄 사람이 없으니까, 내 장부가 곧 현실이 돼 버려요.

셋째, 이건 절대 혼자 오지 않습니다. 유령 하나를 발견하고 나면 반드시 드는 생각이 있어요. "그럼... 다른 것들은?" 목록에 남아 있는 나머지 항목 중에, 저렇게 이미 죽었는데 살아 있는 척하는 게 또 없다는 보장이 어디 있죠? 유령 하나는 장부 전체에 대한 신뢰를 흔듭니다.

3. 왜 하필 지금 발견했을까

여기서 스스로에게 던진 질문이 하나 있어요. "왜 오늘 발견했지? 어제도, 지난주에도 목록에 있었는데."

답은 단순했습니다. 오늘 처음으로 그 항목을 '넘기지' 않고 '열어봤기' 때문이에요.

그동안 제가 그 항목에 한 행동은 "읽기"였어요. 텍스트를 눈으로 읽고, "아 그거"라고 인식하고, 다음으로 넘겼죠. 읽기는 그 항목이 처음 적혔을 때의 상태를 계속 재확인시켜 줄 뿐입니다. 항목의 텍스트는 "아직 안 됨"이라고 적혀 있고, 저는 그 텍스트를 읽었으니, 매일 "아직 안 됨"이라는 정보를 갱신 없이 재입력받은 거예요.

유령을 잡으려면 읽기로는 안 됩니다. 현물을 봐야 해요. 목록에 뭐라고 적혀 있느냐가 아니라, 실제 시스템이 지금 어떤 상태냐를 봐야 하죠. 그 둘 사이의 간격이 바로 유령이 사는 곳입니다.

이건 예전에 제가 지표를 두고 배운 것과 똑같은 교훈이더라고요. 그때는 "0이라고 보고되는 것과 진짜 0인 것은 다르다"였고, 이번엔 "미결이라고 적혀 있는 것과 진짜 미결인 것은 다르다"였어요. 결국 같은 병입니다. 장부와 현실을 헷갈리는 병. 자동화를 늘릴수록, 사람이 직접 현물을 만지는 횟수가 줄어들수록, 이 병은 더 잘 걸립니다.

4. 제가 세운 아주 단순한 규율

거창한 시스템을 만들진 않았어요. 혼자 하는 회사에 무거운 프로세스를 얹으면 그게 또 다른 유령이 되니까. 대신 습관 하나를 정했습니다.

"오래 이월된 항목은, 넘기기 전에 현물을 한 번 연다."

구체적으로는 이래요.

  • 할 일 목록에서 N번 이상 연속으로 이월된 항목에는 표식을 답니다. "이건 오래 묵었음."
  • 오래 묵은 항목은, 그날 처리하든 말든 일단 실제 상태를 한 번 확인합니다. 코드를 열든, 서비스를 직접 찔러보든, 관련 로그를 보든. 텍스트만 다시 읽고 넘기는 건 금지.
  • 확인 결과 이미 끝나 있으면 → 지웁니다. 그리고 "왜 끝난 걸 몰랐는지" 한 줄을 남깁니다. (대개 "다른 작업 하다가 곁다리로 해결됨, 종료 선언 누락"이더라고요.)
  • 아직이면 → 왜 몇 주째 안 됐는지를 봅니다. 진짜 어려워서인지, 아니면 사실 안 해도 되는 일이라 자꾸 밀리는 건지. 후자면 그것도 지울 후보예요.

핵심은 "오래됨"을 위험 신호로 취급하는 거예요. 보통 우리는 오래된 항목을 "언젠가 할 것" 정도로 방치합니다. 그런데 제 경험상, 몇 주를 버틴 항목은 둘 중 하나예요. 이미 끝났거나(유령), 안 해도 되는 거거나(가짜). 진짜로 중요하고 안 끝난 일은, 보통 며칠 안에 아파서 위로 튀어 오릅니다. 조용히 몇 주를 버티는 항목이 오히려 수상한 거죠.

5. 마무리 — 장부를 청소하는 것도 일입니다

한 가지 짚고 싶은 게 있어요. 유령을 지운 그날, 저는 새 기능을 만들지도, 버그를 고치지도 않았습니다. 그냥 할 일 목록에서 항목 하나를 잘못된 위치에서 올바른 위치로 옮겼을 뿐이에요. 코드는 한 줄도 안 바뀌었죠.

그런데 그게 그날 제가 한 일 중 꽤 값진 축에 들었다고 생각해요. 왜냐하면 그 뒤로 제 우선순위 판단이 실제 현실 위에서 돌기 시작했으니까. 잘못된 지도를 들고 아무리 빨리 걸어봐야, 엉뚱한 데 도착합니다. 지도를 현실에 맞추는 것도, 걷는 것만큼이나 일이에요.

특히 혼자, 그것도 자동화에 많이 기대서 굴리는 회사라면 더 그렇습니다. 나 대신 일해 주는 손이 많아질수록, 정작 나는 현물에서 멀어져요. 그 거리감 속에서 유령은 자랍니다. 그래서 가끔은 목록을 위에서 아래로 읽는 대신, 딱 한 항목이라도 골라서 실제로 열어보는 시간이 필요한 것 같아요.

여러분의 할 일 목록 맨 위에도, 혹시 몇 주째 같은 얼굴로 앉아 있는 항목이 있나요? 오늘은 그걸 넘기지 말고, 딱 한 번만 열어보시는 건 어떨까요. 어쩌면 그건 이미, 오래전에 끝나 있을지도 모릅니다.

이 글은 AI 에이전트들과 함께 1인 회사를 운영하며 남긴 기록의 일부입니다. 서비스가 궁금하시면 MONKOS에서 만나요.