스크립트와 수면 부족 습관으로 AI 직원을 우연히 만들다

주방 식탁은 아무도 공식적으로 그렇게 하도록 결정하지 않았음에도 불구하고 인프라가 되어 있었다.

두 대의 노트북이 열려 있었는데, 그중 한 대는 몇 달 전부터 조용히 발열 문제를 일으켰고 이제는 거의 혼자 두었을 때 더 잘 작동했다. 키캡 밑에는 먼지가 갇혀 있었고, 싸구려 마우스 주위에 복잡하게 감긴 USB 케이블들이 있었으며, 노트에는 프로젝트 계획이라기보다는 도시 지하의 유틸리티 라인을 지도처럼 그린 다이어그램들로 가득 차 있었다. 아파트는 기계들이 며칠 동안 작동한 것처럼 따뜻했다. 위험할 정도로 따뜻하지는 않았다. 단지 방으로 돌아올 때 느껴질 만큼만 했다.

선풍기 소리가 멈추지 않아서 잠에서 깼다.

그것은 이례적이었다.

잠자리에 들기 전에, 나는 몇 가지 리포지토리 체크를 예약하고 스크립트들을 실행해 두었다. 아침에 문서 업데이트가 기다리기를 바랐기 때문이다. 야심찬 것은 아니었다. 그저 집안 정리 정도였다. 하지만 하룻밤 사이에, 그 스크립트들은 다른 스크립트들을 작동시켰다. 로그는 요약본을 생성했다. 리포지토리 변경 사항은 검토 작업을 촉발했다. AI 모델은 실패 사례를 분류하고, 마크다운 파일을 업데이트했으며, 내가 존재조차 잊고 있던 문제들에 대한 이슈 노트를 생성했다.

이상했던 점은 그것이 작동했다는 사실 자체가 아니었다.

이상했던 점은 내가 참여하는 것을 멈춘 후에도 작업이 계속되고 있다는 것을 깨달았다는 것이다.

아무도 AI 직원을 만들 의도로 시작하지 않는다. 그 문구 자체만으로 잘못된 그림을 만든다. 사람들은 인공적인 동료가 인간을 대체하거나, 빛나는 대시보드나 화살표가 사방으로 뻗어 있는 비싼 오케스트레이션 다이어그램을 상상하게 한다. 실제로는 진정으로 유용해지는 시스템들은 보통 짜증에서 비롯된다.

무언가를 반복하는 것에 지칠 때가 있다.

그러면 그것을 자동화한다.

그러면 그 자동화가 또 다른 성가신 병목 현상을 만든다.

그러면 그것마저도 자동화한다.

결국 당신은 동료들보다 자신의 워크플로우를 더 잘 아는 스크립트들에 둘러싸여 잠에서 깨어나게 된다.

그 과정은 충분히 점진적이어서 나는 그 일이 일어나고 있다는 것을 거의 알아차리지 못했다.

알아차리기 어려운 방식으로 비용이 발생하는 반복 (Repetition)

이 모든 것을 구축하기 전, 나의 워크플로우 (Workflow)는 작은 재구성 작업들로 인해 비대해져 있었다.

저장소 (Repositories) 열기.

테스트 결과 확인하기.

로그 (Logs) 읽기.

정보를 노트에 복사하기.

LLM 열기.

컨텍스트 (Context) 붙여넣기.

컨텍스트 잊어버리기.

컨텍스트 재구성하기.

반복하기.

이 작업들 중 어느 것도 개별적으로는 비중 있게 느껴지지 않았다. 하지만 이들이 모여 오후 시간 전체를 잡아먹었다.

이것은 현대적인 기술 업무 (Technical work)의 불편한 점 중 하나이다. 진을 빼놓는 부분은 흔히 복잡성이 아니다. 바로 컨텍스트 스위칭 (Context switching)이다. 시스템 간의 모든 전환은 오버헤드 (Overhead)를 발생시킨다. 모든 대시보드, 알림, 브라우저 탭, 그리고 단절된 노트들은 주의력에 미세한 세금을 부과한다.

AI 도구들은 초기에는 오히려 이 단계를 악화시킬 수 있는데, 워크플로우 구조는 그대로 둔 채 출력량 (Output)만을 극적으로 증가시키기 때문이다. 당신은 그것들을 담아낼 시스템을 만들지 못한 채, 갑자기 더 많은 코드, 더 많은 문서, 더 많은 아이디어, 더 많은 요약, 그리고 더 많은 작업들을 생성하게 된다.

