Agent 실행을 감사 로그에서 추적하기
앞선 글에서는 Agent가 사용할 수 있는 기능과 실제로 접근할 수 있는 대상을 분리했습니다. 이번 글에서는 필요한 권한 판정을 모두 통과했다고 가정합니다.
예를 들어 사용자 1이 Agent를 통해 구성원 100의 평가 정보를 조회했다고 해보겠습니다. 현재 감사 로그에서도 사용자와 대상은 확인할 수 있습니다. 하지만 어느 Agent 작업의 어떤 Tool 호출에서 발생한 접근인지는 별도의 실행 기록과 대조해야 알 수 있습니다.
권한을 올바르게 판정하는 것과 그 판정이 어떤 실행에서 어떤 데이터 접근으로 이어지는지 추적하는 것은 별개의 문제였습니다.
데이터 접근에서 Agent 실행을 찾기 어려웠다#
현재는 데이터 접근, 위임 권한, Agent 실행에 관한 기록이 서로 다른 곳에 남습니다. 데이터 접근 로그에서는 원래 사용자와 대상, 사용한 기능을 확인할 수 있습니다. 위임 권한 기록에는 사용자와 실행 문맥, 권한의 발급·회수 이력이 있고, Agent 실행 기록에는 작업 상태와 진행 이벤트가 있습니다.
각 기록에는 필요한 정보가 남아 있지만, 특정 데이터 접근이 어느 Agent 작업과 Tool 호출, 위임 권한에서 발생했는지 바로 파악하기는 어렵습니다.
발생 시각이 가까운 기록을 맞추는 방법은 단순한 요청에서는 동작하지만 Agent가 Tool을 병렬로 호출하거나 timeout 이후 재시도하면 같은 사용자와 대상을 가진 기록이 짧은 시간에 반복됩니다. 시각만으로는 어느 권한 판정과 데이터 접근이 같은 호출에서 나온 것인지 확정하기 어렵습니다.
Tool 호출 하나를 끝까지 연결하기#
따라서 Tool 호출마다 공통 실행 정보를 전달하도록 전환 설계를 했습니다. 하나의 ID에 모든 의미를 담지 않고, 대화와 Agent 실행, Tool 호출, 전송 시도와 위임 권한을 각각 구분합니다.
하나의 대화에는 여러 Agent 실행이 있고, 한 번의 실행에서는 여러 Tool이 호출될 수 있습니다. invocationId는 한 번의 논리적인 Tool 호출을 가리키며, 네트워크 재시도는 별도의 attemptId로 구분합니다. 두 번째 글에서 다룬 것처럼 실행 중 credential이 교체되면 delegationId는 바뀌지만, 최초 위임을 가리키는 rootDelegationId는 유지됩니다.
전환 설계에서는 Core가 확인한 사용자와 tenant, 실행·위임 식별자를 Agent의 Tool 호출 문맥에 함께 전달합니다. 이후 권한 판정 로그와 데이터 접근 로그가 같은 invocationId를 기록하도록 해, 하나의 호출을 여러 기록에서 다시 찾을 수 있게 합니다.
분산 추적의 traceId도 요청 경로를 따라가는 데 유용하지만, 작업 재개나 재시도에서는 달라질 수 있으므로 Agent 작업과 위임 권한을 식별하는 값은 별도로 유지하도록 설계했습니다.
허용과 조회 성공을 따로 기록하기#
이전 글에서 권한 처리 결과로 사용한 ALLOW는 데이터를 조회할 자격이 있었다는 뜻이지, 실제 조회가 성공했다는 뜻은 아닙니다. 권한 검사를 통과한 뒤 DB 조회가 실패하거나, 조회는 끝났지만 응답을 반환하기 전에 네트워크 오류가 발생할 수 있습니다.
그래서 전환 설계에서는 권한 판정과 데이터 접근 결과를 같은 invocationId 아래 서로 다른 기록으로 남깁니다. 권한 판정에는 허용·거절 결과와 적용한 정책을 기록하고, 데이터 접근 기록에는 실제 조회의 성공·실패를 남깁니다. DENY된 요청은 데이터 접근 기록 없이 권한 판정 기록만 남습니다.
재시도도 같은 기준으로 구분합니다. 첫 번째 요청이 실제 조회를 마친 뒤 응답만 유실됐다면, 두 번째 요청은 같은 invocationId를 가지더라도 별도의 전송 시도로 기록합니다. invocationId는 같은 Tool 호출임을 보여주고, idempotency는 같은 작업의 중복 실행을 막습니다.
감사 로그에 남길 정보의 범위#
앞선 글에서 Tool 인자는 대상별 권한 판정의 입력으로 다뤘습니다. 하지만 권한 판정에 사용했다고 해서 인자 전체를 감사 로그에 남겨야 하는 것은 아닙니다. 구성원 정보, 조회 기간, 자연어 검색어 같은 민감한 값까지 함께 저장될 수 있기 때문입니다. 따라서 필요한 식별자와 판정 근거만 기록하고, 실제 위임 credential이나 사용자 credential은 저장하지 않습니다.
현재 운영 경로에는 원래 사용자와 대상 구성원, Agent가 사용한 기능 영역이 남습니다. 공통 실행 식별자를 전달하고 권한 판정과 데이터 접근 결과를 연결하는 구조는 아직 적용하지 않은 전환 설계입니다.
실행이 끝난 뒤에도 설명할 수 있어야 한다#
Agent가 개입하면서 감사 로그에서 필요한 정보가 달라지고, 사용자와 대상만 기록해서는 어떤 Agent 작업의 어떤 Tool 호출에서 발생한 접근인지 설명하기 어려워졌습니다.
전환 설계에서는 Tool 호출을 하나의 invocationId로 식별하고, Agent 실행과 위임 권한, 권한 판정, 실제 데이터 접근 결과가 같은 호출을 가리키도록 연결했습니다. 재시도처럼 하나의 Tool 호출이 여러 요청으로 나뉘는 경우에는 attemptId를 별도로 두어 논리적인 호출과 개별 전송도 구분했습니다.
이번 글에서는 감사 로그에서 Agent가 어떤 행동을 했는지 뿐만 아니라, 누가 시작한 작업에서 어떤 Tool이 호출됐고, 어떤 권한 판정을 거쳐 어떤 데이터에 접근했는지까지 하나의 흐름으로 설명할 수 있어야 하는 이유와 그 전환 설계 방식을 다뤘습니다.