AI 오류 수정 요청법, 고쳐 달라는 말 대신 세 줄을 보내는 순서

3줄 요약

• AI에게 오류를 넘길 때는 '고쳐 주세요'보다 콘솔에 찍힌 오류 문구를 먼저 붙이는 것이 복구의 출발점입니다.
• 오류 문구에 발생 조건과 현재·기대 동작을 함께 적으면 AI가 고칠 범위가 좁혀져 엉뚱한 곳을 건드리는 일이 줄어듭니다.
• 콘솔에 문구가 남지 않는 증상은 발생 화면 캡처와 있는 그대로의 증상 서술로 첫 줄을 대신합니다.

AI 코딩 도구로 랜딩페이지나 이벤트 응모 페이지, 간단한 업무 도구를 직접 만드는 마케팅 실무자에게는 생성보다 복구가 더 어려운 자리입니다. 처음에는 생각보다 쉽게 완성되는 느낌이 들지만, 버튼이 반응하지 않거나 화면이 엉뚱하게 보일 때 '고쳐 주세요'를 반복해서 보내다 보면 멀쩡하던 기능까지 함께 흔들리기 쉽습니다. 긴 촬영본을 숏폼으로 재가공하는 크리에이터도 자동화 설정이나 도구를 손보는 순간에 같은 문제를 만납니다.

AI에게 넘기는 말에 고칠 단서가 거의 없으면 같은 흐름이 반복됩니다. ENLIT은 촬영본에서 쓸 구간을 고를 때도 기준을 먼저 정해 두면 결과가 좁혀진다고 봅니다. 오류 복구도 같은 원리입니다. 무엇이 어떤 조건에서 어떻게 틀렸는지를 말해 주는 순간 AI가 고를 수 있는 선택지가 줄어듭니다.

AI가 코드를 써 준 뒤에도 할 일이 남을까요?

AI가 코드를 써 준 뒤에도 할 일은 남습니다. 코드가 나온 순간을 작업의 끝으로 잡으면 안 되고, 오류를 해결해 그 코드가 실제로 동작하는 순간까지가 한 공정입니다.

막히는 지점은 생성보다 복구에 있습니다. 처음 결과가 그럴듯하게 나오면 쉬워 보이지만, 그다음 단계에서 '고쳐 주세요'만 받은 AI는 어디를 어떻게 바꿀지 추측할 수밖에 없습니다. 추측이 엉뚱한 곳에 닿으면 기능이 하나씩 깨지곤 합니다. 생성이 끝난 결과를 완성본이 아니라 초안으로 다루는 방식은 AI 산출물 점검 순서와 같은 원리입니다.

그래서 복구 단계에는 판단 재료를 함께 넣어 주는 형식이 하나 필요합니다. 재료 없이 고쳐 달라는 말만 반복하면 같은 추측이 매번 새로 만들어집니다. 사람에게는 같은 말이어도 AI에게는 어느 화면을 열어야 하는지, 어떤 동작을 기준으로 삼아야 하는지가 비어 있는 상태입니다. 그래서 고치는 속도는 재료를 얼마나 빨리 붙이느냐에 달려 있습니다.

긴 촬영본을 여러 숏폼으로 나눠 쓰는 작업에서도 만드는 일보다 고치는 일이 작업 시간을 좌우합니다.

오류 문구는 어디에서 어떻게 가져오나요?

오류 문구는 브라우저의 개발자 도구 콘솔 탭에서 가져옵니다. Chrome 기준으로 문제가 난 화면에서 마우스 오른쪽 버튼을 누른 뒤 '검사'를 고르면 개발자 도구가 열리고, 그 안의 콘솔 탭에 나고 있는 오류가 표시됩니다. 도구의 기본 동작은 Chrome 개발자 도구 공식 안내에서 확인할 수 있습니다.

"오류 문구를 주세요"라는 말은 익숙하지만, 그 문구를 어디서 가져오는지 몰라 멈추곤 합니다. 경로는 네 단계로 끝납니다.

