마이리얼트립에는 조금 특별한 조직이 있습니다. 바로 AI Lab.AI Lab은 단순히 기술을 연구하는 부서가 아니에요. 모든 구성원이 AI를 직접 활용해서 더 전략적으로 일할 수 있도록 돕고, 실제로 업무 효율화를 경험할 수 있게 만드는 팀입니다.상반기에 마이리얼트립의 AI Lab은 사내 혁신 프로그램 ‘마리트 크몽’을 시작했습니다. 개발 지식이 없어도 AI와 자동화를 활용해서 실제 업무 문제를 직접 해결해보는 것이 프로그램의 취지였죠. 작은 팀의 불편이 곧 회사 전체의 효율로 이어지는 경험을 만들기 위한 실험이기도 했습니다.오늘 소개할 이야기는 성과가 단번에 체감되는 사례입니다. 매달 수십시간 들여야 했던 항공 해외제휴 정산 업무를 단 1분으로 단축한 프로젝트. 여기서 더 놀라운 건, 이 일을 해낸 주인공이 개발자가 아닌 재무회계팀의 임수진 님이었다는 사실이에요.여행업계의 숨은 병목, 해외 제휴 정산여행업계에서 글로벌 파트너십은 곧 매출입니다. 특히 항공 부문에서는 해외 파트너사와의 협력이 핵심이에요. 그런데 파트너십이 늘어날수록 꼭 따라오는 게 있어요. 정산 업무입니다. 복잡하고 시간도 엄청 잡아먹는 그 정산 때문에 매번 머리가 아프기 마련입니다.임수진 님은 이렇게 말했어요.“업체가 많아질수록 시간이 줄어드는 게 아니었어요. 업체마다 요구사항과 수수료율이 다 달라서, 결국 같은 시간을 계속 들여야 했어요.”각 업체의 조건이 모두 달라, 경험이 쌓여도 효율은 좀처럼 나아지지 않았습니다. 눈이 충혈되고 손목이 시큰거릴 때까지 정산, 정산 또 정산. 정산의 산은 너무나도 높고 끝이 보이지 않았습니다. 새로운 파트너십을 맺을 때마다 매달 수십시간 추가되는 작업을 생각하면, 정산은 사업 확장의 벽처럼 느껴졌습니다.“사업부 입장에서는 해외 업체 영업에 큰 제약이 된다고 생각했어요. 빨리 해결해야겠다고 느꼈죠!”Cursor와 Python, 구세주 등장!문제를 분석해보니 핵심은 두 가지였어요. 세일즈 리포트 작성과 수수료 계산.그리고 임수진 님이 선택한 도구는 Python과 Cursor였습니다.여기서 흥미로운 점은, 임수진 님이 개발 배경이 전혀 없었다는 사실입니다. 원래라면 개발팀에 부탁해야 할 일이었는데, AI의 도움 덕분에 직접 해낼 수 있었던 거죠.“AI랑 같이 일하는 과정은 마치 개인 비서를 둔 것 같았어요. 24시간 언제든 질문할 수 있고, 부담 없이 시행착오를 반복할 수 있었죠.”회계 전문성을 바탕으로 업무를 깊이 이해하고 있었기에, AI는 훌륭한 파트너가 되어주었습니다.1분으로 단축된 정산, 확보된 사업 확장성자동화 결과는 단순한 시간 절약을 넘어서 있었습니다.“실행시간은 1분도 안 걸려요. ‘와, 이걸 해내는구나’라는 말이 절로 나왔죠.”하지만 진짜 임팩트는 따로 있었습니다.“핵심은 확장성을 확보했다는 거예요. 이제 영업을 할 때 정산이 더 이상 허들이 되지 않겠죠.”수십 시간을 잡아먹던 업무가 눈 깜짝할 사이 끝나자, 동료들은 고개를 끄덕였습니다. 정말 ‘숫자의 마술사가 펼친 AI 정산 마법’이라는 표현이 딱 어울렸어요. 정산 자

