"AI 없이 직접 해보라고 하니까 한 줄도 못 짜겠어요."

요즘 개발자 커뮤니티에서 이 말, 꽤 자주 들립니다. 이 고민은 단순한 기분 문제가 아니라 학습 방식의 문제로 이어져요. AI가 코드를 빨리 만들어주는 건 맞는데, 그 속도가 곧 내 실력이 된다고 착각하기 쉬운 거죠.

핵심은 분명합니다. AI를 끊으라는 게 아니라, AI가 틀렸을 때 알아차릴 실력을 남겨야 한다는 겁니다. 그리고 그걸 위해 오늘부터 바꿔볼 수 있는 학습 습관 4가지도 같이 정리해보겠습니다.

AI 없으면 왜 갑자기 막힐까

이 문제가 무서운 이유는 아주 현실적인 장면으로 바로 연결되기 때문이에요. 취업 준비생이 "AI 없이 직접 해보라니까 한 줄도 못 짜겠어요"라고 말합니다. 이 장면이 중요한 이유는 면접, 코드 리뷰, 장애 분석 같은 순간엔 결국 내가 이해한 만큼만 설명할 수 있기 때문이에요.

AI를 켜놓고 작업할 때는 모든 게 잘되는 것처럼 느껴집니다. 막히면 바로 질문하면 되고, 에러도 요약해주고, 코드도 어느 정도 형태를 잡아주니까요. 그런데 노트북을 덮는 순간 설명이 안 된다면, 생산성이 오른 게 아니라 이해를 외주 준 상태일 수 있어요.

💡 Tip: "이 코드를 다시 혼자 설명할 수 있나?"를 중간중간 점검해보세요. AI를 쓰는 것 자체보다, 설명 불가능한 상태로 넘어가는 게 더 위험합니다.

체감 생산성과 실제 학습은 다를 수 있다

AI 사용이 항상 학습에 도움이 되지는 않는다는 사례가 몇 가지 있습니다. 먼저 METR 사례예요. 오픈소스 개발자들에게 실제 개발 태스크를 시켰더니, AI를 사용한 사람들은 스스로 "더 빨리 진척되고 있다"고 느꼈다고 해요. 문제는 실제 결과는 그렇지 않았다는 점입니다. 더 늦었고, 결과도 더 좋지 못했다고 소개돼요.

또 하나는 토론토대 사례입니다. 여기서는 AI 덕분에 과제 수행률 자체는 올라갔어요. 일부 학생은 빠른 피드백을 바탕으로 성장하기도 했고요. 그런데 많은 학생은 다른 방향으로 흘렀습니다. "어차피 AI가 다 풀어주는데 왜 공부해야 하지?"라는 감각이 커지면서 학습 동기를 잃어버린 거예요. 이 두 사례가 같이 말하는 건 단순합니다. 빨리 끝나는 것과 남는 학습은 다르다.

AI는 단기 성과를 올려줄 수 있어요. 하지만 내가 왜 그렇게 풀었는지, 어떤 맥락에서 그 답이 맞는지, 비슷한 문제를 다시 만나면 혼자 풀 수 있는지는 다른 문제입니다.

왜 어려운 과정이 오히려 실력을 만든다고 할까

그다음 질문은 자연스럽게 이어집니다. "대체 왜 이런 현상이 생길까?" 여기서 핵심은 인지과학적인 설명이에요. 여러 사례를 묶어보면 학습은 원래 어느 정도 불편해야 남는다는 결론이 나옵니다.

대표적으로 다시 읽기보다 머릿속에서 꺼내보는 연습이 더 효과적이라고 설명해요. 또 바로 정답을 알려주는 그룹보다, 먼저 머리를 싸매고 고민한 뒤 정답을 받은 그룹이 더 좋은 결과를 냈다는 예시도 나옵니다. 능동적으로 질문을 던진 사람들이 스스로는 덜 배운 것처럼 느껴도 실제 점수는 더 높았다는 이야기까지 이어지고요. 이걸 개발에 그대로 옮기면 의미가 분명해집니다.

바로 답을 받는 건 편하지만, 기억은 불편한 쪽에 남는다는 거예요. 요즘은 검색도 AI로 하고, 에러도 AI한테 물어보고, 문서도 요약해서 받습니다. 여기서 가장 쉽게 빠지는 함정이 "검증을 생략하는 습관"이에요. 답을 받자마자 넘어가 버리면, 그건 문제 해결이지 학습이 아니게 됩니다.

AI는 내가 묻는 범위까지만 답한다

특히 중요한 포인트는 "AI가 모든 걸 아는 것 같지만, 사실은 내가 묻는 범위까지만 답하는 경우가 많다"는 점이에요. 예를 들어 특정 파일 하나의 버그를 물어보면, AI는 그 파일 안에서 가장 가능성 높은 원인을 제시해줄 거예요. 그런데 실제 실무에서는 그 파일을 감싸는 전체 아키텍처, 예전 의사결정, 팀의 운영 방식, 장기 유지보수 위험까지 봐야 할 때가 많습니다.

이 넓은 맥락은 결국 사람이 알고 있어야 질문도 넓어집니다. AI는 질문 도우미가 될 수 있어요. 하지만 이해가 끊기는 지점까지 연결해서 묻는 능력은 여전히 사람 몫입니다. "AI가 다 해주는데 왜 공부해야 하지?"라는 질문에 대한 답도 여기 있어요. 내가 모르는 범위를 넓히는 건 결국 내 몫이기 때문입니다.

