글 리뷰_1_'백엔드 개발자를 꿈꾸는 학생개발자에게'

※ 이 포스트는 개발 학습 과정에서 읽게 된 포스트 중 좋은 글들을 정리해둘겸 작성하는 글이므로 자신이 개발 입문 레벨에서 접근하는 것이 아닌 정확한 지식이 필요하시다면 원문을 읽고 스스로 검색해보시는 걸 추천드립니다.

 

---

'사실 저번 3달 동안 코로나에 걸려 그 후유증으로 학습을 게을리했습니다...'라는 정말 현실도피적인 핑계를 대며 포스팅의 서두를 여는 제가 참 한심합니다. 그런 허접한 핑계 대신 포스팅을 잠시 쉬었던 또다른 이유를 대보자면 최근 블로그 포스팅을 하며 든 생각이 '아니 학습할 시간도 부족하고 아는 것도 없는 주제에 무슨 정보글을 쓰냐?'라는 것이었습니다. 포스팅을 하면서 아무리 시간을 적게 쓰더라도 만만치 않은 학습 시간을 빼앗게되고 물론 포스트를 작성하는 과정이나 이후 수정하는 과정에서 복습할 수 있는 장점이 있기야 하지만 복습은 메모를 보고 빠르게 할 수 있는 만큼 포스트 작성의 주된 이유가 될 수 없더라구요. 나중에 글을 올려놓고 발견하는 오타나 잘못된 내용들을 수정하는 데 드는 시간은 덤이고... 

 

원래는 이런거 감안하고도 블로그 포스팅에 좀 신경쓰자는 생각이었는데 최근에 이거저거 바빠서 포스팅에 시간이 뺏겨 공부가 뒷전인 경우도 생기더라구요. 때문에 앞으로 당분간은 장애해결이나 학습 중 좋은 포스트들에 대한 리뷰만 올릴 생각입니다. 물론 앞에 싸지른 글들은 마무리를 지어야할텐데 언제 다할지는... 

 

---

첫 리뷰 글은 네이버에서 근무 중이신 개발자 정상혁님이 네이버 D2에 기고하신 '백엔드 개발자를 꿈꾸는 학생개발자에게' 입니다. 

- 원문 : https://d2.naver.com/news/3435170

- 개발자 정상혁님의 github : https://github.com/benelog

 

리뷰 시작

 

해당 글은 말 그대로 백엔드 개발을 시작하는 학생 개발자들을 위한 글 그 자체입니다. 아무래도 2018년 글이다보니 아주 최신 트렌드는 아닐 수 있습니다만 그게 아니더라도 현 백엔드 환경을 이해하기엔 충분한 글이라고 생각하기에 원문을 읽고 모두 이해하실 정도면 충분히 좋은 신입 개발자가 아닐까싶네요. 이 이후부터는 요약이기에 음슴체를 주로 사용하니 양해해주세요. 또한 아래 요약들은 원문의 요지를 벗어나지 않는 선에서 제가 학습했던 지식 등 주관이 섞일 수 있기에 비판은 언제나 환영지만 비난은 자제해주시면 좋겠습니다 ㅠㅠ

 

백엔드 개발자의 진로

 

#업무범위

- 백엔드 개발의 업무는 분업 이후에도 '웹 프론트엔드', '모바일앱 개발자' 등 다른 직군보다 넓어 하는 일을 규정짓기 모호함
- 그렇기에 백엔드 개발자는 다양한 분야를 접하고 접한 분야의 전문성을 키울 수 있다는 장점이 있음

- 하지만 이 말은 백엔드 개발자라면 필수 항목인 '백엔드 어플리케이션 개발' 뿐만 아니라 서버관리, DB관리, 프론트엔드 개발부터 CS, 인프라/클라우드,데이터 가공 등 개발 전반에 대한 기초 지식 역시 갖춰야 함을 의미

 

#보람과 고충

- 백엔드 개발자는 트래픽 장애가 없는 서버, 획기적인 성능 개선, 모듈 구조 개선을 통한 클린 코드 등처럼 시스템을 안정적이고 효율적으로 만드는 것이 중요하고 성취감도 얻을 수 있음

- 하지만 클라이언트에게 잘 드러나지 않고 시스템 장애가 없을때는 다른 직군에 비해 임팩트가 부족해서 본인 성향에 맞는지 생각해봐야함

- 서버가 24시간 돌아가는 만큼 장애 대응을 위해 근무 시간 외에도 신경을 써야한다는 고충도 인지해야 함

 

