더 이상 작은 소프트웨어 팀은 없다

현명한 트롤이 예전에 말했죠:

> 복잡성 악마에 맞서는 최고의 무기는 마법의 단어: "아니요"

반대로, 저는 소규모 팀이 작게 유지될 수 있다고 믿습니다. 소규모 팀은 높은 속도, 커밋 수, 품질로 단순한 모놀리스를 출시할 수 있습니다. 서비스 지향이 에이전트 덕분에 갑자기 저비용이 된 것은 아닙니다. 독립적으로 버전을 관리하고 배포하는 여러 서비스 간의 경계는 여전히 다루기 까다로운 존재입니다. 그리고 "더 많은 에이전트를 실행하는 것"이 본질적으로 바람직하거나 영향력이 있는지도 분명하지 않습니다. 제 소규모 팀의 (물론 일화적인) 경험에 따르면 그 가치는 빠르게 포화 상태에 이릅니다.

저는 이미 이것이 오랜만에 들어본 최악의 조언일 것이라고 언급한 적이 있으며, 이런 사람을 제가 유지보수해야 할 코드베이스 근처에 두지 않을 것입니다.

하지만 이것은 본질적으로 블로그 스팸이기도 합니다. 저자는 의도적으로 자신의 주장에 전혀 도움이 되지 않고 읽기에는 너무 작은 두 개의 스크린샷을 포함했습니다. 두 번째 것을 클릭하면 더 큰 버전으로 이동하지 않고, 같은 스크린샷이 있는 회사 웹사이트의 첫 페이지로 이동합니다.

팀에서 시니어 인재가 충분히 이탈할 때까지 2년을 기다리세요. 그러면 모든 서비스가 매일 장애를 겪을 것입니다.

오늘날 시스템을 지탱하는 것은 자신의 시스템을 알고 있는 시니어들뿐이며, 그들은 쓰레기 커밋을 막아내고 있습니다.

그들이 번아웃되어 그만두면, LLM이 무엇을 했고 왜 서비스가 다운되었는지 아무도 감을 잡지 못할 것입니다.

사람당 하루에 약 10개의 PR을 배포할 수 있다는 것에 대해 저는 정말 회의적입니다. 그 PR들이 하나의 기능의 작은 조각이거나 즉시 리뷰할 수 있는 3줄 수정 같은 사소한 버그들이 아니라면 말이죠. 그렇지 않으면 AI가 올바른 수정이나 기능을 제대로 수행했는지 어떻게 확인할 수 있을까요? 당신이 그 기능을 그 방식으로 원했는지조차 어떻게 알 수 있을까요?

사람들이 자동화를 "팀"이라고 부르지 않았으면 좋겠습니다. 단지 "일을 한다"는 이유로 팀이라고 부른다면, CPU 코어와 스레드도 팀입니다. 확률적(지능적)이지는 않지만 말이죠. 그들도 일을 완수합니다.

우버가 수천 개의 마이크로서비스를 보유하게 된 것은 서비스 소유권을 성과 평가와 승진에 연결했기 때문이며, 수년 동안 그 수를 줄이려고 노력해 왔다는 것을 꽤 확신합니다. 이것이 의도적인 선택으로 해석되는 것을 보니 우습습니다.

`require('gulp')`를 보고 옛 기억이 확실히 떠올랐습니다. 확실히 우리가 약 10년 전에 코드를 작성하던 방식이죠. 저는 여전히 프로젝트당 멀티스레딩을 그다지 좋아하지 않습니다. 저는 두 개의 프로젝트를 두고 컨텍스트 창을 전환하는 것을 선호합니다. 현재 도구(적어도 제가 아는 것들)는 멀티스레딩에 다소 부족하다고 생각합니다. 하지만 지식을 업그레이드하려고도 노력 중입니다.

제가 찾은 좋은 방법은, OSS를 많이 하고 제 라이브러리를 가지고 있기 때문에, 그 라이브러리 중 하나에서 버그를 발견하면 메인 창에서 같은 프로젝트를 작업하면서 다른 창에서 라이브러리를 수정할 수 있다는 것입니다. 보통 메인 창에 "지금은 건너뛰자, 라이브러리를 수정 중이야"라고 말해야 합니다.