글 쓰는 시간

리눅스 공부의 필요성

프로그래머가 구현에만 집중할 수 있도록, 나머지 환경들을 계속 추상화 시켜서 추상화의 아래 쪽으로 숨겨버리다 보니
정작 프로그래머가 컴퓨터 자체를 모르는 일이 자주 발생한다.
- 『모던 리눅스 교과서』(책만, 마이클 하우센블라스 지음, 송지연 옮김, 2023)

친구에게 추천받은 책의 서문에 적힌 문장이다.

최근 토이 프로젝트 배포를 위해 인프라 설정도 해보고, 도커나 MySQL도 공부하려니까 CLI를 만질 일이 많아졌다.

그래도 요즘은 챗 GPT 덕분에 웬만해선 리눅스의 필요성을 잘 모르고 살았다.

GUI에 절여져서 간단한 ls 같은 커맨드만 알고 있고, 막힐때는 챗 GPT의 힘을 빌려서 해결했었다.

하지만 최근 친구와 새로 토이 프로젝트를 구상하며 이야기를 나눠보면서 생각이 달라졌다.

환경변수 같은 간단한 설정도 Node.js 나 SpringBoot 같은 프레임워크의 도움을 받아야만 할 수 있을거라고 생각했지만,

간단한 리눅스 커맨드로도 해결하는걸 보고 리눅스라는 기본기를 깔고가면 사고의 폭이 넓어질 수 있을거란 생각이 들었다.

개발자라면 어쩔 수 없이 리눅스를 공부하긴 해야하는것 같다.

회사에 들어가면 인프라를 직접 만질 일이 얼마나 있을까 싶긴 하지만,

그래도 너무 추상화된 고수준 동작만 알고 있는건 바람직하지는 않다는 생각이 든다.

토이 프로젝트를 고도화 하면서 이것저것 써보려면 어떻게든 필요하기도 하고.

엄청 깊게 공부하지는 않더라도 적당히 책 1~2권 정도는 읽고 필요한 만큼은 쓸 수 있게 되는게 목표이다.

DB 공부의 필요성

최근..은 아니고 꾸준히 느끼는게 나는 DB에 대해서 너무 모른다.

SQL도 부족하고, 데이터베이스 지식 자체가 부족해서 프로젝트 고도화를 할 때 걸림돌이 되고 있다.

면접때도 인덱스 관련해서 물어보면 써본적이 없어서 잘 대답하지 못하고 있고...

아무래도 DB를 JPA로 접하다보니 이런 문제가 생긴것 같다.

로컬에서 MySQL을 띄우는것부터 시작해서 이것저것 시도해보면서 공부해봐야지.

어느정도 공부를 해보고 EC2 + 도커 + MySQL로 RDS를 대체하는 작업도 겸하면서 DB에 대해서 알아가야겠다.

테스트 환경 격리

최근 테스트 환경을 격리하는 문제에 대해 고민하고 있었다.

다음 테스트에 영향을 미치지 않으려면 테스트마다 생긴 사이드 이팩트를 제거해야한다.

본인은 아래처럼 매 테스트에서 DB에 데이터를 넣고 종료 시 DB 내용을 지워줬었다.

하지만 최근 @Transactional 테스트를 알게 된 후 몇몇 주의점이 있지만 @Transactional 테스트가 편하긴 하니

주의해야할 점만 생각해보고 그냥 @Transactional 테스트를 써야할지에 대한 고민과,

이렇게 매 테스트마다 DB에 데이터를 넣어주는게 맞을까 라는 생각이 들었다.

특히 연관관계 때문에 연관 된 엔티티가 늘어날 수록 given 절에 해당하는 테스트 사전 작업이 너무 번거로워졌다.

그러던 중 IDIOT-s의 한 개발자 분께 여쭤보니 Repository를 Mocking 해서 사용한다는 이야기를 들었다.

처음 테스트 코드를 작성할 때는 Repository나 Service 레이어는 Mocking 하지 않는게 좋다고 생각했지만,

점점 그 방법 또한 나쁘지 않을 수 있다는 생각이 들었다.

좋은 테스트의 조건인 빠른 테스트에 부합되기도 하고 연관된 엔티티가 늘어나면 이런저런 번거로운 작업이 줄어들지 않을까?

이런건 아무래도 팀바팀일 확률이 높아 보이는데 현업에서는 어떻게 다룰지 궁금하다.

이에 관해서는 좀 더 공부해보고 이것저것 시도해보고 좋은 방법을 찾아봐야겠다.

최종 팀 프로젝트

어찌저찌 한달 조금 넘는 기간의 최종 팀 프로젝트가 마무리 되었다.

역시 사람은 급해야 빠르게 배우는지 팀 프로젝트의 제한 시간이 있다보니 꽤나 몰입해서 공부할 수 있었다.

프론트엔드를 공부하면서 무뎌졌던 백엔드 감도 다시 익히고 기능 개발을 하면서 제법 많은걸 배웠다. 

