Camunda는 기업의 복잡한 비즈니스 프로세스를 설계, 실행 및 제어하는 데 사용되는 프로세스 오케스트레이션 및 자동화 플랫폼을 제공하는 기업입니다. 제품 문서에 AI 에이전트를 제공하고 있다고 설명하는데, 일단 사이트를 보면 kapa.ai를 사용하는 듯합니다.
https://docs.camunda.io/
문서에 AI 기능을 추가하려고 할때 구현하고자 하는 최소한의 요구사항을 4가지로 정리했습니다.
- Cite the Sources
AI 질의로 만들어진 콘텐츠가 어떤 출처에서 만들어졌는지, 사용자가 추가적인 정보를 원한다면 어느 문서로 이동해야 하는지 알 수 있어야 합니다. 초기 ChatGPT에서 답변의 출처에 대한 문제가 많았는데, 최근에는 어느 정도 추가 정보를 제공하고 있죠. 실제 질의 결과를 보면 모든 단락 뒤에 출처가 표시되어 있는 것을 확인할 수 있습니다.
- Allow for feedback from users, including immediate corrections
사용자 피드백은 좋아요, 싫어요 정도 제공하고 있는 듯한데, 관리자 피드백은 아마 kapa.ai에서 제공하는 대시보드에서 컨트롤을 할 수 있을 겁니다.
- Low effort to implement and maintain
이건 뭐 우리의 손을 더럽히고 싶지 않다 정도 같구요.
- Impress me
MVP에 어울리지 않는 요구사항 같지만, 그렇다고 합니다.
AI가 충분한 정보를 가지고 있지 않을때 모른다라고 답해주는 것도 맘에 들었다고 합니다. kapa.ai에서는 이런 질의에 대해 추적할 수 있는 기능을 제공하고 있으며 관련된 콘텐츠를 보완할 수 있는 기회를 제공하기 때문입니다.
AI를 도입하면서 힘들었던 점은 어떤 솔루션을 선택해야 하는지 모호했다는 겁니다. 제안을 하는 솔루션들은 모두 그럴듯하게 이야기하고 있지만, 어떤 말을 믿어야 할지 선수들끼리 고민을 했다는 그런 의미인 것 같습니다.
ugly와 bad가 어떤 차이인지 모르겠으나 하여간 ugly 역시 솔루션 선택에 대한 이야기입니다. 여러 솔루션을 검토하면서 아래와 같은 문제가 있었고 솔루션에서 이런 문제를 어느 정도 해결하는데 도움을 줄 수 있느냐를 중요하게 여겼다고 합니다. 앞에서 언급한 최소한의 요구사항과도 연결되는 부분이죠.
- GARBAGE IN, GARBAGE OUT
이건 kapa.ai에서 문서 작성에 대한 팁을 공개한 적이 있는데 그 부분을 참고하면 좋을 듯 합니다.
2025.06.11 - [그냥 번역] - AI를 위한 문서 작성: 베스트 프랙티스
- WHY DID WE HAVE DOCUMENTATION FROM OUR OLD PRODUCT MIXED WITH OUR NEW PRODUCT?
왜 이전 제품의 문서가 새로운 제품과 혼재되어 있었는가?
개인적인 경험으로 파이썬의 특정 라이브러리를 사용하는데, ChatGPT가 자꾸 잘못된 설명을 알려주었습니다. 왜 그런가 하고 살펴보니 ChatGPT가 참조하는 것은 해당 라이브러리의 베타 버전 문서였고, 사용하는 버전은 정식 릴리즈된 버전이었다는 것이었죠. 제품의 버전이 여러 가지인 경우 사용자가 사용하는 버전에 맞는 콘텐츠를 제공해 주는 것도 중요한 부분입니다.
- WHY DID WE NAME OUR PRODUCTS AND COMPONENTS THE WAY WE DID??!
왜 우리 제품과 구성요소에 그렇게 이름을 붙였는가?
- WHO IS GOING TO BABYSIT THE RESPONSES?
누가 이 답변들을 돌봐 줄 것인가?
발표 내용과 좀 다른 내용이긴 하지만, 마지막 정리가 깔끔하네요.
For stakeholder conversations
- LLMs enforce good docs behaviors and hygiene
앞에서 언급한 "GARBAGE IN, GARBAGE OUT"와 연결된 의미 같네요. LLM에서 사용할 정보를 평가하고 향상할 수 있는 기회로 이어질 수 있다 뭐 그 정도의 의미 같습니다.
- AI Agents source actual user questions
제품에 대한 사용자 반응을 얻는 것은 점점 더 어려워집니다. 사용자는 설문도 싫어하고 간단한 좋아요, 싫어요도 귀찮아하기 때문이죠. 그런데 AI에 대한 질의는 대화 형식이기 때문에 어떤 부분에서는 마치 사용자 인터뷰 같은 효과를 얻을 수 있습니다. 때문에 적은 비용으로 실제 사용자의 요구사항을 얻을 수 있다는 장점이 있습니다(물론 사용자를 특정할 수는 없다는 한계는 있습니다. 사용자를 특정한다면 그건 그거대로 문제가 될 수 있구요).
- LLMs are best at "how do I" type questions (reduce "how do I" tickets!)
문서화의 지표 중에 가장 많이 사용하는 것이 기술지원에 대한 비용 절감인데, LLM은 그 부분을 좀 더 강화할 수 있다는 이야기입니다.
For implementers
- Design a set of questions (and sources!) to test
발표자는 꽤 많은 솔루션을 검토했고 답변을 평가하는 기준을 나름대로 만들었던 것 같네요.
- Take calculated and informed risks
LLM이 가질 수 있는 위험 요소(예를 들어 환각) 같은 것을 인지하고, 대비할 수 있어야 합니다. 특히 공식적인 콘텐츠 외에 포럼 등의 자료까지 활용하는 경우 잘못된 콘텐츠에 대해 어떻게 대응할지에 대한 준비가 되어 있어야 합니다.
- Commit to evaluating and reviewing the metrics
그리고 운영하면서 나오는 여러 수치와 결과에 대해 평가하고 대응할 수 있는 조직이나 인력도 필요하구요.
* 포틀랜드 2025 컨퍼런스에서도 kapa.ai에 대한 간증(?)이 있었습니다. 같이 보셔도 좋을 것 같네요.
2025.06.11 - [테크니컬 라이팅/컨퍼런스] - WTD 포틀랜드 2025 - AI는 단순히 '문서를 대신 써주는' 도구가 아닙니다
https://youtu.be/Us4zFL7JF8U?si=KpmGnOs8zj4BYNw2