#향후 전망

- 생산성 증가에 기여하는 기술의 발전 속도가 오히려 개발자들이 해야할 과제가 느는 속도를 따라가지 못하기 때문에 개발자의 수요나 가치가 하락할 가능성은 적음

- 하지만 개발 분야에 따라서 끊임없이 학습하지 않는 다면 기존에 주류를 이루던 기술이 쇠퇴함과 더불어 사라지는 직군이 존재하는 것은 당연

- 이런 환경을 생각하면 백엔드 개발자에게 가장 필요한 역량은 새로운 개발 지식을 학습하고 새로운 분야에 적응할 수 있는 능력이며 정말 큰 기업이 아니라면(아니면 그 조차도) 새로운 기술이 도입되면 새로운 업무가 필요해졌을때 새로 사람을 뽑을 때까지 대부분 시간은 기다려주지 않기에 실무에서도 마찬가지임. 그런 면에서 백엔드 개발자는 개발 전반에 대한 분야와 연결되기에 역량을 키울 기회를 접하기 유리함

-- (블로거 의견 추가) 최근 GitHub Copillot 등 ai 기술의 발전과 IT 분야의 시장 규모 성장 둔화에 따른 우려에 얼마 전 같이 어느 기업이던 개발자라면 모셔가던 시절보다는 그 수요가 줄지 않느냐?라는 의견이 있을 수 있지만 아직 ai 기술이 개발자들이 하던 일을 대체할 정도로 발전한 것도 아니고 시장도 과거 '판교-구로의 등대'처럼 개발자의 처우가 열악한 시절은 옛말인데다 아직도 많은 기업들에게 IT 시스템 도입을 위한 인력이 부족하며 기술의 발전으로 사람들은 끊임없이 편리함을 추구하기에 그런 우려는 과하지 않나 싶네요

 

- 머신러닝이나 빅데이터 관련 수요가 요근래 늘면서 관련 전문가들을 수혈하지만 앞서 업무 분야 적응같은 역량을 가진 기존 백엔드 개발자들이 그 분야의 전문가로 성장하는 경우도 많음

- 따라서 백엔드 개발자들이 기존에 하던 업무가 머신러닝이나 빅데이터와 밀접하므로 이에 더해 특정 도메인에 대한 이해까지 갖춘다면 그의 시장 가치는 더 높아질 것

 

#다른 분야로의 확장

- 최근 많은 서비스들의 기획 단계부터 개발자들의 의견이 많이 반영되는 추세이며 개발자가 직접 기획, UI/UX 설계를 맡는 경우도 있는 만큼 기획이나 설계, 관리 쪽으로의 확장 역시 충분히 가능

- 하지만 '경영'으로의 확장은 개발자로서가 아닌 그 사람의 officer로서의 역량이 더 중요하며 다른 분야도 그렇겠지만 더욱 개발 능력이 뛰어나다고 맡을 수 있는 문제가 아님

 

 

백엔드 개발에 필요한 지식

 

#개요

- 지금부터 작성하는 내용은 주로 웹 서버 개발에 필요한 요소들을 다루며 아래에 소개하는 지식들을 모두 깊이 잘 알 필요는 없지만 기초 지식은 반드시 알아둬야 함. 또한 실무에서는 최대한 구성원 일부가 잘 알고 있는 stack을 택하기에 한 분야를 깊게 알 필요도 있음

 

#데이터베이스

- 최근 트래픽과 데이터가 폭발적으로 느는 만큼 실무에서는 다양한 저장소를 복합적으로 사용(사용 예시는 원문 참고)

- 그렇지만 RDB는 그 흐름 속에서도 가장 우선시 되는 저장소이기에 이를 잘 아는 것이 벡엔드 개발자의 역량

- 쿼리 모니터링과 코드 수정을 통한 성능 개선은 꾸준히 이루어져야하며 이는 JPA같은 ORM을 사용하면 더더욱 중요

 

* ORM과 JPA를 잘 모르시면 https://victorydntmd.tistory.com/195참고

 

- 기존에 쿼리를 만드는 스타일이 네트워크 호출 비용을 최대한 줄이기 위해 길게 만드는 것이었다면 최근엔 분산 및 캐시의 중요도로 인해 복잡한 JOIN문을 지양하는 스타일로 작성

- 프로시저도 기존엔 급하게 개발되는 레거시에선 성능적으로 이득이 있고 최초 배포가 쉬워 자주 사용되었지만 최근에는 수정이 힘들고 버전 관리가 번거롭기에 가급적 사용하지 않음