아무래도 그동안 공부하고 경험한게 있다보니 첫번째 팀 프로젝트를 하던 때보다 훨씬 능숙하게 할 수 있었던것 같다.

배운 점

팀 프로젝트 기간동안 배운 점, 느낀 점이 많았다.

그걸 지금 기억날 때 잊기 전에 간단하게 정리해볼까 한다.

1. 기존에 해보긴 했지만 이해하기 보다는 그저 따라만 했던 것들을 복습

기본적인 CRUD나 소셜 로그인, EC2 배포하기, 스프링 시큐리티, 테스트 코드 작성 등을 강의나 책으로만 접했었다.

그래서 매번 해봐야지 해봐야지 생각만 하고 막상 하지는 않아서 점점 머리 속에서도 잊혀가고 있었다.

하지만 이번 프로젝트에서 적극적으로 테스트코드도 작성하고, 스프링 시큐리티도 이해하고 적용해보았다.

또한 EC2 배포도 전엔 커맨드만 따라치면서 했었다면 이번엔 리눅스에 대한 이해도가 높아져서 쉽게 할 수 있었다.

2. 새로운 기술에 도전하기 두려워서 미뤄뒀던 것들에 대한 도전

괜히 이름만 듣고 쫄아서 못썼던 레디스를 사용해보았고, AWS나 각종 서드파티 API를 이용하기 위한 SDK 사용법을 익힐 수 있었다.

기존의 AWS ELB와 Route53을 이용한  HTTPS 적용법과 다르게 Nginx를 활용하여 certbot으로 HTTPS를 적용할 수 있었다.

이메일 발송 및 인증도 해보고, 웹소켓을 이용하여 채팅 기능도 구현해보았다.

3. 팀원의 코드를 보며 잊고 있던걸 상기하고 새로운 것을 배움

테스트 코드 작성 시 DB를 롤백 해야하는데 @Transactional 테스트로 쉽게 롤백할 수 있음을 다시 기억할 수 있었다.

또한 스웨거를 써본 적이 없어서 팀원의 코드를 참고하며 스웨거 사용법과 여러 기능을 배울 수 있었다.

느낀 점

완벽한 계획은 없다

이번 팀에서는 팀원들이 너무 완벽하게 계획을 세워두고 진행을 하고 싶어 했던것 같다.

그러다보니 너무 완벽하게 계획을 세우고자 시간을 들이고, 결국 그렇게 세운 계획도 각종 이유로 수정되는걸 다시 보았다.

역시 최대한 러프하게 정하고 진행하면서 수정하는게 가장 바람직한 방법인것 같다.

그리고 그런 수정 요청에 대응하기 용이하도록 유지 보수에 좋은 코드를 작성하는법의 중요성을 다시 느꼈다.

팀원의 코드에서 본 안티패턴

솔직히 웬만하면 가독성 신경써서 작업하지 않나? 생각 했는데 그런걸 생각 못하는 사람도 꽤 있단걸 알 수 있었다.

우선 코드 리뷰 할때부터 읽기 굉장히 불편하고, 100보 양보해서 내 코드는 나만 다룬다면 문제가 되지 않을지도 모르겠지만

팀 프로젝트에서는 팀원과 코드를 공유한다고 생각해야하기 때문에 가독성은 굉장히 중요한 요소임을 알 수 있었다.

팀원의 코드에서 발생한 버그를 디버깅 하면서 가독성이 너무 안좋아서 고생했다.

아래는 간단한 예시다.

왼쪽이 팀원이 작성한 코드고, 오른쪽이 내가 버그 수정을 하면서 가독성이 너무 나빠서 고친 코드다.

들여쓰기를 전혀 활용하지 않고, 파라미터가 여러개일 때 객체를 전달하지 않고 하나하나 늘여쓰는걸 보고 너무 고통스러웠다.

원활한 소통의 중요성

제한된 시간 동안 우선 완성부터가 제일 목표인데 연락이 잘 닿지 않으면 다른 사람의 작업 속도에 영향을 미칠 수 있단걸 느꼈다.

PR을 올리면 빠르게 처리 되어야 그 PR과 연동된 다음 작업을 하기 편한데 하루 넘게 PR을 확인하지 않는걸 보면 속이 탔다.

연락이 잘 안닿다 보니 버그가 발생해도 대부분의 버그는 내가 처리하곤 했다.

공부하는 입장에서 보면 뭐 도움이야 꽤 되긴 했겠지만 코드 가독성이 너무 나빠서 정말 애먹었다.

팀 프로젝트를 진행하면서 역시 소통이 제일 중요한듯... 뭐가 됐든 일단은 연락부터 돼야 함을 느꼈다.

사이드 이팩트 만들지 않기

클린코드나 실용주의 프로그래머 같은 인사이트 출판사에서 나온 개발서적류를 보면 보이 스카웃 규칙을 자주 언급한다.

들어갈때 보다 더 깨끗하게 하고 나오라는 의미인데 사이드 이팩트를 만들지 않는 코드 작성하기도 여기에 포함된다고 생각한다.

