우테코/피드줍줍 2차 데모데이 회고

정말 빠르게 2주가 지나갔다. 

 

2차 데모데이의 요구사항은 다음과 같았다.

 

우리가 생각한 프로젝트의 핵심가치는 특정 공간에서 불편한 점이 있다면, 관리자에게 간편하게 건의하기였다. 사용자는 본인의 불편함을 해소할 수 있으니 만족감을 느낄 것이고, 관리자는 손님의 목소리를 들을 수 있으니 둘 다 만족감을 느낄 수 있다고 생각했다. 

 

플로우는 다음과 같다.

 

case 1)

- 사람들이 불편사항을 건의한다.

- 건의사항이 등록되면, 관리자에게 알람이 간다.

 

case 2)

- 불편사항에 대해 특정 공감횟수를 넘으면 관리자에게 알람이 간다.

 

해당 핵심가치에서 반드시 필요한 도메인 모델은 피드백과 좋아요 라고 생각했다. 내가 생각했을 때는 해당 도메인 모델을 구현한 이후에 추가적인 기능을 구현하는 플로우가 자연스럽다고 생각했다.

 

2차 요구사항은 그렇게 어렵진 않았다. 나를 제외한 피드줍줍의 백엔드 팀원들은 뛰어난 개발 실력을 가지고 있다. 2차 요구사항에 명시되어 있는 CI/CD 파이프라인을 팀원 전부 다 경험해 봤고, 구현하는 데 그리 오래 걸리지 않을 것 같았다. 그래서였을까? 주어진 테스크가 너무 작고, 시간이 많이 남을 것 같아 핵심 기능 외의 추가 기능개발을 하기로 결정했었다.

 

- 카테고리에 대한 CRUD

- 관리자 회원가입, 로그인

- 장소 생성

 

현 시점에서 반드시 필요한 핵심 기능은 아니었지만, 시간이 남아 1차 스프린트에서 개발하기로 한 목록들이었다.

 

코치님들에게 항상 듣던 말이 있었다.

1차 때 회원가입, 로그인 이런 기능 구현하지 마세요. 팀에서 생각하는 핵심 기능만 구현하는 걸 목표로 해봐요.

 

하지만 기능 구현을 안 하자니, 2차 데모까지 시간이 너무 많이 남을 것 같았다. 지금 당장 필요한 기능들은 아니라고 생각했지만, 팀원들에게 내 의견을 말하지는 않았다. 시간이 남는데 미리 구현해서 나쁠 것 없지 않냐 라는 의견을 받으면, 할 말이 없어지기 때문이었다.

 

이에 대해 고민을 하고 있던 찰나, 레벨1 같은 조였던 돔푸가 젠슨네 팀은 뭐 만드냐고 물어봤다. 기능 설명을 하면서, 추가로 내가 하고 있던 고민을 돔푸에게 이야기했다. "핵심 도메인만 구현하고 싶은데, 시간이 남을 것 같아 다른 것들도 구현하기로 했다. 그런데 다른 기능들이 지금 당장은 불필요해 보이는데, 구현하는 게 맞는지 모르겠다."

 

내 고민을 듣고, 돔푸는 "꼭 데모데이에 초점을 맞춰야하나요?" 라는 새로운 관점을 제시해 줬다. 전혀 생각을 못 해봤는데, 내가 하고 있는 고민의 해결책이 될 수 있겠다 생각했다.

---

Agile을 제시하다

데모데이에 초점을 맞추어 핵심 기능만 개발하면 시간이 남지만, 빠르게 핵심 개발만 개발하고 운영하라고 한다면 이야기가 달라진다. 

 

지금까지 내가 한 고민들을 팀원들에게 공유했다. 그리고 해결책으로 '핵심 기능만 빠르게 개발한 이후에 유저 피드백을 받자'를 제시했다. 즉, 팀원들에게 기존 데모데이에 초점을 맞추는 것이 아닌, Agile을 도입하자고 말했다. 그리고 데모데이를 따라가는 게 아닌, 빠르게 만들고 배포했을 때의 장점을 말했다.

• 유저의 피드백을 빠르게 받아볼 수 있다.
• 특정 아이디어에 대해 의견이 달린다면, 우선 실행해보고 유저 피드백을 토대로 개선할 수 있다.
• 필요한 핵심 기능만 빠르게 개발할 수 있다.

 

내 의견에 대해 백엔드 팀원들은 긍정적으로 생각할 것 같았다. 결국 근본적인 문제는 시간이 남아서 추가 기능 개발하기였고, 실제 운영 환경을 구축해야 한다면 할 일이 상당히 많기 때문이었다. 백엔드 팀원들은 긍정적으로 내 의견을 수용해 줬다. 프론트 팀원들은 너무 급하게 하는 건 좋지 않지만, 핵심 기능만 빠르게 개발하자는 의견에 동의해 줬다. 작업해야 하는 테스크가 많아져 팀원들이 부정적으로 받아들일 수도 있겠다 생각했었지만, 내 의견을 잘 수용해 줘서 너무 고마웠다.

