Kernel360 :: E2E를 마치며... 과정 중간 회고

10월 10일에 시작한 과정이 어느덧 정신을 차려보니 절반 가까이 다가와버렸다. 이틀 뒤면 새해이므로 올해가 가기전, 그동안의 나는 무엇을 했고 어떻게 변했는가? 결국 성장을 하고있는가? 생각하는 회고를 가져보고자 한다.

 

front End to back End (E2E) 프로젝트를 진행했다.

https://github.com/Kernel360/E2E1-TaskTracker

GitHub - Kernel360/E2E1-TaskTracker: 공유 일정,목표 관리 서비스

한달간 프론트엔드부터 백엔드까지 풀코스로 플랫폼을 만드는 프로젝트를 진행했다.

아니, 난 백엔드를 배우러 왔는데 프론트엔드를 하라니? 이게 왠 뚱딴지 같은 소리인가 싶지만 백엔드 개발자여도 프론트엔드에 대해 기초는 알아야 실제 협업시 프론트엔드 개발자가 무언가에 대해 물어 볼 때 어떠한 의도로 물어본 것인지의 대한 감을 좀 더 빨리 잡는데 도움이 된다. 그리고 아무리 restful 한 백엔드 서버 개발만 진행한다해도 통탄을 금치 못할 말이지만 회사의 여건에 따라선 결국 일부 프론트를 할 수도 있다. 개잡부다 이말이야 백엔드 개발자든 프론트 개발자든 웹 애플리케이션의 1cycle이 어떻게 흘러가는지는 알아야, 상호 이해가 빠르고 문제가 생겼을시 어디를 고민해야하는지 도움이 되기에 존재하는 커리큘럼이다. 본인은 2세대긴 해도 html과 js, jquery 기반의 프론트는 어느정도 할 줄 알기 때문에 큰 난관은 없었지만 다른 팀원 두분은 많이 힘들어했다... ^^;; 이때 좀 아쉬웠던 것이 팀원분들이 프론트의 개념이 하나도 없었다는걸 일찍 알았으면 최소 하루 이틀정돈 시간을 비우고 속성으로 프론트에 대해 속성 강의를 진행했으면 보다 효율이 좋았을텐데 그러지 못했다는 점이다.

나를 포함한 팀원분들 모두가 일단 설계를 최대한 깔끔하게 빼놓고 개발에 집중하는걸 선호하는 스타일인데, 과정 오더가 e2e 진행하면서 설계보다는 일단 빠르게 개발을 진행하라는 부분이 좀 아쉬웠고 결국 뒷심부족으로 개발 목표의 70%정도만 달성되었기 때문에 깔끔한 마무리가 아닌 영 찝찝한 마무리가 되었지만, 그래도 다양한 인프라와 기술 도입을 시도함으로써 다음 파이널 프로젝트에 좀 더 자신감이 붙기는 했다. 이 과정에서 본인은 백엔드 20% 프론트 40% 데브옵스 40%정도를 한 것 같다.

프로젝트 진행하면서 쓰인 기술스택

백엔드 비중을 적게 했지만 관리자 페이지를 개발하면서 통계 전문 백엔드 프레임워크인 redash를 설치,사용해보았고 자바 14버전부터 추가된 <record> 타입을 써보기도 했다. DTO <-> Entity 데이터를 주고 받을 때 주로 쓰이는 빌더와 맵퍼에 이어 record에 from, of를 작성하여 오버로딩을 이용해 api에 따라 필요한 데이터만 주고받는 방법을 새롭게 익혔다.

빌더는 일일이 타이핑하는게 일이었던걸 맵퍼가 자동으로 해주는 역할이지만 일부 데이터만 주고 받으려면 결국 빌더처럼 별도 항목에 대해 따로 기입을 했어야 하는 불편함이 있었는데 레코드는 미리 작성만 해두면 간단하게 of를 통해 땡겨올 수 있어 매우 편했다. 단, 자바를 잘 이해해야만 레코드를 잘 쓸 수 있을거 같단 생각이 들었다... 🫠 다른 것도 마찬가지지만

