블로그

한국어English日本語中文

#2026-03 762#culture 283#deep-dive 275#kubernetes 260#career 233#ai 220#llm 216#devops 195#2026-04 158#security 147#observability 118#database 113#communication 108#history 107#architecture 101#productivity 98#performance 93#linux 90#networking 89#finance 87#economy 84#mindset 80#psychology 79#ai-papers 78#food 78#it 78#travel 78#japanese 76#deep-learning 75#english 74#gpu 74#ai-agent 69#business-travel 69#postgresql 66#cs-fundamentals 63#rag 63#systems 63#python 55#learning 54#self-improvement 53

• PoC는 왜 프로덕션에 못 가는가 — 성공 기준, 보안 검토, 인수인계

  데모에서 박수를 받은 PoC의 상당수는 그대로 죽습니다. 기술이 부족해서가 아니라 성공 기준이 없어서, 보안 검토를 마지막에 시작해서, 챔피언이 없어서, PoC 환경과 프로덕션 환경의 격차를 늦게 발견해서입니다. Forward Deployed Engineer(FDE)의 일에서 PoC를 프로덕션으로 옮기는 구간은 기술보다 운영 설계가 승부처입니다. 시작 전에 합의하는 성공 기준 문서, 첫 주에

  2026-08-12 · 11 분 읽기 #career#fde#forward-deployed-engineer#poc#production

• FDE 인터뷰 준비 — 진단 시나리오, 고객 시뮬레이션, 케이스 스터디

  Forward Deployed Engineer(FDE) 인터뷰는 알고리즘 문제 대신 낯선 시스템의 장애 진단 시나리오를, 컬처핏 질문 대신 화난 고객 역할극을 내놓는 경우가 많습니다. 측정하려는 것이 코드가 아니라 현장에서의 판단이기 때문입니다. 회사마다 형식은 다르다는 전제 위에서, 공개 채용 공고들이 공통으로 요구하는 능력을 기술 진단 라운드, 고객 시뮬레이션 라운드, 케이스 스터디의 세

  2026-08-12 · 11 분 읽기 #career#fde#forward-deployed-engineer#interview#job-search

• FDE 온보딩 90일 — 파악, 단독 티켓, 주도 미션의 세 달

  Forward Deployed Engineer(FDE)의 온보딩은 회사와 고객사, 두 겹의 낯선 환경에 동시에 적응하는 일이라서 일반 엔지니어의 온보딩보다 설계가 더 필요합니다. 1개월 차에는 환경·제품·사람의 지도를 그리고, 2개월 차에는 단독 티켓으로 신뢰 계좌를 만들고, 3개월 차에는 작은 미션 하나를 주도합니다. 주차별 체크리스트와 각 달의 함정, 그리고 90일이 끝났을 때 스스로를

  2026-08-12 · 9 분 읽기 #career#fde#forward-deployed-engineer#onboarding#checklist

• 백엔드·데브옵스·데이터 엔지니어에서 FDE로 — 6개월 전환 로드맵

  Forward Deployed Engineer(FDE)로의 전환을 고민하는 사람의 대부분은 백엔드, 데브옵스·SRE, 데이터 엔지니어 중 하나에서 출발합니다. 좋은 소식은 어느 배경이든 FDE 기술 지도의 절반은 이미 갖고 있다는 것이고, 나쁜 소식은 나머지 절반이 배경마다 다르다는 것입니다. 세 배경 각각에 대해 이미 가진 것과 채워야 할 것을 가르고, 공통으로 필요한 고객 대면 기술을 짚

  2026-08-12 · 10 분 읽기 #career#fde#forward-deployed-engineer#career-transition#roadmap

• FDE(Forward Deployed Engineer)란 무엇인가 — 고객사 현장에 배치되는 엔지니어

  팔란티어가 만들었고 OpenAI와 앤트로픽이 앞다투어 뽑는 직함, 포워드 디플로이드 엔지니어(FDE)를 한국어로 제대로 정리합니다. 본사가 아니라 고객사 현장에 배치되어 제품과 고객 시스템 사이의 마지막 구간을 코드로 잇는 직무가 무엇인지, 솔루션스 아키텍트·세일즈 엔지니어·컨설턴트·서포트 엔지니어와 어떻게 다른지 표로 가르고, 미완성 플랫폼일수록 현장 엔지니어링이 제품의 일부가 된다는 구조

  2026-08-12 · 12 분 읽기 #career#fde#forward-deployed-engineer#ai#job-search

• FDE 장애 진단 플레이북 — 접속 권한부터 보고서까지 6단계

  자기 서비스의 장애와 고객사 장애의 결정적 차이는 아는 것이 없는 상태에서 시작한다는 점입니다. 그래서 Forward Deployed Engineer(FDE)에게는 실력보다 순서가 먼저 필요합니다. 접속과 권한 확인, 증상 재현, 계층 분리, 원인 가설, 검증, 보고서의 6단계를 결제 API 간헐 504라는 구성한 예시 하나로 관통하며, 각 단계에서 실제로 치는 kubectl, curl, g

  2026-08-12 · 11 분 읽기 #career#fde#forward-deployed-engineer#incident-response#debugging

