AI가 코드를 쓰는 시대의 개발자

AI로 개발하면서 많은 생각이 드는 요즘이다.

예전에는 기능 하나를 만들기 위해 직접 구조를 고민하고, 코드를 작성하고, 에러 메시지를 따라가며 문제를 좁혀갔다. 오랜 시간 헤매다가 원인을 찾아냈을 때의 쾌감이 있었다. 내가 만든 코드가 처음 동작하는 순간도 꽤 즐거웠다.

지금은 많이 달라졌다. 내가 해야 할 일을 설명하면 AI가 코드베이스를 살펴보고 계획을 세운다. 코드를 작성하고 테스트를 실행한 뒤, 실패하면 원인을 찾아 다시 수정한다. 나는 모든 코드를 직접 입력하는 대신 방향을 정하고, 빠진 조건을 찾고, 결과가 원하는 대로 동작하는지 확인한다.

분명 더 빠르고 편해졌다. 그런데 한편으로는 조금 이상한 기분도 든다. 직접 코드를 작성하고 디버깅하며 얻던 재미가 줄었고, 그 과정에서 자연스럽게 쌓이던 경험도 함께 사라지는 것은 아닐까 하는 생각이 들었다.

나는 무엇을 놓치고 있고, 무엇을 새로 익혀야 할까?

그리고 편해진 만큼, 예전의 어려움을 일부러라도 다시 꺼내와야 하는 걸까?

계산기가 있는데 왜 암산을 연습해야 하는가?

줄어든 어려움과 새로운 문제

계산기가 계산을 대신하기 시작한 뒤, 우리는 긴 나눗셈을 빠르게 하는 능력을 전문성의 핵심으로 삼지 않게 됐다. 그 능력이 나빠서 버린 것이 아니다. 도구가 더 빠르고 정확하게 대신하면서 중요도가 내려간 것이다.

코딩도 비슷하다. AI가 잘 맡을 수 있는 일을 굳이 손으로 되풀이해야만 실력이 유지된다고 생각하지 않는다. 모든 구현을 먼저 직접 설계하고, 생성된 코드를 처음부터 끝까지 읽어야만 제대로 공부한 것도 아니다.

인지적 부하는 고통을 준다고 저절로 경험치로 바뀌지 않는다.

실제 서비스에 장애가 생기면 원인을 찾아야 한다. AI가 만든 구조가 변경을 방해하면 결합이 생긴 지점을 파고들게 된다. 성능이 떨어지면 병목을 찾고, 같은 실패가 반복되면 프롬프트와 규칙, 테스트와 구조를 바꾸게 된다. 이때의 어려움은 현실의 문제와 연결되어 있고 해결 결과도 곧바로 돌아온다.

물론 깊이 생각하고 코드를 읽는 훈련 자체가 무의미하다는 뜻은 아니다. 다만 현실의 문제와 떨어진 채 어려운 과정을 반복하는 것이 언제나 더 나은 판단으로 이어지는지는 잘 모르겠다. 문제가 없다면 좋은 일이다. 확보한 시간에는 더 크거나 다른 문제를 해결하면 된다.

AI가 줄여준 인지적 부하를 그대로 되살리기보다, 그 여유를 어디에 사용할지 고민하는 편이 더 중요하다.

그렇다고 기본기가 필요 없어진 것은 아니다

그런데 이 생각을 계속 밀어붙이다 보니 다른 질문을 만나게 됐다.

AI가 만든 결과가 좋은지 나쁜지는 누가 판단하는가?

코드를 직접 작성하는 일의 비중이 줄어도, 소프트웨어가 동작하는 원리까지 사라지는 것은 아니다. 데이터가 어디에서 와서 어디로 흐르는지, 상태가 왜 바뀌었는지, 어떤 경계에서 책임을 나눠야 하는지 모른다면 AI가 만든 결과를 제대로 판단하기 어렵다.

좋은 코드의 기준도 마찬가지다. 사람이 모든 코드를 읽어야 했던 시절과 기준은 달라질 수 있다. 파일이 조금 길거나 이름이 완벽하지 않은 것이 예전만큼 중요한 문제가 아닐 수도 있다. 하지만 변경하기 어려운 구조, 책임이 뒤섞인 코드, 실패를 발견할 수 없는 시스템은 AI가 작성했어도 여전히 좋지 않다.

가독성과 설계는 개발자의 자격을 증명하기 위한 미학이 아니다. 제품을 안전하게 바꾸고, 문제가 생겼을 때 원인을 찾고, 다음 작업을 더 쉽게 만들기 위한 수단이다.

