제가 작성했던 「23년 동안 살아남은 동네슈퍼를 데이터로 분석해보려 합니다. (2편)」을 ‘요즘IT’에 게재하고 싶다는 제안이었습니다.

평소에도 요즘IT에서 새로운 기술이나 흥미로운 프로젝트, 다른 기업과 조직에서는 AI를 어떻게 적용하고 있는지에 관한 글을 자주 읽어왔습니다. 그런 매거진에 제가 만든 프로젝트와 글이 실린다는 사실이 처음에는 조금 얼떨떨했습니다.

내가 만든 작은 동네 슈퍼 프로젝트가 다른 사람에게도 읽을 만한 이야기가 될 수 있구나.

현재는 군 복무 중이기 때문에 당장 정기적으로 글을 쓰기는 어렵지만, 전역 이후에는 정식 작가로 꾸준히 기고해보지 않겠느냐는 제안도 받았습니다. 전역한 뒤에는 개인 블로그에도 계속 기록하겠지만, 조금 더 다듬어진 글은 요즘IT를 통해 자주 공유하게 될 것 같습니다.

이번 3편에서는 2편 이후 프로젝트가 어디까지 확장되었는지, 그리고 데이터를 많이 모으는 것만으로는 왜 점주의 의사결정을 도울 수 없었는지를 정리해보려 합니다.

2편까지는 POS에 갇혀 있던 데이터를 꺼내는 일이었다

2편까지 제가 한 일은 단순했습니다.

기존 나들가게 POS에서 월별 매출, 거래 건수, 객단가, 현금매출과 카드매출 데이터를 크롤링하고, 이를 Supabase에 저장해 별도의 대시보드에서 볼 수 있도록 만들었습니다.

기존 POS에서도 데이터를 조회할 수는 있었습니다. 그러나 과거 데이터를 조회할 때마다 직접 하나씩 하나하나 조회해야 했고, 여러 메뉴에 정보가 흩어져 있어 전체 흐름을 한눈에 파악하기 어려웠습니다.

그래서 한 번 수집한 과거 데이터는 데이터베이스에 저장하고, 이후부터는 복잡한 POS 사이트에 다시 접속하지 않고 바로 불러오는 구조로 변경했습니다.

그 결과, POS가 처음 도입된 2011년의 매출과 2026년의 매출을 같은 화면에서 비교할 수 있는 기반이 만들어졌습니다.

이 단계까지만 해도 나름대로 의미가 있었습니다.

오래된 시스템 안에 갇혀 있던 데이터를 외부로 꺼냈고, 과거의 기록을 빠르게 탐색할 수 있게 되었기 때문입니다.

하지만 여전히 알 수 있는 것은 다음 정도였습니다.

• 이번 달 매출이 얼마인지
• 지난달보다 올랐는지 내렸는지
• 거래 건수가 늘었는지
• 객단가가 달라졌는지
• 현금과 카드의 비중이 어떻게 변했는지

매출이 왜 달라졌는지 알려면 결국 무엇이 팔렸는지까지 내려가야 했습니다.

이번에는 ‘얼마나 팔렸는가’에서 ‘무엇이 팔렸는가’로 내려갔다

이번에 가장 먼저 추가한 것은 상품 상세 데이터였습니다.

기존에는 하루 총매출과 거래 건수만 가져왔다면, 이제는 POS의 다른 메뉴에 들어가 다음 정보까지 수집하도록 만들었습니다.

• 국산담배류, 아이스크림류, 소주 등 중분류별 매출
• 에쎄 수, 떡붕어싸만코처럼 실제 판매된 세부 상품
• 상품별 판매수량과 매출액
• 해당 상품에서 남긴 매출이익
• 거래가 발생한 시간
• 같은 영수증에 포함된 다른 상품

이 데이터는 월매출 달력보다 수집하기 더 어려웠습니다.

상품별 이익은 ‘일일 분류별 상품판매 현황’에 있었고, 몇 시에 어떤 상품이 팔렸는지는 별도의 ‘상품 판매내역 조회’ 화면에 있었습니다. 결국 두 화면을 각각 크롤링한 뒤, 날짜와 상품을 기준으로 다시 연결해야 했습니다.

특히 거래내역 화면은 하루치 영수증을 하나씩 열어 상품을 확인해야 했습니다. 어떤 날은 하루 데이터를 가져오는 데만 몇 분이 걸렸습니다.

그래서 최근 데이터만 가져오는 것으로 끝내지 않고, 과거 날짜를 하루씩 거슬러 올라가며 자동으로 수집하는 백필 과정을 만들었습니다.

월별 매출 데이터는 2011년까지 수집을 마쳤지만, 상품과 영수증 단위의 상세 데이터는 양이 훨씬 많아 아직도 수집 중입니다. 현재는 대략 2014년의 데이터까지 내려가며 차근차근 데이터베이스에 쌓고 있습니다.

그리고 이 과정을 대시보드에서 직접 확인할 수 있도록 별도의 ‘수집 현황’ 페이지도 만들었습니다.

처음에는 단순히 오래 걸리는 작업이라고만 생각했습니다.

하지만 수집 기간이 길어질수록 어느 연도까지 정상적으로 들어왔는지, 누락된 날짜는 없는지, 달력 매출과 세부 상품 매출의 합계가 일치하는지를 확인하는 기능도 중요해졌습니다.

데이터가 많아지면 수집 자체보다 제대로 수집되었는지를 검증하는 일이 더 어려워진다는 사실도 알게 되었습니다.

데이터가 쌓이자 결국 무료 요금제를 벗어나게 됐다

처음에는 개인 프로젝트이기 때문에 Supabase 무료 요금제로도 충분할 것이라고 생각했습니다.

하지만 영수증 거래 데이터만 60만 건을 넘어섰고, 영수증에 포함된 개별 상품 행은 100만 줄 이상 쌓였습니다. 일별 상품 집계 데이터까지 더해지면서 데이터베이스 용량은 빠르게 증가했습니다.

결국 Supabase 무료 요금제에서 제공하는 500MB 한도를 넘겼습니다.

오래된 데이터를 삭제하거나 최근 2년 정도만 보관하는 방법도 생각해볼 수 있었습니다. 하지만 이 프로젝트를 시작한 중요한 이유 중 하나가 2011년부터 이어진 가게의 데이터를 한곳에 모으는 것이었습니다.

과거 데이터를 삭제하면 비용은 줄어들겠지만, 이 프로젝트가 가진 가장 중요한 자산도 함께 사라지게 됩니다.

결국 Supabase Pro 요금제로 업그레이드했고, 현재 매달 약 3만 8천 원 정도를 지불하고 있습니다.

개인 사이드 프로젝트에 매달 비용을 내는 것이 부담스럽지만, 10년이 넘는 실제 가게의 원장을 보존하고 분석하는 비용이라고 생각하고 유지하기로 했습니다.

데이터가 늘어나면서 대시보드의 구조도 다시 나눴다

상품과 시간대 정보가 추가되자 기존 한 화면에 모든 내용을 담기 어려워졌습니다.

그래서 상단 메뉴를 크게 다음과 같이 구분했습니다.

• 오늘
• 월별
• 판단
• 날씨

처음 화면을 열면 ‘오늘’ 탭이 나타납니다.

점주가 가게에서 가장 먼저 궁금해할 정보는 과거의 장기 추세보다 오늘 장사가 어떻게 되고 있는지이기 때문입니다.

‘오늘’ 탭에서는 현재까지의 매출, 거래 건수, 객단가, 예상 이익과 함께 오늘 판매된 주요 상품군과 세부 상품을 보여줍니다.

반면 ‘월별’ 탭에서는 한 달 동안 누적된 데이터를 기준으로 다음 내용을 확인할 수 있도록 했습니다.

• 일별 매출 흐름
• 평균적으로 매출이 높은 요일
• 거래가 가장 많은 시간대
• 중분류별 매출과 이익
• 세부 상품별 매출·이익·판매량 순위
• 현금과 카드 결제 비중

실제로 데이터를 확인해보니 담배, 소주, 맥주가 전체 매출에서 매우 큰 비중을 차지하고 있었습니다. 세 상품군을 합치면 매출의 절반에 가까운 기간도 있었습니다.

그런데 여기서 재미있는 점이 하나 있었습니다.

매출이 높은 날이 반드시 돈을 많이 남긴 날은 아니었습니다.

어떤 날은 음식물 쓰레기 종량제 스티커가 많이 판매되면서 매출액 자체는 높게 나타났습니다. 하지만 이 상품은 가게에 남는 이익이 거의 없기 때문에 매출 순위만 보면 좋은 날처럼 보이지만, 실제 이익 측면에서는 그렇지 않았습니다.

이 경험을 통해 단순한 매출 순위가 점주에게 잘못된 인상을 줄 수 있다는 사실을 확인했습니다.

얼마나 많이 팔렸는가와 실제로 얼마가 남았는가는 전혀 다른 질문이었습니다.

보기 좋은 대시보드만 만들고 싶었던 것은 아니었다

사실 제가 처음부터 만들고 싶었던 것은 POS를 현대적으로 다시 디자인한 화면이 아니었습니다.

기존보다 정보를 보기 쉽게 만들고, 토스처럼 중요한 숫자가 먼저 들어오도록 UI를 구성하는 것도 필요했습니다. 하지만 그것만으로는 기존 POS를 조금 예쁘게 다시 만든 것에 불과합니다.

제가 정말 만들고 싶었던 것은 다음 구조였습니다.

Raw Data
무엇이 언제 얼마에 팔렸는가

↓  

Calculation
요일·시간·상품·이익의 관계를 코드와 공식으로 계산

↓

Decision
그래서 점주가 무엇을 확인하거나 바꿔볼 것인가

여기서 중요한 점은 계산을 LLM에 맡기지 않는 것입니다.

매출 변화율, 판매지수, 동반구매율, 상품별 마진과 같은 숫자는 SQL과 코드로 계산합니다. LLM은 이미 계산된 결과를 점주가 이해할 수 있는 문장으로 바꾸는 역할만 맡도록 했습니다.

LLM이 원본 데이터를 보고 자유롭게 판단하게 하면 그럴듯하지만 근거가 불분명한 설명을 만들 가능성이 있기 때문입니다.

그런데 첫 번째 ‘인사이트’는 별로 유의미하지 않았다

처음에는 이런 판단 카드를 만들었습니다.

13시 방문을 이익으로 전환할 기회가 있어요.

13시는 거래 건수가 많지만 객단가가 낮으므로 계산대 근처에 고마진 상품을 배치해보라는 내용이었습니다.

처음 화면에 띄웠을 때는 꽤 그럴듯해 보였습니다.

하지만 점주의 입장에서 다시 생각해보니 별로 의미 있는 정보가 아니었습니다.

• 정확히 어떤 상품을 놓아야 하는지
• 이러한 패턴이 하루만 나타난 것인지 반복되는지
• 실제로 얼마나 이익이 늘어날 수 있는지
• 단골 한두 명의 반복 구매로 만들어진 패턴은 아닌지

어느 것도 충분히 설명하지 못했습니다.

결국 ‘데이터를 분석한 문장’처럼 보일 뿐, 실제 행동을 바꿀 만큼 구체적인 판단은 아니었습니다.

그래서 이 카드를 제거하고, 계산 계층을 다시 설계했습니다.

반복되는 패턴만 판단 후보로 올리기 시작했다

이후에는 하루의 숫자 하나를 보고 인사이트를 만들지 않도록 했습니다.

예를 들어 특정 상품이 금요일에 많이 팔렸다고 판단하려면 다음 조건을 함께 계산합니다.

• 최근 8주 동안 비교 가능한 금요일이 충분히 존재하는지
• 8주 중 몇 주에서 같은 패턴이 반복됐는지
• 다른 요일보다 얼마나 많이 팔렸는지
• 최근 4주 동안 증가하거나 감소하고 있는지
• 결과를 만들 수 있는 데이터가 충분히 수집되었는지

이를 바탕으로 다음과 같은 결과를 만들고자 했습니다.

최근 8주 금요일 중 7주에서 12~14시 아이스크림 판매량이 다른 시간대보다 높았습니다.

단순히 “금요일에 아이스크림이 많이 팔립니다”라고 말하는 것보다, 표본과 반복성을 함께 보여주는 방식입니다.

‘더 준비하세요’라는 표현도 조심했습니다.

현재 데이터에는 실제 재고 수량이나 발주 단위가 없기 때문에 정확히 몇 개를 주문해야 하는지는 알 수 없습니다. 그래서 시스템에서는 ‘발주량’이 아니라, 과거 판매량의 중앙값과 최근 추세를 기준으로 목표 준비량을 보여주도록 만들었습니다.

가게의 시간을 하나의 리듬처럼 보기 시작했다

데이터가 충분히 쌓이면서 각각의 표를 나열하는 것보다, 가게의 운영 구조를 한 번에 보고 싶다는 생각이 들었습니다.

그래서 ‘판단’ 탭을 일종의 가게 디지털 트윈처럼 다시 구성했습니다.

물론 공장의 설비나 물류 흐름을 실시간으로 복제하는 거창한 디지털 트윈은 아닙니다. 이 가게에서 반복되는 시간과 상품의 구조를 데이터로 옮겨놓았다는 의미에 가깝습니다.

이 화면은 네 가지 관점으로 구성했습니다.

1. 시간대 리듬

요일과 시간을 히트맵으로 연결해, 언제 가게의 거래가 집중되는지 보여줍니다.

실제로 데이터를 확인해보니 요일에 관계없이 대체로 오후 5시에서 8시 사이가 가장 중요한 시간대로 나타났습니다.

단순히 피크 시간만 보여주는 것이 아니라, 오전 812시, 1216시, 1620시, 2024시로 나누어 각 시간대에 어떤 상품과 상품 조합이 주로 판매되는지도 연결했습니다.

2. 계절 달력

월별로 어떤 카테고리의 비중이 달라지는지 여러 해의 평균으로 계산했습니다.

아이스크림처럼 계절성이 명확한 상품뿐 아니라, 같은 계절에도 매년 반복적으로 증가하거나 감소하는 상품군을 확인할 수 있습니다.

3. 명목 매출과 실질 성장

2011년보다 지금의 매출이 높다고 해서 가게가 실제로 더 많은 상품을 판매한다고 볼 수는 없습니다.

그동안 상품 가격 자체가 올랐기 때문입니다.

그래서 공식 소비자물가지수와는 별개로, 우리 가게에서 여러 해 동안 공통으로 판매된 상품들의 단가 변화를 이어 붙인 자체 단가지수를 만들었습니다.

이를 통해 매출이 가격 상승 때문에 오른 것인지, 실제 거래와 상품 판매가 늘어 오른 것인지를 구분해보려 했습니다.

이 지수는 공식 물가지표가 아니라 어디까지나 우리 가게의 판매가격을 기준으로 계산한 지표라는 점도 화면에 함께 표시했습니다.

4. 상품의 세대교체

같은 카테고리 안에서도 시간이 지나면서 대표 상품이 바뀝니다.

과거에 많이 팔렸던 상품의 점유율이 줄어들고 새로운 상품이 이를 추월하는 시점을 찾아, 어떤 제품이 어떤 제품으로 대체됐는지 시각화했습니다.

데이터에서는 박카스 중심이던 에너지음료 수요가 몬스터 같은 새로운 상품으로 이동하는 모습도 확인할 수 있었습니다.

과거에 무엇이 팔렸는지를 단순히 보여주는 것은 “그때는 그랬구나”에서 끝날 가능성이 큽니다.

제가 찾고 싶었던 것은 과거의 기록 자체가 아니라, 현재 상품 운영에 영향을 줄 만큼 반복되거나 구조적으로 변한 패턴이었습니다.

함께 사가는 상품도 데이터로 꺼내보았다

영수증 단위의 상품 데이터가 생기면서 어떤 상품을 함께 구매하는지도 계산할 수 있게 되었습니다.

다만 판매 건수가 많은 상품끼리는 우연히 함께 잡힐 가능성도 높습니다.

그래서 단순 동반구매 횟수뿐 아니라, 두 상품이 각각 팔릴 확률과 비교해 실제로 함께 구매될 가능성이 몇 배 높은지를 나타내는 lift도 함께 계산했습니다.

그 결과 POS에 기록된 상품명을 그대로 기준으로 다음과 같은 조합을 발견했습니다.

• [시원]360ml 보조상표(통합) + 카스1000L 98회 함께 판매, 일반적인 경우보다 20.5배 높은 조합
• [시원]360ml 보조상표(통합) + 팔리아멘트 아쿠아5 53회 함께 판매, 일반적인 경우보다 22.8배 높은 조합

부모님은 오랫동안 가게를 운영했기 때문에 어떤 상품이 함께 팔리는지 어느 정도 이미 알고 계셨을 수 있습니다.

다만 그동안은 경험과 감각으로 알고 있던 사실을 데이터상에서 정확한 횟수와 수치로 꺼낼 수 있게 되었습니다.

그렇다고 이 결과만 보고 곧바로 두 상품을 묶어 팔거나 진열을 바꾸는 것은 아닙니다.

두 상품을 함께 산 사람이 실제로 여러 명인지, 한 명의 단골이 반복해서 구매한 것인지 현재 POS 데이터만으로는 알 수 없기 때문입니다.

결국 동반구매 분석도 정답이라기보다 점주가 현장을 다시 살펴볼 질문의 출발점에 가깝습니다.

2011년부터의 날씨도 가게 데이터와 연결했다

이번에는 POS 밖의 데이터도 처음으로 연결했습니다.

기상청 데이터를 활용해 2011년부터 현재까지 부산의 기온, 습도, 강수량, 운량 등의 날씨 정보를 수집했습니다.

현재는 약 5,690일의 일별 날씨와 13만 건이 넘는 시간대별 관측 데이터가 쌓여 있습니다.

처음에는 같은 달과 같은 요일 안에서 날씨가 더운 날과 그렇지 않은 날을 비교했습니다.

하지만 15년 가까운 데이터가 생기자 같은 달에만 한정할 필요가 없다는 생각이 들었습니다.

작년 8월과 올해 7월이라도 기온과 습도, 강수 조건이 비슷하다면 가게의 입장에서는 충분히 비교할 수 있는 날이기 때문입니다.

그래서 현재는 강수 여부를 먼저 나누고, 기온·습도·운량이 오늘과 가장 비슷했던 과거 날짜를 전 기간에서 찾는 방식으로 변경했습니다.

그 뒤 비슷한 날들에 평소보다 더 팔렸던 상품과 덜 팔렸던 상품을 보여줍니다.

예를 들어 단순히 “더운 날에는 아이스크림이 잘 팔립니다”라고 보여주는 것은 큰 의미가 없습니다.

대신 다음과 같이 보여주는 것이 목표입니다.

오늘과 비슷한 날씨였던 과거 20일에서 비비빅은 하루 평균 9개, 메로나는 3.2개 더 판매됐습니다.

판매량이 0.02개에서 0.4개로 올랐다면 수치상으로는 20배지만, 실제로는 하루 0.38개 차이에 불과합니다.

그래서 배수보다 하루에 실제로 몇 개 더 팔렸는지를 기준으로 순위를 정했습니다.

다만 이것 역시 인과관계라고 단정할 수는 없습니다.

기온이 비슷한 날에 특정 상품이 함께 많이 팔렸다는 사실을 보여줄 뿐, 날씨 때문에 해당 상품이 팔렸다고 확정하는 것은 아닙니다. 계절, 요일, 상품의 출시 시점과 단종 여부 같은 다른 요인도 함께 영향을 줍니다.

따라서 날씨 탭도 현재는 정답을 알려주는 기능이라기보다, 내일 무엇을 조금 더 준비해볼지 판단할 근거를 제공하는 단계에 있습니다.

LLM은 계산하지 않고, 계산된 결과만 설명하게 했다

분석 결과를 점주가 읽기 쉬운 문장으로 바꾸기 위해 LLM API도 연결했습니다.

하지만 LLM이 매출 원장을 직접 보고 계산하거나, 자유롭게 상품 운영 방법을 추천하도록 하지는 않았습니다.

역할을 다음과 같이 분리했습니다.

SQL과 코드
판매량·마진·반복성·동반구매·날씨 효과를 계산

LLM
계산된 수치와 한계를 사람이 이해하기 쉬운 문장으로 정리

LLM이 실패하거나 API를 사용할 수 없는 경우에도 판단 기능이 멈추지 않도록, 같은 내용을 정해진 문장으로 출력하는 템플릿도 함께 만들었습니다.

결국 이 시스템에서 LLM은 판단을 만들어내는 두뇌라기보다, 이미 계산된 결과를 점주의 언어로 번역하는 인터페이스에 가깝습니다.

기능을 추가할수록 서비스는 느려졌다

이번 프로젝트를 하면서 개발자분들이 새삼 대단하다고 느낀 순간도 많았습니다.

이 서비스는 사실상 한 사람, 많아야 가족 몇 명이 사용하는 개인용 서비스입니다. 대규모 트래픽이 발생하지도 않고, 수많은 사용자가 동시에 요청을 보내지도 않습니다.

그런데도 상품 데이터, 판단 탭, 날씨 데이터처럼 기능을 하나씩 추가할 때마다 탭 이동이 느려지고 로딩 시간이 길어졌습니다.

