야근 중 AI 코딩이 막힐 때 쓰는 로그 활용법

• 목록
• 답변
• 글쓰기
• 옵션
  • 수정
  • 삭제

야근 중 막힌 코드를 로그로 재질문하는 법

복붙할 로그와 버릴 로그를 먼저 나눕니다

AI 코딩 도구가 가장 자주 빗나가는 순간은 코드가 어려울 때보다 증거가 흐릿할 때입니다. 특히 밤에 배포 전 테스트가 깨지면 우리는 에러 메시지 전체를 붙여 넣고 빨리 고쳐달라고 말하기 쉽습니다. 그런데 AI는 긴 로그를 많이 받는다고 더 똑똑해지는 것이 아니라, 원인과 무관한 줄까지 함께 해석하면서 엉뚱한 파일을 고치려 할 수 있습니다.

숨은 팁은 로그를 줄이는 것이 아니라 질문 가능한 형태로 접는 것입니다. 실패한 명령, 첫 번째 에러, 마지막으로 변경한 파일, 재현 조건을 따로 묶으면 AI는 추측보다 범위 좁히기에 집중합니다. 개발자가 이미 머릿속으로 하는 판단을 작은 패킷처럼 건네는 셈입니다.

• 실패 명령: 어떤 명령을 실행했는지 한 줄로 남깁니다. 예를 들어 pnpm test --filter billing처럼 범위가 드러나야 합니다.
• 첫 번째 에러: 스택 트레이스 전체보다 처음 터진 예외가 우선입니다. 뒤쪽 에러는 연쇄 반응일 가능성이 큽니다.
• 마지막 변경: 방금 바꾼 파일 2~4개만 적습니다. AI가 저장소 전체를 상상하지 않게 막는 장치입니다.
• 재현 조건: 로컬에서만 나는지, CI에서만 나는지, 특정 브랜치에서만 나는지 구분합니다.

로그를 붙일 때는 많게가 아니라 다시 실행할 수 있게가 기준입니다. AI에게 필요한 것은 감정이 담긴 긴 설명보다 실패를 재현할 수 있는 작은 지도입니다.

예를 들어 결제 테스트가 실패했다면 그냥 결제 테스트가 안 된다고 쓰기보다, billing 모듈의 refund 케이스에서 null userId가 들어오며, 직전 변경은 mapper와 fixture라고 적어보세요. 같은 로그라도 이렇게 접으면 AI는 환불 로직 전체를 갈아엎으려 하지 않고, fixture가 잘못된 값으로 구성됐는지부터 확인합니다. 야근 중에는 이 차이가 10분과 1시간을 가릅니다.

한 줄 에러보다 실행 흐름을 보여주면 답이 빨라집니다

시간순 로그 묶음으로 원인 범위를 줄입니다

많은 개발자가 AI 코딩 도구에 마지막 에러 한 줄만 던집니다. 하지만 마지막 에러는 대개 결과이고, 원인은 그보다 앞에서 조용히 시작됩니다. 그래서 잘 알려지지 않은 방식으로 3단 로그 묶음을 쓰면 답변 품질이 확 달라집니다. 요청 시작, 상태 변화, 실패 지점을 시간순으로 3개만 남기는 방법입니다.

예를 들어 API가 500을 반환한다면 응답 에러만 보여주지 말고 요청 파라미터가 들어온 줄, 서비스 함수가 호출된 줄, DB 쿼리 직전의 값까지 연결해 보여주세요. AI는 이 흐름을 보고 컨트롤러 문제인지, 서비스 레이어 문제인지, ORM 매핑 문제인지 빠르게 분류합니다. 특히 레거시 코드에서는 함수 이름보다 실행 순서가 더 믿을 만한 힌트가 됩니다.

1. 입구 로그: 사용자 입력, route, feature flag, 환경값처럼 흐름이 시작된 정보를 남깁니다.
2. 중간 로그: 값이 변환되는 지점, 캐시 조회, 권한 검증, 외부 API 호출 직전 상태를 남깁니다.
3. 실패 로그: 예외 타입, 실패 함수, 기대값과 실제값을 붙입니다. 스택 트레이스는 필요한 부분만 줄입니다.

