시니어 개발자들이 자신의 전문성을 전달하는 데 실패하는 이유

다음 문장에 대해 어떻게 느끼시나요:

“AI 에이전트 (AI agents)는 소프트웨어 개발의 미래입니다. 비즈니스의 진행 속도를 늦추는 개발자는 더 이상 필요하지 않을 것입니다.”

만약 당신이 시니어 개발자이고 이 말이 사실이라고 생각한다면, 저는 당신의 전문성에 대해 다소 의구심이 듭니다 (그 이유를 설명하겠지만, 불필요하게 적대적인 것은 아닙니다).

하지만 만약 당신이 시니어 개발자가 아니고 이 말이 사실이라고 생각한다면, 저는 당신이 아마 맞을 것이라고 생각합니다.

네? 이게 어떻게 된 일일까요?

카피라이팅 (Copywriting)은 본질적으로 메시지를 청중 (audience)에게 맞추는 일입니다.

그래서 카피라이터인 저에게 있어, 여기서 일어나고 있는 일은 동일한 메시지가 두 명의 서로 다른 청중에게 두 가지 서로 다른 의미로 다가가는 것입니다.

만약 당신이 시니어 개발자이고, 사람들을 놀라게 하고 있는 에이전트 (agents), 스킬 (skills), 모델 (models) 및 그 외 모든 것들을 다뤄보았으며, 당신의 직관이 사람들이 당신의 직업이 쓸모없어질 것이라고 선언하는 방식에 무언가 잘못되었다고 말하고 있다면, 이 포스트를 통해 저는 (유능한 카피라이터가 그러하듯) 당신의 직관을 언어로 표현해 보려고 합니다.

하지만 잠깐만요! 숙련되고 유명한 많은 개발자들 또한 개발자의 종말을 선언하고 있습니다.

어떻게 된 일일까요? 누구의 직관이 맞는 걸까요? 그리고 무엇이 이러한 차이를 만드는 걸까요?

제가 팀에 합류할 때, 저는 두 종류의 시니어 개발자를 만납니다.

첫 번째 유형은 다음과 같이 말합니다:

“이 새로운 도구를 찾았는데 꽤 멋지네요 ...”

“<우리가 있는 곳과는 완전히 다른> 이 회사는 이런 방식으로 일을 하니까, 그러니 …”

“여기 이것이 베스트 프랙티스 (best practice)라고 말하는 HackerNews 포스트를 보세요, 아마 우리는 …”

저는 이런 종류의 시니어 개발자를 좋아하지 않습니다. 약간 자기방어적이고, 업계에서 많은 시간을 보냈으며, 아마도 대인 관계가 좋을 것입니다.

하지만 저와는 결이 맞지 않습니다.

그리고 이런 종류의 시니어 개발자도 있습니다:

“그게 정말 필요한가요?”

“만약 우리가 이걸 하지 않으면 어떻게 되죠?”

“일단은 그냥 버틸 수 있을까요? 나중에 이게 더 중요해지면 그때 다시 돌아오면 안 될까요?”

아, 바로 이분입니다, 나의 시니어 개발자. 회피자(avoider), 축소자(reducer), 재활용자(recycler). 이들은 가능한 한 개발을 피하고 싶어 합니다.

왜일까요? 전문적인 소프트웨어 개발(software development)에서 단 하나의 괴물을 사냥하기 때문입니다. 바로 복잡성(complexity)입니다.

특수 사례(special cases), 조건문(if conditions), 새로운 데이터베이스 테이블(database tables), 새로운 컴포넌트(components). 모두 끔찍한 것들입니다. 시니어 개발자는 이런 것들을 최대한 적게 가지길 원하며, 코드를 반드시 추가해야만 하는지 확인하는 데 많은 시간을 소비합니다.

시스템에 무언가를 추가하는 것은 더 큰 복잡성을 초래할 위험이 있기 때문입니다.

네, 맞습니다. 물론 이것은 단순화된 설명입니다. 해결되지 않은 문제를 맡아 새롭고 창의적인 설계(design)를 찾아내는 데 탁월한 시니어 개발자들도 있습니다.

하지만 결국, 당신이 작동 중인 시스템에 대한 책임을 지고 있다면, 당신은 복잡성을 두려워하게 됩니다.

자, 왜 그럴까요? 복잡성의 단점은 무엇일까요? 그리고 왜 다른 사람들은 이를 이해하지 못할까요?

