프로젝트 회고, 긴 이야기

회고 쓰다가 다 날아가서 다시 쓰는 사람.. 티스토리 자동저장을 너무 믿지말자. 자동 저장 완료라고 했잖아... 야... 진짜..
 

프로젝트 회고

 

기술스택 

레전드의 시작
 
2023년에 시작해 2024에 끝난 프로젝트의 기술스택 라인업을 확인해보아요.
 
JAVA Spring Boot (이건 오케이), 타임리프, 마이바티스, 제이쿼리 .. 점점 어지러워지는 라인업. 정신을 똑바로 차려야한다.
몰아치는 새로운 (구)기술에 숨을 못쉬던 사람. 바로 과거의 저입니다. 하지만 이제는 아주 유연하게 대처가 가능하지요. 잘 씁니다.
지금 생각해보면 기술 스택이 중요한게 아니다, 그냥 수단일 뿐 ... 이 큰 프로젝트의 처음부터 오픈까지 한 사이클을 경험해본게 중요하다는 것. 이런 레전드 경험을 어디서 해보겠냐는거다. (과장님이 해주신 값진 이야기...) 플젝 다 끝나고 회식때 해주시긴 했지만..^^ 그래서 더 공감갔다. 경험 다하고 과거를 되돌아보면서 곰곰이 생각해보니 정말 맞는 이야기다.
 
아무튼 처음에는 진짜 어찌해야 할바를 몰라서 쌩신입으로 돌아가서 걸음마 부터 떼고 있었던게 기억이 난다. JAVA 처음 써보는 프론트 개발자.. 못미더워하던 과장님의 눈빛..히히.. 그래도 프로젝트 끝날때는 혜준님이 있어서 다행이였고 시키는거 그대로 다 해줘서 좀 더 편하게 할 수 있었다고 해주셔서 정말... 눈물이 날뻔했다.. (절대 안울고 풀 집중해서 삼겹살 먹은 사람)
 
 
하나씩 보자.
왜 하필 JSP 인지..? 처음에는 나도 리액트를 할 줄 알았다. 모두가 그런줄 알았다. 그런데 갑작스런 고객사의 요청 "JSP"로 해줘.
해달라면 해드려야죠 ~~ 맛있게 말아드리겠습니다!
 
아무튼 JSP 를 해야한다 -> 그럼 타임리프를 쓰자 이렇게 해서 타임리프를 쓰게 되었다.
 
어드민의 경우는 CRUD 가 많았기 때문에 타임리프를 쓸 일이 많이 없었다. 거의 다 AJAX 요청으로 처리를 했다.
 
사용자 페이지로 오면서 타임리프를 쓸 일이 많아졌다. 보통은 그냥 GET 요청으로 데이터를 받아와서 화면단에 뿌려는 부분이 많았기 때문에..! (실제로 GET 요청이 들어가지는 않는다. 쉽게 예를 들자면 그렇다는 이야기)
 

Thymeleaf(타임리프)란 ? 타임리프의 기본 기능알아보기

 

스프링과 통합되어 있어, 스프링의 다양한 기능을 편리하게 사용할 수 있게 지원해줍니다.
또한 Spring 진영에서 공식적으로 타임리프 사용을 권장하고 있습니다.

 

model.put("userList", userList);

 
이런식으로 서버단에서 데이터를 보내주면 html 안에서 타임리프 문법으로 해당 데이터에 접근이 가능하다.
 
그리고 타임리프에서 제공하는 다양한 문법이 있기 때문에 html 안에서도 손쉽게 데이터 처리가 가능하다. 정말 웬만한건 다 된다. 많이 쓰게 되는 반복문, if 등등..
 
불편했던건? 당연히 있습니다.
 

