사내 시스템에 붙자 데이터가 쏟아져 나오는 장면
📝 바쁘시면 이것만
새 업무를 맡으면 "지금까지 히스토리가 뭐지"부터 알아야 하는데, 저는 선임에게 묻는 대신 사내 시스템 API를 로컬 에이전트에 연결해서 직접 읽었어요.
사내 ERP에 API가 열려 있었어요. 담당자가 화면만 만들고 끝내지 않고 API 키 발급까지 붙여뒀더라고요
에이전트에 연결하니 대화로 물어보게 됐어요. "다시 부른 곳이 어디야?" 하면 답이 나와요
며칠 걸릴 전수 확인을 바로 끝냈어요
⚠️ 함정 하나 — 조회 도구에 "최대 몇 개까지 가져올지" 값이 있는데, 딱 그만큼만 가져와 놓고 그게 전체인 것처럼 답해요. 60건인 줄 알았는데 93건이었어요
🎯 이런 분들께
새 팀에 갔거나 새 업무를 맡아서 뭐부터 봐야 할지 모르겠는 분
사내에 시스템은 있는데 매번 담당자에게 물어보고 기다리는 분
사내 도구를 만들면서 API도 열어둘까 고민 중인 분
😫 Before — 물어볼 것을 모르는 상태
최근 기업교육 연관 프로젝트를 하게 되었는데, 제일 먼저 필요했던 건 하나였어요.
"지금까지 히스토리가 뭐지?"
그런데 이게 묘하게 어려워요. 담당자에게 물어보면 되는데, 뭘 물어야 할지를 알려면 이미 어느 정도 파악이 돼 있어야 하거든요. 순서가 꼬여 있는 거죠.
그래서 처음엔 이렇게 했어요.
"지금까지 진행한 교육 건들 자료 좀 볼 수 있을까요?"
이렇게 보내놓고 회신을 기다렸어요. 상 대도 자기 일이 있으니 바로 오지 않고요. 기다리는 동안 저는 할 수 있는 게 없었어요.
🛠️ 발견 — API가 열려 있었어요
그러다 알게 된 게 있어요. 담당자가 사내 ERP를 직접 만들어 쓰고 있었어요. 개발자가 아니라 업무 담당자가요. 여기까지도 요즘은 종종 보는 일인데, 제가 놀란 건 다음이었어요.
화면에서 끝내지 않고 API 키 발급까지 붙여뒀더라고요.
예전 사내 시스템은 결과물이 화면이었어요. 사람이 보는 게 전부였죠. 그런데 이건 처음부터 사람 아닌 것도 쓸 걸 전제하고 만들어져 있었어요. 도구를 만들 때 "누가 쓸까"의 답에 에이전트가 들어가 있는 거예요.
화면까지 만든 시스템과 API까지 연 시스템 비교
🔧 연결 — 대화로 물어보게 됐어요
로컬 에이전트에 붙였어요. MCP로 연결하니 제 작업 세션에 도구가 그대로 올라오더라고요. 계정·프로젝트·차수·강사 배정·정산 같은 것들이요.
💡 MCP를 몰라도 됩니다. 쉽게 말하면 에이전트가 쓸 수 있는 콘센트 규격이에요. 시스템 쪽에 이 규격으로 구멍을 뚫어두면, 에이전트가 플러그를 꽂고 그 시스템을 읽습니다.
붙이고 나서 달라진 건 딱 하나예요. 화면을 뒤지는 게 아니라 물어보게 됐어요.
"지금까지 진행한 프로젝트 전부 보여줘"
"같은 회사에서 다시 부른 곳이 어디야?"
"중간에 엎어진 건은?"
✅ Before / After
Before
자료를 요청하고 회신을 기다림
뭘 물어야 할지 몰 라서 질문이 두루뭉술함
기다리는 동안 진도가 안 나감
After
궁금한 걸 바로 확인
며칠 걸릴 전수 확인을 대화로 — 프로젝트 93건을 하나씩 열어보지 않고
다시 부른 곳과 한 번으로 끝난 곳을 갈라서 봄
실주 사례를 실물로 확인 — 왜 엎어졌는지가 기록에 남아 있었어요
💬 진짜 좋았던 건 따로 있어요
숫자를 빨리 본 것도 좋았지만, 제가 제일 체감한 건 이거예요.
물어볼 일이 없어진 게 아니라, 물어볼 게 정확해졌어요.
전에는 자료를 좀 볼 수 있을까요 정도밖에 물을 게 없었어요. 뭘 모르는지를 모르니까요.
직접 열어보고 나니 질문이 달라졌어요. 원장을 보면 어떤 칸이 채워져 있고 어떤 칸이 비어 있는지가 보이거든요. 그러면 "이 칸은 누가 언제 채우나요" 같은 걸 물을 수 있어요. 제가 어림으로 알던 것과 기록이 어긋나는 대목도 눈에 들어오고요.
이렇게 물으면 상대도 답하기 쉬워요. 자료를 찾아서 보내주는 게 아니라 아는 걸 말해주면 되니까요. 실제로 이런 것들이 정기미팅 안건이 됐어요.
⚠️ 함정 — 숫자를 그대로 믿으면 안 돼요
60이라고 적힌 종이를 든 뽀짝이, 파이프 너머에 못 본 것들이 남아 있다
정직하게 하나 적을게요. 전체 히스토리를 파악하는 중 숫자 하나가 틀렸어요.
전체 프로젝트를 세어봤더니 60건이 나왔어요. 그런데 나중에 다시 확인하니 93건이더라고요.
원인은 조회 도구의 한도였어요. 목록을 불러오는 도구에는 "한 번에 최대 몇 개까지 가져올지" 정하는 값이 붙어 있어요. 이 도구는 그 값이 기본 30개예요.
문제는 한도를 넘는 건 아예 안 돌아온다는 거예요. 그런데 도구가 "뒤에 더 있습니다"라고 말해주지 않아요. 잘린 목록이 그냥 온전한 목록처럼 도착해요.
그래서 에이전트는 돌아온 걸 세서 "60건입니다" 하고 답했고, 저는 그게 전부인 줄 알았어요. 에러도 안 나고 문장도 깔끔하니까 의심할 이유가 없었거든요. 60은 데이터의 개수가 아니라 한도였어요. 나중에 한도를 훨씬 크게 잡고 다시 부르니 93건이 나왔어요.
실제 93건이 조회 한도에서 60건으로 잘리고, 되물어 93건을 회복하는 흐름
만약 60건으로 계속 분석했으면 비율이 전부 틀어졌을 거예요. 다시 부른 고객의 비율도, 업종 분포도요.
한도가 있는 도구와 없는 도구가 섞여 있어요
나중에 도구를 하나씩 열어보고 알았는데, 전부 한도가 걸려 있는 게 아니었어요.
프로젝트 목록, 메모 이력 → 한도 있음
거래처 목록, 강사 목록, 견적서, 세금계산서 → 한도 없음. 전부 옴
건수가 계속 늘어나는 것에만 한도를 걸어둔 거예요. 합리적인 설계죠.
그런데 이게 저한테는 함정이 됐어요. 같은 날 나란히 뽑은 숫자 두 개 중 하나는 맞고 하나는 틀렸거든요. 거래처 수는 한도 없는 도구에서 나와서 정확했고, 프로젝트 수는 한도 있는 도구에서 나와서 잘렸어요. 저는 둘 다 똑같이 믿고 있었고요.
💡 "이 시스템은 믿을 만하다"는 판단은 시스템 단위로 하면 안 돼요. 도구마다 성질이 다릅니다. 숫자를 쓰기 전에 그 숫자가 어느 도구에서 나왔는지를 봐야 해요.
그런데 한도를 모르면 어떡하죠
여기서 좀 이상하죠. 한도는 도구 안쪽 설정이라 쓰는 사람은 볼 일이 없어요. "프로젝트 몇 건이야?" 하고 물었을 뿐인데 한도가 몇인지 어떻게 알겠어요. 돌아온 건 60건입니다라는 문장 하나뿐인걸요.
그래서 한도를 몰라도 쓸 수 있는 방법 세 개를 씁니다.
1. 숫자가 딱 떨어지면 의심해요
30, 50, 100처럼 반듯한 수가 나오면 한도일 가능성이 커요. 실제 데이터는 이렇게 안 떨어지거든요. 93은 딱 봐도 세어서 나온 수처럼 생겼는데, 60은 누가 정해준 수처럼 생겼잖아요. 이 감각 하나로 꽤 걸러집니다.
2. 그냥 되물어요
"그게 전부야? Limit 걸린 거 아니야?"
이 한 마디면 됩니다. 에이전트는 자기가 쓰는 도구의 설정을 볼 수 있어서 "한도가 30이었고 지금 30건이 왔으니 더 있을 수 있다"고 답해줘요. 제가 몰라도 되고, 아는 쪽에 물으면 되는 거예요.
3. 전체를 셀 때는 미리 못을 박아요
"빠짐없이 전부 세줘. 한도에 걸리면 한도를 올려서 다시 세고."
숫자를 근거로 뭘 판단할 거라면 처음부터 이렇게 시키는 게 편해요.
💡 모르는 걸 아는 척할 필요가 없어요. 에이전트가 답을 주면 "그거 전부야?" 한 번만 되물으면 됩니다. 이 질문 하나가 잘못된 숫자를 대부분 걸러줘요.
이 예시는 저희 ERP 쪽 이야기고 계속 개선 중이예요. 목록을 주는 API는 보통 "뒤에 더 있다"를 같이 알려주거든요. 그러니 다른 시스템을 붙이면 이 함정은 안 만날 수도 있어요.
다만 한도가 있다는 것 자체는 어디나 마찬가지예요. 그리고 원래 API가 알려주던 신호가, 에이전트가 읽기 좋은 문장으로 바뀌는 과정에서 빠지는 경우를 종종 봤어요. 그래서 개수를 세는 습관은 시스템이 바뀌어도 그대로 가져갈 만해요.
🚀 다음에 해볼 것
다른 사내 시스템도 같은 식으로 붙여볼 생각이에요. 화면으로만 보던 것들이요
숫자를 받으면 "그거 전부야?"를 붙이는 습관을 들이려고요
