에이전트(Agent)와 함께 코드를 작성하는 것이 페어 프로그래밍 (Pair Programming)과 같은 것일까요?

최근 이 질문이 많이 회자되고 있는데, 그 질문 안에는 많은 사람이 간과하고 있는 실질적인 결과가 담겨 있습니다.

많은 팀에서 두 명의 개발자가 함께 작성한 코드는 더 가벼운 코드 리뷰 (Code Review)를 받습니다.

개인적으로 저는 이것이 어디에도 명문화되어 있는 것을 본 적이 없습니다. 정책 문서에 적혀 있지도 않고, 아무도 투표로 결정한 것도 아닙니다. 하지만 제가 일했던 모든 곳에서, 두 사람이 함께 구축하고 테스트한 PR (Pull Request)이 올라오면 리뷰는 더 가벼워졌습니다. 리뷰어들은 코드를 더 신뢰했습니다. 리뷰 과정에서 발견되는 이슈가 적었습니다. 그 이후에 새어 나가는 버그 (Bug)도 적었습니다. 그래서 가벼운 리뷰가 옳은 결정처럼 보였고, 그것이 관행으로 굳어졌습니다.

이것은 비록 그렇게 느껴지지는 않더라도, 하나의 리스크 결정 (Risk decision)입니다. 누군가가 변경 사항의 카테고리를 살펴보고, 다른 모든 것보다 더 적은 정밀 조사가 필요하다고 결정한 것입니다.

그리고 여기서 깊이 생각해 볼 부분이 있습니다. 페어링 (Pairing)은 그 할인 혜택을 얻어냈다는 점입니다.

페어링은 그 할인 혜택을 얻어냈다

연구자들은 오랫동안 페어 프로그래밍 (Pair Programming)을 연구해 왔으며, 그 결과는 마케팅만큼 마법스럽지는 않지만 상당히 일관적입니다.

Cockburn과 Williams (2000)는 페어링이 개발 시간을 대략 15% 더 소요하게 하지만, 결함 (Defect)을 대략 15% 더 적게 발생시킨다는 것을 발견했습니다. 그들은 또한 설계 품질 (Design quality), 기술적 숙련도 (Technical skill), 팀 커뮤니케이션 (Team communication), 그리고 지식이 한 사람의 머릿속에만 머물지 않게 함으로써 발생하는 팀의 회복 탄력성 (Resilience) 측면에서 통계적으로 유의미한 이득을 측정했습니다.

Hannay, Dybå, Arisholm 및 Sjøberg의 2009년 메타 분석 (Meta-analysis)은 더 미묘한 차이를 보여줍니다. 품질에는 작은 양(+)의 효과가 있습니다. 기간 (Duration)에는 중간 정도의 양(+)의 효과가 있어, 페어는 실제 시간상으로 더 빨리 끝냅니다. 노력 (Effort)에는 중간 정도의 음(-)의 효과가 있는데, 이는 총 투입 인시 (Person-hours)가 더 많기 때문입니다. 복잡성 (Complexity) 또한 변수가 됩니다. 작업이 단순할 때는 페어가 더 빠르며, 작업이 어려울 때는 더 높은 품질을 만들어냅니다.

여기서 몇 가지 주의할 점이 있습니다. 제가 이 연구를 특정 관행을 옹호하기 위해 사용하고 있기 때문입니다. 두 연구 모두 코드 리뷰 (Code Review) 자체를 구체적으로 측정하지는 않았습니다. 그들은 결함 (Defects)과 소요 시간 (Duration)을 측정했으며, "따라서 리뷰가 짧아진다"는 것은 문앞에 나타나는 결함이 줄어든 것을 보고 내린 저의 개인적인 추론입니다. 또한 메타 분석 (Meta-analysis)의 저자들은 페어 프로그래밍 (Pair Programming) 문헌에서 출판 편향 (Publication Bias)의 징후가 나타난다고 지적했으며, 이는 누군가가 이 수치들을 완전히 확정된 것으로 취급하기 전에 알아둘 가치가 있습니다.

이러한 주의 사항에도 불구하고, 여기에는 실적이 있습니다. 더 가벼워진 리뷰는 실재하는 무언가에 기반하고 있습니다.

그것은 결코 일률적인 할인이 아니었습니다

그 할인에 관한 또 다른 점은 그것이 결코 모든 상황에 적용되는 일률적인 거래가 아니었다는 것입니다.

두 명의 주니어 (Juniors)가 페어링을 하면 보통 각자가 혼자 작업했을 때보다 더 나은 코드를 생성합니다. 진심으로 더 낫습니다. 하지만 여전히 시니어 (Senior)가 페어에 포함되었을 때 나오는 결과만큼 좋지는 않습니다. 저는 그 차이가 발생하는 것을 충분히 목격해 왔기에, 이를 직감이라기보다 확고한 규칙으로 취급합니다.

따라서 지름길은 결코 "페어링을 하면 리뷰가 가벼워진다"가 아니었습니다. 그보다는 "이 페어가, 이것을 작업함으로써, 가벼운 리뷰를 받을 자격을 얻었다"에 더 가까웠습니다. 리뷰를 수행하는 모든 사람은 비록 아무도 말로 내뱉지는 않았지만, 그 사실을 알고 있었습니다.

