Adot에 기억(Memory)을 장착하다최근 저희팀에서는 에이닷에 ‘메모리’를 도입했습니다. (관련 기사)이제 에이닷은 단순히 사용자의 대화를 기억하고 이를 토대로 점점 더 개인화된 경험을 주는 방향으로 진화하고 있습니다.이를 구현하기 위해 저희 팀은 서비스 요구사항에 맞춘 Agentic Memory를 직접 설계·개발했고, 빠른 iteration으로 품질을 높이기 위해 DSPy 기반 프롬프트 최적화까지 도입했습니다.이번 글에서는 이 메모리를 어떻게 만들었는지, 실제 적용 사례와 개발 과정에서의 시행착오, 그리고 DSPy 도입 배경과 효과까지 풀어보려 합니다.Agentic Memory는 간단히 말해 Agent처럼 작동하는 메모리입니다.사용자의 발화를 단순 로그로 남기는 것이 아니라, 의미 단위로 구조화하고, 인간의 뇌처럼 추가·수정·삭제를 통해 기억을 관리합니다.그리고 필요할 때 꺼내 쓰거나 갱신하며 점점 더 정교한 맥락 기반 응답을 가능하게 합니다.• None• None 대화 중 사용자의 발화에서 중요한 정보를 추출하고, 기존에 저장된 기억과 비교하여 ADD / UPDATE / DELETE 중 적절한 연산을 수행해 최신 상태를 유지합니다.• None User: "우와 나 데몬헌터스 너무 재밌었어, '골든' 노래 왜 이렇게 좋아?"→ '골든 노래를 좋아함' 메모리 ADD User: "아 이제 '골든' 좀 질렸어… 소다팝이 더 좋은 것 같아"→ "골든 노래를 좋아함" 메모리와 비교·병합 → '소다팝을 더 선호' 한다는 메모리로 UPDATE• None• None 현재 질문의 의도와 맥락에 가장 관련성 높은 과거 기억을 검색하여 쿼리를 보강하고, 답변의 정확도와 개인화를 높입니다.• None User: "그거 틀어줘, 데몬헌터스에 나왔던 내가 좋아하는 노래"→ "소다 팝을 틀어줌"메모리가 생기면서 확 달라진 경험을 예시로 들어볼게요.이 차이는 ‘기억’이 있냐 없냐에서 발생합니다. 같은 질문도 훨씬 더 개인 상황에 맞는 답변으로 변한 것이죠.개발 과정에서의 고민과 시행착오Agentic Memory를 만들면서 기획자분들과 실제 서비스를 테스트 하면서 유저 발화 중 어떤 부분이 장기적으로 저장할 가치 있는지 계속 구체화해 나갔습니다.이 과정에서 저희는 크게 세 가지 항목에 대한 고민과 시행착오를 거쳤습니다.무엇을 기억할까? — relevance_score로 노이즈 줄이기모든 대화를 다 저장하면 쓸데없는 데이터가 넘쳐났습니다. 단순 추천 요청/검색발화도 전부 중요한 메모리로 저장이되어 버려서 대화에 편향이 생기더라구요.예를 들어, 등산복에 대해서 한번 물어봤는데 주말에 뭐하지? 를 했을 때에 '등산'과 관련된 내용으로 응답에 편향이 생기기도 했습니다.추출되는 메모리가 얼마나 중요한가/반복적으로 언급되는가/장기적으로 기억할 가치가 있는가를 수치화하여 저장하고 선별적으로 활용하기로 하였습니다.이런 시행착오를 거친 후에, 저희 에이닷의 One Agent는 사용자가 대화 중 언급한 ‘기억할만한 정보’를 자동으로 인식하여,User Info와 User Event 두 가지 구조로 나누어 '구조화' 하여 문서 형태로 저장하게 되었습니다.• None 어떤 카테고리(category)에 해당하는• None 그리고 그 정보는 얼마나 장기적으로 기억할 가치가 있는지(relevance_score)초기에는 API 요청 시 실시간으로 메모리를 저장하는 방식을 고려했으나, 다음과 같은 문제점으로 인해 적절하지 않다고 판단했습니다.• None 실시간 저장의 불필요성: 메모리 저장은 즉시 완료될 필요가 없으며, 일정 시간 내에 처리되면 충분함.• None 높은 Latency: 메모리 저장 로직이 복잡하여 응답 시간이 길어지고, 이는 사용자 경험에 부정적 영향을 미침.• None 시스템 안정성: 동기 처리 시 메모리 저장 실패가 전체 API 응답에 영향을 줄 수 있음.따라서 아래와 같은 아키텍쳐를 구성했습니다.앞단의 Message Broker로 Kinesis Data Streams 를 두었고, Lambda 에서 aggreagate 후 SQS 로 전송할 수 있도록 했습니다.SQS 로 전송된 메세지들은 Lambda 에서 consume 하여 최종적으로 memory-layer 서버에 메모리 생성 요청을 하게됩니다.N분간의 사용자 메시지를 모아서 메모리를 생성하여야하는 요구조건이 있었기 때문에 Window 를 지원하는 Kinesis Streams 를 사용하게 되었습니다.따라서, 채팅 메시지 응답 이후에 저장 이벤트가 따로 발생되도록 구성되어, 사용자 응답 속도에는 영향을 주지 않습니다.오픈 전, 메모리 저장/발현에 대한 여러번의 Iteratioin을 돌면서, “무엇을 저장할지”에 대한 기준이 조금씩 바뀌면서 구체화 되기 시작했습니다.이걸 매번 사람이 프롬프트를 고치면서 따라가는 건 속도도 느리고 일관성도 깨지더라고요.그래서 DSPy(Programming—not prompting LMs)를 도입해 프롬프트를 데이터 기반으로 자동 최적화하는 루프를 만들었습니다.이 최적화 루프를 통해 다음과 같은 개선이 가능해졌습니다.• None 개발 효율성 증가: 사람이 직접 수정하던 프롬프트를 자동 최적화 → 반복 작업 최소화.• None 성능 극대화: Golden Dataset으로 검증된 데이터를 활용해 메모리 저장 정확도 성능 향상.• None 유지보수 용이성: 새로운 요구사항이 생길 때마다 데이터 기반으로 빠르게 DSPy 기반으로 프롬프트를 업데이트.이번 Agentic Memory 개발은 저와 우리 팀 모두에게 큰 도전이었습니다.단순한 챗봇이 아니라, 사용자와 장기적인 관계를 맺는 에이전트를 만들기 위한 첫걸음이었으니까요.시행착오도 많았지만, 그만큼 얻은 성과도 컸습니다.덕분에 저희는 앞으로도 유저 맞춤형 기억을 빠르게 개선하고, 더 나은 개인화 경험을 제공할 수 있게 되었습니다.