과거 데이터를 매번 다시 계산하면 화면을 열 때 오래 기다려야 했고, 백필 작업이 브라우저를 사용하고 있으면 오늘 데이터를 수집하는 작업이 밀리기도 했습니다.

이를 해결하기 위해 다음과 같은 방법을 계속 추가했습니다.

• 변하지 않는 과거 데이터는 데이터베이스에서 즉시 조회
• 무거운 분석은 사용자가 접속했을 때가 아니라 야간에 미리 계산
• 계산 결과는 스냅샷 형태로 저장
• 사용자가 새로고침하면 과거 백필 작업이 브라우저를 양보
• 한 번 계산한 값은 캐시에 저장
• 누락되거나 합계가 맞지 않는 날짜는 별도로 탐지해 재수집

혼자 사용하는 서비스에서도 이 정도의 고민이 생겼습니다.

그렇다면 토스처럼 수많은 사용자가 동시에 접속하고, 계속 새로운 기능이 추가되는 서비스에서 백엔드 개발자분들은 얼마나 많은 통신 방식과 캐싱, 동시성, 데이터 정합성 문제를 고민하고 있을까 하는 생각이 들었습니다.

화면에서는 버튼을 한 번 누르면 바로 다음 정보가 나오지만, 그 자연스러운 경험 뒤에 얼마나 많은 최적화가 숨어 있는지 조금이나마 체감할 수 있었습니다.

바이브코딩에도 기억을 보존하는 장치가 필요했다

기능이 많아지면서 또 다른 문제가 발생했습니다.

Claude나 Codex를 이용해 바이브코딩을 하다 보면 새로운 터미널과 새로운 대화창에서 작업을 시작하게 됩니다.

그러면 이전 대화에서 왜 특정 구조를 선택했는지, 어떤 오류 때문에 방어 로직을 추가했는지가 사라집니다.

새로운 AI는 현재 코드만 보고 다음과 같이 판단할 수 있습니다.

이 부분은 복잡해 보이니 제거해도 되겠습니다.

하지만 실제로는 과거에 발생했던 데이터 오염이나 삭제를 막기 위해 일부러 복잡하게 만들어둔 코드일 수 있습니다.

실제로 프로젝트에서는 같은 날 같은 이름을 가진 다른 상품이 한 번에 들어오면서 저장 배치 전체가 실패한 적도 있었습니다. 그 문제로 1,000일이 넘는 상품 데이터가 정상적으로 저장되지 않았고, 백필 작업도 과거로 내려가지 못한 채 같은 구간을 반복하고 있었습니다.

또 수집이 2014년에서 멈춘 이유를 처음에는 데이터베이스 용량이나 POS 보관기간 때문이라고 의심했지만, 실제로는 앞선 저장 오류로 미완료 날짜가 쌓여 과거 날짜까지 내려가지 못한 것이 원인이었습니다.

이런 맥락을 모르는 AI가 코드를 단순화하면 이미 해결한 문제가 다시 발생할 수 있었습니다.

그래서 SSOT.md라는 문서를 만들었습니다.

SSOT는 Single Source of Truth, 즉 하나의 기준이 되는 문서라는 의미입니다.

이 문서에는 다음 내용을 계속 기록했습니다.

• 프로젝트가 어떤 문제를 해결하는지
• 현재 데이터베이스 구조
• 각 파일이 맡는 역할
• 왜 특정 구조를 선택했는지
• 과거에 발생한 장애와 실제 원인
• 제거하거나 변경하면 안 되는 로직
• 현재 진행 중인 작업과 다음 단계

AI에게 새로운 작업을 맡길 때도 먼저 이 문서를 읽도록 했고, 중요한 구조를 변경하면 코드와 함께 SSOT도 갱신하도록 했습니다.

바이브코딩은 코드를 빠르게 만드는 데에는 매우 유용합니다.

하지만 프로젝트가 길어질수록 중요한 것은 코드를 빨리 생성하는 능력보다 왜 이런 코드가 존재하는지를 잊지 않는 능력이라는 사실도 알게 되었습니다.

동네 슈퍼의 데이터는 편의점 데이터와 다르다

이 프로젝트에서 계속 경계하고 있는 부분도 있습니다.

우리 가게는 불특정 다수가 끊임없이 방문하는 대형 매장이나 프랜차이즈 편의점이 아닙니다.

주변에 거주하는 단골손님과 매일 담배나 술을 사러 오는 고객의 비중이 높습니다.

따라서 특정 상품 조합이 많이 나타났다고 해서 많은 고객이 공통으로 선호한다고 단정할 수 없습니다. 한 명의 단골이 같은 조합을 반복해서 구매했기 때문에 만들어진 결과일 수도 있습니다.

고객 ID가 없는 POS 데이터만으로는 이를 완전히 구분하기 어렵습니다.

예를 들어 데이터를 분석하니 월요일에는 캔커피가 평소보다 약 2.3배 많이 팔리는 패턴이 나타났습니다.

하지만 이 수치만 보고 월요일마다 캔커피를 두 배로 발주하는 것은 위험합니다.

먼저 현장에서 다음 질문을 해봐야 합니다.

• 월요일마다 특정 단골이 대량으로 구매하는 것은 아닌가?
• 주변 사업장의 근무 일정과 관련이 있는가?
• 특정 납품이나 작업 일정이 월요일에 몰려 있는가?
• 실제로 진열 위치를 바꾸면 추가 판매로 이어질 수 있는가?

이 시스템이 해야 할 일은 “월요일에는 캔커피를 더 주문하세요”라고 정답을 말하는 것이 아닐 수 있습니다.

오히려 부모님이 오랜 경험 속에서 놓치고 있던 패턴을 꺼내 다음과 같은 질문을 던지는 것이 더 중요할 수 있습니다.

월요일에 캔커피가 반복적으로 더 팔리는 이유가 무엇일까? 이 패턴을 이용해 함께 판매할 상품이나 준비 방식을 바꿔볼 수 있을까?

필요한 데이터는 거의 모았다. 이제 진짜 어려운 문제가 남았다

처음에는 POS 데이터를 가져오는 것 자체가 가장 어려운 문제라고 생각했습니다.

엑셀 다운로드도 제대로 지원하지 않는 오래된 사이트에서 데이터를 크롤링하고, 2011년부터의 기록을 데이터베이스에 저장하는 일이 가장 큰 과제처럼 보였습니다.

그런데 지금은 생각이 달라졌습니다.

데이터를 모으는 것은 어렵지만, 언젠가는 끝납니다.

진짜 어려운 문제는 그다음입니다.

수집한 데이터를 어떤 기준으로 연결하고, 어떤 차이를 의미 있는 변화로 판단하며, 어떤 결과만 점주에게 보여줄 것인가.

수많은 숫자를 보여주는 것은 쉽습니다.

그러나 그중 실제로 부모님의 다음 행동을 바꿀 만한 신호를 찾아내는 것은 전혀 다른 문제입니다.

현재 시스템은 과거와 비슷한 날, 특정 요일과 시간대의 평균, 함께 팔린 상품, 날씨 조건에 따른 판매 차이를 보여줄 수 있는 단계까지 왔습니다.

하지만 아직은 대부분 관찰과 비교에 가깝습니다.

앞으로는 여기서 한 단계 더 나아가고 싶습니다.

• 어떤 패턴이 우연이 아니라 반복되는지
• 어떤 상품은 늘리고 어떤 상품은 줄여볼지
• 진열 위치를 바꾸면 실제 이익이 늘어나는지
• 추천한 행동을 실행한 뒤 결과가 어떻게 달라졌는지
• 부모님의 현장 경험과 데이터가 서로 충돌할 때 무엇을 다시 확인할지

결국 제가 만들고 싶은 것은 가게 운영의 정답을 대신 내려주는 AI가 아닙니다.

점주가 그냥 지나쳤을 수 있는 변화를 발견하고, 무엇을 확인하고 시험해볼지 더 정확한 출발점을 제시하는 시스템입니다.

23년 동안 가게를 운영해온 부모님의 경험을 데이터로 대체하는 것이 아니라, 그 경험이 새로운 질문을 만날 수 있도록 돕는 것.

그것이 이 프로젝트가 다음 단계에서 풀고 싶은 문제입니다.

AX 인재전쟁은 유튜브에서 조코딩님의 영상을 통해 처음 알게 되었습니다.

저는 AI-native 조직과 AX에 관심이 많습니다. 단순히 ChatGPT를 잘 사용하거나 업무에 AI 기능 하나를 추가하는 것을 넘어, 조직의 업무 방식 자체를 AI에 맞게 다시 설계하는 것에 관심을 가지고 있었습니다.

그런 점에서 기업이 겪는 문제를 직접 정의하고, 해결책을 프로덕트와 플러그인 형태로 만들어 제출해야 한다는 예선 방식은 처음에는 당황스러우면서도 저와 잘 맞는 방식이라고 생각했습니다.

다만 저는 군 복무 중이었기 때문에 예선을 준비할 수 있는 시간이 약 3일 정도밖에 없었습니다. 원래는 최대 3개의 기업 트랙에 지원할 수 있었지만, 여러 트랙에 어설프게 지원하기보다 하나의 문제를 깊게 파고들기로 했습니다.

그렇게 선택한 곳이 삼일PwC였습니다.

예선: AI를 도입했지만 감사 업무의 병목은 왜 사라지지 않았을까

예선을 준비하면서 가장 먼저 한 일은 회계법인이 실제로 겪고 있는 문제를 찾는 것이었습니다.

조사 과정에서 대형 회계법인들이 AI 챗봇과 내부 플랫폼, 문서 검색 도구 등을 빠르게 도입하고 있지만, 실제 감사 실무에서는 AI의 활용이 문서 검색이나 계약서 초안 작성처럼 개별 기능에 머물러 있다는 내용의 기사를 접했습니다.

오히려 자체 모델을 학습시키기 위해 고객사의 조서와 자료를 정리하고 입력하는 업무가 추가되면서, 실무자의 업무가 기대만큼 줄지 않는다는 문제도 언급되고 있었습니다.

저는 여기서 문제를 다음과 같이 정의했습니다.

회계법인은 감사 업무를 줄이기 위해 AI를 도입했지만, 감사 업무 전체의 흐름을 다시 설계하지 않은 채 개별 기능 단위로 AI를 붙였다. 그 결과 AI는 문서를 검색하거나 초안을 작성하는 보조도구에 머물렀고, 감사 업무의 전체 병목을 해결하지 못했다.

문서를 찾아주는 기능 하나가 빨라진다고 해서 감사 업무 전체가 자동화되는 것은 아닙니다.

감사 업무에서는 고객사로부터 자료를 요청하고, 도착한 자료가 어떤 거래와 관련된 것인지 확인하고, 전표와 증빙을 매칭하고, 필요한 감사절차를 수행한 뒤, 그 결과를 조서로 작성해야 합니다. 자료가 부족하면 다시 고객사에 요청해야 하고, 이 모든 과정에서 감사인이 검토하고 책임져야 합니다.

따라서 저는 AI 기능을 여러 개 만드는 대신, 감사 업무 전체의 워크플로우를 먼저 구조화하고 그 흐름 안에서 AI가 각 업무를 수행하도록 해야 한다고 판단했습니다.

예선에서 만든 제품

최종적으로 제품의 콘셉트를 다음과 같이 정했습니다.

감사 시즌의 전표·증빙·감사절차·조서를 연결하는 실무형 AI 워크플로우

고객사가 제출하는 자료는 Excel, CSV, PDF, 스캔된 PNG 이미지 등 형식이 제각각입니다. 따라서 먼저 문서의 형식과 관계없이 내용을 추출하고, 이를 감사 업무에서 사용할 수 있는 표준 객체로 변환하도록 설계했습니다.

그 위에서 전표와 증빙을 연결하고, 필요한 자료가 모두 제출됐는지 확인하며, 감사절차와 조서 초안까지 연결하는 흐름을 만들고자 했습니다.

전체 구조는 다음과 같습니다.

이를 흐름으로 표현하면 다음과 같습니다.

고객사 제출자료
Excel / CSV / PDF / PNG
        ↓
문서 내용 추출 및 표준화
        ↓
전표·증빙·감사절차·조서 객체 생성
        ↓
전표와 증빙 자동 매칭
        ↓
필수자료 완전성 검사
        ↓
누락·불일치·예외 항목 탐지
        ↓
조서 초안 및 보충자료 요청 메일 작성
        ↓
근거 문서와 판단 흐름 시각화
        ↓
감사인의 최종 검토·판단

이 제품을 기획하며 가장 중요하게 생각한 원칙은 AI가 최종 감사판단을 하지 않는 구조였습니다.

AI는 자료를 추출하고, 매칭하고, 누락을 찾고, 조서와 메일의 초안을 작성할 수 있습니다. 그러나 어떤 항목을 감사상 중요한 예외로 볼 것인지, 감사의견에 어떤 영향을 주는지는 감사인이 판단해야 합니다.

AI가 감사인을 대체하는 것이 아니라, 감사인이 책임져야 하는 업무에 더 집중할 수 있도록 그 앞단의 반복적인 작업을 정리하는 것이 제품의 본질이라고 생각했습니다.

실제 고객 데이터를 확보할 수는 없었기 때문에 GPT를 이용해 전표, 증빙, 계약서, 거래명세서 등의 합성 데이터를 만들었습니다. 이를 GitHub에 업로드하고, 제출된 데이터로 실제 데모가 동작하도록 구현했습니다.

그렇게 예선 제품을 제출했습니다.

문제가 정해져 있지 않은 해커톤은 부실한 해커톤일까

AX 인재전쟁 예선에서 가장 논란이 되었던 부분은 명확한 문제나 데이터셋이 제공되지 않았다는 점이었습니다.

“문제를 알아서 찾고 해결해서 제출하라”는 방식에 대해, 운영이 부실한 것이 아니냐는 반응도 있었습니다. 탈락 이후 본선 진출작을 전부 공개해 달라는 의견도 적지 않았습니다.

물론 참가자 입장에서는 문제 범위와 평가 기준이 더 명확하게 느껴졌다면 준비가 수월했을 것입니다. 하지만 저는 이 방식 자체가 잘못됐다고 생각하지는 않았습니다.

지금은 AI를 통해 코드를 만들고, 화면을 구성하고, 문서를 작성하는 것 자체는 이전보다 훨씬 쉬워졌습니다. 오히려 더 중요한 역량은 다음과 같은 것이라고 생각합니다.

• 어떤 현상을 문제로 볼 것인가
• 그 문제가 실제로 존재한다는 근거는 무엇인가
• 표면적인 증상이 아니라 원인은 무엇인가
• 누구를 위한 문제인가
• 해결책이 실제 업무 흐름을 어떻게 바꾸는가

결국 요구되는 것은 결과물을 빠르게 만드는 사람이 아니라, 문제를 발견하고 정의해 해결 가능한 구조로 바꾸는 Problem Solver에 가깝습니다.

실제로 운영 측 설명에 따르면 예선 제출물의 약 3분의 1은 자신이 정의한 문제의 출처나 근거가 되는 기사, 보고서, 보도자료 등을 명확히 제시하지 못했다고 합니다.

문제를 자유롭게 정할 수 있었다는 것은 아무 문제나 상상해서 제출해도 된다는 뜻이 아니라, 문제의 존재부터 스스로 증명해야 한다는 뜻이었습니다.

저는 오히려 이 지점이 예선에서 중요했다고 생각합니다.

생각지도 못했던 본선 진출

예선 제출 후 약 일주일 정도가 지났을 때였습니다.

사지방에서 연등을 하던 중 본선 진출 메일을 확인했습니다. 기대하지 않았던 결과였기 때문에 기쁘면서도 당황스러웠습니다.

본선 전날까지 별도의 프로덕트를 미리 만들 수는 없었습니다. 어떤 문제가 나올지, 어떤 데이터가 제공될지 알 수 없었기 때문입니다.

대신 GPT와 한 번의 긴 대화를 진행했습니다.

삼일PwC 트랙의 문제는 유튜브를 통해 일부 공개된 내용을 보면 Trusted CEO Agent를 만드는 것이었습니다. 결국 CEO가 여러 조직의 정보를 종합해 더 빠르고 신뢰할 수 있는 의사결정을 내리도록 돕는 에이전트가 필요하다고 생각했습니다.

저는 조직에서 의사결정이 느려지는 이유를 다음과 같이 가정했습니다.

각 부서에는 그 조직에서만 통하는 암묵지와 판단기준이 존재합니다. 같은 사건이라도 영업팀은 주문으로 보고, 생산팀은 생산능력으로 보며, 재무팀은 매출과 현금으로 봅니다. 데이터는 존재하지만 서로 다른 시스템과 시간축에 흩어져 있어 CEO가 하나의 맥락으로 이해하기 어렵습니다.

그래서 본선에서 데이터가 제공되면 먼저 회사와 부서의 행위를 정의하고, 단순한 숫자를 사건과 관계로 변환해야 한다고 생각했습니다.

날짜를 사건으로 바꾸고, 사건의 순서를 인과가설로 바꿔야 한다.

누가 어떤 결재를 올렸는지, 어떤 원료가 어느 생산 배치에 사용됐는지, 그 배치가 언제 출하되고 언제 고객 클레임으로 이어졌는지를 하나의 흐름으로 볼 수 있어야 한다고 생각했습니다.

그 정도의 방향성만 정리한 뒤, 다음 날 새벽 4시에 일어나 첫차에 가까운 KTX를 타고 서울로 향했습니다.

본선: 3시간 안에 CEO Agent 만들기

본선은 오전 10시에 시작해 오후 1시까지 제출해야 하는 3시간짜리 해커톤이었습니다.

주어진 문제를 요약하면 다음과 같습니다.

Aurora Holdings의 CEO가 두 자회사에 흩어진 자료를 종합해, 5일 뒤 이사회에서 Top 3 Agenda와 90일 Action Plan, 가용자금 300억원의 활용 방향을 제시할 수 있도록 Trusted CEO Agent를 만들어라.

Aurora Holdings는 화장품 제조사인 Corevia Cosmetics와 유통사인 Masil Commerce를 자회사로 두고 있었습니다. 여기에 더마 원료기업 Celtonic Labs의 인수까지 검토하고 있었습니다.

문제와 함께 거의 60개에 가까운 데이터와 문서가 주어졌습니다. 주문, 출하, 생산능력, 품질검사, 원료 로트, 고객 클레임, 마케팅 캠페인, 반품, 재고, 발주, 현금전망, 계약, 투자 검토자료 등이 모두 섞여 있었습니다.

시나리오와 데이터를 분석하면 다음과 같은 충돌이 나타났습니다.

1. 출하는 정상인데 신규 발주는 감소하고 있었습니다.
2. 내부 검사에서는 규격을 통과했지만 고객 단계에서는 불량 클레임이 발생했습니다.
3. GMV, 즉 주문금액은 증가했지만 실제 현금은 감소했습니다.
4. 공식 현금전망에서는 문제가 없었지만, 확정된 발주 지급일을 반영해 재계산하면 Covenant 기준 아래로 내려갈 가능성이 있었습니다.

제공된 데이터에는 단순한 오류뿐 아니라 서로 다른 종류의 충돌이 존재했습니다.

• 실제 계산 결과가 문서의 주장과 다른 경우
• 서로 다른 지표가 상반된 신호를 주는 경우
• 하나의 원인가설을 지지하면서 동시에 반박하는 데이터가 존재하는 경우
• 공식 전망과 확정된 일정의 반영 범위가 다른 경우

이를 한 문장으로 표현하면 다음과 같습니다.

성과가 좋아 보이는 문서와 실제 데이터를 기반으로 한 계산 결과가 일치하지 않았다.

CEO는 각 부서의 보고서 중 하나를 선택해 믿는 것이 아니라, 어떤 데이터와 계산을 기준으로 판단해야 할지 확인해야 했습니다.

그런데 문제를 제대로 이해하기 전에 만들기 시작했다

문제는 시간이었습니다.

약 60개의 데이터를 사람이 하나씩 열어보고 연결하기에는 3시간이 너무 짧았습니다. 문제를 읽고 데이터를 분석하는 데만 30분 이상을 사용해야 했고, 그 이후에는 프로덕트를 설계하고 실제 화면까지 구현해야 했습니다.

저는 모든 데이터를 AI에게 전달하고 다음을 요청했습니다.

• 데이터 사이에 어떤 충돌이 존재하는가
• 시나리오의 주장과 실제 계산은 어떻게 다른가
• CEO가 중요하게 봐야 할 의사결정은 무엇인가
• 어떤 문제를 Primary Issue로 선택해야 하는가

AI는 빠르게 여러 시사점을 정리해 줬습니다. 저는 그 결과를 바탕으로 문제를 이해하고 프로덕트를 만들기 시작했습니다.

당시에는 이것이 AI를 잘 활용하는 방법이라고 생각했습니다. 제한된 시간 안에 사람이 보기 어려운 양의 데이터를 AI로 분석하고, 사람이 제품 방향을 결정한다고 생각했습니다.

하지만 돌이켜보면 저는 데이터를 분석하는 일을 AI에게 맡긴 것에 그치지 않고, 문제를 바라보는 프레임 자체도 AI가 제시한 해석에 상당 부분 의존하고 있었습니다.

AI가 발견한 숫자가 맞는지 일부를 다시 검증했지만, 시간이 부족해 전체 흐름을 직접 이해하지 못했습니다. 그러다 보니 “왜 이 문제가 중요한가”를 제 언어로 설명하기보다, AI가 정리한 문제와 시사점을 제품에 옮기는 데 급급해졌습니다.

