AI 서비스를 직접 만들고 운영하는 세 명의 실무자가 나눈 대화를 들었다. 이론서에 없는 현장 이야기가 많아서 메모하면서 계속 끄덕였다. 인상 깊었던 것들을 적어본다.틀린 이유를 쪼개야 고칠 수 있다AI 응답이 틀렸을 때 그냥 "틀렸다"고 넘기면 막막하다. 패널들이 오류를 네 가지로 쪼개서 분석한다는 이야기를 듣고, 이건 실무적으로 당장 써먹겠다 싶었다.문맥 파악 실패면 프롬프트를 고치고, 데이터 검색 실패면 RAG 파이프라인을 고치고, 데이터 조합 실패면 청킹이나 검색 로직을 점검하고, 최종 생성 실패면 모델이나 파인튜닝을 의심한다. 각각 해결책이 다르니까 원인을 먼저 분리하는 게 시작이라는 생각이 들었다.재현성 이야기도 나왔다. 100번 같은 질문했는데 99번은 같고 1번 다르게 나온다면, 이게 AI..

그림으로 이해하는 AWS 구조와 기술 서평1. 서론프론트엔드 개발자로 실무를 경험하면서 가장 크게 느낀 점 중 하나는,“나는 화면을 만들고 있지만, 서비스 전체 구조는 잘 모른다”는 한계였다. React 기반으로 UI를 구현하고 API를 호출하는 작업에는 익숙해졌지만,그 API가 어디에서 실행되고, 정적 파일이 어떻게 사용자에게 전달되는지에 대해서는명확하게 설명하기 어려웠다. 이러한 상황에서 AWS 전반 을 다루는 이 책은단순한 인프라 학습을 넘어,프론트엔드 개발자가 서비스의 전체 흐름을 이해하기 위한 입문서로 읽게 되었다.2. 책의 구성과 특징이 책은 AWS의 개념부터 시작해 컴퓨팅, 스토리지, 네트워크, 서버리스까지전체 서비스를 폭넓게 설명하는 구조로 이루어져 있다. 특히 인상적이었던 점은 AWS를 ..

1. 인트로며칠 전 aaru라는 해외 스타트업에 대한 글을 봤다. 이 회사는 가상의 페르소나 수천 명을 만들어서 실제 세계의 현상을 예측한다. 선거 결과, 제품 반응, 여론 동향까지. 실제 사람을 인터뷰하지 않고도 꽤 높은 정확도로 맞춘다는 얘기였다. "가상의 사람한테 물어보면 진짜랑 비슷하게 나온다고?"반신반의하면서도 흥미로웠다. 그러던 중 허깅페이스에서 엔비디아가 만든 한국인 페르소나 데이터셋을 발견했다. 이름은 Nemotron-Personas-Korea. 한국인 100만 명 분량의 가상 프로필인데, 연령, 성별, 직업, 거주지, 자기소개까지 딸려 있었다. 이걸로 내가 만드는 서비스에 대한 가상 사용자 인터뷰를 해볼 수 있지 않을까?그래서 해봤다. 1만 명한테 물어봤다. 내 컴퓨터 안에서.2. "그래..

현재 다니는 회사에서는 프론트엔드를 담당하고 있다.회식 자리에서 AI에 관심 있다고 말했다가,사내 AI 에이전트 개발을 맡게 됐다.하려는 것은 다음과 같다.맥을 병렬로 연결한다.(한 컴퓨터에서 도커를 여러개 띄우는 것처럼)이 맥들을 LiteLLM을 통해 라우팅 하며 관리한다.근데 사실 나는 ai 에이전트, 하네스와 같은 것에 관심이 있던거지 인프라에는 관심이 그렇게 많지 않았어서 당혹스러웠다.맥 스튜디오 128GB 짜리를 지급 받고 개발을 시작하려던 도중에 MLX와 GGUF라는 것에 대해서 알게 되었고, 이 차이를 명확하게 이해해보기 위해 글을 써보려고 한다.1. 들어가며휴대폰에서 돌릴 수 있는 Gemma4, 양자화등 로컬 환경에서 LLM을 돌리기 위한 노력들은 국내외를 가리지 않고 점점 늘어나고 있다...

들어가며거부기린은 개인적으로 애정이 가는 프로젝트다. 그래서 더 대충 넘기고 싶지 않았다."지금도 돌아가니까 유지하자"는 식으로 남겨두기보다, 실제로 쓰는 사람이 덜 답답하고 앞으로 유지보수하는 사람도 덜 고생하는 구조로 바꾸고 싶었다. 소프트웨어를 오래 운영하다 보면 초기에 가볍게 선택한 구조가 나중에는 로딩 속도, 화면 전환, 오류 대응, 테스트 난이도, 배포 리스크로 이어진다. 거부기린도 그런 시점에 와 있다고 느꼈다. 특히 이 앱은 장난감 프로젝트가 아니라 실제 업무에 쓰이는 도구라는 점이 컸다. 개발자 입장에서는 "조금 느리지만 참을 수 있는 정도"라고 넘길 수 있어도, 사용자는 매일 반복되는 작은 지연과 어색한 동작을 더 예민하게 느낀다.클릭했을 때 바로 반응하지 않거나, 화면이 잠깐 멈춘 것..

0. Intro인턴 시절 SaaS 어드민에 새로운 기능을 추가해야 했는데, 필요한 라이브러리를 설치하는 과정에서 문제가 생겼다. 당시 프로젝트에서 사용하던 TypeScript 버전이 오래되어, 최신 라이브러리와의 호환성이 좋지 않았기 때문이다. 결국 TypeScript를 3.x에서 5.x대로 마이그레이션하게 되었다.마이그레이션 이후 master 브랜치에 머지하고 CodePipeline에서 빌드를 확인했을 때, 속도가 눈에 띄게 빨라진 것을 체감했다. 그런데 실제로 코드에서 크게 바꾼 부분은 많지 않았다. any 타입을 좀 더 구체적인 타입으로 바꾼 정도였다.그래서 궁금해졌다. 빌드가 빨라진 이유가 any 타입을 줄였기 때문인지, 아니면 TypeScript 컴파일러 자체의 성능이 개선된 결과인지 확인해보고..