서버를 위한 Redux: Node.js 이벤트 소싱 라이브러리 개발기 | by Tony W | 당근 테크 블로그 | Jan, 2026 | Medium (새 탭에서 열림)

당근 프론트엔드코어 팀은 복잡해지는 내부 도구의 요구사항을 해결하기 위해 기존 CRUD 방식의 한계를 넘어 '이벤트 소싱' 패턴을 도입했습니다. 이를 위해 프론트엔드 개발자들에게 친숙한 Redux의 구조를 서버 환경으로 옮겨온 TypeScript 기반 라이브러리 'Ventyd'를 직접 개발하여 오픈소스로 공개했습니다. 이 방식은 데이터의 현재 상태뿐만 아니라 모든 변경 이력을 보존함으로써 감사 로그, 롤백, 비즈니스 인사이트 추출을 획기적으로 용이하게 만듭니다. **전통적 CRUD 방식의 한계와 이벤트 소싱의 필요성** * 기존 CRUD(Create, Read, Update, Delete) 방식은 데이터의 '최종 상태'만 저장하기 때문에, 어떤 과정을 거쳐 현재 상태에 이르렀는지에 대한 맥락을 파악하기 어렵습니다. * 승인 절차, 수정 기록 관리, 복잡한 롤백 로직 등을 구현하려면 별도의 히스토리 테이블이나 복잡한 상태 컬럼을 추가해야 하며, 이는 코드의 복잡도를 높이고 유지보수를 어렵게 만듭니다. * 이벤트 소싱은 상태를 직접 수정하는 대신 "상태를 변경시킨 모든 이벤트"를 순차적으로 기록하여, 필요할 때마다 이벤트를 재생(Replay)해 어느 시점의 상태든 완벽하게 재구성할 수 있게 합니다. **Redux 패턴을 통한 이벤트 소싱의 이해** * 이벤트 소싱 아키텍처는 프론트엔드 상태 관리 라이브러리인 Redux와 매우 유사한 구조를 가집니다. * Redux의 'Action'은 이벤트 소싱의 'Event'와 대응되며, 'Reducer'는 이전 상태와 이벤트를 결합하여 새로운 상태를 계산하는 핵심 로직 역할을 수행합니다. * 가장 큰 차이점은 Redux가 브라우저 메모리에서 상태를 관리하는 반면, 서버의 이벤트 소싱은 이 모든 이벤트를 데이터베이스에 영구적으로 저장하여 데이터의 영속성과 신뢰성을 보장한다는 점입니다. **TypeScript 퍼스트 라이브러리: Ventyd** * Ventyd는 TypeScript 환경에서 이벤트 소싱을 더 쉽고 안전하게 구현하기 위해 개발되었으며, 강력한 타입 추론을 제공합니다. * **스키마 정의**: `defineSchema`를 통해 발생 가능한 이벤트의 종류와 최종 상태(State)의 형태를 정의합니다. 이때 Valibot, Zod, TypeBox 등 다양한 검증 라이브러리를 선택하여 사용할 수 있습니다. * **리듀서 구현**: `defineReducer`를 사용해 각 이벤트가 발생했을 때 상태가 어떻게 변화하는지 선언적으로 기술합니다. * **유연한 확장성**: 특정 데이터베이스에 종속되지 않도록 설계되어 있으며, 프론트엔드와 백엔드 엔지니어가 공통의 비즈니스 로직 언어(이벤트)로 소통할 수 있는 환경을 제공합니다. 단순히 현재의 데이터 값만 저장하는 것을 넘어, 서비스의 성장 과정과 모든 변경 맥락을 자산으로 남기고 싶은 팀에게 Ventyd 도입을 추천합니다. 특히 Redux에 익숙한 엔지니어라면 낮은 학습 곡선으로도 서버 사이드에 견고한 이벤트 중심 아키텍처를 구축하고, 복잡한 비즈니스 요구사항을 깔끔하게 정리할 수 있을 것입니다.

코드 품질 개선 기법 30편: (투명한) 운명의 붉은 실 (새 탭에서 열림)

코드 내에서 서로 다른 함수가 암묵적인 전제 조건을 공유할 때 발생하는 유지보수의 위험성을 경고하고, 이를 해결하기 위한 구체적인 리팩터링 방향을 제시합니다. 특정 함수가 다른 함수의 실행 결과에 의존하는 '암묵적 연관성'은 런타임 에러의 원인이 되므로, 로직을 하나로 통합하거나 의존 관계를 명확히 정의하여 코드의 안전성을 높여야 한다는 것이 핵심입니다. ### 함수 간 암묵적 연관성의 위험성 데이터의 유효성을 검사하는 함수(`isContentValid`)와 데이터를 처리하는 함수(`getMessageText`)가 분리되어 있을 때, 두 함수 사이에는 보이지 않는 의존성이 발생합니다. * **런타임 에러 발생 가능성:** 처리 함수가 유효성 검사 함수에서 `true`를 반환했을 때만 안전하게 호출될 것을 전제로 설계되면, 이 규칙을 어길 경우 컴파일 타임이 아닌 런타임에 에러가 발생합니다. * **일관성 유지의 어려움:** 새로운 데이터 타입이 추가될 때마다 두 함수의 로직을 동시에 업데이트해야 하며, 하나라도 누락할 경우 시스템 전체의 논리적 일관성이 깨지게 됩니다. * **낮은 가독성과 오용 위험:** 호출부의 코드만 봐서는 두 함수가 강하게 결합되어 있다는 사실을 인지하기 어려워, 향후 리팩터링이나 기능 확장 시 함수를 잘못 사용할 가능성이 큽니다. ### 로직 통합을 통한 원자적 처리 필터링(유효성 검사)과 변환(데이터 처리) 기능을 하나의 함수로 합치면 암묵적인 의존성을 제거하고 코드의 안전성을 즉각적으로 향상시킬 수 있습니다. * **Nullable 반환 타입 활용:** `getMessageText` 함수가 유효하지 않은 입력에 대해 에러를 던지는 대신 `null`을 반환하도록 수정함으로써, 호출자가 반환 값을 통해 유효성 여부를 자연스럽게 판단하도록 유도합니다. * **책임의 단일화:** 유효성 검사와 텍스트 추출 로직이 한 곳에 모이게 되어, 데이터 구조가 변경되더라도 한 함수 내의 `when` 절 등에서 모든 처리를 완결할 수 있습니다. ### 연관성을 명시하는 대안적 구현 성격이 다른 두 함수를 반드시 분리해야 하는 상황이라면, 한 함수가 다른 함수를 참조하게 만들어 의존 관계를 겉으로 드러내야 합니다. * **함수 재정의:** `isContentValid` 함수를 독립적인 로직으로 구현하는 대신, `getMessageText(content) != null`과 같이 데이터 처리 함수의 결과를 확인하는 방식으로 재정의합니다. * **단일 진실 공급원(SSOT) 확보:** 이렇게 구현하면 로직의 실질적인 판단 근거가 하나로 집중되어, 함수 간의 동작 불일치 문제를 원천적으로 차단할 수 있습니다. 함수 사이에 '보이지 않는 붉은 실'과 같은 암묵적 규칙이 존재한다면, 이를 코드상에 명확히 드러내거나 하나의 함수로 묶어 관리하는 것이 좋습니다. 이를 통해 동료 개발자가 별도의 사전 지식 없이도 코드를 안전하게 재사용할 수 있는 환경을 만들 수 있습니다.

