포스트

2026-TIL

2026-10-02-TIL: 블로그 인용 카드와 결정 모델

오늘도 여러 저장소에서 세션을 나눠 돌렸다. 커밋이 가장 많이 쌓인 곳은 블로그였고, sys-drill과 neon-diary가 뒤를 이었다. 어제 TIL에 적은 대로 요청에 완료 기준을 넣어 보려고 했는데, 아직은 “다음 단계 진행해줘”가 더 많았다.

오늘 한 작업

블로그: 글 하단 정리와 인용 카드

글 하단 배치를 여러 번 바꿨다. 시리즈 패널, 수정 이력, 관련 글, 이전·다음 글 상자의 위치를 옮겨 보다가 몇 개는 되돌렸다. 화면 배치는 직접 보기 전에는 정하기 어려워서, 결국 여러 번 바꿔 보고 하나씩 고르는 식이 됐다. 지금은 시리즈 패널이 본문 위에 접힌 채로 있고, 이전·다음 글 상자는 라이선스 줄 아래에 있다.

새로 붙인 기능은 두 가지다.

  • 인용 카드: 글에서 인용한 원문을 출처 목록 하나에 등록해 두고, 본문에서는 카드로 보여 준다. 출처마다 페이지가 생겨서 어떤 글이 그 출처를 인용했는지 거꾸로 따라갈 수 있다. 등록되지 않은 출처를 쓰면 일관성 검사가 실패한다.
  • 웹 편집기: 브라우저에서 글을 쓰고 이미지를 올리면 PR 브랜치로 커밋하는 작은 CMS다. 미리보기는 렌더링한 HTML의 스크립트를 실행하지 않게 막았고, 마크다운과 이미지는 한 커밋에 같이 들어가게 했다.

sys-drill: 워게임과 학습 기능 확장

시스템 설계 훈련 플랫폼 sys-drill에서는 장애 대응 워게임 화면을 넓혔다.

  • 인시던트 시간축과 서비스 맵을 만들었다.
  • 지표 차트에서 구간을 드래그하면 그 시간대 로그를 볼 수 있게 했다.
  • 트레이스 스팬을 누르면 서비스 맵의 해당 노드로 이동한다.
  • 완화와 복구를 따로 선언하게 나눴다. 트래픽을 돌려 증상을 멈춘 것과 원인을 고친 것은 다른 단계이기 때문이다.

학습 쪽에는 장애 패턴 사전, 진단 퍼즐, 대응 기록에서 오개념을 찾아 주는 카드를 넣었다. 공식 시나리오에는 카나리 배포 도메인을 하나 더 추가했다. Dependabot이 올린 GitHub Actions 버전 업데이트도 정리했다.

그 밖의 저장소

  • neon-diary: Unity로 옛 게임을 다시 만드는 프로젝트다. 원본의 대사, 음악, 효과음을 장면에 연결했다. 복원한 한글 글리프도 추가했다. 장면 이미지를 필요할 때만 불러오도록 바꾸고 메모리를 다시 측정해 사용량이 줄어든 것을 확인했다.
  • engineering-lab: 백엔드 실험을 재현 가능한 기록으로 남기는 플랫폼으로 바꾸기 시작했다. 실험을 실행할 때마다 파라미터, 실행 환경, git 정보, 입력 파일 지문을 저장한다. 시나리오 정의로 실험을 띄우고, 실행 결과끼리 비교해서 근거 자료로 내보내는 데까지 갔다.
  • monticker: 쌓여 있던 Dependabot PR을 한 번에 머지했다.
  • iterview: 면접 질문을 이력서 주장 하나에 맞춰 좁혔다. 일일 카드가 UTC 기준으로 날짜를 잡던 버그도 서비스 시간대 기준으로 고쳤다.

느낀 점

