[Toy Project] AutoTR 후기

Project README

https://github.com/justdoit0730/AutoTR?tab=readme-ov-file#autotr

후기

 TCP, HTTP Client 통신 기능, Kafka 적재, Elasticsearch indexing, index 정보 확인, Query 사용, TPS에 맞춘 요청 기능, Redis Command 등을 한 번에 수행할 수 있는 웹페이지를 만들고 싶었다. 가볍게 회원가입과, 게시판, 댓글 기능까지 추가했다. UI는 깔끔하게 구현하고 싶었지만, 귀찮다는 이유로 대충 넘긴 부분이 있다. 가이드 없이 바로 사용할 수 있도록 나름 직관적으로 만든 것 같다. 본인은 각 요청이 필요하면 AutoTR을 사용하고 있다. 찾으면 있을 수도 있겠지만 비슷한 콘셉트의 프로그램이 없었다.

 사내에서 Java 기반의 Module을 주된 업무로 하고 있어서 스프링 부트를 사용할 일이 거의 없었다. 개인적으로는 한 번도 스프링 부트를 이용한 프로젝트를 해본 적이 없었다. 그래서 스프링 부트를 이용한 프로젝트도 하고 싶은 마음이 있었고, 각 오픈소스를 이용한 간단한 웹페이지를 만들고 싶었고, 무엇보다 꼭 마무리를 지을 수 있는 프로젝트를 하고 싶었다. 결론은 마무리는 했지만, 마무리하지 못했다.

 

아쉬운 점 및 배울 점

 후기에서 마무리 했지만 마무리하지 못한 가장 큰 부분은 서버에서 기동 중인 프로젝트에서 Local 서버 및 포트에 테스트가 안된다는 것이다. 프로젝트를  local IDE에서 실행 후 server 나 local에 요청하는 식의 테스트를 진행했었다. 그래서 막연히 server에서 실행한 프로젝트도 잘 수행될 것이라고 생각한 것이다. 회사의 서버는 Router를 통해 각 PC에 NatIP를 할당받아 사용 중이다. 특정 서버에서  개인 PC의 IP로 통신을 접근할 때 방화벽 등 보안 정책의 문제로 접근이 안된다는 사실을 간과한 것이다.(이 또한 접근이 안 되는 정확한 이유가 아닐 수 있다.) 그래서 서버에서 실행된 웹 페이지는 개인 PC(Local) 환경이 아닌 서버 간 통신만 가능하다. Local에서 테스트할 일이 많은 나는 결국 프로젝트를 Local에서 실행해야 하는 상황이 된 것이다. 아주 구차한 대안으로 프로젝트 jar를 배치 파일로 실행, 종료하는 방법으로 사용 중이다. 이것이 Kafka, Redis, Elasticsearch에서 작업을 수행할 tool이 찾기 어려웠던 이유였을까 싶었다. 운영가능한 프로젝트를 제작하기 위해 목적도 중요하지만, 인프라적인 측면에서 사용 가능 여부도 포함된다는 것을 배웠다. 지반이 약한 땅이라면 아무리 멋진 아파트를 지었을지라도 아무도 들어가 살지 않을 것이다. 다음 토이 프로젝트나 시작하는 개발 건에 대해서 지반부터 단단히 공사해야만 한다는 걸 배웠다.

 코드 부분에서도 아쉬운 점이 너무 많았다. 초반 개발 때 주요 Server info를 UI에서 출력된 값 그대로 JS로부터 parameter 받아 Service, Util 단에서 split 하는 식으로 가져온 부분이다. 당시에는 몰랐지만, 각 분리를 해서 ENUM처리를 했다면 다른 사람이 읽기에도 훨씬 수월했을 것 같다는 생각이 든다. 이 사실을 알았을 땐 공통 메스드 분리를 다 하고 난 뒤였다. 물론 수정할 수 있지만, 아직은 하지 않았다. 1.0.1 version 이후 해당 프로젝트의 개발은 멈춰있다. 수정한다고 단언은 못하지만, 최소한 해당 부분이 리펙터링이 필요하다는 점은 알고 있다.

 그리고 Thread 를 각 기능에 맞게 singleton 패턴으로 구현하지 않았다는 것이다. 자바 코드에서 가장 아쉬운 부분 중에 하나이다. 머리로는 이 부분에서 싱글스레드를 열어 각 분리된 처리를 하는 게 좋다고 생각했지만, 결국 기능적인 부분 안 쪽에서 비동기 처리하는 말도 안 되는 돌려 막기 코드를 짜버린 것이다. 처음으로 만드는 프로젝트이고, 해당 부분은 생소하니까 일단 프로젝트부터 완성하자는 안일한 생각을 했었다. 처음 시작할 때 나름의 그림이나 표를 그려보면서 어떻게 구현할지 가안이라도 구상해 보는 게 좋을 것 같다는 생각이 들었다. 디렉터리 구조도 잘 정리해서 체계적으로 만들어야겠다.

 무엇보다 ChatGPT의 도움을 너무 많이 받았다는 것이다. Data를 Generating 하는 부분이나 전송에 필요한 구조는 내가 만들었지만(지금 봐도 이 부분이 제일 더럽다.), Spring security, Paging 처리 등 전반적인 JS 코드, TPS 처리에 필요한 비동기 코드들은 구글링에서 확인한 정보보다 GPT에게 받은 코드가 더 유용했고, 그를 토대로 끼워 넣었었다. GPT 덕분에 개발 속도가 굉장히 빨라졌지만, GPT 때문에 내가 개발한 게 아닌 것 같은 기분을 느꼈다. 내 역량을 위해서라도 이해가 꼭 뒷받침되어야겠지만 한편으로는 향후 AI는 믿을 수 없을정도로 우리 주위에 더욱 접근할 것이고, 이런 세계에서 GPT를 사용하지 않는 건 뒤쳐진 것이라고 자기 위안을 한 부분도 있다.

 마지막으로 아쉬웠던 점은 개발 건에 다한 Issue를 적극적으로 작성하지 않았다는 점이다. 중/후반 작업에 가서야 Issue를 작성하기 시작했다. 그전에는 오로지 Commit Message로만 증적을 남겼다. Issue를 작성하기 전까지 당연히 Release Note, Tag 도 없다. 이 부분은 아쉬운 수준이 아니라 후회가 되는 부분이다. 요구사항 발생 및 확인 -> New issue 작성 -> 개발 -> 테스트 ->  Comment에 테스트 결과 작성 -> 배포 -> 개발계 테스트 및 운영계 반영 -> Issue close. 사내에서 내가 속한 파트에서 작업하는 대략적인 방식이다. 참고로 이 와중에 나는 이 방식도 회사에서 처음 배웠다. 회사에서 참 기본적인 것부터 많은 걸 배운 것 같다. 개인 프로젝트라 작성한 Issue에 테스트 결과까지는 작성하진 않았지만, 처음부터 이슈로 작업을 정리했더라면 어떤 기능이 어떻게 추가되었는지 확인할 수 있었을 테니 그 점이 아쉽다. 노션으로 작성해 보라는 조언을 들었던 적이 있었는데 참 후회스럽지 않을 수 없다. 다음 프로젝트에서는 잘 작성해 보자.

 