스마트스토어센터 Oracle에서 MySQL로의 무중단 전환기 (새 탭에서 열림)

네이버 스마트스토어센터는 비즈니스 성장에 따른 Oracle DBMS의 리소스 경합과 라이선스 비용 문제를 해결하기 위해 오픈소스인 MySQL로의 무중단 마이그레이션을 단행했습니다. 10년 이상의 레거시 시스템을 안정적으로 전환하기 위해 '이중 쓰기(Dual Write)' 전략을 채택했으며, 이를 통해 데이터 손실 없는 실시간 동기화와 즉각적인 롤백 가능성을 확보했습니다. 결과적으로 서비스 중단 없이 DB 환경을 성공적으로 전환하며 운영 효율성을 높였습니다. ### 이중 쓰기(Dual Write)를 통한 무중단 전환 전략 * **3단계 전환 프로세스**: 전환 전에는 Oracle을 메인으로 사용하며 MySQL에 백그라운드 쓰기를 수행하고, 데이터 마이그레이션 후에는 MySQL을 메인으로 전환하되 Oracle에 백그라운드 쓰기를 지속하여 정합성을 유지합니다. * **롤백 안정성 확보**: 신규 시스템 배포 후 치명적인 성능 저하나 장애가 발생하더라도, Oracle에 실시간으로 데이터가 쌓이고 있으므로 별도의 복구 작업 없이 즉시 이전 환경으로 복구가 가능합니다. ### JPA 환경에서의 기술적 대응 * **Proxy DataSource 활용**: `datasource-proxy` 라이브러리를 사용하여 Oracle에서 수행되는 쿼리를 가로챈 뒤 MySQL DataSource에서도 동일하게 실행하는 구조를 구축했습니다. * **트랜잭션 분리 및 동기화**: MySQL 쿼리 실패가 메인 트랜잭션(Oracle)에 영향을 주지 않도록 `TransactionSynchronizationManager`를 사용했습니다. Oracle 커밋이 성공한 시점(`afterCommit`)에 모아둔 MySQL 쿼리를 일괄 실행하여 정합성을 맞춥니다. * **엔티티 및 PK 전략 변경**: Oracle의 Sequence 전략을 MySQL의 Identity(Auto-increment)로 변경하고, `columnDefinition` 설정을 통해 Oracle의 VARCHAR2, CLOB 등을 MySQL의 TEXT, LONGTEXT 타입에 맞게 조정했습니다. ### MyBatis 기반의 중앙 집중형 이중 쓰기 구현 * **SqlSession Proxy 적용**: 수천 개의 비즈니스 로직을 수정하는 대신, MyBatis의 `SqlSession`을 프록시로 감싸 쓰기 작업(CUD)이 발생할 때 Oracle과 MySQL 쿼리를 동시에 호출하도록 구현했습니다. * **DBMS별 쿼리 매핑**: Oracle과 MySQL의 SQL 문법 차이를 해결하기 위해 별도의 MySQL용 쿼리 파일을 작성하고, 실행 시점에 Query ID에 접두사(예: `mysql.`)를 붙여 적절한 쿼리를 찾아 실행하는 방식을 사용했습니다. ### 데이터 정합성 검증 및 최종 전환 * **배치 기반 검증**: 두 DB 간의 레코드 카운트와 데이터 해시값을 주기적으로 비교하는 배치 프로그램을 운영하여 미세한 데이터 불일치를 식별하고 수정했습니다. * **기능 토글을 이용한 전환**: ZooKeeper 등을 활용한 설정 변경만으로 메인 DB(Read/Write 주체)를 즉시 교체할 수 있는 환경을 구성하여 배포 없이 안정적으로 전환을 완료했습니다. 이와 같은 전략은 대규모 레거시 시스템에서 DB를 교체해야 할 때, 코드 수정을 최소화하면서도 서비스 안정성을 최우선으로 고려하는 개발자들에게 실무적인 가이드라인을 제공합니다. 특히 트랜잭션 동기화와 프록시 패턴을 활용한 중앙 집중식 제어는 복잡한 시스템 마이그레이션의 위험 부담을 낮추는 핵심 기술 요소입니다.

개발자는 AI에게 대체될 것인가 (새 탭에서 열림)

현재의 AI 열풍은 막대한 자본이 투입된 버블의 성격을 띠고 있지만, 장기적으로는 개발자의 업무를 근본적으로 재정의하는 도구로 자리 잡을 것입니다. 개발자는 단순히 코드를 생산하는 역할에서 벗어나, 어떤 업무를 AI에게 '추상화(위임)'하고 어떤 핵심 판단력을 유지할지 결정하는 설계자이자 디렉터의 역량을 요구받게 됩니다. 결국 AI 시대의 생존은 기술적 위임의 경계를 설정하고 시스템의 복잡성을 관리하는 '추상화 능력'에 달려 있습니다. ## AI 하이프와 경제적 불균형의 실체 * **아마라의 법칙과 버블:** 기술의 효과는 단기적으로 과대평가되는 경향이 있으며, 현재 AI 시장은 투자 대비 매출 비율이 16:1(설비투자 5,600억 달러 대비 매출 350억 달러)에 달할 정도로 극심한 불균형 상태입니다. * **실질 수익의 부재:** 생성형 AI 도입 프로젝트의 약 95%가 실패하거나 뚜렷한 효율 개선을 보이지 못하고 있으며, 빅테크의 매출조차 상당 부분 내부 거래에 의존하고 있는 실정입니다. * **인력 감축의 역설:** 현재의 개발자 감원은 AI가 업무를 대체했기 때문이라기보다, 막대한 AI 투자 비용을 충당하기 위한 기업의 비용 절감 전략에서 기인한 측면이 큽니다. ## 제번스 패러독스와 직무의 재정의 * **수요의 폭발:** 에어컨 보급률이 높아질수록 관련 산업이 커지듯, AI로 코딩의 문턱이 낮아지면 소프트웨어에 대한 전체 수요와 활용처는 오히려 기하급수적으로 늘어날 것입니다. * **도구로서의 AI:** 과거 게임 엔진이 소규모 팀에게 프로급 역량을 부여했듯, AI는 개발자를 보조하는 강력한 '파워 툴'이 되어 상위 실력자의 생산성을 극대화합니다. * **역할의 변화:** 개발자의 정체성은 코드 작성자에서 '코드 크리에이티브 디렉터'로 변모하며, 시스템 설계, 에이전트 지휘, 결과물 검증이 업무의 중심이 됩니다. ## 위임의 사분면과 추상화의 본질 * **위임의 기준:** '위임하기 쉬운가(기술적 난이도)'는 모델의 발전에 따라 계속 변하는 일시적인 경계일 뿐이며, 중요한 것은 '위임해야 하는가(책임과 판단)'라는 가치 판단의 축입니다. * **추상화로서의 위임:** AI에게 업무를 맡기는 것은 프로그래밍의 '추상화'와 같습니다. 이는 세부 사항을 숨기고 더 이상 신경 쓰지 않겠다는 선언이며, 복잡성을 미래로 이동시키는 레버리지 역할을 합니다. * **유형별 위임 전략:** 단순 CRUD나 보일러플레이트 코드, 테스트 케이스 등 잘 정의된 문제는 AI에게 맡기되, 아키텍처 결정이나 보안 정책, 법규 대응처럼 인간의 판단이 필수적인 영역은 분리해야 합니다. ## 잘못된 추상화와 미래의 리스크 * **추상화의 붕괴:** 트래픽 급증, 법률 개정(GDPR 등), 제로데이 보안 취약점 같은 예외 상황이 발생하면 AI에게 위임했던 '추상화된 업무'가 한꺼번에 무너질 수 있습니다. * **시니어의 역할:** 시스템의 근본이 흔들릴 때 이를 해결할 수 있는 능력은 결국 풍부한 경험을 가진 시니어 개발자의 몫이며, AI 결과물을 맹목적으로 수용할 경우 추상화가 없는 것보다 더 큰 재앙을 초래할 수 있습니다. * **지속 가능한 리팩토링:** 개발자는 AI에게 어떤 컨텍스트를 제공하고 어떤 부분을 직접 통제할지 업무 프로세스를 끊임없이 리팩토링하며 '좋은 추상화'를 구축해야 합니다. 성공적인 AI 활용을 위해서는 AI를 단순한 대체재가 아닌, 복잡성을 관리하는 추상화 도구로 바라봐야 합니다. 기술 발전 속도에 일희일비하기보다, 기술이 해결할 수 없는 '비즈니스 임팩트'와 '시스템의 안정성'에 대한 인간의 판단력을 고도화하는 것이 AI 시대 개발자의 핵심 경쟁력이 될 것입니다.

