console.log만으로는 부족했던 어느 날의 디버깅 기록

개발을 하다 보면 누구나 한 번쯤 마주하는 풍경이 있습니다. 콘솔창 가득 메워진 111, here, obj 같은 의미 없는 문자열들. 급한 마음에 추가한 console.log는 당장의 불을 끄는 데는 도움이 되지만, 프로젝트의 규모가 커지고 비즈니스 로직이 복잡해질수록 오히려 소음이 되어 우리의 눈을 가리곤 합니다.

저 역시 얼마 전, 수십 개의 API 응답과 복잡한 상태 변화가 얽힌 결제 로직을 디버깅하며 비슷한 경험을 했습니다. console.log만으로는 도저히 데이터의 흐름을 쫓을 수 없었던 그 순간, 저는 우리가 무심코 지나쳤던 console 객체의 진정한 가치를 다시금 깨닫게 되었습니다. 이번 글에서는 단순한 출력을 넘어, ‘관측 가능성(Observability)‘의 관점에서 console을 어떻게 활용할 수 있는지 그 고민의 과정을 공유하려 합니다.

1. 데이터의 형상에 집중하기: console.table

우리는 보통 API 응답을 확인하기 위해 습관적으로 console.log(response)를 타이핑합니다. 하지만 응답 데이터가 수십 개의 필드를 가진 객체 배열이라면 어떨까요? 브라우저 콘솔에서 화살표를 일일이 클릭하며 필드를 확인하는 과정은 그 자체로 인지 부하를 일으킵니다.

”표(Table)는 인지 부하를 줄이는 가장 강력한 도구입니다”

Toss Tech의 글에서 인터페이스를 ‘계약’으로 바라보듯, 저는 로그 역시 ‘데이터의 계약’을 확인하는 과정이라고 생각합니다. console.table은 이 계약의 이행 여부를 가장 명확하게 보여줍니다.

// 복잡한 주문 목록 데이터
const orders = [
  { id: 'ORD-001', product: 'MacBook Pro', price: 2500000, status: 'PAID', customer: 'Jungjin' },
  { id: 'ORD-002', product: 'iPad Air', price: 900000, status: 'PENDING', customer: 'Antigravity' },
  { id: 'ORD-003', product: 'iPhone 15', price: 1200000, status: 'FAILED', customer: 'Toss' },
]

// 단순히 log로 찍으면 객체의 깊이에 갇히게 되지만,
// table은 데이터의 '형상'을 한눈에 드러냅니다.
console.table(orders, ['id', 'product', 'status'])

실무에서의 가치: 단순히 예쁘게 보여주는 것을 넘어, 콘솔창의 표 헤더를 클릭해 데이터를 정렬해 볼 수 있다는 점이 핵심입니다. 특정 상태(FAILED)의 데이터만 모아보거나 가격 순으로 정렬해 보는 행위는 별도의 로직 추가 없이도 즉각적인 분석을 가능하게 합니다.

2. 맥락(Context)을 잃지 않는 디버깅: console.group

비동기 작업이 연달아 일어나는 환경에서 로그는 순서가 뒤섞이기 마련입니다. A 작업의 로그와 B 작업의 로그가 콘솔창에서 뒤엉키는 순간, 우리는 디버깅의 ‘맥락’을 잃어버립니다.

”로그에도 계층이 필요합니다”

저는 복잡한 로직을 수행할 때 console.group을 통해 로그에 명확한 경계를 긋습니다. 이는 마치 코드에서 함수를 분리하는 것과 같은 논리적 단위의 구분을 콘솔에서도 실현하는 것입니다.

async function processPayment(orderId) {
  console.group(`💳 결제 프로세스 시작: ${orderId}`)

  try {
    console.log('1. 재고 확인 중...')
    // ... 재고 확인 로직

    console.groupCollapsed('🔍 상세 검증 데이터')
    console.log('할인율: 10%')
    console.log('포인트 사용: 5,000p')
    console.groupEnd()

    console.log('2. PG사 결제 요청 전송')
    // ... 결제 요청 로직
  } finally {
    console.groupEnd()
  }
}

왜 groupCollapsed인가?: 모든 정보를 처음부터 다 보여주는 것은 정보 과잉입니다. groupCollapsed를 사용하면 평소에는 핵심 흐름만 보여주다가, 문제가 생겼을 때만 상세 내용을 펼쳐볼 수 있는 ‘선택적 노출’이 가능해집니다. 이는 디버깅 시 시각적 소음을 줄이는 실용적인 전략입니다.

