최근 반년간 회사에서 AI TF 업무를 진행하면서 확인했던 인사이트들을 정리해 보자.
현업에서 AI에 대한 고찰
회사에서 팀원분들이 AI를 얼마나 업무에 활용하나 보면
- 업무 대부분을 AI에게 맡겨 자동화한다.
- 아직까지는 업무에 조언 정도만 받는 정도고, 실질적인 도움은 잘 모르겠다.
이렇게 갈리는 것 같다.
물론 작년 말부터 제대로 GPT나 Claude 같은 도구들의 enterprise 계약을 시작하며 본격적으로 업무에 활용한 기간은 길지 않지만,
AI를 어떻게 업무에 활용하는지 고민을 하게 되는 것 같다.
물론 이건 직무마다 AI를 밀도 있게 활용할 수 있는 범위가 다르긴 하다.
포인트는 시스템을 얼마나 쉽게 AI에 통합할 수 있는지인 것 같다.
예를 들어, 개발자들의 경우 기존 업무 환경 자체가 AI에게 친화적인 환경(Git, Slack, k8s)이고, 대부분의 컨텍스트가 자연어로 처리되며, 조회(GET), 변경(UPDATE) 자체가 명세로 작성되어 있는 환경인 경우 더욱 AI를 도입하기 쉬워지고, LLM 학습 자체가 해당 환경 자체를 학습 데이터로 활용했을 가능성이 높다.
하지만, 이 구분도 생각보다 멀지 않게 허물어질 것 같다.
AI의 능동화
최근 AI 솔루션들이 모델 자체의 발전보다는 LLM에게 sandbox 내에서 subtask 명령을 수행할 권한을 주고, 본인이 도구들을 선택해 수행하게 되었다. 예를 들어 Claude Code, Codex, OpenClaw 등이 있다.
개인적으로 이게 가장 큰 터닝포인트인 것 같다. 단순히 외부에서 Agentic AI라는 것을 칭송할 때도 그렇게 큰 도움이 되지 않을 거라고 생각했다. 작년에 LangGraph가 처음 나왔을 때, 직접 코딩으로 해당 workflow를 구현해야 했고, 튜닝도 직접 개발자가 개입할 필요가 있었다.
하지만 이제는 LangGraph는커녕, Skills와 같은 source에 대한 connector도 프롬프트로 생성이 가능해진 단계까지 보고, 이제는 AI의 커버리지가 훨씬 더 늘었다고 생각한다.
AI Connector에 대한 생각
얼마 전까지 핫했던 게 MCP 서버였다. 수행해야 할 행동들을 서버에 구현해 놓고, LLM이 해당 서버에 tool 호출을 통해 서비스에 접근하게 만든 프로토콜이었다.
최근엔 이도 필요 없다고 한 게, 위에서도 언급한 sandbox 형태의 CLI에서 동작 수행을 너무나 잘하기에, 굳이 사전에 행동들이 명시된 MCP 서버도 필요 없다는 것이다.
하지만, 나는 아직까지 둘이 상위 호환적인 관계는 아니라고 생각한다.
MCP
- Action에 대한 명세가 정확하고 예외적인 상황이 필요 없는 경우
- 연결된 서비스들에 대한 연동이 구현되어 있어야 함(Open API, SQL 등)
SKILL (CLI)
- 너무나 다양한 Action의 형태가 존재하는 경우(사용자가 개별로 custom이 필요한 경우)
- sandbox 밖의 context가 필요한 경우는 보안상 위험
각각에 맞게 필요한 connector들을 선택해 AI에 통합시키면 된다.
Interface (UX)에 대한 고민
이게 가장 큰 고민인 게, 대부분의 사람이 익숙한 게 ChatGPT와 같은 챗봇 형태의 UX이다.
다만 해당 UX에 한정되다 보니, 사람이 중간에 개입하는 interaction이 제한될 수밖에 없고, 팀에 대한 공유가 어렵다는 점이다.
그렇다고, 웹 환경의 새로운 시스템을 만들자니, 들어가는 리소스를 고려하면 배보다 배꼽이 커지는 경우이다.
스케줄링과 다양한 시스템과 연동이 가능한 n8n과 같은 도구들도 고민하고 있지만, (생각보다 굉장히 빠르게 workflow를 찍어낼 수 있다.)
AI agent에 대한 커스텀이 너무나 부족해, 단순한 작업만 가능하다.
이건 아직까지 고민이 많은 것 같다.
AI를 업무에 더 밀도 있게 쓰려면
여기서 내가 말하고 싶은 부분은 사내에서 개인이 AI를 더 잘 쓰는 법을 정리하는 게 아니다. 예를 들어, AI에게 어떻게 프롬프트를 해야 더욱 답변이 잘 나오고, Claude보다 Gemini가 어떤 업무를 잘하나? 이런 미시적인 영역이 아니라, 업무 시스템 자체를 AI에 통합할 수 있는 거시적인 영역에 대한 고민이다.
예를 들어, 사내에서 Confluence 위키, 공용 드라이브를 사용한다고 해 보자.
위키들의 정보들을 AI에게 참고시키고, context를 이해시키게 해야 한다고 하자. 그렇다면 해당 환경에서 지양해야 할 것은 무엇일까?
현재 LLM들은 context size가 200K 토큰 정도이다. 당연히 사내 정보를 모두 넣을 수 없는 용량이다.
업무에 대한 검색 시스템이 필요할 것이고, LLM에게 ground rule로 해당 검색 시스템에 어느 정보들이 있는지 지시하는 것이다. (여기에 말한 검색은 RAG일 필요는 없다)
이미지나 PPT와 같은 소스들은 자연어보다 훨씬 많은 token을 소비하기에 최대한 자연어로 검색이 가능한 시스템일수록 성능이 좋다.
또한 커뮤니케이션 이력들이 투명해야 한다.
사전에 합의한 내용들이 메일과 유선으로만 공유되어, AI에게 접근이 불가한 경우 해당 맥락이 제공이 어렵다면 이는 큰 방해 요소가 된다.
조회가 가능한 Jira, Slack과 같은 기타 협업 툴을 쓰는 것이 더욱 효율적이다.