• None VPC 내에서 네트워크 가상 어플라이언스 간의 동적 라우팅을 간소화하기 위해 사용할 수 있는 완전 관리형 라우팅 제어 서비스• None BGP(Border Gateway Protocol)를 활용하여 네트워크 경로를 동적으로 학습하고, VPC 라우팅 테이블을 자동으로 갱신• None 사용자 지정 스크립트나 오버레이 네트워크 없이도 경로 학습 및 전파가 가능하도록 지원• None 가상 방화벽, IDS/IPS 등 네트워크 가상 어플라이언스(NVA)와의 통합을 간소화VPC Route Server를 이해하기 위한 주요 구성 요소 및 용어• None Route Server가 BGP 피어 등으로부터 학습한 모든 라우팅 정보를 저장하는 데이터베이스• None 네트워크의 최신 토폴로지를 반영하며 지속적으로 업데이트됨• None FIB에 반영할 최적 경로 선정을 위한 평가 기준 역할 수행• None RIB에 저장된 정보 중에서 Route Server가 최적 경로로 판단한 경로만을 선별하여 저장• None 실제 VPC의 라우팅 테이블에 설치되는 경로 집합• None RIB에 변화가 생기면, FIB도 함께 재계산되어 최신 경로를 반영• None AWS에서 관리하는 서브넷 내부 구성 요소• None Route Server와 BGP 피어 간의 BGP 세션을 직접 연결할 수 있도록 하는 인터페이스 역할• None Route Server Endpoint와 AWS 내 배포된 장비(예: 가상 방화벽, NAT 장비 등) 간의 BGP 세션• None 다음 조건을 충족해야 함: - VPC 내에서 ENI(탄력적 네트워크 인터페이스)를 가질 것 - BGP 프로토콜을 지원하고 세션을 직접 개시할 수 있을 것• None 특정 VPC와 Route Server 간에 BGP 기반 라우팅 동기화를 위한 연결 관계• None 이 연결을 통해 VPC 라우팅 테이블에 BGP 기반 동적 경로 전파 가능• None 활성화된 경우, FIB에 있는 경로를 지정된 라우팅 테이블에 자동으로 설치• None 장애 발생 시, 경로 철회(Withdraw)를 자동 반영하여 즉각적인 트래픽 Re-라우팅 가능다음은, 이번 포스팅에서 다룰 구성도입니다.하나의 VPC 안에 Public Subent 2곳에는 네트워크 가상 어플라이언스(NVA) 역할을 할 ZIGI-Proxy를 2대 구성합니다.VPC Route Server를 만들어서, ZIGI-VPC1에 연결하고,Private Subnet 2곳에는 VPC Route Server와 연결 할 Endpoint를 구성합니다.가운데 Private Subnet에서는 VPC Router Server와 NVA (ZIGI-Proxy)간의 BGP 연동을 통해서,인터넷으로 가는 Default 경로를 Proxy1 으로 보낼지, Proxy2로 보낼지에 대한 라우팅 경로를라우팅 테이블에서 반영합니다.VPC 대시보드에서 Route Servers 메뉴로 들어가서,Route Server 이름을 ZIGI-RT라고 하고,Route Server에서 BGP 연동에 사용 할 ASN(AS Number)를 설정합니다.BGP ASN은 1-424967295까지 설정이 가능하지만,Private ASN인 4512–65534 (16-bit ASN) 혹은 4200000000–4294967294 (32-bit ASN)을 사용하는 것을 권고합니다.본 포스팅에서는 나머지는 기본 값으로 두고 생성합니다.참고로, Persist routes는 모든 BGP 세션이 종료된 이후에 경로가 라우팅 서버의 라우팅 Database로 유지 여부를 결정합니다.Enable SNS notifications은 BGP의 상태 값을 SNS 알림을 활성화 하게 합니다.ZIGI-RT라는 이름으로 VPC Route Server가 다음과 같이 생성되었습니다.이제 Route Server를 VPC에 연결합니다.Router Server를 'ZIGI-VPC'라는 이름의 VPC에 연결합니다.Route Server는 1개의 VPC에만 연결이 가능하고,VPC는 최대 5개의 Router Server 연결이 가능합니다. (Support Center를 통해서 한도 증가 가능)Route Server의 경로(Route) 정보를 전파할 서브넷 설정Route Server에서 Route 정보를 전파(Propagations)할 서브넷을 설정합니다.Route Server와 BGP를 연동해서 받은 네트워크 대역 정보를 Route Server의 Propagations에서 설정한 서브넷으로 광고를 하게 됩니다.ZIGI-RT라는 Route Server의 Propagations 메뉴에서 'Enable propagation'을 클릭합니다Pri-RT1이라는 Route table에 네트워크 대역을 광고하기 위해서 선택합니다Route Server와 VPC를 연결하고 난 이후에는 VPC Route Server의 Endpoint를 생성합니다.Route Server와 네트워크 가상 어플라이언스 역할을 하는 ZIGI-Proxy 간의 BGP 연동은 이 Endpoint를 통하게 됩니다.즉, Route Server와 BGP Peer(여기에서는 ZIGI-Proxy) 간의 BGP 연결을 지원하는 관리형 구성 요소가 Endpoint입니다.Route Server Endpoint의 이름으로는 ZIGI-RT-EP1으로 하고,앞서 만든 Route Server를 선택합니다.그리고, Endpoint를 생성 할 Subnet을 지정합니다.이중화를 위해서 서브넷 당 2개의 Endpoint를 만들어야 하지만본 포스팅에서 가용영역 2개에서 서브넷 당 1개의 Endpoint를 만들었습니다.이제 Route Server Endpoint에서 ZIGI-Proxy와 BGP 연동을 위해,Route Servrer peers를 추가 합니다.ZIGI-RT-EP1의 Endpoint에서 Route server peers 메뉴에서,ZIGI-RT-EP1 Endpoint와 BGP를 연결한 Peer의 이름을 'ZIGI-RS-Peer1'로 하고,ZIGI-Proxy1와 BGP 연동을 하기 때문에,ZIGI-Proxy1의 IP 주소를 Peer address와ZIGI-Proxy1에서 사용 할 ASN인 6

