시몬
2026-06-04
조회수 206

 올해에도 AX이야기를 했었다. AI를 도구로 쓰는 것을 넘어서 업무 시스템 자체를 바꿔야 한다고. 말은 그렇게 했는데, 올해 진짜로 해보니까 생각보다 훨씬 험했다.

 제리님이랑 한 달 동안 "헤르메스"라는 AI 워크스페이스를 직접 구축했다. 우리 서버에 올리고, 슬랙이랑 연결하고, 조직의 맥락을 자동으로 위키에 쌓는 시스템. 그 과정에서 겪은 삽질들을 좀 풀어보려고 한다.

 우리가 슬랙이나 먼데이를 못 쓰는 게 아니다. 도구는 잘 쓰고 있다. 문제는 따로 있었다.

 슬랙에서 뭔가 논의하고, 먼데이에 태스크 만들고, 드라이브에 자료 넣는다. 근데 한 달 뒤에 누가 "이거 왜 이렇게 된 거예요?" 하고 물으면, 아무도 정확하게 대답을 못한다. 그때 왜 그런 결정을 했는지가 슬랙 스크롤 어딘가에 묻혀있으니까. 이게 반복되더라. 결국 도구가 문제가 아니라 맥락이 이어지지 않는 게 문제였다.

 그래서 헤르메스한테 제일 먼저 시킬 일을 "조직 위키 만들기"로 잡았다. 사람이 매뉴얼을 쓰는 방식이 아니라, 평소에 우리가 나누는 대화에서 AI가 맥락을 뽑아서 위키에 쌓아주는 구조. 대화하면 위키가 알아서 자란다, 그게 목표였다.


  "개발은 구독 도구, 운영은 API"로 분리했다. 헤르메스를 OpenRouter API 위에 올린 이유다.


 순탄했으면 굳이 글을 안 썼을 것이다.

 헤르메스의 뇌를 뭘로 할지 고르는 게 이렇게 어려운 건지 몰랐다. 처음에 "Sonnet이랑 Opus 두 개 쓰자"고 했다가, "맥락 허브니까 기준이 달라야 하는 거 아냐?"로 바꿨다가, "한국어 잘하고 빠르고 싼 거"로 또 바꿨다가, 결국 "비용 대비 안정적인 거"로 DeepSeek V4 Pro에 안착했다. 4번을 갈아엎은 거다. 돌이켜보면 당연한 건데, "이 AI한테 뭘 시킬 건데?"를 먼저 안 정하면 모델 비교는 끝이 없다.

 재밌었던 건, DeepSeek이 중국에서 만든 거라 한국어 존댓말이 흔들리거나 영어가 섞이지 않을까 걱정을 꽤 했다는 거다. 걱정만 하고 있어도 답이 안 나오니까 직접 테스트를 돌렸다. 5턴 대화를 시키면서 존댓말이 풀리는지, 영어가 끼는지 확인했는데 영어 혼입 0, 반말 0. 기우였다. 역시 걱정은 걱정이고, 해봐야 아는 거다.

 그리고 제일 극적이었던 건 서버가 죽은 거다. 헤르메스를 처음 올린 클라우드(Orgo)가 어느 날 갑자기 접속이 안 됐다. "Socket is not connected" 에러만 뜨고 끝. 처음엔 우리가 뭔가 잘못 건드린 줄 알고 제리님이랑 한참 뒤졌는데, 알고 보니 인프라 자체가 불안정했던 거였다. 바닥이 흔들리는데 위에 뭘 올려봐야 소용이 없다. 바로 다른 서버(Hostinger VPS)로 옮기기로 했다.

 근데 이때 진짜 다행이었던 게, 미리 GitHub에 백업을 해뒀다는 거다. 설정 파일, 위키 데이터, 검증 스크립트를 전부 git에 올려놨기 때문에 서버가 죽어도 데이터를 하나도 안 잃었다. 헤르메스가 오픈소스(Nous Research)라서 아무 서버에나 다시 깔 수 있고, 핵심 데이터가 폴더 하나에 다 들어있어서 그거 복원하면 끝이었다. 서버가 죽었는데 아무것도 안 잃었다. 

 서버 이전 과정도 자잘한 함정들이 자꾸 나왔다. SSH가 안 돼서 모든 걸 채팅 에이전트한테 시켜야 했고, 명령어를 하나하나 붙여넣는 게 진짜 노가다였다. 컨테이너가 여러 개라 "나 지금 어디 있는 거지?" 싶기도 했고, 서버마다 데이터 경로가 달라서 맞춰줘야 했다. 하나하나는 별거 아닌데, 이게 쌓이면 "이거 진짜 되긴 하는 건가" 하는 순간이 온다. 그 순간을 넘기는 건 기술력이 아니라 그냥 끈기인 것 같다.


 서버가 죽으면서 자동화 코드도 같이 사라졌다. 슬랙 메시지를 수집해서 위키에 쌓던 크론 스크립트가 통째로 날아간 거다. 근데 코드는 없어도 "이게 뭘 하는 건지"를 적어놓은 설계 문서가 있었다. 그걸 헤르메스한테 주면서 "이거 내용대로 다시 만들어줘" 했더니, 진짜 만들어냈다. 사람이 코드를 직접 짜는 게 아니라, "뭘 해야 하는지"를 말해주면 AI가 구현하는 방식. 실제로 작동하더라. 코드보다 설계 문서가 더 중요한 것 같다. 코드는 날아가도 다시 만들면 된다. 근데 "왜 이걸 만들었고 뭘 해야 하는지"는 적어두지 않으면 그냥 사라진다.

 좀 의외였던 건, 내가 옆에서 같이 작업한 위키는 꽤 좋았다는 거다. 슬랙 메시지를 그냥 옮기는 게 아니라, "통장 3분리 구조"라든가, "허브앤스포크 분업 방식" 같은 인사이트를 AI가 스스로 뽑아내더라. 그냥 요약이 아니라 의미를 읽어내는 수준이었다. 근데 자동으로 혼자 돌린 결과는 달랐다. 메시지 원문을 그냥 복붙한 수준. 같은 워크플로우인데 사람이 붙어 있느냐 아니냐에 따라 품질이 완전히 달라졌다. "한 번 잘 됐다"가 "앞으로도 잘 될 것이다"의 보증이 아니라는 거. 이건 꽤 중요한 깨달음인 것 같다.

 그리고 제일 아찔했던 순간. 자동 수집 결과를 점검하고 있었는데, 전화번호(010-XXXX-XXXX)랑 외부 고객 실명이 마스킹 없이 위키에 그대로 올라가고 있었다. 내가 직접 작업할 때는 자연스럽게 "이건 빼야지" 하고 걸러냈는데, 자동은 원문 그대로 올린 거다. 바로 크론 프롬프트에 마스킹 규칙을 박고, 이미 쌓여 있던 멘션 25건을 전부 정리했다. 겉으로 보기엔 잘 돌아가는데, 열어보면 문제가 쌓이고 있을 수 있다. 자동화를 많이 할수록 사람이 더 자주 들여다봐야 한다. 좀 아이러니한데, 이게 현실이더라.

 아직 크루 전체한테 본격적으로 열지 않았다. 제리님이랑 계속 다듬고 있다. 비용 조정도 하고, 운영도 안정시키고. 서두르지 않으려고 한다.

 크론 복구할 때 정한 원칙이 하나 있다. "4개를 동시에 어설프게 살리지 말고, 제일 중요한 하나를 제대로 만들어서 패턴을 잡자." 지금 slack-ingest 하나가 안정적으로 돌고 마스킹까지 확인된 상태다. 이걸 기준 삼아서 나머지를 하나씩 늘려갈 생각이다.

 지금 돌아가고 있는 구조는 이렇다. 헤르메스가 매일 자정에 슬랙 7개 채널을 돌면서 메시지를 수집하고, 가공해서 위키에 쌓고, GitHub에 자동 백업한다. 위키가 GitHub, 내 맥, 서버 이렇게 세 곳에 동기화되니까 어디가 죽어도 살아남는다. 앞으로는 모델을 업무에 맞게 나눠 쓰고, 크루들한테는 체감이 큰 기능부터 하나씩 열어가려고 한다. 슬랙에서 논의는 됐는데 먼데이에 태스크로 안 올라간 것들, 이걸 헤르메스가 자동으로 잡아서 리마인드해주면 좋겠다는 생각도 있다. 위키 분석하다가 나온 아이디어인데, 해볼 만한 것 같다.

 작년에 AX 이야기를 했을 때는 이런 삽질들을 예상 못 했다. AI 전환이라는 게, AI가 알아서 해주는 게 아니라 사람이 직접 부딪혀보면서 알아가는 과정이더라. 뭘 원하는지 먼저 정해야 고를 수 있고, 바닥이 흔들리면 위에 뭘 올려도 소용없고, 자동화할수록 점검은 더 자주 해야 하고, 코드보다 "왜 이걸 만들었는지"가 더 중요하다.

기술을 배운 것 같지만 사실 기술이 아닌 것들을 배운 한 달이었다. 이 과정을 적어두면, 다음에 하는 사람은 좀 덜 헤매겠지.

1