Seon's IT Story

[Tomcat] 톰캣 기동의 원리 2편 : Windows 서비스와 레지스트리에 박제되는 설정

이전 포스팅에서 톰캣의 디렉터리 구조와 CATALINA_HOME, 그리고 startup.bat에서 catalina.bat, setenv.bat으로 이어지는 스크립트 체인을 알아보았다.https://hsunnystory.tistory.com/3161편 마지막에 "서비스로 뜨는 톰캣은 이 스크립트 체인을 전혀 거치지 않는다"고 적었다. 처음 이 사실을 확인했을 때 꽤 당황했던 기억이 있다. 배포본의 setenv.bat에 내장 JDK 경로를 지정해 두고 서비스로 돌리고 있었는데, 정작 서비스는 그 파일을 읽은 적이 없고 install하던 날 PC에 깔려 있던 다른 JDK로 계속 돌고 있었기 때문이다. 버전이 우연히 같아서 아무 증상이 없었을 뿐이다.이번 편은 Windows 서비스로 등록된 톰캣이 실제로 어떻게..

최근 사내 배포본을 정리하다가 이상한 증상을 하나 만났다. 같은 톰캣 배포본인데 bin의 startup.bat으로 실행할 때와 Windows 서비스로 실행할 때 설정 파일의 상대 경로가 서로 다르게 해석되는 것이다. 한쪽에서는 resources/...로 잘 잡히던 경로가 다른 쪽에서는 ../resources/...로 고쳐줘야 동작했다.처음에는 설정 문제라고 생각했는데, 원인을 따라 내려가 보니 결국 톰캣이 기동되는 구조 자체를 제대로 이해하지 못하고 있었다는 결론에 도달했다. 톰캣을 몇 년씩 운영하면서도 startup.bat을 실행하면 내부에서 무슨 일이 일어나는지, CATALINA_HOME이 어디까지 영향을 주는지 정확히 설명할 수 없었던 것이다.이번 시리즈에서 그때 추적했던 내용을 원리부터 정리해 보..

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만 건의 결제 데이터를 정산해야 한다고 가정해 보자. 아무리 청크 단위로 데이터를 가공하고 저장한..