네이버 사내 기술 교류 행사인 NAVER ENGINEERING DAY 2025(5월)에서 발표되었던 세션을 공개합니다. 발표 내용대규모 쿠버네티스 GPU 클러스터에서 자체 HPA 시스템 구축을 통해 글로벌 유저 트래픽에 동적으로 대응하는 AI 서비스 오토스케일링을 적용한 사례를 소개합니다.발표 대상AI 서비스 운영을 위해 GPU 서버 기반의 Kubernetes 클러스터 도입을 고려하는 엔지니어AI 서비스 오토스케일링을 Kubernetes 에서 도입하고자 하는 엔지니어기본 HPA 보다 고도화된 방법으로 오토스케일링을 도입하고자 하는 엔지니어목차왜 SNOW는 GPU orchestration이 필요한가GPU 기반 서비스의 오토스케일링이 어려운 이유KEDA: Event-Driven AutoscalerSNOW의 GPU Orchestration 시스템 NAVER ENGINEERING DAY란? NAVER에서는 사내 개발 경험과 기술 트렌드를 교류를 할 수 있는 프로그램이 많이 있습니다. 그중 매회 평균 70개 이상의 발표가 이루어지는 NAVER ENGINEERING DAY를 빼놓을 수 없는데요. 2016년부터 시작된 ENGINEERING DAY는 실무에서의 기술 개발 경험과 새로운 기술과 플랫폼 도입 시 유용하게 활용될 수 있는 팁 등을 공유하며 서로 배우고 성장하는 네이버의 대표적인 사내 개발자 행사입니다. 올해 진행된 NAVER ENGINEERING DAY의 일부 세션을 공개합니다.

이 글은 AI 코딩 어시스턴트 기술의 시장 동향부터 주요 도입 사례, 기반 모델 비교, 솔루션 특징, 활용 시나리오까지 전반적인 흐름을 정리한 기술 블로그입니다.글로벌 및 국내 기업들의 실제 도입 사례를 중심으로, 어떤 방식으로 AI 어시스턴트를 활용하고 있는지 상세히 소개하며, Claude, DevStral, DeepSeek 등 최신 코딩 특화 모델 성능 비교도 함께 다룹니다.또한 다양한 솔루션의 장단점과 지원 환경을 비교하고, 개발 생산성 향상·테스트 자동화·보안 점검 등 실무 중심의 활용 사례도 구체적으로 제시합니다.AI 코딩 어시스턴트 도입을 검토 중인 조직이나 팀에게 실질적인 비교 기준과 전략 수립에 도움이 되는 현실적인 인사이트를 제공합니다.안녕하세요, 기술전략팀 이수경입니다. 최근 AI 코딩 어시스턴트는 코드 자동 완성을 넘어 테스트 생성, 리뷰, 보안 점검까지 지원하며 실제 개발 생산성에 기여하는 실용적 도구로 주목받고 있습니다.저희 회사도 이러한 흐름에 발맞춰, 사내 IDE 기반 AI 개발 환경과 내부 코딩 플랫폼을 운영하며 AI 기술을 활용한 개발 효율화 방안을 꾸준히 모색하고 있습니다.특히 최근에는 AI 코딩 어시스턴트 관련 기술과 시장 흐름이 빠르게 진화하고 있어, 글로벌 동향은 어떻게 바뀌고 있는지, 주요 기업들은 어떤 방식으로 대응하고 있는지를 살펴보게 되었습니다.이 글에서는 AI 코딩 어시스턴트의 시장 동향, 도입 사례, 주요 기술 및 모델 비교, 그리고 실제 활용 시나리오 중심으로 전반적인 흐름을 정리합니다.기업들의 AI 코딩 어시스턴트 도입이 확산되면서, 관련 시장 역시 빠르게 확대되고 있습니다. 글로벌 리서치 기관들의 전망을 바탕으로 시장 흐름을 정리하면 다음과 같습니다.• OpenAI, AI 코딩 스타트업 Windsurf(구 Codeium) 인수(약 30억 달러)→ ChatGPT의 에이전트화 및 코딩 지원 기능 강화• 애니스피어(Anysphere, AI IDE “Cursor” 개발사), 기업 가치 99억 달러 평가 → 차세대 AI IDE 시장 주도국내 시장의 경우 2025년 기준 수백억 원 규모로 성장할 것으로 예상되며, 주요 대기업을 중심으로 파일럿 단계를 거쳐 본격적인 확산 국면에 진입하고 있습니다. 국내 주요 기업들의 도입 사례를 살펴보겠습니다.국내 주요 기업 AI 코딩 어시스턴트 도입 사례 요약국내 주요 기업들은 각자의 보안 환경과 협업 도구에 따라 AI 코딩 어시스턴트 도입 방식에 차이를 보이고 있습니다.자체 구축, 상용 솔루션 도입, 오픈소스 기반 도구 연동까지 다양하지만, 도입 목적은 공통적으로 코드 작성 자동화, 리뷰 효율화, 테스트 생성 지원 등 개발 생산성 향상에 집중되어 있습니다.이제, 다음으로는 이러한 AI 코딩 어시스턴트의 기반이 되는 코딩 지원 모델들을 비교해 보겠습니다.AI 코딩 어시스턴트의 실질적인 성능은 어떤 언어 모델(LLM)을 기반으로 하느냐에 따라 큰 차이를 보입니다. 특히 코드 생성, 디버깅, 리뷰 자동화 등 복잡한 작업의 정확도와 효율은 모델의 품질에 직접적으로 영향을 받습니다.최근에는 이러한 개발 작업에 특화된 LLM이 빠르게 등장하고 있으며, 그 성능을 비교하고 평가하는 지표로 SWE-bench가 대표적으로 활용되고 있습니다.아래는 2025년 6월 기준, 주요 AI 코딩 지원 모델들을 벤치마크 성능, 기능적 특징, 지원 도구 기준으로 정리한 내용입니다.실제 시장과 실무 현장에서 주목받고 있는 모델들은 다음과 같이 요약할 수 있습니다.각 모델은 성능, 라이선스, 보안성, 오픈소스, 지원 IDE 및 도구 등 기업 환경에 따라 선택의 우선순위가 달라질 수 있습니다.예를 들어, Claude Opus 4는 성능 면에서 가장 우수하지만 API 기반으로만 제공되며, DeepSeek R1이나 Mistral DevStral은 성능 대비 오픈소스 및 온프레미스 활용 가능성이 높아 사내 인프라 환경에 맞춰 유연한 도입이 가능합니다.Claude Opus 4와 DevStral의 SWE-Bench는 아래 벤치마크에서 상세 수치를 확인할 수 있습니다.AI 코딩 어시스턴트의 도입은 단순히 모델 선택을 넘어서, 개발 환경 통합성, 보안 요구사항, 예산, 협업 도구와의 호환성 등 여러 요소를 고려해야 합니다.특히 기업 입장에서는 자체 IDE 통합 여부나 온프레미스 설치 가능성 등이 도입 결정에 중요한 영향을 미치게 됩니다.아래는 실제 시장에서 사용되는 다양한 AI 코딩 어시스턴트 솔루션을 기능, 장단점, 지원 환경 등 기준으로 비교한 내용입니다.• Cursor : 강력한 프로젝트 맥락 이해, 다중 파일 에이전트 모드, 다만 고비용 및 불안정성 일부 존재• Windsurf (Codeium 후속) : 무료 버전도 존재, 직관적 UI와 Cascade 에이전트로 멀티스텝 작업 지원• IBM watsonx : 엔터프라이즈 특화, 고비용이나 강력한 거버넌스 및 자바 현대화에 강점경량 오픈소스부터 엔터프라이즈 특화 솔루션까지, 개발팀의 목적과 여건에 맞춰 단계적으로 도입하고, 파일럿 테스트를 통해 실효성을 검증한 뒤 점진적으로 확산하는 전략이 현실적인 접근이라 할 수 있습니다.AI 코딩 어시스턴트의 활용 분야와 시나리오에 대해 알아 보겠습니다.AI 코딩 어시스턴트 도입 시 다음과 같은 장점이 있습니다.AI 코딩 어시스턴트는 단순한 코드 자동 완성을 넘어, 개발 생산성과 품질을 동시에 향상시킬 수 있는 현실적인 도구로 자리잡고 있습니다.글로벌 기업뿐만 아니라 국내 주요 기업들도 각자의 환경과 전략에 맞춰 빠르게 대응하고 있으며, 이제는 실제 업무 적용과 내부 최적화가 중요한 단계에 이르렀습니다.기업마다 요구사항은 다르지만, 파일럿 적용을 통해 도입 효과를 검증하고, 적절한 모델과 솔루션을 선택하는 ‘점진적 도입 전략’이 가장 현실적인 접근이라 할 수 있습니다.이 글이 AI 코딩 어시스턴트를 도입하고자 하는 분들께 현실적인 인사이트를 제공했기를 기대합니다.• 조직에서 AI 코딩 솔루션 도입, 어떻게 시작할까?