이는 제가 이 모든 내용을 글로 쓰고 싶게 만든 질문을 던지게 합니다... 만약 개발자 한 명과 에이전트 (Agent)가 한 쌍으로 간주된다면, 그것은 어떤 종류의 페어일까요?

AI 코드는 그러한 실적을 쌓지 못했습니다

여기서 조심스럽게 접근하고 싶습니다. 고려해야 할 사항이 많고 도구 (Tooling)가 빠르게 움직이고 있기 때문입니다. 하지만 제가 지금까지 본 바로는, AI가 생성한 코드 자체에는 많은 문제점이 수반됩니다. 보안 문제 (Security issues). 기능적 버그 (Functional bugs). 그리고 다른 무엇보다 저를 더 걱정하게 만드는 더 느린 문제... 사람들이 자신의 시스템에 대한 이해를 잃어버리는 것이며, 이는 시간이 흐를수록 해당 시스템을 수정하기 더 어렵게 만듭니다.

이 중 그 어떤 것도 가벼운 리뷰를 받을 자격을 부여하지 않습니다.

동시에 비용은 반대 방향으로 움직였습니다. 우리는 코드를 생성하는 비용이 어떻게 저렴해졌는지 모두 읽고 보아왔습니다. 하지만 그것을 평가하는 비용은 그렇지 않았습니다. 에이전트(Agent)의 그 어떤 것도 코드 읽는 속도를 빠르게 만들거나, 시스템을 머릿속에 담아두는 것을 쉽게 만들거나, 혹은 (에이전트가 아무리 자신만만하게 들리더라도) 잘못된 가정을 더 빨리 찾아내게 만들지 못했습니다.

이것들을 종합해 보십시오. 현재 많은 개발자가 에이전트와 함께 작업하고 있습니다. 만약 이것이 페어 프로그래밍 (Pairing)으로 간주된다면, 더 가벼운 리뷰를 받게 됩니다. 즉, 훨씬 더 많은 양의 코드가 나타나는 바로 그 시점에, 우리는 코드를 더 적게 읽게 됩니다. 게다가 그것은 단지 읽는 것만으로는 문제를 찾아내기가 가장 어려운 종류의 코드입니다.

그 비용은 그렇게 분류하여 제출한 팀에 머물지 않습니다. 그것은 사용자, 고객, 그리고 비즈니스에, 대개 훨씬 나중에 전가됩니다.

회의에서 아무도 이것을 결정하지 않을 것입니다

그것이 제가 오늘 고민하고 있는 부분입니다.

엔지니어링 팀의 그 누구도 일어나서 AI가 작성한 코드를 덜 주의 깊게 리뷰하자고 제안하지는 않을 것입니다 (적어도 그러지 않기를 바랍니다). 그런 식으로 일은 일어나지 않습니다. 일은 이미 존재하던 카테고리가 조용히 새로운 종류의 작업을 흡수하고, 그 카테고리에 붙어 있던 규칙이 함께 따라올 때 일어납니다. 개발자 + 에이전트 조합이 페어 프로그래밍이라 불리기 시작하고, 페어 프로그래밍은 이미 (리뷰의) 할인을 받고 있었으며, 그 할인은 아무도 명시적으로 결정하지 않은 채 그대로 전이됩니다.

대부분의 팀은 리뷰의 지름길(Shortcuts)을 물려받았으며, 무엇이 그 지름길을 얻게 해주었는지 기록해 둔 사람은 없을 것이기에 저는 놀라지 않을 것입니다. 따라서 기존 카테고리 아래에 분류되기를 요청하는 새로운 무언가가 나타날 때, 이를 대조하여 확인할 기준이 아무것도 없습니다.

그래서 제가 실제로 여러분께 요청하고 싶은 것과, 그에 따른 진짜 질문을 드리겠습니다.

여러 팀의 리뷰 지름길을 찾아보십시오. 페어 프로그래밍 코드에 대한 지름길, "이건 단순한 설정 변경일 뿐이야"라는 지름길, "이 사람의 PR은 항상 깔끔해"라는 지름길 같은 것들 말입니다. 그것들은 존재하며, 대부분 명문화되어 있지 않고, 여러분도 아마 더 이상 속해 있지 않은 팀으로부터 적어도 하나는 물려받았을 것입니다.

그런 다음 각 지름길이 무엇을 근거로 얻어진 것인지, 그리고 그 근거가 오늘 여러분이 머지 (Merge)하는 코드에도 여전히 유효한지 물어보십시오.

직접 찾아보았을 때 무엇을 발견하셨나요? 다른 팀들도 이런 현상이 일어나고 있다는 것을 포착했는지, 아니면 이미 너무 멀리 진행되어 명확히 확인하기 어려운 상태인지 매우 궁금합니다. 댓글을 남기는 것보다 직접 이야기를 나누고 싶으시다면, 언제든 제 편지함(inbox)은 열려 있습니다.