이번 포스팅에서 도메인 일부 영역을 Amazon Route 53에서 관리하는 방법에 대해서 알아보려고 합니다.나만의 도메인 혹은 회사의 주 도메인을 모두 Amazon Route 53에 등록해서 관리 할 수도 있겠지만,이미 많은 서비스에 대한 레코드들이 주 도메인에 포함되어서 운용 중인 경우에는도메인의 네임서버를 전체 이관하는 것이 쉬운 일은 아닐 것입니다.이 경우에 특정 영역에 대해서만 Amazon Route 53으로 위임하여 레코드를 관리 할 수 있습니다.예를 들어서, On-Premises의 DNS에서 회사의 주 도메인을 운용 중인 경우에새로운 Chatbot서비스를 개발했을 때주 도메인은 다른 레코드는 기존의 네임서버에서 관리를 하고Chatbot 서비스에 대한 레코드만 Amazon Route 53에서 관리를 하는 것입니다.이러한 관리 방식을 도메인 위임이라고 하는 데,이제부터 도메인 위임을 하는 방법에 대해서 자세히 알아보겠습니다.먼저, 위임할 도메인 영역을 생성하기 위해서 Amazon Route 53 에서 'hosted zones' 메뉴로 가서,Create hosted zone 메뉴를 선택하여, 신규 hosted zone을 생성합니다.주 도메인인 zigispace.store의 서브 영역으로 'chatbot.zigispace.store'를 Domain name으로 입력합니다.Type은 Public hosted zone으로 선택합니다.하단의 Create hosted zone 버튼을 클릭해서 생성을 완료합니다.다음과 같이 chatbot.zigispace.store 에 대한 Hosted zone이 생성된 것을 확인 할 수 있습니다.이제 Zone이 생성되었으니, 레코드를 생성해 보겠습니다.Create Record 버튼을 클릭해서 신규 레코드를 생성합니다.chatbot.zigispace.store 에 대한 레코드를 생성할 것이기 때문에 Record name은 비워둡니다.Record type은 원하시는 type을 선택하면 되며, 여기에서는 A 레코드로 선택한 후, 10.1.1.1로 등록하겠습니다.다음과 같이 레코드가 생성된 것을 볼 수 있습니다.chatbot.zigispace.store에 대한 레코드를 등록하였지만,nslookup으로 chatbot.zigispace.store에 대한 레코드에 값을 조회해 보면,다음과 같이 조회가 되지 않는 것을 볼 수 있습니다.왜나면, zigispace.store라는 도메인의 네임서버거 Amazon Route 53이 아니기 때문입니다.chatboat.zigispace.store 영역을 Amazon Route 53에서 관리하기 위해서는zigispace.store 도메인의 네임서버에서 위임(Delegation)을 설정을 해야합니다.zigispace.store 도메인의 네임서버에서 위임 설정을 진행 해보겠습니다.현재 zigispace.store 도메인의 네임서버는 Windows 서버에서 DNS 기능을 활성화해서 운용 중이라고 가정합니다.Windows DNS에 등록된 zigispace.store 영역을 선택한 이후에Ne

