AI 시대, 우리는 그 여유를 어디에 쓰고 있는가

AI와 함께 개발하는 시대가 왔다. 혼자 앉아 있어도 더 이상 혼자 개발하지 않는다. 막히는 지점에서 가능한 접근법을 제시해주고, 내가 놓친 엣지 케이스를 짚어주고, 테스트 코드를 같이 짜주고, "이 함수는 이름이 좀 모호한데 이렇게 바꾸는 게 어떻냐"는 리팩터링 제안까지 던져주는 친구가 옆에 있다. 질문을 던지면 돌아오는 답이 있고, 내가 쓴 코드를 설명하라고 하면 내 관점과 다른 시각으로 짚어주기도 한다. 혼자 화면을 마주 보며 고민하던 시간이, 누군가와 대화하며 풀어가는 시간으로 바뀌었다. 말 그대로, 드디어 '짝코딩이 가능한 환경'이 만들어졌다. 예전에는 짝코딩이나 TDD가 좋은 방식이라는 걸 알아도 늘 현실적인 제약이 따라붙었다. 사람이 부족했다. 짝을 이룰 동료가 늘 옆에 있는 것도 아니고, 리뷰해줄 시니어의 시간은 언제나 한정적이었다. 시간도 부족했다. 테스트를 먼저 작성하려면 당장의 구현이 느려지는 것처럼 느껴졌고, 설계를 깊게 고민하려면 기능 출시가 밀렸다. 일정은 항상 빠듯했다. 스프린트는 끝나기 전에 이미 다음 스프린트의 압박이 시작되었고, "이번 분기까지는 일단 기능부터 내자"는 말이 계속 반복됐다. 테스트를 먼저 작성하고, 설계를 고민하고, 함께 코드를 리뷰하는 과정은 좋은 줄 알면서도 비용이 큰 선택이었다. 이상적인 방식과 실제로 굴러가는 방식 사이의 간극은 대부분의 팀에서 익숙한 풍경이었다. 그래서 늘 같은 말이 따라붙었다. "나중에 시간 나면 하자." 물론 그 나중은 거의 오지 않았다. 그런데 이제는 상황이 완전히 달라졌다. AI 덕분에 구현 속도는 비약적으로 빨라졌다. 예전에는 보일러플레이트 하나 짜는 데도 몇십 분이 걸렸다면, 지금은 대략적인 의도만 전달해도 초안이 거의 즉시 나온다. 반복 작업의 부담도 크게 줄었다. API 엔드포인트 열 개를 비슷한 패턴으로 찍어내는 일, 비슷한 형태의 모델 클래스를 양산하는 일, 규칙이 정해진 데이터 변환을 코드로 옮기는 일 같은 것들은 예전에 개발자의 집중력을 가장 많이 깎아먹는 구간이었는데, 이제는 그 구간 자체가 대부분 증발했다. 테스트 코드를 작성하는 부담도 마찬가지다. "테스트 코드 짤 시간에 기능 하나 더"라는 오랜 타협은, AI가 테스트 초안을 함께 짜주는 순간 상당 부분 힘을 잃는다. 리팩터링 역시 마찬가지다. 예전에는 큰 구조를 건드리는 순간 일정이 흔들렸지만, 이제는 변경 범위를 빠르게 파악하고 영향도를 함께 검토해주는 도구가 있다. 설계 단계에서도 대안을 여러 개 펼쳐놓고 비교해보는 일이 현실적인 선택지가 되었다. 과거의 병목이 대부분 풀린 셈이다. 이제야 비로소, 우리가 원하던 개발 방식을 시도할 수 있는 조건이 갖춰졌다. 그런데 이상하게도 많은 경우, 우리는 그 방향으로 가지 않는 것처럼 보인다. 속도가 빨라진 만큼 더 고민하고, 더 검증하고, 더 단단하게 만드는 대신 그저 더 많은 기능을 더 빠르게 만들어내는 데 그 속도를 그대로 사용한다. 주변을 둘러보면 이런 풍경이 낯설지 않다. 예전 같으면 일주일은 걸렸을 기능이 하루 만에 PR로 올라오고, 그 PR을 꼼꼼히 리뷰할 시간이 미처 확보되기도 전에 다음 기능이 또 올라온다. 테스트 코드를 함께 짤 수 있는 환경이 갖춰졌는데도, 정작 테스트는 "일단 돌아가니까 나중에"라는 말과 함께 뒤로 밀린다. 설계에 대한 고민이 필요한 지점에서도, AI가 그럴듯한 코드를 즉시 뽑아주기 때문에 "왜 이렇게 설계했는가"를 짚어보기 전에 이미 구현이 끝나 있다. 코드 리뷰는 점점 "이 변경이 맞는가"를 깊이 따지는 자리가 아니라, "이 변경을 이해할 시간이 없으니 일단 통과"에 가까워진다. 쌓이는 코드의 양은 늘었는데, 그 코드를 붙잡고 생각한 시간은 오히려 줄어드는 기묘한 역설이다. 더 묘한 건 이 속도가 만들어내는 기대치의 변화다. 예전에는 "이 정도 기능이면 2주"가 합리적이었던 것이, AI가 옆에 있는 지금은 "그걸 왜 2주나 걸려?"가 된다. 도구가 만들어준 여유는 "이번에는 품질을 더 챙기자"로 흐르지 않고, "그러면 기능을 더 넣을 수 있겠네"로 흐른다. 개인이 여유를 가지려 해도, 주변의 속도가 올라가면 그 여유는 곧 뒤처짐처럼 보이기 시작한다. 그래서 다시 속도를 맞추게 되고, 맞추다 보면 결국 과거와 똑같은 빠듯함 속으로 돌아온다. 도구만 바뀌었을 뿐, 사람의 하루는 여전히 숨 가쁘다. AI가 만든 변화는 분명 "더 잘 만들 기회"이기도 한데, 현실에서는 종종 "더 급하게 만들 수 있는 수단"으로만 소비된다. 같은 기술을 두고도 어떤 관점에서 쓰느냐에 따라 결과물이 완전히 달라지는데, 대부분의 조직이 선택하고 있는 쪽은 후자에 가까워 보인다. "더 좋은 것을 만드는 도구"가 아니라 "더 많이 뽑아내는 도구"로 자리잡은 셈이다. 사실 이 현상은 기술사에서 거의 반복되는 패턴이다. 워드프로세서가 글쓰기를 쉽게 만들었을 때 우리는 더 좋은 글을 쓴 게 아니라 더 많은 글을 썼고, 이메일이 소통을 빠르게 만들었을 때도 더 신중하게 소통한 게 아니라 그냥 더 많이 보냈다. 생산성이 올라가면 그만큼 여유가 생기는 게 아니라, 그만큼 기대치가 올라간다. 일종의 파킨슨 법칙의 기술 버전이다. 그래서 "AI 덕분에 품질에 투자할 여유가 생겼다"는 진단은 논리적으로는 맞지만, 현실에서 그 여유는 거의 항상 새로운 일로 즉시 메워진다. 시장과 조직이 그렇게 설계되어 있기 때문이다. 반복 작업의 비용이 줄었고, 테스트를 작성하는 부담이 낮아졌고, 예전에는 시간 때문에 포기하던 설계와 리팩터링을 다시 시도할 수 있는 여유가 생겼다. 품질에 투자할 조건이 처음으로 현실적으로 갖춰진 셈이다. 그런데도 우리는 그 여유를 품질에 쓰기보다, 다시 속도 경쟁에 투입하고 있다. 과거에는 시간이 부족해서 못 했던 일들을 이제는 할 수 있게 되었음에도, 아이러니하게도 우리는 그 시간을 다시 없애버리고 있다. 여기서 한 가지 비틀어볼 필요가 있다. "속도 대 품질"이라는 프레임 자체가 이미 AI 이전 시대의 잔재일지도 모른다는 점이다. AI를 제대로 쓰면 사실 이 둘은 대립하지 않는다. 테스트를 먼저 쓰게 하고, 여러 설계 대안을 병렬로 탐색하고, 리팩터링을 상시로 돌리는 식으로 둘 다 가능하다. 문제는 많은 사람이 AI를 여전히 "기존 방식을 더 빠르게 하는 도구"로만 쓰고 있다는 것이다. 도구가 바뀌었으면 일하는 단위와 방식 자체를 재설계해야 하는데, 우리는 구-방식을 가속하는 데만 그치고 있다. 속도가 10배 빨라졌다고 해서 같은 작업 흐름을 10배 빠르게 돌리면 되는 게 아닌데, 대부분 정확히 그렇게 쓰고 있다. 결국 달라진 것은 도구인데, 일하는 방식과 의사결정의 기준은 그대로 남아 있다. 그래서 AI 이후의 개발은 더 "좋은 코드"로 이어지기보다, 그저 더 "많은 코드"로 이어지고 있는 것처럼 보인다. 어쩌면 지금 필요한 건 더 좋은 도구가 아니라, 이미 좋아진 도구를 어떻게 쓸 것인지에 대한 태도의 변화인지도 모른다. 물론 태도는 하루아침에 바뀌지 않는다. 도구가 바뀐 속도에 비해 문화가 바뀌는 속도는 언제나 느리고, 그 간극을 메우는 건 결국 현실에서의 경험이다. AI를 속도에만 쓴 팀과 품질에도 쓴 팀이 시간이 흐른 뒤 어떤 차이를 보이는지, 기술 부채가 쌓인 코드베이스와 꾸준히 다듬어진 코드베이스가 어떤 수명을 갖는지, 이런 것들이 하나둘 쌓이면서 비로소 "빠름이 곧 좋음은 아니다"라는 감각이 자리잡는다. 지금은 아직 AI 개발의 초기 행복기에 가깝다. 이런 시기의 특징은 "빠름 = 좋음"이라는 등식이 자연스럽게 공유된다는 것이다. 새로운 도구가 주는 가능성에 흥분하는 건 당연하고, 그 자체가 나쁜 일도 아니다. 다만 그 등식이 전부가 아니라는 사실은 시간이 조금 지나야 서서히 드러나는 편이다. 그리고 먼저 알아차리는 사람들이 먼저 움직이기 시작한다. 기술은 이미 다음 단계로 넘어갔는데, 개발 문화는 아직 이전 단계에 머물러 있다. 기술사의 거의 모든 전환기가 이런 시차를 품고 있었다. 다만 다행스러운 건, 그 간극이 결국엔 좁혀진다는 점이다. 누군가는 먼저 새로운 방식을 시도하고, 그 결과가 드러나면 다른 이들이 뒤따른다. 시차가 좁혀지는 과정이 늘 매끄럽지는 않지만, 적어도 방향은 있다. 그래도 조금 멀리서 보면, 이 흐름은 감쇠 진동처럼 이해할 수 있다. 충격을 받은 시스템은 즉시 안정 상태로 가지 않는다. 한쪽으로 크게 흔들리고, 반대쪽으로 되튕기고, 그 폭이 조금씩 줄어들면서 결국 어딘가에 수렴한다. 지금은 속도 쪽으로 과하게 쏠려 있지만, 몇 년 뒤에는 그 반작용으로 엄격한 검증과 설계 쪽으로 역진자가 움직일 수 있고, 그 사이 어딘가에서 균형점이 찾아질 수도 있다. 과거의 많은 기술 전환기가 실제로 대략 이런 모양으로 흘렀다. 다만 이 비유를 끝까지 밀어보면 두 가지 단서가 붙는다. 하나는, 감쇠 진동이 수렴하려면 수렴할 지점이 고정되어 있어야 한다는 것이다. 그런데 AI는 지금도 계속 진화 중이다. 1년 뒤의 "적절한 개발 방식"과 5년 뒤의 "적절한 개발 방식"은 전혀 다른 것일 수 있다. 그러면 우리는 고정된 점으로 수렴하는 게 아니라, 계속 움직이는 목표를 추격하는 상태에 가까워진다. 균형점이 도망가면 진자는 영원히 따라붙어야 한다. 다른 하나는, 수렴한다고 해서 그 과정에서 생긴 손실이 복원되는 건 아니라는 점이다. 진자가 결국 중앙으로 돌아와도, 흔들리는 동안 누군가의 프로젝트는 기술 부채로 무너졌고, 누군가는 번아웃으로 떠났고, 누군가는 깨진 제품을 세상에 남겼다. "언젠가는 균형점에 도달한다"는 말이 맞더라도, 그 언젠가까지의 비용은 실존하는 비용이다. 그래도 "결국 수렴한다"는 관점은 비관론의 훌륭한 해독제다. 지금 우리가 과하게 한쪽으로 쏠려 있다는 건 맞지만, 그게 영원히 그 방향으로 가는 건 아니다. 시장은 결국 기술 부채의 청구서를 보낼 것이고, 품질을 지킨 팀은 결국 드러날 것이다. 단지 그게 자동으로 일어나지는 않고, 꽤 큰 진폭의 흔들림을 동반하며 일어난다는 것뿐이다. 그러니 어쩌면 지금 필요한 태도는 두 가지가 공존하는 것일지도 모른다. 하나는 결국 수렴할 거라는 낙관, 너무 비관하지 않기 위해. 다른 하나는 진폭을 줄이려는 노력, 수렴이 너무 먼 미래에 너무 큰 대가를 치르고 오지 않도록. 수렴을 믿는 것과, 수렴을 앞당기려 노력하는 건 서로 모순되지 않는다.