한동안 개발 작업을 안 했더니....
작년 9월초쯤 협업 프로젝트인 Pro.gg 를 끝내고 난 뒤 취직을 하기전에 좀 더 공부가 필요하다고 생각해서 개인적으로 공부하기를 수 개월, 올해 3월 한달 간 Pro.gg 프로젝트 에서 조금 부족하다 생각했던 몇 가지를 개선한다음 4월 들어서 포트폴리오를 만들고 본격적으로 취직을 하기 위해 각종 개발 회사에 서류를 돌리고 다녔다.
그렇게 해서 5월 13일 경 처음으로 잡힌 면접에서 기술 면접에 대한 질문들은 나름대로 공부하고 준비한대로 어느정도 잘 대답했으나 예상치 못했던 코딩 테스트에서 난관에 봉착했다.
분명 서류과정엔 코딩 테스트가 없었는데 갑자기 코딩테스트를 한다기에 조금 놀라긴 했지만, 그래도 알고리즘 문제풀이 라면 어느정도 공부를 해뒀고 나름 자신도 있었기에 문제 없겠지라고 생각했다.
하지면 예상과 달리 회사에서 활용하는 데이터베이스 구조에 대한 설명을 해줌과 동시에 제시된 문제에 따라 CRUD 를 구현해보라는 것이 코딩 테스트 주제였다.
물론 예상과 다르긴 했으나 예전 Pro.gg 프로젝트를 진행한것 덕분에 단순히 잘 동작하는 웹 환경을 개발하는 것 자체는 문제가 없을 것이라고 생각했다. 개발 환경 구축만 문제없이 해결했다면 말이다.
Spring initializr 홈페이지에서 필요한 의존성을 다 포함시켜서 패키지를 다운 받고 회사에서 제공해준 노트북에서 스프링 부트를 동작시키려고 했으나, 이상하게도 스프링이 제대로 동작하지 않았다.
개발환경 세팅부터 삐걱대길래 뭔가 불안하긴 했지만, 그래도 일단 스프링 부트가 제공 안되면 제공 안되는대로 코딩 부터 해보기로 했다.
그러자 작년 9월 이후부터 Spring 웹 MVC 패턴을 활용한 코딩을 하지 않았기 때문인지 웹 개발 자체의 숙련도가 이미 떨어질대로 떨어진게 온몸으로 느껴지기 시작했고, 그 때문에 예전 Pro.gg 프로젝트를 했던 기억들을 하나하나 더듬어가며 어떻게든 코드들을 한줄 한줄 작성해 나가야 했다.
하지만 끝까지 스프링 부트 환경이 제대로 제공되지 않는것이 코딩테스트의 발목을 잡았고, 얼마안가서 문제를 하나도 해결하지 못한체로 면접관 분들이 코딩테스트를 종료시켰다.
이후 면접관분들이 회사에서 제공된 노트북에 설치되어 있는 IntelliJ 자체가 문제인것 같다며 날 다독여 주긴 하셨지만, 이 회사를 떨어진것은 결국 이 코딩테스트의 영향이 정말 컸을것이라고 생각한다.
면접 이후 집에 돌아와서 코딩테스트때 했던대로 환경 구축을 해봤는데 참 신기하게도 집에서는 아무런 문제 없이 스프링 부트 환경이 정상적으로 세팅이 완료되는것을 보고 이루 말로 다할 수 없는 허탈함을 느꼈다.
심지어 원래 컴퓨터에 설치되어 있던 IntelliJ 까지 완전히 삭제한 후 IntelliJ 설치부터 다시 해봤는데도 아무 문제없이 정상적으로 잘 동작하는것을 확인할 수 있었다.
그런데 이 환경 설정은 그렇다 치더라도 또 하나 정말 크게 충격이었던 것은, Pro.gg 프로젝트 이후 몇개월간 Spring 웹 MVC 환경에서의 개발을 하지 않아서 떨어질대로 떨어져버린 나의 웹 개발 숙련도였다.
알고리즘 공부다, 스프링 기본 개념 학습(스프링 빈을 활용한 의존성 주입 등)이다, HTML,CSS 다 뭐다 해서 정작 몇 개월간 가장 중요한 직접적인 웹 개발을 하지 않은 상태이다 보니 막상 면접에서 해당 환경에서 코딩을 해보라는 과제를 만났을때 처참하게 떨어져버린 숙련도 때문에 기억을 하나하나 더듬어가며 코딩을 하느라 정말이지 고역이 아닐수 없었다.
그렇기에 소규모로 개인 프로젝트를 하나 더 진행하면서 떨어져버린 웹 개발 숙련도를 다시 끌어 올리고자 했고, 그렇게 해서 이번엔 Calling Diary! 라는 개인 일정 관리 및 문자 메시지 알림 서비스를 지원하는 웹 사이트를 개발 해보았다.
Pro.gg 프로젝트를 하며 아쉬웠던 점들을 이번 프로젝트에서 보완해보자.
1. MyBatis 대신 JPA 를 활용해보자.
Pro.gg 프로젝트를 진행했을 때는 국비 학원에서 만났던 사람들과 같이 프로젝트를 진행하는 것이었어서 학원에서 가르쳐준 것 외에 다른 기술스택을 활용하려고 할 경우 따로 공부가 필요했다.
솔직히 나는 이전에 JPA 를 기본적인 수준이나마 공부해본적이 있기 때문에 기본적이고 단순한 CRUD 쿼리 기능은 메소드로 제공해주는 Spring Data JPA 를 데이터베이스 접근 기술로서 활용하고 싶었으나, 같이 협업을 하는 사람이 학원에서 활용하면서 배운 마이바티스 외에 다른 데이터베이스 접근 기술을 다뤄본적이 없기 때문에 어쩔수 없이 마이바티스를 활용해야 했다.
물론 마이바티스도 훌륭한 데이터베이스 접근 기술이고 동적 쿼리를 작성하는데 있어서는 QueryDSL 이라는 개념을 따로 공부해야 하는 JPA 보다 좀 더 빠르게 배워서 사용할 수 있다는 장점도 있다.
다만 조금 복잡한 쿼리를 작성해야 하는 경우 JPA는 객체를 중심으로 쿼리를 작성할 수 있게 해주는 JPQL 이라는 쿼리 언어를 지원해주고(이 덕분에 어떤 데이터베이스에도 구애받지 않고 쿼리를 작성할 수 있다. 즉, 쿼리를 작성하더라도 MySQL 에 맞는 문법, Oracle 에 맞는 문법 같은걸 신경 쓰지 않고, 오직 객체 하나에만 집중하여 쿼리를 작성해 줄수 있다.),
별다른 조건없이 정말 단순하게 select 또는 insert 만 하면되는 경우 따로 쿼리를 작성해줄 필요 없이 Spring Data JPA 에서 기본적으로 제공해주는 메소드를 호출해주는 것만으로 기능을 처리해줄 수 있는것에 반해(물론 해당 메소드가 적용되는 객체의 경우 @Entity 와 같이 JPA 가 관리하는 객체라는 지정을 해주어야 하고, 기본키, 외래키 같은것들도 어노테이션을 통해 지정 해주어야 한다.)
마이바티스의 경우 아주 단순한 쿼리 조차 직접 매퍼 파일에 쿼리를 작성해주어야 하고, 그 쿼리도 객체가 아니라 테이블 중심으로 작성하는 네이터브 쿼리를 작성해야 하기 때문에 쿼리를 각 데이터베이스 방언(dialect) 에 맞게 작성해 주어야 한다는 단점이 있다.
(중간에 만약 활용하는 DBMS 가 바뀌게 되면 그 DBMS 의 방언(dialect) 에 맞게 쿼리를 조금씩 수정해 주어야 한다.)
Pro.gg 프로젝트에서는 협업 하는 동료가 JPA 를 접해본적이 없다는 점, 그리고 구현하고자 하는 기능 중에 동적 쿼리를 사용해야 하는 기능이 있는데, 마이바티스와 JPA 중 동적 쿼리를 구현하는데 있어 마이바티스 쪽에 그나마 더 빠르게 배워서 활용할 수 있다는 점 때문에 마이바티스를 활용하였으나,
이번에 새로 진행하는 프로젝트에서는 기능을 구현하는데 있어 동적 쿼리가 필요하지 않은점, 그리고 단순한 쿼리들은 굳이 쿼리를 작성해줄 필요 없이 메소드 호출만으로 수행할 수 있다는 점을 적극적으로 활용해보기 위해 데이터베이스 접근 기술로(또는 객체 - 관계형 데이터베이스간 매핑 기술로) JPA 를 활용해보기로 했다.
2. JSP 대신 Thymeleaf 를 활용해보자.
템플릿 엔진도 JSP 를 활용해야 했다. 학원에서 가르친게 그것 이었기에 다른건 사용해본적 없는 사람들을 위해 어쩔수 없이 JSP 를 템플릿 엔진으로 활용하여 Pro.gg 프로젝트를 진행했다.
그러나 스프링 부트의 경우 서버 측의 템플릿 엔진으로 타임리프를 권장하고 있다. 타임리프를 사용하는 경우 의존성을 주입해준 다음 html 문서상에 타임리프를 활용하는 문서라는 태그를 작성하고 resources/template 경로에 html 파일을 저장하는 것만으로 원활하게 타임리프를 템플릿 엔진으로서 활용하는 것이 가능하다.
반면 JSP 를 활용할 경우 스프링부트에서 지원을 해주고 있지 않기 때문에 JSP 에 맞는 리소스 경로를 위해 WEB-INF 와 같은 폴더를 따로 생성해 주어야 하고, application.properties 파일에 jsp 파일을 사용하기 위한 설정을 부차적으로 해주어야 하는 번거로움이 존재한다.
뿐만 아니라 JSP 의 경우 서버 측에서 넘어온 데이터를 클라이언트측에서 활용하려면 JSTL 을 활용한 태그, 또는 자바 코드를 활용해 줄 수 있는데, html 파일상에서 자바 코드를 사용하여 화면을 랜더링 할 수 있다는 점이 언뜻보면 장점 같지만, 코드가 많아질수록 html 파일의 전체적인 가독성이 떨어진다는 단점도 분명히 존재한다.
결국 Pro.gg 프로젝트에서는 JSP 를 활용할 수 밖에 없었지만, 현재 템플릿 엔진으로서는 사장되고 있다는 JSP 하나만을 가지고 프로젝트를 진행한 경험으로는 경쟁력이 부족할 수 밖에 없기에 새로 하는 프로젝트에서는 템플릿 엔진으로 JSP 가 아닌, 스프링 부트에서 권장하는 타임리프를 활용해보기로 했다.
3. 화면도 어느정도는 구현할 줄 알아야지?
이전 Pro.gg 프로젝트에서 부트스트랩과 css 를 활용한 전체적인 화면 테마 디자인 및 설계, 구현의 경우 거의 같이 작업하는 형이 담당했다.
나는 그저 내가 구현한 기능이 화면상에서 잘 동작하는지 확인할 때 형이 작성해놓은 코드들 중에 쓸만한것들을 그대로 베껴서 활용하는 것에 그쳤다.
말 그대로 내 작업의 비중은 거의 기능 구현을 위한 데이터베이스 접근과 비즈니스 로직 구현에 집중되어 있었다.
그런데 실제 현업 개발자가 되면 어지간한 대기업이 아니라면 백엔드 뿐만이 아니라 프론트엔드 또한 병행해서 작업할 줄 알아야 한다.
결국 프론트엔드와 백엔드, 양측에서 협업을 하며 작업을 해야하기 때문에 필요할 경우 프론트엔드 쪽의 작업도 어느정도는 할 줄 알아야 하는것이다.
그렇기 때문에 이번엔 화면의 전체적인 테마 디자인 부터 구현까지 내 힘으로 직접 해보기로 했다.
기본적으로는 html 태그의 클래스 속성을 통해 제공되는 부트스트랩의 각종 테마를 활용하되, 필요한 경우 직접 css 작업을 해주는 식으로 작업을 해서 화면을 완성해보자.