AI를 이용해 문제를 빠르게 이해하려 했지만, 어느 순간부터는 제가 AI를 활용한 것이 아니라 AI가 정리한 해석을 따라가며 제품을 만들고 있었습니다.

본선에서 만든 Aurora Decision Trace

제가 선택한 문제는 단순히 문서와 계산이 다르다는 것이 아니었습니다.

조금 더 근본적으로 다음과 같이 접근했습니다.

데이터는 많지만 품질, 생산, 영업, 재무, 마케팅 데이터가 서로 다른 시스템과 시간축에 흩어져 있어 하나의 CEO 의사결정으로 연결되지 않는다.

예를 들어 C-201이라는 대형 신규 고객 입찰에 참여할지를 결정하려면 영업 데이터만 봐서는 안 됩니다.

• 고객이 요구하는 생산물량
• 기존 라인의 잔여 생산능력
• 더마 제품의 품질 문제
• 원료 로트와 생산 배치
• 기존 고객과 Masil에 공급해야 할 물량
• 설비투자 금액과 리드타임
• 입찰계약의 지연·회수 책임

을 함께 봐야 합니다.

그래서 저는 여러 부서의 데이터를 하나의 의미세계로 연결하고, CEO가 특정 안건을 선택하면 관련된 사실, 계산, 가설, 반대증거, 미확인 정보와 승인조건을 확인할 수 있는 제품을 만들었습니다.

전체 구조는 다음과 같았습니다.

부서별 데이터·문서
품질 / 생산 / 영업 / 재무 / 마케팅 / 계약
        ↓
데이터 표준화 및 객체 매핑
고객 / 제품 / 원료 / 배치 / 계약 / 캠페인 / 현금
        ↓
정적 온톨로지
회사·부서·고객·제품·공급사·승인권한
        ↓
동적 이벤트
원료 입고·생산·출하·클레임·발주·현금지급
        ↓
계산 및 규칙
불량률·생산 부족량·공헌이익·현금전망·승인조건
        ↓
Decision Case
대안·경쟁가설·지지근거·반대증거·Unknown
        ↓
CEO Agenda Dashboard
현재 권고·결정기한·자금 영향·필요 승인
        ↓
Scenario Update
새로운 정보 입력
        ↓
Decision Diff
이전 판단과 변경된 판단 비교
        ↓
Human Approval
CEO·이사회·품질위원회 최종 승인

첫 화면에서는 CEO가 90일 안에 판단해야 할 Top 3 Agenda를 확인할 수 있도록 했습니다. 특정 안건을 선택하면 관련된 부서의 데이터와 경쟁가설, 반대증거, 대안을 비교할 수 있었습니다.

또한 새로운 정보가 들어오면 어떤 가설이 강화됐는지, 기존 권고가 왜 변경됐는지, 후속 Action과 승인자가 어떻게 달라졌는지를 Decision Diff로 보여주도록 설계했습니다.

제가 중요하게 생각했던 것은 AI가 원인을 함부로 단정하지 않는 것이었습니다.

예를 들어 특정 원료 로트를 사용한 문제 배치가 발견됐지만, 같은 원료를 사용한 정상 배치도 존재했습니다. 따라서 “원료가 원인이다”라고 결론내리는 대신 다음 가설을 함께 보여주도록 했습니다.

• 원료 자체의 문제
• 특정 생산공정의 문제
• 고객별 사용환경이나 관찰기간의 차이
• 원료와 공정이 결합된 복합 원인

그리고 각 가설의 지지 근거뿐 아니라 반대증거와 미확인 정보를 함께 표시했습니다.

방향 자체는 문제 요구사항과 맞았습니다. 문제에서도 최소 두 가지의 합리적인 가설이나 의사결정 대안을 비교하고, 결론을 바꾸는 조건을 제시하라고 요구했기 때문입니다.

“그래서 제가 CEO라면, 저한테 뭘 팔겠다는 거예요?”

문제는 발표였습니다.

저는 심사위원에게 프로덕트가 어떤 상황에서 CEO에게 어떤 도움을 주는지 먼저 설명했어야 했습니다.

예를 들어 다음처럼 말할 수 있었습니다.

“이 에이전트는 각 부서의 보고와 실제 계산이 충돌할 때, 어떤 원천 데이터와 가정에서 차이가 발생했는지를 추적하고, CEO가 선택해야 할 대안과 결론이 바뀌는 조건을 보여줍니다.”

하지만 실제 발표에서는 Aurora의 데이터가 왜 사일로되어 있는지, 각 부서가 어떻게 다른 세계관을 가지고 있는지, 왜 의미체계 통합이 필요한지를 길게 설명했습니다.

제가 문제를 어떻게 바라봤는지를 설명하는 데 집중한 나머지, 정작 제품을 사용하는 CEO가 무엇을 얻게 되는지를 명확히 전달하지 못했습니다.

결국 심사위원 한 분이 다음과 같이 질문했습니다.

“그래서 제가 CEO라면, 저한테 뭘 팔겠다는 거예요?”

그 질문을 듣는 순간 아차 싶었습니다.

저는 문제를 설명하고 있었지만, 제품을 설명하고 있지 않았습니다.

제품이 어떤 잘못된 계산을 찾아내는지, 어떤 데이터를 다시 계산하는지, 그 결과 CEO의 어떤 결정이 달라지는지를 보여줬어야 했습니다.

하지만 저는 문제의 근본 원인을 설명하는 데 너무 많은 시간을 사용했습니다. “데이터 사일로”, “부서별 세계관”, “의미 통합”이라는 표현은 틀리지 않았지만, CEO의 구체적인 업무와 연결하지 못하면 일반론처럼 들릴 수밖에 없었습니다.

“저도 Codex를 쓰는데, 프롬프트만 주면 똑같이 만들 수 있지 않나요?”

또 다른 심사위원분은 다음과 같이 질문했습니다.

“저도 Codex를 쓰는데, 저도 똑같이 프롬프팅만 주면 만들 수 있는 것 아닌가요?”

당시에는 카메라 촬영과 마이크까지 진행되고 있었고, 예상하지 못한 질문을 받자 머리가 순간 하얘졌습니다. 제대로 답하지 못하고 의미 없는 말을 이어갔던 것 같습니다.

하지만 대회가 끝난 뒤에는 이 질문이 가장 오래 남았습니다.

처음에는 “내 프로덕트에 해자가 없다는 뜻인가?”라고 생각했습니다. 동시에 제가 실제로 제품을 이해하고 주도한 것이 아니라, AI에게 프롬프트를 주고 만들어진 결과물을 들고 온 것처럼 보였다는 의미이기도 했습니다.

실제로 제 제품은 Claude Code나 Codex를 통해 빠르게 구현됐습니다. 하지만 코드가 AI로 생성됐다는 사실 자체가 문제는 아니라고 생각합니다.

중요한 것은 다음 질문에 답할 수 있느냐는 것입니다.

• 왜 이 문제를 선택했는가
• 어떤 데이터 충돌을 직접 확인했는가
• 어떤 계산은 코드로 고정했고 어떤 판단은 LLM에 맡겼는가
• 왜 이 객체와 관계를 설계했는가
• 어떤 가정이 들어갔는가
• 다른 사람이 같은 프롬프트를 입력해도 만들 수 없는 판단구조는 무엇인가

저는 그 질문에 충분히 답할 준비가 되어 있지 않았습니다.

프로덕트의 해자는 코드의 양이나 화면의 완성도가 아니라, 문제를 이해한 사람이 설계한 데이터 모델, 계산 규칙, 검증 방식, 업무 흐름과 판단 기준에서 나와야 했습니다.

그런데 저는 그 핵심을 심사위원에게 보여주지 못했습니다.

지금 다시 만든다면 무엇을 다르게 할까

수상자의 발표를 보며 가장 인상 깊었던 것은 에이전트의 구조가 매우 명확했다는 점입니다.

제품은 다음 네 단계로 나뉘어 있었습니다.

Raw Data
→ Calculation
→ Conclusion
→ Report

CEO는 각 섹션을 직접 확인할 수 있었고, 별도의 패널에서는 하나의 보고서와 결론이 어떤 원천 데이터에서 시작됐는지를 그래프로 추적할 수 있었습니다.

이 구조가 좋았던 이유는 단순합니다.

결론을 설명하는 것이 아니라 결론이 만들어진 과정을 증명했기 때문입니다.

저는 온톨로지를 통해 여러 부서의 의미를 연결하고, 경쟁가설과 반대증거를 표현하려고 했습니다. 그 방향은 잘못되지 않았습니다. 하지만 온톨로지는 제품의 전면이 아니라 Raw Data에서 CEO 보고까지 연결하는 내부 구조로 사용했어야 했습니다.

다시 만든다면 다음과 같이 구성할 것 같습니다.

1. Raw Data

어떤 문서와 데이터 행을 사용했는지 보여줍니다.

• 출처 파일
• 기준일
• 데이터 소유 부서
• 사용한 컬럼
• 데이터의 상태
• 사실·서술·규칙 구분

2. Calculation

LLM이 아닌 코드와 공식으로 계산합니다.

• 생산 부족량
• 불량률
• 실제 공헌이익
• Real ROAS
• 확정 발주를 반영한 현금전망
• Covenant 하회 여부

계산식과 사용한 데이터, 가정을 모두 표시합니다.

3. Conclusion

계산 결과를 CEO 의사결정으로 변환합니다.

• 가능한 대안
• 경쟁가설
• 지지 근거
• 반대증거
• 미확인 정보
• 결론이 바뀌는 조건
• 현재 권고

4. Report & Action

CEO가 실제로 사용할 수 있는 결과를 만듭니다.

• 이사회 1페이지 보고
• 90일 Action Plan
• 300억원 집행·보류 방향
• 담당 부서
• 완료기한
• 필요한 승인

그리고 보고서의 각 문장을 클릭하면 어떤 Raw Data와 계산, 규칙을 거쳐 만들어졌는지 역추적할 수 있도록 만들 것입니다.

온톨로지는 이 네 단계를 연결하는 역할을 합니다.

Raw Data
원료·배치·클레임·생산능력·현금

        ↓ 온톨로지 관계

Calculation
불량률·부족량·공헌이익·현금전망

        ↓ 규칙과 Boundary

Conclusion
가설·대안·현재 권고

        ↓ 승인체계

Report & Action
CEO·이사회·품질위원회 상신

이렇게 구성했다면 “데이터 사일로를 해결합니다”라는 추상적인 설명 대신, 다음과 같이 말할 수 있었을 것입니다.

“이 에이전트는 문서의 주장과 실제 계산이 충돌할 때 원천 데이터를 다시 계산하고, 어떤 결론이 더 타당한지와 결론을 바꾸는 조건을 CEO에게 보여줍니다.”

AI를 많이 사용한 것과 AI에 끌려다니는 것은 다르다

이번 대회에서 가장 크게 배운 점은 AI를 많이 사용했다고 해서 AI-native하게 일한 것은 아니라는 점입니다.

AI-native하게 일한다는 것은 모든 분석과 개발을 AI에게 맡기는 것이 아닙니다.

AI가 많은 데이터를 빠르게 읽고 가설을 만들어 줄 수는 있지만, 무엇이 중요한 문제인지, 어떤 가설을 검증해야 하는지, 어떤 데이터는 믿을 수 없는지, 제품이 누구의 어떤 결정을 바꾸는지는 사람이 판단해야 합니다.

본선에서 저는 AI를 통해 데이터를 빠르게 분석했지만, AI가 만든 해석을 충분히 제 언어와 판단으로 바꾸지 못했습니다.

그래서 프로덕트는 만들었지만, 그 프로덕트가 왜 이런 구조여야 하는지를 심사위원에게 제대로 설명하지 못했습니다.

돌이켜보면 제게 부족했던 것은 AI 사용 역량이 아니라 문제를 좁히고 직접 검증하며, 하나의 완결된 의사결정 흐름으로 만드는 능력이었습니다.

3시간 안에 모든 조직 문제를 해결하려 하기보다, 다음 하나를 완성했어야 했습니다.

문서에서는 캠페인이 성공했다고 하지만, 실제 데이터를 계산하면 이익이 남지 않는다. Agent는 이 차이를 검증하고, 변수가 바뀔 때 계산과 권고, Action을 다시 갱신한다.

범위는 더 작지만, 제품의 역할은 훨씬 명확했을 것입니다.

그래도 본선까지 올라가서 다행이었다

대회가 끝난 직후에는 아쉬움이 컸습니다.

제가 만든 제품을 제가 제대로 이해하지 못한 것 같았고, 심사위원의 질문에 제대로 답하지 못한 장면도 계속 떠올랐습니다. 특히 카메라 앞에서 머리가 하얘졌던 순간은 당분간 잊기 어려울 것 같습니다.

하지만 시간이 지나고 다시 돌아보니, 이 경험이 없었다면 저는 계속 “근본적인 문제를 정의했다”는 것만으로 좋은 프로덕트를 만들었다고 생각했을 수도 있습니다.

좋은 문제의식은 중요합니다. 하지만 프로덕트는 문제의식을 설명하는 데서 끝나지 않습니다.

사용자에게 무엇을 제공하는지, 어떤 입력을 받아 어떤 계산을 하고, 어떤 판단과 Action으로 이어지는지가 명확해야 합니다. 그리고 그 과정이 다른 사람이 검증할 수 있어야 합니다.

이번 대회를 통해 다음을 배웠습니다.

• 근본적인 문제를 찾는 것과 제품의 범위를 좁히는 것은 별개의 일이다.
• 데이터가 많을수록 AI의 요약보다 계산과 출처 추적이 중요하다.
• 온톨로지는 목적이 아니라 판단 근거를 연결하는 수단이다.
• AI가 만든 결과물을 제출하는 것보다, 내가 어떤 판단을 내렸는지가 보여야 한다.
• 짧은 해커톤에서는 넓은 플랫폼보다 하나의 완결된 의사결정 경험이 낫다.
• 제품을 설명할 때는 “무엇을 만들었는가”보다 “사용자의 어떤 결정이 달라지는가”를 먼저 말해야 한다.

예선 준비부터 본선 발표까지 완벽하게 해낸 것은 아니었습니다. 오히려 제가 AI를 활용하는 방식의 약점을 적나라하게 확인한 경험에 가까웠습니다.

그래도 군 복무 중 3일간 준비한 예선 제품으로 본선까지 올라가고, 실제 기업의 심사위원 앞에서 제가 만든 프로덕트를 설명해 본 것은 흔하지 않은 경험이었습니다.

아직 취업 연계라는 작은 기대도 남아 있습니다.

다음에 비슷한 기회가 온다면 더 많은 기능을 만들기보다, 문제를 제 손으로 더 정확하게 이해하고 하나의 판단이 Raw Data에서 계산, 결론, 보고와 Action까지 이어지는 과정을 끝까지 완성해 보고 싶습니다.

이번 대회에서 가장 크게 남은 질문은 이것이었습니다.

나는 AI를 사용해 문제를 해결한 것인가, 아니면 AI가 만든 해석을 따라 결과물을 만든 것인가?

이번에는 후자에 가까웠던 순간이 많았던 것 같습니다.

다음 프로젝트에서는 그 차이를 극복하고 싶습니다.

저는 PWC 삼일회계법인 전형으로 예선을 지원했고, 붙을거란 기대는 전혀 하지 않고 있었는데 붙어서 어안이 벙벙할 따름입니다. 아무튼 내일 다녀와서 후기도 빠른 시일 내에 블로그에 남기겠습니다.

한동안 블로그에 글을 올리지 못했습니다.

현재 저는 군에서 복무하고 있습니다. 전역한 뒤에는 가능한 한 빨리 PM, PO, AI-native, AX와 관련된 현업에 들어가 실제 제품을 만들고, 조직이 일하는 방식을 경험해보고 싶습니다.

그 마음이 생각보다 꽤 간절해서 최근에는 프로젝트보다 취업 준비에 많은 시간을 썼습니다.

몇 개 회사에서 면접도 봤습니다. 다만 아직까지는 모두 최종 단계에서 떨어졌습니다.

아쉬움이 없다고 하면 거짓말이겠지만, 당분간은 계속 지원하고 계속 부딪혀볼 생각입니다. 제가 부족했던 부분을 확인하고, 포트폴리오와 프로젝트를 보완하면서 다시 도전하려고 합니다.

그 사이 부모님 가게 POS 프로젝트도 잠시 멈춰 있었습니다.

그러다 다시 프로젝트를 시작하기 위한 워밍업으로 최근 화제가 되고있는 Claude의 Fable 5를 사용해보게 됐습니다.

Fable 5는 Anthropic이 장시간 이어지는 복잡한 코딩과 에이전트 작업을 위해 내놓은 상위 모델입니다. 한동안 접근이 제한됐다가 한시적으로 다시 사용할 수 있게 됐고(7월 12일까지), 일상적인 개발에서는 다시 Opus를 주로 사용하게 될 가능성이 커서, 사용할 수 있을 때 제대로 한번 써보고 싶었습니다.

써본 소감은 아주 단순했습니다.

확실히 프런티어 모델은 알잘딱깔센을 잘했습니다.

제가 모든 버튼과 간격, 상태 처리 방식을 하나하나 지시하지 않아도 기존 코드와 화면을 확인하고, 제가 원하는 방향을 어느 정도 추론한 뒤 결과물을 만들어냈습니다.

물론 모델이 제품의 방향까지 대신 결정해준 것은 아닙니다.

어떤 데이터를 남길 것인지, 과거 데이터와 현재 데이터를 어떻게 구분할 것인지, 무엇을 가장 먼저 보여줄 것인지, 이 서비스가 결국 어떤 의사결정을 도와야 하는지는 여전히 제가 판단해야 했습니다.

그리고 그 과정에서 1편에서 말했던 프로젝트를 다시 이어가기 시작했습니다.

1편에서는 이런 이야기를 했습니다.

부모님은 23년 동안 동네 슈퍼마켓을 운영하셨습니다.

저는 그 가게에 쌓인 데이터를 꺼내 단순한 매출표가 아니라, 실제 운영자가 더 나은 결정을 내릴 수 있는 시스템을 만들어보고 싶다고 했습니다.

POS 데이터와 상품, 시간대, 거래처, 결제수단, 재고, 날씨, 상권을 연결하고, 나중에는 온톨로지와 LLM을 활용해 숫자 너머의 맥락까지 보고 싶었습니다.

그런데 프로젝트를 실제로 시작하면서 가장 먼저 알게 된 것이 있습니다.

AI를 붙이는 것보다 먼저 해야 할 일이 있었습니다. 데이터부터 꺼내야 했습니다.

처음에는 간단하게 생각했습니다.

POS 사이트에서 조회한 자료를 엑셀로 내려받고, Python이나 Pandas로 정리하면 되지 않을까?

하지만 실제로 확인해보니 엑셀 추출이 되지 않았습니다.

화면에서는 월매출, 일별 거래건수, 객단가, 현금매출과 카드매출 같은 데이터를 볼 수 있었지만, 그 데이터를 분석 가능한 파일로 내려받는 기능은 사실상 사용할 수 없었습니다.

API 문서도 찾을 수 없었습니다.

결국 선택지는 하나였습니다.

사람이 화면에서 읽을 수 있다면, 브라우저가 대신 읽게 해보자.

나들가게 POS는 생각보다 오래된 시스템이었습니다.

정확한 최초 개발일을 공개 문서만으로 확정하기는 어려웠습니다.

다만 실제 관리 화면 하단에는 Copyright © 2009가 표시되어 있었고, 2010년에는 이미 점주들을 대상으로 나들가게 POS 교육이 진행되고 있었습니다. 적어도 현재 화면의 계보가 2000년대 말에서 2010년대 초반에 만들어진 시스템이라는 것은 확인할 수 있었습니다.

공식 안내를 보면 나들가게 POS는 판매와 반품뿐 아니라 상품관리, 재고관리, 영업관리, 정산과 마감까지 다루는 시스템입니다. 별도의 경영분석시스템도 POS 판매기록을 바탕으로 매출과 이익, 방문객 수, 일·월 영업실적 등을 보여주도록 설계되어 있습니다.

데이터가 없었던 것은 아니었습니다.

오히려 필요한 데이터는 이미 상당 부분 존재하고 있었습니다.

문제는 그 데이터가 오래된 웹 화면 안에 흩어져 있고, 외부에서 쉽게 사용할 수 있는 형태로 열려 있지 않았다는 점이었습니다.

기존 화면은 오래된 GWT 기반 웹 애플리케이션 형태였고, 메뉴와 프레임, 조회 결과가 여러 단계로 나뉘어 있었습니다.

그래서 Claude와 Codex를 활용해 HTML 구조와 프레임을 하나씩 확인하고, 로그인부터 메뉴 이동, 조회, 테이블 파싱까지 브라우저가 자동으로 수행하게 만들었습니다.

아이디와 비밀번호 입력 → 로그인 → 영업분석 메뉴 이동 → 월매출 캘린더 조회 → 셀 데이터 수집

첫 번째 목표는 이것뿐이었습니다.

그리고 결국 월매출 캘린더의 데이터를 가져오는 데 성공했습니다.

처음 데이터를 가져오는 데 약 40초가 걸렸습니다.