깃허브 액션에서 배포 스크립트를 작성하여 S3로 빌드파일을 버켓에 담아 인스턴스에서 코드디플로이 에이전트를 작동시켜 서버 부팅까지의 원스탭 배포를 구축하기도 했다. 페어 프로그래밍도 진행했고 가끔 팀원분들이 작성한 코드에 문제가 생겼을 때 같이 살펴보면서 놓친 부분에 대해 알려주기도 했다. 마지막으로 인텔리제이의 뛰어난 플러그인들에 감탄했다

체계적으로 공부하는 방법을 습득했다.

공부하는 방법을 배웠다 한들 결국 난 우선 시도 -> 막힘 -> 검색 -> 해결 -> 왜? 의 과정이 더 몸에 베여버린 사람이기 때문에 이렇게 하는게 더 편하고 속도도 잘나오기는 한데, 책의 ㅊ과도 거리가 멀던 내가 이동하는 시간을 비롯해 틈이 나면 책을 읽기 시작했다. 그리고, 따로 스터디도 진행 하기도 했다. 항간엔 근본책이라고 공룡책 돛단배책 등등 뭐가 잔뜩 많은데 우리의 시간은 우테코보다 반토막이기 때문에 이 책을 다 볼 순 없다. 그렇기 때문에 후보군을 몇권 정해놓고 아주 당당하게 맨토님에게 어떤 책을 먼저 보는 것이 좋은지, 이 책을 보면 목차에서 어떤 것부터 보는게 좋은지 디테일하게 물어봤다. 이렇게 물어보고 진행한게 나밖에 없는거같아서 내심 뿌듯했다 하지만 아래중에 보라는건 없었다.

흔히 온라인에서 많이들 언급되는 '근본' 리스트

0123

스터디를 같이 진행하는 맴버분들이 다행이 토비의 스프링을 비롯한 근본책들을 좋아해서 바이블이라 불리는 책들을 기반으로 주기적으로 모여서 스터디를 하고있다. 예전의 나였다면 혼자 보는걸 좋아하는편인지라 내가 공부하면서 모르는 것들은 거의 검색에 의존했어야했는데, 바로 물어볼 맴버들이 있다는 점에서 좋았고 내가 이해한 것을 이야기 했을때 다른 사람들은 어떻게 생각하거나 이해했는지 들어 볼 수 있어서 좋았다. 단, 마치 대학 생활 때처럼 이것도 하고 저것도 하고 하면서 프로젝트를 진행하다보니 이것이 서로 기어처럼 맞물릴 때도 있지만 개념이 혼동되면서 헷갈릴 때도 적잖히 없지 않아 있다. 개발자는 역시 공부할게 참 태산같은 분야다

* 도서 정찰제 이후로 전공 도서 비용이 항상 비싸 별로 손이 안갔는데 커널360에선 스터디 장려 지원금도 소액 제공해주기도 하고, 종종 디렉터분들께서도 도서를 증여해주시기도, 스터디를 오픈하시기도 합니다. ^^

무언가를 시작, 도입할 땐 항상 "왜"를 생각하게 되었다.

일다닐때는 내가 설계를 고민 할 필요도, 정의 된 프로그램 명세서에 따라 기능을 구현하기만 하면 되므로 개발 할 때 생각이란게 로직에 대해 어떻게 개발할까 -> 잘되면 왜 잘될까, 안되면 왜 안될까 이런 정도 뿐이라 별로 없었는데 이 과정을 하면서는 앞의 생각과 더불어 앞으로의 확장성에 대해서도 고민하게 되고 어떠한 신규 기술을 선택해서 개발할때 이 자료형을 썼을때 오는 장단점, 후폭풍들은 없을까? (예시로 for 대신 stream, builder나 mapper대신 record+of+from) 에 대한 고민도 하게 되었다. 패키지를 짤때도 모놀리식으로 할지 멀티모듈로 할지, 인프라를 구성할때도 DB를 도커에 띄워놓을지, RDS를 쓸지, OS에 인스톨해서 쓸지라던가 이미 정답인 aws 를 알고있고 사회에서도 많이 쓰고있지만, 왜 많이들 쓰는지의 답을 찾고자 vultr같은 드문 서비스도 써보았다.

