도구의 시대

2025년의 끝자락에 이 글을 쓴다. 올 한 해 가장 자주 했던 생각을 하나만 꼽으라면 "도구가 자라는 속도가 무섭다"였다. Copilot이 자동완성을 넘어선 지 오래고, Cursor나 Claude Code 같은 에이전트는 이제 함수 하나가 아니라 기능 단위, 때로는 작은 프로젝트 단위를 통째로 만들어낸다. 연초에 내가 쓰던 도구와 연말에 쓰는 도구는 사실상 다른 물건이다.

그 속도를 체감할수록 마음 한켠이 계속 불편했다. 코드를 짜는 일 자체는 점점 저 도구들이 나보다 빠르고, 어떤 영역에선 더 정확하다. 그러면 개발자인 나에게 요구되는 건 뭐가 남는가. 이 질문을 반년 넘게 붙잡고 있었고, 아직 깔끔한 답을 내지는 못했다. 다만 흔들리는 와중에 내가 붙잡게 된 것 몇 가지를 정리해두려 한다.

AI가 잘하게 된 것

먼저 인정할 건 인정하고 시작하자. 코드 생산 자체는 빠르게 평준화되고 있다. 예전 같으면 라이브러리 문서를 뒤지고, 예제를 찾고, 시행착오를 거쳐 반나절을 썼을 작업이 지금은 프롬프트 몇 줄로 초안이 나온다. 그 초안이 완벽하진 않아도, 내가 백지에서 시작할 때보다 훨씬 앞선 지점에서 출발하게 해준다.

이게 무슨 뜻인가. "구현할 줄 안다"는 능력의 희소성이 떨어지고 있다는 뜻이다. 물론 복잡한 시스템을 설계하고 디버깅하는 깊은 실력은 여전히 도구가 따라오지 못한다. 하지만 일상 업무의 상당 비중을 차지하던 "이 기능을 코드로 옮기는 일"의 몸값은 분명히 내려갔다. 이걸 부정하면서 글을 시작하고 싶지는 않다.

그래서 위기감이 든 것도 사실이다. 내가 지난 몇 년간 쌓아온 것의 큰 부분이 "구현할 줄 아는 것"이었으니까. 그럼 나는 무엇으로 값을 하는가.

그래서 다시, 무엇을 만들 것인가

이 질문을 파고들다 보니 예전에 들었던 말 하나가 다시 떠올랐다. 지난 회고에서 적었던 "우리 업무는 개발이지만 우리 일은 개발이 아니다"라는 PM분의 말이다. 그때는 시야를 넓히라는 조언 정도로 받아들였는데, 도구의 시대에 이 문장은 다른 무게로 다가온다.

코드를 짜는 일이 싸질수록, 값이 옮겨가는 곳은 "무엇을 왜 만들 것인가"다. 요구사항을 그대로 받아 구현하는 건 이제 도구도 한다. 하지만 그 요구사항이 진짜 우리 프로덕트에 필요한 것인지, 우리 도메인에서 그 문제가 어떤 형태로 존재하는지, 어디를 건드려야 실제로 사용자가 체감하는지를 판단하는 일은 여전히 사람의 몫이다. 나는 이걸 문제를 정의하고 재정의하는 힘이라고 부르기로 했다.

특히 도메인 지식과 결합될 때 이 힘이 산다. 예전 글에서 B2C에서 B2B로 회사를 옮기며 성능 지표에 대한 감각이 완전히 바뀌었던 이야기를 한 적이 있다. 같은 기능이라도 어느 도메인에 놓이느냐에 따라 "잘 만든 것"의 정의가 달라진다. 도구는 내가 정의해준 문제를 잘 푼다. 그런데 그 문제를 우리 프로덕트에 맞게 옳게 세우는 일, 애초에 풀 가치가 있는 문제인지 가려내는 일은 도구가 대신 해주지 않는다. 오히려 구현이 저렴해질수록 잘못된 문제를 빠르게 만들어버릴 위험만 커진다.

AI-agent를 도구가 아니라 파트너로

여기까지는 어렵지 않게 정리됐는데, 올해 나에게 가장 크게 작용한 변화는 조금 다른 데 있었다. 에이전트를 대하는 내 태도가 바뀐 것이다.

처음엔 나도 에이전트를 그냥 코드를 빨리 뱉는 도구로 봤다. 시키면 짜주는 손 하나가 늘었다는 감각. 그런데 쓰다 보니 진짜 쓸모는 다른 데 있었다. 나는 어떤 구조가 나을지, 이 접근이 맞는지 늘 머릿속에서만 저울질하다 지쳐 결국 익숙한 쪽을 택하곤 했다. 에이전트는 그 가설들을 놀랄 만큼 싸게 검증하게 해줬다. "이 방식으로 짜면 이런 문제가 생기지 않을까"를 몇 분 만에 실제로 세워보고 깨볼 수 있다.

그때부터 에이전트를 내 가설을 검증하고 반증해주는 업무 파트너로 인식하게 됐다. 도구라고 생각하면 "얼마나 정확한 코드를 뱉느냐"가 관심사가 되지만, 파트너라고 생각하면 "내가 무엇을 물어야 하느냐"가 관심사가 된다. 그리고 이 전환이 묘한 역설을 만든다. 검증이 싸지니까 오히려 좋은 질문, 좋은 가설을 세우는 내 몫이 더 커졌다. 무엇을 검증할지 모르면 아무리 빠른 파트너가 있어도 쓸 데가 없다.

결국 다시 문제 정의로 돌아온다. 도구가 강해질수록, 그 도구에게 무엇을 시킬지 정하는 사람의 판단이 병목이자 값이 된다.

결론?

솔직히 이 글의 결론을 단정할 자신은 없다. 나는 아직 누군가의 성장에 대해 "이래야 한다"고 말할 만한 위치가 아니고, 지금 붙잡은 답도 내년 이맘때면 또 바뀌어 있을 것이다. 작년의 나는 리랜더링 최적화에 목을 매고 있었으니, 사람 참 쉽게도 바뀐다.

그럼에도 올 한 해를 지나며 확실해진 감각 하나는 남는다. 도구가 코드를 대신 짜주는 시대에 개발자에게 요구되는 건, 더 빨리 짜는 능력이 아니라 무엇을 왜 만들지 정의하는 능력이라는 것. 그리고 그 정의를 도메인 위에서 옳게 세우고, 에이전트라는 파트너를 써서 빠르게 검증하고 틀렸으면 접는 일. 이게 지금의 내가 붙잡은 잠정적인 답이다.

도구의 시대에 무엇을 붙잡고 있는가. 나는 여전히 흔들리는 중이고, 흔들리는 채로 다음 해를 맞으려 한다.