같이 일하고 싶은 개발자

이전글 :: Redis 기반 대시보드 스냅샷 캐시 설계 (4) Redis 기반 대시보드 스냅샷 캐시 설계이전글 :: 예약과 취소처럼 기준 시점이 다른 데이터를 하나의 집계 파이프라인으로 다루기 (3) 예약과 취소처럼 기준 시점이 다른 데이터를 하나의 집계 파이프라인으로 다루기이전 글에서는jipang9-greedy-pot.tistory.com 이전 글에서는 대시보드 데이터를 Redis 스냅샷으로 저장하고, 화면에서는 저장된 데이터를 빠르게 조회하도록 구성한 과정을 다뤘습니다.하지만 Redis 캐시를 사용한다고 해서 모든 문제가 사라지는 것은 아닙니다.캐시에 저장할 데이터를 누군가는 만들어야 합니다.그 역할을 하는 것이 바로 배치입니다. 대시보드 배치는 사용자가 직접 보는 기능은 아니지만, 화면에 노출되는 ..

이전글 :: 예약과 취소처럼 기준 시점이 다른 데이터를 하나의 집계 파이프라인으로 다루기 (3) 예약과 취소처럼 기준 시점이 다른 데이터를 하나의 집계 파이프라인으로 다루기이전 글에서는 메인 대시보드와 판매 제휴사 통계의 숫자를 맞추기 위해, 같은 원천 데이터를 기반으로 여러 통계 뷰를 생성하는 구조를 설계한 과정을 다뤘습니다.하지만 같은 원천 데이터를jipang9-greedy-pot.tistory.com 이전 글에서는 예약과 취소처럼 기준 시점이 다른 데이터를 하나의 집계 파이프라인에서 처리하는 방법을 다뤘습니다.이제 다음 고민은 조회 성능입니다.아무리 집계 기준을 잘 정리하더라도, 사용자가 대시보드에 접근할 때마다 모든 데이터를 실시간으로 계산한다면 화면 응답 속도와 DB 부하를 감당하기 어렵습니다...

이전글 :: 원천 데이터를 기준으로 여러 통계 뷰를 생성하는 구조를 설계해보자 (2) 원천 데이터를 기준으로 여러 통계 뷰를 생성하는 구조를 설계해보자이전 포스팅에서는 관리자 대시 보드 개선이 단순한 UI 리뉴얼 작업이 아니었다는 이야기를 했습니다. 겉으로 보기에는 카드, 그래프, 표를 새로 배치하는 작업처럼 보였지만 실제로는 훨씬 더jipang9-greedy-pot.tistory.com 이전 글에서는 메인 대시보드와 판매 제휴사 통계의 숫자를 맞추기 위해, 같은 원천 데이터를 기반으로 여러 통계 뷰를 생성하는 구조를 설계한 과정을 다뤘습니다.하지만 같은 원천 데이터를 사용한다고 해서 모든 문제가 해결되는 것은 아니었습니다.예약 도메인에는 한 가지 까다로운 문제가 더 있었습니다.바로 "기준 시점이 하나가..

이전 포스팅에서는 관리자 대시 보드 개선이 단순한 UI 리뉴얼 작업이 아니었다는 이야기를 했습니다. (1) 관리자 대시보드 개선기: 화면 뒤에 숨어 있던 숫자의 문제안녕하세요 3년차 플랫폼 개발팀의 지팡구 입니다. 2026년 상반기는 무척 바쁘게 흘러갔습니다.속해 있는 개발팀에서는 인당 최소 2개의 프로젝트를 동시에 진행해야 상반기에 목표한 일정을 달jipang9-greedy-pot.tistory.com 겉으로 보기에는 카드, 그래프, 표를 새로 배치하는 작업처럼 보였지만 실제로는 훨씬 더 본질적인 문제가 있었습니다.바로 숫자의 신뢰성이었습니다.관리자 화면에서는 여러 지표가 함께 노출됩니다.예약 수매출 요약예약 추이매출 추이상위 판매 채널상위 판매 지역판매 제휴사 통계문제는 이 지표들이 서로 독립적인..

안녕하세요 3년차 플랫폼 개발팀의 지팡구 입니다. 2026년 상반기는 무척 바쁘게 흘러갔습니다.속해 있는 개발팀에서는 인당 최소 2개의 프로젝트를 동시에 진행해야 상반기에 목표한 일정을 달성할 수 있었습니다.오늘은 그 많은 프로젝트 중 하나였던 관리자 개선 작업에서 마주한 문제와 해결 과정을 나눠보려고 합니다.사내에는 제휴사, 업체 담당자, 플랫폼 담당자, CS 관리팀, 개발자 등 여러 직군이 함께 고객과 소통하고 도메인이 가진 문제를 해결하기 위해 사용하는 치열한 업무 공간이 있습니다. 바로 "관리자 백오피스" 입니다. 이 관리자 백오피스 시스템은 B2C부터 B2B까지 다양한 업무를 커버하고 있으며, 개발팀에서는 이 시스템을 관리자 ERP라고 부르고 있습니다.회사가 성장하고 서비스 규모가 커지면서 ..

