로그가 뭐예요? 왜 필요한가요?

바이브코딩을 하다 보면 AI가 이런 말을 합니다.

로그를 확인해볼게요.
오류가 발생한 기록을 찾아볼게요.
PostHog에 이벤트를 남길게요.

처음 듣는 사람에게는 모두 낯선 말이에요.

로그가 무엇인지 모르는데 “로그를 확인하세요”라는 설명부터 들으면 무엇을 어디에서 봐야 하는지 알기 어렵습니다.

화면에 나타난 노란색과 빨간색 메시지부터 확인하고 싶다면 Warning과 Error를 구분해 AI에게 전달하는 방법을 먼저 읽어보세요. 이 글에서는 화면에서 바로 확인하기 어려운 문제를 기록으로 찾는 방법을 이어서 설명합니다.

먼저 한 문장으로 알아볼게요.

로그
→ 앱에서 생긴 일을 시간순으로 남긴 기록

로깅
→ 해당 기록을 남기는 일

로그는 개발자만 읽는 복잡한 문서가 아닙니다. 앱이 언제 어떤 요청을 받았고, 어떤 결과를 돌려줬으며, 어디에서 문제가 생겼는지 남기는 작업 일지에 가까워요.

사용자가 보는 화면만으로는 원인을 알기 어려워요

사용자는 결제에 실패하면 다음과 같은 안내를 볼 수 있습니다.

결제에 실패했습니다.
잠시 후 다시 시도해주세요.

이 문구만으로는 왜 실패했는지 알 수 없습니다.

하지만 앱이 필요한 로그를 남겼다면 운영자는 더 많은 내용을 확인할 수 있어요.

오후 3시 12분에 결제 요청이 들어옴
→ 결제 확인 단계까지 진행됨
→ 특정 조건에서 서버 요청 실패
→ 오류 코드가 기록됨
→ 고객에게 실패 안내를 보여줌

사용자에게는 간단한 안내를 보여주고, 운영자에게는 문제를 찾는 데 필요한 기록을 남기는 것입니다.

로그가 있으면 “결제가 안 됐다”에서 멈추지 않고 어느 단계에서 어떤 조건으로 실패했는지 찾을 수 있어요.

뚝딱에도 “결제가 안 돼요”라는 문의가 들어왔어요

뚝딱에서 실제로 결제가 되지 않는다는 고객 문의를 받은 적이 있습니다.

결제 기능 전체가 고장 난 상황은 아니었어요. 다른 고객은 결제하고 있었고, 운영자가 같은 과정을 다시 시도해도 정상적으로 작동했습니다.

일부 고객에게만 문제가 발생함
같은 과정을 다시 시도하면 결제가 됨
같은 행동을 해도 바로 재현되지 않음
문의 내용만으로 실패 조건을 알 수 없음

이런 문제는 코드를 다시 읽는 것만으로 찾기 어렵습니다. 언제나 실패하는 것이 아니라 특정 조건이 겹칠 때만 실패하기 때문이에요.

클로드코드(Claude Code)에 Vercel과 PostHog의 기록을 확인하게 했습니다.

Vercel 로그
→ 결제 요청을 처리한 서버의 기록 확인

PostHog
→ 고객이 결제 전후에 한 행동 확인

클로드코드는 결제에 성공한 경우와 실패한 경우를 나눠 비교했습니다. 실패한 경우에 공통으로 나타난 조건을 좁히고, 해당 조건을 처리하도록 코드를 고쳤어요.

처음에는 직접 재현하지 못했던 문제를 로그에 남은 기록으로 다시 구성한 셈입니다.

로그가 없었다면 고객에게 다시 물어봐야 했어요

기록이 없다면 고객의 기억에 의존해야 합니다.

어떤 기기에서 시도했나요?
어떤 브라우저를 사용했나요?
어느 화면에서 시작했나요?
어떤 버튼을 어떤 순서로 눌렀나요?
화면에 어떤 문구가 나왔나요?

고객도 모든 과정을 정확히 기억하지 못할 수 있어요. 이미 결제를 포기한 고객에게 여러 차례 확인을 요청하기도 어렵습니다.

문의한 고객의 문제를 해결하더라도 같은 상황에서 말없이 떠난 고객이 더 있었는지는 알 수 없습니다.

로그가 없으면
→ 문제를 재현하지 못함
→ 짐작으로 코드를 바꿈
→ 제대로 고쳤는지 알기 어려움
→ 같은 문제가 반복됨
→ 고객을 계속 놓침

