2025년에 LeetCode 그라인딩 대신 내가 선택한 단 하나의 스킬
Source: Dev.to
2025년 말, 당신의 LinkedIn 피드가 나와 비슷하다면 두 가지가 뒤섞인 혼란스러운 모습일 겁니다:
- AI 에이전트가 모든 주니어 개발자를 대체하려 한다는 공포감 🤖
- 주니어들에게 면접을 통과하려면 500개 이상의 LeetCode 문제를 풀라고 조언하는 사람들 💻
이 조언은 구시대적인 느낌이에요—2026년 세계에서 2020년 구직 시장을 준비하는 것과 같죠. 알고리즘이 중요하지 않다는 말은 아니지만, 화이트보드에서 이진 트리를 뒤집는 능력이 새벽 3시에 프로덕션이 다운되는 것을 막지는 못합니다.
새로운 졸업생으로서 눈에 띄려면 단순히 코드를 작성하는 것에서 그 코드가 어디에 배치되는지를 이해하는 쪽으로 초점을 옮겨야 한다는 걸 깨달았습니다. 저는 이를 **“시스템 인식(System‑Awareness)”**이라고 부릅니다. 무한한 grind보다 이 한 가지 스킬을 우선시하는 이유와 배우는 방법을 공유합니다.
“튜토리얼 지옥” 각성 ⏰
그 뒤에 Docker로 컨테이너화하고 저렴한 클라우드 VM에 배포해 보았습니다. 모든 것이 엉망이 되었죠. 🔥
- 프론트엔드가 백엔드와 통신하지 못한 이유는? (내가 이해하지 못한 CORS 문제)
- 컨테이너가 재시작될 때 데이터베이스 데이터가 사라진 이유는? (영구 볼륨이 없어서)
- 레이턴시가 너무 높은 이유는? (데이터베이스를 다른 리전에 두었기 때문)
완벽한 React 코드는 시스템 인식이 전혀 없었기 때문에 무용지물이었습니다. 벽돌을 만드는 방법은 알지만, 벽을, 더 나아가 집을 짓는 방법은 몰랐던 것이죠. 🧐
이제는 “이 함수가 올바른 값을 반환하는가?”를 넘어서 다음을 생각합니다:
- 이 코드는 어디서 실행되고 있는가? (컨테이너? 서버리스 함수? 사용자의 브라우저?)
- 무엇과 통신하고 있는가? (데이터베이스, 캐시, 외부 API?)
- 어떻게 통신하는가? (HTTP/REST, gRPC, 메시지 큐?)
- 실패했을 때는 어떻게 되는가? (재시도하는가? 전체 파드가 다운되는가? 오류를 로그에 남기는가?)
DevOps 혹은 Platform Engineer를 꿈꾸는 사람에게 이것은 단순히 “있으면 좋은” 스킬이 아니라 핵심 스킬입니다. 우리의 일은 기능을 구현하는 것에만 국한되지 않고, 전체 머신—플랫폼—이 원활히 돌아가도록 보장하는 것입니다.
LeetCode 시간 대신 시스템 시간에 투자하기 🛠️
아키텍처 스케치
- 사용자의 진입점 (브라우저/모바일)
- 로드 밸런서
- 애플리케이션 서비스(들)
- 데이터베이스 및 캐시(예: Redis)
그림을 그릴 수 없으면 이해하지 못한 것입니다. 이 간단한 습관은 문법에 앞서 아키텍처를 생각하게 만듭니다.
컨테이너 깨뜨리기
그냥 컨테이너를 실행하는 대신, 의도적으로 깨뜨려 봅니다:
# Example: set resource limits too low
docker run --memory=50m myapp네트워킹 설정을 엉망으로 만들고, 리소스 제한을 너무 낮게 잡아 작은 부하에도 앱이 크래시하도록 만든 뒤, 그 실패 과정을 관찰합니다. 통제된 환경에서 시스템이 어떻게 무너지는지를 보는 것이 성공적인 튜토리얼보다 시스템 회복력을 배우는 데 더 큰 도움이 됩니다. 코드에 대한 화재 훈련과도 같습니다.
실전 관측성(Observability)
앱이 실행될 때 UI만 보는 것이 아니라 터미널을 열어 로그 스트림을 실시간으로 확인합니다. 정상적인 운영 로그와 경고 신호를 구분하는 법을 배우고, 기본적인 Prometheus 메트릭을 설정해 “효율적인” 파이썬 스크립트가 실제로 얼마나 메모리를 쓰는지도 확인합니다.
건강한 시스템이 어떤 모습인지 아는 것이 비정상적인 시스템을 고치는 첫걸음입니다.
새로운 “주니어” 표준 🚀
“나는 이 API 엔드포인트를 어떻게 작성하는지 아는 것에 그치지 않고, 그 성능이 데이터베이스 부하에 어떤 영향을 미칠지, 그리고 앞에 캐시를 두어야 하는 이유까지 이해하고 있습니다.”
이것이 바로 시스템 인식입니다. 그리고 저에게는 또 다른 이진 트리 문제를 파고드는 것보다 훨씬 흥미로운 일입니다.