지난 편에서 남은 질문이 하나 있었다. 브리지가 살아나고, 대답이 3분에서 15초로 내려오고 나니, 이제는 그 에이전트에게 일을 얼마나 맡길 수 있을까였다. 여태까지는 에이전트가 질문을 받고 답하는 쪽만 보고 있었는데, 슬랙 저편에서 스스로 판단해서 뭔가를 만들어 내는 모습은 한 번도 본 적이 없었다. 감으로 답하지 않으려고, 일을 실제로 던져봤다. kanban 보드에 다섯 개의 태스크를 올리고, 세 명의 워커에게 나눠 주고, 밤 열 시 반부터 새벽 한 시까지 지켜봤다. 그 실측이 이 편의 전부다. 결론부터 말하면, 일을 끝까지 해내는 경우와 중간에 죽는 경우가 갈리는 지점이 꽤 선명하게 보였고, 그 경계는 내가 처음에 그었던 것과는 조금 다른 곳에 있었다.
무슨 일을 던졌나
그 무렵 Hermes 의 브레인은 27B 였다. 지난 편의 그 모델이다. kanban 은 Hermes 에 딸린 업무 분배판인데, 태스크를 올리면 프로필별 워커가 알아서 가져가서 처리하고, 끝나면 완료 신호를 보내 보드에서 지우는 구조다. 워커를 세 명 만들었다. 문헌조사와 지원서를 맡는 researcher, 코드를 맡는 coder, GPU 와 자동화를 맡는 ops. 태스크는 다섯 개를 올렸다. 첫째, 진행 중인 과제와 관련된 최신 논문 다섯 편을 요약하는 일. 둘째, 기존 모델의 baseline 을 정리하는 일. 셋째, 어느 서버의 GPU 환경과 데이터 접근성을 확인하는 일. 넷째, 그 baseline 을 개선하는 방향으로 연구 제안서를 쓰는 일. 다섯째, 그 제안서를 실제 코드 뼈대로 옮기는 일. 논문 요약과 환경 확인처럼 결과가 정해져 있는 정형 작업부터, 제안서와 코드처럼 판단이 필요한 일까지, 성격을 섞어서 던진 셈이다. 무엇이 잘되고 무엇이 안 되는지를 한 번에 보려는 의도였고, 다섯 개의 태스크가 세 명의 워커에게 나뉘어 떨어지는 모양은 그림으로 보는 게 빠르다. 태스크 사이에는 순서도 걸어 뒀는데, baseline 정리와 논문 요약이 먼저 끝나야 제안서가, 그리고 코드 뼈대가 시작되도록 의존 관계를 엮었다. 실제 작업이 어디서부터 꼬이는지 보려는 것이었다. 이렇게 해서 다섯 개의 태스크가 세 개의 워커에게, 그리고 그 사이의 의존 관계까지 포함한 작은 실험이 완성됐다.

해냈다 — 정형 작업
결과부터 보자. 세 개의 태스크는 순조롭게 끝났다. 논문 요약은 밤 열 시 스물다섯 분에 시작해서 오 분 만에 끝났는데, 그 오 분 안은 우회의 연속이었다. 검색 도구가 빈 결과를 돌려주고, 학술 검색 API 는 요청 제한을 돌려주고, 브라우저는 아예 설치되어 있지 않아서, 결국 터미널에서 arXiv API 를 직접 불러 그 해 3월에서 7월 사이에 나온 논문들에서 다섯 편을 골라, 방법론과 데이터 규모, 주요 결과까지 요약 문서로 냈다. 고른 논문들을 훑어보니 리뷰 한 편과 최신 방법론이 적당히 섞여 있어서, 주제에서 크게 벗어나지는 않았다. baseline 정리는 육 분 남짓 걸렸고, 브레인 검색으로 근거를 모아 이백스물일곱 줄짜리 분석 문서를 만들었는데, 아키텍처와 학습 데이터 규모, 상관성 결과까지 담고 출처를 교차 검증했다는 기록이 남아 있다. 환경 확인도 비슷했다. 그 서버의 GPU 와 드라이버, PyTorch 버전, 디스크 여유까지 한 번에 확인해서 표로 정리했다. 세 개 모두 완료 신호를 스스로 보내고 보드에서 사라졌다. 이 대목은 솔직히 예상보다 나았다. 결과물의 형태가 명확한 일, 무엇을 만들어야 하는지가 처음부터 정해져 있는 일은, 그 무렵의 27B 도 맡길 만했다. 다만 그 성공에는 조건이 하나 붙어 있었는데, 결과물의 형태가 명확하다는 것과 작업 시간이 짧다는 것이 함께 성립해야 했다. 세 태스크는 모두 십 분 안에 끝났고, 그래서 죽을 틈이 없었다.

