Cohere
경력근거: agents must be reliable, observable, safe, and auditable from day one
※ 실제 산출물이 아닌 AI 예측 시안입니다.
Cohere의 North는 고객사 안에 들어가 사내 도구와 에이전트를 잇는 제품이고, 공고는 금융·의료·통신 같은 규제 산업을 고객으로 적으면서 감사 가능성을 첫날 요건으로 못박습니다. 규제 산업에서는 에이전트가 무엇을 했는지가 아니라 무엇을 할 수 있었는지를 증명해야 하는데, 그 증명은 도구 명세와 실제 호출을 대조한 기록으로만 섭니다. 이 요구는 남의 사내 시스템에 에이전트를 붙이는 자리에서만 생깁니다. 공고 업무는 문제 정의부터 프론트엔드까지 걸쳐 있는데 1주 범위에서 고를 수 있는 것은 하나라 호출 감사 축을 골랐습니다. 이 포트폴리오는 명세를 규칙으로 집행하고 어긋난 근거를 남기는 기술을 보여줍니다. 금융·의료 규제 자체의 전문성은 주장하지 않습니다. 어떤 통제가 법적으로 요구되는지는 면접에서 모른다고 말하는 편이 낫습니다.
에이전트가 첫날부터 믿을 수 있고 관측 가능하며 감사 가능해야 한다고 못박습니다. 어떤 도구를 어떤 인자로 불렀는지 기록을 명세와 대조하는 일이 그 감사의 최소 단위입니다.
LLM을 도구와 API, 데이터 소스에 엮는 첫 사례급 워크플로를 만드는 일이 업무입니다. 도구 호출이 명세대로 나갔는지가 그 워크플로의 첫 점검 지점입니다.
성공과 실패, 회귀를 재는 평가·품질 기준을 정의하고 적용하는 일이 업무로 적혀 있습니다. 명세 대조는 사람 판단 없이 회귀를 잡는 축입니다.
에이전트가 남긴 도구 호출 기록과 도구 명세를 대조해, 인자가 명세를 벗어난 호출을 사유별로 나눠 출력하고 감사용 리포트를 남기는 CLI입니다. 판정은 필수 인자 존재와 허용 값 목록, 수치 범위를 명세와 견주는 대조로 정합니다.
고객사에 에이전트를 붙여 놓고 운영 승인을 받아야 하는 파견 엔지니어입니다. 보안 담당자가 무엇을 어떤 값으로 호출했는지 근거를 요구하는데, 실행 기록을 열어 호출 인자를 하나씩 눈으로 훑으며 명세와 맞춰 보느라 승인 회의 전날을 씁니다.
도구마다 필수 인자와 허용 값이 명세로 적혀 있으면, 어떤 호출이 명세를 벗어났는지는 사람이 기록을 훑지 않아도 대조로 갈라집니다.
도구 호출 기록과 명세 파일을 인자로 받아 호출별 판정을 터미널에 출력하고 감사용 리포트를 떨구는 CLI입니다. 에이전트를 직접 돌리지 않고 이미 쌓인 기록만 읽습니다.
직전 실행 기록을 함께 받아 이번에 새로 어긋난 호출과 고쳐진 호출을 가려내는 회귀 비교기입니다.
도구 명세를 파일로 분리해 고객사마다 다른 도구 묶음을 같은 판정으로 돌리고, 판정 결과를 JSON으로 내보내 감사 시스템이 받아 갈 수 있게 합니다.
담당자가 호출 기록 50행과 도구 명세를 넣어 어긋난 호출이 사유별로 나뉜 판정표와 감사용 리포트가 나오는 것을 시연합니다.
결측·중복·미등록 도구가 섞인 입력 30종을 넣어도 출력 형식이 깨지지 않고, 판정하지 못한 호출은 사유가 붙어 남습니다.
인자가 비어 있는 호출은 통과로 세지 않고 인자 누락으로 따로 답니다. 확인하지 못한 것을 정상으로 만들지 않습니다.
판정과 손으로 만든 정답표를 맞춰 사유별로 어긋난 건을 셉니다. 단, 기록과 정답을 모두 작성자가 만든 합성 기준이라 성능 측정이 아니라 데모 조건 동작입니다.
진짜 성능 검증은 여기서 멈춥니다. 위 수치는 더미데이터 자가채점이며, 실제 감사 정확도는 Cohere 고객사의 실제 호출 기록과 실제 도구 명세가 있어야 측정됩니다. 이 포트폴리오는 그 검증을 바로 돌릴 수 있는 상태까지 만듭니다.
수치는 합성 데이터 자가채점이라 성능 증명이 아닙니다. 면접에서는 데모 동작과 실검증 준비 상태로 솔직히 설명합니다.
도구 명세를 만든 사람이 호출 기록도 만들었습니다. 어긋난 건을 잘 찾는 게 당연하니 도구 이름이 버전마다 다른 건과 인자가 빈 호출, 명세에 없는 도구를 기록에 함께 넣었습니다.
명세를 지켰다고 해서 안전하다고 단정할 수 없습니다. 명세 안에서도 위험한 조합이 있을 수 있으므로, 판정은 명세를 벗어났는지까지만 읽어야 합니다.
실제 도입하면 고객사마다 열어 주는 도구와 허용 값이 다릅니다. 명세를 보안 담당자와 합의해 채우는 일이 도입 단계의 실제 과제입니다.
에이전트가 왜 그 도구를 골랐는지의 판단 품질은 이 도구의 범위 밖입니다. 부른 결과만 검사하므로, 선택 자체의 적절성은 사람이 봅니다.
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
에이전트가 실행 중 남긴 도구 호출 기록입니다. 도구 이름이 버전마다 대소문자·띄어쓰기로 흔들리고, 명세에 없는 신규 도구와 같은 호출 번호가 두 번 들어온 건, 인자가 비어 있는 행을 일부러 섞었습니다.
| call_no | run_no | tool_name_raw | arg_name | arg_value | caller_role |
|---|---|---|---|---|---|
| CL-001 | RUN-001 | search_docs | scope | team | agent |
| CL-002 | RUN-001 | search_docs | top_k | 5 | agent |
| CL-003 | RUN-002 | Search_Docs | scope | global | agent |
| CL-004 | RUN-002 | search_docs | top_k | 200 | agent |
| CL-005 | RUN-003 | send_summary | channel | internal | agent |
아래 JSON Schema에 맞는 도구 호출 기록 행을 더 만들어 주세요. {"type":"object","properties":{"call_no":{"type":"string"},"run_no":{"type":"string"},"tool_name_raw":{"type":"string"},"arg_name":{"type":"string"},"arg_value":{"type":["string","null"]},"caller_role":{"type":"string"}},"required":["call_no","run_no","tool_name_raw","arg_name","arg_value","caller_role"]} 한 run_no에 호출이 두 건 이상 이어지도록 만들어 주세요. 쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라. 첫째 미매핑으로 tool_name_raw가 명세에 없어 tool_id가 null인 행, 둘째 표기흔들림으로 같은 도구를 search_docs와 Search_Docs와 SEARCH DOCS처럼 대소문자·구분자만 다르게 적은 행, 셋째 중복으로 같은 call_no가 두 행에 있는 재적재 건, 넷째 결측으로 필수 인자의 arg_value가 null인 행, 다섯째 경계극단으로 수치 인자가 허용 상한과 정확히 같은 행. 명세를 지킨 정상 호출이 전체의 절반쯤 되게 해 주세요. 또한 형식 깨뜨리기 시도 3건을 별도 파일로 만들어 arg_name을 빼거나 call_no에 숫자 타입을 넣어 스키마 검증이 걸러내는지 확인하게 해 주세요.{"type":"object","properties":{"call_no":{"type":"string"},"run_no":{"type":"string"},"tool_name_raw":{"type":"string"},"arg_name":{"type":"string"},"arg_value":{"type":["string","null"]},"caller_role":{"type":"string"}},"required":["call_no","run_no","tool_name_raw","arg_name","arg_value","caller_role"]}고객사가 에이전트에 열어 준 도구의 인자 명세입니다. 허용 값 목록이 아직 정해지지 않은 인자를 일부러 섞었습니다.
| tool_id | tool_label | arg_name | is_required | allowed_values | max_number |
|---|---|---|---|---|---|
| search_docs | 문서 검색 | scope | true | team|department | — |
| search_docs | 문서 검색 | top_k | true | — | 50 |
| send_summary | 요약 전달 | channel | true | internal | — |
| send_summary | 요약 전달 | recipient | true | — | — |
| lookup_customer | 고객 조회 | customer_id | true | — | — |
아래 JSON Schema에 맞는 도구 인자 명세 행을 더 만들어 주세요. {"type":"object","properties":{"tool_id":{"type":"string"},"tool_label":{"type":"string"},"arg_name":{"type":"string"},"is_required":{"type":"boolean"},"allowed_values":{"type":["string","null"]},"max_number":{"type":["integer","null"]}},"required":["tool_id","tool_label","arg_name","is_required","allowed_values","max_number"]} tool_label은 한글로 적어 주세요. allowed_values는 세로선으로 구분한 목록으로 적고 제한이 없으면 null로 두세요. 쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라. 첫째 결측으로 allowed_values와 max_number가 모두 null인 제한 없는 인자, 둘째 경계극단으로 허용 값이 하나뿐인 인자와 max_number가 1인 인자. 또한 형식 깨뜨리기 시도 3건을 별도 파일로 만들어 is_required에 문자열을 넣거나 arg_name을 빼서 스키마 검증이 걸러내는지 확인하게 해 주세요.{"type":"object","properties":{"tool_id":{"type":"string"},"tool_label":{"type":"string"},"arg_name":{"type":"string"},"is_required":{"type":"boolean"},"allowed_values":{"type":["string","null"]},"max_number":{"type":["integer","null"]}},"required":["tool_id","tool_label","arg_name","is_required","allowed_values","max_number"]}| Python | 호출 기록과 명세를 읽어 인자 대조 판정을 돌리고 리포트를 만드는 본체입니다. |
| TypeScript | 판정 결과를 감사 시스템이 받아 갈 때 쓰는 타입 정의와 내보내기 스크립트입니다. |
| 에이전트 오케스트레이션 | 실행이 도구 호출 열로 남는다는 전제를 주는 구조입니다. 그 호출 열이 이 도구의 입력입니다. |
| 도구 호출 | 판정 대상 자체입니다. 도구 이름과 인자 묶음이 한 행으로 들어옵니다. |
| RAG | 검색 도구도 하나의 호출로 보고 질의 인자와 필터 값을 같은 방식으로 검사합니다. |
| 가드레일 | 명세가 곧 가드레일의 정적 표현이며, 이 도구는 그 명세가 실제로 지켜졌는지를 사후에 확인합니다. |
✓ pass → 여기서 멈춰도 완결입니다. 더 키우려면 직전 실행과 비교해 새로 어긋난 호출만 골라냅니다.
✓ pass → 회귀 비교까지가 한 덩어리입니다. 더 키우려면 명세를 고객사별로 분리하고 결과를 JSON으로 내보냅니다.
도구 호출 한 건이 명세를 지켰는지의 판정 결과입니다. 벗어났다면 어느 인자가 어떻게 벗어났는지를 근거와 함께 담습니다.
{"type":"object","properties":{"call_no":{"type":"string"},"verdict":{"type":"string","enum":["compliant","value_not_allowed","number_over_limit","required_arg_missing","tool_unmapped","duplicate_call"]},"checked_arg":{"type":["string","null"]},"evidence":{"type":"array","items":{"type":"object","properties":{"field":{"type":"string"},"agg":{"type":["string","null"]},"value":{},"quote":{"type":["string","null"]}},"required":["field","value"]}},"next_action":{"type":"string"}},"required":["call_no","verdict","checked_arg","evidence","next_action"]}[
{
"call_no": "CL-001",
"verdict": "compliant",
"checked_arg": "scope",
"evidence": [
{
"field": "arg_value",
"value": "team"
},
{
"field": "allowed_values",
"value": "team|department"
}
],
"next_action": "허용 값 안입니다. 기준선 호출로 남깁니다."
},
{
"call_no": "CL-008",
"verdict": "compliant",
"checked_arg": "top_k",
"evidence": [
{
"field": "arg_value",
"value": "10"
},
{
"field": "max_number",
"value": 50
}
],
"next_action": "상한 안입니다. 기준선 호출로 남깁니다."
},
{
"call_no": "CL-003",
"verdict": "value_not_allowed",
"checked_arg": "scope",
"evidence": [
{
"field": "arg_value",
"value": "global"
},
{
"field": "allowed_values",
"value": "team|department"
}
],
"next_action": "허용 목록에 없는 범위로 검색했습니다. 프롬프트에서 범위 기본값을 team으로 못박습니다."
},
{
"call_no": "CL-004",
"verdict": "number_over_limit",
"checked_arg": "top_k",
"evidence": [
{
"field": "arg_value",
"value": "200"
},
{
"field": "max_number",
"value": 50
}
],
"next_action": "상한을 넘겨 문서를 가져왔습니다. 도구 쪽에서 상한을 강제하도록 고칩니다."
},
{
"call_no": "CL-006",
"verdict": "required_arg_missing",
"checked_arg": "recipient",
"evidence": [
{
"field": "arg_value",
"value": null
},
{
"field": "is_required",
"value": true
}
],
"next_action": "필수 인자가 비어 있습니다. 통과로 세지 않고 호출 실패로 다루도록 고칩니다."
},
{
"call_no": "CL-009",
"verdict": "tool_unmapped",
"checked_arg": null,
"evidence": [
{
"field": "tool_name_raw",
"value": "export_ledger",
"quote": "export_ledger"
}
],
"next_action": "명세에 없는 도구를 불렀습니다. 열어 준 적이 없는 도구인지 보안 담당자와 즉시 확인합니다."
},
{
"call_no": "CL-004",
"verdict": "duplicate_call",
"checked_arg": "top_k",
"evidence": [
{
"field": "call_no",
"agg": "count",
"value": 2
}
],
"next_action": "같은 호출 번호가 두 번 적재됐습니다. 앞 건으로만 판정하고 뒤 건을 기록에서 뺍니다."
}
][자동 검증 · 1주차] 1. verdict가 enum 여섯 값 안에 있는지 확인합니다. 2. call_no·verdict·checked_arg·evidence·next_action이 모두 있는지 확인합니다. 3. max_number가 있는 인자의 arg_value가 0 이상 그 값 이하인지 확인합니다. 4. arg_value가 null이고 is_required가 true이면 verdict가 required_arg_missing인지 확인합니다. 5. evidence의 field가 두 입력 표의 컬럼에 실재하는지 확인합니다. 6. evidence의 quote가 그 행 tool_name_raw의 일부인지 확인합니다. 7. next_action이 존댓말로 끝나는지 확인합니다. [판정 규칙] 1. 도구 이름은 대소문자와 띄어쓰기, 구분자를 없애 소문자로 모은 뒤 tool_specs의 tool_id와 맞춥니다. 맞는 것이 없으면 미매핑으로 남기고 그 행은 나머지 판정에서 뺍니다. 2. 같은 행 번호가 두 번 들어오면 앞 건만 남기고 뒤 건은 적재 단계에서 사유와 함께 뺍니다. [수동 검증] 1. 명세에 없는 도구를 부른 건이 실제로 권한 밖인지 보안 담당자가 확인합니다. 2. CL-003·CL-007처럼 도구 이름 표기가 흔들렸지만 명세로 맞춰진 호출은 미매핑 사유를 달지 않는 것이 맞는지 확인합니다. [평가 러너 · 2주차] 1. 직전 실행과 비교해 새로 어긋난 호출과 고쳐진 호출을 세고 사유별로 나눕니다. 2. 기록과 정답을 작성자가 만든 합성 기준이라 이 수치는 성능 측정이 아니라 데모 조건 동작입니다.
근거: agents must be reliable, observable, safe, and auditable from day one