이번 포스팅은 지난번 을 바탕으로• 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초가 소요되었고, 마찬가지로 어시스턴트의 [ 단계 ] 탭을 클릭하여 진행 과정을 살펴보았습니다.쿠팡에서 구매할 수 있는 파스타 재료 목록을 작성 중입니다.소스를 확인하고 있습니다.쿠팡에서 파스타 필수 재료를 모아 장바구니에 추가하여 쉽게 쇼핑할 수 있도록 하겠습니다.쿠팡에서 파스타를 만들어 먹기 위한 기본 재료(스파게티 면, 토마토 소스, 올리브유, 마늘, 파슬리 또는 바질, 파마산 치즈 등)를 각각 검색해서 대표 상품을 고르고 모두 장바구니에 담아줘.쿠팡에서 파스타 기본 재료를 찾아 장바구니에 담겠습니다.첫 번째 상품으로 청정원 이탈리아 정통 스파게티를 선택하겠습니다.이제 토마토 소스를 찾겠습니다.토마토 소스를 장바구니에 담았습니다. 이제 올리브유를 찾겠습니다.올리타리아 엑스트라버진 올리브유를 선택하겠습니다.올리브유를 장바구니에 담았습니다. 이제 마늘을 찾겠습니다.좋은 마늘 제품이 많네요. 국내산 깐마늘을 선택하겠습니다.이 상품은 로켓와우 전용 상품입니다. 로켓와우 회원이 아니어도 구매할 수 있는 다른 마늘 상품을 다시 찾아서 장바구니에 담겠습니다.이제 파슬리를 찾겠습니다.이 상품도 로켓와우 전용입니다. 파마산 치즈

안녕하세요. 무신사에서 주문을 담당하는 백엔드 엔지니어 박준호입니다.이번 글에서는 제가 운영진이자 동시에 참가자로 참여했던 무신사 엔지니어링에서 진행했던 AI 해커톤 무슨사이(MUSNSAI) 의 여정을 공유하려 합니다. 단순한 이벤트 후기가 아니라, 주문개발팀, 클레임개발팀, 세일개발팀, 그리고 스태프 엔지니어들이 함께 모여 실제로 어떻게 AI와 함께 일하는 문화를 실험했는지 그 순간들을 생생히 담아보고자 합니다. 행사 준비 과정, 운영 철학, 현장의 분위기, 그리고 제가 진행했던 프로젝트 MUBANG(무방) 사례까지 차례대로 나눠보겠습니다.서론: AI, 도구인가 동료인가?AI가 코드를 대신 써주는 시대, 개발자의 역할은 무엇일까요? IDE에서 몇 줄 코드를 찍어보는 체험만으로는 이 질문에 답하기 어렵습니다. 실제 프로젝트의 코드베이스 속에서, 팀 협업의 리듬 속에서, 발표와 문서화의 과정 속에서 AI가 어떻게 자리 잡을 수 있는지를 실험해야만 합니다.그래서 무신사 엔지니어링은 하나의 선택을 했습니다. AI와 함께 일하는 방식을 팀 전체가 동시에 경험해보자. 단순히 재미있는 이벤트가 아니라,실무 중심의 AI 활용 사례를 사내에 축적하고,GPT 질문 수준을 넘어 실제 코드 생산성 중심의 도입 기반을 확보하고, 함께 코딩하는 경험 을 통해 AI 도구 사용 문화를 확산하고자 했습니다.이러한 목적을 담아 기획된 무대가 바로 무슨사이(MUSNSAI) AI 해커톤이었습니다.해커톤을 선택한 이유2025년 여름, 무신사는 AI 코딩 에이전트(Junie, Cursor, Claude)를 공식적으로 지원하기 시작했습니다. 하지만 좋은 도구를 도입했다고 해서 자동으로 생산성과 문화가 변하는 것은 아니었습니다. 도구는 수단일 뿐, 변화를 만드는 것은 결국 사람과 도구가 만나는 방식이었습니다.따라서 더 큰 무대가 필요했습니다. 실패해도 괜찮고, 팀 단위로 AI를 마음껏 부려볼 수 있는 안전한 실험 공간. 바로 해커톤이었습니다.해커톤은 짧은 시간 안에 학습 실험 결과 공유의 사이클을 압축적으로 경험하게 해줍니다. 동시에 실패해도 괜찮다 는 집단적 면허를 주는 특별한 장치이기도 했습니다. 평소라면 망설였을 시도들이 이 자리에서는 자연스럽게 시도되고, 작은 시행착오조차 팀을 단단하게 만드는 자산이 되었습니다. 덕분에 개발자들은 AI를 조심스럽게 만져보는 실험실의 도구 가 아니라, 실제로 옆에서 함께 움직이는 동료처럼 체감할 수 있었습니다.결국 해커톤은 단순히 결과물을 만드는 이벤트를 넘어, 조직이 새로운 도구를 받아들이고 문화를 퍼뜨리는 강력한 촉매제가 되었습니다. 작은 실험들이 모여 우리도 할 수 있다 는 자신감을 만들었고, 그 자신감은 다시 조직 전체의 변화를 밀어 올리는 힘으로 확산되었습니다.무슨사이, 이름과 슬로건행사의 이름은 무슨사이(MUSNSAI). 무신사 AI 를 직관적으로 드러내면서 동시에 AI와 함께라면 무슨 일이든 가능하다 는 말장난을 담았습니다. 이름을 자세히 들여다보면, MUSINSA에서 가운데 알파벳 I를 옮겨 만든 조합이기도 합니다. 단순한 철자 장난처럼 보이지만, 사실은 익숙한 것 속에서 새로움을 발견한다 는 이번 해커톤의 정신을 함축한 상징이었습니다.슬로건은 AI와 함께, 코드가 워킹한다. 무신사가 패션을 대표하는 회사라는 점에서, 런웨이 위를 당당히 걷는 모델들의 워킹을 빌려온 표현입니다. 코드가 단순히 실행되는 것을 넘어, 무대 위에서 빛나는 워킹처럼 멋지게 걸어 나가길 바라는 마음을 담았습니다. 기술은 진지하게 다루되, 참여의 문턱은 낮게 열어두고 싶었던 것, 그것이 바로 무슨사이가 가진 고유한 톤이자 색깔이었습니다.운영 철학해커톤을 기획하면서 가장 먼저 세운 원칙은 단순했습니다. 경쟁이 아니라 학습, 순위가 아니라 경험. 대부분의 해커톤은 점수와 순위를 기준으로 승자를 가려내는 데 집중합니다. 하지만 우리는 다른 접근을 택했습니다. AI는 이겨야 할 상대가 아니라, 함께 문제를 해결하는 협력자라고 믿었기 때문입니다. 도구로서의 AI가 아니라, 사람과 나란히 걸으며 가능성을 확장시켜주는 동료로서 경험되길 바랐습니다. 그래서 이번 행사의 운영 철학은 처음부터 끝까지 경쟁을 넘어 협력으로 라는 기조 위에 세워졌습니다.평가 방식도 이 철학을 그대로 반영했습니다. 모든 프로젝트는 동일한 기본 점수에서 출발했습니다. 그 위에서 각 팀이 보여준 고유한 색깔과 강점을 찾아내어 상을 배분했습니다. 누가 더 잘했는지를 겨루는 대신, 각자가 어떤 새로운 시도를 했는지를 존중하는 구조였습니다. 덕분에 참가자들은 등수 걱정에서 벗어나 자신들만의 방식으로 AI와 부딪히고 탐색할 수 있었습니다.팀 빌딩 방식도 조금 특별했습니다. 행사 당일 현장에서 랜덤 매칭을 도입해 최대 3명이 한 팀을 이루도록 했습니다. 모두 백엔드 개발자였지만, 담당하는 도메인과 프로젝트가 달라 평소라면 협업할 기회가 많지 않았습니다. 같은 영역에 오래 몸담으면 익숙한 방식으로 문제를 풀게 되지만, 다른 도메인의 시각이 섞이면 의외의 해석과 접근이 등장합니다. 실제로 주문, 클레임, 배송, 세일, 쿠폰 등 서로 다른 영역을 담당하던 개발자들이 모여 각자의 언어로 아이디어를 꺼내고, AI를 매개로 새로운 공통점을 발견하는 장면이 자주 목격되었습니다.운영 원칙 또한 실험적이었습니다. 사전 개발물 제출은 철저히 금지했지만, AI 도구 사용은 무제한 허용했습니다. 중요한 것은 사람이 다 했다 는 완벽주의가 아니라, 사람과 AI가 함께 했다 는 경험이었습니다. 이 경험을 어떻게 설계하느냐가 행사 전체의 핵심이었죠. 그래서 참가자들은 부담 없이 AI를 적극적으로 불러내고, 코드 작성부터 문서화, 심지어 발표 준비까지 함께하는 과정을 경험할 수 있었습니다.시간 설계도 신중했습니다. 총 4시간 30분. 전통적인 해커톤에 비하면 짧은 시간이었지만, AI와 함께라면 충분히 완주할 수 있다고 판단했습니다. 오히려 제한된 시간이 집중도를 높이고, 짧은 시간 안에 어디까지 가능할까? 라는 긴장감 섞인 호기심을 자극했습니다. 실제로 현장에서는 시간이 모자란다는 불평보다, AI랑 같이 하니까 가능하네? 라는 반응이 많았습니다.결국 이 모든 설계

