ChatGPT로 코딩하는 개발자가 2년 후 성장을 멈추는 이유

 

사진: Unsplash 의 Daniil Komov

부트캠프 수강생 A는 3개월 만에 스프링 부트 프로젝트를 완성했습니다.

코드는 깔끔했고, 과제 제출 속도는 누구보다 빨랐습니다.

그런데 면접에서 "이 코드가 왜 이렇게 동작하나요?"라는 질문에 아무 말도 하지 못했습니다.

 

저는 스프링 부트 캠프에서 강의를 하면서 이런 장면을 점점 자주 목격합니다.

코드는 돌아가는데, 본인은 그 코드를 이해하지 못하는 기이한 상황. 이것이 LLM 의존이 만들어낸 새로운 풍경입니다.

이 글을 읽으면 알 수 있는 것

• LLM 의존이 왜 단순한 "커닝"이 아닌 "성장 구조 파괴"인지
• 신경과학 관점에서 당신의 두뇌에 무슨 일이 벌어지는지
• 실무에서 LLM 의존 개발자가 어떻게 무너지는지
• 건강하게 LLM을 활용하는 방법

---

1. 당신의 두뇌는 "쉬운 길"을 선택하도록 설계되어 있다

인간의 뇌는 에너지를 절약하려는 성향이 있습니다.

문제 분석, 풀이 경로 탐색, 디버깅 같은 활동은 뇌에게 상당한 에너지를 요구합니다.

 

LLM이 이 모든 과정을 대신 처리해주면, 뇌는 자연스럽게 학습합니다.

"이 과정보다 LLM에게 맡기는 게 훨씬 효율적이네."

 

신경과학에서는 이를 'pruning(가지치기)'이라고 부릅니다.

자주 사용하는 신경 회로는 강화되고, 사용하지 않는 회로는 제거됩니다.

LLM에게 문제 해결을 위임할 때마다, 당신의 문제 해결 회로는 조금씩 약해지고 있습니다.

핵심 인사이트

현업은 정답이 없는 문제와 매일 싸우는 전장입니다. 학습 과정에서 '정답 제공'에 익숙해진 개발자는 이 전장에서 무방비 상태로 서 있게 됩니다.

---

2. 조각난 지식은 연결되지 않는다

예를 들어, 스프링과 자바 기반 지식은 명확한 계층 구조를 가지고 있습니다.

JVM → Java 언어 → Spring DI → AOP → Bean Lifecycle → Transaction

이 구조를 이해해야 비로소 중급 개발자로 도약할 수 있습니다.

 

그런데 LLM이 제공하는 정보는 대부분 "정답처럼 보이는 조각난 지식"입니다.

 

실제 사례를 보겠습니다.

알고 있는 것	모르는 것
@Transactional 붙이면 트랜잭션 적용됨	왜 프록시 기반으로 동작하는지
@Autowired로 주입하면 됨	순환 참조가 왜 발생하는지
@RestController 붙이면 JSON 반환	HttpMessageConverter가 뭔지

 

조각난 지식은 연결되지 않습니다. 연결되지 않으니 구조가 만들어지지 않습니다.

실무에서 벌어지는 일

"트랜잭션이 안 먹어요" → self-invocation 문제인데 원인을 모름

"빈 주입이 안 돼요" → 컴포넌트 스캔 범위 문제인데 구조를 모름

"API가 느려요" → N+1 문제인데 JPA 동작 원리를 모름

---

3. 판단력은 비교 경험에서 생긴다

좋은 코드와 나쁜 코드. 좋은 패턴과 안티패턴.

이런 것들을 구분하는 판단력은 어디서 올까요?

 

직접 비교해보는 경험에서 옵니다.

 

초보자가 성장하려면 다양한 선택지를 놓고 스스로 비교하고 평가해야 합니다.

하지만 LLM이 "하나의 정답"을 제시하면, 학습자는 이 코드가 왜 좋거나 나쁜지 판단해볼 시간조차 갖지 못합니다.

 

무비판적 복사가 반복되고, 판단력은 성장하지 못합니다.

- 코드스멜을 구분하지 못한다
- 구조가 적절한지 판단하기 어렵다
- 테스트 코드의 품질을 평가할 기준이 없다
- "일단 돌아가기만 하면 된다" 수준에서 벗어나지 못한다

---

4. 감각은 고통에서 태어난다

숙련된 개발자에게는 일종의 직감이 있습니다.

"여기서 버그가 날 것 같은데..."

"이 구조는 확장성 측면에서 문제가 있어."

"이 상황에서는 DB 락 이슈가 생기겠다."

 

이런 감각은 어디서 오는 걸까요?

정답은 고통입니다.

 

직접 문제에 부딪히고, 밤새 디버깅하고, 결국 해결했을 때의 경험이 축적되어 감각이 됩니다.

감각은 "문제-해결의 반복"에서만 생성됩니다.

 

