함께 만든 프로젝트
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 · 외부 협업
AI 세무 챗봇 — 삼일회계법인 협업
약국 운영자가 세무·노무·행정을 물어보는 상담 챗봇입니다. 모델과 Q&A DB는 삼일회계법인이, 답할 수 있는 범위와 정책은 제가 맡았습니다.
내가 정한 것
- 답변 가능 범위 정책 — 모델이 답해도 되는 질문과 전문가 상담으로 넘길 질문의 경계
- 3단계 응답 로직 — 예상 Q&A DB 매칭 → 에이전트 탐색 → 양쪽 불가 시 전문가 연결
- 응답 불가 4가지 경우의 처리 — 범위 밖 질문은 특화 안내로 되돌림
- AI 면책 고지 문구와 노출 시점, 근거 조문 표시 규칙
- 대화 이력 보관 정책(7일 자동 삭제)과 북마크 예외 처리
- 토큰 사용량 하드캡을 요구사항으로 정의
배운 것
외부와 함께 AI를 붙일 때 실제로 어려운 것은 모델이 아니라 답하지 않기로 한 것을 누가 어디까지 정하느냐였습니다.
- AI 정책 설계
- 외부 협업
- UX 설계
04 · Team · 재기획
급여명세서 작성 자동화
합류했을 때 이미 기획된 기능이 있었지만 세무 신고 기준을 반영하지 못해 인사 스케줄 관리 정도로만 쓰이고 있었습니다.
기획 전에 한 일
정규직·일용직·프리랜서의 계산식이 모두 다르고 4대보험과 간이세액표까지 얽혀 있어, 약 30개 거래처의 세무 기장을 직접 수행하며 급여·공제 계산 로직과 예외 케이스를 규칙으로 문서화한 뒤 재기획했습니다.
내가 한 일
- 급여·공제 계산 로직과 예외 케이스를 규칙으로 정의
- 유저·어드민 화면 흐름과 데이터 필드 정의, 개발 테스트까지 수행
- 백엔드 ERD를 기획서 규칙과 대조해 검토
결과
스케줄 관리로만 쓰이던 기능이 실제 급여·공제 계산 용도로 사용되기 시작했습니다. 함께 일한 개발자들에게 “구현 중에 판단해야 할 것들이 문서에 정리되어 있어 편하다”는 말을 들었습니다.
- 서비스 기획
- 계산 로직
- 도메인 실무
혼자 만든 프로젝트
Personal
Projects
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 · Solo · 매일 실사용
마켓데스크 — AI 리포트 분석·종목 관리
같은 산업 리포트도 취업 준비생과 투자자가 다르게 읽습니다. 읽는 목적(렌즈)별로 AI가 구조화 요약하고, 산업별 흐름으로 누적해 보여주는 도구입니다.
주요 기능
- 렌즈별 6항목 구조화 요약, 업로드 시 산업·문서 타입 AI 자동 분류
- 흐름 보드 — 월·년 × 산업·기업·경제흐름으로 누적
- 내 종목 — KIS 실시간 시세, 모의투자 시뮬레이션, 매매 다이어리
- PDF·Markdown 내보내기, 분석 엔진 선택(BYO 키)
엔지니어링에서 막혔던 것
PDF 파싱이 업로드 응답을 막아 API 서버와 파싱 워커를 분리해 큐로 연결했습니다. 중복은 내용 SHA-256으로 막고, 유사본은 SimHash로 잡아 병합을 제안합니다. 커밋 219개로 제가 만든 것 중 가장 큽니다.
가드레일
모든 추출 호출에 “리포트에 없는 숫자·전망을 지어내지 말고, 없는 항목은 비워라”를 강제했습니다. 추출한 숫자는 인용 페이지 본문과 대조해 검증 플래그를 남깁니다. 투자 의견은 근거를 함께 쓰고 단정하지 않는 형태로만 두고, 투자 조언이 아니라는 면책을 노출합니다.
- Next.js · Hono
- PostgreSQL
- 큐 · 워커 분리
- 가드레일
03 · Solo · 해커톤 6시간
일경험 운영 트리아지 어드민
운영자 한 명이 참여자 300명의 8주치 출결을 수기로 점검하고 있었습니다. 건당 3~5분, 한 번 점검에 15~25시간이 걸렸고 정산 마감 직전에 몰렸습니다.
해결
- “지금 개입하면 추가로 지킬 수 있는 수당”을 개입가치로 정의해 점검 대상을 자동 정렬
- 남은 주차 출석을 넣으면 수당이 재계산되는 What-if 시뮬레이터
먼저 정한 것
무엇을 AI에게 맡길지를 시작할 때 정했습니다. 계산과 임계 판정은 코드, 요약·안내 문구는 AI, 최종 확정은 사람. 숫자가 한 번 틀리면 운영자는 그 화면을 다시 믿지 않기 때문입니다.
- 역할 분리
- Python
- 프롬프트 설계
04 · Solo · 설계~배포
ClassTrack — 강의·과제 추적 웹앱
듣고 있는 강의와 과제, 결과물 링크를 한곳에서 추적하는 웹앱입니다. 설계부터 배포까지 혼자 했습니다.
설계에서 신경 쓴 것
- 주말·공휴일을 뺀 실제 수업일 캘린더를 종료일을 저장하지 않고 규칙으로 계산
- 실행 중인 앱에서 API·서비스·DB 구조와 로그를 뽑아내는 dev 화면을 붙여 디버깅을 앱 안으로 들여옴
- AOP 로깅, 비동기 링크 검증
- Spring Boot
- Vue 3
- AOP
- Docker
05 · Solo · 매일 실사용
관계부 — 관계 기록·AI 분석
소중한 관계를 놓치지 않도록 사람마다 필요한 걸 한곳에 기록하는 앱입니다. 카톡 대화를 올리면 AI가 날짜별로 요약하고 관계 건강도를 분석합니다.
주요 기능
- 인물 카드 — MBTI·인스타·명함·못 먹는 음식 등 자유 메모
- 경조사비·빌려준 돈 기록, 주고받은 잔액 자동 계산
- AI 관계 건강도 분석 — 소원해진 사람·챙길 사람 추천
- 연락 리마인더 · 경조사 D-day 알림
- Next.js
- Supabase
- Capacitor
- Claude · Gemini API
06 · Solo · AI Agent
일간 메일 요약 에이전트
Gmail을 매일 아침 자동으로 읽어 중요도별로 요약한 뒤 Discord 채널로 보내주는 에이전트입니다. 반복해서 확인하던 일부터 먼저 줄였습니다.
동작 방식
- 매일 아침 Gmail 자동 수집 (IMAP)
- 중요도별 요약 생성, 네이버 메일은 별도 채널로 분리
- Discord 전송 · GitHub Actions로 자동 실행
- Python
- IMAP
- Claude API
- GitHub Actions
07 · Solo
템플릿 허브 · Inwoo.log · 그 외
템플릿 허브
PPT·보고서·이력서 템플릿을 카테고리별로 모아두고, 고르면 AI에 던질 프롬프트가 만들어지는 허브입니다. 프롬프트는 한 번 잘 나오기보다 매번 같게 나오기가 어렵다는 걸 퀴켓 홍보 이미지를 만들며 알았습니다.
Inwoo.log
지금 보고 계신 사이트입니다. 순수 HTML·CSS·JavaScript로 만들었습니다. 색은 CSS 변수로만 관리하고, 사진이 없어도 읽히는 구조로 먼저 만들고, 키보드만으로 모든 기능을 쓸 수 있게 하는 것을 규칙으로 정했습니다.
학습으로 만든 것
- 문자단위 언어모델 — Attention Is All You Need를 읽고 Transformer를 PyTorch로 직접 구현·학습
- 바이브코딩 가이드 — 처음 코딩하는 사람이 기획~배포 8단계를 완주하게 돕는 웹. 빌드가 키 유출 검사를 통과해야 산출물이 나옵니다
- AI 학습 코치 웹앱 4건 — AI에게 묻는 대신 AI가 나에게 주관식 질문을 던지게 만든 도구
- HTML · CSS · JS
- PyTorch
- 프롬프트 설계
일하는 방식
How
I
Work
01 · 루틴
기획 문서 7단계 워크플로
기획 문서를 쓸 때마다 앞 문서와 뒤 문서가 어긋나는 것이 문제였습니다. 일곱 단계를 하나로 묶되 앞 단계가 검증되지 않으면 다음으로 넘어가지 않게 했습니다.
단계와 검토 지점
- 01 프로젝트 개요 — 무엇을 왜 만드는지 먼저 고정
- 02 PRD — 범위와 비범위를 나눠 적음
- 03 IA — 구조가 PRD 범위를 넘지 않는지 대조
- 04 유저플로우 — 예외 경로를 여기서 전부 꺼냄
- 05 기능명세 — input · output · API 규격 · 정책 · 예외
- 06 와이어프레임 — 명세에 없는 화면이 생기지 않게
- 07 QA 체크리스트 — 수정 후 전체 반영 여부 자가 점검
쓰다가 발견한 것
AI가 수정 사항을 조용히 빠뜨린다는 걸 알게 됐습니다. 한 곳을 고치면 다른 곳이 빠지고, 그걸 고치면 앞에서 되던 게 깨졌습니다. 그래서 수정을 요청한 뒤에는 전체에 반영됐는지 스스로 점검하게 하는 단계를 루틴으로 고정했고 누락이 눈에 띄게 줄었습니다.
결과
PRD 초안 3일 이상 → 하루 이내.
- 워크플로 설계
- AI 검증
- 문서 일관성
02 · 원칙
무엇을 AI에게 맡기지 않을지
AI 서비스에서 어려운 것은 모델을 부르는 일이 아니라 역할을 나누는 일이라고 생각합니다. 같은 원칙을 만든 것마다 반복해서 적용했습니다.
세 번의 적용
- 세무상담 AI — 법령 근거는 RAG, 세액 계산은 코드, 범위 밖 질문의 거절은 규칙
- 해커톤 어드민 — 계산과 임계 판정은 코드, 요약·문구는 AI, 최종 확정은 사람
- 마켓데스크 — 없는 숫자는 생성 금지, 추출한 숫자는 인용 페이지와 대조해 검증 플래그
만든 다음에
정확도를 올리는 것보다 틀렸을 때 알아낼 수 있는 장치를 함께 설계합니다. 세무상담 AI에서는 계산 코드에 버그 7종을 일부러 심어 테스트가 6종을 잡아내는지부터 확인했습니다.
AI로 공부하는 방식
AI에게 묻는 대신 AI가 저에게 주관식 질문을 던지게 만들었습니다. 물어보면 답은 나오지만 남지 않기 때문입니다.
- 역할 분리
- 가드레일
- 검증 설계
03 · 양식
기획서 다섯 항목 양식
처음에는 개발자와 디자이너에게 유저플로우와 구현 결과밖에 설명하지 못했습니다. 무엇을 만들지는 전달했지만, 어떤 조건에서 어떻게 동작하고 어떤 예외가 있는지는 전달하지 못했습니다.
그래서 만든 것
강의로 IT 기획을 독학해 기준을 스스로 정리한 뒤, 기획서를 input · output · API 규격 · 정책 · 예외 다섯 항목으로 고정하는 양식을 만들었습니다. 삼일회계법인·온라인팜 등 외부 네 개사와 API 연동 규격을 협의할 때도 같은 방식으로 항목을 먼저 맞췄습니다.
받은 피드백
함께 일한 개발자들에게 “구현 중에 판단해야 할 것들이 문서에 정리되어 있어 편하다”는 말을 들었습니다.
배운 것
계산이 얽힌 서비스는 예외까지 적어야 정의가 끝납니다. 백엔드 개발자가 작성한 ERD를 기획서 규칙과 대조해 검토하는 것도 이때부터 습관이 됐습니다.
- 기획서 표준화
- 외부 규격 협의
- ERD 검토