undefined map 에러, ChatGPT에 먼저 보낼 5줄

쇼핑몰 관리자에서 상품 CSV를 올리고 저장 버튼을 눌렀는데 화면이 멈춘다. 콘솔에는 Cannot read properties of undefined (reading 'map')가 보인다. 이때 에러 로그만 ChatGPT에 붙이면 답이 그럴듯해도 쓸모가 약할 때가 많다. AI는 저장 버튼을 눌렀는지, CSV 업로드 직후인지, 상품 목록 화면인지, 기대 결과가 무엇인지 모른 채 map이 있는 줄만 보고 추측하기 때문이다.

이 글의 상황은 하나로 고정한다. 관리자 상품 업로드 화면에서 CSV 3행을 올리고 저장 버튼을 누르면 undefined.map 오류가 난다. 목표는 전체 리팩터링이 아니다. 오늘 해야 할 일은 저장 버튼이 깨지는 원인을 좁히고, 샘플 CSV 3행이 저장된 뒤 상품 목록에 보이는지 확인하는 것이다.

로그만 붙이면 AI가 저장 버튼 상황을 모른다

Cannot read properties of undefined (reading 'map')는 원인이 하나가 아니다. API 응답이 배열이 아닌 객체일 수 있다. 초기값이 undefined일 수 있다. CSV 파싱 결과가 실패했는데 화면이 그대로 items.map(...)을 호출했을 수도 있다. 저장 버튼을 누른 뒤 서버 응답 구조가 바뀌었는데 프론트가 이전 구조를 기대할 수도 있다.

그래서 AI에게 먼저 줘야 할 정보는 에러 로그가 아니라 상황이다. 아래 5칸을 채우면 추측 범위가 줄어든다.

칸	써야 할 내용
화면	관리자 상품 업로드 화면
행동	CSV를 선택하고 저장 버튼을 눌렀다
기대 결과	CSV 3행이 저장되고 목록에 보여야 한다
실제 결과	`undefined.map` 오류로 화면이 멈춘다
제약	API 구조는 바꾸지 말고 프론트 최소 수정부터 본다

이 5칸이 없으면 AI는 오류 줄 하나를 보고 파일 전체를 흔들 수 있다. 반대로 5칸이 있으면 "초기값 방어", "응답 구조 확인", "CSV 파싱 실패 분기"처럼 작은 후보로 좁힐 수 있다.

ChatGPT에 바로 붙일 프롬프트는 이렇게 쓴다

아래 문장을 그대로 복사해서 프로젝트 상황에 맞게 파일명만 바꾼다.

상황: 쇼핑몰 관리자 상품 업로드 화면에서 CSV 3행을 올린 뒤 저장 버튼을 누르면 오류가 납니다.

기대 결과: 저장 후 상품 목록에 CSV 3행이 보여야 합니다.

실제 결과: 화면이 멈추고 콘솔에 `Cannot read properties of undefined (reading 'map')`가 나옵니다.

관련 파일 후보: app/admin/products/page.tsx, src/modules/products/import.ts

제약: API 응답 구조는 지금 바꾸지 말고, 프론트에서 최소 수정으로 원인을 좁혀 주세요. 전체 리팩터링은 하지 마세요.

요청:
1. 원인 후보를 2개만 제시해 주세요.
2. 가장 가능성 높은 파일과 확인할 줄을 먼저 말해 주세요.
3. 최소 수정안을 코드 조각으로 제시해 주세요.
4. 수정 후 확인할 명령 또는 수동 검증 절차를 적어 주세요.
5. 아직 확인하지 못한 위험을 따로 적어 주세요.

에러 로그:
{여기에 콘솔 로그 붙이기}

샘플 CSV:
sku,product_name,price
A001,테스트 상품 1,12000
A002,테스트 상품 2,15000
A003,테스트 상품 3,18000

여기서 핵심은 "원인 후보를 2개만"과 "전체 리팩터링은 하지 말라"는 제약이다. 이 두 줄이 없으면 AI는 저장 버튼 오류 하나를 고치면서 상태 관리 구조, API 호출 방식, 폴더 구조까지 바꾸려 할 수 있다.

AI 답변에서 먼저 볼 것은 코드보다 원인 후보 순서다

좋은 답변은 바로 긴 코드를 내지 않는다. 먼저 원인 후보를 좁힌다.

예를 들어 이런 답변이면 쓸 만하다.

원인 후보	확인 위치
`products` 초기값이 `undefined`다	`useState` 기본값
API 응답이 `{ items: [...] }`인데 화면은 배열로 본다	저장 후 응답 처리
CSV 파싱 실패 시 빈 배열로 떨어지지 않는다	import 함수의 실패 분기

