싱글코어가 필요한 시대
얼마 전 팀원이 나에게 요즘 어떻게 일하고 있는지, AI를 어떻게 사용하는지 물어봤다. 어떤 식으로 작업을 나누는지, AI에게 어디까지 맡기는지, 어떤 도구를 사용하는지 궁금하다고 했다. 이야기를 하다 보니 자연스럽게 서로의 작업 방식을 비교하게 됐다. 어떤 일을 먼저 보는지, 어디에서 시간을 쓰는지, AI에게 무엇을 맡기는지, 어떤 것은 직접 처리하는지, 결과물을 어떻게 확인하는지까지 하나씩 이야기했다. 그 팀원은 나보다 대략 여섯 배 정도 많은 토큰을 사용하고 있었다. 여러 가지 최신 기능도 적극적으로 사용하고 있었고, skill을 붙이고 harness를 만들고 agent를 활용하는 등 AI를 자신의 개발 환경에 상당히 깊게 끌어다 쓰고 있었다. 반면 나는 거의 순정에 가까운 방식으로 사용하고 있었다. 팀에서 같이 사용하는 몇 가지 skill이나 PR 자동화 같은 것을 제외하면 특별히 복잡한 환경을 만들어놓고 사용하는 것도 아니었다. 그런데 우리가 처리한 일을 하나씩 비교해보니, 그 팀원은 자신이 나보다 훨씬 많은 토큰을 사용하고 여러 가지 도구를 활용하고 있음에도 task의 양이나 난이도에서는 나를 따라가기 어렵다고 했다. 결과물의 퀄리티도 차이가 나는 것 같다고 했다. 우리는 어디에서 이런 차이가 생기는지 이야기했다. 시간과 토큰을 어디에 쓰고 있는지를 하나씩 비교해봤다. 그러다 보니 내가 빠른 부분이 꼭 코드를 작성하는 부분은 아니라는 생각이 들었다. 오히려 그 앞에 있는 경우가 많았다. 문제를 보고 어디를 봐야 하는지 결정하는 데 오래 걸리지 않았고, 어떤 파일을 수정해야 하는지도 비교적 빨리 찾았다. 여러 가지 구현 방법을 만들어놓고 비교하기보다는 경험상 괜찮다고 생각하는 방향을 바로 선택하는 경우도 많았다. AI에게 물어보는 것보다 내가 그냥 직접 처리하는 것이 빠른 일은 굳이 AI에게 넘기지 않았다. AI가 결과를 가져왔을 때도 모든 코드를 처음부터 다시 읽기보다는 문제가 될 만한 부분을 먼저 보고, 괜찮다고 판단되면 바로 다음으로 넘어갔다. 그러다 보니 내가 AI를 적게 사용하는 이유가 AI를 잘 활용하지 못해서가 아니라는 생각이 들었다. 오히려 AI에게 일을 시키는 것보다 내가 직접 판단하고 처리하는 것이 빠른 순간이 꽤 많았던 것이다. 반대로 AI를 많이 사용하는 것은 AI에게 더 많은 일을 맡기고 있다는 뜻일 뿐, 그것이 반드시 더 많은 일을 끝냈다는 의미는 아니었다. 한때는 AI를 잘 사용하는 방법을 토큰을 얼마나 많이 쓰느냐의 문제로 생각하기도 했다. 더 많은 context를 넣고, 더 많은 파일을 보여주고, 더 많은 작업을 한꺼번에 시키고, 여러 agent를 돌리는 식이었다. 한동안은 이런 것을 일종의 토큰 맥싱처럼 생각하기도 했다. 하지만 지금은 조금 다른 생각이 든다. 중요한 것은 토큰을 얼마나 많이 사용했느냐가 아니라, 그 토큰을 어디에 사용했느냐에 가까운 것 같다. 같은 천만 토큰을 사용하더라도 문제를 탐색하고 결정하는 데 사용했는지, 구현하는 데 사용했는지, 결과를 검증하는 데 사용했는지, 아니면 잘못된 방향으로 갔다가 다시 만드는 데 사용했는지에 따라 의미는 완전히 달라진다. 시간도 마찬가지다. 결국 하나의 결과물을 만드는 데 우리가 실제로 무엇을 하고 있는지를 봐야 한다. 얼마나 많은 코드를 생성했는지가 아니라, 그 결과물을 완성하기까지 얼마나 많은 판단과 iteration을 거쳤는지가 더 중요할 수도 있다. AI를 열 번 호출해서 열 번의 결과를 비교한 끝에 하나를 선택하는 것과, 문제를 이해하고 한 번의 요청으로 원하는 결과를 얻는 것은 겉으로 보면 둘 다 AI를 사용한 개발이다. 하지만 실제로 그 둘이 소비한 시간과 집중력은 전혀 다르다. AI를 많이 사용하는 것이 반드시 일을 많이 하는 것은 아니다. 오히려 AI에게 무엇을 시킬지를 빨리 결정하는 능력이 전체 작업 속도를 좌우할 수도 있다. 이런 생각을 하다 보니 AI가 개발자에게 가져온 가장 큰 변화가 무엇인지도 조금 다르게 보이기 시작했다. 우리는 보통 AI가 코드를 빨리 작성해준다고 이야기한다. 물론 그것도 맞다. 하지만 실제로 더 큰 변화는 한 사람이 동시에 할 수 있는 일의 수를 늘려준 데 있는 것 같다. 예전에는 내가 하나의 작업을 하고 있으면 그 일을 끝내야 다음 작업을 할 수 있었다. 지금은 AI에게 migration을 시켜놓고 다른 일을 할 수 있고, 테스트를 만들게 해놓고 또 다른 코드를 볼 수 있고, 문서를 조사하게 하면서 다른 작업을 진행할 수도 있다. 여러 agent를 동시에 돌리는 것도 가능하다. 내가 직접 처리해야 했던 실행의 일부를 밖으로 밀어낼 수 있게 된 것이다. 그런 의미에서 AI는 나를 더 빠른 하나의 코어로 만들어주는 것보다, 내 옆에 여러 개의 실행 코어를 만들어주는 것에 가깝다는 생각이 든다. AI가 발전할수록 이 능력은 더 커질 것이다. 한 사람이 열 개의 작업을 동시에 시킬 수도 있고, 각각의 작업을 서로 다른 agent에게 맡길 수도 있다. 앞으로는 지금보다 훨씬 더 많은 일을 병렬로 처리할 수 있을 것이다. AI가 우리의 멀티코어 성능을 계속 높여준다면, 우리는 무엇을 더 높여야 할까. 나는 오히려 싱글코어 성능이라고 생각한다. 싱글코어 성능이라는 것이 코딩을 얼마나 빨리 하느냐는 뜻은 아니다. 타이핑 속도도 아니고 AI에게 얼마나 복잡한 프롬프트를 작성할 수 있는지도 아니다. 내가 생각하는 싱글코어 성능은 혼자 하나의 문제를 잡았을 때 그 문제를 얼마나 빠르고 정확하게 끝낼 수 있는가에 가깝다. 문제를 이해하고, 필요한 범위를 찾고, 설계를 결정하고, AI에게 맡길 것과 직접 할 것을 구분하고, 결과를 확인하고, 괜찮으면 끝내는 과정 전체를 얼마나 적은 시행착오로 통과할 수 있느냐의 문제다. 개발을 오래 하다 보면 가끔 정말 한큐에 일이 끝나는 순간이 있다. 요구사항을 듣고 잠깐 생각한다. 어디를 수정해야 할지 알고, 어떤 구조로 만들지 결정한다. 필요한 부분은 AI에게 맡기고 결과를 받아서 확인한다. 테스트를 돌리고 끝낸다. 겉으로 보면 별로 특별한 일이 아니다. 그런데 그 짧은 과정이 가능한 이유는 그동안 비슷한 문제를 수없이 봤기 때문이다. 어떤 설계가 나중에 문제를 만드는지 알고 있고, 어떤 abstraction이 불필요한지도 알고 있고, 지금 당장 해결할 필요가 없는 문제가 무엇인지도 알고 있다. 그래서 처음부터 선택지가 많지 않다. 무엇을 해야 할지를 찾는 시간이 짧고, 무엇을 하지 않아도 되는지를 판단하는 시간도 짧다. 어쩌면 숙련이라는 것이 이런 것인지도 모르겠다. 더 많은 것을 아는 것이기도 하지만, 동시에 더 많은 선택지를 버릴 수 있는 것이다. 경험이 적을 때는 여러 가지 방법을 놓고 고민한다. 경험이 쌓이면 그중 상당수를 빠르게 버릴 수 있다. 그리고 어느 순간에는 문제를 보는 순간 대략적인 답의 범위가 보인다. 그래서 좋은 개발자가 빠른 것은 코딩을 빨리하기 때문만은 아니다. 실제로는 코드를 작성하기 전에 이미 많은 일이 끝나 있는 경우가 많다. 문제를 이해했고, 범위를 정했고, 설계를 선택했고, 하지 않을 것을 결정했다. 코드는 그 결정의 결과를 옮기는 과정에 가깝다. AI 시대에는 이런 능력이 오히려 더 중요해질 수 있다. AI는 이미 결정된 문제를 굉장히 잘한다. 기존 코드를 새로운 API로 바꾸거나, 테스트를 추가하거나, 반복되는 패턴을 수정하거나, 이미 정해진 구조 안에서 새로운 기능을 구현하는 것은 AI가 아주 빠르게 처리할 수 있다. 무엇을 해야 하는지가 이미 결정되어 있기 때문이다. 반면 새로운 문제를 만났을 때는 이야기가 달라진다. 무엇을 저장할지, 어떤 모델을 만들지, 기존 구조를 확장할지 새로 만들지, 어떤 책임을 어디에 둘지, 어떤 경우를 지원하고 어떤 경우를 버릴지 같은 문제는 코드보다 먼저 결정되어야 한다. AI에게 아무리 좋은 context를 주고 아무리 강력한 harness를 만들어도, 아직 결정되지 않은 문제를 대신 결정해주는 것은 아니다. 여러 가지 답을 만들어줄 수는 있지만 결국 그중 무엇이 맞는지는 사람이 판단해야 한다. 오히려 AI가 강해질수록 잘못된 판단의 비용은 다른 형태로 커질 수 있다. 예전에는 잘못된 설계를 실제 코드로 옮기는 데 시간이 오래 걸렸기 때문에 중간에 멈춰서 다시 생각할 기회가 있었다. 지금은 AI에게 시키면 몇 분 만에 상당한 양의 코드가 나온다. 잘못된 생각도 너무나 빠르게 현실이 된다. AI가 틀린 답을 빠르게 만들어주는 능력 자체는 생산성이 아니다. 잘못된 방향으로 빠르게 가는 것은 빠른 개발이 아니라 빠른 재작업일 뿐이다. 그래서 AI 시대에는 빠르게 만드는 능력만큼이나 빠르게 틀린 것을 알아차리는 능력이 중요해질 것 같다. 더 좋은 것은 애초에 틀린 방향으로 가지 않는 것이다. 그런 의미에서 검증 역시 싱글코어 성능의 일부라고 생각한다. AI가 만든 코드가 테스트를 통과했다고 해서 반드시 좋은 코드는 아니다. 테스트는 우리가 미리 정의한 동작을 확인해줄 뿐이다. 좋은 abstraction인지, 불필요한 복잡성을 만들지는 않았는지, 기존 시스템의 경계를 제대로 지키는지, 앞으로 변경하기 좋은 구조인지는 별개의 문제다. 숙련된 개발자는 모든 것을 똑같이 검증하지 않는다. 위험한 변경인지, 영향 범위가 넓은지, 핵심 데이터에 영향을 주는지, 실패했을 때 비용이 큰지를 보고 어디까지 확인할지를 결정한다. 무엇을 확인해야 하는지 알고 있기 때문에 모든 것을 확인하지 않아도 된다. 이것 역시 결국 판단의 문제다. 그렇다고 멀티코어가 중요하지 않다는 이야기는 아니다. 오히려 AI 시대에는 멀티코어 능력이 더 중요해질 것이다. 여러 agent에게 일을 나눠주고, 반복적인 작업을 자동화하고, 여러 가지 구현을 병렬로 시도하고, 내가 직접 하지 않아도 되는 일을 계속 밖으로 밀어내는 능력은 앞으로 더 큰 생산성 차이를 만들 것이다. 다만 순서가 중요하다. 먼저 문제를 이해하고, 방향을 결정하고, 작업을 쪼갠 다음에 병렬화해야 한다. 싱글코어가 약한 상태에서 멀티코어만 늘리면 혼란도 같이 병렬화된다. 잘못된 설계를 열 개의 agent에게 시키면 열 개의 잘못된 구현이 나온다. 그리고 결국 그 결과물을 다시 사람이 읽고 판단해야 한다. 그래서 처음에 이야기했던 토큰 여섯 배의 차이도 이제 조금 다르게 보인다. 그 사람이 토큰을 여섯 배 사용했다는 사실 자체가 중요한 것이 아니다. 내가 토큰을 적게 사용한다는 것도 그것만으로 잘하고 있다는 증거가 아니다. 중요한 것은 그 시간과 토큰을 어디에 사용했고, 결국 어떤 결과물을 만들어냈느냐이다. 그리고 이 이야기는 나 자신에게도 그대로 돌아온다. 내가 지금 AI를 잘 사용하고 있는 것일까. 아니면 단순히 내가 익숙한 방식으로 일하고 있는 것일까. 지금은 내가 거의 순정에 가까운 방식으로 사용하는 것이 더 빠르다고 느끼지만, 앞으로 더 좋은 harness나 agent workflow가 나오고 그것이 실제로 더 좋은 결과를 만들어낸다면 나 역시 그것을 배워야 한다. 중요한 것은 순정이냐 최신 기법이냐가 아니다. AI를 얼마나 많이 사용했느냐도 아니다. 결국 중요한 것은 결과물이다. AI는 앞으로도 계속 강해질 것이다. 더 좋은 모델이 나오고, 더 좋은 agent가 나오고, 더 좋은 harness가 나오고, 한 사람이 동시에 처리할 수 있는 작업의 수는 계속 늘어날 것이다. 코드 자체를 만드는 비용은 점점 싸질 것이다. 그렇다면 상대적으로 더 중요해지는 것은 무엇일까. 무엇을 만들어야 하는지 결정하는 것, 무엇을 만들지 않는지 결정하는 것, 여러 결과 중 무엇이 좋은 결과인지 판단하는 것, 그리고 언제 충분히 좋은지를 결정하는 것이다. 어쩌면 AI 시대의 개발 생산성은 얼마나 많은 코드를 만들었는지가 아니라, 얼마나 적은 iteration으로 좋은 결과에 도달했는지로 봐야 할지도 모르겠다. AI에게 일을 많이 시키는 것이 중요한 것이 아니라, AI가 일을 하기 전에 내가 얼마나 많은 불확실성을 제거했는지가 중요할 수도 있다. AI가 나에게 열 개의 코어를 만들어준다고 생각해보자. 그 열 개의 코어에게 무엇을 시킬지는 결국 내가 결정해야 한다. 더 많은 코어를 갖는 것보다 중요한 것은 그 코어들이 무엇을 해야 하는지 정확하게 아는 것이다. 그래서 요즘은 AI를 얼마나 많이 사용하는지보다, 혼자 하나의 문제를 잡았을 때 내가 얼마나 강한지를 더 생각하게 된다. 얼마나 빨리 문제를 이해하고, 얼마나 빨리 불필요한 선택지를 버리고, 얼마나 빨리 올바른 방향을 결정하고, 얼마나 적은 시행착오로 결과를 만들어내는가. AI가 개발자의 멀티코어를 계속 늘려준다면, 우리가 해야 할 일은 어쩌면 그 반대편에 있는 능력을 키우는 것인지도 모른다. 여러 일을 동시에 처리하는 능력만큼이나, 하나의 문제를 깊게 보고 빠르게 결정하는 능력. 많은 일을 시키는 능력만큼이나, 무엇을 시키지 않아도 되는지를 아는 능력. 혼자 하나의 문제를 잡았을 때, 한 번의 판단으로 얼마나 멀리 갈 수 있는가.