AI를 공부 도구로 쓸 때 생각이 멈추지 않게 하는 법

보조 도구가 실제로 무너지는 지점

생성 도구가 내놓는 코드는 대체로 문법이 맞고 형태가 그럴듯합니다. 그래서 초보자가 검증하기가 특히 어렵습니다. 실패가 눈에 띄는 형태로 오지 않기 때문입니다. 성질로 정리하면 아래와 같은 지점에서 어긋납니다.

내 코드베이스 전체를 보고 있지 않습니다. 지금 붙여 넣은 조각만 보고 답합니다. 그래서 이미 프로젝트 안에 있는 유틸리티 함수를 무시하고 같은 일을 하는 코드를 새로 만들어 줍니다. 팀이 암묵적으로 지키는 규칙, 이 프로젝트에서만 통하는 예외 처리 방식 같은 것도 알지 못합니다. 혼자 하는 학습에서는 잘 안 보이다가, 남의 코드가 섞인 저장소에 들어가는 순간 문제가 됩니다.

없는 것을 있는 것처럼 말할 때가 있습니다. 존재하지 않는 함수 이름이나 옵션을 자신 있는 어투로 제시하는 경우가 있습니다. 어투에는 확신의 정도가 드러나지 않으므로, 맞는 답과 틀린 답이 똑같이 단정적으로 옵니다. 초보 단계에서는 그 차이를 구분할 근거가 없어서 그대로 믿게 됩니다.

버전에 약합니다. 라이브러리나 프레임워크는 계속 바뀝니다. 몇 해 전에 널리 쓰이던 사용법이 지금은 권장되지 않거나 아예 제거된 경우가 있는데, 답변은 예전 방식으로 나오기 쉽습니다. 실행하면 경고가 뜨거나 조용히 다르게 동작합니다. 그래서 답을 받은 뒤 공식 문서에서 그 함수 이름을 한 번 검색해 보는 습관이 필요합니다.

모호함을 지적하지 않고 임의로 채웁니다. 이것이 가장 조용한 실패입니다. 요구사항 자체가 덜 정해진 상태에서 물으면, "이 부분은 정해지지 않았습니다"라고 되묻는 대신 그럴듯한 선택지 하나를 골라 코드를 완성해 줍니다. 결과물은 돌아가지만, 내가 결정하지 않은 규칙이 코드 안에 들어와 있습니다. 나중에 그 규칙이 틀렸다는 것이 드러나도, 왜 그렇게 되어 있는지 설명할 수 있는 사람이 없습니다.

코드만 봐서는 알 수 없는 결정을 대신합니다. 어떤 데이터를 로그에 남겨도 되는지, 이 작업을 서버에서 해야 하는지 클라이언트에서 해야 하는지, 이 호출이 비용을 얼마나 발생시키는지 같은 판단에는 코드 바깥의 맥락이 필요합니다. 도구는 그 맥락을 갖고 있지 않습니다.

붙여 넣기 전에 던지는 네 가지 질문

위 문제들은 대부분 붙여 넣기 직전에 몇 초를 쓰면 걸러집니다. 매번 정교하게 검증할 필요는 없고, 아래 네 줄을 습관처럼 통과시키면 됩니다.

1. 이 코드가 하는 일을 한 문장으로 말할 수 있는가?
   -> 못 하면 아직 내 코드가 아니다.

2. 여기서 쓰인 함수/옵션이 실제로 존재하는가?
   -> 공식 문서에서 이름 하나만 검색해 확인.

3. 실패하면 어떻게 되는가?
   -> 입력이 비었을 때, 네트워크가 끊겼을 때.

4. 내가 정하지 않은 규칙이 들어와 있지 않은가?
   -> 반올림, 정렬 기준, 기본값, 시간대.

특히 첫 번째 질문이 핵심입니다. 설명하지 못한다는 것은 그 코드가 나중에 고장 났을 때 손댈 수 없다는 뜻입니다. 지금 당장은 돌아가니 문제가 안 보이지만, 요구사항이 하나 바뀌는 순간 그 부분에서 멈추게 됩니다. 실제로 해 보면 생각보다 자주 막힙니다.

seen = set()
unique = [x for x in items if not (x in seen or seen.add(x))]

# 한 문장 설명 시도:
# "이미 본 값을 set에 모으면서, 처음 보는 값만 남긴다.
#  순서는 원래 순서를 유지한다."
#
# 설명하다 막힌 곳: seen.add()가 None을 반환해서
# or 뒤쪽이 항상 거짓이 된다는 부분 -> 확인 필요

설명하다 막혔다는 사실 자체가 좋은 신호입니다. 막힌 지점을 다시 물어보면 그때부터는 코드를 받는 것이 아니라 개념을 배우는 대화가 됩니다. 답을 받는 대화와 이해를 만드는 대화는 결과물이 완전히 다릅니다.

