[웹 개발] 스프링 부트 목표 설정 서비스

진행 기간

2020.02.01 ~ 2020.03.11

전체 코드

youjeongsue/goal-rest-service

회고

여러 프로젝트를 하면서 처음 해보는 회고이다. 이전에 진행했었던 프로젝트들이 실패하거나 중간에 무산될 때, 나는 종종 자괴감에 빠지곤 했었다. 하지만 그럴 필요가 없다는 걸 느끼고, 이렇게 회고를 남기면서 경험을 돌아보려고 한다. 어떻게 하면 회고를 잘할 수 있을지 고민하다가 좋은 글을 찾게 되어 참고하려 한다. 5F로 정리하는 것인데,

 

• 사실(Fact)
• 느낌(Feeling)
• 교훈(Finding)
• 향후 행동(Future action)
• 피드백(Feedback)

이렇게 5가지라고 한다. 프로젝트에서 겪었던 사실들부터 시작하여 느낀 점을 기록해봐야겠다.

회고 (Retrospective)에 대한 정리 및 설계 · Issue #8 · JaeYeopHan/tip-archive

새로운 기술

REST service를 만들기 위해, 우리 팀은 Spring Boot를 사용했다. Spring을 접한 지 한 달이 채 되지 않았지만(튜토리얼까지 해본 정도..), 계속 공부하며 프로젝트를 진행하겠다고 팀원들과 얘기하고 함께 하게 되었다. 스프링 부트 외에도 TDD나 DDD 등 공부하고 적응해야 할 것들이 많았다.

새롭게 배운 것을 나열해보자면

 

• Spring Boot, JPA, h2
• intelliJ, gradle
• Git version control, Github
• Test Driven Development, Domain Driven Development

팀원들과 얘기한 프로젝트의 목표 중 하나는 최대한 다양한, 새로운 도구들을 사용해보는 것이었다. jenkins, docker, kubernetes 등을 사용해보고 싶었다. 다 같이 공부를 해보고 적용시켜보기로 했었는데, 직접적인 개발 시작이 늦어지는 것 같다는 의견이 있어서 미뤘다가 결국 도입은 못해본 점이 아쉽다. 새로운 기술을 도입할 때 러닝커브도 중요한 고려 요소라고 들었었는데 그 말을 실감했다. 결국 누군가 나서서 공부하고 이끌어주는 역할을 해줘야 실질적인 도입이 가능할 것 같다는 생각을 하게 되었다. 다음에는 내가 그럴 수 있도록 노력해야겠다.

애자일

프로젝트는 애자일 방법론을 따라 진행하기로 하였다. 우리 팀에서 정한 애자일 방법은, 각자 맡은 일을 데드라인까지 알아서 하고 최대한 짧은 주기로 회의를 진행하는 것이었다. 결과적으로 말하면, 보통의 팀 프로젝트처럼 '언제까지 이만큼 해와서 회의를 하자'의 형태가 되었고, 4~5일에 한 번 결과를 보고하는 식으로 진행되었다. 이 방법이 애자일인지는 잘 모르겠다. 애자일을 실제 프로젝트에 적용시키는 것은 어려운 것 같다.

 

다시 애자일을 한다면 다음과 같이 해야겠다고 생각이 들었다. 가능한 한 태스크나 이슈를 작게 나누고, 하루에 한 번 한 것을 보고하고(그 날에 진행된 작업이 없어도 눈치주는 분위기가 없어야 가능할 방식이다), 작은 이슈를 바탕으로 코드 리뷰를 활발히 하는 것이다. 이것도 적절한 방법이 아닐 수 있지만, 적어도 팀원들과 많은 얘기를 할 수 있을 것 같다.

 

그리고 프로젝트에 대해 충분히 이해를 해야 내가 할 일을 찾아서 할 수 있다는 것을 느꼈다. 적극적으로 할 일을 만들고 공부한 것을 공유해야 한다. 누군가 일을 던져주길 기다리면 아무것도 못한다.

소통

이 프로젝트는 끝을 내지 못하고 중단되었고, 가장 큰 문제는 소통의 부재였다고 생각한다. 가능한 만나서 하는 회의를 많이 하려고 노력했지만 코로나-19가 유행하고 있는 지금, 우리는 온라인으로 회의를 대체하게 되었다. 우려하던 것처럼 온라인 회의는 여러 사정들로 인해 계속 미뤄졌다. 프로젝트의 방향에 대해서도, 진행 상황에 대해서도 많은 얘기를 할 수 없었다. 여러 답답함들이 쌓여 프로젝트를 중단하게 되었다.

 

프로젝트를 끝까지 해내기 위해서는, 기술을 잘 다루는 것뿐 아니라 팀원들과 소통을 잘하는 것이 더 중요할 수도 있다는 것을 느꼈다. 기술을 배우는 게 더 쉽다는 말도 있다. 반면 소통하는 방법은 경험하지 않고는 배울 수 없는 것 같다. 이번 프로젝트에서 유기적으로 연결된 도메인들을 팀원들끼리 나눠서 작업하게 되었는데, 쪼개진 코드의 의도를 이해하고 그것을 망치지 않으면서 내 코드를 짜는 것이 쉽지 않다는 것을 느꼈다. 이건 아주 짧은 기간 동안 느낀 단적인 예지만, 더 큰 프로젝트라면 이보다 덜 하진 않을 것이다.

 

커뮤니케이션을 잘 하는 개발자가 되어야겠다. 상대방이 나에게 편하게 피드백을 줄 수 있게 하는 것이 첫 번째라고 생각한다.

Good Developer 2 | 커뮤니케이션 잘하는 개발자가 되는 방법

웹 개발

나는 데이터 엔지니어가 될 것이다. 데이터 엔지니어로서 데이터를 잘 처리하는 것 만큼, 서비스에서 데이터가 어떻게 사용되는지 이해하는 것도 매우 중요하다고 생각한다. 그래서 웹 서비스를 직접 개발해보는 경험을 하고싶었다. 백엔드와 DB, 프론트엔드가 어떻게 데이터를 주고 받는지, 사용자들이 생성하는 데이터는 어떻게 기록되고 관리해야 하는지 실제로 느껴보고자 이 프로젝트를 시작하게 되었다. 비록 마무리는 짓지 못했지만 REST 서비스를 처음 개발해본 좋은 경험이었다고 생각한다.