AI 코딩 시대, 자유로워진 게 아니라 확인할 곳이 바뀐 것이다

AI 코딩 도구를 쓰면 처음에는 개발이 훨씬 자유로워진 것처럼 느껴진다. 코드를 한 줄씩 다 쓰지 않아도 된다. “로그인 기능 만들어줘”, “이 버그 고쳐줘”, “테스트 추가해줘”라고 말하면 도구가 초안을 만든다. 예전보다 손이 덜 간다.

그런데 여기서 착각하기 쉽다.

자유로워진 것은 “손으로 치는 양”이지, “확인해야 할 책임”이 아니다. 오히려 확인해야 할 곳은 더 중요해진다. AI가 만든 코드는 빠르게 늘어나지만, 그 코드가 진짜 맞는지는 여전히 실행 결과로만 알 수 있기 때문이다.

예전에는 손끝에 통제가 있었다

예전 개발자는 많은 것을 직접 챙겼다. 파일을 만들고, 함수를 나누고, 코드를 한 줄씩 쓰고, 빌드 명령을 입력하고, 배포 절차를 따라갔다. 그래서 “내가 통제하고 있다”는 느낌이 강했다.

하지만 그 통제감이 항상 실제 안전을 뜻하지는 않았다. 코드를 직접 썼어도 버그는 생겼다. 명령어를 정확히 입력했어도 배포 환경에서 깨질 수 있었다. 내 컴퓨터에서는 잘 됐는데 다른 환경에서는 안 되는 일도 흔했다.

소프트웨어에서 진짜 확인은 늘 실행 쪽에 있었다. 말이 맞는지, 설계가 맞는지, 코드가 맞는지는 결국 돌려봐야 안다.

이 생각은 새롭지 않다. 2001년 애자일 선언은 “포괄적인 문서보다 작동하는 소프트웨어”를 더 가치 있게 본다고 말했다. 애자일 원칙도 “작동하는 소프트웨어가 진척의 주된 척도”라고 말한다. 말이나 계획보다 실제로 돌아가는 것이 중요하다는 뜻이다.

도구가 좋아질수록 손으로 하는 일은 줄어든다

소프트웨어 역사를 보면 이런 변화가 반복됐다.

예전에는 메모리를 사람이 직접 관리했다. 지금은 많은 언어가 자동으로 관리한다. 예전에는 서버를 직접 설치하고 설정했다. 지금은 클라우드 콘솔과 인프라 코드로 만든다. 예전에는 배포 명령을 사람이 직접 쳤다. 지금은 CI/CD가 대신 돌린다.

이때마다 사람의 손은 덜 바빠졌다. 하지만 통제가 사라진 것은 아니었다. 위치가 바뀌었다.

메모리를 직접 해제하지 않아도 성능 문제는 확인해야 한다. 클라우드를 써도 권한, 비용, 장애는 확인해야 한다. 자동 배포를 해도 테스트가 부실하면 버그가 그대로 나간다.

AI 코딩도 같은 흐름 위에 있다. AI가 코드를 써주면 구현 속도는 빨라진다. 대신 더 중요한 질문이 앞으로 나온다.

“무엇이 되면 끝인가?”

“어떤 테스트로 확인할 것인가?”

“실제로 사용자가 원하는 행동이 나오는가?”

예를 들어 로그인 기능을 만든다고 해보자

AI에게 “로그인 기능 만들어줘”라고 시켰다. 코드가 생겼다. 화면도 뜬다. 아이디와 비밀번호를 넣으면 로그인되는 것처럼 보인다.

여기서 끝내면 위험하다.

없는 계정으로 로그인하면 막히는가? 비밀번호가 틀리면 실패하는가? 로그인하지 않은 사용자가 보호된 페이지에 들어갈 수 없는가? 세션이 만료되면 다시 로그인하게 되는가? 에러 메시지는 사용자에게 필요한 만큼만 보여주는가? 로그에는 민감한 정보가 남지 않는가?

이 질문들은 “코드를 직접 썼는가”와 별개다. 사람이 썼든 AI가 썼든 똑같이 확인해야 한다. 오히려 AI가 빠르게 만든 코드일수록 이런 확인 목록이 더 중요해진다. 빠르게 만든 만큼 빠르게 틀릴 수도 있기 때문이다.

CI는 이미 같은 교훈을 줬다

연속 통합, 즉 CI도 같은 문제를 다룬다. Martin Fowler는 CI를 각 개발자가 변경을 자주 합치고, 그 통합을 자동 빌드와 테스트로 검증하는 개발 방식이라고 설명한다. 핵심은 “내 컴퓨터에서는 됐다”에서 멈추지 않는 것이다.

Fowler는 변경을 mainline에 push한 뒤에도 일이 끝난 게 아니라고 설명한다. CI 서버가 다시 체크아웃하고 빌드하고 테스트한다. 로컬에서 됐어도 CI에서 실패할 수 있기 때문이다.