NVIDIA RTX PRO 6 (새 탭에서 열림)

Amazon은 NVIDIA RTX PRO 6000 Blackwell 서버 에디션 GPU를 탑재한 새로운 EC2 G7e 인스턴스의 정식 출시를 발표했습니다. 이 인스턴스는 생성형 AI 추론 워크로드에서 뛰어난 비용 효율성을 제공하며, 이전 세대인 G6e 대비 최대 2.3배 향상된 추론 성능을 자랑합니다. 공간 컴퓨팅 및 과학적 컴퓨팅과 같이 높은 그래픽 성능이 요구되는 작업에 최적화된 하이엔드 솔루션입니다. ### NVIDIA Blackwell GPU 기반의 성능 혁신 * **메모리 용량 및 대역폭:** NVIDIA RTX PRO 6000 Blackwell GPU를 통해 G6e 대비 2배의 GPU 메모리(개당 96GB)와 1.85배의 메모리 대역폭을 제공합니다. * **대규모 모델 처리:** 향상된 메모리 사양 덕분에 단일 GPU 환경에서도 FP8 정밀도로 최대 700억 개(70B) 파라미터 규모의 중간급 모델을 실행할 수 있습니다. * **컴퓨팅 파워:** 최신 Intel Emerald Rapids 프로세서를 탑재하여 강력한 CPU 성능과 GPU 성능의 조화를 이룹니다. ### 멀티 GPU 효율성 및 상호 연결 기술 * **NVIDIA GPUDirect P2P 지원:** 단일 GPU 메모리를 초과하는 대규모 모델을 위해 PCIe 인터커넥트를 통한 GPU 간 직접 통신을 지원하여 지연 시간을 최소화합니다. * **대역폭 향상:** G6e에 탑재된 L40s GPU 대비 GPU 간 대역폭이 최대 4배 증가하여, 멀티 GPU 워크로드의 처리 효율이 비약적으로 상승했습니다. * **확장성:** 단일 노드에서 최대 8개의 GPU를 사용하여 총 768GB의 GPU 메모리를 확보할 수 있어, 거대 언어 모델(LLM) 추론에 유리합니다. ### 네트워킹 및 스토리지 가속화 * **고속 네트워크:** G6e 대비 4배 더 넓은 최대 1,600Gbps의 네트워크 대역폭을 제공하여 소규모 멀티 노드 워크로드에 적합합니다. * **지연 시간 감소:** Elastic Fabric Adapter(EFA)를 통한 GPUDirect RDMA를 지원하여 원격 GPU 간 통신 시 병목 현상을 줄였습니다. * **데이터 로딩 최적화:** Amazon FSx for Lustre와 GPUDirectStorage를 결합하여 최대 1.2Tbps의 처리량을 지원하므로, 대용량 모델 데이터를 매우 빠르게 로드할 수 있습니다. ### 상세 인스턴스 사양 * **인스턴스 구성:** 최소 `g7e.2xlarge`(1 GPU, 8 vCPU)부터 최대 `g7e.48xlarge`(8 GPU, 192 vCPU)까지 총 6가지 크기를 제공합니다. * **시스템 자원:** 최대 2,048GiB의 시스템 메모리와 15.2TB의 로컬 NVMe SSD 스토리지를 선택할 수 있어 데이터 집약적인 작업에 대응합니다. 생성형 AI 모델의 크기가 커짐에 따라 고용량 GPU 메모리와 빠른 상호 연결 성능이 필수적인 환경에서 G7e 인스턴스는 최적의 선택지입니다. 특히 기존 G6e 인스턴스 사용자가 성능 한계를 느끼거나, 70B급 모델을 보다 효율적으로 서빙하고자 하는 개발 팀에게 이 인스턴스로의 전환을 적극 추천합니다. 현재 미국 동부(버지니아 북부) 및 미국 서부(오레곤) 리전에서 바로 사용할 수 있습니다.

AWS 주간 뉴스 요약 (새 탭에서 열림)