1부에서는 Position Embedding에 대한 전반적인 내용에 대해서 한번 훑어보았습니다.1부 마지막 쯔음에 요즘 open source LLM들은 대부분 Rotary Position Embedding(RoPE)을 사용하고 있다고 말씀드렸습니다.이번 포스트에서는 RoPE layer쪽을 살짝 바꿔줌으로써 원래 수용가능한 context size보다 훨씬 더 많은 양이 수용가능한 방식에 대해 말씀드리도록 하겠습니다.Position Interpolation에 대해 말씀드리기 전에 일단 2d case에서의 RoPE를 recall해보도록 하겠습니다.RoPE를 적용할 때 query function과 key function은 다음과 같이 정의할 수 있습니다.위의 식을 잘 보면 사실 position에 대한 정보(m)는 rotary matrix(cosine, sine부분의 matrix)부분에만 영향을 미칩니다.그래서 제한된 context length가 존재하는 pretrained LLM의 경우 rotary matrix의 값들은 position에 따라서 아래 그림처럼 미리 학습된 영역의 점의 y값을 가지게 됩니다.만약 제한된 context length가 2048일 때 그 이상의 token이 나올 경우에는 rotary matrix의 값은 아래 그림처럼 unseen Range의 y값을 가지게 됩니다.사실 제한된 context length가 아닌 그 이상이더라도 어차피 rotary matrix이기 때문에 -1~1사이의 값을 가지고 이 값 자체는 이미 관측된 값이기 때문에 전혀 문제가 안되는 것처럼 보입니다.그러나 attention score를 찍어보면 아래 그림과 같이 제한된 context length내에서는 -3~3사이에서 값을 형성하는 반면 그 이상 넘어가면 attension score가 폭발하는 경우가 발생을 하게 됩니다.이러한 이유때문에 제한된 context length이상 generate를 하면 이상한 token들이 generate되게 됩니다.그래서 attention score가 폭발이 안되도록 하기위해 아래그림처럼 늘리고자 하는 context length까지 이미 알고있는 영역으로 땡겨주면 별 문제가 없을까요?즉 interpolation을 하게되면 문제가 없을까요?Position Interpolation의 저자는 늘리고자 하는 context length까지 linear scale로 interpolation이 되도록 하면 attention score도 bound됨을 보였고실험에서는 늘리고자 하는 context length에 대해서 fully finetunning을 하는 것보다 Position Interpolation을 하고 1/10수준만 finetunning하더라도 perplexity관점에서는 오히려 성능이 좋음을 보였습니다.원래는 NTK interpolation관련 3개의 interpolation에 대해서도 추가로 작성하려고 했습니다만,다음 blog에서 NTK aware interpolation, NTK by part interpolation, Y

굳이 Svelte 를 선택한 이유왜 하필 Svelte 인가요? 아직 시기상조 아닐까요?Javascript 가 Web 표준 개발 언어기 때문에, 자연스럽게 해당 언어에 기반한 Web Framework (혹은 Library) 는 짧은 시간 내 굉장히 많이 생기고, 동시에 많이 사라지고 있는 것 같습니다.Web Framework 를 선택하는 것이 더욱 어려운 이유는, Frontend 분야의 트렌드가 다른 개발 분야에 비해 비교적 빠르게 변화하고 있기 때문입니다.실제로, 지난 10년 사이에 크고 작은 지각 변동이 수차례 있었던 것 같습니다.2010년대 초반에는 jQuery, 2010년대 중반에는 Angular, 2010년대 후반 이후에는 React 와 Vue 가 Web Framework 핵심 트렌드였던 것 같습니다.개인적으로는 대부분의 기간을 Frontend 분야와 친숙하게 지내지 않았기 때문에, 위와 같이 빠르게 변하는 Frontend 업계 트렌드를 그저 '옆동네 불구경' 정도로 생각했던 것 같습니다.막상 Web 개발 공부를 시작하려다 보니 꽤나 많은 선택지 앞에서 당황했고, 실제로 공부하고자 하는 Web Framework 를 선택하는 과정에서 많은 고민을 하게 되었습니다.현재 시점에서 Javascript 기반의 Web Framework 를 선택할 때, 가장 안정적인 옵션은 의심의 여지없이 React 혹은 Vue 입니다.Frontend 분야에서 이미 전세계에서 큰 비중으로 활용되고 있기에, 개발 안정성이나 확장 가능성은 보장되었다고 해도 무방합니다.실제로, Frontend 분야의 채용 시장도 모두 React, Vue 중심으로 열려 있고, 온라인과 오프라인 구분할 것 없이 대부분의 학습 자료는 해당 Web Framework 위주로 구성되어 있습니다.또한, 현실적으로 개발자들에게 굉장히 중요한 요소로 작용하는 커뮤니티 성숙도 측면에서 압도적인 모습을 보이고 있습니다.직면한 문제가 무엇이든, 대부분 Google 혹은 Youtube 에 이미 해당 문제를 경험하고 해결한 사례가 존재하기 때문에React, Vue 에 익숙하지 않은 개발자더라도 풍부한 Reference 를 통해 어렵지 않게 궁금증을 해결할 수 있습니다.심지어, ChatGPT 도 다른 Web Framework 와 관련된 질문보다는 React, Vue 와 관련된 질문에 보다 명쾌한 해결책을 제시하는 경우가 많습니다.처음 Svelte 를 접하게 된 계기는 '노마드 코더' 라는 유튜버의 Svelte 소개 영상이었습니다.Frontend 분야에 대한 기본 지식이 부족했기에, Svelte 를 추천하는 다양한 이론적인 (Virtual DOM 을 사용하지 않는다든가, 경량화 되었다든가, 실질적인 의미의 Reactive 특성이 구현된 형태다든가 하는) 강점보다는,초심자 입장에서 가시적으로 느낄 수 있을 정도의 간결한 Code 형태가 굉장히 매력적으로 다가왔습니다.이를 계기로, Svelte 라는 Web Framework 에 관심을 가지고 다양한 자료를 찾아보기 시작했습니다.하단에 첨부된 이미지와 같이, 20

