국비교육을 마치며

21-02-18 ~ 21-07-13

 불과 4일전, 7월 13일부로 올해 2월 18일부터 진행된 뉴렉쌤의 국비교육과정의 마침표를 찍었다. 국비교육과정은 사실 제대로 운영되기 힘든 것 같다. 길어야 6개월의 과정에 웹 개발의 상당부분을 배우고, 평가하고 프로젝트를 해야하니 가르치는 입장에서도, 배우는 입장에서도 서로 힘이 빠지는 일이 생긴다. 6개월도 짧은 기간인데, 이번 교육 과정은 5개월이었다. 1달 차이가 뭐 얼마나 크겠냐만은, 실제로는 엄청난 차이라고 생각된다. 예를 들어 스프링 시큐리티를 배울 때 깊게 파고들어 배우는 거랑, 동작만 가능하게 해놓는 데까지 배우는거랑 천지차이라고 생각된다.

1달이라는 시간이 더 있었다면 조금더 깊이있는 공부를 할 수 있었을 텐데 그 점이 매우 아쉽게 느껴진다.

 

 그렇다고 해서 아쉬운 점만 있느냐, 그것은 절대 아니다. 나는 학원을 다닌 것을, 뉴렉쌤한테 배우게 된 것을 정말 잘한 선택이라고 생각한다. 물론 내가 다른 학원을, 다른 선생님께 배워본 적은 없어 구체적인 비교는 어렵다. 하지만 주변 지인들 중 국비학원을 수료했거나, 진행중인 사람의 얘기를 들어보면, 대부분 진도 나가기에 급급한(정해진 커리큘럼 때문에) 면이 없지않아 있다. 하지만 뉴렉쌤의 방식은 달랐다. 하루 8시간 중 점심시간 전후로 4시간씩 쪼개어 수업 3, 복습 1 / 수업 2, 복습 및 프로젝트 2로 진행되었다. 그리고 매 수업시간 물릴 정도로 학생들이 이해하고 있는지 체크하셨다. 코딩을 처음 접하는 입장에선 이 부분이 굉장히 감사하게 느껴졌을 것 이다. 나 또한 확실하게 짚고 넘어갈 수 있어서 좋았다.

(게다가 CSS, JS는 손도 못대던 내가 CSS는 물론이고, JS를 이용해 자유자제로 AJAX를 구사할 수 있는 능력을 겸비하게 되었다. 물론 Spring boot를 이용해 프로젝트를 만들고, SQL을 사용해 CRUD는 덤으로 얻었다. 이외에도 엄청 많다!)

 

 물론 진도를 빨리 빼고 프로젝트 시간을 충분히 확보하는 것도 방법이 될 수 있다. 하지만 그건 실력이 뒷받침 되거나, 수업을 완벽하게 따라왔을 때의 이야기라고 생각된다. 나의 지식 수준이 부족한데, 프로젝트 시간만 충분히 확보해준다면, 앉아서 멍때리기가 주 업무일 것 이다. 

1차 프로젝트 - Stardy (21-02-25 ~ 21-05-28)

 뭐.. 어쨋든 그렇게 1차 프로젝트를 Servlet/JSP, Oracle, Vanila JS, HTML, CSS만 가지고 'Stardy'라는 스터디 커뮤니티를 개발하였다. 처음부터 이 프로젝트는 배포할 생각이 없었다. 왜냐하면 나에게 있어 Servlet/JSP는 너무 낡은 느낌이 강했기에, 그냥 Servlet의 매커니즘과, Spring을 향하기 위한 발판이라고 생각했다. 그렇다고 해서 절대 대충하진 않았었다. 분명히 역할을 나누고, 팀원들과 지속적으로 소통하며 의견을 조율하고, 어려운 부분도 있었지만 잘 헤쳐나갔다고 생각된다. 그렇게 3개월 간의 여정을 마치고 프로젝트를 마치게 되었다. 결과적으로 나는 만족했다. 이 프로젝트를 하면서 퍼블리싱 능력을 극대화할 수 있었고, Ajax를 JQuery를 쓰지 않고 사용하게 되어 뿌듯했으며, JS로 모듈을 만들어 코드의 재사용성을 높였다. 나중엔 XHR로 JQuery의 $.ajax를 본 뜬 ajax()함수를 만들어 간편하게 사용하기도 했다.

 

 요즘 Servlet과 JDBC API로 누가 개발을 하겠냐만은(거의 맨 땅에서 개발하는 거나 마찬가지) 나름 재미있었다. 웹을 독학할 때 Servlet/JSP를 배우던 내가 새록새록 기억나기도 하고(그래봤자 몇 달 전이지만..) 혼자선 사실 이렇게 스케일을 키울 수 없었고, 팀원들이 있어 끝마칠 수 있었던 것 같다. 물론 100%만족은 하지 못한다.. 기술적인 한계도 존재했기 때문에.