• 문제가 난 화면에서 마우스 오른쪽 버튼을 클릭합니다
• 메뉴에서 '검사'를 선택해 개발자 도구를 엽니다
• 콘솔 탭을 열고 오류 항목을 클릭해 확인합니다
• 보이는 오류 문구를 복사해 AI 입력창에 붙여넣습니다 (어려우면 캡처합니다)

네 단계로 끝나는 경로라서 처음 해 보는 분도 같은 자리에서 시작할 수 있습니다. 오류 문구는 요약하지 않고 그대로 옮기는 것이 핵심입니다. 요약하는 순간 AI가 판단에 쓸 단서가 사라지기 때문입니다.

복사한 문구 한 줄이 복구 요청의 첫 재료가 됩니다. 이 한 줄을 어디서 가져오는지 아는 것만으로도 멈추는 자리가 줄어듭니다.

복사할 때는 메시지 앞뒤의 줄 번호나 파일 경로까지 함께 가져오면 AI가 문제가 난 위치를 좁히기 쉽습니다. 경로가 보이지 않는 오류도 있으니, 보이는 만큼 옮기되 임의로 잘라내지 않는 것이 원칙입니다.

AI에게 보낼 세 줄에는 무엇을 적어야 하나요?

오류 세 줄이란 콘솔의 오류 문구, 발생 조건, 현재와 기대 동작을 한 묶음으로 AI에게 보내는 복구 요청입니다. 줄마다 맡은 역할이 달라서 AI가 어디를 봐야 할지 범위를 좁힐 수 있습니다.

줄별로 적을 내용은 다음과 같습니다.

셋째 줄에서 핵심은 두 상태를 한 문장에 나란히 두는 것입니다. 지금 어떻게 되는지와 원래 어떻게 돼야 하는지가 함께 있으면, 고쳐야 할 차이가 드러납니다.

AI에게 이름만 던지지 않고 판단 재료를 붙이는 방식은 기준 문서를 붙이는 순서와 같은 원리입니다.

오류 문구 한 줄보다, 언제 났는지와 원래 어떻게 돼야 하는지를 함께 적는 쪽이 고칠 범위를 좁힙니다.

세 줄의 순서도 중요합니다. 첫째 줄로 무엇이 찍혔는지를 보여 주고, 둘째 줄로 어떤 조건에서 찍혔는지를 좁히고, 셋째 줄로 목표 상태를 정하는 식으로 읽으면 AI가 한 방향으로 생각을 모읍니다. 셋 중 하나가 빠지면 나머지가 아무리 정확해도 고칠 목표가 흐려집니다.

콘솔에 아무 문구도 뜨지 않으면 어떻게 하죠?

콘솔에 아무 문구도 뜨지 않으면 발생한 화면을 캡처해 함께 붙이면 됩니다. 버튼을 눌러도 반응이 없거나 레이아웃이 어긋나 보이는 문제는 콘솔에 오류가 남지 않는 경우가 있습니다. 이때는 캡처가 오류 문구를 대신하는 첫 재료가 됩니다.

캡처는 오류가 나는 순간이 한 장에 담기도록 찍는 것이 좋습니다. 버튼을 누르기 전 화면과 누른 뒤 화면을 함께 보여 주면 AI가 무엇이 바뀌었는지 비교할 수 있습니다.

증상은 꾸미지 않고 그대로 적습니다. '눌러도 아무 반응이 없다'는 설명도 그 자체로 쓸 수 있는 단서입니다. 말로 옮기기 어려운 화면 상태라면 캡처 한 장이 더 정확합니다.

콘솔 문구가 없어도 세 줄의 구조는 같습니다. 첫째 줄 자리에 캡처가 들어가고, 나머지 두 줄은 앞에서 본 것처럼 발생 조건과 현재·기대 동작을 적으면 됩니다.

연동 기능이 얽혀 있다면 공식 문서 주소를 함께 붙이는 것도 도움이 됩니다. AI가 기준으로 삼을 자료가 생기므로 오래된 방식으로 코드를 짜는 일을 줄일 수 있습니다.

