Little J를 만들기 전에도 저는 AI 에이전트를 업무에 사용하고 있었습니다.
Claude Code를 활용해 교육만족도 분석 에이전트 팀을 만들어 실제 업무에 적용해봤습니다.
여러 에이전트에게 역할을 나누고, 각자 데이터를 분석하게 한 뒤 결과를 종합하는 방식이었습니다.
직접 사용해보니 꽤 놀라웠습니다.
혼자 하나씩 분석하던 것과는 일하는 방식 자체가 달랐습니다.
그래서 자연스럽게 이런 생각을 했습니다.
“앞으로 우리가 일하는 방식이 정말 많이 달라지겠구나.”
그런데 동시에 한 가지 질문이 계속 남았습니다.
“그럼 AI와 ‘진짜 같이 일한다’는 건 어떤 모습일까?”
제가 만든 에이전트 팀도 분명 일을 잘했습니다.
하지만 여전히 제가 필요할 때 실행시키고 결과를 받아보는 ‘시스템’에 가까웠습니다.
그러던 중 재미있는 사례 하나를 만나게 됩니다.
올해 초쯤이었던 것으로 기억합니다.
지피터스 그룹에서 ‘뽀짝이’라는 AI 에이전트를 Slack에 초대해 업무에 활용하는 사례를 접했습니다.
처음에는 고양이를 의인화한 AI라는 점이 재미있어서 눈길이 갔습니다.
그런데 자세히 보니 더 충격적인 부분이 있었습니다.
뽀짝이 한 명(?)만 일하고 있는 게 아니었습니다.
서로 다른 역할을 가진 여러 AI 에이전트들이 함께 일하고 있었습니다.
저도 이미 Claude Code에서 여러 에이전트가 역할을 나눠 일하는 방식을 경험했기 때문에, 멀티에이전트 자체가 처음은 아니었습니다.
그런데 느낌이 달랐습니다.
제가 만든 에이전트 팀은 필요할 때 실행하는 시스템에 가까웠다면,
이 에이전트들은 사람들이 실제로 일하는 공간에 같이 들어와 있는 것처럼 보였습니다.
업무의 맥락을 어느 정도 이해하고 있고, 필요할 때 메신저에서 바로 부를 수 있고, 해결책을 제안하는 것에서 끝나지 않고 다음 업무까지 이어지는 모습.
심지어 각자의 캐릭터도 있었습니다.
묘하게 하나의 ‘존재’처럼 느껴졌습니다.
그 모습을 보면서 제가 가지고 있던 질문이 조금 구체적으로 바뀌었습니다.
“아, AI와 진짜 같이 일한다는 게 이런 모습일 수도 있겠구나.”
저도 해보고 싶었습니다.
아니, 꽤 많이 해보고 싶었습니다.
그런데 바로 시작하지는 못했습니다.
알아보기 시작하니 현실적인 문제들이 하나씩 보였습니다.
가장 먼저 걸린 것은 권한과 보안이었습니다.
AI 에이전트가 실제 일을 하려면 파일을 읽거나 프로그램을 실행하는 등 컴퓨터의 일정 영역에 접근할 수 있어야 했습니다.
그런데,
“이 권한을 정말 AI에게 줘도 되는 건가?”
걱정됐습니다.
당시 별도의 Mac mini를 구입해 아예 AI 에이전트 전용 컴퓨터로 사용하는 사람들도 보이기 시작했습니다.
저도 잠깐 고민했습니다.
“AI 동료 한 명 만들겠다고 컴퓨터부터 한 대 사야 하나…?”
결국 거기까지 가지는 않았습니다.
또 다른 현실적인 문제가 있었습니다.
뽀짝이는 Slack에서 일하고 있었습니다.
그런데 우리 회사에서 사용하는 메신저는 Slack도, Telegram도 아니었고, Notion 같은 협업 환경을 사용하고 있는 것도 아니었습니다.
무엇보다 기존 사내 메신저 안에 제가 만든 AI 에이전트를 넣는 것은 현실적으로 가능성이 거의 없어 보였습니다.
사례는 너무 재미있는데,
그대로 따라 할 수가 없었습니다.
OpenClaw를 직접 설치해본 것도 아닙니다.
한동안 다른 사람들이 만든 사례만 계속 찾아봤습니다.
누군가는 메신저에서 자기 에이전트와 대화하고, 누군가는 실제 업무를 맡기고, 누군가는 여러 에이전트를 팀처럼 만들어 사용하고 있었습니다.
저는 계속 구경했습니다.
조금 부러웠습니다.
당시에는 그냥 제가 기술을 잘 몰라서 망설이는 거라고 생각했습니다.
그런데 지금 돌아보니 다른 이유도 있었던 것 같습니다.
“잘못 선택하면 어떡하지?”
OpenClaw가 맞는지, Hermes가 맞는지.
어디에 설치해야 하는지.
어디까지 권한을 줘야 하는지.
어떤 메신저를 사용해야 하는지.
어떤 AI 모델을 연결해야 하는지.
검색하면 할수록 새로운 선택지가 나왔고, 새로운 것을 알게 될수록 오히려 결정하기가 어려워졌습니다.
특히 저는 개발자도 아니고 AI 인프라 전문가도 아닙니다.
그래서 자꾸 이런 생각이 들었습니다.
“이거 잘못 건드리면 안 될 것 같은데….”
실수하지 않으려고 충분히 알아본 뒤 시작하려 했는데,
아이러니하게도 실수하지 않으려다 시작 자체를 못 하고 있었습니다.
OpenClaw와 Hermes를 놓고도 꽤 오랫동안 고민했습니다.
처음에는 계속 비교했습니다.
“둘 중 뭐가 더 좋은 거지?”
그런데 아무리 찾아봐도 명확한 답이 나오지 않았습니다.
어느 순간 생각해보니 질문 자체가 잘못됐다는 생각이 들었습니다.
제가 만들고 싶은 동료가 무엇인지도 제대로 정하지 않은 채, 도구부터 고르고 있었습니다.
그래서 질문을 바꿨습니다.
“가장 좋은 AI 에이전트가 무엇인가?”
가 아니라,
“내가 원하는 AI 동료에게 필요한 것은 무엇인가?”
그때부터 조금씩 기준이 생기기 시작했습니다.
저는 당장 회사 전체가 사용하는 AI를 만들 필요가 없었습니다.
우선 나 한 명과 제대로 일하는 동료부터 만들어보면 됐습니다.
회사 컴퓨터 전체를 맡길 필요도 없었습니다.
Little J가 일할 수 있는 독립된 공간만 만들어주면 됐습니다.
회사 공식 메신저 안에 들어갈 필요도 없었습니다.
나와 Little J가 편하게 이야기할 공간만 있으면 됐습니다.
정답을 찾는 대신,
내가 감당할 수 있는 범위를 정하기 시작했습니다.
회사 컴퓨터에 바로 설치하지 않았습니다.
우선 제 개인 노트북에서 시작하기로 했습니다.
그리고 컴퓨터 전체를 열어주는 대신 Little J가 사용할 별도의 작업공간을 만들기로 했습니다.
우선 작은 범위에서 직접 경험해보기로 한 겁니다.
메신저도 같은 기준으로 생각했습니다.
회사 전체가 사용하는 협업도구가 필요한 것이 아니라,
나와 Little J 둘이 함께 일할 공간이 필요했습니다.
그래서 Telegram을 선택했습니다.
회사 공식 메신저를 바꾸려는 것도 아니고, 누군가에게 새로운 메신저를 사용하자고 설득할 필요도 없습니다.
우선 저 한 사람에게 잘 작동하면 됐습니다.
Little J를 조직 전체에 입사시키기 전에,
일단 제 동료로 먼저 출근시키기로 했습니다.
다음 선택은 AI 에이전트였습니다.
OpenClaw와 Hermes.
여기서도 꽤 오래 고민했습니다.
둘 다 기억과 스킬을 활용하고, 함께 일한 경험을 다음 업무에 활용해갈 수 있는 방향을 가지고 있었습니다.
OpenClaw 역시 사용자가 직접 스킬을 만들고 관리하며 에이전트의 능력을 확장할 수 있고, 학습을 통해 새로운 스킬을 만들거나 기존 스킬을 개선할 수 있는 구조를 갖추고 있습니다.
Hermes 역시 사용자가 직접 스킬을 만들 수 있지만, 제가 특히 눈여겨본 것은 에이전트가 함께 일한 경험을 돌아보고, 필요하다고 판단하면 기억을 남기거나 재사용할 만한 방법을 새로운 스킬로 만들고 개선해가는 학습 구조였습니다.
즉,
“OpenClaw는 학습하고 Hermes는 학습하지 않는다”
같은 단순한 차이는 아니었습니다.
제게 중요했던 것은 어느 방식이 제가 만들고 싶은 Little J와 더 잘 맞느냐였습니다.
저는 처음부터 완성된 AI 직원을 만들 자신도, 그럴 필요도 없다고 생각했습니다.
처음에는 조금 서툴더라도,
같이 일하고, 제가 알려주고, 실수하면 다시 고치고, 그 경험을 쌓으면서 점점 우리 업무를 잘하는 동료가 되었으면 했습니다.
그래서 Hermes를 보면서 들었던 생각은 의외로 단순했습니다.
“얘랑 오래 같이 일해볼 수 있겠다.”
그리고 하나 더.
“한번 잘 키워보자.”
그렇게 Little J가 기억하고, 도구를 사용하고, 실제 행동으로 이어갈 수 있게 해주는 기반으로 Hermes를 선택했습니다.
조금 단순하게 비유하자면,
Telegram에서 저와 이야기하고, 필요한 파일과 도구를 사용하고, 배운 것을 기억하면서 움직일 수 있게 해주는
Little J의 입과 손과 발을 선택한 셈입니다.
그런데 몸만 있다고 동료가 되는 것은 아니었습니다.
다음 질문이 남았습니다.
“그럼 Little J의 뇌는 뭘로 하지?”
제가 하는 말을 이해하고,
업무의 맥락을 해석하고,
무엇을 해야 할지 생각하고 판단하는 역할.
Little J의 뇌 역할을 할 LLM도 선택해야 했습니다.
Claude냐, GPT냐.
사실 그전까지 제가 실제 업무에서 가장 많이 사용하던 것은 Claude Code였습니다.
교육만족도 분석 에이전트 팀도 Claude Code를 활용해 만들었고, 코딩이나 여러 업무에서도 꽤 익숙하게 사용하고 있었습니다.
반면 ChatGPT도 구독하고 있었습니다.
문제는...
구독은 하고 있었는데 상대적으로 많이 사용하지 않고 있었습니다.
그래서 처음에는 당연히 Little J의 뇌도 Claude가 될 거라고 생각했습니다.
그런데 Hermes에서 제가 원하는 방식으로 Claude를 사용하려면 기존 Claude Code 구독과는 별개로 API 비용을 고려해야 했습니다.
반면 GPT는 당시 제가 이미 이용하고 있던 구독 환경을 활용할 수 있었습니다.
생각해보니 저에게는 너무 좋은 상황이었습니다.
이미 구독료는 내고 있는데, 잘 쓰지는 않고 있던 GPT가 있었습니다.
“그럼 Little J가 쓰면 되겠네?”
그렇게 제가 상대적으로 덜 사용하고 있던 GPT가 Little J의 메인 모델이 됐습니다.
거창한 모델 성능 비교 끝에 내린 결정은 아니었습니다.
굉장히 현실적인 선택이었습니다.
Little J를 만들면서 조금씩 알게 됐습니다.
좋은 선택이 항상 최고의 기술을 고르는 것을 의미하지는 않았습니다.
내가 감당할 수 있고, 계속 사용해볼 수 있고, 계속 실험할 수 있어야 했습니다.
처음에는 AI 에이전트 하나 설치하면 Little J가 만들어지는 줄 알았습니다.
그런데 아니었습니다.
어디에서 실행할 것인지.
어디까지 접근하게 할 것인지.
어디에서 대화할 것인지.
어떤 에이전트를 사용할 것인지.
어떤 AI 모델을 연결할 것인지.
하나를 결정하면 또 하나를 결정해야 했습니다.
그리고 매번
“이게 맞나?”
싶었습니다.
지금도 제가 선택한 방법이 정답인지는 모릅니다.
다만 한 가지는 달라졌습니다.
예전에는
틀리지 않는 선택을 한 뒤 시작하려고 했습니다.
그래서 꽤 오랫동안 다른 사람들이 AI 에이전트를 만들어가는 모습을 구경만 했습니다.
이제는 조금 다르게 생각합니다.
“완벽한 선택을 찾지 말고, 내가 감당할 수 있는 범위에서 한번 해보자.”
그래서 회사 컴퓨터가 아닌 개인 노트북에서,
컴퓨터 전체가 아닌 제한된 작업공간으로,
회사 메신저가 아닌 Telegram에서,
Little J의 입과 손과 발이 되어줄 Hermes와,
뇌 역할을 해줄 GPT를 선택했습니다.
돌이켜보면 Little J를 만드는 첫 번째 과정은 개발이 아니었습니다.
선택이었습니다.
그리고 어쩌면 Little J를 만들면서 가장 먼저 조금씩 성장하고 있는 건,
Little J가 아니라 저인지도 모르겠습니다.
이제 선택은 끝난 줄 알았습니다.
몸도 만들었고, 뇌도 골랐습니다.
Hermes를 설치하고 Telegram에 연결하면 드디어 제가 상상하던 AI 동료가 만들어질 줄 알았습니다.
그런데 아니었습니다.
Hermes만 설치한다고 AI 동료가 만들어지는 게 아니었습니다.
사람도 머리와 손발만 있다고 회사에서 바로 일을 할 수 있는 것은 아니니까요.
Little J가 실제 HRD 업무를 하려면
일할 공간도 필요했고, 봐야 할 자료도 필요했고, 실제 업무 시스템과 연결되는 길도 필요했습니다.
한마디로,
Little J에게 ‘업무 환경’을 만들어줘야 했습니다.
그리고 이게 생각보다 훨씬 큰 일이었습니다.
Hermes 에이전트, 개인 노트북의 작업공간, Replit으로 만든 업무 웹페이지, 그리고 GitHub.
각자 따로 존재하던 것들을 어떻게 연결해 Little J가 실제 업무를 할 수 있는 하나의 구조로 만들기 시작했는지 이야기해보겠습니다.
물론 이때는 아직 몰랐습니다.
연결만 하면 되는 줄 알았습니다.