rhacnddl/Stardy

2차 프로젝트 - AROUNDERS (21-05-31 ~ 21-07-12)

 1차 프로젝트를 3개월정도 진행하고 마치니 5월 말이었다. 이제 2차 프로젝트를 진행해야했다. 정말 시간이 없었다. 수료는 1달 하고 1~2주 남짓 남았고, 아직 프로젝트 조도 안짜여있었다. 정말 아이템을 구상해서 뭔가 프로젝트로 만들만한 아이디어가 없던 나는 고민을 하던와중에, 오퍼를 제의받았다. 평소 개발에 있어 많은 지식을 갖고계시던 형이 같이 해보면 좋을 것 같다고 하셨고, 쉐어링 서비스를 하는 것을 구상중이라고 하셨다. 나 또한 아이디어는 없어도 평소 채팅에 관심이 많았기 때문에 둘의 의견을 합쳐 지역 커뮤니티를 함께 만들어보면 어떨까 하는 생각이 들었고 바로 팀을 결성했다. 다른 분들도 함께 했으면 좋았겠지만, 아쉽게도 두 명이서 작업을 하게 되었다. 다른 조에 비해 인원이 적다고 결코 위축되거나, 부러워하지는 않았다. 팀원이 적은 만큼 코드 집중화를 할 수 있고, 의견 조율도 쉬울 뿐만 아니라, 무엇보다 코드를 merge 할 때 너무 간편했다.

 

 그래서 말도안되는 1달이라는 기간동안 수업을 들으며 틈틈히 프로젝트를 진행했고 결국 AROUNDERS를 제작하였다. 처음 구상 및 설계했던 그대로는 아니지만, 제공하고자 했던 서비스는 대부분 포함하고 있어 개인적으로 90% 만족한다. 그 중에서도 채팅을 완벽하게 구현해냈다는 것. 채팅을 하고, 그 채팅을 저장하고, 채팅을 불러오는 과정또한 밑에서 서술하도록 하겠다. 이 프로젝트는 실제 배포를 염두해두고 개발을 하였고, 현재 배포에 성공했다. 하지만 몇 가지 이슈를 발견해 해결하기 전까지 다시 내린 상황이다.

rhacnddl/web

 

# 구현 스펙

Maven 
JUnit 

Java 11
Spring Boot v2.5.0
Thymeleaf v2.5.3
devtools v2.5.0

MySQL v8.0.25
MyBatis v2.2.0
Spring Security v2.5.0

Lombok v1.18.20
Thumbnailator v0.4.8
Spring mail v2.5.0
WebSocket v2.4.0
SockJS v1.1.2
STOMP v2.3.3-1

jQuery v3.6.0
Axios v0.21.1
Bootstrap v5.0.2
Font-awesome v5.15.2
Google-font
Juso(도로명주소) API
Naver Map API v3

HTML 5
CSS 3
Javascript(ES6+)
IntelliJ Ultimate

AROUNDERS ver.2.0

 어라운더스는 나에게 있어 성장의 발판이다. 요즘 많은 기업들이 실제 배포 및 운영을 해본 경험과, 인프라 혹은 메세지큐나 이벤트 큐, 인메모리 DB(예를 들어, apache kafka, redis, rabbitMQ ...) 같은 소프트웨어를 다뤄본 경험을 자격조건이나 우대조건에 내걸기도 한다. 이러한 트렌드에 맞춰 어라운더스를 계속 개선해 나가는 방향으로 여러 기술을 접목시킬 생각이다.

 

 현재 채팅을 Spring Websocket, SockJS, STOMP를 이용해 구현하였고, 메세지 큐는 STOMP의 내장된 SimpleMessageBroker를 사용 중이다. 1차적으로 이 메세지 큐를 RabbitMQ로 갈아 끼우려고 생각중이다. 이렇게 되면 아키텍쳐 부분에 변동이 생기게 된다. 현재 아키텍쳐는 다음과 같다.

 

