기술을 잘하는 사람과 기술적 결정을 잘하는 사람

기술을 잘 안다는 것과 기술적 결정을 잘한다는 것은 겹치지만 같은 말은 아닙니다. 연차가 올라갈수록 평가는 "무엇을 아는가"에서 "무엇을 선택했는가" 로 옮겨 갑니다.

기술을 잘하는 사람

• 도구와 언어, 프레임워크를 깊이 이해하고 빠르게 구현한다
• 어려운 버그의 원인을 끝까지 파고든다
• 새 기술을 빠르게 익힌다

이 역량은 모든 개발의 바탕입니다. 부족하면 어떤 결정도 실행할 수 없습니다.

결정을 잘하는 사람

• 문제를 먼저 정의한다: 풀 가치가 있는 문제인지, 지금 풀어야 하는지를 묻는다
• 선택지를 비교한다: 가능한 방법을 두세 가지로 좁히고 각각의 비용과 위험을 따져 본다
• 포기하는 것을 말한다: 무엇을 얻고 무엇을 포기하는지 분명히 한다
• 되돌릴 수 있는지 본다: 틀려도 바꿀 수 있는 결정과 바꾸기 어려운 결정을 구분한다
• 다른 사람이 따라올 수 있게 남긴다: 왜 그렇게 정했는지 기록한다

트레이드오프라는 관점

좋은 결정에는 거의 항상 치른 대가가 있습니다.

예시(재구성한 상황입니다)

새 기능을 빠르게 출시해야 해서 조회 로직을 단순하게 두기로 했다.

• 얻은 것: 일정 준수

• 포기한 것: 데이터가 늘었을 때의 성능

• 안전장치: 느려지는 신호(응답 시간 지표)를 정해 두고, 그 기준을 넘으면 개선하기로 팀과 합의

이 이야기가 좋은 이유는 "완벽한 구조"를 만들었기 때문이 아니라 지금 상황에 맞는 선택과 그 이유, 이후 계획이 함께 있기 때문입니다.

이력서와 면접에서 어떻게 드러날까

• "A 기술을 도입했다"보다 "A와 B를 비교했고, 우리 상황에서는 이런 이유로 A를 골랐다"
• "구조를 개선했다"보다 "어떤 문제가 반복되어 구조를 바꾸기로 했고, 바꾸지 않았다면 어떤 비용이 생겼을까"
• 실패한 결정과 그에서 얻은 배운 점. 숨기기보다 어떻게 바로잡았는지를 말할 수 있는 사람이 신뢰를 얻습니다.

결정하는 힘을 키우는 방법

1. 작은 결정부터 선택지와 이유를 짧게 적어 둡니다. (한 줄이면 충분합니다)
2. 몇 달 뒤에 그 결정을 다시 읽고, 무엇이 맞았고 틀렸는지 확인합니다.
3. 팀에서 결정이 내려질 때 내가 놓친 관점이 무엇인지 질문해 봅니다.
4. 큰 결정은 코드를 짜기 전에 글로 먼저 정리해 봅니다.

기술을 깊이 아는 것은 출발점입니다. 그 위에 선택의 이유를 설명하는 힘이 쌓일 때 개발자는 한 단계 다른 신뢰를 얻습니다.