커맨드 로그는 에이전트가 실제로 무엇을 했는지 말해주지 않습니다.

커맨드 로그는 무엇이 실행됐는지 알려줍니다. 감사는 누가·왜·누구의 승인으로 했는지에 답해야 합니다. 사람이든 에이전트든 똑같이요.

프로덕션 서버의 로그 한 줄입니다.

2026-05-22T03:14:21Z  host=web-prod-04  user=svc-deploy  cmd="systemctl reload nginx"  exit=0

얼핏 증거처럼 보입니다. 어떤 명령이 어느 서버에서 언제 실행돼 성공했는지 알려주니까요. 그런데 무언가 이상해 보이는 순간 정작 던지게 되는 질문에 답해 보세요. 왜 nginx를 reload했고, 누구의 승인으로, 어떤 작업의 일환으로 했으며, svc-deploy는 사람인가 에이전트인가? 이 부분에 대해선 답하지 못합니다. 이런 로그가 수천 개로 쌓이면 포렌식이 아니라, 타임스탬프만 찍힌 노이즈가 됩니다.

이건 로그입니다. 감사가 아닙니다. 이 시리즈는 AI 에이전트가 공격 표면을 넓히지 않게 하는 것(1편), 그리고 에이전트가 무엇을 실행하는지 통제하는 것(2편)을 다뤘습니다. 이번 글은 무언가 벌어진 '뒤에' 받는 질문입니다. 무슨 일이 있었는지 증명할 수 있는가.

---

커맨드 로그가 곧 감사일까요?

요약: 아닙니다. 로그는 무엇이 실행됐는지를 알려줍니다. 감사는 누가, 언제, 무엇을, 왜, 누구의 승인으로, 어떤 목적으로 했는지에 답해야 합니다. 사람이든 에이전트든 똑같이요.

에이전트가 예상 밖 행동을 했을 때, '무슨 명령이 실행됐나'는 이미 알 수 있습니다. 감사가 답해야 하는 건 여섯 가지입니다. 누가 했는지(사람인가 에이전트인가, 인증된 아이덴티티로), 언제(어떤 세션 구간 안에서), 무엇을(명령, 건드린 경로, 결과), 왜(그 동작이 속한 선언된 목적), 누구의 승인으로, 그리고 어떤 목적으로(그 행위를 정당하게 만드는 업무 맥락). 커맨드 로그는 이 중 무엇을에만 답하고, 그 외는 거의 아무것도 답하지 못합니다. 나머지는 마감에 쫓기며 손으로 재구성합니다. 셸 히스토리, 티켓 링크, 그리고 '누가 승인했더라'는 누군가의 기억을 이어 붙여서요.

이 과정은 사람만 있어도 이미 고통스러웠습니다. 에이전트가 들어오면 손댈 수조차 없습니다. 대다수 조직은 자기 에이전트조차 아직 파악하지 못합니다. 82%가 자기 환경에 미파악 AI 에이전트가 있다고 답했고, RSAC 2026에서 63%는 에이전트가 무엇을 할 수 있는지를 강제할 수 없다고 답했습니다. 애초에 담아 두지 않은 것을 사후에 감사할 수는 없습니다.

감사가 그 질문들에 답하려면 무엇이 필요할까요?

요약: 맥락을 사후에 추측하는 게 아니라 동작이 일어나는 그 순간에 필드로 담아야 합니다. 그리고 사람과 에이전트를 하나의 타임라인에 올려야 합니다.

커맨드 로그가 그 질문들에 답하지 못하는 이유는, 무엇을만 기록하고 그 주변을 전부 버리기 때문입니다. Alpacon의 감사는 반대로 작동합니다. 맥락이 모든 동작에 내장돼 있습니다. 모든 동작이 이미, 그것을 선언한 통제된 세션 안에서 일어났으니까요.

CISO가 '어제 web-prod-04에서 무슨 일이 있었나'라고 물으면 하나의 타임라인을 받습니다. 사람용 따로, CI용 따로, 에이전트용 따로가 아니라요. 모든 동작은 Work Session에 속하고, 세션은 미리 선언된 필수 목적, 부여된 스코프, 활성화시킨 승인, 그리고 각 명령이 매긴 위험 점수를 지닙니다. 모든 기록은 행위자와 그 동작을 실행한 정확한 자격증명을 명시합니다. 사용자인지, API 토큰인지, 애플리케이션에 묶인 서비스 토큰인지요. 그래서 '누가'는 그 아이덴티티가 사람이든 에이전트든 인증된 아이덴티티로 귀결됩니다. 이 중 어느 것도 사후에 자유 텍스트 로그에서 파싱해 낸 게 아닙니다. 실행 시점에 구조화된 필드로 기록됩니다.

