AI 문제가 아니라 사고의 문제다

DEV Community

You Don't Have an AI Problem You Have a Thinking Problem.

I used to think AI was making me lazy. I was wrong. AI wasn't making me lazy I was using AI as an...

Harsh · 2026-08-10

개요 #

버그는 고쳤는데 왜 고쳐졌는지 설명할 수 없다면, 그건 해결한 걸까 승인한 걸까. Dev.to에 올라온 Harsh의 글은 이 질문에서 출발한다.

글쓴이는 AI가 자신을 게으르게 만든다고 여겼다가 생각을 바꿨다. AI는 게으름의 원인이 아니라 생각하지 않기 위한 핑계였다는 것이다. 한 번 알아채고 나니 같은 패턴이 도처에 보였다. 자기 코드에서도, 리뷰하던 PR에서도, "AI가 이렇게 하면 된다고 했어요"라는 한 줄로 논의를 끝내버리는 슬랙 메시지에서도.

그래서 글쓴이가 던지는 질문은 단순하다. 어려운 문제를 만났을 때 첫 반응이 무엇인가. 생각을 시작하는가, 아니면 AI 창을 여는가.

null이 사라졌는데 개운하지 않았던 날 #

몇 달 전 Node.js 백엔드 API를 만들다 겪은 일이다. 어떤 엔드포인트가 특정 필드를 null로 돌려줬다. 항상은 아니고, 거슬릴 만큼만 자주. 그래서 원인을 짚기가 더 어려웠다.

1년 전이었다면 30~60분을 이렇게 썼을 거라고 글쓴이는 적는다. 엔드포인트와 주변 코드를 다시 읽고, 그 필드가 어디서 채워져야 하는지 확인하고, 요청을 위에서 아래까지 따라가고, 뭔가 시도해보고, 망가뜨리고, 고치고, 결국 알아내는 과정.

이번엔 AI 어시스턴트를 열고 증상을 설명했다. DB에는 데이터가 있는데 응답에서는 필드가 null이라고. 답이 돌아왔다. 체인 어딘가에 await이 빠져서, 의존하는 값이 resolve되기 전에 필드를 읽고 있다는 것. 적용했더니 null이 사라졌다.

성취감이 들었어야 할 순간인데 그렇지 않았다. 왜 그 await이 중요했는지, 정확히 무엇과 무엇이 경쟁하고 있었는지 설명하려니 말이 나오지 않았다. 동작하는 엔드포인트는 손에 들어왔고, 이해가 있어야 할 자리는 비어 있었다.

생각이 선택 사항이 됐다 #

AI가 개발 일상에 들어오기 전, 많은 개발자가 몸으로 익힌 흐름은 이랬다.

문제 → 혼란 → 조사 → 가설 → 실험 → 실패 → 이해 → 해결

요즘 점점 흔해지는 흐름은 이렇다.

문제 → 프롬프트 → 답변 → 복사 → 끝

두 번째가 압도적으로 빠르다. 그래서 끌린다. 하지만 배움이 일어나던 자리는 첫 번째였다. 혼란은 과정의 결함이 아니라 과정 그 자체였고, 헤매는 시간은 낭비가 아니라 학습이 작동하는 방식이었다.

글쓴이는 문제의 핵심을 이렇게 정리한다.

문제는 AI가 답을 준다는 게 아니다. 우리가 우리 질문을 만들어보기도 전에 답을 받아버린다는 것이다.

Photo by MART PRODUCTION on Pexels

생각한다는 건 빈 화면을 노려보는 게 아니다 #

"문제를 좀 생각해봐"라는 말은 막연하게 들리지만, 개발자에게 생각은 배울 수 있는 구체적인 동작들의 묶음이라고 글쓴이는 말한다.

• 문제를 더 작은 조각으로 쪼개기
• 테스트하기 전에 가설을 세우기
• 시스템이 어떻게 동작해야 하는지 먼저 예측하기
• 해법을 제안하기 전에 제약을 파악하기
• 결과만이 아니라 트레이드오프를 따지기
• 디버깅하면서 자기 전제를 의심하기
• "어떻게 고치지?" 이전에 "이건 왜 존재하지?"를 묻기
• 무엇을 만들지 않을지 결정하기

코드를 쓰는 일은 소프트웨어 개발의 작은 조각일 뿐이다. 더 어렵고 값진 부분은 애초에 어떤 코드가 존재해야 하는지 정하는 일이고, 그건 프롬프트 입력창에 나타나지 않는다.

