12월 초, 세 명이 모여서 첫 번째 프로젝트 회의를 진행했다.
처음에는 프론트엔드 개발자를 구할 수 없어 Vue.js를 따로 해야 하나 싶었지만, 기획을 담당했던 팀원분이 프론트엔드 개발자분을 모셔 와서 한숨 돌릴 수 있었다.
예전 개발을 처음 시작하는 단계에서 실전! 스프링 5와 Vue.js 2로 시작하는 모던 웹 애플리케이션 개발을 읽고, 처음 Vue.js를 사용해 봤던 경험이 있다.
그때 Vue.js에 대해 처음 알게 되었는데, 검색을 해보니 3이 있어서 책은 2로 되어 있었지만, 이왕 최신 버전을 사용해 보고 싶어 3으로 진행했는데.. 3에서는 2의 기능이 빠져있거나 새롭게 변경된 경우가 있어 이슈를 해결하는데 온 시간을 쏟았다. 😂
책의 내용에는 테스트 코드의 중요성에 대해 많이 나와 있었고, 여기서 TDD의 개념을 처음 배웠던 것 같다.
읽다가 이해가 되지 않는 것이 많아 주화입마 상태에 빠져 중간에 읽는 것을 그만뒀지만, 지금 읽으면 공감되는 내용이 많아 끝까지 읽을 수 있을 것 같다.
만약 프론트엔드 분이 오시지 않았다면 그 책을 다시 봤을 것 같다.
간단하게 모여서 각자 맡을 수 있는 기술에 관해 얘기하고 기능 명세서를 작성했다.
이 프로젝트의 목적은 국내에 번역된 뉴스를 보여주는 것이지만, 먼 미래를 바라봤을 때 글로벌 서비스를 제공할 수 있을 것 같았다.
하지만 말 그대로 먼 미래의 일이니, 한국어 서비스를 제공하는 것에 집중하기로 했다. 😂
그 외 기능으로 스타시티즌의 한글 패치 배포도 지금 서비스에서 제공하는 것도 제시되어 나중에 뉴스 번역 기능 제작이 완료되면 그때 진행해 볼 것 같다.
한 가지 걸리는 점이 있다면 나 빼고 전부 현업에 종사하는지라, 다음 회의 일정 잡기가 힘들다는 점이다.
지금 백수인 나의 특권을 살려 빠르게 개발할 수 있겠지만, 우테코에서 배웠던 코드 리뷰는 고사하고, 페어 프로그래밍을 적용하기는 힘들 것 같다.
우선은 기능을 추가할 때 이슈를 작성하고, PR을 올려서 승인을 얻어야 머지가 되도록 하여 최소한의 안전장치는 마련해 두었다.
첫 개발 단계에 들어가서, 우선 핵심 기능인 News 도메인을 설계했다.
간단히, 뉴스 사이트에 들어가서 어떠한 형식으로 뉴스가 제공되는지 분석하고, HTML 파싱을 어떻게 해야 할지 고민을 많이 했다.
여기서 알아낸 점은 카테고리별로 HTML 형식이 많이 달랐다.
즉, 여러 버전의 크롤러를 만들어야 한다는 뜻이었다.
공통적인 뉴스의 틀은 제목과 소제목 그리고 내용과 사진이 제공되었고, 특별히 다른 카테고리라 하더라도 추가되는 특징은 없었다.
어떤 카테고리는 제목이 제공되지 않으니, HTML의 title 태그를 파싱하여 제목으로 가져와야 하는 점만 주의하면 될 것 같았다.
그리고 도메인 분석을 마치고, 엔티티 설계에 들어갔다.
코틀린은 최신 버전인 1.9.20을 사용했고 스프링 부트 또한 3.2를 사용하였다.
그리고 빌드를 하자마자 컴파일 단계에서 에러를 마주쳤다. 😂
그래서 당장 패키지를 만들고, 클래스를 만들기 전에 build.gradle 파일을 수정하느라 애를 먹었다.
위에서 이런 경험을 했던 것 같은데.. 😂
하지만 크게 어려운 이슈는 아니라서 검색을 통해 빠르게 해결할 수 있었다.
오히려 이슈를 처리하느라, gradle 파일을 코틀린으로 사용하는 데 익숙해졌다.
그리고 드디어 코틀린 클래스를 생성하고 엔티티를 만드는데...
생성자를 만드는 것부터 일이었다.. ㅋㅋㅋ
그 외 자바에 익숙한 탓인지, 타입을 먼저 적거나 getter를 자꾸 만들려고 한다거나..
솔직하게 개발하며 약간 후회했다... ㅋㅋㅋㅋㅋㅋ
익숙했던 자바나 쓰지, 뭐 하러 사서 고생하려고 코틀린을 썼을까 하며..
지금, 이 글을 쓰는 시점에는 오히려 코틀린이 편해져서 기존 자바로 만든 프로젝트를 코틀린으로 바꿔버리고 싶을 정도이다.
아무튼, 여러 시행착오를 거치며 최대한 코틀린답게 작성하도록 노력했다.
참고하며 많은 도움을 얻었던 블로그 링크를 첨부한다.
- https://www.baeldung.com/kotlin/spring-boot-testing
- https://kyucumber.github.io/posts/spring/kotlin-test-with-spring
- https://medium.com/@joongwon/kotlin-%EC%BD%94%EB%94%A9-%EC%BB%A8%EB%B2%A4%EC%85%98-%EC%A0%95%EB%A6%AC-7681cde920ce
- https://spoqa.github.io/2022/08/16/kotlin-jpa-entity.html
- https://toss.tech/article/kotlin-dsl-restdocs
News 엔티티 설계를 마치고, API 또한 만들었다.
API를 만들면 당연하게 API 문서 또한 만들어야 한다.
그리고 Swagger와 REST Docs 중 무엇을 선택할지 고민했다.
결론부터 말하자면 REST Docs를 선택했다.
이유는 코틀린을 사용하기 때문이다.
페스타고 프로젝트에서는 API 문서를 만들 때 Swagger를 사용했다.
이유는 API 문서화가 매우 쉬워서였다.
예전 스프링을 학습하고 우테코 미션에서 REST Docs를 사용했는데, REST Docs를 사용하고 느낀 점은 "API 문서를 이렇게 쉽게 만들 수 있다고?" 였다.
그리고 Swagger를 쓰고 나서 다시 한번 느꼈다.
"API 문서를 이렇게 쉽게 만들 수 있다고?" 😂
그런데도 왜 REST Docs를 쓰는가 하면, 코틀린을 사용하면 REST Docs를 생성하는데 비용과 시간을 크게 줄일 수 있기 때문이다.
이것은 코틀린이 제공하는 확장 함수와 중위 함수 덕분이다.
REST Docs를 사용하므로, 테스트 코드를 자연스럽게 작성해야 하는 것은 덤이기도 하고...
이때 더 이상 자바를 사용할 수 없겠구나 라는 생각이 들었던 것 같다.
그 외 테스트 코드도 JUnit5 말고 Kotest를 처음 사용해 봤는데..
코틀린이 정말 잘 만든 언어인 것을 다시금 느낄 수 있었다.
자바도 물론 잘 만든 언어지만, 코틀린은 자바의 한계를 뛰어넘는 그 이상의 언어였다.
처음에 봤을 때 문법이 이게 뭔가 싶다가도, 적응되니 이만한 게 없었다.
취업을 한다면 코틀린을 사용하는 회사에 무조건 가고 싶다. ㅋㅋㅋ