안녕하세요 여기어때컴퍼니 DevOps팀 주피터입니다DevOps팀은 여기어때컴퍼니 Tech 조직내 개발자들의 업무 몰입을 위한 개발 환경과 체계를 만들어가는 조직으로 조직별로 상이한 개발 환경을 통합하고 운영하고 있습니다.이번에 다룰 주제는 모두를 위한 CI/CD 개선기 2편, CI 공통화를 위한 모듈화 설계 입니다.이번 편에서는 CI에 대한 내용, 특히 Gitlab CI를 이용해서 구현한 내용을 집중적으로 다뤄보겠습니다.어떤 난관이 있었을까?파악하는 것부터가 문제지난 1편에 말씀드린 것처럼 기존 여기어때 CI Template은 30여개의 파일로 나눠져있었습니다.때문에 아래와 같이 여러가지 template을 찾아 include 해야 했습니다.include: project: "gitlab/ci-template" file: - "workflow/....gitlab-ci.yml" - "gradle/AAA.gitlab-ci.yml" - "gradle/AAA-1gb.gitlab-ci.yml" - "gradle/BBB.yml" - "gitops/CCC.gitlab-ci.yml"이러한 Template들은 사소한 차이에 의해서 발생했습니다.누군가 사용하고 있을 기존 CI 코드를 수정할 순 없었기 때문이죠# ex) AAA.gitlab-ci.yamlvariables: GRADLE_OPTS: "-Dorg.gradle.daemon=false"# ex) AAA-1gb.gitlab-ci.yamlvariables: GRADLE_OPTS: "-Dorg.gradle.daemon=false -Dorg.gradle.jvmargs=-Xmx1024M -Dorg.gradle.logging.stacktrace=full"그렇다면 이 옵션은 어떤 이유로 사용하는지, 왜 사용하게 되었는지 파악하기는 어렵습니다.이 때문에 어디까지 공통화하고, 어디까지 커스텀할 수 있게 해야할지 범위 산정에 어려움을 겪었습니다.팀마다 다른 전략에 모두 대응할 수 있을까?한편 개발팀마다 서로 다른 브랜치 전략을 사용하는 경우는 빈번합니다.출처 : ChatGPT 생성개발 환경을 나타내는 브랜치도 어떤팀은 dev, 어떤팀은 develop 로 달랐습니다.Feature 추가 시 사용하는 브랜치가 feature/<티켓번호>인 경우도, epic/<티켓번호>인 경우도 있었습니다.정답은 없는 모호한 부분이었기에 이를 모두 지원할 수 있게 해야 했습니다.한편, 백엔드와 프론트엔트 프로젝트 간 CI는 명확하게 다른 형태를 띄고 있습니다.출처 : ChatGPT 생성구조면에서는 단순하게 보면 각각 파일의 확장자가 다르고, 소스 코드가 위치하는 디렉토리 명도 다릅니다.더 깊게 들어가면 Cache가 생성되는 디렉토리, 의존성 파일 구조, Mono-Repo 구조도 상이합니다.그렇다면 CI 동작은 어떨까요? 수행되는 CI Job의 내용도 일부 다릅니다.백엔드는 공통 모듈 업로드를 위해 Nexus Publish를 수행하곤 합니다.프론트엔드는 백엔드와 다르게 CloudFront Invalidation과