처음에는 성공했다는 사실만으로도 만족했습니다.

그런데 새로고침을 한 번 할 때마다 40초 가까이 기다려야 했습니다.

한 번 테스트할 때는 괜찮았지만, 실제 서비스라면 사용할 수 없는 속도였습니다.

로그를 나눠서 확인해보니 사이트가 원래 느린 것 외에도, AI가 만든 크롤러 안에 불필요한 낭비가 꽤 많았습니다.

가장 큰 문제는 이중 로그인이었습니다.

한 번 로그인한 뒤 바로 메뉴를 클릭하면 되는데, 캘린더 주소로 직접 접근하면서 로그인 페이지로 되돌아가고 있었습니다. 그 결과 로그인과 GWT 초기화가 두 번씩 발생했습니다.

셀을 읽는 방식도 비효율적이었습니다.

화면에 있는 약 400개의 셀을 하나씩 Python으로 가져오면서 브라우저와 수백 번 통신하고 있었습니다. 이를 frame.evaluate 한 번으로 모든 셀의 텍스트를 묶어서 가져오는 방식으로 바꿨습니다.

스크린샷과 HTML 저장도 실패하거나 디버깅이 필요한 경우에만 실행하도록 변경했습니다.

브라우저와 로그인 세션은 계속 살려뒀습니다.

새로고침을 누르면 다시 로그인하는 대신 이미 열린 세션에서 조회 버튼만 누르고 데이터를 읽도록 했습니다. 세션이 만료된 경우에만 자동으로 초기화하고 한 번 다시 시도하게 했습니다.

마지막으로 배경 예열을 추가했습니다.

서비스가 시작되면 데이터를 미리 가져오고, 기본 10분마다 다시 갱신해 캐시를 채우도록 했습니다.

그 결과 속도는 다음과 같이 줄었습니다.

• 캐시된 일반 접속: 거의 즉시
• 수동 새로고침: 약 5초
• 최초 배포 후 콜드 스타트: 약 15초
• 기존 방식: 약 40초

그런데 속도를 줄이고 나니 또 다른 문제가 보였습니다.

2012년 1월 매출을 조회한다고 가정해보겠습니다.

처음 조회할 때 오래 걸리는 것은 어느 정도 이해할 수 있습니다.

하지만 같은 달의 데이터를 며칠 뒤 다시 보고 싶을 때도, 또 오래된 POS에 로그인하고 또 같은 화면을 불러오고 또 같은 데이터를 크롤링해야 했습니다.

이상했습니다.

2012년 1월 매출은 더 이상 바뀌지 않습니다.

지난달 데이터도 마감이 끝났다면 바뀔 가능성이 거의 없습니다.

그런데 왜 볼 때마다 원본 POS를 다시 조회해야 할까?

그래서 데이터 구조를 바꾸기로 했습니다.

과거 데이터는 한 번 가져오면 데이터베이스에 저장하고, 현재 진행 중인 달만 다시 조회한다.

Supabase에 monthly_sales, daily_sales 등의 테이블을 만들었습니다.

월별 총매출, 거래건수, 객단가, 일평균 매출, 반품 건수와 금액, 수집 시각, 월 마감 여부를 저장했습니다.

현재 달은 계속 변하므로 새로고침할 때 POS에서 다시 가져옵니다.

반면 이미 끝난 달은 Supabase에서 즉시 읽습니다.

나들가게 POS
    ↓
브라우저 자동화·크롤링
    ↓
데이터 정규화
    ↓
Supabase 저장
    ↓
새로운 조회·분석 UI

기존 POS는 여전히 원천 시스템입니다.

제가 만든 서비스는 운영 데이터를 수정하지 않고, 데이터를 가져와 조회와 분석에 적합한 형태로 저장하는 새로운 읽기 계층입니다.

그리고 2011년 7월, 부모님 가게에 POS가 처음 도입된 시점부터 월별 데이터를 순차적으로 가져와 저장했습니다.

가게 자체의 역사는 23년이지만, 디지털로 남은 매출의 역사는 약 15년입니다.

이제 2012년 1월을 보든, 2018년 6월을 보든 매번 오래된 POS를 다시 기다릴 필요가 없습니다.

한 번 구해놓은 과거 데이터는 데이터베이스에서 바로 불러옵니다.

이 결정 하나로 서비스의 성격이 바뀌었습니다.

이전에는 오래된 POS 화면을 대신 열어주는 크롤러였다면, 이제는 매장의 역사를 자체적으로 보관하고 조회하는 서비스가 됐습니다.

데이터를 가져온 뒤에는 화면도 다시 만들었습니다.

기존 POS에도 필요한 숫자는 있었습니다.

문제는 정보가 너무 많은 표와 메뉴 안에 흩어져 있다는 점이었습니다.

월매출을 보려면 월매출 캘린더를 열어야 하고, 날짜를 누르면 오른쪽에 세부 결제수단이 나옵니다. 지난달과 비교하려면 다른 화면을 열어야 하고, 월별 흐름을 보려면 숫자를 직접 기억하거나 옮겨 적어야 했습니다.

기존 화면이 틀렸다는 의미는 아닙니다.

당시의 업무 환경에서는 많은 기능을 한 화면에 제공하는 것이 중요했을 것입니다.

하지만 제가 만들고 싶은 서비스의 목적은 달랐습니다.

저는 “조회할 수 있는 화면”보다 “빠르게 이해할 수 있는 화면”을 만들고 싶었습니다.

그래서 토스증권의 정보 구조를 참고했습니다.

토스증권은 모든 숫자를 한꺼번에 보여주기보다, 사용자가 현재 가장 궁금해할 정보부터 위계를 만들어 보여줍니다.

제가 만든 화면도 같은 원칙으로 다시 구성했습니다.

상단에는 이번 달 총매출을 가장 크게 배치했습니다.

바로 아래에는 전월 대비 변화, 거래건수, 객단가, 일평균 매출, 최고 매출일을 두었습니다.

그다음에는 일별 매출 그래프와 최근 6개월·12개월 흐름을 배치했습니다.

아래에는 현금매출, 카드매출, 포인트매출 등 결제수단의 구성을 정리했습니다.

현재 진행 중인 달은 완료된 달과 구분해 진행 중 상태로 표시했습니다. 아직 끝나지 않은 달을 전월과 단순 비교하면 큰 폭으로 하락한 것처럼 오해할 수 있기 때문입니다.

단순히 색상을 바꾸고 카드 형태로 만든 것은 아닙니다.

사용자가 숫자를 이해하는 순서를 다시 설계했습니다.

지금 매출이 얼마인가?
지난달보다 올랐는가?
거래건수와 객단가 중 무엇이 변했는가?
어느 날 매출이 높았는가?
최근 흐름은 상승인가 하락인가?
어떤 결제수단으로 매출이 발생했는가?

기존 POS의 메뉴와 표를 그대로 복사하지 않고, 사용자의 질문을 기준으로 정보를 다시 배열했습니다.

만들고 보니 아주 작은 ‘차세대 프로젝트’ 같았습니다.

IT 업계에서 차세대 프로젝트라는 말을 자주 사용합니다.

오래된 ERP나 업무 시스템을 새로운 데이터 구조와 화면, 인프라로 다시 만드는 프로젝트를 의미합니다.

제가 한 일이 기업 단위의 거대한 차세대 프로젝트와 같다고 말할 수는 없습니다.

하지만 구조는 꽤 닮아 있었습니다.

• 오래된 시스템은 원천 시스템으로 유지하고
• 필요한 데이터를 새롭게 수집하고
• 새로운 데이터베이스에 표준화해 저장하고
• 조회 성능을 개선하고
• 현대적인 사용자 경험으로 재구성했습니다.

작은 동네 슈퍼마켓을 대상으로 한 아주 작은 레거시 현대화 프로젝트였던 셈입니다.

이 작업을 하면서 기존에 ERP, MES, 관리자 대시보드를 구축해온 업체들의 해자가 예전보다 많이 낮아질 수 있겠다는 생각도 들었습니다.

과거에는 오래된 시스템을 분석하고, 별도의 데이터베이스와 화면을 만들고, 자동화 코드를 작성하려면 상당한 개발 인력과 비용이 필요했습니다.

지금은 Claude Code나 Codex 같은 도구를 이용해 기존 HTML을 분석하고, 크롤러를 만들고, 데이터베이스 스키마를 설계하고, 프런트엔드를 구현하는 데 필요한 비용과 시간이 크게 낮아졌습니다.

물론 모든 해자가 사라지는 것은 아닙니다.

실제 현장을 이해하고, 데이터의 의미를 정의하고, 기존 시스템과 안정적으로 연결하고, 장애와 예외를 관리하는 역량은 여전히 중요합니다.

오히려 코드를 작성하는 비용이 낮아질수록 이런 판단 역량이 더 중요해질 것 같습니다.

“어떻게 개발할 것인가”보다 “무엇을 왜 만들어야 하는가”가 더 큰 차이가 되는 것입니다.

2011년의 데이터를 열어보니, 매출표가 아니라 시간의 기록처럼 보였습니다.

처음에는 월별 숫자를 저장하는 것만 생각했습니다.

그런데 2011년과 2012년 데이터를 실제로 조회해보니 예상보다 훨씬 많은 질문이 생겼습니다.

2012년 1월의 객단가는 5,566원이었습니다.

최근에는 대체로 9,000원 안팎까지 올라와 있습니다.

2012년에는 현금매출이 압도적으로 많았고 카드매출의 비중은 훨씬 작았습니다.

지금은 반대입니다.

카드와 각종 전자결제가 매출의 대부분을 차지합니다.

한 가게의 데이터 안에 한국 사회의 결제 방식 변화가 그대로 남아 있었습니다.

객단가가 5,000원대에서 9,000원대로 오른 것도 흥미로웠습니다.

물론 이것을 단순히 “물가가 올랐기 때문”이라고 단정할 수는 없습니다.

상품 가격의 상승도 영향을 줬겠지만, 상품 구성과 고객층, 한 번에 구매하는 물품 수, 주변 경쟁점, 소비 습관도 함께 바뀌었을 수 있습니다.

그렇기 때문에 오히려 다른 데이터를 연결할 필요가 생깁니다.

소비자물가지수 품목별 가격 변화 날씨와 기온 공휴일과 요일 지역 지원금 지급 시기 주변 편의점과 대형마트의 개업일 인근 상권 변화 가게의 가격과 진열 변경

2020년, 재난지원금이 지급된 뒤 매출이 눈에 띄게 올랐던 시기가 있었습니다.

주변에 편의점이 생긴 뒤 매출이 크게 떨어졌던 기억도 있습니다.

지금까지는 부모님의 기억으로만 남아 있던 사건입니다.

하지만 15년치 월별·일별 데이터를 확보하면 실제 변화가 발생한 날짜를 찾을 수 있습니다.

지원금 지급 전후로 거래건수와 객단가가 어떻게 변했는지, 편의점 개점 이후 어떤 품목과 시간대의 매출이 먼저 떨어졌는지 확인할 수 있습니다.

이때부터 데이터는 단순한 매출표가 아니라, 현장의 사건과 연결되는 기록이 됩니다.

숫자만 많다고 현장을 이해하는 것은 아닙니다.

기존의 회귀분석이나 머신러닝으로도 매출과 날씨, 요일, 가격 사이의 상관관계를 찾을 수 있습니다.

하지만 숫자만 놓고 보면 그 사이에 숨어 있는 현장의 구조를 놓치기 쉽습니다.

예를 들어 편의점이 생긴 뒤 매출이 떨어졌다고 해도, 모든 상품이 똑같이 영향을 받은 것은 아닐 것입니다.

편의점이 강한 담배, 음료, 간편식이 먼저 영향을 받았을 수 있습니다.

반대로 대용량 생필품이나 동네 단골이 외상으로 구매하던 상품은 영향을 덜 받았을 수도 있습니다.

정책지원금이 풀린 뒤 매출이 올랐다고 해도, 단순히 손님이 많아진 것인지, 기존 고객의 객단가가 올라간 것인지, 특정 상품군에만 소비가 집중된 것인지 나눠봐야 합니다.

숫자만 보면 매출 상승입니다.

현장의 구조를 연결하면 다음처럼 바뀝니다.

정책지원금 지급
→ 특정 결제수단 사용 증가
→ 기존 고객의 객단가 상승
→ 생필품과 고단가 상품 판매 증가
→ 월매출 증가

또는 다음과 같을 수도 있습니다.

인근 편의점 개점
→ 야간·출근시간 고객 이동
→ 담배·음료 거래건수 감소
→ 전체 고객수 감소
→ 월매출 하락

제가 온톨로지에 관심을 갖는 이유도 여기에 있습니다.

온톨로지는 단순히 그래프를 멋지게 그리는 기술이 아닙니다.

상품과 카테고리, 거래처, 결제수단, 시간, 날씨, 정책, 경쟁점, 매장의 의사결정을 서로 연결해 현장의 구조를 표현하는 방법입니다.

저는 앞으로 이 구조를 세 계층으로 만들고 싶습니다.

첫 번째는 매장의 기본 개체입니다.

상품, 카테고리, 거래처, 결제수단, 날짜, 시간대, 고객군

두 번째는 실제 발생한 사건입니다.

판매, 반품, 가격 변경, 지원금 지급, 경쟁점 개점, 비와 폭염

세 번째는 가게의 의사결정입니다.

무엇을 더 발주할지, 가격을 바꿀지, 어디에 진열할지, 어떤 상품을 묶어 팔지

이 세 계층이 연결돼야 단순히 “무슨 일이 있었는가”를 넘어서 “왜 그랬고, 다음에는 무엇을 바꿀 것인가”에 답할 수 있다고 생각합니다.

이 프로젝트를 하면서 AX에 대해서도 다시 생각하게 됐습니다.

최근 많은 기업과 조직이 AX를 이야기합니다.

문서를 요약하고, 사내 자료를 검색하고, 회의록을 정리하는 AI를 도입합니다.

이런 기능도 분명히 유용합니다.

하지만 단건의 문서 요약이나 검색만으로 조직이 AI-native하게 바뀌었다고 보기는 어렵습니다.

진짜 조직에 맞는 AX를 하려면 그 조직이 실제로 어떻게 판단하고 움직이는지를 먼저 구조화해야 한다고 생각합니다.

• 어떤 단계로 업무가 진행되는가
• 누가 어떤 시점에 판단하는가
• 어떤 데이터와 규정을 참고하는가
• 정상적인 경우와 예외적인 경우는 무엇인가
• 문서에는 없지만 구성원들이 당연하게 여기는 가정은 무엇인가
• 의사결정 결과가 다음 단계에 어떤 영향을 미치는가

이런 암묵지와 의사결정 구조가 워크플로에 담겨 있어야 합니다.

LLM은 학습 과정에서 역전파를 통해 방대한 언어 패턴을 익히고, 실제 생성 과정에서는 주어진 문맥을 바탕으로 다음 토큰의 확률 분포를 계산해 결과를 만듭니다. 이 방식은 매우 강력하지만, 조직 고유의 맥락이 없으면 자연스럽게 일반적이고 평균적인 답변으로 흐를 수 있습니다. 다음 토큰 예측은 현대 언어모델의 핵심 학습·생성 구조지만, 그것만으로 특정 조직의 규칙과 예외, 책임 구조가 자동으로 생기는 것은 아닙니다.

그래서 AI에게 문서만 많이 넣는다고 우리 조직에 맞는 AI가 만들어지는 것은 아닙니다.

우리 조직의 개체와 관계, 이벤트, 규칙, 예외, 의사결정 단계를 먼저 정리해야 합니다.

그 위에서 AI가 워크플로를 따라 움직여야 합니다.

조직이 AI의 방식에 맞추는 것이 아니라, AI가 조직의 실제 구조를 이해하고 따라가게 만들어야 합니다.

동네 슈퍼마켓 프로젝트는 아주 작은 사례지만 본질은 비슷합니다.

단순히 POS 매출표를 LLM에 넣고 “인사이트를 알려줘”라고 하면 그럴듯한 말은 만들 수 있습니다.

하지만 왜 특정 상품을 계속 취급했는지, 거래처와 어떤 조건으로 거래했는지, 편의점이 언제 들어왔는지, 특정 정책이 어떤 고객에게 영향을 줬는지 모르면 현장에 맞는 판단을 내릴 수 없습니다.

결국 AI보다 먼저 필요한 것은 조직과 현장의 구조입니다.

아직 이 프로젝트에는 AI가 거의 없습니다.

현재까지 가져온 데이터는 나들가게 POS의 월매출 캘린더 정보가 중심입니다.

지금 볼 수 있는 것은 다음 정도입니다.

월별 총매출
월별 거래건수
객단가
일평균 매출
일별 매출
현금매출
카드매출
포인트매출
최근 6개월과 12개월 흐름

아직 상품별 판매 데이터도 충분히 가져오지 못했습니다.

카드사별 매출, 카테고리별 매출과 이익, 거래처별 상품, 재고와 발주 데이터도 추가해야 합니다.

그래프 데이터베이스도 없습니다.

온톨로지도 아직 만들지 않았습니다.

LLM에게 자연어로 질문하는 기능도 없습니다.

그렇지만 저는 지금 단계가 중요하다고 생각합니다.

AI를 붙이기 위한 가장 기본적인 토대를 만들었기 때문입니다.

데이터가 어디에 있는지 확인했고,

사람이 화면을 열지 않아도 자동으로 가져올 수 있게 만들었고,

변하지 않는 과거 데이터를 데이터베이스에 쌓았고,

사용자가 빠르게 이해할 수 있는 화면으로 다시 구성했습니다.

앞으로는 여기에 하나씩 데이터를 붙여갈 생각입니다.

먼저 상품별 매출과 이익, 카테고리와 거래처 데이터를 가져옵니다.

그다음 날씨와 공휴일, 물가, 상권, 정책 데이터를 연결합니다.

이후 상품, 거래처, 시간, 외부 사건, 운영 의사결정을 그래프와 온톨로지로 구조화합니다.

마지막에 LLM을 붙이려고 합니다.

LLM이 숫자를 직접 계산하고 근거 없이 판단하게 하는 것이 아니라, 구조화된 데이터와 규칙, 과거 실험 결과를 근거로 설명하고 다음 행동을 제안하게 만들고 싶습니다.

AI는 마지막입니다.

먼저 현장을 담아야 합니다.

이번 단계에서 제가 한 일은, 어쩌면 데이터를 구출한 것에 가깝습니다.

가게에는 이미 15년치 디지털 기록이 있었습니다.

하지만 그 데이터는 오래된 POS 화면을 한 달씩 넘겨보지 않으면 볼 수 없었습니다.

한 번 본 과거 데이터를 다시 보기 위해 또 로그인하고, 또 기다리고, 또 조회해야 했습니다.

저는 그 데이터를 꺼내 데이터베이스에 쌓고, 다시 빠르게 볼 수 있는 화면을 만들었습니다.

아직 이 시스템은 제가 최종적으로 만들고 싶은 의사결정 도구가 아닙니다.

지금은 토대에 가깝습니다.

하지만 이제 최소한 2011년의 가게와 2026년의 가게를 같은 화면에서 비교할 수 있습니다.

현금 중심의 매장이 카드 중심의 매장으로 바뀐 과정도 볼 수 있고,

객단가가 5,000원대에서 9,000원대로 이동한 과정도 볼 수 있고,

부모님의 기억 속에 있던 사건을 실제 날짜와 숫자로 다시 확인할 수도 있습니다.

1편에서는 이런 질문을 했습니다.

부모님 가게는 어떻게 23년 동안 망하지 않고 살아남았을까?

아직 답을 찾지는 못했습니다.

다만 이제 그 질문에 답할 수 있는 데이터를 처음으로 한곳에 모으기 시작했습니다.

그리고 다음 단계에서는 단순히 매출이 오르고 내린 것을 보는 것을 넘어,

어떤 상품과 거래처, 어떤 시간대와 외부 사건이 그 변화에 영향을 줬는지 연결해보려고 합니다.

데이터가 없었던 것이 아니었습니다.

오래된 화면 안에 갇혀 있었을 뿐입니다.

이번에는 그 데이터를 꺼냈습니다.

이제부터는 그 데이터에 현장의 맥락을 연결해보려고 합니다.

저는 한국해양대학교에 현재 휴학 중인 23학번입니다.

저는 저희 학번이 소위 말하는 AI-native 학번에 가깝다고 생각합니다. 입학하자마자 ChatGPT가 사람들 입에 오르내리기 시작했고, Bard, Gemini, Claude 같은 서비스들이 계속 등장했습니다. 과제를 하거나 글을 쓰거나 모르는 개념을 찾아볼 때, 자연스럽게 검색창뿐만 아니라 LLM에게도 질문을 던지는 세대가 된 것입니다.

물론 처음부터 AI를 잘 이해하고 쓴 것은 아니었습니다. 저 역시 처음에는 단순히 신기해서 써봤고, 답변이 그럴듯해서 놀랐고, 어떤 때는 말도 안 되는 내용을 너무 자신 있게 말해서 당황하기도 했습니다. 당시에는 지금보다 모델 성능도 불안정했고, LLM의 hallucination, 즉 환각현상 문제가 훨씬 크게 느껴지던 시기였습니다.

그러다 자연스럽게 RAG라는 개념을 접하게 되었습니다.

