클로드 전문가 말고, AX 전문가
FOMO(Fear of Missing Out)는 흐름을 따라가지 못하면 나만 뒤쳐질 것이라는 두려움을 뜻한다. AI 코딩 분야에서 소셜미디어를 보면 마치 약간의 흥분 상태로 보이는 듯하다. 어디서 새로운 기능 뭐가 나왔다더라, 뭐가 좋다더라. 스킬이 있다더라, 누구는 이렇게 한다더라. 어느 조직은 에이전트를 만든다더라, 토큰 사용량을 측정하겠다더라와 같은 소문도 들린다.
코딩 에이전트, 그리고 AX와 관련해 지난 1달 간 내가 시도했던 것들과 생각을 정리하며, 앞으로의 방향을 가늠해 본다.
Try and Error
에이전트 오픈소스 프로토타입 만들어보기
에이전트 코드의 실체는 무엇일까. 우리가 일상처럼 쓰던 채팅 UI 형태의 llm은 인풋을 던지고, 답변을 기다려서 사람이 읽은 후, 다시 던지는 것을 반복한다. 일단 이것을 루프 형태로 순환시키며, 이전 인풋에 대한 아웃풋을, 다시 다음 인풋으로 던져, 사용자의 의도, 목적에 맞는 결과를 만족할때까지 루프를 돌면서, 도구를 사용하고, 상태 관리를 하는 것이다. 프론티어 모델이 좋다던지, 콘텍스트, 메모리 최적화나 멀티 에이전트도 결국 부차적인 것들이다. LLM의 내부 원리와 동일하다. 같은 인풋을 던져고, 매번 응답이 다른 이유는 스테이트리스, 상태를 가지지 않는 모델의 응답은 비결정적이기 때문이다. 상태가 없다는 말의 의미는 다음 출력을 결정하는 다음 잇풋이 곧 이전의 인풋과 아웃풋이기 때문이다. 코딩 에이전트도 동일한 원리를 차용한 것으로 보인다. 이전의 응답 결과를 다음 요청에 담아서 보내고, 이것을 반복시킨다. 나는 오픈소스 하나를 골라, 핵심이 되는 것만 골라서 직접 에이전트를 만들어보았다. 먼저 맥스튜디오에서 운영중인 로컬 LLM을 붙였다가, 단순하지만 복잡한 작업인, 새 프로젝트를 생성 시켜보기도 하고, 기존 코드베이스를 읽게한 후 문서를 작성시켜보았다. 전자는 디코딩, 후자는 인코딩이다. 만들다보니, 우리 시스템 어디에 응용할지, 적은 비용으로 혜택 볼 수 있는 부분이 떠올랐다. 내가 겪는 문제, 팀원의 시간을 아껴주는 곳에 효율적인 방법을 골라 적용해볼 예정이다.
에이전트 사용해보기
일단 가장 쉬운건 돈을 쓰는 것이다. LLM 4개 구독한다. (미국 기업 2개, 중국 제품 2개) 그리고 코딩 에이전트 상용 서비스 클로드, 오픈소스 서비스 오픈코드를 이용해본다. 새 프로젝트는 HTTP 스트리밍으로 STT를 네트워크 위에 올린 서비스로, 회사에서 CS 음성 데이터의 분석이 마침 필요해서 진행해보았다. 설계 문서 없이, 결과를 사람이 기다리는 바이브 코딩 스타일이다.
두 번째는 지금 작성하는 블로그는 매번 Github Pages로 서비스되기 때문에, 문서를 매번 깃헙 레파지토리에 커밋, 푸시를 해야했다. 포스트의 작성 환경과 출판 환경이 불일치했기 때문에 작성한 글의 출판 빈도가 적어졌다. 그래서 옵시디언 하나로 통일시키기 위한 시스템을 만들었다.
에이전트에 모든 MCP를 연결해본다. 미디어에서 된다라고 하는 것의 수준과 실체가 궁금했다. 코드리뷰 자료를 슬라이드덱으로 만들어보기도 하고, 피그마를 붙여보기도 했으나 만족할만한 수준인지는 잘 모르겠다. 아직 손이 많이간다.
소셜미디어 활동, 주변인 인터뷰
주변에 사람들을 꽤 많이 만났다. 디자이너부터 개발자, 기술과 관련없는 사람들이 느끼는 것과 내가 인식한 수준의 거리를 쟀다. 비슷한 FOMO를 겪기도 하고, 자조적이기도 하다. 반면, 과거에 잘 했던 사람은 대상만 바뀌었지, AI가 아니더라도 잘 할 사람들이기도 하다. 내 인맥이라는 물리적 한계로 얻은 결론을 일반화 할 수는 없으니, 인풋을 온라인으로도 늘인다. 유튜브도 AI 몇 개 좋아요 눌러놓고 알고리즘을 바꿔, 피드를 보고, 쓰레드, X 모두 마찬가지로 테크 인플루언서들의 목소리와 개발자들의 목소리도 살펴보았다. 트렌드를 꽤 빠르게 얻을 수는 있었다.
설계서/작업지시서 작성, 수행 연습
AI에게 잘 시키려면, 내가 어떤 산출물을 낼지, 산출물의 품질을 측정할 수 있어야 한다. 기획자의 언어로 된 비즈니스 요구사항을 기능/비기능 목록으로 만들어내고, 그 기능을 개발자에게 잘 전달하고, 만들어진 결과물을 검증하는 것. 이런 시스템을 만들어 운영하려면, 휴먼 워크플로우의 작업지시서를 내가 직접 수행하면서, 이 부분을 시스템으로 대체하려는 상상을 보해는 것이다. 결국 AI가 아니라 본질로 돌아간다. 내 아웃풋을, 내 대신 시스템이 생산하도록 하려면, 내가 AI의 산출물을 평가할 수 있어야 한다.
시간 차와 거리 차
우리 각자에게는 시간과 거리라는 차이가 있다. AI는 사과, 바나나같은 실체가 명확한 대상이 아니다. 젠슨 황, 일론 머스크가 말하는 AI와, X에 포스팅하는 어느 개발자 사이에도, 비즈니스 요구사항, 업무를 쳐내느라 바쁜 개발자와, AX를 리딩해야하는 리더 사이에서도 너무 큰 시차가 발생한다. 시차는 내 수준에서 보이는 것과, 저 수준에서 보이는 미래 사이의 간극이 너무 크다는 말이다. 저 사람에게는 보이는게, 나한테는 안 보일 수 있는 것이다. 일단 이것을 인정해야 한다. 수 년 전처럼, 문제A에는 솔루션 B를 쓰세요 라고 정답이 명확하지가 않다. 그래서 회사 간, 개인 간, 추구하는 방향 간 거리가 너무 크게 발생한다. 이 말은 아직 정답에 가까운 뭔가가 나오지 않았고, 누구나 다 시행착오를 하고있는 상태이지 않을까.
앞에서 이야기한 대상만 바뀌었을 뿐, 어느 환경에서든 살아남을 조직 또는 개인. 여기에 답이 있어 보인다. 기능 테스트, 내가 만든 서비스를 모니터링을 안/못하던 조직에서, 갑자기 클로드를 사용한다고 산출물이 좋아질까? 이게 지속가능할까? 당장 생산은 빨라지더라도 지금 수준에서는 검토의 문제가 반드시 생길 것이다. 개발조직이 AX를 도입해서 와 이제 개발자 필요없어졌다고 치자. 개발 산출물을 결정하는 비즈니스 요구사항이 담긴 기획서가 그대로라면, 내 출력, 즉 산출물의 한계는 정해져있는 것 아닌가?
워크플로우
그래서 워크플로우에 더 집중해야 한다. 안 좋은 워크플로우에 AI만 도입하면 그냥 안 좋은 결과를 빠르게 생산할 뿐이다. 내 산출물을 결정하는 인풋은 무엇인가, 내 아웃풋의 수준을 효과, 효율적으로 생산하려면 어떻게 해야 하는가라는 질문부터 시작해서, 내가 일하는 것을 제3자 입장에서 보듯이, 마치 바둑을 구경하는 옆 사람처럼 메타인지를 통해 바라볼 수 있어야 한다. 워크플로우가 있고 그것에 적절한 도구를 선택해야 한다. 모든 워크플로우에 AI를 적용할 필요 없다. AI가 아니라 크론과 같은 시스템이어도 된다. 휴먼 워크플로우도 필요하다. 그런데 워크플로우 자체를 인지 해야한다. 도구만 클로드, 코덱스를 도입한다면 결과의 한계는 이미 도구로 접근한 순간 결정된다. 에디터를 인텔리제이에서 다른 무언가로 바꾼다고 크게 바뀔까.
방향과 전략
내가 선택한 방향은 3가지이다.
- 변하지 않는 것, 코어에 집중
- 했다고 치고 넘어가기
- 소프트웨어 개발분야의 에이전트를 넘어 비즈니스의 AX
1번은 본질을 흐리는 너무 많은 정보를 거르는 작업이다. 거르고 걸러, 핵심만 되는 부분에 투자한다. "이 도구/모델을 쓰면, 더 복잡한 작업을 수행할 수 있어"의 접근이 아니라 "LLM의 콘텍스트의 한계를 결정하는 것은 무엇인가", "모델과 에이전트는 어떤 전략으로 콘텍스트를 압축하는가"와 같은 본질에 가까운 접근이다. LLM 모델의 컨셉에서 임베딩 모델이나 RAG, 코딩 에이전트가 나왔듯이, LLM 모델을 더 이해하는 것이 중요하지 않을까.
2번이 특히 중요하다. 정보가 너무 많고, 그래서 하고 싶은 것도 너무 많다. 그런데 비즈니스 요구사항도 하랴, 기술 리서치도 하랴, 모든 것을 할 수 없다. 손이 빠른 편이라, AI 이전 세상에서는 빨리 하면 되니 편했는데, 이제 손이 따라가지 못한다. 그래서 관념적으로 머릿속에서만 수행 후 결론을 내고, 실제로 수행하는 것은 1번에 가까운 것만 수행해야 한다.
3번은 비즈니스 분야에 AX를 적용하는 것이다. 개발 분야에 도입하는 것은 당연한 수순처럼 보이지만, 비개발자에게 AI 도구를 쥐어주는 것은 차원이 다른 어려움일 것이다. 실제로 회사에서 진행중인 AX중 하나로, 각종 장애, 이슈 등 접수 채널을 프론트데스크라는 프로젝트로 운영중이다. 이슈를 접수되면, 접수된 채널에서 메시지를 읽고, LLM이 분류하고, 문제를 분석해서 우리 지식 데이터로부터 조회 후 최소 수행 절차를 제시해주는 방향으로 진행중이다. 이것을 올해는 AS 분야로 확장에서 접목시키고 있다.