소프트웨어 개발에서의 운전사식 지식: 개발자들이 깊은 이해 없이 똑똑해 보일 때

발행: 1일 전 (2026년 2월 8일 오후 04:16 GMT+9)

16 분 소요

Source: Dev.to

우리는 모두 회의에서 “event‑driven architecture” 혹은 “CQRS pattern” 같은 용어를 자신 있게 내뱉지만, 실제 의미를 설명해 달라는 요청이 없기를 비밀스럽게 바랐던 개발자였던 적이 있습니다. 저도 마찬가지였죠.

The Chauffeur Story
유명한 과학자에게는 전국을 돌며 강의를 데려다 주는 운전사가 있었습니다. 몇 달 동안 같은 연설을 듣고 나서, 그 운전사는 연설을 한마디도 빠짐없이 외워버렸습니다. 어느 날 그는 농담으로 “내가 직접 그 강의를 할 수 있겠어!”라고 말했습니다. 과학자는 웃으며 그에게 기회를 주었습니다.
운전사는 완벽히 해냈습니다. 완벽한 전달. 기립 박수.
그러다 누군가가 추가 질문을 했습니다.
운전사는 얼어붙었습니다.
이것이 소프트웨어 개발에서 우리가 “chauffeur knowledge” 라고 부르는 것이며, 어디에나 존재합니다.

당신도 그 사람을 알고 있을 겁니다. 어쩌면 당신이 바로 그 사람일 수도 있죠.

“우리는 microservices! Event sourcing! Kubernetes! 가 필요해요”
“왜요?”
“왜냐하면… 성공적인 기업들이 쓰고 있거든요”

“멋진” 유행어가 함정이 될 수 있는 이유

Netflix는 마이크로서비스를 사용합니다 왜냐하면 수백 명의 개발자와 수백만 명의 사용자가 있기 때문입니다.
귀사의 내부 도구는 개발자 3명과 사용자 200명을 가지고 있습니다.
여러분은 분산된 악몽보다는 잘 조직된 모놀리식이 필요할 가능성이 높습니다.

하지만 **“마이크로서비스”**는 LinkedIn 프로필에서 훨씬 더 멋져 보입니다.

실제 예시

저는 한 번 아름다운 React 앱을 만들 수 있는 개발자와 함께 일한 적이 있습니다 – 정말 인상적인 작업이었죠. 그런데 우리 Node.js 백엔드가 무작위로 멈추기 시작했습니다.

"It's probably the async calls," I suggested.
Blank stare.
"How do promises work?" I asked.
More blank stares.

그들은 2년 동안 async 앱을 만들었지만 async가 실제로 무엇을 의미하는지 이해하지 못했습니다. 프레임워크가 모든 복잡성을 숨겨 주었지만, 어느 순간 그 숨김이 사라졌습니다.

“복사‑붙여넣기” 사이클

프로덕션이 중단됩니다.
오류를 구글에 검색하고, Stack Overflow 답변을 찾아 복사‑붙여넣기 해결책을 적용해 프로덕션에 배포합니다.
작동합니다! 배포합니다!
세 달 후, 같은 버그가 다른 상황에서 다시 나타납니다.
팀원 누구도 처음에 왜 이 수정이 작동했는지 이해하지 못합니다.
또 다른 패치를 위해 Stack Overflow로 돌아갑니다.

그것이 legacy codebases가 탄생하는 방식입니다.

“Uber” 사고방식

“우리 시스템을 Uber처럼 만들자!”
“우리에겐 Uber 같은 문제가 있나요?”
“음… 아니요. 최대 10명의 동시 사용자가 있어요.”
“우리에겐 Uber 같은 엔지니어링 팀이 있나요?”
“아니요, 우리 셋뿐이에요.”
“그럼 왜—”
“왜냐하면 베스트 프랙티스이기 때문이죠.”

우리는 실제로 필요하지 않은 큰 기술 기업의 방식을 그대로 베끼는 것을 좋아합니다. 마치 한 개의 소파만 옮기면 되는 상황에서 대형 세미‑트럭을 사는 것과 같습니다.