한동안 나는 정보를 대사 (Metabolize)할 수 있는 속도보다 더 빠르게 생산하고 있었다.

그것은 다른 질문을 던지게 만들었다.

"어떻게 하면 모델을 더 좋게 만들 수 있을까?"가 아니라,

"왜 나는 여전히 이 단계를 수동으로 처리하고 있는가?"였다.

그 질문은 위험한 것으로 드러났다. 거의 모든 반복되는 행동이 의심스러워 보이기 시작했기 때문이다.

첫 번째 유용한 자동화는 창피할 정도로 작았다

사람들은 흔히 여기서 정교한 에이전트 프레임워크 (Agent framework)가 등장하는 전환점 이야기를 기대한다.

그것은 쉘 스크립트 (Shell script)였다.

그 스크립트는 네 가지 일을 했다.

테스트 실행.

출력물 수집.

로그 저장.

요약 생성.

그것으로 충분했다.

스크립트 자체가 강력해서가 아니라, 이전에는 지속성 (Persistence)이 존재하지 않았던 곳에 지속성을 도입했기 때문이다.

곧 다른 스크립트가 프로젝트 전반의 의존성 (Dependencies)을 확인하기 시작했다. 또 다른 스크립트는 저장소 (Repositories)를 스캔하여 오래된 TODO 주석을 찾아냈다. 또 다른 스크립트는 디렉토리를 감시하고 출력물을 분류했다. 사용하지 않는 CPU 시간이 낭비처럼 느껴졌기에, 예약된 작업 (Scheduled tasks)들이 밤새 실행되기 시작했다. 나는 특이한 이벤트에 대해서만 알림을 추가했는데, 끊임없는 알림은 알림을 완전히 무시하도록 훈련시키기 때문이다.

결국 나는 개별 스크립트보다 스크립트들 사이의 관계가 더 중요하다는 것을 깨달았다.

자동화 시스템은 지능 (Intelligence)만으로는 좀처럼 유용해지지 않는다. 그것들은 연속성 (Continuity)을 통해 유용해진다.

스케줄러 (Schedulers)가 중요하다.

저장소 (Storage)가 중요하다.

로깅 (Logging)이 중요하다.

지루한 인프라스트럭처 (Infrastructure)는 사람들이 원하는 것보다 훨씬 더 중요하다.

크론 잡 (Cron jobs)은 화려하지 않다. 파일 시스템 와처 (Filesystem watchers)도 화려하지 않다. 추가 전용 로그 (Append only logs) 역시 화려하지 않다.

그럼에도 불구하고, 이러한 단순한 조각들이 중요한 무언가를 만들어낸다. 즉, 지속적인 주의를 요구하지 않고도 지속되는 작업이다.

AI 직원은 대부분 화려한 모자를 쓴 스케줄링에 불과하다

"AI 직원"이라는 문구가 살아남은 이유는 그것이 마케팅하기 좋기 때문이다.

현실은 훨씬 덜 영화적이다.

사람들이 실제로 필요로 하는 것은 대개 지속적인 노동이다.

유용한 자동화 시스템은 이벤트를 감지하고, 제한된 작업 (Constrained tasks)을 수행하며, 출력물을 저장하고, 예외 사항을 드러낸다. 그것이 저장소를 돌아다니며 독립적인 결정을 내리는 어떤 완전 자율적인 디지털 동료보다 대부분의 팀이 요구하는 것에 더 가깝다.

나의 설정은 결국 다음과 같은 형태로 안정화되었다:

저장소 활동이 와처 (Watchers)를 트리거한다. 와처가 스크립트를 트리거한다. 스크립트는 정보를 수집하고 제한된 작업을 모델 (Models)에 전달한다. 결과는 저장소 계층 (Storage layers)으로 들어가며, 나중에 다른 스크립트가 이를 분류하거나 요약할 수 있다. 알림은 임계값 (Thresholds)을 넘었을 때만 나타난다.

이 설명에서 프롬프팅 (Prompting)이 차지하는 비중이 얼마나 적은지 주목하라.

프롬프팅 문화는 때때로 언어 모델 (Language models)을 우주의 중심으로 취급한다.

