시리즈1 - 컨텐츠의 동기 및 개요
아무것도 모르던 시절 배포방식?
- 테스트 코드가 없는건 당연하며 신규 기능 개발이나 버그 등 사람 손이 많이 들어갔다.
- Maven으로 WAS를 .jar 형태로 빌드
- WinSCP라는 FTP 클라이언트 서버에 원격접속
- jar 파일 덮어쓰기
- Putty라는 SSH 클라이언트로 서버에 원격접속
- screen으로 돌아가고 있는 WAS 세션에 들어가서 서버를 껏다 키기
- 자동화 생각이 들지 않았음.
물리서버가 하나..?
- 리눅스에서 물리적인 터미널을 가상 터미널 여러개로 다중화해주는 screen 도구를 사용해 screen 하나는 서버를 돌리고 하나는 DB를 돌리는 식으로 운영을 했었음.
- 비용도 문제였지만? 서버가 한 대인게 가장 큰 문제점..!
- 그 이유는 서버가 하나라면? 이거 고장나면 어떡함..!
테스트코드가 없다?
- 테스트를 코드가 아닌 PostMan으로 진행했다.
- 취업을 준비하고 테스트코드에 익숙하지 않은 나의 입장에선 너무나도 와닿는 부분이였다. 오히려 이런게 습관으로 잡혔기 때문에 고치기가 조금은? 힘들었던 것 같다.
리뷰없는 배포?
- 각자 작업을 분할하고 배포를 리뷰없이 알아서 진행했다.
- 나 또한 조별과제를 하면서 배포는 아니지만 이런식으로 진행했을 것 같다. 하지만 다양한 곳에서 코드리뷰를 받은 경험이 생기다보니 코드리뷰의 위대함을 많이 느껴 리뷰는 필수라고 생각이 들었다.
로그가 없다?
- 로그가 많이 필수라는 것을 요즘들어 많이 느끼고 있는 것 같다. 하지만 불과 작년만 해도 로그가 아닌 콘솔에 print 찍어보기 바빴다. 많이 반성하게 되는 것 같다.
왜..!?
- 백엔드를 경험해본 사람이라면 사용자 인증을 어떻게 할지, 암호화는?, API 문서는 어떻게 작성해야할 지 같은 걸 쉽게 결정할 수 있지만, 그렇지 않은 사람은 이런 가이드가 필요하다
- 애플리케이션 레벨의 경우 언어와 프레임워크 선택지가 너무 다양해서 예제를 찾기 힘들다.
- production level의 코드를 뜯어볼만한 기회가 별로 없다. 웹이라면 개발자 도구를 켜고 앱은 종종 github에 올라오는 코드를 얼 추 알아볼 수 있지만 백엔드는 그렇지 않다. 동감한다.
- 백엔드는 코드만 봐서 되는 포지션이 아니다. 배포와 배포패턴, 모니터링, 로깅, 스토리지, 트래픽 변동의 대응처럼 코드 외적으로 신경써야 할 부분이 많다.
- 어느 기술이던 경험해보지 않으면 필요성을 못느낀다. 그러나 백엔드는 그런 경험조차 해보기가 어렵다 —> 매우동감.. 예를들어 변동이 적은 데이터는 캐싱해 두면 좋지만 굳이 캐싱해두지 않아도 데이터베이스 쿼리하는 시간이 워낙 짧기때문에 필요성을 느끼지 못한다.