안녕하세요. AI에이전트플랫폼 베니, 클룽, 홀든 입니다.최근 AI는 놀라울 만큼 자연스러운 대화를 만들어내고 있습니다. 상황을 정확히 파악하고 문맥에 맞는 표현을 선택하며, 때로는 재치 있는 농담까지 해내죠.하지만 카카오는 이보다 더 깊은 AI의 가능성을 바라보고 있습니다. 단순히 말을 능숙하게 하는 수준을 넘어서 사용자의 요청을 정확히 이해하고 그에 맞는 행동까지 수행할 수 있는 AI가 필요해진 시점이라고 생각합니다.예를 들어, "오늘 3시에 무슨 회의가 있어?"라는 질문에 단순히 답변을 생성하는 것만으로는 부족합니다. 사용자가 원하는 것은 AI가 직접 캘린더를 열어 실제 일정을 확인한 후에 그 정보를 전달해주는 것입니다.즉, 상황을 이해하는 것을 넘어 직접 도구를 활용해 적절한 액션을 수행할 수 있는 AI가 카카오가 그리는 다음 단계입니다.이처럼 '도구를 사용할 줄 아는 AI’는 최근 AI 기술의 핵심 화두로 떠오르고 있으며, AI에 도구를 연결하는 방식을 표준화하고 확장하는 프로토콜이 바로 MCP(Model Context Protocol)입니다.저희는 이 MCP를 실험하고 실제 서비스에 적용해보기 위한 플랫폼을 만들었고, 그것이 바로 PlayMCP입니다. PlayMCP는 AI가 도구를 사용할 수 있도록 연결해주고, 또 AI의 도구 활용을 테스트할 수 있는 공간입니다. 우리는 이 공간에서 도구 기반 AI가 일상 속에 자연스럽게 스며드는 미래를 먼저 그려보려고 합니다.이번 글에서는 PlayMCP의 기술적 배경과 해결하고자 하는 문제가 무엇인지, 또 이 플랫폼을 어떻게 만들어왔는지 자세히 소개해드리겠습니다.1. PlayMCP, 이것 뭐에요?PlayMCP는 2025년 7월 31일 오픈한 신선하고☘️ 따끈따끈한☀️ 서비스로, 카카오 AI 서비스에 연결될 MCP 서버를 실험하고 준비할 수 있는 개발자용 플랫폼입니다. 👉🏻 PlayMCP 바로가기PlayMCP에서는 LLM과 연결되는 다양한 도구를 직접 테스트할 수 있습니다.AI가 실제로 어떤 도구를 호출하고, 그 과정에서 어떤 데이터를 주고받는지 투명하게 확인하며 실험하는 플레이그라운드 역할을 합니다.아울러, 자신이 만든 도구를 다른 사람들과 공유하거나 다른 사용자가 만든 도구를 직접 사용해 볼 수 있는 마켓으로서의 기능도 제공합니다.PlayMCP에서 할 수 있는 일 👀• 카카오 내부 서비스 뿐만 아니라 다양한 개발자와 개발사가 공개한 MCP 서버를 탐색할 수 있습니다.• 현재는 카카오 서비스와 관련된 MCP 서버가 주로 공개되어 있지만, 앞으로 더 다양한 MCP 서버가 공개될 예정입니다.• 마음에 드는 MCP 서버는 바로 AI 채팅에 적용해 사용해볼 수 있어요!• 선택한 MCP 서버를 AI 채팅에 적용하면 대화 흐름에 따라 어떤 상황에서 Tool Selection이 일어나는지 확인할 수 있습니다.• Tool Argument Binding 과정을 툴 호출 로그 뷰어를 통해 시각적으로 확인할 수 있어, 도구 호출의 흐름을 보다 쉽게 이해할 수 있습니다.• 내가 직접 만든 Remote MCP 서버를 PlayMCP에 등록할 수 있습니다.• 처음에는 임시 등록 상태로 조용히 테스트해볼 수도 있고, 원한다면 다른 사용자에게 공개해 사용성과 반응을 확인할 수도 있어요.PlayMCP에 대한 기본적인 소개는 여기까지입니다. 이제부터는 이 플랫폼이 어떻게 만들어졌는지 자세히 이야기해보겠습니다.USB 포트가 없는 컴퓨터: MCP 이전의 LLM 생태계MCP는 (위에서 잠깐 언급했지만) 대규모 언어 모델(LLM)이 외부 도구 및 컨텍스트와 원활하게 상호작용할 수 있도록 만들어진 프로토콜입니다.그런데 이 정의만 봐서는 MCP가 왜 이렇게 큰 주목을 받는지 의문이 들 수 있습니다.MCP 이전에도 LLM은 이미 웹 검색을 하거나 코드를 작성하는 등 에이전틱(Agentic)한 AI로서 충분히 다양한 역할을 해왔기 때문이죠.MCP가 주목받는 핵심적인 이유는 바로, LLM과 외부 도구가 연결되는 통일된 규격을 제시했기 때문입니다.MCP 등장 이전의 개발자는 자신이 개발한 도구를 여러 LLM에 연결하기 위해서 모델마다 다른 연동 방식에 맞춰 직접 연동 작업을 해야만 했습니다.이는 마치 모든 컴퓨터가 USB 포트 대신 독자 규격 포트만 지원해서, 사용자가 가지고 있는 주변 기기를 자유롭게 연결하기 어려운 것과 같은 상황이었죠.LLM 서비스 제공자 입장에서도 문제는 컸습니다.도구를 활용하는 LLM 서비스를 제공하기 위해서는 직접 외부 도구를 붙여야 했는데, 사용자가 필요로 하는 모든 도구를 연결하는 것은 사실상 불가능한 일이었습니다. 결국 서비스 제공자는 제한된 범위의 도구만 지원할 수밖에 없었고, 이는 서비스 확장에 큰 제약이 되었습니다.결국 표준의 부재는 AI 생태계의 생산성과 확장성에 구조적인 한계를 만들어냈습니다. 그리고 바로 이 한계를 해결하기 위해, MCP라는 ‘게임 체인저’가 등장했습니다.MCP는 LLM과 외부 도구를 연결하는 보편화 된 공통 인터페이스, 즉 AI 세계의 USB-C 표준을 지향하는 프로토콜입니다.MCP 표준을 지원하는 LLM 서비스와 외부 도구는 마치 USB 케이블을 꽂으면 바로 연결되는 것 처럼 별도의 복잡한 통합 과정 없이 연결될 수 있습니다.이제 LLM은 MCP라는 표준화된 포트 규격을 통해 누구나 필요한 도구를 자유롭게 연결할 수 있는 확장 가능한 시스템으로 진화했습니다. 코딩을 전혀 모르는 일반 사용자도, LLM 서비스가 MCP를 지원하기만 한다면(ex. Claude) 원하는 MCP 서버를 손쉽게 연결할 수 있죠.PlayMCP 역시 MCP의 핵심 스펙을 충실히 지원합니다. 직접 구현한 MCP 서버를 등록해 동작을 검증할 수 있고, 다른 사람이 올린 MCP 서버를 AI 채팅에 적용해 보며 새로운 활용 아이디어를 얻을 수 있습니다.그럼 이제부터 PlayMCP가 MCP 스펙을 어떻게 구현하고 있는지 자세히 살펴보겠습니다.이 글은 MCP 스펙에 대한 기본적인 이해가 있다는 것을 전제로 작성되었습니다.만약 MCP 스펙에 대한 학습이 필요하시다면 MCP Documentation을 참고해 주세요.MCP 아키텍쳐의 핵심 구성 요소: Hos