안녕하세요. 오피스기술검증팀 QA 엔지니어 양승혁입니다.최근 다양한 산업 분야에서 고객 서비스(CS)와 장애 대응은 기업과 제품의 이미지를 결정짓는 핵심 요소가 되었습니다.이런 흐름 속에서, 사전에 품질을 보장하며 장애 발생을 예방할 수 있는 전략적 QA(품질 보증) 활동과 리스크 관리의 중요성이 더욱 강조되고 있습니다.이 글에서는 QA의 개념과 주요 업무, 기대 효과에 대해 설명하고, 이를 제대로 수행하지 못했을 때 발생한 실제 사례를 통해 QA 리스크 관리의 중요성을 조명합니다. 또한 장애가 발생했을 때 효과적으로 대응하기 위한 전략까지 함께 살펴보겠습니다.품질검증(QA)과 리스크 관리의 중요성우리가 어떤 제품이나 서비스를 사용할 때 기대하는 가장 기본적인 전제는 “내가 원하는 기능이 문제 없이 잘 작동하는 것”입니다.이러한 기대를 충족시키기 위해 기업들이 수행하는 핵심적인 활동이 바로 품질보증(QA, Quality Assurance)입니다.QA는 제품이나 서비스가 일정한 품질 기준을 충족하도록 보장하는 체계적인 활동으로, 단순한 검수 수준을 넘어 결함을 사전에 예방하고, 제품의 전반적인 신뢰성을 높이는 데 목적이 있습니다. 이는 소프트웨어뿐 아니라 제조업, 서비스업 등 다양한 산업에서 필수적으로 수행되며 다음과 같은 주요 목표를 가집니다.• 고객 만족도 향상이처럼 QA는 단순한 품질 검토 단계를 넘어 기업의 경쟁력과 직결되는 핵심 프로세스입니다.아무리 철저한 QA를 수행하더라도, 예기치 못한 문제가 발생할 가능성은 언제든 존재합니다. 따라서 QA 활동이 실질적인 효과를 발휘하려면, 반드시 리스크 관리가 함께 고려되어야 합니다.제품 또는 서비스 개발 과정에서 발생할 수 있는 잠재적인 위험 요소를 사전에 식별하고, 그로 인한 부정적인 영향을 예방하거나 최소화할 수 있는 대응 전략을 수립하는 과정입니다.이 과정을 소홀히 하면, 출시 이후 예상치 못한 결함이나 품질 문제가 발생하여 브랜드 신뢰도 하락, 고객 만족도 저하, 비용 증가 등의 부작용이 발생할 수 있습니다. 특히 서비스 규모가 커지고 고객 접점이 다양해질수록, 사전 리스크 관리는 더욱 중요한 QA의 연장선이 됩니다.실질적인 품질 확보를 위해 QA와 리스크 관리는 반드시 함께 설계되어야 하며, 이를 위한 핵심 활동은 다음과 같습니다.• 리스크 식별: 개발 초기부터 발생 가능성이 있는 위험 요소를 예측하고 분석• 리스크 분석 및 평가: 각 리스크의 영향도와 발생 가능성을 평가하고 우선순위를 정함• 리스크 대응 계획 수립: 우선순위에 따른 대응 방안을 마련하고, 실제 문제 발생 시 신속하게 대처이러한 활동은 국제적으로도 PMBOK, PRINCE2 등 다양한 프로젝트 관리 표준에서 리스크 관리의 핵심 프로세스로 정의되어 있으며, 아래와 같은 절차를 따릅니다.이와 같은 리스크 관리 프로세스는 전사적 프로젝트 운영의 관점에서 설정된 것이며, 실제 QA 단계에서는 이를 기반으로 보다 실질적이고 실행 가능한 테스트 전략으로 구체화됩니다.QA에서는 특히 리스크 기반 테스트(Risk-Based Testing)라는 접근을 통해, 리스크가 높은 기능부터 우선순위를 정해 테스트를 수행하고, 리소스를 효율적으로 배분하는 방식이 효과적으로 활용됩니다.아래는 리스크 기반 테스팅의 실제 프로세스를 도식화한 것입니다. 리스크 항목을 식별하고 분석한 후, 이를 바탕으로 테스트 전략을 수립합니다.이처럼 리스크 관리가 잘 수행되면, 개발 과정의 시행착오를 줄일 수 있고, 출시 전 제품의 품질을 확보할 수 있습니다. 이는 기업이 불필요한 비용을 줄이고, 신뢰성 높은 제품을 제공하며, 시장에서 안정적으로 성장하는 데 핵심적인 역할을 합니다.따라서 QA와 리스크 관리는 단순히 품질을 보장하는 차원을 넘어, 기업의 성공적인 운영과 지속적인 경쟁력 확보를 위한 필수 전략이라 할 수 있습니다.이제 본격적인 테스트 전략을 살펴보기에 앞서, 리스크 관리에도 다양한 유형이 존재한다는 점을 짚고 넘어갈 필요가 있습니다.리스크 관리는 일반적으로 프로젝트 리스크 관리와 품질 리스크 관리로 구분됩니다.프로젝트 리스크 관리는 일정 지연, 예산 초과, 외주 협력 실패 등 프로젝트 전반의 성공에 영향을 미치는 리스크를 다루며, QA 일정을 포함한 전반적인 진행 상황에도 간접적인 영향을 줍니다.반면, 품질 리스크 관리는 테스트 누락, 요구사항 미반영, 성능 저하, 보안 취약점 등 제품의 품질에 직접적으로 영향을 미치는 요소들을 관리합니다. 이 영역은 QA 활동의 핵심으로, 사전에 테스트 전략을 수립하고 결함을 예방하는 역할을 수행합니다.이처럼 두 리스크 관리 영역에서 각각의 역할은 다르지만 모두 장애를 사전에 예방하고 제품 품질을 높이기 위한 중요한 기반이 됩니다.예를 들어, 외주 업체의 납기가 지연되면 전체 일정에 차질이 생기고, 테스트 일정이 줄어드는 문제가 발생할 수 있습니다. 이는 프로젝트 전반에 영향을 주는 리스크로, QA 활동에도 직간접적인 부담을 주게 됩니다.반면, 테스트 단계에서 주요 기능이 누락되어 제품 결함으로 이어지는 상황은 품질 자체에 대한 리스크로, 사용자에게 직접적인 피해를 주고 서비스 신뢰도에 영향을 미칩니다.QA는 이처럼 제품의 품질을 중심으로 움직이지만, 프로젝트 일정이나 리소스 변화와 같은 외부 변수에도 유연하게 대응해야 합니다. 예정된 테스트가 제대로 수행되지 못하면, 단순한 오류 하나가 심각한 장애로 이어질 수 있기 때문입니다.결국 품질 리스크와 프로젝트 리스크는 각각 다른 성격을 갖고 있지만, 실제 현장에서는 서로 맞물려 작동하며 함께 관리되어야 합니다. QA는 이러한 두 리스크를 모두 인식하고 조율하는 핵심적인 역할을 맡고 있으며, 이를 체계적으로 관리하고 사전에 결함을 차단하기 위해 다양한 테스트 기법을 활용합니다. 테스트는 단순한 검증을 넘어, 품질과 안정성을 확보하기 위한 가장 실질적인 리스크 대응 도구입니다.소프트웨어 테스트 방법론에는 기능 테스트, 회귀 테스트, 경계값 분석, 탐색적 테스트, 성능 테스트 등이 있습니다. 이 중에서도 기능 테스트와 회귀 테스트는 가장 보편적으로 사용되고 필수적으로 수행되는 기법입니다.기능 테스트는

