코드 리뷰도, 팀 분리도, 깊은 전문성도… 이제는 '나쁜 아이디어'가 아니다
Bad ideas that aren't bad anymore
15년 경력의 엔지니어링 리더가 최근 팀 운영에서 겪은 변화를 공유한다. PR 리뷰를 없애고 Claude가 코드를 작성하면 담당자가 리뷰하는 방식, 팀을 독립된 작업 스트림으로 나누는 방식, 그리고 깊은 기술 전문성 대신 기본기와 제품 감각을 강조하는 조언이 모두 예상과 달리 잘 작동하고 있다. 핵심은 AI 덕분에 컨텍스트 전환 비용이 급감하면서 '지식'보다 '판단력'이 더 중요해졌다는 것이다.
이제 나는 사람들에게 거의 정반대의 조언을 하고 있다. 특정 기술에 대한 깊은 전문성은, 그 프레임워크의 소스 코드를 모두 읽고 몇 초 만에 어떤 질문에도 답할 수 있는 협업자가 있을 때 훨씬 덜 가치 있다.
HN 토론
78- sn
저는 프린시펄 엔지니어입니다. 프로덕션 소프트웨어에서는 코드 리뷰가 여전히 중요합니다.
어쩌면 당신은 제가 바이브 코딩을 충분히 열심히 하지 않는다고, AI를 더 잘 썼다면 코드 리뷰가 필요 없을 거라고 생각할지도 모르겠네요. 저는 동의하지 않습니다. 엔지니어든 LLM이든 여전히 불필요한 복잡성을 더하거나 나중에 문제를 일으킬 잘못된 추상화를 선택하고, 모든 코너 케이스를 고려하지 않으며, 에러 상황에 대한 잘못된 처리를 고릅니다. 그들은 자신들에게 좋은 아이디어처럼 보이는 것들을 추가하고 스펙을 지키지 않습니다.
만약 우리 회사가 중요한 소프트웨어에 대한 코드 리뷰를 중단한다면, 저는 그만둘 겁니다.
스타트업의 압박에 시달리지 않는 엔지니어들은 LLM을 더 빠르게가 아니라 더 잘 코딩하는 데 사용하는 것을 목표로 해야 합니다. 더 빠르게는 기술 부채만 쌓고 장기 비용을 높일 뿐입니다.
- xg15
이 다양한 예시들에서 공통적으로 보이는 주제는 다음과 같습니다:
"예전에는 각 팀원이 우리 코드베이스에 대한 경험과 전문성을 쌓도록 주의하고, 지식 사일로가 형성될 수 있는 역학을 피해야 했습니다. 이제는 모든 사람이 Claude에게 모든 것을 설명해 달라고 요청할 수 있기 때문에 이런 것들은 더 이상 중요하지 않습니다."
솔직히 말해서, 저는 그렇게 확신하지 않습니다. 단기적으로는 그렇습니다, 효과가 있습니다. 하지만 장기적으로는 마치 아주 좋은 책은 있지만 그 일에 대한 직접적인 경험이 전혀 없는 것과 같을 수 있습니다. 우리 모두는 붐 지식이 학습된 경험과 다르다는 것을 알고 있습니다.
- ro_sharp
왜 그렇게 많은 사람들이 코드 리뷰가 주로 불신이나 실수 찾기에 관한 것이라고 생각할까요?
제 생각에는 코드 리뷰는 단지 지금 일이 어떻게 변하고 있는지뿐만 아니라 앞으로 어떻게 변할지에 대한 공유된 이해와 합의를 보장하는 데 주로 관한 것입니다.
- kbiessy
이 목록에서 제가 가장 잘 아는 항목에 대해 이야기하겠습니다. "구매 대신 구축"이 제가 의문을 제기하고 싶은 항목입니다.
도구를 작성하는 비용은 대부분 사라졌다는 점에는 동의합니다. 소유 비용은 그렇게 많이 변하지 않았다고 생각합니다. 제가 아는 몇몇 작은 회사의 소프트웨어 스택을 돌봐 온 경험에 비추어 보면, 맞춤형 도구들이 결국 가장 큰 골칫거리가 됩니다. API 호출이 깨지거나 그것을 만든 사람이 떠나기 전까지는 아무도 그것이 맞춤 제작되었다는 것을 기억하지 못합니다. 유지보수 비용이 특히 높다고 생각합니다.
한나절 만에 만드는 것이 장기 유지보수를 해결해 주지도 않고, 기능적 지식도 제공하지 않습니다. 제너럴리스트들은 AI로부터 많은 이점을 얻을 수 있지만, 미래에도 소프트웨어를 안내하고 유지하는 전문가의 역할은 여전히 클 것입니다.
- ahartmetz
>팀 내 누구도 모르는 언어나 도구를 도입하는 것은 [이제 나쁜 아이디어가 아니다]
좋아요, 이제 그 사람이 헛소리를 하고 있다는 게 확실해졌네요.