회사 내 AI 도입을 이끄는 법

게시일: 2025년 12월 17일 | 원문 작성일: 2025년 12월 7일 | 저자: Will Larson | 원문 보기

• • •

들어가며

저는 지난 18개월 동안 사내 “AI 도입”을 진행해왔어요. 솔직히 말하면 LLM 도구와 에이전트 도입이죠. 이건 요즘 시대 모든 엔지니어링 리더에게 최소한 사이드 퀘스트 정도는 되는 문제라고 생각해요.

이 글은 “이렇게 해야 한다”는 권고가 아니에요. 제가 문제에 어떻게 접근했고, 반복적인 시도를 통해 무엇을 배웠는지에 대한 작업 노트예요. 읽을수록 점점 구체적인 내용이 나올 거예요. 끝부분에서는 “에이전트가 사람이 읽기 쉬운 Slack 엔티티 표현을 mrkdwn 포맷의 올바른 ID로 변환하게 만드는 법” 같은 얘기까지 나올 거예요.

• • •

사전 작업: 직관 쌓기

기술자로서 팀에 당연히 해야 할 일 중 하나는, 새로운 도구가 어떻게 작동하고 어떻게 작동하지 않는지 직접 시간을 들여 익히는 거예요. AI 도입도 마찬가지예요.

저는 Chip Huyen의 AI Engineering을 읽는 것으로 시작했고, 그다음엔 범위가 명확한 몇 가지 프로젝트에 뛰어들었어요:

• Claude Code로 간단한 에이전트 플랫폼 직접 구축하기
• 제 블로그 글을 검색하는 간단한 MCP 만들기
• Notion 문서에 코멘트를 다는 에이전트 만들기

각 프로젝트는 2–10시간 정도 걸렸는데, 정말 많은 것이 명확해졌어요. 특히 도구 사용(tool use)은 직접 구현해보기 전까지는 마법처럼 느껴졌는데, 막상 만들어보니 논리적으로 이해하고 추론할 수 있는, 전혀 마법이 아닌 것이 되었죠.

• • •

AI 도입 전략

Imprint의 AI 도입 접근법은 전략 테스팅이에요. 몇 가지 목표를 정하고, 초기 접근법을 선택한 다음, 세부사항에서 빠르게 반복하면서 정말로 작동하는 접근법을 찾아가는 거죠. 시니어 리더가 세부사항을 직접 파고드는 게 요즘 시대 몇 안 되는 대비책이에요.

입사 직후 경영진과 함께 AI 도입 전략 초안을 작성했어요. 약간의 논의 끝에 세 가지 핵심 원칙을 정했어요:

원문 보기

Imprint의 AI 도입 전략 초안 (클릭하여 원문/번역 전환)

1. 도입의 길을 닦아라 — 도구 접근 권한을 명시적으로 요청해야 하는 것처럼 도입을 가로막는 장애물을 제거하세요. AI 도입에 대한 내부와 업계의 열기가 있으니, 팀을 믿어야 해요. 채택이 안 되면 회의적으로 바라보기보다 더 쉽게 만드는 데 집중하세요.
2. 도입 기회는 어디에나 있다 — 엔지니어링이나 고객 서비스에만 국한되지 않아요. AI의 혜택을 회사 전체로 확산하려면, 모든 팀에 적용 가능한 접근법이 필요해요.
3. 시니어 리더십이 앞장선다 — 우리가 하는 일이 정말 유용한지 확인하기 위해서요. 측정 지표에 함몰되지 않으려면요.

대외적 이미지는 모든 일의 핵심 부분이지만, 거의 모든 흥미로운 일은 이미지와 현실이 만나는 지점에서 일어나요. 위 원칙들은 그 교차점을 지원하기 위한 거예요.

• • •

팁과 트릭 문서화하기

도입을 위한 첫 번째 단계는 사내의 팁과 트릭 사례들을 하나의 Notion 데이터베이스에 모으는 것이었어요. “이게 팁으로 적합한가?”에 대해 매우 넓은 기준을 적용했어요. 다양한 기능 부서에 걸친 여러 사용 사례를 보여주는 게 유용하고 영감을 준다고 믿었거든요.

원문 보기

AI 팁과 트레이닝을 정리한 Notion 데이터베이스 (클릭하여 원문/번역 전환)