안녕하세요. AI Services Lab 팀의 ML 엔지니어 박희웅입니다. 저희 팀에서는 LINE 오픈챗과 관련해 다양한 AI/ML 모델을 개발해 서빙하고 있는데요. 지난 오프라인과 온라인 A/B 테스트를 통해 오픈챗 추천 모델 개선하기 포스트에서는 개인 취향에 맞는 오픈챗들을 추천하는 모델의 개선 과정에 대해 공유드렸고, 이후 오픈챗 해시태그 예측을 위한 다중 레이블 분류 모델 개발하기 포스트에서는 오픈챗을 생성할 때 해시태그 지정을 돕는 해시태그 예측 모델을 어떻게 개발했는지 공유드린 바 있습니다.이번 글에서는 오픈챗들에서 오가는 메시지 콘텐츠로부터 유행하는 주제 키워드를 어떻게 추출할 수 있는지 소개드리고자 합니다.현재 오픈챗 서비스의 메인 화면은 채팅방 검색과 추천, 랭킹 기능 위주로 구성돼 있으며, 추천으로 노출되는 아이템은 대부분 채팅방 그 자체입니다. 오픈챗 주제를 키워드 나열 형태로 추천하고 있기는 하지만 키워드를 클릭하면 결국 이와 연관된 채팅방들이 노출되는 방식입니다.이와 같은 메인 화면은 사용자에 따라서 지속적으로 재방문할만큼 매력적이지는 않을 수 있습니다. 각 채팅방은 일종의 작은 커뮤니티로 사용자가 하나의 채팅방을 파악하려면 커버뷰에 적힌 설명글과 메시지 요약글을 읽어보거나 실제로 채팅방에 입장해 이전에 오간 콘텐츠를 확인하는 등의 노력이 필요합니다. 따라서 이미 마음에 드는 채팅방을 발견하고 가입해서 활발히 참여하고 있는 사용자의 경우 새로운 채팅방을 탐색할 동기가 약해지면서 주로 채팅방 위주로 노출되는 메인 화면 방문이 뜸해질 수 있습니다.여기서 고려해야 할 점은, 메인 화면 방문자 수가 오픈챗 서비스의 주요 KPI라는 것입니다. 서비스 활성도를 대표할 뿐 아니라 광고 매출과도 연결되기 때문입니다. 이러한 배경 하에 채팅방 대신 채팅방에서 주고받는 메시지 콘텐츠를 메인 화면에 노출해 보는 것을 구상하게 되었습니다.오픈챗 서비스를 다른 마이크로 블로그 서비스와 비교해 보면 채팅방은 인플루언서의 계정에, 메시지는 계정에 게시된 포스트에 대응시킬 수 있는데요. 대부분의 마이크로 블로그 서비스는 주로 포스트를 메인 화면에 노출합니다. 일반적으로 마이크로 블로그 서비스는 신규 포스트를 보기 위해 서비스 메인 화면에 방문하는 사용자의 비율이 새로운 인물을 팔로잉하려는 비율보다 높을 것이기 때문입니다. 포스트를 탐색하는 와중에 취향에 맞는 계정을 발견하는 선순환이 발생할 수도 있고요.그런데 마이크로 블로그의 포스트와는 달리 대부분의 오픈챗 채팅방의 메시지 단건은 독립된 콘텐츠로 제공하기에는 적합하지 않습니다. 빠르게 주고받는 모바일 채팅의 특성상 오타나 비문이 많고 생략된 부분도 많기 때문에 채팅 중간의 메시지 하나만 떼어 놓으면 전체 맥락이 잘 파악되지 않기 때문입니다.이에 따라 저희는 비슷한 주제의 메시지들을 묶어서 콘텐츠화하는 방향으로 가닥을 잡았으며, 이때 주제가 가시적으로 드러나도록 메시지에 등장한 주요 키워드 기반으로 묶는 방식을 채택했습니다. 이와 같은 접근 방식의 핵심은 메시지 텍스트 말뭉치에서 유행하는 주제 키워드를 추출하는 기법인데요. 이 기법을 어떻게 구현해 적용했는지 소개하겠습니다.먼저 메시지 텍스트 말뭉치에서 지금 유행하는 '트렌딩 키워드'가 무엇인지를 어떤 기준과 방법으로 선정했는지 살펴보겠습니다.유행하는 키워드를 탐지하는 방법으로 단순히 최근 등장 빈도가 높은 단어를 선택하는 방식을 떠올릴 수 있습니다. 하지만 오픈챗에 이 방식을 사용하면 검색 포털의 검색어라든가 뉴스 포털의 댓글 같이 해당 시점의 화제가 적절히 반영된 단어들이 뽑히지 않고, 인삿말이나 고마움, 웃음 표현과 같은 너무나 일상적인 단어들이 뽑힙니다. 오픈챗 커뮤니티는 사용자들이 일상적으로 담소를 나누는 공간이자 새 멤버들이 수시로 가입하는 공간이기에 인사나 소개, 환영의 말 등이 대화에서 높은 비중을 차지하기 때문입니다.따라서 저희는 일별로 단어의 등장 빈도를 집계하면서 빈도가 급격하게 증가하는 단어를 트렌딩 키워드로 정의했습니다. 집계 기간 단위를 하루로 설정한 이유는 두 가지입니다. 하나는 통계적으로 유의미한 샘플을 충분히 확보하기 위해, 또 하나는 대부분의 사용자들이 하루에 한번만 오픈챗 메인 화면에 방문한다는 데이터 분석 결과가 있었기 때문입니다.빈도 증가량을 측정할 때는 일주일 전의 해당 단어의 빈도를 기준으로 삼았습니다. 이 방식에는 두 가지 이점이 있는데요. 첫 번째는 특정 주제가 화제로 떠오를 때 그 열기가 하루에 그치지 않는 경우가 종종 나타난다는 점에 기인합니다. 바로 전날과의 빈도 차이만 고려할 경우 화제성이 정점에 달해 피크가 지속되고 있음에도 증가량이 미미해 트렌딩 키워드로 탐지되지 않을 수 있습니다(이에 대한 사례는 아래에서 자세히 살펴보겠습니다). 두 번째는 이 방식을 사용하면 일주일마다 반복적으로 언급되는 요일 관련 단어들을 자연스럽게 억제할 수 있습니다. 참고로 같은 이유로 한 달 전 빈도와도 비교하도록 구현했는데요. 이 글에서는 논의를 간결히 하기 위해 해당 내용은 생략하겠습니다.두 빈도값 간의 차이를 계량하는 지표로는 이표본 모비율 차 검정을 위한 Z-테스트 통계량을 사용했습니다. 각 단어별로 Z-테스트 통계량을 계산하고 이를 점수로 사용해 점수가 높은 키워드를 트렌딩 키워드로 선정합니다. 이 방식은 메시지 하나하나가 독립적으로 작성된 메시지라고 간주하기는 어렵기 때문에 유의 확률에 기반해 엄밀하게 가설을 검정할 수는 없지만, 트렌딩 키워드로 가히 분류할 수 있는 최소 점수 임곗값을 정규 분포 곡선을 참고해 결정할 수 있습니다. 또한 빈도수가 작을 때 영향력이 커지는 노이즈 효과를 확률 분포 이론에 근거해 감안할 수 있다는 것도 좋은 점입니다.통계랑 Z를 수식으로 살펴보기 위해 수식에 사용할 기호를 다음과 같이 정의하겠습니다.• : 타깃 단어의 출현 빈도(term frequency, TF). 해당 단어를 포함하는 메시지의 수이며, 현재 TF에는 , 이전 기준선 TF에는 사용위와 같이 기호를 정의했을 때 통계량 Z값은 다음과 같습니다.여기서 주의해야 할 점은 빈도가 커질수록 비율 차이가 크지 않음에도 통계량 Z값이 크게 측정되는 경