---

Agile을 위한 빠른 개발/운영 서버 환경 구축

 

운영 서버 구축은 4차 데모데이의 요구사항이다.

 

하지만 유저의 빠른 피드백을 받기 위해서는 개발 환경이 아닌, 실제 운영 환경을 배포해야 한다. 그래서 보다 빠르게 2차 데모데이에서 개발환경과 운영환경 아키텍처를 구축했다.

왜 개발환경과 운영환경을 분리해야돼?

 

알람 기능을 개발했다고 가정해 보자. 서버 측에서 아무리 코드상의 테스트를 꼼꼼하게 짜도, 실제 개발 동작을 확인하는 과정은 반드시 필요하다. 만약 개발서버와 운영서버를 하나로 사용하고 있다면, QA과정을 운영서버에서 진행해야 할 것이다.

 

QA 과정에서 알람 기능에 버그가 발생한다면?? 그 버그가 운영 환경에도 그대로 전파가 되고, 이는 곧 서비스의 신뢰도 하락으로 이어질 가능성이 높다. 이러한 문제를 방지하기 위해 개발환경과 운영환경은 반드시 분리되어야 한다. 개발환경에서는 자유롭게 테스트하고, 실제 운영과 비슷한 조건에서 사전 검증을 할 수 있다. 이후 문제가 없다고 판단된 코드만 운영환경으로 배포하는 것이 안전한 프로세스다.

---

개발/운영 서버 환경 아키텍처 소개

 

아키텍처를 보면 몇 가지 특이한 점이 있다.

 

1) Load Balancer 대신 사용한 Nginx

2) AWS RDS가 아닌, EC2 인스턴스 내부에 설치되어 있는 MySQL

3) 하나의 EC2 인스턴스 안에 띄워져 있는 spring, mysql 

 

위의 그림으로 아키텍처를 설명한 이유에 대해 설명하려고 한다.

 

Load Balacer 대신 사용한 Nginx

 

초반에는 Load Balancer 도입을 고려했었지만, 현시점에서는 필요 없다고 생각했다. 이유는 다음과 같다.

• 운영 초기에는 사용자가 별로 없을 것이다. 하나의 운영 서버로 충분히 감당 가능하다. 즉, Load Balancer의 핵심인 트래픽을 분산시킬 상황이 나오지도 않아 불필요한 기술 도입이라 생각했다. 또 해당 기술은 충분히 Nginx로 감당이 가능하다.
• 서버 비용은 50$로 한정되어 있다. 추후에 어느 기술을 도입할지 모르기 때문에, 우선 최소한의 비용으로 아키텍처를 설계하기로 결정했다.

AWS RDS가 아닌, EC2 인스턴스 내부에 설치되어 있는 MySQL

• 비용 문제가 제일 컸다.
• 실제 운영 환경에서 유의미한 데이터가 많이 쌓인다면, 데이터의 안정성을 위해 AWS RDS로 이전을 고려할 것 같다.

 

하나의 EC2 인스턴스 안에 띄워져 있는 spring, mysql 

• 해당 EC2 인스턴스는 개발서버다.
• 개발서버에서 굳이 WAS와 DB를 나눌 필요가 없다고 생각했다. 물론 나누면 좋지만, 최소한의 비용으로 운영환경을 구축하는 것을 1차 목표로 삼았기에, 나누지 않았다.

정말 최소한으로 잘 구축했다고 생각한다. private subnet에 접근하기 위해 bastion ec2도 하나 띄워놔야 하는데, 코치님을 설득해 SSM을 도입을 해 추가로 비용을 절약했다.

 

우선은 해당 아키텍처로 비용을 추적해보려고 한다. 돈이 많이 남는다면, AWS RDS 도입을 우선시할 것 같다.

 

(Nginx는 nano, 나머지 서버들은 micro로 띄워놨다)

 

+참고

NAT Gateway가 비용이 많이 들어 Nat Instance 도입을 고려하고 있었지만, 우테코에서 NAT Gateaway를 제공해주고 있었다. 즉 서버비 50$에서 Nat Gateway 비용은 포함되지 않는다. 

---

4차 데모데이 때까지 하면 될 태스크를 2차 데모에 끝내니 힘들긴 했다. 하지만, 팀의 방향성과 목표를 위해서는 꼭 필요한 작업이었다...!

 

애자일을 할 수 있는 환경이 구성되었으니, 실행할 시간이다. 화요일에 우리 프로젝트를 크루들이 사용할 수 있도록 선릉과 잠실 캠퍼스에 QR 코드를 부착할 생각이다. 앞으로는 3차, 4차 데모에 초점을 맞추는 것이 아니라, 우리들의 정의한 스프린트에 초점을 맞출 생각이다. 하나의 스프린트 단위를 정해놓고 그에 맞게 개발을 끝내고 배포하고,  빠르게 유저의 피드백을 받으며 개선해 나가려고 한다.