가장 무서운 AI 답변은 맞는 답변이다 #

틀린 답은 오히려 알아채기 쉽다. 망가지고, 조사하게 되고, 고치는 과정에서 뭔가를 배운다.

맞는 답은 신뢰하게 된다. 그리고 신뢰가 생기는 지점에서 사고가 조용히 퇴근한다.

수동적으로 AI를 쓰면 흐름이 이렇게 줄어든다.

문제 → 해결

의식적으로 붙들지 않으면 건너뛰게 되는 건 이 부분이다.

문제 → 왜? → 제약은? → 대안은? → 트레이드오프는? → 해결

맞는 답은 빠진 멘탈 모델을 가려준다. 동작하는 코드와 이해의 공백을 함께 안고 나오게 되고, 그 공백은 석 달 뒤 프로덕션에서 새벽 2시에 드러난다. "왜"가 정말 필요해지는 순간에 그게 없는 것이다.

일부러 '생각세'를 내보기 #

글쓴이는 다른 방식을 시도했다. AI 창을 열기 전에 스스로에게 부과하는 '생각세(thinking tax)'다.

규칙 1 — 웬만큼 복잡한 문제라면 AI를 열기 전에 몇 분간 직접 생각한다. (새벽 2시 장애 대응에는 당연히 해당되지 않는다. 불을 끄는 상황이 아니라 평소 문제에 적용하는 규칙이다.)

규칙 2 — AI에게 뭘 묻기 전에 내 가설을 적어둔다.

규칙 3 — 답이 오면 "이거 맞나?"를 묻지 않는다. 대신 이렇게 묻는다.

"내가 놓친 건 뭐지?"

규칙 4 — 해법 하나가 아니라 대안 세 가지를 요청한다.

규칙 5 — 최종 해법을 내 말로, 소리 내어, 누군가를 가르치듯 설명해본다.

흥미로웠던 건 AI 없이 푼 문제가 줄었다는 게 아니었다. 막상 AI를 열었을 때 질문이 훨씬 날카로워졌다는 점이다. 더 이상 대신 생각해달라고 하지 않고, 내 생각을 검증해달라고 요청하게 됐다.

이게 진짜 변화다. 답변 기계로서의 AI에서 사고 파트너로서의 AI로.

THINK 방법론 #

"좀 더 의식적으로 하자" 같은 다짐은 아무도 지키지 못한다. 그래서 글쓴이는 실험에서 나온 절차를 다섯 글자로 정리했다.

AI에게 묻기 전에 THINK.

• T — Try First. 도움을 청하기 전에 몇 분은 진짜로 붙어본다.
• H — Hypothesize. 틀릴 것 같아도 무슨 일이 벌어지는 중인지 적어본다.
• I — Identify Constraints. 여기서 바꿀 수 있는 것과 없는 것을 구분한다.
• N — Need a Second Opinion. 이제 AI를 부른다.
• K — Know Why. AI 없이 설명할 수 있기 전까지는 답을 받아들이지 않는다.

AI를 피하자는 게 아니다. AI가 멘탈 모델을 건네주기 전에 내 멘탈 모델을 먼저 갖자는 것이다.

차이는 프롬프트 자체에서 드러난다. 이렇게 묻는 대신,

이 버그 좀 고쳐줘 — 필드가 null로 나와.

이렇게 묻게 된다.

의존하는 값이 resolve되기 전에 이 필드를 읽어서 null이 되는 것 같아. 체인 어딘가에 await이 빠졌을 가능성이 있고. 내 추론은 이런데, 뭘 놓쳤을까?

같은 버그다. 프롬프트 반대편에 있는 개발자만 완전히 달라졌다.

수동적 AI vs 사고하는 AI #

AI를 쓰느냐 마느냐가 아니라, 생각을 얼마나 넘겨주느냐의 차이다. 누가 생각하고 있느냐의 문제다.

AI를 잘 쓰는 사람은 프롬프트를 잘 쓰는 사람이 아니다 #

AI 이야기의 상당 부분이 프롬프트 엔지니어링을 더 잘하자는 쪽으로 흐른다. 글쓴이는 과녁이 조금 어긋나 있다고 본다.

AI를 가장 잘 쓰는 사람은 영리한 프롬프트 구조를 아는 사람이 아니라, 애초에 어떤 질문이 물어볼 가치가 있는지 아는 사람이다. 그건 프롬프트 기술이 아니라 프롬프트로 위장한 도메인 지식이다.