우리는 두 개의 루프(loop)를 사용하여 비즈니스(business)가 무엇인지 단순화해 볼 것입니다.

이것이 첫 번째 루프입니다. 마케터(marketers), 영업 사원(salespeople), 제품 관리자(product managers), CEO는 모두 이곳에 속해 있습니다.

이 루프의 주요 목표는 학습을 시도하는 것입니다. 비즈니스는 제품을 시장에 내놓고, 그것이 가치 있는 것인지 아닌지에 대한 피드백(feedback)을 받고 싶어 합니다.

이 루프에 속한 사람들에게 괴물은 불확실성(uncertainty)입니다.

그리고 불확실성은 잔인합니다. 어떤 전략도 반드시 성공한다는 보장이 없기 때문입니다. 여기에 시간(마케팅/영업 비용, 창업자의 급여, 또는 제품 관리자를 위한 데이터)이 결합되면, 마감일 전에 불확실성을 줄이는 유일한 방법은 가능한 한 빨리 제품을 시장에 내놓는 것처럼 느껴질 수 있습니다. 시장에 더 많이 내놓을수록, 더 많은 피드백을 받을 수 있고, (잠재적으로) 불확실성을 더 많이 줄일 수 있습니다.

이 루프, 그리고 모든 회사가 시작하는 이 루프는 순수하고 가공되지 않은 속도(speed)에 관한 것입니다.

하지만 비즈니스가 고객을 확보하면 어떻게 될까요?

아, 이제 우리의 두 번째 루프가 등장합니다. 서비스에 비용을 지불하는 사람들입니다.

이 루프는 많은 시니어 개발자들이 처하게 되는 곳입니다. 이 루프의 주요 목표는 서비스의 지속과 보장(guarantee)입니다.

상태를 유지하고, 이해 가능하게 유지하고, 디버깅 가능하게 유지하고, 수정 가능하게 유지하고, 교육 가능하게 유지하고, 안정적으로 유지하는 것입니다.

시니어 개발자들은 비즈니스가 고객에게 서비스를 계속 제공할 수 있도록 책임을 지기 때문에 안정성에 대해 걱정합니다.

그리고 그 모든 것을 위협하는 것은 무엇일까요?

복잡성 (Complexity)입니다.

복잡성은 시스템을 덜 이해하기 쉽게 만들고, 디버깅하기 어렵게 만들며, 수정하기 어렵게 만들고, 교육하기 어렵게 만들며, 궁극적으로는 덜 안정적으로 만듭니다.

복잡성 증가 = 안정성 저하 = 시니어 개발자의 책임 실패 = 매우 나쁘고 좋지 않음, 결제 중단, 모두가 슬퍼함.

따라서 첫 번째 루프의 목표가 불확실성 감소 (uncertainty reduction)였다면, 두 번째 루프의 목표는 복잡성 관리 (complexity management)입니다.

하지만 왜 이것이 소통의 실패로 이어질까요?

고객이 생기면 두 루프가 동시에 돌아가기 때문입니다. 비즈니스는 가능성을 탐색하는 동시에 고객에게 서비스를 제공해야 합니다.

자, 이제 여러분은 이 포스트의 제목에 대한 제 답을 찾아낼 수 있을지도 모릅니다.

여러분이 어떤 루프에 시간을 쓰느냐에 따라 여러분의 문제는 다르게 정의됩니다 (이것이 제가 개발자들이 AI에 대해 의견이 갈린다고 생각하는 이유입니다. 어떤 이들은 다른 루프보다 한쪽 루프에서 더 많이 작업합니다).

이것은 첫 번째 루프에 있는 사람들의 이야기였습니다:

하지만 이것은 두 번째 루프에 있는 시니어 개발자의 이야기였습니다:

두 이야기는 일치하지 않습니다.

시스템을 구축하고 추가해달라는 요청이 많아질수록, 시니어 개발자는 "어어, 복잡성... 유지보수 비용... 이해 가능성... 개발 지속 속도... 시간이 흐름에 따른 생산성..."이라며 대응하고 싶어 합니다.

하지만 이는 불확실성을 줄이려는 비즈니스의 나머지 요구사항을 해결하는 데 아무런 도움이 되지 않습니다.

카피라이터의 진단: 당신의 문제를 사용하여 타인의 문제를 설명해 없앨 수는 없습니다.

카피라이터의 처방: 당신의 해결책을 그들의 문제에 대한 해결책으로서도 설명해야 합니다.