테스트 이름을 프롬프트 키로 씁니다

테스트가 깨졌다면 테스트 이름은 단순한 설명이 아니라 AI에게 주는 검색 키워드입니다. should return empty list when account is suspended 같은 테스트 이름은 조건, 기대 결과, 도메인 규칙을 한 번에 담고 있습니다. 그래서 프롬프트 맨 위에 실패한 테스트 이름을 적고, 그 아래 로그를 붙이면 AI가 훨씬 덜 헤맵니다.

아래처럼 질문을 바꾸면 같은 도구에서도 답이 달라집니다. 핵심은 고쳐줘가 아니라 이 실패가 어느 레이어에서 시작됐는지 먼저 판단해줘라고 묻는 것입니다.

• 아쉬운 질문: 이 에러 왜 나요? 고쳐주세요.
• 나은 질문: suspended account 테스트에서 빈 배열을 기대했는데 active item 1개가 반환됩니다. mapper, policy, fixture 중 어디를 먼저 확인해야 할까요?
• 더 나은 질문: 아래 로그의 시간순 흐름을 보고 원인 후보를 3개로 좁힌 뒤, 가장 작은 수정부터 제안해주세요.

이 방식은 AI가 바로 코드를 생성하기보다 진단자 역할을 하게 만듭니다. 코드 자동완성보다 더 값진 순간은 문제의 위치를 정확히 좁혀주는 때입니다. 손이 급할수록 이 한 문장을 앞에 붙여보세요. 수정량이 줄어들고, 리뷰에서 왜 이렇게 바꿨는지 설명하기도 쉬워집니다.

팀 저장소에서 몰래 효율을 올리는 로그 템플릿

PR 설명 대신 실패 노트를 붙입니다

AI 코딩을 팀에서 쓸 때 은근히 효과가 큰 습관은 PR 본문에 실패 노트를 남기는 것입니다. 모든 로그를 공유하라는 뜻은 아닙니다. AI에게 물어본 질문, 실패한 시도, 버린 원인 후보를 짧게 적어두면 다음 사람이 같은 길을 다시 걷지 않습니다. 이 노트는 리뷰어에게도 좋고, 며칠 뒤 자신에게도 좋습니다.

특히 버그 수정 PR에서는 성공한 코드보다 실패한 접근이 더 많은 정보를 줍니다. 예를 들어 캐시를 비우면 해결되는 줄 알았지만 재현됐다는 기록은, 리뷰어가 캐시 레이어가 아니라 상태 동기화를 보게 만듭니다. AI도 이 노트를 함께 받으면 이미 배제한 원인을 반복하지 않습니다.

• 문제 상황: 어떤 사용자 흐름에서 깨졌는지 한 문장으로 씁니다.
• 관찰 로그: 실패 지점의 핵심 값 2~3개만 적습니다.
• 버린 가설: 확인했지만 원인이 아니었던 후보를 남깁니다.
• AI에게 남길 질문: 다음에 이어서 물을 수 있는 질문 형태로 끝냅니다.

보안 로그는 먼저 지운 뒤 건넵니다

로그 활용에서 가장 위험한 실수는 민감정보가 섞인 로그를 그대로 AI에게 붙이는 것입니다. 토큰, 세션 쿠키, 고객 이메일, 내부 URL, 계정 ID는 디버깅에 필요해 보여도 대부분 대체값으로 바꿀 수 있습니다. AI 코딩 생산성을 높이려다 보안 사고의 씨앗을 남기면 팀 전체 비용이 커집니다.

코드와 로그를 함께 다룰 때는 코드 보안의 기본 개념을 한 번씩 되새기는 편이 좋습니다. 또 짧은 설명이 필요하다면 코드 보안 요약처럼 핵심 용어를 확인해두면 팀원 간 기준을 맞추기 쉽습니다. 여기서 중요한 포인트는 보안을 개발의 마지막 관문으로 미루지 않는 것입니다. 로그를 AI에게 전달하는 순간에도 이미 보안 판단이 들어갑니다.