이건 AI 코딩 시대에도 그대로 적용된다. AI가 코드를 만들었다고 끝이 아니다. 로컬에서 테스트하고, CI에서 확인하고, 실제 동작을 봐야 한다. 통제의 중심은 “누가 코드를 썼나”가 아니라 “어떤 피드백 루프가 그 코드를 검증하나”로 이동한다.

AI 도구 문서도 같은 방향을 말한다

AI 코딩 도구의 공식 문서도 비슷한 말을 한다.

Anthropic의 Claude Code 문서는 테스트 작업 흐름에서 “새 테스트를 실행하고 실패를 고치라”고 안내한다. 리팩터링을 할 때도 변경 후 테스트를 돌려 확인하라고 한다. AI에게 코드를 맡기더라도 테스트와 검증은 작업의 일부라는 뜻이다.

OpenAI Codex의 베스트 프랙티스 문서도 “변경을 시키는 데서 멈추지 말고, 필요한 테스트를 만들고, 관련 검사를 실행하고, 결과를 확인하고, 리뷰하라”고 말한다. 프롬프트에는 “완료 조건”을 넣으라고도 한다. 예를 들면 “테스트가 통과한다”, “버그가 재현되지 않는다”, “동작이 바뀐다” 같은 조건이다.

즉 AI 시대의 좋은 지시는 “이거 만들어줘”에서 끝나지 않는다.

좋은 지시는 이렇게 바뀐다.

이 기능을 만들어줘. 완료 조건은 기존 테스트 통과, 새 테스트 추가, 로그인 실패 케이스 확인, 보호된 페이지 접근 차단 확인이야.

이렇게 말하면 통제는 줄어드는 것이 아니라 더 분명해진다.

개발자의 역할은 줄어드는 게 아니라 바뀐다

AI가 코드를 쓴다고 해서 개발자의 역할이 사라지는 것은 아니다. 역할이 바뀐다.

예전에는 “내가 얼마나 정확히 구현하는가”가 큰 비중을 차지했다. 지금도 중요하지만, 앞으로는 “무엇이 맞는 결과인지 정의하는 능력”이 더 중요해진다.

개발자는 다음을 더 잘해야 한다.

• 요구사항을 모호하지 않게 말하기
• 완료 조건을 테스트 가능한 문장으로 바꾸기
• AI가 만든 코드를 기존 구조와 비교하기
• 실패 케이스와 예외 상황을 먼저 떠올리기
• 테스트, 로그, 화면, 데이터로 실제 동작 확인하기
• 리뷰에서 위험한 부분을 찾아내기

이 능력들은 손코딩보다 덜 멋져 보일 수 있다. 하지만 실제 제품을 안전하게 만드는 힘은 여기에 있다.

자유는 대충 해도 된다는 뜻이 아니다

AI 코딩 도구는 분명 개발자를 자유롭게 만든다. 반복적인 코드를 덜 쓰게 해준다. 낯선 코드베이스를 더 빨리 읽게 해준다. 테스트 초안을 만들고, 리팩터링 방향을 제안하고, 문서도 정리해준다.

하지만 그 자유는 책임에서 벗어나는 자유가 아니다. 더 중요한 일에 시간을 쓰게 해주는 자유다.

코드를 덜 쳐도 된다. 대신 결과를 더 잘 확인해야 한다.

구현 세부를 덜 붙잡아도 된다. 대신 완료 조건을 더 분명히 해야 한다.

AI의 답을 빨리 받을 수 있다. 대신 그 답이 실제로 맞는지 더 빨리 검증해야 한다.

그래서 처음 문장을 쉽게 다시 쓰면 이렇다.

소프트웨어 개발 도구가 좋아질수록 개발자는 더 자유로워진 것처럼 느낀다. 하지만 실제로는 통제가 사라지는 게 아니다. 코드를 직접 쓰는 곳에서 테스트, 실행 결과, 사용자 행동을 확인하는 곳으로 통제가 옮겨가는 것이다.

AI 코딩 시대의 핵심은 “AI가 얼마나 많이 써주나”가 아니다.

핵심은 “그 결과가 맞는지 얼마나 빨리, 얼마나 확실하게 확인할 수 있나”다.

출처

• Manifesto for Agile Software Development — “작동하는 소프트웨어”를 문서보다 더 가치 있게 본다는 선언.
• Principles behind the Agile Manifesto — 작동하는 소프트웨어를 진척의 주된 척도로 둔다는 원칙.
• Martin Fowler, Continuous Integration — 변경을 자주 통합하고 자동 빌드, 테스트로 검증하는 CI 설명.
• Anthropic, Claude Code Common Workflows — 테스트 추가, 테스트 실행, 실패 수정, 리팩터링 검증 워크플로.
• OpenAI Codex Best Practices — 변경 후 테스트, 검사, 동작 확인, 리뷰를 수행하라는 권장 사항.