AI로 개발하며 진짜 배우게 되는 것들

배경

dev.to 커뮤니티에 올라온 이 글은 한 개발자가 AI 도구로 프로젝트를 만든 과정을 1인칭으로 돌아봅니다. 질문은 하나입니다. AI가 코드를 쓰고 자료를 찾고 설계안을 내놓는 동안, 사람은 실제로 무엇을 배우는가. 글은 특정 도구의 성능 평가나 효율 수치를 다루지 않고, 사용자 자신에게 초점을 맞춥니다.

제목의 '진짜'라는 단어가 작가의 입장을 보여 줍니다. 생성된 코드의 양보다 작업이 끝난 뒤 머릿속에 무엇이 남았는지가 중요하다는 것입니다. 프로젝트는 빨리 돌아가는데 핵심 설계를 왜 그렇게 했는지 설명하지 못하는 경험은 많은 개발자에게 낯설지 않습니다. 이 글은 그 경험에 대한 솔직한 복기입니다.

심층 분석

AI로 개발하면 왜 배우는 내용이 달라질까요? 전통적인 개발에서는 동작하는 코드를 쓰려면 인터페이스, 자료구조, 오류 처리를 먼저 이해해야 했고, 이해는 구현의 부산물이었습니다. AI를 쓰면 구현과 이해가 분리됩니다. 구현은 모델이 할 수 있지만, 이해는 사람이 의식적으로 채워야 합니다.

대규모 언어모델은 그럴듯하고 완결된 답을 내놓는 데 능하지만, 이해에 드는 비용까지 대신 치러 주지는 않습니다. 출력을 그대로 받아들이고 되묻기와 검증이 없으면 학습은 표면에 머뭅니다. 반대로 모델을 언제든 물어볼 수 있는 동료로 대하면 달라집니다. 왜 이 라이브러리를 골랐는지, 이 로직의 경계 조건은 무엇인지, 다른 방식이면 어떤 대가가 따르는지 물으면 대화마다 작은 페어 프로그래밍이 됩니다. 차이는 질문하는 방식, 그리고 결과를 직접 읽고 실행하고 고치는 태도에 있습니다.

디버깅은 이해의 빈틈이 가장 선명하게 드러나는 순간입니다. 모델이 준 방안이 오류를 내면 개발자는 오류 메시지를 따라 원리까지 거슬러 올라가야 합니다. 글은 이 단계를 가장 단단한 학습의 순간으로 봅니다. 따라서 효과적인 사용법은 과제를 통째로 넘기는 것이 아니라, 모델을 사고 곁에 두고 판단을 증폭시키는 것입니다.

산업 영향

개인 개발자, 특히 입문자에게는 학습 경로가 바뀝니다. 반복 코딩으로 쌓던 감각은 압축될 수 있고, 대신 코드를 읽고 검토하며 모델의 환각을 알아채는 능력이 더 중요해집니다. 이런 능력은 의식적으로 훈련해야 합니다.

팀과 기술 리더에게는 산출물을 어떻게 평가할지가 과제입니다. 납품 속도만 보면 유지보수 위험이 가려집니다. 아무도 제대로 이해하지 못한 코드는 반년 뒤 고치기 어려운 짐이 될 수 있습니다. 그래서 코드 리뷰, 테스트 커버리지, 문서화가 예전보다 중요하며, 이들은 모델의 출력을 팀의 공유 지식으로 바꾸는 통로입니다.

도구 업체의 경쟁 축도 조용히 이동합니다. 생성 능력 겨루기에서 생성된 내용을 이해하도록 돕는 쪽으로 옮겨 갑니다. 더 나은 설명, 추적 가능한 변경 이력, 더 분명한 차이 표시가 그 예입니다. 교육 기관 역시 질문, 검증, 리뷰를 문법과 같은 비중의 기본기로 가르쳐야 합니다.

전망

몇 가지 신호를 눈여겨볼 만합니다. 첫째, 이런 경험담이 늘어나며 '도구를 잘 쓰는 법'에서 '쓰면서 계속 성장하는 법'으로 무게가 옮겨 갈 것입니다. 업계가 신기함의 단계를 지나 성찰의 단계로 들어선다는 뜻입니다. 둘째, 팀 차원의 사용 규칙이 더 분명해질 수 있습니다. 제출자가 모델이 생성한 코드를 모두 설명할 수 있어야 한다거나, 리뷰에서 경계 조건과 의존성 선택을 따로 확인하는 식입니다.

셋째, 모델이 좋아질수록 사람과 모델의 역할 분담은 계속 다시 그려지겠지만, 요구사항을 정의하고 대안 사이에서 선택하고 결과에 책임지는 일은 아마 사람의 몫으로 남을 것입니다.

AI의 도움으로 작업을 끝낸 개발자는 무엇을 해야 할까요? 범위가 분명한 작은 과제부터 시작하고, 끝난 뒤 세 가지에 답해 보세요. 왜 이 방안을 받아들였는가, 어떤 경우에 실패하는가, 다음에는 혼자 할 수 있는가. 셋 다 답할 수 있으면 협업이 배움을 준 것이고, 답이 비면 돌아가 메워야 합니다. 도구는 계속 바뀌지만, 이해력은 개발자가 끝까지 가져갈 수 있는 자산입니다.