작은 문제를 적은 자원으로 푸는 엔지니어링

출처 및 AI 안내: 이 글은 제미니의 개발실무 유튜브를 기반으로 작성되었습니다. gpt-5.6-sol 모델을 사용해 생성·편집했습니다.

비례 있는 엔지니어링은 현재 가진 자원으로 지금 문제를 풀고, 결과를 측정한 뒤, 한계가 실제로 드러났을 때 복잡성을 더한다. API가 조금 느리거나 작은 동시성 문제가 생겼다고 Redis, 캐시, 메시징, 서버 증설이 자동으로 필요한 것은 아니다. 먼저 현재 애플리케이션과 데이터베이스가 어디까지 할 수 있는지 알아야 한다.

이미 가진 용량부터 쓴다

애플리케이션 서버와 충분한 RDB가 있다면 먼저 그 자원 안에서 문제를 풀어 본다. 급박해서 서버나 인프라를 더해야 하는 순간도 있다. 그런 상황이 아니라면 이미 주어진 자원부터 활용한다.

그 자원으로 어느 정도 효율을 낼 수 있는지 측정하고 계속 검증한다. 트래픽이나 규모가 더 커져 현재 시스템으로 해결하기 어려워질 때 다음 기술을 더한다.

아직 없는 사용자를 위해 크게 만들지 않는다

수백만 사용자의 아키텍처를 복사해 큰 이론상 용량을 만드는 일은 쉬울 수 있다. 실제 사용자 열 명에게 맞는 작은 시스템을 만드는 편이 더 어렵다.

Redis, 캐시, 서버 증설이나 분산 컴포넌트를 더하면 더 많은 자원을 쓴다. 현재의 작은 문제가 요구하기 전에 이런 수단을 붙이는 것은 오버엔지니어링이다.

작은 해법을 반복해야 판단력이 생긴다

테이블 하나로 풀 수 있는 문제는 테이블 하나에서 시작하면 된다. 작은 문제를 실제 크기에 맞춰 효율적으로 해결하는 경험이 판단력을 만든다. 나중에 큰 문제가 정말 강한 도구를 요구할 때 이 경험이 더 중요해진다.

아는 기술을 너무 일찍 모두 쓰면 다음 선택지도 줄어든다. 트래픽이 커졌는데 익숙한 캐시와 분산 계층을 이미 전부 붙였다면 다음 문제는 더 풀기 어려워진다.

다양한 규모의 경험이 단일 정답을 막는다

자원이 풍부한 환경만 경험하면 새 저장소의 운영 비용을 느끼지 못할 수 있다. 전담팀이 제공하고 튜닝해 주기 때문이다. 작은 시스템만 봤다면 대규모 성능 테스트로 반대쪽 경험을 보완할 수 있다. 서로 다른 규모에서 일하거나 부족한 쪽을 의도적인 실험으로 경험하면 선택지가 넓어진다.

그래서 특정 아키텍처를 늘 써야 한다거나, 영속성 엔티티를 도메인 객체로 절대 쓰면 안 된다거나, 모든 서비스의 레이어 수가 같아야 한다고 단정할 수 없다. 이 네 가지 주제는 하나의 정답이라기보다 직접 고민하고 경험하고 실험해 볼 거리다. 좋은 엔지니어링은 문제의 크기에 맞게 자원을 쓰고 규모가 커질 때 필요한 기술을 더한다.