devrives
ENKR

Meta 해커톤 회고: 수상작 14개에서 배운 것과 건물 출구 공개 데이터

5분 분량

핵심 요약

  • Meta 해커톤 제출작 5,300개가 넘는 가운데 14개가 상을 받았고, 제 HereOut은 받지 못했어요.
  • 수상작 대부분은 Meta 도구를 3~6개 쓰며 모델에게 큰 일을 맡기고 코드로 결과를 검증했어요. 저는 모델 하나에 작은 일만 맡겼어요.
  • 인디 트랙 2위 Gatekeeper는 대회 기간에 나중에 악성으로 확인된 npm 패키지 48개를 공개 목록보다 중앙값 25시간 먼저 잡았고, 누구나 그 시각을 확인할 수 있게 했어요.
  • HereOut은 14개 국가·지역의 피난안내도 사진에서 출구를 절반쯤 찾았어요. 건물 출구가 공통 형식의 공개 데이터로 있다면 사진을 읽을 필요가 없어요.

Meta Global AI Developer Hackathon 인디 트랙에 HereOut으로 나갔고, 상은 받지 못했어요. 제출작 5,300개가 넘는 가운데 14개가 상을 받았고, 수상작을 읽어 보니 제 패착이 보였어요. 만들면서 건물 출구가 공개 데이터로 있다면 외국 건물에서도 출구를 더 쉽게 찾을 수 있겠다는 생각도 들었어요.

HereOut이 한 일

HereOut은 벽에 붙은 피난안내도를 찍으면 출구를 찾고, 내가 누른 위치에서 가장 가까운 출구까지 길을 그려 주는 웹 앱이에요. 모델은 Meta의 Muse Spark 하나를 썼어요. Muse Spark가 출구와 안내도의 글자를 읽고, 벽과 경로는 코드가 그렸어요.

심사는 네 가지 기준으로 했어요.

항목배점
Impact30%
Meta AI 도구 활용25%
기술 깊이와 완성도20%
데모25%

수상작은 모델에게 큰 일을 맡겼어요

먼저 도구 활용부터 보면, 수상작 14개 중 대부분은 Meta 도구를 3~6개 썼어요. 인디 트랙 1위 ControlAnything은 Quest 3 헤드셋으로 실제 기기를 보고 말하면 Spark 에이전트가 연결 코드를 쓰고 테스트해요. 모델이 큰 일을 하고, 코드가 그 결과를 검증해요.

저는 반대로 갔어요. 모델이 틀릴까 봐 모델이 맡는 일을 점점 줄였어요. 처음에는 안내도의 "현재 위치" 표시도 모델이 읽게 했는데, 나중에는 사용자가 직접 누르게 바꿨어요. Meta 모델은 Muse Spark 하나만 썼고, 25%짜리 도구 활용 항목에서 점수를 얻기 어려워졌어요. 게다가 이 배점은 제가 아이디어를 고른 뒤에 공개됐는데, 그때 아이디어를 다시 점검하지 않았어요.

붐비는 주제도 이길 수 있어요

주제를 고르는 방식에서도 차이가 났어요. 인디 트랙 2위 Gatekeeper는 npm1 악성 패키지 탐지라는, 상용 도구가 이미 많은 주제로 상을 받았어요. 대회 기간에 새 패키지를 실시간으로 감시했고 나중에 악성으로 확인된 패키지 48개를 공개 목록보다 중앙값 25시간 먼저 잡았어요. 탐지 시각은 누구나 볼 수 있는 기록에 미리 남겨서, 심사위원이 숫자를 믿을 필요 없이 직접 확인할 수 있었어요.

저는 아이디어를 고를 때 "이미 하는 사람이 많은 주제"를 걸렀어요. 그런데 Gatekeeper를 보면 주제가 새로운지보다 대회 기간에 확인할 수 있는 결과가 있는지가 더 중요했던 것 같아요.

돌아보니 더 아팠던 건 분야였어요. 에이전트가 판정하고 코드가 근거를 검증하는 보안 도구는 제가 평소에 만드는 형태인데, 그 분야 아이디어는 후보에 올리지도 않았어요. 기존 제품과 이어지는 아이디어부터 찾다 보니 소비자용 안전 앱으로 좁혀졌어요.

데모는 영상으로, 첫 문장은 가장 강한 숫자로

