LLM은 그 자체로는 "텍스트를 잘 만들어내는 함수"에 가깝다. 의료/헬스케어 도메인의 AI Agent — 케어챗처럼 사용자의 증상 문의, 복약 안내, 예약 변경, 의료진 라우팅 같은 실제 업무를 처리해야 하는 시스템 — 에서는 모델이 "그럴듯한 답"을 생성하는 것만으로는 충분하지 않다. 진짜 가치는 모델이 외부 시스템을 안전하게 호출하고, 그 결과를 바탕...
LLM은 그 자체로는 "텍스트를 잘 만들어내는 함수"에 가깝다. 의료/헬스케어 도메인의 AI Agent — 케어챗처럼 사용자의 증상 문의, 복약 안내, 예약 변경, 의료진 라우팅 같은 실제 업무를 처리해야 하는 시스템 — 에서는 모델이 "그럴듯한 답"을 생성하는 것만으로는 충분하지 않다. 진짜 가치는 모델이 외부 시스템을 안전하게 호출하고, 그 결과를 바탕으로 다음 행동을 결정하며, 실패했을 때 사람에게 다시 넘기거나 재시도할 수 있을 때 만들어진다.
이 흐름의 가운데에 있는 것이 Tool Calling(또는 Function Calling)이고, 그 위에서 도구 호출을 여러 번 엮어 하나의 사용자 의도를 처리하는 것이 Agent Workflow다. 백엔드 엔지니어가 면접에서 평가받는 지점은 다음과 같다.
이 문서는 이 네 가지를 케어챗-스타일 백엔드 관점에서 풀어 쓴다.
Tool Calling은 LLM이 자연어 응답 대신, 사전에 정의된 함수 시그니처에 맞는 JSON 인자를 출력하도록 유도하는 메커니즘이다. OpenAI, Anthropic, Bedrock, Vertex 등 주요 제공자는 동일한 모양의 인터페이스를 갖는다.
{"tool": "...", "arguments": {...}} 형태의 구조화된 응답을 돌려준다.여기서 가장 자주 오해받는 부분은 "모델이 도구를 호출했다"가 아니라 "모델이 도구를 호출하자고 제안했고, 백엔드가 검증하고 실행했다" 라는 점이다. 모델은 어디까지나 인자 후보를 만든다. 실행 권한은 항상 백엔드에 있다. 이 분리를 흐리면 권한, 감사, 비용, 신뢰성 모두가 무너진다.
도구 호출을 한 번 하면 끝나는 단순 케이스는 거의 없다. 보통 두 가지 패턴 중 하나를 쓴다.
final_answer를 내거나, 최대 step 수를 초과하거나, 실패 가드가 발동했을 때다.케어챗처럼 "사용자 → 1차 분류 → 의료/예약/일반 상담 분기 → 도구 호출 → 응답"이 정형화된 도메인은 Plan-then-Execute의 약식 버전 + ReAct를 도구 호출 단계에서만 허용하는 하이브리드가 실용적이다. 자유도는 줄이고, 감사·재현성·비용 통제는 늘리는 방향이다.
다음 흐름을 백엔드 관점에서 단계별로 본다. 사용자 발화: "어제 처방받은 약 다시 보내줄 수 있어요? 이름은 김OO이에요."
가장 먼저 하는 일은 이 발화가 어떤 카테고리인지를 판별하는 것이다. 두 가지 접근이 있다.
헬스케어 도메인은 후자가 안전하다. "처방 재발송"은 의료기록 접근 권한이 필요한 민감 카테고리이고, "오늘 날씨" 같은 잡담과 같은 도구 풀에 두면 안 된다. 분류 결과에 따라 다른 system prompt + 다른 tool subset을 모델에 주입한다.
1차 분류: { category: "PRESCRIPTION_RESEND", confidence: 0.92 }
→ 토구 풀: [findPatient, findRecentPrescription, resendPrescription, escalateToHuman]
→ 시스템 프롬프트: "본인 확인이 끝나기 전에는 처방 정보를 노출하지 마라"도구는 코드 곳곳에 흩어두지 않고 하나의 레지스트리에 등록한다. 각 도구는 다음 메타데이터를 가진다.
resend_prescription)prescription:read, prescription:send)retry, escalate, apologize)PHI_READ, PHI_WRITE, BENIGN)레지스트리는 단순한 Java 인터페이스 + Spring Bean 등록으로 충분하다. 추후 모델에 노출할 JSON Schema는 이 레지스트리에서 자동 생성한다. 메타데이터를 코드와 따로 두지 않는 것이 핵심이다. 따로 두면 둘이 어긋나고, 어긋난 순간이 가장 위험한 순간이다.
모델이 돌려준 arguments JSON은 절대 그대로 실행하지 않는다. 두 단계 검증을 거친다.
networknt/json-schema-validator 같은 라이브러리가 표준이다.구조 검증이 통과해도 의미 검증에서 떨어지는 경우가 가장 흔한 hallucination 패턴이다. 모델은 그럴듯한 환자 ID를 만들어낸다. 백엔드는 그것을 정중히 거절해야 한다.
도구 호출은 항상 현재 인증 컨텍스트의 권한과 함께 검증한다. 모델은 권한을 알 필요가 없고, 알게 해서도 안 된다. Spring Security 환경이라면 다음과 같은 모양이 된다.
SecurityContext의 권한과 도구 스코프를 비교여기서 자주 하는 실수는 "모델이 시킨 일이니까 잠깐 권한을 올려서 실행한다"는 우회다. 어떤 경우에도 도구 실행은 사용자 컨텍스트에서 벌어진다. 모델은 권한 상승의 근거가 될 수 없다.
도구는 실패한다. HTTP 5xx, timeout, 부분 성공, 외부 EMR의 일시 장애. 각 실패에 대해 다음 정책을 미리 정한다.
findPatient, findRecentPrescription): 지수 백오프 + jitter로 2~3회 재시도. 결과적으로 모델에게 보여줄 observation은 "성공" 또는 "최종 실패".resendPrescription, cancelAppointment): 재시도는 idempotency key가 있을 때만. 없으면 즉시 실패로 보고. 모델이 같은 도구를 반복 호출해 부작용이 누적되는 사고를 막는다.루프 전체에는 최대 step 수, 최대 누적 토큰, 최대 누적 비용 가드를 둔다. 한 사용자 발화당 도구 호출 6회, 누적 LLM 토큰 30k, 시간 20초가 흔한 출발점이다. 가드에 걸리면 친절한 fallback 답변과 함께 사람 상담사로 escalate한다.
규제 도메인에서 audit log는 후순위가 아니라 1차 산출물이다. 한 번의 사용자 발화에 대해 다음을 모두 남긴다.
audit는 운영뿐 아니라 모델 평가의 입력이 된다. 어떤 분류가 자주 잘못되는지, 어떤 도구의 인자 hallucination이 잦은지, 어떤 fallback 경로가 가장 많이 도는지를 정량적으로 본다. 이 데이터 없이는 LLM 시스템은 개선되지 않는다.
다음은 케어챗-스타일 백엔드에서 자주 쓰는 구조다. 코드는 핵심만 추렸다.
public interface AgentTool<I, O> {
String name();
Class<I> inputType();
JsonNode jsonSchema();
Set<String> requiredScopes();
SideEffect sideEffect(); // NONE, IDEMPOTENT_WRITE, NON_IDEMPOTENT_WRITE
O invoke(I input, ToolContext ctx);
}
@Component
public class ToolRegistry {
private final Map<String, AgentTool<?, ?>> byName;
public ToolRegistry(List<AgentTool<?, ?>> tools) {
this.byName = tools.stream().collect(toMap(AgentTool::name, t -> t));
}
public List<JsonNode> exposedSchemasFor(IntentCategory category, Authentication auth) {
return byName.values().stream()
.filter(t -> categoryAllows(category, t))
.filter(t -> hasAllScopes(auth, t.requiredScopes()))
.map(AgentTool::jsonSchema)
.toList();
}
}핵심은 모델에 "노출되는 도구 목록"이 카테고리 + 권한으로 동적으로 좁혀진다는 점이다. 정적 전체 노출은 헬스케어에서는 위험하다.
public ToolResult dispatch(ToolCall call, ToolContext ctx) {
AgentTool<Object, Object> tool = registry.require(call.name());
if (!ctx.hasAllScopes(tool.requiredScopes())) {
audit.permissionDenied(call, ctx);
return ToolResult.refused("not_authorized");
}
Object input = schemaValidator.validateAndBind(call.arguments(), tool.inputType());
domainValidator.validate(input, ctx); // 환자 소유권, 날짜 sanity 등
try {
Object output = retryPolicy.runWithIdempotency(
tool.sideEffect(), call.idempotencyKey(),
() -> tool.invoke(input, ctx)
);
audit.success(call, output, ctx);
return ToolResult.ok(output);
} catch (DomainRefusal r) {
audit.domainRefused(call, r, ctx);
return ToolResult.refused(r.reasonCode());
} catch (Exception e) {
audit.failure(call, e, ctx);
return ToolResult.error("tool_failed");
}
}모델에게 돌려주는 ToolResult는 항상 사용자에게 그대로 노출되어도 안전한 수준의 메시지여야 한다. 스택 트레이스, 내부 환자 ID, 외부 시스템의 원시 에러 코드를 모델에 흘리지 않는다. 모델은 그것을 사용자에게 그대로 풀어 쓸 수 있다.
public AgentReply run(UserMessage msg, AgentContext ctx) {
Intent intent = intentClassifier.classify(msg, ctx);
LlmSession session = llm.openSession(intent.systemPrompt(),
registry.exposedSchemasFor(intent.category(), ctx.auth()));
session.append(msg);
for (int step = 0; step < ctx.maxSteps(); step++) {
LlmResponse r = session.next(ctx.budget());
if (r.isFinal()) return AgentReply.text(r.text());
ToolResult tr = dispatcher.dispatch(r.toolCall(), ctx.toToolContext());
session.appendObservation(r.toolCall(), tr);
if (ctx.budget().exhausted()) break;
}
return AgentReply.escalate("budget_exceeded");
}루프는 단순해 보이지만, 실제 운영에서 어렵게 만드는 것은 루프 외부의 가드다. 토큰 예산, 시간 예산, step 수, 외부 의존성의 헬스 상태, circuit breaker — 이 모든 것을 ctx.budget() 안에 모아둔다. 모델이 무한히 도구를 부르거나, 같은 도구를 반복 호출해 비용을 폭발시키지 않게 하는 마지막 안전망이다.
// 안티패턴
Map args = objectMapper.readValue(modelJson, Map.class);
String patientId = (String) args.get("patientId");
prescriptionService.resend(patientId);문제: schema 검증 없음, 권한 검증 없음, 환자 소유권 검증 없음, audit 없음. 모델이 임의 환자 ID를 만들면 그대로 처방이 재발송된다.
ToolCall → Dispatcher.dispatch 경로를 강제한다. 모델 출력은 항상 dispatcher 입구에서만 시스템 안으로 들어온다.
// 안티패턴
@Retryable(maxAttempts = 3)
public void resend(String prescriptionId) { ... }문제: 첫 호출이 외부 시스템에는 성공했는데 응답 타임아웃으로 우리 쪽이 실패라고 판단하면, 두 번 재시도가 추가로 발송된다. 환자에게 같은 SMS가 세 번 간다.
idempotency key (예: agentRequestId + toolName) 를 외부 시스템과 합의해 같이 보낸다. 외부가 idempotency를 지원하지 않으면 재시도하지 않는다. 모델에게는 "발송 시도 결과 확인 불가, 사람 상담사로 연결" 같은 정직한 observation을 돌려준다.
// 안티패턴
session = llm.open(systemPrompt, registry.allSchemas());문제: 잡담 컨텍스트에서도 resendPrescription 같은 민감 도구가 노출된다. prompt injection이나 사회공학 발화에 모델이 끌려갈 여지가 커진다.
intent 분류 결과 + 사용자 권한으로 도구 풀을 좁힌다. 잡담 컨텍스트에는 PHI 도구를 절대 노출하지 않는다.
면접 대비 학습용으로 가볍게 굴릴 수 있는 환경.
spring-boot-starter-web, spring-boot-starter-validation, networknt/json-schema-validator, resilience4j-retry, micrometer-tracingfindPatient, findRecentPrescription, resendPrescription을 인메모리 Map<String, ...>으로 구현한 fake adapter. 일정 비율로 5xx와 timeout을 주입할 수 있게 둔다.logs/agent-audit.jsonl 파일에 줄 단위 JSON으로 audit를 적재. 분석은 jq로 충분하다.다음 시나리오는 손으로 굴려보면서 워크플로의 실패 모드를 익히는 데 유용하다.
findPatient → findRecentPrescription → resendPrescription → 최종 답변. audit log 4줄, 모두 성공.not_authorized로 거절. 모델이 사람 상담사로 escalate.resendPrescription이 idempotency key와 함께 한 번 호출되고 실패. 재시도 정책 상 비-idempotent로 분류돼 있다면 재시도 없이 사용자에게 사과 + 콜백 예약 도구로 우회.{"sms": "sent", "push": "queue_failed"}로 정직히 기록. 모델 답변은 "문자로는 보내드렸고 앱 알림은 잠시 후 다시 시도하겠다"가 돼야 한다. "모두 발송 완료"가 되어선 안 된다.각 시나리오는 통합 테스트로 묶어둘 수 있다. fake LLM은 시나리오별 스크립트를 받아 결정적으로 동작하게 만든다. 이렇게 하면 모델 응답이 바뀌어도 워크플로 가드가 잘 작동하는지를 회귀 테스트로 묶을 수 있다.
질문 유형별로 미리 정리해 둘 답의 뼈대.
모델의 비결정성과 시스템의 결정성을 잇는 경계 설계라고 답한다. 구체적으로는 (1) 도구 메타데이터를 코드와 한 곳에 두는 레지스트리, (2) 모델 출력에 대한 두 단계 검증(스키마 + 의미), (3) 권한·idempotency·audit를 dispatcher 한 지점에 모아 우회 경로를 없애는 것 — 이 세 가지를 들면 백엔드 관점이 잘 드러난다.
모델은 "잘 모를 때도 그럴듯한 인자"를 만든다는 전제에서 시작한다. 막는 게 아니라 걸러내는 설계라고 표현한다. 스키마 검증, 도메인 의미 검증, 사용자 권한·소유권 검증, 그리고 거절을 모델에게 정중한 observation으로 돌려보내 다음 step이 본인 확인 같은 안전한 경로로 흐르도록 유도한다. 거절 메시지에 내부 정보를 흘리지 않는다는 점도 같이 말한다.
도메인이 정형화돼 있고 감사 추적이 중요한 헬스케어라면 Plan-then-Execute의 약식 버전을 선호한다고 답한다. 자유도는 줄지만 재현성과 비용 통제가 좋아진다. ReAct는 도구 단계 내에서 제한적으로만 허용. trade-off를 명확히 말하는 것이 중요하다.
루프당 step 수, 누적 토큰, 누적 시간, 누적 비용 가드를 sessions 단위로 두고, 각 도구의 평균/최대 응답 시간을 SLO로 관리한다. 외부 의존성에는 circuit breaker. 사용자 발화 1건에 대한 budget을 사전에 정하고, 초과 시 사람 상담사로 escalate.
분류 결과, 노출 도구 목록, 모델 제안 tool call, 검증 결과, 실제 실행 결과, 최종 답변까지를 한 correlation id로 묶어 audit JSONL에 적재한다. 운영뿐 아니라 모델 평가의 입력이 된다는 점을 강조한다.