트레이드 오프 모르는 개발자가 신기술을 밀어붙일 때

 

트레이드 오프는 기술 선택에서 가장 중요한 개념인데, 13년 넘게 개발 일을 하면서 느낀 건 이 개념을 모르는 개발자가 생각보다 많다는 사실입니다. 신기술 도입 회의에서 장점 목록은 줄줄 나오는데, 그 기술이 무엇을 포기하는 대가로 그 장점을 얻었는지 말하는 사람은 드뭅니다. 오늘은 이 이야기를 해보려고 합니다.

 

 

"멀티스레드가 당연히 빠르죠"
"요즘 누가 모놀리식으로 만들어요"
"NoSQL이 확장성이 좋으니까 이걸로 가시죠"
"이 프레임워크가 요즘 대세예요"

 

 

다 어디선가 들어본 말일 겁니다. 문제는 이 문장들이 틀렸다는 게 아닙니다. 조건이 빠져 있다는 겁니다. 어떤 상황에서, 무엇을 포기하고, 그 대가로 무엇을 얻는지가 없으면 기술 선택이 아니라 유행 추종이 됩니다. 저는 이걸 구분하는 열쇠가 트레이드 오프라는 개념 하나라고 생각합니다.

신기술 도입을 검토 중인 분, 그리고 회의에서 "그게 요즘 대세잖아요"라는 말에 뭔가 찜찜함을 느껴본 분에게 도움이 될 만한 글입니다.

목차

1. 트레이드 오프란 무엇인가
2. 개발자들이 트레이드 오프를 놓치는 이유
3. 싱글 스레드 vs 멀티스레드, 가장 오해가 많은 선택
4. Redis는 왜 싱글 스레드로 설계됐나
5. 모놀리식 vs MSA, Amazon도 되돌아갔다
6. 어디에나 있는 같은 패턴
7. 기술 검토에서 던져야 할 질문 하나
8. 신기술 도입을 판단하는 저의 기준

1. 트레이드 오프란 무엇인가

트레이드 오프는 간단히 말해 무언가를 얻으면 반드시 무언가를 내준다는 원리입니다. 경제학 용어지만 소프트웨어 설계에서는 거의 물리 법칙에 가깝게 작동합니다.

속도를 얻으면 메모리를 내줍니다. 캐시가 그렇습니다. 유연성을 얻으면 복잡도를 내줍니다. 추상화 계층이 그렇습니다. 확장성을 얻으면 정합성 관리 비용을 내줍니다. 분산 시스템이 그렇습니다. 예외가 없다고 단정할 수는 없지만, 저는 아직 아무것도 내주지 않고 무언가를 얻는 기술을 본 적이 없습니다.

 

 

📌 이 글의 한 줄 요약

"이 기술은 무엇이 좋은가"만 묻는 사람과 "이 기술은 무엇을 포기했는가"까지
묻는 사람의 차이가 연차가 쌓일수록 벌어집니다.

 

 

그러니까 어떤 기술이 좋다는 말은 그 자체로는 정보가 아닙니다. 어떤 비용을 지불하고 무엇을 얻는 기술인지, 그리고 지금 우리 상황이 그 비용을 지불할 가치가 있는 상황인지까지 가야 판단이 됩니다.

2. 개발자들이 트레이드 오프를 놓치는 이유

이 개념을 모르는 게 개인의 잘못만은 아니라고 봅니다. 우리가 기술을 접하는 경로 자체가 장점 위주로 설계돼 있기 때문입니다.

공식 문서의 첫 페이지는 그 기술이 해결하는 문제를 보여줍니다. 컨퍼런스 발표는 도입 성공 사례를 다룹니다. 기술 블로그는 "우리가 X를 도입해서 Y를 개선한 이야기"가 대부분입니다. 도입했다가 걷어낸 이야기는 잘 공유되지 않습니다. 실패담은 쓰기 민망하니까요. 그래서 학습 단계에서 접하는 정보의 비율 자체가 장점 쪽으로 기울어 있습니다.

여기에 이력서 문제가 겹칩니다. 새 기술을 도입해 본 경험은 경력에 한 줄이 되지만, 도입하지 않기로 판단한 경험은 한 줄이 되기 어렵습니다. 그러다 보니 기술 선택이 프로젝트가 아니라 커리어를 위한 결정으로 기울어지는 경우를 종종 봤습니다. 저 역시 5년 차 무렵 실력에 집착하던 시기에는 새로운 걸 써보고 싶다는 욕심이 판단에 섞여 들어갔던 것 같습니다. 그때는 그게 욕심인지도 몰랐습니다.