모델이 모든 것을 알고 있다고 가정하는 대신, 외부의 신뢰할 수 있는 문서를 검색하고, 그 검색 결과를 바탕으로 답변하게 만드는 방식이었습니다. 그때는 이것이 단순히 LLM의 약점을 보완하는 여러 방법 중 하나라고 생각했습니다. 하지만 나중에 프로젝트를 직접 해보면서 조금 다르게 이해하게 되었습니다.

RAG는 단순히 LLM에게 문서를 붙여주는 기술이 아니었습니다.

현실의 문서를 기계가 읽을 수 있는 구조로 바꾸고, 그 구조를 바탕으로 필요한 정보를 검색하게 만든 다음, 모델이 그 근거 안에서만 답변하도록 제어하는 일이었습니다.

이번 글은 2024년에 제가 해양인문사회과학대학 논문공모대회에 참여하며 진행했던 “LLM을 활용한 선박충돌 사고 과실비율 예측” 연구에 대한 회고입니다.

단순히 “LLM으로 선박 충돌 과실비율을 예측했다”는 이야기를 쓰고 싶지는 않습니다. 오히려 지금 돌아보면 이 연구는 부족한 점이 훨씬 많았습니다. 모델 비교도 엄밀하지 못했고, RAG 구현도 기초적인 수준이었고, 평가 방식 역시 지금 기준으로 보면 많은 한계가 있었습니다.

그럼에도 이 연구가 저에게 중요했던 이유는 분명합니다.

처음에는 LLM이 과실비율을 맞히는 것이 핵심이라고 생각했지만, 프로젝트를 진행하면서 진짜 문제는 모델이 아니라 데이터 구조에 있다는 것을 알게 되었기 때문입니다.

시작은 서울대 영어학회었습니다.

이 이야기는 2023년 겨울, 서울대학교 한국영어학회 겨울학술대회를 참관했을 때부터 시작됩니다.

당시 저는 학과 교수님의 제안으로 학술대회에 함께 가게 되었습니다. 여러 발표가 있었고, 언어학과 영어학, 자연어처리와 관련된 다양한 연구들이 소개되었습니다. 그중에서 가장 충격적으로 다가왔던 발표는 서울대학교 컴퓨터언어학·자연어처리 연구실에서 진행한 "DaG LLM" 관련 발표였습니다.

그 연구는 LLM을 파인튜닝해서 교통사고 과실비율 조사에 활용하는 내용이었습니다.

자동차 사고 상황을 입력하면, 관련 도로교통법과 판례를 바탕으로 과실비율을 제시하고, 사고 해설과 관련 근거까지 함께 출력하는 방식이었습니다.

그 발표를 보면서 조금 충격을 받았습니다.

그전까지 저는 언어학이나 영문학이라는 학문을 조금 오래된 방식으로만 바라보고 있었던 것 같습니다. 문학 작품을 읽고, 문장을 분석하고, 번역을 하고, 텍스트를 해석하는 학문이라고 생각했습니다.

물론 그것도 중요한 일입니다. 하지만 그 발표를 보면서 언어학이 단순히 과거의 텍스트를 해석하는 데서 끝나는 것이 아니라, 현실의 법률 문제와 사고 판단 문제를 다루는 기술로 확장될 수 있다는 생각을 하게 되었습니다.

문과생도, 언어학 전공자도, 영문학 전공자도 이런 연구를 할 수 있구나.

언어를 디지털로 다루면 이렇게 현실적인 문제까지 연결될 수 있구나.

그날 학회장을 나와 다시 학교 기숙사로 돌아오면서 한 가지 생각이 계속 남았습니다.

자동차 사고에는 이런 연구가 있다면, 선박 사고에는 왜 없을까.

자동차 사고에는 DaG LLM이 있었다. 선박 사고에는 없었다.

2024년이 되고, 단과대학 논문공모전이 열린다는 사실을 알게 되었습니다.

주제는 비교적 빠르게 정해졌습니다. 서울대 연구를 그대로 따라 하자는 것은 아니었습니다. 다만 그 연구가 던진 질문을 해양대의 도메인으로 옮겨보고 싶었습니다.

자동차 충돌 사고가 아니라, 선박 충돌 사고라면 어떨까.

선박 충돌 사고에서도 과실비율은 중요한 문제입니다. 사고가 발생하면 어느 선박에게 어느 정도의 원인이 있는지 판단해야 하고, 그 판단은 이후의 법적 분쟁과 책임 문제로 이어집니다.

그런데 선박 사고는 자동차 사고보다 훨씬 복잡합니다. 도로 위에서 차선과 신호, 일시정지 여부만 보는 문제가 아니라, 시계, 조류, 항로, 선박의 크기, 조업 상태, 피항 의무, 유지선의 협력 동작 같은 요소들이 복합적으로 얽힙니다.

논문을 준비하면서 확인한 자료에 따르면, 2019년부터 2023년까지 최근 5년간 선박 충돌 사고는 총 1,276건 발생했습니다. 연평균 244건 이상 발생한 셈입니다. 자동차 사고에 비하면 규모가 작아 보일 수 있지만, 해양 사고라는 특성을 고려하면 결코 가볍게 볼 수 없는 숫자였습니다.

당시 저희가 바라본 문제는 두 가지였습니다.

첫 번째는 과실비율 판단이 중앙해양안전심판원의 재결서와 조사관의 판단에 크게 의존한다는 점이었습니다. 물론 전문가의 판단은 매우 중요합니다. 하지만 사고가 복잡하고 재결서가 많아질수록, 유사한 사고를 빠르게 찾고 비교하는 일은 점점 어려워질 수밖에 없습니다.

두 번째는 해양안전심판원의 재결서와 민사소송에서의 판단이 항상 같은 방식으로 이어지지는 않는다는 점이었습니다. 해양 사고의 특수성과 법적 판단 사이에는 여러 해석의 여지가 있고, 이 때문에 과실비율은 법적 다툼의 쟁점이 될 수 있습니다.

그래서 처음에는 단순하게 생각했습니다.

선박 충돌 사고의 재결서를 모으고, LLM이 그것을 참고하게 만들면, 새로운 사고 상황에 대해 어느 정도의 과실비율을 예측할 수 있지 않을까.

지금 생각하면 꽤 거친 문제정의였습니다. 하지만 그 거친 질문이 연구의 출발점이 되었습니다.

서울대처럼 파인튜닝할 수는 없었다

문제는 방법이었습니다.

서울대 연구실에서 발표한 DaG LLM은 단순히 LLM에게 질문을 던지는 방식이 아니었습니다. 도로교통법과 판례 데이터를 바탕으로 모델을 Instruction Tuning, 즉 파인튜닝한 연구였습니다. 발표자료를 보니 기반 모델과 학습 방법론, 그리고 대규모 GPU 자원까지 정리되어 있었습니다.

그런데 우리는 그런 방식으로 갈 수 없었습니다.

대규모 GPU가 있는 것도 아니었고, 충분한 연구비가 있는 것도 아니었고, 애초에 지원이 풍부한 공학 연구실 소속도 아니었습니다. 학부생 팀이었고, 현실적으로 사용할 수 있는 자원은 매우 제한적이었습니다.

그래서 발상을 바꿔야 했습니다.

모델 자체를 다시 학습시키는 대신, 이미 존재하는 LLM이 신뢰할 수 있는 재결서를 검색해서 참고하게 만들면 어떨까.

파인튜닝 대신 RAG를 선택한 것입니다.

RAG는 Retrieval-Augmented Generation의 약자입니다. 쉽게 말하면, 사용자의 질문이 들어왔을 때 관련 문서를 먼저 검색하고, 그 검색된 문서를 LLM에게 함께 제공하여 답변을 생성하게 만드는 방식입니다.

당시 저는 유튜브로 테디노트님의 RAG 관련 자료를 보며 기초를 공부하고 있었습니다. LangChain, VectorDB, embedding, chunking 같은 단어들을 하나씩 익히던 시기였습니다. 지금 보면 정말 기초적인 수준이었지만, 그때의 저에게는 꽤 새로운 세계였습니다.

파인튜닝은 어렵지만, RAG라면 해볼 수 있지 않을까.

해양안전심판원 재결서를 정리해서 VectorDB에 넣고, 새로운 사고 상황을 입력하면, 유사한 판례를 검색해서 LLM이 과실비율을 추론하게 만들 수 있지 않을까.

그렇게 연구가 시작되었습니다.

처음 만든 RAG는 솔직히 많이 부족했습니다.

지금 돌아보면, 이 연구는 기술적으로 부족한 점이 많았습니다.

당시 논문에서는 GPT-4o Mini와 Gemini Flash2.0을 비교하면서, GPT-4o Mini가 Gemini Flash2.0 보다 실제 재결서의 원인제공비율에 더 가까운 근사치를 보였다고 정리했습니다.

발표자료에서는 VectorDB에 저장되지 않은 데이터를 바탕으로 모델의 예측 성능을 검증했고, 근사치 비교 결과 GPT-4o Mini가 Gemini Flash2.0 보다 더 높은 결과를 보였다고 설명했습니다.

하지만 지금 기준으로 보면 이 표현은 훨씬 조심해서 다뤄야 합니다.

몇 개의 사례를 한 번씩 넣어본 결과만으로 “어떤 모델이 더 정확하다”고 말하기는 어렵습니다. 평가 사례 수도 부족했고, 같은 조건에서 여러 번 반복 실행한 결과도 충분하지 않았으며, temperature나 프롬프트 구성, 검색된 문서의 차이가 결과에 미치는 영향도 분리하지 못했습니다.

RAG에서는 모델 자체의 성능만 중요한 것이 아닙니다.

어떤 문서가 검색되었는지, 청크를 어떻게 나눴는지, 검색된 문서가 실제 판단에 적합했는지, 프롬프트가 모델을 얼마나 잘 제어했는지에 따라 결과가 크게 달라질 수 있습니다.

따라서 당시의 비교는 엄밀한 모델 성능평가라기보다, 제한된 테스트 사례에서 어느 모델이 실제 재결서 비율에 더 가까운 근사치를 보였는지 확인한 수준에 가까웠습니다.

RAG 구현도 마찬가지였습니다.

당시 제가 만든 RAG는 고도화된 시스템이 아니었습니다. 문서를 불러오고, 일정한 단위로 나누고, 임베딩하고, VectorDB에 저장한 뒤, 사용자의 질문이 들어오면 유사한 문서를 검색해서 LLM에게 넣어주는 정도였습니다.

지금의 기준으로 보면 아주 기초적인 VectorDB 기반 RAG였습니다.

정교한 chunking도 부족했고, hybrid search도 없었으며, reranker를 붙이지도 못했습니다. Retrieval quality를 평가하는 지표도 없었고, LLM의 답변이 검색된 문서에 얼마나 충실한지 평가하는 faithfulness 평가도 없었습니다. HWP나 PDF 형태의 재결서를 완전히 구조적으로 파싱했다고 보기도 어려웠습니다.

그때는 RAG를 만들었다고 생각했지만, 지금 보면 RAG의 가장 기본적인 골격을 겨우 구현한 것에 가까웠습니다.

그래서 이 연구를 “정교한 RAG 시스템을 만들었다”고 말하고 싶지는 않습니다. 그렇게 말하면 오히려 틀린 설명에 가깝습니다.

하지만 그럼에도 의미는 있었습니다.

부족한 RAG였지만, 그 부족한 RAG를 만들면서 더 중요한 문제를 보게 되었기 때문입니다.

문제는 모델이 아니라 데이터였다

처음에는 LLM이 과실비율을 맞히는 것이 중요하다고 생각했습니다.

GPT에게 사고 상황을 넣고, Gemini에게도 같은 사고 상황을 넣고, 실제 해양안전심판원 재결서의 원인제공비율과 얼마나 가까운지 비교하면 된다고 생각했습니다.

지금 보면 많이 부족한 접근이었습니다.

몇 개의 사례만으로 모델의 우열을 말하기는 어려웠고, 한 번의 출력만 보고 성능을 판단하는 것도 엄밀한 실험이라고 보기 어려웠습니다. 하지만 이상하게도, 그 부족한 실험을 하면서 오히려 더 중요한 것을 보게 되었습니다.

문제는 모델이 아니었습니다. 데이터였습니다.

해양안전심판원의 재결서는 사람이 읽기 위해 쓰인 문서입니다. 사건번호, 사고 종류, 선박의 종류, 사고 경위, 항법 위반, 판단 이유, 최종 원인제공비율이 모두 긴 자연어 문장 속에 들어 있습니다. 사람은 문맥을 따라 읽으며 이해할 수 있지만, 기계가 바로 검색하고 비교하기에는 어려운 형태였습니다.

그래서 우리는 재결서를 다시 나누기 시작했습니다.

사고 종류를 분리하고, 재결 일자를 분리하고, 재결 번호를 분리하고, 선박 종류를 분리하고, 사고 경위를 분리하고, 최종 원인제공비율을 따로 정리했습니다. 논문에서는 2019년부터 2023년까지의 선박충돌 사고 중 재결서가 있는 89건을 선정해, 서술식 비정형 데이터를 일정한 정형 데이터 형식으로 구조화했다고 정리했습니다.

처음에는 이것을 단순히 RAG를 하기 위한 전처리라고 생각했습니다.

하지만 자문을 받으면서 생각이 조금 바뀌었습니다.

전 목포지방해양안전심판원장이시자 해양수산연수원 특임교수로 계신 정대율 교수님께 자문을 구하면서, 이 데이터 정형화 작업 자체가 더 큰 과제로 발전할 수 있다는 이야기를 들었습니다.

LLM이 과실비율을 몇 퍼센트로 맞히는지도 중요하지만, 그보다 먼저 해양안전심판원 재결서라는 비정형 법률 문서를 사고 단위, 선박 단위, 위반 행위 단위, 법령 단위, 판단 근거 단위로 구조화하는 일이 훨씬 중요한 문제일 수 있다는 것입니다.

그때 조금 다르게 보이기 시작했습니다.

처음에는 LLM으로 과실비율을 예측하는 연구라고 생각했습니다. 그런데 자문을 받고 데이터를 정리하다 보니, 이 연구의 핵심은 모델이 아니라 재결서를 기계가 읽을 수 있는 구조로 바꾸는 일에 가까웠습니다.

그 구조화가 되어야 검색도 가능하고, 비교도 가능하고, 유사 판례 추천도 가능하고, 나중에는 실무자의 판단을 보조하는 시스템으로 발전할 수 있었습니다.

그때 처음 느꼈습니다.

AI를 잘 쓰는 것보다 먼저, 현실의 문서를 데이터 구조로 바꾸는 일이 중요하다는 것을요.

논문공모대회 대상, 그리고 남은 문제의식

결과적으로 이 연구는 2024년 해양인문사회과학대학 논문공모대회에서 대상을 받았습니다.

물론 연구가 완벽해서 받은 상이라고 생각하지는 않습니다.

오히려 지금 다시 보면 부족한 점이 훨씬 많이 보입니다. 모델 비교도 더 엄밀했어야 했고, 평가 지표도 더 정교했어야 했고, RAG 파이프라인도 더 깊게 구현했어야 했습니다. 지금이었다면 단순히 예측 비율만 비교하지 않고, 검색된 판례의 적합성, 법령 적용의 일관성, 추론 근거의 충실성, 반복 실행 시 출력 안정성까지 함께 평가하려 했을 것입니다.

하지만 당시에는 LLM을 선박 충돌 사고의 과실비율 판단 문제에 연결했다는 점, 자동차 사고 중심의 선행연구를 해양 도메인으로 확장해보려 했다는 점, 그리고 인문학과 AI의 결합을 실제 도메인 문제로 풀어보려 했다는 점에서 좋은 평가를 받은 것 같습니다.

저에게 이 대상은 “연구를 잘했다”는 의미보다, “이 방향으로 더 깊게 파볼 수 있겠다”는 신호에 가까웠습니다.

지금 돌아보면, 이 연구는 출발점이었습니다.

처음에는 LLM이 과실비율을 맞히는 것이 연구라고 생각했습니다.

GPT와 Gemini를 비교하고, 실제 재결서 비율과 얼마나 가까운지 보면 된다고 생각했습니다. 하지만 지금은 조금 다르게 생각합니다.

중요한 것은 모델이 숫자를 맞히는 것이 아니었습니다.

중요한 것은 사고를 구조화하는 일이었습니다. 문서를 구조화하는 일이었습니다. 판단 근거를 구조화하는 일이었습니다.

해양안전심판원의 재결서는 사람이 읽기 위한 문서였습니다. 하지만 그 안에는 선박 사고 판단에 필요한 중요한 데이터가 들어 있었습니다. 그 데이터를 어떻게 꺼내고, 어떻게 정리하고, 어떻게 검색 가능하게 만들고, 어떻게 LLM이 근거 기반으로 설명하게 만들 것인가.

이 연구는 그 질문에 대한 아주 부족한 첫 시도였습니다.

부족했지만, 그래도 의미는 있었습니다.

그때 처음 느꼈습니다.

AI를 잘 쓰는 것보다 먼저, 현실의 문제를 데이터 구조로 바꾸는 일이 중요하다는 것을요.

그리고 아마 저는 앞으로도 이 문제를 계속 붙잡고 있을 것 같습니다.

요즘 말로 하면 AI-native 조직을 만들어보고 싶었다고 할 수도 있겠지만, 당시에는 그렇게 거창하게 생각한 것은 아니었습니다.

그냥 사람들이 이미 쓰고 있는 카카오톡 단톡방 안에서, 필요한 정보를 바로 가져오고, 긴 링크를 빠르게 요약하고, 간단한 AI 기능을 호출할 수 있으면 좋겠다고 생각했습니다.

오픈채팅방 뿐만 아니라, 이미 모두가 매일 쓰는 단톡방 안에 작은 AI 기능을 넣어보는 실험이었습니다.

당시 저는 학생생활관 관생자치위원회에서 활동하고 있었고, 기숙사에 살고 있었습니다. 그래서 이 실험을 실제 관생자치위원회 단톡방에 적용해보기로 했습니다.

시작은 교양 프로젝트였다

처음 이 프로젝트는 GPT 활용 교양 수업 발표 과제로 시작했습니다.

주제는 단순했습니다.

유튜브 링크를 카카오톡방에 보내면, 봇이 영상을 요약해서 다시 보내줄 수 없을까?

긴 유튜브 영상을 매번 끝까지 보기 어렵고, 필요한 내용만 빠르게 확인하고 싶을 때가 많았습니다. 그래서 카카오톡방에 링크만 보내면 요약된 텍스트를 돌려주는 챗봇을 만들어보고자 했습니다.

이 아이디어는 카카오톡 오픈채팅방에서 유명한 솔론봇을 만드신 유사개발자 솔론님의 구현 방식에서 많은 힌트를 얻었습니다.

저는 그 구조를 참고해서, 제가 속해 있던 학교 생활과 생활관 조직에 맞게 작게 변형해보고 싶었습니다.

구조는 메신저봇R + FastAPI + Gemini API

구조는 생각보다 단순했습니다.

안드로이드 공기계에 메신저봇R이라는 앱을 설치하고, JavaScript 기반으로 카카오톡 메시지를 감지했습니다.

사용자가 특정 명령어나 링크를 보내면, 메신저봇R이 그 메시지를 읽고 제 로컬 컴퓨터에서 돌아가는 FastAPI 서버로 요청을 보냈습니다.

그리고 FastAPI 서버에서는 Python 코드가 실행됐습니다.

웹사이트 링크라면 HTML을 파싱하고, 유튜브 링크라면 자막을 가져오고, 그 내용을 AI API로 보내 요약한 뒤 다시 카카오톡방으로 응답을 보내는 방식이었습니다.

전체 흐름은 대략 이랬습니다.

카카오톡 메시지 → 안드로이드 공기계 + 메신저봇R →
JavaScript 코드 → FastAPI 서버 → Python 크롤링 / 유튜브 자막 처리 →
Gemini API 요약 → 카카오톡방으로 응답

메신저봇R은 카카오톡 메시지를 감지하는 입구 역할을 했고, FastAPI 서버는 실제 Python 코드를 실행하는 처리 서버 역할을 했습니다.

요약 모델로는 Gemini 1.5 Flash를 사용했습니다.

당시 Google이 Gemini API에 대해 하루 약 1,500회 수준의 무료 호출 정책을 제공하고 있었고, 개인 프로젝트나 교양 발표용 프로토타입에서 사용하기에는 꽤 파격적인 조건이었습니다.

유튜브 자막이나 웹페이지 본문을 요약하는 용도라면 속도와 비용 면에서 충분하다고 판단했습니다. 그래서 처음부터 무거운 모델을 붙이기보다는, 빠르게 테스트하고 실제 단톡방에 적용해볼 수 있는 Gemini 1.5 Flash를 선택했습니다.

가장 먼저 적용된건 AI가 아니라 웹크롤링이었습니다.

그런데 막상 만들다 보니, 가장 먼저 체감됐던 기능은 유튜브 요약이 아니라 식단 조회였습니다.

당시 저는 기숙사에 살고 있었습니다. 기숙사생 입장에서 매일 확인하는 정보 중 하나가 식단이었습니다.

기숙사 식단을 보려면 학교 홈페이지에 들어가야 했고, 학생식당 메뉴도 따로 확인해야 했습니다.

