프로젝트 요약
SKALA 프로젝트
SKALA
01 · Solo · Spring AI
SKALA증권 세무상담 데스크
금융소득 종합과세 대상인지와 세액을 법령 근거와 함께 답하는 상담 AI입니다. 세무 상담에서는 근거 없는 답이 무책임하고, 계산이 빠진 답은 쓸모가 없습니다.
역할을 나눈 방식
- 법령 근거는 RAG, 세액 계산은 Tool Calling으로 나눠 두 결과를 함께 산출
- 세법 문서 9종을 조문 경계로 잘라 청크 39개를 만들고, 각 청크에 조문 번호를 실어 인용
- 범위 밖 질문은 규칙·모델 2단 라우팅으로 모델을 부르기 전에 거절
- 서비스 주체를 국세청이 아닌 가상 증권사로 잡음 — 업무 범위가 좁아야 거절이 정직한 답이 되기 때문
만든 다음에 한 일
계산 코드에 버그 7종을 일부러 심어 테스트가 6종을 잡아내는지 확인했습니다. 걸러지지 않은 1종은 원인을 끝까지 좇아가 분리과세를 선택하면 값은 계산되지만 결과에 반영되지 않는 문제를 찾았습니다. 세법 원문과 대조하다 개정 전 11%로 남아 있던 Gross-up 율도 10%로 고쳤습니다.
- Spring AI
- RAG
- Tool Calling
- 검증 설계
02 · Team · 2인
차량용 교통표지판 인식 모델 경량화
정확도가 이미 98.5%였습니다. 더 올릴 방법을 찾다가 모델 구조를 뜯어보고 방향을 바꿨습니다. 파라미터 218만 개 중 연결만 담당하는 한 층이 96%를 차지하고 있었습니다.
목표를 바꾼 근거
차량에서는 이 모델 하나만 메모리를 쓰지 않습니다. 차선·차량·보행자 인식 모듈이 같이 돌아야 합니다. 그래서 정확도 1%p를 더 올리는 것보다 크기를 절반 이하로 줄이는 편이 탑재 관점에서 이득이라고 보고 목표를 경량화로 잡았습니다.
결과
- 실험 21종 비교 — 최종 파라미터 25.2%, 크기 8.33MB → 2.10MB
- 3개 시드 평균 정확도 차이는 0.09%p로 시드 변동폭과 비슷한 수준
- 추론 시간은 직접 재봤습니다. 한 장씩은 작은 모델이 오히려 느리고(0.174ms vs 0.099ms), 배치로는 빨랐습니다(0.080ms vs 0.216ms). 파라미터 수만으로 속도를 판단할 수 없었습니다.
팀 의견을 되돌린 지점
Test 정확도가 예상보다 낮게 나오자 “모델을 바꾸자”는 의견이 나왔습니다. 하지만 Test를 보고 모델을 고르면 그 시험지에 우연히 맞은 결과가 섞입니다. 원인을 좇아가 보니 모델이 아니라 데이터 분할이었습니다. 같은 표지판을 연속 촬영한 30장짜리 묶음 888개가 학습과 검증 양쪽에 걸쳐 있었습니다. Test는 순위를 정하는 점수가 아니라 격차의 원인을 찾는 자료로만 쓰자고 정리했습니다.
다음 사람을 위해 남긴 것
확신하지 못할 때 차량이 어떻게 동작할지, 정지·속도제한처럼 안전과 직결된 클래스를 따로 봐야 한다는 것, 야간·역광·우천은 이번 데이터로 확인하지 못했다는 것을 미검증 항목으로 명시했습니다.
- PyTorch
- 모델 경량화
- 실험 설계
- CNN
03 · SKALA · 4인 팀 · 프론트엔드
EDU:UP — 교육복지포인트 플랫폼
회사가 배정한 교육복지포인트가 쓰는 사람만 계속 쓰고 정작 배워야 할 사람에게는 닿지 않는 문제를 다뤘습니다. 직원 쪽에서는 목록이 수백 개라 고르는 일이 부담이 되어 미루다 분기 말에 포인트가 소멸됩니다. 같은 원인이 직원에게는 미사용으로, 회사에는 편중으로 보였습니다.
서비스가 대신 고르게
한 번 직무와 관심 분야를 답하면 강의 2개와 도서 2권, 네 건만 받습니다. 직원이 할 일은 확인하고 신청 버튼을 누르는 것으로 줄었습니다. 성과는 배정한 교육비가 실제로 쓰인 비율과 추천을 보고 신청까지 간 비율 두 가지로 보기로 했습니다.
돈이 걸린 흐름만 이벤트로
- 신청과 확정을 분리 — 신청은 바로 접수로 두고, 차감이 끝났다는 소식을 받은 뒤에만 확정으로 바꿈
- 결과를 모르는 것과 실패는 다르게 처리 — 소식이 오지 않으면 접수로 두고 다시 확인하고, 잔액 부족처럼 분명한 경우만 실패로 남김
- 같은 사람이 동시에 누르면 막아 잔액이 음수로 내려갈 길을 열지 않음
- 취소는 포인트를 되돌리는 처리가 필요해 다음 스프린트로 미룬다고 명시
제 범위
4인 팀에서 프론트엔드를 맡아 Gateway 뒤 다섯 개 서비스를 화면에 붙였습니다. 서비스 경계는 제공된 템플릿 구조를 그대로 두고, 표기 규칙과 값만 바꿔 도메인을 옮겼습니다. MSA 구조를 제가 설계한 것은 아닙니다.
- MSA 실습
- 이벤트 설계
- 프론트엔드
- Agile · Scrum
04 · Solo · 서비스 설계
관계부 — 기능·화면·ERD·API 설계
5월에 만들어 매일 쓰던 관계부를 과제로 다시 설계했습니다. 페인 포인트와 기능을 하나씩 맞춰 보니 AI 관계 분석, 카톡 대화 가져오기, 리마인더는 연결되는 곳이 없었습니다. 받은 금액을 확인하고 명부를 정리하는 데는 기록과 조회면 충분해서 뺐습니다.
순서대로 맞춘 것
- 페인 포인트 4개 → 기능 18개 → 화면 11개 → 테이블 6개 → API 33개
- API마다 어느 화면에서 부르는지 적었습니다
- 화면에만 보이고 저장하지 않는 값(건수, 하트, 명부 합계)은 표로 따로 정리했습니다
- 뺀 기능은 지금 테이블과 API로 바로 만들 수 있으면 Phase 1, 외부 연동이 필요하면 Phase 2로 나눴습니다
고민했던 것
- 차액은 계산할 수 있지만 보여 주지 않았습니다. 관계를 숫자로 따지게 될 것 같았습니다. 대신 ‘보내기만 한 / 받기만 한’ 목록을 뒀습니다.
- 축의금은 경조사보다 주고받은 돈에 가깝다고 보고 gifts에만 뒀습니다. 두 곳에 두면 합계가 두 번 잡힙니다.
- 중복 입력은 화면과 DB에서 둘 다 막았습니다. 화면만 막으면 동시에 넣는 경우를 놓치고, DB만 막으면 저장을 누른 뒤에야 알게 됩니다.
- 다른 사람의 기록에 접근하면 403이 아니라 404를 줬습니다. 경조사 금액은 기록이 있다는 것만 알려져도 민감하다고 봤습니다.
- 요구사항 정의
- ERD · dbml
- OpenAPI 3
- Vue 3 · Pinia
팀에서 만든 것
With
a Team
01 · Team · 7인 · PM
퀴켓 — AI 퀴즈 학습 앱
내 필기를 넣으면 AI가 문제를 만들어 주는 학습 앱입니다. 일곱 명이 만들어 양대 스토어에 올렸습니다.
가장 어려웠던 결정
팀원 전원이 본업이 있어 쓸 수 있는 시간은 주말뿐이었습니다. 인터뷰 12건으로 정의한 기획안은 그 시간 안에 끝낼 분량이 아니었습니다. 기능을 삭제하는 대신 데이터 구조는 설계안대로 두고 화면 노출만 줄여, 출시 후 화면만 붙이면 되는 상태로 남겼습니다.
내가 한 일
- 사용자 인터뷰 12건으로 문제 정의를 다시 씀
- PRD·IA·기능명세·유저플로우 작성, 와이어프레임 100화면 이상
- 기능명세를 스프린트로 나눠 개발자 4명 일정 운영, 백엔드 ERD를 정책과 대조 검토
- 핵심 로직만 담은 미니 버전을 직접 구현해 검증한 뒤 본 개발로 넘김
- 사용성 테스트, 스토어 심사 대응, 중간·최종 발표
결과
3개월 만에 App Store·Google Play 동시 출시. 동아리 PM MVP 선정.
- 기획
- 사용자 조사
- 스토어 출시
- 스코프 조정
02 · Team · 2인 · 프로토타입
에이링크 — AI 링크·QR 북마크
링크와 QR코드를 한곳에 모으는 북마크 서비스입니다. 링크를 넣으면 AI가 폴더·이름·설명·태그를 채웁니다. 정식 서비스가 아니라 2인이 만든 프로토타입이며, 아래 링크에서 직접 눌러 볼 수 있습니다.
주요 기능
- 링크를 추가하면 AI가 폴더 분류·링크명·설명·태그를 자동 생성
- 웹·앱 통합 북마크 + 포털 검색 내장
- 링크에 할 일과 알림을 붙여 기록 관리
QA에서 뒤집은 것
로그인 벽과 봇 차단으로 AI가 아예 읽지 못하는 링크가 생각보다 많았습니다. 자동 분류 실패를 예외 처리로 두면 사용자가 그 자리에서 막힙니다. 그래서 실패를 예외가 아니라 기본 경로로 바꿔 바로 직접 채워 넣도록 흐름을 다시 설계했습니다.
내 범위
기획 전반과 프론트엔드 프로토타입을 맡았고, 요구사항을 말로 맞추는 대신 프로토타입을 먼저 배포해 기준으로 고정한 뒤 React 19·TypeScript로 이관했습니다. 서버·DB 구조와 인프라는 팀 백엔드 개발자가 설계했습니다.
- AI 자동 분류
- React 19
- PWA
- 프로토타입
03 · Team · 라벨링 도구 담당
데이콘 블랙박스 대회 — 팀 라벨링 도구
주행 영상으로 재촬영 여부·사고 시점·주행 상태를 맞히는 3단계 모델 대회입니다. 저는 모델이 아니라 팀이 영상을 보고 라벨을 넣는 도구를 만들었습니다. 폴더째 넣으면 클립이 이어서 재생되고, 키보드만으로 판정하면 CSV가 쌓입니다.
사람이 판단하고, AI는 참고만
AI 초벌 라벨과 기존 라벨은 회색 참고 오버레이로만 띄우고 자동으로 채워 넣지 않게 했습니다. 판단이 안 서면 UNSURE·NEEDS_REVIEW로 표시하고 넘어가게 해, 망설이는 시간이 라벨 품질을 깎지 않게 했습니다.
프레임 하나가 라벨을 가른다
- 충돌·진입 프레임은 마킹 직후 ±7프레임 미세 조정 모드로 들어가고, 0.25× 슬로우 재생과 1프레임 이동으로 확정
- 재촬영 판정의 근거인 모아레·스캔라인은 리사이즈 화면에선 안 보여 원해상도 100% 줌을 한 키에 둠
- fps는 컨테이너 메타데이터를 믿지 않고 프레임수 ÷ 실제 길이로 다시 계산해 저장 — 메타데이터가 틀린 클립을 겪고 정한 규칙
중간에 꺼져도, 여럿이 해도
- 판정 즉시 CSV에 append — 크래시가 나도 유실이 없고, 다시 실행하면 완료한 클립을 건너뛰고 이어감
- 검수자 이름이 파일명에 들어가 같은 배치를 여러 명이 보면 불일치율을 잴 수 있음. 클립당 소요시간도 행마다 기록
- 목표는 클립당 20~30초. 검수 배치 생성 스크립트와 검수 가이드를 함께 넘김
- Python · OpenCV
- 키보드 UX
- 프레임 정밀도
- 이어하기 · CSV
04 · Team · 외부 협업
AI 세무 챗봇 — 삼일회계법인 협업
약국 운영자가 세무·노무·행정을 물어보는 상담 챗봇입니다. 모델과 Q&A DB는 삼일회계법인이, 답할 수 있는 범위와 정책은 제가 맡았습니다.
내가 정한 것
- 답변 가능 범위 정책 — 모델이 답해도 되는 질문과 전문가 상담으로 넘길 질문의 경계
- 3단계 응답 로직 — 예상 Q&A DB 매칭 → 에이전트 탐색 → 양쪽 불가 시 전문가 연결
- 응답 불가 4가지 경우의 처리 — 범위 밖 질문은 특화 안내로 되돌림
- AI 면책 고지 문구와 노출 시점, 근거 조문 표시 규칙
- 대화 이력 보관 정책(7일 자동 삭제)과 북마크 예외 처리
- 토큰 사용량 하드캡을 요구사항으로 정의
배운 것
외부와 함께 AI를 붙일 때 실제로 어려운 것은 모델이 아니라 답하지 않기로 한 것을 누가 어디까지 정하느냐였습니다.
- AI 정책 설계
- 외부 협업
- UX 설계
05 · Team · 재기획
급여명세서 작성 자동화
합류했을 때 이미 기획된 기능이 있었지만 세무 신고 기준을 반영하지 못해 인사 스케줄 관리 정도로만 쓰이고 있었습니다.
기획 전에 한 일
정규직·일용직·프리랜서의 계산식이 모두 다르고 4대보험과 간이세액표까지 얽혀 있어, 약 30개 거래처의 세무 기장을 직접 수행하며 급여·공제 계산 로직과 예외 케이스를 규칙으로 문서화한 뒤 재기획했습니다.
내가 한 일
- 급여·공제 계산 로직과 예외 케이스를 규칙으로 정의
- 유저·어드민 화면 흐름과 데이터 필드 정의, 개발 테스트까지 수행
- 백엔드 ERD를 기획서 규칙과 대조해 검토
결과
스케줄 관리로만 쓰이던 기능이 실제 급여·공제 계산 용도로 사용되기 시작했습니다. 함께 일한 개발자들에게 “구현 중에 판단해야 할 것들이 문서에 정리되어 있어 편하다”는 말을 들었습니다.
- 서비스 기획
- 계산 로직
- 도메인 실무
직접 만든 것
Built
Myself
01 · Solo · 매일 실사용
마켓데스크 — AI 리포트 분석·종목 관리
같은 산업 리포트도 취업 준비생과 투자자가 다르게 읽습니다. 읽는 목적(렌즈)별로 AI가 구조화 요약하고, 산업별 흐름으로 누적해 보여주는 도구입니다.
주요 기능
- 렌즈별 6항목 구조화 요약, 업로드 시 산업·문서 타입 AI 자동 분류
- 흐름 보드 — 월·년 × 산업·기업·경제흐름으로 누적
- 내 종목 — KIS 실시간 시세, 모의투자 시뮬레이션, 매매 다이어리
- PDF·Markdown 내보내기, 분석 엔진 선택(BYO 키)
엔지니어링에서 막혔던 것
PDF 파싱이 업로드 응답을 막아 API 서버와 파싱 워커를 분리해 큐로 연결했습니다. 중복은 내용 SHA-256으로 막고, 유사본은 SimHash로 잡아 병합을 제안합니다. 커밋 219개로 제가 만든 것 중 가장 큽니다.
가드레일
모든 추출 호출에 “리포트에 없는 숫자·전망을 지어내지 말고, 없는 항목은 비워라”를 강제했습니다. 추출한 숫자를 인용 페이지 본문과 대조하는 검증 도구도 만들었는데, 아직 업로드 파이프라인에는 붙이지 않았습니다. 투자 의견은 근거를 함께 쓰고 단정하지 않는 형태로만 두고, 투자 조언이 아니라는 면책을 노출합니다.
- Next.js · Hono
- PostgreSQL
- 큐 · 워커 분리
- 가드레일
02 · Solo · 해커톤 6시간
일경험 운영 트리아지 어드민
운영자 한 명이 참여자 300명의 8주치 출결을 수기로 점검하고 있었습니다. 건당 3~5분, 한 번 점검에 15~25시간이 걸렸고 정산 마감 직전에 몰렸습니다.
해결
- “지금 개입하면 추가로 지킬 수 있는 수당”을 개입가치로 정의해 점검 대상을 자동 정렬
- 남은 주차 출석을 넣으면 수당이 재계산되는 What-if 시뮬레이터
먼저 정한 것
무엇을 AI에게 맡길지를 시작할 때 정했습니다. 계산과 임계 판정은 코드, 요약·안내 문구는 AI, 최종 확정은 사람. 숫자가 한 번 틀리면 운영자는 그 화면을 다시 믿지 않기 때문입니다.
- 역할 분리
- Python
- 프롬프트 설계
03 · Solo · 설계~배포
ClassTrack — 강의·과제 추적 웹앱
듣고 있는 강의와 과제, 결과물 링크를 한곳에서 추적하는 웹앱입니다. 설계부터 배포까지 혼자 했습니다.
설계에서 신경 쓴 것
- 주말·공휴일을 뺀 실제 수업일 캘린더를 종료일을 저장하지 않고 규칙으로 계산
- 실행 중인 앱에서 API·서비스·DB 구조와 로그를 뽑아내는 dev 화면을 붙여 디버깅을 앱 안으로 들여옴
- AOP 로깅, 비동기 링크 검증
- Spring Boot
- Vue 3
- AOP
04 · Solo · 매일 실사용
관계부 — 관계 기록·AI 분석
소중한 관계를 놓치지 않도록 사람마다 필요한 걸 한곳에 기록하는 앱입니다. 카톡 대화를 올리면 AI가 날짜별로 요약하고 관계 건강도를 분석합니다.
주요 기능
- 인물 카드 — MBTI·인스타·명함·못 먹는 음식 등 자유 메모
- 경조사비·빌려준 돈 기록, 주고받은 잔액 자동 계산
- AI 관계 건강도 분석 — 소원해진 사람·챙길 사람 추천
- 연락 리마인더 · 경조사 D-day 알림
- Next.js
- Supabase
- Capacitor
- Claude · Gemini API
05 · Solo · 매일 실사용
개인용 툴
템플릿 허브
PPT·보고서·이력서 템플릿과 오픈소스를 카테고리별로 모아두고, 고르면 AI에 던질 프롬프트가 만들어지는 허브입니다. 프롬프트는 한 번 잘 나오기보다 매번 같게 나오기가 어렵다는 걸 퀴켓 홍보 이미지를 만들며 알았습니다. 디자이너가 매번 새로 그리지 않아도 되게 하려던 것입니다.
이메일 요약봇
Gmail을 매일 아침 IMAP으로 수집해 중요도별로 요약한 뒤 Discord 채널로 보냅니다. 네이버 메일은 별도 채널로 분리했고 GitHub Actions로 자동 실행됩니다. 반복해서 확인하던 일부터 먼저 줄였습니다.
바이브코딩 가이드
코딩을 처음 시작하는 사람이 기획부터 배포까지 8단계를 한 사이클 완주하도록 돕는 웹입니다. 단계마다 AI에 줄 프롬프트와 쓸 만한 오픈소스를 모아 두었고, 빌드가 키 유출 검사를 통과해야 산출물이 나오게 막아 두었습니다.
학습용 AI 코치 웹앱
AI에게 묻는 대신 AI가 저에게 주관식 질문을 던지게 만들었습니다. 물어보면 답은 나오지만 남지 않기 때문입니다. 서술형으로 답하면 AI가 채점하고 답안과 통과 여부를 DB에 남깁니다. 파이썬, 자바·스프링부트, 도커 등 과목별로 네 건을 만들어 썼습니다.
- Python
- Spring Boot · Vue
- 프롬프트 설계
- GitHub Actions