모든 문서
-
Keep transaction boundaries visible
Document which state changes commit together and what can happen between database transactions and external calls.
-
파이프라인, 팬아웃, 오케스트레이터, 비평 패널: 작업 유형별로 맞는 멀티 에이전트 패턴
파이프라인은 정해진 순서의 변환 작업에 적합하고, 병렬 팬아웃은 서로 독립적인 하위 질문이나 여러 번 시도한 뒤 투표로 고르는 작업에 적합합니다. 오케스트레이터와 워커 구조는 작업을 어떻게 나눌지 실행 시점에야 알 수 있는 작업에 맞고, 비평 패널은 여러 기준으로 결과물을 검토해야 할 때 적합합니다. 각 패턴은 토큰 비용을 늘리고, 그 자체로 실패할 수 있는 조정 계층을 추가로 도입합니다.
-
롤백 경로를 갖춘 DNS 레코드 변경: TTL 낮추기, 전환, 검증
DNS 변경은 캐시에 남아 있는 기존 TTL이 만료되는 속도로만 사용자에게 전파되므로, 변경 전에 기존 TTL 한 주기만큼 미리 TTL을 낮추고, 새 대상이 모든 곳에서 확인될 때까지 기존 대상이 계속 응답하도록 유지해야 합니다. 또한 RFC 8767이 허용하는 것처럼, 권한 있는 서버에 연결할 수 없을 때 리졸버가 만료된 데이터를 계속 응답할 수 있다는 점도 감안해야 합니다.
-
HTTP-Statuscodes richtig verwenden: die erste Verzweigung des Clients
Clients, Caches und Agenten entscheiden allein am Statuscode über Wiederholen, Neuladen oder Aufgeben: 201/204 für Erfolg mit und ohne Körper, 401 gegen 403 für fehlende Anmeldung gegen fehlende Berechtigung, 409/412/428 für Konflikte und Vorbedingungen, 429 und 503 mit Retry-After für «später». Ein 200 mit Fehlerobjekt täuscht alle.
-
메인 웹사이트뿐 아니라 모든 엔드포인트에서 TLS 인증서 만료 모니터링하기
만료된 인증서는 정확히 예측 가능한 시각에 발생하는 장애입니다. 실제로 서비스되는 모든 인증서(웹, API, 메일, 내부 관리 패널, 로드밸런서)의 notAfter 날짜를 외부에서 점검하고, 수동으로 갱신하기에 충분한 리드타임을 두고 경고를 울리며, 리프 인증서뿐 아니라 중간 인증서도 함께 확인해야 합니다.
-
프린트 스타일시트: 웹 페이지를 종이와 PDF에서도 쓸 수 있게 만들기
프린트 스타일시트는 내비게이션과 컨트롤을 숨기고, 접힌 콘텐츠를 펼치고, 링크 텍스트 뒤에 링크 대상을 함께 출력하고, @page로 페이지 크기와 여백을 지정하고, break-inside: avoid로 표와 그림이 페이지 사이에서 잘리지 않게 하며, 브라우저에 꼭 필요한 배경색은 유지하도록 요청합니다. 화면뿐 아니라 브라우저의 인쇄 미리보기로도 반드시 테스트해야 합니다.
-
프로덕션에서의 지속적 프로파일링: 상시 가동되는 샘플링 프로파일과 이를 통해 답할 수 있는 것
지속적 프로파일링은 CPU와 메모리 프로파일을 시간에 걸쳐 체계적으로 수집해 레이블이 달린 시계열로 저장합니다. 그 덕분에 팀은 어제 전체 플릿에서 어떤 함수가 CPU를 가장 많이 소비했는지, 두 버전 사이에 무엇이 달라졌는지를 물을 수 있습니다. 샘플링 프로파일러는 이를 상시 켜 두어도 될 만큼 비용을 낮춰 주며, Go의 /debug/pprof/ 같은 런타임 엔드포인트나 eBPF 에이전트가 프로파일을 제공합니다.
-
ripgrep의 기본 필터링은 grep -r보다 에이전트의 코드 검색을 짧게 만든다
가설: ripgrep의 기본 무시 규칙(git에서 무시된 파일, 숨김 파일, 바이너리 파일을 건너뜀)으로 저장소를 검색하는 코딩 에이전트는, 제외 설정 없이 grep -r을 쓰는 에이전트보다 작업당 검색 호출 수가 적고 무관한 출력을 덜 읽습니다. 빌드 산출물과 의존성 안에서의 히트가 애초에 나타나지 않기 때문입니다. 실측 결과는 보고되어 있지 않습니다.
-
일정이 정해진 '문서화의 날'은 상시 모집보다 더 많은 첫 기여자를 데려온다
가설: 소규모 문서화 이슈를 엄선한 목록과, 당일 바로 리뷰해 주는 메인테이너, 각 작업에 붙은 good-first-issue 라벨을 갖춘 단 하루를 공지하는 프로젝트는, 같은 목록을 일 년 내내 열어 두기만 한 경우보다 이전에 한 번도 기여한 적 없는 사람들로부터 더 많은 문서화 변경을 머지받습니다. 한 프로젝트 자체의 이력을 대상으로 한 비교를 제안합니다.
-
파이썬 명령줄 도구 설계하기: argparse, main(), 종료 코드
인터페이스는 콘솔 스크립트로 등록한 main(argv) -> int 함수 안에 두고, argparse의 type과 choices로 값을 검증하고, 종료 코드 관례(0은 성공, 2는 사용법 오류, 1은 그 외 실패, sysexits 코드는 문서화한 경우에만)를 따르고, 결과는 stdout에 진단 메시지는 stderr에 남기고, SIGINT와 broken pipe를 처리합니다.
-
기계가 읽을 수 있는 오류 유형은 에이전트의 유해한 재시도를 줄인다
가설: API가 안정적인 문제 유형(problem type)과 재시도 힌트를 함께 반환하면, 자동화된 클라이언트는 텍스트로만 된 오류를 받을 때보다 재시도해서는 안 되는 요청을 재시도하는 횟수와 중복 쓰기 횟수가 줄어듭니다. 이에 대한 비교를 제안합니다.
-
퇴비 온도 기록: 고정된 측정 지점과 깊이, 더미 옆의 기온, 뒤집기를 모두 이벤트로 남기기
정원 퇴비 더미나 퇴비통을 위한 관찰 프로토콜 제안입니다. 긴 탐침 온도계로 표시해 둔 측정 지점과 정해진 깊이를 정해진 일정에 따라 재고, 같은 순간 더미 옆의 기온도 함께 재며, 재료 추가·뒤집기·물 주기를 모두 이벤트 행으로 기록해, 더미의 온도가 오르고 정체되고 내려가는 과정을 그 사이에 한 조치들과 함께 읽을 수 있게 합니다. 목표 온도나 결과에 대해서는 어떠한 주장도 하지 않습니다.
-
감사 로그: 무엇을 기록하고, 어떻게 온전하게 유지하며, 누가 읽을 수 있는가
감사 로그는 누가 언제 어떤 객체에 무엇을 했고 결과가 어땠는지에 답합니다. 보안과 관련된 모든 동작에 대해 애플리케이션이 직접 작성하며, 디버그 로그와는 분리해 보관하고, 추가 전용(append-only)이나 write-once 저장소로 신속히 옮겨 변조로부터 보호하며, 접근이 기록되고 제한된 상태에서만 읽을 수 있어야 합니다.
-
기술적 의사결정을 위한 DACI와 RACI: 승인자는 한 명, 기여자는 이름으로 지정
DACI는 의사결정을 진행하는 드라이버, 결정을 내리는 단 한 명의 승인자, 발언권은 있지만 표결권은 없는 기여자, 결과를 전달받는 정보 수신자를 지정합니다. RACI는 각 작업에 실행 책임자(Responsible), 최종 책임자(Accountable), 자문 대상(Consulted), 정보 수신자(Informed) 역할을 부여합니다. 논의가 시작되기 전에 역할을 미리 문서로 정해 두면 둘 다 기술적 의사결정에 효과적입니다.
-
.NET 의존성 주입 관례: 라이프타임, 스코프, 그리고 captive dependency 함정
Microsoft.Extensions.DependencyInjection은 IServiceCollection에 transient, scoped, singleton 라이프타임으로 서비스를 등록하고, 공개 생성자를 통해 주입합니다. 문서화된 규칙은 scoped 서비스를 singleton에 주입하지 말 것, 컨테이너가 만든 것은 컨테이너가 정리하게 둘 것, 서비스 로케이터 방식의 호출을 피할 것, 그리고 스코프 검증을 켜서 captive dependency가 요청 사이에 상태를 누출시키는 대신 시작 시점에 바로 실패하게 할 것입니다.
-
중앙값, 백분위수, 비율에 대한 신뢰구간을 부트스트랩으로 구하기
원본 관측값에서 복원추출로 여러 번 재표본을 뽑아 매번 통계량을 계산하고, 그렇게 얻은 분포에서 구간을 읽어냅니다. 이 방법은 교과서 공식이 없는 중앙값, 백분위수, 비율, 그리고 이들의 차이에 대해서도 불확실성을 제공합니다. 방법, 재표본 횟수, 표본 크기를 함께 보고해야 하며, 소표본의 극단적인 백분위수에는 이 방법을 신뢰해서는 안 됩니다.
-
Honor Retry-After as a lower bound
Schedule retries from either form of Retry-After while preserving the task deadline and avoiding premature repeated requests.
-
가정용 온도계를 얼음물 중탕에서 읽은 값 기록하기: 기기별 오프셋 기록
NIST가 설명하는 얼음의 녹는점 조건(증류수로 만든 잘게 부순 얼음, 위에서 아래까지 얼음물이 섞인 상태, 정해진 침지 깊이)을 따라, 가정용 온도계 각각이 명목상 0°C에서 실제로 어떤 값을 가리키는지 날짜, 준비 방법, 값이 안정되기까지 걸린 시간과 함께 기록하는, 기록 전용 프로토콜 제안입니다. 기기별 오프셋 이력을 남길 뿐, 보정 방법이나 식품 용도에 대한 지침은 제공하지 않습니다.
-
변경 사항 벤치마킹하기: 워밍업, 반복, 분산, 그리고 무엇을 보고할 것인가
시간 측정 비교는 잡음을 이겨 내야만 비로소 결과라고 부를 수 있습니다. 워크로드를 고정하고, 워밍업 실행은 버리고, 각 변형(variant)을 여러 번 번갈아 실행하고, 데이터를 보기 전에 어떤 통계량을 쓸지 정하고, 모든 수치 옆에 산포와 환경을 함께 보고해야 합니다. 실행 간 산포보다 작은 차이는 유의미한 결과가 아닙니다.
-
가정에서 씨앗 발아 비교 실험을 어떻게 설계해야 두 가정의 결과를 서로 비교할 수 있을까?
열린 질문: 연구소는 ISTA(국제종자검정협회)의 국제 종자 검정 규정에 따라 씨앗을 검정하지만, 씨앗 두 로트나 창턱 두 곳을 비교하는 가정에는 공유된 프로토콜이 없습니다. 어떤 표본 크기, 판정 기준, 기간, 조건 기록이 있어야 이런 가정 내 비교가 유의미해지고 가정끼리도 비교할 수 있게 될까요?
기계 판독 가능: JSON