[GIT] 장애 원인 추적: Blame & Bisect

이번 포스팅에서는 [실전 활용 및 고급 기술] 파트의 세부 주제인 장애 원인 추적: Blame & Bisect에 대하여 상세히 알아보겠습니다.

1. 라인별 작성자 추적 (Blame)

운영 중인 서비스에서 특정 코드 라인으로 인해 치명적인 에러가 발생했을 때, 해당 코드를 누가, 언제, 어떤 커밋 메시지와 함께 추가했는지 즉각적으로 파악해야 합니다. git blame은 파일의 각 줄(Line)마다 수정된 마지막 커밋 내역을 보여줍니다.

# utils.js 파일의 모든 줄에 대한 변경 이력 조회
$ git blame src/utils.js

# 너무 길 경우 특정 라인(예: 50~60번 줄)만 지정해서 조회
$ git blame -L 50,60 src/utils.js

2. 이진 탐색으로 버그 커밋 찾기 (Bisect)

수십 개의 커밋이 쌓인 후에야 특정 기능이 고장 났다는 사실을 뒤늦게 알게 될 때가 있습니다. 어느 커밋부터 문제가 시작되었는지 일일이 확인하는 것은 비효율적입니다. git bisect는 이진 탐색 알고리즘을 활용하여 문제의 커밋을 매우 빠르게 격리시킵니다.

# 1. 탐색 모드 진입
$ git bisect start

# 2. 현재 시점은 버그가 존재함을 명시
$ git bisect bad

# 3. 버그가 없었던 과거의 확실한 커밋 해시(예: c1a2b3) 명시
$ git bisect good c1a2b3

# Git이 자동으로 중간 지점 커밋으로 코드를 되돌려줍니다. 
# 코드를 테스트해 본 뒤, 버그가 있으면 bad, 없으면 good을 입력합니다.
$ git bisect good  (또는 bad)

# 위 과정을 몇 번 반복하면 Git이 "이 커밋이 첫 번째 bad 커밋입니다"라고 알려줍니다.
# 4. 원인 파악 후 원래 시점으로 복귀
$ git bisect reset

---

지금까지 장애 원인 추적: Blame & Bisect의 개념과 구체적인 활용 방안에 대해 살펴보았습니다. 이어지는 다음 포스팅에서 관련 심화 주제를 지속적으로 다루어보겠습니다.