gornn blog

portfolio

신뢰할 수 있는 서비스를 설계하는 백엔드 개발자 김균호입니다.

사용자가 믿고 이용할 수 있는 서비스는 명확한 규칙과 안정적인 동작에서 시작한다고 생각합니다. 이를 위해 현실의 복잡한 문제를 규칙으로 정리하고, 장애에도 데이터의 정확성을 지키도록 설계합니다. 설계한 내용이 실제 운영에서도 지켜지는지 검증하고 개선합니다.

contact: gyunh01@naver.com
: g0rnn.github.io

Skills

Java
Spring Boot
Spring Data JPA
MySQL
AWS

Education

2026.01 ~ 진행중삼성 청년 SW · AI 아카데미(SSAFY)
2020.03 ~ 2026.02국립부경대학교 컴퓨터공학전공 4.08 (전공 4.20) / 4.5

Awards

2026.06SSAFY 1학기 관통 프로젝트 최우수상 (12팀 중 1등)
2024.08지역 사회 문제 해결을 위한 해커톤 우수상 (20팀 중 2등)

Certifications

2026.02.21PCCP (프로그래머스 코딩전문역량인증) 4급 775/1000점
2025.12.24정보처리기사

Waps

동아리 프로젝트 운영 서비스

프로젝트 개요

배경: 동아리 프로젝트의 전 과정을 일관되게 운영하고 학기별 활동을 축적할 수 있는 공간 필요
목표: 프로젝트 시작부터 최종 평가까지의 운영을 통합하고, 활동 기록을 보존·공유하는 웹서비스 구축
규모: 총 6명 (FE 3명, BE 2명, Design 1명), 누적 가입자 200명
역할: Backend & Infra
기여: 30% (주요 기능 3개 개발, 14/18개월 운영)

주요 기능

팀빌딩: 지원자와 팀장의 선호와 역할·인원 조건을 반영한 팀 편성
행사 투표: 우수 프로젝트 투표 및 결과 집계
관리자 운영: 프로젝트·행사 진행 상태 변경

담당 역할

팀빌딩 알고리즘 설계·구현: 지원자·팀장 양측의 선호와 모집 조건을 반영한 자동 편성 기능 개발
투표 정합성 및 설계 개선: 동시 요청에 따른 초과·중복 투표 문제 해결, 다음 학기에도 재사용할 수 있도록 투표 구조 개선
관리자 기능 개발: 임원진이 개발자의 도움 없이 프로젝트와 행사 진행 상태를 직접 관리하도록 운영 기능 개발
배포·운영 및 유지보수: 배포 자동화와 서버 이전 담당, 14개월간 서비스 운영 중 발생한 오류 수정 및 기능 개선

Waps 팀빌딩 행사를 운영하는 모습 — Waps 팀빌딩 첫 운영 시

Waps 부스 안내 배너 — Waps 첫 부스 운영

Waps

동시 요청으로 인한 투표 규칙 위반을 DB 구조 개선으로 차단

문제

사용자의 동시 요청으로 '1인 3표 제한'과 '동일 프로젝트 중복 투표 금지' 규칙이 위반됨
각 투표 요청의 트랜잭션이 투표 내역 조회(SELECT)와 기록(INSERT) 사이에 다른 트랜잭션이 개입하는 Race Condition

개선 전: 두 트랜잭션이 모두 저장되어 6표가 기록되는 흐름 — Before

해결과정

판단

투표 행 잠금을 검토했으나 첫 투표에는 잠글 투표 행이 없고, 사용자 행 잠금은 같은 행을 사용하는 다른 기능에도 영향을 줄 수 있음
여러 요청이 동시에 투표 가능하다고 판단하더라도, 저장 시점에 투표 규칙을 준수하도록 DB 제약 선택

행동

슬롯 컬럼과 CHECK 제약을 추가해 사용자 투표를 최대 3개로 제한하는 구조 설계
사용자별 슬롯 중복과 동일 프로젝트 중복 투표를 막는 UNIQUE 제약 각각 추가
동시 요청 상황을 재현하는 테스트를 작성해 문제 재발을 감지하도록 함

개선 후: UNIQUE 제약 위반으로 두 번째 트랜잭션이 롤백되는 흐름 — After

결과

동시 요청에서도 유효한 투표만 저장되고, 초과 요청은 거부됨
기존 중복 데이터 삭제 후 슬롯 컬럼과 DB 제약을 운영 서비스에 반영

Waps

수작업으로 30분 이상 소요되던 팀빌딩을 명확한 기준에 따라 자동화