안녕하세요. 커뮤니케이션 앱 LINE의 모바일 클라이언트를 개발하고 있는 Ishikawa입니다.저희 회사는 높은 개발 생산성을 유지하기 위해 코드 품질 및 개발 문화 개선에 힘쓰고 있습니다. 이를 위해 다양한 노력을 하고 있는데요. 그중 하나가 Review Committee 활동입니다.Review Committee에서는 머지된 코드를 다시 리뷰해 리뷰어와 작성자에게 피드백을 주고, 리뷰하면서 얻은 지식과 인사이트를 Weekly Report라는 이름으로 매주 공유하고 있습니다. 이 Weekly Report 중 일반적으로 널리 적용할 수 있는 주제를 골라 블로그에 코드 품질 개선 기법 시리즈를 연재하고 있습니다.이번에 블로그로 공유할 Weekly Report의 제목은 '사상누각'입니다.다음 는 '사용자 프로필'을 표시하기 위한 UI 모델입니다.이 인스턴스를 생성하기 위해 다음과 같은 빌더를 제공한다고 가정해 봅시다.여기서 는 인수를 호출한 후 수신자를 반환하는 함수입니다. 즉 는 를 에 대입한 후 를 반환합니다. 또한 은 인수가 이면 을 발생시키고, 이 아니라면 인수를 그대로 반환하는 함수입니다.위 코드의 문제는 무엇일까요?특별한 이유가 없다면 빌더 패턴 대신 생성자나 팩토리 함수를 사용하는 것이 더 바람직한 경우가 많습니다. 생성자나 팩토리 함수를 사용하면 꼭 전달해야 하는 인수를 누락해 발생하는 버그를 쉽게 방지할 수 있기 때문입니다.위 예시의 경우 의 생성자를 그대로 사용하면 충분합니다. 앞서 빌더에서는 과 가 필수였지만 이를 전달하지 않아도 컴파일 에러는 발생하지 않고 런타임 에러만 발생하는데요. 런타임 에러가 아니라 컴파일 에러로 결함을 검출할 수 있게 만들면 코드가 더 견고해집니다.물론 라이브러리나 플랫폼 상황에 따라 어쩔 수 없이 빌더 패턴을 사용해야 하는 경우도 있으며(Object–relational mapper 등), 그 밖에도 다음과 같은 상황에서는 빌더 패턴이 필요할 수 있습니다.• 필수 인수가 적고, 기본값이 존재하는 인수가 많은 경우• '생성 중'인 상태를 다른 클래스나 함수에 전달해야 하는 경우• 데코레이터 등에 대해 '마지막 작업'을 정의하고 싶은 경우1번과 2번의 경우 다른 방법으로 대체할 수 있는 경우도 있는데요. 하나씩 살펴보겠습니다.1: 기본값이 존재하는 인수가 많은 경우만약 선택적 인수가 많다면 프로그래밍 언어에 따라 기본 인수를 사용할 수 있습니다. 또한 인수 제공 패턴이 제한적이라면 생성자를 오버로드하는 것도 한 가지 방법이 될 수 있습니다.기본 인수를 사용할 수 없는 프로그래밍 언어에서는 빌더 패턴도 하나의 선택지입니다. 이 경우 필수 인수를 빌더 생성자로 전달하면 더욱 견고한 코드를 만들 수 있는데요. 다음 빌더에서는 필수 인수인 과 를 빌더의 생성자 인수로 전달받습니다.2: '생성 중' 상태를 처리해야 하는 경우아래와 같이 '생성 중'인 상태를 다른 함수 등에 전달하고 싶은 경우도 있습니다.그런데 위 코드의 의 인수 는 출력 인 수(out parameter)처럼 작동합니다. 일반적으로 코드 가독성 측면에서도 출력 인수보다는 반환값을 사용하는 것이 바람직하며, 반환값을 사용하면 다음과 같이 빌더 패턴을 생성자나 팩토리 함수로 대체할 수 있습니다.만약 인스턴스를 생성하는 로직이 파이프라인과 같은 경우, 각 구성 단계마다 다른 타입을 정의해서 유효하지 않은 상태를 제외할 수 있습니다. 다음 코드에서는 부여 전후에 과 로 타입을 구분합니다.3: '마지막 작업(terminal operation)'을 만드는 경우다음 조건에 해당할 때에는 빌더 패턴과 유사한 것을 사용하면 잘 작동할 수 있습니다.• 0회 이상인 임의의 횟수와 임의의 순서로 적용되는 '작업'이 있다.• '마지막 작업' 이후에는 위 작업이 금지된다.일반적으로 데코레이터 패턴에 마지막 작업을 추가하는 경우가 이에 해당합니다. 다음 코드는 이미지 편집에 이 패턴을 이용한 예시입니다.이렇게 하면 다음과 같은 순수한 데코레이터 패턴보다 가독성이 좋아집니다.

