기술 블로그 모음

개발자들에게 익숙해진 불편함을 해결하기 위한 사내의 Swagger MCP 서버를 구축한 이야기를 들려드립니다.

20년간 유지되어 온 PG의 레거시 결제창 시스템을, 변화에 유연하게 진화할 수 있는 새로운 결제 시스템으로 재탄생시킨 여정을 공유합니다.

오늘은 범용 M 인스턴스 패밀리에 최근에 추가된 Amazon Elastic Compute Cloud(Amazon EC2) M8a 인스턴스의 출시를 발표합니다. 이 인스턴스는 최대 주파수가 4.5GHz인 5세대 AMD EPYC(코드명 Turin) 프로세서로 구동됩니다. 고객은 M7a 인스턴스에 비해 최대 30% 더 높은 성능과 최대 19% 개선된 가격 ...

Amazon Elastic Compute Cloud(Amazon EC2) 메모리 최적화 R8i 및 R8i-flex 인스턴스와 범용 M8i 및 M8i-flex 인스턴스를 출시한 후, AWS에서만 제공되는 맞춤형 Intel Xeon 6 프로세서 기반의 컴퓨팅 최적화 C8i 및 C8i-flex 인스턴스의 정식 출시를 발표하게 되어 기쁩니다. 이 인스턴스는 ...

오늘은 Amazon Elastic Container Service(Amazon ECS)의 새로운 컴퓨팅 옵션인 Amazon ECS Managed Instances를 발표합니다. 이 옵션을 사용하면 개발자들이 Amazon Elastic Compute Cloud(Amazon EC2)의 모든 기능을 사용하는 동시에 인프라 관리 책임을 Amazon Web S...

안녕하세요. 당근페이 오프라인 결제팀에서 백엔드 엔지니어로 일하고 있는 윈터(Winter.you)예요.저희 팀은 당근머니가 온라인을 넘어 오프라인에서도 자연스럽게 쓰일 수 있도록 만드는 일을 하고 있어요.이번 글에서는 저희가 7주 만에 준비했던 QR 기반 현장결제에 대해 소개하려고 해요. 여기서 말하는 현장결제란 오프라인 매장에서 당근머니나 포인트로 ...

토스페이먼츠 엔지니어들이 지난 몇 년 간 쏟아부은 치열한 고민과 노력을 기록한 시리즈를 소개합니다.

올리브영이 데이터의 품질을 높이기 위한 여정 "고객이 100원 상품을 클릭했는데 결제하고 보니 10,00…

안녕하세요. 저는 당근 피드실 피드 인프라팀에서 Software Engineer로 일하고 있는 Lebron이라고 해요.당근 피드는 당근 앱에 있는 다양한 콘텐츠를 모아서 하나의 리스트로 보여줘요. 사용자는 피드를 통해 중고거래, 구인 공고, 중고차, 부동산 등 자신에게 맞춤화된 정보를 한눈에 확인할 수 있어요. 이 피드시스템은 당근의 핵심 기능으로, ...

CDC를 Iceberg에 어떻게 안전하게 적재할 수 있는지에 초점을 맞춰, 우리가 마주했던 문제와 원칙들을 공유합니다.

오늘, 새로운 8세대 메모리 최적화 Amazon Elastic Compute Cloud(Amazon EC2) R8i 및 R8i-flex 인스턴스의 정식 출시를 발표합니다. 이 인스턴스는 AWS에서만 제공하는 맞춤형 Intel Xeon 6 프로세서로 구동됩니다. 동급 Intel 프로세서 중 가장 뛰어난 성능과 가장 빠른 메모리 대역폭을 클라우드에 제공합...

웹 프레임워크는 웹 서비스, 리소스, API를 포함한 웹 애플리케이션 개발을 지원하도록 설계된 소프트웨어 도구입니다. 일반적으로 모범 사례, 도구, 테스트 리소스, 라이브러리를 갖춘 완전한 패키지 형태로 제공되어 앱을 더 쉽게 개발할 수 있도록 돕습니다. 프레임워크는 명확한 구조를 제공하며, 일반적으로 널리 사용되는 MVC(모델-뷰-컨트롤러) 설계 패...

