5주 동안 866번 커밋했습니다. 이해력은 그 속도를 따라가지 못했습니다

AI 요약

AI를 활용한 뒤 작성자의 GitHub에는 활동이 급증했습니다. 9월 초부터 Linux 데스크톱 펫, 고객용 재고 관리 앱, 글쓰기 작업용 터미널 도구, 걸어 다닐 수 있는 3D 도서관 등을 만들었습니다. 아이디어를 하루 만에 작동하는 시제품으로 만들고, 낯선 API를 익히거나 버그를 추적하는 일도 빨라졌습니다. 5주 동안 866번 커밋했지만, 그중 대부분의 코드는 AI가 작성했습니다.

작성자는 소프트웨어를 만드는 능력보다 자신이 만든 소프트웨어를 설명하는 능력이 더 느리게 늘고 있다는 사실을 깨달았습니다. 프로젝트가 작동하는지 확인하는 데 집중한 나머지, 왜 작동하는지는 충분히 묻지 않았습니다. PostgreSQL을 사용하는 고객용 앱을 운영하면서도 인덱스의 비용을 설명하지 못했고, 해시 테이블 학습 뒤 LeetCode의 입문 문제 Two Sum을 풀려다 막혔습니다.

AI가 없앤 마찰과 남은 학습 격차

코딩 보조 도구가 없던 시절에는 비동기 JavaScript, 데이터베이스 트랜잭션, Linux 권한처럼 모르는 부분이 작업을 막았습니다. 문서를 읽고 오류를 살피며 시행착오를 겪는 동안 문제를 이해하는 정신 모델도 생겼습니다. AI를 쓰면 오류를 붙여 넣고 수정안을 적용해 곧바로 문제를 없앨 수 있습니다. 하지만 오류가 사라져도 지식의 격차는 그대로 남습니다. 작성자는 AI가 작업 속도를 높여 준다는 사실을 실력까지 함께 키워 준다는 뜻으로 받아들인 점이 자신의 실수였다고 말합니다.

수정안을 받기 전에 먼저 예측하기

작성자가 구분하는 작업 방식은 두 가지입니다. 하나는 오류를 AI에 붙여 넣고 제안된 네 줄을 고친 뒤 계속 개발하는 방식입니다. 빠르지만 자신의 추론 과정을 건너뛰기 쉽습니다. 다른 방식은 오류를 재현하고, 원인에 관한 가설을 적은 다음, 검증할 부분을 찾아 코드나 로그를 살피는 것입니다. 한 번에 한 가지를 바꾸고, 필요한 경우 AI에 도움을 구한 뒤 수정이 통했던 이유를 이해합니다. 가능하면 회귀 테스트도 추가합니다.

작성자는 AI에 묻기 전에 원인을 예측해 적습니다. 예를 들어 상태 갱신이 다시 렌더링을 일으키고, 그 과정에서 객체가 새로 만들어져 effect가 반복 실행된다고 가정할 수 있습니다. 또는 오래된 상태를 기준으로 두 클라이언트가 같은 레코드를 수정해 두 번째 쓰기가 첫 번째 변경을 덮어쓸 수 있다고 예상할 수 있습니다. 예측이 틀려도 괜찮습니다. 먼저 가설을 세우면 AI의 답변을 단순한 패치가 아니라 자신의 추론을 확인하는 피드백으로 활용할 수 있습니다.

생성된 코드와 리팩터링을 검토하는 기준

모든 의존성의 구현 세부사항을 알 필요는 없지만, AI가 애플리케이션에 중요한 로직을 추가했다면 어떤 문제를 해결하는지, 왜 이 방식으로 구현했는지, 어떤 가정을 두는지, 실패하면 무엇이 일어나는지 설명할 수 있어야 한다고 말합니다. 코드를 6개월 뒤 유지보수할 엔지니어의 관점에서 설명해 달라고 AI에 요청한 뒤, 실제 코드와 설명을 함께 읽기도 합니다. AI가 만든 코드는 자신감 있게 보이므로, 의심스러운 선택을 놓치지 않도록 코드를 직접 대조해야 합니다.

