김지현 · 풀스택 개발자

세 프로젝트에서 똑같이 지킨 것

플랫폼은 달랐지만 원칙은 같았습니다. 아래 문장은 전부 실제 코드로 남아 있습니다.

하나

클라이언트가 보낸 값을 신뢰하지 않는다

결제 금액은 항상 서버 단가로 재계산하고, 결제 결과는 PG 재조회로만 확정하며, 전자서명의 서명자는 서버가 DB에서 조회한 사업자번호로 판정합니다. 외부 시스템이 인가 판단을 못 하는 규격이면 서버가 조회 대상을 다시 만듭니다.

icube 쇼핑몰 결제, PAD+S 전자서명과 외부연계에서.

둘

상태는 코드가 아니라 데이터 계층에서 지킨다

상태 전이 조건을 SQL where 절에 직접 넣고 영향 행 수로 분기합니다. API를 우회 호출해도 자격 없는 변경이 0행으로 차단되고, 중복 클릭은 멱등 경로가 흡수합니다. 값이 틀리면 값보다 계산 기준부터 고칩니다.

PAD+S 계약 상태 머신, 쇼핑몰 주문, GaiA 기성 누계에서.

셋

검증하지 않은 것을 끝났다고 하지 않는다

테스트케이스 101건의 기대값을 실데이터 전수 검산으로 채워 금액 결함 5건을 배포 전에 잡았고, 브라우저 E2E 48건을 전량 통과시켰습니다. 자동화가 안 되는 항목은 통과로 적지 않고 SKIP 사유를 남깁니다.

PAD+S 금액 검산, 쇼핑몰 테스트결과서에서.

프로젝트

실무 셋과 개인 프로젝트 하나. 펼치면 문제를 어떻게 풀었는지 볼 수 있습니다.

건설사가 협력업체와 하도급 계약을 맺기까지의 전 과정을 온라인으로 옮긴 플랫폼입니다. 회원사 관리만 있던 상태에서 발주, 입찰, 계약 세 도메인을 데이터 모델부터 새로 설계했고, 사내 ERP와 공정관리 시스템 등 외부 시스템 네 곳과 양방향으로 연계했습니다.

계약을 상태 머신으로 설계하고 전이 조건을 SQL에 넣어, 우회 호출이 구조적으로 차단되게 했습니다.
서명자 판정을 서버 조회 기준으로 바꾸고 서명 체이닝을 도입해, 계약 체결 순서가 서명값 자체로 증명됩니다.
연계 문서와 실제 API가 달랐던 3건을 개발 전에 왕복 검증으로 정정했습니다.
수의계약을 "경쟁 절차를 건너뛴 입찰 1건"으로 모델링해, 하위 로직 수정 없이 계약 유형을 추가했습니다.
IDOR 3건과 권한 역전을 차단하고, 인증 파라미터 위조를 두 겹으로 방어했습니다.

문제 해결 2건

금액 정합어느 값이 맞는지 판정할 기준이 없다

문제: 발주에서 계약으로 흐르는 금액 계산이 서버 여러 곳과 화면에 각각 구현되어, 값이 갈릴 때 기준이 없었습니다.
해결: 테스트케이스 101건의 기대값을 실데이터 전수 검산으로 채우며 결함 5건을 수정하고, 계산 로직을 의존성 없는 클래스 3개로 모았습니다. 저장 API는 금액 파라미터를 아예 받지 않게 바꿨습니다.
결과: 확정 계약 1건의 약 2,600만 원 과소 산정을 발견해 보고했고, 계산 규칙은 한 곳만 고치면 전 경로에 반영됩니다.

전자서명정당한 사용자가 막히고, 서명 순서는 증명할 수 없다

문제: 서명자 판정이 "인증서 이름과 사용자명 문자열 대조"라 표기 차이로 정당한 사용자가 막히거나 우회가 가능했고, 서명 순서를 증명할 수단이 없었습니다.
해결: 기업 공동인증서(VID)로 전환하고 판정 기준을 서버가 조회한 사업자등록번호로 변경했습니다. 원수급사가 하수급사의 서명값 자체에 서명하는 체이닝을 도입했습니다.
결과: 서명 주체가 법인으로 정확히 특정되고, 체결 순서가 별도 기록이 아니라 서명값으로 증명됩니다.

PAD+S 대표 화면images/pads.png (1600x900)

icube 쇼핑몰

2026.06 ~ 재직 중, 모듈 단독 담당 (PAD+S와 병행)

소프트웨어와 특허, 용역을 판매하는 B2B 커머스. 기획서와 DDL 설계부터 결제 연동, QA까지 전 과정을 혼자 만들었습니다. 화면 11개, E2E 48건 전량 통과.

결제 결과를 클라이언트가 아니라 포트원 재조회로만 확정합니다. 조회가 실패하면 성공으로 치지 않습니다.
주문 상태 전이는 전부 상태 가드 update 한 문장으로, 결제 확정은 멱등으로 처리했습니다.
주문 시점의 상품 정보를 스냅샷으로 보존해, 상품이 바뀌어도 주문 이력이 당시 조건을 증언합니다.
채번과 insert를 재시도 루프로 감싸 동시 주문에도 사용자 에러가 없습니다.

문제 해결 1건

결제 확정결제창이 돌려준 결과를 그대로 믿으면 안 된다