이 글은 2026년 1월 셋째 주 AWS의 주요 기술 업데이트와 커뮤니티 소식을 다루며, 특히 Kiro CLI의 기능 강화와 유럽 주권 클라우드의 정식 출시를 핵심 성과로 제시합니다. 또한 고성능 메모리 최적화 인스턴스인 EC2 X8i의 상용화와 Amazon Quick Suite를 통한 AI 에이전트 활용 사례를 통해 더욱 고도화된 클라우드 생태계를 구축했음을 보여줍니다. 이번 소식은 엔터프라이즈급 성능 요구 사항과 지역별 규제 준수, 그리고 AI 기반 생산성 향상이라는 세 가지 측면에서 AWS의 진보를 요약하고 있습니다. **Kiro CLI의 제어 및 사용자 경험 강화** * 웹 호출(web fetch) URL에 대한 세밀한 제어 기능을 도입하여, 허용 목록(allowlist)과 차단 목록(blocklist)을 통해 에이전트가 접근할 수 있는 URL 범위를 엄격하게 제한할 수 있습니다. * 커스텀 에이전트를 위한 전용 키보드 단축키와 개선된 Diff 뷰를 제공하여, 단일 세션에서 여러 전문화된 에이전트와 협업할 때 발생하는 마찰을 최소화했습니다. **AWS 유럽 주권 클라우드 정식 출시** * 2023년부터 추진해 온 독립적인 클라우드 인프라인 'AWS European Sovereign Cloud'가 모든 고객을 대상으로 정식 서비스(GA)를 시작했습니다. * 유럽 내 가장 엄격한 데이터 주권 및 규제 요건을 충족할 수 있도록 설계되었으며, 포괄적인 AWS 서비스 세트를 제공하여 유럽 고객들의 컴플라이언스 대응을 지원합니다. **메모리 최적화 EC2 X8i 인스턴스 상용화** * AWS 전용 커스텀 Intel Xeon 6 프로세서를 탑재한 EC2 X8i 인스턴스가 정식 출시되었으며, 모든 코어에서 최대 3.9GHz의 터보 주파수를 유지합니다. * SAP 인증을 획득한 이 인스턴스는 클라우드 내 인텔 기반 프로세서 중 최고 수준의 성능과 메모리 대역폭을 제공하여 메모리 집약적인 워크로드에 최적화되어 있습니다. **생산성 향상을 위한 AI 에이전트 및 도구** * AI 에이전트 동료인 'Amazon Quick Suite'를 통해 비즈니스 질문에 답을 구하고 인사이트를 행동으로 전환하는 생산성 활용 사례가 공유되었습니다. * GitHub Actions를 사용하여 Amazon Bedrock AgentCore에 AI 에이전트를 자동 배포하는 방법이 소개되어, 개발자들이 더욱 효율적으로 AI 기능을 운영 환경에 적용할 수 있게 되었습니다. 이번 업데이트는 강력한 보안과 규제 준수가 필요한 유럽 시장부터, 고성능 컴퓨팅이 요구되는 엔터프라이즈 환경, 그리고 실무 효율을 높이는 AI 에이전트 기술까지 폭넓은 영역을 아우르고 있습니다. 기술 조직은 특히 강화된 Kiro CLI와 Bedrock AgentCore 배포 자동화 가이드를 참고하여 사내 AI 에이전트 운영 환경을 최적화하고 개발 생산성을 한 단계 더 끌어올릴 수 있을 것입니다.

토스인컴 QA Platform: ‘누구나 테스트할 수 있는’ 도구의 시작 (새 탭에서 열림)

토스 QA 팀은 반복되는 테스트 데이터 생성과 복잡한 API 호출 문제를 해결하기 위해 기존 Swagger API를 GUI 기반으로 추상화한 'QA Platform'을 구축했습니다. 이 도구는 테스트의 진입 장벽을 낮춰 QA뿐만 아니라 모든 팀원이 품질 검증에 참여하게 함으로써 제품 개발 속도를 획기적으로 높이는 결과를 가져왔습니다. 단순히 테스트를 자동화하는 것을 넘어, 품질을 제품 설계 과정의 일환으로 내재화하여 팀 전체가 확신을 가지고 움직일 수 있는 환경을 조성한 것이 핵심입니다. **Swagger 기반의 접근성 개선 (Phase 1)** * Swagger에 흩어져 있는 테스트 API들을 한곳에 모으고, 복잡한 JSON 작성 없이 버튼 클릭만으로 실행할 수 있는 GUI를 도입했습니다. * 사용자의 숙련도에 따라 입력 방식을 이원화했습니다. 'Normal 모드'는 복잡한 필드를 숨겨 누구나 쉽게 쓰게 했고, 'Swagger 모드'는 QA 매니저나 엔지니어가 세부적인 파라미터를 제어할 수 있도록 설계했습니다. * 환경 스위칭, 최근 실행 값 저장, API 응답 값의 자동 복사 기능 등 사소하지만 빈번한 번거로움을 줄여주는 UX 요소를 배치해 심리적 장벽을 낮췄습니다. **자동화의 대중화와 통합 관리 (Phase 2 & 3)** * QA 팀 내부에서만 활용되던 기존의 자동화 스크립트를 플랫폼 내 컨트롤러로 이식하여, 개발자나 기획자도 버튼 하나로 자동화 테스트를 수행할 수 있게 했습니다. * 복잡한 환경 설정이나 스크립트 실행 지식 없이도 자동화 자산을 활용할 수 있게 되어, 검증의 주체가 QA 팀에서 제품 팀 전체로 확장되었습니다. * 외부 도구에 의존하는 대신 조직의 고유한 테스트 방식에 최적화된 통합 관리 시스템을 구축하여, 테스트 설계부터 실행 및 관리까지의 전 과정을 하나로 연결하고 있습니다. **품질 검증에서 품질 설계로의 관점 전환** * 테스트가 '시간을 내서 해야 하는 특별한 작업'이 아니라 '생각나면 바로 하는 일상'이 되면서, 제품의 병목 현상이 제거되고 의사결정 속도가 빨라졌습니다. * 개발자가 기능을 완성하자마자 직접 검증할 수 있는 환경이 마련됨에 따라, 품질은 마지막 단계의 체크리스트가 아닌 개발 흐름 속에 자연스럽게 녹아드는 요소가 되었습니다. * QA 팀은 단순 반복적인 테스트 데이터 세팅 작업에서 벗어나, 더 고도화된 비즈니스 로직 분석과 리스크 관리에 집중할 수 있는 환경을 확보했습니다. 테스트가 쉬워지면 제품의 속도는 자연스럽게 빨라집니다. 기술적인 고도화만큼이나 중요한 것은 "누가 하느냐"에 갇혀 있던 테스트 권한을 "누구나 할 수 있는 구조"로 만드는 것이며, 이를 통해 팀 전체가 품질에 대한 공동의 책임과 확신을 갖는 것이 실질적인 제품 경쟁력으로 이어집니다.

레거시 인프라 작살내고 하이브리드 클라우드 만든 썰 (새 탭에서 열림)