AI가 급속도로 발전하면서, 이제는 단순히 “잘 답하는 AI”를 넘어 Responsible AI(책임 있는 AI)가 중요한 화두가 되었습니다.AI는 보편적 기준을 따르면서도, 동시에 문화적 다양성과 개별적 맥락을 존중해야 합니다.SPeCTRA는 이런 책임 있는 AI 검증을 위해 출발했고, AI의 발전 단계마다 함께 진화해왔습니다. 그 과정에서 새롭게 등장한 축이 바로 Memory, 즉 제 5원소입니다.Memory는 단순한 Agent의 기능 추가가 아닙니다. 기억이 있다는 것은 곧 AI가 사용자와 맥락을 지속적으로 이어가며, 경험을 학습해 나간다는 것을 의미합니다.이를 통해 더 큰 편의성과 개인화 기능을 만족하지만, 동시에 보안, 편향, 책임성 같은 새로운 위험이 커집니다.Memory는 AI에게 친밀함과 위험성을 동시에 줄 수 있는 힘이 있는 녀석(?)이라는게 제 생각입니다.Responsible AI의 관점에서 Memory를 어떻게 설계하고 검증하느냐가 앞으로 AI의 신뢰를 결정하게 될 요소가 될것입니다.원래 SPeCTRA는 Safety, Performance, Tone & Manner, Accuracy 네 가지 축으로 구성됩니다.효과적인 LLM 품질 평가 : 도구, 기준, 그리고 적용기 톺아보기(SPeCTRA)기존의 반응형 LLM은 질문에 대답하고, 요청을 수행하는 데 초점이 있었습니다. 그러나 Agentic Agent는 다릅니다.• None 스스로 목표를 세우고(Subgoal Decomposition),• None 필요한 도구를 오케스트레이션하며(Tool Orchestration),• None 사용자와의 맥락을 장기적으로 이어가고(Proactive Interaction)이 과정에서 “기억(Memory)”은 단순한 보조 기능이 아니라 에이전트 지능의 핵심 자원이 되었습니다.• None 연속성: 사용자가 매번 처음부터 설명하지 않아도 됩니다.• None 개인화: 사용자의 선호, 맥락, 목표를 기억해 더 자연스러운 상호작용을 만듭니다.• None 자율성: 에이전트가 스스로 학습하고, 새로운 목표를 세울 수 있습니다.• None 지속성: 기업 환경에서는 고객 지원, 금융, 교육 등 도메인 맥락을 장기간 유지해야 하므로 Memory 없이는 실제 서비스화가 어렵습니다.Memory는 추상적 개념이 아니라 실제 기술적 구현을 통해 Agentic Agent에 탑재됩니다. 대표적인 접근은 다음과 같습니다.현재 대화 세션 안에서 유지되는 짧은 맥락 저장소입니다. 빠르게 불러올 수 있고, 즉시 반응에 사용되는 장점이 있습니다.• None 한계: 세션이 끝나면 사라지거나, 지나치게 많은 대화를 포함할 경우 모델 컨텍스트 윈도우를 압박합니다.• None• None 대화 기록 유지 (Conversation History): 가장 기본적인 형태로, 사용자의 최근 발화를 순차적으로 보관합니다. 이전 대화 내용을 구조화해 DB나 벡터스토어에 저장하고 불러오는 방식입니다.• None 슬라이딩 윈도우 (Sliding Window): 최근 N개의 발화만 남기고 나머지는 버리는 형태입니다.• None 요약 기반 (Summarization): 긴 대화를 전부 저장하는 대신, 주제와 핵심만 요약해서 축적하는 방식입니다. 오래된 대화를 요약해 단기 기억 부담을 줄이는 형태로 장기 대화 시 효율적이며, 맥락 추적에 유리합니다.시간이 지나도 보존되는 지속적 맥락 저장소입니다. 에이전트가 사용자를 오래도록 “기억”할 수 있으며, 맞춤형 경험과 지속적 학습이 가능해집니다.• None 위험: 개인 정보 노출, 편향 고착화 가능성 → Responsible AI의 원칙 필요• None• None 벡터 임베딩 기반 Memory: 대화 내용이나 문서를 벡터화하여 벡터 DB에 저장, 유사도 검색을 통해 맥락을 재구성합니다. Retrieval-Augmented Memory(RAM) 형태로 많이 사용됩니다.• None 계층적 Memory (Hierarchical Memory): 단기/중기/장기 메모리를 분리해 저장하고, 필요에 따라 계층적으로 검색합니다. 인간의 기억 구조(단기 기억 ↔ 장기 기억)를 모방한 방식입니다.• None Knowledge-Linked Memory: 내부 Memory와 외부 지식 베이스(DB, API, 문서 저장소)를 연동해 최신성(Freshness)과 정확성을 확보합니다.실제 Agentic Agent에서는 단기와 장기가 결합됩니다.단기 기억이 대화 맥락을 빠르게 반영하고, 장기 기억이 사용자 프로필, 과거 프로젝트, 실패/성공 경험 등을 이어줍니다.이 구조가 있어야 에이전트는 반응형 AI를 넘어 맥락 기반 Proactive AI로 발전할 수 있습니다.실제 Agentic Agent에서는 Memory가 다음과 같이 쓰입니다.• None 도구 선택: 사용자가 과거에 선호했던 방법을 기반으로 툴을 선택• None 상황 판단: 이전 대화에서의 미완성 과제를 기억해 이어서 처리• None 학습 루프: 실패 경험을 기록해 반복 학습으로 품질 개선• None 개인 맞춤형 경험: 사용자별 데이터와 맥락을 지속적으로 반영이후에 Memory가 추가되면서 다섯 개의 품질 특성이 완성되었습니다.• None 기억 정확성 (Memory Accuracy): 이전 대화나 저장된 정보가 제대로 보존되는가• None 기억 활용성 (Memory Utility): 저장된 맥락을 얼마나 효과적으로 불러와 활용하는가• None 기억 유지보수성 (Memory Maintainability): 오래된 기억을 적절히 갱신하거나 관리할 수 있는가• None 기억 재현율 (Memory Reproducibility): 동일한 맥락에서 일관된 기억을 되살려낼 수 있는가이 네 가지 지표로 세분화되어 평가됩니다.즉, 스펙트라의 제5원소는 에이전트적 지능을 가능하게 하는 기억(Memory Intelligence) 이라고 정리할 수 있습니다.Memory Intelligence 역시 컷오프 스코어와 TC 작성방식은 기존의 SPeCTRA 1.0 의 방식을 따릅니다. 평가의 형식적 구조는 동일합니다.그러나 검증 대상의 특성 때문에 Memory Intelligence만의 특

