기술을 알면 기술에 갇힙니다

by 그릿 | GROWTH_ESSAY | 2026-03-30

멘토링을 하다 보면 이런 설계를 자주 봅니다.

"선착순 보장을 위해 Redis의 Lua Script를 사용하고, 순번 표시를 위해 ZSet을 적용하고, 실시간 업데이트를 위해 SSE를 도입하겠습니다."

틀린 말이 아닙니다. 기술에 대한 이해도가 보입니다. 공부를 많이 했구나, 싶습니다.

그런데 뭔가 불안합니다.

만약 이 회사가 보안 규정상 Redis를 못 쓴다면? 인프라 표준이 Kafka로 바뀐다면? 이 설계는 처음부터 다시 써야 합니다.

기술을 잘 아는 것과, 기술을 잘 쓰는 것은 다릅니다.

기술은 도구입니다

당연한 말 같지만, 많은 사람들이 잊습니다.

Redis는 도구입니다. Kafka도 도구입니다. Spring도 도구입니다. 모든 기술은 도구입니다.

도구는 문제를 풀기 위해 존재합니다. 문제가 먼저이고, 도구는 그 다음입니다.

그런데 기술을 많이 공부하면 순서가 뒤집힙니다. 도구가 먼저 떠오릅니다. "이 문제는 Redis로 풀어야지." "이건 Kafka가 필요해." 도구가 사고의 출발점이 됩니다.

문제는, 도구에서 출발하면 도구에 갇힌다는 겁니다.

도구가 사라지면 어떻게 될까요

면접에서 이런 질문이 나옵니다.

"우리 회사는 보안 규정상 Redis를 못 씁니다. RDB만 써야 한다면 대기열을 어떻게 구현하시겠습니까?"

기술에 매몰된 사람은 막힙니다. Redis가 없으면 대기열을 못 만든다고 생각하니까요. ZSet이 없으면 순서를 어떻게 보장하지? Lua Script가 없으면 원자성을 어떻게 보장하지? 머릿속이 하얘집니다.

추상적으로 사고하는 사람은 다릅니다.

"인메모리의 정렬된 셋 대신 RDB의 인덱스를 활용해 순서를 보장하고, 낙관적 락을 통해 동시성을 제어하겠습니다. 구현체만 달라질 뿐, 논리적 구조는 동일합니다."

이렇게 답합니다. 도구가 바뀌어도 흔들리지 않습니다. 본질을 알기 때문입니다.

면접관이 보고 싶은 건 Redis 사용법을 아는지가 아닙니다. Redis라는 도구가 사라졌을 때도 시스템을 설계할 수 있는 사람인지를 보는 겁니다.

기술의 이름이 아니라 속성을 정의하세요

설계의 초기 단계에서는 기술의 이름이 아니라 시스템이 갖춰야 할 속성을 정의해야 합니다.

대기열을 예로 들어봅시다.

"Redis의 ZSet을 써야 한다"가 아닙니다.

"수만 명이 동시에 접속해도 순서가 보장되어야 한다." 이게 먼저입니다. 이건 동시성 제어와 원자성 보장이라는 속성입니다. 이 속성을 만족시킬 수 있다면, 도구는 Redis든 RDB든 Kafka든 상관없습니다.

"SSE를 써야 한다"가 아닙니다.

"유저가 묻기 전에 서버가 상태 변화를 전파해야 한다." 이게 먼저입니다. 이건 푸시 기반 실시간 통신이라는 속성입니다. 이 속성을 만족시킬 수 있다면, SSE든 WebSocket이든 Polling이든 상관없습니다.

속성을 먼저 정의하면, 도구는 갈아끼울 수 있습니다. 도구를 먼저 정하면, 도구에 종속됩니다.

추상화의 힘

이게 추상화입니다.

추상화란 구체적인 것에서 본질을 뽑아내는 것입니다. Redis에서 "인메모리 정렬 셋"이라는 본질을 뽑아내고, Lua Script에서 "원자적 연산 보장"이라는 본질을 뽑아내는 것입니다.

본질을 알면 도구가 자유로워집니다. Redis가 없으면 다른 도구로 같은 본질을 구현하면 됩니다. 도구는 바뀌어도 본질은 남습니다.

반대로 본질을 모르면 도구에 갇힙니다. Redis만 알고, Redis가 없으면 아무것도 못 합니다. 도구가 곧 한계가 됩니다.

프로그래밍의 역사는 추상화의 역사입니다. 어셈블리에서 C로, C에서 Java로, 프레임워크로, 라이브러리로. 계속 추상화 수준이 올라갔습니다. 구체적인 것을 감추고, 본질만 드러내는 방향으로요.

좋은 개발자는 이 흐름을 이해합니다. 도구 사용법을 아는 것에서 멈추지 않고, 도구 뒤에 있는 본질을 봅니다.

비즈니스가 먼저입니다

한 단계 더 올라가봅시다.

기술적 속성보다 먼저인 게 있습니다. 비즈니스 요구사항입니다.

"대기 중인 유저에게 어떤 경험을 제공해야 하는가?"

이 질문이 먼저입니다. ZSet이 먼저가 아닙니다.

유저가 불안하지 않으려면 뭘 보여줘야 할까요? 순위? 예상 대기 시간? 실시간 갱신? 정확도는 어느 수준이어야 할까요? 1초 단위? 10초 단위? 갱신이 늦어도 되는 상황인가요, 아니면 즉각적이어야 하나요?

이런 질문에 답이 있어야 합니다. 답이 있으면 기술적 속성이 정해집니다. 속성이 정해지면 도구를 선택할 수 있습니다.

비즈니스 → 속성 → 도구.

이 순서가 맞습니다. 도구 → 속성 → 비즈니스가 아닙니다.

기술에 갇힌 사람 vs 기술을 쓰는 사람

기술에 갇힌 사람은 이렇게 말합니다.

"이건 Redis로 해야 해요. ZSet이 순서를 보장하거든요."

기술을 쓰는 사람은 이렇게 말합니다.

"순서 보장이 핵심이에요. Redis의 ZSet이 적합하지만, RDB 인덱스로도 가능합니다. 상황에 따라 선택하면 됩니다."

같은 기술을 알고 있어도, 말이 다릅니다. 사고방식이 다릅니다.

전자는 도구에 종속되어 있습니다. 후자는 도구를 사용하고 있습니다.

회사가 원하는 건 후자입니다. 인프라가 바뀌어도, 제약이 생겨도, 문제를 풀 수 있는 사람. 도구가 사라져도 시스템을 설계할 수 있는 사람.

정리하면

기술을 많이 알면 기술에 갇히기 쉽습니다.

도구가 사고의 출발점이 되면, 도구가 한계가 됩니다. 도구가 바뀌면 아무것도 못 합니다.

설계의 초기 단계에서는 기술의 이름이 아니라 속성을 정의하세요. Redis가 아니라 "순서 보장". Kafka가 아니라 "비동기 처리". SSE가 아니라 "실시간 전파".

속성을 알면 도구는 갈아끼울 수 있습니다. 도구는 바뀌어도 본질은 남습니다.

비즈니스가 먼저이고, 속성이 그 다음이고, 도구는 마지막입니다.

기술을 아는 것에서 멈추지 마세요. 기술 뒤에 있는 본질을 보세요.

그래야 기술을 쓰는 사람이 됩니다. 기술에 갇힌 사람이 아니라.