백엔드 개발자
전은성입니다.

제품별 탄소배출량을 계산하는 서비스입니다. DB 스키마 관리와 조회 성능을 개선하고, 중복으로 유지되던 화면 구현을 통합했습니다.

• 기존 스키마와 충돌한 Flyway를 제거하고 필요한 SQL만 자동 적용

  Flyway 적용 후 새 DB에서 스키마를 재현하지 못하고, 모듈별 실행 순서와 기존 스키마의 차이를 처리하는 설정이 221줄까지 늘었습니다. 이 구성을 유지하는 대신 Flyway를 제거하고, JPA 스키마 관리와 보완 SQL 자동 실행으로 바꿨습니다.

  도입 22일 후 제거 · 보완 SQL 자동 적용

  Flyway를 제거한 이유 스키마 변경 SQL 자동 적용

• 집계 조회와 PDF 생성의 병목을 각각 개선

  조회할 때마다 CTE 5개를 재계산하던 뷰는 집계 결과를 저장하는 테이블로 옮겼습니다. 기존 조회를 유지한 채 데이터 일치를 확인한 뒤 읽기 경로를 전환했습니다. PDF 생성에서는 한글 텍스트 배치가 병목이어서, 화면 캡처 방식으로 바꿔 생성 시간을 줄였습니다.

  PDF 생성 6.4초 → 0.7초 · 이미지 방식이라 텍스트 검색 불가

  집계 뷰를 테이블로 전환한 과정 N+1 문제를 해결한 네 가지 사례 PDF 생성 방식 변경과 성능 비교

• V1·V2 화면 구현을 통합하고 사용하지 않는 파일 정리

  V1과 V2가 함께 남아 같은 버그를 두 번 수정해야 했습니다. 화면을 단계적으로 V2로 통합했습니다. 별도로 실행 경로를 확인해, 최근까지 수정됐지만 실제로는 사용하지 않는 파일도 정리했습니다.

  V1 코드 2,389줄 삭제 · 미사용 파일 누적 102개 정리

  V1·V2 통합 과정 실행 경로를 확인해 미사용 파일 정리

기관별 Kubernetes 클러스터와 블록체인 네트워크를 생성·관리하는 플랫폼입니다. 백엔드 API와 인프라 자동화를 담당했습니다. 인터넷이 차단된 환경에서 설치할 수 있도록 필요한 이미지를 로컬 레지스트리에 미리 적재하고, 외부 다운로드를 막았습니다.

• 신규 기관 환경 구성을 API 요청 한 번으로 자동화

  신규 기관을 추가할 때 약 157회의 명령 실행과 설정 파일 5종 작성이 필요했습니다. 각 단계가 끝날 때마다 운영자가 다음 명령을 실행하던 과정을 스크립트로 묶고, 애플리케이션 서버에서 SSH로 실행하게 했습니다. 20~43분이 걸리는 환경 구성은 트랜잭션 커밋 후 비동기로 처리해 HTTP 응답을 기다리지 않게 했습니다. 진행 상태를 DB에 기록해 실패한 작업을 확인할 수 있게 했습니다.

  운영자 수동 조작 157회 → 1회 · 실행 후 추가 조작 불필요

  환경 구성에는 자동화 후에도 20~43분이 걸립니다. 운영자는 시작 요청 후 각 단계를 지켜보며 다음 명령을 실행할 필요가 없어졌습니다.

• 기관별 클러스터로 운영 환경 분리

  기관별로 데이터와 운영 환경을 분리해야 했습니다. 네임스페이스만 나누면 API 서버와 CRD(사용자 정의 리소스 정의)를 공유하므로, 기관마다 독립 클러스터를 구성했습니다. 포트는 기관당 10개씩 배정하고, DB에 남은 최대 대역 다음 번호부터 할당했습니다. 중간의 빈 대역은 건너뛰지만, 가장 높은 대역을 삭제하면 그 대역이 다시 배정될 수 있습니다.

  기관별 독립 클러스터 · 포트 10개씩 배정

  기관당 약 0.9코어·메모리 2.4GiB·저장 공간 28Gi가 필요합니다. 기관별 설정을 분리할 수 있지만, 공유 클러스터보다 자원을 많이 사용해 서버 한 대에 수용할 수 있는 기관 수는 줄어듭니다.