크게 어려운 일은 아니지만, 매일 반복해서 확인하기에는 은근히 귀찮은 일이었습니다.

그래서 '/긱식'을 입력하면 기숙사 식단을, '/학식'을 입력하면 학생식당 메뉴를 가져오도록 만들었습니다.

학교 웹사이트를 크롤링해서 필요한 부분만 파싱하고, 카카오톡방에서 보기 좋게 정리해서 출력하는 방식이었습니다.

링크를 보내면 내용을 요약해주는 기능으로 확장하며

이후에는 단순 명령어 응답을 넘어서, 카카오톡방에 링크를 보내면 내용을 요약해주는 기능으로 확장했습니다.

일반 웹사이트 링크를 보내면 FastAPI 서버가 URL을 받아 HTML을 파싱하고, 본문 내용을 추출한 뒤 Gemini API로 요약했습니다.

유튜브 링크도 처리할 수 있도록 만들었습니다.

유튜브 링크는 youtube.com 형식도 있고 youtu.be 형식도 있어서, 두 주소를 모두 처리할 수 있도록 조건을 따로 잡았습니다.

또 유튜브 자막을 가져오고 요약하는 데 시간이 조금 걸렸기 때문에, 먼저 “유튜브 영상을 분석 중입니다. 잠시만 기다려주세요.”라는 메시지를 출력하고, 처리가 끝나면 요약 결과를 다시 보내도록 만들었습니다.

나중에는 arXiv 같은 논문 링크도 테스트했습니다.

영어 논문 페이지를 파싱하고, 핵심 내용을 한국어로 요약하는 방식이었습니다.

처음에는 유튜브 요약 챗봇으로 시작했지만, 점점 웹사이트 요약, 논문 요약, 학교 생활 정보 조회까지 붙으면서 단순 챗봇보다는 작은 정보 자동화 도구에 가까워졌습니다.

서버는 기숙사 방에서 24시간 돌아갔습니다.

재밌는 점은 서버 운영 방식이었습니다.

별도의 클라우드 서버를 쓴 것이 아니라, 당시 기숙사 방에 있던 제 컴퓨터를 24시간 켜두고 FastAPI 서버를 돌렸습니다.

기숙사 전기와 랜선을 사용했고, 안드로이드 공기계는 카카오톡 메시지를 감지하는 인터페이스 역할을 했습니다.

실제 크롤링과 요약 처리는 제 로컬 컴퓨터가 담당했습니다.

지금 보면 꽤 거친 구조였습니다.

하지만 당시에는 가장 빠르게 만들고, 가장 빠르게 실제 단톡방에 붙여볼 수 있는 현실적인 방법이었습니다.

생각보다 어려웠던 부분

당시에 비전공자로서 가장 어려웠던 점은, GPT가 코드를 만들어준다고 해서 바로 서비스가 만들어지는 건 아니라는 점이었습니다.

처음에는 ChatGPT에게 원하는 기능을 설명하고 코드를 생성하게 했습니다.

하지만 메신저봇R은 자료가 많지 않은 환경이었고, GPT가 최신 버전과 맞지 않는 코드를 제안하거나 실제 동작 방식과 다른 코드를 만들어내는 경우가 있었습니다.

FastAPI와 연결하는 과정에서도 문제가 많았습니다.

비동기 처리 문제, HTTP 요청 오류, 응답 구조 문제, CORS 문제처럼 직접 부딪혀야 하는 것들이 계속 나왔습니다.

결국 ChatGPT만으로는 해결되지 않는 부분이 있었고, Claude도 함께 사용하면서 코드 흐름을 다시 정리했습니다.

AI가 코드를 만들어주는 시대가 되었지만, 결국 내가 만들고 싶은 구조를 이해하고 있어야 했습니다.

어떤 도구가 어떤 역할을 해야 하는지, 어디까지는 메신저봇R에서 처리하고, 어디부터는 FastAPI 서버에서 처리해야 하는지, AI가 만든 코드가 왜 틀렸는지 판단할 수 있어야 했습니다.

AI를 잘 쓰는 능력은 단순히 프롬프트를 잘 쓰는 능력만은 아니었습니다.

내가 원하는 결과물의 구조를 이해하고, AI가 만든 결과를 수정할 수 있는 능력이 필요했습니다.

실제 적용은 기숙사 학생회 단톡방에서

이 봇은 당시 제가 활동하고 있던 학생생활관 관생자치위원회 단톡방에 적용했습니다.

단톡방 안에서 기숙사 식단을 확인하고, 학교 웹사이트 링크를 요약하고, 필요할 때는 AI API를 바로 호출할 수 있도록 만들었습니다.

거창한 협업툴을 새로 도입한 것은 아니었습니다.

그냥 모두가 이미 쓰고 있던 카카오톡방 안에 작은 자동화 기능을 붙인 것입니다.

하지만 저는 이 경험이 꽤 중요했다고 생각합니다.

AI를 조직에 도입한다고 해서 꼭 새로운 플랫폼을 만들 필요는 없었습니다.

사람들이 이미 일하고 있는 흐름 안에, 반복되는 정보 조회와 요약 기능을 작게 붙이는 것만으로도 충분히 의미가 있었습니다.

돌아보면 작은 AX 실험이 아니었나

기술적으로 깔끔한 제품이라기보다는, 어떻게든 실제로 돌아가게 만든 실험에 가까웠으나, 조직에서 이미 쓰고 있던 단톡방 안에 정보 조회와 요약 기능을 붙여봤다는 점이 좋았습니다.

반복해서 확인하는 식단, 매번 읽기 귀찮은 링크, 바로 물어보고 싶은 간단한 질문.

이런 작은 불편을 줄이는 것에서부터 조직 안의 AI 활용은 시작될 수 있다고 느꼈습니다.

요즘은 특히 2025년도를 거치면서 AI Agent, LLM, AX라는 말이 익숙해졌고, Notion이나 Slack 같은 업무 도구에 AI를 붙여 자동화하는 사례도 많아졌습니다.

하지만 2024년 당시에는 카카오톡 단톡방 안에 AI 요약 기능과 정보 조회 기능을 붙여 실제 조직에서 사용해본 것만으로도 나름 신박한 실험이었다고 생각합니다.

거창한 시스템은 아니었지만, 사람들이 이미 쓰고 있던 흐름 안에 AI를 넣어본 첫 경험이었습니다.

처음부터 거창하게 공모전을 준비했던 것은 아니었습니다.

어느 날 군 인트라넷을 보다가 우연히 「국방 AI 활용 아이디어 경연대회」 공고를 보게 되었습니다.

주제는 병력 절감을 위한 AI 기술 전장 활용 방안이었습니다.

처음 봤을 때는 그냥 “이런 공모전도 있구나” 정도였습니다. 그런데 이상하게 계속 눈이 갔습니다.

마침 그때 저는 군에서 당직을 서며 CCTV 감시 업무에 대해 여러 생각을 하고 있었습니다.

당직을 서면 40개가 넘는 내·외부 CCTV 화면을 계속 확인해야 했습니다. 상황일지를 기록하고, 이상 징후가 없는지 확인하고, 근무 시간 동안 화면을 계속 보고 있어야 했습니다.

처음에는 그냥 당직 업무 중 하나라고 생각했습니다.

그런데 계속 하다 보니 이 업무가 생각보다 단순하지 않다는 것을 느꼈습니다.

사람은 24시간 같은 집중력을 유지할 수 없습니다. 특히 새벽에는 피곤할 수밖에 없고, 여러 개의 화면을 계속 보고 있다고 해서 모든 이상 상황을 정확히 인지할 수 있는 것도 아닙니다.

더 근본적으로는, 앞으로 한국의 가용 병력은 계속 줄어들 텐데 정말 필요한 전투 업무나 전문 업무에 투입되어야 할 인력이 가만히 앉아 CCTV만 보고 있어야 한다는 점이 아쉽게 느껴졌습니다.

물론 CCTV 감시는 반드시 필요한 업무입니다.

하지만 그 방식이 계속 지금과 같아야 하는지는 의문이 들었습니다.

그때부터 이런 생각을 하게 되었습니다.

“CCTV를 더 많이 설치하는 것만으로는 해결되지 않는다.” “단순히 사람이나 차량을 탐지하는 AI만으로도 부족하다.” “중요한 것은 화면에 무엇이 보였는지가 아니라, 그것이 왜 중요한 상황인지 판단하는 것이다.”

사실 저는 그 무렵 온톨로지와 Graph RAG에도 관심을 갖고 있었습니다.

팔란티어에 대한 글을 읽으면서, 데이터를 단순히 많이 모으는 것보다 현실의 객체와 관계, 사건과 행위를 구조화하는 것이 중요하다는 관점을 접했기 때문입니다.

예전에는 빅데이터, 머신러닝, 회귀이론처럼 데이터를 분석하고 예측하는 쪽에 더 관심이 많았습니다. 그런데 팔란티어 이야기를 읽고 나서는 조금 다른 생각을 하게 되었습니다.

그래서 저는 이 공모전에 지원하게 되었습니다.

군 인트라넷에서 우연히 보게 된 2026 제1차 국방 AI 활용 아이디어 경연대회.

제가 제안하고 싶었던 것은 단순히 “CCTV에 AI를 붙이자”는 이야기가 아니었습니다.

이미 CCTV는 많습니다. 문제는 사람이 그 많은 화면을 계속 보고 있어야 한다는 점이고, 더 나아가 화면 속 상황을 사람이 즉시 판단해야 한다는 점입니다.

AI가 사람, 차량, 동물, 드론을 탐지하는 것은 중요합니다.

하지만 탐지했다고 해서 곧바로 판단이 끝나는 것은 아닙니다.

사람이 지나갔다고 해서 모두 침입은 아닙니다. 동물이 감지됐다고 해서 무조건 무시해도 되는 것도 아닙니다.

야간인지, 제한구역 근처인지, 반복적으로 발생한 위치인지, 이전에도 오탐이 많았던 구역인지, 현재 경계 등급은 어떤지 함께 봐야 합니다.

결국 문제는 탐지가 아니라 판단이었습니다.

그래서 제가 생각한 구조는 이랬습니다.

먼저 CCTV와 센서에서 사람, 차량, 동물, 장비, 구역 같은 객체를 인식합니다. 그다음 객체 사이의 관계를 장면 그래프로 만듭니다.

예를 들어 이런 식입니다.

“야간 시간대에 사람이 제한구역 방향으로 이동 중이다.”
“울타리 인근에서 반복적으로 움직임이 감지되고 있다.”
“이전에도 같은 위치에서 야생동물 오탐이 있었다.”
“현재 경계 등급상 해당 구역은 더 높은 우선순위로 확인해야 한다.”

이런 상황은 단순히 객체 하나를 탐지한다고 해결되지 않습니다.

사람, 시간, 위치, 구역, 이전 기록, 작전 기준이 함께 연결되어야 합니다.

이후 이 장면 그래프를 국방 도메인 개념 모델과 연결하고, Graph RAG를 통해 관련된 규정, 작전 기준, 과거 사례, 위협 판단 조건을 검색합니다.

마지막으로 LLM은 이 근거를 바탕으로 “왜 이 상황이 위협인지”, “왜 오탐 가능성이 높은지”, “어떤 조치를 우선해야 하는지”를 설명합니다.

즉, 제가 만들고 싶었던 것은 AI가 지휘관이나 근무자를 대체하는 시스템이 아니었습니다.

사람이 더 정확하게 판단할 수 있도록, AI가 상황의 맥락과 판단 근거를 정리해주는 시스템이었습니다.

서류를 제출한 뒤 큰 기대는 없었습니다.

그런데 예상과 다르게 서류심사를 통과했습니다. 본선 발표심사 대상자로 선정되었고, 본선 진출자는 총 지원자 약 230명 중, 12명이었습니다.

서류를 통과하고 나서는 발표자료를 준비해야 했습니다.

발표는 15분, 질의응답은 5분이었습니다.

제가 공부한 내용을 전부 설명하기에는 부족했고, 그렇다고 제가 공부한 내용이 그리 깊지도 많지도 않았습니다.

하지만 결국 핵심은 하나였습니다.

CCTV 경계 업무에서 사람의 한계를 AI가 어떻게 줄일 수 있는가.

이 질문 하나로 발표자료를 다시 정리했습니다.

당시 저는 이것을 온톨로지 기반 국방 AI라고 설명했습니다.

그런데 지금 다시 보면, 제가 말한 온톨로지는 엄밀한 의미의 온톨로지와는 거리가 있었습니다.

이 부분이 이번 공모전을 준비하고 나서 가장 크게 배운 점이었습니다.

온톨로지를 논리 명세로 본다면, 저는 아직 RDF, OWL, SHACL 같은 형식 논리 체계를 제대로 구현한 것이 아니었습니다.

온톨로지를 도메인 개념 모델로 본다면 어느 정도 가까웠습니다. 객체, 구역, 행동, 시간, 위협 조건, 판단 기준을 나름대로 구조화하려고 했기 때문입니다.

온톨로지를 데이터 통합 모델로 본다면 한계가 있었습니다. 실제 군 내부의 CCTV 로그, 상황일지, 작전 문서, 권한 체계, 감사 기록을 하나의 운영 데이터 모델로 통합한 것은 아니었기 때문입니다.

온톨로지를 AI Context Layer로 본다면 제가 생각한 구조와 꽤 가까웠습니다. LLM이 아무 말이나 생성하지 않도록, 그래프 기반의 맥락과 근거를 제공하려 했기 때문입니다.

하지만 팔란티어식 운영 플랫폼 Layer로 본다면 더더욱 아니었습니다.

팔란티어식 온톨로지는 단순히 그래프를 만드는 것이 아니라, 현실 세계의 객체, 관계, 권한, 액션, 함수, 업무 흐름을 하나의 운영 계층으로 연결하는 것에 가깝다고 이해하고 있습니다.

반면 제가 구현하고 설명한 것은 그보다 앞 단계였습니다.

저는 CCTV 경계 상황을 객체, 행동, 위치, 시간, 위협 조건으로 구조화하고, 그 구조를 Graph RAG의 검색 맥락으로 활용하려 했습니다.

그래서 더 정확히 말하면, 제가 만든 것은 팔란티어식 온톨로지 운영 플랫폼이 아니라 Graph RAG 기반 판단 보조 아이디어에 가까웠습니다.

이 차이를 이해하는 것이 중요했습니다.

Graph RAG는 LLM에게 더 좋은 문맥을 주기 위한 기술에 가깝습니다. 반면 팔란티어식 온톨로지는 단순히 검색 성능을 높이는 구조가 아닙니다.

현실 세계의 객체를 정의하고, 그 객체들이 어떤 관계를 맺고, 사용자가 어떤 액션을 취할 수 있으며, 그 액션이 어떤 권한과 감사 기록 아래 실행되는지를 포함합니다.

즉 Graph RAG가 “AI가 더 잘 답하게 만드는 구조”라면, 팔란티어식 온톨로지는 “조직이 더 잘 판단하고 실행하게 만드는 구조”에 가깝습니다.

당시의 제 아이디어는 분명 후자를 지향했지만, 실제 구현 수준은 전자에 가까웠습니다.

그래도 이 차이를 알게 된 것 자체가 저에게는 큰 배움이었습니다.

발표 당일에는 계획운영과장님께서 배려해주신 덕분에 당일치기로 서울에 다녀올 수 있었습니다.

새벽 4시에 부대에서 일어나 창원중앙역으로 이동했고, KTX를 타고 서울로 올라갔습니다.

발표 장소는 용산 전쟁기념관 피스앤파크 컨벤션이었습니다.

현장에 도착해서 발표 순서표를 보니 그때서야 조금 실감이 났습니다.

솔직히 발표장에 가서는 조금 위축되기도 했습니다.

다른 영관급 장교를 포함한 간부님, 군무원, 병사분들의 주제를 보니 단순한 아이디어 차원이 아니라 실제로 깊게 연구하고 있는 주제들이 많았습니다.

어떤 주제는 이미 현장에서 바로 실험해볼 수 있을 것 같았고, 어떤 주제는 실현 가능성이 매우 높아 보였습니다.

그래서 발표를 마치고 나서도 크게 기대하지 않았습니다.

제가 제안한 것은 완성된 기술이 아니었습니다. 실제 시스템을 만든 것도 아닌, 데모 영상 정도를 보여준 정도였습니다.

오히려 문제를 구조화하고, 그 문제를 AI와 그래프 구조로 풀어보자는 방향에 가까웠습니다.

발표가 끝나고 나서는 조금 허탈하기도 했습니다.

새벽부터 움직였고, 발표는 끝났고, 이제 결과만 남아 있었습니다.

그런데 결과는 예상과 달랐습니다.

장려상. 전체 4등. 한국오픈소스협회 협회장상.

솔직히 놀랐습니다.

다른 분들의 주제가 워낙 좋아 보여서 수상까지는 기대하지 않았습니다.

그런데 감사하게도 제 문제의식이 어느 정도 전달된 것 같았습니다.

완성된 기술을 보여준 것은 아니었지만, CCTV 경계 업무의 구조적 한계와 탐지 이후 판단의 문제를 이야기한 점이 의미 있게 받아들여진 것 같았습니다.

행사 이후에 관련 기사에도 사진이 실렸습니다.

이번 공모전은 저에게 단순히 상을 받은 경험으로 끝나지 않았습니다.

오히려 제가 무엇을 알고 있고, 무엇을 모르는지 확인한 경험이었습니다.

저는 온톨로지라는 말을 썼지만, 그것이 논리 명세인지, 도메인 개념 모델인지, 데이터 통합 모델인지, AI Context Layer인지, 운영 플랫폼 Layer인지 명확히 구분하지 못했습니다.

이제는 조금 더 정확히 말할 수 있을 것 같습니다.

제가 당시 제안한 것은 완성된 온톨로지 플랫폼이 아니었습니다.

국방 경계 도메인을 객체와 관계로 구조화하고, 그 구조를 LLM의 판단 근거로 활용하는 Graph RAG 기반 판단 보조 아이디어에 가까웠습니다.

하지만 그 차이를 알게 된 것 자체가 저에게는 큰 배움이었습니다.

앞으로는 RDF, OWL, SHACL, SPARQL 같은 시맨틱웹 계열의 기본기를 더 공부해야겠다고 느꼈습니다.

동시에 Neo4j 같은 LPG 기반 그래프 모델링도 익혀야 합니다.

그리고 데이터의 출처, 신뢰도, 감사 로그, 액션 모델, 운영 앱까지 고민해야 합니다.

그래야 단순히 “온톨로지 기반”이라는 표현에 머무르지 않고, 실제 현장에서 작동하는 판단 지원 시스템으로 발전시킬 수 있다고 생각합니다.

처음에는 그냥 당직 업무 중 하나라고 생각했습니다.

그런데 지금은 그 장면이 다르게 보입니다.

가만히 앉아 40개가 넘는 CCTV를 바라보는 사람. 반복되는 경보와 피로. 줄어드는 병력. 그럼에도 놓치면 안 되는 현장의 위험.

겉으로 보기에는 단순한 감시 업무처럼 보입니다.

하지만 안쪽에서는 병력, 피로, 경보, 판단, 책임, 데이터 구조가 계속 맞물려 돌아가고 있었습니다.

그리고 저는 그 현장을 다시 보고 싶어졌습니다.

이번에는 그냥 화면을 보는 것이 아니라, AI와 Graph RAG, 그리고 온톨로지라는 도구를 가지고.

저는 팔란티어식 온톨로지를 꿈꾸며 시작했지만, 실제로 만든 것은 Graph RAG에 가까웠습니다.

하지만 그 차이를 알게 된 것 자체가 저에게는 큰 진전이었습니다.

앞으로도 저는 그런 문제를 보고 싶습니다.

그냥 지나쳤던 현장을 다시 보고, 그 안의 객체와 관계를 정의하고, 사람이 더 나은 판단을 할 수 있도록 데이터 구조와 AI로 번역하는 사람.

이번 국방 AI 활용 아이디어 경연대회는 그 방향을 확인한 첫 번째 작은 결과였습니다.

처음에는 단순히 “국가나 공공기관에서 쓰던 물건을 경매로 파는 사이트” 정도로만 생각했습니다. 그런데 실제로 들어가 보니 생각보다 훨씬 다양한 물건들이 올라와 있었습니다.

경찰차, 소방차 같은 국가 불용차량도 있었고, 공공기관에서 사용하던 컴퓨터, 냉장고, 모니터, 책상 같은 물건들도 있었습니다. 조금 더 찾아보면 전기차 충전기처럼 일반적인 중고거래 플랫폼에서는 쉽게 보기 어려운 물건들도 올라와 있었습니다.

그때부터 저는 가끔 온비드를 구경했습니다. 딱히 무언가를 꼭 사야겠다는 목적이 있었던 것은 아니었습니다. 그보다는 “이런 물건도 공매로 나오는구나” 하는 호기심에 가까웠습니다.

그러다 어느 날, 꽤 특이한 물건 하나를 발견했습니다.

우즈베키스탄산 스마트폰이었습니다.

감정가 10,000원짜리 스마트폰

공고에는 물품명이 단순히 스마트폰이라고 적혀 있었습니다.

감정평가금액은 10,000원. 최저입찰가격도 10,000원이었습니다.

처음에는 그냥 오래된 저가 스마트폰인가 싶었습니다. 그런데 사진을 자세히 보니 조금 달랐습니다.