- DB 서버 1대로 트래픽이 감당이 안되는 경우 샤딩을 통해 이를 분산하지만 어떤 솔루션을 쓰는 그에 따른 비용이 발생하므로 이에 대해 학습하고 구축하는 것이 필요

 

* 샤딩을 잘 모르시면 http://wiki.hash.kr/index.php/%EC%83%A4%EB%94%A9 참고

 

#개발툴

- 개발도구를 잘 활용하는 능력은 당연히 개발자의 능력 중 하나이지만 앞서 말했듯 특정 개발툴을 잘 다루는 것보다 새로 접한 개발툴에 적응할 수 있는 실력이 더 중요하므로 입문부터 특정 개발툴을 처음부터 깊게 공부하는 것보다 적절한 도구를 선택하고 적응할 수 있는 역량을 키우는 것을 추천

- 그렇기에 개발 입문 단계부터 공식 문서를 통해 스스로 학습하고 터득한 지식을 다른 개발자와 협업할 수 있을 정도로 커뮤니케이션할 수 있는 능력을 키우는 것이 중요(블로거 : 그 이상은 사실 재능의 문제가 아닐까 싶습니다...)

 

#병렬처리

- Java를 주력으로 사용하는 개발자라면 스레드, 병렬 처리에 대한 학습을 했을 것인데 서블릿 기반의 자바 웹 서버들은 기본적으로 병렬 처리를 기본으로 함.

- 멤버 변수를 늘 Thread-safe 하게 선언해둔다는 규칙만 지켜 코딩하면 많은 문제를 에방할 수 있지만 Local cache 적용시 객체 관리가 어려울 수 있기에 캐시 상태의 객체는 항상 immutable하게 둘 것

 

* 서블릿을 잘 모르시면 https://fadet-coding.tistory.com/35 참고

* Local cache를 잘 모르시면 https://goldfishhead.tistory.com/29 참고

 

#보안

- 보통 개발자들이 사용하는 라이브러리/프레임워크들은 보안적으로 계속 패치를 해주기에 직접 보안에 대한 깊은 학습을 잘 하지는 않지만 널리 알려진 XSS, CSRF, SQL Injection 등의 공격에 대한 학습은 해두는 것이 필요. 또 당연히 개발을 오래하다보면 '이건 이렇게 공격받으면 여기가 취약하겠는데?' 같은 생각이 들기에 개발자끼리 그런 의견을 나누기도 하고 이것을 파다보면 보안 쪽 전문가로 분야를 변경하는 것도 가능

 

* XSS, CSRF를 잘 모르시면 https://lucete1230-cyberpolice.tistory.com/23 참고

* SQL Injection을 잘 모르시면 https://namu.wiki/w/SQL%20injection 참고

 

#테스트

- 최근 실무에서 개발은 수 많은 이들이 협업을 통해 진행하기에 테스트 코드를 작성하는 능력도 백엔드 개발자의 중요 소양 중 하나. FE와 BE의 분업화로 백엔드 개발자는 더욱 API 개발에 초점이 가 있고 HTTP API는 테스트 코드 작성의 난이도도 낮은데 비용 대비 얻는 이득이 큼

-  API에서 나아가 라이브러리나 플랫폼 개발 역시 재배포, 장애 대응 등의 과정에서 비용 절감과 신뢰감을 줌. 그리고 영역 상관 없이 테스트 코드를 작성하지 않아 대는 핑계는 그 자신의 평가를 깎아 먹는 자충수

- 테스트는 개발자가 느끼기에 크게 세가지 분류인 새로 투입되는 사람에게도 도움이 되는 유지보수시 생산성 향상 테스트, 프로젝트 오픈까지 코드 수정과 디버깅에 도움을 주는 테스트, 오늘의 개발 일정에 맞춰 속도를 끌어올려주는 테스트가 있을 수 있으며 이런 테스트에 대해 중요하게 생각하지 않는 사람은 다시 한 번 본인에 대해 재고해보는 것을 추천

 

- 테스트에 관심을 갖게되면 다른 분야만큼이나 깊이 있게 팔 수 있고 다양한 기법으로 테스트 코드를 짜게 됨. 필자의 경우는 처음 Unity 클래스 테스트 작성 > Spring JUnit 및 DB 통합테스트 > Mockito 등 테스트 객체 생성 툴 사용 처럼 단계적으로 경험하였고 시간이 지난 지금은 더 빠르게 이런 흐름을 알 수 있으리라 생각

 

