블로그
GPU·LLM·MLOps·쿠버네티스, 그리고 마음가짐에 관한 글 · 3704 편
#2026-03 762#culture 283#deep-dive 275#kubernetes 262#career 233#ai 223#llm 217#devops 198#2026-04 158#security 149#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 67#cs-fundamentals 63#rag 63#systems 63#python 56#learning 54#self-improvement 53
API 설계 완전 가이드: 되돌릴 수 없는 결정부터 정하기 ♪ 들을 수 있어요
API 설계를 하나의 축으로 다시 배열합니다. 공개하는 순간 되돌릴 수 없게 되는 결정과 나중에 바꿀 수 있는 결정을 구분하고, 리소스 경계·식별자·메서드 의미론·상태 코드·오류 형식·페이지네이션·시간과 돈의 표현·버저닝을 되돌림 비용 순서로 정리합니다. RFC 9110, RFC 6585, RFC 9457 원문을 근거로 씁니다.
2026-08-15 · 44 분 읽기 #api설계#rest#http#rfc9110#rfc9457리팩터링 완전 가이드: 동작을 지키면서 구조를 바꾸는 절차 ♪ 들을 수 있어요
리팩터링을 언제 하느냐가 아니라 어떻게 안전하게 하느냐를 다룹니다. 리팩터링의 정의에서 출발해 특성화 테스트로 안전망을 만들고, 손댈 수 없는 코드에 접합부를 내고, 병렬 변경으로 인터페이스를 바꾸고, 큰 변경을 되돌릴 수 있는 조각으로 자르는 절차를 순서대로 정리합니다. 자동 리팩터링과 코드모드의 검증 방법, 그리고 멈출 때를 정하는 기준까지 포함합니다.
2026-08-15 · 47 분 읽기 #리팩터링#레거시코드#테스트#refactoring#characterization-test배포 전략 완전 가이드: 되돌릴 수 있는 것과 없는 것 ♪ 들을 수 있어요
배포 전략을 도구 목록이 아니라 가역성이라는 하나의 축으로 다시 정렬합니다. 아직 되돌릴 수 있는 변경과 이미 되돌릴 수 없는 지점을 지난 변경을 구분하는 체크리스트, 카나리가 통계적으로 의미를 갖기 위한 조건, 그리고 배포 전략을 가장 자주 무너뜨리는 스키마 변경과 데이터 마이그레이션을 중심에 놓고 설명합니다.
2026-08-15 · 46 분 읽기 #배포#릴리스#카나리#deployment#canary인증과 인가 완전 가이드: 스펙 원문으로 짚는 열 가지 오해 ♪ 들을 수 있어요
OAuth 2.0은 인가 프레임워크이고 OIDC가 그 위에 인증을 얹습니다. 권장에서 빠진 플로우, JWT 검증에 대한 착각, 토큰 저장 위치의 교환 조건을 RFC 6749·9700·7636·7519·8725와 OIDC Core, OWASP 치트시트 원문으로 정리합니다. 기존 OAuth 심화 글이 "어떻게 동작하는가"였다면 이 글은 "어디서 틀리는가"입니다.
2026-08-15 · 48 분 읽기 #인증#인가#oauth#oidc#jwt무엇이 비싸게 남는가 — 생성이 싸질 때 값이 오르는 네 가지
IT 엔지니어가 앞으로 무엇을 준비해야 하는지 묻는 질문에 도구 목록으로 답하면 그 답은 2년이면 낡습니다. 이 글은 다른 축을 제안합니다. 값이 남는 기술은 검증 비용이 비싼 기술이라는 것입니다. 생성 비용과 검증 비용을 두 축으로 놓고 네 칸을 그리면, 자동화가 어디를 먼저 먹었고 어디에 사람이 남는지가 한 장에 정리됩니다. 그리고 이 틀에는 반전이 하나 있습니다. 엔지니어의 일은 검증을
2026-08-15 · 13 분 읽기 #career#skills#ai#craft#engineering-culture남이 쓴 것을 읽는 능력 — 코드베이스 진입과 문서 없는 시스템 역설계
쓰기는 연습이 강제되지만 읽기는 그렇지 않습니다. 그래서 읽기는 모두가 매일 하면서도 아무도 훈련하지 않는 기술이 됐고, 생성이 싸진 지금 가장 빠르게 값이 오른 능력이 됐습니다. 이 글은 낯선 대규모 코드베이스에 진입하는 일곱 단계 절차, 문서가 없는 시스템을 실행 중인 상태에서 역설계하는 방법, 그리고 코드에 절대 남지 않는 정보가 무엇인지를 다룹니다. 읽기가 왜 검증 비용이 비싼 쪽에
2026-08-15 · 12 분 읽기 #career#skills#code-reading#craft#legacy-code도메인 지식이 왜 방어선인가 — 업을 아는 엔지니어와 기술만 아는 엔지니어
도메인 지식은 코드에도 문서에도 없고 사람과 관행에만 있습니다. 그래서 이 시리즈가 말해 온 검증 비용을 가장 비싸게 만드는 요인이자, 그 비용을 감당할 수 있는 사람이 남는 이유입니다. 이 글은 업을 아는 엔지니어가 질문과 예외와 요구 해석에서 무엇을 다르게 하는지, 회의에서 쓰는 말과 코드에 있는 이름이 어긋날 때 무엇이 깨지는지, 도메인을 익히는 여섯 단계 절차, 그리고 도메인 지식이
2026-08-15 · 14 분 읽기 #career#skills#domain-knowledge#ddd#ontology조직 안에서 보이기 — 성과는 저절로 알려지지 않는다
한 일과 알려진 일 사이에는 거의 언제나 거리가 있습니다. 이 거리는 겸손의 문제가 아니라 정보가 조직 안에서 전달되는 방식의 문제입니다. 성과가 왜 저절로 알려지지 않는지, 성공하면 아무 일도 일어나지 않는 종류의 일이 왜 기록에서 가장 먼저 사라지는지, 자랑처럼 들리지 않으면서 기록을 남기는 형태는 무엇인지 정리했습니다. 1:1을 상태 보고가 아니라 다른 세 가지 용도로 쓰는 방법, 보이
2026-08-15 · 11 분 읽기 #career#visibility#communication#one-on-one#growth레버리지가 없다고 느낄 때의 협상 — 무엇이 테이블 위에 있는가
협상을 시작하지 못하는 이유는 대개 정보 부족이 아니라 나에게는 레버리지가 없다는 자체 판정입니다. 그런데 그 판정은 레버리지를 다른 회사의 오퍼 하나로 좁게 정의한 결과입니다. 레버리지가 실제로 나오는 네 곳을 대체 비용, 정보, 시간, 대안으로 나누어 보고, 금액 말고 테이블 위에 올라와 있는 항목들을 정리했습니다. 요구를 순차적으로 던지면 왜 신뢰가 깎이는지, 조건부 수락이 왜 상대에게
2026-08-15 · 11 분 읽기 #career#negotiation#offer#communication#decision-making틀릴 것을 전제한 계획 — 목표 대신 방향, 분기마다 묻는 질문
5년 계획이 틀리는 것은 계획을 대충 세워서가 아닙니다. 예측 대상이 둘인데 시장도 나도 함께 움직이기 때문입니다. 정확도를 높이려는 시도가 왜 헛도는지, 계획의 값어치가 예측이 아니라 선택의 속도에 있는 이유를 정리했습니다. 도달점을 지정하는 목표 대신 방향으로 적는 방법, 되돌릴 수 있는 선택과 되돌리기 어려운 선택을 나누어 다르게 다루는 방법, 분기마다 던질 질문 여섯 개를 담았습니다.
2026-08-15 · 10 분 읽기 #career#planning#decision-making#career-strategy#reflection새벽 세 시에 커리어 걱정으로 깼다면
커리어 걱정은 유독 밤에 크게 자랍니다. 그것은 의지가 약해서가 아니라, 불안이라는 위협 탐지 시스템이 계획으로 오인되기 쉬운 구조로 만들어져 있기 때문입니다. 이 글은 불안이 실제로 하는 일과 하지 못하는 일을 구분하고, 반추와 계획을 가르는 세 개의 질문을 제시한 뒤, 새벽 세 시에 실제로 취할 수 있는 몇 가지 조치와 최악의 시나리오를 끝까지 적어 보는 방법을 다룹니다. 확신을 주는 글
2026-08-15 · 11 분 읽기 #career#anxiety#sleep#rumination#mental-health오래된 기술과 함께 나이 드는 것에 대한 두려움
연차가 쌓이면 불안의 모양이 바뀝니다. 시작할 자리가 있을까에서, 내가 서 있는 자리가 언제 없어질까로. 이 글은 그 두려움을 두 개로 나눕니다. 쌓은 것의 감가와 다시 배울 능력의 감소. 그다음 지식을 유통기한이 다른 세 개의 층으로 갈라 무엇이 실제로 낡고 무엇이 남는지 보고, 같은 십 년이 어떤 조건에서 자산이 되고 어떤 조건에서 부채가 되는지를 각각 세 가지와 네 가지로 정리합니다.
2026-08-15 · 12 분 읽기 #career#senior-engineer#obsolescence#skills#aging주니어가 특히 불안한 이유 — 진입 계단이 달라졌다는 것
주니어의 불안은 성격이 아니라 위치에서 나옵니다. 대체 가능성이 가장 크다고 지목되는 층이면서, 증거는 가장 적고, 비교 대상은 가장 많은 자리이기 때문입니다. 이 글은 AI가 주니어 일을 한다는 말의 어디까지가 관측이고 어디부터가 예측인지 가른 뒤, 진짜 문제는 일이 사라지는 것이 아니라 시니어로 가는 계단이 아직 다시 설계되지 않았다는 점임을 짚습니다. 그리고 그 상황에서 사람이 배워야
2026-08-15 · 12 분 읽기 #career#junior-developer#ai#learning#entry-level남들은 다 앞서 가는 것 같을 때 — 표본과 시간표에 대하여
피드를 열면 모두가 앞서 가고 있는 것처럼 보입니다. 이 글은 그 감각을 위로로 덮지 않고 구조로 설명합니다. 우리가 보는 것이 왜 표본이 아니라 자기 선택된 광고인지, 잘 안 된 사람은 왜 그 선택에 대해 글을 쓰지 않는지, 커리어에 정해진 시간표가 있다는 감각이 어디서 왔는지, 그리고 상상한 마감과 진짜 마감을 어떻게 구분하는지를 다룹니다. 마지막으로 비교를 끄는 대신 정보로 바꾸는 방법
2026-08-15 · 11 분 읽기 #career#comparison#social-media#career-timeline#anxietyLangfuse SDK 계측 — 무엇이 자동으로 잡히고 무엇을 손으로 넣나
트레이스를 만드는 일은 SDK를 설치하는 일이 아니라 경계를 긋는 일입니다. 이 글은 Langfuse 파이썬 SDK v4를 기준으로 데코레이터, 컨텍스트 매니저, 수동 생성 세 가지 계측 방식이 각각 무엇을 다르게 하는지 정리하고, 속성을 하위로 흘려보내는 propagateattributes가 왜 필요한지, OpenAI와 LangChain 같은 프레임워크 통합이 자동으로 잡아 주는 범위가 어
2026-08-14 · 15 분 읽기 #observability#langfuse#llm-tracing#instrumentation#opentelemetryLangfuse가 트레이스를 ClickHouse에 두는 이유 — 저장 계층의 역할 분담
Langfuse를 직접 띄워 보면 저장소가 하나가 아니라는 사실에 먼저 놀랍니다. ClickHouse, Postgres, Redis, 오브젝트 스토리지 네 가지가 각각 다른 몫을 맡습니다. 이 글은 공식 문서를 기준으로 각 저장소가 무엇을 담는지, 수집된 이벤트가 어떤 순서로 이 구성 요소들을 지나가는지, 큰 payload가 어디로 빠지는지를 정리합니다. 컬럼 지향 저장이 트레이스 분석 질의
2026-08-14 · 20 분 읽기 #observability#langfuse#clickhouse#architecture#postgresLangfuse 자체 호스팅 — 배포 경로, 시크릿, 그리고 첫 기동에서 걸리는 것들
Langfuse를 직접 운영하려면 컨테이너 두 개와 저장소 네 개를 동시에 세워야 합니다. 이 글은 공식 문서를 기준으로 docker compose 경로와 헬름 차트 경로를 각각 정리하고, 반드시 직접 만들어 넣어야 하는 시크릿이 무엇인지, Postgres와 ClickHouse의 연결 문자열이 왜 두 개씩 필요한지, 오브젝트 스토리지 설정에서 MinIO가 요구하는 옵션이 무엇인지를 짚습니다.
2026-08-14 · 17 분 읽기 #observability#langfuse#self-hosting#docker-compose#kubernetes트레이스가 비용이 될 때 — Langfuse의 보존, 샘플링, 마스킹
트레이싱은 트래픽이 적을 때는 공짜처럼 보이다가 어느 순간 저장 비용과 개인정보 문제로 되돌아옵니다. 이 글은 Langfuse에서 양이 비용으로 바뀌는 지점을 네 곳으로 나눠 정리하고, 공식 문서 기준으로 샘플링이 trace 단위로 결정된다는 사실과 그것이 실무에서 무엇을 뜻하는지, 파이썬과 JS 각각의 마스킹 방식이 데이터를 어느 시점에 가리는지를 확인합니다. 보존 정책의 기본값이 삭제하지
2026-08-14 · 17 분 읽기 #observability#langfuse#cost#sampling#data-retentionLangfuse 트레이싱 데이터 모델 — trace, observation, score가 한 번의 실행을 담는 방식
Langfuse 화면을 먼저 보면 무엇을 보고 있는지 알 수 없습니다. 이 글은 Langfuse가 수집하는 데이터의 형태부터 정리합니다. trace가 무엇을 묶고 observation이 span·generation·event로 갈리는 기준은 무엇인지, session과 user가 trace 위에 어떤 층으로 얹히는지, score가 어디에 붙는지를 공식 문서 기준으로 확인합니다. RAG 한 번의
2026-08-14 · 15 분 읽기 #observability#langfuse#llm-tracing#data-modeling#opentelemetry수집한 다음 — Langfuse 대시보드, 메트릭 API, 그리고 트레이스에 붙는 평가
트레이스를 모으는 것과 그 트레이스로 답을 얻는 것은 다른 일입니다. 이 글은 Langfuse가 제공하는 지표 축이 무엇이고 그것을 어떤 차원으로 쪼개 봐야 하는지 정리한 뒤, 메트릭 API v2의 질의 구조를 실제 요청 형태로 확인합니다. v4에서 traces 뷰가 사라지고 observations 중심으로 재편된 변화, score가 trace·observation·session·데이터셋 실
2026-08-14 · 17 분 읽기 #observability#langfuse#llm-evaluation#metrics-api#dashboard