반대로 "전체 컴포넌트를 다시 작성하겠습니다"로 시작하면 위험하다. 지금 필요한 것은 저장 버튼 오류를 좁히는 일이지 관리자 화면 전체를 새로 만드는 일이 아니다. AI가 큰 수정안을 주면 먼저 "이 변경 없이 원인 확인만 하는 3줄 로그를 제안해 달라"고 되물어야 한다.

최소 수정은 기본값, 응답 구조, 실패 분기 순서로 본다

undefined.map 오류는 대개 세 군데에서 잡힌다.

첫째, 화면 상태의 기본값이다.

const [products, setProducts] = useState<Product[]>([]);

둘째, 응답 구조다. 서버가 { items: [...] }를 주는데 화면이 setProducts(response)처럼 받으면 다음 렌더에서 깨질 수 있다.

const result = await response.json();
const nextProducts = Array.isArray(result.items) ? result.items : [];
setProducts(nextProducts);

셋째, 실패 분기다. CSV 파싱이 실패했을 때 오류 메시지를 보여주지 않고 undefined를 넘기면 화면에서 늦게 터진다.

if (!parsedRows.length) {
  setProducts([]);
  setError("CSV에서 읽은 상품 행이 없습니다.");
  return;
}

이 코드는 예시다. 그대로 붙이라는 뜻이 아니다. AI에게도 "내 파일 기준으로 위 세 위치 중 어디가 맞는지 먼저 확인해 달라"고 시켜야 한다. 그래야 파일 구조와 맞지 않는 코드를 줄일 수 있다.

검증은 샘플 CSV 3행으로 끝낸다

수정 후 검증 기준은 단순해야 한다. 샘플 CSV 3행을 업로드하고 저장 버튼을 누른다. 화면이 멈추지 않고 상품 목록에 3개가 보이면 1차 통과다. 콘솔에 같은 undefined.map 오류가 없어야 한다. 실패한 행이 있으면 오류 파일이나 오류 메시지가 보여야 한다.

Codex CLI 문서는 로컬 프로젝트에서 파일을 읽고 바꾸며 명령을 실행할 수 있다고 설명한다. Codex의 AGENTS.md 문서는 프로젝트 지침에 검증 명령과 제약을 담을 수 있다고 안내한다. OpenAI의 장기 작업 글도 계획, 수정, 도구 실행, 관찰, 실패 수정, 상태 업데이트, 반복의 루프를 강조한다. 이 흐름을 이 상황에 맞추면 검증은 거창하지 않다. 저장 버튼을 다시 누르고, 샘플 3행이 목록에 보이는지 확인하면 된다.

같은 에러가 다시 나면 질문을 바꾼다

한 번에 해결되지 않으면 같은 로그를 다시 붙이지 않는다. 실패 결과를 추가한다.

방금 제안한 수정 뒤에도 같은 오류가 납니다.

바뀐 점:
- products 기본값은 []로 바꿨습니다.
- 저장 후 응답은 `{ items: [...] }` 형태입니다.
- 오류는 저장 직후 목록 렌더링에서 납니다.

이제 API 응답 처리와 목록 렌더링 중 어느 쪽을 먼저 확인해야 하는지 2단계로만 좁혀 주세요.

이렇게 쓰면 AI는 이미 확인한 후보를 반복하지 않는다. 문제 해결형 프롬프트의 가치는 여기서 생긴다. 상황, 시도한 수정, 남은 증상을 누적해서 원인을 좁히는 것이다.

오늘 바로 쓸 체크리스트

저장 버튼에서 undefined.map 오류가 나면 아래 순서만 지킨다.

에러 로그를 붙이기 전에 화면과 행동을 한 문장으로 쓴다.
기대 결과를 숫자로 쓴다. 예: CSV 3행이 목록에 보여야 한다.
관련 파일 후보를 2개만 적는다.
전체 리팩터링 금지, 최소 수정 우선이라고 제약을 건다.
원인 후보는 2개만 달라고 요청한다.
샘플 CSV 3행으로 검증하게 한다.
실패하면 같은 로그가 아니라 "시도한 수정과 남은 증상"을 붙인다.

에러 로그는 출발점이 아니라 증거다. AI에게 가치 있는 지시는 "어떤 화면에서 어떤 행동을 했고, 어떤 결과를 기대했는데, 어디서 멈췄는지"까지 들어간다. 이 상황을 고정하면 ChatGPT 답변은 길어지는 대신 좁아지고, 좁아진 답변이 오늘 고칠 수 있는 답변이 된다.

저장 버튼 누르면 undefined map 에러가 날 때, ChatGPT에 먼저 보낼 5줄