개발자 측면 2021 회고

일단 회고부터 처음 써본다... 

먼저 2021년은 대학교 4학년으로서 개발 동아리(스터디)와 개발자 1년 차를 보냈다.

솔직히 학교가 상위권 학교는 아니여서 배울게 엄~~ 청 많다고는 생각을 못했다.

그래서 우연히 인턴을 할 수 있게 돼서 4월달에 인턴을 하게 됐다.

스터디를 하며...

일단 2021년도 초에 코딩 잘하는 친구가 같이 스터디하자고 해서 그 친구랑 동아리(?) 비슷하게

스터디를 했다. 일단 나는 4학년이지만 군대갔다가 이제 막 코딩을 시작하는(html, css, javascript, c, c++ 등 기본적인 것만 한) 코린이었기에 그 친구가 프로젝트나 스터디를 같이 하자는 거에 당연히 동의를 했다. 솔직히 지금 이 글을 쓸 때쯤 생각해보니 진짜 너무 고마운 친구였다. (이 친구는 모두가 아는 대기업 감)

 

일단 그렇게 스터디를 시작했다. 이전에 말했듯이 나는 react 조금 건들고 node js로 express를 조금 건들줄 아는 그런 학생이었다. 그래서 백엔드를 node js로 하기로 했다. 지금의 spring boot처럼 express로 DI(dependency injection)를 이용해서 백엔드를 구축할 수가 있다. 이런 것에는 nest js가 있었지만 그래도 express에 typescript로 해보기로 했다. 그렇게 typeorm을 썼는데 음... 분명 잘 썼다고 생각했는데 중간에 막힌 부분이 있었다. 개념적으로 분명 맞게 한 것 같은데 안됐다.(음... 그때 버그일 수도 있고 우리가 잘 몰랐을 수도 있다.) 그래서 그 잘하는 친구가 spring boot를 이전부터 해왔기 때문에 java를 하기로 했다.

 

솔직히 나는 군대가기전에 java를 1학년 때 하고 그 이후로 한 적이 없다. 그래도 spring boot를 많이 사용하기도 하니까 해보기로 했다. 일단 나는 진짜 코린이 시절 express로 할 당시 강의를 보면서 했는데 컨트롤러 - 서비스 - 도메인 부분을 나누지 않고 그냥 컨트롤러에 거의 다 적는 그런 방식의 강의를 많이 봤다... (패스트 캠퍼스에서 하는 거는 클래스로 했는데 지금은 이해가 가지만 그때는 이해가 가지 않았다.)

근데 스프링을 해봤더니 아는게 하나도 없었다. 그리고 지금까지 해왔던 거랑 완전히 달랐다고 느꼈다. 일단 이 당시 기본적인 자바를 알아야 하기 때문에 자바 공부를 했다.(음 나름 시간을 쏟아부었지만 열심히 했다는 건 내가 결정하는 게 아니어서 열심히 한지는 모르겠다.) 그러면서 친구가 설정을 다하고 샘플 코드로 짜준 코드를 봤다.

‘와 진짜 하나도 모르겠다.’ 그러면서 스프링에 기본 개념 - ioc 컨테이너, di, 그리고 김영한님의 jpa 등 이것저것 많이 보면서 공부했다. 처음에는 컨트롤러 - 서비스 - 도메인 이렇게 나뉘어서 코드를 짜는 게 뭔가 어렵다고 생각했지만 내가 지금까지 한 방식이 잘못됐다고 느꼈다.

 

그렇게 스터디에서 프로젝트를 하기로 했다. 학교 졸업 프로젝트도 있었기 때문에 좋은 기회라고 생각했다. 이때 내가 jpa를 공부하고 스프링 기본 개념을 공부하고 자바를 공부하고 난 후에 코드를 짰다. 그래도 어려웠던것 같다. 그렇게 코드를 짜면 이 친구가 코드 피드백도 해주고 기본적인 컨벤션이나 깃 전략도 알려주고 그랬다. 그리고 이 친구가 ghcr이나 github action, aws까지 잘 써서 이 친구를 보면서 많이 ‘이런 것도 있구나’ 하면서 구글링도 엄청하고 찾아봤다. 그리고 내가 모르는 게 너무 많아서 질문도 많이 했다. 솔직히 너무 귀찮게 한 것 같아서 미안하기도 했다. 