회사 전체의 기여로 계속 확장됐고, 이제는 사람과 봇 모두에게 AI 도구로 문제에 접근하는 방법을 제안하는 유용한 리소스가 됐어요.

• • •

프롬프트 중앙화하기

우리 접근법의 핵심 신념 중 하나는, 프롬프트를 회사 내에서 발견 가능하게 만드는 게 엄청나게 가치 있다는 거예요. 발견 가능성은 다섯 가지 문제를 해결해요:

1. 프롬프트가 할 수 있는 일에 대한 가시성 — 다른 사람들이 비슷한 시나리오에서 영감을 받을 수 있어요
2. 좋은 프롬프트가 어떻게 생겼는지 보여주기 — 다른 사람들이 자신의 프롬프트를 개선할 수 있어요
3. 프롬프트 간 재사용 가능한 섹션의 저장소 — 기존 “Jira 이슈 분류 프롬프트”를 복사해서 새 프로젝트에 적용할 수 있어요
4. 프롬프트는 한 사람의 것이 아닌 팀의 공동 자산 — 헬프데스크 팀 누구나 프롬프트를 개선할 수 있어요. Git이나 GitHub에 익숙하지 않아도요
5. 반복 패턴에서 누락된 도구 발견 — 프롬프트에서 같은 내용이 계속 반복되면, 그건 도구가 빠졌거나 쓰기 어렵다는 신호예요. 예를 들어 초기 프롬프트들에서 Slack 사용자와 채널 지정 방법에 대한 혼란이 많았는데, 저는 우회하는 데 익숙해졌지만 다른 사람들은 그렇지 않았어요

핵심 접근법은 모든 에이전트의 프롬프트를 회사 전체가 읽을 수 있는 단일 Notion 데이터베이스에 저장하는 거예요. 대부분의 프롬프트는 누구나 편집 가능하지만, 일부는 편집 제한이 있어요.

거의 모든 프롬프트 끝에 “생성된 메시지에 이 프롬프트 링크를 포함하라”는 지시가 있어요. 이렇게 하면 별로인 응답에서 그 응답을 만든 프롬프트로 쉽게 이동해서 고칠 수 있죠.

원문 보기

중앙 데이터베이스에 저장된 라우팅 프롬프트 예시 (클릭하여 원문/번역 전환)

원문 보기

인프라 관련 프롬프트 예시 (클릭하여 원문/번역 전환)

• • •

표준 플랫폼 채택

팁과 프롬프트 수집 외에도, AI 도입의 다음 명백한 단계는 회사 전체에서 사용할 표준 AI 플랫폼을 정하는 거예요.

우리는 모든 직원에게 OpenAI를 제공하기로 했어요. 플랫폼 표준화와 함께, 계정 프로비저닝을 자동화하고 첫날부터 접근 가능하게 만들었어요. IT 근처에서 일해본 사람이라면 놀랍지 않겠지만, 혁명적인 범용 AI 도입의 상당 부분은… 결국 계정 프로비저닝과 접근 제어예요. 이런 사소한 것들이 제대로 안 되면 큰 계획 전체가 무너질 수 있죠.

엔지니어링 내에서는 Cursor와 Claude도 제공해요. 그렇긴 한데, Claude 사용의 대부분은 AWS Bedrock을 통해 이루어지고, Claude Code를 구동하는 데 사용해요. 그리고 Claude Code는 정말 많이 써요.

• • •

측정

AI 도입 측정은, 모든 측정 주제가 그렇듯이, 복잡해요. 전체적으로 봤을 때, 도구 도입 측정은 올바른 질문을 찾는 데 매우 유용하다는 걸 알게 됐어요.

왜 Cursor를 안 쓰세요? Claude Code는요? 뭐든요? 이런 질문들을 파고드는 게 정말 흥미로워요. 저는 최소 한 달에 한 번 사용 데이터를 보면서 두 가지 질문에 집중해요:

1. 파워 유저들은 실제로 뭘 하고 있나? 왜 유용하다고 느끼나?
2. 저사용자나 미사용자들은 왜 도구를 안 쓰나? 어떻게 해결해줄 수 있나?

