WEB AGENCY STARTUP
버그 수정 작업은 추리 과정이다
버그가 발생했다고 바로 원인을 알 수 있는 것은 아니다
개발을 하면서 가장 당황스러운 순간 중 하나는 프로그램이 예상대로 동작하지 않을 때입니다.
분명 코드에는 큰 문제가 없어 보이는데 화면에서는 오류가 발생하고, 기능테스트중 갑자기 동작하지 않는 현상이 발생하기도 합니다.
더 어려운 경우도 있습니다.
에러 메시지는 나타나지만 실제 원인은 다른 곳에 있는 경우입니다.
에러 발생
↓
에러 메시지 확인
↓
원인 추적
↓
관련 코드 확인
↓
다른 가능성 확인
↓
원인 발견
이 과정은 단순히 코드를 수정하는 것과는 조금 다릅니다.
문제의 원인을 찾아가는 과정에 가깝습니다.
첫 번째 단서는 에러 메시지
버그가 발생하면 가장 먼저 확인하는 것은 에러 메시지입니다.
예를 들어 다음과 같은 오류가 발생할 수 있습니다.
TypeError: Cannot read properties of undefined
처음에는 단순한 에러 메시지처럼 보입니다.
하지만 이 메시지를 통해 특정 값이 예상했던 데이터가 아니라는 사실을 알 수 있습니다.
그다음에는 다음과 같은 질문을 하게 됩니다.
왜 값이 undefined가 되었을까?
API에서 전달되지 않은 것일까?
프론트엔드에서 잘못 처리한 것일까?
데이터베이스에 값이 없는 것일까?
이때부터 본격적인 추리가 시작됩니다.
버그를 재현하는 것이 중요하다
버그를 해결하기 위해서는 먼저 동일한 문제가 다시 발생하는지 확인해야 합니다.
어떤 조건에서 버그가 발생하는지 찾는 것입니다.
예를 들어 다음과 같은 상황을 확인할 수 있습니다.
로그인한 상태에서 발생하는가?
로그아웃 상태에서도 발생하는가?
PC에서 발생하는가?
모바일에서도 발생하는가?
특정 데이터에서만 발생하는가?
특정 버튼을 클릭했을 때 발생하는가?
조건을 하나씩 바꿔보면서 버그가 발생하는 범위를 좁혀갑니다.
이 과정에서 문제의 중요한 단서를 발견할 수 있습니다.
가설을 세운다
버그를 수정할 때는 하나의 원인만 생각하기보다 여러 가지 가능성을 생각해 보는 것이 좋습니다.
예를 들어 API 요청이 실패했다고 가정해 보겠습니다.
가능성은 여러 가지가 있습니다.
① API 주소가 잘못되었을 수 있다.
② 백엔드 서버가 실행되지 않았을 수 있다.
③ CORS 문제일 수 있다.
④ 인증 토큰이 잘못되었을 수 있다.
⑤ 데이터베이스 오류일 수 있다.
이제 하나씩 확인하면서 가능성을 제거합니다.
API 주소 확인 → 정상
서버 상태 확인 → 정상
CORS 확인 → 정상
토큰 확인 → 정상
데이터베이스 로그 확인 → 오류 발견
이렇게 원인의 범위를 좁혀갈 수 있습니다.
로그는 중요한 단서다
버그를 추적할 때 로그는 매우 중요한 역할을 합니다.
프론트엔드에서는 브라우저 개발자 도구의 콘솔과 Network 탭을 확인하고, 백엔드에서는 서버 로그를 확인합니다.
Browser Console
↓
Network
↓
Spring Boot Log
↓
Database Log
각 단계에서 어떤 일이 발생했는지 확인하면 문제가 발생한 지점을 좁힐 수 있습니다.
특히 여러 시스템이 연결된 웹 서비스에서는 한 곳의 오류가 다른 곳에서 증상으로 나타나는 경우가 많습니다.
가장 어려운 버그는 증상과 원인이 다른 경우다
버그 수정이 어려운 이유 중 하나는 사용자에게 나타나는 증상과 실제 원인이 다를 수 있기 때문입니다.
예를 들어 화면에서 상품 목록이 나타나지 않는다고 가정해 보겠습니다.
처음에는 프론트엔드 문제라고 생각할 수 있습니다.
하지만 실제 원인은 다음과 같을 수도 있습니다.
Frontend
↓
API 요청
↓
Spring Boot
↓
JPA
↓
PostgreSQL
↓
잘못된 데이터
데이터베이스에 문제가 있었는데 사용자는 단순히 "상품 목록이 안 나온다"고 느끼는 것입니다.
따라서 증상이 발생한 화면만 보는 것이 아니라 데이터가 전달되는 전체 흐름을 확인해야 합니다.
하나씩 가능성을 제거한다
버그 수정 과정은 추리와 비슷합니다.
처음에는 가능한 원인이 여러 개 있습니다.
원인 후보
A
B
C
D
E
그리고 하나씩 확인합니다.
A → 정상
B → 정상
C → 정상
D → 이상 발견
이제 D를 중심으로 다시 범위를 좁혀갑니다.
D-1
D-2
D-3
D-4
이 과정을 반복하다 보면 결국 문제를 발생시킨 원인에 가까워집니다.
성급하게 코드를 수정하지 않는다
버그를 발견하면 바로 코드를 수정하고 싶은 마음이 생깁니다.
하지만 원인을 정확히 파악하지 않은 상태에서 코드를 수정하면 문제가 해결되지 않거나 새로운 문제가 발생할 수 있습니다.
그래서 가능하면 다음 순서로 접근하려고 합니다.
문제 확인
↓
재현
↓
로그 확인
↓
가설 설정
↓
가설 검증
↓
원인 확인
↓
코드 수정
↓
테스트
원인을 확인한 후 수정하는 것이 중요합니다.
버그를 해결하면서 배우게 된다
개발하면서 경험하는 버그는 스트레스를 주기도 하지만 동시에 많은 것을 배우게 합니다.
처음에는 단순한 오류였던 문제가 나중에는 시스템 전체의 구조를 이해하는 계기가 되기도 합니다.
예를 들어 API 하나의 오류를 해결하면서
React
↓
REST API
↓
Spring Boot
↓
JPA
↓
PostgreSQL
전체 흐름을 이해하게 될 수도 있습니다.
문제를 해결하기 위해 시스템을 따라가다 보면 자연스럽게 프로그램의 구조를 더 깊게 이해하게 됩니다.
버그 수정은 문제해결 과정이다
버그가 발생하면 처음에는 단서가 거의 없습니다.
에러 메시지 하나,
재현 조건 하나,
로그 한 줄.
이런 작은 단서들을 모아서 문제의 원인을 추론해야 합니다.
그리고 여러 가능성을 하나씩 제거하면서 결국 원인을 찾아냅니다.
그래서 개발을 하면서 점점 이런 생각을 하게 됩니다.
버그 수정은 코딩이라기보다 추리에 가깝다.
코드를 작성하는 능력도 중요하지만 문제의 원인을 논리적으로 추적하는 능력 역시 개발자에게 중요한 능력이라고 생각합니다.
마무리
버그는 개발 과정에서 완전히 피하기 어렵습니다.
중요한 것은 버그가 발생했을 때 당황하지 않고 문제를 작은 단위로 나누어 하나씩 확인하는 것입니다.
에러 메시지를 보고,
문제를 재현하고,
로그를 확인하고,
가능한 원인을 세우고,
하나씩 검증하다 보면 결국 원인을 찾을 수 있습니다.
처음에는 복잡해 보였던 문제도 단서를 하나씩 모으다 보면 해결 방법이 보이기 시작합니다.
그래서 앞으로도 버그를 만났을 때 단순히 "왜 안 되지?"라고 생각하기보다,
"어떤 단서가 있고, 어떤 가능성을 제거할 수 있을까?"
라고 생각해 보려고 합니다.
버그를 해결하는 과정은 결국 문제를 추리하고 답을 찾아가는 과정이기 때문입니다.