최근 사내 이동을 통해 새로운 팀에 합류하게 되었다. 5년간 몸담았던 팀을 떠나 맞이하는, 실로 오랜만의 새 출발이었다.

이번 이동이 유독 기대가 되었던 이유는 AI가 개발의 표준 도구로 자리 잡은 뒤 겪는 첫 번째 온보딩이었기 때문이다.

5년 전과 달리 지금 나에겐 AI라는 강력한 무기와, 회사에서 제공하는 무제한 토큰이 있었다. 팀을 옮긴 직후 나는 “AI 덕분에 너무 빨리 적응해서 동료들이 놀라지 않을까?” 하는 기분 좋은 상상을 하곤 했다.

새로운 팀으로 옮겨 일한 지 한 달. 그 상상은 절반은 맞고 절반은 틀렸다. 흥미로웠던 지난 한 달간의 기록을 남긴다.

#낯선 코드는 덜 두렵다

AI가 코딩을 잘한다는 건 이미 알고 있었다. 팀을 옮기기 전에도 업무에 AI를 적극적으로 활용했고, 개인 시간에는 여러 AI 코딩 툴을 써보며 개발의 새로운 지평을 탐험하고 있었다.

이전 팀에서는 오픈소스를 주로 다뤘지만, 이곳은 철저히 구글 내부 기술로 만들어진 코드베이스였다.

구글의 기술 스택은 고도로 ‘갈라파고스화’ 된 것으로 유명하다. 하드웨어부터 소프트웨어까지 거의 모든 것을 자체 개발해 쓴다. Java를 쓰더라도 오픈소스 라이브러리 대신 내부 표준을 따르고, 비동기 프레임워크나 웹 스택도 모두 독자적이다. 공개된 학습 데이터에 없을 테니, AI가 힘을 못 쓸 것이라 예상했다.

하지만 AI는 놀라울 정도로 훌륭했다.

얼마 전 Armin Ronacher가 지적했듯, 프런티어 모델의 지능은 이미 충분히 높다. 구조가 잘 잡혀 있고, 충분한 주변 컨텍스트가 있으며, 확실한 피드백 루프만 있다면, AI는 처음 보는 낯선 내부 라이브러리라도 금방 패턴을 모방해 낸다.

무엇보다 구글은 검증 테스트(Presubmit)가 상당히 촘촘하게 짜여 있다. Lint 같은 기본 문법 체크부터 반강제적으로 작성하는 integration test까지, 검증의 기준치가 내가 겪어본 어떤 곳보다 높았다.

이러한 엄격함은 사람에게도, AI에게도 훌륭한 피드백이 되었다. AI가 코드를 쓰고, 테스트가 깨지고, AI가 다시 고치는 사이클이 빠르고 자동적으로 돌아갔다. 덕분에 나는 10년 만에 다시 쓰는 Java였음에도, 첫 주에 코드를 기여하는 개인적인 미션을 달성할 수 있었다.

#코드에 모든 컨텍스트가 있는 건 아니다

반면, 인프라 설정은 정반대였다. 도움이 되기는커녕 방해가 되었다.

첫 프로젝트로 인프라 설정 파일을 수정해야 했다. 문제는 이런 작업에선 즉각적인 피드백을 기대하기 어렵다는 점이다. 설정을 적용하고 실제 배포가 끝난 뒤에야 에러를 확인할 수 있었다. 피드백 루프가 끊긴 곳에서 AI의 근거 없는 자신감은 내 시간을 철저하게 낭비했다.

사실 AI 탓만 하기는 어렵다. 구글은 비교적 오래된 테크 기업이고, 그만큼 내부 인프라의 best practice는 수없이 바뀌어 왔다. 문서는 낡았고, 코드는 파편화되어 있으며, 진짜 지식은 문서가 아닌 동료들의 머릿속에만 존재하는 경우가 허다하다. 인간조차 이 인프라의 맥락을 잡는 건 쉽지 않다.

“지금 이 기능을 적용하려면 3년 전 방식이 아니라 지난 분기에 도입된 방식을 써야 한다"는 맥락을 AI는 알 길이 없다. AI는 그럴듯한 오답을 내놓았고, 나는 그걸 붙들고 반나절을 허비했다.

결국 해결책은 고전적인 방법이었다. 이 설정 파일을 마지막으로 변경했던 동료에게 물어보고, 다른 팀은 비슷한 문제를 어떻게 해결했는지 맥락을 직접 찾아보는 것. AI를 통해 같이 리서치하고 방법을 모색했지만, 결국 내가 생각을 멈추고 AI를 사용해 “딸깍” 하고 티켓을 처리하는 건 불가능했다.

#병목은 생성이 아니라 ‘책임’

이번 온보딩에서 가장 깊게 고민한 주제는 기술이 아닌 개발자의 책임이었다.

AI는 순식간에 코드를 쏟아낼 수 있다. 하지만 그 코드를 검증하고, 동료에게 리뷰를 요청하고, 나중에 문제가 생겼을 때 책임져야 하는 건 오로지 나다.

처음엔 인터넷에서 읽은 수많은 개발자들의 간증을 따라 AI를 블랙박스처럼 믿고 쓰려 했지만, 내가 이해하지 못한 코드를 동료에게 리뷰해 달라고 던지는 건 동료에 대한 예의가 아니라고 느꼈다.

최근 뜨거운 논쟁 주제이기도 하지만 Armin이 지적했듯 이제 개발의 병목은 코드 생성이 아니라, 코드를 책임져야 하는 바로 우리에게 있다는 것을 뼈저리게 느끼게 되었다.

누군가는 나를 곧 도태될 꼰대 개발자라고 할 수도 있겠지만, 적어도 현시점에서 나는 Russ Cox의 말마따나, 도구가 바뀌었다고 해서 본질이 바뀌는 건 아니다라는 의견에 깊이 공감한다.

AI 도구를 쓰더라도 기여자는 여전히 스스로 검토를 마친 양질의 코드를 제출해야 합니다. 한 번 쳐다보지도 않은 코드를 보내는 건 용납될 수 없습니다.

더 나아가, 충분한 고민이 담기지 않은 코드를 보내는 것 역시 용납될 수 없습니다. 이것이 최적의 해결책인가? 더 간단한 방법은 없는가? 중요한 테스트가 빠지진 않았는가?

소프트웨어 엔지니어링에 대한 신중한 고민을 AI 도구에 떠넘겨서는 안 됩니다.”

결국 나는 온보딩 기간 중 일주일을 할애해 Java의 기본기를 다시 공부했다. 당연하게도 내가 내용을 완벽히 이해하고 주도할 때야 비로소 AI와의 협업 속도가 빨라졌다.

#마치며

AI 덕분에 온보딩은 확실히 빨랐다. 절대적인 생산성의 우위는 의심할 여지가 없다. 하지만 나는 아직 코드를 완전히 블랙박스로 취급할 수 있는 단계에 도달하지 못했다.

오래된 레거시, 문서화되지 않은 지식, 그리고 ‘내 코드에 책임을 진다’는 개발자의 책임이 존재하는 한, 운전대는 여전히 내가 잡고 있을 것이다. 비록 그 생각이 얼마나 빠르게 구닥다리가 될지는 모르겠지만 말이다.