오늘부터 바로 써먹을 학습 습관 4가지

추상적인 경고에서 끝나지 않고, 아주 실용적인 루틴 4가지를 제안할 수 있어요.

1. AI 쓰기 전 30분 먼저 삽질하기

문제를 보자마자 바로 AI에게 맡기지 말고, 30분 정도는 공식 문서와 에러를 직접 만나보는 시간을 가져보라는 제안이에요. 이 30분이 중요한 이유는, 내가 어디서 막히는지 알아야 이후에 AI에게도 더 좋은 질문을 던질 수 있기 때문입니다.

2. 답보다 "왜?"를 묻기

"왜 이 구조가 더 좋은가?" "이 방법 말고 더 큰 레벨에서는 어떤 선택지가 있나?" "더 낮은 레벨에서 보면 어떤 단점이 있나?"

이런 질문은 단순 복붙을 이해로 바꿔줍니다. 코드를 받는 것보다, 구조와 trade-off를 묻는 습관이 오래 남아요.

3. 다음날 빈 에디터에서 다시 써보기

이 습관은 정말 강력합니다. 전날 AI와 함께 만든 코드를 다음날 빈 에디터에서 다시 써보는 거예요. 그대로 복붙하는 대신, 주석을 달면서 "내가 왜 이렇게 작성했는지"를 설명해보면 기억에 훨씬 오래 남습니다.

4. 직접 프로젝트를 만들며 문제 기억 쌓기

같은 포맷을 조금씩 틀어서 여러 아이디어를 구현해보는 과정이 중요해요. 결국 실력은 깔끔한 정답을 많이 읽어서가 아니라, 내가 직접 부딪힌 문제의 기억이 쌓이면서 만들어지니까요.

팀과 실무에서는 무엇을 더 조심해야 할까

업계 분위기도 이미 비슷하게 흘러갑니다. AI를 쓰는 개발자는 이미 굉장히 많고, 실무에서 이 흐름은 더 커질 가능성이 높아요. 하지만 동시에 AI가 만든 코드에 대해 불신하는 사람도 적지 않습니다. 이건 이상한 반응이 아니에요.

AI가 만든 결과물은 얼핏 보기엔 그럴듯합니다. 포맷도 예쁘고, 설명도 매끈해요. 그런데 정확성, 안전성, 유지보수성은 따로 검수해야 해요. 이건 코드도, 문서도, 콘텐츠도 마찬가지입니다.

그래서 팀 차원에서는 "AI를 얼마나 쓰느냐"보다 "AI 결과를 어떻게 검수하고 설명 가능하게 만들 것이냐"가 더 중요해집니다.

마치며

결론은 꽤 선명합니다. AI 시대에 살아남는 개발자는 AI가 틀렸을 때 알아차릴 수 있는 개발자다. AI를 안 쓰는 사람이 되라는 말이 아니에요. 오히려 잘 써야 합니다. 다만 더 빨리 쓰는 것보다, 더 깊게 이해하는 쪽으로 습관을 바꿔야 한다는 거예요.

오늘 바로 하나만 바꿔본다면 이걸 추천합니다. 다음 문제를 만나면 AI를 켜기 전에 30분만 먼저 부딪혀 보세요. 그 30분이 생각보다 많은 걸 남길 겁니다. 여러분은 요즘 AI를 "답변 기계"로 쓰고 있나요, 아니면 "질문을 더 잘하게 만드는 도구"로 쓰고 있나요?

자주 묻는 질문 (FAQ)

Q1. AI를 쓰면 무조건 실력이 떨어지나요?

A. 핵심은 "무조건 떨어진다"가 아니라 "어떻게 쓰느냐가 중요하다"에 가깝습니다. 바로 답만 받는 습관, 검증 없이 넘어가는 습관, 설명 가능성을 놓치는 습관이 누적될 때 문제가 커집니다.

Q2. AI 도움을 받으면서도 공부가 남게 하려면 어떻게 해야 하나요?

A. 네 가지를 강조합니다. AI 쓰기 전 30분 먼저 부딪혀보기, 구조와 이유를 묻기, 다음날 빈 에디터에서 다시 써보기, 직접 프로젝트를 만들어 문제 기억을 쌓기입니다.

Q3. 검색이나 문서 요약도 학습을 방해하나요?

A. 정보를 찾는 데 도움을 받는 것 자체는 괜찮습니다. 문제는 찾은 뒤 검증과 내재화 과정이 사라질 때예요. 요약을 읽은 뒤 내 말로 다시 설명해보는 과정이 꼭 필요합니다.

Q4. 면접 준비에도 이 방식이 정말 도움이 되나요?

A. 네. 면접에서는 결국 "왜 그렇게 짰는지", "어떤 선택을 했는지", "다른 방법은 없었는지"를 설명해야 합니다. AI가 생성한 결과를 다시 설명할 수 있을 정도로 소화하는 연습이 특히 중요합니다.

Q5. 팀에서 AI 코딩 도구를 도입할 때 가장 중요한 건 뭔가요?

A. 단순히 속도를 높이는 것보다, 설명 가능성과 검수 루틴을 같이 설계하는 게 중요합니다. AI가 만든 코드를 누가 어떤 기준으로 리뷰할지, 아키텍처 이해를 어떻게 유지할지까지 같이 봐야 합니다.