AI가 개발 속도를 높여줍니다. 하지만 실력을 떨어뜨리게 두고 싶지는 않습니다

AI 요약

AI를 코딩과 글쓰기에 자주 쓰는 글쓴이는 조사, 코드 계획, 디버깅, 낯선 API 탐색, 테스트 생성, 코드 리뷰에 AI가 유용하다고 말합니다. 동시에 AI가 프로그래밍 실력을 약하게 만들 수도 있다고 봅니다. 문제는 AI가 코드를 작성한다는 사실 자체가 아닙니다. 개발자가 기억하고 추론하며 문제를 붙잡고 정신적 모델을 만드는 과정까지 AI에 넘길 때 실력이 무뎌질 수 있다는 점입니다. 따라서 사용량을 줄이기보다 어떤 일을 맡길지 의식적으로 정해야 합니다.

기계적 수고와 사고 과정

자동 완성, 문서, Stack Overflow, 린터, 프레임워크, 디버거 같은 도구는 반복 작업을 줄여왔습니다. 웹 개발자가 fetch()를 쓰기 전에 TCP를 직접 구현할 필요는 없습니다. AI도 추상화 도구의 하나지만, 기존 도구와 다른 점은 기계적인 작업뿐 아니라 사고 과정까지 대신할 수 있다는 것입니다.

예를 들어 비동기 콜백을 담은 forEach()가 await되지 않는 버그를 직접 추적하면, 오류를 읽고 관련 코드를 살펴 가설을 세우고 틀린 뒤 다시 상태를 확인하는 과정을 거칩니다. 20분이 걸려도 JavaScript 비동기 실행에 관한 이해가 남습니다. 반면 함수를 AI에 붙여넣고 고쳐달라고 하면 몇 초 만에 Promise.all()과 map()을 이용한 코드가 나올 수 있습니다. 속도는 크게 빨라지지만 학습은 거의 일어나지 않을 수 있습니다. 편리함과 학습이 늘 같은 방향을 향하지는 않습니다. 그렇다고 프로그래밍을 일부러 불편하게 만들기보다, 배움에 도움이 되는 수고를 남겨야 합니다.

답을 받기 전에 가설을 세웁니다

버그나 스택 트레이스를 AI에 보내기 전 30초 동안 먼저 원인을 추측해보라고 제안합니다. 가령 “의존성 배열의 참조가 렌더링마다 바뀌어 상태 업데이트가 effect를 다시 실행하는 것 같다”고 가설을 세울 수 있습니다. 예측 없이 AI의 설명을 읽으면 그럴듯하다고 받아들이고 곧 잊기 쉽지만, 먼저 생각해두면 AI의 답을 자신의 정신적 모델과 대조할 수 있습니다.

“이 코드를 고쳐줘” 대신 “무엇이 버그를 일으키는지 설명하고 아직 수정하지 마세요”, “가능성 높은 원인 세 가지와 원인을 가려낼 증거를 알려주세요”, “코드를 바꾸지 않고 어떻게 디버깅할지 순서대로 설명해 주세요”라고 요청합니다. 그러면 AI는 코드를 내놓는 기계가 아니라 디버깅을 돕는 상대가 됩니다.

생성된 코드를 내 것으로 만듭니다

중요한 개념을 AI가 제안했다면 답을 읽은 뒤 창을 닫고 직접 구현해보라고 합니다. 상태 머신 도입, 서비스 분리, 메모이제이션 계층 추가 같은 제안을 다시 구현하면 핵심 개념을 자신의 이해로 옮길 수 있습니다. 복사해서 붙이는 일보다 어렵지만, 그 어려움이 학습에 도움이 됩니다.

글쓴이가 권하는 방식은 먼저 직접 구현하고 AI에 정확성, 가독성, 예외 상황, 불필요한 복잡성을 검토하게 한 뒤 피드백을 받아들일지 스스로 결정하는 것입니다. AI가 쓴 코드도 배포했다면 자신의 코드입니다. 운영 장애가 새벽에 나도 모델이 호출을 받지 않고, 설계를 이해관계자에게 설명하거나 몇 달 뒤 저장소를 유지보수하는 일도 개발자가 맡습니다. 구현의 모든 줄을 동료 코드 리뷰에서 설명할 수 있는지 확인하고, 어렵다면 의존성이 필요한 이유나 검사가 보호하는 불변 조건, 네트워크 요청 두 개가 동시에 실행될 때의 결과를 계속 질문해야 합니다.