1. 작은 단위의 화면 리렌더링

 
페이지안에서 변화가 있는 경우 데이터를 호출해서 다시 화면을 그려줘야 하는데 이 모든걸 js 안에서 html 을 직접 그려준다음 append 하는 형식으로 해야한다는 점이 굉장히 불편했다. (타임리프의 문제가 아니라 html + js 만으로 화면을 그려주면 맞닥뜨릴 수 밖에 없는 한계)
리액트를 사용했다면 컴포넌트를 언마운트 했다가 다시 마운트해서 아주 손쉽게 그려주고 하나의 js 안에서 작은 단위의 컴포넌트를 관리하지 않아도 되어서 편리했을텐데 그런 부분이 아쉽고 불편했다.
그렇다고 해서 타임리프가 리액트랑 추구하는 바가 다른가..? 그건 또 아니다. 타임리프 안에서도 컴포넌트 형식으로 단위를 작게 작게 쪼갤 수 있다. 이번 프로젝트에서는 리스트 안에 아이템을 컴포넌트화 해서 아주 유용하게 잘 써먹었다. 3개의 사이트에서 사용할 수 있었고 코드 수정도 편리했다. 원래는 페이지 내에서 각자 쓰다가 도저히 관리가 안되는 것 같아서 시간 내서 하나로 만들었다. 정말 훨씬 편했고.. 근데 이건 정말 디자인 + 퍼블리싱 영향을 많이 받을 수 밖에 없다. 3개의 사이트에서 아이템의 세부적인 컬러만 다르고 다른 큼지막한 요소들은 동일해서 가능했던 것. 정말... 감사하다. 그게 아니였으면 화면개발자는 죽음뿐..!
 

2. 서버에서 보내주는 데이터 확인하기

 
최초 로드 시에 서버에서 데이터를 model에 담아서 보내주고 이걸 사용하는게 타임리프. 그러다보니 네트워크 창에서 데이터를 확인할 수 없고, th:text 혹은 th:inline:"javascript" 안에서 데이터를 찍어서 확인해야한다는 점이 불편했다.
나는 작업할때 주로 네트워크 창을 켜놓고 그 안에서 요청 값, 응답 값을 확인하며 작업하는데 타임리프의 경우는 초기 데이터를 서버단에서 바로 보내주기 때문에 눈으로 확인할 수 없다는 점이 익숙치 않았다. 초기 데이터 이외에 AJAX로 요청하는 부분은 axios 요청과 유사하기 때문에 큰 문제 없었음.
 
 

JAVA 한명이요!

 
1. 타입과 선언형
이번 프로젝트를 들어가면서 JAVA Spring Boot를 처음 써보게 되었다. JavaScript를 기반으로 하는 (Node.js + React)로 신나게 개발하던 사람.. 불편한 구두를 신은것 처럼 뚝딱거렸는데 아직도 잘 쓰고 있는건지 모르겠다. gpt 선생님과 함께하는 자바교실..! 과장님의 코드를 보면서 한걸음씩 걸음마를 떼는 사원..!
 
예를 들어서 길이가 3인 빈 배열을 만들면 그 뒤로 배열의 길이를 내 맘대로 조절 할 수 없다는 것. 선언한 그대로 가야한다는 것.
함수 혹은 클래스의 리턴타입을 정해주고 (이게 안맞으면 계속 오류 나고 - 당연함 ㅋ) 왜 이게 이렇게 불편했을까 생각해보니 JSON 타입에 너무나도 익숙한 사람이라 그랬던 것 같다. js야 고마워~~ ts 도 어느정도 할만했는데 java는 조금 다른 영역 같았다.
 
2. 외부 API 호출하기 (JSON 쓰고 싶어)
물론 쓸 수 있다. 라이브러리 활용하면 쓸 수 있는거 아는데, 팀에서 안쓰고 있는데 나 혼자만 암묵적인 약속을 깨고 쓸 수 는 없는법! 악으로 깡으로 버텼다. 특히 나는 외부 API를 사용하는 경우가 많았는데 이럴때마다 눈을 질끈 감고 싶었다. 외부 API에서는 json 객체 형태로 응답을 내려주는데 나는 이걸 한번 가공해서 써야하니까. 프론트에서 바로 외부 API를 호출하면 안되니까!!!! 엉엉..
 