안녕하세요, 카카오의 언어모델 ‘Kanana’의 연구 및 개발을 담당하는 Kevin, Louie, Terry, 그리고 Sean 입니다. 2024년 9월 OpenAI의 o1 모델이 출시되고, 2025년 1월에 DeepSeek R1이 공개된 이후, LLM의 추론 능력에 대한 관심이 폭발적으로 늘어났습니다. 학습 단계에서 더 많은 연산 자원을 투자하는 것은 물론, 테스트 시점에도 사고 과정에 충분한 연산을 할당하는 방식의 LLM 추론 기술은 기존 LLM들의 성능을 한 차원 높여주고 있습니다. 이제 LLM은 대부분의 사람보다 코드포스(Codeforces) 순위가 높고, 고등 수학 올림피아드 문제도 인간보다 더 잘 푸는 시대가 되었습니다.저희도 Kanana의 성능을 혁신적으로 높이기 위해 다양한 내부 연구를 꾸준히 이어왔습니다. 그 결과, 기존에는 풀지 못했던 많은 문제들을 추론 기법을 도입하여 성공적으로 해결할 수 있게 되었습니다. 이번 블로그에서는 이러한 연구 과정에서 저희가 겪었던 시행착오와 인사이트를 여러분과 공유하고자 합니다.LLM이 추론 능력을 발휘한다고 판단할 수 있는 대표적인 신호는, 모델의 답변에서 계획(Planning), 평가(Evaluation), 반성(Reflection), 탐구(Exploration)와 같은 사고 과정이 드러나는 경우입니다. 이러한 개별적인 요소들은 웹 텍스트, 책, 혹은 인간 간의 대화 속에서도 자연스럽게 존재하지만, 특정한 문제 풀이 상황에서 이 모든 과정이 복합적으로 드러나는 경우는 드뭅니다. 기존 학습 단계에서 이러한 추론 패턴이 충분히 내재화되지 않았다면, 이를 보완하기 위해서는 추론 중심의 학습 데이터(Reasoning Demonstration Data)를 기반으로 Supervised Fine-Tune(SFT)를 수행하는 과정이 필요합니다.SFT는 단순히 모델이 추론 과정을 내재화하는 역할만 하는 것이 아니라, 강화학습(Reinforcement Learning, RL) 단계가 효과적으로 작동하기 위한 초석을 마련합니다. RL에서는 반드시 긍정적인 학습 신호(Positive Signal)가 필요합니다. 하지만 RL 초기 모델이 문제를 전혀 풀지 못한다면, 학습 과정에서 어떤 방식으로 문제를 접근해야 하는지 단서조차 얻을 수 없어 성능 향상을 기대하기 어렵습니다.이 점은 저희가 진행한 Zero-RL 실험을 통해 명확히 확인되었습니다. 여기서 Zero-RL이란, SFT(지도 학습)를 전혀 거치지 않은 Pre-trained 모델을 바로 강화학습에 투입하는 방식을 말합니다. 아래 그래프는 Kanana-9.8B 모델을 PPO 알고리즘으로 Zero-RL 실험을 수행했을 때의 Reward 그리고 AIME 2024 점수 변화를 보여줍니다. Kanana-9.8B 모델의 Reward 점수를 보면 최대 0.3 수준에 그치는 걸 확인할 수 있습니다. 특히 AIME 2024 평가에서 대부분의 타임 스텝에서 0점을 기록하였습니다. 이는 곧 SFT 없이 RL만으로는 충분한 학습 신호를 얻기 어렵다는 점을 잘 보여줍니다.최신 공개된 연구들에서도 비슷한 패턴을 확인할 수 있습니다. Magistral 24B 모델은 SFT만으로도 AIME2024에서 pass@1 65.4점을 기록했습니다. 여기서 중요한 점은, 기존의 많은 수학 Reasoning 관련 연구들이 주로 최종 RL 단계의 성능만 리포트하고, SFT 단계에서의 구체적인 성능은 잘 드러내지 않았다는 것입니다. 이로 인해 SFT가 얼마나 중요한지, 그리고 RL 성능이 어디서부터 출발하는지 명확하게 파악하기 어려웠지만, Magistral은 SFT 성능 자체를 명확히 공개했습니다.그 수치는 이미 기존 RL 기반 모델들이 도달한 성능에 필적하거나 그 이상이었습니다. 이를 통해 저희는 “좋은 성능의 Reasoning LLM을 얻기 위해서는 SFT 단계에서 이미 충분히 높은 성능이 확보되어야 한다”는 사실을 직접적으로 확인할 수 있습니다. 즉, Magistral은 단순히 뛰어난 성능을 보인 모델일 뿐 아니라, SFT의 중요성을 실험적으로 뒷받침한 드문 사례라고 할 수 있습니다. 따라서 SFT는 단순한 전처리 과정이 아니라, 좋은 성능의 Reasoning LLM을 만들기 위해 반드시 거쳐야 하는 핵심 단계라 할 수 있습니다.앞서 설명했듯이 SFT 단계에서는 추론 과정을 모델이 학습할 수 있도록 Reasoning Demonstration Data가 필요합니다. 이러한 데이터는 일반적으로 아래의 두 가지 방식으로 만들어 집니다.• CoT Prompting 기반 생성 추론 특화 모델이 없는 상황에서, Instruction-following 능력이 강력한 PLM(Pre-trained Language Model)을 활용해 Chain-of-Thought(CoT) prompting을 적용하는 방식입니다. 이 방법은 DeepSeek-V3처럼 자체적으로 매우 강력한 PLM을 보유한 경우에 효과적입니다.• 추론 모델 기반 Data Distillation 이미 공개된 강력한 추론 모델을 활용하여 질문–정답 쌍에 대한 체계적인 추론 과정을 생성하고, 이를 Reasoning Demonstration 데이터로 활용하는 방식입니다.최근 오픈소스 추론 모델들은 단순 CoT prompting 기반 PLM보다 훨씬 뛰어난 성능을 보이고 있습니다. 따라서 저희는 이러한 최신 추론 모델들의 강점을 적극적으로 활용할 수 있는 Data Distillation 방식을 선택했습니다. 이는 단순히 자체 PLM의 Instruction-following 능력에 의존하기보다는, 이미 검증된 오픈소스 Reasoning 모델이 보여주는 안정적이고 높은 품질의 추론 경로를 학습 데이터로 이전할 수 있다는 점에서 훨씬 효율적입니다.저희는 높은 품질의 추론 경로를 활용하기 위해서, 오픈소스 Reasoning 모델로부터 생성된 SFT 데이터(예: AM-DeepSeek-Distilled-40M, AceReason-1.1-SFT)를 활용하는 것을 기본으로 하고, 모델이 추론을 배우는 데 진짜 도움이 되는 데이터만을 잘 고르는 데에 집중했습니다. 이를 위해 DeepDistill에서 제

