Week 0 _ review(1) #백엔드 개발자의 진로

이 글은 개발을 본격적으로 배우기에 앞서 프론트엔드와 백엔드가 하는 일을 알아보고, 참고자료를 리뷰하는 글이다.

내게 필요한 것 >>>       

내가 좋아하는 것 >>>       

내 개인적인 생각 >>>       

 

프론트엔드가 하는 일

 #UI 개발.
 #event에 대한 로직 개발.
 #크로스 브라우징/디바이스.
 #데이터 시각화.

 

다음 세 가지에 관심이 있다면 프론트엔드 개발자!

1. 창업, 아이디어, 나만의 것

>>> 👌👌

2. 사용자 관점에서 생각

>>> 👌

3. UI가 완벽하고 아름다운 사이트

>>> 👎 아름다움 보다는 효율과 편리를 더 중시

 

 

백엔드가 하는 일

 #API.
 #Data Pipeline.
 #Infrastructure&Architecture

 

다음 세 가지에 관심이 있다면 백엔드 개발자!

1. 서비스 구성 _ 데이터 구조 설계 등 전체적인 서비스 구성에 관심이 있는가?

>>> 👌
2. 데이터 중심의 사고 _ 데이터 분류와 관계, 전달에 관심이 있는가?

>>> 👌👌👌
3. 효율적이고 안정적인 시스템 _ 많은 사용자가 접속해도 효율적이고 안정적인 서비스를 만드는데 관심이 있는가?

>>> 👌👌

 

나는 백엔드를 하고 싶으므로 백엔드 관련 추가 자료를 보고 리뷰를 아래에 적었다. 

(물론 프론트엔드 자료도 모두 보았다)

 

 

 

백엔드 개발자의 진로

원글 >>> https://d2.naver.com/news/3435170

 

백엔드 일의 범위

- 서버관리, DB관리

- SE(System engineer), FE(Front End) 등 인접한 분야의 개발자와 소통할 기회가 많음

- 대용량 데이터 분석이나 처리

- 모니터링, 관리 도구 제작

=> 깊이 있는 전문분야와 함께 애플리케이션 개발 능력을 갖춘다면 더욱 유능한 개발자가 될 수 있음

 

보람과 고충

- 백엔드 개발자는 시스템을 안정적이고 효율적으로 만들 때 보람을 느낌

- 에러 없이 서버 프로그램이 실행될 때
- 성능을 획기적으로 개선했을 때

- 모듈의 구조를 개선해서 코드를 많이 줄였을 때

- 내면적인 부분까지 완성도를 추구하는 사람이 백엔드 개발에 적합

- 24시간 실행된다는 점이 백엔드 개발자들에게는 고충

- 장애 상황에 대응

- 규모가 큰 서비스에서는 당번(oncall)을 정해서 통상적인 휴식 시간대에는 돌아가면서 대응을 하기도

 

향후 전망

- 과제가 늘어가는 속도에 비하면 기술 발전 속도는 오히려 느리다고 느껴짐 -> 백엔드 개발자 수요는 많음

- 새로운 도구와 프레임워크들도 기존의 개발자에게 더 큰 기회

- 실무에서는 갑자기 새로운 업무가 필요해졌을 때 사람이 채용될 때까지 기다릴 수도 없음. 그래서 새로운 개발 분야에 적응할 수 있는 역량이 필요함

- 백엔드 개발은 여러 분야와 연결되기에 그런 면에서 무난한 선택. 포용하는 분야가 많음.

- 백엔드 개발을 하다가 데이터 분석, 모델링 업무에 참여하는 경우도 더 늘어날 것 같음.

- 서비스를 개발하면서 사용자의 특성을 이해한 개발자가 이론적인 깊이까지 갖춘다면 가치가 더 높아질 수 있음.

- 대용량의 서비스를 개발하는 백엔드 개발자는 AI/빅데이터와 맞닿아 있음.

 

다른 분야로의 확장

- 서비스/제품의 기획 단계에서 개발자의 의견이 많이 반영
- 개발업무를 개선하기 위해 만드는 자동화 도구들, 모니터링 도구들도 큰 방향성을 잡는 사람은 개발자일 수밖에 없음

- 구체적인 데이터 구조를 고려하는 백엔드 개발자가 초기에 의견을 주면 효율적인 방향으로 기획이 이루어질 가능성이 높아짐. -> 이것은 실제 실무에서 중요할 것 같다. 내가 속한 팀도 개발자가 진짜 개발만 해서 반년 이상 고생하고 있다. 안 하느니만 못한 개발이 될 수 있다. 

- '경영'의 영역에 관여하는 것은 개발 조직에서 조직장이 하는 역할 : 리소스 투자, 채용, 보상, 등의 의사결정

- 조직장은 기술뿐만 아니라 사람 사이의 일에 관심을 깊이 가져야 잘할 수 있는 일

- 그런 일로도 긍정적인 영향력을 크게 미친다면 조직 내에서 중요한 존재로 대우받을 것

 

백엔드 개발에 필요한 지식

<웹 서버 개발 요소>  -> 아직 1도 모르겠음😥

• 웹 생태계의 스펙
• 기본 SDK, 라이브러리/프레임워크 이해와 활용
• 클라이언트를 위한 API 설계
• 서버/컴퍼넌트/객체 간의 역할 분담/의존성/통신 방법 설계
• 저장소 활용
• 검색엔진 연동 방식 결정
• 빌드 도구
• 배포 전략
• 성능 테스트/프로파일링/튜닝
• 인접 기술에 대한 이해
• 서버 개발자에만 해당하지는 않는 항목