왜 이런 일이 일어나는가

변화 속도 – 지난 주에 뜨던 프레임워크가 이번 주엔 레거시 코드가 된다. 우리는 이해하기보다 외우게 된다.
임포스터 증후군 – 다른 사람들은 모든 것을 알고 있는 것처럼 보여서, 우리는 복잡한 단어로 위장한다.
면접 압박 – “화이트보드에 이진 트리를 역전시켜라”는 이해가 아니라 암기를 테스트한다.
가혹한 마감 – “왜 작동하나요?”는 우리가 가질 시간이 없다. “작동하나요?”는 내일 배포할 때 전부다.
툴‑우선 사고방식 – 부트캠프는 3주 차에 React를 가르친다. 브라우저가 실제로 어떻게 동작하는지는 가르치지 않는다.

이해합니다. 저도 그 경험이 있습니다. 우리 모두 그 경험을 했습니다.

고통스러운 결과

오전 3시 프로덕션 사고 – 복사한 솔루션이 깨집니다. 이유를 전혀 모릅니다. 당신을 구해준 Stack Overflow 답변도 이제는 도움이 되지 않습니다.
성능 재앙 – 사용하라고 권유받은 ORM이 페이지 로드당 1,000 DB 호출을 발생시킵니다. SQL을 배운 적이 없어서 ORM이 그렇게 할 수 있다는 걸 몰랐습니다.
과도하게 설계된 혼란 – 서로 통신하는 8개의 마이크로서비스, 배포에 세 시간이 걸리고 디버깅은 여러 시스템의 로그를 확인해야 합니다. 3명으로 구성된 팀이 기능보다 DevOps에 더 많은 시간을 씁니다.
보안 구멍 – 토큰을 이해하지 못한 채 인증 패턴을 복사했습니다. 애플리케이션이 6개월 동안 사용자 세션을 유출하고 있습니다.

이것들은 가상의 시나리오가 아닙니다. 매일 일어나고 있습니다.

구현하기 전에 잠시 멈추고 물어보세요

왜 이 솔루션이 존재하나요?
어떤 문제를 해결하고 있나요?
대안은 무엇인가요?
잘못되면 무엇이 깨지나요?

이 질문들에 답할 수 없다면, 아마도 운전사 모드일 가능성이 높습니다.

플래시보다 기본

HTTP 기본을 배우는 것이 최신 JavaScript 프레임워크를 배우는 것만큼 매력적이지는 않지만 프레임워크는 변하고, 기본은 변하지 않는다.

데이터베이스 – 실제 작동 방식을 배우세요.
네트워크 – OSI 모델, TCP/IP, 지연 시간을 이해하세요.
메모리 – 가비지 컬렉션과 할당이 성능에 어떻게 영향을 미치는지 알아두세요.

그 지식은 누적됩니다. 새로운 도구를 배울수록 그것이 무엇 위에 구축되었는지 이해하고 있기 때문에 더 쉬워집니다.

실습 과제

Express – 순수 Node.js http 핸들러로 웹 서버를 구축하세요.
Redux – 처음부터 간단한 상태 관리를 구현하세요.
Authentication – 기본 JWT 생성기/검증기를 직접 작성하세요.

프레임워크가 여러분을 위해 하는 일을 이해하게 되고, 문제가 발생했을 때 어떻게 고치는지도 알게 될 것입니다.

“I don’t know”를 받아들이기

다음 회의에서 누군가 당신이 이해하지 못하는 것에 대해 물어볼 때, 다음과 같이 말해 보세요:

“모르겠어요. 설명해 주실 수 있나요?”

방 안의 절반도 모릅니다; 그저 숨기는 데 더 능숙할 뿐이죠.

좋은 팀은 호기심을 장려합니다, 가짜 자신감보다. 만약 당신의 팀이 “I don’t know”를 처벌한다면, 당신은 잘못된 팀에 있는 겁니다.

가르치며 배우기

Dependency injection? 주니어 개발자에게 설명해 보세요.
Can’t do it without hand‑waving? 아직 이해하지 못한 거예요.

