Seon's IT Story

기능 개발을 마치고 로컬 서버를 띄운 뒤, Postman으로 API를 호출해 DB에 정상적으로 저장되는지 확인한다. 콘솔에 출력된 쿼리와 로그를 눈으로 훑고 나서야 PR(Pull Request)을 올린다. 실무를 경험하며 누구나 거쳐왔을 익숙한 흐름이다. 하지만 서비스 규모가 커지고 비즈니스 로직이 복잡해지면, 이러한 수동 테스트는 명확한 한계를 드러낸다. 첫 번째로 짚고 넘어가야 할 부분은, 왜 비용을 들여가며 테스트 코드를 작성해야 하는가에 대한 근본적인 이유다. 눈으로 확인하는 수동 테스트의 함정수동 테스트는 실행 비용이 높고 반복하기 엉렵다. 특정 비즈니스 로직의 분기문이 10개라면, 모든 엣지 케이스를 검증하기 위해 서버를 재시작하고 파라미터를 바꿔가며 10번의 API 호출을 수행해야 한다. ..

이전 포스팅에서 테스트 코드가 없는 레거시 환경에서 GitLab Runner를 구축하고 스모크 빌드(Smoke Build)를 통해 컴파일과 패키징 무결성을 확보하는 과정에 대해 알아보았다. 스모크 빌드로 기본 파이프라인의 뼈대를 갖추었다면, 다음 단계는 코드 레벨의 결함을 사전에 차단하는 품질 게이트(Quality Gate)를 설계하는 것이다. 테스트 검증 없이 빌드 산출물만 뽑아내는 파이프라인은 버그가 포함된 산출물 또한 자동으로 배포하는 위험을 내포한다. 레거시 Java/Spring 프로젝트에 JUnit/Mockito 기반 단위 테스트를 작성하는 기준과, JaCoCo를 활용해 최소 코드 커버리지를 시스템적으로 강제(Build Break) 하는 방법에 대해 알아본다. 1. 레거시 환경에서의 단위 테스트..

이전 포스팅에서 수동 배포가 초래하는 환경 파편화와 휴먼 에러, 그리고 릴리즈 리스크를 제어하기 위한 CI/CD의 기본 개념에 대해 알아보았다. https://hsunnystory.tistory.com/309 [Software Enginnering] 수동 배포의 한계와 CI/CD 파이프라인의 엔지니어링 가치운영 서버에 변경 사항을 반영할 때 로컬 PC에서 빌드한 산출물을 올리거나, 수정된 .class 파일만 서버에 직접 덮어쓰는 방식을 사용하는 환경을 종종 마주한다. 개발자가 터미널을 열고 직접 프hsunnystory.tistory.com 실무에서 CI 파이프라인을 도입하려 할 때 가장 먼저 마주치는 현실적인 문제는 프로젝트에 작성된 단위 테스트가 전무한 상황이다. 테스트 코드가 없다는 이유로 파이프라인..

