아이디어와 인사이트

AI 퍼스트 개발, 코딩 가드레일, 그리고 폐기 가능한 아키텍처를 탐구합니다.

main 브랜치가 깨졌습니다. 200개의 커밋을 뒤져야 합니다.

git bisect은 수동 커밋 탐색을 자동화된 이진 검색으로 바꿉니다. 모든 커밋을 하나씩 checkout하지 않고 버그를 도입한 정확한 커밋을 찾는 방법을 알아보세요.

main에서 CI가 빨간불이지만 어제는 초록불이었습니다. 그사이 어딘가에 버그가 기어들어왔습니다. 200개의 커밋을 스크롤하며 디프를 읽고 추측할 수 있습니다. Slack에 물어보고 누군가 관련 코드를 건드렸던 것을 기억하길 바랄 수 있습니다. 아니면 Git에게 일을 맡길 수도…

에러 추적기는 어디서 죽었는지 압니다. 하지만 재현은 도와주지 않습니다

stack trace는 크래시가 어디서 발생했는지 알려주지만, 원인은 알려주지 않습니다. 프로덕션 크래시를 실제로 디버깅할 수 있는 로컬 테스트 케이스로 바꾸는 capture-and-replay 패턴을 소개합니다.

프로덕션에서 정확히 어디서 크래시가 났는지 압니다. stack trace가 의 147행을 가리킵니다. 예외는 에 대한 입니다. 코드를 pull하고 테스트를 실행하면 모두 통과합니다. 샘플 페이로드로 endpoint를 수동으로 호출해도 잘 작동합니다. 버그는 실재합니다. 고객들이 이를…

94% 테스트 커버리지도 놓친 정수 오버플로우를 symbolic execution이 찾아냈습니다

unit tests는 특정 입력을 검증합니다. symbolic execution은 모든 가능한 입력을 검증합니다. 작동 방식, 비용, 시작 방법을 알아보세요.

테스트 스위트는 94% 커버리지와 0개의 실패를 기록했습니다. symbolic execution 엔진은 3초 만에 코드의 크래시를 찾아냅니다. 테스트가 고장 난 것이 아닙니다. 커버리지 지표가 거짓말을 하는 것도 아닙니다. 문제는 테스트가 특정 지점에서의 동작을 검증한다는 것입니다.…

로그에서 PII가 새고 있는데, grep으로는 해결되지 않습니다

대부분의 팀은 고객 민원 이후에야 PII 유출을 발견합니다. 민감한 데이터를 수집부터 출력까지 추적하는 방법과 오늘 바로 사용할 수 있는 코드 예제를 소개합니다.

대부분의 팀은 고객 민원이나 규정 준수 감사 이후에야 PII 유출을 발견합니다. 그때가 되면 데이터는 이미 ETL 파이프라인을 통과해 애플리케이션 로그에 남고, 세 가지 다른 observability 도구에 인덱싱되어 있습니다. 사후에 찾는 것은 고고학과 같습니다. 실제로 필요한 것은…

CI는 코드는 테스트했지만 contract는 아니었기 때문입니다

대부분의 CI 파이프라인은 문법 오류와 논리 버그를 잡아냅니다. 하지만 실제로 프로덕션을 중단시키는 API contract 파괴는 놓칩니다. 이 문제를 해결하는 방법을 알아보세요.

제 팀에서 프로덕션까지 간 모든 API 파괴는 CI를 통과했습니다. 전부요. unit tests는 초록불이었고, integration suite도 통과했습니다. 배포가 나갔고, 그다음 Slack 메시지가 쏟아지기 시작했습니다. 문제는 테스트를 하지 않았던 것이 아닙니다. 잘못된 것을…

크래시 상관관계는 거짓말한다. 진짜 버그를 가리키게 만드는 방법

Statistical debugging은 크래시와 연관된 predicate를 찾지만, 상관관계는 파일과 줄 번호가 아니다. 상관관계 점수에서 실제 버그 위치까지 순위 매기기, 필터링, 삼각 측량하는 방법이다.

Statistical debugging은 근본 원인이 아닌 predicate의 정렬된 목록을 준다. 모든 분기와 null check를 계측하고, 십만 번의 실행을 돌리면, 알고리즘이 점수판을 건네준다. 의 의 중요도는 0.94다. 의 도 마찬가지다. 하나는 버그고, 다른 하나는…

Sentry의 Seer는 트레이스를 읽을 수 있다. 그렇다고 항상 근본 원인을 찾는 건 아니다

Seer는 트레이스 트리, 연결된 오류, 프로파일링 데이터를 수집해 분산 문제를 진단한다. 실제로 어떻게 작동하는지, 어디서 빛나는지, 여전히 인간의 도움이 필요한 곳은 어디인지 설명한다.

프론트엔드에서 500 오류가 발생했다. 스택 트레이스는 React 컴포넌트를 가리킨다. 실제 문제는 세 개의 서비스 뒤에 있고, 누수하는 백그라운드 작업에 의해 고갈된 데이터베이스 커넥션 풀에 있다. 트레이스 폭포를 클릭해가며 타임스탬프를 연관 짓고 커밋 기록을 읽을 수도 있다.…

Statistical debugging은 printf 디버깅을 끝낼 거라 했다. 대부분의 팀은 결국 작동시키지 못했다

Statistical debugging은 프로그램 동작과 실패를 연관 지어 버그를 정확히 찍어주겠다고 약속했다. 이 아이디어가 연구 논문에서 운영 환경 시스템으로 건너오지 못한 이유를 설명한다.

Statistical debugging은 시대를 끝낼 예정이었다. 코드를 계측하고, 수천 번의 실행에서 트레이스를 수집하고, 상관관계 분석을 실행하면, 도구가 크래시를 유발할 가능성 순으로 모든 분기와 null check를 순위 매기는 것을 지켜볼 수 있을 것이다. 2000년대 중반의…

테스트는 통과했는데, 데이터는 여전히 잘못되어 있다

Statistical debugging은 운영 환경 데이터를 신호로, 버그를 이상 신호로 다룬다. 단 하나의 단위 테스트도 추가하지 않고 데이터 손상, off-by-one 오류, 침묵하는 실패를 찾는 방법이다.

당신의 테스트 스위트는 초록색이다. 로그는 조용하다. 대시보드에는 빨간 선이 없다. 그런데 3%의 사용자가 음수 합계가 적힌 인보이스를 받고 있거나, 추천 모델이 삭제된 상품을 조용히 맨 위에 올리고 있거나, 집계 파이프라인이 특정 시간대의 환불을 이중 집계하고 있다. 이것들은 데이터…

Metamorphic testing으로 GCC·LLVM에서 147개 컴파일러 버그와 자율주행차 결함을 발견하는 방법

Metamorphic testing은 GCC, LLVM, Vulkan 셰이더 컴파일러, ADAS 시뮬레이터에서 실제 버그를 찾아냈다. 이 글에서는 이 기법을 동작하는 코드와 함께 설명하고, 당신의 테스트 스위트에 어디에 맞는지 보여준다.

Metamorphic testing은 GCC와 LLVM에서 147개의 확인된 버그를 찾았고, 자동차 OEM이 사용하는 상용 ADAS 시뮬레이터의 결함을 발견했으며, 보행자 사망 사고 8일 전 자율주행차 인지 시스템의 치명적인 결함을 잡아냈다. 이 기법은 학술적으로 들리지만, 버그는…