싸피 1학기를 수료했다.
수료 일주일 전부터 진행한 프로젝트가 있는데, 프로젝트를 진행하면서의 느꼈던, 좋았던, 나빴던 점에 대해 되돌아보고자 하는 시간을 가졌다.
(싸피 측에서 커리큘럼에 대해 외부적으로 노출되는 것을 싫어하기에, 요구사항에 대한 것과 프로젝트에 자세항 사항은 남기지 않았다.)
WHAT ? : 웹서비스 개발
WHO ? : 2명 (서버 1명, 프론트 1명)
WHEN ? : 일주일 ( 11.21 ~ 11.28 )
프로젝트를 시작하기에 앞서 기대하던 점
개인적인 이번 프로젝트 목표는 다음과 같았다.
1. 프로젝트의 성공
- 이번 프로젝트가 1학기 동안 진행하면서의 최종 결과물이기에 꼭 성공적으로 마무리 짓고 싶었다.
- 기능이 정상적으로 작동하는 것으로 끝이 아니라, Best Practice를 따르고 싶었다. 단순히 기능을 돌아가게 하는 것 뿐만 아니라, 아름다운 객체 지향적인 코드를 짜고 싶었다.
2. 팀으로서의 성공
싸피를 들어오면서 내가 가장 원했던 것은 팀 프로젝트의 경험이었기에, 팀으로서도 성공하고 싶었다. 이에 우리 팀이 일주일을 어떻게 보내야 성공하는 것인지에 대해 팀원과 이야기를 나누었다.
서로 목표에 대해 이야기를 나누었고, 프로젝트를 통하여 개개인의 개발 역량 향상을 원했다. 물론, 프로젝트를 성공적으로 마무리 짓는 것 포함이었다.
나에게는 이번 프로젝트가 프론트 개발자와의 첫 협업이라고 볼 수 있기에 경험적인 측면에서 유의미했다.
팀원이 나를 볼 때, 개발을 잘하는 동료라기 보기 보다는, 함께 개발하고 싶어하는 동료가 되고 싶었다. 내 스스로가 팀에서 개발을 잘하는 것 보다 함께 개발하고 싶은 사람이 되고 싶었기 때문이다.
3. 회고
이번 프로젝트나 팀이 성공/실패 여부와 관련없이 그 과정 속에서 좋았던 점, 잘못된 점에 대해 반성하고자 했으며 이는 나를 성장시키는 계기가 되기를 바랬다.
팀 프로젝트를 하며 기술적인 부분에서 새롭게 학습한다거나, 혹은 나의 부족했던 점들에 대해 느꼈을 것이기에 더 나은 개발자가 되기 위해 회고하며 기록하고 싶었다.
개발 시작
1. MVC 에서 서버/프론트로 전환
기존의 MVC 코드에 기능을 추가하여 개발할 수도 있었지만, 서버와 프론트 로 분리하여 밑바닥부터 다시 개발하였다.
굳이 전환한 이유는 다음과 같다.
1) 우리가 이해할 수 없는 코드
기존의 코드들은 수 많은 사람들의 손을 거친 코드이다. 그렇게 거쳐가며 점점 좋은 코드로 개선된 것이 아니라, 커리큘럼에 맞는 기술 스택으로 기능을 점점 늘려간 코드이다. 이에 내 스스로가 내가 가진 코드를 이해하기 어려웠으며, 이 코드를 팀원에게 설명하기 보다는 처음부터 짜보는게 학습 면에서나 코드 품질에서도 이득일 것이라고 생각을 했다.
2) 서버 / 프론트 분리
이왕 엎어버릴 거 서버/프론트를 분리시키기로 했다. Srping Boot로 HTTP API를 개발하고, 프론트는 Vue.js로 개발했다. 팀원은 Vue.js를 이번이 첫 프로젝트이지만, 내가 Vue.js에 대한 경험이 있어 막히는 부분은 내가 도움을 줄 수 있어서 큰 어려움이 없을 것이라 판단했다.
그렇게 기존의 기능들을 하나씩 추가하였다. 까다로운 부분이 있었다면 사용자 인증 부분이었다. 인증된 사용자를 서버에서 어떻게 처리할 지에 대한 고민이 있었다.
이는 스프링 시큐리티를 이용하여 OAuth2의 리소스 소유자 암호 자격 증명 타입으로 access token을 발급하여 해결하였다.
2. 추가 기능
1) 소셜 로그인
소셜 로그인은 내 욕심이었다. 새로운 사이트에 회원가입하는 것 보다 소셜 로그인을 제공하는 것이 사용자 유입에 이득이 있다는 이유로 팀원을 설득하려 했고, 팀원은 흔쾌히 승낙해주었다. 그런데 내가 설득시켜서 소셜 로그인을 구현했다기 보다는, 엄청 하고싶어 보여서 해준 것 같다ㅋㅋ
2) 추천 시스템
유저들이 추천하는 기능을 넣었다.
추천을 누를 수가 있는데, 이는 한명의 유저가 여러번 추천할 수 있다.
미디움 블로그의 Clab 기능 처럼..
3) 도표화
인증한 사용자의 로그를 이용하여 유의미한 그래프를 제공했다.
기존에는 유저에게 다양한 그래프를 제공하려고 하였으나 시간 관계상 한가지만 넣었다.
발표
일주일이 자니서, 팀별로 발표를 하였다.
나는 제품을 발표하면서, access token에 관련하여서도 발표했다.
듣는 사람이 다 개발자니까 결국에는 이런 기술적인 부분에도 관심이 많을 것 같았기 때문이다.
발표하기에 앞서, 각 팀에서 개발한 것들을 로컬에서 배포하였었는데, 발표를 하는 도중에 마우스를 광클하는 소리가 엄청났다. 그 이유는 우리 프로젝트의 무한적으로 할 수 있는 추천 기능 때문이었다. 서버를 뻗게 만들고 싶었는지, 자신이 추천한 제품이 1위를 하기 위한 경쟁이었는지는 알 수 없지만.. (그리고 서버는 터졌지..)
아쉬운점은 없었나 ?
많았다. ㅎ
1. 애자일
애자일을 도입하자 라고 했으나, 정작 내가 애자일에 대해 이해도가 없었던 것 같음. 우리의 개발 방식은 우선 핵심 기능에 우선순위를 정하고 하나씩 구현해 나갔으며, 그 이후 새로운 기능들을 생각하려고 했다. 애자일을 거론하기에 앞서 애자일이 무엇인지에 대한 깊은 이해도가 선행되어야 할 것 같다.
2. 함께 자라기
팀이 있었기에 기능 구현에 필요한 것들을 함께 학습하는 것에 대한 기대감이 있었다. 하지만 우리는 서버 / 백엔드 역할을 따로 맡아 분담했기에 함께 자라기가 현실적으로 어려웠다.
3. 코드 품질
서버에서의 코드 품질에 대해서도 아쉬움이 많다.
첫 번째로, RequestDTO에 비즈니스 로직이 들어있는 경우도 있었다. 소셜 로그인하는 과정에서 사용자 아이디를 소셜타입_고유번호 (ex. google_10294193561363) 으로 했었는데 소셜타입과 고유번호를 이용하여 아이디로 하겠다는 로직이 requestDto에 들어있었다. 이는 레이어간 데어터를 전달하는 dto의 책임을 벗어난 행위이다.
두 번째로는, 테스트 코드의 부재에서 오는 아쉬움이다. 처음 개발을 시작할 때는 여유가 있으면 테스트 코드를 짜야겠다고 생각했다. 하지만 주어진 시간안에 기능을 개발하는 데 많은 시간을 소모했기에 테스트 코드를 짜지 않았다.
한번은 팀원이 인증된 사용자가 사용하는 어떤 기능의 변경을 요구를 했다. 요구한 기능에 대해 개발을 마치고 end-to-end 테스트가 필요한데, 이를 팀원에게 부탁했다. 이는 프론트엔드를 개발하고 있는 팀원의 생산성에 영향을 미치는 행위일 수 밖에 없다. 그럼에도 내가 테스트 하려면 postman으로 로그인-기능 확인 하는 2단계를 거쳐야 했기에 귀찮았기 때문. 매우 무책임한 사람처럼 보이기도 하지만 팀원이 내가 기능 구현하는 것들을 기다리는 상황이었고 나는 결과를 실제 동작하는 화면으로 함께 확인해보고 싶었다는 변명을 해본다.
어쨌든 중요한 건 테스트 코드를 짰더라면 이런 기능 테스트도 쉽게 할 수가 있었다는 것이다. 만약 그때로 돌아간다면 또 안짰을 것 같지만, 아쉬움으로 남는 건 사실이다.
4. 서버 터짐
발표 도중에 서버가 뻗었다. 발표를 마치고 노트북을 봤는데 누군가의 request 로그가 매우 빠르게 찍히고 있음을 발견했다.
저녁 먹으면서 친구가 그 원인을 알려주었는데, while문 안에 서버에게 POST 요청을 하는 스크립트를 넣어 서버에게 무한정한 request Message를 보냈다고 하더라. 생각치도 못한 공격이라 처음에 듣고는 너무 당황스러웠고, 발표 도중에 터져버린 것이 너무 아쉬웠다.
5. 좋은 동료 되기
함께 개발하고 싶어하는 동료가 되고 싶었지만, 과연 좋은 동료였을까에 대한 의문이 남는다. 프로젝트를 너무 내가 하고 싶은 방향으로 흘러가지 않았나 싶다. 설령 그랬다면 내가 프로젝트에 대해 잘 알아야하고 전체적인 조율을 맡았어야 했는데 그런 부분들에 대해 신경을 못 쓴 것 같다. 함께 개발하고 싶어하는 동료라기 보다는 개발 좋아하는 동료로 밖에 안보일 것 같다. 이런 부분들은 서적을 읽고, 앞으로 더 많은 팀프로젝트를 해봐야 할 것 같다.
6. 스프링 시큐리티
소셜 로그인은 마지막 날까지 헤매었던 부분이다. Vue.js 에서 구글 OAuth 서버에서 얻은 code를 HTTP API 서버에 전송하면, HTTP API 서버가 code를 이용하여 구글 OAuth 사용자를 받아와서 로그인하게 하려고 하였으나, 마지막 날까지 해결하지 못하였다.
이에 대안으로 Vue.js에서 구글 OAuth 서버에서 받은 회원 정보들을 HTTP API 서버로 넘겨주었으나 이는 보안상 문제가 있다고 생각된다.
또한, 소셜 로그인 요청이 HTTP API 서버로 들어오면 Spring Security 에서 인증을 거친 후 AccessToken을 반납하는 것이 옳다고 생각하였으나, 실제 구현한 로직은 Controller로 로그인 정보를 받아서 RestTemplate를 이용하여 다시 자신의 서버에 요청하였다. 이는 나의 Spring Security 이해도 부족으로 인한 결과인 것 같다.
좋았던점은 ?
개발 역량 향상이 있었음을 느낀다.
팀원은 Vue.js를 이용하여 첫 프로젝트였는데 Vuex도 잘 사용하고, 컴포넌트화도 잘 나눈 것 같다. 나 또한 OAuth 에 대한 이해도를 좀 더 높일 수 있었고, TypedQuery를 이용하여 Select문을 처리하는데 있어 자신감과 역량이 향상되었다고 느낀다. 그리고 학습한 것들을 곧 까먹을 것이란 걸 알기에 정리가 꼭 필요하다.
그리고 팀원을 잘 만나서 좋았다. 프로젝트를 진행하면서 팀원이 너무 착하고 잘 맞춰준 것 같은 느낌을 받았다.
또한, 발표를 할 때 자체적으로 각 팀을 심사를 하여 반에서 우수한 팀에게 상을 줬는데 운좋게도 우리가 2등을 하게 되었다. 기대를 하지 않은 탓인지 너무 기뻤고, 일주일 간의 노력에 대한 보람을 다시 한번 느낄 수 있었다.
앞으로 해야할 것
나는 서버를 맡았고 다른 팀원은 프론트를 맡았다. 애초에 역할을 분담할 때 서버 로직에 대해 팀원에게 설명을 하면서 개발하려고 하였으나, 이 또한 시간을 핑계로 하지 않았다. 이에 서로 코드를 공유하는 시간을 가지면 좋겠다는 생각을 했다.
서비스 거부 공격으로 인하여 발표 도중에 서버가 터진 것을 대처하는 것도 숙제로 남았다. 검색해보니 특정 시간 동안 실행 횟수를 제한하는 라이브러리를 쓰면 될 것 같은데, 곧 개선해 봐야겠다.
Comments powered by Disqus.