백엔드 개발자가 알아야 할 것

지식 지도

백엔드 개발자가 다루는 영역은 넓다. 전부 외울 필요는 없다. 각 영역이 무엇을 풀려고 존재하는지 알고, 필요할 때 찾아서 쓸 수 있으면 된다.

flowchart TB
  subgraph g1["요청이 도착하기까지"]
    direction LR
    a1["인터넷"] --> a2["DNS"] --> a3["HTTP"]
  end
  subgraph g2["요청을 처리하는 코드"]
    direction LR
    b1["언어"] --> b2["웹 프레임워크"] --> b3["API 설계"] --> b4["인증·인가"]
  end
  subgraph g3["데이터"]
    direction LR
    c1["데이터 표현(JSON 등)"] --> c2["데이터베이스"] --> c3["배치 처리"]
  end
  subgraph g4["코드를 내보내는 일"]
    direction LR
    d1["Git"] --> d2["CI/CD"] --> d3["도커"] --> d4["클라우드"] --> d5["리눅스"]
  end
  subgraph g5["전체를 받치는 것"]
    direction LR
    e1["보안"] --> e2["아키텍처"]
  end

더 촘촘한 단계별 지도는 roadmap.sh/backend에 있다.

언어 고르기

특별한 이유가 없으면 오래 쓰여 안정적이고, 문제가 생겼을 때 답을 찾기 쉬운 언어를 고른다. 생태계와 팀의 경험이 언어 자체의 우열보다 중요하다.

웹 프레임워크

작은 서비스나 API 하나면 마이크로, 여러 사람이 오래 키울 서비스면 풀스택 쪽이 유지보수가 쉽다. 같은 개념이 프레임워크마다 어떻게 다른지는 Express 라우팅과 Django MTV를 비교해 보면 보인다.

API 스타일: REST · GraphQL · gRPC

백엔드가 외부에 내놓는 API는 대개 이 셋 중 하나다. 통신 단위·형식·강점과 약점, 고르는 기준을 SOAP·WebSocket·Webhook과 함께 비교한 표는 API 아키텍처 스타일에 있다.

• REST는 표준 규격이 아니라 아키텍처 스타일이다. 상태 없음(stateless), 캐시 가능 여부 명시, 균일한 인터페이스가 핵심이다. 설계 규칙은 REST API에 있다.
• GraphQL은 스키마로 타입을 정의하고 클라이언트가 원하는 필드를 질의한다. 구독(subscription)으로 실시간 갱신도 받는다.
• gRPC는 .proto로 서비스와 메시지를 정의해 여러 언어의 코드를 생성하는 RPC 방식이다. 자세한 내용은 gRPC: Protocol Buffers로 정의하는 RPC에 있다.

GraphQL의 도입 패턴은 GraphQL에 있다.

연차별 보안 학습 순서

보안팀은 인프라·계정·정책을 챙기지만, 고객이 쓰는 웹·앱의 API는 그것을 만든 개발자가 가장 잘 안다. 게시글 번호나 파일 경로를 바꿔 요청해도 남의 데이터가 나오지 않는지, 처리 단계에서 권한을 다시 확인하는지는 기능을 만든 사람이 점검할 몫이다. 로그인·권한·게시판·업로드를 만들기 시작하면 그 기능의 보안도 함께 맡는다고 보고, 연차에 맞춰 범위를 넓힌다.

세부 체크리스트는 API 보안 체크리스트, 파이프라인 쪽은 DevSecOps에 있다.

백엔드 개발자의 태도

정리

• 백엔드 지식은 「요청이 도착하기까지 → 처리 → 데이터 → 배포 → 보안·아키텍처」로 묶으면 지도가 잡힌다.
• 다 외우지 않는다. 무엇을 풀려고 있는 기술인지 알고 필요할 때 찾는다.
• 언어·프레임워크는 안정성과 생태계, 팀의 경험으로 고른다.
• API는 공개·일반 서비스는 REST, 다양한 화면은 GraphQL, 내부 서비스 간 통신은 gRPC가 기본 선택지다.
• 판단은 숫자로 한다.
• 내가 만든 API의 보안은 내가 점검한다. 신입은 웹 취약점, 1~3년차는 인증·인가와 시큐어 코딩, 그 위로 배포·비밀 관리 순으로 넓힌다.

관련 노트: 프론트엔드 학습 로드맵, 초보 웹 개발자의 공부 방향과 차별화, 데이터베이스 모델, REST API