시니어 개발자들이 소통에 실패하는 이유는, 불확실성 감소 (uncertainty reduction)의 관점에서 해결책을 설명해야 할 때 복잡성 관리 (complexity management)의 관점에서 자신의 문제를 표현하기 때문입니다.

회사의 나머지 구성원들이 찾고 있는 것이 불확실성 감소라는 점을 인정함으로써, 시니어 개발자는 자신의 전문성을 활용해 도움을 줄 수 있습니다.

그렇다면 시니어 개발자가 가진 가장 유용한 기술은 무엇일까요? 그것은 불필요한 것을 만들기를 주저하는 마음, 그리고 이미 만들어진 것을 재사용할 기회를 포착하는 능력입니다.

설문 데이터를 수집해야 하나요? Google Forms를 쓰세요.

테스트를 위해 완전히 새로운 기능을 만들어야 하나요? 기존 UI에 버튼을 하나 달아서 사람들이 클릭하는지 확인해 보는 건 어땠나요?

새로운 분석 서비스가 필요한가요? 분석이 필요한 가장 중요한 결정이 무엇인가요? 하나의 결정, 하나의 차트, 하나의 지표로 시작할 수 없을까요?

나를 위해 생일 케이크를 통째로 구워주고 싶나요? 그냥 내 샌드위치 위에 초 하나만 꽂아주세요.

이것이 바로 시니어 개발자들이 배우는 방식입니다. 그들은 기존 소프트웨어를 자원 활용적으로 사용하여 사람들이 원하는 것을 제공하는 법을 배웁니다.

하지만 긴 에세이를 보내지 않고 어떻게 이를 전달할 수 있을까요?

카피라이터들은 여러 신호를 하나의 문구로 응축하는 것을 좋아합니다. 그래서 모든 시니어 개발자가 반드시 배워야 할 마법 같은 문구가 있습니다: ‘더 빠르게 시도해 볼 수 있을까요? (Can we try something quicker?)’

‘더 빠르게 (quicker)’라는 표현은 그들이 실제로 찾고 있는 것을 인정하며, ‘무언가 (something)’는 그것을 달성하는 또 다른 방법을 암시하고, ‘시도 (try)’는 불완전함을 암시하면서도 동시에 그것이 충분히 괜찮을 가능성을 내포합니다.

이 문구는 불확실성을 줄이기 위한 속도라는 회사 구성원들의 요구사항을 완벽하게 관통하는 동시에, 시니어 개발자가 자신의 전문성인 축소, 재사용, 그리고 인생이 정말 축복이라면 '회피'하는 능력을 발휘할 수 있게 해줍니다.

그게 전부입니다. 이것이 이 포스트의 제목에 대한 저의 답변입니다: 시니어 개발자들은 다른 모든 이들이 불확실성을 걱정할 때 복잡성의 관점에서 이야기합니다.

하지만! 아주 큰 반전이 있습니다!

이제 AI가 이 모든 것을 무의미하게 만드는 것처럼 보이지 않나요? 왜 줄여야 하죠? 왜 재사용해야 하죠? 왜 피해야 하죠? AI는 아주 짧은 시간 안에 아주 많은 것을 만들어낼 수 있으니까요.

아, 글쎄요, AI는 시니어 개발자들이 여전히 하고 있는 단 한 가지는 아직 하지 못합니다.

책임을 지는 것 (Take responsibility).

시니어 개발자들은 시스템을 이해하는 것에 매우 신경을 씁니다. 왜냐하면 이해를 해야만 상황이 잘못되었을 때 이를 수정할 수 있기 때문입니다. 시스템이 확장되어야 할 때 지능적으로 확장하는 것을 가능하게 합니다. 그리고 무엇보다도, 비용을 지불하는 고객들에게 지속적이고 신뢰할 수 있는 서비스를 제공하는 것을 가능하게 합니다.

AI는 이러한 이해 가능성 (understandability)을 위협합니다. AI는 제품을 시장에 내놓는 속도를 높이는 데는 놀라운 능력을 보여주지만, 시니어 개발자들이 책임을 지고 있는 또 다른 루프 (loop)에도 영향을 미칩니다.

만약 여러분이 수많은 AI 에이전트 (AI agents), 주니어 개발자, 비개발자, 그리고 투자자와 그들의 어머니까지 시스템에 코드를 추가하고 있다면, 여러분은 안정성을 포기함으로써 속도에 과하게 보상하는 시스템을 얻게 될 것입니다.

