내가 담당
- 문제 정의와 요구사항
- 기능 우선순위
- 데이터·비용 정책
- 코딩 에이전트 작업 규칙 (해도 되는 일·안 되는 일)
- 품질 기준과 결과 검수
- 운영 판단
Backend / AI Engineer · AI-assisted Delivery · AX
서비스의 흐름을 설계하고,
AI의 판단을 검증합니다.
2023.04 ~ 현재 금융 서비스 개발 경력 · Java/Spring Backend → AI/ML → AX
회사에서는 Java/Spring 금융 서비스, 실시간 데이터 처리, ML·LLM 운영 파이프라인을 개발했습니다. 이 페이지는 그 경력을 바탕으로 AI 코딩 에이전트를 활용해 기획하고, 결과를 검증하고, 운영한 개인 프로젝트입니다.
- 기획 · 요구사항
- 문제 정의, 기능 우선순위, 데이터·비용 정책
- 품질 기준 · 검수
- AI 결과를 테스트·실데이터·운영 화면으로 확인
- 운영 판단
- 사용 의견을 받아 고치고 배포, 실패하면 대안으로
AI 협업 프로젝트의 기여 기준
누가 무엇을 했는지
먼저 밝혀 둡니다.
데이트코스와 힐링룸은 AI 코딩 에이전트로 만든 개인 서비스입니다. 코드는 에이전트가 쓰고, 저는 에이전트가 무엇을 만들고 어디까지 해도 되는지 정하고 결과를 검수했습니다. 프로젝트마다 맡은 범위는 배지로 따로 표시했습니다.
AI가 담당
- 코드 초안과 구현
- 요청한 기능의 테스트 작성
사용 도구: Claude Code 등
이 프로젝트로 보여 드리는 것
코드를 직접 쓴 숙련도가 아니라, AI 에이전트에게 일을 맡기고 결과를 믿을 수 있게 만드는 방법입니다. 직접 개발한 Java/Spring 실무는 경력기술서의 회사 업무에서 확인할 수 있습니다.
01 · 대표 개인 프로젝트 · 운영 중
데이트코스 추천
공공데이터 92만 곳을
걸어서 도는 코스로.
내 역할기획 · 정책 결정 · 검수 · 운영
개발AI 코딩 에이전트가 코드 작성서비스 안 AIAI 검색·추천은 서버 안 로컬 LLM(Ollama)
지역과 분위기를 고르면 구경 → 카페 → 식당 코스를 순위대로 보여주고, 그 코스를 고쳐 내 일정으로 저장·공유하는 서비스입니다.
- 01문제
- 데이트 코스는 장소 찾기·동선·식당과 카페 고르기가 겹쳐 짜기 어렵습니다. 미리 짜인 코스를 순위대로 보여주면 찾는 대신 고르기만 하면 됩니다.
- 02제약
- 지도 서비스의 리뷰·별점은 약관상 가져올 수 없고, 유료 API 비용은 0원이어야 하며, 로그인 없이 개인정보를 최소로 받아야 했습니다.
- 03내가 내린 결정
- 유료화된 카카오·길찾기 API를 빼고 공공데이터와 네이버 무료 이용량 안에서만 운영. 별점 대신 모범음식점 지정·관광공사 소개·체인 판별을 품질 신호로 쓰고 화면에 고른 이유를 보여줌.
- 04검증 방법
- 실데이터로 결과를 확인하고 규칙을 고침(체인 카페가 든 코스 437 → 140개). 문서 AI 검색은 사용 중 틀렸던 문장과 대표 문장 40개를 시험 모음으로 두고 규칙을 고칠 때마다 돌림. 시험 문장
- 05운영 결과
- 공개 서비스로 운영 중. main 푸시 → 테스트 → 자동 배포, 실패하면 이전 버전으로 복구. 사용 의견을 받은 날 고쳐 배포한 사례가 이어졌습니다.
- 920,698
- 장소 (공공데이터 2곳)
- 11,809
- 미리 만든 코스
- 9,616
- 모범음식점 연결
- 0원
- 유료 API 비용 (무료 이용량 안에서 운영)
핵심 사례 1 · 사용 의견 → 배포
의견을 받은 날 고쳐서 배포
핵심 사례 2 · 서비스 안 AI 기능 통제
AI 는 후보 안에서만, 틀리면 순위로
그 밖에 내린 결정 보기
- 네이버 검색 API 요금을 다시 확인해, 무료 한도 안인 지역 검색만 데이터에 없는 가게 찾기에 붙임 (결과는 우리 DB 에 쌓지 않음)
- 로그인 없이 쿠키로 저장하고, 다른 기기에서 보려는 사람만 코드 + 비밀번호 (연락처·기기 정보는 모으지 않음)
- 일정 공유 링크는 만든 때 그대로 떠 두고 90일 뒤 만료 (받은 사람이 보는 일정이 몰래 바뀌지 않게)
- 날씨는 키 신청이 필요하고 3일까지인 기상청 대신 Open-Meteo 로 15일 뒤까지, 비 소식이면 근처 실내 코스 권함
- AI 는 서버 안 Ollama(gemma3:4b)로만 돌리고 사용자 문장은 밖으로 보내지 않음. 코스 임베딩은 벡터 DB 없이 서버 메모리(약 36MB)
구현 구성 Java 17 · Spring Boot · PostgreSQL · Redis · React · 네이버 지도 · Ollama
02 · AI 코딩 에이전트 통제 사례 · 운영 중
힐링룸
내 역할기획 · 코딩 에이전트 작업 규칙 · 검수 · 운영
로그인 없이 테마별 방에 모여 YouTube 음악을 함께 듣고 대화하는 공간입니다. 코드와 화면 이미지는 AI 가 만들었고, 저는 에이전트가 지켜야 할 규칙을 문서로 정하고 결과를 운영에서 확인했습니다.
- 작업 규칙 문서: 에이전트가 DB 구조를 스스로 바꾸지 못하게 하고(검증만), 다른 서비스와 함께 쓰는 Redis 에서는 자기 키만 쓰게 하며, 공개 저장소에 비밀값을 남기지 않게 함
- 배포 안전장치: main 푸시 → 테스트 → 자동 배포, 실패하면 이전 버전으로 자동 복구. DB 구조를 바꾸는 배포는 변경을 먼저 적용한 뒤 배포
- 오탐 기준: 공개 욕설 목록을 그대로 쓰면 평범한 문장의 65% 가 걸려, 확실한 말만 제한하고 애매한 말은 가리기만 하도록 기준을 정함
- 의견 반영: "환경음 조절이 안 된다"는 의견에, 직접 켠 환경음은 다음 곡에서도 끄지 않고 기억하도록 고침
03 · AI 협업 연구 · 판단 기준
테스트 통과 ≠ 정답,
AI 출력 ≠ 최종 판단
가장 강한 증거테스트가 모두 통과했지만 틀린 PR 2개를 AI 리뷰어가 잡아냈고, 설계 판단이 필요한 PR 은 사람에게 넘겼습니다. 테스트 통과가 곧 정답은 아니고, 최종 병합(Merge)은 사람이 결정해야 했습니다.
AI PR Review Agent
직접 설계한 고정 PR 5개에서 기대 판정과 일치 (5/5)
테스트가 통과한 로직 오류·동작 회귀를 잡고, 과한 리팩터링은 "사람 검토 필요"로 넘겼습니다. AI 는 판정을 제안하고 병합은 사람이 결정하는 구조입니다. 표본이 5개라 다른 저장소에서도 같다고 보지 않습니다. MCP로 연결된 환경을 활용한 실험이며, MCP 서버를 직접 만들지는 않았습니다.
RepositoryHuman-AI Review Benchmark
사람 단독 6/8, AI 단독 7/8 (같은 판정 5/8)
테스트가 모두 통과한 상태에서 사람이 놓친 계약 위반을 AI 가 찾았고, 판단을 보류해야 할 사안은 사람이 보류했습니다. 표본이 8건이라 우열은 주장하지 않습니다.
RepositoryAI Coding Agent Benchmark
과제 3개를 각 1회 실행: 조사·문서화는 Claude, 기능 개발은 Codex 쪽이 나았고 버그 수정은 비슷
같은 저장소·요구사항에서 두 에이전트를 따로 실행하고 교차 평가했습니다. 한 에이전트로 모든 일을 하기보다 작업에 맞게 고르는 쪽이 나았습니다. 모델 순위가 아니라 이 조건에서의 관찰입니다.
Repository04 · 개인 금융 AI 연구 · 판단 기준
AI 출력과 서비스 결정 분리,
성능보다 재현성
가장 강한 증거개인 Signals 서비스(회사 업무 아님) 운영에서 시험·실전 결과를 보고 정책을 고른 선택 편향을 찾아내고, 정책은 검증 기간 결과로만 고르고 시험 기간은 마지막에 한 번만 평가하도록 절차를 고정했습니다.
시장 데이터→피처→ML 모델→예측→정책·관문→신호→검증
시험(Test)·실전(Live) 결과를 보고 정책을 고르면, 앞으로 통할 정책이 아니라 이미 본 결과에 맞춘 정책이 됩니다.
정책은 검증 기간 결과로만 고르고, 기간 사이에 빈 구간(Embargo)을 두어 정보가 새지 않게 하며, 시험 기간은 마지막에 한 번만 평가합니다.
학습 2012~2023, 검증 2024, 시험 2025로 시간 순서를 지키고, 2026년부터는 실제 운영 기록으로 확인합니다.
수익률은 거래비용·세금·슬리피지·실제 체결을 반영하지 않은 신호 단위 시뮬레이션이라 이 페이지에서 성과로 내세우지 않습니다. 이 프로젝트에서 보여 드리고 싶은 것은 숫자가 아니라, 좋은 숫자를 고르지 못하게 막은 검증 절차입니다. 매일 쌓이는 신호 기록은 개인 Signals 서비스에 그대로 공개합니다. 무료 개인 연구 기록이며 투자 자문, 리딩, 매매 추천을 제공하지 않습니다.
05 · 개인 RAG (이력서 챗봇) · 판단 기준
검색 품질은 임베딩 이전의
개인정보·문서 나누기에서 시작
가장 강한 증거전화번호·주소·개인 보상 같은 정보는 임베딩 전에 지우고, 인덱싱 전에 개인정보·URL 패턴을 다시 검사한 뒤에만 색인합니다.
이력서→개인정보 제거→의미 단위 나누기→범위 표시→임베딩→JSON 색인→하이브리드 검색→로컬 LLM
임베딩 전에 개인정보 제거
전화번호·주소·개인 보상과 비공개 식별정보를 검색 데이터에서 제거했습니다.
의미 단위로 나누기
고정 글자 수가 아니라 경력·프로젝트·문제 해결 단위로 문서를 분리했습니다.
범위를 구분하는 검색
회사 경력과 개인 프로젝트를 구분하고 넓은 질문에는 관련 범위를 다양하게 검색합니다.
색인 전 최종 검사
필수 필드, 중복 ID, 개인정보와 URL 패턴을 인덱싱 전에 다시 검사했습니다.
하이브리드 검색
임베딩 유사도(0~1)×0.70과 BM25 점수(질문마다 최고점으로 나눠 0~1)×0.22를 더하고, 질문의 범위·분야가 맞는 조각에 가산점(최대 +0.10)을 더해 순위를 매깁니다. 합을 다시 정규화하지는 않습니다. 코드
근거가 약하면 한 번 더
찾은 조각이 답의 근거로 충분한지 검사하고, 약하면 검색어를 넓혀 한 번만 다시 찾습니다.
단계별 기록
질문마다 단계별 시간과 판단 결과를 남겨, 느린 곳과 틀린 곳을 찾을 수 있게 했습니다.
- 58
- 문서 조각 수
- Scope
- 회사 경력 · 개인 프로젝트 구분
- Gemma
- 임베딩 모델 (서버 안에서 실행)
- JSON
- 벡터 색인 (별도 DB 없음)
회사 경력
실제 업무와 성과는
경력기술서에 정리했습니다.
Java/Spring 금융 서비스, 실시간 데이터 처리, ML·LLM 운영 파이프라인을 회사에서 개발·운영한 내용입니다.