안녕하세요 여기어때컴퍼니 DevOps팀 주피터입니다DevOps팀은 여기어때컴퍼니 Tech 조직 내 개발자들의 업무 몰입을 위한 개발 환경과 체계를 만들어가는 조직으로 조직별로 상이한 개발 환경을 통합하고 운영하고 있습니다.이번에 다룰 주제는 여기어때 Tech 조직의 모두를 위한 CI/CD 개선에 대한 내용이고, DevOps팀 9개월 간의 여정을 5 편에 나눠 정리하였습니다.특히, 사내 개발자 플랫폼(IDP) 없이 CI/CD Pipeline을 구축하고 운영 중인 분들에게 도움이 되었으면 합니다.개발자가 작성한 코드가 어떻게 하면 매끄럽게 배포될 수 있을까?이와 같은 고민으로 출발한 DevOps팀의 여정을 공유드리고자 합니다.현황 파악기존 CI/CD Workflow개선에 앞서 DevOps팀이 생기기 이전!여기어때에서는 EKS에 서비스를 배포하기 위해 CI 도구로는 Gitlab CI를, CD 도구로는 ArgoCD를 사용하고 있습니다.개발팀에서 배포 환경에 해당하는 dev / stage / release 브랜치에 Merge하면서 CI가 시작됩니다.이후 ArgoCD에서 Webhook 감지를 통해 Sync를 수행하여 자동적으로 배포하도록 되어 있습니다.하지만, 기존 구조에서는 CI 적용 시, 어떤 파일을 고쳐야 하는지 알기 어려웠습니다 (30여개 가량의 YAML 파일 존재)Gradle 빌드 옵션 하나 차이로 새로운 템플릿 파일이 생겨나는 경우도 있었습니다.그 결과, 30개가 넘는 CI 관련 파일이 생성되었습니다.include: project: "gitlab/ci-template" file: - "workflow/....gitlab-ci.yml" - "gradle/AAA.gitlab-ci.yml" - "gradle/AAA-1gb.gitlab-ci.yml" - "gradle/BBB.yml" - "gitops/CCC.gitlab-ci.yml"각각 어떤 Job이 실행되는지, 동작 조건은 어떤 것인지 처음 적용하는 팀은 며칠씩 분석에 매달려야 했습니다.한편 배포 설정을 구성하는 Manifest인 Helm Chart의 상황도 비슷했습니다.관리 주체 없이 최초 배포된 Helm Chart Template은 시간이 갈수록 각 개발팀 문화에 따라 파편화되기 시작했습니다.그렇게 Template이라는 이름에 걸맞지 않게 서비스마다 Template이 따로 존재하게 되었습니다.이러한 현상은 서비스 규모가 커질수록 문제를 야기했습니다.예를 들어, Spring 에서 Pinpoint(APM 도구) 옵션 (pinpoint.profiler.profiles.active)을 release 로 선택하지 않으면 성능상의 문제가 발생하게 됩니다.이를 일괄적으로 고치기 위해서는 몇백 개가 넘는 Manifest Template을 수정해야 했습니다.또한, 개발팀이 굳이 알 필요 없는 ArgoCD 관련 설정이나, Node 관련 설정들도 포함되어 있었습니다.때문에, 인프라 관련 공통 설정 변경 시 개발팀이 직접 가이드를 보며 하나씩 수정해야 했거나,필수 설정을 누락한