토스페이먼츠는 20년 된 레거시 인프라의 비효율성을 극복하기 위해 오픈소스 기반의 OpenStack 프라이빗 클라우드를 직접 구축하고, 이를 퍼블릭 클라우드와 결합한 'Active-Active 하이브리드 클라우드' 환경을 구현했습니다. 단 2명의 엔지니어가 운영 경험 없이 시작했음에도 불구하고 자동화와 고가용성 전략을 통해 인프라 제어권을 100% 확보했으며, 결과적으로 어떤 환경에서도 즉시 배포 가능한 유연한 기술 기반을 마련했습니다. ### 1,997개의 라우팅이 보여주는 레거시 인프라의 한계 * 과거 인수한 인프라는 네트워크 장비가 아닌 개별 서버가 직접 라우팅 정보를 관리하는 비정상적인 구조로, 서버당 약 2,000개의 라우팅 경로가 설정되어 있었습니다. * 새로운 경로 추가 시 모든 서버를 일일이 수정해야 하는 관리 포인트의 과부하가 발생했으며, 이는 서비스 확장의 심각한 병목 현상이 되었습니다. * 초기에는 퍼블릭 클라우드 도입으로 대응했으나 비용 증가, 환율 변동, 하이브리드 DR 구성의 어려움 및 가시성 부족이라는 새로운 문제에 직면했습니다. ### OpenStack 기반 프라이빗 클라우드 내재화 * 상용 솔루션 대신 오픈소스인 OpenStack을 선택하여 기술 내재화와 유연한 인스턴스 타입(VM, Container, K8S) 대응력을 확보했습니다. * 부족한 운영 경험을 극복하기 위해 3가지 버전의 OpenStack을 수십 번 설치하고 장애 시나리오를 반복 재현하며 아키텍처 이해도를 높였습니다. * 로드밸런서인 옥타비아(Octavia)의 소스 코드를 직접 수정하여 비즈니스 요구에 맞는 로그 포맷을 생성하는 등 오픈소스의 이점을 극대화했습니다. ### 자동화와 모니터링을 통한 운영 효율 극대화 * Ansible과 Terraform 코드를 활용해 모든 자원의 라이프사이클을 자동화했으며, 골든 이미지를 통해 신규 인스턴스 생성 시간을 10초 이내로 단축했습니다. * Zabbix, Prometheus, Mimir, Grafana 등 다양한 오픈소스 툴을 조합하여 모든 메트릭을 수집하고, 실시간 알람 체계를 구축해 장애 감지 능력을 높였습니다. * 운영 인력의 한계를 극복하기 위해 CMDB와 연동된 봇(Bot)을 구현하여 인프라 현황을 실시간으로 조회하고 관리할 수 있도록 했습니다. ### 고가용성을 위한 다중 클러스터 및 Cluster API 전략 * 장애 발생 시 서비스 가용성을 즉시 확보하기 위해 서로 독립된 3개의 OpenStack 클러스터를 구축하고 평상시 Active-Active로 운영합니다. * 특정 클러스터 장애 시 트래픽을 즉시 차단하는 방식으로 복구 시간을 최소화했으며, 클러스터 간 의존성을 완전히 제거했습니다. * K8S 관리를 위해 Cluster API(CAPI)를 도입하여 쿠버네티스 클러스터 자체를 쿠버네티스 리소스로 관리함으로써 퍼블릭 클라우드 수준의 관리 편의성을 프라이빗 환경에서도 구현했습니다. 전통적인 금융 인프라의 보수성을 탈피하고 오픈소스 기술을 깊이 있게 내재화한다면, 퍼블릭 클라우드의 편리함과 온프레미스의 통제권을 동시에 거머쥘 수 있습니다. 인력 부족이나 기술적 난도는 자동화와 표준화된 도구(CAPI, Terraform 등)를 통해 충분히 극복 가능하므로, 비용 최적화와 기술적 가시성이 필요한 조직이라면 하이브리드 클라우드 전략을 적극 권장합니다.

네이버 통합검색 AIB 도입과 웹 성능 변화 분석 (새 탭에서 열림)

네이버 통합검색에 도입된 AI 브리핑(AIB)은 채팅 기반의 동적인 UI 특성으로 인해 기존의 핵심 웹 지표인 LCP(Largest Contentful Paint)를 지연시키는 결과를 초래했습니다. 분석 결과, 이는 서버 성능의 문제가 아니라 스트리밍 방식의 어절 단위 렌더링과 인터랙션을 위한 DOM 재구성 등 클라이언트 측의 구조적 특성이 LCP 측정 방식과 충돌하며 발생한 현상으로 확인되었습니다. 네이버는 이러한 UI 특성을 고려하여 LCP 위주의 단일 지표 관리에서 벗어나, TTFT(Time to First Token)와 같은 사용자 체감 성능에 특화된 새로운 측정 체계를 도입하여 성능 관리를 고도화할 계획입니다. **AIB 도입에 따른 성능 지표의 변화** * **LCP p95 지표 악화:** AIB 노출량이 증가함에 따라 통합검색의 LCP p95 값이 목표치인 2.5초를 상회하는 약 3.1초까지 상승하는 경향을 보였습니다. * **성능 분포의 변화:** AIB가 전체 LCP 분포의 꼬리(tail) 영역에 영향을 주면서, 'Good' 구간에 해당하는 사용자 비율이 감소하고 느린 구간의 사용자가 증가했습니다. * **렌더링 방식의 차이:** 구글의 AI Overview가 블록 단위로 렌더링하는 것과 달리, 네이버 AIB는 어절 단위의 점진적 노출과 적극적인 애니메이션을 사용하여 지표 측정에 더 큰 영향을 미쳤습니다. **채팅 UI에서 LCP 왜곡이 발생하는 기술적 원인** * **DOM 재구성 로직:** 텍스트 애니메이션이 끝난 후 하이라이트 기능을 위해 DOM 구조를 다시 변경하는 과정에서, 브라우저가 LCP 후보 영역의 렌더링 시점을 실제보다 늦게 기록하게 됩니다. * **어절 단위 렌더링의 한계:** 콘텐츠가 어절 단위로 쪼개져 렌더링되면 LCP 알고리즘이 '가장 큰 텍스트 블록'을 찾지 못하거나, 의미가 적은 작은 요소를 LCP로 잘못 선택하는 문제가 발생합니다. * **Chromium Paint Invalidation:** 스트리밍 방식으로 텍스트가 추가될 때마다 해당 레이어 전체에 페인트 무효화가 발생하며, 이로 인해 이미 화면에 그려진 요소의 `renderTime`이 프레임 단위로 계속 갱신되어 최종 측정값이 늦춰집니다. **네이버 통합검색의 성능 관리 개선 방향** * **독립적 성능 기준 수립:** AIB 영역을 제외한 일반 검색 결과의 LCP 'Good' 비율은 96%로 안정적이므로, AIB와 같은 특수 UI에는 별도의 성능 지표를 적용할 필요가 있습니다. * **TTFT(Time to First Token) 도입:** 사용자가 첫 번째 응답을 인지하는 시점을 측정하는 TTFT를 핵심 지표로 검토하여, 채팅 UI의 실제 체감 성능을 더 정확하게 반영하고자 합니다. * **지표 해석의 고도화:** 단순히 수치상의 LCP 최적화에 매몰되지 않고, UI의 특성과 사용자 경험을 더 잘 예측할 수 있도록 지표 분석 체계를 세분화하고 개선해 나갈 예정입니다. 현대적인 웹 환경에서는 스트리밍이나 동적 인터랙션이 강조되는 만큼, 기존의 정적 페이지 중심 지표인 LCP만으로 모든 성능을 대변하기 어렵습니다. 따라서 서비스의 UI 특성에 맞춰 TTFT와 같은 대안 지표를 함께 활용하고, 지표의 수치 너머에 있는 브라우저 렌더링 파이프라인의 동작 원리를 이해하는 것이 실질적인 사용자 경험 개선의 핵심입니다.

코드 품질 개선 기법 29편: 고르디우스 변수 (새 탭에서 열림)

