김윤기 — 포트폴리오

프로젝트

4건

KiniQ — 만성신장질환 조기 발굴 및 생활습관 중재 서비스

오즈코딩스쿨 K-Digital Training AI 헬스케어 과정 최종 프로젝트 · Talos 참여기업 주제 제공

검진 결과를 넣으면 위험 단계와 맞춤 생활습관 챌린지를 받는 헬스케어 웹 서비스

#헬스케어
#풀스택
#OCR
#PostgreSQL
#부하테스트

기간	2026.04.23 – 06.19 (304시간)
팀·역할	4명 — 저는 화면 전체와 API·배포, 팀원들은 위험 예측 모델과 RAG 챗봇
기술	FastAPI · PostgreSQL 16 · Tortoise ORM · React 19 · TypeScript · TanStack Query · CLOVA OCR · Docker · AWS EC2

내 커밋 97 / 124

40세 이상 만성신장질환 위험군이 건강검진 결과를 입력하면 G1~G4 위험 단계를 배정받고, 단계에 맞는 생활습관 챌린지와 대시보드를 받는 서비스입니다.

왜 만들었나

만성콩팥병은 증상 없이 진행돼, 검진 결과지를 받아도 숫자가 무슨 뜻인지, 오늘 무엇을 해야 하는지 알기 어렵습니다. 병원은 처방과 검사까지만 하고 일상 관리는 본인 몫입니다. 그래서 검진 결과를 넣으면 위험 단계를 알려 주고, 단계에 맞는 생활습관을 매일 실천하게 돕는 서비스를 만들었습니다.

국내 만성콩팥병 환자는 2012년 13만 7천 명에서 2022년 29만 6천 명으로 10년 동안 2배 넘게 늘었고, 진료비는 1조 2천억 원에서 2조 3천억 원이 됐습니다.질병관리청 「주간 건강과 질병」 2024;17:381–382 (팀 결과보고서 인용)
주제는 참여기업 Talos가 제시했고, 기업의 관여는 주제 제공까지였습니다.

검진 입력 → 위험 단계 배정 → 챌린지 → 대시보드까지 화면 전체와 API — 팀원이 도운 화면과 로직도 이어받아 하나로 통합
결과지 사진·PDF에서 수치 10종 자동 입력 (OCR)
DB를 PostgreSQL로 교체하고 운영 중 스키마 변경 16번 무중단 적용
보안 필수 항목 8건, 동시 접속 50명 부하 테스트에서 조회 P95 18ms
AWS EC2에 접속해 Docker 컨테이너를 띄우는 배포 담당

팀 밖의 사용자가 써본 적은 없습니다. 위험 예측 모델은 팀원이 맡았고 저는 성능을 주장하지 않습니다. 커밋 78%는 분담의 결과입니다 — 팀원들의 예측 모델·RAG 실험은 커밋으로 잡히지 않습니다.

github.com/rladbsrl298/AH_03_02

발생한 문제와 해결 과정발생한 문제와 해결 과정 접기

검진 결과지의 고밀도콜레스테롤 수치가 총콜레스테롤 칸으로 새어 들어갔습니다.

문제	결과지 사진을 올리면 수치가 자동으로 채워져야 하는데, 표 형식 결과지에서 고밀도콜레스테롤 값이 총콜레스테롤 칸으로 들어갔습니다.
판단	OCR이 글자 조각마다 줄을 바꿔 한 행이 흩어진 것이 원인이었습니다. 줄바꿈 신호가 아니라 글자의 위치로 행을 판단해야 한다고 봤습니다.
조치	좌표로 같은 행을 다시 묶고, “고밀도·저밀도”가 들어간 행은 총콜레스테롤로 매핑하지 않게 막았습니다. 두 줄짜리 고밀도콜레스테롤 칸은 칸 경계를 기준으로 따로 읽습니다.
결과	혈압·공복혈당·콜레스테롤 등 10종을 자동으로 채우고, 여러 쪽짜리 PDF는 쪽 단위로 나눠 처리합니다.

받은 템플릿의 MySQL로는 형태가 바뀌는 기록과 의료 수치를 함께 담기 어려웠습니다.