Context Engineering은 2025년 현재 AI를 활용하는데 중요한 핵심 역량으로 떠오르고 있습니다.LLM이 나오면서 Prompt Engineering이라는 개념이 중요했는데 이런 개념도 어느덧 outdated되어 Context Engineering이란 개념으로 발전되었습니다.단순한 프롬프트 최적화를 넘어서 LLM의 전체 정보 환경을 체계적으로 설계하는 공식적인 학문 분야로 발전했으며, 1,400편 이상의 관련 연구가 이를 뒷받침하고 있습니다.이와 관련하여 체계적으로 연구한 프로젝트와 논문(https://github.com/Meirtz/Awesome-Context-Engineering)이 있어서해당 내용을 기반으로 Context Engineering을 스터디하는 느낌으로 조사해보았고,요즘 핫한 AI 코딩 툴인 Cursor AI, Claude Code에서 해당 개념이 어떤 식으로 작동하는지 살펴보겠습니다.Context Engineering이 단순한 기술적 개선이 아닌 AI 시스템을 근본적으로 전환시키는 핵심 요소인 이유와 실제 적용 방법을 살펴보겠습니다.Context Engineering은 대형 언어 모델(LLM)의 성능을 극대화하기 위해 정보 페이로드를 체계적으로 최적화하는 공식적 학문 분야이기도 하며,이는 단순한 프롬프트 설계를 넘어서 지능형 시스템에 통합되는 정보의 동적 조립과 최적화를 포괄합니다.Context Engineering의 3가지 핵심 구성요소Context Engineering은 다음 세 가지 주요 영역으로 구성됩니다:Context Window는 LLM이 한 번에 처리할 수 있는 토큰의 최대 길이입니다. 쉽게 말해서, AI가 "기억할 수 있는 정보의 한계"라고 생각하시면 됩니다.현재 많이 쓰고 있는 모델들인 GPT-5는 8K-128K 토큰, Claude 4은 최대 1M 토큰, Gemini 2.5 Pro는 최대 1M 토큰을 처리할 수 있습니다.Prompt Engineering과의 근본적 차이점정의와 범위의 차이Prompt Engineering은 AI 모델에게 특정 응답을 이끌어내기 위해 단일 프롬프트 문자열을 정교하게 설계하는 기법입니다.단일 입력-출력 쌍 내에서 작동하며 "무엇을 말할지"에 집중합니다.반면 Context Engineering은 LLM이 작업을 완수하는데 필요한 모든 정보와 도구를 적절한 형식으로, 적절한 시점에 제공하는 동적 시스템을 설계하는 것입니다.모델이 보는 전체 정보 환경을 설계하며 메모리, 히스토리, 도구, 시스템 프롬프트 등 모든 것을 관리합니다.• None 각 변형에 대해 수동으로 프롬프트를 조정해야 함• None 동적 조립: 요청마다 실시간으로 컨텍스트 구성• None 토큰 관리: 제한된 컨텍스트 윈도우 내에서 정보 우선순위 결정일정 관리 사례를 예시로 들자면 아래와 같습니다.• None Prompt Engineering 접근: "내일 회의 일정 잡아줘" → 기본적이고 로봇적인 응답• None Context Engineering 접근: 캘린더 정보, 과거 이메일, 연락처 정보, 도구 접근권한을 모두 통합 → "Jim! 내일은 하루종일 빽빽해. 목요일 오전이 괜찮다면? 초대장 보냈어, 확인해봐."Context Engineering은 전반적인 정보를 종합하여 보다 동적이고 체계적으로 상황을 이해하여 최적의 결과를 내게 됩니다.Context Engineering과 Prompt Engineering은 계층적 관계를 가집니다.Context Engineering이 컨텍스트 윈도우를 무엇으로 채울지 결정하면, Prompt Engineering이 그 안에서 어떻게 말할지 결정합니다.• None 단순한 작업은 Prompt Engineering으로 시작• None 복잡하거나 장기적인 시스템은 Context Engineering 아키텍처 우선 설계• None 두 접근법을 계층적으로 조합하여 최적의 결과 달성Context에 따라 성능이 달라지는 기술적 원리LLM의 성능이 context에 따라 크게 달라지는 이유는 Transformer의 attention mechanism에 있습니다. Self-attention은 다음 공식으로 계산됩니다:하지만 실제로는 몇 가지 중요한 한계가 있습니다:• None 연산 복잡도: Self-attention의 연산 복잡도는 context length의 제곱에 비례(O(n²))하므로, context window가 2배 증가하면 메모리 사용량과 연산량이 4배 증가합니다.• None Working Memory의 제한: Long context에서 transformer의 실제 "working memory"는 context window보다 훨씬 제한적입니다. 변수 추적 실험에서 frontier 모델들도 변수 수가 증가하면 random guessing 수준으로 성능이 저하됩니다.핵심 발견(Liu et al., 2023): Multi-document QA와 key-value retrieval 실험에서 일관된 패턴이 발견되었습니다.관련 정보가 context 중간에 위치할 때 성능이 최대 20% 이상 저하됩니다.• None GPT-3.5-Turbo: 30-document 설정에서 중간 위치 정보 접근 시 closed-book 성능(56.1%)보다도 낮은 결과• None 300개 key-value pairs에서 relevant key가 중간에 있을 때 정확도 급격히 감소• None Claude 1.3만이 이 과제에서 완벽한 성능 유지코드 생성에서의 구체적 성능 차이Q&A Reasoning에서의 성능 차이결과: 추론 과정 명확성과 정확도 모두 향상복합 추론 태스크에서의 민감도:• None Single-hop QA: Context 순서 효과 상대적으로 적음 (5-10% 차이)• None Causal Reasoning: 인과관계 정보가 순서대로 배치될 때 최적 성능Context Engineering을 효과적으로 하는 실무 가이드• None Right Time: 작업 흐름에 맞는 적절한 시점에 제공Context 구성의 8가지 핵심 요소:• None User Input: 즉각적인 질문이나 작업 지시• None Knowledge Retr

안녕하세요, 개발그룹 데이터서비스개발팀 이성현 매니저입니다. 본 글을 통해 저희 '오!라방' 서비스의 클라우드 비용 절감 사례를 소개해 드리게 되어 기쁩니다. '오!라방'(설명 참조)은 SK플래닛의 OK캐쉬백 앱 내에서 운영되는 라이브커머스 채널링 플랫폼의 이름으로, 'OK캐쉬백'과 '라이브커머스 방송'의 합성어입니다. 오!라방 서비스가 성장함에 따라 클라우드 비용 증가 문제에도 함께 직면하게 되었는데요, 저희 팀에서는 이를 해결하기 위한 비용 절감 방안을 다각도로 검토해 왔습니다. 비용 절감을 위해서는 먼저 주요 비용 발생 지점을 파악해야 했는데요, 비용 리포트를 분석한 결과 네트워크 트래픽으로 인한 AWS ELB(Elastic Load Balancing) 비용과 Amazon ECS(Elastic Container Service) 컴퓨팅 비용이 가장 큰 비중을 차지했습니다.분석 과정에서 오!라방의 여러 서비스 중 프론트엔드 서버의 트래픽이 다른 API 서버들보다 월등히 많다는 사실을 발견했습니다. 따라서 프론트엔드 서버의 구조 개선이 핵심 과제라는 결론에 도달했습니다.오!라방은 다음과 같은 서비스로 이루어져 있습니다.• 오!라방: 방송전, 방송진입, 방송중, 방문미션 등 가장 많은 포인트 기재를 가진 오!라방의 메인 라이브 커머스 콘텐츠• 라이브모아: 방송전, 방송중 포인트 기재를 가진 라이브커머스 콘텐츠오!라방과 라이브모아는 방송 시작에 맞춰 푸시를 발송합니다. 따라서 방송 시작과 동시에 사용자의 유입이 몰리게 되며, 이와 같은 구조로 인해 사용자 트래픽은 1~2분 내에 집중됩니다.이러한 트래픽 패턴으로 인해, ECS의 Auto Scale 기능을 사용할 경우 스케일 아웃 전에 서비스가 다운되는 현상이 발생합니다. 따라서 별도의 람다 코드를 통해 방송 시간에 맞춰 태스크 수를 제한하여 수동 스케일 아웃하는 방식을 그 동안 사용하고 있었습니다.참고로 스케일 람다는 매 15분, 45분마다 트리거가 돌면서 API 를 통해 방송 정보를 받아와 별도 로직에 맞춰 스케일 아웃과 스케일 인 동작을 실행합니다.그러나 위와 같이 람다를 활용한 스케일 작업 방식은, 사전에 스케일 규모를 지정해야 하는 데서 오는 근본적인 문제점을 안고 있었습니다.(1) 예측 불가능한 스케일링: 스케일 아웃할 규모를 미리 예측해서 설정할 수밖에 없어, 예상 최대치에 맞춰 설정하다 보니 낭비되는 자원이 많았고, 때로는 예기치 못한 트래픽이 발생하면 ECS 태스크가 다운되는 경우도 발생했습니다. (2) 불필요한 자원 유지: 트래픽이 집중되는 1~2분을 제외하고는 굳이 컴퓨팅 자원이 필요 없음에도 불구하고, 몇 번의 예외 상황으로 인해 스케일 아웃 규모를 유지해야 했습니다.위와 같은 이유로 기존 ELB + ECS 구조로는 오!라방의 특수한 트래픽 패턴을 효율적으로 처리하기 어려웠습니다. 그래서 인프라 구조의 변경을 고민했고, 이미 많이 사용되고 있고 충분히 검증된 서버리스 아키텍처인 CloudFront와 S3 기반의 서버리스 구조로 마이그레이션하기로 결정했습니다.CloudFront 와 S3 기반의 서버리스 아키텍처를 선택하게 된 이유는 아래와 같습니다.• 불필요한 컴퓨팅 비용 제거 : 저장소 비용과 요청에 대한 비용을 기반으로 요금을 책정하는데 여기서 저장소 비용은 매우 작은 용량이기에 무시할 수 있는 수준이었고 요청에 대한 비용만 고려하면 됐기 때문에 기존 구조의 가장 큰 문제점이었던 낭비되는 불필요한 컴퓨팅 비용을 절감할 수 있습니다.• 예기치 못한 트래픽 대처 : 컴퓨팅 자원이 따로 없기 때문에 예기치 못하게 늘어나는 트래픽에 대해서도 유연하게 대처 가능했습니다.• 네트워크 비용 절감: CloudFront의 비용이 동일 트래픽인 경우 ELB 대비 저렴하였기에 네트워크 비용도 절감되는 효과가 있었습니다.위와 같은 장점을 기반으로 마이그레이션을 진행하기 위해서 몇 가지 사전 검증이 필요한 부분들이 있었습니다.• 비용 효율성: 기존 ELB + ECS 환경 대비 마이그레이션 후 확실한 비용 절감 예상 여부검증을 위해 현재 트래픽 기준 비용과 마이그레이션 이후 예상 비용을 산정해 비교했고, 약 $4,600 ~ $7,000 정도의 절감이 가능한 것으로 확인했습니다. 이는 기존 전체 클라우드 비용의 약 50% 에 육박하는 수치였습니다.이후에 성능 검증을 위헤 관련 조사를 진행해보니 CloudFront 를 통해 서비스하는 경우 최대 250,000 TPS 까지 보장하고 있어 충분히 여유있는 상황이었기에 안정적으로 프로젝트를 시작할 수 있었습니다.위 프로젝트를 통해서도 많은 비용을 절감할 수 있었지만 추가적인 비용 절감을 위해 또 다른 문제였던 네트워크 트래픽량 절감을 위해 여러 방법을 고민했습니다. 프론트엔드 서버의 네트워크 사용량이 높은 이유를 분석해 보니 번들의 크기가 문제였습니다. 기존 Next.js 환경은 프레임워크 자체의 오버헤드로 인해 번들 크기가 컸습니다. 여러 방안을 검토한 결과, Next.js의 구조적 한계로 인해 기본 오버헤드를 근본적으로 줄이기 어려워 상대적으로 가벼운 Vite로 마이그레이션하기로 결정했습니다.(1) 마이그레이션 과정의 도전Next.js 전용 hook들이 코드베이스 전반에 광범위하게 사용되어 있어 마이그레이션에 어려움이 있었습니다. 이를 해결하기 위해 기존 로직을 대폭 수정하는 대신, Next.js hook과 동일한 API를 제공하는 커스텀 훅을 개발하여 코드 변경을 최소화했습니다.Vite로 마이그레이션을 완료한 결과:8월 11일 배포 후 1주일간의 안정화 기간을 거쳐 비용을 분석한 결과, 7월 대비 월 $5,000의 절감 효과를 확인했습니다. 트래픽 변동성을 고려할 때 실제 절감액은 이보다 더 클 것으로 예상됩니다.5. 요약: 프로젝트 성과• 빌드 성능: Vite 도입으로 개발 서버 속도 및 빌드 시간 단축

• Part 1. ISR 전환과 Redis 외부 캐싱 - 카카오 인프라 환경에서 SSR을 운영하며 맞닥뜨린 한계와, 그 과정에서 얻은 Next.js 캐싱 인사이트를 공유합니다.• 👉 Part 2. SSR 서버를 위한 모니터링 시스템 구축 - PM2 운영 환경에서 OS를 넘어 프로세스 레벨의 모니터링 파이프라인을 만든 과정을 공유합니다.안녕하세요. 메이커스FE개발 베리입니다. 이번 글에서는 카카오메이커스 Next.js 서버의 가시성을 확보하기 위해, 모니터링 시스템을 구축한 내용을 설명드리고자 합니다.모니터링 시스템을 구축하게 된 배경은 Next.js SSR 전환 과정에서 발생한 서비스 장애와, 이를 ISR + Redis 캐싱으로 해결한 경험에서 비롯되었습니다. 자세한 내용은 1편 〈ISR 전환과 Redis 외부 캐싱〉의 첫 단락을 참고해 주세요.서비스 장애 당시 저희 팀은 서버에서 무슨 일이 벌어지고 있는지 제대로 파악하지 못했습니다. 503 오류가 발생하고 있었지만, 모니터링 지표는 멀쩡했습니다. CPU나 메모리 사용량도 이상이 없었기 때문에, 리소스 부족 문제라는걸 바로 알아차리기 어려웠습니다.1.1 프로세스 레벨 모니터링의 필요성카카오에는 모피어스(Morpheus)라는 사내 모니터링 서비스가 있습니다. 전사 서버에는 모피어스 에이전트(Agent)가 설치되어, 이를 통해 지표를 수집하여 대시보드를 보여주고 알람을 설정할 수 있습니다.그러나 프론트엔드 서버는 이것만으론 충분하지 않았습니다. 모피어스는 OS 레벨의 지표만 볼 수 있었을 뿐, 실제로 Node.js가 실행되는 프로세스의 상태는 알 수 없었기 때문입니다.CPU나 메모리 등 서버 자원이 충분한데도 프로세스가 종료될 수 있을까요? 잘 아시는대로 Node.js 애플리케이션은 힙(Heap)을 메모리 영역으로 사용합니다. 그런데 V8 엔진은 이 힙 메모리 크기에 제한이 있습니다. 서버의 램 용량이 아무리 크더라도, 개별 Node.js 프로세스는 최대 2~4GB 정도의 힙 메모리 제한을 갖고 있습니다. 이렇게 할당된 힙 메모리를 가득 채우게 되면 Out Of Memory 에러를 발생시키며 프로세스가 종료되게 되죠.또한, 무거운 동기 작업이 많아지면 이벤트 루프를 점유하여 지연(Event Loop Lag)이 발생할 수 있습니다. 프로세스는 살아있지만 요청은 처리하지 못하는 좀비 프로세스가 되어버립니다. 이러한 지연이 누적되면 오류가 발생하거나, 커넥션이 고갈되어 서비스 전체가 마비될 수 있습니다.때문에 저희는 OS 레벨의 모니터링을 넘어서, 힙 사용량, 이벤트 루프 지연 등 Node.js 프로세스 내부의 상태까지 확인할 수 있는 모니터링 시스템이 필요했습니다.카카오메이커스 프론트엔드는 VM 인프라 위에서 PM2로 Node.js 애플리케이션을 띄우고 있습니다. PM2의 클러스터 모드를 이용해 가용한 모든 CPU 코어를 활용합니다. 이는 단일 서버 내에서 기본적인 로드 밸런싱과 장애 복구 기능을 제공하는 첫 번째 방어선이기도 합니다.클러스터 모드는 개별 프로세스 관리의 복잡성을 감춰주지만, 동시에 프로세스 단위의 가시성을 확보하기 어렵게 만들었습니다. 이 한계를 풀기 위해 아래와 같은 구조로 모니터링 파이프라인을 구성했습니다. 으로 지표를 노출하고, 로 지표를 수집하며, 에 데이터를 쌓고, 를 통해 이를 시각화합니다. 자세한 내용은 아래에서 하나씩 짚어보겠습니다.PM2 클러스터 모드로 인한 서버의 가시성 문제는 라는 오픈소스를 이용해 쉽게 해결할 수 있었습니다. 이 툴은 PM2 데몬을 쿼리하여 CPU/메모리 사용량, 이벤트 루프 지연, 힙 사용량 등 프로세스 지표를 수집하고, Prometheus 포맷으로 보여줍니다. 경로로 HTTP 엔드포인트를 열어주기 때문에 해당 페이지에 접속하는 것만으로 쉽게 지표 수집이 가능합니다.대상 서버에서 아래 명령어로 pm2-metrics를 설치합니다.curl 또는 브라우저 접속을 통해 지표가 정상 노출되는지 확인합니다.메트릭 데이터를 적재하기 위한 데이터베이스도 필요합니다. 저희는 TSCoke를 활용하기로 했습니다. TSCoke는 카카오 사내에서 운영 중인 TSDB(시계열 데이터베이스) 서비스입니다.시간에 따라 바뀌는 메트릭이라는 데이터 특성상 TSDB를 사용하기 적합했고, 또 프로메테우스와의 호환성을 제공하여 간편하게 연동할 수 있었습니다.시계열 데이터베이스(Time-Series Database, TSDB)란 시간의 흐름에 따라 기록된 데이터를 처리하기 위한 데이터베이스입니다. 모든 데이터에 타임스탬프를 함께 저장합니다. 시간이 지남에 따라 생성되는 대량의 데이터를 효율적으로 수집, 저장, 조회하는 데 특화되어 있습니다. 모니터링 지표를 비롯해 주가 정보나 온습도, 전력 사용량처럼 시간의 흐름에 따른 데이터를 처리하기에 적합합니다.Grafana Alloy는 메트릭 데이터를 수집하고 전송할 수 있는 도구입니다. 간단한 설정을 통해 타깃 호스트로부터 수집한 프로메테우스 형식의 메트릭 데이터를 원격 저장소로 쉽게 보낼 수 있습니다.Alloy를 띄울 서버에서 아래와 같이 설정 파일을 생성합니다. 가 노출한 HTTP 엔드포인트를 일정한 간격으로 스크래핑하고, 라벨을 추가한 후, 그 결과를 TSCoke 데이터베이스로 전송하는 설정입니다.그리고 Docker를 이용해 Alloy를 실행합니다.그럼 바로 메트릭 수집을 시작하게 됩니다.Alloy는 UI 대시보드도 제공합니다. 12345번 포트로 접속하면 대시보드가 열립니다. 대시보드에서는 설정에서 정의한 컴포넌트들의 상태를 확인하고 디버깅할 수 있습니다.또한 Graph 메뉴에서는 이처럼 데이터의 흐름을 시각화하여 보는 것도 가능합니다.Grafana는 시계열 데이터에 대한 대시보드를 제공해주는 시각화 툴입니다. 저희가 Alloy를 통해 DB에 적재한 메트릭 데이터를 이용해, 원하는 대로 대시보드를 꾸밀 수 있습니다.Docker를 이용해 아래 명령어로 Grafana를 실행합니다.이후 http://localhost:3000/ 경로로 접속하면 아래와 같은 화면이 뜨는 걸 볼 수 있습니다. 초기 아이디와 비밀번호는 admin/admin 입니다.메뉴에 접속하여 를 선택

• 👉 Part 1. ISR 전환과 Redis 외부 캐싱 - 카카오 인프라 환경에서 SSR을 운영하며 맞닥뜨린 한계와, 그 과정에서 얻은 Next.js 캐싱 인사이트를 공유합니다.• Part 2. SSR 서버를 위한 모니터링 시스템 구축 - PM2 운영 환경에서 OS를 넘어 프로세스 레벨의 모니터링 파이프라인을 만든 과정을 공유합니다.안녕하세요. 메이커스FE개발 수빙입니다. 이번 글에서는 카카오메이커스 이벤트 서비스를 Next.js SSR 기반으로 전환하면서 겪었던 이슈들과, 이를 ISR + Redis 외부 캐시로 해결하게 된 과정을 공유드리려고 합니다.카카오메이커스는 카카오 ESG 활동의 일환으로, 사회적 가치를 실현하는 동시에 이커머스의 성격을 가진 임팩트 커머스입니다. 이를 위해 농가돕기(제가버치), 새활용(새가버치), 환경보호 등 다양한 캠페인을 진행하고 있는데요, 이벤트 페이지를 통해 이를 소개하고 있습니다. 이벤트 페이지는 링크 공유가 자주 일어나기 때문에 오픈그래프(Open Graph, OG) 대응이 필요했고, 또 화면 로드 시간을 줄여 사용자 경험을 향상시키기 위해 SSR(Server-Side Rendering)을 적용하게 되었습니다.카카오메이커스에서 진행중인 프로젝트• 새가버치 - 쓰임을 다한 물건의 새로운 가치를 찾아주는 프로젝트• 독립유공자 후손을 돕는 굿즈 제작 프로젝트카카오메이커스 프론트엔드는 기존에 Nuxt 기반으로 개발되어 있었는데요, 이를 Next.js(v14, App Router) 기반으로 순차 전환 중입니다. 인프라는 카카오 자체 VM 환경에서 운영되고 있으며, Node.js 애플리케이션은 PM2 클러스터 모드로 실행해 CPU 코어 수만큼 프로세스를 활용하고, 프로세스가 비정상 종료되면 자동으로 재시작되도록 설정했습니다.1.3 SSR의 달콤함 뒤에 숨은 그림자카카오메이커스의 이벤트 서비스를 Next.js로 전환하며, SSR을 적용한 결과는 상당히 만족스러웠습니다. 일단 첫 화면 로딩 시 표시되던 로딩 스피너가 사라지고, LCP(Largest Contentful Paint, 최대 콘텐츠 렌더링) 시간도 크게 단축되었습니다. 성능 측정 도구인 Lighthouse 테스트에서는 성능 점수가 60점에서 97점으로 비약적으로 개선되었습니다.그러나 프로덕션 배포 이후 곧바로 한계에 부딪혔습니다. 카카오메이커스 트래픽의 대부분은 카카오톡 채널 메시지를 통해 유입되는데요, 대규모 채널 메시지를 발송하게 되면서 순간적으로 다량의 트래픽이 몰렸습니다. 서버는 응답 불능 상태에 빠졌고, 결국 서비스 장애로 이어졌습니다.이는 저희만의 문제가 아니라, SSR 환경에서는 흔히 발생할 수 있는 현상이었습니다. 정적 리소스만 서빙하면 되는 CSR(Client-Side Rendering)과 달리, SSR은 데이터 패칭과 컴포넌트 렌더링 과정이 필요해 서버 리소스를 크게 요구합니다. 결국 더 나은 사용자 경험과 서버의 높은 부하라는 트레이드오프가 존재하는 셈이었습니다.이를 해결하기 위해 ISR(Incremental Static Regeneration)을 도입해 캐싱을 극대화했고, Next.js 프론트엔드 서버의 성능을 크게 개선할 수 있었습니다. 또한 프론트엔드 서버의 가시성을 개선하고자 모니터링 시스템을 구축했으며, 이에 대한 내용은 2편 Next.js SSR 서버를 위한 모니터링 시스템 구축에서 설명드리겠습니다.저희가 경험한 성능 개선의 핵심은 Next.js의 캐싱(ISR, Data Cache)을 제대로 이해하고, 서비스에 맞게 적용하는 것이었습니다. 단순히 기능을 켜는 수준이 아니라, 구조를 이해하고 제약 조건을 파악한 뒤 운영 환경에 맞게 튜닝하는 과정이 필요했습니다.Next.js 서버는 크게 네 부분으로 나눌 수 있습니다.ISR(Incremental Static Regeneration)는 정적 페이지를 필요할 때 부분적으로 다시 생성하는 방식입니다.• SSR처럼 매 요청마다 렌더링하지 않고,• SSG처럼 빌드 타임에 모든 페이지를 미리 만들지도 않습니다.대신 아래 세 단계를 통해 SSG의 성능 + SSR의 유연성을 모두 얻습니다.• 시간이 지나면, STALE 데이터를 반환하면서 백그라운드에서 새 HTML 생성• 이후 요청부터는 갱신된 HTML 반환아래 그림을 통해 동작 방식을 설명드리겠습니다.첫 번째 사용자가 요청을 보내면 캐시에 MISS가 발생해 새로 렌더링된 결과를 응답받고, 동시에 해당 데이터가 캐시 스토리지에 저장됩니다. 이후 30초 뒤, 두 번째 사용자가 요청하면 렌더링 과정 없이 캐시된 데이터를 바로 응답받게 됩니다.1분으로 설정된 Revalidate 시간이 지난 후 세 번째 사용자가 요청하면, 이전에 저장된 STALE 데이터를 우선 응답하고, 백그라운드에서 캐시 갱신을 위해 다시 렌더링이 수행되어 스토리지가 최신 데이터로 업데이트됩니다. 그 이후 네 번째 사용자가 요청하면, 이미 갱신된 최신 데이터를 캐시에서 즉시 제공받을 수 있습니다.저희가 직접 제어할 수 있는 Next.js 캐싱은 크게 두 종류가 있습니다.• Full Route Cache: 페이지 전체(HTML/RSC 페이로드) 캐시상황에 따라 이 두 캐시는 동시에 동작할 수 있으며, 페이지 전체를 캐싱하는 Full Route Cache와 데이터 수준에서 중복 호출을 막아주는 Data Cache가 함께 적용되어 데이터 요청을 최소화합니다.ISR(Full Route Cache)이 동작하려면, 해당 라우트가 ‘정적으로 렌더링 가능’해야 합니다. 예를 들어 app/promotion/[id]/page.tsx 같은 동적 세그먼트가 있다면, generateStaticParams를 통해 생성 가능한 경로를 먼저 확정하고, 라우트에 revalidate를 선언해 ISR을 활성화해야 합니다.저희 서비스는 사전에 전체 Promotion ID를 가져올 수 있는 API가 없었기 때문에, generateStaticParams에서 빈 배열을 반환하도록 구현했습니다. 이 경우 첫 요청 시 동적으로 생성된 데이터가 캐시로 저장되고, 이후 요청부터는 정적 캐시가 반환됩니다.그러나 미리 생성할 수 있는 API가 존재한다면 빌드

바쁜 현대인을 위한 3줄 요약 🚀1. GitLab CI와 ArgoCD를 활용한 CI/CD 알림 개선2. 파편화된 알림 구조의 통합3. 세분화된 환경 및 이벤트별 알림 구현1. 들어가며안녕하세요, 여기어때컴퍼니 DevOps팀 클로이입니다.지난 ‘CI/CD 개선기’ 시리즈에서는 DevOps팀이 하나의 표준화된 CI/CD 파이프라인을 구축하는 과정을 공유드렸습니다. 하지만 여전히 알림 프로세스에는 개선할 여지가 남아 있었습니다. 알림 기준과 구현 방식이 팀별로 달라 파이프라인 개선 효과를 온전히 확인하기 어려웠고, 특히 DevOps팀이 반드시 필요로 했던 배포 실패 감지 환경도 기존에는 충분히 제공되지 않았습니다.이에 이번 CI/CD 개선기 5편에서는 GitLab CI와 ArgoCD 기반으로 동작하는 슬랙 알림 개선기를 소개하고자 합니다. 먼저 2장에서 GitLab CI 파이프라인에서 일관된 알림 체계를 구현한 방법을 살펴보고, 이어서 3장에서 ArgoCD 배포 결과를 효율적으로 알릴 수 있도록 개선한 과정을 다루겠습니다.2. CI 알림 (Gitlab CI + Slack)2.1 문제 인식사내 CI 알림 구조는 파편화된 알림 체계로 운영되고 있었습니다. 각 개발팀에서 자체적으로 알림 모듈을 구현하거나 일부는 알림 없이 완료만 확인하는 경우도 있어, DevOps팀이 전체 현황을 일관되게 파악하기 어려웠습니다.더불어, 기존 알림 방식의 한계도 존재했습니다. Gitlab for Slack App의 경우, 환경별·이벤트별 알림 구분, 실패 로그나 추가 컨텍스트 제공에도 제약이 있었습니다.즉, 기존 구조로는 DevOps팀이 필요로 하는 파이프라인 실패 조기 감지가 어려웠습니다. 마침 CI/CD 파이프라인 표준화 작업과 맞물리면서, 다음의 요구사항을 만족하는 새로운 알림 프로세스를 구축하게 되었습니다.✅ 파편화된 알림 단일화✅ 환경·이벤트별 알림 세분화✅ 전체 모니터링과 팀별 알림을 동시에 충족2.2 구현하기CI 알림 프로세스는 크게 세 가지 축으로 구현했습니다. 먼저 알림의 기반이 되는 전용 에이전트를 도입했고, 그 위에서 환경별 알림 채널 선택과 결과에 따른 알림 흐름을 구성했습니다.1️⃣ Pipeline-agent의 도입초기에는 Slack Webhook에 curl로 JSON payload를 전송하는 방식으로 구현했는데, 메시지 포맷이 길어지고 따옴표 이스케이프가 늘어나면서 스크립트가 200줄을 넘어가곤 했습니다. 또한 알림을 여러 채널로 보내려면 채널 수만큼 Job을 복제해야 하는 번거로움도 있었습니다.# (구방식) webhook + curl — 길어지는 JSON payload.send-slack-message: - | curl -X POST --data-urlencode 'Content-type: application/json' --data \ "payload={ \"attachments\": [ { \"color\": \"$COLOR\", \"text\": \"<$CI_PIPELI

안녕하세요, 여기어때컴퍼니 DevOps팀 주피터입니다.지난 3편에서는 공통 Helm Chart를 위한 저장소(Registry)를 마련했는데요,이번 글에서는 그 안에 채워질 ‘공통 Helm Chart’를 어떻게 설계했는지 본격적인 이야기를 시작해보려고 합니다.지난 3편에서는 흩어져 있던 Helm Chart를 한데 모으기 위해 AWS ECR을 중앙 Chart Registry로 도입한 과정을 소개해 드렸습니다.마침내 공통 Chart가 머무를 안전한 집이 생긴 셈이죠. 이제 그 집을 채울 차례입니다.이번 4편에서는 이 공통 Helm Chart를 어떻게 설계했는지, 그리고 개발자가 신경 써야 할 코드와 인프라의 복잡성 사이에서 어떻게 균형을 맞췄는지에 대한 저희 팀의 깊은 고민과 전략을 공유하고자 합니다.CD 공통화, 어떤 난관이 있었을까?“공통 Helm Chart를 만들자!”는 목표는 쉬웠지만, 실행은 만만치 않았습니다.수십 개의 서비스가 각자의 방식으로 운영되던 환경을 하나로 표준화하는 길에는 여러 난관이 도사리고 있었습니다.같은 듯 다른, 파편화된 Helm Chart가장 큰 문제는 ‘파편화’였습니다.같은 Spring Boot API라도 팀마다 배포 Spec의 구성이 미묘하게 달랐습니다.어떤 팀은 Pod 수량을 안정적으로 제어할 수 있는 HPA와 PDB를 사용하지 않는 팀도 있었고, 어떤 팀은 KEDA와 HPA를 활용하여 커스텀 메트릭 기준으로 설정하는 등 활용도가 천차만별이었습니다.# 일부 팀에서만 사용하던 KEDA {{- if .Values.keda.triggers.prometheus.tomcatThreadsUtilization }} - type: prometheus metricType: Value metadata: serverAddress: {{ .Values.keda.triggers.prometheus.serverAddress }} metricName: tomcat_threads_current_utilization threshold: '{{ .Values.keda.triggers.prometheus.tomcatThreadsUtilization }}' query: > avg( sum_over_time(tomcat_threads_busy_threads{job="{{ .Values.keda.triggers.prometheus.jobName }}"}[30s]) / sum_over_time(tomcat_threads_config_max_threads{job="{{ .Values.keda.triggers.prometheus.jobName }}"}[30s]) ) * 100 {{- end }}중요한 것은 이러한 설정이 한 개발팀 내에서도 균일하지도 않았으며, 복사-붙여넣기로 인해 해당 설정이 왜 필요한지 모른 채 사용하는 경우가 많았습니다또한, 어떤 설정이 왜 추가, 삭제, 변경되었는지에 대한 원인 추적이 어려웠습니다고통스러운

이번 포스팅은 지난번 을 바탕으로• None DeepSeek로 보는 LLM Model의 개선방향에 대해서 알아봅니다.기존에 블록이 어떻게 계산되는지를 확인 했습니다.다음에 가 왔다고 보겠습니다.그러면 GPT는 (End Of Setence)가 나오지 않았기 때문에다음 무슨 단어가 올 지를 예측하게 됩니다.이 경우에 다시 흐름을 따라가보면, 불필요한 연산들이 눈에 보이게 됩니다.기존에 임베딩 작업은 이미 끝나서 Fast만 임베딩을 하면 됩니다.QKV를 계산할 때도 마지막 ROW만 별도로 행렬곱을 취해주면 됩니다.(최적화된 실제 계산을 위해서 전체 Input을 넣지않고, 마지막 Input에 대해서만 계산하면 됩니다) Attention Pattern을 만들어 낼때는 문제가 Attention Pattern의 우측, 아래측을 추가하기 위해서Q와 K값이 모두 필요하게 됩니다. 하지만 여기서 Masked Attention인걸을 생각해보면 기존의 K값을 저장할 경우 K를 다시 구하기위한 연산 리소스를 아낄 수가 있습니다,그럼 Value와의 연산도 봐 볼까요?V 역시 다음 단어 Attention을 구하기 위해서 기존 값이 유지 되어야 합니다.그래서, 의 경우 다음단어 예측간의 QKV 중KV를 Cache하여 불필요한 연산의 중복을 막아 계산 효율을 높이게 됩니다.대신, KV Cache를 위한 메모리 공간이 확보되어야 하고Mutihead개수 * Attention Stack의 개수 * 다음단어 예측을위해 사용된 단어의 개수(=실제 환경에선 Max token)3가지의 영향을 받아서 커지기 때문에 부족한 그래픽메모리를 잡아먹게 됩니다.때문에, 70B LLM 모델이라고 해서 70B를 올릴 수 있는 메모리만 있다고 실행할 수는 없습니다.위에서 알 수 있지만, 트랜스포머 기반의 GPT모델들은블록의 Input과 Ouput의 크기가 동일하기 때문에원하는 만큼 를 추가할 수가 있습니다.그래서 저 를 구성하는 가중치 개수가 3B개 라고 했을때그러면 그냥 무조건 많이쌓으면 되는거 아녀요🤔?-> 계산이 많이해야됨 + RAM이 많이필요함-> Model을 실사용 하기 어려워짐(한번 사용하기 위해서 많은 리소스가 요구됨)-> 계산이 적어짐 + RAM이 적게필요-> 데이터로부터 지식을 저장하기 가중치의 수가 부족해짐이때 중간에 타협점으로, 양자화 라는 기법이 사용됩니다. 컴퓨터는 실수(1.0215150216132324)를 표현하기 위해서 2진수를 조합해서 표현합니다. 이때 실수를 표현하기 위해서 2진수를 4개, 8개, 16개 등등 사용할 수 있습니다. 2진수를 많이 사용할 수록 좀더 Detail한 실수표현(1.02151502161=>거의 기존 실수에 가까움)이 가능한 대신 메모리를 많이먹고 2진수를 적게 사용할 수록 조금 대충 실수를 표현하지만(1.021 => 기존 실수와의 차이값이 커짐) 대신 메모리를 적게 먹습니다.LLM의 Weight의 경우 실수로 표현된 숫자를 저장하게 되는데이때 32진수로 되어있는 실수 Weight를 4진수로 표현해서 가지고오는 방법이 바로 양자화 방법 입니다.-> 계산이 많아짐 + RAM이 적게필요(양자화의 효과)-> 계산량을 동일하지만, RAM은 적게 사용 하면서 적게쌓을 모델 대비 우월한 성능많이 쌓은 모델 > 많이쌓고 양자화한 모델 > 적게쌓은 모델 > 적게쌓고 양자화한 모델순으로 성능을 보여줍니다.• None KV를 Cache할게 아니라, 하나로 합치면 어떨까? -> 어따쓰지 탄생• None KV를 Grouping해서 KV를 조금만 만들면 어떨까? -> 에메르송 탄생때문에 KV Cache로 많은 RAM을 차지하지만기존 구조를 그대로 가져갈 경우 효율을 위해서 성능의 하락을 피할 수가 없었다는 말 입니다.• None KV를 바로 계산하지 않고, Latent Vector를 생성함• None Latent Vector를 가지고 KV를 계산함• None 선형대수를 활용해서 Q와 Latent Vector로 구해진 K를 한번에 계산때림• None Latent Vector를 통해서 구해진 V값을 하나만 구하고, 이걸 모든 MultiHead가 공유함이 방식을 통해서 KV Cache를 57배 개선하면서, 기존의 구조보다 성능이 올라갔다(라고 DeepSeek에서는 주장합니다)

최근 Perplexity AI에서 차세대 AI 브라우저 ‘Comet’ 을 공개했습니다.일반적인 크롬·엣지 같은 브라우저와 달리, Comet은 AI 검색, 자동화, 개인화 탐색을 한 곳에 통합해 복잡한 정보 탐색과 반복 업무를 크게 줄여주는 게 특징입니다.직접 사용해본 경험을 바탕으로 주요 기능과 장단점을 정리해봤습니다.Comet에는 'Assistant' 버튼이 있어, 현재 보고 있는 웹사이트 내용을 AI가 즉시 이해하고 질문, 요약, 번역, 정보 검증 등 의 기능을 요청할 수 있습니다.예를 들어, 뉴스를 보다가 의문이 생기면, 검색어를 다시 입력할 필요 없이 페이지 맥락에 맞는 답변을 바로 받을 수 있습니다.이렇게 네이버 포털에 진입해 뉴스를 읽다가, 기사의 주요 내용을 요약해달라고 부탁할 수 있습니다.즉 현재 활성화된 창에 대해 사이드 패널에서 요약, 추천, 관련 정보 탐색이 가능합니다.위의 사진처럼 “기사 내용 팩트 체크해줘”라고 요청하여 기사에 대한 내용이 사실인지 다른 뉴스와 대조하여 체크도 가능했습니다.또, 페이지 내용을 기반으로 추가 검색 제안도 가능합니다.예를 들어 논문을 읽다가 "이 연구의 핵심만 알려줘"라고 입력하면, 별도 검색 없이 사용자가 원한 해당 내용만 깔끔하게 요약해 보여줍니다.Comet은 개인 히스토리 기반 검색을 지원합니다.“지난주에 봤던 인공지능 기사 찾아줘”나 “두 달 전 보낸 견적서 파일”처럼 자연어로 요청하면, 브라우저 기록·열린 탭·연동된 클라우드 파일까지 찾아줍니다.저번 주에 봤던 한 스포츠 선수 기사를 다시 읽어보고 싶을 때, 최근에 봤던 뉴스 기사를 찾아낼 수 있습니다.상단에는 기존에 봤던 뉴스 기사 링크를 첨부해주고, 하단에는 그 기사들의 주요 내용을 정리하여 원하는 정보와 출처를 빠르게 파악할 수 있어 매우 편리하죠.또, Comet은 탭 관리 기능이 잘 되어 있습니다.관련 탭끼리의 grouping이 가능하다는 것이 그 특징인데,의식의 흐름에 따라 여러 탭을 열어 둔 다음 SKT 관련 탭들만 모아 추후에 다시 이 그룹에서 원하는 탭을 선택하는 것이 가능합니다.“skt 관련 탭만 모아 그룹 만들기” 라고 요청을 하니, T월드 홈페이지, 그리고 Google과 Perplexity에서 “SKT”라는 키워드를 갖고 있는 검색 결과 페이지를 모두 모아 한 그룹에 둔 것을 볼 수 있습니다.자유롭게 어시스턴트 기능을 사용하다가, @tab 기능을 통해 선택한 탭을 AI 질문에 첨부함으로써 언제든지 탭 내 정보에 대한 검색이 가능합니다.좌측 화면처럼 @를 입력하면 현재 창에서 활성화된 탭에 대한 선택이 가능합니다.마지막으로, 탭에 대한 웹 자동화가 가능합니다.새 창을 여러 번 클릭하여 너무 많은 비활성 탭들이 많다면, “활성 안 된 탭 닫아줘” 라고 요청하여 불필요하게 오픈된 탭에 대한 삭제가 가능합니다.웹 페이지 상의 반복 작업을 AI가 직접 수행하는 것도 가능합니다.예를 들어 쿠팡에서 ‘옥수수캔’을 인기순으로 찾아 장바구니에 담는 작업을 Comet에게 부탁해봅시다.저는 로그인하지 않은 상태에서 쿠팡에 접속한 뒤 “옥수수캔 인기많은거 장바구니 담아줘”라고 요청했는데,Comet이 자동으로 검색창에 “옥수수캔”을 검색하고, 정렬을 변경하고 스크롤 및 클릭하며 정보를 수집하는 모습을 볼 수 있었습니다.그 결과, 1분 13초 만에 장바구니에 오뚜기 스위트콘 통조립을 장바구니에 담아줬네요.사실 시간이 적게 걸리는 편은 아니라서 이 부분에 대해서는 아쉽지만,판매량 많은 순으로 정렬하지 않고 하나의 프롬프트만으로 인기 많은 제품을 선택해주니 제품 비교가 귀찮은 분들께는 Comet이 좋은 선택지가 될 수 있을 것입니다.저는 이 웹 자동화 과정이 흥미로워서 조금 더 자세히 살펴보고자 합니다.사이드 패널의 “단계” 탭을 선택하면, Comet이 어떻게 사용자의 요청을 처리했는지 파악할 수 있습니다.처리 단계의 시작 부분을 번역해보면 다음과 같습니다.“저는 이제 Coupang에서 인기 있는 통조림을 검색한 뒤, 판매량/리뷰순으로 정렬하여 상위 3개 상품을 기본 옵션으로 장바구니에 담으려고 합니다.정렬 옵션 상단에서 "판매량순"을 클릭해 가장 인기 있는 상품을 먼저 보이도록 정렬했습니다.”이렇게 Comet이 요청을 이해한 후 실행할 단계를 수행하는 과정을 자연어로 풀어내고 있습니다.이 과정을 간단히 정리하면 다음과 같습니다.판매량 순으로 정렬을 시도하고, 리뷰 수도 집계하여 다시 한 번 인기 제품인지 확인하는 과정을 거친 후에 최종적으로 하나의 제품을 장바구니에 추가하는 모습을 볼 수 있었습니다.사용자 요청의 의도를 아주 정확히 파악하고 실행한 것이지요.두 번째로는 "파스타 만들어 먹고 싶은데 쿠팡에서 필요한 재료 장바구니에 담아줘"라고 요청해보았습니다.이 때는 로그인이 필요하다고 안내하기에 로그인 후 요청을 진행했습니다.파마산 치즈, 엑스트라버진 올리브유, 토마토 스파게티 소스, 스파게티 면으로 총 4개의 제품이 장바구니에 담겼습니다.시간은 4분 7초가 소요되었고, 마찬가지로 어시스턴트의 [ 단계 ] 탭을 클릭하여 진행 과정을 살펴보았습니다.쿠팡에서 구매할 수 있는 파스타 재료 목록을 작성 중입니다.소스를 확인하고 있습니다.쿠팡에서 파스타 필수 재료를 모아 장바구니에 추가하여 쉽게 쇼핑할 수 있도록 하겠습니다.쿠팡에서 파스타를 만들어 먹기 위한 기본 재료(스파게티 면, 토마토 소스, 올리브유, 마늘, 파슬리 또는 바질, 파마산 치즈 등)를 각각 검색해서 대표 상품을 고르고 모두 장바구니에 담아줘.쿠팡에서 파스타 기본 재료를 찾아 장바구니에 담겠습니다.첫 번째 상품으로 청정원 이탈리아 정통 스파게티를 선택하겠습니다.이제 토마토 소스를 찾겠습니다.토마토 소스를 장바구니에 담았습니다. 이제 올리브유를 찾겠습니다.올리타리아 엑스트라버진 올리브유를 선택하겠습니다.올리브유를 장바구니에 담았습니다. 이제 마늘을 찾겠습니다.좋은 마늘 제품이 많네요. 국내산 깐마늘을 선택하겠습니다.이 상품은 로켓와우 전용 상품입니다. 로켓와우 회원이 아니어도 구매할 수 있는 다른 마늘 상품을 다시 찾아서 장바구니에 담겠습니다.이제 파슬리를 찾겠습니다.이 상품도 로켓와우 전용입니다. 파마산 치즈