5차 데모데이 회고

 

짧았던 일주일 간의 방학이 끝나고 레벨 4가 시작이 되었다

레벨 4 부터는 강의와 미션이 추가되기 때문에 프로젝트에 좀 소홀해질수밖에 없다는 이야기를 들었다.

그래서 스프린트 미팅때 각자 프로젝트, 미션, 개인 공부의 비율을 어떻게 가져갈지 논의하는 시간을 가졌다. 다들 생각이 비슷비슷했는데 아무래도 우리의 포트폴리오 중에 가장 중점이 되는 부분이 프로젝트일 것이기에, 프로젝트의 완성도를 높이고 실제 사용자를 유치하고 싶어했다. 그래서 다들 평균 40 정도는 프로젝트에 투자하는 방향으로 의견을 냈고, 우테코가 끝나고나서도 취준을 하지 않고 학교로 돌아가는 크루들은 유지보수를 계속해서 하기로 했다 (취준 하는 크루들도 여력이 닿으면 하는걸로. 서버비는 그때가서 생각!)

 

이번 데모데이에서 가장 중요 이슈였던 것은 2가지였다! 

1. 데이터베이스 스키마 바꾸기 2. 사용자 유치

데이터베이스 스키마 바꾸기

스탬프크러쉬의 핵심 가치인 고객의 편리한 적립을 위해 우리는 서비스에 가입하지 않은 고객이더라도 전화번호의 입력만으로 임시 고객으로 가입을 시켜주는 기능을 구현해놨다. 그리고 이번 데모데이 스프린트때는 임시 고객이 카카오 로그인을 했을 때 기존 적립 정보를 연동을 시켜주는 기능을 구현해야 했다.

 

그런데 임시 고객 <-> 가입 고객의 데이터 연동을 구현하다보니 문제가 생겼다. 

 

기존 테이블 구조

기존의 테이블 구조는 임시 고객과 가입 고객이 Customer 테이블을 상속받도록 구현했었다. (상속관계 매핑 - JOIN 전략) 사유는 TEMPORARY_CUSTOMER 에는 login_id, password 등의 컬럼값이 들어가지 않는데 통합해서 만들어두면 NULL 값이 데이터베이스에 들어갈 수 밖에 없기 때문이었다.

 

그런데 임시 고객을 가입 고객으로 전환하려다보니 Customer 의 dtype 을 변경해줘야 하는 문제가 생겼는데 dtype 은 엔티티에서 따로 필드로 존재하는 것이 아니라 @DiscriminatorColumn(name = "dtype") 의 어노테이션을 사용해 JPA 서 구현되기 때문에 코드상으로 dtype 을 바꿔줄 방법이 없었다. 극단적 생각으로 네이티브 쿼리로 update 를 시키면 값이 변경되는 것을 확인했다. 하지만 기존 사용하던 엔티티를 변경하기 싫다는 이유로 코드상에 갑자기 네이티브 쿼리가 들어가게 된다면 유지보수성에 최악이고 앞으로 다른 문제가 생겼을때 더 대응하기 어려울 것이라는 것에 팀원들 모두가 합의를 했다. 그래서 Customer 테이블을 합치고 enum 값으로 임시 고객과 가입 고객을 구분하도록 코드를 수정했다.

 

엔티티를 바꾸면 데이터베이스 스키마도 변경이 되어야 하기 때문에 이를 어떻게 처리할까 고민을 하다가 데이터베이스 형상관리 툴인 Flyway 를 도입했다. 사실 이전까진 데이터베이스 형상관리가 왜 필요한지 몰랐었는데 프로젝트를 진행하면서 스키마가 변경되는 일을 종종 겪다보니 버전별로 DDL 형상관리를 해주는 Flyway 의 사용에 대해 필요성을 느꼈고 적용하게 되었다.

 

그리고 자바 코드를 배포, 데이터베이스의 스키마 변경 의 2가지 작업을 해주었어야 했는데 둘 중 어떤 작업을 먼저 진행해도 JdbcException 에러가 발생할 수 밖에 없었다. 개발 서버에는 먼저 자바 코드를 머지를 해버려서 에러가 나는 상태로 데이터베이스 스키마를 바꾸어주었다. 그런데 운영서버에는 이렇게 하면 안될거라는 생각에 토미에게 조언을 구했다. 토미의 조언으로 두 작업을 한번에 진행해선 안되고 중간에 복잡한 절차들이 많다는 것을 들었고 토미가 실무해서 했었던 방법을 들었다. 간단히 요약하자면 변경될 구조의 테이블을 추가로 생성하고 마이그레이션 작업을 한 뒤 변경할 테이블과 변경될 테이블 둘 다에 CRD 작업을 동시에 하는 WAS 를 무중단 배포하고, 변경할 테이블과 변경 후 테이블의 DB 데이터 정보가 동일하게 맞았다고 확신되면 변경될 테이블에만 CRD 작업을 하는 WAS 를 무중단 배포하는 방식이었다. 이를 이번에 적용해봤으면 좋았겠지만 아직 무중단 배포 플로우가 되어있지 않아서 무중단 배포를 학습하고 진행해보면 좋겠다고 팀원들과 이야기를 했다. (우리 서비스에 테이블 변경할 사항 또 있음)

 

사용자 유치

사실 이번 스프린트에서 코치들이 가장 중요하게 봤던 부분일 것 같다. 사실 우리 서비스는 고객이 실제 카페 사장님이기 때문에 생계가 얽혀있는거라 사용자 유치계획을 짤때 걱정이 많았다.

온라인으로 할 수 있는 영업으로는 네이버 카페 영업, 인스타그램 DM 등이 있었고 카드 뉴스도 제작을 했다!

 

하지만 온라인에서는 성과가 미미했고 기획자인 라잇이 카페 영업에 성공해서 고객이 생겼다!!!!

(기획부장이자 영업부장 라잇.... 최고👏👏👏👏👏👏👏👏👏👏)

지금은 카페 대표님과 한번 미팅을 마치고 피드백을 반영하는 중인데 다들 실제 고객이 생겨서 그런지 더 열정있게 프로젝트를 진행하고 있는것 같아서 기분이 좋다

데모데이 발표

데모데이 발표를 하고 코치들에게 칭찬만 받은 거 같다. 사유는 라잇의 영업 성공 + 깃짱과 하디의 시연 (카페 사장 - 고객 시뮬레이션) 이다.

사실 시연도 나랑 윤생이 했었어야 하는데 내가 시연할 생각에 너무 힘들어서 점심에 체했더니 깃짱이 하디랑 해주겠다고 말을 해줬다. 정말 감동받았다.... 진짜 잘했는데 우리팀만 발표를 봐서 좀 아쉬웠다! 그래서 유투브에 데모데이 영상 올릴지 말지 투표가 올라와 바로 찬성표를 던져주었다. 

 

5차 데모데이까지 잘 마쳐서 다행이다. 특히 고객이 유치가 되니 진짜 운영서버를 소중히 다루어야겠고 책임감도 생긴다. 

추석 연휴까지는 피드백 받은거 반영 다하고 연휴가 끝나고부터 실 사용이 시작되는데 이슈 없이 잘 사용이 되고 실제 고객의 피드백을 받는 경험을 더 쌓았으면 한다.