네이버 SMS API 에 대한 이야기... 와 이거는 AS IS 코드가 레전드였다. 이거를 갖다 쓰자니 심각하고 새로 짜자니 엄두가 안나고.. js는 도저히 건들 수 없는 무너지기 직전의 젠가라서 어떻게 건들 수 없었다. 그냥 그대로 쓰는 수 밖에 없었고 답은 기도 뿐이였다. 미안하지만... 시간 비용 상 갈아 엎을 수 없었다. 화면단은 차치하고 Controller로 와봤더니 여기도 만만치 않은 상황 ㅋ 그나마 여기는 기존 코드가 완성이 안되어있는터라 내 식대로 고쳐서 쓸 수 있었다. 외부 API 호출하는 부분 최대한 함수화 하고.. 아 그래도 만족스럽지 못하지만 일단은 그렇게 마무리 지었다. 작업하면서 네이버 SMS API 스웨거랑 공식 문서 보면서 작업하는데.. 커스텀 헤더도 쓰고.. 꽤나 잘되어있더라. 그리고 정말 편했던것은 즉시발송 / 예약발송(+예약시간) 이것만 정해주면 요청단에서 신경쓸게 없었다. 너~~무 편했고 .. 근데 발송 결과가 15일인가 30일까지만 보관되고 그 뒤로는 조회가 안되기 때문에 필요하면 우리쪽 DB에 넣어놔야겠더라. 그건 그럴 수 밖에 없겠지 어떻게 전체 다 보관을 하겠어..
 
 
3. 비지니스 로직
저번에 컨퍼런스 갔다가 들은 이야기인데 SQL이 모든 비지니스 로직을 담당한다면 큰일난거라고 했다. 큰일난 부분도 있고 아닌 부분도 있고.. 외려 내가 기본적인 CRUD 정도만 쓸줄 아니까 최대한 모든 비지니스 로직을 컨트롤러나 서비스단에서 해결하려고 했다. 그러다 보니 코드가 길어지고 이게.. 맞나 싶은게 생기기도 했지만 어쨌든 되니까. 개발자의 중요한 덕목 "어찌됐든 시간안에 만들기" 시간안에 못끝내면 테스트코드? 클린코드? 코드리뷰고 나발이고 비지니스가 안되는데 어쩔거야 돈이 먼저다 돈이...
 
 
 

JS 뜯어먹기

화면단은 js 로 모든걸 처리했다. 그나마 다행이였던것.. js가 익숙하니..
 
screen.v.XXX -> 전역변수
screen.f.XXX -> 전역함수
screen.c.XXX -> AJAX 호출함수
 
이렇게 생명주기를 내내 들고 간다는것. 함께가자 ^^
as is 코드를 보면서 이게 뭐지..? 내가 알던 js가 맞나? 싶었는데 써보니까 별거 없더라
타이밍 좋게 js에서의 [선언 + 실행컨텍스트 + 호이스팅 + this + 비동기처리] 수업을 들어서 다행이였다. 좀 더 이해를 하면서 쓸 수 있었다.
 
 

그 이외에 배운것들

 
1. DB 인덱싱

[Database] DB 인덱싱(Indexing)이란?

파일을 관리하는 테이블이 있는데 이게 수 많은 게시판의 파일 전체를 관리하다보니까 검색하는데 진짜 한 세월이 걸렸다. 그래서 목록 / 상세 페이지를 조회할때도 정말 대단한 속도를 보여주었는데 (3초 ㅋ) 파일의 그룹아이디를 인덱싱을 해서 좀 속도를 줄여줬다. 그리고 상세페이지에서 하나의 쿼리에서 조인을 걸어서 가져오는것 때문에도 속도 이슈가 있어서 전체적으로 쿼리를 분리해서 정보를 가져오는 것으로 수정했다. (이 두가지는 과장님이 알려주셨다.)
 
