AI 시대, 좋은 결과물을 알아보는 눈은 어떻게 기를까

AI에 전적으로 위임한 개발자들은 가장 빨리 끝냈지만 평가에서는 가장 낮은 점수를 받았습니다.

가장 무서운 점은 자신이 점점 둔해지고 있다는 것을 전혀 알아채지 못한다는 것입니다.

코드를 리뷰하지 말고 스펙과 아키텍처를 리뷰하라. 개발자 커뮤니티가 찾아낸 답입니다.

리뷰 패러독스

커뮤니티에서 널리 인용된 관찰이 하나 있는데, AI에게 전적으로 위임한 개발자들이 작업 속도는 가장 빨랐지만 평가에서는 가장 낮은 점수를 받았다는 것입니다. 그리고 AI의 생산성 혜택을 가장 많이 받는 초보자가, 정작 AI를 감독하려면 가장 필요한 디버깅 역량을 AI에게 가장 먼저 잠식당합니다.

AI를 많이 쓸수록 그것을 리뷰할 자격이 줄어듭니다. 이것을 리뷰 패러독스라고 부르는데, 많이 쓰는 것과 리뷰할 자격을 잃는 것은 애초에 분리할 수 없기 때문입니다.

좋은 결과물을 알아보는 눈은 좋은 결과물에 대한 글을 읽어서 생기는 것이 아니라, 직접 서툴게 해보고 깨지고 수년간의 실전을 통해 감각을 쌓아야 생깁니다.

비개발 직군에도 그대로 적용된다

이 주제는 개발자 커뮤니티에서 뜨겁게 다뤄지고 있지만, 사무직과 비개발 직군에도 똑같이 적용됩니다.

AI가 실행 업무의 대부분을 해주기 시작하면 우리에게 남는 것은 리뷰, 관리, 기획, 전략인데 멋지게 들립니다.

그런데 우리는 그 일들을 애초에 허드렛일을 직접 하면서, 실수를 하고 교정을 받으면서 배웠습니다. 결과물을 리뷰할 수 있는 판단력은 그 일을 직접 수백 번 해봤기 때문에 생긴 것입니다.

그것을 빼앗기면 AI가 실행하고 나는 결과물만 리뷰하는데, 정작 좋은 결과물이 무엇인지 판단할 근육이 없습니다. 그리고 가장 무서운 점은 자신이 둔해지고 있다는 것을 전혀 알아채지 못한다는 것입니다.

스펙을 리뷰하라

개발자 커뮤니티에서는 이미 이 문제를 풀려는 움직임이 시작됐고, 핵심 원칙은 하나입니다. 코드를 리뷰하지 말고 스펙과 아키텍처를 리뷰하라.

코드가 작성되기 전에 제대로 된 스펙을 먼저 쓰면서 문제를 명확히 정의하고, 트레이드오프를 이해하고, 비즈니스 언어를 제품 요구사항으로, 제품 요구사항을 기술 아키텍처로 번역합니다. 사람은 스펙과 아키텍처, 그리고 검증 계획을 읽고 리뷰하면서 무엇이 만들어지고 있고 왜 만들어지는지를 실제로 이해하는 것입니다.

그다음에 AI가 코드를 쓰고 코드가 스펙을 따르는지 확인하는데, 규정 준수 여부를 확인하는 것은 AI가 잘하는 일이고 스펙 자체가 맞는지 판단하는 것은 사람이 해야 할 일입니다.

일부 팀에서는 이것을 의무화하고 있는데, 강제하지 않으면 아무도 하지 않고 다들 흐름대로 작업하다가 나오는 대로 그냥 올려버리기 때문입니다.

타이핑이 전부였던 적은 없다

이 상황을 가장 잘 요약하는 문장은 이것이었습니다.

"소프트웨어 엔지니어링은 코드를 타이핑하는 것이 전부가 아니었다. 문제를 잘 정의하고, 문제를 이해하고, 비즈니스에서 제품으로, 제품에서 코드로 언어를 번역하고, 모호함을 해소하고, 트레이드오프를 결정하고, 무엇을 바꾸면 무엇이 깨지는지를 이해하는 것이다."

여기서 소프트웨어 엔지니어링을 아무 지식 노동으로 바꿔도 그대로 성립합니다.

답을 받아먹지 않는 연습

클로드에는 러닝(Learning)이라는 설정이 있는데, 답을 바로 주는 대신 질문을 주고받으면서 실제로 가르쳐주는 방식입니다.

몇 달 전이었다면 물어보지 말고 그냥 해달라고 생각했을 텐데, 핵심이 판단력과 이해력을 계속 키우는 것이라면 답을 그냥 받아먹는 것이야말로 최악의 방법입니다.

스펙 레벨에서 제대로 개입하면 오히려 상황이 나아지는데, 기계적인 실행이 아니라 가장 중요한 부분에 시간을 쓰게 되기 때문입니다.

Bloom과 함께하기

Bloom은 사람과 기술이 만나는 오프라인 자리를 만듭니다. 다음 행사에서 뵙겠습니다.

• 💬 디스코드 커뮤니티, 행사 공지가 가장 먼저 올라옵니다
• ▶️ 유튜브, 지난 행사 강연 다시 보기
• 📸 인스타그램, 행사 사진
• 🎟️ 다가오는 행사 보기