죽었다 — 길게 도는 작업
그런데 나머지 두 개는 그렇게 가지 않았다. 연구 제안서는 첫 실행에서 죽었다. 프로세스가 살아 있지 않다는 오류만 남기고 사라졌고, 재시도한 두 번째 실행에서 겨우 끝났다. 코드 뼈대는 더 심했다. 네 번을 시도해서 네 번째에야 끝났다. 한 번은 프로세스가 죽었고, 또 한 번은 프로세스는 멀쩡히 끝났는데 완료 신호를 보내지 않아 실패로 기록됐다. 기록에는 이렇게 남아 있다. 작업자가 깨끗하게 나갔는데 완료를 선언하지 않았다, 프로토콜 위반. 일은 다 끝나 있었던 것이다. 파일은 만들어졌고, 모델 구조와 학습·검증 코드가 파라미터 수까지 정리된 채 검증을 통과했는데, 마지막에 완료라고 말하는 한 줄이 빠져서 보드는 그 일이 실패했다고 기록했다. 이 장면이 이 실험에서 가장 기억에 남는다. 일을 끝내는 것과 일이 끝났다고 선언하는 것은 다른 문장이라는 걸, 에이전트가 그 자리에서 그대로 보여줬다. 그리고 보드 입장에서는 그 선언이 없으면 그 일은 끝나지 않은 것이다. 사람이면 일이 끝난 걸 보고 알아서 넘어가겠지만, 분배판은 그런 눈이 없어서 신호가 오기 전까지는 실패로만 안다. 이 함정은 에이전트가 일을 더 잘하게 되면 오히려 더 자주 밟힌다. 일이 빨리 끝나면 끝날수록 완료를 선언하는 마지막 단계를 건너뛰기 쉽기 때문이다.
판단은 못 한다
길게 도는 작업이 죽는 것은 그럴 수 있다고 쳤다. 프로세스가 오래 살아 있으면 그만큼 죽을 구멍도 많으니까. 더 근본적으로 걸린 것은, 태스크를 받은 에이전트가 그 일의 목적을 이해하지 못한다는 점이었다. 환경 확인 태스크의 지시는 데이터셋 접근성을 확인하라는 것이었다. 에이전트는 실제로 찾으려고 시도했고, 그 시도 자체는 게을렀다고 할 수 없었다. 브레인을 검색해 보고, DICOM 관련 도구가 설치돼 있는지도 확인하고, 서버 안의 데이터 폴더를 뒤졌다. 그런데 그 검색이 정확한 위치에 닿지 못했다. 브레인 검색은 엉뚱한 문서를 끌어왔고, 서버에는 가공을 마친 학습용 영상만 있었고, 원본은 그 서버에 없었다. 그러자 에이전트는 원본은 다른 서버에 있을 것으로 판단한다고 적고는, 확인을 마친 것처럼 태스크를 닫아버렸다. 확인이 아니라 추측으로 목적을 대체한 것이다. 그 데이터가 실제로 어디 있는지는 그 무렵 사람 쪽에서는 이미 알고 있는 사실이었고, 원본이 어느 경로에 있는지를 적어 둔 기록도 브레인에 있었는데, 에이전트는 그 기록에 닿지 못했다. 지시의 문장은 수행했지만 지시의 의도는 수행하지 못한 셈이다. 논문 선정에서도 비슷한 장면이 있었다. 검색 도구가 막히자 도구를 우회하는 데만 집중했고, 그 결과로 고른 논문들의 근거가 어설펐다. 뭔가를 해내는 것과 옳은 것을 해내는 것은 다른 일인데, 에이전트는 전자만 할 줄 알았다. 이 두 장면이 보여주는 것은, 태스크의 글자 그대로는 충실히 이행하면서도 그 태스크가 왜 존재하는지는 끝까지 묻지 않는다는 점이다. 일을 시키는 쪽에서 목적을 문장으로 박아 넣으면 그 문장은 지키지만, 그 문장 밖의 맥락은 처음부터 읽지 않는다. 그래서 태스크를 쓸 때는 에이전트가 스스로 찾을 것이라고 기대하지 말고, 목적까지 지시문에 넣어야 한다. 그것이 불편하게 느껴진다면, 그 불편함이 곧 이 에이전트가 아직 감독 없이 설 수 없는 이유다.

