자동 조종 대신 학습 선택: AI 코딩 시대에 성장하는 개발자의 일하기
AI 코딩 도구가 코드를 “대신” 써주는 시대입니다. 프롬프트 한 줄에 함수가 뚝딱, 심지어 전체 앱 골격까지 만들어 줍니다. 그런데 어느 순간 이런 생각이 들지 않나요?
“나는 점점 덜 배우고 있는 건 아닐까?”
이 글은 AI 코딩 도구를 자동 조종(autopilot) 으로 쓰는 대신, 학습을 가속하는 엔진으로 쓰는 방법에 대한 이야기입니다.
언제 AI에게 맡기고, 언제 직접 손으로 구현해야 하는지, 그리고 실전에서 써먹을 수 있는 구체적인 워크플로까지 정리해 보겠습니다.
AI 코딩 도구, 쓰면 쓸수록 성장할 수도 퇴화할 수도 있다
AI 코딩 도구는 기본적으로 “개발자 생산성 증폭기”입니다. 반복적인 코드, 보일러플레이트, 테스트 코드, 설정 작업을 대신해 줘서 개발자가 더 중요한 문제에 집중하게 돕습니다.12
하지만 이건 어디까지나 “잘 쓸 때” 얘기입니다.
AI 도구를 이렇게 쓰기 시작하면 바로 함정에 빠집니다.
코드를 제대로 읽지도 않고 그대로 붙여넣기
왜 돌아가는지 모르는 상태로 PR 만들기
디버깅할 때마다 다시 AI에게 “고쳐줘”만 반복하기
이렇게 되면 당장은 편한데, 시간이 지날수록 문제를 스스로 모델링하고 설계하고 디버깅하는 능력이 급격히 떨어집니다. 한마디로 “자동 조종 모드”가 켜진 상태죠.
중요한 사실 하나만 기억하면 좋습니다.
AI는 “곱하기” 도구지 “대체” 도구가 아닙니다. 0에 100을 곱해도 여전히 0입니다.1
기본 실력이 없는 상태에서 AI에 기대면, 일이 빨라지는 게 아니라 실수를 빨리 양산 하는 셈입니다.
따라서 질문은 이렇게 바뀌어야 합니다.
“AI 도구를 쓰면서도, 어떻게 내 개발 실력을 더 빨리 키울 수 있을까?”
자동 조종을 끄는 가장 현실적인 방법: “AI = 똑똑한 인턴”으로 보기
AI를 제대로 쓰는 개발자들은 공통적으로 한 가지 마인드셋을 갖고 있습니다.
AI를 ‘선배 시니어’가 아니라, “엄청 빠르지만 맥락이 부족한 주니어 인턴”이라고 보는 관점입니다.1
이렇게 생각하면 자연스럽게 다음과 같은 행동들이 따라옵니다.
AI가 짠 코드는,
“와 완벽하다!”가 아니라
“인턴이 초안을 빨리 만들어줬네, 이제 내가 책임지고 리뷰해야지.”가 됩니다.
그래서 다음 두 가지 원칙이 생깁니다.
첫째, AI가 만든 코드는 반드시 내가 끝까지 이해한다.
둘째, 내가 PR 리뷰하듯 AI 코드를 리뷰하고, 필요하면 다시 짜본다.
특히 기억해야 할 함정이 하나 있습니다.
코드를 쓰는 것보다 읽는 게 훨씬 어렵다는 점입니다.1
내가 직접 코드를 짤 땐 머릿속에 로직이 쌓이지만, AI가 한 번에 50줄을 던져 주면 그 맥락을 따라가기가 쉽지 않습니다. 대충 보기엔 맞는 것 같고, 컴파일도 되니 그냥 넘어가죠. 그리고 몇 주 뒤 버그가 터졌을 때, 이 코드가 왜 이렇게 생겼는지 기억이 안 납니다.
이걸 막으려면 의도적으로 이런 과정을 거쳐야 합니다.
AI가 준 코드를 한 줄씩 따라가며 직접 트레이스한다.
이해 안 되는 부분은 “이 코드 라인별로 설명해줘”라고 AI에게 설명을 요청한다.1
그래도 꺼림칙하면, 내가 그 로직을 다시 타이핑해서 재구현해 본다.
이것만 꾸준히 해도 “자동 조종 모드”에서 크게 벗어나게 됩니다.
학습을 위한 AI 활용 워크플로: 생성하고, 버리고, 다시 만든다
이제 조금 더 구체적으로, “어떻게 AI를 쓰면서도 계속 배우는지”를 단계별 워크플로로 정리해보겠습니다.
핵심은 이겁니다.
AI를 “지름길”이 아니라 “연습장”으로 쓴다.
1단계: 먼저 구조를 스스로 설계한다 (AI는 참견 금지)
코드 치기 전에, AI부터 여는 습관을 의도적으로 끊어야 합니다.
우선 종이, 노트, 화이트보드, 노션 어느 것이든 상관없으니 직접 다음을 설계해 봅니다.
이 기능이 해결하려는 문제 정의
입력과 출력(데이터 구조, 타입, 예외 상황)
필요한 모듈/클래스/함수 구조
외부 시스템(데이터베이스, API 등)과의 인터페이스
이 과정을 온전히 내 힘으로 한 번 해보는 게 중요합니다.
AI가 “아키텍트” 역할을 못 하는 이유도 여기에 있습니다. 세부 구현은 잘하지만, 전체 시스템 설계는 여전히 인간의 몫입니다.12
설계 초안을 만든 다음에야 AI를 부르는 거죠.
“내가 이렇게 설계했는데, 빠진 부분이나 리스크가 있을까?”
이때 AI는 리뷰어이지, 설계자 역할이 아닙니다.
2단계: AI에게 초안을 맡기되, 테스트부터 정의한다
AI 코드의 가장 큰 문제는 “그럴듯하지만 틀린 코드”를 만들어낸다는 점입니다. LLM은 “진실”보다 “그럴듯함”을 우선해서 예측하기 때문입니다.13
이를 막는 가장 실용적인 방법이 테스트 우선 접근(TDD 스타일)입니다.
먼저 AI에게 “이 기능이 어떤 상황에서 어떻게 동작해야 하는지”를 설명합니다.
“이 요구사항을 만족하는 단위 테스트를 작성해줘”라고 요청합니다.1
생성된 테스트 케이스가 실제로 엣지 케이스까지 잘 커버하는지 내가 검토합니다.
그다음에야 “이 테스트를 통과하는 함수/클래스를 작성해줘”라고 구현을 요청합니다.
이렇게 하면 “코드가 맞는지 모르겠는 상태”가 아니라
“테스트가 정의한 기준에 맞춰 코드를 강제로 튜닝하는 상태”가 됩니다.
3단계: 자주 버리고, 자주 다시 만든다
AI가 준 코드가 마음에 안 들 때, 대다수는 이렇게 합니다.
“이 부분 살짝 고쳐줘”, “이것만 개선해줘”
이것도 괜찮지만, 학습 관점에서 더 좋은 방법이 있습니다.
전체 함수를 과감히 지우고,
방금 이해한 로직을 기준으로 내 손으로 다시 써보기
혹은 이렇게도 할 수 있습니다.
“이 함수의 핵심 로직을 내가 직접 짜볼 테니, 내가 작성한 코드에서 버그나 비효율을 리뷰해줘”
자꾸 코드를 버리고 다시 시작하는 이 과정에서, 문제에 대한 이해도가 훨씬 깊어집니다.
머릿속에 “문제의 구조”가 박히기 시작하죠.
실무에서도 이 습관이 매우 큰 차이를 만듭니다. 덕지덕지 붙인 코드보다, 몇 번을 버리고 다시 쓴 코드가 결국 유지보수하기 좋고, PR도 깔끔해집니다.
4단계: 커밋과 PR은 “정리된 사고”를 담는 그릇으로 쓴다
AI를 열심히 쓰다 보면 커밋 로그가 이런 식으로 쌓이기 쉽습니다.
“fix”
“another fix”
“temp commit”
“ai suggestion apply”
이건 나중에 과거를 추적하기도 어렵고, 팀원에게도 불친절합니다.
AI 도움을 받더라도, 다음은 반드시 사람이 책임지고 해야 합니다.
기능 단위로 코드를 정리해서 작은 커밋으로 쪼개기
각 커밋 메시지에 “무엇을, 왜” 했는지 명확하게 적기
PR 설명란에 변경 이유, 구현 방식, 고려한 대안 등을 직접 작성하기
이 과정 자체가 한 번 더 머릿속을 정리하는 학습 루프입니다.
AI가 코드를 많이 썼더라도, PR 설명을 내가 직접 쓰기 시작하면 “아, 이 기능이 이런 제약 때문에 이런 구조가 된 거였지” 하는 이해가 단단해집니다.
“설명은 AI가 쓰게 하면 되지 않나?” 문서만큼은 직접 써야 하는 이유
많은 팀이 이런 유혹을 받습니다.
“기능 설명서, 기술 문서, README도 AI에게 시키면 되겠다.”
물론 초안 정도는 AI에게 맡길 수 있습니다. 하지만 최종 문서를 그대로 쓰는 건 위험합니다.
문서를 직접 쓰는 행위는 단순한 기록이 아니라, 문제를 언어로 재구성하는 과정이기 때문입니다.
문서를 스스로 쓰면 다음이 강제됩니다.
이 시스템이 정확히 어떤 문제를 해결하는지 다시 정의하게 되고
경계 조건, 실패 케이스, 성능 이슈를 다시 떠올리게 되며
“이제 처음 온 팀원이 이 문서를 읽고 이해할 수 있을까?”를 고민하게 됩니다.
이건 곧 아키텍트 관점의 훈련입니다.
AI 코드 도우미가 아무리 발전해도, “우리 팀의 시스템이 왜 이렇게 구성됐는지” 설명하는 역할은 결국 사람이 맡게 됩니다. 실제로 기업들은 개발자에게 AI 사용 능력뿐 아니라, 여전히 설계와 커뮤니케이션 능력을 강하게 요구합니다.45
그래서 추천하는 패턴은 이렇습니다.
문서 초안을 내가 직접 쓴다.
필요하면 AI에게 “이 문장을 더 명확하게 다듬어줘”, “구조를 나눠줘” 정도만 맡긴다.
내용의 사실 관계와 논리 구조는 스스로 책임진다.
문서를 직접 쓰는 개발자일수록, 아키텍트·리드 포지션으로 성장하기가 훨씬 쉽습니다.
AI 도구를 “학습 모드”로 쓰기 위한 실전 가이드라인
지금까지의 내용을 바탕으로, 실제로 따라 할 수 있는 실전 체크리스트를 정리해 보겠습니다.
AI 코딩 도구를 켤 때마다, 아래 질문을 스스로에게 던져 보세요.
지금 이 작업의 목표를 내가 명확히 말할 수 있는가?
목표를 말로 못 풀면, AI도 정확한 코드를 못 만듭니다. 우선 문제를 자연어로 정리한 뒤 AI를 부릅니다.AI에게 “무엇을”이 아니라 “왜”를 물어보고 있는가?
“이 기능 코드 써줘”보다
“이 문제를 해결하려면 어떤 접근이 좋고, 트레이드오프는 뭐야?”처럼
설계·이유·비교를 요청하면 학습 효과가 훨씬 큽니다.1생성된 코드를 완전히 이해했는가, 아니면 단지 ‘돌아가니까’ 쓰고 있는가?
이해가 안 되는 줄이 하나라도 있다면,AI에게 설명을 요구하거나
스스로 작은 예제로 재현해 보거나
아예 내 손으로 다시 구현해 보는 편이 낫습니다.
테스트를 먼저 정의했는가?
최소한 “이 기능이 실패해야 할 케이스” 몇 개는 머릿속에 떠올린 뒤, 테스트 코드로 옮겨 보세요. AI에게 “이 엣지 케이스들도 포함해서 테스트를 확장해줘”라고 할 수도 있습니다.1커밋·PR·문서는 내가 썼는가?
기록을 남기는 순간만큼은 자동 조종을 끄고, 내 언어로 설명해 보세요. 이게 결국 “내가 진짜 이해했는지”를 검증하는 리트머스 시험지입니다.
마무리: 자동 조종을 끄는 개발자가 결국 더 빨리 간다
AI 코딩 도구는 이미 개발 현장의 기본 장비가 되었습니다. 이제 중요한 건 “쓸까, 말까”가 아니라, “어떻게 써야 내가 더 성장할까”입니다.
핵심을 정리하면 이렇습니다.
AI는 나를 대신해주는 “자동 조종 장치”가 아니라,
내 실력을 증폭하는 “학습 가속기”여야 한다.설계, 테스트 정의, 코드 리뷰, 문서 작성은 여전히 사람의 핵심 역량이며,
AI는 이 과정에서 설명자·리뷰어·속도 향상 도구로 활용하는 게 좋다.코드를 자주 버리고, 다시 만들고, 직접 설명하는 습관이
장기적으로 “문제 해결 능력”과 “시스템 설계 능력”을 키운다.
AI에게 타이핑 속도는 맡기되,
이해하고 결정하고 책임지는 일은 절대 맡기지 마세요.
자동 조종 대신 “학습을 선택하는 개발자”가 결국 가장 멀리, 가장 빠르게 가게 됩니다.
참고
1How to Not Be Overwhelmed by AI – A Developer’s Guide to Using AI Tools Effectively
2What is AI Code Generation? - AI Coding Explained - AWS
3How AI coding agents work—and what to remember if you use them
4How AI Coding Assistants Are Changing What Developers Need to Know