Seon's IT Story

2025년 1회 정보보안기사 필기에 합격한 지 1년이 훌쩍 지났지만.. 실기까지 마무리된 김에 기억을 더듬어 필기 후기부터 써보려고 합니다. 제 블로그 예전 글을 보신 분들은 아시겠지만, 사실 제가 정보보안기사에 처음 발을 들인 건 2020년이었습니다. https://hsunnystory.tistory.com/194 정보보안기사 취득 준비 시작오랜만에 자격증을 취득해보려고 한다. 지금 회사에서 하고있는 업무가 정보보호이고 앞으로 이 분야에 있을 것 같으니 미래를 위해 도전..! 시험 일자는 2020-05-30 이니 주말에 시간내서 공부하hsunnystory.tistory.com 학부 때 정보보안 동아리를 하면서 이쪽 일에 로망이 있었고 (해킹 같은 게 멋있어 보였습니다 ㅎㅎ), 2017년에 정보처리기사..

기능 개발을 마치고 로컬 서버를 띄운 뒤, 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..