새 기술보다 오래 버틸 기술을 고르는 법

새 기술보다 오래 버틸 기술을 고르는 법

AI 뉴스 썸네일

새 도구를 고르는 일은 기술 취향 문제가 아니에요. 팀이 앞으로 몇 년 동안 감당할 운영 부담을 정하는 결정에 가까워요. Dan McKinley의 2015년 글은 새 기술을 무조건 피하자는 얘기가 아니라, 회사가 정말 새로워야 할 지점을 먼저 골라야 한다는 조언에 가까워요. 2

핵심 요약

구분	핵심	왜 볼만한가요
기술 선택	새 기술을 쓸 때마다 팀의 주의력과 운영 여유를 써요	도구 선택을 취향이 아니라 조직 비용으로 보게 해요
운영 리스크	오래된 기술은 실패 양상이 더 잘 알려져 있어요	장애 대응과 적응 지원에서 예측할 수 있는 선택이 돼요
제품 개발	새로움은 핵심 문제에만 아껴 써야 해요	제품 차별화와 기술 실험을 분리하게 해요

1. 새 기술은 공짜가 아니라 팀의 주의력을 써요

Dan McKinley는 회사마다 쓸 수 있는 "혁신 토큰"이 몇 개 없다고 말해요. NodeJS, MongoDB, 막 나온 서비스 디스커버리 도구처럼 새 선택을 하나씩 더할 때마다 그 토큰을 쓴다는 비유예요. 표현은 가볍지만 메시지는 꽤 실용적이에요. 새 도구를 넣으면 설치와 학습만 생기는 게 아니라 모니터링, 장애 대응, 배포 방식, 테스트 방법까지 같이 따라와요. 2

여기서 말하는 지루한 기술은 낡고 나쁜 기술이 아니에요. MySQL, Postgres, Python, Cron처럼 많은 팀이 이미 오래 써 봤고, 장점과 약점이 충분히 드러난 기술에 가까워요. 중요한 건 기능 목록보다 실패 방식이에요. 장애가 났을 때 어디를 봐야 하는지, 어떤 부하에서 흔들리는지, 어떤 패턴을 피해야 하는지 팀 안팎에 경험이 쌓여 있으면 운영 리스크가 줄어요.

반대로 새 기술은 문서에 없는 문제를 자주 데려와요. 성능 한계가 예상과 다르거나, 특정 상황에서 런타임이 멈추거나, 커뮤니티가 아직 해결책을 찾지 못한 버그를 만날 수 있어요. 이런 문제는 멋진 기술 발표 자료에서는 잘 보이지 않아요. 실제 서비스 트래픽과 장애 상황을 지나야 드러나는 경우가 많아요.

2. "일에 맞는 최고의 도구"라는 말도 범위를 넓혀 봐야 해요

개발팀에서 자주 나오는 말이 있어요. 문제마다 가장 잘 맞는 도구를 쓰자는 말이에요. 듣기에는 합리적이지만, McKinley는 이 말이 너무 좁게 쓰일 때 위험하다고 봐요. 특정 기능 하나만 보면 Redis가 좋아 보이고, 다른 기능 하나만 보면 새로운 큐 시스템이 좋아 보일 수 있어요. 그런데 회사 전체를 보면 다른 계산이 필요해요. 2

도구가 늘어나면 운영 표면도 늘어요. 누가 배포를 이해하는지, 누가 장애를 볼 수 있는지, 누가 테스트를 고칠 수 있는지가 모두 비용으로 돌아와요. 한 명의 전문가가 있을 때는 괜찮아 보여도, 그 사람이 휴가를 가거나 팀이 커지면 문제가 바뀌어요. 기술 선택은 한 프로젝트의 로컬 최적화가 아니라 조직 전체의 지속 가능한 선택이어야 해요.

이 관점은 요즘 AI 도구와 개발 인프라를 고를 때도 그대로 이어져요. 모델, 벡터 DB, 에이전트 구조, 관측 도구가 빠르게 늘고 있어요. 새 도구를 붙이면 초기 데모는 빨라질 수 있어요. 하지만 운영 권한, 비용 추적, 장애 재현, 보안 검토까지 함께 챙기지 않으면 제품 속도가 나중에 꺾여요. 그래서 더 많은 도구보다 더 적게 실패하는 조합이 나을 때가 많아요.

3. 새 기술을 쓰지 말자는 얘기는 아니에요

이 글이 오래 살아남은 이유는 보수적인 결론만 내리지 않기 때문이에요. McKinley는 때로 새 기술을 골라야 한다고 말해요. 기존 도구로는 해결이 너무 비싸거나, 새 도구가 팀의 핵심 문제를 확실히 줄여 주거나, 회사가 그 영역에서 차별화를 만들어야 한다면 토큰을 쓸 이유가 있어요. 1

다만 새 기술을 고를 때는 질문이 달라져야 해요. "이 도구가 멋진가요"보다 "이 도구가 우리 팀의 제한된 관심을 쓸 만큼 중요한가요"가 먼저예요. 더 나아가 "3개월 뒤에도 운영할 수 있나요", "장애가 나면 누가 고칠 수 있나요", "기존 도구로 80%를 해결하면 충분하지 않나요"를 같이 물어야 해요.

결국 지루한 기술은 속도를 늦추는 선택이 아니에요. 덜 중요한 곳에서 예측 가능한 선택을 해 두면, 팀은 제품과 고객 문제에 더 많은 에너지를 쓸 수 있어요. 새로움은 차별화가 필요한 곳에 남겨두고, 나머지는 충분히 검증된 선택으로 밀어붙이는 쪽이 오래 가기 쉬워요.

왜 중요한가요

요즘 개발팀은 새 기술을 너무 쉽게 만나요. GitHub 저장소, 클라우드 서비스, AI 구조가 매주 쏟아져요. 문제는 선택지가 많아질수록 기술 판단이 더 좋아지는 게 아니라는 점이에요. 기준이 없으면 팀은 데모가 잘 되는 도구와 실제로 오래 버티는 도구를 헷갈리기 쉬워요.

이 글은 기술 리더와 제품 팀이 같은 질문을 보게 해요. 지금 필요한 건 새로움인지, 예측 가능성인지, 아니면 운영 부담을 줄이는 일인지 구분하게 해요. 특히 작은 팀일수록 이 구분이 중요해요. 한 번 잘못 고른 기반 기술은 코드 몇 줄보다 오래 남고, 채용과 적응 지원과 장애 대응까지 영향을 줘요. 2

새 기술은 여전히 필요해요. 다만 모든 층에서 새로울 필요는 없어요. 제품이 새롭다면 데이터베이스는 지루해도 괜찮아요. AI 기능이 실험적이라면 배포와 로그와 권한 관리는 익숙한 방식이 더 안전해요. 팀이 어디에서 위험을 감수할지 정하면, 기술 선택이 유행 따라가기보다 전략에 가까워져요.

참고 자료

1. 지루한 기술을 선택하라 (2015) — GeekNews
2. Choose Boring Technology — Dan McKinley