Imprint에서 내부 LLM 도구 및 에이전트 도입을 추진하며 얻은 실전 메모: 전략 수립, 프롬프트·팁 공유, 표준 플랫폼 선정, 지표, 내부 에이전트 구축, Slack/Jira/Notion 연동의 난점과 해결책까지.
2025년 12월 7일 게시. llm (23),executive (42)
지난 18개월 정도 내부 “AI” 도입을 해오고 있습니다. 사실 이는 LLM 툴링과 에이전트 도입에 가깝습니다. 이 문제는 현 시대의 모든 엔지니어링 리더에게 최소한 ‘사이드 퀘스트’ 정도는 된다고 생각합니다. 각 회사에서 이 문제를 다루는 사람이 워낙 많다 보니, 지금까지 배운 내용을 “작업 노트(working notes)” 형태로 정리해보고자 합니다.
이 글은 여러분이 무엇을 해야 하는지에 대한 권고가 아니라, 제가 지금까지 이 문제에 어떻게 접근해왔고, 지속적인 반복(iteration)을 통해 무엇을 배웠는지에 대한 요약입니다. 여기의 사고방식이 여러분에게 도움이 되거나, 적어도 롤아웃 과정에서 겪는 일을 일부라도 ‘맞아, 우리도 그래’라고 확인해주는 데 도움이 되었으면 합니다. 읽을수록 점점 더 구체적으로 들어가며, 끝에는 Slack 엔터티를 사람이 읽을 수 있는 텍스트로 표현한 것을 올바른 실제 엔터티의 mrkdwn 포맷으로 에이전트가 신뢰성 있게 변환하게 만드는, 값싼 터펜틴 냄새 같은 주제까지 다룹니다.
채용 중입니다: Imprint에서 내부 에이전트와 AI 도입을 저와 함께 추진하는 데 관심이 있다면, 창립 멤버급 Senior Software Engineer, AI 포지션을 채용 중입니다. 이상적인 후보는 에이전트 실험을 해본 제품 엔지니어(product engineer)로, 앞으로 1~2년 동안 이 영역을 깊게 파고들고 싶어 하는 분입니다.
기술자(technologist)로서 팀에 해줘야 하는 기본 중 하나는, 새로운 도구를 직접 사용해보며 무엇이 되고 무엇이 안 되는지에 대한 직관을 쌓는 일이라고 생각합니다. AI 도입도 다르지 않습니다.
그래서 저는 먼저 약간의 독서를 했는데, 특히 Chip Huyen의 _AI Engineering_이 도움이 되었고, 이후 몇 가지 범위가 제한된 프로젝트에 뛰어들었습니다. Claude code로 구현해 조잡한 개인 에이전트 플랫폼을 만들고, 블로그 글을 검색하는 매우 단순한 MCP를 만들고, Notion 문서에 코멘트하는 에이전트를 만들었습니다.
각 프로젝트는 2~10시간 정도였고, 매우 명확한 깨달음을 줬습니다. 특히 툴 사용(tool use)은 직접 간단한 툴-사용 에이전트를 구현해보기 전까지는 마법처럼 보였지만, 구현하고 나니 전혀 마법이 아니라 논리적으로 추론하고 이해할 수 있는 것이 되었습니다.
Imprint가 AI 도입을 다듬는 전반적인 접근은 전략 테스트(strategy testing)입니다. 즉, 몇 가지 목표를 정하고, 초기 접근을 선택한 뒤, 그 접근이 실제로 작동할 때까지 세부를 빠르게 반복 개선합니다. 과도하게 ‘옵틱스(겉모양/인상)’가 중요해진 시대에서, 고위 리더가 디테일에 몰입하는 것은 우리가 가진 몇 안 되는 방어 수단 중 하나입니다.
합류 직후, 경영진과 함께 위와 같은 AI 도입 전략을 초안으로 만들었습니다. 적당한 논의 끝에 우리가 정한 핵심 축(pillars)은 다음과 같습니다.
이 원칙들과 앞서 말한 바를 보면 알 수 있듯이, 제가 AI 도입에서 가장 두려워하는 것은 실제 생산성을 늘리기보다 ‘AI를 도입한 것처럼 보이게 만드는 것’에 집중하는 것입니다. 옵틱스는 어떤 일에서든 핵심 요소이지만, 거의 모든 흥미로운 일은 옵틱스와 현실이 만나는 지점에서 일어납니다. 이 축들은 그 교차점을 지지하기 위해 마련되었습니다.
참고로, _Crafting Engineering Strategy_에서 말하는 전략의 구성 요소 관점에서 보면, 이것은 사실 전략의 정책(policy)에 가깝습니다. 추가로 우리는 전략 테스트를 통해 접근을 정교화했고, 이를 운영하기 위한 구체적인 초기 액션 세트를 정의했으며(외부에 공유하기엔 다소 회사 특화), 제가 Carta에서 했던 기존 경험에 과적합(overfitting)하지 않도록 짧게 탐색(exploration)도 했습니다.
도입을 향한 첫 단계는 가능한 한 많은 내부 팁과 트릭 사례를 하나의 Notion 데이터베이스로 모으는 것이었습니다. 무엇이 자격이 있는지 아주 넓게 잡았는데, 다양한 기능(조직)에서의 도구 사용 예시를 많이 보여주는 것이 유용하기도 하고 영감을 주기도 한다고 믿었기 때문입니다.
이 데이터베이스는 회사 전반의 기여로 계속 확장되고 있으며, 사람뿐 아니라 봇도 AI 툴링으로 문제에 접근하는 방법을 제안하는 데 유용한 리소스가 되었습니다.
우리 접근에서 제가 가진 핵심 신념 중 하나는, 회사 내에서 프롬프트를 ‘발견 가능(discoverable)’하게 만드는 것이 매우 가치 있다는 점입니다. 발견 가능성은 네 가지(실제로는 다섯 가지) 문제를 해결합니다.
저의 핵심 접근은 모든 에이전트 프롬프트를 회사 누구나 읽을 수 있는 하나의 Notion 데이터베이스에 저장하는 것입니다. _대부분_의 프롬프트는 누구나 편집 가능하지만, 일부는 편집 제한이 있습니다.
아래는 고객지원(Customer Support)에서 들어오는 Jira 이슈를 올바른 엔지니어링 팀으로 라우팅하는 프롬프트 예시입니다.
다음은 인프라 엔지니어링 팀의 요청 채널에서 요청에 응답하는 프롬프트 예시입니다.
거의 모든 프롬프트는 생성된 메시지에 프롬프트 링크를 포함하라는 지시로 끝납니다. 이를 통해 ‘그저 그런 응답’에서 그 응답을 만든 프롬프트로 쉽게 이동할 수 있고, 그래서 고칠 수 있습니다.
팁과 프롬프트를 수집하는 것 외에, AI 도입의 다음 명확한 단계는 회사 내에서 사용할 표준 AI 플랫폼(예: ChatGPT, Claude, Gemini 등)을 정하는 것입니다.
우리는 전사적으로 OpenAI를 선택했습니다. 플랫폼을 표준화하는 것과 더불어, 계정 프로비저닝이 자동으로 되며 1일차부터 동작하도록 했습니다. IT 업무를 해봤거나 가까이서 본 사람에게 놀랄 일은 아니지만, 혁신적 범용 AI 도입의 많은 부분은… 사실 ‘계정 프로비저닝과 접근 제어’입니다. 이런 작은 디테일이 디테일에 깊이 파고들지 않으면 전체 계획을 너무 쉽게 탈선시킵니다.
엔지니어링 조직에는 Cursor와 Claude도 제공합니다. 다만 Claude 사용의 대부분은 AWS Bedrock을 통해 이루어지며, 이것으로 Claude Code를 구동합니다… 그리고 우리는 Claude Code를 꽤 많이 씁니다.
업계 전반에 더 많은 AI 툴 도입 압력이 있지만, 제 경험상 “AI 도구”의 상당수는 마케팅 피치에서 AI를 이야기하는 SaaS 벤더일 뿐입니다. 우리는 벤더 도입을 계속하고 있지만, 내부적으로 팀이 어떤 “AI 도구”가 의미 있는지 평가하도록 돕는 데도 노력해왔습니다.
채팅 및 IVR 툴링과 AI 툴링의 통합을 깊게 파고든 시간도 꽤 있지만, 그건 완전히 다른 글 주제입니다.
AI 도입을 측정하는 일은, 모든 측정 주제와 마찬가지로 위험합니다. 그럼에도 도구 도입을 측정하는 것은 올바른 질문을 찾는 데 매우 유용하다고 느꼈습니다. 왜 Cursor를 안 썼나요? Claude Code는요? 이런 질문은 파고들 가치가 큽니다. 저는 최소 월 1회는 사용 데이터를 보려고 하며, 특히 다음 두 질문에 집중합니다.
핵심적으로 저는 도구를 도입하지 않는 사람들은 ‘합리적 비도입자(rational non-adopters)’라고 믿습니다. 위에서 아래로의 명령(top-down mandate)보다, (겉으로 보이는) 저항을 이해하는 데 시간을 쓰는 것이 더 큰 효과가 있습니다. 대개는 교육 격차이고, 비교적 쉽게 메울 수 있습니다. 언젠가는 수익 체감(diminishing returns) 지점을 발견할 수도 있습니다. 예컨대 누군가가 AI 도구를 거부해서라든지, 혹은 AI 도구가 진짜로 유용하지 않아서라든지 말이죠. 하지만 아직 그 지점을 찾지는 못했습니다.
이후 몇 섹션은 내부 에이전트 구축에 관한 내용입니다. 핵심 구현은 다양한 HTTP 요청을 처리하는 단일 무상태(stateless) 람다로, Zapier와 비슷한 면이 있습니다. 현재 Python으로 구현되어 있고, 코드가 대략 3,000줄 정도이며, 그 상당 부분은 Slack 메시지 포맷팅 같은 자잘한 특이 케이스(oddities)에 쓰였습니다.
참고로 저는 원래 이걸 Zapier 안에서 해보려고 했습니다. 하지만 Zapier는 효과적으로 하기에 필요한 정밀함을 제공하지 못한다고 느꼈습니다. 또한 Zapier는 비엔지니어 대상 사용자에게 그다지 접근성이 좋지 않다고도 생각합니다.
플랫폼 엔지니어링에서 오랫동안 일한 사람으로서, 저는 아직도 “플랫폼을 만들면 사용자가 온다”를 믿고 싶습니다. 실제로 충분히 고통스러운 문제가 있다면 소수의 얼리어답터는 오긴 합니다. 예컨대 Uber의 서비스 마이그레이션(2014)이 그랬죠.
하지만 우리가 도입을 견인하는 데 효과적이었다고 느낀 방식은 그 반대에 가깝습니다. 진짜로 효과가 있었던 것은 플랫폼 엔지니어링과 구식 제품 엔지니어링의 교집합이었습니다.
내부적으로 성과가 있었던 프로젝트 예시는 다음과 같습니다.
AGENTS.md 파일을 통해 효과적으로 소프트웨어 작성이렇게 잘 된 프로젝트들의 공식은 “플랫폼을 만들면 사람들이 온다”의 반대였습니다. 대신 AI 에이전트 구축 경험과 AI 툴링 활용 경험이 있는 사람들이 깊게 파트너십을 맺고 진행해야만 진전이 있었습니다. 중요한(또는 운영에 준하는) 워크플로에서 효과적인 AI 도입을 위한 학습 곡선은 여전히 꽤 높습니다.
강력한 도구를 쓰는 에이전트는 복잡한 구성 문제를 가집니다. 첫째, 너무 많은 도구를 노출하면(특히 프롬프트 작성자가 제대로 이해하지 못하는 도구를 포함하면) 신뢰성 있는 워크플로를 만들기 매우 어렵습니다. 예를 들어 exit_early 커맨드는 에이전트를 조기에 종료할 수 있어 많은 경우 매우 유용하지만, 봇을 망가뜨리기도 쉽습니다. 마찬가지로 slack_chat 커맨드는 여러 채널에 게시할 수 있어 다양한 유용한 워크플로(예: 한 채널에서 나온 질문을 더 적절한 채널로 따뜻하게 핸드오프하는 것)를 지원하지만, 사람들을 스팸할 수도 있습니다. 둘째, 도구가 더 강력해질수록 복잡한 보안 시나리오를 유발할 수 있습니다.
이 둘을 해결하기 위해, 현재 우리는 코드를 리뷰하는 Git 저장소에 구성을 저장합니다. 아래는 JIRA 프로젝트 구성 예시입니다.
아래는 Slack 응답 봇 구성을 지정하는 예시입니다.
JSON 파일과 비교하면, 구성을 정적으로 타입 지정할 수 있고 시간이 지남에 따라 확장하기도 쉽습니다. 예를 들어 slack_chat을 확장해 특정 봇이 게시할 수 있는 채널을 제한하도록 만드는 것도 충분히 쉽습니다. 현재 대부분의 에이전트에서 Git 버전 관리 아래에 있지 않은 유일한 것은 프롬프트 자체인데, 이는 Notion에서 버전 관리됩니다. 하지만 민감한 시나리오에서는 특정 에이전트가 Git 관리 저장소 내 프롬프트를 사용하도록 강제할 수도 있습니다.
테스트, 린팅, 타입체킹을 통과하면 구성은 자동으로 배포됩니다.
좀 웃긴 이야기지만, 실제로 효과적인 프롬프트를 쉽게 작성하는 데 큰 방해가 된 것 중 하나는 @Will Larson 같은 표현을 쉽게 쓸 수 있게 하고, 이를 <@U12345> 같은 Slack의 적절한 식별자로(사용자/채널/사용자 그룹 등) 변환하는 일이었습니다. 같은 문제는 Jira 그룹, Notion 페이지와 데이터베이스 등에서도 존재합니다.
이는 프롬프트 중앙화가 왜 유용한지 보여주는 좋은 예입니다. 저는 유니크 식별자를 직접 뽑는 데 익숙해졌지만, 대부분의 사람들은 그렇지 않다는 것이 분명해졌습니다. 결국 Slack 해소를 위한 도구 세 가지로 귀결되었습니다. slack_lookup은 조회할 참조 목록을 받아 해소하고, slack_lookup_prefix는 특정 접두사로 시작하는 모든 Slack 엔터티를 찾습니다(예: 프롬프트에 목록을 하드코딩하지 않고 @oncall-로 시작하는 채널이나 그룹을 모두 가져오는 데 유용). slack_search_name은 문자열 거리(string-distance)로 잠재적 매치를 찾습니다(오타 처리에 유용).
이게 어리둥절하게 들린다면, 대체로 Slack이 이런 조회를 위한 적절한 API를 노출하지 않는 탓입니다. Slack API는 사용자/그룹/채널 조회에 ID를 쓰길 원하기 때문에, 조회를 하려면 이런 항목들을 위한 자체 캐시를 유지해야 합니다. 조회 자체도(특히 사용자) 지저분합니다. Slack 사용자는 최소 세 가지 방식으로 참조될 수 있습니다: user.profile.display_name, user.name, user.real_name. 이 중 일부만 설정된 사용자도 있습니다. 제가 아는 한 올바른 로직은 다음과 같습니다. 먼저 user.profile.display_name으로 매치를 찾고, 있으면 그것을 사용합니다. 그다음 user.name, 마지막으로 user.real_name을 같은 방식으로 처리합니다. 이 셋 중 하나라도 매치되는 첫 사용자를 그냥 선택해버리면, 어떤 경우에는 잘못된 사용자를 쓰게 됩니다.
LLM에 이름 해소 도구를 제공하는 것 외에도, 저는 각 응답마다 반환된 참조가 실제 항목을 가리키는지 확인하는 최종 필수 체크를 추가했습니다. 유효하지 않다면 어떤 것들이 무효인지 컨텍스트 윈도우에 주입하고, 엔터티 해소 도구만 사용 가능하도록 제한한 추가 에이전트 루프를 한 번 더 수행합니다. 터무니없게 느껴지지만, 이 지점에 이르러서야 일관되게 제대로 동작하기 시작했습니다.
참고로, 이 스크린샷들이 부끄러워서 오늘 Notion 페이지와 데이터베이스에 대해서도 Slack에 했던 것과 동일한 변경을 적용했습니다.
외래 엔터티 해소와 비슷하게, Slack의 mrkdwn 변형 마크다운과 JIRA의 Atlassian Document Format에서도 유사한 문제가 있습니다. 둘 다 엄격합니다.
이제 해당 API를 호출하는 도구들은 포맷팅에 대한 엄격한 지침을 포함합니다. 원래는 개별 프롬프트 안에 들어 있었지만, 모든 프롬프트에 계속 나타나기 시작해서, 프롬프트 작성자마다 이 문제를 이해하게 하기보다 에이전트 프레임워크 자체로 끌어올려야 한다는 걸 알았습니다.
제 추측으로는 엔터티 해소에 추가한 것과 유사한 검증 단계를 추가해야 할 것 같습니다. 그 전까지는 아주 드물지만 짜증나는 렌더링 이슈가 계속 남을 것입니다. 솔직히 저는 개인적으로 렌더링 이슈를 크게 신경 쓰지 않지만, 에이전트를 쓰는 다른 사람들에게는 불확실성을 만들기 때문에 해결이 필요하다고 생각합니다.
현재 모든 로그, 특히 도구 사용 로그는 두 곳으로 들어갑니다. 첫째, Datadog에 들어가 전체 로깅 가시성을 제공합니다. 둘째, 비엔지니어에게는 더 유용할 수 있는데, Slack 채널 #ai-logs로도 들어가며 어떤 도구가 (일부 잘린) 어떤 파라미터로 사용됐는지 가시성을 제공합니다.
장기적으로는 전용 내부 웹 UX로 노출되겠지만, 일반적으로 에이전트를 적극적으로 개발하는 사람들은 약간의 번잡함(cruft)을 감수할 의지가 있습니다. 반대로 에이전트를 직접 개발하지 않는 사람들은 로그를 보지 않고, 매번 완벽하게 동작하길 원합니다.
오늘날 제가 보기에 가장 큰 내부 기회는, 비엔지니어에게도 로컬에서 Claude Code를 실행하고 자신이 좋아하는 MCP 서버를 모두 꽂아 쓰는 것과 동등한 경험을 제공하는 방법을 찾는 것입니다. 저는 ChatGPT나 Claude.ai가 이를 제공해주길 바랐지만, 사실 거기까지는 못 갑니다. Claude Desktop이 거의 근접하지만, 우리가 내부 모든 사람이 쉽게 커스터마이즈하고 매일 사용할 수 있도록 허용할 도구를 찾는 관점에서는 설정이 다소 복잡합니다.
저는 아직 여기서의 ‘정답 도구’가 무엇인지 찾는 중입니다. 2년 뒤에도 존재할 거라고 어느 정도 확신할 수 있고, 아주 초기 단계 회사로 내부 데이터를 잔뜩 보내지 않아도 되는 좋은 제안이 있다면 듣고 싶습니다!
좋은 결론은 보통 전체 논지를 새로운 방식으로 비추는 강렬한 일화로 시작해야 한다고 하죠. 제가 그 기준을 충족할 수 있을지는 모르겠지만, 제게 가장 중요한 네 가지 아이디어는 다음과 같습니다.
다른 사람들은 무엇을 발견하고 있는지 궁금합니다!
안녕하세요. 저는 Will Larson입니다.
저에게 연락하고 싶다면, 제가 도울 수 있는 방법들이 여기 있습니다.
도서
저는 An Elegant Puzzle, Staff Engineer, The Engineering Executive's Primer, Crafting Engineering Strategy를 썼습니다.
뉴스레터
업데이트를 받고 싶다면 주간 이메일을 위해 구독하거나 RSS 피드를 팔로우하세요.
인기
최근
관련