원리와 흐름을 이해하고 좋은 코드와 나쁜 코드를 구분하는 능력은 여전히 필요하다. 다만 그 능력이 드러나는 장소가 달라지고 있다.

예전에는 내가 직접 작성한 코드에 그 사고가 남았다면, 이제는 AI에게 건네는 맥락과 제약, 질문과 피드백에 남는다. 그동안 쌓아온 판단은 사라진 것이 아니라 프롬프트로 이어진다. 무엇을 먼저 확인하게 할지, 어떤 선택지를 비교하게 할지, 어디까지 허용하고 무엇은 금지할지에 그대로 드러난다.

좋은 프롬프트는 말재주가 아니다.

그동안 쌓아온 판단이 프롬프트의 형태로 드러날 뿐이다.

코드를 잘 짜는 것에서, 잘 짜게 만드는 것으로

AI가 좋은 결과를 내도록 만드는 환경도 점점 중요해지고 있다.

프로젝트의 컨벤션을 명확하게 정리하고, 린트와 타입 검사로 어긋난 코드를 바로 잡는다. 테스트와 E2E로 기능이 실제 요구사항을 만족하는지 검증한다. 반복해서 설명해야 하는 판단은 스킬과 규칙으로 만들고, AI가 스스로 실행하고 실패를 확인할 수 있는 피드백 구조를 만든다.

이런 장치들이 AI를 둘러싼 **하네스(harness)**라고 생각한다.

좋은 하네스가 있으면 AI는 더 넓은 범위의 작업을 맡을 수 있다. 결과를 확인할 방법이 있으니 실패도 빨리 발견할 수 있다. 개발자는 모든 코드를 대신 읽는 병목이 아니라, AI가 올바른 방향으로 작업하고 스스로 검증할 수 있는 시스템을 만드는 사람이 된다.

코드를 직접 잘 짜는 것만큼, 더 나은 결과를 안정적으로 만들 수 있는 환경을 설계하는 일이 중요해진 것이다.

물론 하네스가 기본기를 대신해 주지는 않는다. 무엇을 규칙으로 만들지, 어떤 테스트가 중요한지, 어디에 경계를 세워야 하는지를 결정하려면 결국 소프트웨어를 이해해야 한다. 아는 만큼 요구할 수 있고, 아는 만큼 틀린 결과를 발견할 수 있다.

그래서 개발자의 실력을 코드를 직접 작성하느냐, 작성하지 않느냐로만 판단할 수는 없다고 생각한다. 어떤 문제를 풀어야 하는지 정의하고, 시스템의 원리와 흐름을 이해하며, 만들어진 결과가 올바른지 판단하는 일이 남는다. 그 판단을 AI가 반복해서 지킬 수 있도록 환경에 녹여내는 것도 이제 개발자의 일이다.

나는 이 일을 더 잘하고 싶다.

결국, 오늘의 문제를 해결하는 것

예전처럼 직접 코드를 작성하고 디버깅하며 한 줄씩 문제를 좁혀가던 재미는 많이 사라졌다. 내가 만든 코드가 처음 동작하던 순간의 작은 쾌감도 이전보다 줄었다.

조금 아쉽다.

하지만 그만큼 결과가 중요해졌다. 오늘 몇 줄의 코드를 작성했는지가 아니라, 어떤 문제를 해결했는지와 실제 제품을 얼마나 앞으로 움직였는지가 더 선명하게 남는다. 더 넓은 범위를 보고 더 빠르게 시도할 수 있다는 새로운 재미도 생겼다.

결국 내가 할 일은 크게 달라지지 않았다.

나는 회사에서 나에게 주어진 문제에 하루하루 몰입하고, 눈앞의 문제를 하나씩 해결한다. 지금 내 손에 쥔 가장 강력한 도구가 AI일 뿐이다.

그렇다고 과거에 배운 것들을 내려놓지는 않을 것이다. 원리와 흐름을 더 깊게 이해하고, 좋은 코드가 무엇인지 판단할 수 있도록 기본기와 기술 실력을 계속 쌓을 것이다. AI를 쓰지 않기 위해 공부하는 것이 아니라, AI를 더 잘 사용하고 그 결과에 책임지기 위해 공부할 것이다.

계산기가 있다고 수학이 사라지는 것은 아니다. 암산에 매달릴 필요는 없지만, 어떤 식을 세워야 하는지와 나온 답이 말이 되는지는 알아야 한다.

코드를 직접 작성하는 시간은 줄어들 것이다.

대신 무엇을 만들지 결정하고, 나온 답을 판단하고, 그 결과를 끝까지 책임지는 일이 남는다.