목차
영웅문S#을 열었지만 아직 검색할 종목이 없는 사람에게 무엇을 먼저 보여줘야 할까. Itemify는 이 질문에서 출발했다. 종목 검색창 대신 오늘 손에 든 제품을 찍게 하고, 익숙한 브랜드 뒤의 상장기업을 보여주는 방식이다.
이 프로젝트는 키움 디지털 아카데미 4기에서 5명이 진행한 영웅문S# 간편모드 서비스 제안이다. 2026년 8월 3일부터 19일까지, 기획부터 작동하는 제품 완성까지 약 2주가 걸렸다. 마지막에는 키움증권 현직자 멘토와 관계자 앞에서 제품을 시연하고 최종 발표했다.
나는 5인 팀의 팀장으로 문제 정의와 사용자 조사·인터뷰, 백엔드 아키텍처, 스티커 생성 파이프라인, 최종 발표를 맡았다.
공식 영웅문S#에 출시된 기능은 아니다. 영웅문S#이 이미 가진 기업 정보와 주식 주문 영역 앞에, 초보자가 첫 기업을 발견하는 경험을 붙인 프로토타입이다.
핵심 아이디어는 짧다.
제품을 촬영한다 → 브랜드 뒤의 기업을 확인한다 → 스티커로 남긴다 → 관심이 생기면 영웅문S#의 소액주식 모으기 흐름으로 이동한다.
영상 다음에는 실제 제품을 직접 만져볼 수 있게 했다.
임베드가 보이지 않는 환경에서는 Itemify를 새 탭에서 열어 체험할 수 있다.
브랜드는 알지만, 기업은 떠올리지 못했다
처음부터 AI 카메라를 만들겠다고 정한 것은 아니었다. 먼저 주식 초보자가 첫 종목을 찾는 장면을 살폈다. 익숙한 제품은 많지만, 그 제품을 만든 기업을 투자 탐색의 출발점으로 연결하지 못하는 순간이 반복됐다.
주식 초보자 56명을 대상으로 설문하고, 2030세대 4명과 약 두 시간 동안 인뎁스 인터뷰를 진행했다. 브랜드와 기업을 연결하는 질문의 평균 오답률은 57%였다. 설문과 인터뷰를 함께 보니 문제는 세 갈래로 이어졌다.
조사 결과를 세 가지 제품 과제로 번역했다.
- 시작: 볼 기업을 고르는 기준이 없다 → 검색어 대신 카메라
- 연결: 아는 브랜드를 상장기업과 연결하지 못한다 → AI 단서와 검증 레지스트리
- 지속: 알아가는 과정이 공부처럼 느껴진다 → 스티커와 컬렉션
문제는 기업 정보가 부족해서가 아니었다. 기존 증권 앱은 종목명이나 검색어를 정한 뒤 들어가는 구조다. 초보자에게는 그 첫 검색어를 고르는 일부터 어렵다. 그래서 검색창보다 카메라를 앞에 두었다. 이미 아는 기업을 찾게 하기보다, 일상에서 몰랐던 기업을 발견하게 만드는 쪽을 택했다.
네 가지 기능으로 MVP의 경계를 정했다
약 2주 안에 만들 수 있는 범위를 촬영, 스티커 수집, 소액 투자 연결, 발견 랭킹·공유의 네 기능으로 제한했다. 제품을 찍었다고 그 회사를 바로 사게 만들지는 않았다. 익숙한 브랜드가 곧 매수 신호처럼 보이면 제품은 종목 추천 서비스로 변한다.
Itemify가 설계한 경험은 다음과 같다.
- 제품을 촬영해 브랜드와 기업을 확인한다.
- 발견한 기업을 회사 단위 스티커로 저장한다.
- 더 알아보고 싶으면 영웅문S#의 1,000원 단위 소액주식 모으기 흐름으로 이동한다.
- 최근 많이 발견된 기업과 다른 사용자의 스티커를 보며 탐색 범위를 넓힌다.
실제 주문 체결은 구현 범위에 넣지 않았다. 시세·호가·주문은 영웅문S#이 이미 잘하는 영역이기 때문이다. Itemify가 맡은 부분은 검색할 종목이 없던 사람에게 첫 기업을 발견하게 하는 일이었다.
스티커의 COMMON, UNCOMMON, RARE 등급에도 PER 같은 투자 지표를 쓰지 않았다. 저PER 기업을 ‘레어’로 표시하면 재미를 위한 등급이 추천 신호로 오해될 수 있다. 대신 브랜드명과 회사명이 다른지, 한 회사가 여러 소비재 브랜드를 보유하는지처럼 상장기업과의 연결을 알아차리기 어려운 정도만 반영했다. 도감의 한 칸도 브랜드가 아니라 회사 하나로 정의했다.
AI는 사진을 읽고, 기업은 검증 데이터가 결정했다
사진에서 브랜드를 읽는 것보다 위험한 일은 그럴듯하지만 틀린 회사를 자신 있게 보여주는 것이었다. 그래서 인식 성공률을 높이기 전에 잘못된 기업 확정을 줄이는 구조부터 만들었다.
파이프라인은 네 단계로 나눴다.
- 브라우저에서 촬영 영역을 자르고 크기를 줄인 뒤 EXIF와 GPS를 제거한다.
- Tesseract OCR이 포장의 글자를 먼저 읽는다.
- OCR만으로 부족할 때 Gemini가 제품명·브랜드·제조사와 화면에서 확인한 근거를 구조화한다.
- 브랜드의 소유 기업, 상장 여부와 종목코드는 팀이 검수한 레지스트리에서만 결정한다.
AI에게 “이 종목은 무엇인가”를 그대로 묻지 않았다. 모델은 사진 속 단서만 읽고, 기업과 종목코드를 붙이는 일은 코드와 검증 데이터가 맡았다. 결과보고서 제출 당시 브랜드→기업 매핑 101건을 직접 구축해 전수 검수했다.
인식 결과도 성공과 실패 두 가지로 줄이지 않았다.
CONFIRMED: 검증된 기업 하나로 확정AMBIGUOUS: 후보 2~3개를 사용자가 직접 선택UNMAPPED: 읽은 브랜드는 있지만 아직 레지스트리에 없음UNKNOWN: 근거가 부족해 재촬영이나 텍스트 검색이 필요NOT_A_BRAND: 수집 대상 제품이 아님PROVIDER_ERROR: 외부 모델이나 네트워크가 실패
못 알아보는 상황과 시스템이 고장 난 상황을 같은 문구로 처리하지 않기 위해 PROVIDER_ERROR를 별도로 뒀다. 비전 샘플과 상장 모회사 연결 비교에서도 “맞혔는가”만 보지 않고, 전혀 다른 회사를 말하는 오류를 따로 확인했다.
틀린 회사를 보여주지 않는 것이, 못 알아보는 것보다 중요했다.
React 프론트와 FastAPI 서버리스 함수를 단일 Vercel 프로젝트에 둔 것도 의도한 선택이었다. 별도의 프론트·백엔드 주소와 CORS 설정을 관리하지 않고, 같은 도메인 안에서 화면과 /v1/* API를 함께 배포했다.
제품 사진에는 집 안 배경, 얼굴, 촬영 위치가 함께 담길 수 있다. 누끼는 브라우저의 IS-Net과 ONNX Runtime에서 처리하고, EXIF와 GPS를 제거한 뒤 사용자가 선택한 프레임만 서버로 보냈다. 원본과 모델의 원문 응답은 저장하지 않았다. 사용자가 확인한 투명 PNG만 비공개 객체 저장소에 올리고, DB에는 기업·브랜드 ID와 최소 인식 메타데이터를 남겼다.
인식과 누끼도 한 덩어리로 묶지 않았다. 둘을 병렬로 실행하되 한쪽이 실패해도 다른 결과는 살렸다. 네트워크 때문에 기업 인식이 실패해도 누끼 결과를 다시 쓸 수 있고, 브라우저 컷아웃이 실패해도 기업 정보는 확인할 수 있게 했다.
스티커는 장식이 아니라 다시 돌아오게 하는 기록이었다
한 번 기업을 확인하고 앱을 닫으면 검색 경험과 크게 다르지 않다. 그래서 촬영 결과를 회사 단위 스티커로 남기고, 컬렉션에서 다시 꺼내보게 했다. 관심이 생긴 기업은 소액주식 모으기로 연결했다.
그런데 촬영할 때마다 생성형 이미지 API를 호출하면 비용이 바로 쌓인다. 스티커는 리텐션 장치이면서 동시에 가장 큰 운영비 후보였다. 같은 휴대폰 사진을 반복 호출해 모델, 프롬프트, 입력 크기를 하나씩 바꿨다.
처음부터 가장 싼 모델을 고르지 않았다. 제품의 형태와 패키지 특징이 유지되는지 먼저 보고, 그 기준을 통과한 후보 안에서 시간과 비용을 비교했다. 그다음 프롬프트와 입력 이미지를 줄였다.
비교 기준은 모양 오차, 패키지 글자 보존, 사진 속 손 제거, 투명 배경, 생성 시간, 장당 비용이었다. 형태와 글자 보존이 좋은 후보는 투명 배경을 직접 만들지 못했다. 그래서 생성과 규칙적 후처리를 한 모델에 억지로 맡기지 않았다.
장표의 62.9원은 제품 밖의 빈 영역까지 큰 캔버스로 처리하던 초기값이다. 먼저 캔버스 비율을 바로잡아 41.9원으로 낮췄고, 이후 모델·프롬프트·입력 크기를 차례로 조정했다. 아래 72%는 이 41.9원을 기준으로 계산한 값이다.
변경은 세 단계였다.
- 이미지 모델을 교체해 41.9원 → 30.0원으로 낮췄다.
- 프롬프트를 717토큰 → 222토큰으로 줄여 26.5원까지 낮췄다.
- 모델에 보내는 입력 이미지를 3,258px → 224px로 줄여 11.8원까지 낮췄다.
입력 이미지를 224px로 줄이면서 포장 글자가 깨질 가능성은, 인식 단계에서 얻은 OCR 문자열을 이미지 모델에 함께 전달하는 방식으로 보완했다. 같은 파이프라인에서 이미 얻은 정보를 다시 활용해 입력 비용을 낮춘 것이다.
발표 당시 모델 가격과 같은 샘플 한 장을 기준으로 약 72% 절감했다. 모델 가격이나 사진 조건이 달라지면 그대로 재현되는 보편적 절감률은 아니다. AI가 하지 않아도 되는 작업은 코드로 옮겼다.
AI는 제품의 특징을 보존한 캐릭터 이미지를 만드는 일에만 집중했다. 투명 배경 정리, 크기 통일, 흰 외곽선과 캔버스 배치는 Pillow로 처리했다. 생성 결과는 일정 기간 기기 캐시에 보관해 같은 스티커를 다시 그릴 때 외부 호출을 반복하지 않게 했다.
비용만 낮추면 운영 가능한 파이프라인이 되지는 않는다. 이미지 API에는 429 rate limit과 5xx 오류가 생길 수 있다. 구현에서는 429와 500·502·503·529만 최초 호출 포함 최대 4회, 즉 재요청은 최대 3회로 제한했다. 대기는 8초부터 늘리되 한 번에 20초를 넘지 않고 전체 생성 예산 안에서만 진행한다. 타임아웃은 이미 생성이 끝났을 때 이중 과금될 수 있어 자동 재시도하지 않는다. 끝내 실패하면 프론트가 브라우저에서 만든 누끼를 대체 이미지로 남기고, 사용자가 스티커 생성을 다시 요청할 수 있게 했다.
5명이 병렬로 움직이기 위해 계약부터 만들었다
약 2주 안에 조사, 데이터, 제품 인식, 프론트와 스티커 생성을 동시에 진행해야 했다. 한 파트가 끝난 뒤 다음 파트가 시작되는 방식으로는 시간이 부족했다.
FastAPI의 /docs를 API 계약서로 공유하고, 인식 엔진이나 DB가 없어도 같은 응답 모양을 돌려주는 샘플 모드를 만들었다. 프론트는 실제 AI 연결을 기다리지 않고 CONFIRMED, AMBIGUOUS, UNMAPPED 같은 상태별 화면을 먼저 구현할 수 있었다.
GitHub 이슈와 PR로 화면·API·데이터 경계를 합쳤고, Vercel 배포본을 모바일에서 직접 확인했다. 구현 중에는 기획 문서를 넘기는 데 그치지 않고, 실패 상태와 데이터 계약이 실제 코드에서 같은 의미를 갖는지 계속 맞췄다.
5명 테스트는 가능성과 한계를 함께 보여줬다
최종 사용자 테스트에는 5명이 참여했다. 정해진 과업을 수행하는 동안 막힌 지점과 클릭 위치를 기록했다. 투자 정보 확인과 ‘요즘 사람들의 발견’ 화면에서 높은 오클릭이 나타나, 두 화면을 우선 개선 대상으로 정했다.
86.1%와 95.2%는 성과 수치가 아니라 오클릭 발생률이다. 별도 인터뷰에서 사진 촬영형 기업 정보는 5명 모두, 스티커 수집은 4명이 주식 진입장벽을 낮추거나 다시 보고 싶게 만드는 요소로 평가했다. 하지만 이 작은 표본으로 투자 전환율이나 장기 리텐션을 말할 수는 없다.
이번에 구현하고 확인한 범위는 분명했다.
- 촬영한 제품을 기업 정보로 연결하는 흐름
- 틀린 기업 확정을 줄이는 검증 구조
- 발견을 스티커와 회사 단위 컬렉션으로 남기는 경험
- 실제 모바일 웹에서 작동하는 MVP
반대로 실제 주문 체결, 장기 사용, 다양한 조명·반사·가림을 포함한 운영 수준의 인식 정확도는 아직 검증하지 않았다. 브라우저 누끼 엔진의 상용 라이선스와 첫 모델 다운로드 크기도 상용화 전에 풀어야 할 문제다.
최종 발표에서 다시 확인한 제품의 경계
Itemify는 키움 디지털 아카데미에서 조사 자료만 발표한 프로젝트가 아니었다. 영웅문S# 안에서 어떻게 시작하고, 어떤 데이터를 거쳐, 어디에서 기존 투자 기능으로 넘길지까지 작동하는 제품으로 만들어 현직자 앞에서 시연했다.
발표를 준비하며 가장 많이 설명한 것은 AI 모델 이름보다 “무엇을 자동화하지 않았는가”였다.
- AI가 말한 종목코드를 그대로 쓰지 않았다.
- 희귀도에 PER을 넣지 않았다.
- 원본 사진을 저장하지 않았다.
- 5명 테스트를 투자 전환의 증거라고 부르지 않았다.
발견 랭킹도 수익률이나 상승률이 아니라 최근 7일 동안 사람들이 마주친 횟수로 정렬했다. 익숙한 브랜드를 보여주는 것은 매수 대상을 골라주는 일이 아니라, 사용자가 직접 알아볼 기업의 범위를 좁혀주는 일이기 때문이다.
금융과 AI가 만나는 제품에서는 할 수 있는 기능의 수보다, 사용자가 오해하지 않도록 경계를 어디에 긋는지가 더 중요했다. Itemify는 제품 사진을 읽는 AI 데모에서 멈추지 않고, 일상의 소비를 기업 발견으로 바꾸고 그 발견을 다시 꺼내볼 수 있는 기록으로 만든 프로젝트였다.
- 기간: 2026.08.03–08.19, 기획부터 제품 완성까지 약 2주
- 팀: 4인
- 맥락: 키움 디지털 아카데미 4기 · 영웅문S# 간편모드 서비스 제안 · 현직자 대상 최종 발표
- 역할: 팀장 · 기획 · 사용자 조사/인터뷰 · 백엔드 아키텍처 · 스티커 파이프라인 · 발표
- 기술: React · Vite · TypeScript · Zustand · FastAPI · PostgreSQL · Vercel · Gemini · GPT Image · Tesseract OCR · IS-Net
- 데모: Itemify 바로 보기
- 개인 회고: Itemify에서 팀장과 백엔드를 함께 맡은 2주