6개월 만에 포트폴리오 5개를 만든 신입 개발자가 실무 첫날 코드 리뷰에서 아무것도 설명하지 못했습니다.
우리는 지금 역사상 가장 쉽게 코드를 작성하는 시대에 살고 있습니다
ChatGPT에게 물어보면 즉시 코드가 나옵니다. 에러가 나면 스택 오버플로우 대신 Claude에게 물어봅니다. 막히는 부분이 있으면 GitHub Copilot이 자동 완성해줍니다.
놀라운 시대입니다. 하지만 동시에 위험한 시대이기도 합니다.
저는 지난 1년간 200명이 넘는 개발 부트캠프 수강생들을 가르쳤습니다.
그중 상당수가 LLM의 도움을 받아 빠르게 “결과물”을 만들어냈습니다. 포트폴리오는 화려했고, 코드는 깔끔해 보였습니다. 하지만 면접에서, 실무에서, 그들은 무너졌습니다.
왜일까요?
문제는 ‘정보 부족’이 아니라 ‘사고력 상실’입니다
LLM 의존 학습의 가장 큰 함정은 이것입니다:
정보는 넘쳐나는데, 이해는 사라진다.
우리는 더 이상 정보가 부족한 시대에 살지 않습니다. 문제는 정보를 사고로 전환하는 능력이 사라지고 있다는 것입니다.
아래는 제가 실제로 목격한 7가지 치명적 패턴입니다.
1. “이 코드가 왜 동작하는지 모릅니다”
증상
수강생 A는 복잡한 인증 로직을 단 10분 만에 구현했습니다. JWT, Refresh Token, Redis까지 완벽했습니다. 하지만 코드 리뷰에서 이렇게 물었습니다.
“왜 Access Token과 Refresh Token을 나눠서 쓰나요?”
그는 대답하지 못했습니다.
왜 이런 일이 생길까?
LLM은 ‘사고 과정’을 완제품으로 제공하기 때문입니다.
개발의 본질은 이렇습니다:
문제 이해 → 요구사항 정리 → 모델링 → 설계 → 구현하지만 LLM은 이 모든 과정을 건너뛰고 ‘결과’만 줍니다.
그러면 뇌는 스스로 사고할 필요가 없어집니다. 인간의 뇌는 에너지를 아끼려는 본능이 있습니다. LLM이 구조화를 대신해주는 상황이 반복되면, 뇌는 더 이상 구조화 능력을 훈련하지 않습니다.
결과적으로 ‘정보 소비자’는 되지만, ‘문제 해결자’는 되지 못합니다.
2. “이 코드는 다른 상황에서 왜 안 되나요?”
증상
수강생 B는 게시판 CRUD를 완벽하게 만들었습니다. 하지만 댓글 기능을 추가하려 하자 똑같은 패턴이 작동하지 않았습니다.
“왜 게시글에서 되던 코드가 댓글에서는 안 돼요?”
왜 이런 일이 생길까?
LLM은 특정 맥락을 가정하고 답하지만, 초보자는 그 맥락을 읽지 못하기 때문입니다.
개발에는 절대적 정답이 없습니다. 모든 것은 상황에 따라 다릅니다.
- 데이터 구조가 다르면
- 관계가 다르면
- 트랜잭션 범위가 다르면
- 동시성 요구사항이 다르면
답도 달라집니다.
하지만 LLM에 의존하면 ‘패턴 인식’ 대신 ‘문자열 복사’만 하게 됩니다. 코드 조각을 가져다 붙이는 행위는 원리를 이해하는 게 아닙니다.
문맥이 바뀌면 깨지는 이유를 이해하지 못합니다.
3. “에러 메시지를 읽어본 적이 없습니다”
증상
NullPointerException at line 42수강생 C는 이 에러를 보자마자 전체 코드를 LLM에게 붙여넣었습니다. 스택 트레이스는 읽지도 않았습니다.
왜 이런 일이 생길까?
디버깅은 고차원적 사고를 요구하는데, LLM이 이를 대신하면 그 사고 과정이 사라지기 때문입니다.
디버깅의 본질은 이겁니다:
문제를 쪼개고
→ 가설을 만들고
→ 로그를 확인하고
→ 원인을 좁히고
→ 결과를 검증한다이 사이클을 반복하면서 개발자는 빠르게 성장합니다.
하지만 LLM이 바로 “고쳐진 코드”를 제시하면? 이 소중한 학습 기회가 증발합니다.
더 중요한 건 성취감의 부재입니다.
스스로 해결했을 때의 “아하!” 순간이 기억을 강화시키는데, LLM이 대신 해결하면 뇌는 “내가 해결했다”고 느끼지 못합니다.
4. “Spring은 알지만 DI가 뭔지는 모릅니다”
증상
수강생 D는 Spring Boot 프로젝트를 3개나 만들었습니다. 하지만 이렇게 물었을 때:
“Bean이 뭔가요?”
“DI와 IoC의 차이는?”
“왜 @Autowired를 쓰나요?”
대답하지 못했습니다.
왜 이런 일이 생길까?
LLM은 ‘정보 조각’ 단위로 제공하지만, 개발자는 ‘연결 구조’로 배워야 하기 때문입니다.
진짜 실력은 이런 네트워크 구조에서 나옵니다:
Spring Bean
├─ 생명주기
│ └─ 초기화/소멸 콜백
├─ DI (Dependency Injection)
│ ├─ 생성자 주입
│ ├─ setter 주입
│ └─ 필드 주입
├─ IoC Container
│ └─ ApplicationContext
└─ AOP
└─ Proxy 패턴이 모든 개념이 연결되어야 실무가 보입니다.
하지만 LLM은 각 개념을 따로따로 설명해주므로 수평 확장만 되고 수직적 이해가 생기지 않습니다.
결과는? 프레임워크를 ‘사용’하지만 ‘이해’하지는 못하는 개발자가 탄생합니다.
5. “코딩이 너무 쉬워서 공부를 깊게 안 했어요”
증상
수강생 E는 3개월 만에 5개의 프로젝트를 완성했습니다. 하지만 면접에서 떨어졌습니다.
“기술적으로 어려웠던 부분이 뭐였나요?”
“왜 이 기술을 선택했나요?”
“다시 한다면 어떻게 개선하시겠어요?”
모든 질문에 막혔습니다.
왜 이런 일이 생길까?
즉각적인 보상이 뇌의 학습 회로를 장악하기 때문입니다.
LLM으로 코드를 쉽게 얻으면 작은 도파민이 즉시 발생합니다.
이 짧은 보상 사이클이 반복되면:
뇌는 “어려운 길(깊이 있는 학습)”을 점점 더 싫어합니다.
진짜 실력은 이런 과정에서 나옵니다:
- 공식 문서를 직접 읽고
- 내부 동작 방식을 파악하고
- 여러 번 시행착오를 겪고
- 스스로 문제를 해결하면서
하지만 이 과정은 시간이 오래 걸리고 어렵습니다. LLM은 이를 건너뛰게 만듭니다.
결과는?
“빠르게 성장하는 착각”만 남고, “실제 역량”은 성장하지 않습니다.
6. “React 버전이 바뀌니까 아무것도 못 하겠어요”
증상
수강생 F는 React로 Todo 앱, 게시판, SNS 클론까지 만들었습니다. 하지만 회사에서 Vue를 쓴다고 하자 패닉에 빠졌습니다.
“완전히 새로 배워야 하나요?”
왜 이런 일이 생길까?
원리가 아니라 도구 사용법만 습득했기 때문입니다.
진짜 개발자와 도구 의존 개발자의 차이:
| 도구 의존 개발자 | 원리 기반 개발자 |
|---|---|
| React만 할 수 있음 | React → Vue → Svelte 빠른 전환 |
| 버전 업데이트에 막힘 | 변경사항을 빠르게 이해 |
| 프레임워크 없이 무력함 | 순수 JS로도 구현 가능 |
| 면접에서 “사용법” 설명 | 면접에서 “설계 원리” 설명 |
LLM은 특정 기술과 특정 방식을 기반으로 답합니다.
도구에 맞춰 사고가 형성되면, 도구가 바뀔 때 사고 구조도 무너집니다.
진짜 개발 실력의 핵심은:
언어와 프레임워크가 바뀌어도 남는 것
그게 바로 원리입니다.
7. “더 나은 구조를 생각해본 적이 없습니다”
증상
수강생 G는 이커머스 프로젝트를 만들었습니다. 리뷰에서 이렇게 물었습니다:
“주문 처리를 동기로 하셨는데, 비동기로 하면 어떨까요?”
“결제 실패 시 재시도 로직은 어떻게 구현하셨나요?”
“대용량 트래픽을 고려하셨나요?”
답: “LLM이 이렇게 해줘서…”
왜 이런 일이 생길까?
설계는 ‘문제 정의 → 우선순위 → 트레이드오프 판단’이 본질인데, LLM이 이를 대신해버리기 때문입니다.
설계 시 마주하는 선택들:
- 성능 vs 안정성
- 단순성 vs 확장성
- 구현 시간 vs 코드 품질
- 동기 처리 vs 비동기 처리
- 정규화 vs 비정규화
이런 판단은 사고 과정입니다. LLM이 대신해줄 수 있는 영역이 아닙니다.
설계 능력은 반복된 경험과 깊은 사고에서 나옵니다.
LLM이 바로 구조를 제시하면 사고 자체가 일어나지 않습니다.
결과는?
주니어에서 시니어로 성장할 수 없는 개발자가 탄생합니다.
그렇다면 해답은 무엇일까요?
LLM을 버리라는 게 아닙니다
LLM은 강력한 도구입니다. 문제는 사용 방법입니다.
❌ 잘못된 사용법
막힘 → LLM에게 질문 → 코드 복사 → 실행 → 끝✅ 올바른 사용법
문제 정의 (스스로)
↓
해결 시도 (스스로)
↓
막힘 (어디서 막혔는지 명확히 파악)
↓
LLM에게 "방향" 질문
↓
힌트를 바탕으로 다시 시도 (스스로)
↓
구현 (스스로)
↓
LLM으로 리뷰 (개선점 찾기)핵심 원칙 3가지
1. LLM은 답안지가 아니라 힌트북입니다
답안지는 정답을 바로 보여줍니다. 힌트북은 스스로 풀 수 있도록 방향을 안내합니다.
문제를 풀지 않고 답안지만 보면 시험에서 떨어집니다. 힌트를 보고 스스로 푸는 연습을 하면 실력이 늡니다.
LLM을 “완성된 코드를 주는 도구”로 쓰지 말고, “어디를 공부해야 할지 알려주는 나침반”으로 사용하세요.
2. “왜?”를 3번 물어보세요
LLM이 코드를 주면:
- “이 코드가 왜 이렇게 작동하나요?”
- “왜 이 방식을 선택했나요?”
- “왜 다른 방식은 안 되나요?”
답을 얻은 후에도 직접 실험하세요. 변수를 바꿔보고, 구조를 바꿔보고, 망가뜨려보세요.
3. 고통은 성장의 신호입니다
막히면 좋은 겁니다.
에러가 나면 좋은 겁니다.
이해가 안 되면 좋은 겁니다.
그게 바로 뇌가 성장하는 순간입니다.
LLM으로 이 고통을 즉시 제거하면, 성장도 함께 제거됩니다.
마지막으로
저는 최근 두 명의 지원자를 면접했습니다.
지원자 A:
- 포트폴리오 5개
- 모든 프로젝트가 최신 기술 스택
- 코드가 깔끔하고 완성도 높음
- 하지만 “왜”를 물으면 답하지 못함
지원자 B:
- 포트폴리오 2개
- 에러 로그가 담긴 README
- 시행착오가 기록된 기술 블로그
- 모든 선택에 명확한 이유를 설명함
누구를 뽑았을까요?
당연히 B입니다.
결론
LLM 시대에 개발자로 살아남으려면:
LLM은 지식을 제공하지만, 사고를 대신해선 안 됩니다.
개발의 본질은 코드를 작성하는 것이 아닙니다.
문제를 이해하고, 구조화하고, 해결하는 것입니다.
LLM은 당신을 도와줄 수 있습니다.
하지만 대신 생각해줄 수는 없습니다.
사고는 개발자의 몫입니다.
그리고 그것만이 도구가 바뀌어도 남는, 진짜 실력입니다.
이 글이 도움이 되었다면, 지금 당장 LLM을 끄고 에러 메시지를 끝까지 읽어보세요. 그게 바로 성장의 시작입니다.
📧 피드백과 의견은 언제나 환영합니다.