후보	판단	이유
PostgreSQL 16	채택	포인트 적립 내역·감정 기록처럼 형태가 바뀌는 데이터를 JSONB로 담을 수 있고, 트랜잭션도 확실합니다
MySQL 8.0	기각	JSON만 있고 JSONB가 없습니다
MongoDB	기각	혈압·혈당·eGFR 같은 의료 수치의 트랜잭션 무결성
SQLite	기각	여러 사용자가 동시에 씁니다

감수할 단점(멘토의 PostgreSQL 경험 부족, JSONB 인덱싱 비용)까지 의사결정 문서(ADR-0001)에 적어 팀이 알고 결정하게 했고, 운영 중 스키마 변경 16번을 중단 없이 적용했습니다. 프론트엔드도 같은 방식으로, 백엔드를 FastAPI로 분리한 이상 Next.js는 기능이 겹쳐 기각하고 Vite + React로 정했습니다(ADR-0002).

한 장 정리 — 목표 · 역할 · 진행 · 결과한 장 정리 접기

목표	검진 결과 입력 → 위험 단계 → 생활습관 챌린지 → 대시보드로 이어지는 한 흐름을 만든다
내 역할	화면 전체와 API(커밋 97 / 124). 팀원이 도운 화면·로직을 이어받아 통합, OCR과 게이미피케이션은 단독 구현, AWS EC2에 Docker로 배포
진행 과정	기획(~5.19) → 1차 스프린트: 인증·DB(~5.26) → 2차: AI 핵심 기능·OCR(~6.01) → 3차: 통합·화면 다듬기·부하 테스트(~6.17) → 발표(6.19)
결과	수치 10종 자동 입력, 운영 중 스키마 변경 16번 무중단, 동시 접속 50명 부하 테스트에서 조회 P95 18ms, 기술 선택 기록(ADR) 4건
배운 점	결과가 틀리면 규칙부터 고치기보다 데이터가 어떻게 들어오는지 먼저 봐야 한다는 것. 가장 오래 막힌 곳은 기획·설계 단계였고, 이후 프로젝트에서는 문서를 먼저 쓰게 됐습니다
한계	팀 밖의 사용자가 써 본 적은 없습니다. 위험 예측 모델은 팀원이 맡아 성능을 주장하지 않습니다

전문가 지식 클론 챗봇

AX컨설턴트 과정 수강 기간 중 진행 · 수주 시나리오 기반 단독 프로젝트

전문가의 블로그·SNS·저서를 학습한 AI가 1:1 상담 일부를 대신하는 서비스

#AX
#챗봇
#설계문서
#검증루프
#단독

기간	2026.07.16 – 07.24 (8일)
팀·역할	단독 — 기획·설계·구현
기술	Next.js · Supabase · Drizzle ORM · Gemini · BMAD Method
만든 방법	Claude Code + BMAD — BMAD(기획 문서를 단계별로 쓰게 돕는 방법론)로 브리프·요구사항·설계 문서를 먼저 쓰고, Claude Code로 기능을 하나씩 구현

내 커밋 66 / 66

브랜딩 전략가의 1:1 상담은 단가가 높고 본인 시간이 병목이라, 수요가 있어도 공급이 늘지 않습니다. 전문가의 콘텐츠를 학습한 클론이 상담 일부를 대신하도록 설계했습니다.

왜 만들었나

클론이 많이 답하는 것보다, 틀린 답이 전문가 이름으로 나가지 않게 하는 것이 먼저라고 봤습니다. 그래서 전문가가 확인하고 운영자가 승인한 내용만 답하도록 설계했습니다.

코치·크리에이터·전문가가 자기 자료로 AI 클론을 만들어 더 많은 사람에게 답하게 하는 서비스 Delphi가 270만 달러 투자를 받았습니다.VentureBeat, 2023.09.06
에어캐나다 챗봇이 환불 규정을 잘못 안내하자, 재판소는 회사가 책임져야 한다고 판단했습니다. 가트너는 챗봇 답변을 사람이 미리 검토·승인하는 절차를 권했습니다.CIO 코리아, 2024.02.21