팀원이 테스트 코드를 작성하긴 하는데 신경 쓰이는 점이 너무 많았다.

딱히 그럴만한 사유 없이 매 테스트마다 컨텍스트를 초기화 해서 테스트 속도가 너무 오래 걸리게 작성했다.

또한 테스트 순서에 따라 성공, 실패 여부가 달라지는 테스트를 자꾸 작성해서 고치도록 설득하느라 힘들었다.

뭐 덕분에 나도 더 좋은 테스트 코드를 작성하는법을 익힐 수 있어서 얻은것도 있다만...

아무튼 이러니 저러니 해도 잘 마무리 되었다.

한 달 조금 넘는 시간동안 꽤나 바쁘게 작업했던것 같다.

이제 그간 바쁘다고 미뤄뒀던 블로그 글도 다시 쓰고 이력서 다듬어서 다시 제출해야지.

번아웃

최근 잦은 면접 실패 때문에 자존감이 떨어진데다가 이런저런 일이 겹쳐서 번아웃이 왔었다.

원래라면 IDIOT-s를 보면서 의욕을 충전하면서 마음을 잡았겠지만

최근 IDIOT-s 분들도 바쁘셔서 활동량이 줄었기에 더더욱 마음을 잡기 힘들었던것 같다.

한동안 안하던 모바일 게임 스토리도 정독하고 이래저래 시간을 막 썼던것 같다.

그래도 다시 의욕을 찾은것도 이거 덕분이기는 해서 완급만 잘 조절한다면 나쁘지만은 않을 수도...

Re:Dash

시간을 막 썼다곤 해도 그나마 팀 프로젝트 시즌이라 최소한의 공부는 강제돼서 다행이었다.

2차 팀 프로젝트 초기에는 좀 방황했지만 그래도 막상 마감일이 닥치니까 어찌저찌 정신없이 바쁘게 공부해서 처리했던것 같다.

이미 지나간 일 별 수 있겠나 훌훌 털고 다시 열심히 달려야지.

요즘 백엔드 공부에 소홀했기도 하고 만들고 싶은게 생겨서 다시 프로젝트를 시작하려고 한다.

이제 프론트엔드 지식도 어느정도 쌓았으니 뭐든 닥치는대로 하나 만들어보고 고도화 해보자.

발표

이번 팀에서는 결국 사다리 타기에 실패해서 2차 팀 프로젝트 발표를 맡아버렸다.

발표 준비를 하면서 프로젝트 시연을 위해 이것저것 만져보면서 버그도 발견하고 고칠 수 있었다.

그래서 오늘 새벽 내내 팀 프로젝트 리팩토링 하면서 발표 준비까지 하느라 밤을 새버렸다.

멀쩡한 정신이 아니라 걱정 됐지만 그래도 어찌저찌 잘 마무리는 한 것 같아서 다행이다.

전이었으면 발표 정도야 싶었겠지만, 최근 잦은 면접 실패 때문에 자존감이 떨어져서 발표도 부담이 되더라.

그래도 어찌저찌 끝났고 다시 힘내서 가보자.

예비군

애석하게도 팀 프로젝트 도중에 예비군이 일정이 껴있었다.

양평으로 이사오고 여기서는 처음 해보는 작계였는데 해봤자 동네 한바퀴겠지 했는데 2시간동안 등산을 할줄이야.

그나마 저녁이라도 맛있게 줬으면 했지만 도시락도 아니고 전투식량을 주더라.

간만에 먹는거라 그런지 생각보다 나쁘진 않았고 배고파서 다 먹기는 했지만 아쉬웠다.

안그래도 최근 무릎이 안좋아서 조심스러운데 덕분에 무릎 통증과 온몸에 근육통이 왔다.

원래는 집에 와서 프로젝트를 할 예정이었지만 바로 뻗어서 아무것도 못했다...

폴더 구조 정하기

팀 프로젝트를 함에 있어서 컨벤션을 정하는건 아주 중요한 일이라고 생각한다.

도중에 바꾸기도 쉽지 않기 때문에 처음에 컨벤션을 잘 정해두는게 중요한것 같다.

그런데 막상 컨벤션을 정할 때 의견을 내서 팀원들을 설득해서 정하기가 쉽지 않은것 같다.

오늘 폴더 구조를 정할 때도 의견이 분분했는데 정확히 어떤 방식으로 하자고 설득하기가 어려웠다.

FSD를 써보자고 설득해보고 싶었지만 이걸 접한지 얼마 되지 않아서 안써봤기에 어떤게 좋은지 어필하기가 어려웠다.

아무래도 경험치가 좀 더 쌓여야하지 싶다.

백엔드에서도 프로젝트 폴더 구조를 정하는건 쉽지 않은 일이지만 프론트엔드에서도 너무 다양한 폴더 구조가 있는것 같다.

꾸준히 뭔가 이것저것 시도해보고 비교하면서 정리해봐겠다.