vultr을 쓴 경우 사실 꼭 개발이 아니어도 '바퀴를 다시 발명하지 마라'에 속해서 선호하진 않는다. 단지 이 과정이 회사와 다르게 실패를 해도 되는 과정이고 다양한걸 시도 할 수 있는 환경이니까.. 지금이니까 해보는것일 뿐. 시간이 넉넉한 과정이 아닌만큼 난 실패를 하더라도 안겪어도 될 문제를 굳이 겪기보다 해야 할 일을 하면서 문제를 겪고 극복하는 과정을 경험하는걸 선호한다. 이미 내 기준으론 해커톤, E2E 프로젝트를 실패했기 때문에 마지막 파이널 만큼은 어디든 내놓을 수 있는 뚜렷한 결과물을 하나쯤은 만들고싶다.....^^

가령 생각난김에 쓰자면 아래의 주제는 코딩하기 위해 키보드 잡는 매일 고민한다.

데이터 중심 개발에서 객체 중심의 개발로....?

SI에서 일했을때 비하면 확실히 데이터 중심보단 객체 중심으로 개발도 하고 생각을 하게 되기 시작은 했다...만 아직은 좀 몇가지 생각하게 되는 사항들이 있다.

    - JPA, QueryDSL을 쓰게 되면서 DB 요청을 쿼리 또는 xml에서 메서드콜 기반으로 바꿈에 따라 컴파일 레벨에서 에러를 사전에 방지 할 수 있다. 그렇지만, 메서드콜을 하기 위해 기존 쿼리작성보다 쿼리 라인이 몇배는 길어지는걸 목격하게 되니 이게 개발 속도를 요구하는 곳에선 쓰기 좋을까? 쿼리에디터로 정상동작을 보증하는 쿼리를 짜고 mybatis를 통해 쿼리를 날리는게 당장의 개발엔 더 빠르고 효율적으로 보이며 운영 플랫폼이 DB를 자주 변동한다는건 그만큼 플랫폼 운영(경영)에 문제가 많은거 아닌가? 하는 생각.

    - 아무리 객체 중심으로 개발한들 결국 데이터를 저장하는 곳은 DB이므로 DB의 지식을 요구하게 되는데 JPA는 join 개념이 없으므로 join인척 하는 단방향 참조를 두번 걸어야 하는 일이 흔하다. 또한 테이블이 많아질수록 join을 생각하고 데이터를 가져다 쓰려다가 JPA이기 때문에 데이터 하나를 찾기위해 메서드콜을 꼬리물기로 몇번씩 하는 경우도 있다. 객체중심의 개발을 잘 살리려면 데이터 저장하는 구성체도 큰 변화가 와야되지 않나? 데이터 저장소가 데이터베이스인 이상 아무리 객체 중심 개발로 한다한들 결국 객체 중심인척 하는 데이터 중심 개발이 되지 않나?  데이터 보존이 의도대로 되지 않으면 잘나가는 플랫폼도 무쓸모가 되버리니 결국은 데이터베이스가 갑이 아닌가? 하는 생각.

    - JPA는 영속성 컨텍스트라는 존재 덕분에 일종의 어플리케이션 레벨의 가상 DB처럼 운용되게 되는데 "가상"이라 함은 결국 JVM 위로 올라가 메모리(ram)를 잡아먹는다는걸 뜻한다. 요즘 아무리 컴퓨팅 파워가 좋아졌다 한들 서비스가 커질수록 감당이 가능할까? 꼭 이것 때문만은 아니겠지만 이런 문제도 영향이 있기에 멀티 모듈을 기반으로 하는 MSA, EDA 아키텍처가 등장하고 수평적 확장으로 나아가는 추세가 된게 아닐까? 하는 생각도 든다.