브리프 → 요구사항 → 구조 설계 순으로 구현 전에 문서로 확정 (총 6,747줄)
전문가 교정과 운영자 승인을 거친 지식만 공개하는 검증 루프 구현
기능을 스토리 단위로 나눠 구현 문서 18건, 에픽마다 회고와 보류 목록 관리
공개 범위를 단계로 나눈 로드맵 — 내부 정교화 → 팬 상담 → 리포트 → 멀티 클론

지식이 공개되기까지

전문가가 클론의 지식을 채팅으로 읽고, 틀린 곳은 고쳐 달라고 요청
운영자가 요청을 검토해 승인하거나 반려
승인된 지식만 지식베이스에 반영 — 승인을 되돌릴 수도 있음
회원이 상담을 받고, 대화를 바탕으로 리포트를 받음

상담 리포트 · 5부 구성

상황 요약 — 상담 대화에서 고객의 상황을 정리
진단 — 무엇이 문제인지
프레임워크 대입 — 전문가의 방법론에 맞춰 보기
처방 3가지 — 바로 해 볼 수 있는 조치
근거 — 진단·처방마다 출처 표시, 근거 없는 내용은 넣지 않음

설계 문서(Story 7.1) 기준 결과 형식입니다. 실제 응답 화면이 아니며, 응답 품질은 검증하지 않았습니다. 승인된 지식에 근거가 없으면 "모른다"고 답하도록 지시했습니다.

github.com/rladbsrl298/clone-expert

실존 전문가를 상정한 제안용 프로젝트로 계약은 없었습니다. 소재가 된 전문가의 실명과 저서·채널 이름은 가명으로 바꾼 공개본을 올렸으며, 응답 품질은 검증하지 않았습니다. 설계 문서 원본은 면접 자리에서 직접 보여드릴 수 있습니다.

발생한 문제와 해결 과정발생한 문제와 해결 과정 접기

전문가 한 사람의 시간이 상담의 병목이었습니다.

문제	1:1 상담은 단가가 높고 전문가 본인의 시간이 병목이라, 찾는 사람이 있어도 더 받을 수가 없었습니다.
판단	클론이 상담 일부를 대신하되, 틀린 말이 나가는 위험은 사후 대응이 아니라 공개 순서로 막아야 한다고 봤습니다.
조치	전문가가 위키형 채팅으로 클론의 지식을 열람·교정하고, 운영자가 승인한 지식만 지식베이스에 반영한 뒤 공개하도록 설계했습니다.
결과	전문가 교정과 운영자 승인을 통과하지 않은 지식은 공개 대상에 오르지 않습니다. 모델은 비용을 쓰지 않도록 Gemini 무료 티어로 고정했습니다.

같은 지식을 두 사람이 동시에 승인하면 먼저 처리된 결과가 사라질 수 있었습니다.

문제	구현 전 설계 검토에서 문제 5건이 걸렸고, 그중 하나가 동시 승인 때 먼저 처리된 결과가 사라지는 문제였습니다.
판단	구현을 끝낸 뒤에 발견했다면 되돌릴 범위가 훨씬 컸을 문제입니다. 구현 전에 발견해서 코드를 쓰기 전에 설계부터 고칠 수 있었습니다.
조치	설계 문서와 인프라 설정, 코드, 테스트까지 함께 고쳐 반영했습니다.
결과	구현에 들어가기 전에 결함 5건이 문서로 정리됐습니다. KiniQ에서 가장 오래 막혔던 기획·설계 단계를 이번에는 먼저 끝낸 셈입니다.

한 장 정리 — 목표 · 역할 · 진행 · 결과한 장 정리 접기

목표	전문가의 시간 없이도 상담 일부를 대신하되, 틀린 답은 나가지 않게 한다
내 역할	단독 — 기획·설계·구현·테스트 (커밋 66 / 66)
진행 과정	기획 문서(브리프 → 요구사항 → 구조 설계, 총 6,747줄) → 설계 검토(지적 5건 반영) → 기능을 스토리 단위로 나눠 구현(18건) → 에픽마다 회고와 보류 목록
결과	교정 → 승인 → 공개 검증 단계, 회원 상담, 5부 상담 리포트까지 구현. 실명을 가명으로 바꾼 공개본을 GitHub에 올림
배운 점	KiniQ에서 가장 오래 막혔던 기획·설계를 이번에는 먼저 끝냈고, 구현 전 검토로 결함을 일찍 고칠 수 있었습니다
한계	계약 없이 만든 포트폴리오용 프로젝트입니다. 실제 사용자와 응답 품질은 검증하지 않았고, 모델은 비용이 들지 않는 Gemini 무료 티어를 썼습니다