이때 왜 사람들이 프로젝트를 해야지 실력이 는다고 하는지 느낀 것 같다.

사실 4학년 되기 전에 강남에 비트(고급) 학원을 들었다. 학교에서 연계하기도 했고 평도 괜찮아서 들었다. 근데 mfc, wpf를 배웠다. 음 솔직히 나는 웹 쪽을 공부하고 싶었는데 이런 거를 배워서 뭔가 좀 아쉬웠다. 그리고 여기서도 프로젝트를 했는데... 음 잘하는 사람이 없어서 그런가 (이끌어주는 사람이 없고... 나랑 동기형이 그나마 잘하는 거였다.... 우리 학교는 진짜...) 그래도 이런 스터디를 하면서 많이 배운 것 같아서 좋았다.

 

인턴을 하며...

그러다가 인턴을 하게 됐다.

사실 나는 같이 스터디 한 친구보다 현업에 있는 사람들이 훨씬 잘할거라고 생각을 했다. 그래서 거기 가서 많이 배워야지 하는 생각에 인턴을 하게 됐다. 근데 웬걸.... 내가 생각했던 것들 하고는 좀 달랐다..

일단 신입이기도 하고 실력도 많이 떨어지긴 할 것이다. 하지만 이때의 느낀점을 적어보고 싶어서 적어보려고 한다.

내가 느낀 장단점

장점

• 리눅스 환경을 혼자 사용하는 것보다 많이 사용하고 배우게 됨
• 소켓쪽 이나 redis를 많이 사용해보지 않았는데 이해도가 높아짐
• db에 대한 깊이가 기존보다 깊어짐
• 백엔드, 프론트엔드, 인프라팀 다 나뉘어 있음
• 몰랐던 현업 지식 및 노하우를 알게된다.

단점

