백엔드 개발자를 꿈꾸는 학생개발자에게라는 글을 읽고

📌 참고 자료

📌 오늘의 한 줄

백엔드 개발자는 폭넓은 기술을 접할 수 있는 역할을 수행하며, SE(System engineer), FE(Front End) 등 인접한 분야의 개발자와 소통할 기회가 많습니다.
개발 프로젝트 팀을 음악 밴드에 비유하자면, 인프라 담당자와 백엔드 개발자는 드럼이나 베이스 기타와, 프런트엔드 개발자는 보컬이나 퍼스트 기타와 비슷하게 느껴집니다. 무대에서 주목받고 찬사를 받기 쉬운 쪽은 보컬이지만 베이스와 드럼이 안정적으로 뒷받침하지 못하면 좋은 공연이 나올 수 없습니다.
백엔드 개발자는 시스템을 안정적이고 효율적으로 만들 때 보람을 느낍니다. 내면적인 부분까지 완성도를 추구하는 사람이 백엔드 개발을 하기에 더욱 적합합니다.
백엔드 개발자는 포용하는 분야가 많고, 이론과 실무경험이 잘 조화될 수 있습니다. RDB, TCP/IP, OS, 통계 등의 바탕이 되는 지식들은 몇십 년 전부터 축적되면서 발전된 것들입니다. 그래서 실무에 들어가기 전에 학교에서부터 준비할 수 있는 지식이 많기도 합니다.
테스트 코드를 작성하는 능력도 백엔드 개발자의 핵심역량 중 하나이기도 합니다.
'시간이 없어서 테스트를 못 만들었다’는 말은 '나는 테스트 코드를 만드는데 시간이 많이 걸린다’는 말과 동일합니다. 해당 언어에 대한 숙련도가 떨어지는 사람일수록 테스트 코드를 작성하는데 부담을 크게 느끼는 경우도 많이 봤습니다.

📌 도구를 배우는 것이 과연 실력일까?

신입사원에게 레벨2 정도는 바라고 있다.
레벨0: 이미 쓰고 있는 개발도구의 사용법을 알려주거나 가이드 문서를 줘도 잘 못 씀
레벨1: 알려주거나 같은 팀에서 만든 가이드 문서에 있는 만큼만 쓸 수 있음
레벨2
개발도구의 공식 레퍼런스를 보고 사용법을 스스로 익힐 수 있음
자신이 경험한 사용법을 문서화해서 팀 내에 전파할 수 있음
레벨3
여러 개발도구를 비교 분석해서 상황에 적합한 도구를 선택할 수 있음
공식 레퍼런스 문서에서 부족한 부분을 수정해서 기여할 수 있음
레벨4
개발도구의 문제를 소스 코드를 수정해서 Fork/패치해서 사용할 수 있음

📌 백엔드 개발에 필요한 지식

필요한 지식들

1.
웹 생태계의 스펙
HTML, HTTP(1.1 , HTTP/2)
2.
기본 SDK, 라이브러리/프레임워크 이해와 활용
3.
클라이언트를 위한 API 설계
4.
서버/컴퍼넌트/객체 간의 역할 분담/의존성/통신 방법 설계
5.
저장소 활용
DBMS 설계
Cache 적용
Global/Local cache 적용범위, 라이프 싸이클, 솔루션 선택
6.
파일 저장 정책/솔루션 선택 활용
7.
검색엔진 연동 방식 결정
8.
빌드 도구
Maven/Gradle
9.
배포 전략
10.
성능 테스트/프로파일링/튜닝
JVM 레벨의 튜닝 (GC 옵션 등)
웹 서버(Nginx,Tomcat)등의 설정/튜닝
11.
OS 설정의 주요 값 확인
12.
인접 기술에 대한 이해
DBMS, Front End 등
13.
서버 개발자에만 해당하지는 않는 항목
테스트 코드 작성/리팩토링 기법
버전 관리 전략
branch 정책 등

DB 어디까지 알아야 하나? 어떻게 활용하나?

사용자의 요청량과 저장 용량이 많은 서비스에는 하나의 저장소만을 쓰지 않는다.
네이버의 서비스에서도 MySQL, CUBRID, Redis, Memchaced, HBase, MonoDB, Elasticsearch 등 다양한 저장소를 활용하고 있다.
네이버와 라인에서 Arcus, Elasticsearch, Cassandra, Redis, HBase와 같은 다양한 저장소가 쓰인 사례
다양한 저장소가 쓰이는 시대에도 RDB(관계형 데이터베이스)는 여전히 가장 우선시되는 저장소이다. RDB를 잘 다루는 능력은 백엔드 개발자의 핵심 역량 중 하나이다.
쿼리의 호출 횟수나 실행 계획이 비효율적이지 않은지 확인하는 습관이 필요하다.
운영 중에도 느린 쿼리를 모니터링하고 DBA와 협업하여 성능 개선을 하는 작업을 실무개발자들은 꾸준히 하고 있다.
ORM같은 추상화된 프레임워크를 써서 직접 SQL을 작성하지 않는 경우에도 그런 작업들은 더욱 중요하다.
요즘은 복잡한 JOIN은 가급적 피하는 경향이 생겼다.
데이터를 조회하는 SQL이 단순할수록 데이터를 다른 저장소에 캐시하거나 분산해서 저장하기가 쉬워진다.
대용량을 저장하는 UGC 서비스에서는 RDB 테이블 사이의 JOIN은 최대한 제약을 하고 어플리케이션 레벨에서 여러 저장소의 연관된 데이터를 조합한다.

DB서버 1대로 트래픽이나 저장량이 감당이 안되면?

이를 분산할지도 항상 어려운 과제입니다.
성능 향상을 위해서 Local cache, Global cache를 동원하기도 한다.
복제지연(Replication replay)이 그다지 민감하지 않은 서비스에서는 쓰기 작업은 Master 노드로, 읽기작업은 복제되는 Master의 데이터를 복제한 여러 대의 Slave로 DB를 구성하기도 한다.
총 저장되는 용량이 많을 때에는 여러 개의 DB인스턴스에 이를 나누어서 저장하기도 한다. 이를 샤딩이라고 부른다.

📌 용어의 범위

협업하는 사람들 사이에서 용어의 정의가 명확하지 않다면 갈등이 생기기 쉽다.
익숙하게 쓰고 있는 용어일지라도 그 정의에 대해서 한번도 찾아본 적이 없다면 원래의 의미를 잘못 이해했을 가능성이 높다.
책이나 인터넷 동영상에서도 정밀하지 못한 용어를 쓰는 경우가 꽤 많다.
때로는 용어의 정의 자체가 논쟁적인 경우도 있다. 그런 경우 어떤 논란이 있는지 이해를 한다면 그 용어를 피하거나 합의점을 찾아가는데 도움이 된다.

📌 학습이 필요한 내용들

샤딩
복제 지연
Master / Slave 구성
Local cache, Global cache
DB 서버 1대로 감당이 안되면 어떻게 분산할까?
IaaS, PaaS, SaaS
TOP