맛보았던 점

 내가 이 프로젝트를 진행할 수 있었던 이유는 [스프링 부트와 AWS로 혼자 구현하는 웹 서비스]라는 책 덕분이었다. 애초에 Spring boot를 사용해 본 적도 없던 나에게 아주 친절한 선생님이자, 조언자이자, 귀찮게 계속 물어볼 수 있는 일종의 구원자였다. 그래서 게시판에 관한 코드와 DB 저장에 관한 코드는 거의 책에 있는 내용과 흡사하다. 해당 책의 Spring boot 버전은 2.3.1.RELEASE이었다. 사내 JDK는 17 version을 사용 중이었다. 내 입장에선 그래도 회사에서 사용하고 싶다는 마음에 JDK 17 버전을 사용하고 싶었다. 그런데 JDK 17은 해당 버전의 Spring boot와 호환되지 않았고, Spring boot version upgrade 시 spring security의 설정과 java import 주체가 javax에서 jakarta로 바뀐다는 것도 알았다.

 httpSession, IndexedDB 기능, Websocket 기능, Domain @SessionScoper 기능, runnable, Flux 및 mono 처리 등은 만약 내가 이 toy project를 하지 않았더라면 몰랐을 것이다. 얕은 깊이더라도 사용 봤으니 이제 구체적으로 각각 무엇인지 확인해 볼 생각이다. JPA 구조도 추가적으로 확인해봐야 한다. 최소한 모르는 걸 모르는 수준은 넘겼으니 이제 모르는 걸 알아갈 생각이다.

 

추가로 공부할 점

통신 방식

- TPC 소켓통신

- HTTP API 통신

 

인프라

- 도커 : 서버와 컨테이너, Local 환경의 네트워크 관계

 

자바

- runnable

- Flux

- mono

- Thread 구현

 

Spring 및 Web

- Spring Secuirty

- IndexedDB

- Websocket

- SessionScoper

- JPA