• Fabric과 Besu의 배포·운영을 공통 API로 제공

  Fabric과 Besu는 네트워크 구성과 인증 방식이 달라 각각의 명령이 필요했습니다. 원격 실행의 공통 절차와 체인별 구현을 분리해, 사용자가 같은 REST API로 배포·운영할 수 있게 했습니다. 파드 시작이 늦어져 실패하던 작업에는 공통 대기·재시도 처리를 적용했습니다.

  Fabric 네트워크 생성 20단계 자동화 · 배포 스크립트 1,178줄

  SFTP 디렉터리 생성의 동시성 오류 해결 비동기 작업의 요청 검증과 응답 처리 CRD 스키마 패치로 배포 오류 우회 kubectl exec 타임아웃과 재시도 적용

프로젝트 규모: 백엔드 655파일·63,828줄  /  REST 컨트롤러 123개  /  프론트엔드 536파일  /  커밋 1,083개  /  직접 작성한 인프라 셸 스크립트 49개·8,831줄

JSP와 JavaScript로 구현한 업무 화면 수십 개를 운영하는 시스템입니다. 장비의 조직 소속 모델, 권한 관리, 검색 쿼리를 개선했습니다.

• 장비의 소속 조직을 고객과 독립적으로 관리하도록 모델 변경

  기존에는 고객의 조직 정보로 장비의 소속을 결정해, 고객과 다른 조직에 속하거나 고객이 아직 배정되지 않은 장비를 처리할 수 없었습니다. 장비에 조직 컬럼을 추가하고 기존 조인 결과로 값을 채웠습니다. 기존 조회와 새 컬럼의 값이 일치하는지 확인하며 조회 경로를 단계적으로 전환했습니다.

  장비의 조직 정보 직접 저장 · 기존 데이터 이전 후 조회 전환

  조직 컬럼 추가와 데이터 이전 과정

• 검색 조건을 인덱스에 맞춰 전체 스캔 해소

  부분일치 검색용 GIN trigram 인덱스를 만들었지만 검색에 사용되지 않았습니다. 검색 컬럼에 적용한 LOWER()가 인덱스 정의와 달라, 쿼리를 ILIKE로 바꿨습니다. 제조사 검색은 드롭다운으로 바꿔 부분일치 검색을 없앴습니다.

  약 130곳 ILIKE 전환 · 검색 시 전체 스캔 해소

  검색 쿼리와 인덱스가 일치하지 않았던 원인 인증·권한·로깅 필터의 DB 접근 개선 깊이 제한으로 누락된 조상 조직 조회 수정

증권사 API로 주문과 체결을 처리하는 개인 프로젝트입니다. 직접 개발해 실계좌로 운용하며, 실제 체결 내역과 백테스트 결과로 계산과 전략을 검증하고 있습니다.

• 실제 체결 47건과 대조해 수수료·세금 계산 수정

  증권사가 청구한 금액과 시스템의 계산값을 대조해 수수료율 오류, 거래세율 변경 누락, ETF 분류 오류를 확인했습니다. 요율과 분류 기준을 수정하고, ETF 여부를 확인하지 못하면 세금을 포함해 손익을 계산하도록 했습니다.

  실제 청구 세금 대비 상대오차 1.250% → 0.068%

  체결 내역으로 수수료와 세금 검증

• ML 설정 오류를 수정한 뒤에도 기능을 비활성화한 이유

  환경변수 누락으로 ML 기능이 켜지지 않는 문제를 수정한 뒤, 기능 사용 여부는 별도로 검증했습니다. A/B 비교와 분류·회귀 실험에서 수익 개선 근거를 얻지 못했습니다. 과거 데이터로 학습하고 이후 기간을 평가하는 순차 검증에서도 효과가 확인되지 않아 기본값을 비활성화로 유지했습니다.

  A/B 비교·분류·회귀 실험 후 ML 비활성화 유지

  ML 사용 여부를 판단한 검증 과정 매수 신호 이후 체결이 없었던 원인 분석