• 컨벤션이 없음
• 쉽게 적응하기 힘든 코드 스타일(컨트롤러에 모든 코드가 있음, 모든 response를 hashMap으로 함 
  • 클린 코드, 리팩터링 X
• 테스트 코드 없음 (mybatis는 테스트 코드를 짜는지를 모르겠음)
• git 전략 없음 - 이건 뭐 상관없음
• 기획 없음
• cicd 없음
• 코드 리뷰 없음

어떠한 글을 읽었는데 그 글에 너무 공감을 했다.

• 스타트업은 레거시한 코드를 고치는 일을 하러 간다.
• 개발자는 시대의 흐름(트렌드?)을 알아야 하지만 그렇지 못한 개발자들이 많다.

인턴으로 들어오기 전에 잘하는 친구랑 피드백하면서 어떤 코드가 더 좋은 코드일까 고민하는 게 슬프지만 더 도움됐던 것 같다.

 

 

일단 mybatis를 사용을 했다. 들어보니까 꽤 오래된 회사들은 아직 mybatis를 많이 사용한다고 한다. 그건 오케이다. 근데 코드를 봤다. 음 이게 바로 나의 이상과 현실의 갭 차이 인가 싶었다.

그래도 들어왔으니까 mybatis에 대해 어느 정도 숙지했다. 그리고 어떤 요청이 들어왔을 때 대리님들이 하는 거를 따라 할 필요는 없다고 생각해서 나만의 좋은 코드를 짜기로 결심했다. 일단 controller, service, domain(mybatis니까 sql)를 분리해서 각 역할에 맞게 짜려고 노력했고 dto로 어떤 데이터를 전달할 건지 바로 알 수 있게 하고 나만의 컨벤션을 정해놓고 코드를 짰다.

그러다가 새로운 프로젝트를 하고 난 뒤에 다시 처음 프로젝트로 왔다.

 

중간에 새로운 프로젝트를 하고 다시 처음 프로젝트로 와서

새로 온 대리님이랑 하게 됐다. 그러면서 코드들을 싹~~~ 다 바꿨다.

일단 먼저 jpa를 할 수 있는 사람이 신입인 나밖에 없었다. 그래도 신입인 나를 믿고 mybatis에서 jpa로 바꿨다.

그리고 새로 시작하는 김에 단점들을 혼자서라도 조금씩 보완해보고자 노력했다.

그리고 컨트롤러에 있던 코드들을 역할에 맞게 다~ 분리하고 쿼리는 querydsl로 했다. 기본 로직만 맞게 하고 리팩터링을 싹~~~~~ 다 했다.(사실 맞게 한지는 모르겠다. 내가 한 코드보다 훨씬 좋은 코드가 많을거라고 생각이 든다.)

기존에 중복된 회원 인증을 jwt로 했는데 모든 api에 @RequestHeader를 받아서 로직 처리하는 걸 써줬다. 그리고 그걸 모든 api에 복붙 하는 형태였다. 나는 이게  진짜 너무 싫었다.

그래서 중복된 코드들을 줄이려고 많은 고민도 해보고 구글링도 많이 해서 중복된 코드들을 진짜 많이 줄였다. 
진짜 뿌듯했다. 이런 맛에 리팩터링 하나보다.

그리고 새로 온 대리님도 이를 만족해했고 뭐 좋은 방법 알게 되면 서로 알려주고 피드백해주고 했다.

그리고 혼자서 로직이 잘 작동하는지 컨트롤러가 잘 작동하는지 테스트 코드도 짰다. 물론 회사에서 나 혼자만 테스트 코드를 작성한다...

뒤로 갈수록 기획이 없어서 너무 바뀌는 게 많아서 이전처럼 다하지는 않았지만 확정이 되면 다시 다 짜 봐야겠다.

그리고 나만의 컨벤션을 정해서 하고 cicid도 gitlab ci를 사용해서 했다. 

하지만 서버에 무리 간다고  이거 사용하지 말라고 하셔서 나중에 빌드용 서버 세팅이 되면 하라고 하셨다. 

그리고 단기간에 백오피스 쪽 api를 따로 만들어야 해서 멀티 모듈을 사용하려고 했지만 멀티모듈을 사용하지 말라. '멀티 모듈 할 바에 차라리 msa를 사용해라 msa가 그렇게 어려운 게 아니야'라고 하시는데 솔직히 이거 듣고 내가 생각하는 msa를 사용해라라고 하는 게 맞는지 의문이었다. msa를 조금 맛만 봤는데 공부할게 진짜 많았는데 저런 말씀을 하시니까.. 당황했다. 근데 경력 많으시니까 알고 말했겠죠?

이 외에 진짜 옛날 방식이 많았다. 그래도 같이 일하는 대리님이 은근 많이 밀어주시고 변화하는데 많은 도움을 줬다. 

솔직히 혼자서 문제를 다 해결할 수는 없다고 생각한다. 그래도 내 위치에서 할 수 있는 최선을 다했다고 생각한다.

 

그리고 점차 개발을 할수록 시간이 나면 개인 공부를 꾸준히 했다. 이때 졸업 프로젝트도 했고 요즘 기본적인 게 제일 중요하다고 생각해서 개인적으로 책도 읽고 소켓 쪽도 공부하고 기본 cs 관련된 것도 공부하고 있다. 계속 공부하면서 느낀 건데 참 공부할게 많다. 아직 msa를 시작하지도 않았고 devops 관련된 공부도 해야 하고 알고리즘도 공부하면서 코딩테스트준비도 해야하고 참 할게 많다는 것을 느꼈다. 그래도 나름 새로운 것을 알아가고 고민하는 게 재밌어서 다행이다.

 

하지만 고민인 게

요즘 프런트 개발자가 부족해서 진도를 많이 못 나간다고 느낀다.

최근에 오픈했는데 이럴 때 노 저어야 하는데 아쉽다. 이러다가 서비스가 잊히지는 않을까
그리고 나의 성장에 도움이 많이 될까? 하는 많은 고민이 된다.

 

 

그나저나 회고를 처음 쓰는데 너무 못쓴 것 같다. 다음에는 뭔가 체계적으로 써봐야겠다. 

끝!