사이드 프로젝트, 백엔드 개발자에게 왜 여전히 유효한가
4년차 이상의 백엔드 개발자라면 업무에서 맡는 도메인이 점점 좁아지는 경험을 한다. 특정 시스템의 특정 레이어만 반복적으로 다루다 보면, 기술적 시야가 좁아지고 성장 체감도 떨어지기 쉽다. 이런 시점에서 사이드 프로젝트는 단순한 취미가 아니라, 실무에서 접하기 어려운 기술 영역을 능동적으로 탐색하는 수단이 된다.
커뮤니티 스레드에서 한 개발자가 공유한 사례는 흥미롭다. AWS의 200여 개 서비스가 결국 EC2, Lambda, S3, DynamoDB, KMS, IAM 등 핵심 10여 개 서비스 위에 구축되어 있고, 그 아래에는 AWS가 외부에 노출하지 않는 더 깊은 기반 서비스들이 있다는 것이다. 이 개발자는 그 "보이지 않는 기반"을 직접 구현하는 사이드 프로젝트를 진행했다. 루트 키와 인증서 관리, 인프라 구성 저장소, 아이덴티티 관리 — 이 모든 것을 순환 의존성 없이, 외부 의존성 최소화 상태로 직접 구성하는 작업이다.
의존성 없는 시스템 설계, 실무에서 무엇을 가르쳐 주는가
이 프로젝트의 핵심 제약 조건은 "어떤 외부 서비스에도 의존하지 않는다"는 것이다. 실무에서는 대개 이미 구축된 인프라 위에서 개발하기 때문에, 의존성의 바닥이 어디인지 생각할 기회가 거의 없다. 하지만 이 제약을 스스로 부과해보면, 시스템 설계에 대한 근본적인 이해가 생긴다.
예를 들어 Java 기반 백엔드에서 설정 저장소를 구성할 때, 흔히 Spring Cloud Config나 AWS Parameter Store를 당연하게 사용한다. 그러나 아래처럼 의존성 없이 직접 만들어보면, 추상화 뒤에 숨어있던 복잡성이 드러난다.
// 외부 의존성 없이 로컬 파일 기반 설정 저장소 예시
public class MinimalConfigStore {
private final Map<String, String> store = new ConcurrentHashMap<>();
private final Path configPath;
public MinimalConfigStore(Path configPath) throws IOException {
this.configPath = configPath;
reload();
}
public void reload() throws IOException {
Properties props = new Properties();
try (InputStream in = Files.newInputStream(configPath)) {
props.load(in);
}
props.forEach((k, v) -> store.put(k.toString(), v.toString()));
}
public Optional<String> get(String key) {
return Optional.ofNullable(store.get(key));
}
}
이런 구현을 직접 해보면 실제 프로덕션 도구들이 왜 그렇게 설계되었는지, 어떤 트레이드오프가 있는지를 체득하게 된다.
"스케일 없음"을 의도적으로 선택하는 설계 철학
또 하나 주목할 지점은 해당 개발자가 "단일 노드로 충분한 부하를 처리할 수 있도록, 의도적으로 스케일 아웃을 고려하지 않았다"고 밝힌 부분이다. 실무에서는 항상 확장성을 고려하도록 훈련되어 있다. 하지만 이 관성이 오히려 시스템을 불필요하게 복잡하게 만드는 경우도 많다.
사이드 프로젝트는 이런 전제를 깨볼 수 있는 공간이다. 분산 처리 없이, 단일 프로세스로 문제를 얼마나 단순하고 견고하게 풀 수 있는지 실험해보는 것 자체가 설계 능력을 키운다. 4년차 이상 개발자라면 "어떻게 키울까"보다 "어떻게 단순하게 만들까"를 고민하는 경험이 더 필요한 시점이기도 하다.
정리
- 사이드 프로젝트는 실무에서 당연하게 사용하는 기반 기술의 내부 원리를 직접 구현하며 이해할 수 있는 기회다
- "외부 의존성 없이 구현"이라는 제약은 시스템 설계의 근본을 이해하게 만드는 효과적인 학습 방법이다
- 의도적으로 스케일을 제한하는 설계를 경험함으로써, 복잡성을 추가하는 것과 제거하는 것 사이의 균형 감각을 기를 수 있다