스택 선택은 기술적 결정이 아니라 사회적 결정이다

Source: Dev.to

죄송합니다만, 번역하려는 전체 텍스트를 제공해 주시면 한국어로 번역해 드리겠습니다. 현재는 링크만으로는 실제 기사 내용을 확인할 수 없습니다. 번역이 필요한 본문을 복사해서 보내 주세요.

개요

개발자 그룹에게 왜 특정 기술 스택을 선택했는지 물어보면 다음과 같은 답변을 들을 수 있습니다:

• “스케일링이 더 잘 됩니다.”
• “속도가 더 빠릅니다.”
• “더 최신 기술입니다.”
• “업계 표준입니다.”

하지만 대부분의 사람들이 입 밖에 내지 않는 불편한 진실이 있습니다:

대부분의 기술 스택은 기술적으로 우수해서 선택되는 것이 아니라, 사람 때문에 선택됩니다.

그리고 이 사실을 한 번 알게 되면, 다시는 눈을 돌릴 수 없습니다.

“최고 스택”이라는 신화

우리는 소프트웨어 결정이 합리적이라고 믿고 싶어합니다. 성능 벤치마크, 생태계 성숙도, 확장성 차트를 비교하면 어느 한 스택이 명확히 최고의 선택으로 떠오른다고 생각하죠.

실제로 대부분의 현대 스택은 충분히 좋습니다.

• React, Vue, Angular.
• Spring, Node, Django.
• Postgres, MySQL, MongoDB.

어느 정도 수준에 이르면 차이가 결정적이지 않게 됩니다. 그렇다면 왜 팀들은 여전히 스택에 대해 열정적으로 논쟁할까요? 그 결정은 실제로 코드에 관한 것이 아니라 사람, 신뢰, 인센티브, 그리고 두려움에 관한 것이기 때문입니다.

스택 선택은 누굴 고용할 수 있느냐에 관한 것

가장 영향력 있지만 논의가 적은 스택 선택 이유 중 하나:

“이걸 위해서 채용할 수 있나요?”

다음이 아니라:

• “가장 우아한 해결책인가?”
• “가장 깔끔한 아키텍처인가?”

하지만:

• 개발자를 구할 수 있나요?
• 신규 채용자가 빠르게 온보드될 수 있나요?
• 이 때문에 후보자들이 겁을 먹지는 않을까요?

기술적으로 “더 나은” 스택이라도 아무도 모르면 비즈니스 위험이 될 수 있습니다. 팀은 최적의 스택을 선택하지 않습니다; 살아남을 수 있는 스택을 선택합니다.

친숙함이 매번 탁월함을 이긴다

여기에는 어려운 진실이 있습니다: 팀은 더 나은 스택보다 이해하는 스택을 선호합니다.

왜일까요? 친숙함은 다음을 감소시킵니다:

• 위험
• 두려움
• 의사결정 피로
• 책임감

친숙한 스택에 문제가 생기면 모두가 디버깅 방법을 알고 있습니다. “똑똑한” 스택에 문제가 생기면 누군가가 비난을 받습니다. 그래서 사람들은 이전에 사용해 본 것을 기본으로 선택합니다 — 최고라서가 아니라 방어 가능하기 때문에.

기술 스택 결정은 정치적이다 (예, 정치적)

많은 기업에서 스택 선택은 다음에 의해 형성됩니다:

• 방 안에서 가장 큰 소리를 내는 사람
• 가장 선임된 엔지니어
• 아키텍트의 과거 경험

때때로 스택은 단순히 다음과 같은 이유로 선택됩니다:

“제가 이전 직장에서 사용했던 것이고, 잘 작동했어요.”

그것은 기술적인 이유가 아닙니다. 사회적 증거입니다. 그리고 그것은 놀라울 정도로 강력합니다.

“Modern” 종종 “사회적으로 받아들여짐”을 의미한다

스택이 갑자기 “현대적”이 되는 경우를 살펴보세요:

• 대기업이 채택할 때
• 인플루언서가 항상 언급할 때
• 채용 공고에 언급될 때

“현대적”이라고 해서 더 좋다는 뜻은 아닙니다. 설명 없이 선택해도 안전하다는 의미인 경우가 많습니다. 인기 있는 스택을 선택하면 의사결정자를 보호할 수 있습니다. 만약 실패하더라도 그들은 무모한 것이 아니라 트렌드를 따랐을 뿐입니다.

모든 스택 선택 뒤에 숨은 질문

Not:

• “Is this the fastest?”
• “Is this the cleanest?”

But:

• 누군가 나에게 책임을 돌릴까요?
• 이것이 채용을 지연시킬까요?
• 이것이 시작을 더 오래 걸리게 할까요?
• 유지보수가 필요할 때 팀에게 복잡해질까요?

이것이 스택 논쟁이 끝나지 않는 이유

스택 논쟁이 거의 합의에 이르지 못한다는 것을 눈치채신 적 있나요? 그 이유는 여러분이 코드를 논의하는 것이 아니라 다음을 논의하고 있기 때문입니다:

• 정체성
• 경험
• 자아
• 위험 감수성

두 개발자가 같은 문제를 바라보면서도 서로 다른 스택을 선택할 수 있습니다—둘 다 타당한 사회적 이유 때문이며, 어느 쪽도 “잘못된” 것이 아닙니다.

왜 이것이 중요한가 (특히 개발자를 위해)

이것을 이해하면 다음에 대한 사고 방식이 바뀝니다:

• 경력 성장
• 학습 우선순위
• 프로젝트 결정

다음 이유를 설명합니다:

• “열악한” 스택이 살아남는다
• “우수한” 스택이 사라진다
• 레거시 시스템이 지속된다
• 단순한 도구가 지배한다

또한 “최고” 기술만 배우는 것이 충분하지 않은 이유를 설명합니다. 중요한 것은:

• 팀이 그것을 사용할 수 있는가?
• 사람들이 유지 관리할 수 있는가?
• 조직이 이를 지원할 수 있는가?

The Real Skill Isn’t Choosing the Stack

The real skill is knowing when stack choice matters — and when it doesn’t. Great engineers don’t obsess over tools. They think about:

• Teams
• Communication
• Longevity
• Change

They understand that software lives longer than trends — and people live longer than code.

진정한 기술은 스택 선택이 아니다

진정한 기술은 스택 선택이 중요한 시점과 그렇지 않은 시점을 아는 것이다. 훌륭한 엔지니어는 도구에 집착하지 않는다. 그들은 다음을 생각한다:

• 팀
• 커뮤니케이션
• 장기성
• 변화

그들은 소프트웨어가 트렌드보다 오래 살아남고, 사람은 코드보다 오래 살아간다는 것을 이해한다.

최종 생각

경력 초기에 있다면 이것은 자유로움을 의미합니다. 모든 “핫” 기술을 쫓을 필요가 없다는 뜻이죠. 완벽한 스택이 필요하지도 않습니다. 대신 트레이드‑오프, 사람, 그리고 상황을 이해해야 합니다.

실제 현장에서는:

최고의 스택은 가장 좋은 벤치마크를 가진 스택이 아닙니다.
팀이 실제로 구축하고, 유지보수하며, 함께 진화시킬 수 있는 스택이 바로 최고의 스택입니다.

궁금한 점이 있습니다—여기서 최고의 토론이 시작되죠 :)

“기술적으로 더 나은” 스택이 더 익숙한 스택에게 패배한 사례를 본 적이 있나요?
왜 그렇게 되었을 것이라고 생각하시나요?

함께 이야기해 봅시다. 👇