코드 내 데이터의 의존성이 복잡하게 얽혀 로직을 파악하기 어려운 상태를 '고르디우스의 매듭'에 비유하며, 이를 해결하기 위한 설계 기법을 제시합니다. 복잡한 조건문과 데이터 가공이 반복되는 경우, 최종 로직에 필요한 이상적인 중간 데이터 구조를 먼저 정의하고 이를 생성하는 방식으로 코드를 재구성하면 가독성과 유지보수성을 동시에 높일 수 있습니다. **데이터 의존성 과다로 인한 가독성 저하** * 원격과 로컬 데이터를 동기화할 때 추가, 업데이트, 삭제 대상을 구분하는 과정에서 데이터 의존성이 복잡해지기 쉽습니다. * 단순히 ID 목록을 비교해 차집합을 구하는 방식은 실제 데이터를 처리할 때 다시 원본 리스트에서 객체를 찾아야 하거나, 맵(Map)에서 데이터를 꺼낼 때 발생할 수 없는 예외 상황을 처리해야 하는 번거로움을 유발합니다. * 이로 인해 비즈니스 로직의 핵심인 '동기화 액션'보다 데이터를 분류하고 가공하는 '준비 과정'이 코드의 흐름을 방해하게 됩니다. **이상적인 중간 데이터 설계를 통한 역설계** * 복잡한 매듭을 풀기 위해서는 최종적으로 필요한 데이터의 형태를 먼저 상상하고, 그 지점부터 함수의 구성을 역으로 설계하는 것이 효과적입니다. * 이번 사례에서는 추가(`created`), 업데이트(`updated`), 삭제(`deleted`)될 대상들을 명확히 분리한 세 가지 리스트를 중간 데이터로 정의했습니다. * 로컬과 원격의 모든 ID 집합을 기준으로 `Pair<RemoteData?, LocalData?>` 형태의 시퀀스를 만들고, 이를 상태에 따라 분류하는 것이 핵심입니다. **`partitionByNullity`를 활용한 로직 단순화** * `partitionByNullity`라는 유틸리티 함수를 도입하여 데이터의 존재 여부에 따라 세 그룹(Remote만 존재, 둘 다 존재, Local만 존재)으로 깔끔하게 분리합니다. * 이 함수를 사용하면 메인 함수인 `synchronizeWithRemoteEntries`에서는 복잡한 필터링이나 조건문 없이 각각의 리스트에 대해 `forEach`를 돌며 추가, 업데이트, 삭제 로직만 수행하면 됩니다. * 결과적으로 런타임 에러를 방지하기 위한 불필요한 null 체크가 사라지고, 전체적인 실행 흐름이 일관성 있게 정돈됩니다. **실용적인 제언** 코드의 흐름을 따라가기 벅차다면 데이터의 흐름이 꼬여있지 않은지 점검해야 합니다. 구현에 매몰되기보다 "어떤 모양의 데이터가 있으면 이 로직이 가장 깔끔해질까?"를 먼저 고민하고, 그 중간 구조를 만들어내는 로직을 별도로 분리하면 코드 품질을 획기적으로 개선할 수 있습니다.

커스텀 인텔 (새 탭에서 열림)

AWS가 Intel Xeon 6 프로세서를 탑재한 차세대 메모리 최적화 인스턴스인 Amazon EC2 X8i의 정식 출시를 발표했습니다. 이 인스턴스는 이전 세대인 X2i 대비 최대 1.5배의 메모리 용량과 3.4배의 대역폭을 제공하여 대규모 데이터베이스 및 분석 작업에 최적화되었습니다. 특히 SAP 인증을 획득하여 SAP HANA와 같은 고성능 인메모리 워크로드에서 압도적인 효율성을 보여줍니다. **커스텀 Intel Xeon 6 기반의 독보적인 성능** * AWS 전용으로 설계된 커스텀 Intel Xeon 6 프로세서를 탑재하여 전 코어 3.9GHz의 지속적인 터보 주파수를 제공합니다. * 이전 세대(X2i)와 비교했을 때 전체적으로 최대 43%의 성능 향상을 실현했습니다. * 최대 6TB의 메모리 용량을 지원하며, 메모리 대역폭은 3.4배 더 넓어져 데이터 집약적인 처리에 유리합니다. **주요 워크로드별 벤치마크 및 비용 효율성** * SAP HANA 워크로드에서 이전 세대 대비 최대 50% 향상된 SAPS(SAP Application Performance Standard) 성능을 기록했습니다. * PostgreSQL 성능은 최대 47%, Memcached는 최대 88%, AI 추론 성능은 최대 46%까지 개선되었습니다. * 실제 고객 사례인 Orion의 경우, X8i의 높은 성능 덕분에 활성 코어 수를 줄이면서도 동일 성능을 유지하여 SQL Server 라이선스 비용을 50% 절감했습니다. **유연한 인스턴스 규격과 대역폭 옵션** * 가상화 인스턴스(48xlarge, 64xlarge, 96xlarge 등)부터 베어메탈(metal-48xl, metal-96xl)까지 총 14가지 크기를 제공합니다. * 최대 100Gbps의 네트워크 대역폭(EFA 지원)과 80Gbps의 Amazon EBS 대역폭을 통해 대규모 데이터 전송 병목 현상을 최소화합니다. * IBC(Instance Bandwidth Configuration) 기능을 지원하여 사용자가 필요에 따라 네트워크와 EBS 대역폭 할당량을 조정할 수 있습니다. **가용성 및 구매 방식** * 현재 미국 동부(버지니아 북부), 미국 서부(오레곤), 유럽(프랑크푸르트, 아일랜드), 아시아 태평양(시드니, 도쿄) 리전에서 즉시 사용 가능합니다. * 온디맨드, 예약 인스턴스(RI), Savings Plans 및 스팟 인스턴스 등 다양한 구매 옵션을 통해 비용을 최적화할 수 있습니다. SAP HANA와 같은 대규모 인메모리 데이터베이스를 운영하거나, 높은 컴퓨팅 파워와 방대한 메모리가 동시에 필요한 EDA(전자 설계 자동화) 및 데이터 분석 환경이라면 X8i 인스턴스로의 전환을 통해 성능 향상과 라이선스 비용 절감 효과를 동시에 거둘 수 있을 것입니다.

토스의 새로운 얼굴 만들기 (새 탭에서 열림)

