전체 글
-
먹고, 코딩하고, 사랑하라개발/그 외 2025. 3. 30. 20:52
회사에서 일을 시작한 지 어느새 7개월 차가 되었다. 그동안 나는 회사에 모니터링 시스템을 구축하거나, 구식 시스템을 유지보수 가능한 현대적인 구조로 바꾸는 프로젝트를 맡아왔다. 내가 속한 조직은 전형적인 개발 조직과는 거리가 있었다. 개발 업무가 필요했지만, 이를 전담하거나 체계적으로 운영할 개발팀은 없었다. 시스템을 개선하거나 업무 효율을 높이기 위한 개발은 최소한으로만 이루어지고 있었다. 그런 환경 속에서, 나는 프로젝트를 진행하며 점점 욕심이 생겼다. 처음엔 주어진 일만 해도 충분했다. 그러나 시스템을 들여다볼수록 눈에 보였다. 느렸지만 모두가 불편을 감수하고 사용하던 시스템, 고장 나지 않으면 굳이 손대지 않던 구조들. 누군가는 '원래 그런 것'이라며 넘기던 것들이 내 눈에는 고쳐야 할 문제로 ..
-
기술 황무지에서 살아남기: 제가 어떻게 해야 하나요?개발/그 외 2025. 3. 23. 13:15
컴퓨터공학을 전공했고, 나는 자연스럽게 개발자가 됐다.첫 회사에 들어갈 때는 기대도 컸다. 테크 기업은 아니었지만, 사용자에게 가치를 전달하는 '서비스'의 본질을 배우는 게더 중요하다고 생각했다. 최신 기술을 반드시 다루지 않아도 괜찮다고 여겼고, 실무 경험과 문제 해결 능력이 더 중요하다고 믿었다. 하지만 현실은 생각보다 훨씬 복잡했다. 이 정도로 시스템이 낙후돼 있을 줄은 몰랐고, 무엇부터 손대야 할지조차 막막했다.기술적인 기반이 부족하다 보니, 개선을 시작하는 것 자체가 쉽지 않았다. 겉보기에는 컨테이너 기반의 기술을 쓰고 있었지만, 그건 껍데기에 불과했다. 서비스는 Docker 위에서 돌아갔지만, 그에 걸맞은 운영 체계는 없었다. 모니터링 시스템은 없었고, 장애나 리소스 이슈에 대한 대응은 늘 ..
-
왔노라, 보았노라, 모니터링 했노라 : 제로부터 시작하는 모니터링 시스템 구축개발/그 외 2025. 3. 20. 13:48
이전 글 "달리는 자동차의 타이어를 교체하기 : Stored Procedure 기반 데이터 접근 방식에서 ORM 기반으로 전환 (1)" (https://na2ru2.tistory.com/46)에서 내가 근무하고 있는 회사의 환경이 어떠한지 간단하게 언급한적이 있다. 우리 회사는 테크 회사가 아니다. 그렇다 보니 체계적으로 애플리케이션들의 상태를 실시간으로 모니터링할 수 있는 시스템이 없는 상태였다. (테크 회사가 아니라고 전산화 수준이 높지 않다는 것은 아니다.) 사실 우리 회사의 서비스는 재난급 트래픽이 몰리는 상황이나, 하드웨어 자원이 턱없이 부족한 상태에서 애플리케이션을 극한으로 최적화해야 하는 극단적인 환경에 놓여있지는 않다. 따라서, 모니터링 시스템을 구축하게 된 특별한 계기나 긴박한 필요성이 ..
-
달리는 자동차의 타이어를 교체하기 : Stored Procedure 기반 데이터 접근 방식에서 ORM 기반으로 전환 (2)개발/Spring Boot 2025. 3. 20. 09:42
이 글은 Stored Procedure에서 ORM으로 전환하는 여정을 다루는 시리즈의 두 번째 글입니다. 첫 번째 글에서는 기존 시스템의 Stored Procedure 기반 데이터 접근 방식과 그 한계에 대해 살펴보았습니다. 이제 본격적인 전환 과정과 그 과정에서 직면했던 다양한 난관, 그리고 이를 해결하기 위해 취했던 접근 방식에 대해 자세히 설명해보려고 합니다.Stored Procedure에서 ORM으로의 전환 과정에서의 난관과 해결 전략1. 기존 SP의 복잡한 의존성 구조 파악Stored Procedure(SP)에서 ORM으로 전환하는 과정에서 가장 먼저 직면한 문제는 SP의 복잡한 호출 관계였습니다. 기존 시스템에서는 SP들이 다양한 함수(FN)를 호출하며 강한 의존성을 가지고 있었으며, 단순히 ..
-
달리는 자동차의 타이어를 교체하기 : Stored Procedure 기반 데이터 접근 방식에서 ORM 기반으로 전환 (1)개발/Spring Boot 2025. 3. 18. 21:47
나는 IT가 주된 핵심이 아닌 고전적인 서비스 기업에서 웹 개발자로 근무하고 있다. 이 회사는 다수의 서비스를 운영하고 있으나, 대부분은 과거에 구축된 레거시 아키텍처를 기반으로 현재까지 유지보수되고 있다. 나는 이런 환경에서 레거시 시스템을 모던 아키텍처로 전환하는 과정을 직접 겪어보았기에, 그 경험을 기록하고 나누고자 이 글을 작성하게 되었다.특히 기존에 Stored Procedure(이하 SP) 기반으로 동작하던 시스템을 ORM 기반으로 전환하는 과정에서 겪은 어려움과 해결 방법 그리고 그 전환이 가져다 준 이점등을 집중적으로 다룰 예정이다. 이 글은 그 여정에서 얻은 경험과 인사이트를 공유함으로써 비슷한 고민을 하는 사람들에게 도움을 주는 것을 목표로 한다.운영중인 시스템에서 Stored Pro..
-
(OCP)개방 폐쇄 원칙 위배를 극복한 전략 패턴 적용 사례개발/Spring Boot 2024. 7. 12. 14:39
public interface PhotoProvider { String crawlingImageURL(String page_url); byte[] getImageBytes(String image_url); String getHostname();}public abstract class AbstractPhotoProvider implements PhotoProvider { @Override public byte[] getImageBytes(String image_url) { return ConnectionAction.getImage(getHostname(), image_url); }}@Componentpublic class HaruFilm extends Abstr..
-
Redis Cache를 통해 이미지 조회 성능 개선하기개발/Spring Boot 2024. 5. 24. 23:52
기존의 이미지 조회 방식에서는 DB에 직접 접근하여 이미지를 가져오는 방식이었다. 우리 서버는 이미지를 조회할 때 항상 Snappy를 통해 압축 해제를 해야 했는데, Snappy의 성능이 아무리 좋아도 항상 일정한 오버헤드를 가진다는 문제가 있었다. 이로 인해 일반 DB 조회보다 더 많은 리소스를 소모하게 되어 성능 저하가 발생했다. 이러한 문제를 해결하기 위해 Image Cache를 구현해야 했다. 캐시를 통해 빈번하게 조회되는 이미지를 메모리에 저장하면, 데이터베이스에 직접 접근하는 빈도를 줄 일 수 있어 조회 성능이 크게 향상될 수 있다. 특히, Redis는 인 메모리 데이터 저장소로 매우 빠른 조회 속도를 제공하여 이미지 조회 성능을 극대화시킬 수 있다. Redis를 이용하여 Image Cache..
-
이미지 압축, 해제 성능 개선하기 - Snappy 도입을 통하여개발/Spring Boot 2024. 5. 24. 17:10
nGrinder를 사용하여 이미지 로드 API를 테스트하는 동안 서버가 다운되는 문제가 발생했다.초기에는 서버가 정상적으로 응답했지만, 가상 사용자가 점차 증가하면서 서버의 응답 속도가 느려지기 시작했다. 결국 사용자가 일정 수를 넘어서자 서버가 더 이상 요청에 응답하지 않고 다운되었다. 서버 로그를 확인해 보니 이미지 로드 API를 호출하는 중 문제가 발생하는 것을 확인할 수 있었고, 문제의 원인이 ImageUtil 클래스 내의 decompressImage 메서드를 호출하면서 발생함을 알게 되었다. 문제를 찾기 위해서는 먼저, 원래 서버에서 이미지 압축과 해제가 어떻게 이루어졌는지 다시 확인하는 과정이 필요하다. 서버에서는 Deflater와 Inflater를 사용하여 이미지 압축 및 해제를 수행한다. ..