기업 기술블로그의 Architecture 관련 글 314개
들어가며 아임웹의 서비스 진입 경로는 AWS 계정과 VPC, 클러스터에 걸쳐 확장되어 왔습니다. 그 과정에서 로드밸런서 계층의 한도에 부딪혔는데, 상향 신청으로 해결되는 한도도 있었지만, ECS 서비스당 Target Group 5개 제한처럼 상향 대상이 아닌 것도 섞여 있었습니다. 이를 계기로 마이크로 프론트엔드(Micro-Frontends, MFE) 서빙 경로를 대상으로 서비스 네트워크를 재설계했습니다. 재설계의 골자는 외부 진입점(North
젭(ZEP) 소개 젭은 온라인 메타버스 플랫폼 ZEP을 운영하는 스타트업입니다. ZEP은 사용자들이 온라인 공간에서도 자연스럽게 만나고 소통할 수 있는 경험을 제공하며, 오프라인의 물리적 제약을 넘어 다양한 활동이 이루어질 수 있는 환경을 만들어가고 있습니다. ZEP은 400만 MAU 규모의 서비스 환경에서 WebRTC 기술을 내재화해 안정적인 동시 스트리밍 경험을 제공하고 있으며, 대규모 동시 접속과 상호작용을 처리하는 게임 서버, 웹 […]
안녕하세요, 카카오스타일 지그재그 전시BE파트 밀리입니다. 전시 개발자로서 혹시 이런 하루를 보내고 있나요?
Lambda로 서버리스 워크로드를 설계하다 보면 비슷한 고민을 반복해서 만나게 됩니다. 15분 한도를 넘는 장기 워크 플로우는 어떻게 처리할지, 호출 사이에 실행 환경이 멈추는 freeze(일시 정지) 동작이 상시 트래픽 서비스에 맞는지, 사용자나 AI가 생성한 코드를 어디서 안전하게 실행할지 같은 질문입니다. 지금까지는 이 답을 Lambda 외부에서 찾는 경우가 많았습니다. 워크 플로우는 AWS Step Functions로 옮기고, 상시 워크
생성형 AI가 빠르게 발전하면서 IT 업계에서는 자연스럽게 이런 질문이 나오고 있습니다. “AI가 코드를 작성하고 아키텍처까지 제안하는 시대에 클라우드 엔지니어의 역할은 어떻게 달라질까?“ 최근의 AI는 Terraform 코드를 생성하고, Kubernetes Manifest를 작성하며, 로그를 분석하고, AWS 서비스 구성을 제안하는 수준까지 발전했습니다. 하지만 클라우드 엔지니어, 특히 Solutions Architect의 핵심 역할은 원래부
GS Neotek은 AWS 프리미어 파트너로, 다수의 고객에게 클라우드 마이그레이션·현대화·운영 서비스를 제공하며 생성형 AI 도입을 지원하고 있습니다. 이 글은 여러 조직에 코딩 어시스턴트 도입을 지원하며 축적한 경험을 바탕으로, LLM Gateway 없이도 사용자별 비용을 통제하는 경량 아키텍처를 정리한 것입니다. Amazon Bedrock을 통해 Claude Code와 같은 코딩 어시스턴트를 사용하기 위한 기본 조건은 의외로 단순합니다.
AWS Elemental MediaLive의 썸네일 API와 Amazon Rekognition Custom Labels, AWS Step Functions를 결합하여 라이브 방송 화면을 AI가 실시간으로 인식하고, 하프타임 등 브레이크 진입 시 송출되는 필러(Filler) 영상을 감지하여 SCTE-35 광고 신호를 자동으로 삽입하는 아키텍처를 소개합니다. 소개 라이브 스트리밍과 광고 삽입 운영의 과제 라이브 스트리밍(특히 스포츠 중계)에서 SC
도메인별 모듈 경계가 AI 에이전트의 코드 탐색 범위와 컨텍스트 효율에 미치는 영향
실리콘투는 한국의 뷰티 브랜드를 전 세계 고객에게 유통하는 글로벌 플랫폼 기업입니다. 수많은 브랜드와 상품, 국가별 물류가 실시간으로 맞물려 돌아가고, 이 방대한 흐름을 CMS, WMS, OMS를 비롯한 여러 사내 시스템이 나눠 맡습니다. 사업이 커질수록 업무 규칙도 함께 불어났고, 그 규칙은 저장 프로시저(SP, Stored Procedure. 데이터베이스에 넣어 두고 불러 쓰는 SQL 로직 묶음), 소스 코드, 그리고 여기저기 […]
Amazon Bedrock 앞에 LLM 게이트웨이(이하 게이트웨이)를 두면 편의와 통제를 얻지만, 그 대가로 Amazon Bedrock이 보는 호출자 신원과 모델별 관측 지점이 게이트웨이 뒤로 흐려지는 사각지대가 생깁니다. 이 글은 잘 알려진 레퍼런스 아키텍처를 출발점으로, 그 사각지대를 Amazon Bedrock 네이티브 기능으로 보완하는 방법 (호출자 감사 추적과 모델별 관측 및 거버넌스)을 다룹니다. <Claude Code → LLM 게이
기업 AI 도입은 늘었지만 ROI로 이어지지 않는 이유는 모델이 아니라 ‘의미 계층’의 부재다. 온톨로지는 기업의 개념·관계·규칙을 기계가 읽을 수 있게 고정하는 의미 지도이며, 에이전트 시대에는 운영 신호와 결합된 ‘살아 있는’ Active Ontology(컨텍스트 그래프)가 신뢰·권한·감사추적을 가능하게 한다. HelpNow Ontology Studio는 자동 구축, 지속 갱신, 에이전트 소비 가능성을 통해 AX 트랜스포메이션의 코어 레이어
형식이 제각각인 수천만 행 시장 데이터를 활용해, 자연어 질문에 검증된 수치로 답하는 사내 AI 애널리스트 플랫폼을 만든 개발기입니다. LLM은 질문 해석만 담당하고 수치 계산은 결정적 코드가 수행하는 아키텍처부터, 결정적 프리파서가 LLM 추출을 덮어쓰는 하이브리드 설계, 정답표를 코드로 고정하는 이중 평가 체계(오라클 테스트 + 골드 평가 하니스)까지 구체적인 버그 해부와 함께 공유합니다. 여기에 개발 전 과정을 멀티에이전트 AI 워크플로로
AWS S3에서 다른 오브젝트 스토리지로 이전하며 확인한 Port와 Adapter의 조건, 그리고 아키텍처 경계가 지켜주지 못하는 영역
에이전트에게 일을 맡길 때, 스스로 알아서 하게 둘 것인가 아니면 정해진 순서대로 하나씩 시킬 것인가. 이 선택이 시스템 전체의 성격을 바꿉니다. 어느 한쪽이 더 나은 것이 아니라, 각자 비싸지는 지점이 다를 뿐입니...
본 블로그 시리즈는 A1Mobilsoft, Megazone, AWS 가 공동 작성 하였으며, 두 편으로 이루어져 있습니다. 각 편의 구성은 다음과 같습니다. 1편 (0~3장, 현재 글): 문제 정의와 3-에이전트 아키텍처 설계 2편 (4~7장): 세 에이전트 구현 우여곡절과 사람 vs AI 검증 1편: 슬랙 #운영개발문의 채널의 고통에서 출발해, 왜 Knowledge·Code·DB 세 에이전트 구조로 갈랐는가 수 시간씩 늘어지던 운영 문의를 [
해당 포스트는 당근의 최용환님, 조승환님, 오현준님과 함께 작성했으며, AWS Summit Seoul 2026에서 발표한 세션 내용을 기반으로 합니다. 이 시리즈의 1부에서는 서명키 보안의 중요성과 당근이 AWS CloudHSM과 AWS KMS를 비교하여 하이브리드 전략을 선택한 과정을 다루었습니다. 이번 글에서는 CloudHSM 아키텍처를 어떻게 설계했는지, 그리고 서명키에 대한 접근을 어떻게 다계층으로 보호했는지 공유합니다. CloudHSM
hearth를 직접 만든 이유와 설계 과정을 소개합니다
흩어진 도메인 지식을, 개발 루프 안에서 스스로 걸러지고 자라는 그래프로
페이지 2 / 18 (총 314개)