이번 글에서는 LLM의 등장과 함께 새롭게 등장한 용어, '프롬프트 엔지니어링' 기법들을 알아보고 여러 프롬프트 엔지니어링 기법들을 혼합해서 GPT 앱을 만드는 방법을 알아보려고 합니다.최근에 본 컬럼 중에 "정답을 좇을 것인가 질문을 설계할 것인가"라는 글이 있습니다. 프롬프트 엔지니어링은 원하는 답을 찾을 수 있도록 정답을 설계하는 과정입니다.즉, 컴퓨터와 자연어를 통해서 대화하며 LLM에게 잠재되어 있는 많은 속성과 능력을 활용해서 정답을 설계하는 과정이라고 볼 수 있지요.프롬프트 엔지니어링은 아래와 같은 공식으로 표현할 수 있을 것 같아요. 마치 프로그래밍 시, Object에서 속성을 뽑아내는 거라고 생각됩니다.즉 LLM 내에는 문헌으로 존재하는 수많은 사람들의 글, 그림 등이 모두 학습되어 있는데, 프롬프트 엔지니어링을 통해 내가 풀고자 하는 문제에 대해서 역할을 부여하는 것 부터 시작합니다.대표적인 프롬프트 엔지니어링 기법은 아래와 같은 것들이 있고, 수많은 프롬프트 엔지니어들이 시행착오와 실험을 거쳐 새로운 방법을 계속해서 발견하고 체계화하고 있습니다.• None 역할 지정 기법 (Role Playing): "넌 지금부터 ㅇㅇ분야에 서 아주 뛰어난 전문가야. 다음 묻는 말에 ㅇㅇ 전문가로서 답해줘: "• None 형식 지정 기법: "#명령문 #제약 조건 #출력 형식 #입력문: " 형태로 항상 써먹을 수 있는 형태의 템플릿을 만들어서 입력문만 바꾸어 사용하는 기법• None Few Shot 기법: 프롬프트에서 몇개의 예시를 주는 기법• None Q&A 기법: 질문, 답변을 나열해서 질문에 대해 답변하는 형태를 알려주는 기법• None 이어쓰기 기법: LLM은 기본적으로 문장을 이으려는 습성을 가지고 있는데, 이를 활용하는 기법또한 학자들이 프롬프트 엔지니어링을 체계적으로 연구를 한 후 발표하고 있는데요.Tree of Thoughts 기법 (2023년, Tree of thoughts: Deliberate problem solving with large language models)에 대해 비교, 분석해 보도록 하겠습니다.복잡한 사고가 요구되는 문제를 풀기 위해 단계적 사고를 하라고 모델에 지시하는 프롬프트 기법• None 즉, 과정을 강제함으로써 '환각' 현상을줄이고 생성 결과에 대해 논리적인 단계로 검증 가능하도록 하는 기법입니다.• None 복잡한 문제에 대하여 다양한 추론 경로를 탐색하고 자체적으로 평가하여 최적의 해결책을 찾는 기법논문에 언급된 구현 방식은 네 가지 요소로 구성됩니다.• None Thought Decomposition: 문제를 여러 '생각'의 단계로 분해• None Thought Generator: 다음 단계에 필요한 '생각' 생성• None State Evaluator: 현재 상태를 평가하여 문제해결에 가까운 정도 판단• None Search Algorithm: 문제해결 과정에서 다양한옵션을 탐색하고 평가이를 잘 진행하기 위한 프롬프트 엔지니어링 방법은 아래와 같습니다.• None 명시적 브랜치 요청: "여러방법을 동시에 탐색하세요"• None 평가기준 제시: "각 방법을 점수로 평가하세요"• None 선택과 포기 지시: "가장 좋은 것만 계속 진행하세요"• None 백트래킹 허용: "막다른길이면 돌아가세요"• None 최종통합요청: "가장 성공적인 경로의 해답을 제시하세요"GPT 앱을 만들기 위해서 아래와 같은 단계로 진행합니다.이 글에서는 '연구 논문 계획서 작성' 앱을 예제로 만들어 보고자 합니다. 논문을 작성할 때 과정을 보면 일반적으로 아래와 같은 과정을 거치게 됩니다.이 때 주제와 관련된 선행논문 탐색과 연구방법론 도출에 많은 시간이 소요되는데, 이 과정을 자동화하는 GPT앱을 만들고자 합니다.• None 연구 주제 선정 --> 이론적 배경 (선행논문 탐색) --> 연구 방법론 도출 --> 연구 결과 작성연구 논문 기획이라는 특성에 맞추어 아래와 같이 프롬프트 엔지니어링을 구성하였습니다.즉, '학술 연구전문가(academic research expert)'라는 역할을 부여하고 단계별로 생각할 수 있도록 Chain of thought 프롬프팅 (Let's think step by step)으로 시작합니다.1. 학계 전문가, 산업실무자 등 다양한 이해관계자의 관점에서 해당 연구주제가 연구할만한 가치를 분석하고(Role Playing),2. 이와 관련된 선행연구 조사를 원하는 포맷으로 검색, 정리하고 (Few shot 기법)3. 진행 가능한 다양한 연구방법을 탐색해서 스스로 평가하고 가장 유망한 방법 2가지를 선택하게 하여,최종 연구방법론을 제안 받도록 합니다.(Tree of thoughts)이에 따른 프롬프트 엔지니어링의 구성은 다음과 같습니다.chatGPT에 접속해서 왼쪽 메뉴의 GPT를 선택하면 앱을 만들고 다른 사람이 만든 앱도 사용해 볼 수 있습니다.오른쪽 상단에 '만들기' 버튼을 클릭합니다.이후, 아래와 같이 앱 등록 창에 필요한 항목들을 입력하면 되는데 가장 핵심적인 부분은 '지침' 칸으로 이곳에 프롬프트 엔지니어링 작업 결과물을 등록해야 합니다.필요한 항목들을 입력하고 나서 아랫 부분에 있는 '새 작업 만들기' 버튼을 누르면 GPT 앱이 등록됩니다.입력: 아래와 같이 프롬프트를 입력하면....결과: 이렇게 하면 5~6장 정도의 요구사항에 맞는 연구계획서가 필요한 양식에 맞추어서 작성됩니다.Role Playing 기법을 활용해서 다양한 이해관계자들의 관점을 이해하고, 선행연구를 내가 원하는 포맷으로 효율적, 효과적으로 가져옵니다.Tree of thoughts 기법의 장점은 다양한 연구 방법론의 대안을 제시하고 스스로 비교, 분석, 평가해서 가장 좋은 대안을 제시하는 것이라서 관련 연구 기간의 단축에 도움이 될 것으로 생각됩니다.상단 오른쪽 버튼의 공유하기 후 필요한 내용을 선택한 후 공유하면 됩니다.

지난 글에서 Jetson Thor의 기본적인 설명을 끝냈다면 이번엔 직접 실행해본 결과를 공유하는 내용을 작성해 보도록 하겠습니다.기본적으로 시작하기 앞서 필요한 준비물이 있습니다.Jetson Thor는 Linux Host PC 없이 기존 PC용 리눅스를 설치 하는 방법과 동일하게 iso 이미지로 부트 USB를 만들어 설치가 가능 합니다.부팅용 USB는 Jetson BSP ISO Image를 받아 Balena Etcher App을 통해 설치하여 준비하면 됩니다대부분의 설치 방법은 Quick Start Guide에 잘 나와 있으므로, 설치하면서 약간 이상했던 부분 위주로 설명드리겠습니다.부팅 되고 난 후, 설정에 따라 진행하다 보면 UEFI firmware update 과정이 실행됩니다.이 후, 재부팅 되고 바로 Jetson Ubuntu 설치 화면으로 들어가야 하는데,다시 Jetson BSP installation menu 가 나온다면 당황하지 마시고 다시 한번 UEFI firmware update를 진행하면 됩니다.UEFI firmware update가 정상적으로 완료되고 나면, 아래 사진과 같이 Ubuntu 설치를 진행하면 됩니다.Linux 설치 후 아래와 같은 화면이 나오면 설치 완료 및 준비가 끝났습니다.Jetson Thor 설정이 완료 되었으므로 본격적인 테스트를 해보았습니다.실습의 내용은 HIL 즉, 실제 하드웨어 장치와 시뮬레이션을 연결해서 테스트하는 것입니다.Digital Twin을 하는 가장 큰 이유 중 하나는 실제 환경에서 시도해 보기 어려운 작업을 시뮬레이션 환경에서 테스트 해볼 수 있다는 점 입니다.그런 이유에서 HIL은 Digital Twin의 중요 요소라고 할 수 있습니다.이번 테스트의 환경 구성은 다음과 같습니다.해당 환경으로 실제 휴머노이드 로봇은 없지만 시뮬레이션 환경에서 로봇의 카메라 영상을 실시간으로 추론 모델에 전달,추론 모델에서는 받은 이미지를 통해 해당 조인트의 액션 값을 예측하여 시뮬레이션 상의 GR1T2 휴머노이드 로봇으로 보내고 결과적으로 로봇이 스스로 물건을 옮기는 상황을 진행할 예정입니다.위의 시뮬레이션으로 실제 동작과 동일한 환경을 미리 테스트 해보고 개선하여 검증된 모델을 그대로 실제 로봇에 적용하여 사용할 수 있게 됩니다.이러한 방법으로 실제 로봇 을 운영하면서 발생할 리스크를 줄일 수 있고, 미리 검증을 함으로써 비용도 아낄 수 있는 방법으로 HIL이 사용된다고 볼 수 있습니다.자세한 사항은 아래 실제 시뮬레이션 결과를 통해 확인해 보실 수 있습니다.이번 테스트에서 사용된 모델과 데이터 셋에 대한 설명이 필요할 것 같아서 간단히 집고 넘어가겠습니다.해당 모델인 NVIDIA Isaac GR00T N1-2B는 세계 최초의 오픈 파운데이션 모델로, Cosmos가 데이테 셋을 모으기 위한 설계된 모델이라면,위 모델은 범용적인 휴머노이드 로봇의 추론과 기술 수행을 위해 설계되었습니다.• None• None 상태: 로봇의 고유 감각 데이터이와 같이 비전을 입력으로 받고 모터 제어의 액션을 출력으로 하는 모델을 VLA (Vision Language Action) 라고 하며,VLA 모델은 시각적 정보(Vision), 자연어 지시(Language), 그리고 물리적 행동(Action)을 통합적으로 처리할 수 있는 차세대 AI 모델입니다.이러한 모델은 다음과 같은 특징을 가집니다:• None 멀티모달 입력 처리: 카메라 영상, 텍스트 명령, 센서 데이터를 동시에 처리• None 행동 생성: 입력된 정보를 바탕으로 로봇의 구체적인 동작을 출력• None 상황 인식: 환경을 이해하고 적절한 반응을 생성• None 언어 기반 제어: 자연어 명령을 물리적 행동으로 변환VLA 모델은 전통적인 로봇 제어 시스템과 달리, 인간과 같은 방식으로 시각적 정보와 언어적 지시를 종합하여 의사결정을 내릴 수 있습니다.테스트를 위해 사용된 모델은 위에서 설명한 NVIDIA Isaac GR00T N1-2B을 베이스로 하여 견과류 따르기 작업을 위한 전문적인 훈련 데이터로 파인튜닝 된 모델을 사용합니다.기본 베이스인 NVIDIA Isaac GR00T N1-2B는 다양한 데이터를 기반으로 학습된 모델이기 때문에,특정 작업이나 특정 로봇의 행동을 예측하는 모델이 필요하다면 필수적으로 데이터 셋을 통한 파인튜닝이 필요합니다.테스트로 진행된 모델의 데이터 셋은 실제 환경에서 로봇의 카메라로 만들어진 영상이 아닌 시뮬레이션 환경에서 만들어진 영상, 즉 합성데이터를 기반으로 하고 있습니다.이제 본격적으로 테스트를 진행합니다.해당 테스트는 Jetson Thor Setup and Demo Guide 문서 내용을 토대로 진행 하였습니다.• None 시뮬레이션 환경의 로봇의 카메라의 영상을 실시간으로 Jetson Thor에 전달• None• None ROS2 DDS는 UDP Multicast를 이용하여 통신• None 같은 공유기, 라우터, 스위치 내에 있어야 통신 가능• None 그 외의 환경을 CycloneDDS 또는 Discovery Server 설정을 통해 가능실제 시뮬레이션의 동작 과정을 도식화 하면 아래 그림과 같습니다.테스트를 위한 앱 및 모델은 Jetson Thor Demo를 위한 도커 컨테이너 환경에서 실행 하였으며,GR00T 모델과 데이터셋에 대한 내용과 실습 환경인 ROS2 그리고 그 외의 내용에 대해선 다음 기회에 다뤄보도록 하겠습니다.영상의 왼쪽은 시뮬레이션 환경에서 로봇의 카메라로 보여지는 장면입니다.영상엔 없지만 GR00T 모델에선 로봇의 카메라 영상을 실시간으로 입력 받아 왼쪽 아래에서 보는 것과 같이 로봇 제어의 모터 값을 전달(Publisher)해 줍니다.오른쪽 위, 시뮬레이션 환경인 Isaac Sim에서 GR00T모델에서 전달해준 로봇 제어의 모터 값을 통해 실제 로봇의 움직임을 표현해 줍니다.Jetson Thor 보드를 셋팅하고 검증하는 방법으로 HIL 데모를 진행 했습니다.이 테스트에서는 일반적인 휴머노이드 작업용으로 설계된 GR00T 모델을 살펴보고, Thor에서 추론을 실행하는 모습을 관찰하고, Isaac Sim의 시뮬레이션 환경 설정을

Product Designer 현정 님은 토스에서 계속 새로운 임팩트를 만들어가고 있어요. B2B부터 광고, 이제는 돈을 들이지 않고 사용자를 모으는 전략까지. 전혀 다른 듯 보이지만, 이 모든 길에는 공통점이 있어요. 바로, 없던 길을 스스로 만들어왔다는 것. 0에서 1, 그리고 1에서 100으로 키워가는 과정에서 현정 님은 어떤 마음으로 임팩트를 만들어왔을까요?Q. 패션 업계에서 커리어를 시작하셨어요. 어떠셨나요?네, 정말 '패션 회사 막내' 하면 떠오르는 거의 모든 일을 다 해봤어요. 피팅, 촬영 소품 구하기 같은 것들이요. 업무 강도는 괜찮았고 재미도 있었지만, 현실적인 고민이 많았어요. 급여는 낮고 소비문화는 강했거든요.더 근본적인 문제는 의사결정 구조였어요. 직급 높은 사람의 직관과 주관으로 모든 게 결정되다 보니, 이유 없이 "이 콘셉트로 가자"가 통하는 환경이었죠. 너무 비합리적이라고 느꼈어요.Q. UX/UI 업계로는 어떻게 오게 되셨어요?UX는 사용자를 분석하고 문제를 파악해 개선하는 일이잖아요. 적어도 패션보다는 훨씬 논리적일 거라 생각했어요. 그래서 디자인 부트캠프를 들었죠. 처음으로 '내가 잘할 수 있는 일'을 찾은 것 같았어요. 과제가 주어지면 바로 답이 떠오르고, 선생님도 자주 짚어주셨어요. "이렇게 쉬운데 왜 다들 어렵다고 하지?" 싶을 정도로 재미있었어요. 그 6개월이 정말 행복했어요.Q. 실무는 기대와 같았나요?첫 실무는 디자인 에이전시에서 시작했는데, 기대와는 좀 달랐어요. 사용자를 고민하기보단 예쁜 장표를 만들고 '그럴듯하게 포장하는' 일이 대부분이었죠. 합리성을 찾아 UX 업계로 넘어왔는데 여전히 비합리적이라고 느꼈어요.그래서 외국계 스타트업으로 옮겼어요. UX라는 개념이 해외에서 시작된 만큼, 그 근본에서 일해보고 싶었거든요. 초기 SaaS 스타트업이었는데, 처음엔 해외로 가기 위한 브리지 정도로 생각했어요. 그런데 그곳에서 처음 '진짜 UX'를 경험했어요.‘사람들이 진짜 원하는 게 뭘까?’라는 질문에서 일이 시작됐으니까요. 단순히 UI가 아니라 콘셉트와 브랜딩까지 고민하며 회사 방향성을 함께 만들어가는 과정이 정말 재미있었어요. 이때 처음으로 "0에서 1을 만드는 일"의 매력을 느꼈어요.Q. 재미있었는데 토스로 이직을 결심한 이유는요?회사 규모가 커지면서 문화와 방향성이 바뀌는 게 힘들었어요. 처음엔 사용자를 고민하며 제품을 만들었지만, 점점 그런 환경이 아니게 됐거든요. UX를 하고 싶었는데 UX를 하지 못하는 자리에 있다는 느낌이 들었어요. 그래서 제품에 애정이 깊은 사람들이 모인 토스로 오게 됐어요.Q. 토스 입사하고 나서는 그런 갈증이 해소가 되셨나요?솔직히 처음엔 기대에 못 미쳤어요. ML팀의 인터널 제품을 맡았는데, 당시 팀이 막 만들어진 단계라 성과 증명이 더 시급했거든요. 디자인으로 직접 임팩트를 내기보단 빠르게 성과를 내는 게 중요했어요. 제가 기대했던 만큼 디자인을 통해 직접적인 영향을 줄 기회가 많지는 않았던 거예요. 그래서 희연 님 찾아가서 “저 일 더 주세요”라고 말하기도 하

오늘은 Toss USA에서 Director of Engineering으로 근무하고 계신 고동일(Diko Ko)님의 커리어 이야기를 들려드려요. Diko님은 한국 IT 업계가 막 시작되던 90년대에 게임 개발자로 커리어를 시작해, 미국의 글로벌 회사와 창업 등 정말 다양한 경험을 거쳐 오셨는데요. 지금은 실리콘 밸리에 위치한 Toss USA에서 토스의 광고 기술을 고도화하기 위해 실험과 연구를 진행하고 계십니다.Q. Diko님은 스스로를 세 가지 정체성으로 정의한다고 들었어요.저는 제 인생을 세 가지 페르소나로 나눌 수 있다고 생각해요. 하나는 Anime Otaku, 또 하나는 Game Developer, 그리고 지금의 Engineer/Producer예요. 제 자아는 이 세 가지 축이 겹치며 만들어진 것 같아요.Q. 순서대로 얘기해보고 싶어요. 애니메이션에는 어떻게 빠져들게 되셨나요?중학생 때 변덕쟁이 오렌지로드(きまぐれオレンジ☆ロード)라는 애니를 보게 된 게 계기였어요. 문제는 그 당시 일본 애니메이션을 보는 건 불법으로 취급됐다는 거죠. 보고 싶으면 회현역 지하상가에 VHS 테이프를 들고 가서 불법 복사를 해야 했어요. 정말 마약 거래 같은 느낌이었죠.주변의 시선에 굴하지 않고 보고싶은 것을 보려면, 1등을 해야한다는 생각을 했어요. 그 단순한 동기 덕분에 공부를 열심히 했고 서울대학교 컴퓨터공학과에 진학했어요.당시는 90년대 초였고, 일본 애니메이션을 좋아한다는 이유만으로 압박이 있었던 시기였지만 굴하지 않았어요. 직접 번역하고 자막을 달아 상영회를 열었고, 결국에는 선배들의 인정을 받게 됐죠. 그렇게 만든 동아리가 애니뮤인데, 지금도 서울대학교 공대에서 활동하고 있어요.Q. 애니메이션이 자연스럽게 게임 개발로 이어졌군요?맞아요. 애니메이션을 좋아했고, 당연히 게임도 좋아했죠. 컴퓨터공학과를 선택한 것도 그런 이유였어요. 대학원 석사 과정 중이었던 1997년, 같은 연구실에서 박사 과정을 밟고 있었던 김택진 대표님이 막 엔씨소프트라는 회사를 창업했고 함께 일할 것을 제안하셨어요. 밤에는 일을 하고, 아침에는 연구실에서 잠을 자는 생활을 이어갔어요.당시 전체 인원이 20명도 되지 않던 엔씨소프트에서, 게임 개발을 하고싶었던 차에 리니지 프로젝트에 참여하게 되었어요. 당시 리니지팀은 3명이었고, Sun Solaris 서버에 언어는 Objective C로 구성되어 있었어요. 동시 접속자는 겨우 300명 정도였는데요, ‘말하는 섬’만 존재했답니다. 밤에는 GM을 하고, 동시에 유저 캐시 서버도 만들었어요. 지금은 너무나도 당연한 Redis 같은 기술이 없던 시절이라, 서버가 죽으면 유저 데이터가 통째로 날아가곤 했습니다. 그래서 이를 백업으로 갖고 있으면서, DB IO를 줄여주는 서버를 따로 만들었어요.리니지 프로젝트에 참여한 것은 1년도 채 되지 않았지만, 이 경험이 이후 제 커리어에 정말 큰 자산이 되었고 게임 업계에서 많은 기회를 잡을 수 있었습니다.Q. 한국 IT산업이 태동하던 시기를 직접 겪으셨네요! 게임 개발자로서 이후 가장 기억

보통 ingress(inbound)만 열심히 방어하지 egress(outbound)까지 막아야되는 경우는 잘 없죠.보안이라는게 참 비용도 많이 들고 요구 사항을 모두 커버하는 네트워크를 구성하기가 참 쉽지가 않습니다.특히 기존에 서비스를 운영하고 있다면 기존 아키텍처를 호환/유지해야되는데SW라면 모를까 하필 최하단의 네트워크를 건들기란 참 쉽지 않은 길입니다.하지만 저는 그 길을 걸어보았고그 여정에 대한 발자취를 공유하고자 합니다.그럼 수요 없는 공급인 centralized egress vpc를 향한 여정 출발합니다.AWS를 사용하면 전공수업 잘 들어둘껄이란 생각을 하게 되는 서비스인 VPC입니다.처음에 아무런 지식 없이 AWS에서 MVP레벨의 서비스를 구축하게 되면 요런 모습을 가집니다.저도 처음 AWS를 사용했을때 이렇게 만들었던거 같네요 ㅎㅎ...그냥 EC2에 Elastic IP(EIP)를 달고 도메인 연결하고spring mvc, tomcat, mysql, redis 다 때려박아서 서비스를 했던 기억이 있습니다.당연히 이렇게 된다면 EC2를 재시작하거나 트래픽이 몰리거나 DB에 부하가 생기면 서비스에 장애가 생기겠죠?그래서 Scaling 가능한 구조로 바꾸기 위해서 AWS에서 제공해주는 Managed Service를 도입하게 됩니다.가장 처음으로 도입하는게 Elastic Load Balancer(ELB)와 Auto Scaling Group, RDS, ElastiCache이죠.Auto Scaling Group을 사용해서 웹서버인 EC2를 Scaling하고ELB 서비스에서 제공하는 ALB(Application Load Balancer)를 사용해서 Scaling되는 EC2를 라우팅해주고RDS, ElastiCache를 사용해서 DB를 Scaling하는 아주 기초적인 구조입니다.보안을 아주 살짝 곁들여봅시다잘동작하고 돈만 많다면(?) 기존 구조로도 안정적으로 서비스할 수 있겠죠?하지만 Auto Scaling Group에 있는 EC2와 RDS, ElastiCache 등이 외부에 노출되기 때문에보안을 위해서 그 다음 스탭으로는 아래와 같이 네트워크를 분리해서 구성합니다.외부에 서버나 DB를 직접 노출하지 않기 위해서죠.위처럼 구성한다면 EC2, ElastiCache, RDS 등에 EIP(=Public IP)를 주지 않아도 되고그러면 외부에서 서버에 접근할 방법이 없기 때문에 안전합니다.다만 이러면 EC2는 Public IP가 없이 때문에 인터넷이 안되는데EC2의 인터넷 통신을 위해서 중간에 NAT Gateway(NAT)를 두고 EIP를 할당해서EC2는 NAT를 통해서 Public IP를 할당 받아서 인터넷 통신을 할 수 있게 됩니다.그래서 보통 Public Subnet에는 NAT와 ELB만 두고Private Subnet에는 웹서버 역할을 하는 EC2만 두고DB Subnet에는 DB만 둬서 외부 공격에 대해 네트워크 레벨로 방어진을 구성합니다.ALB 앞단에 NLB(Network Load Balancer)를 둬서 정적IP를 사용자에게 제공할 수 있습니다.이러면 사용자가 접근해야되는 시스템에서 방화벽에 IP를 등록해야된다고 하면 우린 NLB의 EIP를 알려주면 되죠.대신 기존에 ALB에 연결했던 도메인을 NLB로 옮겨줘야되긴 합니다.이정도면 외부 공격에 대해서 모두 막은걸까?보안이란게 100%는 불가능하지만지금 구조라면 약간 아쉬운점이 있습니다.바로 가장 기본적인 DDoS나 SQL Injection, 악성 봇 등에 대한 방어가 없죠!!ORM만 써도 SQL Injection을 막을 순 있다곤 하지만그건 정말 기본적인 안전장치이고 네트워크 레벨에서 1차적으로 막아주는게 가장 중요합니다.그래서 도입하게 되는게 바로 WAF(Web Application Firewall)라는 서비스죠.서드파티 방화벽을 쓰는 경우도 보긴 했는데 WAF 정도만 달아줘도 대부분의 공격을 잘 막아주긴 합니다.다만 비싼게 흠이긴한데 DDoS 한번 당해보면 싸다고 느껴지실겁니다.요금제는 트래픽당 과금 방식이라 대충 얼마 나온다고 예측하기 힘들기 때문에 직접 보고 판단하시는게 좋습니다.아래 링크에서 요금 예시를 보면 생각보다 얼마 안하네?라고 생각하실텐데실제 워크로드에 적용해보시면 어마어마하게 나올겁니다 ㅎㅎ...제가 예전 언급했던 내용이지만outbound가 열려있다면 해커 입장에서는 1번이라도 뚫어내면 데이터를 다 빼갈 수 있습니다.제목은 "Gradle 프로젝트 빌드하기"이지만Log4j 취약점이나 공급망 공격에 대해서 언급한 내용이 있으니 참고하시면 좋을듯합니다.어쨋든 요점은 해커 입장에서는 악성코드를 1번이라도 심을 기회가 생겨서 심는다면outbound가 다 열려있는 상태라면 해당 프로그램을 통해서 데이터를 빼갈 수 있습니다.대표적인게 최근 유행(?)하고 있는게 eBPF죠.eBPF는 github에 공개된 오픈소스이고 커널 레벨에서 실행되기 때문에어떤 프로세스가 어떤 파일에 접근하고 네트워크 통신을 하는지 감시할 수 있습니다.그렇다면 우리가 구축한 아키텍처에서 EC2의 outbound만 볼까요?예를 들어서 EC2에서 git push/pull하거나 docker push/pull, slack api 호출 등이 outbound에 해당되죠.보통 security group의 outbound는 기본이 any open(=0.0.0.0/0 all port 허용)이기 때문에이제까지 문제 없이 사용하고 계셨을겁니다.만약 사용자가 업로드한 첨부파일이 악성코드였고 그게 EC2에 설치가 됐다면?SQL Injection 공격으로 명령어를 삽입해서 RCE(Remote code execution) 공격을 시도했다면?공격 당한 EC2 디스크에 있는 데이터는 물론이고해당 EC2에서 접근 가능한 DB까지 싹싹 긁어서 해커의 서버로 퍼다 날랐을겁니다.그렇다고 outbound를 무작정 막자니 애매한 부분이 있습니다.security group은 IP기반으로만 허용이 가능해서 특정IP를 차단하기엔 어려움이 있습니다.예를 들어서 IPv4에서 1개의 IP만 차단하려면security group은 차단할 IP 1개를 제외한 약 43억 개 IP를 등록해야되거든요.하지

사내 AI 챗봇 ‘조리’ 개발기 및 멀티에이전트 구조 적용 사례사내 AI 챗봇 ‘조리’👋 들어가며요기요는 빠르게 변화하는 업무 환경에 발맞춰, 반복적인 IT/HR 문의를 자동으로 처리하는 사내 AI 챗봇 ‘조리’를 개발했습니다. 단순한 Q&A 챗봇이 아니라, 실제로 업무를 처리하는 액션까지 포함한 지능형 업무 자동화 시스템입니다.이 글에서는 조리의 전체 아키텍처, 기술적 의사결정, 멀티에이전트 구조 적용 사례, 그리고 내부 자동화 연동 포인트를 상세히 소개합니다.🧠 요기요 AI 챗봇 ‘조리’란?조리는 Slack 기반으로 동작하며, 구성원의 자연어 요청을 분석해 아래 두 가지 방식으로 대응합니다:Knowledge 기반 응답 (RAG)- 사내 위키(Confluence)와 Slack 채널을 기반으로 임베딩 검색 후 응답 생성실제 작업 자동화 (Action Group)- Okta, Google Calendar, Slack 등 외부 시스템과 연동된 Lambda 호출🧱 전체 아키텍처 구성도🎯 추가된 기능: @사내, @사외 태그를 통해 다중 에이전트 라우팅 처리🧩 멀티에이전트 구조: @사내 / @사외조리는 사용자의 입력에 포함된 키워드 또는 태그를 기반으로, 서로 다른 Bedrock Agent를 자동 선택해 답변합니다@사내 → IT/HR 전용 Agent@사외 → 일반 지식 Agent (Claude)💡 라우팅 구조 다이어그램📌 @사내 → internal-agent사내 IT/HR 정책, 시스템 관련 응답 (예: 가이드, 연차, Okta 등)@사내 IT/HR 관련 문의📌 @사외 → external-agent외부 일반 지식 기반 응답 (예: 기술 질문, 상식 등)@사외 일반 문의답변 형태실시간 타이핑 시뮬레이션: 챗봇 답변을 한 번에 던지지 않고, 입력 중인 것처럼 메시지를 동적으로 업데이트체감 대기시간 단축: 사용자가 “멈춘 건가?” 불안해하지 않고, 답변을 기다리는 경험이 훨씬 자연스러움사람 같은 인터랙션: 실제 사람이 채팅하는 듯한 느낌으로 몰입도와 친근감을 강화Slack 친화적 UX: 단순 로딩 스피너 대신, 텍스트와 이모지로 Slack 대화에 자연스럽게 녹아듦👉 “챗봇이 단순히 ‘생각 중’임을 보여주는 게 아니라, 마치 사람이 직접 타이핑하는 듯한 경험을 구현했습니다.”✅ 분기 처리 코드 예시if "@사내" in text: agent_alias = "internal-agent"else: agent_alias = "external-agent"⛔️ 참고: @사외는 따로 분기 처리하지 않아도 기본값인 external-agent로 자동 처리됩니다.📥 RAG 기반 문서 검색사용자가 “연차 가이드 알려줘”라고 입력하면…→ Bedrock Agent가 KB에서 관련 문서를 벡터 검색 → Claude가 핵심 내용을 자연스럽게 요약 → Slack으로 전송 (누구나 이해할 수 있도록 구성)⚙️ 자동화 Action Group 예시🔐 Okta MFA 초기화Slack 메시지 수신: @조리 MFA 초기화 해줘Lambda가 Bedrock Agent 호출 → Rese

2025년 LLM 필드에서 가장 중요한 키워드 하나를 꼽으라면 바로 'Reasoning'일 것입니다.Test-time-computing을 통해서 LLM은 사람처럼 생각하는 과정을 거쳐 답변을 이끌어냈고, 이는 다양한 벤치마크 성능을 극적으로 끌어올렸습니다.하지만 이 Reasoning 모델은 일반 사용자들 (단순한 태스크에 LLM을 적용하려는) 에게는 큰 영향을 주지 못했습니다.금방 대답할 수 있는 질문들에도 쓸데없는 사고과정을 거치면서 답변을 기다리는 사용자들을 지치게 만들곤 했기 때문입니다.그래서 제안된 방식 중 하나가 바로 Think-fusion입니다. 이전 블로그 글에서 Qwen3에 적용된 Hybrid think mode 에 대해서 살펴본 바 있습니다.Think-fusion이 적용된 LLM은 단일 모델 (unified model)이 reasoning과 non-reasoning 방식을 모두 지원합니다.이 글에서는 think-fusion을 구현하는 여러 방식과, 최근 모델들의 think-fusion 방식을 통해 LLM의 방향성을 살펴보려 합니다.Think fusion은 기본적으로 사용자가 'Think 모드'를 활성화했을 때, 모델이 형태의 답변을 생성하도록 학습됩니다.하지만 모델별로, 그리고 'Non-think 모드'일 때의 응답 형태에 따라 세 가지 구현 방식의 차이가 존재합니다.각각의 방식을 조금 더 자세히 살펴보겠습니다.가장 직관적인 방식입니다. 사용자가 Think 모드를 끄면, 모델은 추론 과정을 생략하고 최종 답변([resp])만 내놓습니다.Think 모드를 사용하기 위해서는 토큰 뒤에 를 미리 붙인 뒤 응답을 생성하도록 합니다.사용자가 Think 모드를 끄면, 태그를 출력한 후 답변을 제공합니다. 이는 빈 reasoning을 생성한 것과 동일합니다.이는 모델이 항상 '생각' 단계를 거치도록 구조적으로 템플릿을 유지하되, Non-think 모드에서는 그 내용을 비워두는 방식으로 응답 형태의 일관성을 유지하려는 시도입니다.Think 모드를 사용하기 위해서는 토큰 뒤에 를 미리 붙인 뒤 응답을 생성하도록 하고,Non-think 모드를 사용하기 위해서는 토큰 뒤에 를 미리 붙인 뒤 응답을 생성하도록 합니다.사용자가 Think 모드를 끄면 뒤에 바로 토큰이 나타나고, 그 이후에 답변 생성되는 다소 특이한 형태입니다.Think 모드를 사용하기 위해서는 토큰 뒤에 를 미리 붙인 뒤 응답을 생성하도록 하고,Non-think 모드를 사용하기 위해서는 토큰 뒤에 를 미리 붙인 뒤 응답을 생성하도록 합니다.세 가지 방식이 별로 다를 것 없어 보이지만, 확률적으로 다음 토큰을 생성하는 LLM의 특성을 생각해보면 큰 차이가 있습니다.LLM 은 next token prediction loss에 의해서 학습된 모델입니다.따라서 학습 때 본 적 있는 sequence 라면 해당 token 이 생성될 가능성이 존재합니다.Case 1의 경우, Non-think 모드를 사용하기 위해서 뒤에 아무것도 붙이지 않고 inference 를 수행하는 상황을 가정해보겠습니다.Think 모드를 위해서 뒤에 토큰이 있는 데이터가 학습된 적 있기 때문에 Non-think 모드라고 할지라도 토큰이 생성될 수 있습니다.만약 생성된다면 think 모드로 답변하게 됩니다.반면 Case 2의 경우, Think 모드를 사용하기 위해 만 붙여 inference 를 했는데, 바로 가 나오면서 Non-think 모드가 되어버릴 수 있습니다.Case 3의 경우, 앞의 경우와는 다르게 두 모드가 완전히 분리되어 있습니다. 로 시작한다면 가 나올때까지 reasoning 을 하게 될 것이고,로 시작한다면 바로 응답이 생성될 것입니다.따라서 Case 1과 Case 2의 경우, 각각 Non-think 모드와 Think 모드에서는 사용자가 아닌 모델이 모드를 선택하게 됩니다.학습된 데이터의 비율이나 학습 레시피에 따라서 그 비중이 결정될겁니다.그렇다면 반드시 Case 3가 좋은 것일까요? 장담할 수는 없습니다. Case 1과 Case 2는 Think/Non-think 에서 사용하는 템플릿이 일관성을 유지합니다.반면 Case 3는 특정 토큰이 나오면서 이후에 아예 다른 distribution 을 가지게 됩니다. 이는 모델 학습시에는 sample efficiency 를 떨어뜨릴 가능성이 있습니다.다시 말해, Case 1과 Case 2가 학습이 더 효율적일 수도 있습니다. 반면 Case 1과 Case 2는 모델이 Think/Non-think 를 잘 결정할 수 있도록 하는 데이터 mixture 를 잘 찾아야 하겠습니다.Think-fusion을 사용하지 않고 다시 모델 분리그런데 최근 공개된 GPT-5는 오히려 Reasoning 모델 (gpt-5-thinking) 과 Instruct 모델 (gpt-5-main) 을 아예 분리해 버렸습니다.그리고 모델 앞에 Router를 붙였습니다. 사용자의 질문을 router가 먼저 분석하고 이 질문이 복잡한 추론을 요구하는지, 아니면 간단한 지시 수행이나 정보 검색으로 충분한지를 판단합니다.그리고 판단에 따라 요청을 전문화된 각 모델로 전달합니다.Alibaba의 Qwen3-235BA22B도 2507 버전으로 Instruct-only 모델을 내놓았습니다.기존의 think-fusion 을 업그레이드 하지 않고, instruct-only 모델로 변경하여 내놓은 것입니다.GPT-5와 Qwen3는 Think/Non-think 모델을 분리하여 학습 하고 있고,think-fusion의 case 3방식을 사용하는 DeepSeek-V3.1 또한 Think/Non-think의 distribution 분리하려는 시도를 한 것을 볼 수 있습니다.비교적 최신 모델들이 think-fusion 을 분리하려는 이유는 무엇일까요?몇 가지 추론을 해볼 수 있습니다.• None 성능 저하의 가능성: 하나의 모델에게 복잡한 추론 태스크와 간결한 답변 생성이라는 두 가지 작업을 모두 잘 해내도록 학습시키는 것은 둘 중 하나의 태스크에서 성능 저하를 가져올 수 있습니다. 실제로 Think-fusion을 적용한 모델들은 Non-think모드 성능이