안녕하세요. DEVOCEAN AI Fellowship 7기에서 Computer Use Agent(CUA) 프로젝트를 진행 중인 장교철입니다.저번에 Computer Use Agent라는 개념을 해당 블로그 포스트 에서 소개해 드렸었죠.Computer Use Agent가 Multimodal LLM, Agent Ability를 사용해서 화면을 조종한다는 건 알겠는데,이게 실제로 어떤 식으로 조종하고 훈련이 되는 건지 아직 감이 안 잡히실 거라고 생각합니다.이번 포스트에서는 Computer Use Agent 분야에서 유명한 스타트업인 Multi-On과 스탠포드에서 공개한 AgentQ라는 Open Source GitHub repo를 직접 돌려보면서Computer Use Agent의 작동 방식에 대해서 이해해 보는 시간을 가져 보도록 하겠습니다!저번 포스트에서 소개해 드린 것처럼 Computer Use Agent는 MLLM과 AI Agent 기술을 기반으로 브라우저 환경, 모바일 혹은 웹 UI를 실제로 조작할 수 있는 Agent입니다.먼저, MLLM을 통해 Screenshot, DOM 정보, 그리고 유저의 instruction과 같은 정보를 인풋으로 받아 현재 컴퓨터 화면에 대한 유저의 의도를 파악합니다.그리고 Actionning, Planning, Memorizing, Tool Using 과 같은 AI Agent 기술을 사용하여 유저의 의도대로 컴퓨터 화면을 조작하여 컴퓨터 조작을 도와줍니다.일반적으로 브라우저를 조작할 때는 Playwright 혹은 Selenium 같은 툴을 많이 사용합니다.📝 AI Agent에 대한 자세한 설명은 아래 DEVOCEAN에 올라온 포스트들을 참고해주세요!• None 생성형 AI의 게임체인저, ReAct Agent를 알아보자• None Agentic AI 개념 정리: 에이전트와 워크플로우의 스펙트럼🤖 포스트 작성자의 자비스 만들기 프로젝트Computer Use Agent를 언제 사용할 수 있을지를 얘기하려면 먼저 제가 CUA에 관심을 갖게 된 계기에 대해서 설명해 드리면 좋을 것 같은데요...(TMI 주의 요망)학부 시절 AI를 처음 접하게 되고, AI 기술을 사용하면 사람들의 삶이 더 윤택해질 수 있을 거라는 생각으로 아이언맨의 자비스를 만들기 위하여 AI를 연구해야겠다고 다짐하였습니다.그리고 대학원 진학 후 저는 아이언맨의 자비스 시스템을 만들기 위한 첫걸음으로 Siri, Alexa와 같은 voice assistant를 자동화 하자는 취지로 function calling을 연구하게 되었습니다.Function Calling Benchmark를 주제로 ACL에 논문도 냈습니다!. 하지만, 외부 API call을 하는 것이 주목적인 Function Calling으로는 JARVIS처럼 모든 것을 자동화하는 것이 한계가 있다고 느꼈습니다.Function Calling 및 MCP로는 이미 존재하는 API만 활용해서 자동화할 수 밖에 없었죠.저는 이 한계를 느끼고 Function Calling의 부족한 공간을 메꿔주는 분야를 찾다가, Computer Use Agent라는 기술을 찾게 되었습니다.API Calling으로 해결할 수 없는 Task 들은 AI가 실제로 컴퓨터나 모바일 화면을 조작하게 하여 해결하는 방법입니다.대학원에서 홀로 연구에 몰두하며 막막함을 느끼던 중, 마치 누군가 이끌어주신 듯 DEVOCEAN AI Fellowship 7기에서 관련 프로젝트를 진행할 계획이라는 공기를 보게되었습니다.급하게 뜻이 맞는 팀원들과 함께 지원하여 최종 선발되었습니다. 현재는 김동현 멘토님의 탁월한 지도 아래 프로젝트를 수행해나가고 있습니다.이렇듯 Computer Use Agent는 JARVIS와 같은 Voice Assistant에서 Function(API) Calling으로 해결할 수 없는 자동화 부분을 컴퓨터를 조종하여 해결해 줄 수 있는 기술입니다!이미 미국과 중국과 같은 나라에서는 2022년 쯤부터 많은 연구가 진행되었고, 서비스도 나오고 있습니다.논문 관련해서는 지난 포스트에서 몇 편 소개해 드렸으니, 이번 포스트에서는 Computer Use를 서비스화한 기업을 소개해 드리겠습니다.아마도 최근에 화젯거리였었던 서비스 중의 하나일 텐데요 중국의 Monica라는 회사에서 개발한 Manus[/ˈmæn.əs/]입니다. (Deepseek moment Part II 라고도 하더라고요)Computer Use 기능을 AI Agent에 적용하여 유저의 명령을 수행할 때 Manus 서버에 설치된 컴퓨터를 직접 조작하여 문제를 해결해 줍니다.사진처럼 핸드폰 여러 대가 동시에 혼자서 작동하고 있는 영상으로 화제가 되었었죠.다음은 미국에 Computer Use 분야로 논문도 내고 서비스화하고 있는 The AGI Company라는 기업입니다.이전 이름은 한 번쯤은 들어보셨을 MultiOn이라는 회사인데, 이번 포스트에서 설명하려는 [AgentQ](https://arxiv.org/abs/2408.07199라는 논문을 스탠포드 대학교와 publish 한 회사이기도 하죠.REAL-Bench라는 Standardized test lab for Web Agent Evaluation을 제안하는 논문도 publish 했습니다. 같이 확인해 보셔도 좋을 것 같습니다.대표적인 AI 기업 OpenAI와 Claude에서도 각각 Operator, 그리고 Computer Use라는 이름으로 서비스화하였습니다.OpenAI는 Pro를 결제해야지만 사용해 볼 수 있는데, 저는 직접 사용해 본 결과 "서울대입구역에 한식 맛집을 찾아줘"와 같은 간단한 명령어도 버벅대고 실패하는 모습을 보였습니다.Claude는 Computer Use라는 이름으로(아마 이때부터 Computer Use라는 이름을 사용하게 된 것 같습니다.)Computer Use를 직접 돌려볼 수 있도록 Open Source로 깃헙에 공개했었습니다. 링크위에 나열해 드린 기업 말고도 Computer Use라는 기능을 사용하여 서비스하고 있는 기업은 매우 많은데요,이렇듯 단순히 Chatbot 형태의 LLM이 해결해 줄 수 있는 부분에 한계가 있다 보니

모든 ML 태스크가 고성능, 고용량 GPU를 필요로 하는 것은 아니다.이전 포스트에서 우리는 고성능 GPU 클러스터를 구축한 경험을 공유했습니다. 이러한 고성능 GPU 클러스터는 LLM 학습이나 파인튜닝(Fine-tuning) 작업에 필수적입니다. 하지만 모든 AI/ML 작업이 항상 고성능, 고용량 GPU를 요구하는 것은 아닌데요. 간단한 실험이나 PoC(Proof of Concept) 단계에서는 작은 모델로 충분한 경우가 많으며, 서비스 운영 단계에서도 상대적으로 작은 모델을 사용하는 경우가 흔합니다. 예를 들어 실시간 번역 서비스의 경우, 빠른 응답을 위해 애초부터 작은 모델을 학습시키거나 이미 훈련된 모델을 양자화(Quantization)하여 모델의 크기를 줄이는 전략을 활용합니다.모델이 고성능·고용량 GPU(예: H100)에 배치될 경우 GPU 메모리를 충분히 활용하지 못하고 낭비하게 됩니다. 특히 작은 모델들도 응답 시간이 중요한 서비스에 활용될 때는 빠른 처리 속도가 필수적이기 때문에, 고성능 GPU를 완전히 배제할 수는 없습니다. 하지만, GPU 메모리 용량은 상대적으로 덜 필요합니다. 토스증권처럼 다양한 서비스를 빠르게 출시하고 지속적으로 테스트하는 환경에서는 이런 자원 낭비가 더 빈번하게 발생할 수 있습니다. 데이터 분석 결과, 전체 워크로드의 약 1/3은 GPU 자원을 1/4조차 활용하지 않고 있었습니다. 물론 이는 서비스 개발 주기나 비즈니스 상황에 따라 다를 수 있습니다.이러한 낭비는 비용 측면에서도 심각한 문제입니다. 예를 들어 AWS 기준으로 H100 GPU 한 장의 하루 대여 비용은 약 38만 원(환율 1300원 기준)입니다. 이 GPU를 단지 1/4만 활용한다면 하루 약 28만 원의 손실이 발생하고, 월 단위(30일 기준)로 환산하면 약 840만 원의 비용이 낭비됩니다. 서버 한 대에 GPU가 8장 있다고 가정하면 단순 계산상 서버 당 월 6,700만 원이라는 상당한 손실이 생기게 되죠.ML 엔지니어들에게 GPU 클러스터 운영은 식당 운영과 비슷합니다. 식당이 최대한 많은 손님을 받아 최대의 이윤을 내기 위해 빈 테이블을 최소화하듯, GPU 클러스터 역시 최대한 많은 태스크를 효율적으로 배치하여 GPU 자원의 낭비를 최소화하는 것이 핵심입니다.이러한 문제를 어떻게 해결해볼수있을까요?GPU 자원의 낭비를 최소화하기 위해서는 결국 태스크에 맞는 GPU를 제공해야 합니다. 이러한 환경을 제공하기 위해서는 보통 세 가지의 선택지가 있습니다. 첫 번째는 클라우드를 활용하는 방법이며, 두 번째는 다양한 GPU를 혼합하여 운용하는 방법, 마지막으로는 Nvidia에서 제공하는 GPU 가상화 기술(MPS, MIG 등)을 활용하는 방법입니다. 각 방법의 장단점을 차례로 살펴보겠습니다.클라우드를 활용한 GPU 운영은 빠르고 유연한 자원 확장성이라는 측면에서 큰 장점이 있습니다. 필요할 때만 자원을 할당받아 사용할 수 있어 초기 자본 투자 없이 다양한 실험을 빠르게 시도해볼 수 있습니다. 특히 PoC 단계나 일시적인 고부하 테스트

에이닷 전화는 이미 통화 요약, 상세 요약, 통화 유형 분류, 할 일 추출, 주요한 키워드 추출 등 다양한 AI 기능을 통해 사용자에게 풍부한 경험을 제공하고 있습니다.이제는 에이닷 전화에 AI가 붙는 것이 더 이상 신기하지 않을 정도로 자연스러워졌습니다.오늘 소개해 드릴 기능과 LLM모델은 미저장 연락처 관계 추정 서비스로 통화 상대방이 나와 어떤 관계인지 예측하여 사용자에게 노출해주는 서비스 입니다.모르는 번호로 전화가 왔는데 이 전화를 받을까? 말까? 고민한 경험이 있으실거에요.전날 통화한 '직장동료'였는지, 어제 이사갈 집 계약을 논의했던 '부동산 사장님'이었는지,사용자가 받을 필요가 있는 전화인지 쉽게 판단하는 방법으로 관계를 예측하여 태그를 붙여준다면 우리의 고민 시간을 줄여줄 수 있어요.예측의 성능이 왜 중요할까요?AI 기능이 사용자에게 진정한 가치를 제공하려면, 단순한 자동화나 요약을 넘어 정확하고 신뢰할 수 있는 결과를 전달해야 합니다.특히 관계 예측과 같이 사용자 통화 맥락을 다루는 기능은 예측이 틀렸을 때의 영향이 단순한 오류에 그치지 않습니다.예를 들어, 통화 내용에서 '지인과의 약속'을 언급했음에도 불구하고, 모델이 단순히 호칭을 근거로 그 인물을 배우자로 잘못 분류한다면?사용자는 이 서비스를 신뢰하지 않을 뿐 아니라, 예측 결과 자체를 불쾌하게 느낄 수도 있습니다.관계 예측이라는 기능은 단순히 ‘누구일 것 같다’를 넘어서, 사용자의 실제 생활과 감정을 건드릴 수 있는 민감한 정보입니다.그렇기 때문에 모델이 최대한 정확하게 예측할 수 있도록, 단순한 규칙이나 단편적 문맥에 의존하지 않고, 요약 데이터들을 통합적으로 고려할 수 있도록 설계했습니다.정확도와 정보 전달력을 개선하기 위해 세 가지 주요 챌린지를 해결해야 했습니다.첫 번째 과제는 현실 세계에서 사용되는 관계 표현의 다양성이었습니다. 수집한 데이터에는 2.7만 개 이상의 고유한 관계명이 존재했으며,이는 단순한 다중 분류(Multi-class classification) 문제로 해결하기엔 한계가 있었습니다.관계명을 직접 생성해야 하는 생성형 문제는, 모델이 처음 보는 관계명도 유추해야 하므로 표현력과 일반화 능력 모두가 요구되는 고난이도 문제였습니다.즉, 모델은 관계명을 예측하는 것이 아니라, 언제든 새롭게 등장할 수 있는 표현을 "지어내야" 하는 것이죠. 다양하고 섬세한 관계명 표현을 생성하기 위한 설계가 첫 번째 도전이었습니다.두 번째는 사용자와 상대방 간 역할 혼동 문제였습니다.통화요약은 대화를 한 쌍으로 요약하기 때문에, “엄마와 아들의 대화”는 맞더라도,사용자가 엄마인지, 아들인지 구분하기가 어렵습니다.이는 실제 사용자로부터 혼란을 야기하거나, AI가 ‘내가 엄마인데 상대가 엄마인 것처럼’ 잘못 판단하는 쌍바뀜 오류로 이어질 수 있습니다.즉, 단순한 문맥 해석을 넘어 요약 정보를 통해 '나'와 '상대방'을 추론하는 논리적 장치가 필요했습니다.마지막으로, 직장동료와의 통화를 연인과의 통화로 오인하는 등의 민감관계 오추정은 서비스 신뢰도에 직접적인 영향을 미칩니다.특히 낮은 친밀도의 관계를 높은 친밀도로 오추정하는 경우는 불쾌함과 오해를 유발할 수 있으며, 실제 VOC로 이어지는 사례도 있었습니다.따라서 이러한 민감관계에 대한 별도 정밀 추론 로직과 보수적 태깅 전략 등을 도입해 안정적인 사용자 경험을 우선시하는 방향으로 모델을 고도화를 기획했습니다.좋은 모델을 만들기 위해서는 태스크에 적합한 고품질 데이터가 필수입니다.관계 추정 모델을 예측하기 위해, 통화 관련 데이터를 input으로, 관계명을 label로 설정하여 학습을 진행했습니다.이번 고도화 과정에서는 특히 '쌍바뀜 문제'를 해결하기 위해 ‘나’를 유추할 수 있는 보조 feature들을 설계하고, 특히 할일 정보 등에서 주체성 힌트를 추가로 확보했습니다.또한, 상대방을 부르는 호칭이나 발언 주체를 요약에 명시하는 등의 방법을 테스트했고, 그 중에서도 나와 상대방이 구분 될 수 있는 feature를 활용하였습니다.예를 들어, 사용자의 할 일이 "매물 정보 문자로 넣어주기"인 경우, 사용자는 ‘부동산 중개인’일 가능성이 높고 상대방은 ‘고객’일 확률이 높습니다.이처럼 요약 단계에서 드러나지 않는 사용자/상대방의 역할 구분을 할일을 통해 보완하고자 했습니다.이렇게 발굴한 정보를 바탕으로 고지능 추론형 LLM을 활용해 정확한 관계 정답지를 생성했습니다.비추론형 모델과 비교했을 때, 추론형 LLM은 관계를 맥락적으로 해석하고 추론하는 능력이 뛰어나며, 이를 통해 생성된 Ground Truth(GT) 데이터는 질적으로 우수했습니다.또한, 기획 의도에 따라 정교하게 설계된 프롬프트를 통해 더 정밀한 관계명을 생성할 수 있었고, 이는 모델의 예측 정확도 향상에 기여했습니다.데이터 imbalance 문제를 해결하기 위해 '친구'나 '직장동료'와 같은 상위 3개 관계명이 전체 데이터의 약 30%를 차지하는 편향성을 보여줬기 때문에해당 관계명들의 데이터를 4위 수준과 비슷하게 임의로 줄여 모델의 bias를 감소시켰습니다.반면, 롱테일(long tail)에 해당하는 다양한 관계명들은 그대로 유지하여 모델이 폭넓은 관계명을 학습할 수 있도록 했습니다.학습 전에 데이터 품질 확보를 위해 상위 빈도 관계명을 중심으로 전문가 평가단의 리뷰를 진행했습니다.정답 관계명이 실제 맥락과 부합하는지, 오해의 소지는 없는지, 정보 전달력이 충분한지를 다각도로 점검했습니다.전문가 평가시에 정확도와 구체성을 평가 지표를 정의하고 이번 고도화 과제에서 해결하고자 하는 부분에 집중하여 평가가 진행됐습니다.이를 통해 최종적으로 신뢰할 수 있는 학습을 위한 데이터를 준비할 수 있었습니다.정답지 생성 단계에서도 추론형 모델이 정답을 잘 생성하는 것에서 파악했던 것처럼,관계명은 label이 짧아서 간단해 보이는 것에 비해 통화의 맥락을 정확히 파악해야하고 관계에 대한 사전지식이 충분히 필요한 추론의 난이도가 높은 task입니다.따라서 고지능의 학습 모델이 필수적이라고 판단하였고, SKT 자체 foundation모델인 A.X 모델을 선택하여 학습시켰습니다.기존 모델이 가진 방대한 언

안녕하세요. SK AX의 바이브코딩입니다. 요즘 Python으로 개발을 하면서 비동기 로직을 접하는 일이 많아졌습니다.특히 FastAPI의 등장 이후, LLM을 연동하는 작업이 늘면서 비동기의 중요성과 활용 빈도가 크게 높아졌습니다.체감적으로는 비동기를 이해하고 있지만, 막상 정확히 설명하려면 혼란스러운 부분이 있었습니다. 이번 포스트에서는 비동기 관련 핵심 용어들을 정리해보려 합니다.비동기(Asynchronous)란 용어를 살펴보려면 먼저 그 반대되는 개념인 동기(synchronous)를 알아야 합니다.두 단어 모두 일상 생활에서는 잘 사용하지 않았던 용어이고, 프로그래밍 쪽에서 활발하게 사용하는 용어일텐데요. 단어 개념부터 짚고 가겠습니다.사전적인 의미부터 살펴보겠습니다.• None• None 접두사 은 같은(together), 는 시간(time)이라는 뜻을 가집니다.• None 즉 같은 시간에 함께 진행되는 것, 동시에 발생하는 것 이라는 의미가 됩니다.• None• None 접두사 는 부정을 나타내는 접두어로, 같지 않은(not)을 의미합니다.• None 따라서 동시에 일어나지 않는, 시간적으로 분리된 상태 를 의미합니다.프로그래밍에서 사용하는 의미를 알아보겠습니다. 프로그래밍에서 동기/비동기는 호출자(caller) 관점에서 작업의 처리 순서와 대기 시간 처리 방식에 대해 이야기합니다.• None• None 요청한 작업이 끝날 때까지 다음 작업을 하지 않고 기다리는 방식입니다.• None 호출자(caller)가 함수를 호출할 경우, 함수의 리턴값(혹은 예외)을 받아야 다음 로직 수행이 가능합니다.• None• None 작업이 완료되기를 기다리지 않고, 다른 작업을 먼저 수행하는 방식입니다.• None 호출자(caller)가 함수를 호출할 경우, 결과를 기다리지 않고 다음 로직을 수행합니다.간단한 예제 코드를 보겠습니다. 파일을 다운로드 하는 코드입니다.실행하면 아래처럼 출력됩니다."프로그램 시작" 후 함수를 호출했는데, 이 함수가 3초 정도 소요됨에도 함수가 끝날때까지 기다린 후 "다음 작업"을 수행한 것을 볼 수 있습니다.다음은 비동기 방식입니다.실행하면 아래처럼 출력됩니다."프로그램 시작" 후 함수를 호출했는데, 이 함수가 끝날때까지 기다리지 않고 "다음 작업"을 수행한 것을 볼 수 있습니다.블로킹/논블로킹 이란?동기/비동기의 개념을 살펴보다 보면 같이 나오는 용어가 있습니다. 블로킹과 논블로킹입니다.동기/비동기와 비슷한 의미인 거 같으면서도 바라보는 관점이 조금 다릅니다.역시 단어 개념부터 짚고 가는 게 좋아 보입니다. 블로킹과 논블로킹은 동기/비동기보다는 조금 직관적으로 파악이 가능합니다.• None• None 막다, 차단하다의 의미를 가지고 있습니다.• None **어떤 작업이 수행되고 있으면, 다른 일은 할 수 없게 막는 상태를 나타냅니다. **• None• None Blocking의 반대 의미입니다.• None 작업 중 대기하지 않고 다른 일을 계속할 수 있는 상태를 나타냅니다.수행하고 있는 작업이 자원을 점유하고 있으면, 그 자원을 쓰는 다른 작업은 기다릴 수밖에 없겠죠. 여기에서의 자원은 보통 CPU인 경우가 많습니다.수행되고 있는 작업이 I/O 대기하고 있을 때도, CPU를 점유하고 놓지 않는 것이죠.그러면 CPU를 사용해야 하는 다른 작업은 수행할 수 없습니다. 이것이 블로킹의 개념이며, 논블로킹은 이를 반대로 이해하면 됩니다.코드를 한 번 볼까요? 파일을 읽는 코드입니다.위 코드의 함수에서는 함수가 작업을 마칠 때까지 프로그램이 흐름을 멈춥니다.다음은 논블로킹입니다.코드 형태는 비슷하지만, 함수는 즉시 반환되고 결과는 나중에 준비됩니다.헷갈리는 개념에 대해 다시 정리!동기/비동기, 블로킹/논블로킹의 개념을 정리해보았습니다.그런데 뭔가 비슷해보이고 헷갈립니다. 둘 다 기다리는 개념인 거 같기도 하고요.그래서 두 개념의 차이를 간단히 정리해보겠습니다.동기/비동기는 호출자(caller) 관점에서 바라보는 로직 흐름 관점의 설계 방식 이고,블로킹/논블로킹은 함수나 시스템 호출 자체의 동작 방식에 초점을 둔 시스템 레벨 개념 입니다.예제로도 한 번 설명해 보겠습니다.동기/비동기의 경우 친구들과 연락하는 것을 생각해 볼 수 있습니다.전화로 연락을 한다면 앞 친구와 통화를 마쳐야 다음 친구에게 전화를 걸 수 있겠죠. 이것이 동기입니다.문자로 연락을 한다면 여러 명에게 문자를 보내 놓고, 응답이 오는 친구에게 또 문자를 이어나갈 수 있겠죠. 이것이 비동기입니다.블로킹/논블로킹은 헬스장에서 기구를 사용하는 것을 예로 들어보겠습니다. 하나의 기구를 여러 세트 수행한다고 할 때, 한 세트 후 쉴 때 어떻게 하는지에 따라 블로킹과 논블로킹을 나눌 수 있습니다.한세트 후 쉴 때도 기구에 앉아서 쉬면서 다른 사람이 기구를 사용하지 못하게 하는 것이 블로킹, 쉴 때는 잠시 일어서서 다른 사람이 사용가능하게 하는 것이 논블로킹입니다.일반적으로 동기는 블로킹, 비동기는 논블로킹인 경우가 대부분입니다.하지만 동기와 블로킹이 같은 용어는 아니다보니 꼭 그렇지 않은 경우도 생깁니다. 드물지만 동기+논블로킹인 경우도 있고, 비동기+블로킹인 경우도 있습니다.이 부분을 담기에는 내용이 복잡해서.. 아래 URL을 참고하세요.근데 그럼 그냥 다 비동기로 하면 되는 거 아닌가요?다른 이야기가 길었죠? 다시 비동기로 돌아와보겠습니다.개념을 정리해보니 비동기가 참 좋아보입니다.작업을 요청 후 기다리지 않고 다른 작업을 수행할 수 있다니, 효율성이나 성능 면에서 장점이 있어 보입니다.그렇다면 이런 의문이 들 수 있습니다. "모든 작업을 비동기로 처리하면 되는 것 아닐까?"꼭 그렇진 않습니다. 오히려 비동기는 필요할 때만 쓰는 게 정답입니다.비동기는 I/O 작업이 많은 곳에서는 놀라운 성능 향상을 가져올 수 있지만, 무턱대고 적용하면 코드가 복잡해지고 오히려 성능이 떨어지는 경우도 있습니다.그럼 비동기는 언제 쓰는 게 좋나요?비동기는 I/O 작업이 많은 경우에 쓰는 것이 좋습니다.• None REST API 호출이나 웹 크롤러 등 네트워크 요청 처리가 많은 경우• None 대용량 파일 처리나

네이버 사내 기술 교류 행사인 NAVER ENGINEERING DAY 2025(5월)에서 발표되었던 세션을 공개합니다. 발표 내용Spring Cloud Config을 도입 및 커스텀하여 서비스 안정성을 높힌 방법을 소개합니다.발표 대상배포없이 프로퍼티 동적 변경에 관심있으신 분들spring cloud config으로 프로퍼티 동적 변경을 적용하고 싶으나, SPOF 이슈로 꺼려했던 분들목차Spring Cloud Config 소개 Spring Cloud Config 란?Spring Cloud Config ServerSpring Cloud Config ClientSpring Cloud Config ContextSpring Cloud Config 정리Spring Cloud Config 활용Spring Cloud Config 커스텀 Mysql 저장소 사용Kafka 이중화 적용Service API 특정 빈만 리프레시Service API eagerLoading 적용최종 구조Spring Cloud Config 동작 예시 기능 테스트 프로퍼티 값 변경eagerLoading 동작특정 빈만 리프레시DR 테스트 cloud config server 장애kafka cluster 장애한계 및 개선 사항 NAVER ENGINEERING DAY란? NAVER에서는 사내 개발 경험과 기술 트렌드를 교류를 할 수 있는 프로그램이 많이 있습니다. 그중 매회 평균 70개 이상의 발표가 이루어지는 NAVER ENGINEERING DAY를 빼놓을 수 없는데요. 2016년부터 시작된 ENGINEERING DAY는 실무에서의 기술 개발 경험과 새로운 기술과 플랫폼 도입 시 유용하게 활용될 수 있는 팁 등을 공유하며 서로 배우고 성장하는 네이버의 대표적인 사내 개발자 행사입니다. 올해 진행된 NAVER ENGINEERING DAY의 일부 세션을 공개합니다.