🧑🏻💻 Ep.16 | AI에게 도구를 쥐여 준다는 것
지난주에 클로드한테 이렇게 부탁한 적이 있습니다. "어제 새벽 배포 로그 좀 같이 보자."
돌아온 답은 이랬어요. "저는 그 시스템에 접근할 수 없습니다."
조금 멋쩍었습니다. 이렇게 똑똑한 모델이 정작 우리 회사가 뭘 어떻게 굴리는지는 하나도 모릅니다. 생각해보면 당연합니다. 우리 사내 위키도, 모니터링 대시보드도, 배포 파이프라인도 학습 데이터에 들어 있을 리가 없으니까요.
AI를 똑똑하게 만드는 것과, AI에게 우리 일을 시킬 수 있게 만드는 건 별개의 문제입니다.
1. 똑똑한 것과 일할 수 있는 것
AI는 일반적인 지식을 정말 많이 압니다. 정렬 알고리즘도 알고, React 훅도 알고, Kafka 컨슈머 설정도 줄줄 설명합니다. 그런데 우리 결제 서버가 지금 살아 있는지, 어젯밤 어떤 PR이 머지됐는지, 이 고객 주문이 어느 단계에서 막혀 있는지는 모릅니다. 이건 지식이 아니라 지금 이 순간의 상태니까요. 학습으로는 알 도리가 없습니다. 그래서 아무리 좋은 모델이라도 우리 일 앞에서는 종종 멈춥니다. 똑똑한데 손이 없는 셈이죠.
2. 도구를 쥐여준다는 것
해결책은 의외로 단순합니다. AI가 직접 확인할 수 있게 도구를 쥐여주면 됩니다.
신입을 떠올리면 쉽습니다. "결제 서버 상태 좀 봐줘"라고 부탁하려면, 먼저 모니터링 대시보드 접근 권한부터 줘야 합니다. 권한이 없으면 아무리 유능해도 확인할 방법이 없죠. AI도 똑같습니다.
요즘은 MCP(Model Context Protocol) 같은 표준이 나오면서 이 연결이 한결 쉬워졌습니다. 대시보드, 사내 위키, 이슈 트래커, DB를 한 번 꽂아두면 AI가 직접 조회해서 답합니다. "접근할 수 없어요"가 "확인해보니 이렇네요"로 바뀌는 순간입니다.
MCP는 "AI에게 우리 시스템을 연결하는 표준 콘센트"에 가깝습니다.
3. 직접 만든다는 것
연결만 하는 게 아니라, 필요한 도구를 직접 만들 수도 있습니다. 거창할 건 없어요. 저도 처음엔 이런 작은 것부터 시작했습니다.
✔️ 주문 ID를 넣으면 현재 상태를 돌려주는 함수
✔️ 특정 서비스의 최근 에러 로그를 가져오는 함수
✔️ 스테이징에 테스트 배포를 거는 함수
이 함수들을 AI가 호출할 수 있게 등록해두면, AI가 필요할 때 알아서 골라 씁니다. 사람이 매번 로그를 복붙해서 떠먹여 줄 필요가 없어지죠. 도구 하나를 잘 만들어두면, 그걸 쓰는 모든 대화가 한 단계씩 똑똑해집니다.
4. 손을 쥐여줬다면, 닿는 범위도 정해야 한다
여기서 새로운 고민이 생깁니다. AI에게 손을 쥐여줬으면, 그 손이 무엇까지 만질 수 있는지도 정해야 합니다.
✔️ 조회만 시킬지, 변경도 시킬지
✔️ 운영 DB에 직접 붙일지, 읽기 복제본만 열어줄지
✔️ 배포를 바로 걸게 할지, 사람 승인 단계를 둘지
조회 도구는 마음 편히 줘도 됩니다. 문제는 삭제하거나 배포하는 도구예요. AI가 "그럴듯하게 틀릴" 수 있다는 건 이 시리즈에서 여러 번 이야기했는데, 그 틀린 판단이 운영 시스템을 건드리면 곤란해집니다.
무엇을 할 수 있게 할지보다, 무엇을 못 하게 막을지가 더 중요할 때가 많습니다. 권한 설계가 도구 설계의 절반입니다.
5. 도구의 설명이 곧 사용 설명서다
재밌는 점이 하나 있습니다. AI는 도구의 이름과 설명만 보고 그걸 언제 쓸지 판단합니다.
getData라고만 적혀 있고 설명이 한 줄도 없으면, AI는 그게 무슨 데이터인지 모릅니다. 엉뚱한 데서 호출하거나, 정작 써야 할 때 안 씁니다. 반대로 이렇게 적혀 있으면 이야기가 달라집니다."이 도구는 주문 ID로 결제 상태를 조회한다. 환불 여부는 알 수 없으니 환불 조회 도구를 따로 써라."
사람을 위한 API 문서와 똑같습니다. 다만 AI는 그 문서를 매번 실제로 읽고 따른다는 차이가 있죠. 그동안 미뤄두던 "제대로 된 도구 설명"을, 이제는 안 쓰면 바로 티가 납니다. (덕분에 저는 오히려 문서를 더 챙기게 됐습니다.)
6. 도구를 나누는 일은 설계에 가깝다
곰곰이 보면, 도구를 만드는 건 "이 일을 어떤 단위로 쪼갤까"를 정하는 일입니다.
주문 조회와 환불 조회를 한 도구로 묶을까 나눌까, 배포를 한 번에 걸까 빌드와 릴리스를 나눌까, 검색은 키워드만 받을까 필터까지 받을까. 전부 좋은 함수를 설계하고 좋은 API 경계를 긋는 감각의 문제입니다. 그러니 AI에게 도구를 잘 쥐여주는 사람은, 사실 원래부터 일을 잘 쪼개던 사람인 경우가 많습니다.
7. 경계는 사람이 긋는다
도구를 주면 AI가 할 수 있는 일이 폭발적으로 늘어납니다. 그래도 그 도구로 무엇을 하게 할지, 어디까지 맡길지는 사람이 정합니다. 조회는 맡기고 결정은 가져오고, 초안은 맡기되 배포 버튼은 직접 누르는 식으로요.
AI를 더 잘 쓰는 다음 단계는 "더 좋은 프롬프트"보다 "더 좋은 도구"일 때가 많습니다. 그리고 그 도구의 경계를 설계하는 일은, 도구가 아무리 좋아져도 엔지니어의 몫으로 남습니다.
🌱 도구를 만들고 자동화를 고민하는 개발자들이 모인 곳, 루퍼스
AI를 똑똑하게 쓰는 다음 단계는 우리 일에 맞는 도구를 직접 만드는 것입니다. 그 과정에서 부딪히는 설계와 권한, 안전에 대한 고민을 함께 나누고 싶다면 루퍼스에서 그 여정을 시작해보세요 🙌
AI 시대에도 결국 중요한 건 생각하는 힘과 성장하는 환경이라고 믿습니다.
루퍼스에는 성장에 진심인 800+명의 크루가 함께하고 있습니다. 현업에서 부딪히는 고민과 경험을 나누며 함께 성장하는 크루들의 이야기. 전액 기부 강의 그리고 다양한 오프라인 네트워킹까지! 루퍼스는 개발자를 위한 지속 가능한 성장을 만들어 갑니다.
📢 LOOPERS의 소식이 궁금하다면?
Share article