문제: 클라이언트가 보낸 "성공"을 믿으면 금액을 위조한 요청으로 결제 없이 결제완료를 만들 수 있었습니다.
해결: 결제 식별자를 서버에서 발급해 주문에 저장하고, 복귀 후 포트원 단건조회로 상태와 금액, 통화를 재검증한 뒤에만 확정했습니다.
결과: 위조 경로가 사라졌고, 새로고침과 중복 클릭에도 주문 상태가 깨지지 않습니다. E2E 5개 시나리오로 검증했습니다.

Java 25 / Spring Boot 4 / Oracle 23 / MyBatis / 포트원 V2 / Playwright

GaiA&CaiRos

2024.08 ~ 2026.06, 담당 메뉴 풀스택 (개발 약 10명)

발주처와 시공사, 감리가 함께 쓰는 건설 사업관리 시스템. 입사 후 첫 실무로 1년 10개월간 기성관리(선급금과 공제금)를 주 담당하며 사업관리 전반을 맡고, 기술검토서와 실정보고 두 메뉴를 새로 구축했습니다. 커밋 391건.

공제금 누계를 자기 회차 값에서 더하던 계산 기준을 직전 회차 누계로 바로잡아, 재계산이 몇 번 돌아도 결과가 같습니다.
사업과 계약 정보가 공공 플랫폼과 어긋나지 않도록 수정, 삭제, 승인 전 경로의 동기화를 정비했습니다.
메인화면과 대시보드의 공정률이 다르게 나오던 문제를 집계 기준 통일로 해소했습니다.

문제 해결 1건

금액 누적재계산할 때마다 공제금이 다시 쌓인다

문제: 기성 공제금 누계가 재계산마다 다시 쌓였습니다. 처음 계산은 정확해 화면에는 이상이 없고, 몇 회차 뒤에야 보고가 들어왔습니다.
해결: 누계 기준을 자기 회차가 아니라 직전 회차로 옮겨 재계산을 멱등으로 만들고, 내역서 수신 경로도 같은 기준으로 통일했습니다.
결과: 회차마다 커지던 오차가 사라졌습니다. "값보다 기준을 먼저 본다"는 원칙은 이후 PAD+S 검산에서도 그대로 썼습니다.

Java 21 / Spring Boot 3.3 / PostgreSQL / MyBatis + MapStruct / Pebble / TUI Grid

duckzip

2026.05 ~ 진행 중, 개인 프로젝트

팀원 다섯을 모아 만드는 팬 커뮤니티 서비스.
웹과 앱이 UI를 공유하는 모노레포입니다.

Next.js 15 / React 19 / TypeScript
Supabase / React Query v5

제 몫은 인증 전체입니다. 다단계 회원가입과 아이디 찾기, 비밀번호 재설정을 만들고 카카오와 구글 소셜 로그인에 더해 네이버 로그인을 직접 구현했습니다. Supabase가 네이버를 기본 제공하지 않아 OAuth 인가와 토큰 교환, 프로필 조회를 커스텀으로 붙이고, 소셜 계정과 일반 계정이 얽히는 가입 흐름을 분리와 통합 규칙으로 정리했습니다. 이메일 인증은 발송 서비스 제약이 생겨 Gmail API(OAuth2)로 전환했습니다.

소셜 로그인 3종이 같은 가입과 온보딩 흐름을 공유합니다.
홈 피드와 사이드바를 DB 연동으로 전환하고, 캐릭터투표와 이상형월드컵을 구현했습니다.
실무 습관 그대로, 전체 테이블과 컬럼에 DB 코멘트를 달아 팀원이 스키마를 읽을 수 있게 했습니다.

기술

언어

Java 21, 25와 JavaScript(ESM), TypeScript, SQL

백엔드

Spring Boot 3.3과 4, Spring Security, MyBatis, MapStruct

프론트엔드

Pebble(SSR), Tailwind CSS v4, TUI Grid. 개인 프로젝트에서 Next.js 15와 React 19

데이터베이스

PostgreSQL, Oracle 23, Supabase. 스키마 설계와 복합 키, 집계 쿼리, 트랜잭션 설계

연동

포트원 V2 결제, 전자서명 SDK(공동인증서 VID), ERP 양방향 REST, 전자결재, OAuth 소셜 3종

품질과 도구

Playwright E2E, 테스트케이스 설계, Git, Gradle 멀티모듈, Jenkins, Docker. 결정은 ADR과 워크로그로 남깁니다.

경력

아이디어정보기술건설과 엔지니어링 B2B 플랫폼 개발사

2024.08 ~ 재직 중, 풀스택 개발자

GaiA&CaiRos2024.08 ~ 2026.06

건설 사업관리(PMIS). 기성 선급금과 공제금 주 담당, 사업관리 전반, 기술검토서와 실정보고 신규 구축

PAD+S2026.06 ~ 재직 중

외주 발주와 계약 플랫폼. 발주, 입찰, 계약 핵심 도메인 리드. 팀 최다 커밋

icube 쇼핑몰2026.06 ~ 재직 중

B2B 커머스 모듈 단독 담당. PAD+S와 병행

학력

동양미래대학교 반도체전자공학과2021 졸업

자격증

정보처리산업기사2025.12
SQLD2024.04
컴퓨터활용능력 2급2023.09

교육

K-Digital Training 풀스택 과정, 멀티캠퍼스2024.01 ~ 07

숫자와 상태가 맞는 시스템을 함께 만들고 싶습니다.

이메일jihyeon2368@naver.com 전화010-3260-9346 깃허브github.com/Z-hyeon

지역경기도 안산시