3. 싱글 스레드 vs 멀티스레드, 가장 오해가 많은 선택

구체적인 예를 하나 잡아보겠습니다. 제가 겪은 논쟁 중에 제일 흔했던 게 이겁니다. "멀티스레드가 당연히 빠르다"는 믿음이요.

멀티스레드는 CPU 코어를 여러 개 쓸 수 있게 해줍니다. 얻는 것이 분명합니다. 그런데 내주는 것도 분명합니다.

• 컨텍스트 스위칭 비용 - 스레드를 전환할 때마다 CPU가 상태를 저장하고 복원하는 비용이 발생합니다
• 동기화 비용 - 같은 데이터를 여러 스레드가 만지려면 락이 필요하고, 락을 기다리는 시간이 생깁니다
• 레이스 컨디션 - 실행 순서에 따라 결과가 달라지는 버그가 가능해집니다. 재현이 안 되는 종류의 버그입니다
• 디버깅 난이도 - 순차 실행이 깨지는 순간 코드를 눈으로 따라가는 게 어려워집니다

그래서 작업의 성격이 갈림길이 됩니다. CPU를 오래 붙잡고 계산하는 작업이라면 코어를 여러 개 쓰는 이득이 비용을 넘어섭니다. 반대로 하나하나가 짧고 빠른 작업을 대량으로 처리하는 경우라면, 락 경합과 컨텍스트 스위칭 비용이 병렬 처리의 이득을 갉아먹습니다. 스레드끼리 락을 두고 줄 서 있는 시간이 실제 일하는 시간보다 길어지는 상황도 나옵니다.

멀티스레드가 나쁘다는 얘기가 아닙니다. 멀티스레드는 공짜가 아니라는 얘기입니다. "당연히 빠르다"의 "당연히"가 문제인 겁니다.

4. Redis는 왜 싱글 스레드로 설계됐나

이 트레이드 오프를 설계 철학으로 밀어붙인 대표 사례가 Redis입니다. Redis는 명령 처리 코어를 스레드 하나로 설계했습니다. 세상에서 손꼽히게 빠른 저장소가 싱글 스레드라는 게 처음 들으면 이상하게 느껴집니다.

이유는 위에서 말한 비용 구조에 있습니다. Redis의 작업은 메모리 위에서 도는 짧고 빠른 명령이 대부분입니다. 이런 워크로드에서는 락과 컨텍스트 스위칭이라는 세금을 아예 안 내는 쪽이 코어 여러 개를 쓰는 쪽보다 이득이 큽니다. 스레드가 하나면 락이 필요 없고, 레이스 컨디션이 원천적으로 없고, 모든 명령이 자연스럽게 원자적으로 실행됩니다. 대신 다중 접속은 I/O 멀티플렉싱으로 풀었습니다. 이 구조로 단일 서버에서 초당 10만 건 안팎의 요청을 처리한다고 알려져 있습니다.

물론 Redis도 대가를 지불했습니다. CPU 코어 하나만 쓰기 때문에 나머지 코어는 놀고, 오래 걸리는 명령 하나가 서버 전체를 붙잡는 문제가 있습니다. 그래서 Redis 6.0부터는 네트워크 I/O에 한해서 멀티스레드를 도입했습니다. 명령 실행 코어는 여전히 싱글 스레드로 두고요. 얻을 게 확실한 곳에만 멀티스레드의 비용을 지불한 겁니다. 저는 이게 트레이드 오프를 이해한 설계의 교과서라고 생각합니다.

 

 

💡 뒤집으면 이렇게 됩니다

"Redis는 싱글 스레드인데도 빠르다"가 아니라 "싱글 스레드라서 빠르다"에 가깝습니다.

기술의 성능은 절대값이 아니라 워크로드와의 궁합입니다.

 

5. 모놀리식 vs MSA, Amazon도 되돌아갔다

같은 패턴이 아키텍처 단위에서도 반복됩니다. 한동안 MSA가 정답처럼 통하던 시기가 있었습니다. 모놀리식이라고 하면 낡은 것 취급을 받았고요.

그런데 2023년에 Amazon Prime Video 팀이 흥미로운 글을 공개했습니다. 영상 품질을 분석하는 모니터링 서비스를 서버리스 마이크로서비스 구조로 만들었다가, 컴포넌트 사이에 데이터를 넘기는 오케스트레이션 비용과 중간 저장소 비용이 병목이 돼서 모놀리식 구조로 재설계했고, 그 결과 인프라 비용을 90% 줄였다는 내용이었습니다. MSA를 세상에 퍼뜨린 회사 중 하나가 자기 서비스 하나를 모놀리식으로 되돌린 겁니다.