가르치는 것은 생각을 정리하고, 간단한 예시를 찾으며, 예상치 못한 질문에 답하도록 강요합니다. 이는 자신의 지식에 있는 빈틈을 가장 빠르게 발견하는 방법입니다.

마무리 생각

나는 이 글을 읽어야 했기 때문에 작성했습니다.

지난달 나는 코드 리뷰에서 자신 있게 캐싱 전략을 추천했습니다. 누군가가 나에게 e…

(이야기는 계속되지만, 요점은 명확합니다: 질문을 계속하고, 배우는 것을 멈추지 않으며, 모든 답을 가지고 있다고 가장하는 것을 멈추세요.)

Explain the eviction policy

I… couldn’t.
나는… 할 수 없었다.

I’d read about it. I’d used it. I could spell “LRU cache.” But I didn’t actually understand how it worked.
나는 그것에 대해 읽었고, 사용했으며, “LRU 캐시”를 철자할 수 있었다. 하지만 실제로 어떻게 작동하는지는 이해하지 못했다.

I’d been the chauffeur.
나는 운전사 역할을 하고 있었다.

So I shut up, went back, actually learned it, then came back to the conversation. It was humbling. It was also necessary.
그래서 나는 입을 다물고, 다시 돌아가서 실제로 배웠고, 대화에 다시 참여했다. 겸손해졌고, 또한 필요했다.

You don’t need to understand everything from first principles. That’s impossible.
모든 것을 근본 원리부터 이해할 필요는 없다. 그건 불가능하다.

The point is recognizing when you’re operating on chauffeur knowledge versus real understanding—and being honest about which one you have.
핵심은 운전사 지식과 진정한 이해 중 어느 쪽으로 움직이고 있는지를 인식하고, 자신이 어느 쪽인지 솔직히 인정하는 것이다.

Sometimes chauffeur knowledge is fine. If you’re prototyping fast, copy that Stack Overflow solution. Ship it. Learn later.
때때로 운전사 지식으로도 충분하다. 빠르게 프로토타입을 만든다면 Stack Overflow의 해결책을 복사해라. 배포하고 나중에 배우면 된다.
But when you’re building something that matters—something people depend on, something that needs to scale, something you’ll maintain for years—that’s when you need to slow down and actually understand what you’re doing.
그러나 사람들에게 의존되는, 확장이 필요하고, 수년간 유지할 무언가와 같이 중요한 것을 만들 때는 속도를 늦추고 실제로 무엇을 하는지 이해해야 한다.

If you made it this far and thought, “Oh god, this is me”—good. That means you’re self‑aware enough to do something about it.
여기까지 읽고 “오, 이게 바로 나다” 라고 생각했다면—좋다. 이는 당신이 스스로를 인식하고 행동에 옮길 만큼 자각하고 있다는 뜻이다.

The worst developers I’ve worked with weren’t the ones with chauffeur knowledge. They were the ones who refused to admit it.
내가 일해본 최악의 개발자는 운전사 지식을 가진 사람이 아니라, 그것을 인정하기를 거부한 사람들이다.

The best developers I’ve worked with? They said “I don’t know” constantly. Then they’d go learn, come back, and teach the rest of us.
내가 일해본 최고의 개발자는? 그들은 끊임없이 “모른다”고 말했다. 그리고 배우러 가서 돌아와 우리에게 가르쳐 주었다.

Be the second kind.
두 번째 유형이 되라.

P.S. – If you’re reading this thinking “I should share this in Slack,” but worried your team will think you’re calling them out… you’re overthinking it. Share it anyway. The developers who need it most won’t realize it’s about them. The ones who do realize are already working on it.
P.S. – “이걸 슬랙에 공유해야겠다” 라고 생각하면서도 팀이 나를 비난한다고 걱정한다면… 너무 생각하고 있는 것이다. 어쨌든 공유해라. 가장 필요로 하는 개발자는 자신에게 해당된다는 것을 깨닫지 못한다. 깨닫는 사람은 이미 작업 중이다.