제품 박스에는 익숙하지 않은 브랜드 로고가 있었고, 국내에서 흔히 볼 수 있는 삼성, LG, 애플, 샤오미 같은 브랜드가 아니었습니다.

브랜드는 Artel mobile이었습니다. 제품에는 우즈베키스탄과 관련된 문구도 적혀 있었습니다.

그때는 이 제품이 얼마나 좋은지, 실제로 쓸 수 있는지보다 “왜 이런 스마트폰이 한국의 국가공매 사이트에 올라와 있지?”라는 점이 더 궁금했습니다.

26,800원에 낙찰받았습니다

저는 입찰금액으로 26,800원을 적어냈습니다.

감정평가금액은 10,000원이었지만, 저 말고도 이 물건에 관심을 가진 사람이 있었기에 당시 지갑사정도 함께 고려해서 고심 끝에 금액을 적어냈던 것이었습니다.

며칠 뒤 결과가 나왔습니다.

결과는 낙찰이었습니다.

다행히 여러 경쟁자 분들이 계셨지만, 다행히 이중엔 제가 가장 금액을 높게 썼더군요.

하지만 이 물건은 가격보다 이야기가 더 흥미로웠습니다.

실제로 받아본 Artel mobile 스마트폰

실제로 물건을 받아보니 생각보다 포장이 잘 되어 있었습니다.

파란색 케이스 안에 스마트폰이 들어 있었고, 케이스 겉면에는 정부기관에서 받은 기념품처럼 보이는 문구도 적혀 있었습니다.

케이스를 열자 안쪽에 스마트폰이 들어 있었습니다.

이건 제가 갖고 있을 물건이 아니라, 누군가가 더 재미있게 다룰 수 있는 물건이었습니다

처음에는 그냥 제가 신기해서 산 물건이었습니다.

그런데 제품을 받아보고 나니 한 가지 생각이 들었습니다.

이걸 제가 혼자 가지고 있는 것보다, 이 물건을 더 재미있게 다룰 수 있는 사람에게 보내면 어떨까?

당시 저는 IT 기기 리뷰 유튜브를 자주 봤습니다. 그중에서도 뻘짓연구소는 일반적인 제품 리뷰뿐만 아니라, 평소에 보기 어려운 특이한 기기들도 재미있게 다루는 채널이었습니다.

그래서 메일을 보냈습니다.

“이런 스마트폰을 온비드에서 낙찰받았는데, 혹시 리뷰해보실 생각이 있으신가요?”

큰 기대를 하지는 않았습니다만, 그런데 실제로 답장이 왔습니다.

이후 제품을 보내드렸고, 소정의 답례품도 받았습니다.

그리고 얼마 뒤, 제가 온비드에서 낙찰받은 우즈베키스탄 스마트폰은 뻘짓연구소 영상에 소개되었습니다.

관련 영상: 뻘짓연구소 영상 보기 링크텍스트

이후 영상으로 올라온 내용을 보면서

제가 생각했던 것보다 훨씬 더 재미있는 포인트들을 찾아내시는 것을 보고, 역시 유튜버는 유튜버라고 생각했습니다.

저에게는 그저 특이한 스마트폰을 낙찰받은 일이었지만, 뻘짓연구소 님은 그 안에서 우즈베키스탄 스마트폰, 현지 플랫폼, 낯선 브랜드라는 소재를 뽑아 하나의 재미있는 콘텐츠로 만들어주셨습니다.

이번 글은 그런 일이 있었다는 것을 소개하고 싶어서 작성했습니다.

고등학생 때 온비드에서 낙찰받은 우즈베키스탄 스마트폰이 뻘짓연구소 영상에 나오기까지의 과정.

지금 다시 생각해봐도 꽤 재미있는 에피소드였습니다.

누군가가 종이에 적고, 누군가가 단톡방에 공지하고, 누군가가 기억하고 있다가 다시 확인합니다. 겉으로 보기에는 큰 문제가 없어 보이지만, 실제로는 작은 비효율들이 계속 반복됩니다.

이번 글은 제가 군 복무 중에 만들었던 부대 복지관 셔틀버스예약 시스템에 대한 회고입니다.

저는 개발자라기보다는, AI를 활용해 문제를 정의하고 제품으로 만들어가는 AI-native Product Owner / Product Manager에 가까운 방향을 지향하고 있습니다.

그래서 이 글도 단순히 “웹사이트를 만들었다”는 개발일지보다는,

현장의 문제를 어떻게 발견했고, 그 문제를 어떤 흐름과 로직으로 정의했으며, AI에게 어떻게 설명해서 실제 서비스로 만들었는지 에 초점을 맞춰 정리해보려 합니다.

최종적으로 이 프로젝트는 실제 부대 운영에 적용되었고, 그 과정과 결과를 인정받아 전대장 상장을 받을 수 있었습니다.

처음부터 복지차 시스템을 만들려던 것은 아니었습니다

처음부터 복지차량 셔틀버스 시스템을 만들려고 했던 것은 아니었습니다.

처음에는 부대 안에서 운전병 배차를 조금 더 편하게 관리할 수 있는 시스템을 만들고 싶었습니다.

부대 환경에서는 일반적인 웹 서비스를 마음대로 도입하기 어렵습니다. 인트라넷 환경의 제약도 있고, 외부 서버나 데이터베이스를 자유롭게 붙이기도 어렵습니다.

그래서 처음에는 특정 컴퓨터 안에서만 돌아가는 HTML 기반 운전병 배차 시스템을 고민했습니다.

그때 제가 다루고 싶었던 문제들은 이런 것들이었습니다.

-운전병 순번을 어떻게 관리할 것인가
-휴가자가 생기면 어떻게 처리할 것인가
-대타가 들어가도 원래 순번이 꼬이지 않게 하려면 어떻게 해야 하는가
-해군식 계급과 호봉을 어떻게 자동 계산할 것인가
-인트라넷 환경 안에서 어떻게 관리 가능한 형태로 만들 것인가

처음에는 단순히 배차표를 조금 편하게 만들려는 시도였습니다.

그런데 시스템을 기획하다 보니 생각이 꼬리를 물었습니다.

어차피 운전병 배차를 관리할 거라면, 탑승자들도 밖에서 스마트폰으로 예약하고 현황을 볼 수 있게 만들면 어떨까? 운전병만 보는 배차표가 아니라, 실제 복지차를 이용하는 사람들도 함께 볼 수 있는 시스템으로 확장하면 어떨까?

이 생각이 들면서 프로젝트의 방향이 조금씩 바뀌기 시작했습니다.

처음에는 운전병을 위한 배차 관리 시스템이었습니다. 하지만 점점 탑승자와 운전병이 함께 사용하는 복지차 운영 시스템으로 확장되었습니다.

그렇게 부대 복지관 셔틀버스 예약 시스템이 시작되었습니다.

문제는 차량이 아니라 “기다림”이었습니다

복지관 셔틀버스는 항상 18시 30분에 출발했습니다.

그런데 실제 운영 과정에서 작은 비효율이 있었습니다.

복지차를 예약한 사람이 모두 왔는지 명확하게 확인하기 어렵다 보니, 이미 사람이 다 모였는데도 18시 30분이 될 때까지 기다리는 경우가 있었습니다.

반대로 아직 누가 오지 않았는지 확인하려면 운전병이나 담당자가 계속 인원을 확인해야 했습니다.

겉으로 보면 단순한 문제처럼 보였습니다.

“복지차는 정해진 시간에 출발한다.”

하지만 제가 보기에는 이것은 차량의 문제가 아니었습니다.

진짜 문제는 예약 현황이 시스템으로 관리되지 않는 것이었습니다.

누가 탈 예정인지 명확히 보이지 않기 때문에, 운전병 입장에서는 사람이 다 왔는지 아닌지 판단하기 어려웠습니다.

그래서 저는 복지차 운영을 이렇게 다시 정의했습니다.

복지차 시스템의 핵심은 단순히 예약을 받는 것이 아니라, 운전병이 “오늘 누가 타는지”를 확인하고, 사람이 다 왔다고 판단되면 더 빠르게 출발할 수 있게 만드는 것이다.

제가 만들고 싶었던 첫 번째 흐름은

탑승자가 스마트폰으로 복지차를 예약한다
↓
운전병은 오늘 예약자 명단을 확인한다
↓
예약한 사람이 실제로 다 왔는지 육안으로 확인한다
↓
다 왔다고 판단되면 18:30이 되기 전이라도 출발할 수 있다

중요한 것은 시스템이 모든 것을 자동으로 판단하는 것이 아니었습니다.

저는 탑승 확인까지 시스템으로 자동화한 것이 아니라, 예약자 명단을 명확히 보여주고 운전병이 육안으로 확인할 수 있게 하는 것을 우선했습니다.

즉, 시스템의 역할은 운전병의 판단을 대체하는 것이 아니라, 판단에 필요한 정보를 정리해주는 것이었습니다.

기존에는 운전병이 이런 고민을 해야 했습니다.

“오늘 누가 타기로 했지?” “다 온 건가?” “혹시 누가 아직 안 온 건가?” “조금만 더 기다려야 하나?”

저는 이 불확실성을 줄이고 싶었습니다.

예약자 명단이 명확히 보이면, 운전병은 현장에서 사람을 확인하고 더 빠르게 판단할 수 있습니다.

코드로 보면 단순한 예약 목록 기능일 수 있습니다. 하지만 제품 관점에서는 기다림의 불확실성을 줄이는 기능이었습니다.

처음에는 “예약”과 “취소”부터 제대로 만들어야 했습니다

복지차 시스템에서 가장 기본이 되는 기능은 예약이었습니다.

하지만 예약 기능을 만들다 보니 바로 다음 문제가 생겼습니다.

“본인이 신청한 예약을 어떻게 취소하게 할 것인가?”

회원가입을 시키기는 어려웠습니다. 부대원들이 사용하는 시스템인데, 매번 계정을 만들고 로그인하는 구조는 너무 무거웠습니다.

그래서 저는 처음에 4자리 숫자 비밀번호를 활용한 본인 확인 방식을 만들었습니다.

흐름은 단순했습니다.

이름을 입력한다
↓
복지차를 예약한다
↓
예약할 때 숫자 4자리 비밀번호를 함께 입력한다
↓
나중에 예약을 취소하려면 같은 비밀번호를 입력한다
↓
비밀번호가 일치하면 본인이 신청한 예약을 취소할 수 있다

이 방식은 완벽한 인증 시스템은 아니었습니다.

하지만 당시 상황에서는 적절한 수준의 해결책이었습니다.

회원가입 없이 사용할 수 있어야 했습니다. 본인이 신청한 예약은 직접 취소할 수 있어야 했습니다. 다른 사람이 마음대로 예약을 지우면 안 됐습니다. 구현 난이도는 너무 높지 않아야 했습니다.

그래서 4자리 숫자 비밀번호는 꽤 현실적인 선택이었습니다.

저는 이 기능을 만들면서 처음으로 제품에서 “적절한 수준의 인증”이 무엇인지 생각하게 되었습니다.

항상 완벽한 로그인 시스템이 필요한 것은 아닙니다. 중요한 것은 사용 맥락에 맞는 마찰과 안전장치의 균형이었습니다.

AI에게 “페이지”가 아니라 “문제와 조건”을 설명했습니다

이 프로젝트를 진행하면서 저는 AI를 단순히 코드 생성기로만 사용하지 않으려고 했습니다.

당시에 제가 사용했던 모델은 Gemini 2.5 Pro였습니다.

저는 Gemini 2.5 Pro를 활용해 기획, UI 구성, 코드 작성, 오류 수정, Firebase 연동, Render 배포까지 하나씩 진행했습니다.

중요한 것은 특정 모델명이 아니었습니다.

제가 이 프로젝트를 통해 배운 것은, AI에게 막연히 “복지차 예약 페이지 만들어줘”라고 말하는 것만으로는 부족하다는 점이었습니다.

제가 먼저 해야 할 일은 현장의 문제를 구조화하는 것이었습니다.

예를 들어 저는 AI에게 이런 식으로 설명했습니다.

'''복지차는 18시 30분에 출발합니다.
그런데 예약자가 모두 왔는지 알기 어렵다 보니, 다 왔는데도 기다리는 경우가 있습니다.

탑승자는 스마트폰으로 예약할 수 있어야 하고,
운전병은 오늘 예약자 명단을 확인할 수 있어야 합니다.

회원가입은 시키기 어렵습니다.
대신 예약할 때 4자리 숫자 비밀번호를 입력하게 하고,
취소할 때 같은 비밀번호를 입력하면 본인이 신청한 예약을 취소할 수 있게 만들고 싶습니다.'''

이런 식으로 문제와 조건을 설명하니, AI는 그 요구사항을 코드와 구현 순서로 바꿔주었습니다.

제가 했던 작업 방식은 대략 이랬습니다.

현장 문제를 설명한다
↓
사용자 흐름을 정리한다
↓
AI에게 기능 단위로 요청한다
↓
코드를 적용한다
↓
오류가 발생한다
↓
오류 로그를 다시 AI에게 보여준다
↓
수정한다
↓
다시 테스트한다

이 과정을 반복하면서 조금씩 실제 서비스에 가까워졌습니다.

처음에는 Firebase도 쓸 줄 몰랐습니다

처음에는 데이터베이스도 제대로 쓸 줄 몰랐습니다.

초기에는 화면에서 예약 기능이 동작하는 것처럼 보였습니다. 하지만 새로고침을 하면 데이터가 사라지는 문제가 있었습니다.

이 상태로는 실제 운영에 사용할 수 없었습니다.

겉으로 보기에는 서비스처럼 보여도, 데이터가 유지되지 않으면 사실상 데모에 가까웠습니다.

저는 이때 처음으로 느꼈습니다.

“화면이 동작하는 것과 실제 서비스가 되는 것은 다르다.”

그래서 Firebase Realtime Database를 붙이기로 했습니다.

처음에는 Firebase 설정도 낯설었습니다.

-Firebase 프로젝트를 어떻게 생성하는지
-웹앱과 어떻게 연결하는지
-데이터를 어떻게 읽고 쓰는지
-React 상태와 DB 데이터를 어떻게 연결하는지
-새로고침해도 데이터가 유지되게 하려면 어떻게 해야 하는지

모르는 것이 많았습니다.

그래서 하나씩 AI에게 물어봤습니다.

현재 코드와 오류 메시지를 보여주고, 어떤 부분이 문제인지 설명해달라고 했습니다. 그리고 수정된 코드를 받아 적용하고, 다시 테스트했습니다.

이 과정을 반복하면서 예약 데이터가 Firebase에 저장되기 시작했습니다.

이때부터 시스템은 단순한 화면이 아니라, 실제로 여러 사람이 사용할 수 있는 운영 도구에 가까워졌습니다.

누구나 쓸 수 있지만, 아무나 망가뜨릴 수는 없게 만들기

Firebase를 붙이고 나니 또 다른 문제가 생겼습니다.

복지차 시스템은 부대원들이 쉽게 사용할 수 있어야 했습니다. 그런데 매번 회원가입을 요구하기는 어려웠습니다.

사용자는 최대한 간단하게 접속해서 신청할 수 있어야 했습니다.

그래서 익명 접근 구조를 고민했습니다.

하지만 동시에 이런 위험도 있었습니다.

아무나 데이터를 삭제하면 어떻게 할 것인가 장난으로 여러 번 신청하면 어떻게 할 것인가 누군가 예약 데이터를 망가뜨리면 어떻게 할 것인가

즉, 시스템은 열려 있어야 했지만, 완전히 무방비 상태여서는 안 됐습니다.

처음에는 4자리 숫자 비밀번호로 본인이 신청한 예약을 직접 취소할 수 있게 만들었습니다.

그다음에는 Firebase 보안 규칙을 고민했습니다.

읽기와 쓰기는 가능하게 하되, 전체 데이터를 삭제하는 식의 위험한 동작은 막는 방향으로 설정했습니다.

이 과정에서 저는 단순히 기능을 만드는 것과, 실제로 운영 가능한 구조를 만드는 것은 다르다는 것을 배웠습니다.

기능은 “되게” 만들면 끝나는 것처럼 보입니다.

하지만 운영 시스템은 다릅니다.

누가 사용할지, 어떤 방식으로 잘못 사용할 수 있는지, 문제가 생겼을 때 어떻게 막을 수 있는지까지 고려해야 했습니다.

오남용 신청을 줄이기 위해 신청 이력 확인 기능도 추가했습니다

서비스를 실제로 운영하려면 오남용 가능성도 고려해야 했습니다.

누군가 장난으로 여러 번 신청하거나, 의도치 않게 중복 신청을 할 수도 있었습니다.

처음에는 4자리 숫자 비밀번호로 예약 취소 문제를 해결했습니다.

하지만 그것만으로는 반복 신청이나 장난 신청 가능성을 완전히 줄이기 어려웠습니다.

그래서 이후에는 신청 이력을 확인할 수 있는 기능도 추가했습니다.

당시에는 IP 주소를 기반으로 신청 이력을 확인하는 방식까지 고민했습니다.

다만 이 기능은 감시를 위한 것이 아니라, 운영 안정성을 위한 최소한의 장치에 가까웠습니다.

제가 원했던 것은 사용자를 통제하는 것이 아니라, 시스템이 장난 신청이나 중복 신청으로 망가지지 않게 하는 것이었습니다.

이 부분도 AI에게 다음과 같은 식으로 설명했습니다.

'''회원가입 없이 누구나 신청할 수 있어야 합니다.
그런데 같은 사용자가 반복적으로 신청하거나 장난 신청을 하는 것은 줄이고 싶습니다.
신청 이력을 확인할 수 있는 최소한의 IP추적 장치를 만들고 싶습니다.'''

이 기능을 붙이면서 서비스가 조금 더 실제 운영 시스템에 가까워졌습니다.

처음에는 단순한 예약 페이지에 가까웠지만, 점점 운영 정책과 예외 상황을 포함한 시스템이 되어갔습니다.

복지관 셔틀버스는 사람만 태우는 것이 아니었습니다

이후에는 택배 수령 기능도 추가했습니다.

복지차량은 단순히 사람만 이동시키는 수단이 아니었습니다. 실제 운영에서는 누군가의 택배나 물품을 함께 가져와야 하는 상황도 있었습니다.

그래서 택배를 수령할 인원들이 미리 신청하면, 담당자가 누구의 택배를 몇 개 가져와야 하는지 확인할 수 있도록 만들었습니다.

이 기능을 추가하면서 저는 다시 한 번 생각했습니다.

“사용자가 실제로 하는 행동은 무엇인가?”
“이 행동을 시스템 안에서 어떻게 자연스럽게 만들 수 있을까?”

단순히 입력 폼을 하나 추가할 수도 있었습니다.

예를 들면 이런 식입니다.

이름 입력
택배 수량 입력
신청 버튼

기능적으로는 충분합니다.

하지만 저는 조금 더 복지차라는 맥락에 맞게 만들고 싶었습니다.

차량 옆문을 클릭하면 택배상자가 나오게 했습니다

그래서 UI를 조금 다르게 구성했습니다.

스타렉스 차량의 옆면 문을 클릭하면 문이 열리고, 택배상자 이모지가 나타나는 방식으로 만들었습니다.

그 안에서 자연스럽게 이름과 택배 수량을 선택할 수 있게 했습니다.

기능만 보면 단순한 택배 신청 기능입니다.

하지만 사용자 경험 관점에서는 조금 달랐습니다.

복지차라는 맥락에서는 “차 문을 열고 택배를 싣는다”는 행동이 직관적이라고 생각했습니다.

그래서 택배 신청을 단순한 폼이 아니라, 복지차의 행동 흐름 안에 넣고 싶었습니다.

이 경험을 통해 UI에 대해 조금 다르게 생각하게 되었습니다.

UI는 단순히 예쁜 화면이 아닙니다.

좋은 UI는 사용자가 지금 무엇을 해야 하는지 자연스럽게 알려주는 구조라고 생각합니다.

스타렉스 옆문을 클릭하고, 택배상자가 나오고, 이름과 수량을 선택하는 흐름은 작은 디테일이었지만, 제가 제품을 바라보는 방식이 담긴 기능이었습니다.

내 컴퓨터에서 되는 것과 실제로 접속되는 것은 달랐습니다

로컬에서 실행되는 것과 실제로 누군가 접속할 수 있는 것은 완전히 다른 문제였습니다.

제 컴퓨터에서만 돌아가는 상태라면, 그것은 제품이라기보다 개인 프로젝트에 가까웠습니다.

실제로 부대원들이 사용하려면 URL로 접속할 수 있어야 했습니다.

그래서 GitHub에 코드를 올리고, Render를 통해 배포를 시도했습니다.

하지만 배포 과정도 쉽지는 않았습니다.

처음에는 빌드 오류가 계속 발생했습니다.

특히 이런 부분에서 문제가 생겼습니다.

package.json의 build script
Vite 설정
의존성 문제
Firebase 환경 변수 설정
Render 빌드 환경과 로컬 환경의 차이

처음에는 에러 로그 자체도 낯설었습니다.

하지만 이때도 AI에게 에러 로그를 그대로 보여주고, 어떤 부분이 문제인지 분석해달라고 했습니다.

예를 들어 이런 식이었습니다.