Python의 전역 인터프리터 잠금(GIL)이란? ‘전역 인터프리터 잠금'(또는 GIL)은 Python 커뮤니티에서는 익숙한 용어로, 잘 알려진 Python 작동 방식입니다. 그렇다면 GIL은 정확히 무엇일까요? 다른 프로그래밍 언어(예: Rust)를 사용해 본 적이 있다면 뮤텍스가 무엇인지 아실 겁니다. 뮤텍스는 ‘mutual ...

토스증권의 실시간 데이터 파이프라인을 대규모로 구성하고 운영해 온 경험을 소개합니다.

안녕하세요. 네이버페이에서 카드 BE 담당하고 있는 허수진입니다. 🙂저희 팀에서는 데이터베이스의 실제 저장 형태와 무관하게 애플리케이션에서 타입 안정성을 확보하면서 원하는 형식으로 데이터를 다루기 위해서 Spring Data JDBC에서 커스텀 컨버터를 사용하고 있습니다.e.g.DB에는 문자열로 저장되어 있지만 애플리케이션에서는 LocalDate로 다...

저희 팀에서는 Apache Spark를 기반으로 배치 및 실시간 처리를 수행하는 AI 데이터 파이프라인을 구축하고 있습니다. 그 과정에서 Spark의 마이크로 배치 아키텍처보다 더 효율적이고 생산적으로 실시간 데이터를 수집하고 집계하는 방법을 고민해왔습니다. 이 글에서는 Apache Flink와 Apache Paimon을 도입하여 빠르고 안정적인 데이...

안녕하세요! 동네생활팀 프론트엔드 엔지니어 인턴 링커(Linker)예요. 저희 팀은 동네 정보와 이야기를 자유롭게 나누는 커뮤니티, 동네생활을 만들고 있어요.동네생활은 모바일 기기 성능이 좋지 않거나 웹뷰 로딩이 느린 환경에서도 사용자에게 원활한 경험을 제공하기 위해 Streaming SSR*을 도입했어요. 이런 구조에서 디버깅을 수월하게 하기 위해 ...

네이버 사내 기술 교류 행사인 NAVER ENGINEERING DAY 2025(5월)에서 발표되었던 세션을 공개합니다. 발표 내용 이 세션에서는 BERT기반 모델인 SPLADE모델의 대규모 실시간 서비스를 위한 최적화 방법에 대해서 이야기 합니다. 세상에서 가장 빠른 BertTokenizer 구현체인 FlashTokenizer 의 개발 배경과 성능에 ...

NGINX Socket Reverse Proxy 구성 현대의 웹 애플리케이션은 단순한 요청-응답 패턴을 넘어, 실시간 데이터 통신을 요구하는 다양한 기능들을 필요로 합니다. 대표적으로 채팅 서비스, 실시간 알림, 스트리밍 등이 그 예입니다. 이러한 실시간 통신을 가능하게 하는 기술 중 하나가 Socket입니다. 본 문서에서는 Socket의 개념부터 시...

오늘 AWS AppSync Events가 이제 채널 네임스페이스에 대한 데이터 소스 통합을 지원하게 되었다는 소식을 알려드립니다. 이로써 개발자 여러분은 앞으로 더 정교한 실시간 애플리케이션을 제작할 수 있게 됩니다. 이 새 기능을 통해 AWS Lambda 함수, Amazon DynamoDB 테이블, Amazon Aurora 데이터베이스 및 기타 데이...

오늘은 BESPIN GLOBAL AIX실 전희연님이 작성해주신 'Springboot 구동시 AWS Secret을 조회하여 Datasource 생성'에 대해 소개해드리도록 하겠습니다. The post Springboot 구동시 AWS Secret을 조회하여 Datasource 생성 appeared first on BESPIN Tech Blog.

오늘은 AWS WAF의 AWS Amplify Hosting 통합 정식 출시 소식을 알려드립니다. 웹 애플리케이션 소유자는 다양한 위협으로부터 애플리케이션을 보호하기 위해 끊임없이 노력 중입니다. 이전에는 Amplify Hosting으로 호스팅되는 애플리케이션에 강력한 보안 태세를 구현하려면 AWS WAF 보호가 지원되는 Amazon CloudFront...

