기술 용어의 소용돌이 속에서 끝없이 소용돌이치는 것이 아니라, 효과가 있는 기존 도구를 채택하여 당면한 비즈니스 문제에 적용하고 비즈니스 영역에서 빠르게 반복하는 것은 안타깝게도 과소평가되고 있습니다. 저는 이전에 두 종류의 회사에서 일한 적이 있습니다:
측정 가능한 비즈니스 성과에만 신경을 써서 기술 부채를 쌓고 아무도 코드베이스로 작업하기를 원하지 않을 때 엔지니어를 비난하여 궁극적으로 제품에 손상을 입히는 회사. 다른 하나는 엔지니어가 하루 종일 린터 구성에 시간을 보내고 거의 읽지 않는 RFC를 작성하는 반면, 후배들은 셀러리를 버리고 카프카가 최신 유행이라는 이유로 카프카를 사용하려고 하는 경우입니다.
둘 다 똑같이 나쁘지만, 기술자들은 전자를 좋아하면서 후자에 대해서는 행복하게 무지한 채로 지냅니다. 아마도 그렇게 할 인센티브가 없고 이력서 중심 개발1이 진정으로 더 나은 보상을 받기 때문일 것입니다. 회사가 사람들에게 직무와 상관없는 모호한 퍼즐을 풀게 하거나 채용 관리자가 이력서에서 키워드를 찾는 자동화 시스템을 계속 사용하는 한, 똑똑한 사람들은 항상 다음 큰 기회를 준비하기 위해 테크노 맥시멀리즘에 빠져서 기본 제품을 실패에 대비하게 될 것입니다.
회사의 규모가 커지고 확고한 입지를 다질수록 두 번째 유형의 특성이 더 많이 나타나기 시작합니다. 여기에 일벌들이 밑에서 무엇을 요리하고 있는지 전혀 모르는 중간 관리자가 가세하면 재앙의 완벽한 레시피가 완성됩니다. 보푸라기나 단추를 고치기 위해 터무니없는 돈을 긁어모으는 것이 세상에서 최악은 아닐 수 있지만, 이 지루한 사람들이 상상의 문제를 해결하기 위해 터무니없이 복잡한 도구를 도입하여 건축 우주비행사가 되겠다는 꿈을 꾸지 않는다면 말입니다.
회사가 개발자 생산성을 정량화하기 위해 LOC, PR 횟수 또는 기능 티켓 수와 같은 쓸모없는 메트릭을 도입하기 시작하면 상황은 더욱 악화됩니다. 이는 종종 불필요한 티켓 생성으로 이어지고 개발자가 모범 사례, 미세 최적화, 무료 기능 및 핵심 비즈니스 로직 이외의 모든 것에 대해 끝없이 토론하는 악순환의 PR 사이클을 시작하게 됩니다. 비즈니스 로직에 대한 작업이 보상을 받지 못한다면 누가 더 나은 로직을 만드는 데 집중할 이유가 있을까요? 재시도 데코레이터를 작성하고 작동 여부를 모니터링하는 것보다 RPC의 호출 경로에 데드 레터 큐를 도입하는 것이 훨씬 더 수익성이 높습니다.
마이크로서비스가 더 이상 유행하지 않고, 수많은 회사가 그 정도의 매출이나 인력이 없음에도 불구하고 넷플릭스의 작업 방식을 채택했다가 낭패를 본 지금, PostgreSQL 기반의 Django 모놀리스로도 충분할 텐데 SoA를 채택하는 것이 얼마나 나쁜지에 대한 기사2는 부족하지 않습니다. 또한 간단한 비정규화된 보조 인덱스로 충분할 때 GraphQL이 얼마나 끔찍한지, 또는 JavaScript 프런트엔드 프레임워크의 높은 이탈률로 인해 시간, 노력, 비용이 얼마나 낭비되었는지에 대해서도 언급합니다. 하지만 조직 구조와 정책이 어떻게 사람들이 그런 길을 택하도록 강요하는지에 대해서는 거의 언급하지 않습니다.
개발자가 기술 부채를 발생시키거나 개발 프로세스를 악몽으로 만들지 않고도 가장 큰 가치를 창출하는 핵심 비즈니스 로직에 집중할 수 있는 중간 지점이 있어야 합니다. 저는 이에 대한 해답을 가지고 있지 않으며, 완벽한 균형을 찾은 회사에서 일한 적도 없습니다. 게다가 저는 기술 책임자, 관리자, 비즈니스 소유자도 아닙니다. 따라서 여러분도 이러한 상황에 처해 있다면 여러분 또는 여러분의 조직이 이 문제를 어떻게 해결할 계획인지 듣고 싶습니다.