이번 블로그는 사내 Agent를 개선하면서 고민 했던 사례와 제가 적용해 보았던 Query Rewriting 사례를 공유하고자 합니다.엔터프라이즈 환경에서 LLM을 활용해본 분들이라면 RAG(Retrieval-Augmented Generation, 검색 증강 생성) 라는 용어가 매우 익숙하실 겁니다.기업의 모든 절차는 외부 검색이나 LLM 자체의 지식이 아닌, 내부 문서, 사규, 공동 작업 문서를 기반으로 답변해야 하기 때문에 RAG는 선택이 아닌 필수 기술로 자리 잡았죠.RAG를 처음 구성하고 단일 질문을 던져보면, 놀라울 정도로 정확하고 신뢰도 높은 답변을 제공합니다.하지만 사용자와 AI의 대화가 여러 차례 이어지는 멀티턴(Multi-turn) 상황에 들어서면 이야기는 완전히 달라집니다.RAG 챗봇을 개발해본 사람이라면 누구나 겪어봤을 답답한 순간입니다.사용자는 분명 '육아 휴직' 에 대해 묻고 있는데, AI는 엉뚱하게 '의료 지원'이나 '교육 지원'에 대한 답을 내놓습니다.왜 이런 문제가 발생할까요?문제의 핵심은 RAG 파이프라인의 문서 검색 단계에 있습니다.AI는 "아이는 몇 명까지 지원돼?" 라는 질문 그 자체만 보고, 대화의 맥락('육아 휴직')을 놓친 채 '아이 수'와 관련된 모든 문서를 찾아내기 때문입니다.이러한 한계를 극복하고 똑똑한 대화형 AI를 만들기 위한 핵심 열쇠가 바로 쿼리 재작성(Query Rewriting) 입니다.💡 해결책: 검색 전에 질문부터 다듬어라! 쿼리 재작성(Query Rewriting)쿼리 재작성은 사용자의 질문을 검색 시스템이 가장 잘 이해할 수 있는 형태로 변환하는 과정입니다.이전 대화 기록과 현재 질문을 함께 고려하여, 맥락이 누락된 질문을 완전한 형태의 질문으로 다시 만들어주는 것이죠.단순히 이전 대화를 기억하지 못하는 문제를 넘어, 대화형 RAG 시스템은 다음과 같은 복합적인 과제를 안고 있습니다.• None 문맥적 모호성 (Contextual Ambiguity): 사용자는 "그건?", "다른 옵션은?"처럼 핵심 정보를 생략하는 경우가 많습니다. 시스템은 이런 문맥 의존적인 질문을 그 자체로 완전한 의미를 갖는 독립적인 형태로 변환해야 합니다.• None 의도의 진화 (Intent Evolution): '노트북 가격'을 묻던 사용자가 다음엔 '성능 비교', 그다음엔 '사용자 후기'를 물어보는 것처럼, 대화가 진행됨에 따라 변화하는 사용자의 의도를 실시간으로 추적해야 합니다.• None 정보 손실 및 최신 편향 (Information Loss & Recency Bias): LLM은 긴 대화의 초기 내용을 잊고, 가장 최근 질문에만 집중하는 경향이 있습니다. 이로 인해 전체 흐름을 무시한 단편적인 답변을 내놓을 수 있습니다.이러한 문제들을 해결하기 위해, 현대적인 RAG 아키텍처는 검색 단계 이전에 쿼리 재작성(Query Rewriter) 모듈을 도입합니다.이 모듈은 사용자의 질문과 대화 기록을 받아, Vector DB 같은 정보 검색 시스템에 가장 효과적인, 명확하고 구체적인 검색 쿼리를 생성하는 역할을 담당합니다.그렇다면 쿼리를 '잘' 재작성하는 데에는 어떤 기법들이 있을까요? 대표적인 세 가지 방법을 소개합니다.복잡한 질문에 바로 답하는 대신, 의도적으로 한 걸음 물러나(step back) 더 근본적이고 추상적인 상위 개념의 질문을 먼저 생성하는 기법입니다.예를 들어, "특정 물리학 문제를 푸는 방법"을 묻는 대신, "이 문제에 적용되는 물리 법칙은 무엇인가?" 라는 근본적인 질문을 먼저 생성하고 검색하는 식이죠.이렇게 얻은 배경 지식은 LLM이 더 깊이 있는 추론을 통해 정확한 답변을 도출하는 데 결정적인 단서가 됩니다.• None 👍 장점: 복잡한 추론이 필요한 전문 분야(과학, 법률 등)에서 답변의 깊이와 정확성을 높여줍니다.• None 👎 단점: 효과적인 상위 질문을 만들기 위한 프롬프트 설계가 까다롭고, 추가 LLM 호출로 인해 응답 시간과 비용이 증가합니다.정보 검색의 패러다임을 '질문-문서 유사도'에서 '답변-문서 유사도' 로 전환하는 혁신적인 접근법입니다.사용자의 질문을 받으면, LLM이 먼저 그 질문에 대한 **이상적인 '가상의 답변'**을 생성합니다. 그리고 이 가상 답변과 가장 유사한 실제 문서를 찾아내는 것이죠.질문(의문문)과 문서(평서문) 사이의 표현 차이를 극복하고, 의미의 핵심이 유사한 문서를 더 효과적으로 찾아낼 수 있습니다.• None 👍 장점: 사용자의 질문이 모호하거나 키워드가 부족할 때, 의미적 의도를 파악하여 예상치 못한 관련 문서를 발굴하는 데 강력합니다.• None 👎 단점: LLM이 전혀 모르는 최신 정보나 전문 용어에는 엉뚱한 가상 답변을 생성하여 오히려 검색 성능을 저하시킬 수 있습니다.3. Multi-Query & RAG-Fusion: 질문을 쪼개고 결과를 합치기"최근 레드삭스와 패트리어츠 중 어느 팀이 더 최근에 우승했나요?"와 같은 복잡한 질문은 사실 여러 개의 하위 질문("레드삭스의 마지막 우승 연도는?", "패트리어츠의 마지막 우승 연도는?")을 내포하고 있습니다.Multi-Query는 이처럼 복합적인 질문을 여러 개의 단일 관점 쿼리로 분해하는 전략입니다.RAG-Fusion은 여기서 한 단계 더 나아가, 각 쿼리에 대해 독립적으로 검색을 수행한 후,그 결과들을 지능적인 알고리즘(Reciprocal Rank Fusion)으로 융합(Fusion)하여 최종적으로 가장 관련성 높은 문서 순위를 결정합니다.• None 👍 장점: 여러 정보를 동시에 묻거나 비교가 필요한 질문에 대해, 놓치는 정보 없이 포괄적인 검색을 수행하여 신뢰성을 높입니다.• None 👎 단점: 여러 번의 쿼리 생성 및 검색으로 인해 응답 시간과 비용이 가장 크게 증가할 수 있습니다.지금까지 소개된 기법을 모든 쿼리에 일괄적으로 적용하는 것은 비효율적일 수 있습니다.때로는 사용자의 원본 질문 자체가 가장 좋은 검색어일 수도 있으니까요.최근 RAG 연구는 쿼리의 특성에 따라 최적의 처리 방식을 동적으로 결정하는 '적응형(Adaptive)' 아키텍처로 나아가고 있습니다.파이프라인 가장 앞단에 '라우터(R