도메인 지식이 좋은 질문을 만들고, 좋은 질문이 좋은 결과물을 만든다. 도메인 지식이 없으면 순서가 반대로 흐른다. AI 결과물이 그럴듯해 보이고, 검증 없이 받아들여진다. 검증할 만큼 알지 못하기 때문이다.

Photo by Kaboompics on Pexels

생각을 멈춘 개발자에게 벌어지는 일 #

"AI가 당신을 대체할 것"이라는 겁주기가 아니다. 그보다 느리고 조용하게 진행된다고 글쓴이는 말한다.

1단계 — AI 덕분에 빨라진다. 이건 정말 좋다.

2단계 — 문제를 스스로 정의해보기도 전에 기본값처럼 AI부터 찾게 된다.

3단계 — 대안 탐색을 그만두게 될 수 있다. 첫 답이 통했는데 굳이 왜.

4단계 — 생성된 해법으로 내 생각을 검증하는 게 아니라, 그 해법에 생각을 맡기게 된다.

5단계 — 코드는 여전히 많이 만들어낸다. 다만 그게 왜 존재하는지, 왜 그렇게 짜였는지, 제약이 하나 바뀌면 뭐가 깨지는지 설명하기 어려워질 수 있다.

AI 활용 능력의 문제가 아니다. 의존의 문제다.

돌아가지는 않겠다 #

반AI 선언으로 읽히기 쉬워서 글쓴이는 선을 긋는다. 그런 글이 아니다.

전부 손으로 짜던 시절로 돌아갈 생각은 없다고 그는 적는다. AI는 너무 유용하고, 아닌 척하는 건 그냥 보여주기다. 보일러플레이트, 디버깅, 테스트, 문서화, 리팩터링, 브레인스토밍, 대안 구현 생성, 처음 만져보는 API 탐색에 지금도 계속 쓴다.

바꾼 건 하나뿐이다. 내 문제를 처음으로 생각하는 존재가 AI이길 원하지 않는다는 것. 그건 자기 자신이어야 한다.

미래는 프롬프트 엔지니어링이 아닐지도 모른다 #

업계 논의가 살짝 비껴가 있다고 글쓴이는 본다. 가치 있는 역량 조합은 이게 아니다.

AI + 영리한 프롬프트 100개

이쪽에 가깝다.

도메인 지식 + 비판적 사고 + 문제 분해 + AI + 판단력

AI는 가능한 해법을 대량으로 만들어내는 비용을 극적으로 낮췄다. 답을 뽑아내는 일이 싸질수록, 어떤 답을 왜 골라야 하는지 아는 능력의 값은 반대로 올라간다. 코드 생성이 흔해진 자리에서 비싸지는 건 기술적 판단이다.

남는 것은 판단력 #

원문의 결론은 이렇다. 코드 생성 속도로 AI와 겨루지 마라. 이길 필요가 없는 경쟁이다. 대신 더 나은 질문을 던지는 일에서 어제의 자신과 겨뤄라.

지루한 코드는 AI에게 맡기고, 대안 생성도, 엣지 케이스 탐색도, 내 전제를 흔드는 일도 맡겨라. 다만 개발자를 개발자로 만드는 그 한 가지, 판단력만은 넘기지 마라.

푼 건가, 승인한 건가 #

글쓴이가 요즘 붙들고 있다는 질문으로 원문은 끝난다. AI가 문제를 풀어줬을 때, 나는 정말 그 문제를 푼 걸까. 아니면 해법을 승인한 것뿐일까.

가장 중요한 AI 역량은 프롬프트를 잘 쓰는 게 아니라, 아직 프롬프트를 열지 않을 때를 아는 것일지 모른다. AI 문제가 아니라 사고의 문제라는 것. 그리고 자기 문제도 아직 푸는 중이라고 글쓴이는 덧붙인다.

원문은 독자에게도 같은 질문을 던진다. 코딩 문제에 막혔을 때 첫 수는 무엇인가. (A) 생각하고 디버깅한다 (B) 문서나 검색을 찾는다 (C) AI에게 묻는다 (D) 문제에 따라 다르다.

이 글은 위 출처를 바탕으로 한국 독자를 위해 재작성한 기사입니다. 원문의 사실과 수치에 근거하며, 별도의 견해를 포함하지 않습니다.