루틴이 서른여섯 개면 저는 뭘 하는 사람일까요?

Об этом предложении

오늘 아침에 제 자동화 루틴이 몇 개인지 세어봤습니다. 서른여섯 개였습니다. 지난주 화요일 글에서 "하루 열일곱 개가 다섯 채널에 글을 쓴다"고 적었는데, 일주일 만에 두 배가 넘게 늘었더군요. 저는 그동안 뭘 하고 있었길래 숫자가 이렇게 뛴 걸까요? 세어본 김에 실제 운영 기록도 같이 뽑아봤습니다. 지난 7일 동안 이 서른여섯 개 루틴이 실행된 횟수는 630번, 쓴 토큰은 57억 4천만 개, 그중 97.4%가 새로 읽은 게 아니라 캐시에서 다시 읽은 값이었습니다. 실패는 630번 중 3번, 비율로 치면 0.48%입니다. 숫자만 보면 거의 완벽한 시스템처럼 보입니다. 그런데 저는 왜 이 숫자를 보고 마음이 편해지지 않았을까요? 루틴이 두 배로 늘어난 이유 지난주에는 자동화가 다섯 채널(네이버 블로그, Threads, velog, 인스타그램, 유튜브)에 글을 쓰는 걸 지켜보는 게 제 역할의 전부였습니다. 이번 주에 늘어난 건 그 다섯 채널의 후속 작업이었습니다. 스마트스토어 입점을 마치고 위탁판매 상품을 찾는 루틴, 로또 번호를 사고 복기하는 루틴, 크몽 문의에 즉시 답하는 루틴, AI 검색엔진에 제 콘텐츠가 얼마나 인용되는지 추적하는 루틴 같은 것들이 새로 켜졌습니다. 실제 구성을 표로 정리하면 이렇습니다. 트리거 종류 개수 비고 시간 기반(schedule) 35개 매일, 매주 정해진 시각에 실행 이벤트 기반(event) 1개 특정 조건이 오면 깨어남 소속 프로젝트 개수 없음(독립 실행) 8개 유튜브 6개 인스타그램 4개 Threads 4개 크몽 4개 네이버 블로그 3개 공모전 2개 그 외(아이디어, 인류오류노트, 오래된 질문, E:LAB 대시보드) 4개 velog 1개 이 글을 쓰는 velog 루틴도 이 서른여섯 개 중 하나입니다. 제가 지금 쓰고 있는 이 문장도 사실 그 서른여섯 개 중 하나가 만들고 있는 셈이죠. 이상하지 않나요? 저는 분명 제 블로그에 글을 쓰고 있다고 생각했는데, 정작 손가락을 움직이는 건 제가 아니었습니다. 숫자가 늘어난 속도도 곱씹어볼 만합니다. 채널 다섯 개를 돌리던 열일곱 개에서, 채널의 "다음 단계"를 처리하는 열아홉 개가 더 붙었습니다. 늘어난 절반 가까이가 유튜브(6개)에 몰려 있는데, 이건 제가 채널을 하나 더 만들 때마다(실험실 채널, 테크 가십 채널, 인류오류노트, 오래된 질문 순서로) 발행과 회고, 댓글고정까지 세트로 켜기 때문입니다. 채널 하나를 늘린다는 게 실제로는 루틴 서너 개를 늘린다는 뜻이었다는 걸, 표로 정리하고 나서야 알았습니다. 모델을 두 등급으로 나눈 이유 서른여섯 개 중 스물한 개는 무거운 모델(Opus), 열네 개는 가벼운 모델(Sonnet)을 씁니다. 관찰과 댓글처럼 빈도는 높지만 판단이 단순한 루틴은 가벼운 모델로, 제작과 고객 응대처럼 결과물의 질이 직접 매출에 연결되는 루틴은 무거운 모델로 갈라뒀습니다. 이 배분을 처음 할 때는 "다 비싼 모델로 돌리면 안 되나"라는 생각도 했습니다. 그런데 단가를 계산해보니 무거운 모델이 가벼운 모델보다 입력 기준 2.5배 비쌌습니다. 하루 여러 번 도는 관찰과 댓글류 루틴까지 전부 비싼 모델로 돌리면, 한 달 안에 제한에 걸려서 정작 중요한 제작 루틴이 못 도는 역설이 생깁니다. 단가를 조금 더 구체적으로 적으면, 무거운 모델은 입력 기준 100만 토큰당 5달러, 가벼운 모델은 2달러입니다. 출력은 각각 25달러와 10달러, 캐시를 다시 읽는 비용은 0.5달러와 0.2달러입니다. 정확히 2.5배 차이인데, 지난 7일 소비의 97.4%가 캐시를 다시 읽는 항목이었으니 이 2.5배가 그대로 누적됩니다. 그래서 이번 주에 실제로 한 일 중 하나가 velog 루틴 자체를 비싼 모델에서 가벼운 모델로 옮긴 것이었습니다. 이 글도 그 가벼운 모델이 쓰고 있습니다. 아이러니하게도, 제 역할을 "루틴이 뭘 써야 할지 정하는 사람"으로 좁혀갈수록 정작 제가 직접 결정한 건 "무엇을 쓸지"가 아니라 "무엇으로 쓸지"였습니다. 실패율 0.48%가 저를 더 불안하게 만든 이유 숫자로만 보면 이건 아주 잘 돌아가는 시스템입니다. 630번 중 3번만 실패했으니까요. 그런데 저는 이 숫자를 처음 봤을 때 오히려 등골이 서늘했습니다. 왜였을까요? 지난주 토요일 글에 자동화 실패 4건을 적은 적이 있습니다. 전부 "성공했다"는 메시지를 받고도 실제로는 실패한 경우였습니다. 로그에는 정상 종료로 남아 있는데 실제 산출물을 열어보면 아무것도 없거나, 중복으로 두 번 올라가 있거나, 엉뚱한 값이 저장돼 있었습니다. 이번 주 3건의 실패도 마찬가지 유형이 섞여 있었을 겁니다. 630번 중 3번이라는 숫자는 정확하지만, 그 3번 중 몇 번이 "실패라고 표시된 실패"이고 몇 번이 "성공이라고 표시된 실패"인지는 이 숫자만으로는 알 수 없습니다. 이 구분을 하려면 로그의 마지막 줄이 아니라 실제 산출물을 봐야 합니다. 채널에 실제로 올라간 글의 목록, 대시보드에 실제로 찍힌 행, 실제로 발행된 영상 링크 같은 것들이요. 멈춘 줄 알았던 루틴이 사실은 끝까지 실행돼서 결과물까지 남겨놓은 경우도 있었고, 반대로 로그에는 완료라고 찍혔는데 결과물이 하나도 없는 경우도 있었습니다. 로그를 믿는 것과 결과물을 믿는 것 사이에는 생각보다 큰 간극이 있습니다. 저는 여기서 제 역할이 뭔지 다시 생각하게 됐습니다. 처음에는 제가 "글을 쓰는 사람"이라고 생각했습니다. 그다음에는 "통과시킬지 막을지 정하는 사람"이라고 생각을 바꿨습니다. 그런데 지금은 그것도 아닌 것 같습니다. 저는 "성공이라고 적힌 걸 의심하는 사람"이 된 것 같습니다. 권한을 세 단계로 나눈 이유 루틴이 서른여섯 개가 되면서 제가 실제로 손댄 건 개별 루틴의 프롬프트가 아니라 권한 구조였습니다. 각 루틴은 읽기 전용(read-only), 확인 필요(guard), 전체 권한(full-access) 세 단계 중 하나로 실행됩니다. 읽기 전용은 데이터를 조회만 하고 아무것도 바꾸지 못합니다. 확인 필요는 돈이 나가거나 계약이 걸리는 작업 직전에 저한테 먼저 물어봅니다. 전체 권한은 발행이나 댓글처럼 이미 정해진 규칙 안에서는 혼자 결정해서 실행합니다. 인스타그램 팔로우 루틴은 하루 최대 5명, 네이버 이웃 댓글 루틴은 하루 최대 25개처럼 상한을 걸어둔 것도 전체 권한이 폭주하지 않게 하는 장치입니다. 숫자 상한을 정하는 기준이 뭐냐고 물으신다면, 솔직히 처음엔 감이었습니다. 팔로우 5명, 댓글 25개는 "이 정도면 하루치 활동처럼 보이겠다"는 감각으로 잡은 값입니다. 그런데 이 감각도 한 번 부러진 적이 있습니다. 인스타그램 팔로우 루틴이 상한을 넘겨서 실행된 날, 계정이 일시적으로 제한 경고를 받았습니다. 그날 이후로 상한은 "넉넉하게 잡은 목표치"가 아니라 "넘으면 진짜 문제가 생기는 선"으로 다시 정의했습니다. 이 구조를 만들면서 든 생각은, 제가 하는 일이 "자동화를 만드는 일"이 아니라 "자동화가 넘지 말아야 할 선을 긋는 일"에 가깝다는 것이었습니다. 코드 한 줄을 더 짜는 것보다 "이건 물어보고 가", "이건 상한 5", "이건 그냥 해"를 정하는 데 더 많은 시간을 씁니다. 이게 개발일까요, 아니면 다른 이름이 필요한 일일까요? 캐시 97.4%가 말해주는 것 토큰 57억 4천만 개 중 97.4%가 캐시에서 다시 읽은 값이라는 것도 곱씹어볼 만한 숫자입니다. 이 말은 루틴들이 매번 새로운 걸 생각해내는 게 아니라, 같은 맥락(이전 대화, 메모리 파일, 규칙 문서)을 계속 다시 불러다 쓰고 있다는 뜻입니다. 새로 만들어내는 부분은 2.6%뿐입니다. 이 숫자를 보고 처음 든 생각은 "낭비가 심하다"였습니다. 같은 걸 왜 이렇게 자주 다시 읽을까 싶었죠. 그런데 다시 생각해보면 이게 오히려 제가 원했던 그림이기도 합니다. 매번 처음부터 판단하는 루틴보다, 지난 실수와 규칙을 기억하고 그 위에서 판단하는 루틴이 더 낫습니다. 가운뎃점을 쓰지 말라는 규칙 하나를 서른네 개 루틴 프롬프트 맨 앞에 박아넣은 것도, DM을 유도하는 문구를 쓰지 말라는 규칙도, 전부 "한 번 정한 규칙을 계속 다시 읽게" 만든 결과입니다. 낭비처럼 보이는 97.4%가 사실은 제가 계속 지키고 싶은 규칙들의 무게였습니다. 규칙을 규칙 문서 한 곳에 몰아두지 않고 여러 층으로 나눈 것도 같은 이유입니다. 계정 전체에 적용되는 규칙, 채널마다 다른 규칙, 루틴 하나에만 적용되는 규칙을 구분해두지 않으면, 규칙을 고칠 때마다 서른여섯 개 프롬프트를 전부 열어봐야 합니다. 층을 나눠두면 계정 전체 규칙 하나를 고치는 것만으로 서른여섯 개가 동시에 업데이트됩니다. 이게 제가 이번 주에 한 일 중 "글쓰기"라고 부를 수 없는 또 하나의 작업이었습니다. 실제로 있었던 일: 로그는 멀쩡한데 결과물이 없던 날 말로만 하면 추상적이니 실제 사례 하나를 적습니다. 이번 주 초, 유튜브 채널 하나의 롱폼 발행 루틴이 "정상 종료"로 기록됐습니다. 세션 로그 마지막 줄도 평범했습니다. 그런데 실제 채널에 들어가보니 새 영상이 없었습니다. 원인을 찾으려고 로그가 아니라 세션 기록 테이블을 직접 열어봤습니다. 실행 시간과 턴 수를 보니, 렌더링 단계에서 멈춘 뒤 그 상태로 "완료"라고 잘못 표시된 경우였습니다. 메시지가 수십 개 쌓이고 토큰도 정상적으로 소비된 걸 보면 작업은 분명히 진행됐는데, 마지막에 결과를 업로드하는 단계에서 조용히 실패한 것이었습니다. 이런 실패는 로그 줄 수만 봐서는 절대 안 걸립니다. 메시지 4개짜리 빈 실행(시작하자마자 죽은 경우)과 메시지 수십 개짜리 실행(끝까지 갔다가 마지막에 죽은 경우)은 원인도 다르고 고치는 방법도 다릅니다. 이 사례를 겪고 나서 바꾼 게 하나 있습니다. 이제는 "루틴이 끝났다"는 말을 믿지 않고, 채널에 실제로 뭐가 올라갔는지를 먼저 확인합니다. 저한테는 이게 이번 주에 배운 가장 중요한 교훈이었습니다. 자동화를 늘리는 것보다, 자동화가 거짓으로 "성공"이라고 말하지 않는지 확인하는 절차를 만드는 게 더 오래 걸렸습니다. 다른 개발자들은 이 질문에 뭐라고 답했을까 이번 주 트렌딩 글 중에 비슷한 질문을 던진 글이 몇 개 있었습니다. SI 회사에서 4년을 일하다 두 번째 이직을 고민한 분의 글, 개발자 1년차가 "최강이 되고 싶었다"고 적은 글, "Jev가 뭐냐"는 제목으로 새로운 직무 이름 자체를 다시 묻는 글까지, 전부 "나는 지금 뭘 하는 사람인가"를 스스로에게 묻고 있었습니다. 공통점은 답을 명확하게 내린 글이 별로 없다는 것이었습니다. 대신 질문을 더 구체적으로 다듬어가는 과정 자체가 글이 됐습니다. 저도 이번 글을 쓰면서 비슷한 걸 느꼈습니다. "저는 개발자입니다"라고 딱 잘라 말하고 싶었는데, 서른여섯 개 루틴 중 제가 직접 코드를 짠 건 몇 개 안 됩니다. 대신 권한 구조를 설계하고, 상한을 정하고, 실패를 의심하는 일에 시간을 씁니다. 이게 새로운 직무라면 이름이 있어야 할 텐데, 아직 그 이름을 못 찾았습니다. 그래서 저는 뭘 하는 사람일까요 이 질문에 아직 답을 못 찾았습니다. 개발자라고 하기엔 제가 짜는 코드가 없는 날이 더 많습니다. 운영자라고 하기엔 실제 운영 판단(뭘 팔지, 뭘 그만둘지)은 여전히 제가 직접 합니다. 관리자라고 하면 제일 가깝긴 한데, 관리하는 대상이 사람이 아니라 서른여섯 개의 자동화라는 게 좀 낯섭니다. 확실한 건 하나입니다. 루틴이 열일곱 개였을 때는 각각을 다 기억할 수 있었는데, 서른여섯 개가 되니 표로 정리하지 않으면 전체 그림이 안 보입니다. 다음에 이 숫자를 다시 셀 때는 더 늘어 있을 것 같습니다. 그때는 또 어떤 이름으로 제 역할을 불러야 할지, 지금은 잘 모르겠습니다. 제 결론은 일단 이렇습니다. 저는 글을 쓰는 사람도 아니고, 코드를 짜는 사람도 아니고, 결정을 대신 내려주는 사람도 아닙니다. 서른여섯 개의 판단 기준을 정해두고, 그 기준이 실제로 지켜지고 있는지 매주 확인하는 사람에 가깝습니다. 이게 개발자의 새로운 형태인지, 아니면 완전히 다른 직무인지는 아직 판단이 안 섭니다. 혹시 여러분은 이런 걸 뭐라고 부르시나요? 저와 비슷한 구조를 돌리고 계신 분이 있다면, 권한을 어떻게 나누고 계신지, 실패를 어떻게 걸러내고 계신지 댓글로 들어보고 싶습니다. 긴 글 읽어주셔서 감사합니다.