15년 차 구글 출신 개발자, AI 반대론에 지치다

구글에서 3년 보낸 걸 포함해서 시스템 개발 쪽에서만 15년을 굴렀다. AI에 대해 불만은 존나 많지만, AI가 이미 다 할 수 있는 일인데도 못 하는 척하는 꼴은 진짜 봐주기 힘들다.

C++ 검색 서빙 시스템에서 테일 레이턴시(tail latency) 잡는 것처럼 복잡한 걸 예로 들어보자. 요청이 RPC를 타고 여러 백엔드로 퍼져나가는데, 대부분은 금방 끝나지만 몇몇 느린 응답 때문에 전체가 다 막혀버린다. 중간값 레이턴시는 멀쩡해 보여도 p99는 개판이 나기 일쑤지. 기본 테스트 다 통과한 변경 사항도 부하가 걸리면 바로 맛이 가버린다.

진짜 골치 아픈 예시가 하나 있다. 느린 RPC 하나가 다른 복제본으로 두 번째 요청을 날리는 상황이다. 호출자는 결국 타임아웃이 나는데, 백엔드 작업은 계속 돌아가고 있다. 부하가 걸리면 이런 추가 요청들이 큐를 꽉 채우면서 전체를 더 느리게 만든다. 레이턴시 줄이려고 만든 메커니즘이 오히려 과부하를 일으키는 꼴이지.

이걸 고치려면 호출 체인 전체에서 데드라인을 추적하고, 취소 여부 확인하고, 추가 작업을 제한해야 한다. 거기다 C++ 특유의 수명 문제까지 겹친다. 취소된 뒤에도 완료 콜백이 실행될 수 있다면, 요청 상태를 너무 빨리 해제하는 순간 use-after-free가 터진다. 축하한다, 레이턴시 잡으려다 프로세스까지 날려 먹는 거다.

2016년 같았으면 이런 거 하나 잡느라 며칠씩 까먹었다. 남이 짠 코드 읽고, 트레이스 비교하고, 프로파일 뒤지고, 기존 테스트로는 재현이 안 되니까 재현 코드까지 따로 짜야 했다. 패치 하나 올리면 한쪽 고치다 다른 쪽 터져서 리뷰 다시 받고.

작업 넘겨주고 일주일 내내 똑같은 제약 사항 설명하느라 진 빼던 시절은 다시 겪고 싶지 않다. 누가 작업 안전성 확인도 안 하고 재시도 로직 넣는 바람에 내 일 다 제쳐두고 4시간씩 붙잡혀 있던 것도 마찬가지고. 주니어든 시니어든 그런 짓은 진짜 사람 지치게 만든다. 나도 남들한테 그런 오후를 선사한 적이 있으니 할 말은 없지만.

이제는 Opus한테 관련 구현이랑 트레이스, 제약 사항 던져주면 바로 같이 문제를 풀 수 있다. 파일 넘나들면서 요청 수명 추적하게 시키고, 데드라인 전파가 어디서 끊기는지 찾고, 패치 제안까지 받는다. 취소 후에 콜백이 오거나 백엔드가 느려지는 상황을 시뮬레이션하는 테스트 코드도 짜게 한다. 나는 그놈이 내놓은 논리 검토하고 결과 테스트하는 데만 집중하면 된다.

물론 수정에 대한 책임은 여전히 내 몫이다. 프로덕션 성능 문제는 부하 테스트가 필수니까. 하지만 제대로 된 패치 후보를 뽑아내는 게 너무 쉬워져서, 이제는 예전처럼 모든 단계를 수동으로 할 생각이 전혀 안 든다. 예전 같으면 몇 주 동안 사람들 사이를 핑퐁 치던 일들을 이제는 오후 반나절이면 끝낸다.

지난 1년 동안 미루고 미뤄왔던 것들을 다 만들었다. 아이디어가 식기 전에 실제로 구현까지 끝내고 있다.

AI 모델이 내 일의 일부를 나보다 더 잘한다는 걸 인정하기는 싫다. 그래도 뭐, 어쩌겠나. 옛날 방식이 더 좋다고 우기면서 시간 낭비하기엔, 지금 뭐 만드는 게 너무 재밌어서 참을 만하다.