오프닝의 그 로그 한 줄을 Alpacon 기록으로 보면 이렇습니다.

로그는 무엇을만 줬습니다. 나머지 줄은 전부 동작이 실행될 때 담긴 필드지, 사후 재구성이 아닙니다.

이미 사용 가능한 기능이고, 전체를 떠받치는 핵심입니다. 포렌식 질문에 답할 수 있는 이유는, 내부 사고 조사가 됐든 외부 감사가 됐든, 그 답을 누가 물으러 왔을 때 재구성해서가 아니라 동작이 실행되는 순간에 이미 담아 뒀기 때문입니다.

감사는 왜 append-only여야 할까요?

요약: 몰래 고칠 수 있는 감사는 아무것도 증명하지 못합니다. Alpacon은 감사 이력을 읽기 전용 API로 노출합니다. 제품을 통한 수정 경로는 없고, 기록은 편집이 아니라 보존 기간에 따라 만료될 뿐입니다. 저장계층 자체를 암호학적으로 변조탐지 가능하게 만드는 건 다음 단계입니다.

고칠 수 있는 감사는 믿을 수 없는 감사입니다. 그래서 Alpacon은 감사 이력을 읽기 전용 API로 노출합니다. 제품을 통해 기록을 고쳐 쓸 경로가 없고, 기록은 여러분이 정한 보존 기간에 따라 만료될 뿐입니다. 편집이 아니라 정해진 기한에 따른 삭제죠. 현재는 이것이 API 수준에서 강제됩니다. 각 기록을 hash-chain으로 묶어 어떤 변조든 탐지되게 만드는 저장계층 차원은 다음 단계입니다. 그리고 기록은 검색 인덱스에 저장돼, 마감에 쫓기며 grep하는 평면 파일이 아니라 질의 가능한 형태가 됩니다.

Alpacon은 여러분의 SIEM이 되려는 게 아닙니다. 권한 접근 조각, 즉 누가 여러분의 인프라에서 무엇을 어떤 승인으로 어떤 목적으로 했는지를 담고, 질의 가능한 상태로 유지합니다.

그냥 감사 기록에 무슨 일이 있었는지 물어볼 수 있을까요?

요약: 이 모든 것들이 이미 구조화돼 있어서 기록은 지금도 바로 물어볼 수 있습니다. 프로그램적으로 MCP로, 그리고 그냥 대화하는 것처럼요. Alpacon 감사 화면엔 'Ask AI' 박스가 있습니다. '고위험 세션 보여줘'나 '어떤 에이전트 세션이 sudo를 썼나'라고 물으면 세션 이력에서 답을 받습니다. 일주일간 로그 파헤칠 필요가 없습니다.

지금까지 얘기한 모든 것이 무엇을 가능하게 하는지 봅시다. 모든 동작이 이미 누가·언제·무엇을·왜·누구의 승인으로·어떤 목적으로 했는지를 담고 있기에, 감사는 grep할 넘쳐나는 기록이 아니라 물어볼 수도 있는 구조화된 데이터이고, 이미 프로그램적으로 제공됩니다. 에이전트나 도구가 MCP로 활동 이력을 읽어, 구조화되고 귀속된 읽기 전용 기록을 제공합니다.

그냥 물어볼 수도 있습니다. Alpacon은 감사 화면에 'Ask AI' 박스를 더했습니다. '이번 주 고위험 세션은?'이나 '어떤 에이전트 세션이 sudo를 실행했나'라고 치면, 권한 세션 이력에서 답을 줍니다. 의미 기반 검색에 LLM을 얹은 것으로, 워크스페이스 내에서 작동하고, 실제로 사용 가능합니다. 경계를 분명히 하면, 이건 세션 기록에 대한 LLM 답변이지 모든 승인 행을 조인하는 정밀 쿼리는 아닙니다. 이런 기록은 규제가 점점 의무화하는 바로 그 내용이기도 합니다. 다만 이 기록으로 프레임워크에 매핑된 SOC 2·ISO 증거를 자동 생성하는 건 아직 로드맵 단계입니다. 어쨌든, '무슨 일이 있었냐'고 묻는 건 이제 언젠가의 막연한 얘기가 아닙니다. 이제는 에이전트가 무슨 일을 했는지 일주일간 로그를 파지 않고 파악할 수 있습니다.