위의 아키텍쳐에 메세지 큐를 따로 두는 서버를 붙이게 되므로 변동이 생기게 된다. 나에게 있어 이는 크나큰 의미이다. 어서 해보고 싶은 마음이 굴뚝같다. 음.. 당장 기술적인 면에서 개선하고 싶은 사항은 이정도로 생각하고 있다.

 

그리고 위에서 몇 가지 이슈를 발견하여 배포를 잠시 중단했다고 했는데, 그 이슈는 다음과 같다.

1. 위치 정보 동의를 받아야하는데, https에서만 가능하다. (SSL 인증서를 달아야한다)
2. https와 도메인 문제를 해결해주는 heroku를 이용하였다.
3. heroku는 미접속 시 30분마다 서버 리프레시를 한다.
4. 서버 리프레시 시, 업로드된 static 파일들이 사라진다. 혹은 재배포 시에도 날아간다. (실제로 heroku 공식 사이트에서도 파일 저장은 aws를 권장한다)
5. 즉, 이미지 업로드 하면 이미지 파일이 날아간다.

이러한 이슈 떄문에 정적인 파일을 업로드하고, 불러올 수 있는 하나의 서버 어플리케이션을 하나 더 만들려고 하는데, 문제는 기본 로직에서 큰 변화 없이 동작하게끔 구현하고 싶었다. 그러기 위해선 Server-Client 간의 통신이 아닌, Server-Server 간의 통신이 요구되었다. 구글링 끝에 RestTemplate라는 것을 알게되었고, 이를 사용해서 현재 게시글 등록 시, 이미지가 다른 서버에 저장되는 것 까지 테스트를 완료한 상태이다. 이제 로직을 구체화해서 실제 비즈니스 로직에 적용하면 되는 단계이다.

 

아마 이런 생각을 하는 분도 계실 것이다. 'AWS를 이용하거나, 따로 서버컴퓨터를 장만해서 거기에 서비스를 올리지... 굳이?? 아니 그보다 heroku쓰지말고 SSL을 등록하면 되지 않나?'

 

충분히 이해한다.. 나 또한 이런 설계를 하며 '굳이 이렇게 까지 해야하나...' 싶은 생각이 든 것도 사실이다. 하지만 현재 이를 배포함으로써 얻는 수익은 0이고, 아직 취준생이기에 경제적 수입이 없다ㅠ 그래서 돈을 최대한 쓰지 않는 방향으로 가자면 이러한 방법도 있겠다 싶어서 이렇게 진행하게 되었다. 앞으로 진행도 같은 것을 간간히 기록할 생각이다!

Chatting

끝으로 채팅의 저장에 대해서도 거창한 기술을 쓰지 않고 나름 논리적인 로직을 사용했는데, 궁금해하실 분들도 계실 것 같아 간단하게 소개해보고자 한다.

 

우선 위에 언급햇듯, websocket, socksj, stomp를 사용했다. 그리고 채팅방을 고도화 해서 여러개의 채팅방이 있다. 각각의 채팅방은 하나의 채팅방 파일(DB가 아닌 .txt에 저장했다)을 갖는다. 이곳에 JSON 형태로 채팅 내역이 들어오게된다.

 

이 때, 하나의 채팅-> 하나의 save가 아닌, Map<Long, List<Chat>>의 형태로 개인적으로 나름 괜찮은 인메모리 Queue(Buffer)를 만들어 사용했다. 채팅방에 접속중인 사람이 0명이거나, buffer에 특정 크기만큼 채팅 데이터를 저장하면 flush해서 파일에 저장하도록 했다. 고수분들이 보기에 결코 좋은 로직은 아니겠지만 내 나름대로 만족하는 알고리즘이었다 ㅎㅎ..