대부분의 경우 쉽게 해결할 수 있는 교육 격차라고 생각해요. 언젠가는 효과가 떨어지는 시점에 도달해서, AI 도구를 거부하는 사람들 때문에, 혹은 AI 도구가 실제로 유용하지 않아서 진전이 막히는 때가 올 수도 있겠지만, 아직 그 시점은 찾지 못했어요.

• • •

내부 에이전트 구축

다음 몇 섹션은 내부 에이전트 구축에 대한 내용이에요. 핵심 구현은 Zapier와 비슷하게 다양한 HTTP 요청을 처리하는 단일 상태 없는 람다(stateless lambda)예요. 현재 Python으로 구현되어 있고, 대략 3,000줄 정도 되는데 상당 부분이 Slack 메시지 포맷팅 같은 자잘한 것들에 할애되어 있죠.

참고로 처음에는 Zapier 안에서 이걸 하려고 했는데, 제가 원하는 수준의 정밀함을 제공하지 못한다는 걸 알게 됐어요. 또한 Zapier는 비엔지니어에게도 그다지 접근하기 쉽지 않다고 생각해요.

에이전트 도입을 이끈 것들

플랫폼 엔지니어링에서 오래 일한 사람으로서, 저는 여전히 “플랫폼을 만들면 사용자가 올 것이다”를 믿고 싶어요. 실제로 문제가 충분히 고통스럽다면 소수의 얼리 어답터는 와요.

하지만 실제로 도입을 이끈 건 정반대였어요. 정말 효과가 있었던 건 플랫폼 엔지니어링과 전통적인 프로덕트 엔지니어링의 교차점이에요:

1. (프로덕트 엔지니어링) 많은 문제가 있거나 잠재적 영향이 큰 워크플로우를 찾는다
2. (프로덕트 엔지니어링) 도메인 전문가와 밀접하게 협력해서 첫 버전을 작동하게 만든다
3. (플랫폼 엔지니어링) 작동하는 솔루션을 사용하는 팀이 확장할 수 있게 한다
4. (둘 다) 도입을 문제-솔루션 핏의 지표로 모니터링한다

내부에서 실제로 견인력을 얻은 프로젝트들의 예시:

• 테스트, 타입체킹, 린팅 사용을 안내하는 효과적인 AGENTS.md 파일로 소프트웨어 작성하기
• 챗과 IVR을 통한 초기 고객 질문 처리
• 문제를 해결하거나, 답변을 제공하거나, 올바른 응답자에게 알리는 챗봇 라우팅
• 들어오는 티켓에 대한 이슈 분류: 태깅하고 적절한 팀에 할당
• 일상적인 컴플라이언스 및 법률 질문에 대한 실시간 초기 피드백 제공
• 다양한 소스(Git 커밋, Slack 메시지 등)를 끌어와서 주간 우선순위 업데이트 작성

이 모든 성공한 프로젝트에서 공식은 “플랫폼을 만들면 알아서 오겠지”의 반대였어요. AI 에이전트를 구축하고 AI 도구를 사용하는 경험이 있는 사람들의 깊은 파트너십이 필요했어요. 중요하거나 프로덕션 수준의 워크플로우에서 효과적인 AI 도입의 학습 곡선은 여전히 의미 있게 높아요.

에이전트 설정

강력한 도구를 사용하는 에이전트에는 복잡한 설정 문제가 따라와요. 첫째, 너무 많은 도구를 노출하면—특히 프롬프트 작성자가 제대로 이해하지 못하는 도구들—신뢰할 수 있는 워크플로우를 만들기가 매우 어려워져요. 둘째, 도구가 더 강력해질수록 복잡한 보안 시나리오가 생길 수 있어요.

이 두 가지를 해결하기 위해, 현재 설정을 코드 리뷰되는 Git 저장소에 저장해요. JSON 파일 대비 정적 타입 지정이 가능하고, 시간이 지나면서 쉽게 확장할 수 있어요. 테스트, 린팅, 타입체킹을 통과하면 설정이 자동으로 배포돼요.

원문 보기

Jira 에이전트 설정 예시 (Python) (클릭하여 원문/번역 전환)

원문 보기

Slack 에이전트 설정 예시 (Python) (클릭하여 원문/번역 전환)

외래 키 해결