운영 서버에 변경 사항을 반영할 때 로컬 PC에서 빌드한 산출물을 올리거나, 수정된 .class 파일만 서버에 직접 덮어쓰는 방식을 사용하는 환경을 종종 마주한다. 개발자가 터미널을 열고 직접 프로세스를 제어하는 방식은 초기에는 직관적으로 보이지만, 기능이 추가되고 팀 규모가 커질수록 소프트웨어 릴리즈 라이프사이클 전체의 리스크를 가중시키는 주원인이 된다. 수동 배포 환경이 초래하는 기술적 결함을 분석하고, 지속적 통합(CI)과 지속적 배포(CD)가 시스템 안정성과 소프트웨어 품질에 미치는 아키텍처적 가치를 정리해 본다. 1. 수동 배포 프로세서의 구조적 한계수동 배포는 일반적으로 개발자 로컬 환경에서 컴파일한 바이너리를 운영 서버로 직접 전송하고 프로세스를 재기동하는 방식으로 진행된다. [개발자 ..

이전 포스팅에서 장애 대응을 위한 Skip/Retry 메커니즘과 상태 저장 복구(Restart) 아키텍처를 알아보았다. https://hsunnystory.tistory.com/307 [Spring Batch] 장애 대응과 멱등성 : Skip, Retry, Restart이전 포스팅에서 OOM을 방지하기 위한 ItemReader의 Cursor와 Paging 아키텍처를 알아보았다. https://hsunnystory.tistory.com/306 [Spring Batch] OOM을 피하는 ItemReader 아키텍처 : Cursor vs Paging이전 포스팅에서 데이터hsunnystory.tistory.com 대용량 데이터 처리의 안정성을 확보했다면, 남은 과제는 처리 속도다. 1억 건의 데이터를 순차적으로..

이전 포스팅에서 OOM을 방지하기 위한 ItemReader의 Cursor와 Paging 아키텍처를 알아보았다. https://hsunnystory.tistory.com/306 [Spring Batch] OOM을 피하는 ItemReader 아키텍처 : Cursor vs Paging이전 포스팅에서 데이터를 분할하여 트랜잭션을 관리하는 청크 지향 처리(Chunk-oriented Processing) 메커니즘을 알아보았다. https://hsunnystory.tistory.com/305 [Spring Batch] 청크 지향 처리(Chunk-oriented Processinghsunnystory.tistory.com 엔터프라이즈 환경에서 야간에 수행되는 대용량 배치는 수백만 건의 데이터를 수 시간에 걸쳐 처리한다..

이전 포스팅에서 데이터를 분할하여 트랜잭션을 관리하는 청크 지향 처리(Chunk-oriented Processing) 메커니즘을 알아보았다. https://hsunnystory.tistory.com/305 [Spring Batch] 청크 지향 처리(Chunk-oriented Processing)이전 포스팅에서 스프링 배치 도메인 모델과 6개의 핵심 메타 테이블이 작업 상태와 재시작을 통제하는 원리를 알아보았다. https://hsunnystory.tistory.com/284 [Spring Batch] 스프링 배치(Batch) 도메인 모델hsunnystory.tistory.com 엔터프라이즈 환경에서 1,000만 건의 결제 데이터를 정산해야 한다고 가정해 보자. 아무리 청크 단위로 데이터를 가공하고 저장한..

이전 포스팅에서 스프링 배치 도메인 모델과 6개의 핵심 메타 테이블이 작업 상태와 재시작을 통제하는 원리를 알아보았다. https://hsunnystory.tistory.com/284 [Spring Batch] 스프링 배치(Batch) 도메인 모델과 메타 테이블엔터프라이즈 분산 환경에서 동작하는 대용량 배치는 반드시 언젠가 실패한다는 가정하에 설계되어야 한다. 수백만 건의 데이터를 처리하다가 네트워크 타임아웃이나 데이터 정합성 문제로 예hsunnystory.tistory.com 엔터프라이즈 환경에서 수백만 건의 데이터를 다룰 때, 가장 중요한 것은 메모리 관리와 트랜잭션의 제어다. 100만 건의 데이터를 단이 트랜잭션으로 묶으면 데이터베이스 락(Lock) 점유 시간이 길어지고 애플리케이션 메모리 누수(O..

스프링 부트로 개발을 마치고 빌드 명령(gradle build)을 수행하면 단 하나의 거대한 .jar 파일이 생성된다. 이 파일은 외부 라이브러리 의존성뿐만 아니라 내장 WAS(Tomcat) 라이브러리까지 내부 하위 경로에 전부 품고 있는 Fat JAR(혹은 Executable JAR) 포맷이다. 개발자는 이 단 하나의 파일만 서버에 복사한 뒤 java -jar application.jar 명령을 통해 서비스를 즉각 구동할 수 있다. 이번 포스팅에서는 표준 자바 명서(JVM)의 한계를 스프링 부트가 어떤 클래스로딩 아키텍처로 극복하고 실행 가능한 단일 JAR 구조를 완성했는지 그 원리를 알아본다. 1. JVM 클래스패스 명세의 한계와 중첩 JAR(Nested JAR) 문제표준 Java Virtual Ma..

1. 정보보호 및 개인정보 관리체계(ISMS -P)기존의 정보보호 관리체계(ISMS)와 개인정보보호 관리체계(PIMS)를 통합한 인증제도다. ISMS-P 인증 기준 (총 101개 통제 항목) - 관리체계 수립 및 운영 (16개) : 정보보호 정책 수립, 경영진의 참여, 위험 관리 등 (Plan-Do-Check-Act 사이클 기반) - 보호대책 요구사항 (64개) : 접근 통제, 암호화, 물리적 보안, 사고 예방 및 대응 등 실질적인 보안 대책 - 개인정보 처리단계별 요구사항 (21개) : 수집 -> 보유 및 이용 -> 제공 -> 파기에 이르는 개인정보 생명 주기 관리. (ISMS 인증만 받을 경우 이 영역은 제외) 인증 의무 대상자 - 정보 통신망 서비스 제공자 (ISP), 집적 정보 통신시설 사업자 (..