EA의 AI 판단을 나중에 검증할 수 있도록 artifact로 저장하는 설계

서론

EA에 AI 판단을 통합할 때 가장 두려운 점은 "왜 그런 판단을 내렸는가"를 나중에 알 수 없게 되는 것입니다.

매매 로직 자체는 공개하지 않습니다.

이 기사에서는 EA의 내부 내용이 아니라, AI에게 전달한 입력, AI로부터의 응답, 파싱(Parsing) 후의 결과를 나중에 검증할 수 있도록 저장하는 설계에 대해 작성합니다.

테마는 AI 판단을 블랙박스(Black box) 상태로 두지 않는 것입니다.

왜 AI artifact를 남기는가

AI를 사용한 시스템에서는 동일한 입력이라도 향후 완전히 동일한 출력이 반환된다는 보장이 없습니다.

모델, 프롬프트(Prompt), 주변 컨텍스트(Context), 재시도(Retry), 파싱(Parsing) 처리가 조금만 바뀌어도 결과가 달라집니다.

EA와 같이 판단 결과가 중요한 시스템에서는 나중에 다음과 같은 질문에 답할 수 있어야 합니다.

그때 AI에게 무엇을 전달했는가
AI는 무엇을 반환했는가
애플리케이션은 어떤 JSON으로 해석했는가
...

이것이 남아 있지 않으면 결과만 보고는 원인 분석을 할 수 없습니다.

저장하는 것

AI artifact로서, 1회의 AI 호출마다 폴더를 생성합니다.

logs/ai_artifacts/YYYY-MM-DD/<HHMMSS_kind_id>/

그 안에는 다음과 같은 파일을 저장합니다.

metadata.json
prompt.txt
raw_response.txt
...

포인트는 AI의 생(raw) 응답과 애플리케이션이 해석한 JSON을 분리하여 남기는 것입니다.

raw_response.txt: AI가 반환한 그대로의 내용
parsed_response.json: EA 측에서 사용하기 위해 정규화(Normalization)한 결과

이 두 가지를 분리하면 문제가 AI 출력에 있었는지, 파서(Parser)에 있었는지를 구분하기 쉬워집니다.

kind로 용도를 구분하기

AI 호출은 한 종류가 아닙니다.

EA 측에서는 용도에 따라 kind를 나누고 있습니다.

deep_research
daily_scenario
hourly_update
...

kind를 나누어 두면 나중에 목록으로 보았을 때 무엇을 위한 AI 판단이었는지 알 수 있습니다.

예를 들어, 긴 매크로 분석인지, 통상적인 시나리오 생성인지, 단기 업데이트인지에 따라 확인해야 할 파일이나 검증 방법이 달라집니다.

판단 로그와 artifact를 연결하기

artifact를 저장하는 것만으로는 부족합니다.

실제 판단 로그 측에서 해당 artifact를 참조할 수 있어야 합니다.

그래서 시나리오나 이력 측에 artifact의 경로(Path)를 가지도록 하고 있습니다.

artifact_dir
deep_research_artifact_dir
deep_research_report_chars
...

이를 통해 특정 판단 결과를 보았을 때, 그 근거가 된 AI 입력과 출력으로 추적할 수 있습니다.

로그와 artifact가 연결되어 있지 않으면 폴더만 대량으로 남아 있어도 사용할 수 없습니다.

재시도(Retry)도 저장하기

AI 호출 시에는 실패나 불완전한 응답이 발생합니다.

따라서 최종 결과뿐만 아니라 재시도 시의 생 응답이나 에러도 저장합니다.

raw_response_attempt_1.txt
raw_response_attempt_2.txt
error_attempt_1.json

이를 남기면 다음과 같은 검증이 가능합니다.

첫 번째 시도에서만 깨진 것인가
몇 번째 시도에서 성공했는가
매번 동일한 형식으로 깨지는가
...

AI 시스템에서는 성공한 최종 결과만 보면 문제가 숨겨집니다.

실패한 중간 과정도 저장해 두면 개선 포인트를 볼 수 있습니다.

대시보드에서 확인할 수 있도록 하기

artifact는 파일로 저장하고 있지만, 매번 서버에 접속하여 폴더를 확인하는 것은 번거롭습니다.

그래서 대시보드에서 artifact 목록이나 상세 내용을 볼 수 있는 API를 준비하고 있습니다.

GET /api/ai_artifacts?limit=100
GET /api/ai_artifacts/detail?path=<artifact path>
GET /api/ai_artifacts/file?path=<file path>

이를 통해 최신 AI 판단, metadata, 파일 목록, prompt, raw response, 차트 이미지 등을 확인할 수 있습니다.

운용 중의 검증에서는 보고 싶을 때 즉시 볼 수 있는 것이 중요합니다.

로그가 남아 있어도 접근하기 어려우면 결국 보지 않게 됩니다.

백테스트(Backtest)에서 재사용하기

artifact를 저장하는 목적은 감사(Audit)뿐만이 아닙니다.

나중에 백테스트(Backtest)나 리플레이(Replay)에서 재사용할 수 있습니다.

AI 호출을 매번 다시 수행하면 비용과 시간이 소요될 뿐만 아니라, 결과가 달라질 가능성도 있습니다.

저장된 artifact를 사용하면 과거 시점의 AI 출력을 고정하여 검증할 수 있습니다.

AI 출력을 고정
로직 변경만을 비교
동일한 가격 데이터로 차이(Difference)를 확인
...

이는 AI를 포함한 시스템의 검증에서 매우 중요합니다.

AI의 출력과 로직이 동시에 바뀌면, 무엇 때문에 결과가 바뀌었는지 알 수 없게 됩니다.

공개할 때의 주의사항

EA 관련 내용은 민감하므로 공개 범위를 좁힐 필요가 있습니다.

이 글에서 다루는 것은 artifact logging 설계뿐입니다.

공개하지 않을 것은 명확하게 결정해 두었습니다.

매매 로직
진입 조건 (Entry Condition)
파라미터 (Parameter)
...

공개하는 것은 AI 판단을 나중에 검증할 수 있도록 하는 설계 사상과 로그 구조까지입니다.

요약

EA에 AI 판단을 통합한다면, AI의 출력을 사용하는 것뿐만 아니라 나중에 검증할 수 있는 형태로 저장해야 합니다.

prompt를 저장
raw response를 저장
parsed response를 저장
...

AI 판단은 그 자리에서 맞았는지 틀렸는지만 봐서는 개선하기 어렵습니다.

나중에 "왜 그렇게 판단했는가"를 볼 수 있도록 해두는 것이 AI를 운용에 통합하기 위한 토대라고 느꼈습니다.

Discussion