토스는 서비스의 인상과 신뢰감을 효과적으로 전달하기 위해 기존의 인물 그래픽을 고도화했습니다. 기존의 귀엽고 어린 이미지를 탈피하여 똑똑하고 믿음직한 '토스다운' 인상을 구축하고, 글로벌 확장에 발맞춰 다인종·다문화 환경을 포용할 수 있는 보편적인 디자인 체계를 마련하는 데 집중했습니다. 이를 통해 어떤 화면에서도 완성도를 유지하며 사용자에게 친근하면서도 전문적인 가치를 전달하는 새로운 페르소나를 완성했습니다. **토스다운 신뢰감을 주는 인물 비율 조정** - 기존 그래픽은 얼굴의 세로 비율이 짧아 다소 어려 보이고 신뢰감이 부족하다는 피드백이 있었습니다. - 얼굴 형태를 크게 바꾸어 이질감을 주는 대신, 눈·코·입의 배치와 표현을 미세하게 조정하여 지적이고 성숙한 인상의 균형점을 찾았습니다. - 도형을 단순히 이어 붙인 구조에서 탈피하여 목과 어깨의 곡선을 다듬고 입체감을 더해 조형적 완성도를 높였습니다. - 단정하고 전문적인 분위기를 자아낼 수 있도록 과한 디테일이 배제된 짧은 목폴라 형태의 의상을 기본 착장으로 설정했습니다. **성별과 인종의 경계를 허무는 중립적 디자인** - 특정 성별로 치우치지 않는 중성적인 헤어 스타일을 개발하여 성별 중립적인 인상을 구현했습니다. - 헤어의 부피감을 보완하고 라인을 정돈하여 화면 크기가 커지더라도 그래픽의 밀도가 떨어져 보이지 않도록 개선했습니다. - 단일한 스킨톤에서 벗어나 이모지의 표준을 참고한 다섯 가지 스킨톤 체계를 정의함으로써 다양성을 수용했습니다. - 여러 인물이 등장하는 화면에서는 다양한 스킨톤을 섞어 배치할 수 있도록 가이드를 마련하여 유니버설 디자인의 가치를 투영했습니다. **글로벌 확장을 고려한 포용적 그래픽 시스템** - 한국 중심의 서비스에서 글로벌 시장으로 확장함에 따라 특정 문화권에 국한되지 않는 보편적인 얼굴이 필요해졌습니다. - 노란색과 같은 추상적인 중립 컬러 대신 실제 인종의 다양성을 반영한 컬러 시스템을 선택하여 사용자들의 공감을 유도했습니다. - 디자인 개선 후 실제 앱 적용 시 주변 인터페이스 요소들과 자연스럽게 어우러지며 브랜드의 지향점을 명확히 드러내고 있습니다. 이러한 개편은 단순한 시각적 변화를 넘어 토스가 지향하는 포용성과 신뢰라는 브랜드 가치를 사용자에게 더 가깝게 전달하는 역할을 합니다. 향후에도 인종, 성별, 연령에 관계없이 누구나 자신을 투영할 수 있는 중립적이고 포용적인 그래픽 시스템을 지속적으로 확장해 나갈 것으로 기대됩니다.

당근페이 백엔드 아키텍처가 걸어온 여정. Money라는 하나의 작은 프로젝트부터 수십 개의 서비스를 하나의… | by Jeremy | 당근 테크 블로그 | Jan, 2026 | Medium (새 탭에서 열림)

당근페이 백엔드 아키텍처는 서비스의 급격한 성장과 조직의 확장에 발맞춰 계층형, 헥사고날, 그리고 클린 아키텍처 기반의 모노레포 형태로 끊임없이 진화해 왔습니다. 초기에는 빠른 기능 출시를 위해 단순한 구조를 채택했으나, 비즈니스 복잡도가 증가함에 따라 의존성 관리와 코드 응집도를 높이기 위해 구조적 제약을 강화하는 방향으로 발전했습니다. 결과적으로 아키텍처는 기술적 부채를 해결하는 수단을 넘어, 대규모 팀이 협업하며 지속 가능한 성장을 이뤄낼 수 있는 기반이 되었습니다. ### 초기 성장을 견인한 계층형 아키텍처 (Layered Architecture) * **빠른 실행력 중심:** 2021년 당근페이 출시 초기, 송금 서비스의 신속한 시장 진입을 위해 `Controller-Service-Repository`로 이어지는 직관적인 3계층 구조를 사용했습니다. * **성장통의 발생:** 서비스가 커지면서 송금, 프로모션, FDS 등 다양한 기능이 하나의 계층에 뒤섞였고, 서비스 간 순환 참조와 강한 결합이 발생해 코드 변경의 영향 범위를 예측하기 어려워졌습니다. * **기술 부채의 축적:** 모든 비즈니스 로직에 프레임워크 기술(Spring)이 깊숙이 침투하면서 테스트 작성이 까다로워지고, 순수 도메인 로직만 분리해 관리하기 어려운 구조적 한계에 직면했습니다. ### 구조적 제약을 통한 응집도 향상 (Hexagonal Architecture) * **외부 구현과의 분리:** 도메인 규칙을 중심에 두고 UI, DB, 외부 API 등 인프라 영역을 포트와 어댑터를 통해 분리하여 프레임워크에 의존하지 않는 POJO 중심의 설계를 지향했습니다. * **모듈 역할의 세분화:** 프로젝트를 핵심 규칙을 담은 `domain`, 사용자 시나리오 단위의 `usecase`, 실제 입출력을 담당하는 `adapter` 모듈로 재구성하여 의존성 방향을 한곳으로 모았습니다. * **재사용성과 테스트 용이성:** 유스케이스 단위로 로직이 응집되면서 REST API뿐만 아니라 이벤트 컨슈머, 배치 잡 등 다양한 진입점에서 동일한 비즈니스 로직을 안전하게 재사용할 수 있게 되었습니다. ### 규모 확장에 대응하는 클린 아키텍처와 모노레포 * **모노레포 도입의 배경:** 머니, 포인트, 빌링 등 도메인이 늘어남에 따라 여러 저장소를 관리하는 비용이 증가했고, 이를 효율적으로 통합 관리하기 위해 하나의 저장소에서 여러 서비스를 운영하는 모노레포 구조를 채택했습니다. * **계약 기반의 모듈 분리:** 각 도메인을 `contract(인터페이스)`와 `impl(구현체)` 모듈로 쪼개어 의존성 규칙을 강제했습니다. 다른 모듈은 `contract`만 참조하게 하여 불필요한 내부 구현 노출을 차단했습니다. * **빌드 성능 및 생산성 최적화:** Gradle의 `api`와 `implementation` 구성을 활용해 컴파일 시점의 의존성을 제어함으로써, 대규모 프로젝트임에도 불구하고 빌드 시간을 단축하고 변경 영향도를 최소화했습니다. 아키텍처에는 정답이 없으며, 조직의 규모와 비즈니스의 현재 단계에 가장 적합한 형태를 선택하는 것이 중요합니다. 당근페이의 사례처럼 초기에 과도한 설계를 지양하되, 서비스 성장 속도에 맞춰 구조적 제약을 단계적으로 도입함으로써 기술 부채를 통제하고 개발 생산성을 유지하는 전략을 권장합니다.

AWS 유럽 소버린 클라우 (새 탭에서 열림)