문의 한 건은 눈에 보이는 문제일 뿐입니다. 오류를 겪은 고객이 모두 문의를 남기지는 않아요.

로그는 오류를 고치기 위한 기록이면서, 말없이 떠나는 고객을 발견하기 위한 기록입니다.

로그에는 무엇을 남기나요?

처음부터 모든 일을 기록할 필요는 없습니다.

회원가입, 예약, 문의와 결제처럼 서비스에서 중요한 흐름부터 시작하면 돼요.

결제를 예로 들면 다음 단계를 남길 수 있습니다.

결제 페이지 진입
→ 결제 버튼 클릭
→ 결제창 열림
→ 결제 확인 요청
→ 결제 성공 또는 실패

각 단계에서 다음 질문에 답할 수 있으면 좋습니다.

• 어떤 일이 일어났나요?
• 언제 일어났나요?
• 성공했나요, 실패했나요?
• 실패했다면 어느 단계였나요?
• 어떤 오류 코드가 남았나요?
• 개발 중인 앱과 실제 운영 중인 앱 중 어디에서 발생했나요?
• 수정한 뒤 같은 문제가 줄었나요?

로그를 많이 남기는 것보다 나중에 필요한 질문에 답할 수 있게 남기는 것이 중요합니다.

Vercel 로그는 서버에서 생긴 일을 보여줘요

Vercel에 앱을 배포하면 서버 기능이 실행된 기록을 확인할 수 있습니다.

결제 기능에서는 다음 내용을 찾는 데 도움이 돼요.

결제 요청이 서버까지 들어왔는가
어느 기능에서 실패했는가
어떤 상태와 오류를 돌려줬는가
어느 배포 버전에서 발생했는가

사용자 화면에는 같은 실패 문구가 나와도 실제 원인은 다를 수 있습니다.

결제 요청이 서버에 도착하지 않았을 수도 있고, 외부 결제 서비스가 오류를 돌려줬을 수도 있고, 결제 후 주문을 저장하는 과정에서 문제가 생겼을 수도 있어요.

Vercel 로그를 보면 서버가 무엇을 처리했고 어디에서 멈췄는지 확인할 수 있습니다.

PostHog는 사용자가 한 행동을 보여줘요

서버의 기록만으로는 사용자가 실패 전에 무엇을 했는지 알기 어려울 수 있습니다.

PostHog 같은 제품 분석 도구를 연결하면 사용자가 어느 화면을 봤고, 어떤 버튼을 눌렀으며, 어느 단계에서 멈췄는지 확인할 수 있어요.

결제 페이지를 본 사람
→ 결제 버튼을 누른 사람
→ 결제창을 연 사람
→ 결제에 성공한 사람

단계마다 몇 명이 도착했는지 비교하면 사용자가 많이 빠져나가는 지점을 찾을 수 있습니다. 이런 흐름을 퍼널이라고 해요.

PostHog의 세션 리플레이를 사용하면 사용자가 화면에서 어떤 행동을 했는지도 다시 볼 수 있습니다.

Vercel
→ 서버에서 생긴 일

PostHog
→ 사용자가 화면에서 한 일

두 기록을 함께 보면 “서버에서 오류가 났다”를 넘어 “어떤 사용자가 어떤 흐름을 거쳤을 때 오류가 났다”까지 확인할 수 있어요.

클로드코드가 기록을 남기고 분석할 수 있어요

로그를 활용하려면 원래 데이터를 다루는 여러 역할이 필요합니다.

데이터 엔지니어는 앱에서 필요한 기록을 빠짐없이 남기는 구조를 만듭니다. 데이터 분석가는 쌓인 기록을 비교해 문제가 발생한 조건과 사용자가 떠난 지점을 찾습니다.

바이브코딩에서는 클로드코드에 두 역할의 실무를 맡길 수 있어요.

기록을 남기는 역할
→ 중요한 사용자 흐름 정리
→ 시작·성공·실패 이벤트 추가
→ 서버 오류와 결과 기록
→ PostHog 연결
→ 민감한 정보 검사

기록을 분석하는 역할
→ 성공과 실패 사용자 구분
→ 두 집단의 조건 비교
→ 많이 멈추는 단계 확인
→ 실패 조건에 대한 가설 정리
→ 수정 전후 결과 비교

사용자가 직접 분석 명령을 작성하거나 데이터를 표로 정리할 필요는 없습니다.

다음처럼 원하는 조사를 설명하면 됩니다.

최근 7일 동안 결제를 시작했지만
완료하지 못한 흐름을 확인해줘.