LG전자 채용 면접 배정 시스템

바이브코딩대학 AX컨설턴트 1기 해커톤 · LG전자 연계 과제

면접 담당자가 고른 지원자와 가능 시간을 함께 만족하는 면접 시간표 자동 생성

#HR
#업무자동화
#일정배정
#해커톤
#통합

기간	2026.07.29 – 07.30 (2일)
팀·역할	4명 — 인증·권한 트랙 담당, 이후 배정 엔진을 넘겨받아 통합
기술	Python · SQLite · TypeScript · BMAD Method

내 커밋 13 / 95

8개 팀 면접 담당자가 고른 지원자(약 470명)와 담당자별 가능 시간을 함께 만족하는 시간표를 자동으로 짜는 과제입니다. 실제 지원자 데이터를 다뤘습니다.

왜 만들었나

팀마다 면접 볼 지원자를 따로 고르고, 담당자마다 가능한 시간도 달라서 모두를 만족하는 시간표를 사람이 짜기 어렵습니다. 팀원이 진행한 HR 담당자 인터뷰에 함께 들어가, 지금 막힌 곳과 가장 먼저 풀고 싶은 것, 해결 뒤 기대하는 모습을 들었습니다.

과제 데이터: 팀별 희망 지원자 엑셀 8개, 취합 파일 471행(지원자 약 470명). 실제 지원자 정보라 저장소는 비공개입니다.

인증·권한 트랙 전체 — 계정 사전 생성, 로그인, 담당자 전용 화면, 전 화면 권한 적용
성능 문제로 막힌 배정 엔진을 넘겨받아 화면과 통합
배정 결과 화면 4단계와 엑셀 내보내기 구현
평문 비밀번호 파일·로컬 DB를 저장소 추적에서 제외

커밋은 95개 중 13개로 팀에서 가장 적습니다. 다만 인증 트랙을 끝내고, 막힌 엔진을 넘겨받고, 갈라진 작업을 하나로 합치는 작업이었습니다. 실제 지원자 데이터가 있어 저장소는 비공개이며, 순위나 수상은 없습니다.

발생한 문제와 해결 과정발생한 문제와 해결 과정 접기

배정 엔진이 성능 문제로 막혀, 화면에 붙일 결과가 없었습니다.

문제	팀장이 작업을 화면·배정 엔진·인증 세 트랙으로 나눠 병렬로 진행했는데, 팀원이 맡은 배정 엔진에 성능 문제가 생겼습니다.
판단	결과 화면은 배정 엔진의 결과를 받아 보여주는 구조라, 엔진이 막히면 결과 화면에도 실데이터를 연결할 수 없었습니다.
조치	맡은 인증 트랙을 끝낸 뒤 엔진 작업을 넘겨받아 이식·배선하고, 화면 트랙과 통합 머지해 결과 화면을 실데이터에 연결했습니다.
결과	갈라져 있던 두 갈래 작업이 하나로 합쳐졌습니다.

한 장 정리 — 목표 · 역할 · 진행 · 결과한 장 정리 접기

목표	담당자가 고른 지원자와 가능 시간을 모두 만족하는 면접 시간표를 자동으로 만든다
내 역할	인증·권한(계정 사전 생성, 로그인, 담당자 전용 화면) → 막힌 배정 엔진 인수·통합 → 결과 화면 4단계와 엑셀 내보내기 (커밋 13 / 95). 팀 발표자료 40장 제작
진행 과정	HR 담당자 인터뷰 참석(진행은 팀원) → 인증·권한 완료 → 배정 엔진 넘겨받아 연결 → 화면 작업과 통합 → 결과 화면·엑셀 내보내기 → 발표자료 제작(발표는 팀원)
결과	배정 결과를 화면과 엑셀로 확인. 평문 비밀번호 파일과 로컬 데이터베이스를 저장소에서 빼 실제 지원자 정보를 지켰습니다. 발표자료 40장은 현황 진단 → 근거 → 요구사항 → 솔루션 → 데모 → 기대 효과 순서로, HR 담당자·팀 담당자·지원자 세 입장을 나눠 비교했고 성공 지표에는 실제로 잰 값만 넣었습니다
한계	2일짜리 해커톤이라 순위나 수상은 없습니다. 커밋 수는 팀에서 가장 적지만, 막힌 엔진을 넘겨받아 합치는 일이었습니다