2. 파일 저장할때
어쩌다보니 S3 업로드 구현부를 내가 하게 되었는데 (정말 대단한 로컬 개발자의 깽판으로 인해) 팀장님이 알려준게 있었다.
업로드를 할때 "파일의 원본 이름" 과 "파일의 업로드 명" 을 나눠서 저장하고 "파일 확장자" 도 따로 저장한다는 점. 보안에 관련된 부분이였다. 파일명과 확장자를 알면 S3 정보를 알기만 하면 누구나 접근이 가능해져 공격에 취약하다는 점. 확장자를 알려주면 안되는다는 이야기를 해주셨다. 만들때는 처리할게 좀 많아서 헷갈렸는데 만들고 나서 잘쓰니까 다행이다. 프론트할때는 일단 파일 담아서 보내주기만 하면 되니까 그 뒷단의 처리는 잘 몰랐는데 암튼 재밌었다.
 
3. 네이버 에디터 (사진 업로드)
네이버 에디터에 오! 이거는 정말 충격. 에디터를 쓸 때 암것도 모르고 쓰고 있었던 사진 첨부하기! (개발자의 많은 노고가 숨어있었다)
이 또한 네이버 서버에 업로드 되는 줄 알았는데 그게 아니라 사용하는 쪽에서 이미지 업로드 부분을 구축해줘야 한다는 것. 사용자가 바로 볼 수 있게 우리쪽 서버에 올리고 바로 보여준다! 결과적으로 이 사용자가 해당 사진을 올리던 올리지않던 일단 사진이 첨부되자마자 사진이 서버에 올라가야 한다는 점! 이게 포인트였다. 그렇게 하고 나서 결국 사용자가 안올린 사진은 다시 서버에서 지워줘야 한다. (이건 친구한테 들은 얘기) 네이버 에디터 사진업로드는 .. 우리팀 신입분이 했다.. 내가 검색엔진 외부 API 연결하느라 정신이 하나도 없어서 도와주지를 못했는데 "OO님.. 사용자가 사진을 첨부하자마자 S3에 올려주는거에요 알겠죠...? 사진이 실제로 첨부됐는지 여부는 중요하지 않아요. 일단 에디터에 첨부되면 S3에 올라가는 겁니다. 그게 중요해요.." 까지만 말해주고 나는 정신없이 다른거 했다. 코드 구현부를 도와드리지 못해 미안함이 컸는데 정말 결국엔 해낸 OO님!! 정말 대견해요 아주 멋져요. 하산하시라고 했다ㅋ
 
4. 운영 / 검증 / 개발 서버
이렇게 나눠서 했음. 같은 코드를 썼는데도 어디선 되고 어디선 안되고.. 아 정말 골치 아팠고. 데이터 문제도 컸다. 정말 다시 돌아가고 싶지 않은 오픈 초기. 지금은 많이 안정화 되어서 다행이다.
 
 

그래서 지금은?

지금은 부족한 부분 + 빠뜨린 부분 수정하고 있다. 과장님이 짠 코드라서 풀 집중해서 읽어봐야 한다. 잘못건들면 안돼... 그래도 어느정도 내용을 알고 있어서 수정하는데 큰 어려움은 없었다. 사람 때문에  + 소통 때문에 화나는 일도 많았고 (여전히 많고) 힘들었지만 (이건 좀 괜찮아졌다) 잠도 못자고 (이건 여전히!).. 이 프로젝트를 하면서 저연차로서 경험할 수 있는 최대치의 경험을 한 것 같다. 자체 서비스를 하는 회사에 간다면 더 다양하고 신기한 경험을 하겠지..? (막연한 기대를 가지면서) 지금 휴가와서 회고 쓰고 있는데 미리 노트에 정리해두길 잘했다. 노트에 있는 내용들 순화해서 잘 쓰고 이만 마무리한다. 정말 고달팠지만 오픈했으니 "오케이"
팀원들이랑도 정말 많이 가까워져서 만족스럽고.. 나름.. 나름 행복하다. 안녕~ 앞으로도 문제 없이 잘 돌아가기를 바란다!