기술 선택에도 용기가 필요하다 — 채용과제에서 배운 트레이드오프 이야기
분명히 잘 알고 있는 기술인데, 막상 프로젝트에 쓰려고 보니까 뭔가 이상하게 돌아가는 느낌. 근데 익숙하니까 그냥 밀고 나가다가 나중에 더 큰 수렁에 빠지는 그런 상황이요.
저도 최근 채용과제를 진행하면서 정확히 그 상황을 겪었어요. 그리고 그때 처음으로 “트레이드오프(Trade-off)”라는 개념을 머리가 아닌 몸으로 이해하게 됐어요.
오늘은 그 경험을 솔직하게 풀어볼게요.
트레이드오프가 뭔데요?
트레이드오프는 간단하게 말하면 “A를 얻으면 B를 잃는다” 는 관계예요.
개발에서는 특히 이런 선택이 자주 나와요.
- 성능을 높이면 → 코드가 복잡해지고 유지보수가 어려워진다
- 개발 속도를 높이면 → 코드 품질이 떨어질 수 있다
- 기능을 많이 넣으면 → 프로젝트 완성이 늦어진다
전공자들은 이미 수업이나 팀 프로젝트에서 이걸 자연스럽게 익히는 경우가 많은데, 비전공자인 저는 솔직히 이 개념을 “아는 척”만 했지 실제로 느껴본 적이 없었어요.
근데 채용과제에서 제대로 한 방 맞았어요.
트레이드오프 = 무언가를 얻기 위해 무언가를 포기하는 선택
채용과제에서 겪은 일 — 익숙함의 함정
채용과제를 받았을 때, 저는 처음에 제가 익숙한 스택과 방식으로 설계를 시작했어요.
“이건 내가 써봤으니까 빠르게 할 수 있어”라고 생각했거든요. 근데 막상 구현을 시작하니까 뭔가 계속 어긋나는 느낌이 들었어요.
이 기술이 과제 요구사항과 딱 맞지 않는 거예요. 과제는 단순하고 빠른 파이프라인 구현을 원하는데, 제가 쓰려던 방식은 설정도 복잡하고 구조도 무거웠어요. 익숙하니까 쓰려고 했던 건데, 오히려 그게 발목을 잡은 거죠.
결국 며칠을 그 방식으로 끙끙대다가 결론을 내렸어요.
“이거 버리자.”
포기하니까 더 빨라졌어요
솔직히 처음엔 버리는 게 손해처럼 느껴졌어요.
“지금까지 한 게 아깝잖아”라는 생각이 계속 들더라고요. 근데 그게 바로 매몰 비용의 함정이라는 걸 나중에 알았어요. 이미 쓴 시간이 아깝다고 계속 비효율적인 방향으로 가는 건, 더 큰 시간을 낭비하는 거였어요.
과감하게 익숙한 스택을 내려놓고 과제에 맞는 더 단순한 방식을 선택했더니, 진짜 신기하게도 속도가 붙기 시작했어요.
설정이 줄어드니까 → 에러가 줄고
구조가 단순해지니까 → 흐름이 눈에 보이고
눈에 보이니까 → 디버깅도 빠르고
결국 전체 시간은 오히려 줄었어요. 익숙한 걸 고집했을 때보다요.
포기가 손해가 아니라, 더 나은 선택을 위한 공간 확보였어요.
기술을 선택할 때 진짜 고려해야 할 것들
이 경험을 하고 나서 기술 선택 기준을 다시 생각해봤어요.
비전공자인 저는 그동안 이런 기준으로 기술을 골랐던 것 같아요.
- “많이 들어봤으니까”
- “써봤으니까”
- “남들이 쓰니까”
근데 채용과제를 통해서 배운 진짜 기준은 달랐어요.
1. 이 기술이 지금 해결하려는 문제에 맞는가?
기술은 도구예요. 못을 박아야 하는데 드라이버를 들고 있으면 안 되는 것처럼, 요구사항에 안 맞는 기술은 익숙해도 비효율적이에요.
2. 내가 이 기술의 단점을 감당할 수 있는가?
모든 기술에는 단점이 있어요. 그 단점이 이번 프로젝트의 상황에서 얼마나 문제가 되는지를 먼저 따져봐야 해요.
3. 지금 시간과 리소스가 어느 정도인가?
채용과제처럼 시간이 제한된 상황에서는, 완벽한 구조보다 동작하는 결과물이 우선일 때가 있어요. 개발 속도 대비 완성도의 균형을 맞춰야 하는 거죠.
기술 선택 기준 = 익숙함이 아니라 “지금 이 상황에 맞는가”
트레이드오프를 인식하는 게 실력이에요
사실 트레이드오프를 모르는 개발자는 없어요.
근데 트레이드오프를 인식하고, 선택하고, 이유를 설명할 수 있는 개발자는 다르다고 생각해요.
면접에서도 “이 기술을 왜 선택했나요?”라는 질문을 많이 받잖아요. 그 질문에 “익숙해서요”라고 답하는 것과, “이런 트레이드오프를 고려했고, 이 상황에서는 이게 더 적합하다고 판단했어요”라고 답하는 건 완전히 다른 레벨이에요.
저는 채용과제를 통해서 처음으로 그 경험을 했고, 이게 앞으로 기술을 선택할 때마다 중요한 기준이 될 것 같아요.
마무리 — 포기도 전략이다
취준하면서 “포기”라는 단어가 부정적으로 느껴질 때가 많아요.
근데 개발에서, 특히 기술 선택에서 포기는 전략이에요. 더 효율적인 방향을 위해 비효율적인 것을 내려놓는 행위거든요.
저도 채용과제에서 익숙한 스택을 포기했고, 그 덕분에 더 빠르고 깔끔하게 과제를 마무리할 수 있었어요.
여러분도 만약 지금 하고 있는 방식이 계속 막히고 비효율적이라는 느낌이 든다면, 한 번쯤 이 질문을 해보세요.
“내가 이걸 고집하는 이유가, 진짜 이게 좋아서인가? 아니면 그냥 익숙해서인가?”
그 질문에서 트레이드오프 고민이 시작되는 것 같아요.