블로그 화면을 여러 번 고쳐 보면서, 레이아웃은 에이전트에게 맡겨도 판단은 결국 내가 화면을 보고 내려야 한다는 걸 느꼈다. 수정 이력 위치를 몇 번이나 옮겼다. 처음부터 “이 정보는 독자가 언제 필요로 하는가”를 먼저 정했다면 덜 오갔을 것 같다.

기술 뉴스: Atlassian의 OpenTelemetry 이전

CNCF 블로그에 Atlassian이 메트릭 플랫폼을 OpenTelemetry로 옮긴 사례가 올라왔다. 14개 리전, 약 10만 대 호스트에서 분당 약 48억 개의 데이터 포인트를 받는다. 집계를 거치면 분당 약 2억 2천만 개로 줄어드는 규모다.

기존에는 gostatsd라는 StatsD 수집기를 썼다. 오래 잘 돌았지만 메트릭만 다룰 수 있었고, 트레이스와 로그를 받을 방법이 없었다. 그렇다고 이것만 자체적으로 키워서는 OpenTelemetry로 모이는 커뮤니티를 따라잡을 수 없다고 판단했다.

흥미로운 건 이전 방식이다. 서비스 쪽 계약은 그대로 뒀다. “이 주소로 StatsD를 UDP로 보내면 메트릭이 백엔드에 나타난다”는 약속이다. 그 뒤의 수집, 라우팅, 집계, 전달 단계만 OpenTelemetry Collector로 하나씩 바꿨다. 그래서 각 팀은 계측 코드를 고치지 않고도 플랫폼 교체를 받아들일 수 있었다. 인터페이스를 고정해 두고 구현을 단계별로 바꾸는 방식이다.

참고:

AI 키워드: 결정 모델이 늘어나고 있다

어제 TIL에서 Jev를 “LLM 앞단에 붙는 타입 지정 결정 레이어”로 정리했다. 그런데 하루 이틀 사이에 비슷한 것이 두 개 더 나왔다.

  • Cloudflare Clef: 10월 1일 Workers AI에 공개한 결정 모델이다. 27B 모델인 Clef와 9B 모델인 Clef-flash 두 가지가 있다. 정해진 타입의 질문을 받아 확률이 붙은 답을 돌려준다. Apache 2.0으로 가중치도 공개했고, Jev API와 호환된다고 한다. Cloudflare가 잰 중앙값 지연은 Clef-flash가 38.8ms, Clef가 209.3ms였다. 같은 글에서 Jev는 524.1ms였다.
  • OpenAI Decisions API: 9월 29일 DevDay에서 발표했다. 질문과 허용할 답 목록, 판단 근거가 될 텍스트나 이미지를 보내면 그중 하나를 고른다. GPT-6 Luna의 한 버전을 쓴다. 일반 API로 부를 때보다 약 10배 빠르다고 하며, 아직은 제한된 프리뷰다.

세 곳이 거의 같은 시기에 같은 방향을 내놓은 셈이다. 분류, 라우팅, 다음 행동 고르기처럼 답의 형태가 정해진 판단은 문장을 생성하는 큰 모델에 맡기지 않고 따로 떼어 낸다. 에이전트를 만들 때 “어디까지를 결정 모델에 넘길 것인가”가 설계 질문 하나로 자리 잡는 것 같다. 다만 위 지연 수치는 모두 각 회사가 직접 잰 값이다.

참고:

다음에 확인할 것

  • 글 하단 배치를 독자가 정보를 찾는 순서에 맞춰 다시 정하기
  • engineering-lab의 실행 기록에 JVM 관측값을 붙였을 때 실험 간 비교가 실제로 쉬워지는지
  • 블로그 일관성 검사를 커밋 전에서 파일 수정 시점으로 앞당길 수 있는지
  • Clef-flash를 sys-drill의 대응 기록 분류에 붙여 보면 기존 LLM 호출 대비 비용과 지연이 얼마나 다른지
이 글은 저작권자의 CC BY 4.0 라이선스를 따릅니다.

변경이력

1번 수정

  1. docs(til): drop the course review section from 2026-10-02 til

댓글

아직 댓글이 없습니다