콘솔에 남지 않는 오류일수록 캡처와 증상 서술의 무게가 커집니다.

AI에게 맡기기 어려운 일도 있을까요?

맡기기 어려운 일은 분명히 있습니다. 오류가 곧 피해로 이어지는 대규모 운영 시스템, 성능 최적화가 필요한 영역, 도메인 지식이 필요한 복잡한 업무 로직이 여기에 듭니다. 이 방식도 모든 영역에 통하지는 않으므로 맡길 수 있는 일과 없는 일을 먼저 구분해야 합니다.

쉽게 나눠 보면 이렇습니다.

잘 맞는 쪽

• MVP나 프로토타입으로 아이디어를 빠르게 검증하는 일
• 데이터를 등록·조회·수정·삭제하는 반복형 CRUD 앱
• 엑셀 정리 스크립트, 웹 스크래핑, PDF 추출, 보고서 자동 생성 같은 데이터 처리와 자동화
• 외부 API 연동

어려운 쪽

• 오류가 나면 안 되는 대규모 운영 시스템
• 성능 최적화가 필요한 영역
• 다단계 승인 흐름이나 세금 계산처럼 도메인 지식이 필요한 복잡한 업무 로직

마케팅 실무자가 직접 만드는 랜딩페이지나 업무용 도구는 잘 맞는 쪽에 가깝습니다. 다만 이 방식은 도구 안에서 고칠 수 있는 문제의 범위를 좁히는 것이지, 도구 바깥의 문제까지 풀어 주지는 않습니다.

판단이 끼는 일과 절차가 고정된 일을 가르는 방식은 역할 배치를 세우는 순서와 맞닿아 있습니다.

맡기기 어려운 일을 억지로 맡기면 요청문을 아무리 정교하게 써도 결과가 흔들립니다. 그런 자리에서는 세 줄 형식보다 사람이 직접 확인하는 절차를 앞에 두는 편이 안전합니다.

할 수 있는 일과 없는 일을 나누는 데서 AI 코딩의 판단이 시작됩니다.

한눈에 비교

오늘 바로 적용한다면

• 문제가 난 화면에서 개발자 도구 콘솔을 열고 오류 문구를 복사합니다
• 오류 문구는 요약하지 않고 그대로 AI 입력창에 붙입니다
• 언제·어디서·어떻게 났는지 한 문장을 적습니다
• 지금 동작과 원래 동작을 한 문장에 나란히 적습니다
• 콘솔에 문구가 없다면 발생 화면을 캡처해 첫 줄 자리에 붙입니다

자주 묻는 질문

콘솔 오류 문구가 길면 전부 붙여야 하나요?

네, 보이는 문구는 줄여 쓰지 말고 그대로 붙이는 것이 원칙입니다. 요약하는 순간 AI가 판단에 쓸 단서가 사라집니다. 같은 문구가 여러 개라면 가장 먼저 나온 항목부터 붙여 보는 것이 무난한 순서입니다.

개발을 전혀 모르는 마케터도 이 세 줄을 쓸 수 있나요?

네, 세 줄은 개발 지식이 아니라 눈앞에서 관찰한 내용을 옮기는 형식입니다. 콘솔을 여는 경로가 네 단계로 끝나기 때문에 처음 해 보는 분도 같은 자리에서 시작할 수 있습니다. 다만 구조 전체를 자동으로 돌리는 단계에서는 코드 편집기와 터미널을 오가는 작업이 전제로 깔린다는 점을 알아 두셔야 합니다.

AI가 세 줄을 보내도 엉뚱한 곳을 고치면 어떻게 하나요?

엉뚱한 곳을 고쳤다면 세 줄 중 빠진 줄이 있는지부터 확인하는 것이 순서입니다. 셋째 줄의 기대 동작이 모호했다면 원래 어떻게 돼야 하는지를 한 문장 더 덧붙여 다시 요청합니다. 바뀐 범위를 짚어 그 부분만 되돌려 달라고 하는 편이 안전합니다.