아직 학생 개발자인 신분이지만 백엔드 개발에 관심이 많아 이것저것을 혼자 공부하고 있었다.
그러던 중 ‘아는 만큼 보이는 백엔드 개발’이라는 책을 발견하게 되었는데 현재 내가 어디까지 알고 있는지 궁금하기도 했고
목차를 보니 다양한 분야의 이론들을 보며 내가 어떤 부분이 부족한지 알 수 있을 것 같았다.
그리고 구입하고보니 내가 종종 유튜브를 참고했던 ‘컴공선배’ 유튜브의 개발자님들이 쓰신거라
워낙 현실적으로 말해주던 채널이라 관심을 갖고 있었기에 기대가 되었던 것 같다.
사실 이 뒷부분을 보고도 이 책을 선택하기로 마음을 먹긴 하였었는데,
지금까지는 친구들끼리의 소형 프로젝트나, 소규모의 프로젝트만 진행하였기 때문에
그때그때 필요한 기술들을 정말 문제점을 쳐내기 위해서만 공부했었다.
깃, 도커, 테스트 코드, 클라우드, DB, API까지 직접 몸으로 부딪히면서 배웠지만 머리속에 제대로 정립되지 않은 기분이라
이 책을 통해서 이것이 해결되기를 기대하였다.
물론 지금은 프론트엔드도 같이 공부를 하고 있지만, 백엔드를 처음시작했을 때 찾아본게 바로 로드맵이었다.
위의 로드맵을 쭉 읽어보며 현재 내가 어디까지 와있는지 파악도 가능했고
책도 위 로드맵에 따라서 쓰여져 있어 필요할때마다 꺼내 읽기도 유용해 보였다.
실제로 나는 컴공생이기 때문에 기본적인 네트워크, OS, 자료구조나 프레임워크, API, 깃 정도는 알고있어서
그 부분은 후루룩 빨리 읽고 나머지를 더 정독했었다.
이렇게 NOTE로 헷갈릴만한 개념들도 한번 짚고 넘어가주니 모호하게 머리에 있던 개념들이 다시 생각나서 좋았다.
간단한 예시와 함께 설명되어 있는 부분도 많았고
실제 실습 예제를 가지고 설명하는 부분도 있어서 백엔드 기초 책으로 보기에 딱인것 같았다.
사실 많이 사용하는 설명이긴 하지만 웹 서버와 웹 애플리케이션 서버를 분리해서 설명해주어 좋았다.
매 챕터가 지날때마다 이렇게 추천 프로젝트를 추천해주는데
처음에는 로드맵의 첫부분이다보니 print hello 같은 간단한 예제들이지만 뒤로 갈수록 어려워진다.
뒤의 챕터에서는 앞선 개념들까지 사용하여 만드는 프로젝트를 추천해주는데, 생각보다 쉽지 않았다.
사실 CI/CD를 제대로 다루어 본적도 없기 때문에 조금더 공부를 통해서 프로젝트도 완성해야겠다.
아는 만큼 보이는 백엔드 개발 책을 통해서 새로 알게된 내용과 내 부족함을 채우기 위한 내용들을 많이 발견하였다.
백엔드 기초 책이다보니 막 이해하기 어려운 내용들은 없었지만 머릿속 개념들을 바로잡기엔 되게 좋았다.
여러 프로젝트나, 개인 프로젝트에서 서버와 DB까지 모두 맡아서 하다보니 데이터베이스 설계할일이 많은데
항상 설계할때마다 정규화를 제대로 못한 부분을 뒤늦게 발견하여 수정하고 수정하고
데이터를 지우고 다시 넣고 하는 일들이 많이 발생했었다.
그 중 한 예로 속성 추출과 관계 추출의 예시인데,
평소 주먹구구 식으로 회원이니까 번호, 이메일 등이 필요하지! 주문은 이런이런게 필요하지!까지만 생각하고,
이후에 만들 주문과 상품, 회원의 연관성은 잘 생각하지 않고 테이블을 만들었었다.
그러다 보니 나중가서 테이블들이 엉켜 다시 만드는 경우가 빈번했던 것 같다.
DB 정규화는 워낙 중요하기 때문에 많이 공부했었고 하려고 노력하고 있긴 하지만
아는 만큼 보이는 백엔드 개발 책을 보고 좀 더 공부해야 겠다는 생각이 들었고
트랜잭션을 최근 많이 빼먹고 개발하고 있던게 생각나서 session 관리하는 방법을 다시 익혀야 겠다고 생각했다.
db 분기를 만들어주지 않고, commit하는 타이밍도 이상하게 잡아서 rollback이 잘 안될때면 그냥 rollback을 삭제해버려서 … ㅋㅋㅋ
이제 다시 DB 잘 관리하는 코드 작성 해야겠다.
사실 대부분 swagger로 처리하긴 하지만, 저번학기 LG 커넥티드 플랫폼 수업 때 WebOs 어플을 개발하면서 개발문서의 중요성을 조금 느꼈다.
실제로 기업에서 API를 하나 만들려면 명세서부터 테스트 케이스, 예외 케이스 등등 몇개의 문서를 작성해야 하더라…
그런 역량을 좀 키워야 겠다고 생각해서 아는 만큼 보이는 백엔드 개발 책에서 꼼꼼히 읽었다.
협업에서 중요한 건 문서를 남기는 것이지만 개발은 재밌고 문서 작성은 귀찮기 때문에…
이러한 방법도 익혀둔다면 협업에서 더 좋을 것 같다.
사실 나는 테스트 코드를 전혀 작성하지 않는다. 전혀
이게 문제라는 것을 인식을 하고는 있지만 내 프로젝트들이 대규모 프로젝트도 아니고 빠르게 치고 빠지는 형식이다보니
그냥 개발하고 디버깅하는 식으로 진행했었다.
사람이 많아진다면 테스트 코드가 매우 중요하다고 많은 개발자들이 말해서 그 중요성을 깨닫긴 했다.
개발자가 일일이 코드를 실행해보지 않고도 코드가 잘 동작하리라는 것을 보장받을 수 있도록, 발생 가능한 테스트 케이스를 코드로 작성해 실행함으로써 예상치 못한 부작용을 잡아낼 수 있다
위의 문장이 굉장히 좋더라
일일이 실행해 보지 않아도 코드가 잘 동작하리라는 보장을 받을 수 있다니..
각각의 기능을 테스트 하는것이 단위 테스트인데, 하나의 함수를 만들때마다 테스트를 실행하다보니
각각의 기능을 최대한 개별적으로 동작하는 코드로 작성하게 만들어야 한다.
그 과정에서 코드 상호간의 결합도와 의존성까지 낮추는 효과가 있어서 품질이 향상되는 이점도 있다고 한다.
단위 테스트 이후 백엔드와 DB 사이의 테스트와 같은 통합적인 테스트를 진행하는데
status나 response, data가 잘 도착했는지를 테스트 하게 된다.
어플리케이션이 잘 돌아가는지 뿐만 아니라, 성능, 안정성, 보안까지 테스트 하게 된다.
테스트 코드는 지금까지 해본 적이 없어 좀 깊이 있게 보고 정리해 보았는데
단점은 거의 없고 (귀찮은거?) 그것도 프로젝트가 커지면 더 귀찮은 것을 막을 수 있는 장점이더라
이건 꼭 해봐야겠다
CI / CD도 말만들어봤지 개념을 공부해볼 생각조차 없었는데 이번 기회에 조금 찍먹해보게 되었다.
CI(Continuous Integration)은 소스 코드의 변경 사항을 자동으로 빌드하고 테스트해 master 브랜치의 코드 품질을 높이고 충돌을 방지해 준다.
깃허브로 프로젝트를 하면서 잘 일어나지는 않지만 한번 발생하면 머리가 터질 것 같은게 바로 병합할때 충돌문제이다.
코드를 두시간 짜고 병합해결만 두시간한적도 있다…
그런 의미에서 CI를 이용하는 것은 매우매우매우 좋은 것이라는 생각이 들었다.
많은 기업들이 젠킨스를 쓰는 이유일까? 젠킨스 로고 멋져..
CD(Continuous Delivery / Continuous Deployment)는 웹 어플리케이션을 지속적으로 개발하고 테스트해 언제든지 배포 가능한 상태로 유지하는 것이다.
배포할때 생각하는게 올리면서 문제가 발생하거나 서버가 중단되는 문제는 어떡하지? 하는데
그것을 CD로 해결할 수 있었다
젠킨스 + AWS 코드디플로이 조합으로 많이 사용을 한다하니 시간이 날때 공부해 봐야겠다.
딥한내용이 들어있지 않아 백엔드 기초 책으로는 딱이고 실습이나 좋은 사이트도 소개해줘서 좋은 책이었다.
하지만 조금 더 궁금한데? 하면 다음 내용이 없는 경우가 많아 조금은 아쉬웠다. 그런 부분은 더 자세한 책으로 공부해 봐야겠다.
로드맵은 두고두고 참고하며 앞으로 개발길에 참고할 예정이다!
이 글은 길벗 23차 개발자 리뷰어로 선정되어 쓴 글입니다
비전공자도 배울 수 있는 타입스크립트 자바스크립트는 이상하게 정이안가는 언어중에 하나이다. 분명 web을 처음 시작했을 때…
IT 엔지니어를 위한 AWS 운영의 기본과 노하우 선택한 이유 AWS는 정말 공부해야지 공부해야지... 하면서도 쉽게…
개발하는 남자의 핸즈온 플러터 최근 계속해서 플러터를 개발할 일들이 많은데, 워낙 가지고 있는 강의들은 많은데…
갑자기 독스헌트 사업계획서? 아직 거창한 사업계획서를 쓸일은 없지만, 최근 진행하는 프로젝트의 지원금을 받을 수 있을까…