사업 리서치 프로젝트 5기 — 상장사 사업·재무 분석

넥스트러너스(오즈코딩스쿨) 사업 리서치 프로젝트 5기 · 진행 중

주차마다 산업을 정해 상장사의 사업 모델·재무·SWOT을 분석하고 10분간 발표

#리서치
#공시분석
#발표
#SWOT
#진행중

기간	2026.09.21 – 10.20 (4주 · 진행 중)
팀·역할	3명 — 리서치와 자료 제작, 1·3주차 발표 담당
도구	OpenDART · Claude Code · 발표자료
만든 방법	Claude Code + OpenDART — 금융감독원 공시 API(OpenDART)에서 공시를 모으는 일은 Claude Code에 맡기고, 핵심 질문·SWOT·종합 평가는 직접 판단

가설을 세우고 근거로 확인해 결정까지 가는 것이 과제의 목적입니다. 주차마다 지정 기업과 자유 기업을 함께 다루고, 분석 결과를 10~15장으로 정리해 발표합니다.

왜 하나

회사 소개 자료에는 좋은 말만 있어서, 그 회사의 성장을 어디까지 믿어도 되는지 알 수 없습니다. 그래서 가설을 먼저 세우고, 회사가 법에 따라 공개하는 공시로 확인해 결론을 냅니다. 고객사를 만나기 전에 그 회사가 어디서 돈을 벌고 무엇이 위험한지 읽는 연습이기도 합니다.

1주차 디어유(376300) — 핵심 질문을 먼저 세우고 공시 16건 · IR 자료 14건 · 앱 리뷰 35건으로 확인, 팀 자료를 모아 발표 담당
1주차 팀 최종본 검수 — 매출 구성 그래프의 기획사 몫 누락과 순이익 브리지의 중복 반영을 고쳐 반영
2주차 플리토(300080) — 리서치와 자료 제작 담당, 연결 재무제표 주석에서 단일 고객 매출 비중 48.7%를 확인하고 최대 위협을 그 고객의 이탈로 판단
3주차 콜로세움코퍼레이션·실리콘투(257720) — 리서치·자료 제작·발표 담당. 비상장인 콜로세움은 감사보고서 주석에서 최대 고객 한 곳이 매출의 41%를 차지하는 것을 확인해 가장 큰 위협을 최대 고객 이탈로, 실리콘투는 업계 흐름을 근거로 브랜드의 탈중개로 판단
공시 수집은 Claude Code로 자동화하고, 핵심 질문과 SWOT·종합 평가는 직접 판단해 기록

4주 중 3주차까지 발표를 마쳤고 4주차는 진행 중입니다. 투자 판단이 아니라 사업 구조를 읽는 연습 과제이고, 기업의 실제 의사결정에 쓰인 자료는 아닙니다. 과제 자료는 내부 자료라 공개하지 않습니다.

발생한 문제와 해결 과정발생한 문제와 해결 과정 접기

매출이 늘고 있는 회사인데, 그 성장을 어디까지 믿어도 되는지가 자료에 없었습니다.

문제	플리토는 AI 학습 데이터 판매로 매출이 늘고 있었지만, 공개된 소개 자료만으로는 그 매출이 어디서 오는지 알 수 없었습니다.
판단	성장의 지속 가능성은 매출의 크기가 아니라 매출이 누구에게 의존하는지에서 갈린다고 봤습니다. 사업보고서 본문이 아니라 연결 재무제표 주석을 봐야 한다고 판단했습니다.
조치	연결 재무제표 주석에서 주요 고객별 매출 비중을 찾아 단일 고객이 48.7%를 차지하는 것을 확인하고, 공급계약 공시를 시점순으로 추적해 그 고객과의 거래가 언제부터 늘었는지 맞춰 봤습니다.
결과	SWOT의 최대 위협을 '해당 고객의 이탈'로 확정하고, 종합 평가의 근거로 썼습니다. 숫자마다 출처와 시점을 적어 질문이 들어와도 바로 댈 수 있게 했습니다.

