아키텍처 기술 블로그 최신 글

필터 0

선택된 필터 없음

2026년 2월 27일

아키텍처

[기술리포트] 클라우드 네이티브 4편 : 상태 관리와 데이터 일관성 - 안정성·신뢰성 확보 전략

클라우드 네이티브에서 상태를 서버 밖으로 분리하고 데이터별 정합성 정책을 세우는 방법을 다뤘습니다. saga, outbox, 복제, 캐시 완화 패턴으로 가용성과 신뢰성을 높이는 전략을 정리했습니다.

[트렌드분석] 글로벌 데이터센터의 전력 문제와 AI 인프라 – Megawatt 시대의 도전과제

AI 인프라 경쟁의 중심이 GPU 성능보다 전력 확보 능력으로 이동했다고 설명했습니다. 지역별 전력망과 규제 차이를 바탕으로 데이터센터 투자와 운영의 핵심 과제를 정리했습니다.

[기술리포트] 클라우드 네이티브 3편 : 장애 도메인과 격리 설계 - 가용성·복원력 강화 전략

멀티 리전이라도 공유 지점이 남으면 장애가 전파될 수 있다는 점을 정리했습니다. 가용성과 복원력을 높이기 위한 격리 설계와 순차 배포 원칙을 설명했습니다.

#cloud#Kubernetes

4900

AI 시대의 데이터센터: GPU의 뜨거운 열을 어떻게 식힐 것인가?

2026년 2월 12일

아키텍처

AI 시대의 데이터센터: GPU의 뜨거운 열을 어떻게 식힐 것인가?

AI 데이터센터의 GPU 발열 문제로 공랭식 냉각이 한계에 이르렀다고 설명했습니다. 액체 냉각 도입 시 전력, 물, 안정성까지 인프라 전반의 재설계가 필요하다고 정리했습니다.

AWS Transform Custom을 활용한 ASP.NET 모노리스 애플리케이션을 마이크로서비스로 변환하기

AWS Transform Custom으로 ASP.NET 모노리스 애플리케이션을 마이크로서비스로 전환하는 과정을 소개했습니다. 커스텀 변환 정의를 만들고 반복 적용해 레거시 현대화를 자동화하는 방법을 설명했습니다.

#AWS#MSA

5200

장애 대응의 성패를 가르는 First Action: 우아한형제들의 장애 관리 라이프사이클

2026년 2월 3일

아키텍처

장애 대응의 성패를 가르는 First Action: 우아한형제들의 장애 관리 라이프사이클

장애 대응에서 가장 중요한 초동 조치와 이를 관리하는 라이프사이클을 정리했습니다. 시간 기반 메트릭으로 병목을 찾고 운영 개선으로 연결하는 방식을 소개했습니다.

#SRE#모니터링

20300

Prompt Engineering 이후의 시대 : 프롬프트 중심 설계는 왜 한계에 도달했고, 무엇이 그것을 대체하는가

2026년 1월 30일

아키텍처

Prompt Engineering 이후의 시대 : 프롬프트 중심 설계는 왜 한계에 도달했고, 무엇이 그것을 대체하는가

프롬프트 중심 설계가 왜 한계에 도달했는지 설명하고, 의도·정책·관측 기반 아키텍처로의 전환을 제안했습니다. 프롬프트는 주인공이 아니라 시스템이 생성하는 결과물로 다뤄야 한다고 강조했습니다.

모바일 지도 SDK의 재설계

기존 모바일 지도 SDK의 성능 한계와 플랫폼별 중복 구조를 해결하기 위해 재설계를 진행했습니다. C++ 공통 코어와 그래픽 추상화, 스트리밍 파이프라인으로 성능과 확장성을 개선했습니다.

#C++#Kotlin

12600

80TB 데이터 비용 10배 절감기: DynamoDB에서 Apache Iceberg로의 여정 - Part 1

2026년 1월 23일

아키텍처

80TB 데이터 비용 10배 절감기: DynamoDB에서 Apache Iceberg로의 여정 - Part 1

80TB 이중 저장 구조를 S3 기반 Iceberg 단일 테이블로 통합해 비용을 1/10로 낮추는 과정을 정리했습니다. Rowgroup, 버켓, 컴팩션, 파티션 조합으로 조회 파일 수를 크게 줄였습니다.

#DynamoDB#Apache Iceberg

왜 행사 상품은 항상 늦게 연동될까?

FCFS 기반 제휴 상품 연동의 한계를 보완하기 위해 SoAP 점수 체계를 도입했습니다. 주요 상품의 우선순위를 높여 연동 속도와 운영 효율을 개선했습니다.

#Kotlin#비동기

5200

“이번 달도 밤샘 정산입니다.” — 정산 시스템은 왜 필요했을까 (설계편)

2026년 1월 22일

아키텍처

“이번 달도 밤샘 정산입니다.” — 정산 시스템은 왜 필요했을까 (설계편)

정산을 사람의 기억이 아닌 시스템의 책임으로 옮기기 위한 MASS 설계 원칙을 다뤘습니다. 멱등성, 결정적 계산, 고정 반올림으로 재처리와 재계산에도 동일한 결과를 보장했습니다.

#Kafka#Spring Batch

13900

당근페이 백엔드 아키텍처가 걸어온 여정

2026년 1월 15일

아키텍처

당근페이 백엔드 아키텍처가 걸어온 여정

당근페이 백엔드가 계층형 아키텍처에서 헥사고날 아키텍처를 거쳐 클린 아키텍처와 모노레포로 진화한 과정을 소개했습니다. 서비스 성장에 따른 결합도와 배포 복잡도를 줄이기 위해 도메인 분리와 의존성 역전을 강화했습니다.

#Layered Architecture#Hexagonal Architecture

42200

복잡한 비즈니스 로직, 파이프라인으로 다듬기

2026년 1월 12일

아키텍처

복잡한 비즈니스 로직, 파이프라인으로 다듬기

대출 심사 로직의 복잡도를 줄이기 위해 Pipeline, Job, Store 구조를 적용한 사례를 소개했습니다. 정책 변경과 테스트를 더 쉽게 만들기 위한 설계 고민을 정리했습니다.

전시 동적필터 리팩토링

페이지 타입별 필터 정책이 코드 곳곳에 흩어져 있어 확장과 유지보수가 어려운 문제를 리팩토링했습니다. 정책은 전략으로, 생성은 공통 흐름으로 분리해 변경 지점을 명확히 했습니다.

#리팩토링#디자인패턴

7500