핵심은 이게 그저 가져다 붙인 분석 툴이 아니라는 점입니다. 처음부터 올바른 것을 올바른 형태로 기록한 데서 자연히 따라온 결과물입니다.

에이전트가 잘못됐을 때, 이게 무엇을 바꿀까요?

요약: 기록이 사후에 마감에 쫓겨 짜맞추는 일이 아니라, 행동과 동시에 쌓여가는 기록물이 됩니다. 에이전트가 한 일에 답해야 하는 바로 그 순간, 이미 답이 있습니다.

시리즈 전체의 한 줄 요약입니다. 1편에서는 에이전트를 더해도 공격 표면이 넓어지지 않는 법을 얘기했습니다. 2편에서는 일단 들어온 에이전트가 무엇을 하는지 통제하는 법을 알려드렸습니다. 스코프와 의도, 그리고 애매한 부분은 사람이 맡는다는 내용을요. 이번 글은 그 둘을 증명 가능하게 만드는 법을 얘기했습니다. 사람과 에이전트를 하나의 타임라인에, 실행 시점에서부터, 누가·왜·누구의 승인으로 했는지에 답하는 감사요.

묻는 이가 사고 조사자든 감사관이든 문제는 같습니다. 저희도 지금 SOC 2 Type 2를 밟고 있어서 한 마디 덧붙이자면, 이 과정이 괴로운 건 맥락을 늘 마감에 쫓겨 사후에 재구성하기 때문입니다. 동작이 실행될 때 담아 두면, 답은 원래부터 존재합니다. 그게 저희가 만들어가는 가치입니다.

---

자주 묻는 질문

AI 에이전트가 예상 밖 행동을 했을 때, 무엇을 했는지 알아낼 수 있나요? 동작이 실행될 때 맥락을 담아 뒀을 때만요. 커맨드 로그는 명령과 그 정도만 줍니다. 에이전트가 누구로서, 누구의 승인으로, 어떤 선언된 목적으로 행동했는지는 아닙니다. Alpacon은 그것들을 실행 시점에 필드로, 하나의 타임라인에 기록합니다. 그래서 에이전트의 행위를 재구성하는 건 일주일간의 포렌식이 아니라 하나의 질의가 됩니다.

AI 에이전트가 프로덕션 서버에서 무엇을 했는지 감사할 수 있나요? 가능합니다. 단, 에이전트의 모든 동작이 누가 또는 무엇이, 어떤 스코프로, 누구의 승인으로 했는지를 하나의 타임라인에 기록하는 세션 안에서 돌아갈 때에요. Alpacon에서는 에이전트와 사람이 그 타임라인을 공유하고, 각 기록은 그 동작을 실행한 정확한 자격증명을 명시합니다. 그 맥락이 없는 커맨드 로그는 감사가 아닙니다.

감사 로그와 감사 이력(audit trail)은 어떻게 다른가요? 로그는 이벤트의 흐름, 즉 무슨 일이 일어났는가입니다. 이력은 그 이벤트에 책임성을 부여하는 맥락, 즉 아이덴티티, 목적, 승인, 결과를 더해 그것이 속한 세션과 작업에 연결한 것입니다. 차이는 '무엇이 실행됐나'만이 아니라 '누가 그걸 승인했고, 왜'에 답할 수 있느냐입니다.

Alpacon이 우리 컴플라이언스 리포트를 만들어 주나요? 리포트가 만들어지는 근거인 권한 접근 증빙, 즉 세션마다의 목적·승인·스코프·결과를 담고 질의 가능한 상태로 유지합니다. 프레임워크에 매핑된 증빙(SOC 2, ISO 27001, HIPAA)를 자동 생성하는 것은 아직 로드맵 단계이며, 그것도 권한 접근 조각으로 한정됩니다. Alpacon이 여러분의 GRC 플랫폼 전체는 아닙니다.

사람과 에이전트가 같은 감사 기록에 나오나요? 네. 그게 하나의 Work Session 타임라인의 핵심입니다. 사람이든 에이전트든 같은 이력 위에서 인증된 아이덴티티로 귀결되니, '누가 이걸 했나'에 세 개의 도구를 교차 확인하는 대신 하나의 답이 나옵니다.

프로덕션 인프라에 에이전트를 사용하고 있다면, 감사는 사고가 터진 뒤가 아니라 터지기 전에 설계에 넣어 뒀길 바라게 되는 부분입니다.