고등학생도 이해하는 Transformer (Deep Learning) #1고등학생도 이해하는 Transformer (Deep Learning) #2고등학생도 이해하는 Transformer (Deep Learning) #3고등학생도 이해하는 Transformer (Deep Learning) #4고등학생도 이해하는 Transformer (Deep Learning) #5이전 5편에서는 Linear Layer를 이용한 손글씨 분류기를 만들어 보았습니다.사실 아직 Deep Learning이 아니라 Machine Learning으로만 이야기 하고 있습니다.그럼 AI(Artificial Intelligence), ML(Machine Learning)과 DL(Deep Learning)이 무슨 차이일 까요?아래 그림과 같이 AI 부류 안에 ML(기계학습)과 DL(심층학습)이 속해 있어요이전 강의의 손글씨 분류기는 왜 ML이지 DL이 아닐까요?ML은 어떤 Model에 데이터를 입력해서 결과가 나오는 구조이고, DL은 이 모델이 Deep 하게 심층 구조로 되어 있는게 특징입니다.Deep 이 뭔지 다시 이야기 해보겠습니다. Deep Learning은 그림과 같이 모델안에 Layer가 여러개 있어서 Deep 한 구조인데요,5편에서는 Linear Layer를 사용한 모델이 Deep Learning이 아니라고 했습니다.5편의 손글씨 분류기는 Linear Layer 1개만 사용했는데요, Deep게 한번 Linear Layer를 여러개 추가 하면 DL이 될까요?Linear Layer를 a(x)=Ax+B 라고 정의하고, a(x), b(x), c(x) 의 Layer를 3개 추가 한다고 하면, y = a(b(c(x))) 로 구성 할 수 있습니다.a(b(c(x))) 를 풀어서 합성해보면 a(b(c(x))) = d(x) 로 풀어볼 수 있습니다.이를 설명하면 선형함수들의 합성은 선형함수가 됩니다. 이 뜻은 아무리 Linear Layer를 여러 층으로 쌓아보아도 하나의 Linear Layer로 합성되기 때문입니다. 이를 이용한것이 LLM Fine Tuning방법중에 하나인 LoRA(Low-Rank Adaptation) 입니다. (이야기가 또 다른데로 샐뻔 했네요. LoRA는 나중에 다시 설명드릴께요)따라서 Linear Layer를 여러 개층으로 쌓아도 결국 하나의 Layer 통과한 것과 동일합니다. 이러한 문제를 막고, 여러 레이어를 통과할 수 있도록 하는 방법이 각 레이어 사이에 Non-Linear 함수를 추가해서 함성함수가 안되도록 하는 방법입니다.대표적인 Non-Linear 함수는 ReLU(Rectified Linear Unit) 함수 입니다. 아래 수식 및 그림과 같이 생겼습니다. 각 Linear Layer 사이에 이 Non-Linear 함수를 추가하여 Deep 하게 계층을 쌓으면, 수식을 전개 하거나 함성 함수로 간략화 할 수가 없게 됩니다. 이러한 Layer 사이에 추가 되는 Non-Linear Layer를 Activation Function 이라고 부릅니다.ReLU 함수를 r(x) 라고 하면 a(r(b(r(c))) = y 로 모델을 구성하면 수식을 전개해서 함성 함수를 생성 할 수 없이 구성 할 수 있게 됩니다. 이러한 구조를 생물학적 신경 구조를 본따서 만들어서 신경망(Neural Network)으로 불리기도 합니다. 'Dendrite(덴드라이트)'는 '나뭇가지 모양으로 부터 여러 입력을 받아 세포체(Nucleus)에서 입력을 더해서 시냅스를 통해 전달 됩니다. 이러한 Neuron이 모여서 뇌신경망을 구성하게 되는데요 여러 입력 을 받아 출력값을 다음으로 전달하여 사고 및 판단하는 구조에서 본따서 인공 신경망도 여러 입력을 받아, 곱하고 더해서 출력하게 되는 구조로 설계 되었습니다. 여러 입력을 받아서 연산을 수행하고 다시 다음 레이어로 전달하는 구조가 아주 유사합니다.이러한 Linear Layer와 Non-Linear Layer를 중첩하여 Deep 한 네트워크를 구성 하여 뇌의 사고와 같은 복잡한 사고를 구성 할 수 있게 되었습니다.• None Deep Learning은 Linear Layer와 Non-Linear Layer를 중첩하여 Deep 한 구조로 되어 있다.• None 이러한 Deep 한 구조는 뇌신경망을 참고하였다.• None Linear Layer로만 Deep 하게(여러 레이어로) 구성하면, 하나의 Linear Layer로 합성 될 수 있으며, 이를 방지하는 것이 Activation Function이다. Activation Function(Non-Linear Layer)로 복수의 Linear Layer들이 하나의 Layer로 합성되는 것을 방지하여 Deep 한, 깊은 구조의 Model 을 구성할 수 있다.