만든 것을 보여 주는 방식도 달랐어요. 수상작 14개는 모두 YouTube 영상을 냈어요. 저는 영상 칸에 소리 없는 화면 녹화 영상 링크를 넣었어요. 데모 배점이 25%인데 실제 안내도 앞에서 쓰는 장면도, 설명하는 목소리도 없었어요.

제출문에서는 순서가 아쉬웠어요. 저는 HereOut이 출구를 절반쯤 찾는다는 정확도를 글 한가운데에 두었어요. 숨기지 않은 건 맞았지만, Gatekeeper처럼 강한 결과를 먼저 보여 주고 한계를 뒤에 밝히는 순서가 더 나았을 거예요.

출구를 절반만 찾은 이유

그 "절반"이라는 숫자는 이렇게 나왔어요. HereOut은 14개 국가·지역의 피난안내도 사진 28장에서, 안내도가 분명히 표시한 출구의 53%를 찾았어요. 반대로 HereOut이 출구라고 짚은 곳 중에서는 47%만 실제 출구였어요. 앞선 실행에서 틀린 출구는 계단 문 대신 옆의 표지판이거나, 복도의 방향 표시인 경우가 많았어요.

다만 언어는 큰 문제가 아니었어요. HereOut은 안내도 카드를 영어 외에 12개 언어로 보여 주고 원문도 함께 보여 줘요. 어려웠던 건 그림이었어요. 피난안내도 그림은 ISO 23601이라는 국제 표준이 있지만, 미국은 주와 지역의 소방 규정을 따르는 등 나라마다 따르는 규칙이 달라요. 사진 속 안내도도 나라마다, 건물마다 생김새가 달랐어요.

출구가 공개 데이터라면

제각각인 그림을 읽느라 애쓰다 보니, 애초에 그림을 읽지 않아도 되면 어떨까 하는 생각이 들었어요. 건물 출구 위치가 공통 형식의 공개 데이터로 있다면, 여행자의 휴대폰은 사진을 읽어 추측할 필요가 없어요. 그런 데이터를 담을 형식은 이미 있어요. Apple이 만든 실내 지도 형식 IMDF에는 비상구 문 유형(emergencyexit)이 있고, 건물 설계 데이터 표준 IFC에는 문과 공간에 비상구 여부(FireExit)를 적는 칸이 있어요.

없는 건 그 형식으로 공개된 데이터예요. 한국은 민방위 대피시설을 매일 갱신하는 공공데이터로 내고, 일본도 지정긴급피난장소를 공개해요. 다만 둘 다 어디로 대피할지를 알려 줄 뿐, 건물 안 출구 위치는 없어요.

정작 건물 안 출구 위치를 프로그램이 읽을 수 있는 공개 데이터로 내는 곳은 한국, 일본, EU, 미국에서 찾지 못했어요. 한국에서 가장 가까운 건 다중이용업소의 비상구 설치 여부를 집계한 자료와 역사 준공도면이었어요. 집계 자료에는 위치가 없고, 도면은 고쳐 쓰거나 상업적으로 쓸 수 없어요.

누구나 고칠 수 있는 지도 OpenStreetMap에도 이런 데이터는 드물어요. 건물은 약 7억 1,400만 개 등록돼 있지만, 비상 출입구(entrance=emergency)가 표시된 곳은 전 세계 29,235곳뿐이에요(2026년 11월 9일(UTC) 기준).

저는 이 빈칸이 두 쪽에서 줄어들 거라고 봐요. 하나는 AI예요. 안내도 그림을 읽는 정확도가 오르면 사진 한 장이 곧 출구 데이터가 돼요. 다른 하나는 공개예요. 건물 출구가 공개 데이터로 나오면 사진 없이도 길을 찾을 수 있어요.

다음 대회에서 바꿀 것

그래서 다음 대회에서는 이렇게 하려고 해요.

  1. 아이디어는 제가 잘 아는 분야에서 먼저 찾아요.
  2. 모델에게 큰 일을 맡기고 코드로 결과를 검증해요.
  3. 주최사 도구를 여러 개, 각자 실제 역할로 써요.
  4. 배점이 공개되거나 바뀌면 아이디어를 다시 점검해요.
  5. 대회 기간에 누구나 확인할 수 있는 결과를 만들어요.
  6. 실제로 쓰는 장면과 목소리가 있는 영상을 YouTube에 올려요.

출처

각주

  1. npm은 자바스크립트 개발자들이 코드 묶음(패키지)을 올리고 내려받는 공개 저장소예요.

공유하기

블로그로 돌아가기