장애 대응 로그 읽기를 소재로 한 조사 게임 'Ghost in the Log'를 제작했습니다. 실제 로그는 일절 다루지 않으며, 공개 버전에서는 백그라운드에서 AI가 실제로 로그를 읽고 원인 후보를 반환합니다.
1. 서론
심야의 장애 대응으로 로그를 들여다보고 있으면 조금 신비로운 기분이 듭니다. 수상해 보이는 줄, 아무것도 아닌 것 같은 줄. 그 사이에 진짜 원인이 숨어 있습니다.
에러 로그는 한 줄만 보면 단순한 단편일 뿐입니다. 단편만 보면 나도 모르게 이야기를 꾸며 채우고 싶어집니다. 본 작품은 그 '채워 넣는 방식'을 안전한 장소에서 연습하기 위해 만들었습니다.
DEV Hacktoberfest Open-Source AI Challenge Week 4의 테마인 'Ghost in the Machine'에 맞춘 할로윈 버전 앱입니다.
공개 리포지토리 (MIT, npm 의존성 없음, Node 20+):
공개 데모:
2. 주요 기능
가상의 인시던트 3건을 준비했습니다. 사건을 선택하여 조사를 진행하는 형식입니다.
각 사건에서는 번호가 매겨진 로그를 읽습니다. '가능한 원인', '근거가 되는 줄', '아직 모르는 것'의 세 가지로 나누어 생각합니다.
화면은 기본적으로 영어이며, 한국어로도 전환할 수 있습니다.
3. 작동 방식
로그는 발생 순서대로 배열되어 있습니다. 먼저 원인 후보를 하나 제시합니다. 어떤 줄이 뒷받침이 되는지, 어떤 줄이 맞지 않는지, 어디에 결정적인 증거가 부족한지를 확인합니다.
이렇게 만든 이유가 있습니다. 실무에서 위험한 것은 가장 그럴듯한 이야기가 보였다는 순간 증거 확인을 멈추어 버리는 것입니다.
로그에 번호를 매긴 것도 그 때문입니다. '근거는 이 줄입니다'라고 말할 수 있게 되면, 이야기는 감상이 아니라 증거 검토가 됩니다.
4. 사용 방법
- 앱을 실행합니다 (로컬에서 구동하는 경우, 리포지토리를 clone하여 Node 20+로 시작).
- 3건의 사건 중 1건을 선택합니다.
- 로그를 읽고 AI가 반환하는 원인 후보/근거 줄/모르는 것과 대조해봅니다.
npm 의존성이 없기 때문에 로컬에서도 바로 구동할 수 있습니다.
5. 설계상의 고려: AI를 구동해도 안전한 공개 형태
가장 고민했던 부분입니다. 로그 조사 형태의 도구는 본래 운영(Production) 로그를 붙여 넣고 싶게 만듭니다. 그 로그가 그대로 AI에 유입되는 구조라면 공개하기 어렵다고 생각했습니다.
그래서 진입점을 과감하게 좁혔습니다.
선택할 수 있는 것은 준비된 3건의 가상 사건뿐입니다. 자유롭게 문장을 입력하는 칸은 없습니다. 실제 로그를 붙여 넣는 장소도 없습니다. AI에게 전달되는 것은 선택한 사건 ID와 언어뿐입니다. 읽게 하는 로그 본문은 서버 측에서 준비한 것을 사용합니다.
로그는 AI에게 '명령'이 아니라 '자료'로 취급됩니다. 반환된 답은 형식을 체크한 후에 표시됩니다. 원인 후보, 근거 줄 번호, 모르는 것. 이 3가지가 갖춰지지 않은 답은 내보내지 않습니다.
호출 횟수에도 제동을 걸었습니다. AI에게 보내기 전에 공유 데이터베이스(Neon)에서 예약을 하고, 끝나면 기록합니다. 예약이 안 되면 보내지 않습니다. 결과가 불분명해져도 임의로 재전송하지 않습니다. 접수를 닫으면 더 이상 전송되지 않습니다.
사용하는 모델은 오픈 웨이트인 Muse Spark Open입니다. 호스팅된 추론 API(Baseten)를 통해 호출하고 있습니다. 초기 테스트는 자체 관리 GPU 인프라(Modal)에서 Gemma를 구동하여 진행했습니다. 동작 자체에는 문제가 없었으나, 호출할 때마다 GPU를 띄우는 구성은 시간 과금이 많이 발생합니다. 공개 버전에서는 같은 오픈 웨이트 모델을 API 경유로 호출하는 형태로 전환했습니다. 대기 비용이 들지 않고, 가중치(weight)가 공개되어 있다는 점은 동일합니다. 모델을 구동할 장소를 선택할 수 있다는 것은 '중요한 로그를 외부로 유출하지 않는다'는 설계도 생각하기 쉽게 만듭니다. 이번 로그는 가상의 것이지만, 사고방식은 실제 로그에서도 같습니다. 참고로 공개는 기간과 횟수를 제한했습니다.
물론 이것으로 AI의 답이 반드시 정확해지는 것은 아닙니다. 막을 수 있는 것은 '예상치 못한 입력이 들어오는 것'과 '모르는 사이에 호출이 증가하는 것'입니다. 답변의 정확성은 별개의 문제이며, 보장할 수는 없다고 알려드립니다.
6. 제작 과정 및 배경
구현을 시작한 것은 2026년 10월 28일입니다. 코드는 AI 코딩 에이전트가 작성했고, 저는 지시와 승인을 담당했습니다.
10월 29일에는 AI를 사용하지 않는 데모를 공개했습니다. 먼저 AI 없이도 플레이할 수 있는 형태를 만들었기 때문에, 나중에 AI를 연결할 때 기반이 흔들리지 않게 할 수 있었습니다.
10월 30일에는 데이터 저장소를 Neon(Postgres)으로 옮기고 Vercel에 올리면서 두 가지를 연결했습니다.
그 이후가 하이라이트였습니다. 안전을 위해 공개 버전은 고정된 데모 결과로 되돌릴지 하는 방안도 있었습니다. 하지만 진입점을 가상의 사건에만 한정하면, 그대로 공개해도 AI를 구동할 수 있습니다. 게이트가 있는 시험 환경에서 가상의 DB 로그로부터 원인 후보, 근거가 되는 행, 알 수 없는 것을 반환하는 것이 정상적으로 작동함을 확인했습니다. 조건이 갖춰졌기에, 마지막으로 게이트를 열었습니다.
공개 버전은 현재 백그라운드에서 AI가 구동되는 형태로 공개할 수 있게 되었습니다.
7. 기존 도구와의 차이점
일반적인 로그 도구는 실제 데이터를 빠르게 찾는 데 목적을 두고 있습니다. 본 작품은 그 반대입니다. 여기서 요구되는 것은 검색의 속도가 아니라 판단력입니다. 준비된 증거만으로 어디까지 확신할 수 있는지, 그것을 생각하는 연습의 장으로 만들었습니다.
입력 방식의 사고방식도 다릅니다. 실제 로그를 받으면 편리하겠지만, 현장의 로그에는 기밀 정보나 개인 정보가 섞이기 쉽습니다. 본 작품은 그 진입점 자체를 갖지 않는 것을 사양(仕様)으로 선택했습니다.
감시 제품이라기보다는 훈련을 위한 교재에 가깝게 제작되었습니다.
8. 주의사항
- 사건 3건 모두 가상의 것입니다. 실제 로그는 입력할 수 없습니다 (사양).
- AI가 반환하는 것은 원인의 '후보'입니다. 진단을 확정하는 것이 아닙니다.
- 사건은 3건만 다루는 작은 세트이며, 포괄적인 교재는 아닙니다.
- 악용 및 비용 문제에 대비하여 AI 호출 횟수에 상한선을 두었습니다.
- 개발 중인 시험 환경은 제한된 횟수만을 사용하므로, AI 답변의 품질을 보장하지 않습니다.
피드백 부탁드립니다
실제로 만져보시고, 잘 된 점, 어려웠던 점, 걸렸던 부분을 이 글의 댓글로 알려주세요. 실제로 사용해 보신 감상이 다음 개선에 가장 큰 도움이 됩니다.
9. 요약
Ghost in the Log는 로그를 '원인・근거・알 수 없는 것'으로 나누어 읽는, 작은 할로윈 조사 게임입니다.
유령의 정체는 대개 착각에서 비롯됩니다. 그럴듯한 이야기만 쫓지 않고, 증거가 도착하는 지점에서 결론을 멈추는. 그 당연한 연습을 재미있게 할 수 있도록 만들었습니다.
공개 방식도 같은 사고방식입니다. AI를 막는 것이 아니라, AI에게 전달할 것을 먼저 정해두는 것입니다. 입력을 가상의 사건으로 한정하고, 횟수에 상한선을 두며, 답변의 형식을 체크합니다. 여기까지 결정했기에, 공개 버전에서도 AI를 구동할 수 있었습니다.
재미있어 보인다면 꼭 만져보세요.
해피 할로윈, 그리고 해피 인베스티게이션! 🎃
