Quartz 4

주니어 개발자를 위한 기술 역량 증명법: '해봤다'를 넘어 '안다'로

8 min read

주니어 개발자를 위한 기술 역량 증명법: ‘해봤다’를 넘어 ‘안다’로

최신 기술을 단순히 ‘사용해 봤다’는 것과, ‘왜(Why) 그 기술을 선택했으며, 그 아키텍처가 어떤 의미를 갖는지 정확히 이해하고 있다’는 것을 보여주는 것은 신입과 경력(혹은 시니어)을 가르는 결정적인 차이입니다.

부트캠프와 개인 프로젝트를 진행하면서 **‘최신 기술과 아키텍처에 대한 깊은 이해’**를 증명하기 위해 추가로 갖춰야 할 부분들을 4가지 핵심 관점으로 정리합니다.

1. 기술 선택의 “Why”를 설명하는 능력

가장 중요한 부분입니다. 면접관은 ‘무엇을 썼는지’보다 ‘왜 썼는지’를 궁금해합니다. 이는 해당 기술의 본질과 존재 이유를 이해하고 있음을 증명합니다.

  • 보여줄 것:
    • Kubernetes (K8s) vs. EC2+스크립트: “왜 굳이 복잡한 K8s를 도입했나요?”라는 질문에, “초기엔 EC2에 PM2/Gunicorn으로 배포했지만, 마케팅 데이터 수집 모듈이 트래픽에 따라 스케일 아웃이 필요했고, 장애 발생 시 자동 복구(Self-healing) 기능이 필수적이어서 컨테이너 오케스트레이션을 도입했습니다.”라고 답할 수 있어야 합니다.
    • FastAPI vs. Django/Flask: “왜 Python 백엔드 중 FastAPI를 선택했나요?” → “향후 AI 모델 서빙 API로의 확장을 고려할 때, 비동기(Async) 처리를 통한 고성능과 자동 API 문서(Swagger) 생성이 데이터 처리 파이프라인에 가장 적합하다고 판단했습니다.”
    • Terraform (IaC)의 필요성: “왜 클릭 몇 번으로 만들 수 있는 인프라를 코드로 관리했나요?” → “개발/스테이징/운영 환경의 인프라 구성을 일관되게 유지하고(Reproducibility), 변경 이력을 Git으로 관리하며, 실수를 방지하기 위해(Idempotency) IaC를 도입했습니다.”

2. “트레이드오프(Trade-off)“를 인지하고 내린 결정

모든 기술과 아키텍처에는 장점과 단점(비용, 복잡성, 러닝 커브)이 공존합니다. ‘만능 기술’은 없습니다. 이 트레이드오프를 명확히 인지하고 있음을 보여주는 것이 전문가의 증명입니다.

  • 보여줄 것:
    • MSA (마이크로서비스 아키텍처)의 함정: “처음부터 모든 것을 마이크로서비스로 쪼개는 대신, 핵심 기능(데이터 수집, 데이터 조회)을 하나의 모놀리식 API로 먼저 구현했습니다. MSA는 서비스 간 통신 복잡성과 데이터 일관성 유지 비용이 크기 때문에, 명확한 분리 기준이 생겼을 때 K8s 내에서 점진적으로 분리하는 전략을 택했습니다.”
    • Managed Service (예: AWS RDS) vs. Self-Hosting: “K8s 클러스터 안에 직접 PostgreSQL 컨테이너를 띄우는 대신 AWS RDS를 사용했습니다. 이는 운영/백업/패치 부담을 클라우드 벤더에 맡기고, 저는 애플리케이션 로직에 집중하기 위한 전략적 선택이었습니다. 물론 비용은 더 발생하지만, 1인 개발 상황에서 운영 안정성을 확보하는 것이 더 중요했습니다.”

3. 실패 및 “트러블슈팅” 경험의 자산화

이론만 아는 사람은 에러가 발생하지 않는 ‘Happy Path’만 이야기합니다. 실제 운영을 아는 사람은 ‘문제가 터졌을 때’ 어떻게 해결했는지를 이야기합니다.

  • 보여줄 것:
    • K8s의 단골 문제: “분명히 이미지를 빌드했는데 Pod가 ImagePullBackOff 에러가 발생했습니다. 원인을 추적해보니 프라이빗 레지스트리(ECR/GHCR) 접근 권한(IAM Role/Secret) 문제였고, Service Account에 올바른 권한을 부여하여 해결했습니다.”
    • CI/CD 파이프라인 최적화: “초기 CI/CD 파이프라인 빌드 시간이 10분이 걸렸습니다. 원인은 Docker 빌드 시 매번 모든 의존성 라이브러리를 새로 다운로드하는 것이었습니다. Docker의 멀티 스테이지 빌드와 캐시 레이어를 활용하여 빌드 시간을 2분으로 단축했습니다.”
    • 모니터링 경험: “API 응답 속도가 느려지는 것을 Grafana 대시보드로 확인했습니다. kubectl top pod로 리소스를 확인하고 로그를 분석한 결과, 특정 API의 DB 쿼리가 비효율적인 것을 발견하고 인덱싱을 추가하여 해결했습니다.”

4. 아키텍처의 “시각화” 및 “문서화”

“아키텍처를 이해했다”는 말의 가장 확실한 증거는 그것을 **그림(Diagram)**으로 그려낼 수 있다는 것입니다.

  • 보여줄 것:
    • 완성도 높은 아키텍처 다이어그램: (매우 중요) README.md에 draw.io나 Lucidchart 같은 툴로 그린 시스템 아키텍처 다이어그램을 반드시 포함해야 합니다.
    • 다이어그램에 포함될 내용:
      1. Cloud Infra: AWS/GCP의 VPC, Subnet, EKS/GKE, RDS, S3 등 리소스와 그 관계
      2. K8s 내부: Ingress Controller, Service, Pods(Deployment), ConfigMap, Secret 등
      3. CI/CD 파이프라인: GitHub → GitHub Actions (Build/Test) → Docker Hub/ECR (Push) → ArgoCD/KubeCtl (Deploy) → EKS Cluster
    • 명확한 README: 왜 이 프로젝트를 시작했는지 (마케터의 Pain Point), 어떤 기술을 ‘왜’ 썼는지, 그리고 이 아키텍처가 어떻게 동작하는지 명확히 설명해야 합니다.

결론적으로,

6개월간의 프로젝트에서 이 4가지(Why, Trade-off, Troubleshooting, Diagram)를 명확하게 정리하고 설명할 수 있다면, 단순한 부트캠프 수료생이 아닌 **‘아키텍처를 이해하고 주도적으로 시스템을 설계할 수 있는 엔지니어’**로 강력하게 어필할 수 있을 것입니다.

작성일: 2025-10-30

그래프 뷰