실무 팁: 로그를 붙이기 전 token, cookie, authorization, email, phone, secret, key 같은 단어로 한 번 검색하세요. 발견된 값은 실제 형식을 유지한 더미 값으로 바꾸면 AI의 추론력은 유지하면서 노출 위험은 줄일 수 있습니다.

팀에서 바로 쓸 수 있는 간단한 템플릿은 다음과 같습니다. 환경: local 또는 CI / 실패 명령: 한 줄 / 첫 에러: 세 줄 이내 / 직전 변경: 파일명 목록 / 제외한 가설: 두 개 이내 / 원하는 답: 원인 후보, 최소 수정, 테스트 보강 순서로 적습니다. 이 정도만 표준화해도 AI가 매번 질문을 다시 해석하는 비용이 줄어듭니다.

로그를 남겨도 AI가 헛도는 순간들

증상만 모아두면 같은 답을 반복합니다

로그를 꽤 붙였는데도 AI 답변이 계속 비슷하다면, 로그가 부족한 것이 아니라 대조군이 없을 수 있습니다. 실패한 케이스만 보여주면 AI는 정상 흐름과 무엇이 다른지 모릅니다. 같은 함수가 정상 동작하는 입력 하나를 함께 주면, AI는 차이를 기준으로 원인을 찾습니다. 이 작은 비교가 숨어 있는 꿀팁입니다.

예를 들어 관리자 계정에서는 성공하고 일반 계정에서는 실패한다면, 두 요청의 role, permission, tenantId 차이를 나란히 적어주세요. AI는 이때부터 인증, 권한, 멀티테넌시 같은 후보를 우선순위에 올립니다. 반대로 실패 로그만 길게 주면 네트워크, 타입, 캐시, DB를 모두 의심하며 답이 넓어집니다.

• 실수 1: 실패 로그만 길게 붙입니다. 정상 로그 한 조각을 같이 줘야 차이를 볼 수 있습니다.
• 실수 2: 에러를 예쁘게 요약하다가 원래 값의 형태를 지웁니다. null, undefined, 빈 문자열, 0은 서로 다른 단서입니다.
• 실수 3: 원하는 답의 형식을 말하지 않습니다. 원인 후보가 필요한지, 패치 코드가 필요한지, 테스트 케이스가 필요한지 구분해야 합니다.

실패 로그를 너무 예쁘게 다듬는 습관

로그를 정리하는 일은 좋지만, 지나치게 번역하면 단서가 사라집니다. 특히 타입스크립트, SQL, HTTP 상태 코드, 빌드 도구의 원문 표현은 그대로 두는 편이 낫습니다. 사람이 보기 좋게 바꾼 문장은 AI에게 친절해 보이지만, 실제로는 검색 가능한 기술 단어를 없애는 일이 될 수 있습니다.

또 하나 자주 보이는 실수는 AI가 제안한 패치를 바로 적용한 뒤, 새 로그를 이전 대화에 덧붙이기만 하는 것입니다. 패치 후에는 상황이 달라졌으므로 질문도 다시 구성해야 합니다. 이전 상태, 적용한 변경, 새로 생긴 증상을 구분해서 적어야 AI가 자신의 이전 답을 방어하지 않고 새 증거를 봅니다.

1. 먼저 원문 에러 3~7줄을 보존합니다. 사람이 만든 요약은 그 아래에 붙입니다.
2. 정상 케이스와 실패 케이스를 하나씩 둡니다. 값의 차이가 드러나야 합니다.
3. AI에게 원하는 산출물을 지정합니다. 예: 원인 후보 3개, 최소 수정 diff, 재발 방지 테스트.
4. 새 패치를 적용했다면 질문을 새로 시작합니다. 같은 채팅을 쓰더라도 변경 전후를 명확히 나눕니다.

야근 중에는 빨리 끝내고 싶어서 로그를 한꺼번에 던지게 됩니다. 하지만 AI 코딩에서 로그는 쓰레기통이 아니라 작은 실험 기록에 가깝습니다. 실패 명령, 첫 에러, 정상 대조군, 민감정보 제거, 원하는 답 형식만 챙겨도 AI는 훨씬 덜 떠돌고, 개발자는 더 적은 수정으로 같은 문제를 통과할 수 있습니다.