소프트웨어 엔지니어링에서 ‘좋은 취향’은 특정 기술 스택 선호가 아니라, 주어진 프로젝트 상황에 가장 잘 맞는 엔지니어링 가치를 유연하게 고르는 능력이라는 이야기.
취향은 실력과 다른 개념
- 기술적 취향은 요리 입맛처럼 실력과 독립적인 감각으로, 코드를 직접 잘 짜지 못해도 “이 코드는 보기 좋다/싫다”, “이 설계 결정은 마음에 든다/미묘하다”를 구분하는 능력에서 드러나는 개념임.
- for 루프 vs map/filter 같은 선택은 절대적인 기술 우열이 아니라, 각자가 더 중요하게 여기는 가치(가독성, 단순함, 성능 등)에 따라 갈리는 취향 차이일 뿐이며, 엔지니어는 결국 자신이 중시하는 가치 세트를 기준으로 판단하게 됨.
엔지니어링 취향 = 가치의 우선순위
- 소프트웨어 엔지니어링의 대부분 결정은 성능·가독성·정확성·유연성·확장성·복원력·이식성·개발 속도 등 가치들 사이의 트레이드오프 문제이고, 항상 한쪽이 절대적으로 옳은 선택인 경우는 드묾.
- 한 엔지니어의 취향은 이 가치들 중 무엇을 얼마나 우선시하는지에 의해 정의되며, 예를 들어 속도·정확성을 개발 속도보다 중시하면 러스트·특정 클라우드에 손이 가고, 복원성을 속도보다 중시하면 멀티 리전 분산 같은 선택을 자연스럽게 하게 됨.
나쁜 취향: 유연성 없는 ‘베스트 프랙티스’ 숭배
- 나쁜 취향은 그 사람이 선호하는 가치가 현재 프로젝트와 맞지 않는데도, 과거에 통했다고 믿는 방법론(형식 검증, 특정 언어로 재작성, 과도한 멀티 리전, 복잡한 메타프로그래밍 등)을 맥락과 무관하게 밀어붙이는 태도로 나타남.
- 이들은 “이건 베스트 프랙티스니까” 같은 절대 기준에 기대어 선택을 정당화하고, 특수한 상황에서는 잘 작동하지만 맥락이 바뀌면 나침반이 엇나가듯 잘못된 방향으로 팀을 이끄는 문제를 만든다는 비유를 쓸 수 있음.
좋은 취향: 맥락에 맞는 가치 선택과 유연성
- 좋은 취향은 특정 문제와 조직·비즈니스 제약 안에서 어떤 가치를 앞세우고 어떤 것을 희생할지 제대로 고르는 능력이라서, 단순 문답이나 이론 테스트로는 측정하기 어렵고 실제 프로젝트의 설계·결과 속에서만 드러남.
- 자신이 동의한 설계가 들어간 프로젝트가 잘 풀리고, 동의하지 않았던 선택이 들어간 프로젝트가 고생을 겪는 패턴을 여러 프로젝트에서 반복 관찰할 때 비로소 “내 취향이 이 맥락에서는 맞았다/틀렸다”를 검증할 수 있음.
좋은 취향을 기르는 법
- 좋은 취향은 단일 정답이나 교과서로 얻기보다, 다양한 유형의 프로젝트를 겪으며 “어디가 수월했고 어디서 고생했는지”, “어떤 가치 선택이 나중에 발목을 잡았는지”를 계속 의식적으로 되짚는 과정에서 서서히 쌓이는 것이라는 주장임.
- 핵심은 유연성으로, 특정 언어·패턴·아키텍처를 절대 규칙처럼 여기지 말고, 새로운 도메인과 동료의 취향에도 열린 태도로 여러 관점과 언어를 시도하면서 자신의 기본 취향을 계속 업데이트하는 태도가 중요하다고 강조함.