• "느려요"를 엔지니어링 문제로 옮기는 법 — FDE 고객 커뮤니케이션

  고객은 버그 리포트를 주지 않습니다. "느려요", "안 돼요", "가끔 이상해요" 같은 고통 리포트를 줍니다. Forward Deployed Engineer(FDE)의 핵심 기술 하나는 이 말을 측정 가능한 엔지니어링 문제로 번역하는 질문법입니다. 언제부터, 누가, 무엇을 할 때, 얼마나, 무엇과 비교해서의 다섯 축으로 증상을 좁히는 법, 같은 상황에서 신뢰를 깎는 답변과 쌓는 답변의 대비,

  2026-08-12 · 10 분 읽기 #career#fde#forward-deployed-engineer#communication#customer-success

• FDE 기술 지도 — 8개 도메인의 최소선, 실무선, 확인 질문

  Forward Deployed Engineer(FDE)에게 필요한 기술을 리눅스, 네트워크, 쿠버네티스, 데이터베이스, 인증·보안, 관측성, 클라우드·인프라, 고객 커뮤니케이션의 8개 도메인으로 지도화합니다. 도메인마다 왜 필요한지, 이력서가 아니라 현장에서 통하는 최소선은 어디인지, 실무선은 어디인지, 그리고 자기 위치를 재는 확인 질문 세 개를 붙였습니다. 전부를 다 갖춘 사람은 없으니

  2026-08-12 · 12 분 읽기 #career#fde#forward-deployed-engineer#skills#roadmap

• 텍스트 생성 오픈 모델, 크기대별로 고르는 법

  오픈 텍스트 생성 모델을 고를 때 크기는 성능 등급이 아니라 배치 제약입니다. 이 글은 온디바이스용 소형, 단일 GPU에 올리는 중형, 서버가 필요한 대형으로 나눠 각 구간에서 실제로 확인한 모델들의 파라미터, 컨텍스트, 라이선스를 정리하고, MoE 모델의 메모리 계산이 왜 다른지, 컨텍스트 확장이 왜 공짜가 아닌지, 카드가 요구하는 실행 조건을 무시하면 무엇이 깨지는지를 설명합니다. 오픈

  2026-08-12 · 12 분 읽기 #ai#llm#huggingface#open-source-llm#text-generation

• 음성 모델 고르기: STT와 TTS의 실전 기준

  음성 모델은 텍스트 모델과 달리 언어 지원, 오디오 길이 제약, 실시간성, 화자 분리 여부가 먼저 정해지고 그다음에 모델이 결정됩니다. 이 글은 2026-08-12에 확인한 STT와 TTS 오픈 모델의 파라미터, 라이선스, 지원 언어, 오디오 제약을 정리하고, 실시간이라는 말을 어떻게 쪼개야 하는지, 카드에 적힌 환각과 동의 관련 경고가 왜 설계 제약인지를 설명합니다. 오픈 모델 가이드 시리

  2026-08-12 · 13 분 읽기 #ai#huggingface#open-source-llm#speech-to-text#text-to-speech

• 한국어를 지원하는 오픈 모델과 토크나이저 비용

  한국어 지원이라는 표기는 그 언어를 처리한다는 뜻이지 잘한다는 보장이 아닙니다. 이 글은 2026-08-12에 확인한 한국어 전용·이중언어 오픈 모델과 다국어 모델의 카드 값을 정리하고, 토크나이저가 한국어를 어떻게 쪼개는지가 왜 그대로 비용과 컨텍스트 소모로 이어지는지, 그리고 그것을 직접 재는 방법을 설명합니다. 한국어 모델에서 특히 갈리는 라이선스 유형도 함께 다룹니다. 오픈 모델 가이

  2026-08-12 · 12 분 읽기 #ai#llm#huggingface#open-source-llm#korean-nlp

• 라이선스와 배포: 유형 읽는 법과 양자화 배포판 출처 확인

  오픈 모델의 license 필드에 적힌 짧은 식별자는 목차일 뿐이고 실제 조건은 전문에 있습니다. 이 글은 2026-08-12에 실제로 마주친 라이선스 유형들을 정리하고, 커뮤니티 라이선스와 비상업 조건이 무엇을 요구하는지, 게이트 저장소가 배포 파이프라인에서 왜 문제가 되는지, 그리고 GGUF 같은 양자화 배포판의 출처를 어떻게 확인해야 하는지를 설명합니다. 오픈 모델 가이드 시리즈 마지막

  2026-08-12 · 13 분 읽기 #ai#llm#huggingface#open-source-llm#license

• 코드 모델 고르기: 자동완성과 대화형, FIM, 라이선스

  코드 모델은 편집기 안에서 커서 위치를 채우는 자동완성용과 질문에 답하는 대화형이 서로 다른 제품입니다. 이 글은 2026-08-12에 확인한 오픈 코드 모델들의 파라미터, 컨텍스트, FIM 지원 표기, 라이선스를 정리하고, 기본 모델에 채팅을 시키면 왜 실패하는지, 코드 모델에서 라이선스가 왜 특히 조심스러운지를 설명합니다. 오픈 모델 가이드 시리즈 7편입니다.

  2026-08-12 · 13 분 읽기 #ai#llm#huggingface#open-source-llm#code-llm

