인프라팀에 업무 요청이 들어오면 5분동안 벌어지는 일
사람을 채우는 대신 누가 받아도 같은 정보에서 시작하는 구조를 만들었습니다.
devBlog
Architecture 글 모음
기업 기술블로그의 Architecture 관련 글 314개
때로는 오버엔지니어링이 필요합니다
…
[기술분석] AI 추론 메모리 병목과 서버 아키텍처 변화
.ktc-poster img { transition: transform .3s ease, box-shadow .3s ease; } .ktc-poster:hover img { transform: translateY(-4px); box-shadow:0 10px 22px rgba(0,154,135,0.22) !important; } .imageblock img { max-width:100% !important; height:auto !importan
[아키텍처] 이기종 데이터 통합 설계, 모니터링 통합에서 얻은 3가지 경계
@keyframes kttblink { 50% { opacity:0; } } .ktt-cursor { animation:kttblink 1.05s step-end infinite; } @keyframes kttlive { 0% { box-shadow:0 0 0 0 rgba(63,185,80,0.55); } 70% { box-shadow:0 0 0 6px rgba(63,185,80,0); } 100% { box-shadow:0 0 0 0 rgba
AWS 네트워크 데이터 전송 및 처리 요금, 아키텍처로 이해하기 [3부: VPC 간 연결과 하이브리드]
이 글은 여러 VPC와 계정, 온프레미스를 연결하는 네트워크를 설계하거나 운영하는 아키텍트와 네트워크 담당자를 대상으로, VPC 경계와 리전 경계를 넘는 트래픽에 어떤 요금이 과금되고 연결 방식별로 비용이 어떻게 달라지는지를 다룹니다. 1부에서는 AWS 네트워크 비용이 데이터 전송 요금과 데이터 처리 요금 두 축으로 정해진다는 점과 인터넷 게이트웨이, NAT Gateway, VPC 엔드포인트의 요금을 살펴보았습니다. 2부에서는 같은 리전 안에서
AWS 네트워크 데이터 전송 및 처리 요금, 아키텍처로 이해하기 [2부: 리전 안의 트래픽]
이 글은 VPC와 가용 영역(Availability Zone, AZ)의 기본 개념과 Elastic Load Balancing, Amazon ElastiCache, Amazon EKS를 운영해 본 경험이 있는 아키텍트와 운영 담당자를 대상으로, 같은 리전 안에서 AZ 경계를 넘는 트래픽이 어디에서 발생하고 어떻게 최적화하는지를 다룹니다. 1부에서는 AWS 네트워크 비용이 데이터 전송 요금과 데이터 처리 요금 두 축으로 결정된다는 점을 살펴보았습니
AWS 네트워크 데이터 전송 및 처리 요금, 아키텍처로 이해하기 [1부: 요금 구조와 인터넷 경계]
이 글은 VPC, 서브넷, 가용 영역(Availability Zone, AZ)의 기본 개념을 아는 아키텍트와 운영 담당자를 대상으로, AWS 네트워크 비용이 어느 경로에서 어떤 단위로 발생하는지와 이를 설계 단계에서 최적화하는 방법을 다룹니다. 데이터 전송 비용은 청구서에서 식별되기 어렵습니다. EC2 인스턴스나 RDS처럼 서비스 이름으로 묶이지 않고 여러 서비스에 흩어져 기록되기 때문입니다. 필자가 검토한 고객 사례들에서는 EC2-Other
[데이터센터 입문콘텐츠] GPU를 사 왔습니다. 그런데 이건 어디에 두나요? AI GPU와 데이터센터
고성능 GPU 1만 장은 칩만으로 약 7MW를 소비해 소도시급 전력에 맞먹습니다. 전력밀도·발열·하중을 일반 서버실이 감당하지 못해 전용 데이터센터가 필요합니다. AI GPU는 서버·랙·상면과 전력·냉각 설비를 갖춘 ... Read More
쿼리가 아니라 정의를 고치기로 했습니다: Databricks Metric View 도입기
Metric View를 신규 런칭 게임의 데이터 파이프라인에 도입하면서, 대시보드와 분석 에이전트가 같은 지표 정의를 읽게 하기 위해 데이터 구조를 어떻게 나눴는지, 그 과정에서 정한 설계 규칙과 결과를 공유합니다.
“배포해줘” 한 줄로 끝나는 배포 — 전 직원이 쓰는 사내 플랫폼 구축기
AI에게 분석을 맡기기 전에, '분석할 수 없음' 부터 가르치세요 — Wear OS 이슈 초도 분석을 자동화한 WOA Agent 개발기
Galaxy Watch 검증 단계에서 등록되는 Crash·ANR·화면 흑화 이슈의 초도 분석을 자동화한 WOA(Wear OS Analysis) Agent의 개발 과정을 소개합니다. 덤프 수집부터 로그 복호화, 난독화 해제, RAG 기반 유사 이슈 검색과 담당자 추천까지 사람이 반복하던 30분의 준비 작업을 어떻게 이벤트 기반 자동 분석으로 전환했는지 다루며, 특히 "분석 불가 판단 능력"을 핵심 기능으로 구현한 이유를 설계 관점에서 풀어봅니다.
지피지기 7편: GPU로 만든 모델이 GPU보다 좋은 칩을 만들다
AI로 AI를 돌리는 칩을 만드는 시대가 도래했습니다. AI 회사인 OpenAI의 자체칩 할라피뇨의 공개된 정보들을 바탕으로 이를 알아봅니다.
하루 N억 건의 알림 시스템 구축기 (1): 카카오뱅크는 어떻게 발송 플랫폼의 새로운 뼈대를 세웠나
플랫폼의 핵심은 개발자의 멘탈 모델을 단순하게 유지하는 데 있습니다. 카카오뱅크의 신규 발송기는 Lock-Free, Work-Stealing 같은 복잡한 성능 최적화는 내부에 숨기고, 개발자에게는 “몇 개의 메서드만 구현하면 된다"는 단순한 인터페이스를 제공합니다. 시리즈물로 연재되는 ‘대규모 알림 시스템 구축기’의 첫 번째 글인 이번 편에서는, 하루 N억 건을 처리하는 고성능 발송 플랫폼의 뼈대와 계층 분리 아키텍처를 공유합니다.
채널코퍼레이션의 Amazon DynamoDB와 함께한 아키텍처 현대화 여정 – 3부
이 블로그는 Channel Corporation의 이해빈님, 박진영님과 함께 작성되었습니다. 채널코퍼레이션은 올인원 AI 메신저 ‘채널톡’을 운영하는 B2B SaaS 스타트업으로 Amazon DynamoDB의 수평 확장성, ACID 트랜잭션과 같은 특징을 활용해 빠르게 성장하는 비즈니스를 문제없이 수행하고 있습니다. 이 시리즈의 1부에서는 채널코퍼레이션이 Amazon DynamoDB를 선택한 이유와 Amazon DynamoDB에서 트랜잭션을 처
배송최적화 시스템 구축기 Part 02. 복잡한 비즈니스 로직에 유연한 디자인 패턴 입히기
안녕하세요! 올리브영 배송최적화 스쿼드의 백엔드 개발을 담당하고 있는 로미입니다.🌠 지난 Part 01에서는 멀티 센터 체제 전환의 배경과 배송최적화 시스템의 전체 아키텍처를 소개했는데요. 이번 Part 0…
Product Engineer의 가능성과 조건: 대규모 예산이 투입되는 프로젝트에서 확인하다
LLM에게 수백 MB 로그를 통째로 주지 마세요 — 근거를 "검증"할 수 있는 AI 이슈 분석 에이전트 개발기
개발자는 이슈를 해결하기 전에 이슈를 찾고 읽으며 수백 MB의 로그를 뒤지는 데 하루의 상당 시간을 씁니다. 이 글은 그 시간을 되찾기 위해 만든 AI 이슈 분석 에이전트의 개발기입니다. 로그를 LLM에 통째로 넣었다가 실패한 이야기부터 결정적 전처리 파이프라인, 환각을 구조적으로 차단하는 인용 규율, 빌드가 지키는 아키텍처까지 개발 과정의 실패와 결정을 있는 그대로 담았습니다.
모놀리식인데, 도메인 하나만 따로 띄웁니다
모듈러 모놀리식에서 도메인 하나를 독립된 실행 단위로 만드는 방법
페이지 1 / 18 (총 314개)