한 장 정리 — 목표 · 역할 · 진행 · 결과한 장 정리 접기

목표	가설을 세우고, 공시로 확인해, 결론까지 가는 연습
내 역할	리서치와 자료 제작, 1·3주차 발표
진행 과정	1주차 디어유: 핵심 질문을 먼저 세우고 공시 16건·IR 자료 14건·앱 리뷰 35건으로 확인 → 팀 최종본 검수 → 2주차 플리토: 재무제표 주석에서 한 고객 매출 비중 48.7% 확인 → 3주차 콜로세움·실리콘투: 팀원 발표자료를 원문 숫자와 대조해 15장으로 다시 만들어 발표
결과	주차마다 가장 큰 위협을 하나로 정해 결론을 냈고, 숫자마다 출처와 시점을 적어 질문이 들어와도 근거를 바로 댈 수 있게 했습니다
한계	진행 중인 과제라 4주차 결과는 아직 없습니다. 기업의 실제 의사결정에 쓰인 자료가 아니며, 과제 자료는 내부 자료라 공개하지 않습니다

일하는 방식

클론 챗봇 8일간 실제 진행 순서

브리프

무엇을 왜 만드는지, 누구의 어떤 문제인지 먼저 글로 정리한다. 코드는 아직 없다.
PRD

브리프를 기능 요구사항으로 쪼갠다. 이번에 안 만들 것도 명시한다.
아키텍처 명세

데이터 흐름과 구조를 265줄로 확정한다. AI에게 시키기 전에 판단을 내려둔다.
설계 리뷰

아키텍처 문서를 리뷰해 구현 전에 결함을 찾는다. 이 프로젝트에서는 리뷰 기록이 255줄 남았다.
에픽 · 스토리 단위 구현

기능을 스토리로 나누고 하나씩 끝낸다. 스토리마다 구현 기록을 남긴다.
회고와 보류 목록

에픽이 끝날 때마다 회고를 쓰고, 못 한 일은 지우지 않고 보류 목록으로 추적한다.

쓰는 도구

생성형 AIChatGPT · Claude · Gemini · Higgsfield(이미지·영상 생성)
에이전트Claude Code — 문서 작성·개발·공시 수집 자동화 / BMAD Method — 기획 문서를 단계별로 쓰는 방법론
업무 자동화n8n — 키워드 뉴스를 매일 아침 구글 시트에 자동으로 쌓는 흐름 (2026.10)
데이터·리서치OpenDART · Python(pandas) · SQL
개발·배포Next.js · React · FastAPI · Supabase · PostgreSQL · Docker · AWS EC2
협업Notion · GitHub

교육 · 활동 · 자격

2020.03 – 2026.02청주대학교 보건행정헬스케어학부 보건행정학 전공 졸업
2024.03 – 2024.12보건행정헬스케어학부 보건행정학 학생회장 — 학과 연간 행사 기획·예산 편성·집행 총괄
2025.12 – 2026.06오즈코딩스쿨 — K-Digital Training AI 헬스케어 웹서비스 개발자 양성 과정 수료
2026.07.13 – 07.30바이브코딩대학 — AX컨설턴트 과정 1기 수료
2026.03병원행정사 · 건강보험사 — 대한병원행정관리자협회
2023.11개인정보보호사 — 한국정보평가협회

Email: rladbsrl298@gmail.com
GitHub: github.com/rladbsrl298

프로젝트

왜 만들었나

왜 만들었나

지식이 공개되기까지

상담 리포트 · 5부 구성

왜 만들었나

왜 하나

일하는 방식

브리프

PRD

아키텍처 명세

설계 리뷰

에픽 · 스토리 단위 구현

회고와 보류 목록

쓰는 도구

교육 · 활동 · 자격