• 디버깅은 원래 ‘문제를 찾고 해결하는 것’이라는 뜻이지만, 개발자는 코드의 작동 방식을 분석하는 다양한 목적으로 디버깅을 수행한다.
    • 새로운 프레임워크 배우기
    • 문제의 근본 원인 찾기
    • 기본 로직을 이해하여 새로운 기능으로 확장하기

앱을 더 쉽게 이해하는 방법

  • 코드 조사: 소프트웨어 기능의 특정한 동작을 분석하는 프로세스
    • ‘소프트웨어 에러를 찾아 고치는’ 디버깅이라는 용어를 혼용해서 사용하고 있다.
  • 코드 조사를 하는 이유
    • 어떤 문제를 찾아낸다.
    • 어떤 소프트웨어의 기능이 어떻게 작동되는지 알아야 개선할 수 있다.
    • 어떤 기술 또는 라이브러리를 학습한다.
  • 코드 조사 기법은 다양하다. 아래 방법 중 하나 이상을 택하여 소프트웨어 작동 방식을 이해한다.
    • 코드 읽기
    • 프로파일링
    • 디버깅
    • 스레드 상태 분석
    • 로그 분석
    • 메모리 상태 분석
    • 모킹 및 스터빙

일반적인 코드 조사 시나리오

상황 1: 예상과 다른 아웃풋의 원인을 밝힌다

  • 아웃풋은 앱에 따라 다양하게 정의할 수 있는데, 콘솔에 표시되는 텍스트일 수도 있고 DB에서 변경된 레코드일 수도 있다. 앱이 다른 시스템으로 보내는 HTTP 요청이나 클라이언트의 요청에 대한 HTTP 응답이 아웃풋인 경우도 있다.
  • 시나리오 1: 단순 케이스
    • DB에 레코드를 삽입하는 앱이 있는데 예상보다 더 적은 레코드가 DB에 삽입되는 경우
    • 디버거 도구를 이용해 코드 실행을 따라가보는 것이 가장 간단한 분석 방법이다.
  • 사니라오 2: 어디서부터 디버깅을 시작해야 할 까?
    • 아웃풋의 문제이긴 하나, 이 앱을 구현한 수천 라인의 코드 중 어디를 고쳐야할지 모르는 경우
    • 프로파일러: 앱이 실행되는 동안 어떤 코드가 실행되는지 식별하는 도구
    • 디버거로 어디서부터 조사를 시작해야 할지 영감을 주는 것에는 프로파일러가 적합하다.
  • 시나리오 3: 멀티스레드 앱
    • 멀티스레드 아키텍처는 간섭에 민감한 편이어서 디버거를 사용할 수 없는 경우가 많다.
    • 하이젠버그 실행 또는 하이젠버그: 디버거를 사용하는 시점마다 앱이 다르게 작동할 수 있다는 의미
  • 시나리오 4: 주어진 서비스에 잘못된 호출 보내기
    • 다른 시스템의 컴포넌트나 외부 시스템과 올바르게 상호작용하지 못하는 경우
    • 코드의 어느 부분이 요청을 보내는지 알고 있다면 디버거를 사용해서 앱이 어떻게 요청을 생성하는지 살펴보고 어디가 잘못됐는지 확인한다.
    • 앱의 어느 코드가 요청을 전송하는지 모르면 프로파일러를 사용해서 찾아야 한다.
    • 앱이 요청을 주고 받는 위치를 특정하기 곤란한 복잡한 경우라면, 다른 앱을 스텁으로 바꿔버리는 방법이 있다.
      • 스텁으로 요청을 차단시켜 앱이 응답을 무한 대기하도록 만들면 코드의 어느 부분이 요청을 보내는지 알 수 있다.

상황2: 특정 기술을 습득한다

  • 새로운 지식을 습득할 때 문서 읽기가 필수인 것은 맞지만, 어떤 기술은 너무 복잡한 나머지 나머지 책이나 스펙을 읽는 것만으로는 배우기가 어렵다.
  • 그러므로 항상 프레임워크나 라이브러리를 깊이 파헤쳐보면서 제대로 이해하는 것이 중요하다.

상황3: 속도 저하 이유를 알아낸다

  • 성능 문제는 앱을 실행하는 시시각각 발생하기 때문에 다른 문제와 마찬가지로 해결 방안을 강구하기 전에 원인을 조사해야 한다.
    • 따라서 성능 문제의 원인을 파악하기 위해 다양한 디버깅 기법의 올바를 사용법을 배울 필요가 있다.
  • 가장 흔히 발생하는 성능 문제는 앱의 응답 속도와 연관되어 있다.
    • 하지만 응답 속도는 성능 문제의 한 부류일 뿐이다.
    • 좀비 스레드 문제, 네트워크 대역폭 문제 등도 성능 문제의 일례다.
  • 응답 속도 문제는 프로파일러를 사용하면 쉽게 밝혀낼 수 있다.
    • 프로파일러는 어떤 코드가 실행되는지 알아내는 일 외에도 커맨드별 실행 시간도 함께 표시된다.

상황4: 앱 크래시가 발생한 이유를 이해한다

  • 앱 크래시는 특정한 조건에서 발생하는 경우가 많은데, 로컬 환경에서는 앱 크래스를 재현하기가 어려워 다른 문제보다 좃하하기가 더 까다로운 편이다.
  • 앱 크래시는 보통 두 가지 형태로 일어난다.
    • 앱이 완전히 멈춘다.
    • 실행은 계속되지만 요청에 응답하지 않는다.
  • 앱이 완전히 멈춰다는 것은 복구 불가능한 에러가 발생했다는 뜻이다.
    • 대부분 메모리 에러 때문에 일어난다. 자바는 힙 메모리가 가득 차 앱이 더 이상 작동하지 않으면 OOM 에러를 낸다.
    • 힙 메모리 문제를 조사하려면 특정 시점에 힙 메모리에 어떤 데이터가 포함되어 있는지 스냅숏에 해당하는 힙 덤프를 사용한다.
  • 앱은 계속 실행되고 있지만 요청을 해도 응답이 없는 경우, 스레드 덤프는 안에서 무슨 일이 일어나고 있는지 분석하는 최상의 도구다.