처음엔 별거 아닌 줄 알았다.
GitHub Copilot을 처음 쓰기 시작했을 때, 솔직히 말하면 그냥 "스택오버플로우 조금 더 편하게 쓰는 도구" 정도로 생각했다. 에러 메시지 붙여넣으면 그럴듯한 코드 조각이 나오고, 구글링 시간이 좀 줄었다. 유용하긴 한데, 뭔가 획기적이다는 느낌은 아니었다.
그러다 어느 날 문득 깨달았다.
내가 하루 종일 Ctrl+C, Ctrl+V만 하고 있네.
AI가 고쳐준 코드를 그대로 복붙하는 것이 루틴이 돼버렸다. 그 순간 이런 생각이 들었다. '이럴 거면 그냥 AI가 직접 코드를 고쳐주면 안 되나?' 마침 그 즈음, 코딩 에이전트가 등장했다.
에이전트는 진짜 신세계였다
처음 코딩 에이전트를 써봤을 때의 느낌은, 솔직히 말해서 충격이었다. 말만 하면 알아서 파일을 열고, 코드를 바꾸고, 에러를 잡아낸다. 내가 잘 모르는 라이브러리도 알아서 문서 찾아가며 구현한다.
'아, 이제 개발자는 다 없어지겠구나.'
진심으로 그런 생각이 들었다. 뭔가 불안하기도 하고, 흥미롭기도 하고, 묘한 감정이었다.
하지만 현실은 좀 달랐다.
코딩 에이전트는 잘 할 때는 정말 눈부시게 잘 했다. 그런데 못할 때는, 사람이라면 5초 만에 잡을 버그를 수십 번의 시도와 엄청난 토큰을 쏟아부으면서도 못 잡는 일이 생겼다. 맥락을 잃어버리거나, 이전에 고쳤던 부분을 다시 되돌리거나, 이상한 방향으로 계속 파고드는 경우도 있었다.
디버깅 방식도 달라졌다
예전에 오류가 생기면 내가 직접 코드를 열었다. 의심 가는 지점마다 print를 박아 넣고, 결과를 눈으로 하나씩 확인하면서 원인을 좁혀나갔다. 코드 흐름을 머릿속에 그려가며 "여기서 값이 이상하네", "아, 여기서 꼬이는구나" 하고 직접 손을 댔다.
지금은 다르다.
오류가 생기면 에이전트를 마치 심문하듯 묻기 시작한다. "지금 이 함수에서 어떤 값이 넘어오고 있어?", "이 로직이 이 케이스에서도 맞다고 생각해?", "혹시 여기 사이드 이펙트가 있을 수 있지 않아?" 질문을 하나씩 던지면서 에이전트 스스로 원인을 찾아가도록 유도한다. 묘하게도, 이렇게 하면 에이전트가 스스로 "아, 여기가 문제였네요"를 찾아내는 경우가 많다.
print 디버깅에서 대화형 심문으로. 어느 순간 나도 모르게 일하는 방식 자체가 바뀌어 있었다.
1년이 지난 지금
이제 AI 코딩을 본격적으로 도입한 지 약 1년이 됐다. AI 자체도 많이 발전했다. 예전엔 복잡한 작업엔 Opus를 써야 했는데, 이제는 Sonnet만으로도 오류 없는 깔끔한 코드를 뽑아낸다.
그리고 내가 하는 일도 달라졌다.
나는 이제 코드를 직접 짜는 시간보다, 설계하는 시간이 훨씬 많아졌다. 그 설계라는 게 거창한 게 아니다. AI가 작은 기능 하나를 구현할 때, '이 기능이 나중에 어떤 기능과 연결될 것인지', '어떤 의도에서 이 로직이 돌아가야 하는지'를 미리 정리해서 지침으로 주는 것이다. 그 차이가 생각보다 결과물을 엄청나게 바꾼다.
gowon-throwdown을 만들면서
이 방식이 가장 잘 맞아떨어진 경험이 바로 gowon-throwdown.team 프로젝트였다.
클라이언트를 만나고, 요구사항을 듣고, 그것을 어떻게 구조화된 DB와 시스템으로 풀어낼지 설계하는 데 집중했다. 실제 구현은 AI 에이전트들이 맡았다. 내가 막히거나 방향이 애매할 때는 AI와 같이 의견을 나눴다.
결과는 놀라웠다. 예전 같으면 몇 달 걸렸을 프로젝트를 훨씬 짧은 시간에 끝냈고, 클라이언트도 매우 만족했다.
개발자가 없어지는 게 아니라, 개발자의 역할이 바뀐다
처음에 '개발자 다 없어지겠네' 했던 그 생각, 지금은 조금 다르게 본다.
없어지는 건 아니다. 다만 달라진다. AI가 코드를 짜는 시대에, 시니어 개발자의 가치는 '얼마나 빠르게 타이핑하냐'가 아니라 '시스템을 어떻게 설계하고, AI에게 무엇을 시킬지, 그리고 AI가 막혔을 때 어떻게 풀어나갈지 판단하는 능력'으로 이동하고 있다.
솔직히 말하면, 이 변화가 나쁘지 않다. 오히려 내가 진짜 잘할 수 있는 것에 더 집중하게 됐다.
아직 1년밖에 안 됐다. 앞으로 또 어떻게 달라질지 모르겠지만, 일단은 이 흐름이 꽤 마음에 든다.