지난주 DevDay Exchange Community 해커톤에 다녀왔습니다. 현장에서는 두 개의 트랙이 함께 진행됐고, 저는 1번 트랙인 AI for Safety & Resilience에 참가했어요. 안전과 재난이라는 주제가 딱딱해서 사람이 많지 않을 거라 생각했는데, 막상 가 보니 생각보다 훨씬 많은 사람이 1번 트랙에 모여 있어서 놀랐습니다. 재난 대응을 AI로 풀어 보고 싶은 사람이 이렇게 많다는 게 반가웠죠.
제가 만든 서비스는 '아직 여기'입니다. 대규모 재난 상황에서 구조를 기다리는 사람이 한 명도 남지 않도록, 그리고 구조대원들이 최적의 경로와 정보를 받으면서 움직일 수 있도록 돕는 AI 상황실 서비스예요. 코드는 GitHub 저장소에 전부 올려 두었습니다.
▸ 세 명 중 두 명을 구조했을 때
태풍이나 집중호우가 오면 같은 현장에서 신고가 여러 건 들어옵니다. 당사자가 문자를 보내고, 가족이 대신 전화를 걸고, 출동한 뒤에도 사진과 메시지가 계속 도착하죠. 상황실이 이걸 하나의 사건으로 묶어 보지 못하면 같은 곳에 구조팀을 두 번 보내거나, 대신 신고한 가족의 GPS를 구조 대상자의 위치로 착각하거나, 세 명 중 두 명을 구조하고 사건을 닫아 버리는 일이 생깁니다. 그래서 이 서비스가 붙잡고 있는 질문은 "신고를 몇 건 처리했는가"가 아니라 "아직 안전이 확인되지 않은 사람이 남아 있는가"입니다.
시연 사례는 태풍으로 침수된 가상의 지하주차장이에요. 할머니와 여자아이, 성인 여성 세 명이 갇혀 있습니다. 문자에는 "여자 세 명이 갇혔다"고만 적혀 있고, 전화 음성에는 물소리와 잡음이 섞여 있죠. 그리고 신고자가 직접 찍은 사진이 한 장 들어옵니다.
상황실 화면에 들어온 사진 신고. 가운데에는 시간순으로 쌓이는 신고 원문과 첨부 사진이, 오른쪽에는 구조팀의 현장 진행 기록이 보입니다. 사진은 시연용으로 생성한 합성 이미지예요. 출처: 아직 여기 서비스 화면
AI는 기둥에 적힌 B2 / C07을 읽어 위치 후보로 제시합니다. 여기서 중요한 건 "후보"라는 단어인데요, 사진 한 장으로 주소나 GPS까지 알아냈다고 확정하지 않습니다. 사진 아래로는 음성 신고가 이어지고, 잡음이 섞인 원본과 잡음을 줄인 음성을 나란히 들어 볼 수 있어요. 잠시 뒤 구조팀이 할머니와 여자아이를 구조했다고 보고하고, 성인 여성에게서 "저는 아직 안에 있어요"라는 문자가 도착합니다.
사건 상단에 구조 대상 위치와 접수 인원, 담당팀이 정리되고, 그 아래 판단·조치 카드가 접수 3명과 현장 확인 2명을 대조해 1명이 미확인이라고 알려 줍니다. 출처: 아직 여기 서비스 화면
이 카드에서 "3명 중 1명 미구조"를 계산하는 건 LLM이 아니라 규칙입니다. 접수된 인원과 현장 근거로 확인된 인원을 대조하고, 숫자가 맞지 않으면 사건을 완료 처리하지 못하게 막아요. AI는 첨부를 읽고 위치 후보, 중복 신고 후보, 신고자에게 다시 물어볼 질문 같은 초안을 쓰는 데까지만 하고, 사건에 반영하려면 담당자가 확인해야 합니다. 사람 목숨이 걸린 숫자를 모델의 판단에 맡기고 싶지 않았거든요.
구조대원을 위한 화면도 만들었습니다. "3층 창가 쪽"이라는 말만으로는 위치가 잘 그려지지 않으니, 공개된 건물 도면을 Codex로 해석해 공간 모형을 만들고, 층을 잘라 신고 원문의 위치 후보와 대조해 보여줍니다.
3층을 잘라 복도와 계단, 창가 위치 후보를 표시한 건물 공간정보 화면. 공개 도면을 바탕으로 만든 목업입니다. 출처: 아직 여기 서비스 화면
출동 경로는 OSM 도로 데이터 위에서 계산합니다. 비가 많이 오는 날을 가정해 보죠. 관악소방서에서 도림천 옆 신림 신원시장 주변으로 출동한다면, 먼저 구난작업차의 폭 2.5m와 높이 3.2m, 좌우 여유까지 넣어 차가 지나갈 수 없는 길을 뺍니다. 그다음 서울시가 공개한 침수흔적도를 지도에 겹쳐 놓고, 과거에 물이 찼던 구간을 덜 지나는 경로를 따로 계산하죠.
출동경로 안내 화면. 붉은 점들이 과거 침수흔적이고, 보라색 선이 침수 이력을 고려한 경로입니다. 초록색은 훈련 추천 경로, 주황 점선은 최단 경로예요. 출처: 아직 여기 서비스 화면
지도를 보면 최단 경로와 훈련 추천 경로는 도림천 쪽 골목으로 내려가고, 침수 이력을 고려한 경로는 하천에서 떨어진 북쪽 큰길로 크게 돌아갑니다. 거리는 최단 경로가 2.91km, 침수 이력 고려 경로가 3.49km로 600m쯤 더 길고, 예상 시간도 1분 늘어나요. 대신 침수흔적 주변 10m 안을 지나는 거리가 155m에서 18m로 줄어듭니다.
세 경로의 비교 카드. 거리와 예상 시간, 방향 전환 횟수와 함께 침수흔적을 얼마나 지나는지 보여줍니다. 출처: 아직 여기 서비스 화면
물론 과거에 물이 찼던 길이 지금도 잠겨 있다는 뜻은 아니고, 실시간 교통도 반영하지 않습니다. 화면 맨 위에 "훈련 가정 · 현장 검토 필요"라는 경고를 늘 띄워 둔 것도 그 때문이에요.
그런데, 아쉬운 점도 있었습니다. 이번 해커톤에서는 Codex 외에 다른 LLM이나 서비스를 전혀 쓸 수 없었어요. 오픈AI가 후원하는 행사니 이해는 됩니다. 다만 재난 현장의 신고 음성은 물소리와 잡음에 묻히고, 겁에 질린 사람은 말을 제대로 잇지 못하죠. 시연용 음성을 만들고 잡음 속 목소리를 가려내는 데 ElevenLabs 같은 음성 특화 API를 붙일 수 있었다면 훨씬 완성도 있게 만들 수 있었을 겁니다. 실제로 시연 음성의 가상 지명이 엉뚱한 지명으로 전사되는 오류도 있었고요. 다음에는 후원사가 오픈AI라도 이런 부분은 조금 감안해 주면 좋겠네요.
▸ 4분짜리 무대
예선 발표는 단 4분이었습니다. 저는 당연히 AI Judge가 심사할 거라고 생각했어요. Codex가 만들어 낸 이 방대한 코드와 문서를, 사람이 4분짜리 발표만 눈으로 보고 선발한다는 건 상상하지 못했거든요. 그래서 서비스 전체에 GEO를 적용했습니다. 자바스크립트를 실행하지 못하는 AI 도구도 서비스의 목적과 업무 흐름, 한계를 읽을 수 있도록 정적 HTML을 따로 만들고, 문서 색인과 본문 전체를 담은 llms.txt, 입력 자료와 검사 명령, 실제 모델 실행 여부를 구조화한 evidence.json까지 준비했죠. (점수를 달라는 문구 같은 건 절대 넣지 않았습니다. ㅎㅎ)
그런데, 정말 4분짜리 발표만 보고 뽑았나 봐요. 결과는 예선 탈락이었습니다. 솔직히 무척 당황스러웠고, 앞으로 해커톤에 나가야 할지 꽤 고민이 되더라고요. Codex와 함께 쌓은 코드와 검증 기록, 실패 기록까지 4분 안에 보여줄 방법은 애초에 없었으니까요.
돌아보면 너무 현실적인 고민만 했던 게 탈락의 원인이었을 수도 있습니다. AI가 판단을 확정하지 못하게 막고, 화면 곳곳에 "후보", "미확인", "과거 이력" 같은 단서를 붙였죠. 실제 상황실이라면 꼭 필요한 장치지만, 4분짜리 무대에서는 화려한 AI 데모보다 눈에 덜 띄었을 겁니다. 그렇다고 50대 두 명이 참가해서 아이디어가 별로였다는 생각은 들지 않습니다. 구조를 끝내기 전에 남은 한 명을 끝까지 세는 일이 이 문제의 본질이라는 생각은 지금도 그대로예요.
그래도 이번에 확실하게 느낀 게 있습니다. Codex든 Claude든, 어떤 서비스를 만들겠다고 마음먹으면 하루 만에 MVP를 뚝딱 만들 수 있다는 사실이요. 상황실 콘솔과 AI 분석, 데이터베이스, 건물 공간정보, 출동 경로까지 하루 안에 공개 서비스로 올라간 걸 다시 봐도 놀랍습니다. 함께 해커톤에 참여해 주신 Caselnes 님께도 감사드립니다. 그리고 생각보다 훨씬 많은 참가자를 맞아 두 트랙을 동시에 꾸려 주신 해커톤 운영진 분들, 정말 고생 많으셨습니다. 다음엔 4분 안에 보여줄 장면부터 고민해 봐야겠네요.
커버 이미지: 시연용 합성 신고 사진, 침수된 지하주차장의 B2 / C07 기둥 — 아직 여기 서비스 화면
전체 사이트에서 댓글·관련 글을 함께 보시려면
이야기 공장에서 보기 →