LLM이 원인을 찾아주고, 문제를 진단해주고, 버그를 해결해주면 학습자는 이 고통을 경험할 기회를 잃습니다.

불편한 진실

아무리 많은 코드를 작성해도, 그 과정에서 고통이 없었다면 성장도 없습니다.

---

5. 당신은 개발자인가, 프롬프트 운영자인가

다음 패턴이 익숙하다면 위험 신호입니다.

"이 코드 좀 고쳐줘"
"이 오류 해결해줘"  
"이 기능 어떻게 만들어?"

 

이런 요청이 반복될수록 뇌는 사고를 포기하는 방향으로 최적화됩니다.

 

문제를 마주할 때마다 자동적으로 이런 반응 패턴이 형성됩니다.

"내가 생각할 필요 없어, LLM이 해줄 거야."

 

LLM은 도구입니다. 그런데 주도권이 LLM에게 넘어가면, 당신은 더 이상 개발자가 아닙니다.

스스로 만들고 고민하는 사람이 아니라, LLM이 만들어주는 흐름을 따라가는 운영자가 됩니다.

---

6. 단기 효율 vs 장기 성장의 딜레마

LLM 의존의 가장 교활한 측면은 단기적으로 효율적으로 보인다는 것입니다.

단기 (3~6개월)	장기 (2년 이후)
빠른 코드 작성	구조적 사고 부재
빠른 과제 제출	디버깅 능력 부재
빠른 프로젝트 완성	실전 문제 해결 불가

 

개발 학습의 핵심은 스스로 질문을 만들고, 가설을 세우고, 실험하고, 실패하고, 다시 고치는 "자기 생성 학습" 사이클입니다.

 

LLM 의존은 이 모든 것을 LLM이 생성하게 만듭니다.

실무에서 만나는 벽

분산 트랜잭션, 성능 병목, 동시성 이슈 같은 실전 문제 앞에서 속수무책이 됩니다.
이 문제들은 LLM에게 "해결해줘"라고 할 수 없는 문제들입니다.

---

7. 디버깅: 개발자의 진짜 실력이 드러나는 순간

스프링 부트 실무의 대부분은 디버깅입니다.

- 로그 분석
- 예외 스택 추적  
- 컨텍스트 초기화 문제
- Bean 주입 오류
- 트랜잭션 전파 이슈
- 캐시 일관성 문제
- 동시성과 락 문제

 

디버깅은 단순히 에러 메시지를 해결하는 게 아닙니다.

시스템이 어떻게 돌아가는지 머릿속에 모델링하고, 가능한 원인을 열거하고, 하나씩 제거하며 가설을 좁혀가는 고도의 추론 능력입니다.

 

문제를 만날 때마다 "에러 해결해줘"라고 입력하면, 이 추론 과정이 사라집니다.

'디버깅 사고 회로' 자체가 발달하지 않습니다.

---

그래서 어떻게 해야 하는가

LLM을 완전히 금지하자는 이야기가 아닙니다. 그것은 비현실적이고, 바람직하지도 않습니다.

문제는 사용 시점과 방식입니다.

Rule 1: 먼저 30분은 직접 시도하라

에러가 발생하면 최소 30분은 직접 분석해보세요. 공식 문서를 찾아보고, 스택 트레이스를 읽고, 가설을 세워보세요.

그 과정에서 실패해도 괜찮습니다. 아니, 실패해야 합니다. 그 실패가 당신을 성장시킵니다.

Rule 2: "정답"이 아닌 "이해"를 요청하라

Bad:  "이 에러 해결해줘"
Good: "이 에러가 발생하는 원리를 설명해줘"

Bad:  "이 기능 코드 짜줘"  
Good: "이 두 가지 구현 방식의 차이가 뭐야?"

Bad:  "이 코드 고쳐줘"
Good: "이 코드의 문제점이 뭘까?"

Rule 3: 복사하지 말고 다시 작성하라

LLM의 답변을 그대로 복사하지 마세요. 이해한 후에 자신의 코드로 다시 작성하세요.

이 한 단계가 학습과 복사를 가릅니다.

---

마치며: 고통 없이 성장 없다

LLM 의존이 위험한 이유는 단순히 "커닝"이기 때문이 아닙니다.

학습자의 두뇌가 '생각하는 법'을 배우지 못하고, 문제 해결, 추론, 감각, 설계 능력을 잃어버리기 때문입니다.

 

지금 당장 LLM 없이 코딩하는 것이 느리고 고통스럽게 느껴질 수 있습니다.

하지만 그 고통이 바로 성장의 신호입니다.

 

쉬운 길을 선택할 때마다 당신의 개발자로서의 잠재력이 조금씩 닫혀갑니다.

 

LLM이 당신의 코드를 대신 짜주는 동안, 당신은 무엇을 잃고 있는지 한 번 생각해보세요.