[ 소개 ]

책임감과 성실함을 강점으로 가진 백엔드 개발자 김현승입니다.

7년간 육군 재정장교로 근무하며 예산·회계 데이터의 정확성과 신뢰성을 관리했습니다.
Java · Spring Boot 프로젝트에서 결제·환불·정산, 동시성 제어, 성능 개선과 장애 대응을 직접 구현하고 검증했습니다.
기술을 먼저 정하기보다 문제를 측정하고 원인을 확인한 뒤, 선택한 방법의 결과까지 검증하는 개발을 중요하게 생각합니다.

📧 Email　[email protected]

🐙 GitHub　https://github.com/hyeonseung-dev

📝 Blog　https://velog.io/@khs0305/posts

📄 이력서 PDF PDF 보기

🌐 온라인 이력서　https://hyeonseung-dev.github.io/

[ 기술 스택 ]

Backend : Java 17 · Spring Boot · Spring Security · JPA

Database : MySQL · Redis / Valkey · Redis Sentinel

Messaging : Kafka

Infra & DevOps : AWS EC2 · RDS · S3 · ECR · ElastiCache · CloudWatch · Docker · GitHub Actions

Test & Performance : JUnit · K6 · EXPLAIN ANALYZE

External & AI : PortOne · OpenAI API · Structured Output

김현승 프로필

[ 주요 프로젝트 ]

주요 프로젝트

[ 기타 프로젝트 ]

대표 프로젝트 외에 부트캠프에서 진행한 학습 프로젝트입니다.

프로젝트	기간	핵심 경험	GitHub
커머스 결제 시스템 프로젝트	2026.05.27 ~ 2026.06.09	PortOne V2 결제·환불·웹훅 구현, 비관적 락과 Idempotency-Key로 결제·환불 정합성 및 중복 처리 대응	payment-system
**고객 및 상품 관리 시스템 프로젝트
• 이커머스 백오피스 -**	2026.04.23 ~ 2026.04.30	공통 예외·응답 구조와 Enum·Soft Delete 기반을 구성하고, JWT/Spring Security 인증·인가 및 DB 블랙리스트 로그아웃을 구현	e-commerce
일정 관리 앱 만들기 Develop	2026.04.16 ~ 2026.04.23	기존 일정 CRUD를 사용자·로그인·댓글 CRUD와 페이징까지 확장하고 세션 기반 인증을 적용	schedule-develop
일정 관리 앱 만들기	2026.04.10 ~ 2026.04.13	Spring 3계층 구조로 일정·댓글 CRUD, 입력 검증, ERD와 API 명세를 구현·문서화	schedule
커머스 과제	2026.03.26 ~ 2026.04.02	Java 콘솔 기반 카테고리·상품 조회, 장바구니·주문, 관리자 상품 추가·수정·삭제 기능 구현	CommerceProject
계산기 과제	2026.03.19 ~ 2026.03.24	제네릭·enum 기반 사칙연산과 계산 이력 관리, 람다·스트림을 활용한 조건 조회 기능 구현	calculator-sparta

[ AI 활용 ]

<aside> 🤖

AI가 코드를 대신 작성하게 두기보다, AI로 개발 속도가 빨라져도 사람이 설계와 코드에서 탈락하지 않도록 검증·이해 구조까지 함께 설계했습니다.

</aside>

0. 사전 실험 · Coffee Order System에서 멀티에이전트 자동화의 한계를 확인

최종 프로젝트 전 1인 Coffee Order System에서 AI 개발 자동화를 먼저 실험했습니다. 처음에는 Planner → Implementer → Verify → Reviewer → Log처럼 역할을 나눈 멀티에이전트 하네스와 반복 수정 루프를 구성해 구현·검증·리뷰를 최대한 연결했습니다.
실제 적용 결과 Issue·문서 충돌을 구현 전에 찾고 독립적인 리뷰를 받는 장점은 있었지만, 에이전트마다 같은 문서와 코드를 반복해서 읽고 역할 사이 결과를 전달하면서 토큰·실행시간·관리 복잡도가 증가했습니다. 반복이 길어지는 문제를 막기 위해 자동 수정 횟수 제한까지 별도로 두었습니다.
또 AI가 Human의 판단이 끝나기 전에 정책이나 구현 시작 여부까지 확정할 수 있는 위험을 확인했습니다. 이를 통해 자동화 단계가 많을수록 좋은 것이 아니라, 도메인 정책·설계·트레이드오프처럼 사람이 책임져야 하는 결정 지점을 명확히 남겨야 한다고 판단했습니다.
그래서 Coffee Order System의 최종 흐름을 단일 Codex + Human Gate로 단순화했고, 이 경험을 BobFull 팀 프로젝트에 가져와 Issue 설계·이해도 질문 → Human READY → AI 구현 → PR 코드 기반 이해도 질문 → Human 리뷰·Merge 구조로 적용했습니다.
AI 자동화 실험 기록 · AI 워크플로우 개선 기록 · Velog AI 고민 기록

① AI 기반 개발 워크플로우 · 이해 병목을 줄이는 방식

flowchart LR
    A["Issue 초안<br>설계 + 이해도 질문"] --> B["Human READY<br>담당자 답변 확인"]
    B --> C["AI 활용 구현"]
    C --> D["PR<br>한 줄 요약 + Mermaid + 코드 이해도 질문"]
    D --> E["사람 리뷰<br>설계·로직 중심"]
    E --> F["Merge"]
    F --> G["V1·V2·V3 종료<br>HTML 시뮬레이터·학습서"]

팀 적용 기준: AI 생성 코드가 동작하더라도 담당자가 설계와 구현 이유를 설명하지 못하면 인지부채가 쌓인다고 판단했습니다. 그래서 Issue에는 구현 전 설계·이해도 질문, PR에는 실제 코드베이스 기반 이해도 질문을 넣고 답변이 확인되어야 구현 완료와 리뷰 승인이 가능하도록 운영했습니다.
발견한 병목: Kafka·Outbox·AI 검수처럼 구조가 복잡해지고 일정상 구현 속도가 빨라지면서, 코드가 만들어지는 속도보다 사람이 이해하는 속도가 느려지는 이해 병목이 생겼습니다.