*API를 잘 모르신다면 https://fadet-coding.tistory.com/7 참고

* JUnit을 잘 모르신다면  https://minkwon4.tistory.com/155 참고

* (블로거 추천) TDD에 대해서도 알아보시기 바랍니다. https://mangkyu.tistory.com/182 참고

 

 

#자료구조/알고리즘

- 학교에서 배운 자료구조/알고리즘이나 CS 관련 지식들은 많이 사용되는 만큼 이미 많은 솔루션들에서 구현되어 있기에 직접 구현할 필요는 없지만 구현된 여러 솔루션들 중 현재 진행중인 내 프로젝트에 적용할 솔루션을 선택하고 활용하는데 앞선 지식들의 학습이 요구 됨

- 일례로 Java, JDK의 컬렉션 프레임워크(Map, List 등)의 소스를 볼 때 HashMap의 동작원리, ConcurrentHashMap을 통한 동시성 이슈 해결 등 실무에서 이런 선행지식들이 필요하고 B Tree의 활용법처럼 대용량의 데이터를 다룰때도 역시 필요(관련 포스트들은 원문 링크 참조)

 

* 컬렉션 프레임워크를 잘 모르신다면 https://opentutorials.org/course/1223/6446 참고

* B 트리를 잘 모르신다면 https://ko.wikipedia.org/wiki/B_%ED%8A%B8%EB%A6%AC 참고

 

* 

 

#개발 프레임워크

- JVM 생태계에서는 고부하 처리를 위한 Netty와 널리 알려진 Spring 계열이 주로 사용됨.

- 모든 서버 어플리케이션이 비동기로 개발되어야할 필요는 없지만 최근 MSA나 로드밸런서 등 트래픽 처리를 위해 더 효율적인 개발 방식을 택하는 것이 중요(원문 Spring의 비동기 관련 언급은 @Async 등 패치로 당시와 다른 부분이 많아 보류)

 

*Java에서 비동기 처리를 잘 모르신다면 https://velog.io/@pllap/Java%EC%97%90%EC%84%9C%EC%9D%98-%EB%B9%84%EB%8F%99%EA%B8%B0-%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D

*로드밸런서를 잘 모르신다면 https://0zii.tistory.com/m/38과 원문 링크 참고

* (블로거 추가) MSA를 잘 모르신다면 https://www.samsungsds.com/kr/insights/msa_and_netflix.html 참고

 

#Serverless

 - 주로 Baas와 Faas(Xaas[X as a service] 중 가장 추상화된 단계)에 의존하는 아키텍쳐를 Serverless라고 하며 일반적으로 개발자가 서버 관리에 신경쓰지 않는 구조를 이르며 이 때문에 백엔드 개발자에게 전통적으로 요구되었던 JVM, 커널 파라미터, 웹 서버 튜닝 등 인프라 관련 지식이 필수가 아니라고 생각할 수 있지만 이 역시 추상화된 서비스의 선택 및 활용 면에서 학습해두면 좋음

-- (블로거 추가) Serverless라는 단어가 주는 어감이 강해서 최근 자주 사용되지만 추상화된 Xaas를 사용함에 있어서 원문처럼 백엔드 개발자라도 인프라/클라우드 관련 지식이 요구되기에 학습이 반드시 필요하다고 생각합니다

 

* Xaas에 대해 잘 모르신다면 http://www.epnc.co.kr/news/articleView.html?idxno=96102 참고

* serverlss에 대한 추가 설명이 필요하시다면 https://velopert.com/3543 참고

 

 

실무에서 하는 고민

 

#용어의 범위

- 실무에서 협업을 함에 있어 개발 전반에 통용되는 용어더라도 프로젝트 구성원 사이에서 정의가 정확히 통일되지 않는다면 갈등이 생길 수 있으므로 구성원간 합의가 필요. 또한 범용적으로 쓰이는 용어와 사내에서 사용하는 용어 역시 구분하지 않으면 이후 오해의 소지 발생 가능

- 예1) 일반적으로 HTTP통신 위에서 XML/JSON 형식으로 통신하는 API를 REST API라고 통칭 > 정확히는 HTTP 혹은 Web API를 사용하는 것이 맞음

- 예2) TDD와 테스트코드를 병용하여 사용 > 서로 엄연히 다른 개념