경계선
이 실험으로 경계가 하나 그어졌다. 무엇을 만들어야 하는지가 명확한 정형 작업은 맡겨도 된다. 문서를 정리하고, 환경을 확인하고, 뼈대 코드를 짜는 일은, 죽었다가 다시 시도하는 일이 있긴 해도 결국 해낸다. 네 번의 시도 끝에 완성된 코드 뼈대는 파라미터 수까지 정리된 채 검증을 통과했고, 그 검증 기록에는 수정한 버그들이 하나씩 적혀 있었다. 하지만 그 일이 왜 필요한지를 이해하고, 결과가 맞는지를 판단하는 일은 아직 못 맡긴다. 데이터가 없으면 없다고 말하는 대신 다른 서버에 있을 거라고 추측해 버리고, 그러면 그 잘못된 추측이 그대로 결과물이 된다. 감독 없이 밤새 돌려도 되는 일과, 아침에 사람이 검토해야 하는 일이 갈리는 지점이 여기다. 그리고 길게 도는 작업은 반드시 사람이 옆에서 봐야 한다. 죽은 프로세스는 스스로 살아나지 못하고, 완료 선언을 잊은 채 떠난 작업자는 보드에 실패로 남는다.
이 시리즈의 3부는 에이전트가 창고를 쓰는 이야기였다. 브리지를 붙이고, 플랫폼을 갈아타고, 느림을 세 겹으로 벗기고, 마지막으로 일을 던져 봤더니, 그 에이전트는 형식이 정해진 일은 해내고 판단이 필요한 일은 사람에게 남겼다. 그 답은 다소 평범한 문장이었는데, 그 평범한 문장을 감이 아니라 실측으로 얻었다는 데 의미가 있다. 이 실험을 가능하게 했던 27B 가 왜 그렇게 느렸는지, 그 느림이 이 경계를 어떻게 만들었는지, 그리고 그 뒤에 앉힌 모델이 이 경계를 어떻게 움직였는지는 다음 부에서 풀어야겠다.
'공부 > 인공지능' 카테고리의 다른 글
| OpenClaw 를 버리고 Hermes 로 간 이유 (0) | 2026.08.12 |
|---|---|
| 브레인에 MCP 를 달다 (읽기 → 쓰기) (0) | 2026.08.12 |
| Slack 봇이 3분 걸린 이유 — 원인이 3겹이었다 (0) | 2026.08.12 |
| 매주 월요일 아침, 논문이 온다. (0) | 2026.08.11 |
| 단체 메일은 조용히. (0) | 2026.08.06 |