[MCP] 2주차 Day 1 — 이름이 절반이다
주차 주제: 도구 설계 | 제조 사례: 이름을 바꿔 71% 가 94% 가 된 자리
오늘의 목표: 모델이 고를 수 있는 이름을 짓는 법을 익힌다.
소요 시간: 30분
1. 한 문장으로
모델은 이름과 설명만 보고 고릅니다. ★· 안을 못 봅니다 ★
· 불러 보고 고르지 않습니다
· 이름이 거의 전부입니다 ★2. ★ 좋은 이름의 조건 넷
① 무엇을 하는지가 들어 있습니다 ★
조회 · 검색 · 생성 · 변경
② 무엇에 대한 것인지 ★
품목 · 수주 · 실적
③ 비슷한 것과 갈립니다 ★
품목검색 vs 품목상세
④ 우리 말입니다 ★
현장이 쓰는 말③이 자주 무너집니다. ★3. ③ 갈리지 않는 이름들
조회 · 가져오기 · 검색 · 찾기 · 목록 ★다섯이 비슷하게 들립니다. ★그래서 이렇게 되면 품목조회 · 품목검색 · 품목목록 · ★
품목찾기 · 품목가져오기 ★모델이 못 고릅니다. ★그리고 대개 맨 앞 것을 부릅니다. ★4. 동사를 정해 두세요
회사 안에서 동사 목록을 고정하세요. ★ 검색 조건으로 여러 건을 찾습니다 ★
상세 하나를 자세히 봅니다 ★
목록 전부 또는 최근 것을 봅니다 ★
집계 숫자를 냅니다 ★
요청 쓰기를 요청합니다 (4주차) ★다섯이면 대개 됩니다. ★그리고 이 목록을 설명에도 적으세요. ★ "검색은 여러 건, 상세는 한 건이다." ★5. ④ 우리 말로
나쁜 것
getItemMaster · fetchSO · queryPRD ★ 좋은 것
품목검색 · 수주상세 · 생산실적집계 ★왜
· 모델이 질문의 말과 잇습니다 ★
사용자: "품목 좀 찾아 줘"
→ 품목검색 ★
· 사람이 로그를 읽을 수 있습니다 ★
· 토큰도 짧습니다 ★그리고 온톨로지 과정의 개념 이름과 ★
맞추세요. 개념 「품목」 → 도구 「품목검색」 ★6. 이름이 길어도 됩니다
품목검색 ★
vs
사용중인품목을이름이나품번으로검색 ★후자가 나을 때가 있습니다. ★· 비슷한 도구가 여럿일 때 ★
· 조건이 이름에 있으면 안 헷갈립니다 ★다만 너무 길면· 읽기 어렵고 ★
· 토큰이 듭니다기준 — 한 줄에 들어가면 됩니다. ★7. 제조 현장의 실제
어느 업체, 도구를 7개로 줄였는데도
엉뚱한 도구를 불렀습니다. ★ 맞는 도구를 고른 비율 71% ★이름을 보니 getItem · getItemDetail · searchItem · ★
listItems · findItemByCode ★다섯이 다 품목 조회였습니다. ★그리고 사실은· getItem 과 getItemDetail 이 같은 일 ★
· listItems 는 안 쓰는 것 ★
· findItemByCode 는 searchItem 의 일부 ★정리한 뒤 품목검색(키워드, 옵션) ★
품목상세(품번[]) ★ 둘이 됐습니다. ★ 맞는 도구 고르는 비율 71% → 94% ★그리고 남은 6% 를 보니 · 「검색」 을 써야 할 때 「상세」 를 부름 ★
· 품번을 모르는데 상세를 부름 ★설명을 고쳐 98% 가 됐습니다. (내일) ★8. ★ 「같은 일을 하는 도구」 를 찾으세요
도구 목록을 놓고 "이 둘의 차이를 한 문장으로 말할 수 있나" ★못 하면 합치세요. ★· 인자로 가를 수 있으면 하나로 ★
품목검색(키워드, 정확일치=true) ★9. 오늘 해 볼 것 (15분)
① 도구 이름을 나열하세요
1. ________ 2. ________ ★
3. ________ 4. ________② 비슷한 것을 묶으세요
이 둘의 차이를 한 문장으로
____________ vs ____________ ★
차이 ____________________ ★
→ 못 하면 합칠 후보 ★③ 동사를 정하세요
검색 · 상세 · 목록 · 집계 · 요청 ★
우리 도구를 이 동사로 다시 이름 짓기 ★10. 내일 할 것
★ 설명은 모델이 읽는 문서다.
이름보다 설명이 더 많이 듭니다. 그리고 대부분 나쁘게 쓰여 있습니다.
이 글은 MCP 과정의 2주차 1일차입니다. 과정 전체 보기
진도와 검색이 되는 판: AXPulse 기술따라가기
댓글
댓글 쓰기