안녕하세요. 당근 알림 경험팀에서 프론트엔드 엔지니어로 일하고 있는 딜런(Dylan.lee)이라고 해요.알림 경험팀은 당근 사용자들뿐만 아니라 당근 구성원들의 알림 경험(Notification Experiences)을 책임져요. 사용자가 그동안 받은 알림을 모아볼 수 있는 알림함부터 당근 구성원이 알림을 간편하게 발송할 수 있는 알림 센터까지, 알림과...

If you’re using Kotlin for server-side development and sharing your experiences – whether through blog posts, videos, or sample projects – know that we see you, and we want to highlight your ...

PHP는 여전히 웹 개발의 중추로, 전 세계 수백만 개 웹사이트의 기반입니다. 활기차고 헌신적인 PHP 커뮤니티는 PHP의 유연성과 사용 편의성에 큰 가치를 둡니다. 그런데 PHP 개발의 현황은 어떨까요? 에코시스템을 형성하는 더 심층적인 인사이트와 추세를 알아보기 위해 JetBrains의 사내 전문가인 PHP 개발자 애드버킷 Brent Roose에게...

안녕하세요. Azar API Dev Team의 Ledger입니다. 이번 글에서는 Spring Transactional 동작에서 Checked Exception과 Unchecked Exception의 롤백(rollback) 처리에 관한 내용을 다뤄보겠습니다. 여러 사례를 통해 예외 처리 코드를 작성해 보고, 자주 혼동되는 부분들을 정리해 보았습니다. 그...