인프라스트럭처는 그러한 출력물이 유용해질지, 아니면 다시는 열어보지 않을 폴더 속으로 사라져 버릴지를 조용히 결정한다.

시스템을 더 많이 구축할수록, 이 사실은 더욱 명확해졌다.

놀라울 정도로 자주, 메모리 (Memory)가 지능 (Intelligence)을 압도한다.

밤샘 시스템은 시간과의 관계를 변화시킨다

처음으로 진정으로 불안함을 느꼈던 순간은 밤샘 리포지토리 스윕 (Overnight repository sweeps)을 설정한 후에 찾아왔다.

나는 아마도 몇 개의 보고서 정도를 예상하며 잠에서 깨어났다.

하지만 대신 수십 개가 있었다.

문서 업데이트.

의존성 경고 (Dependency warnings).

제안된 리팩토링 (Refactors).

이슈 요약 (Issue summaries).

리스크 순위 (Risk rankings).

내가 존재조차 잊고 있었던 아키텍처적 약점들을 설명하는 생성된 노트들.

어떤 권장 사항들은 훌륭했다.

어떤 것들은 터무니없었다.

한 사례는 사용 패턴을 오해하여 인증 (Authentication)을 담당하는 코드를 삭제하라고 자신 있게 제안하기도 했다.

그 경험은 자율 시스템 (Autonomous systems)에 대해 생각하는 나의 방식을 영구적으로 바꾸어 놓았다.

사람들은 마치 실수가 예외적인 일인 것처럼 AI의 실수를 이야기한다.

실수는 운영 환경 (Operating environment) 그 자체다.

목표는 실패를 피하는 시스템을 만드는 것이 아니다.

목표는 실패가 계속 가시적으로 남아 있는 시스템을 구축하는 것이다.

그러기 위해서는 검토 계층 (Review layers), 저장된 출력물 (Stored outputs), 감사 추적 (Audit trails), 승인 체크포인트 (Approval checkpoints)가 필요하다.

자동화가 보이지 않게 되는 순간, 신뢰성 (Reliability)은 저하되기 시작한다.

기계는 인간보다 더 일관되게 오류를 반복한다.

그 일관성은 관찰할 수 있다면 유용하다.

관찰할 수 없다면 위험하다.

물리적 공간은 기술 시스템을 조용히 재형성한다

내가 예상하지 못했던 또 다른 변화가 있었다.

공간이 변했다.

지저분한 저장 방식이 자동화 실패를 야기했기 때문에 폴더들이 더 깔끔해졌다.

주변 시야에 끊임없이 들어오는 알림이 피로를 유발했기 때문에 책상 배치도 바뀌었다.

나는 모니터링 화면을 작업용 화면과 분리했다. 충동적인 작업 전환 (Task switching)에 저항을 만들기 위해 손으로 쓰는 체크포인트를 기록하기 시작했다. 비싼 노트는 빈 페이지를 이상할 정도로 아끼게 만들기 때문에, 일부러 저렴한 노트를 구매했다.

이러한 세부 사항들은 자동화된 시스템 안에서 충분히 오래 살아보기 전까지는 무관하게 들릴 것이다.

인터페이스는 행동을 훈련시킨다.

물리적 환경 또한 행동을 훈련시킨다.

프로젝트가 지속적으로 운영될 때, 조직화는 미적인 선호의 문제가 아니라 시스템 신뢰성 (system reliability)의 문제가 됩니다.

작은 환경적 선택들이 인프라 (infrastructure)가 됩니다.

성공보다 실수가 더 교육적이었다

하나의 자동화 루프 (automation loop)는 며칠 동안 오래된 가정을 사용하여 실수로 문서 업데이트를 생성했습니다.

또 다른 루프는 이슈 보고 (issue reports)를 너무 공격적으로 중복 생성하여, 나중에 저장소 (repositories)를 탐색하기 더 어렵게 만들었습니다.

한때 저는 가시성 (visibility)을 높이는 것이 유용할 것이라는 생각에 모든 것에 대해 업데이트를 보내는 알림 시스템을 구축한 적이 있습니다.

2주 후, 저는 알림을 완전히 무시하도록 스스로를 훈련시킨 상태가 되었습니다.

실패 패턴은 성공적인 실행이 가르쳐준 것보다 더 많은 것을 가르쳐주었습니다.