3. 보이지 않는 범인 찾기: console.count & console.dir

가끔은 로직이 의도치 않게 여러 번 실행되거나, DOM 객체의 내부 속성이 궁금할 때가 있습니다. 이때 log는 우리에게 너무 많은 정보를 주거나, 혹은 너무 적은 정보를 줍니다.

”횟수를 세는 것만으로도 버그는 잡힙니다”

리액트 컴포넌트가 왜 이렇게 자주 리렌더링되는지 궁금할 때, console.count는 가장 원초적이면서도 확실한 도구가 됩니다.

function MyComponent() {
  // 컴포넌트가 렌더링될 때마다 횟수를 기록합니다.
  console.count('🖥️ MyComponent 렌더링 횟수')
  return <div>Hello World</div>
}

또한, DOM 요소를 console.log로 찍으면 HTML 태그 형태로 보이지만, console.dir로 찍으면 해당 요소가 가진 모든 자바스크립트 속성을 계층적으로 확인할 수 있습니다.

// 태그가 아니라 '객체'로서의 속성이 궁금할 때
const button = document.querySelector('button')
console.dir(button)

4. 나만의 디버깅 테마: CSS Styling (%c)

로그가 너무 많아 중요한 메시지가 묻힌다면, 아예 눈에 띄게 스타일을 입힐 수도 있습니다. 이는 단순한 재미를 넘어, 대규모 프로젝트에서 특정 모듈의 로그를 시각적으로 구분하는 데 매우 유용합니다.

const successStyle =
  'color: white; background: green; font-weight: bold; padding: 2px 5px; border-radius: 3px;'
const errorStyle =
  'color: white; background: red; font-weight: bold; padding: 2px 5px; border-radius: 3px;'

console.log('%c SUCCESS ', successStyle, '데이터 동기화 완료')
console.log('%c ERROR ', errorStyle, '네트워크 연결 실패')

실용적 포인트: 라이브러리를 개발하거나 공통 모듈을 만들 때, 해당 모듈에서 발생하는 로그에 고유한 색상을 부여해 보세요. 다른 개발자들이 로그를 확인할 때 “아, 이건 그 모듈에서 보낸 거구나”라고 즉각적으로 인지할 수 있게 됩니다.

5. 성능과 추적, 그 이상의 신뢰: console.time & trace

가끔은 “코드가 돌아가긴 하는데, 왜 이렇게 느리지?” 혹은 “이 함수가 왜 여기서 호출됐지?”라는 근본적인 의문이 들 때가 있습니다. 이때 우리는 감(Intuition)에 의존하기보다 데이터(Data)에 의존해야 합니다.

”측정할 수 없다면 개선할 수 없습니다”

console.time은 코드의 특정 구간이 차지하는 물리적 시간을 측정해 줍니다. 특히 리액트의 리렌더링 최적화나 대량의 데이터 가공 로직에서 병목 지점을 찾는 데 탁월합니다.

console.time('🔥 데이터 가공 성능 테스트')
const processedData = data.filter((item) => item.active).map(transform)
console.timeEnd('🔥 데이터 가공 성능 테스트')

또한, console.trace는 호출 스택(Call Stack)을 그대로 노출합니다. 이는 특히 공통 컴포넌트나 유틸리티 함수가 의도치 않은 곳에서 호출되어 부수 효과(Side Effect)를 일으킬 때, 그 범인을 찾는 가장 확실한 증거가 됩니다.

마치며: 콘솔은 우리와 코드 사이의 대화창입니다

Toss Tech의 SDK 개발기가 ‘안정성’과 ‘명확성’을 향한 여정이었듯, 우리의 디버깅 과정 역시 코드에 대한 신뢰를 쌓아가는 과정이어야 합니다. console.log 한 줄에 의존하던 습관에서 벗어나 상황에 맞는 적절한 메서드를 선택하는 것, 그것이 바로 ‘실용주의 개발자’로서 우리가 가져야 할 태도가 아닐까 생각합니다.

단순히 텍스트를 찍는 행위를 넘어, 시스템의 상태를 구조적으로 관측하고 분석하는 도구로서 console을 바라봐 보세요. 여러분의 콘솔창이 소음이 아닌, 명확한 신호(Signal)로 가득 차길 응원합니다.