이 사례에서 조심할 부분이 있습니다. 이게 MSA가 틀렸다는 증거가 아니라는 점입니다. Prime Video 전체가 아니라 특정 워크로드 하나의 이야기이고, 반대 방향의 사례도 있습니다. Netflix는 2008년 모놀리식 시스템의 대형 장애를 계기로 서비스를 수백 개로 쪼갰고 그게 맞는 선택이었습니다. 두 회사가 반대 방향으로 움직였는데 둘 다 옳았습니다. 결정을 가른 건 유행이 아니라 각자의 워크로드와 조직 상황이었습니다.

MSA는 배포 독립성과 조직 확장성을 얻는 대신 네트워크 비용, 분산 트랜잭션, 운영 복잡도를 내주는 구조입니다. 그 비용을 감당할 팀 규모와 인프라 성숙도가 없으면, 얻는 것보다 내주는 게 커집니다. 당시 Amazon CTO가 남긴 "아키텍처는 종교가 아니라 전략"이라는 말이 이 사례의 요약이라고 봅니다.

6. 어디에나 있는 같은 패턴

한 번 보이기 시작하면 이 패턴은 어디에나 있습니다.

반응형

선택지	얻는 것	내주는 것
멀티스레드	CPU 코어 활용, 병렬 처리	락 경합, 레이스 컨디션, 디버깅 난이도
MSA	배포 독립성, 조직 확장성	네트워크 비용, 분산 트랜잭션, 운영 복잡도
NoSQL	수평 확장, 유연한 스키마	조인·트랜잭션 제약, 정합성 관리 부담
캐시	응답 속도	무효화 관리, 데이터 불일치 가능성
비정규화	조회 성능	중복 데이터, 갱신 비용과 무결성 위험
비동기 처리	처리량, 응답성	흐름 추적 난이도, 실패 처리 복잡도

표를 보면 오른쪽 열이 비어 있는 행이 없습니다. 앞으로 나올 신기술도 마찬가지일 거라고 봅니다. 내주는 것 열이 비어 있는 것처럼 보인다면, 그 기술이 대단한 게 아니라 아직 우리가 비용을 발견하지 못한 것에 가깝습니다. 그리고 그 비용은 대개 도입하고 한참 뒤에, 제일 바쁠 때 청구됩니다.

7. 기술 검토에서 던져야 할 질문 하나

그래서 저는 기술 검토 자리에서 질문 하나를 꼭 던집니다. "이 기술의 단점이 뭔가요?"

단순한 질문인데 반응이 갈립니다. 그 기술을 제대로 아는 사람은 단점부터 술술 나옵니다. 어떤 상황에서 쓰면 안 되는지, 운영하면서 뭐가 아픈지를 압니다. 반대로 장점만 줄줄 나오고 단점에서 말문이 막히면, 그 사람은 기술을 아는 게 아니라 기술의 광고를 아는 상태일 가능성이 큽니다.

이건 사람을 평가하려는 질문이 아니라 논의의 수준을 한 단계 올리는 질문입니다. 단점이 테이블 위에 올라와야 "그 단점이 우리 상황에서 문제가 되는가"라는 진짜 논의가 시작되니까요. 단점 없는 기술 발표는 검토가 아니라 영업입니다.

덧붙이면, 이 질문은 자기 자신에게 던질 때 제일 효과가 좋습니다. 내가 밀고 싶은 기술일수록 단점이 눈에 안 들어오기 때문입니다. 저도 도입하고 싶은 기술이 생기면 일부러 검색어에 문제점, 후회, 단점 같은 단어를 붙여서 반대편 글부터 찾아봅니다.

8. 신기술 도입을 판단하는 저의 기준

13년 하면서 제 나름대로 정리된 기준은 세 가지입니다.

하나, 지금 겪고 있는 문제에서 출발했는가. 기술에서 출발하면 문제를 찾아다니게 됩니다. 망치를 들면 모든 게 못으로 보이는 상태죠. 문제에서 출발하면 그 문제를 푸는 여러 선택지 중 하나로 신기술을 저울질하게 되고, 그 저울질이 곧 트레이드 오프 분석입니다.