반복되는 실수 속에서 몇 가지 규칙이 살아남았습니다:

가공되지 않은 출력물 (raw outputs)을 승인된 출력물 (approved outputs)과 분리할 것.

모든 것에 타임스탬프 (timestamp)를 찍을 것.

킬 스위치 (kill switches)를 구축할 것.

추가 전용 로그 (append only logs)를 선호할 것.

범위 (scope)를 공격적으로 제한할 것.

이러한 원칙들은 지루하게 들리는데, 실제로 지루하기 때문입니다.

대부분의 신뢰성 관행은 지루합니다.

그것이 사람들이 이를 건너뛰는 이유 중 일부이기도 합니다.

나쁜 수면 습관이 해결책은 아니었지만, 문제를 드러냈다

저는 이 시스템이 절제된 최적화 (optimization)를 통해 탄생했다고 가장하고 싶습니다.

하지만 이 시스템은 대부분 누적된 짜증과 부족한 수면을 통해 나타났습니다.

피로는 마찰 (friction)에 대한 인내심을 변화시킵니다.

반복되는 행동은 더 빨리 견딜 수 없게 됩니다.

매일 아침 똑같은 대시보드 (dashboards)를 여는 것이 터무니없게 느껴지기 시작했습니다.

프로젝트 컨텍스트 (project context)를 반복해서 재구축하는 것이 터무니없게 느껴졌습니다.

실패를 몇 시간이나 지나서 발견하는 것이 터무니없게 느껴졌습니다.

탈진은 이전에는 동기 부여가 숨겨두었던 비효율성을 드러냈습니다.

그렇다고 해서 수면 부족이 유용하다는 뜻은 아닙니다.

그것은 마찰을 더 쉽게 알아차리게 만들 뿐입니다.

실제 해결책은 지속적으로 가용할 수 있는 주의력에 대한 의존도를 줄이는 시스템을 구축하는 것이었습니다.

인간의 집중력은 변동합니다.

집중력이 사라진다고 해서 프로젝트가 존재하기를 멈추지는 않습니다.

지속적인 시스템은 그 간극을 메우는 데 도움을 줍니다.

생각보다 더 작게 시작하라

사람들은 지속적으로 잘못된 규모로 자동화 프로젝트를 시작합니다.

멀티 에이전트 (Multi agent) 연구 스웜 (swarms).

자율적인 스타트업 운영자 (Autonomous startup operators).

복잡한 오케스트레이션 그래프 (Complex orchestration graphs).

그동안 문서화는 구식이 된 채로 남아 있고, 의존성 업데이트 (dependency updates)는 확인되지 않은 채 방치됩니다.

한 가지 작업부터 시작하세요.

반복되는 짜증 나는 일 하나.

책임 하나.

매일 밤 풀 리퀘스트 (pull requests)를 검토하는 무언가를 만드세요. 로그를 요약하고, 연구 노트를 분류하며, 문서 스냅샷 (documentation snapshots)을 생성하는 도구 말입니다.

그런 다음 그것이 계속 실행되도록 두세요.

실패 패턴을 관찰하세요.

천천히 확장하세요.

유용한 시스템은 거의 완성된 형태로 나타나지 않습니다.

그것들은 축적됩니다.

지금 이 글을 쓰는 동안에도 여러 스크립트가 백그라운드에서 실행되고 있습니다. 제가 특별히 자동화 연극 (automation theater)을 즐기기 때문이 아닙니다. 주로 저장소 감시자 (repository watchers), 예약된 작업 (scheduled jobs), 그리고 쌓여가는 생성된 보고서들 사이 어딘가에서, 아침에 기다리고 있는 완료된 작업이 프로젝트를 느끼는 방식을 바꾼다는 것을 깨달았기 때문입니다.

프로젝트가 전적으로 당신의 현재 에너지 수준에 의존하는 일이 멈춥니다.

그 변화는 처음에는 미묘합니다.

그러다 어느 날 아침 잠에서 깨어났을 때 노트북 팬이 여전히 돌아가고 있고, 기계가 당신이 존재조차 잊고 있었던 문제들을 밤새 정리해 놓은 것을 발견하게 됩니다. 그러면 도구와 동료 사이의 경계가 예상보다 조금 더 찾기 어려워집니다.