AB180

RSS

게시글: 43
등록: 2026년부터

All Frontend Backend AI DevOps Architecture Etc

AI
AI 에이전트와 함께하는 개발
이 글은 AI 에이전트와 함께 개발하는 경험을 공유하며, AI 기반 개발 보조 도구의 발전과 활용 방안을 탐구합니다. 필자는 과거 GitHub Copilot을 사용하며 AI 도구에 대한 회의적인 시각을 가지고 있었으나, Claude Code를 직접 사용하며 생각이 변화했습니다. AI 에이전트는 낯선 코드베이스 탐색, 웹 크롤러 작성, 언어 마이그레이션 문서화 등 다양한 개발 작업에서 생산성을 향상시키는 데 도움을 주었습니다. 특히, 코드 분석 및 맥락 파악 시간을 단축하고, 익숙하지 않은 분야에 대한 접근성을 높여 개발자가 더 효율적으로 작업할 수 있도록 지원합니다. AI 에이전트의 한계점도 언급하며, 이를 극복하고 더 잘 활용하기 위한 방법을 모색합니다.
AI 코딩 에이전트CopilotClaude Code
AB180·2025년 10월 7일
Backend
인증 서버 응답 속도 최적화
본 글은 Airbridge 인증 서버에서 발생한 간헐적인 응답 속도 지연 문제를 해결한 경험을 공유합니다. 인증 서버는 모든 API 요청 처리 전 토큰 검증 및 권한 확인을 담당하며, 그 성능은 전체 서비스 안정성에 직접적인 영향을 미칩니다. 모니터링 결과 응답 지연 알림이 빈번해지자 원인 분석에 착수했습니다. 인프라 및 JVM 단에서는 이상 징후가 발견되지 않았으나, 인증 서버 내부 로직 분석 결과 과다한 DB 쿼리 발생과 이로 인한 HikariCP Connection Pool 포화 현상을 발견했습니다. 특히 권한 확인 과정에서 요청 복잡도에 따라 DB 쿼리가 100회 이상 실행되어 DB 커넥션 풀이 빠르게 소진되었고, 이로 인해 스레드가 응답 대기 상태에 빠지는 문제가 확인되었습니다. 이러한 문제점을 개선하여 간헐적인 응답 지연을 해결하고 트래픽 급증에도 안정적인 인증 시스템을 구축했습니다.
인증 서버응답 속도최적화
AB180·2025년 8월 26일
DevOps
AB180 개발팀의 AWS 비용 관리 여정: 청구서 확인부터 Fin Ops 문화까지
마테크 스타트업 AB180은 데이터 처리량이 많은 서비스 특성상 AWS 비용 관리에 어려움을 겪었으나, 체계적인 관리 시스템 구축을 통해 비용 절감 노하우를 공유합니다. 초기에는 비용 관리보다 성장에 집중했지만, 데이터 트래픽 증가로 비용 지출이 늘어나면서 비용 관리의 중요성을 인지했습니다. 인터넷 검색만으로는 얻기 힘든 노하우를 바탕으로, 구글 시트를 활용한 비용 대시보드 구축, 태그 전략 수립, 정기적인 FinOps 미팅 운영 등 비용 관리 문화를 만들어온 과정을 상세히 설명합니다. 이 글은 AB180 팀이 겪은 시행착오와 5가지 핵심 교훈을 통해 다른 팀에게 실질적인 도움을 주고자 하며, 더 나은 비용 관리 방법 공유를 장려합니다.
AWS비용 관리FinOps
AB180·2025년 6월 30일
Etc
주니어 개발자의 시작: AB180에서 배운 엔지니어링 문화 (AB180 인턴 후기)
AB180에서 백엔드 개발자로 인턴을 시작하여 정규직으로 전환되기까지의 경험을 회고하는 글입니다. 필자는 ICT 학점 연계 인턴십 프로그램을 통해 AB180에 합류하여 데이터 파이프라인 팀에서 매체 연동 관련 업무를 수행했습니다. 이 과정에서 단순 쿼리 수정부터 시작하여 티켓 전체를 설계, 구현, 배포하는 경험을 쌓으며 주니어 개발자로서 성장했습니다. 특히, AB180의 엔지니어링 문화 중 '커뮤니케이션'과 '더 나은 설계'를 추구하는 점을 강조합니다. 동료들과 맥락과 의도를 담아 소통하는 습관, 업무 요청 및 의사 결정 시 배경과 근거를 명확히 공유하는 방식, 그리고 '왜 이렇게 설계했는지' 질문하며 더 나은 구조를 탐구하는 문화가 필자의 사고방식을 변화시키는 데 큰 영향을 미쳤다고 말합니다. 이러한 경험을 통해 필자는 협업과 자기 성장에 도움이 되는 실무적인 인사이트를 얻었음을 공유합니다.
인턴회고엔지니어링 문화
AB180·2025년 4월 7일
Backend
좋은 개발자로 가는 길목에서 – AB180에서의 성장기 (AB180 인턴 후기)
AB180에서 6개월간 인턴십을 수행하며 경험한 성장 과정을 회고하는 글입니다. 필자는 마케팅 솔루션 기업 AB180의 Data Pipeline 조직에서 비용 연동 시스템과 대시보드 백엔드 API 개발을 담당했습니다. 특히, Airflow 기반의 대규모 배치 작업에서 발생하는 약 1억 4천만 건의 광고 비용 데이터를 효율적으로 처리하고 데이터 정합성을 확보하기 위한 테스트 자동화 프로세스 개선 경험을 상세히 다룹니다. 기존의 번거롭고 시간 소모적인 테스트 방식을 개선하여 개발 생산성을 높이고 API 호출 제한 문제를 해결한 사례를 통해, 대규모 데이터 처리 시스템의 안정성과 효율성을 높이는 중요성을 강조합니다.
Airflow데이터베이스API
AB180·2025년 4월 7일
DevOps
Luft's Road to Elasticity - Part 2: Auto-Scaling with Query History
이 글은 자체 개발 OLAP 데이터베이스인 Luft의 탄력성을 개선하기 위한 경험을 공유합니다. 이전 글에서 Shared Storage 아키텍처로 전환하여 탄력성을 높인 후, 본 글에서는 쿼리 히스토리를 활용한 비용 기반 오토스케일러 구현에 초점을 맞춥니다. 목표는 오버프로비저닝 없이 클러스터를 운영하며, 쿼리 시점에 부하를 예측하여 필요한 만큼만 스케일링하는 것입니다. 이를 위해 빠른 스케일링을 위한 클러스터 매니저와 정확한 스케일링 결정을 위한 비용 기반 오토스케일러를 구현했습니다. 클러스터 매니저는 Kubernetes의 Go 클라이언트를 사용하여 스케일링을 트리거하고, Karpenter가 실제 스케일링을 처리합니다.
Luft오토스케일링쿼리 히스토리
AB180·2025년 3월 16일
Architecture
Luft's Road to Elasticity - Part 1: From Shared Nothing to Shared Storage
이 글은 자체 제작 OLAP 데이터베이스인 Luft의 탄력성(elasticity)을 개선하기 위한 여정의 첫 번째 이야기입니다. AB180에서 사용자 행동 분석 및 리포트 제공에 사용되는 Luft는 기존에 Shared Nothing 아키텍처를 기반으로 로컬 스토리지(AWS EBS 또는 Instance Store)와 딥 스토리지(AWS S3)를 활용했습니다. Shared Nothing 아키텍처는 병목 현상과 SPOF를 최소화하여 높은 확장성과 가용성을 제공하는 장점이 있습니다. 본문에서는 이 아키텍처에서 S3에 직접 쿼리가 가능하도록 개선하는 과정의 배경과 Shared Nothing 아키텍처의 특징을 설명합니다. 다음 글에서는 Shared Storage 아키텍처로의 전환 경험을 다룰 예정입니다.
Luft데이터베이스Shared Nothing
AB180·2025년 3월 6일
DevOps
Github Ops 로 Mono Repo 배포를 더욱 쉽게
이 글은 Mono Repo 환경에서 Github Actions를 활용하여 컴포넌트 배포를 효율화하는 방법을 다룹니다. 여러 컴포넌트를 하나의 Git 저장소에서 관리할 때 발생하는 문제점, 특히 변경이 드문 컴포넌트의 유지보수 어려움과 오래된 CI/CD 파이프라인 문제를 해결하기 위한 방안을 모색합니다. Git 브랜치를 이용한 기본적인 배포 방식의 장단점을 분석하고, Mono Repo 환경에 적용 시 변경된 코드에 따라 필요한 컴포넌트만 배포하는 방식을 제안합니다. 이를 통해 배포 경험을 통일하고 더 나은 배포 Practice를 탐색하는 과정을 공유합니다.
모노레포GitHub ActionsCI/CD
AB180·2024년 12월 17일
DevOps
AWS Lambda 를 활용한 Luft 스케일링
이 글은 OLAP 데이터베이스인 Luft의 유동적인 워크로드 특성으로 인해 발생하는 리소스 낭비 및 부족 문제를 해결하기 위해 AWS Lambda를 활용한 스케일링 POC(Proof of Concept) 과정을 다룹니다. 기존 EC2 기반 스케일링은 확장 속도가 느려 요구사항을 충족시키기 어려웠지만, 서버리스 컴퓨팅 서비스인 AWS Lambda는 빠른 시간 내에 대규모 확장이 가능하여 부하 집중 시간에만 클러스터를 신속하게 확장하는 데 유리합니다. Luft의 쿼리 처리 과정을 스테이지별(Scan, Group by user, Aggregate)로 나누어 설명하고, 각 스테이지가 노드에 분산 실행되는 구조를 보여주며, Lambda를 통한 효율적인 스케일링 방안을 모색합니다. 이를 통해 사용자 경험 개선과 비용 절감을 기대합니다.
AWS LambdaLuft스케줄링
AB180·2024년 6월 18일
Backend
동일한 비용으로 리포트 요청 10배 처리하기
이 글은 Airbridge의 Actuals Report API 사용량 증가로 인한 비용 상승 문제를 해결하기 위한 개선 과정을 공유합니다. 새로운 Overview Dashboard 출시로 인해 Report API 요청이 급증했고, 이를 처리하기 위해 Worker 수를 5배 늘리면서 비용도 5배 증가했습니다. 저자는 이러한 비용 증가 구조의 비효율성을 인지하고, 데이터 처리 과정의 병목 지점을 파악하여 비용 효율적인 개선 방안을 모색합니다. 구체적인 개선 방법과 결과는 본문에서 더 자세히 다뤄질 것으로 예상됩니다.
Report API비용 절감성능 개선
AB180·2024년 3월 3일
Backend
Luft 성능 리포트 2: 더 많은 코호트에 대한 리텐션 집계
본 글은 Airbridge의 리텐션 리포트에서 제공하는 스타트 이벤트 설정의 한계를 극복하고, 더 많은 코호트에 대한 리텐션 집계를 가능하게 하기 위한 Luft의 성능 개선 과정을 다룹니다. 기존에는 Install, Deeplink Open, Deeplink Pageview로 한정되었던 스타트 이벤트 설정을 확장하여 다양한 사용자 요구사항을 만족시키고자 합니다. 하지만 현재 Luft의 쿼리 성능으로는 더 많은 사용자 데이터를 처리하기 어렵고, 비용 효율적인 확장이 현실적으로 어렵다는 문제가 제기됩니다. 이에 따라 성능 개선이 필요한 두 가지 주요 쿼리(스타트 이벤트 Open, 1개월 일단위 리텐션 및 스타트 이벤트 Open, 3일 분단위 리텐션)를 선정하고, 리텐션 집계의 5단계(Scan, User grouping, User aggregation, Local aggregation reduction 등) 동작 방식을 설명하며 성능 개선의 필요성을 강조합니다.
리텐션쿼리 성능데이터 집계
AB180·2024년 2월 11일
DevOps
모니터링은 마틴 파울러처럼: Domain-Oriented Observability 도입기
이 글은 빠르게 변화하는 환경에서도 모니터링 코드가 비즈니스 로직을 복잡하게 만들지 않도록 하기 위해 마틴 파울러가 제안한 'Domain-Oriented Observability(DOO)' 개념을 도입한 경험을 공유합니다. 기존에는 시스템 인프라 메트릭과 애플리케이션 로그/메트릭 수집을 분리하여 관리했지만, 특히 비용 연동 시스템과 같이 외부 API 연동이 잦은 경우 에러 처리를 위한 모니터링 코드 추가 시 비즈니스 로직과 테스트 코드에 영향을 미치는 문제가 있었습니다. DOO는 이러한 문제를 해결하기 위해 도메인 관점에서 모니터링을 설계하고 구현하는 접근 방식으로, 비즈니스 로직을 방해하지 않으면서도 테스트하기 좋은 코드를 작성할 수 있게 돕습니다. 글에서는 DOO 도입을 통해 모니터링 코드의 개선과 테스트 안정성 확보 경험을 상세히 다룹니다.
모니터링ObservabilityDomain-Oriented Observability
AB180·2023년 11월 23일
Backend
제안서: Luft 의 대형 쿼리 처리에 관하여
Luft 데이터베이스 시스템에서 발생하는 특수한 대형 쿼리 처리 문제를 해결하기 위한 제안서입니다. 현재 시스템은 복잡한 OLAP 워크로드를 효율적으로 처리하지만, 특수한 대형 쿼리에 대해서는 리소스 할당 및 최적화에 어려움을 겪고 있습니다. 제안 내용은 고도화된 쿼리 옵티마이저와 리소스 스케줄링 메커니즘 도입입니다. 쿼리 옵티마이저는 최적의 실행 계획을 수립하고 리소스 필요 여부를 사전에 판단하며, 리소스 스케일러는 이에 따라 순간적으로 대량의 리소스를 할당합니다. 이를 통해 리소스 낭비와 사용자 경험 저하를 방지하고, 오버 프로비저닝 없이 특정 쿼리에 특화된 최적화를 적용하여 시스템 효율성과 성능을 크게 향상시키는 것을 목표로 합니다. 특히 Serverless 서비스 활용 가능성을 언급하며 기술적 접근 방식을 제시합니다.
Luft대형 쿼리쿼리 옵티마이저
AB180·2023년 10월 12일
Backend
Redis 사용량 타노스하기
이 글은 Elasticache의 메모리 사용량을 52%, 비용을 66% 절감한 최적화 경험을 공유합니다. 광고 클릭 이벤트 데이터를 Redis에 JSON 형태로 저장하면서 발생하는 비효율성을 발견하고, 데이터 특성을 분석하여 최적화 방안을 모색했습니다. 특히, 작은 크기의 데이터를 대량으로 저장하는 문제와 여러 서비스에서 하나의 Redis를 공유하는 상황을 해결하기 위해 Protobuf 직렬화 포맷 도입과 다양한 압축 알고리즘(zstd, snappy, zlib, zopfli, brotli) 벤치마킹을 통해 저장 효율을 극대화했습니다. 이를 통해 비용 절감뿐만 아니라 데이터 관리의 용이성까지 확보한 과정을 상세히 설명하며, 향후 추가적인 최적화 가능성까지 제시합니다.
RedisElastiCache최적화
AB180·2023년 9월 26일
DevOps
Scenario Test: 인수 테스트 자동화로 자신감, 생산성 높이기 (GopherCon 2023 발표)
이 글은 GopherCon 2023에서 발표된 'Scenario Test: 인수 테스트 자동화로 자신감, 생산성 높이기' 내용을 다룹니다. Python에서 Golang으로 거대한 레거시 시스템을 마이그레이션하는 과정에서 인수 테스트 자동화 도구인 Scenario Tester를 Go로 개발하고 활용했던 경험을 공유합니다. 발표자는 마이그레이션 검증에 이 도구가 큰 역할을 했음을 강조하며, 개발 전략, 사용 도구, 그리고 실제 장애 경험과 개선 과정을 상세히 설명합니다. 이를 통해 테스트 자동화를 통해 개발팀의 자신감과 생산성을 높이는 방안을 제시합니다.
인수 테스트테스트 자동화Scenario Test
AB180·2023년 8월 16일
Backend
Profiling and Tracing Tips in Go(GopherCon 2023 발표)
이 글은 GopherCon 2023에서 발표된 'Profiling and Tracing Tips in Go' 내용을 공유합니다. AB180의 백엔드 엔지니어 박재완 님이 작성했으며, 이전 글에서 다루지 못했던 상세한 프로파일링 결과와 데이터를 중심으로 설명합니다. Go 언어에서의 성능 분석 기법과 트레이싱의 중요성을 강조하며, 이를 통해 애플리케이션의 성능을 효과적으로 개선하는 방법을 다룹니다. 향후 Go뿐만 아니라 디자인 개선을 통한 성능 향상에 대한 내용도 공유될 예정임을 시사합니다. 이 글은 개발자들이 Go 애플리케이션의 성능 문제를 진단하고 해결하는 데 유용한 인사이트를 제공합니다.
GoProfilingTracing
AB180·2023년 8월 15일
Backend
적정 엔지니어링으로 검색 속도 10x 빠르게 만들기
이 글은 에어브릿지에서 트래킹링크 조회 및 검색 기능의 성능 저하 문제를 해결한 경험을 공유합니다. 데이터가 누적되면서 검색 시간이 분 단위로 늘어나 사용자 경험에 악영향을 미쳤습니다. 문제의 원인은 텍스트 컬럼에 대한 복잡한 LIKE 쿼리와 여러 테이블 간의 JOIN이었습니다. 특히, 100자 이상의 텍스트 컬럼 전체에 LIKE 쿼리를 수행하고 정규식까지 사용하는 방식은 성능을 크게 저하시켰습니다. 또한, 사용자 정보 조회를 위해 여러 테이블을 JOIN하고, JOIN된 테이블에서도 LIKE 쿼리가 필요한 경우가 있어 성능에 부담을 주었습니다. 이러한 문제들을 해결하기 위한 적정 엔지니어링 접근 방식과 구체적인 개선 방안을 제시하며 검색 속도를 10배 빠르게 만든 경험을 설명합니다.
검색 품질SQLLIKE Query
AB180·2023년 7월 13일
Backend
Luft 성능 리포트 2023.1
이 글은 AB180에서 사용하는 OLAP 데이터베이스인 Luft의 2023년 첫 성능 리포트입니다. Luft는 사용자 행동 분석에 최적화되어 대규모 사용자 데이터를 경쟁력 있는 비용으로 처리하는 데 사용됩니다. 글에서는 성능 향상의 필요성을 강조하며, 데이터 제공 기간 증가, 데이터 익명화, Funnel 리포트 제공 등 실제 기능 개발에 성능이 어떻게 기여했는지 설명합니다. 또한, 사용자 데이터 물리 노드 분산 개선, Instance store 대신 EBS 사용, Data ingestion 파이프라인 개선 등 구체적인 성능 개선 도전 과정과 그 결과를 소개합니다. 이러한 개선을 통해 노드 간 통신 감소, 쿼리 속도 향상, 디스크 사용량 최적화 등의 성과를 달성했습니다.
LuftOLAP데이터베이스
AB180·2023년 5월 5일
DevOps
Yarn 대신 pnpm으로 넘어간 3가지 이유
이 글은 Airbridge에서 Yarn에서 pnpm으로 패키지 매니저를 전환한 경험을 공유합니다. 필자는 Yarn Berry의 PnP 모드가 Git 저장소에 미치는 잠재적 영향과 패키지 호환성 문제를 겪은 후 pnpm으로 전환했습니다. pnpm은 디스크 공간 효율성, 빠른 설치 속도, 그리고 더 나은 Git 통합을 제공하여 개발 생산성을 향상시켰습니다. 특히, pnpm의 하드 링크 방식은 중복 파일 저장을 방지하고, Git 커밋 히스토리에 패키지 의존성이 직접적으로 영향을 미치는 것을 줄여줍니다. 또한, 잘못된 패키지 참조로 인한 런타임 오류를 방지하는 데에도 기여했습니다. 이 글은 pnpm 도입을 통해 얻은 실질적인 이점들을 설명하며, 다른 개발팀에게도 pnpm 전환을 고려해볼 만한 가치가 있음을 시사합니다.
pnpmYarn패키지 매니저
AB180·2023년 4월 3일
Backend
TrailDB to Ziegel(Cgo to Go)
AB180은 자체 OLAP 데이터베이스인 Luft의 데이터 저장을 위해 사용하던 오픈소스 스토리지 엔진 TrailDB를 직접 개발한 Ziegel로 교체한 과정을 공유합니다. 기존 TrailDB는 2019년 개발 중단으로 인한 성능 및 생산성 문제, 비효율적인 멀티코어 활용, Row 단위 데이터 저장 방식, 그리고 Go(Luft)와 C++(TrailDB)라는 두 가지 언어 사용으로 인한 개발 비효율 등의 단점을 가지고 있었습니다. 이러한 문제를 해결하기 위해 AB180은 5단계의 마이그레이션 작업을 수행했습니다. 정합성 검증을 위한 테스트 추가, 엔진 교체 인터페이스 구현, 스토리지 엔진(Ziegel) 구현 및 안정화, 성능 최적화 및 프로덕션 적용, 그리고 최종적으로 TrailDB 의존성 제거 과정을 거쳐 성공적으로 스토리지 엔진을 교체했습니다. 이 과정을 통해 인덱싱 소요 시간을 절반으로 줄이고 쿼리 성능 저하를 최소화하는 등 성능 향상을 달성했습니다.
스토리지 엔진GoC++
AB180·2022년 11월 28일