우리는 어디에 서 있는가?지금 우리는 거대한 변혁의 한복판에 서 있습니다. 어떤 사람들은 지금을 ‘제2의 산업혁명’이라 부르고, 또 어떤 사람들은 ‘지능 혁명’이라고도 칭합니다. AI라는 거대한 변혁의 파도가 우리의 일과 삶, 그리고 생각하는 방식까지 모든 것을 바꾸고 있다는 사실만은 분명한 듯 합니다.18세기에는 증기기관이 인간의 근육을 대신해 물리적 한계를 무너뜨렸다면, 21세기는 AI가 인간의 두뇌를 확장시키고 지적 능력의 경계를 허물고 있습니다. AI가 가져오고 있는 변화는 단순한 기술의 발전이 아니라, 인류 문명의 OS를 통째로 업그레이드하는 것과 같은 근본적인 변화로 보입니다.이 변화는 두려움과 설렘이 뒤섞인 복잡한 감정을 불러 일으킵니다. 특히 변화의 물결을 가장 먼저, 그리고 가장 온몸으로 맞고 있는 소프트웨어 엔지니어들에게 ‘AI 네이티브’라는 화두는, 오늘의 생존과 성장에 관한 절박한 질문일 것입니다.여기에서는 AI의 전면적인 등장 앞에서 개인과 조직이 어떻게 방향을 찾고, 어떻게 대응해야 하며, 궁극적으로 어떻게 AI 네이티브화되어야 하는지에 대해 이야기하고자 합니다. 카카오테크가 AI 네이티브 전환 과정에서 얻은 교훈을 공유하면서 이 시대를 살아가는 우리 모두의 미래에 대한 제 생각을 함께 나누고 싶습니다.AI는 위협인가, 기회인가?골리앗들의 전쟁과 우리의 위치2023년과 2024년은 그야말로 AI 광풍의 시대였습니다. OpenAI의 압도적인 질주와 이를 추격하는 글로벌 빅테크들의 천문학적인 자본 경쟁은, 1990년대에서 2000년대 초반으로 이어진 월드 와이드 웹(WWW)의 등장을 방불케 하며 새로운 AI 시대의 재림과 거대한 변화의 흐름을 온 몸으로 느낄 수밖에 없는 시기였습니다. AI가 가져올 변화에 대한 기대감과 함께, “이 게임에 우리가 낄 자리가 있기는 한 걸까?” 하는 깊은 초조함도 함께 느꼈습니다.LLM의 발전 속도는 상상을 초월했습니다. 오늘 최신 버전을 가정하고 만든 서비스가, 내일 새벽에 발표된 다음 업데이트와 함께 구식이 되어버리는 일이 비일비재했습니다. “OpenAI가 키노트를 할 때마다 스타트업들이 사라진다”는 말이 더 이상 농담처럼 들리지 않았던 시절입니다. 이 거대한 흐름 앞에서 근본적인 질문과 마주하게 됩니다.“우리가 참여할 수 있는 경쟁인가?”결론부터 말하자면, LLM 자체를 처음부터 개발하는 ‘모델 경쟁’은 이미 다른 차원의 이야기가 되었습니다. 이는 단순히 돈의 문제를 넘어, 국가 단위의 인프라와 자원이 동원되는 총력전의 양상을 띠고 있기 때문입니다.• 전력: 메타와 테슬라가 건설 중인 데이터센터는 ‘기가와트’ 단위의 전력을 소모합니다. 이는 원자력 발전소 몇 기가 생산하는 전력량과 맞먹는 수준으로, 하나의 거대 도시가 쓰는 에너지를 단 몇 개의 기업이 AI를 위해 사용하고 있다는 의미입니다. 카카오가 수천억을 들여 지은 최신 데이터센터의 총 전력 용량이 수십메가와트 수준임을 감안하면, 현재의 인프라로는 상상조차 하기 힘든 규모입니다. 중국이 서부 해안에 수십 기의 원자력 발전소를 동시에 건설하며 AI 시대의 에너지 패권을 노리는 것은 결코 우연이 아닙니다.• 컴퓨팅: 19세기의 골드러시 시기에 부를 거머쥔 사람들은 금을 찾아 헤매던 광부가 아니라 광부들에게 채굴 도구와 의식주를 제공했던 상인들이었습니다. AI 시대의 GPU는 바로 이 ‘채굴 도구’와 같습니다. AI라는 새로운 금맥을 캐기 위한 경쟁이 치열해질수록 채굴 도구의 가치는 천정부지로 치솟고 있습니다. 따라서 이 자원을 안정적으로, 그리고 대규모로 확보하고 운영하는 능력 자체가 곧 국가와 기업의 경쟁력을 결정짓는 핵심이 되었습니다.• 인재: 경쟁력 있는 LLM을 만드는 과정은 정해진 공식에 따라 기계를 조립하는 것과는 다릅니다. 수많은 변수를 조정하고 데이터의 미묘한 특성을 파악해 최적의 결과물을 만들어내는, 마치 ‘연금술’에 가까운 경험적 튜닝에 크게 의존합니다. 이 때문에 전 세계 최고의 AI 연구자는 100명 내외라는 말이 나올 정도로 극소수이며, 이들의 몸값은 천정부지로 치솟고 있습니다. 수백억 원의 연구 인프라와 최고의 인재가 확보되어야만 비로소 경쟁의 출발선에라도 설 수 있는 것이 현실입니다.AI를 OS로 바라보기이처럼 거대한 장벽 앞에서 우리는 좌절해야만 할까요? 저는 그렇지 않다고 생각합니다. 관점을 바꾸면 새로운 길이 보입니다. 바로 AI, 특히 LLM을 OS 레이어로 인식하는 것입니다.우리는 윈도우나 iOS, 안드로이드를 직접 만들지 않습니다. 이미 세상에 존재하는 강력하고 안정적인 OS 위에서 우리만의 독창적인 애플리케이션과 서비스를 만들어 새로운 가치를 창출합니다. 카카오톡이 안드로이드와 iOS 위에서 국민 메신저가 되었고, 수많은 스타트업이 AWS나 GCP 위에서 세상을 바꾸는 서비스를 만들어내고 있듯이 말입니다.마찬가지로, LLM 자체를 처음부터 개발하는 경쟁에 매몰되기보다, 이미 존재하는 강력한 LLM들을 마치 OS처럼 활용하고, 그 위에 우리만의 비즈니스와 서비스, 데이터에 맞게 ‘튜닝’하고 ‘커스텀’할 수 있는 역량에 집중하는 것이 더 현명한 전략 일 수 있습니다. 범용 리눅스 커널을 가져와 셋톱박스나 가전제품에 맞게 최적화된 임베디드 OS를 만드는 것과 같이 말입니다. 물론, 이 역량을 갖추기조차 쉽지 않지만, 이것이 바로 미국과 중국을 제외한 대부분의 국가와 기업이 집중해야 할 소버린 AI, 즉 ‘AI 기술 주권’의 핵심이라고 생각합니다.현재의 AI 시장은 2000년대 초반의 인터넷 시장과 놀라울 정도로 유사합니다. 당시에는 모두가 네트워크 망을 깔고 데이터센터를 짓는 인프라 경쟁에 열을 올렸습니다. 하지만 결국 시장의 진정한 승자는 그 인프라 위에서 콘텐츠와 서비스를 만들어낸 구글, 아마존, 페이스북과 같은 기업들이었습니다.지금도 LLM이라는 거대한 인프라를 구축하는 경쟁은 극소수 플레이어들의 승리로 귀결될 가능성이 높습니다. 하지만 진짜 부가가치와 혁신은 그 인프라 위에서 피어날 것입니다. AI라는 OS를 활용해 이전에는 불가능했던 새로운 사용자 경험을 만들고, 특정 산업의 고질적인 문제를 해결하는 애플리케이션과 서