안녕하세요. 저는 당근페이 머니서비스팀 백엔드 엔지니어 클로버(Clover)에요! 당근페이에서는 동네에서 쉽고 편하게 쓸 수 있는 금융 서비스를 만들고 있어요. 당근에서 일어나는 거래에는 당근머니가 사용되는데요. 머니서비스팀에서는 당근머니와 관련된 일들에 더해, 동네에서 쓰면 다양한 혜택이 적립되는 당근카드와 관련된 일들을 하고 있어요. 다시 말해 저희 팀은 지역에서 생기는 다양한 거래를 연결하는 게 목표예요!재무 결산의 중요성당근페이에서는 매월 셀 수 없이 많은 거래가 이루어지는데요. 매월 이 거래들을 바탕으로 당근페이 내에서 돈이 어떤 경우에 어디에서 어디로 흘러갔는지 재무 결산을 진행해요. 예를 들면 당근머니를 충전하면 사용자의 계좌에서 당근페이 모계좌로 돈이 이동하는데, 당근머니 충전액의 총합은 모계좌 입금액의 총합과 같아야 해요. 재무 결산을 했는데 단 1원이라도 맞지 않는다면 그 1원을 찾기 위해 모든 업무를 중단해야 해요. 그만큼 핀테크 회사인 당근페이에서는 재무 결산이 중요해요.당근페이 초기에는 거래량이나 거래 종류가 많지 않았기 때문에 데이터를 직접 SQL 쿼리로 뽑았었어요. 그러다가 당근페이가 커지면서…결산 어드민 도입 전 머니 결산 스레드위와 같이 매월 초에 열리는 머니 결산 스레드에서, 백엔드 엔지니어들이 태그되기 시작했어요. 머니서비스팀에 도메인 담당자가 많아질수록 매월 결산 슬랙 스레드에 태그되는 사람도 점점 많아졌죠. 결국 머니서비스팀 백엔드 개발자들은 매월 첫 주에는 정기적으로 코드가 아닌 SQL 쿼리를 치고 있는 상황이 일어났어요.이런 비효율을 어떻게 개선해 볼 수 있을까요? 모두가 SQL 쿼리를 더 정확하고 빠르게 작성하도록 SQLD 자격증 스터디를 열어볼 수도 있을 듯해요. 하지만 저희 팀에서는 이를 시스템적으로 개선해보고자 했어요.Spring Batch와 MySQL기반 결산가장 쉽게 떠오르는 방법은 스프링 배치를 이용하는 방법이에요. 대용량 데이터를 처리할 때 가장 흔하게 사용하는 기술이죠. 처음에는 저희 팀도 이 방법으로 결산을 진행했어요. 대략적인 구조는 다음과 같았어요.당근페이 머니서비스팀은 마이크로서비스로 컴포넌트들이 구성돼 있어서, 각자 다른 데이터베이스를 가지고 있어요. 여러 데이터들을 종합해서 진행하는 결산의 특성상, 배치는 여러 개의 데이터베이스를 바라보고 진행해요.이러한 결산은 크게 두 단계로 구성돼 있어요.원본 DB에서 성공 거래를 바탕으로 원장(raw data)을 구성해 결산 전용 DB에 밀어 넣기위에서 가져온 원장을 기반으로 집계해 일별 결산 리포트를 만들고 결산 전용 DB에 쌓기이런 단계별로 구성된 배치를 매일 00시에 Cron을 통해 트리거해요. 재무 담당자나 결산 이해관계자들은 이렇게 단계별, 일자별로 잘 집계된 데이터들을 스프링 기반 백엔드 및 결산 프론트 화면을 통해 언제든지 조회할 수 있어요. 여기까지는 괜찮은 것 같아요. 그러던 어느 날 문제를 마주했죠.구조의 한계배치 실패 알림 발생어느 날 갑자기 이런 배치 작업 실패 알림을 받게 됐어요. 보통 이렇게 결산 배치를 실패하는 이유는 크게 세 가지가 있어요.결산 코드 비즈니스 로직 상의 문제로 인한 실패원본 테이블 구조(혹은 필드 ENUM 타입) 변경으로 인한 실패인프라나 애플리케이션 자체(JVM, DB 커넥션 등)의 이슈로 인한 실패여기서 첫 번째와 두 번째 이슈가 가장 잦으면서도 중요한 이슈라 조금 더 구체적으로 예시를 들어볼게요. 예를 들어, 당근페이가 “당근머니 송금” 기능만을 제공하다가, “당근머니 결제”라는 기능을 추가적으로 오픈했다고 가정할게요. 이때 당근머니 DB에는 “송금”이라는 거래 타입뿐만 아니라 “결제”라는 거래 타입도 추가될 거예요. 게다가 기존의 “송금”은 단순히 사용자 간의 지갑 잔액이 변한다면, “결제”는 지갑 잔액 변동과 함께 외부로의 정산이 발생해요. 이 경우 테이블 구조뿐만 아니라 결산에 대한 비즈니스 로직도 변경될 수 있어요.물론 당근머니만을 대상으로 결산한다면 이는 큰 문제는 아닐 거예요. 당근머니와 관련된 기능이 추가될 때마다 결산에도 추가적으로 대응하면 되니까요. 하지만 당근페이에서의 결산은 당근머니, 은행 거래, 카드 거래 등 다양한 서비스를 기반으로 진행하게 돼요. 그리고 각 서비스들은 결산에서 긴밀하게 얽혀 있죠. 결국 결산은 언제든 깨질 수 있는, 테이블 끝에 걸친 유리잔이 됐어요. 각 서비스들에 새로운 기능이 생길수록 작은 변화가 결산에 큰 영향을 미치게 되고, 결국 결산 오류가 더 자주 발생하게 된 거예요.이외에도 다른 서비스 컴포넌트에서 기능이 추가될 때 대응이 복잡하다는 문제가 있어요. 결산이 하는 일은 거래들을 일자별로 모아서 더하고 빼는 것뿐이지만, 새 기능이 도입될 때마다 결산에 추가적으로 코틀린 ENUM 타입을 추가하고 코드를 작성해야 하는 건 굉장히 비효율적이죠. 모든 팀원들이 결산의 내부 동작 구조를 이해하고 있는 건 아니니까요.위의 문제를 해결할 수 있는 방법은 없을까요? 조금 더 엄밀히 말하면 테이블 변경이나 비즈니스 로직 변경에 좀 더 유연하게 대응하려면 어떻게 해야 할까요?Airflow와 dbt를 활용한 데이터 기반 결산Airflow와 dbt는 백엔드 개발자에게는 조금은 생소한 개념일 수도 있는데요. 우선 Airflow는 초기에 Airbnb에서 개발한 작업(워크플로)을 코드를 통해 작성하고, 스케쥴링하고, 모니터링할 수 있는 플랫폼이에요.dbt는 원시 데이터(raw data)를 분석 가능한 형태의 데이터로 변환하고, 데이터 중심의 결정을 내리도록 돕는 프레임워크예요. dbt는 Airflow 위에서 실행되면서, 미리 작성해 둔 SQL 쿼리를 바탕으로 데이터를 가공해요. 쿼리 결과에 맞는 형태로 테이블이나 뷰를 만들어주는 툴이라고 볼 수 있어요.기존 구조였던 Spring Batch와 MySQL 기반 결산과 대조되는 개념들로 이해하면 더 쉽게 이해할 수 있어요. 기존의 원장 데이터와 집계된 데이터를 저장하던 MySQL 데이터베이스는 데이터 웨어하우스가 되었고, Argo Workflow가 해주던 작업 스케쥴링은 이제 Airflow가 담당해요. 데이터 변환과 집계 로직을 담고 있던 Spring Batch는 dbt가 대신하게 됐고요!가장 큰 변화는 각 서비스 컴포넌트의 DB 구조를 이해하고 직접 집계해야 했던 기존 결산 구조에서 벗어났어요. dbt를 통해 각 서비스가 오너십을 가지고 집계 쿼리를 작성하고, 결산 서비스는 잘 집계된 데이터를 분류에 맞게 시각화하는 기능을 제공하게 됐어요. 이제 더 이상 각 컴포넌트의 기능 추가로 인해 결산 집계가 실패하는 일은 없어졌어요.큰 그림 말고, 이제 조금 더 깊게 살펴볼까요?dbt 스키마 구조위에서 기존 MySQL 기반 결산을 소개하면서, 결산은 크게 두 단계로 나뉜다고 설명드렸어요. 먼저 거래 원장을 구성하고, 원장을 바탕으로 결산 집계 작업을 진행하죠. 실제 재무 결산에서는 집계된 데이터를 보고 진행하지만, 혹여 결산 과정에서 틀어지거나 올바르지 않은 데이터가 있을 때를 교차검증하기 위해 원장 테이블이 존재해요.예를 들어, “프로모션 지급” 거래의 원장은 다음과 같은 쿼리를 통해 성공한 거래 내역을 추출해요.-- promotion_ledger.sql (프로모션 지급 거래 원장)SELECT 거래ID, 거래타입, 거래금액, 생성일시FROM 거래내역WHERE 거래타입 = '프로모션' AND 거래상태 = '성공'# dbt YAMLmodels: - name: promotion_ledger description: 프로모션 지급 거래 원장 columns: - name: 거래금액 description: 거래에서 발생한 금액 (실제 지급된 금액) data_tests: - not_null - dbt_utils.expression_is_true: expression: "> 0"이러한 형태로 추출된 dbt 스키마는 거래타입별로 존재해요. 모든 거래 타입의 거래 원장을 하나의 스키마로 관리하지 않는 이유는 실제 재무실 니즈에 조금 더 유연하게 대응하기 위함인데요. 예를 들면 같은 “프로모션” 거래타입 일지라도, 당근페이 내에서 진행한 프로모션이 있을 수도 있고 다른 서비스에서 진행한 프로모션이 있을 수 있어요. 원장을 거래타입별로 구분하면서 이러한 구체적인 거래 분기에 조금 더 유연하게 대응할 수 있게 되었어요.data_tests: - not_null - dbt_utils.expression_is_true: expression: "> 0"그리고 이 표현처럼 특정 필드의 값을 테스트할 수 있게 됐어요. 위 경우에서는 거래 금액이 null이 아니고 0보다 커야 함을 테스트하는 표현이에요. 데이터 변환과 함께 원장 데이터의 무결성도 함께 검증할 수 있게 된 셈이에요.이렇게 수집된 원장을 기반으로 다음과 같이 일별 집계를 진행해요.-- daily_report.sql (일별 결산 집계)WITH -- 프로모션 지급daily_promotion AS ( SELECT DATE(생성일시) AS 대상날짜, 거래타입, SUM(거래금액) AS 총거래금액 FROM {{ ref('promotion_ledger') }} GROUP BY 1, 2),-- 머니송금daily_transfer AS ( SELECT DATE(생성일시) AS 대상날짜, 거래타입, SUM(거래금액) AS 총거래금액 FROM {{ ref('transfer_ledger') }} GROUP BY 1, 2)...SELECT * FROM daily_promotionUNION ALLSELECT * FROM daily_transfer...# DBT YAMLmodels: - name: daily_report description: 일별 결산 집계 columns: - name: 총거래금액 description: 일별 거래에서 발생한 총 금액 data_tests: - not_null - dbt_utils.expression_is_true: expression: "> 0"앞서 수집했던 원장 스키마를 바탕으로 일별 거래타입별 거래액을 집계해요. 집계 결과도 마찬가지로 상황에 맞게 테스트를 진행해요.결국 이렇게 정의된 SQL과 dbt YAML들을 바탕으로 Airflow는 dbt Task를 실행시켜 주고, 이 Task는 결국 필요한 데이터를 데이터 웨어하우스에 밀어 넣어줘요. 그렇다면 이 데이터는 어떻게 기존 결산 어드민처럼 재무팀분들에게 보여줄 수 있을까요? 재무팀분들께 DW 접근 권한을 드려야 할까요?Spring Boot에 데이터 웨어하우스 연결하기현재 당근페이에서 사용하고 있는 데이터 웨어하우스는 Redshift인데요. 놀랍게도 Redshift(정확히는 AWS)에서 JDBC 드라이버를 제공하고 있어요. JDBC 드라이버가 존재한다는 것은 Spring Data JPA를 그대로 활용할 수 있다는 것을 의미해요. 결국 실제 백엔드에 새로운 쿼리 전용 라이브러리를 도입할 필요 없이, 기존 기술 스택 그대로 새로운 Airflow와 dbt 기반 결산 데이터를 조회할 수 있게 됐어요.우선 다음과 같이 Gradle에 RedShift JDBC 드라이버를 추가하고,dependencies { runtimeOnly("org.hibernate.orm:hibernate-community-dialects:6.4.4.Final") runtimeOnly("com.amazon.redshift:redshift-jdbc42:2.1.0.30")}다음과 같이 driver-class-name 과 database-platform 값, 그리고 RedShift 접근 정보를 채워주면 돼요.spring: jpa: driver-class-name: com.amazon.redshift.jdbc.Driver database-platform: org.hibernate.community.dialect.PostgreSQLLegacyDialect datasource: url: jdbc:redshift://{DB_HOSTNAME}:{DB_PORT}/{DB_DATABASE} username: {DB_USERNAME} password: {DB_PASSWORD}기존에 Spring Boot 2.x 에서는 Hibernate에 내장된 Dialect인 org.hibernate.dialect.PostgreSQL9Dialect를 사용할 수 있었지만, Spring Boot 3.x에서 해당 클래스가 사라지면서 org.hibernate.community.dialect.PostgreSQLLegacyDialect 로 지정해야 해요.그 외에는 기존 Spring Boot JPA와 똑같아요. 다음과 같이 Entity를 정의하고 쓰면 돼요. (대신 애플리케이션에서 업데이트하는 것을 방지하기 위해 @Immutable 어노테이션을 추가했어요.)@IdClass(DailyReportEntity.DailyReportEntityKey::class)@Immutable@Entity@Table(name = "daily_report")abstract class DailyReportEntity( @Id @Column(name = "대상날짜", nullable = false) val targetDate: LocalDate = LocalDate.now(), @Id @Column(name = "거래타입", nullable = false) val transactionType: String = "", @Column(name = "총거래금액", nullable = false) val totalAmount: Long = 0L,) { data class DailyReportEntityKey( val targetDate: LocalDate = LocalDate.now(), val transactionType: String = "", ) : Serializable}그 외에 다른 로직들은 기존 Spring JPA 사용법과 전부 동일해요. 다시 말해 과거에 Spring Batch와 MySQL기반으로 결산 데이터를 모으고 쌓는 부분만 Airflow로 이전하고, 그 외의 결산 결과를 확인하던 대시보드와 조회 로직은 그대로 사용할 수 있었어요. 덤으로 기존 MySQL로 되어있던 결산 데이터베이스는 필요 없어졌고요!최종 결산 아키텍처 구조는 다음과 같아요.(데이터팀분들이 구축해 주신 부분) 매 시간마다 운영(Reader 인스턴스) MySQL 데이터베이스에서 Spark를 통해 데이터 웨어하우스로 테이블이 싱크돼요.매일 Airflow는 dbt를 통해 결산에 필요한 원장과 일별 집계 데이터를 테이블로 가공해요.재무 담당자분들은 결산 어드민 프론트 화면을 통해서 데이터 웨어하우스에 적재된 결산 데이터를 볼 수 있어요.이루어낸 성과우선 기존 Spring Batch와 MySQL 기반 결산의 한계였던 구조적 복잡성을 해결했어요. 덕분에 머니서비스팀 내의 백엔드 개발자분들이 각자가 개발한 기능에 대한 결산 대응을 SQL 쿼리 수정만으로 쉽게 해결할 수 있게 됐죠.이는 단순히 작업자의 접근성을 끌어올려줬을 뿐만 아니라, 실제 결산 시 기능 추가 과정에서 필요한 작업들을 효과적으로 줄이기까지 했어요. 이제 더 이상 애플리케이션에서 각 타입을 알고 계산 로직을 추가해야 하는 게 아니라 SQL 쿼리에서만 대응하면 되니까요![Before]Spring Batch + MySQL 아키텍쳐에서 결산 로직 변경시 사례[After]Airflow + dbt 아키텍쳐에서 결산 로직 변경시 사례확실히 기존에 코틀린 코드로 존재하던 결산을 SQL 쿼리로 변경하니 수정 사항을 변경하는 게 간단해지기도 하고 가시성도 높아졌죠?마치며현대 사회에서 데이터의 가치는 회사의 중요한 자산과 경쟁력이 되고 있어요. 특히 당근페이와 같은 핀테크 기업에서 이러한 데이터의 정합성과 투명성은 사용자들의 신뢰를 구축하기 위한 핵심 요소예요. 위 사례에서 살펴본 데이터 기반 결산 아키텍처로의 변화는 단순한 결산 과정 비효율 개선을 넘어서, 장기적으로 당근페이 내 구성원들이 데이터 기반의 의사결정과 소통을 할 수 있도록 도와요. 결국 이를 통해 사용자에게 더 나은 서비스를 제공하는 데 기여할 수 있을 거예요.따라서 당근페이에서는 데이터 중심적 사고를 백엔드 엔지니어에게도 중요한 역량으로 인식해요. 당근페이의 백엔드 엔지니어들은 단순히 코드를 작성하는 것을 넘어, 데이터의 정합성과 무결성을 보장하기 위해 위의 Airflow 같은 다양한 데이터 중심의 아키텍처를 탐구하죠. 또한 데이터 중심적 사고방식을 확산하려고 노력하고 있기도 해요. 조직 전체가 데이터를 적극적으로 이해하고 활용하려는 문화가 정착되면서, 모두가 데이터에 기반해 더 나은 의사결정을 할 수 있도록 변화하고 있어요.지역의 다양한 거래를 연결한다는 팀의 비전을 위해 비효율적인 부분을 개선하고 데이터 관점에서도 끝없이 고민하는 머니서비스팀! 저희 팀이나 오늘의 이야기에 대해 궁금하신 게 있다면 clover@daangnpay.com 으로 연락 주세요! 사소한 궁금증도 괜찮아요 ✌️또 현재 머니서비스팀에선 기술의 장벽 없이 비효율적인 부분을 개선하고 다양한 문제를 해결해 나갈 백엔드 엔지니어도 채용하고 있으니 많은 관심 부탁드려요!https://about.daangn.com/jobs/4511184003/참조[1] https://airflow.apache.org/[2] https://www.getdbt.com/product/what-is-dbt당근페이 재무 결산 사례로 보는 백엔드와 데이터의 만남 was originally published in 당근 테크 블로그 on Medium, where people are continuing the conversation by highlighting and responding to this story.

👉 들어가기에 앞서 안녕하세요! 올리브영에서 상품 도메인을 책임지고 있는 윤긱스입니다. 혹시 지금.. 이런 고민을 하고 계신가요? 🙋 : MongoDB…

자바 모듈 시스템의 변화로 인한 직렬화 문제를 분석하면서 알게된 내용을 공유합니다.

…