데이터베이스

- RDB를 잘 다루는 능력은 백엔드 개발자의 핵심 역량 중 하나(RDB = 관계형데이터베이스)

- 쿼리의 호출 횟수나 실행 계획이 비효율적이지 않은지 확인하는 습관이 필요

- 느린 쿼리를 모니터링하고 DBA와 협업하여 성능 개선을 하는 작업

 

개발툴

<개발자의 수준 분류>

레벨0😑

>>> 이미 쓰고 있는 개발도구의 사용법을 알려주거나 가이드 문서를 줘도 잘 못 씀
레벨1😐

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

 

=> 신입사원이라도 레벨2 정도는 함께 일할 개발자에게 기대를 하게 됩니다. 

 

보안

- XSS, CSRF, SQL Injection 공격에 대해서 대처하는 방법은 모든 개발자가 알아야 함. -> 이번에 처음 들어봄...ㅜㅜ

 

테스트

- 테스트 코드를 작성하는 능력도 백엔드 개발자의 핵심역량 중 하나 -> 핵심역량이 꽤나 많다... ㄷㄷ

- 최근 백엔드 개발자의 업무는 API 서버 개발에 더 집중되고 있음

- 최종적으로 UI와 통합하기 전에 개발한 API를 스스로 테스트해야 할 필요성 커짐

- 오류 제보를 받아서 수정 후 재배포하고 다시 알리는 비용은 스스로 오류를 발견했을 때보다 굉장히 크기 때문

- 최대한 모든 경로를 상상해서 테스트 코드를 작성

- '시간이 없어서 테스트를 못 만들었다’는 말은 '나는 테스트 코드를 만드는데 시간이 많이 걸린다’는 말과 동일 -> 시간이 없다는 말, 바쁘다는 말은 절대 하지 말 것. 자신의 무능함을 더욱 드러낼 뿐!

- 테스트는 실제적이 이득의 관점에서 생각해보아야 함.

• 유지보수 기간의 생산성을 높여주고 새로 프로젝트에 투입될 사람에게도 이득을 주는 테스트
• 프로젝트 오픈 일정 직전까지의 코드 변경과 버그 발견에 도움을 주는 테스트
• 오늘 당장 프로그램을 목표한 곳까지 작성하는 일을 더 빨리 마치게 해주는 테스트

- 부분적으로 잘라서 테스트하는 것이 버그를 쉽게, 빨리 잡는데 도움이 됨 <> 마지막 날에 한 번에 테스트한다면 디버깅에 훨씬 시간이 많이 걸릴 것 -> 코딩도 부분적으로 잘라서 하면 더 쉽게 작성할 수 있을까?

- 긍정적인 경험을 쌓아가다 보면 더 넓은 범위와 다양한 기법으로 테스트 코드를 작성하는데 동기유발이 됩니다.

- 점진적으로 테스트 코드를 작성하는 범위를 늘려가는 방식이 도움이 됨 -> 뭐든지 점진적 과부화로!

 

자료구조/알고리즘

- 실무에서는 기본적인 알고리즘을 직접 구현하지는 않음

- 이미 구현된 솔루션을 잘 선택하고 활용하기 위해서는 그 바탕이 되는 지식이 중요 -> 평소 관련 글이나 강의를 들어두자.

- 대용량 데이터를 어떻게 저장하고 탐색할지를 결정할 때도 자료구조는 중요함

 

시스템을 어떻게 자를 것인가

- 나누어진 경계에 맞추어 업무의 범위나 협업 방식이 정해짐. 구조가 잘 잘라져 있어야 많은 사람들이 동시에 협업하면서 소프트웨어를 개발할 수 있음 -> 바운더리의 중요성은 개발에서도 동일. 업무 복잡도를 낮추기 때문.

 

마치며

- 일단 실행은 되는 백엔드 프로그램을 만드는 일은 쉽지만, 협업하기에 좋은 방식으로 성능과 안정성까지 고려한 백엔드 프로그램을 만드는 개발은 쉽지 않음

- 모니터링과 데이터 수집, 분석 등 사용자의 눈에 보이지 않는 영역들도 실무에서는 많은 비중

- 데이터나 사용자가 적었을 때에는 효율적이었던 구현 방식이 시스템이 성장하면서 문제의 근원지가 되기도 함 -> 스프레드 시트로 수백만의 데이터를 다루면서 이 부분만큼은 매우 공감

- 현실의 문제를 해결하고 상상을 실현시키는 개발자로 나아가기를. -> 내가 매우 매우 되고 싶은 모습. 역시 나는 개발자 해야 함.

 

---

리뷰 후기

- 원래는 참고로 본 자료 모두에 대한 리뷰를 작성하려고 했으나 글이 길어져서 다음 review(2)에 작성하기로 함.

- 보면서 느낀 점은 아직 내가 모르는 용어와 개념이 너무 많다는 점. 사실 글의 80%는 이해하지 못함. 때문에 리뷰도 이해 가능한 부분만 작성함. (많은 부분 생략되어 있음)

- 리뷰를 하면서 과연 내가 백엔드를 할 수 있을까 걱정이 들기도 함. 그래서 '그냥 하면 되지'라고 가볍게 넘겨버리기로 함.

- 의미 있는 내용은 하이라이트를 칠했는데, 다음에 다시 보러 왔을 때 보기 편할 듯. 앞으로 이렇게 작성하자.