묻기 전에 쓰는 5분이 답의 질을 바꿉니다

같은 도구를 써도 결과가 크게 갈리는 이유는 대개 질문 쪽에 있습니다. 막히자마자 화면을 통째로 붙여 넣고 "안 돼요"라고 물으면, 돌아오는 답도 그 수준에 맞춰집니다. 반대로 5분만 정리하고 물으면 답이 훨씬 좁고 정확해집니다.

정리할 것은 세 가지입니다. 기대한 결과, 실제로 나온 결과, 그리고 이미 확인한 것입니다. 세 번째가 답의 질을 가장 크게 바꿉니다. "출력을 찍어 보니 이 시점까지는 값이 정상이었다"는 한 줄이 들어가면, 이미 배제된 원인을 다시 제안받는 일이 사라집니다.

그리고 이 정리 과정 자체가 문제의 절반을 해결하는 경우가 많습니다. 기대 결과와 실제 결과를 나란히 적다 보면 어디서 갈렸는지가 그 자리에서 보이기 때문입니다. 이것은 사람에게 질문할 때와 완전히 같은 원리이고, 그래서 더 나은 질문 만들기에서 다룬 방법이 여기서도 그대로 통합니다.

또 하나, 한 번에 큰 덩어리를 요청하지 않는 편이 좋습니다. "로그인 기능 전체를 만들어 달라"는 요청은 검증할 수 없는 분량의 코드를 돌려줍니다. 검증할 수 없는 코드는 내 프로젝트에 들어와도 내 것이 아닙니다. 한 번에 한 함수, 한 번에 한 문제로 끊으면 매번 이해하고 넘어갈 수 있고, 문제가 생겨도 범위가 좁습니다.

반대로, 안 쓰는 것도 답은 아닙니다

여기까지 읽고 손으로만 짜야겠다고 결론 내리면, 그것도 학습을 느리게 만듭니다. 실제로 시간을 크게 아껴 주는 구간이 분명히 있습니다.

낯선 에러 메시지를 해석할 때가 대표적입니다. 검색어를 뭐라고 쳐야 할지도 모르는 상태에서, 메시지를 통째로 붙여 넣고 "이게 무슨 상황인지"만 물으면 방향이 잡힙니다. 그 뒤의 확인은 직접 하면 됩니다. 에러를 읽는 기본기는 에러 메시지를 처음 읽을 때에 따로 정리해 두었습니다.

이미 아는 것을 다른 언어로 옮길 때도 그렇습니다. 개념을 이미 이해하고 있고 문법만 모르는 상황이라면, 번역에 시간을 쓸 이유가 적습니다. 이때는 받은 결과를 검증할 능력도 이미 있습니다.

이름 후보를 뽑거나 문서 초안을 잡을 때도 무난합니다. 틀려도 손해가 작고, 최종 판단은 내가 하기 때문입니다. 변수 이름 하나를 두고 20분을 쓰는 것보다 후보 다섯 개를 받아 그중 하나를 고르는 편이 낫습니다.

이미 짠 코드를 읽어 달라고 할 때도 쓸모가 있습니다. 내가 쓴 코드를 붙여 넣고 "여기서 예외가 날 수 있는 입력이 뭔지" 물으면, 내가 생각하지 못한 경우를 짚어 주기도 합니다. 이 방향은 코드를 받는 것이 아니라 내 코드에 대한 질문을 받는 것이어서, 사고를 멈추게 만들지 않습니다.

반면 지금 배우고 있는 바로 그 주제는 맡기지 않는 편이 낫습니다. 조건문을 배우는 주에는 조건문을 직접 씁니다. 그 외의 주변 작업은 도구를 써도 됩니다. 이렇게 구분해 두면 "AI를 쓰면 실력이 안 는다"는 막연한 불안 없이도 속도를 낼 수 있습니다.

오늘부터 지킬 다섯 가지

• 받은 코드를 붙여 넣기 전에 하는 일을 한 문장으로 말해 봅니다.
• 처음 보는 함수나 옵션은 공식 문서에서 이름을 한 번 검색합니다.
• 정답 대신 점검 순서를 먼저 요청합니다.
• 받은 코드에서 한 줄을 바꿔 결과를 예측하고 실행해 확인합니다.
• 지금 배우는 주제만큼은 직접 씁니다.

도구를 낀 작업 흐름 전반이 궁금하다면 AI 활용 코딩 학습 경로를, 도구와 함께 디버깅하는 순서는 디버깅 가이드를 참고하시면 됩니다.

대신 생각해 주는 도구로 쓰면 오래 못 갑니다. 내 생각을 더 또렷하게 만드는 거울로 쓰면 오래 갑니다.