코드를 이해하기 앞서 병렬처리는 무엇일까?병렬 처리(parallel Processing)동시에 동작하는 복수의 마이크로프로세스를 갖추고 있는 컴퓨터에 의해서만 실행될 수 있는 처리 방식모든처리 장치가 하나의 프로그램상의 서로 다른 작업을 **동시에 처리함으로 처리의 부하를 분담하여 처리 속도를 향상시키키는 방법(다중 처리(Multi Processing)와는 다른 방식)여러 개의 작업을 동시에 실행하여 처리 속도를 높이는 방법아주 간단한 예시 코드로 보는 처리 흐름일반적인 순차 처리(Sequential) = 줄 서서 일하기// CODEfor( element : elementList){ execute(element);}// DESCRIPTION시간 →0ms 200 400 600 800..

1. 개발 요구사항사용자 사용 하루 전 사전 이용 안내 알림 푸시 발송 기능 개발매일 19시 발송플랫폼 예약 및 특정 지역에 대해서만 발송 처리 진행실패 후처리 불필요2. 설계한 전체 아키텍쳐본 시스템은 두 단계의 실행 구조를 가짐1. 도메인 레벨에서는 순차적으로 실행하여 전체 시스템의 부하를 제어2. 각 도메인 내부에서는 데이터 단위로 병렬 처리를 수행하여 처리 성능을 확보이를 통해 과도한 병렬 실행으로 인한 시스템 부하를 방지하면서도,I/O 기반 작업의 처리 효율을 극대화하도록 설계[Trigger Layer] ↓[Orchestration Layer] ↓[Domain Layer] ↓[Concurrency Layer] ↓[External System][Jenkins / API Trigger..

Spring에서의 데이터 조회 방식과 JPQL DTO 바인딩 이슈Spring에서는 다양한 데이터 조회 방식을 지원합니다.일반적으로 많이 사용하는 방식은 다음과 같습니다.JPA (ORM 기반 엔티티 조회)JPQL (직접 쿼리 작성 후 DTO 바인딩)Interface-based ProjectionOpen Projection (SpEL 기반 표현식 활용)프로젝트 특성과 요구사항에 따라 위 방식들을 적절히 선택해 사용할 수 있습니다.현재 진행 중인 프로젝트에서는 JPA와 MyBatis를 함께 사용하고 있습니다.엔티티 객체를 직접 바인딩할 때는 JPA(ORM)를 주로 사용DTO와 같은 별도의 객체로 매핑할 때는 JPQL을 활용문제 상황JPQL을 통해 DTO로 데이터를 바인딩하던 중, 다음과 같은 런타임 에러가 발..

안녕하세요블로그 주인장 지팡구입니다. 다사다난한 2025년이 지나가고 2026년 병오년의 해가 밝았습니다.올해 저의 개발력은 벌써 해로는 4년차, 개월수로는 2년 10개월의 경력이 되었습니다. 오늘은 2025년도의 회고록을 작성해보고자 합니다.그럼 시작하겠습니다. 1月 ~ 3 月 : 찬바람이 칼바람으로 ChatGPT같은 AI 서비스가 더욱 상용화됨에 따라 개발자의 생산성에 많은 영향을 미치게 되었습니다. 이는 좋게 말하면 1의 개발자가 연차,직급 등의 영향을 많이 받지 않고 2의 개발자의 퍼포먼스를 낼 수 있는 시대가 왔고 이로 인해 2,3의 개발자가 할 일을 1의 개발자가 혼자서도 해낼 수 있게 되었습니다. 때문에 IT 회사가 많이 몰려있는 강남/역삼권에서 점심시간에 식당에서 귀를 열고 있으면 종종..

오늘 출/퇴근하며 유튜브의 쉬운코드 님의 채널 라이브 녹화방송을 보며 정리한 내용입니다. 먼저 쉬운코드님은 회사 문화에 관심이 많아 보이셨습니다. 주니어 시절에도, 현재에도 그리고 미래에도 관심이 많으실 것 같은데 쉬운 코드님이 라이브로 진행하시며 정리하신 내용을 출근하며 들으며 뭔가 가슴속에 울리는 그런 내용이 있고 제가 생각한 결과 같아 이렇게 정리해봅니다 그 중 가장 기억에 남는, 울림이 있는 내용만 한번 간단하게 정리해보겠습니다. 1. 사람을 리소스로 보지 않는 것 한분 한분이 소중하다, 서로를 존중하는 것이 중요하고 귀하게 여기자.2. 프로페셔널한 회사 더 나은 퀄리티 추구, 책임 의식,한계에 대한 인정 ,효율적인 시간 사용, 대표로서 책임의식프로젝트 일정산정 ㅡ 회사의 비즈니스 상황 때문에 ..