버그를 고친 뒤에는 사용자가 문제를 겪기 전에 어떤 테스트가 이를 잡았을지 생각합니다. 단위 테스트나 통합 테스트가 적절할 수 있고, 해당 계층에서 현실적으로 시험하기 어려운 실패도 있습니다. 또 “리팩터링해 줘”라고 뭉뚱그려 요청하기 전에 어떤 점이 불편한지 먼저 짚습니다. 예를 들어 한 모듈이 영속성, 검증, UI 상태 관리를 모두 맡고 있다면 책임을 나누려는 이유를 설명하고, 가능한 구조와 각각의 절충점을 요청합니다. AI를 계속 쓰되, 엔지니어링 판단은 먼저 내리려는 접근입니다.

빠른 개발과 기초 학습을 함께 이어가기

작성자는 AI가 익숙하지 않은 기술을 탐색하고, 반복적인 뼈대 코드를 만들며, 프로젝트를 출시하는 데 도움이 된다고 말합니다. 다만 코드 생성이 쉬워져도 인증의 보안 문제, 데이터베이스의 일관성 모델, 네트워크 장애, 예상 밖의 사용자 행동은 사라지지 않습니다. 경험이 적은 개발자도 복잡한 소프트웨어를 빠르게 만들 수 있지만, 그 복잡성을 이해하는 일은 여전히 필요합니다. 익숙한 작업에서는 AI로 속도를 높이고, 낯선 영역에 들어서면 구현과 문서를 읽고 가설을 검증하며 의도적으로 속도를 늦추겠다고 합니다.

실천 계획에는 AI 없이 매일 작은 문제 하나를 푸는 일도 포함됩니다. 문자열의 단어 수를 세거나 목록의 중복을 제거하는 문제를 빈 파일에서 시작해 20분 동안 풉니다. 또 자신의 프로젝트에서 기능 하나를 골라 AI 도움 없이 코드를 읽고 처음부터 끝까지 설명해 볼 예정입니다. 막히는 지점을 다음 학습 과제로 삼습니다. 작성자가 던지는 질문은 AI가 사라진 상황에서도 오늘 출시한 소프트웨어를 디버깅하고, 구조를 설명하고, 안전하게 수정할 수 있느냐는 것입니다.

dev.to 반응

• @technogamerz — 와우 😮
• @danielecangi — 5주 동안 866번 커밋했는데, 마지막 보스로 Two Sum이 나타났네요 😄 2026년 개발의 정수입니다. 농담은 제쳐 두고, 우리가 만들 수 있는 것과 완전히 이해하는 것 사이의 격차는 정말 실재합니다. 좋은 글입니다!
  • @mikachu — 읽어 줘서 고마워요, DaC! 그리고 하하, 마지막 보스라는 말이 정확하네요 😄 해시 테이블 수업을 다 듣고도 Two Sum에 완전히 당했어요. 재도전 목록에 올려뒀습니다. 언젠가 당신 수준에 도달할게요 >:P
• @deanlee — 코드를 작성하는 일은 애초에 문법을 만들어 내는 작업만이 아니었습니다. 시스템 장애가 일으키는 인지적 부담을 엔지니어가 분산해 처리하는 과정이기도 했습니다. 상태 경계, 인덱스 비용, 캐시 무효화를 고민하는 일이 느리게 느껴진 이유는, 실제 서비스에서 대가를 치르기 전에 엣지 케이스의 비용을 정신 모델에 미리 반영하고 있었기 때문입니다. 보조 도구가 그 마찰을 없애면 비용 구조가 뒤집힙니다. 미리 인지적 비용을 들이지 않고 시제품을 빠르게 만들 수 있지만, 디버깅 때 감당해야 할 위험을 그대로 떠안습니다. 장애 상황에서 낯선 생성 코드를 검토하는 일은 처음부터 직접 작성하는 일보다 훨씬 어렵습니다. 운영상의 부담이 쌓이지 않게 하려면 작업 과정에 마찰을 다시 넣는 방법밖에 없습니다.

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