백엔드 개발자 로드맵

잡담/개발다반사

gnidoc 2019. 3. 9. 03:05

최근에 면접보다가 갑자기 떠올랐다.

굳이 한글로 보고싶다면 okky에서 어떤분이 번역한 것도 있다.(깃헙 링크)

왜 떠올랐냐면 포지션(백엔드)을 정해서 넣은 곳은 공통된 질문이 많았다.

(난 군대에서 전산병으로도 일했고 전역하고서는 주로 AWS에서 백엔드 개발을 했다)
(그리고 랜선을 손으로 만들 수 있다는걸 군대가서 알게 되었지)
(군대에서 네트워크관련해서 많이 배운것 같다-스스로...)

바로 스파크, 하둡, 하이브, 카프카을 사용해봤냐는 것이다. 그래서 갑자기 로드맵이 떠오르더라...

아닛... 근데 해당 내용은 백엔드 로드맵에 없다!

왜냐하면 빅데이터쪽은 데이터 엔지니어에 해당한다.

그런데 사실 회사에서 백엔드 업무를 하다보면 결국 빅데이터도 해야되더라...

로그가 쌓이는데 이게 서비스 규모에 비례해서 늘어나고 누적되다보니 결국에 이런게 필요했다.

그래서 하둡을 보다가 AWS에서 Athena 를 발견하고 이걸 썼다.

이름만 Athena이지 사실상 인프라는 만질 필요없는 하둡+스파크였다.

너무 편하게 쓰다보니 하둡은 생각조차 안하게 되더라...

비용도 S3에 데이터 쌓는 비용 + Query 당 금액만 내면 되서 매우 저렴한데

당시에 기본 query 동시처리 수가 5개가 최대였다.

회사에서 몇억씩 AWS를 쓰면 동시처리 수를 팍팍 늘려줬을텐데 그게 좀 아쉬웠다...

아무튼 클라우드를 사용하는 회사를 가려고 했었는데

생각보다 Athena와 같은 완전관리형 제품을 직접 사용하지 않고

직접 EC2 인스턴스에 인프라를 설치해서 사용하는 회사가 많았다.

왜지하고 생각해보니 이번에 Kafka를 공부하면서 깨달은게 있다.

AWS에서 비슷한 걸로 SQS를 제공해주는데

SQS와 Kafka 비용을 계산해보니 서비스 규모가 커질수록 SQS가 더욱 비쌌다.

(kafka는 서버당 비용, SQS는 메세지 큐당 비용)

실제로 전 회사에서 SQS를 사용했는데 1/5 정도는 SQS 비용이 나갔고 나머지는 RDBS, EC2, CloudFront가 주로 차지했다.

결국 클라우드 아키텍쳐에서 제일 중요한건 요금을 줄이는게 가장 큰 이슈인데

규모가 커질수록 EC2로 직접 클러스터 구성하는게 더 싸게 먹힌다...

그러니 클라우드를 써도 결국 오픈소스를 써야되더라...

(최근 지원한 곳들이 대부분 머기업이라 ㅎㅎ..)

그래서 백엔드도 딱히 업계 탑이다할 정도로 잘하진 않지만

데이터 엔지니어링쪽도 공부 중이다.

(공부라기보단 오픈소스 써보는 중이다)

아마 잘풀리면 데이터 사이언스쪽도 공부해보고 싶은데 이건 욕심인 것 같고

데이터 엔지니어링 + DevOps 이렇게 배워나가지 않을까싶다.

역시 인생은 고통의 연속... ㅋㅋㅋ

그래도 고통받다가 해결되면 레벨업한거 같아서 기분이 좋다 ㅋㅋ