AWS가 유럽의 공공 부문과 고도로 규제된 산업의 디지털 주권 요구사항을 충족하기 위해 'AWS 유럽 소버린 클라우드(AWS European Sovereign Cloud)'의 정식 출시를 발표했습니다. 이 서비스는 기존 AWS 리전과 물리적·논리적으로 완전히 분리된 독립적인 인프라를 제공하며, 모든 데이터와 운영 제어권을 유럽 연합(EU) 내에 유지하도록 설계되었습니다. 이를 통해 유럽 고객들은 강력한 보안과 기술적 통제력을 갖춘 환경에서 최신 클라우드 기술을 활용하여 규제 준수와 혁신을 동시에 달성할 수 있게 되었습니다. ### 유럽 내 완전 독립형 인프라 가동 * **지리적 격리:** 첫 번째 리전은 독일 브란덴부르크에 위치하며, 기존의 글로벌 AWS 리전들과는 물리적으로나 시스템적으로 완전히 분리되어 운영됩니다. * **운영 자율성:** 중복된 전력 및 네트워킹 시스템을 갖춘 여러 가용 영역(Availability Zones)을 포함하며, 외부 세계와의 연결이 끊긴 상황에서도 지속적으로 작동할 수 있도록 설계되었습니다. * **독립적 거버넌스:** 유럽 내 독립적인 운영 주체에 의해 관리되며, 데이터 저장부터 처리까지 모든 과정이 유럽 사법권 체제 아래에서 투명하게 관리됩니다. ### 데이터 주권 및 규제 요구사항 최적화 * **엄격한 통제권:** 데이터 레지던시, 운영 제어 및 거버넌스 독립성에 대한 복잡한 규제 요구사항을 해결하여 공공기관 및 금융, 의료 등 규제가 엄격한 산업군에 최적화된 환경을 제공합니다. * **온프레미스 대체:** 기능이 제한된 기존의 온프레미스 환경이나 파편화된 소버린 솔루션 대신, AWS의 방대한 서비스 포트폴리오를 그대로 활용할 수 있는 완전한 클라우드 기능을 제공합니다. * **법적 및 기술적 보장:** 강력한 기술적 제어와 법적 보호 장치를 결합하여 유럽 고객들이 요구하는 최상위 수준의 주권 보증을 실현했습니다. ### 유럽 전역으로의 확장 및 유연한 배포 * **지역 확장 계획:** 독일을 시작으로 벨기에, 네덜란드, 포르투갈에 새로운 '소버린 로컬 존(Sovereign Local Zones)'을 구축하여 유럽 전역으로 서비스 범위를 넓힐 예정입니다. * **하이브리드 지원:** 고객의 자체 데이터 센터에서 사용할 수 있는 'AWS Outposts'나 전용 로컬 존, AI 팩토리 등을 통해 고객이 원하는 위치에서 주권 클라우드 인프라를 확장할 수 있습니다. * **풍부한 서비스 생태계:** 초기 출시 단계부터 보안, 컴퓨팅, 스토리지 등 핵심 서비스를 포함한 포괄적인 AWS 서비스 세트를 제공하여 기술적 제약 없는 전환을 지원합니다. 유럽 연합 내에서 엄격한 규제 준수가 필수적인 조직이라면, AWS 유럽 소버린 클라우드를 통해 데이터 주권 문제 해결과 현대적인 클라우드 네이티브 아키텍처 도입이라는 두 가지 목표를 동시에 검토해 보시기 바랍니다.

Kanana-2 개발기 (1): Pre-training에서의 의사결정들을 중심으로 - tech.kakao.com (새 탭에서 열림)

카카오는 전문가 혼합(MoE) 아키텍처를 적용하여 추론 효율을 극대화한 'Kanana-2' 모델 시리즈를 공개하고, 이를 확장한 155B 규모의 대형 모델 학습 과정과 기술적 노하우를 공유했습니다. 이번 개발의 핵심은 Muon 옵티마이저와 MuonClip 등의 최신 기술을 도입하여 대규모 학습의 안정성을 확보하고 비용 효율성을 높인 데 있습니다. 특히 한국어 LLM 생태계의 연구 기반을 넓히기 위해 합성 데이터가 포함되지 않은 순수 베이스 모델을 공개함으로써 지속 가능한 AI 연구 환경 구축을 목표로 합니다. **전문가 혼합(MoE) 아키텍처와 효율성** * 전체 32B 파라미터 중 추론 시에는 3B만 활성화하도록 설계하여, 거대 모델의 지능을 유지하면서도 연산 비용을 획기적으로 낮췄습니다. * MoE 학습에 필수적인 커널들을 직접 개발하여 적용함으로써 성능 손실 없이 학습 속도를 높이고 메모리 사용량을 줄였습니다. * 현재 학습 중인 155B 모델(활성 17B)은 8.9T 토큰 학습만으로도 MMLU, KMMLU 등 주요 벤치마크에서 글로벌 경쟁 모델 대비 우수한 성능을 입증하고 있습니다. **연구를 위한 통제된 테스트베드 구축** * 'Kanana-2-30b-a3b-base-2601' 모델은 성능 향상을 유도하는 합성 추론(Reasoning) 데이터를 의도적으로 배제하고 학습되었습니다. * 이는 미세 조정이나 강화 학습 시 발생하는 데이터 불일치 현상을 연구하기 위해, 오염되지 않은 깨끗한 '베이스 모델'이 필요한 연구자들을 위한 결정입니다. * 한국어 LLM 커뮤니티가 모델의 변화 과정을 정밀하게 측정하고 추론 연구를 지속할 수 있는 기초 자산 역할을 수행합니다. **Muon 옵티마이저와 Polar Express 적용** * 기존의 AdamW를 대체하여 파라미터 업데이트 시 그라디언트를 직교화(Orthogonalize)하는 Muon 옵티마이저를 채택하여 학습 효율을 높였습니다. * 업데이트 행렬 계산 시 일반적인 Newton-Schulz 알고리즘 대신, 정확도가 더 높은 Polar Express 알고리즘을 사용해 대규모 학습 후반부의 노이즈를 줄였습니다. * RMSNorm의 파라미터화와 학습률(LR) 조정 등 세부적인 디테일을 최적화하여 수천억 규모의 모델에서도 안정적인 수렴을 달성했습니다. **MuonClip을 통한 대규모 학습 안정화** * 대형 모델 학습 시 발생하는 로짓 폭주(Logit Explosion)를 방지하기 위해 Kimi-K2에서 제안된 MuonClip 기법을 도입했습니다. * 효율적인 연산을 위해 Flash Attention 커널을 수정하여 내부의 Max Logit 값을 실시간으로 반환받아 모니터링과 클리핑에 활용했습니다. * 실험 결과, MuonClip은 높은 학습률 설정에서도 모델이 발산하지 않도록 잡아주며, 훈련이 수렴하더라도 발생할 수 있는 잠재적인 성능 저하 요인을 효과적으로 억제함을 확인했습니다. 카카오의 Kanana-2 개발 사례는 단순한 모델 공개를 넘어, 대규모 MoE 모델 학습에서 발생하는 엔지니어링 이슈를 해결하는 구체적인 방법론을 제시합니다. 특히 고성능 오픈소스 모델을 활용하려는 개발자와 연구자들에게는 효율적인 추론 구조와 더불어, 탄탄한 기초 모델을 기반으로 한 한국어 특화 AI 연구의 새로운 가능성을 제공할 것입니다.