안녕하세요. 에이닷에서 프론트엔드 개발 업무를 하고 있는 스카이입니다.지난 9월 23일 토요일 FEConf 2025가 열렸습니다.코로나 팬데믹 이후 오프라인 콘퍼런스는 오랜만이었는데 생각보다 사람들이 많아서 놀랐습니다. 다녀온 후기를 간단하게 정리해 보았습니다.FEConf는 매해 열리는 Front-End 콘퍼런스로 FE 기술을 공유하는 콘퍼런스입니다. 이번 콘퍼런스는 세종대학교에서 진행되었습니다.30분 단위로 세션이 있었고10분 단위의 Lightning talk 세션이 따로 있었습니다.세션 중에 가장 기억이 남는 세션들 위주로 정리해 보았습니다.이 세션에서 놀라웠던 건 스벨트의 파인 그레인드(fine-grained) 업데이트 방식이었습니다.리액트처럼 전체 컴포넌트가 재렌더링되는 게 아니라, 바뀐 부분만 딱 업데이트하는 방식을 말하는데 빠른 성능을 내는 큰 장점이 있어 보였습니다.또한 ref callback에 대해서도 설명했는데 Vue에서도 적용해 볼 수 있을 것 같습니다.간단하게 ref callback에 대해 설명하면, ref에 ref로 선언한 값만 할당할 수 있다고 생각했는데요.함수를 할당하는 방식을 말합니다. 다음은 예시 코드입니다.이 방식을 통해 페이지가 in/out될 때 애니메이션을 구현하는 예시를 보여주었는데 생각하지 못했던 접근법이라 신선했습니다.♿ 중요하지만 긴급하지 않은 일, 그럼에도 계획해야 하는 웹 접근성업무에 바빠 아무래도 우선순위가 낮을 수밖에 없는 웹 접근성에 대해 다시 생각해 보게 된 세션이었습니다.ARIA(Accessible Rich Internet Applications) 속성 하나하나가 누군가에겐 정말 중요한 의미라는 생각을 하게 되었습니다.ARIA 역할의 정의와 기본 원칙은 이렇습니다.• None ARIA는 HTML의 의미를 확장하거나 보완하는 역할로서, UI 요소에 적절한 역할을 명시해 보조기술에 정보를 제공함• None 이미 HTML에 정의된 역할은 우선적으로 사용하고, 없는 UI 패턴에 대해 ARIA 역할을 정의하여 표현함ARIA 속성을 정리해 보면 다음과 같습니다.• None aria-expanded : 메뉴나 리스트가 확장되었는지 여부를 나타냅니다.• None aria-selected : 선택된 항목을 표현한다고 합니다.• None aria-controls : 버튼 등 UI 요소가 제어하는 대상 요소의 ID를 연결해 상호작용 관계를 명확히 합니다.• None aria-labelledby, aria-describedby : 레이블과 설명을 연결해 시멘틱 정보를 보완합니다.🎨 최신 CSS? 10년 뒤에 쓰면 되나요?CSS 새로운 기능이 실제 적용되기까지 예전에는 5~8년 정도의 시간이 걸렸으나 요즘은 빠르게 진행되고 적용된다고 합니다.이 세션에서 그 예로 다음 두 가지를 알려주었습니다.Customizable Select, select box 디자인을 변경하려면 select 태그 자체로만 구현이 어려워 div, span 태그를 활용해야 했습니다.하지만 요즘에는 select에 CSS를 적용해서 가능하다고 합니다. 자세한 코드는 링크에서 확인하실 수 있습니다.또한 Popover API에 대해서도 언급해 주었는데요.이것 역시 실무에 사용해 볼 수 있는 기능으로 보입니다.🤖 UI 코드 생성 자동화를 프로덕션까지 (Figma MCP + Cursor)'오늘의 집' 회사에서 발표한 내용으로 Figma MCP + Cursor 조합으로 UI 개발은 Cursor에게 위임했다는 이야기였습니다.디자인팀과 1px로 싸울 일이 없다는 마지막 말은 너무나 감동적이었습니다.9명 팀에서 AI를 실제 프로덕션까지 도입한 사례로 국내에서는 거의 최초라고 하더군요.특히 디자인 시스템과 AI를 연결하는 부분에서 많은 노하우를 알려주셨습니다.유튜브에서 찾아보니 이것 관련 영상이 꽤 많이 나오더라고요. 참고해서 도입해 보면 좋을 것 같습니다.강남언니, 오늘의집, AWS, MOYO 부스가 있었습니다. 링크드인에 각 회사를 구독하면 상품을 주는 행사도 진행 중이었습니다.