둘, 도입 비용을 전부 세었는가. 라이선스나 서버비 같은 눈에 보이는 비용 말고요. 팀원 학습 비용, 운영과 모니터링 비용, 장애 났을 때 디버깅할 수 있는 사람이 몇 명인지, 그 사람이 퇴사하면 어떻게 되는지까지가 도입 비용입니다. 경험상 이 뒷단 비용이 앞단 비용보다 큰 경우가 많았습니다.

셋, 되돌릴 수 있는가. 트레이드 오프 분석을 아무리 해도 예측은 빗나갑니다. Amazon도 만들어보고 나서야 알았으니까요. 그래서 판단이 틀렸을 때 걷어낼 수 있는 구조인지가 마지막 안전장치입니다. 되돌리기 쉬운 결정은 조금 과감해도 되고, 되돌리기 어려운 결정은 훨씬 보수적으로 가는 게 맞다고 봅니다.

이 기준이 정답이라고 하진 않겠습니다. 이것 역시 신중함을 얻는 대신 속도를 조금 내주는 트레이드 오프니까요. 빠르게 실험하고 빠르게 버리는 게 맞는 조직도 분명 있습니다. 다만 그 경우에도 무엇을 내주고 있는지는 알고 내줘야 한다는 것, 그게 이 글에서 하고 싶은 이야기의 전부입니다.

자주 묻는 질문

Q. 트레이드 오프를 따지다 보면 아무것도 도입 못 하는 것 아닌가요?

목적이 다릅니다. 트레이드 오프 분석은 도입을 막는 절차가 아니라 비용을 알고 도입하는 절차입니다. 비용을 알고 시작하면 그 비용에 대비할 수 있고, 문제가 터졌을 때 놀라는 대신 예상했던 청구서를 받는 쪽이 됩니다.

Q. 신기술을 빨리 도입하는 회사들이 성장하는 것 아닌가요?

빠른 도입 자체가 성장 요인이라기보다, 잘 되는 회사는 되돌릴 수 있는 구조와 실험 문화를 갖추고 빠르게 도입하는 경우가 많다고 봅니다. 같은 속도라도 안전장치가 있느냐 없느냐의 차이가 큽니다. 속도와 안정성도 결국 트레이드 오프 관계라, 자기 조직이 어느 쪽 비용을 감당할 수 있는지가 기준이 됩니다.

Q. 주니어인데 트레이드 오프 감각은 어떻게 기르나요?

기술을 공부할 때 장점과 함께 어떤 상황에서 쓰면 안 되는지를 세트로 찾아보는 습관이 제일 빠르다고 생각합니다. 검색할 때 기술 이름 뒤에 문제점이나 한계 같은 단어를 붙여서 반대편 글을 읽어보는 것만으로도 감각이 달라집니다. 공식 문서의 제약 사항 페이지도 의외로 보물창고입니다.

Q. 팀에서 특정 기술을 유행이라는 이유로 밀어붙이면 어떻게 하나요?

정면으로 반대하기보다 "우리 상황에서 이 기술의 단점이 어떻게 작동할지"를 질문으로 올려보는 걸 권합니다. 단점 논의가 시작되면 대화의 질이 달라집니다. 그리고 결정이 반대로 나더라도, 비용을 미리 짚어둔 기록은 나중에 팀의 자산이 됩니다.

마무리

정리하면 이렇습니다. 모든 기술 선택은 거래이고, 거래에는 항상 지불하는 쪽이 있습니다. 좋은 개발자와 그렇지 않은 개발자를 가르는 건 신기술을 얼마나 아느냐가 아니라, 그 기술이 청구할 비용을 도입 전에 볼 수 있느냐라고 저는 생각합니다.

싱글 스레드 Redis가 빠르고, Amazon이 모놀리식으로 돌아가서 비용을 줄였다는 사실이 말해주는 건 하나입니다. 기술에는 정답이 없고 상황에 맞는 답이 있을 뿐이라는 것. 다음에 누군가 "이게 요즘 대세예요"라고 말하면, 조용히 한 번 물어봐 주세요. 그래서 그건 뭘 포기한 대가로 그걸 얻는 기술인가요?

📚 함께 보면 좋은 글

개인 생각 - Java가 떡상한 진짜 이유, Docker 없던 시대의 JVM이었기 때문

SSL 인증서 유효기간 단축 - 1년에서 47일로, 무료 SSL 인증서 대응법

웹개발 직군 변천사 - 웹마스터에서 AI 시대까지 (프론트·백엔드·DBA·DevOps)

같은 연차에 200만 원 더 받는데, 프리랜서를 안 하는 개발자들