- 예3) JUnit으로 작성되면 모두 유닛테스트라 부르는 경우 > JUnit 이름때문에 생긴 오해로 통합테스트 역시 존재

- 예4) VO와 DTO 용례 > 요약하면 주소가 달라도 값에 의해 동등성이 판단되는 경우만 VO며 데이터 전달 객체가 DTO

(자세한 reference는 원문 링크 참고)

 

* VO와 DTO, Entity에 대해 잘 모르신다면 https://tecoble.techcourse.co.kr/post/2021-05-16-dto-vs-vo-vs-entity/ 참고

 

 

#FE와 BE의 역할분담

- 과거에는 JSP 등을 통해 SSR을 주로 사용하며 필요한 경우 보조적으로 Ajax 비동기 처리를 사용했지만 최근 리액트나 뷰 등 FE 프레임워크의 발달로 CSR도 많이 사용되기에 렌더링 방식을 결정하는 것도 중요. 또한 이 결정은 FE와 BE간의 작업 분담에 큰 영향을 주며 백엔드 개발자들도 UI 개발자로 참여하곤 함

 

* CSR, SSR, ajax를 잘 모르신다면 https://velog.io/@commitnpush/CSR-vs-SSR 참고

 

# 클라이언트를 위한 API 설계

- REST 스타일의 HTTP API설계시 단순 CRUD의 경우는 기존의 방식으로 매핑한다 하더라도 페이징 처리 등 자주 사용되지만 서비스마다 정의가 다른 더 복잡한 기능들을 어떻게 설계해야할지 많은 고민이 필요.

-- (블로거 추가) 원문에선 GraphQL이 언급되었는데 물론 요구사항 변경마다 개발자가 일일이 대응해야하는 문제를 획기적으로 줄여주긴하지만 DB 부하 등 단점도 명확하기 때문에 설계에 있어 원문처럼 REST 스타일에서 뻗어나갈지 GraphQL을 도입할지 선택하는 것도 개발자의 역량인 듯 합니다

 

* REST와 GraphQL을 잘 모르신다면 https://velog.io/@djaxornwkd12/REST-API-vs-GraphQL-%EC%B0%A8%EC%9D%B4%EC%A0%90-%EC%95%8C%EC%95%84%EB%B3%B4%EA%B8%B0참고 

 

#시스템 분산

- 시스템 분산의 목적은 '구성요소 간 역할과 책임을 어떻게 나눌 것이냐'이며 그 경계에 맞추어 업무 범위를 나누고 협업 방식을 정함. 네이버의 경우 오래된만큼 MSA라는 용어가 도입되기 전부터 서비스했으나 모듈화를 적극적으로 사용하고 그 모듈들의 협응을 많이 고민한만큼 그 경향을 오래전부터 실용적으로 추구했다고 생각됨

- 과거 MSA와 같은 구조로 서비스를 만드는 것이 전통적인 MA 구조보다 비용이 더 큰 경우가 많았으나 최근 기술의 발전으로 서비스를 쪼개고 서비스간 협응 설정하는 것이 쉬워졌으며 클라우드가 대중화되어 협업과 유지보수에 강점을 갖는 MSA를 대부분의 기업들이 도입하는 추세지만 여전히 서비스간 경계를 정하고 어떻게 설계할지의 작업은 개발자들의 과제

 

 

네이버의 백엔드 개발

 

#개발/배포 방식

- 요약하기엔 너무 길기에 원문 참고바람

 

#인프라 기술 활용

- 네이버를 예로 들면 내부에서 VM을 관리하는 방식은 IaaS에 가깝고 최근 여기에 Docker, Kubernetes를 추가로 사용. 사내에서 주로 쓰이는 플랫폼은 자체적 PaaS 형태로 제공

- 코드 배포는 내부 배포 솔루션을 사용하며 배포 전 코드 리뷰, 소스 통합, 테스트 등 필요한 작업들은 사전 회의를 통해 결정. 모니터링의 경우 툴마다 특화 영역이 다르므로 복합적으로 다수의 툴을 사용

- SE, DBA에게 맡기는 중요한 작업들도 분명 많지만 JVM, Tomcat, NginX 등 솔루션 설치/설정이나 개발DB 설치/스키마 변경 등 개발팀에서 직접하는 업무도 존재하는 만큼 관련 지식을 알아두면 좋음

 

 

마치며

 

* 원문에서 직접 읽어보시기 바랍니다.

 

 

---

처음보면 헷갈렸을만한 용어는 주석으로 링크를 달아놨습니다.