이것은 두 개의 루프로 이루어진 비즈니스였습니다:

그리고 이것이 AI가 두 루프에 영향을 미치는 방식입니다:

안정성을 유지하는 것은 잊으세요, AI는 그야말로 불안정화 요소 (destabilizer)입니다. AI는 이해 가능성 (understandability), 수정 가능성 (fixability), 디버깅 가능성 (debuggability), 교육 가능성 (teachability), 보장 가능성 (guaranteability), 즉 모든 빌리티 (bilities)를 악화시킵니다.

AI는 이 모든 일을 저지르면서 아무런 책임도 지지 않습니다.

좋지 않죠. 이것이 바로 무시당하고 있는 시니어 개발자의 주요 걱정거리입니다.

다행히도, 시니어 개발자들에게는 몇 가지 비책이 있습니다.

바로 디커플링 (decoupling)입니다.

오랫동안 소프트웨어 개발자들은 소프트웨어를 만들 수 있는 유일한 사람들이었습니다. 그들은 두 루프 모두에 책임을 졌습니다.

그것은 두 가지 목표를 지원하는 하나의 시스템이었습니다.

만약 각 목표를 위한 시스템을 각각 하나씩, 즉 두 개의 시스템을 갖게 된다면 어떨까요?

비유를 들자면: 소설가는 초안 (흔히 'vomit draft'라고 불리는)을 완성하기 위해 서두르고, 나중에 잘 작동하는 부분을 추출하고 그렇지 않은 부분을 제거합니다. 초기 급속 집필 이후에는 편집 과정이 있습니다. 편집자의 역할은 잘 작동하는 부분들을 가져와서 그것들을 모두 응집력 있는 하나의 전체로 형성하는 것입니다.

만약 오직 속도만을 위한 하나의 시스템이 있다면 어떨까요? 무언가를 구현하는 데 집중하는 모든 이들이 여기서 일할 수 있을 것입니다. AI 에이전트(AI agents), 우리가 직접 생성하고 검토하지 않은 코드, 주니어 개발자(junior devs), 마케팅 등 말이죠.

우리는 이것을 시스템의 ‘속도(Speed)’ 버전이라고 부를 수 있습니다. 이것은 이해하기 쉽게 만드는 것이 목적이 아니라, 피드백을 받기 위해 시장에 내놓을 수 있을 만큼 충분히 괜찮은 결과물을 만드는 것이 목표입니다.

그렇다면 안정성에 집중하는 두 번째 시스템이 있다면 어떨까요?

우리는 이것을 시스템의 ‘규모(Scale)’ 버전이라고 부를 수 있습니다. 이것은 시니어 개발자(senior developers)들에 의해 안정적이고, 이해 가능하며, 확장 가능한(scalable) 구조로 설계됩니다.

‘속도’ 버전은 비즈니스의 나머지 부분들이 시장으로부터 계속해서 배울 수 있게 해주는 한편, 시니어 개발자들은 잘 검토되고 이해 가능한 후행 버전의 시스템을 구축합니다.

게다가, ‘규모’ 버전의 설계는 시스템의 ‘속도’ 버전에서 무엇이 작동했고 무엇이 작동하지 않았는지에 의해 영향을 받습니다.

기능들은 ‘속도’ 버전에서 구축되지만, 이후 ‘규모’ 버전에서 안정화됩니다.

이것이 실제 현장에서 어떻게 나타날지는 불분명할 수 있지만, 핵심 아이디어는 속도를 추구하는 것과 안정성을 추구하는 것 사이에는 차이가 있다는 점을 설명하는, 잘 전달된 디커플링(de-coupling, 결합 해제)을 갖는 것입니다.

당신이 야심 찬 무언가를 만들어 달라는 요청을 받았을 때, 다음과 같이 말한다고 상상해 보세요.

“물론이죠, 3일 안에 ‘속도’ 버전을 준비하겠습니다. 그러고 나서 약 6주 안에 ‘규모’ 버전을 완성하겠습니다.”

그들은 그들이 원하는 것, 즉 속도와 추진력을 얻습니다. 당신은 당신이 원하는 것, 즉 관찰과 설계를 얻습니다.

그럴까요?

시니어 소프트웨어 개발자(senior software developer) 여러분, 어떻게 생각하시나요?

아니면, 시니어 소프트웨어 에디터(senior software editor)라고 불러야 할까요?