좋은 개발자와 위대한 개발자를 구분 짓는 조용한 스킬

Source: Dev.to

Introduction

방 안에 있는 개발자들에게 가장 중요한 것이 무엇인지 물어보면, 보통 알고리즘, 시스템 설계, 깨끗한 코드, 성능 같은 흔한 답변을 들을 수 있습니다. 모두 맞는 말이죠. 하지만 LinkedIn에서 자랑하기는 드물지만 시간이 지날수록 가장 큰 차이를 만드는 조용한 스킬이 있습니다: 트레이드‑오프를 생각하는 것.

The reality of trade‑offs

실제 현업 개발은 “가장 좋은” 해결책을 찾는 것이 아니라, 현실적인 제약 하에서 가장 덜 나쁜 선택을 하는 것입니다.

튜토리얼에서는 모든 것이 깔끔합니다. 요구사항은 명확하고, 마감일은 여유롭고, 시스템에는 10년 된 레거시 코드가 2016년에 떠난 사람들의 TODO 주석과 함께 뒤섞여 있지 않습니다. 실제로는 모든 결정이 시간, 품질, 비용이라는 삼각형 안에 존재합니다. 한 모서리를 너무 강하게 밀면 다른 모서리가 튀어나옵니다.

Asking the right questions

훌륭한 개발자는 다른 질문을 하는 법을 배웁니다:

• “이게 가장 우아한 설계인가?”가 아니라 “우리가 지금 해결하고 있는 문제에 이 정도 우아함이면 충분한가?”
• “이걸 다시 짜야 할까?”가 아니라 “우리가 안 하면 무엇이 깨지고, 다시 하면 무엇이 깨질까?”

Trade‑offs in practice

이 사고방식은 어디에나 나타납니다:

• 프레임워크를 선택한다는 것은 그 프레임워크의 의견과 제한을 받아들인다는 뜻입니다.
• 캐시를 추가하면 속도는 빨라지지만 무효화가 복잡해집니다.
• 마이크로서비스는 확장성을 약속하지만 팀에 운영 오버헤드를 부과합니다.
• 변수 이름 짓기도 간결함과 명확성 사이의 트레이드‑오프입니다.

강한 개발자를 구분 짓는 것은 나쁜 결정을 전혀 하지 않는 것이 아니라 (그것은 불가능합니다), 왜 그 결정을 내렸는지, 언제 다시 검토해야 하는지를 인식하는 것입니다. 스타트업 압박 속에서 작성된 코드는 은행에서 작성된 코드와 다르게 보일 수 있으며, 그것은 괜찮습니다. 상황이 왕입니다.

The human side of trade‑offs

트레이드‑오프를 명확히 설명하면 신뢰가 쌓입니다. “우리는 더 빨리 배포하기 위해 기술 부채를 일부 감수하고, 그 부채를 어떻게 갚을지 계획하고 있습니다”라고 말할 수 있다면, 문지기처럼 들리는 대신 파트너처럼 들리게 됩니다.

Building the habit

시간이 지나면서 이 사고방식은 복리 효과를 냅니다:

• 더 단순한 시스템을 만들게 됩니다.
• 과도한 엔지니어링을 덜 하게 됩니다.
• 죄책감이 아니라 목적을 가지고 리팩터링하게 됩니다.
• 반짝이는 도구에 “아니오”하고, 작동하는 지루한 솔루션에 “예”라고 말하는 능력이 향상됩니다.

그러니 다음 언어나 프레임워크를 넘어 연습하고 싶다면, 이것을 연습하세요: 코드를 작성하기 전에 잠시 멈추어 무엇을 최적화하고 무엇을 의식적으로 포기하고 있는지 스스로에게 물어보세요. 그 짧은 멈춤이 코드가 단순히 실행되는 것과 시스템이 살아남는 것 사이의 차이를 만들곤 합니다.