동시성 (Concurrency)
한 프로젝트에 매달리는 대신 여러 프로젝트를 닫히는 단위로 쪼개어, AI 작업이 도는 동안 사람의 판단을 다른 프로젝트로 옮겨 가며 동시에 진행하는 일하는 방식입니다.
동시성은 한 번에 한 프로젝트에 매달리는 대신, 여러 프로젝트를 각자 닫히는 작업 단위로 쪼개어 AI 작업이 도는 동안 사람의 판단을 다른 프로젝트로 옮겨 가며 동시에 진행하는 일하는 방식입니다.
출발점은 단순한 관찰이었습니다. AI에게 작업을 시키면 그 작업이 도는 동안 사람의 손이 비고, 하루는 여전히 24시간이라 시간은 늘지 않습니다. 더 많은 일을 하려면 일을 순서대로 쌓는 대신 겹쳐서 돌려야 했습니다. 동시성은 AI 작업이 도는 그 빈 시간에 다른 프로젝트의 판단을 끼워 넣는 것입니다. 예전에는 그 빈 시간을 기다림으로 썼습니다.
진짜 병목은 AI의 처리 속도가 아니었습니다. AI는 충분히 빨랐고, 진짜 비용은 프로젝트를 오갈 때 맥락을 다시 잡는 시간이었습니다. 흐름과 흐름 사이를 건너가는 비용이 컸습니다.
병목은 AI의 속도가 아니라, 사람이 한 흐름에서 다른 흐름으로 건너가는 비용이었습니다.
이 비용을 줄이려면 모든 프로젝트가 같은 모양의 '닫히는 단위'로 쪼개져 있어야 했습니다. 같은 모양이어야 어느 프로젝트로 건너가도 다음에 내려야 할 판단을 빠르게 잡을 수 있기 때문입니다. 골격은 세 단계였습니다.
이 한 줄의 맥락 메모가 맥락 전환 비용을 가장 크게 줄였습니다. 닫히는 단위라는 토대는 너디의 마침표 사고와 직결됩니다. 일을 '기능'이 아니라 '끝나는 단위'로 나누어 끝나는 지점을 먼저 정의하는 사고법이, 동시성이 프로젝트를 쪼개는 단위가 됩니다.
4월에 처음 만든 방식은 거칠었습니다. 맥락 메모를 손으로 남기는 게 번거로웠고, 여러 프로젝트의 상태를 한눈에 보는 도구가 없어 머릿속으로 저글링했으며, 어떤 날은 두 프로젝트의 맥락이 섞여 한쪽 판단을 다른 쪽에 잘못 적용하기도 했습니다. 너무 적게 벌리면 빈 시간이 오히려 낭비됐고, 그때는 서너 개가 한계였습니다. 자세한 과정은 빌드로그에 남겨 두었습니다.
머릿속 저글링의 한계는 6개였습니다. 5월 초 프로젝트가 6개를 넘어가자 한 프로젝트의 맥락이 다른 프로젝트로 새고, '이 판단을 어느 프로젝트에서 하다 말았더라'가 잦아졌습니다. 동시성의 한계는 AI가 아니라 사람 머릿속의 작업 기억이었습니다.
6개의 벽을 깨기 위해, 모든 프로젝트의 상태를 한곳에 모으는 작은 시스템을 직접 만들었습니다. 프로젝트마다 '지금 어느 단계인지', '내가 다음에 내려야 할 판단이 무엇인지', '무엇을 기다리는 중인지'를 한 화면에 모은 것입니다. 머리로 저글링하던 것을 화면이 대신 들어 주자, 들어온 판단 하나만 보고 처리하면 됐습니다. 맥락은 시스템이 쥐고, 판단은 사람이 쥐었습니다. 너디가 제품에서 늘 말해 온 '반복은 시스템이 닫고 판단은 사람이 쥔다'는 원칙을, 일하는 방식 자체에 적용한 것입니다. 이 상태 추적 방식은 증거 기반 운영과 같은 계열이고, 단위 사이의 연결을 잇는 자리는 워크플로 자동화와 맞닿습니다.
그 결과 5월 한 달 동안 솔로로 동시에 굴린 프로젝트가 10개를 넘었습니다. 다만 한 사람이 10개를 풀가동했다는 뜻은 아닙니다. 10개가 각자 닫히는 단위로 쪼개진 채 판단 지점들을 거치며 동시에 전진했고, 실행의 대부분은 AI와 시스템이 맡았습니다. 종류는 제품 작업, 사내 도구, 콘텐츠, 고객 대응이었습니다. 결이 다른 프로젝트를 섞을수록 머리가 덜 섞여 동시성이 더 잘 작동했습니다. 같은 종류만 굴리면 오히려 맥락이 헷갈렸습니다. 이 한 달의 기록은 10개 프로젝트 후속편에 있습니다.
마지막으로 한 가지가 동시성에 맞지 않았습니다. 깊은 사고가 필요한 일입니다. 한 가지를 오래 붙들고 깊이 들어가야 하는 일을 판단 지점만 끊어 처리하니 얕아졌습니다. 그래서 5월 후반에는 규칙을 하나 더 두었습니다. 깊은 사고가 필요한 한 개는 동시성 밖에 따로 두고, 나머지를 동시에 굴리는 것입니다.