Roy Derks는 IBM에서 일하고 있습니다(테크니컬 라이터는 아니고, PM입니다). AI 에이전트를 활용하는 방안에 대한 이야기를 공유합니다. 일반적으로 많은 기업이 AI를 통해 일관성 있는 문서를 만드는 것을 이야기하는데 Roy는 오히려 이 때문에 AI가 문서를 만드는 것은 반대한다고 합니다. 모든 문서가 너무 똑같아 보이니깐요.
person should do and not AI because otherwise all these documentation pages will start looking like each other.
제품마다 가지고 있는 톤앤매너가 있고, 문서 작성자마다 독특한 위트나 개성이 사라지는 것은 아니라는 것 같습니다. 문서화 과정에서 반복되는 작업을 AI를 통해 자동화하고 개선하는 것은 가능하지만, 여전히 창의적인 개발자 문서를 만드는 것은 개발자나 테크니컬 라이터의 역할이라는 것이죠(IBM의 공식적인 입장인지는 모르겠습니다).
AI 에이전트에 대해 이야기할때 어떤 언어 모델을 쓸 것인지에 대해 많이들 이야기하는데, Roy는 그것보다 어떤 도구를 사용할 수 있는지가 중요하다고 합니다. 실제 사람처럼 말이죠. 언어 모델을 상당 부분 많은 성장을 했기 때문에 어떤 모델을 사용하는지 큰 차이는 없습니다.
기존 문서 관리는 분산된 팀에서 관리하고 있었습니다. 제품 문서는 콘텐츠 팀과 제품 팀이 관리했고, GitHub 저장소에 올라간 문서는 각 SDK 개발 엔지니어들이 관리하고 있었습니다. 각각의 문서는 개발자 허브를 통해 제공됩니다. 하지만 각 팀이 문서를 만들면 이를 PM이 확인하고 개발자 허브에 게시하는 수작업이 포함되어 있습니다.
이렇게 수작업으로 진행되는 것을 자동화하기 위해 처음에는 LangGraph와 타입스크립트를 사용해 간단한 싱글 에이전트를 만들었습니다. CMS로 생성되는 페이지는 웹스크래핑을 사용해 데이터를 가져오고 GitHub에서는 저장소를 읽어서 정보를 확인합니다. 이 과정에서 일부 웹스크래핑이 막힌 페이지 문제가 있었구요. 정확도가 낮았고, 유지보수도 쉽지 않았습니다.
그래서 두 번째 단계로 멀티 에이전트를 사용하는 방식으로 변경했습니다. 각 리소스마다 에이전트를 구성하지만 기본적으로 사용하는 도구는 싱글 에이전트일때와 같습니다. 하지만, 개별 에이전트가 실패하는 경우에는 역시 정확도는 떨어지기 때문에 첫 번째 시도와 큰 차이는 없었습니다. 오히려 에이전트 간 핸드오프 과정에서 오류가 발생하기 쉽고, 시스템 프롬프트가 늘어나 토큰 소비량이 증가하여 비용 효율성이 떨어졌습니다.
다음 단계로 MCP를 도입했는데, 일단 유지보수면에서 상당한 이득이 있습니다. 각 에이전트별로 호출 로직을 따로 작성할 필요 없이 MCP로 일원화할 수 있어서, 에이전트가 늘어나더라도 유지보수 부담이 늘어나지 않습니다. 처음에는 Claude Desktop 앱에 바로 연결해 에이전트 코드 한 줄 짜지 않고도 PR 생성까지 자동화에 성공했으며, 이후 LangGraph 에이전트로 전환하여 안정적으로 최적화했다고 합니다.
* 참고로 소개한 MCP 서버를 구축하는 방법에 대한 영상입니다.
Build your first MCP Server in TypeScript
https://youtu.be/8m-O_KiHRjk?si=vXjyWuvc3O1xr8G-
Roy Derks: Effectively use AI Agents to Maintain Your Docs
https://youtu.be/KBaGF0_a6RE?si=xv4FWqqV6H1w2mMF