능력을 점검하고 부족한 부분을 연습합니다

AI 없이 유틸리티 함수를 작성하거나, console.log와 디버거로 작은 문제를 해결하거나, 모델에게 묻기 전에 종이에 아키텍처를 그리는 짧은 연습도 권합니다. 면접이나 장애 대응, 중요한 시스템 문제에서 AI 없이 코딩하기 어려운 사실을 처음 깨닫지 않도록 자신의 능력을 미리 확인하는 셈입니다.

특정 주제를 반복해서 AI에 묻는다면 그 기록을 연습에 활용할 수 있습니다. 예를 들어 비동기 JavaScript 상태를 여러 번 질문했다면, 정답을 바로 알려주지 말고 이해도를 확인할 난이도별 문제 세 개를 내달라고 요청합니다. 이때 AI는 버팀목이 아니라 개인 교사 역할을 합니다.

글은 이해 수준을 정답 알아보기, 설명을 듣고 이해하기, 기존 해법 수정하기, 문서를 보고 구현하기, 기억만으로 구현하기, 다른 사람에게 가르치기로 나눕니다. AI를 쓰면 앞의 두 단계가 쉬워져 실제로는 4단계나 5단계에 도달했다고 착각할 수 있습니다. 기능 설계를 시작하자마자 AI에 아키텍처를 묻기보다 먼저 상태의 소유 주체, 필요한 경계, 작동하는 가장 단순한 구현을 생각한 뒤 초안을 검토받으라고 합니다. AI는 반복 작업을 줄이고 낯선 영역을 탐색하며 설명과 검토를 돕게 하되, 개발자는 예측하고 기억하고 디버깅하고 설계하고 설명하는 일을 계속 맡아야 합니다.

dev.to 반응

• @marcusykim — AI에 묻기 전에 30초 동안 예측하는 습관은 정말 좋습니다. 이 과정을 건너뛰면 마법처럼 느껴지는 해법만 얻게 됩니다. 고치기 전에 설명을 요청하는 방식도 이해하지 못한 코드를 복사하는 일을 막아줍니다. 생성된 코드가 단순한 임시방편이 아니라, 구현을 찾아보지 않고도 설명할 수 있는 코드인지 확인하는 데 초점을 두겠습니다.
• @docsemantic — 공감합니다. 독학으로 배웠고 AI를 많이 활용해 지난 7개월 동안 제품을 만들었습니다. 가장 많이 가르쳐준 건 AI가 작성한 코드가 아니라, AI가 만든 버그를 직접 디버깅한 경험이었습니다. 한 번은 자동 수정 기능이 ‘수정 2건’이라고 적힌 PR을 열었지만 아무것도 바꾸지 않았습니다. 서로 모순되는 신호 두 개가 모두 적용돼 결과적으로 서로 상쇄됐습니다. AI는 자신 있게 코드를 썼습니다. ‘왜 diff가 비어 있지?’라고 멈춰 생각한 덕분에 알아챘습니다. 이유를 알기 전에 뭔가 잘못됐다고 예측한 그 순간이 첫 번째 요점과 맞닿아 있습니다. AI에 묻기 전에 예측하는 습관을 우연히 실천했는데, 이제는 의도적으로 해보고 싶습니다.
• @hannune — 약 6개월 동안 돌리던 배치 파이프라인이 뚜렷한 오류 없이 레코드를 누락하기 시작했을 때 처음 알아차렸습니다. 디버깅에 AI를 많이 기대다 보니 실행 로그를 찬찬히 읽는 습관이 사라졌다는 걸, 로그를 추적하려고 앉은 뒤에야 깨달았습니다. 한 시간이면 끝났을 일이 세 시간 가까이 걸렸습니다. 구체적인 지식은 그대로 있었지만 주의 깊게 살피는 태도는 사라졌습니다. 기술 유지 능력을 이야기할 때 이 차이를 충분히 다루지 않는 것 같습니다.

원문: dev.to / 번역·요약: Trawling