객체 중심 개발의 장점을 느끼려면 어떤 개발을 해야할지, 어떤 경험을 해보는 것이 좋을지 생각이 많아진다. 이런 고민들을 이전처럼 일 잘하는 회사원으로서만 살았다면 생각해보지 못했을 것이다. 일 잘하는 회사원도 중요한건 맞지만 결국 개발이라는 기술직으로 먹고 살려면 더 성장하는 개발자가 되어야 하니까.. 이 또한 SI를 퇴사한 이유중 하나기도 하다. 개발만 하고싶지 사업따려고 발표쟁이를 메인으로 하고싶진 않아서.

글 쓰면서 좋은 부분만 줄줄이 쓰긴 했다만 때론 커널360의 첫기수여서 서로가 좀 서툰 부분도 있고 개선 해야할 방향들도 있기에 투덜대기도 했다. 그래도 다행인점은 운영진분들이 최대한 수용해주려고 노력하고 있음을 알 수 있다는 것이다. 안타까운 점은 나 외의 다른 맴버들도 초창기에 비하면 얼굴부터 피곤에 찌들어🤪 폭삭 늙어가는게 보인다... 🫠 개발자 되기 참 힘들다

마지막으로 글을 틈틈히 쓰기 시작했다.

평소엔 "굳이 귀찮게 글을 왜 써두냐, 내가 이해했다면 언제 한번 까먹었을때 검색해서 금방 다시 기억해낼 수 있는데." 이 스탠스를 지니고 있다. 일상생활중엔 이게 적용이 가능한데, '개발' 분야는 이렇게 적용하기가 힘든 분야다. 나이탓은아니다 결국 기억해놓고 꺼내보려면 글을 많이 써둬야하는데 이 과정을 하면서 이거 하나만큼은 상대적으로 기가막히게 잘 하고 있다. 개발 잘해야 할 사람이 글 더 잘써지는게 씁쓸하긴 한데 (?) 한번 하기 시작하니, 개발하면서 혼동되거나 기억나지 않는 상황이 올때 검색해서 찾는것보다 내가 정리해 둔 글을 찾아 보는게 처음 글 쓸때만 시간 좀 걸리고 그 후엔 훨씬 시간절약이 되고 자연스럽게 더 기억하려고 하다보니 공부에도 도움이 되었다. 무엇보다 이력서에 내밀면 마냥 놀진 않고 뭔가를 깨달아갔어요 하고 보여주기 좋다. 포트폴리오나 이력서를 기가막히게 잘 쓰고 잘 준비한 사람이 아니라면 결국 내가 뭘 했는지 보여주는 히스토리가 필요한 법이다. 개발자라면 깃허브 블로그로 써야 진짜다 하는 꼰대도 있긴하다만 난 티스토리가 편해서 이쪽으로 쭉 작성하고 필요에 따라 다른쪽으로 옮길듯. 나름 테마도 바꿨는데 잘 써먹어야지...

기술세미나 발표도 했지만 이건 유튜브에 영상이 올라온다면 그때 별도로 글을 쓰고자 한다.

종종 크루들간에 가끔 서로에 대해 이야기 할때 '성장하고 있는가?'로 이야기를 주고 받는다면 분명 성장은 하고있다. 알아주는 머기업에서 현업으로 굵직한 포지션을 담당하고 계시는 맨토님들께 질문을 드릴때도 이제는 수준높은 고민을 하신다는 이야기를 듣자니 내심 감개무량하기도 하다. 근데, 맞는 방향으로 가고 있나?는 아직 잘 모르겠다. 스터디 하니까 이 부분에 대해서도 고찰이 있는데 이 주제의 글은 과정이 거의 끝나갈 무렵, 다음 기수들을 위한 글로 어떻게 준비하면 좋을지 팁을 주는 글에 가미를 해서 쓰지 않을까? 싶다.

앞으로 남은 기간동안엔 얼마나 더 알아가게 되고 성장해있을지... 사실 지금의 관심사는 성장보단 파이널 프로젝트 완성이긴해서 이번 플랫폼은 무사히 론칭했으면 좋겠다. 그러면 자연스레 성장해있지 않을까? 싶으며 다시 공부하러 이만 총총..