바야흐로 대 LLM의 시대입니다. ‘혁명’에 비견될 정도로 지금 LLM의 성능은 매우 우수하고, 그 영향력이 거의 모든 산업과 분야에 걸쳐 광범위하게 나타나고 있습니다.2025년까지 LLM 기술이 적용된 어플리케이션이 약 7억 5천만개로 예상된다고 할정도로 LLM을 서비스에 적용하는 것은 어떻게 되면 피할수 없는 미래가 된 느낌입니다.마침, 저희 팀도 고객의 편의성 향상을 위한 LLM Backend Task Assistant Agent를 만들게 되었습니다.LLM 기반으로 어플리케이션을 제작하는 것은 매우 쉬워보입니다.많은 오픈소스와 솔루션들이 있고 이를 이용하여 단 몇 줄의 코드, 심지어 코드 없이 UI 콘솔로도 만들 수 있습니다. 하지만 대고객 Production 향 LLM Application 은 안타깝게도 그렇게 쉽게 만들 수는 없었습니다.다른 여타 서비스와 마찬가지로 고가용성(high-availablity)과 확장성(scalable)이 보장되어야하기 때문에LLM 을 통해서 모든 문제가 해결되기 보다는 Application 설계 시 해야하는 Engineering 고민들에 LLM Application 이 가질 수 있는 문제들이 오히려 더해져서 더 어려운 과제였습니다.게다가 기존 솔루션들을 사용하다보면 적은 코드로 빠르게 구현하는 것을 목적으로 하다보니 코드 자체가 LLM과 Application 코드가 뒤섞여 굉장히 복잡해지는 문제가 있었습니다.LLM 기반의 Application 에서 고민해야할 것이 많은데 이것들이 뒤섞여서 안그래도 복잡한데 더 복잡해지는 문제였죠.그래서 저희는 기타 오픈소스를 사용하지 않고 LLM OpenAI API 만을 가지고 자체 Framework 'Aide'를 만들어서 위 과제를 진행하고자 했습니다.저희가 만든 Framework의 요건은 두가지였습니다.• None LLM 기반의 Multi-turn 대화를 지원하는 Agent 를 쉽게 개발할 수있는 Framework• None Agent 개발에 필요한 다양한 기능들을 고도의 추상화를 통해 단순화하여, 쉽고 빠르게 LLM 기반의 대화형 Agent를 만들고 다른 고민 없이 LLM 을 이용해 풀어야하는 ‘문제’(Task)에 집중할 수 도와주는 Framework모두가 함께 참여 하되, 2번을 통해 Application Engineer는 Application Layer 의 문제에 좀 더 집중하고,LLM Engineer들은 LLM Customization(Prompt engineering, Task-focused fine-tuning)에 좀 더 집중할 수 있도록 하였습니다.Aide 의 특징을 간략히 요약하자면 아래와 같습니다.• None 쉽게 개발하고 트래픽 요구사항에 맞춰 Scalable 한 Production 레벨 LLM Agent Application Framework(w/fastapi)• None Agent 동작에 필요한 각 기능들을 추상화하고 Layer 로 만들어 각 Layer 에 계층적 구조를 적용, 하위 레이어는 상위 레이어에 의존하지 않도록 설계. LLM Ag