결제 성공과 실패를 나누고
실패한 경우에 공통으로 나타나는 조건을 찾아줘.

개인정보와 결제 정보는 출력하지 마.
아직 코드를 수정하지 말고 확인한 근거부터 설명해줘.

클로드코드가 기록을 모으고 비교하더라도 무엇을 조사할지 정하고 어떤 정보에 접근하게 할지 결정하는 일은 사람이 해야 합니다.

바이브코딩 프로젝트에는 PostHog를 추천해요

바이브코딩으로 첫 서비스를 운영한다면 PostHog를 먼저 검토해볼 만합니다.

사용자 행동 분석, 퍼널과 세션 리플레이를 한곳에서 시작할 수 있어 사용자가 어디에서 멈췄는지 확인하기 좋습니다. 오류 추적과 기능 플래그처럼 서비스를 운영하며 필요한 기능도 함께 제공해요.

광고별 사용자 흐름을 비교하기 전에는 메시지 매칭으로 광고와 랜딩페이지를 연결하는 방법부터 확인하세요.

바이브코딩 기술 스택 추천에서도 사용자 행동을 확인하는 도구로 PostHog를 소개했습니다.

PostHog를 연결해도 결제 성공만 기록해서는 부족합니다. 결제 시작과 실패도 함께 남겨야 어느 단계에서 고객을 놓치는지 찾을 수 있어요.

로그에 민감한 정보를 남기면 안 돼요

문제를 자세히 보고 싶다고 모든 정보를 저장해서는 안 됩니다.

다음 정보는 로그나 분석 이벤트에 그대로 남기지 마세요.

• 비밀번호
• 카드번호와 보안 코드
• 인증 토큰과 비밀 키
• 결제 서비스의 비밀값
• 전체 주민등록번호
• 문제 해결에 필요하지 않은 개인정보

이메일, 전화번호와 주문 정보도 꼭 필요한 범위만 남기고 접근 권한을 제한해야 합니다.

클로드코드에 로그를 추가해달라고 요청할 때는 민감한 값을 제외하고, 실제 운영 기록에 무엇이 들어가는지도 확인하게 하세요.

첫 버전에서는 중요한 흐름부터 남겨요

처음부터 앱의 모든 버튼과 화면을 기록하려고 하면 어떤 정보가 중요한지 판단하기 어려워집니다.

고객과 매출에 직접 연결되는 흐름부터 시작하세요.

회원가입 시작 → 성공 → 실패
예약 시작 → 제출 → 확정 → 실패
결제 시작 → 결제창 열림 → 성공 → 실패
문의 작성 → 제출 → 전송 성공 → 실패

클로드코드에는 다음처럼 요청할 수 있습니다.

이 프로젝트에서 고객과 매출에 직접 연결되는
핵심 사용자 흐름을 찾아줘.

각 흐름의 시작, 성공과 실패를 확인할 수 있도록
필요한 로그와 PostHog 이벤트를 제안해줘.

비밀번호, 인증 정보와 개인정보는 수집하지 마.
아직 코드를 수정하지 말고 계획부터 보여줘.

계획을 검토한 뒤 필요한 흐름부터 하나씩 추가하면 됩니다.

결제 기능을 준비하고 있다면 내 웹 애플리케이션에 온라인 결제를 붙이는 방법도 함께 읽어보세요.

로그는 앱에서 생긴 일을 설명하는 기록이에요

화면에 기능이 보인다고 운영할 준비까지 끝난 것은 아닙니다.

서비스를 운영하려면 다음 질문에 답할 수 있어야 해요.

사용자가 실제로 기능을 쓰고 있는가?
어느 단계에서 실패하는가?
어떤 조건에서 같은 문제가 반복되는가?
수정한 뒤 문제가 줄었는가?

뚝딱의 결제 문제도 Vercel과 PostHog에 기록이 남아 있었기 때문에 발생 조건을 찾고 고칠 수 있었습니다.

로그가 없었다면 문제를 재현하지 못한 채 결제를 포기하는 고객을 계속 놓쳤을 수 있어요.

기능 만들기
→ 기록 남기기
→ 실제 사용 확인하기
→ 문제 조건 찾기
→ 수정하기
→ 결과 확인하기

로그는 앱에서 생긴 일을 시간순으로 남긴 기록이고, 로깅은 해당 기록을 남기는 일입니다.

이 두 단어만 이해해도 AI가 “로그를 확인해볼게요”라고 말할 때 무엇을 찾으려는지 알 수 있습니다.