• 비전과 멀티모달: 이미지 이해, OCR, VLM 고르기

  비전 모델은 하나의 범주가 아닙니다. 대화형 VLM, OCR 전용, 문서 구조화, 이미지 검색용 임베딩은 서로 다른 물건이고 대체되지 않습니다. 이 글은 2026-08-12에 확인한 각 범주의 오픈 모델 카드 값을 정리하고, 해상도와 다중 이미지 처리 같은 실제 제약, 그리고 카드가 명시한 금지 용도를 함께 다룹니다. 오픈 모델 가이드 시리즈 6편입니다.

  2026-08-12 · 13 분 읽기 #ai#huggingface#open-source-llm#vision-language-model#ocr

• 허깅페이스 모델 카드 읽는 법: 무엇을 믿고 무엇을 의심할까

  허깅페이스 모델 카드에서 실제로 판단 근거가 되는 항목은 라이선스, 파라미터 수, 컨텍스트 길이, intended use, limitations, 학습 데이터 여섯 가지입니다. 이 글은 각 항목이 무엇을 뜻하고 무엇을 숨기는지, 다운로드 수와 좋아요 수가 왜 품질 지표가 아닌지, 그리고 카드에 적혀 있지 않은 항목을 어떻게 다뤄야 하는지를 2026-08-12에 실제로 확인한 모델 페이지 사례

  2026-08-12 · 12 분 읽기 #ai#llm#huggingface#open-source-llm#model-card

• 임베딩과 리랭커, RAG에서 실제로 중요한 것

  RAG를 만들 때 임베딩 모델 선택을 좌우하는 것은 리더보드 순위가 아니라 차원, 최대 입력 길이, 접두어 규약, 다국어 표기, 그리고 리랭커와의 역할 분담입니다. 이 글은 2026-08-12에 확인한 임베딩·리랭커 모델들의 실제 카드 값을 정리하고, MTEB 점수가 무엇을 말해 주지 않는지, 한국어 문서를 다룰 때 무엇을 직접 재야 하는지를 설명합니다. 오픈 모델 가이드 시리즈 3편입니다.

  2026-08-12 · 12 분 읽기 #ai#llm#huggingface#open-source-llm#embedding

• vLLM 내부 구조 (5) — 접두사 캐싱, 시스템 프롬프트 설계가 곧 성능이 되는 이유

  vLLM의 접두사 캐싱이 언제 적중하고 언제 못 하는지를 공식 설계 문서 기준으로 정리했습니다. 블록 해시가 앞 블록에 사슬처럼 묶이는 구조, 꽉 찬 블록만 캐시되는 이유, 프롬프트 맨 앞에 넣은 타임스탬프 하나가 캐시 전체를 날리는 과정, 그리고 cachesalt까지 다룹니다. vLLM 내부 구조 시리즈 5편.

  2026-08-12 · 13 분 읽기 #vllm#prefix-caching#kv-cache#prompt-engineering#llm

• vLLM 내부 구조 (3) — 연속 배칭이 GPU를 놀게 두지 않는 방법

  정적 배칭이 왜 GPU를 놀리는지, vLLM의 이터레이션 단위 스케줄링이 그것을 어떻게 없애는지 정리했습니다. prefill과 decode의 성격 차이, V1의 통합 스케줄러와 토큰 예산, chunked prefill이 지연과 처리량에 미치는 영향을 공식 문서 기준으로 확인했습니다. vLLM 내부 구조 시리즈 3편.

  2026-08-12 · 12 분 읽기 #vllm#continuous-batching#chunked-prefill#llm#inference

• vLLM 내부 구조 (4) — 스케줄러와 선점, 처리량이 갑자기 무너지는 지점

  vLLM 스케줄러가 매 스텝 무엇을 결정하는지, 대기 큐와 실행 큐가 어떻게 움직이는지, KV 캐시가 모자랄 때 일어나는 선점(preemption)이 지연과 처리량을 어떻게 무너뜨리는지 공식 문서와 V1 스케줄러 소스로 확인해 정리했습니다. recompute와 swap의 차이, fcfs와 priority 정책도 함께 다룹니다. vLLM 내부 구조 시리즈 4편.

  2026-08-12 · 12 분 읽기 #vllm#scheduler#preemption#kv-cache#llm

• vLLM 내부 구조 (1) — 요청 하나가 토큰이 되어 나오기까지

  vLLM에 요청 하나가 들어와 토큰이 나오기까지의 전체 경로를 따라갑니다. API 서버, 스케줄러, KV 캐시 매니저, 워커, 샘플러가 각각 무슨 일을 하는지, V1 재작성 이후 프로세스가 어떻게 나뉘는지를 공식 문서와 소스로 확인해 정리했습니다. vLLM 내부 구조 시리즈 1편.

  2026-08-12 · 10 분 읽기 #vllm#llm#inference#gpu#ai-platform