좀 우습게 들릴 수 있지만, 실제로 효과적인 프롬프트 작성을 크게 방해한 것 중 하나는 @Will Larson 같은 것을 쉽게 써서 그게 <@U12345> 같은 적절한 Slack 식별자로 변환되게 만드는 거였어요. 같은 문제가 Jira 그룹, Notion 페이지와 데이터베이스 등에도 존재해요.

이게 프롬프트 중앙화가 유용한 좋은 예시예요. 저는 고유 식별자를 직접 찾아오는 데 익숙해졌지만, 대부분의 다른 사람들은 그렇지 않다는 게 분명해졌어요. 결국 Slack 해결을 위한 세 가지 도구를 만들었어요:

• slack_lookup — 조회할 레퍼런스 목록을 받아서 처리
• slack_lookup_prefix — 특정 접두사로 시작하는 모든 Slack 엔티티 찾기 (예: @oncall-로 시작하는 모든 채널이나 그룹)
• slack_search_name — 문자열 거리를 사용해서 잠재적 매치 찾기 (오타 처리에 유용)

이게 복잡하게 들린다면, Slack이 이런 종류의 조회를 위한 API를 제공하지 않기 때문이에요. Slack API는 ID를 사용해서 사용자, 그룹, 채널을 조회하길 원해서, 조회를 수행하려면 이런 아이템들의 자체 캐시를 유지해야 해요.

LLM에 이름 해결 도구를 제공하는 것 외에도, 각 응답에 대해 반환된 레퍼런스가 실제 아이템을 참조하는지 확인하는 최종 필수 체크가 있어요. 만약 아니라면, 어떤 것들이 유효하지 않은지 컨텍스트 윈도우에 주입하고 엔티티 해결 도구만 사용 가능한 상태로 추가 에이전트 루프를 수행해요. 이게 황당하게 느껴지지만, 바로 이 지점에서야 비로소 일관되게 작동하기 시작했어요.

포맷팅

외래 엔티티 해결과 비슷하게, Slack의 mrkdwn 마크다운 변형과 Jira의 Atlassian Document Format에도 비슷한 문제가 있어요: 둘 다 엄격해요.

그 API들을 호출하는 도구들은 이제 포맷팅에 대한 엄격한 지시를 갖고 있어요. 이전에는 개별 프롬프트에 포함되어 있었는데, 모든 프롬프트에 나타나기 시작해서 에이전트 프레임워크 자체로 가져와야 한다는 걸 알았어요. 모든 프롬프트 작성자가 이 문제를 이해하도록 강제하는 대신요.

로깅과 디버깅

현재 모든 로그, 특히 도구 사용은 두 곳으로 보내져요. 첫째, 전체 로깅 가시성을 위해 Datadog으로 가요. 둘째, 그리고 비엔지니어에게 아마도 더 유용하게, #ai-logs Slack 채널로 보내서 어떤 도구가 어떤 (잠재적으로 잘린) 파라미터로 사용되었는지 가시성을 만들어요.

장기적으로는 전용 내부 웹 UX를 통해 노출될 것 같지만, 일반적으로 에이전트를 적극적으로 개발하는 사람들은 약간의 불편함을 기꺼이 감수해요. 비슷하게 에이전트를 직접 개발하지 않는 사람들은 별로 신경 안 써요. 그들은 매번 완벽하게 작동하길 원하고, 로그를 보는 데 시간을 쓰지 않아요.

• • •

가장 큰 남은 격차

제가 보는 가장 큰 내부 기회는, 비엔지니어들이 자신이 좋아하는 MCP 서버들을 다 연결한 Claude Code를 로컬에서 실행하는 것과 동등한 경험을 얻게 하는 방법을 찾는 거예요.

ChatGPT나 Claude.ai가 이걸 제공해주길 바랐는데, 아직 거기까지는 도달하지 못했어요. Claude Desktop이 가깝지만, 내부의 모든 사람이 쉽게 커스터마이즈하고 매일 사용할 수 있는 도구를 찾는 관점에서 보면 설정이 다소 복잡해요.

여전히 여기에 맞는 도구를 찾고 있어요. 2년 후에도 존재할 거라고 어느 정도 확신할 수 있고, 아주 초기 단계 회사에 많은 내부 데이터를 보내지 않아도 되는 좋은 제안이 있다면 알려주세요!

• • •

다음은 뭘까?

다른 분들은 어떤 걸 발견하고 계신지 궁금해요!