많은 분들이 기다리셨던 토스 개발자 컨퍼런스 SLASH24가 지난 9월 12일 코엑스 그랜드볼룸에서 진행되었습니다. 올해로 벌써 4회째를 맞은 이번 컨퍼런스는 더욱 특별했는데요, 그동안 온라인으로만 진행되었던 SLASH가 처음으로 오프라인으로 진행되었기 때문이에요.SLASH24 당일, 여름 더위를 식히는 가을비가 내렸지만, 개발자들의 열정은 식힐 수 없었어요. 무려 1,500여 명의 개발자분들이 참석해 자리를 빛내주셨습니다. 그 뜨거웠던 현장, 함께 살펴볼까요?올해 SLASH24에서 전하고자 했던 메세지는 “No Limit: 풀지 못할 문제는 없다”였어요. 컨퍼런스의 컨셉 역시 한계를 규정하지 않고 늘 다음 문제를 찾아다니는 ‘클라이밍’으로, 홈페이지를 비롯해, 오프닝 영상과 굿즈, 행사장 곳곳에서 만나볼 수 있었죠.더 나은 서비스를 위한 토스팀의 끝없는 도전기토스 CTO 형석님의 오프닝 세션을 시작으로 본격적인 메인 세션이 시작되었습니다.SLASH24의 메인 세션은 직군별로 3개의 트랙으로 나누어 진행되었어요. Track T에는 Data, Python, Infra 세션, Track O에는 Server, Node.js 세션, Track S에는 Frontend, DevOps, Android, QA 세션이 진행되었습니다.트랙별 세션에 참여했던 참가자분들과 연사분들의 이야기를 들어볼까요?Server <보상 트랜잭션으로 분산 환경에서도 안전하게 환전하기>거대한 은행 계정계 시스템과 새로운 MSA 서비스는 어떻게 협력할 수 있을까요? 계정계 시스템의 원화 계좌와 분리된 외화 계좌를 오가는 환전 트랜잭션 구현법을 다뤘어요.Frontend 토스증권 PC를 개발하는 데 어떤 새로운 도전이 있었을까요? 모바일과 다르게 여러 탭을 열어놓고 사용하는 PC에서 WebSocket의 연결 개수를 관리하고 최적화할 수 있는 방법을 공유했어요.Server 평생 무료 환전을 제공하는 토스뱅크 ‘외화통장’ 서비스는 어떻게 만들어졌을까요? 토스뱅크의 Oracle 기반 모놀리식 아키텍처를 MSA, MySQL로 전환해서 국내 송금보다 빠른 24시간 무중단 환전을 제공한 경험을 나눴습니다.최소한의 context switching만으로 어떻게 다양한 도메인 영역을 분석할 수 있을까요? 토스의 데이터웨어하우스 테이블 구축 및 운영기를 다뤘어요.이론으로, 감으로 예상만 하던 Kernel 영역까지 명확하게 확인할 수 없을까요? eBPF를 활용해 Observability를 대폭 향상시킨 경험을 나누었어요.오프라인이기에 가능했던 특별한 시간오프라인 컨퍼런스의 묘미는 더 깊고 풍부한 경험을 만들어주는 ‘인터랙션’이 아닐까 싶은데요, 그렇기에 SLASH24에서도 참가자분들이 다양한 인터랙션을 경험할 수 있는 여러 프로그램을 준비했습니다.더 깊은 기술적 고민을 나누는 데브챗세션 관련 질의나 기술적 고민을 더 깊고 넓게 나눌 수 있었던 네트워킹 프로그램, DevChat. 연사자뿐만 아니라, 토스 커뮤니티 CTO분들과 시니어 개발자, 파트너사(AWS, Notion, 세일즈포스)의 개발자에게 직접

1. 들어가며가상화 기술의 발전으로, PM(Physical Machine, 물리 서버) 한 대에 여러 대의 VM(Virtual Machine, 가상 서버)을 운영하는 것은 이제 흔히 찾아볼 수 있는 일이 되었습니다. VMWare는 이러한 가상화 기술을 제공하는 대표적인 솔루션으로, 카카오에서도 상당한 규모의 VMWare 인프라를 운영하고 있습니다.이러한 VM 인프라를 운영하다 보면 ‘PM 한 대에서 VM을 몇 대 실행시킬지’, 즉 VM 집적도에 대한...