Engineering Culture
Sphinx의 푸시 전 퀴즈, 통과 기록을 어디까지 믿을까
Sphinx는 AI가 만든 변경의 동작을 푸시 전에 묻는다. 공개 평가의 오답 처리 사례와 Git 훅의 적용 범위, 코드 전달·모델 호출 비용을 살펴 이해를 돕는 도구로 쓸 조건을 정리한다.
THE BUILDER’S NOTE
Engineering.
01 / INSIDE THE BUILD만들며 배우고, 배운 것을 나눕니다.
더 나은 제품을 향한 개발의 기록.
찾고 있던 이야기
작은 발견부터 깊이 있는 고민까지.
카테고리Engineering Culture
필터 초기화Engineering Culture
오픈소스 기여자가 적다는 소식, 의존성을 바꿀 근거가 될까
기여자 수와 특정 후원 목록만으로 오픈소스의 안전성과 지속성을 판단하기 어렵다. SQLite와 XZ의 공식 자료를 대조하고, 릴리스·지원·인계 경로에서 의존성의 유지 비용을 확인한다.
Engineering Culture
AI 코드 리뷰, 결함 탐지와 변경 승인을 나눠야 하는 이유
AI 리뷰의 탐지 능력과 팀에 남는 이해는 별도로 평가해야 한다. 코드 리뷰 대체 논문과 반론을 비교하고, 자동화할 검사·사람이 결정할 경계·도입 효과를 확인할 기준을 정리한다.
Engineering Culture
Rune의 오픈소스 공개에서 본 IDE 성능과 확장성의 조건
Go로 만든 Rune의 오픈소스 공개를 계기로 터미널 성능 측정의 범위와 확장 API의 경계를 살펴본다. 언어 지원, 빌드 전제, 원격 연결 비용을 바탕으로 일상적인 개발 도구로 전환할 조건을 정리한다.
Engineering Culture
긴 설명보다 실행 가능한 운영 절차, 다음 실험으로 이어지는 회고
장애 상황에서는 시스템의 모든 배경을 처음부터 읽기 어렵다. 현재 증상에 맞는 확인과 다음 행동을 빠르게 찾을 수 있어야 한다. 결론보다 남은 질문를 중심으로 작은 예제와 확인 기준을 정리합니다.
Engineering Culture
장애 회고에서 판단 당시의 정보 복원하기, 다음 실험으로 이어지는 회고
결과를 알고 나면 당시의 선택이 쉽게 잘못으로 보인다. 개인을 탓하는 설명은 비슷한 조건에서 같은 문제가 반복되는 이유를 찾기 어렵게 한다. 결론보다 남은 질문를 중심으로 작은 예제와 확인 기준을 정리합니다.