문제

동아리 팀빌딩에서 지원자는 희망 팀 순위를, 팀장은 직군별 정원과 선발 우선순위를 제출
중복 지명, 직군별 정원 초과/미달 문제가 얽혀 팀 합류 기준을 결정하기 어려움

해결과정

판단

예시 시나리오를 손으로 그려보던 중 두 팀이 같은 지원자를 지명하는 경우 어느 팀에 합류시켜야할지 기준이 없다는 걸 파악
중복 지명, 직군별 정원 초과/미달 문제 중 중복 지명이 문제의 핵심이라고 판단

중복 지명을 희망 팀 순위로 해소하는 팀빌딩 규칙 예시

행동

중복 지명 시 지원자의 희망 팀 순위가 반영되도록 규칙 정의
정원 미달, 후보 고갈 등 엣지 케이스에 대한 테스트 검증
알고리즘이 직군을 참조하지 않게 설계하고 직군마다 반복 실행하는 구조로 구현

결과

25년 1학기 ~ 26년 2학기 행사에 사용하여 팀 35개 편성 & 지원자 총 309명
한 명이 빠질 때만 한 명이 추가되는 규칙으로 정원 초과가 구조적으로 불가능
정원 초과/미달 문제는 중복 지명 규칙 수립 후 추가 설계 없이 해결됨

행사 OT부터 결과 발표까지의 진행 흐름 중 자동화된 구간

Secome

AI 회의 보조 서비스

프로젝트 개요

배경: 협업 중 나온 결정과 맥락이 흩어져 기록되지 않고 매번 처음부터 다시 논의됨
목표: 회의 내용과 결정사항을 프로젝트 문서에 자동 반영해 팀의 협업 맥락을 이어감
규모: 총 6명 (FE 1명, BE 4명, AI 1명)
역할: Backend & Infra
기여: 20% (JIRA 1,252 SP 중 223 SP (17.8%) 완료)

주요 기능

AI 회의록: 회의 음성을 변환해 AI 회의록 생성·편집
문서 자동 관리: 회의록 근거 문서 수정안 생성 및 반영
문서 기반 AI 챗봇: 프로젝트 문서를 검색해 근거와 함께 답변

담당 역할

회의 기록 자동화: 회의 녹음부터 음성 변환, 대화 기록 생성까지 처리되는 파이프라인을 구축하고 서버 중단 시 변환 작업이 유실되지 않도록 개선
회의 종료 정합성 개선: 회의가 종료·취소되면 진행 중인 안건과 녹음도 함께 정리되게 하고, 외부 호출이 실패해도 다시 시도할 수 있도록 개선
AI 사용량 제한: AI를 쓰는 API에 회원별 사용 한도를 두어 한 사용자의 무분별한 AI 호출을 제한
조회 성능 개선: 목록 조회 시 항목 수만큼 쿼리가 늘어나던 문제를 해결해 쿼리를 13개에서 4개로 줄이고, 테스트로 다시 나빠지지 않게 고정

회의 중 챗봇을 사용하는 화면

작성된 회의록이 기존 문서에 반영되는 화면

Secome

서버 중단에도 재시도 가능한 STT 처리 구조 설계

문제

STT 변환 완료 응답을 받기 전에 서버가 중단되면 회의 대화 기록이 누락될 수 있음을 발견함
서버가 중단되어도 결과를 복구하거나 변환을 재시도할 수단이 필요함

개선 전: 서버 중단 시 응답이 유실되어 대화 기록이 누락되는 흐름 — Before

해결과정

판단

상태를 DB에 기록 & 스케줄러 도입: 작업 정보를 보존 & 중단된 작업을 주기적으로 재시도 가능
@Async로 비동기 실행: 서버 재시작 시 작업 정보가 사라져 재시도 불가
AI 서버에서 결과 보관·재전송: AI 서버는 상태를 관리하지 않도록 설계함

행동

변환 대상과 처리 상태를 보존하는 STT 작업 테이블을 설계하고 스케줄러가 변환할 녹음을 대기 작업으로 등록하도록 구현함
STT 호출 전에 진행 상태를 기록하도록 처리 순서를 구성하고 진행 중 상태가 15분을 초과한 작업을 재시도하는 복구 로직을 구현함

개선 후: 15분 넘은 작업을 재선점해 변환을 재요청하는 흐름 — After

결과

중단된 변환을 자동 재시도해 사용자가 직접 재처리를 요청할 필요를 줄임
최종 실패한 작업도 상태와 원인이 남아 누락된 기록을 확인하고 대응할 수 있음