'''Render에서 배포하려고 하는데 빌드 에러가 납니다.
package.json과 vite.config.js를 보고 어떤 설정이 잘못됐는지 확인해주세요.'''

AI는 에러 로그를 바탕으로 빌드 스크립트와 설정 파일을 점검해주었고, 저는 수정된 내용을 적용하면서 다시 배포를 시도했습니다.

이 과정을 여러 번 반복한 끝에 Render를 통해 외부에서 접속 가능한 형태로 배포할 수 있었습니다.

그때 느꼈습니다.

“로컬에서 되는 것”은 시작일 뿐이고, “다른 사람이 접속해서 쓸 수 있는 것”부터가 제품에 가깝다.

이 프로젝트에서 제가 한 일은 코딩만이 아니었습니다

이 프로젝트에서 제가 한 일은 단순히 코드를 작성하는 것만은 아니었습니다.

물론 코드를 적용하고, 오류를 수정하고, Firebase와 Render를 붙이는 과정도 있었습니다.

하지만 더 중요한 것은 그 앞단에 있었습니다.

저는 먼저 현장에서 반복되는 문제를 발견했습니다.

그리고 그 문제를 기능으로 바로 바꾸기 전에, 운영 흐름으로 다시 정의했습니다.

복지차 시스템의 핵심 흐름은 다음과 같았습니다.

탑승자가 스마트폰으로 예약한다
↓
예약 시 4자리 숫자 비밀번호를 입력한다
↓
본인이 예약을 취소할 때 같은 비밀번호를 입력한다
↓
운전병은 오늘 예약자 명단을 확인한다
↓
예약자가 모두 왔다고 육안으로 확인되면 조기 출발할 수 있다
↓
필요한 경우 택배 수령 신청도 함께 관리한다
↓
오남용 신청은 최소한의 신청 이력 확인으로 줄인다

이 흐름을 만들면서 제가 했던 일은 다음과 같았습니다.

문제 발견
피벗 방향 설정
요구사항 정의
사용자 흐름 설계
AI에게 조건 제시
UI 구성
기능 구현
오류 수정
Firebase DB 연동
4자리 비밀번호 기반 예약 취소 기능 설계
익명 접근 구조 고민
보안 규칙 설정
오남용 방지 기능 추가
택배 수령 기능 추가
Render 배포
실제 운영 적용

저는 이 과정이 제가 지향하는 AI-native Product Owner / Product Manager의 일과 가깝다고 느꼈습니다.

단순히 아이디어를 말하는 것도 아니고, 단순히 코드를 작성하는 것도 아닙니다.

현장의 문제를 발견하고, 그것을 사용자의 흐름과 시스템 구조로 바꾼 뒤, AI와 기술을 활용해 실제 작동하는 결과물까지 만드는 일입니다.

전대장 상장을 받으며

결과적으로 이 프로젝트는 단순한 개인 실험으로 끝나지 않았습니다.

실제 부대 운영의 불편함을 줄이는 시도로 이어졌고, 그 과정과 결과를 인정받아 전대장 상장을 받을 수 있었습니다.

물론 이 시스템이 완벽한 제품이었다고 생각하지는 않습니다.

지금 다시 만든다면 더 나은 구조로 만들 수 있을 것입니다.

데이터베이스 구조도 더 깔끔하게 설계할 수 있고 권한 관리도 더 정교하게 만들 수 있고 UI도 더 체계적으로 구성할 수 있고 로그 관리와 운영자 화면도 더 잘 만들 수 있을 것입니다.

하지만 이 프로젝트는 저에게 중요한 의미가 있었습니다.

처음으로 제가 발견한 작은 현장 문제를 실제 조직 안에서 작동하는 시스템으로 바꿔본 경험이었기 때문입니다.

이전에는 막연히 “AI를 활용해 제품을 만들 수 있다”고 생각했습니다.

하지만 이 프로젝트를 하면서 조금 더 구체적으로 알게 되었습니다.

AI는 제가 모르는 기술을 대신 해결해주는 도구이기도 했지만, 더 중요하게는 제가 발견한 문제를 빠르게 제품으로 실험하게 해주는 실행 파트너였습니다.

그리고 AI가 아무리 좋아져도, 여전히 사람이 해야 하는 일이 있다는 것도 배웠습니다.

문제를 발견하는 일. 사용자를 관찰하는 일. 현장의 흐름을 이해하는 일. 무엇을 시스템으로 바꿀지 결정하는 일. 그리고 끝까지 실제로 작동하게 만드는 일.

저는 이 경험을 통해 제가 어떤 방향의 사람이 되고 싶은지 조금 더 선명하게 알게 되었습니다.

저는 단순히 코드를 많이 쓰는 개발자가 되고 싶은 것은 아닙니다. 또 아이디어만 말하는 기획자가 되고 싶은 것도 아닙니다.

현장의 문제를 발견하고, 사용자의 흐름을 정의하고, AI와 기술을 활용해 실제로 작동하는 결과물까지 만드는 사람.

저는 그런 AI-native Product Owner / Product Manager에 가까운 일을 하고 싶습니다.

나는 왜 부모님 가게의 POS 데이터를 분석하려고 할까.

부모님은 동네 슈퍼마켓을 운영하셨고, 저는 어릴 때부터 자연스레 아버지를 따라 세무서, 회계사무소, 구청, 지역 물류도매센터를 자주 따라다녔습니다.

그때는 그냥 아버지 따라다니는 일이었습니다.

어른들이 무슨 이야기를 하는지도 잘 몰랐고, 세금이 뭔지, 납품이 뭔지, 마진이 뭔지도 제대로 몰랐죠.

그런데 이상하게 재밌었습니다.

물건이 어디서 들어오고, 왜 어떤 상품은 갑자기 많이 들어오고, 왜 어떤 상품은 가격이 자주 바뀌고, 왜 어떤 거래처는 아버지에게 이것저것 부탁하는지.

그런 장면들이 어릴 때부터 계속 눈에 들어왔습니다. 지금 생각해보면, 나는 꽤 이른 시기에 장사의 뒷면을 보고 자란 것 같습니다.

겉으로 보기엔 동네 슈퍼마켓은 그냥 물건을 파는 곳입니다. 하지만 안쪽에서는 유통, 세금, 행정, 거래처, 가격정책, 고객 수요가 계속 맞물려 돌아가고 있었습니다.

그리고 지금 나는 그 현장을 다시 보고 싶어졌습니다.

이번에는 그냥 어깨너머로 보는 게 아니라, POS 데이터와 매출 데이터, 그리고 AI와 온톨로지라는 도구를 가지고.

시작은 그냥 아버지를 따라다니는 일이었죠.

어릴 때 저는 아버지를 따라 여기저기 많이 다녔습니다. 세무서도 가고, 회계사무소도 가고, 구청도 가고, 지역의 중형 물류도매센터도 갔습니다.

어린 제 입장에서는 다 신기했습니다.

세무서에서는 사업자와 세금 이야기를 하고, 회계사무소에서는 장부와 신고 이야기를 하고, 구청에서는 행정 처리와 허가 이야기를 하고, 물류도매센터에서는 상품과 납품 이야기가 오갔습니다.

지금 보면 이건 전부 작은 매장을 운영하기 위한 백오피스였습니다. 하지만 그때는 그냥 이런 생각을 했습니다. “장사라는 게 생각보다 복잡하네?”

슈퍼마켓은 단순히 물건을 사 와서 파는 곳이 아니었습니다. 어떤 상품을 들여올지, 어떤 가격에 팔지, 어떤 거래처와 관계를 유지할지, 어떤 행정 처리를 해야 하는지, 세금은 어떻게 내야 하는지, 손님들은 어떤 상품에 반응하는지. 이 모든 것이 매일매일 돌아가는 하나의 시스템이었습니다.

아마 그때부터였던 것 같습니다. 내가 비즈니스라는 걸 막연하게나마 재밌어하기 시작한 게.

유통은 생각보다 훨씬 복잡했습니다.

어릴 때 기억에 남는 장면이 하나 있습니다. 한 대형 식품회사 영업사원이 납품을 하러 온 적이 있었습니다.

그 회사에서는 지역 대리점마다 일종의 판매 장려 정책을 운영하고 있었습니다. 예를 들면 신제품을 일정 물량 이상 소진하면 대리점에 인센티브가 지급되는 구조였죠. 그러다 보니 현장에서는 꽤 복잡한 일이 벌어졌습니다.

영업사원은 아버지에게 이런 식으로 부탁했습니다.

“이 상품 몇 박스만 창고에 보관해주시면 안 될까요? 나중에 다시 회수해가겠습니다.”

어릴 때는 이게 무슨 말인지 잘 몰랐습니다.

왜 팔지도 않을 상품을 창고에 보관해달라고 하지? 왜 마진도 별로 없어 보이는데 굳이 저렇게까지 하지?

나중에야 조금 이해하게 됐습니다.

그 사람에게 중요한 건 단순히 우리 가게에 상품 몇 박스를 파는 게 아니었고, 회사와 대리점 사이에 걸린 판매 목표, 신제품 소진 물량, 인센티브, 영업 실적이 모두 연결되어 있었습니다.

그때 처음 느꼈습니다.

유통은 물건이 A에서 B로 이동하는 단순한 과정이 아니었습니다. 각자의 목표와 인센티브가 얽혀 움직이는 구조였습니다.

제조사는 신제품을 밀어야 하고, 대리점은 물량을 맞춰야 하고, 영업사원은 실적을 만들어야 하고, 매장은 팔릴 수 있는 상품인지 판단해야 합니다. 같은 상품 하나에도 여러 이해관계가 붙어 있었죠.

어릴 때는 그냥 신기한 장면이었습니다. 지금은 그게 일종의 비즈니스 구조였다는 생각이 듭니다.

법과 규정도 현장에서는 다르게 움직였습니다.

구청과 관련해서도 기억나는 일이 있습니다.

가게에 옥외 돌출형 광고판이 있었는데, 어느 날 부모님께 구청 담당자에게 연락이 왔습니다. 해당 광고판이 세금 부과 대상이니 세금을 내야 한다는 내용이었습니다.

처음엔 그런가 보다 했습니다.

그런데 시간이 지나 담당자가 바뀌자 이야기가 달라졌습니다. 이번에는 같은 광고판을 두고, 이건 해당 사항이 아니며 세금 대상이 아니라고 했습니다.

어릴 때 이 장면도 꽤 이상했습니다.

“같은 광고판인데 왜 담당자에 따라 말이 달라지지?”

그때는 단순히 행정이 이상하다고 생각했습니다. 그런데 지금은 조금 다르게 보입니다.

규정은 문서에 적혀 있지만, 실제 현장에서는 누가 어떻게 해석하느냐가 중요합니다. 담당자의 이해도, 해석 방식, 처리 의지에 따라 같은 사안도 다르게 적용될 수 있죠.

이 경험은 나중에 제가 온톨로지나 규정 기반 시스템에 관심을 갖게 된 배경과도 연결됩니다.

현장의 문제는 단순히 데이터를 많이 모은다고 해결되지 않습니다. 상황을 정확히 정의하고, 관련 규정을 연결하고, 맥락에 맞게 판단할 수 있어야 합니다.

작은 슈퍼마켓 하나를 운영하는 데에도 상품, 세금, 행정, 거래처, 고객이 모두 연결되어 있었습니다. 다만 그 연결이 시스템 안에 정리되어 있지 않았을 뿐입니다.

대부분은 부모님의 경험, 담당자와의 대화, 회계사무소 자료, POS 화면, 종이 서류 속에 흩어져 있었습니다. 문서는 남아있지만 현장의 암묵적 노하우가 사라져버린 현상을 "로스트 테크놀로지 현상" 이라고 부르더군요. 23년동안 유지되던 체계에 새로운 사람이 와서 문서만 본다고 이 체계가 유지될지 생각이 들었습니다.

대패삼겹살이 동네 슈퍼마켓에 들어오던 시절

제가 사업이라는 것에 진짜 관심을 갖게 된 장면은 따로 있습니다.

예전에 대패삼겹살이 주로 고깃집에서 유행하던 시절이 있었습니다. 그때 어떤 대표님이 직접 부모님 가게에 찾아왔습니다.

그분은 대패삼겹살을 동네 슈퍼마켓마다 납품하고 싶다고 했습니다.

아이디어는 단순했습니다.

“고깃집에서 대패삼겹살이 잘 팔리면, 동네 마트 냉동고에서도 팔 수 있지 않을까?”

생각해보면 정말 단순한 가설입니다.

고깃집에서 잘 팔리는 상품을 가정에서도 쉽게 사 먹을 수 있게 만들면 동네 슈퍼마켓에서도 수요가 생기지 않을까?

처음에는 그 대표님이 직접 영업을 다녔고, 직접 납품도 했습니다.

큰 회사처럼 보이지도 않았습니다. 오히려 작은 창고에 고기 써는 기계 하나 놓고 시작한 사업처럼 보였죠.

그런데 시간이 지나면서 상황이 달라졌습니다.

동네 슈퍼마켓과 마트에서 대패삼겹살을 저렴하게 팔기 시작하자 손님들이 반응했습니다. 집 근처에서 쉽게 살 수 있고, 가격도 부담 없고, 보관도 냉동고에 하면 되니 수요가 생긴 것입니다.

처음에는 대표님이 직접 오던 납품이, 어느 순간 영업사원과 배송기사들이 오는 구조로 바뀌었습니다.

거래처가 늘고, 물량이 늘고, 규모가 커졌습니다. 나중에는 인천 지역에 공장까지 지었다는 이야기도 들었습니다.

이 장면은 제에게 꽤 강하게 남았습니다.

처음에는 정말 작아 보였던 사업이었습니다. 그런데 현장의 수요, 상품의 형태, 가격대, 유통 방식, 소비 트렌드가 맞아떨어지자 사업이 확장됐습니다.

그때 처음 체감했습니다.

사업은 꼭 엄청난 기술에서만 시작되는 게 아니었고, 현장에서 발견한 수요를 사람들이 살 수 있는 형태로 바꾸는 것. 그리고 그것을 반복 가능한 유통 구조로 만드는 것.

그것만으로도 사업은 커질 수 있었습니다.

아마 이때부터였던 것 같습니다. 내가 “돈을 버는 구조”에 관심을 갖기 시작한 게.

그래서 중학생 때 사업자등록을 냈습니다

이런 배경 때문인지, 저는 어릴 때부터 창업가들을 좋아했습니다.

초등학교 6학년 때 내가 존경하던 사람은 쿠팡 창업자인 김범석 의장이었습니다. 중학생 때는 토스를 만든 이승건 대표님을 존경했습니다.

두 사람에게서 제가 본 것은 단순히 “돈을 많이 번 사람”이 아니었습니다.

사람들이 불편해하던 문제를 발견하고, 그걸 새로운 방식으로 풀어내고, 실제로 많은 사람들이 쓰는 서비스로 만든 사람들이었습니다.

그러다 중학생 때 직접 작은 사업을 해본 적이 있습니다. 세무서에 가서 사업자등록증을 냈습니다. 간이과세자로 등록했고, 구청에 통신판매업 신고도 했습니다.

그리고 쿠팡에서 파트너스 활동과 해외 구매대행 판매를 했습니다.

당시에는 운 좋게 특정 상품이 쿠팡에서 일명 '쿠런티'상품으로 지정되기도 했습니다.

그 흐름을 타고 한 달 동안 약 68만 원의 매출을 만들었습니다. 부가가치세와 플랫폼 수수료 비용을 제외하고 나니 순이익은 약 12만 원 정도였습니다.

지금 보면 정말 작은 숫자입니다. 하지만 중학생이었던 저에게는 꽤 큰 경험이었습니다.

내가 직접 상품을 올리고, 누군가 그 상품을 보고, 실제로 구매하고, 주문이 발생하고, 정산이 되고, 세금과 비용을 제외한 뒤 이익이 남는 과정.

그걸 직접 경험했습니다.

결국 학교생활과 병행하기 어려워서 폐업신고를 하게 됐지만, 그 경험은 아직도 기억에 남아 있습니다. 제가 좋아했던 건 단순히 돈이 아니었습니다.

내가 만든 작은 구조에 누군가 반응하는 순간. 내가 올린 상품을 누군가 실제로 구매하는 순간. 내가 만든 흐름이 현실에서 작동하는 순간.

그게 좋았습니다.

저는 결국 이런 일을 하고 싶은 것 같습니다

시간이 지나면서 내가 하고 싶은 일도 조금씩 명확해졌습니다.

저는 단순히 기술만 만드는 사람이 되고 싶은 건 아닙니다. 그렇다고 아이디어만 말하는 사람이 되고 싶은 것도 아닙니다.

제가 하고 싶은 일은 조금 더 전체 과정에 가깝습니다.

문제를 발견하고, 그 문제를 해결할 제품이나 서비스를 만들고, 고객에게 전달하고, 실제로 판매하고, 고객의 반응을 보고, 다시 개선하는 일.

그래서 PM이라는 역할에 관심을 갖게 됐습니다.

제가 생각하는 PM은 기획서만 쓰는 사람이 아닙니다. 고객의 문제를 이해하고, 기술과 비즈니스를 연결하고, 팀이 실제로 움직일 수 있게 만들고, 시장에서 검증되는 결과물을 만드는 사람에 가깝습니다.

생각해보면 부모님 가게에서 봤던 장사도 비슷했습니다.

상품을 고르고, 가격을 정하고, 진열하고, 팔고, 고객 반응을 보고, 다시 발주하고, 거래처와 협상하고, 정산하고, 세금을 처리합니다.

이 모든 과정은 작은 프로덕트 운영과 닮아 있었습니다.

그때는 그걸 데이터나 PM, 제품 운영이라는 말로 설명하지 못했을 뿐입니다.

다시 부모님 가게를 보게 된 이유

최근 저는 해군에서 의무복무를 하며 바이브코딩, LLM, RAG, 온톨로지에 관심을 가지고 공부하고 있습니다.

처음에는 기술 자체가 재밌었습니다.

LLM으로 무언가를 만들 수 있다는 것도 신기했고, RAG로 필요한 정보를 검색해 답변하게 만드는 것도 흥미로웠고, 온톨로지로 현실의 개념과 관계를 구조화한다는 것도 매력적이었습니다.

그런데 공부할수록 이런 생각이 들었습니다.

“이 기술을 어디에 써야 하지?”

멋진 데모를 만드는 것만으로는 부족하다고 느꼈습니다. 진짜 현장의 문제에 붙여보고 싶었습니다.

그러다 다시 가장 가까운 현장이 떠올랐습니다.

부모님 가게.

그곳에는 매일 데이터가 쌓입니다.

어떤 상품이 팔렸는지, 몇 시에 팔렸는지, 하루 매출은 얼마였는지, 손님 한 명이 평균 얼마를 쓰는지, 어떤 상품이 잘 팔리고, 어떤 상품은 생각보다 안 팔리는지.

이 데이터들은 이미 POS 안에 있습니다.

하지만 대부분의 작은 매장에서는 그 데이터가 제대로 활용되지 못합니다.

물론 POS에서도 기본적인 매출 조회는 가능합니다. 하지만 제가 보고 싶은 것은 단순한 매출표가 아닙니다.

저는 이 데이터를 더 넓은 맥락과 연결해보고 싶습니다.

VAN사 카드매출, 홈택스 자료, 상품별 판매 데이터, 시간대별 매출, 상권 데이터, 가능하다면 고객층과 날씨 데이터까지.

이런 것들을 연결하면 작은 매장도 꽤 많은 질문을 던질 수 있습니다.

특정 시간대에 잘 팔리는 카테고리는 뭘까? 재고가 자주 부족해지는 상품은 뭘까? 매출은 오르는데 왜 현금흐름은 답답할까?

이런 질문들에 답해보고 싶습니다.

제가 만들고 싶은 건 멋진 AI 대시보드가 아닙니다.

처음부터 거창한 AI 시스템을 만들 생각은 없습니다.

오히려 먼저 해야 할 일은 훨씬 단순합니다.

POS 데이터를 받아오고, CSV나 엑셀 형태로 정리하고, Python이나 Pandas로 데이터를 다듬고, 일별 매출, 시간대별 매출, 상품별 판매량, 객단가 같은 기본 지표를 보는 것.

그 다음에야 LLM이든, RAG든, 온톨로지든 붙일 수 있습니다.

제가 만들고 싶은 것은 “AI가 알아서 분석해주는 멋진 화면”이 아닙니다.

작은 매장의 운영자가 실제로 더 나은 결정을 내릴 수 있게 해주는 시스템을 만들고 싶습니다.

예를 들면 이런 식입니다.

“이 상품은 매출은 높은데 마진이 낮습니다.” “이 시간대에는 객단가가 낮습니다.” “이 카테고리는 비 오는 날 판매량이 증가합니다.” “이 상품은 재고가 자주 끊깁니다.” “이 조합은 함께 구매되는 빈도가 높습니다.”

이런 인사이트가 쌓이면, 단순한 대시보드가 아니라 작은 의사결정 시스템이 될 수 있습니다.

그리고 그 과정에서 제가 공부하고 있는 온톨로지도 써볼 수 있을 것 같습니다.

상품과 카테고리, 판매 시간대와 고객군, 매출과 마진, 재고와 발주, 상권과 수요.

이 관계들을 구조화하면, 단순한 숫자 이상의 것을 볼 수 있지 않을까 싶습니다.