소개

안녕하세요! 맘편한세상 제품개발팀 백엔드 개발자 김경록입니다. 지난 온보딩 회고 글을 작성한지 벌써 2개월이라는 시간이 지났네요. 이번 포스팅에서는 온보딩을 갓 마치고 TF에 편성된 신입 개발자의 첫 MVP 개발기를 담아보려고 합니다.

MVP 배경

우선 맘시터 교육사업의 배경과 프로젝트 목표에 대해서 간단히 설명해 드리고자 해요. 아이 돌봄유형에는 여러 종류가 있습니다.

1. 놀이시터
2. 등하원 시터
3. 신생아/영아 풀타임 시터
4. 신생아/영아 보조 돌봄 시터
5. 긴급/단기 시터

시터분들은 자신의 적성과 시간을 고려하여 돌봄유형을 선택하여, 구직 활동을 하게 되고 매칭이 되어 채용이 확정 된 이후에는 부모와 활동 조율을 해나가면서 아이를 돌보게 됩니다. 하지만 이런 과정을 진행하면서 시터들에게는 몇 가지 어려움이 있었습니다.

플랫폼을 통해 처음 돌봄활동을 시작하는 분들의 막막함

어떤 돌봄활동들이 있고 각 활동들은 어떻게 해야하는건지, 또 나에게 맞는 돌봄활동은 무엇인지, 스스로 파악해야하고 그 뿐만아니라 돌봄을 시작한다면 부모님과는 어떻게 소통해야 하는지, 아이에겐 어떻게 접근해야 할 지, 이 역시 초보시터에게는 심적인 장벽으로 작용합니다.

시터로서의 전문성을 갖추기 어려움

미술 전공 대학생 시터의 그림 교육, 전문 자격증을 가진 선생님의 학습 시터, 그 외에도 돌봄 경험이 있는 엄마 시터가 자신의 경험을 살려 아이를 돌보는 것처럼 이미 자신의 적성을 잘 살려 활동하는 시터분들도 있습니다.

하지만 시터들이 아이의 연령별 발달 특성이나, 성향 파악, 돌봄 방법을 학습하여 부모들과 아이들에게 전문적인 서비스를 제공하는 데는 한계가 있습니다. 그뿐만 아니라 베테랑 시터분들조차도 부모님의 니즈에 맞춘 서비스 마인드를 갖추고 시터로서 소통하는 방법을 습득하는 데 많은 어려움을 겪고 있었습니다.

기존의 아이 돌봄 교육은 교육신청자의 90% 이상이 3개월 이내 취업을 희망하지만, 다양한 돌봄 니즈를 가진 부모들의 구인조건에 맞지 않다보니 매칭이 잘 안되는 상황이었습니다. 그래서 초보 시터들과 숙련된 시터들의 니즈를 모두 만족하는 양질의 교육상품이 필요했습니다.

맘시터는 고용노동부와 연계하여 작년 7월에 구직과 돌봄 제공에 실질적인 도움을 줄 수 있는 시터 양성 교육을 시작하였습니다. 실제로 7월~12월간 교육 수료자들의 교육 성과를 파악해보니 매칭 성공율은 5배로 증가하였고, 월 소득은 160% 증가함을 확인할 수 있었습니다.

팀 내에서는 정부와 연계한 B2G 교육 사업에서 좋은 성과를 바탕으로 B2C 교육 사업도 시도해볼 만하다고 판단했습니다. 내일 배움 카드 없이도 들을 수 있는 교육 사업을 안내해드리면 시터분들의 교육 접근성을 더 확보할 수 있고 향후 맘시터 서비스와의 연계도 고려해볼 수 있어 다양한 장점이 있다고 생각했습니다. 그래서 팀에서는 B2C 교육 사업을 위해 필요한 최소 기능을 가진 MVP 모델을 개발해서 런칭하는 것을 최우선 순위로 잡게되었습니다.

그리고 이 중요한 B2C 교육 사업 MVP 모델을 풋내기 주니어 개발자🐣인 제가 개발하게 되었습니다 😱.

네???? 제가요?

물론 혼자서 A부터 Z까지 모든 것을 다 개발하는 것은 아니었지만, ‘큰 포부를 안고 시작한 신사업이 내 실수로 엎어지면 어쩌지?’라는 불안감이 생겼습니다. 무엇보다도 교육 상품을 기획하느라 고생하셨을 교육 사업팀 분들을 뵐 면목이 없을 것 같았습니다. ‘이거 정말로 내가 개발해도 되는 건가…?’라는 생각도 들었습니다.

어떻게 저를 의심하실 수 있으십니까?

피할 수 없다면 즐기라는 말이 있듯이 조금 더 책임감 있게 잘해보자는 생각으로 MVP가 뭔지 무엇인지부터 찾아보았습니다. 제가 아는 MVP는 축구, 농구와 같은 스포츠나 e-sport 경기에서 뽑는 최우수 선수의 개념밖에 몰랐기에 MVP를 개발한다는 의미가 잘 와닿지 않았습니다. 이상하다 싶어 구글링을 해보니 MVP는 Minimum Viable Product의 약자로 ‘최소한의 기능을 구현한 제품’이라는 의미가 있고 MVP를 개발하는 이유는 기능을 빠르게 개발하고 출시하여 고객의 피드백을 통해 사업을 검증하고 개선해나가며 완성도를 높여가는 데 목적이 있다는 사실도 알게 되었습니다.

MVP가 뭐죠…? 페이커인가?

진행한 작업

배경에서 언급했듯이 이번 MVP 개발은 “빠르게 만들어서 런칭해보자”가 목표였습니다. 그래서 진행전 몇가지 개발적인 의사결정을 진행했습니다.

결제는 기존 PG 사와 연동된 코드를 최대한 재활용

코틀린으로 개발된 PG 연동 코드는 본래 다른 프로젝트에서 개발되었기에, 좀 더 깔끔한 작업을 위한다면 이 연동 코드에 기능을 확장해야 하지만, 이번 프로젝트에서는 PG 결제요청 시 몇 가지 옵션만 더 추가할 수 있게만 개발하기로 했습니다.

세부 기술 관심사에 대한 공수는 최소한으로

이번 MVP 개발에 영속성을 위해서 실제 운영 DB를 활용할 수도 있겠지만 추후 교육사업 도메인은 변경 가능성이 커서 시터들이 교육 신청을 할 수 있는 교육 신청 페이지와 교육 운영팀이 신청 상황을 곧바로 조회할 수 있는 내부 어드민 페이지를 개발하는 데에 많은 공수가 들 수 있었습니다. 그래서 이번 MVP 모델에서는 구글 시트를 DB처럼 활용해보기로 했습니다.

MVP를 제공하기 위한 최소 기능만 구현

즉 사용자는 “교육 신청을 할 수 있고”, “교육에 대한 결제를 진행할 수 있다.” 이 두 가지 스토리만 이번 MVP의 범위로 삼았습니다.

요구사항 도출

MVP 모델을 빠르게 개발해야하다보니 맘시터 팀이 “정석” 으로 일하는 방식보다 간소화되고 더 빠르게 커뮤니케이션을 진행했습니다. 우선 직접 교육 사업팀과 긴밀하게 소통하여 요건을 추출한 뒤, 어떻게 기능을 개발할 것인지, 결과물이 어떤 모양일지 등에 대한 합의를 갖춰 개발 플래닝을 진행했습니다.

플래닝

어떤 작업을 시작하기 전에는 작업을 세분화하고, 누가(Who), 무엇을(What), 언제까지(When) 해야 할 지를 정하는 것이 중요합니다. 저희가 개발 작업을 본격적으로 진행하기에 앞서 가장 먼저 한 일은 작업을 작은 단위로 분리하는 것이었습니다. 저희 맘시터 제품개발팀은 개발 프로세스 관리하는데 Jira 툴을 적극적으로 활용하고 있어서 큰 이슈(= B2C 교육 사업 개발)를 하위 이슈들로 잘게 쪼개는 작업을 진행하게 되었습니다.

이것이 바로 Micro Issues…?

큰 작업을 잘게 쪼개는 대는 여러 가지 이유가 있겠지만, 제가 느낀 장점들은 다음과 같습니다.

• 이슈의 작업 분량이 적어지니 작업자의 부담을 덜 수 있다.

• PR 단위가 줄어들고, 리뷰어가 리뷰해야 하는 코드양이 줄어든다. (PR의 코드 수가 줄어듦)

• 작은 단위의 코드를 실제 운영 서버에 배포하여 테스트해볼 수 있다.

• 나의 작업이 얼마만큼 진행됐는지 다른 팀원들도 쉽게 파악할 수 있다.

큰 이슈를 하위 이슈들로 잘 분리했다면, 분리한 하위 이슈들에 대한 일정 산출한 뒤, 본격적으로 개발을 진행하면 됩니다.

설계 방향

저희가 개발하는 B2C 교육 사업은 MVP 단계이기 때문에 다음에 변경될 확률이 높았습니다. (당장 초기 MVP 모델의 DB로는 Google Sheet를 사용하고 있어서 B2C 교육 사업이 잘된다면 Google Sheet가 아니라 실제 운영 DB에 새로운 스키마를 추가해서 관리할 것으로 생각했습니다)

또한 B2C 교육 서비스가 성장함에 따라 코드의 확장성 또한 고려하여 개발해야 했고, 이런 ‘확장성’, ‘유연성’을 모두 갖춘 설계를 고민하였습니다. 그리고 해결책으로 클린 아키텍처에서 언급하는 ‘헥사고날 아키텍처’를 도입하였습니다.

헥사고날 아키텍처(= 포트-어댑터 패턴)

출처: Hexagonal Architecture with Java and Spring

헥사고날 아키텍처 스타일에서 사용되는 주 요소들을 간략히 소개하자면

• Domain Objects: 도메인 객체는 응용 프로그램의 다른 계층에 의존하지 않으므로 다른 계층의 변경 사항이 도메인 객체에 영향을 미치지 않습니다. 즉, 다른 계층에 종속되지 않고 독립적으로 발전할 수 있습니다. 도메인 개체는 비즈니스 요구 사항이 변경되는 경우에만 변경될 수 있습니다. (SRP 원칙을 만족함)

• Use Case: 유스 케이스는 특정 유스 케이스와 관련된 모든 것을 처리하는 클래스입니다. 도메인 개체와 유사하게 유스 케이스 클래스는 외부 구성 요소에 대한 종속성이 없습니다. 만약 도메인 모델, 유스케이스와 같은 애플리케이션 코어가 아닌 외부의 관심사(=기술적인 관심사)는 출력 포트에 의존합니다.

• Port: 도메인 객체와 유스 케이스는 육각형 내(= 애플리케이션의 핵심 내)에 있고 외부와의 모든 통신은 전용 ‘포트’를 통해 이루어집니다. 입력/출력 포트가 있으면, 데이터가 시스템에 들어오고 나가는 위치가 명확하므로 아키텍처를 쉽게 파악할 수 있습니다.

  • Input Port: 외부 구성 요소에서 호출할 수 있고 유스 케이스에 의해 구현되는 간단한 인터페이스입니다. 이러한 입력 포트를 호출하는 구성 요소를 입력 어댑터라고 합니다.
  • Output Port: 외부에서 무언가가 필요한 경우(예: 데이터베이스 액세스), 유스 케이스에서 호출할 수 있는 간단한 인터페이스입니다. 이 인터페이스는 유스 케이스의 요구 사항에 맞게 설계되었지만, 출력 어댑터라고 하는 외부 구성 요소에 의해 구현됩니다.

• Adapters: 어댑터는 육각형 아키텍처의 외부 레이어를 형성합니다. 그것들은 코어의 일부가 아니지만, 그것과 상호작용합니다. 어댑터를 사용하면 응용 프로그램의 특정 계층을 쉽게 변경할 수 있습니다.

  • Input Adapter: 입력 포트를 호출하여 작업을 수행 ex) 웹 인터페이스
  • Output Adapter: 유스 케이스에 따라 호출된다. ex) DB

저희는 도메인 객체들과 Use Case, Port를 설계하고 정립하는 작업은 짝 프로그래밍하며 서로의 생각을 일치시키며 작업했고, 각 포트 및 Use Case의 구현체인 Adapter를 구현하는 작업은 개별로 작업한 뒤, 코드 리뷰를 통해서 작업한 내용을 팔로우해나갔습니다. 이렇게 헥사고날 아키텍처를 도입함으로써 추후 구글 시트가 아닌 B2C 교육 사업의 데이터가 실제 운영 DB를 사용해서 운영하게 된다면 지금은 Google Sheet를 사용하도록 구현한 Adapter를 실제 운영 DB에 영속화(ex. JPA를 사용)되는 Adapter로 변경한다면 손쉽게 확장할 수 있습니다.

헥사고날 아키텍처를 도입함으로써 느꼈던 장점은 핵심 도메인 로직을 외부에 의존하지 않게 완전히 분리할 수 있어 기술적인 관심사를 미뤄두고 오직 도메인 로직을 짜는 데에 집중할 수 있다는 점입니다. 그 덕분에 도메인 설계도 어느 정도 만족할만한 수준으로 했었다고 생각합니다.

또 다른 장점은 같이 페어 프로그래밍을 하면 좋은 작업과 따로 하면 좋은 작업이 쉽게 분리된다는 점이었습니다. 페어 프로그래밍의 장점은 많은 개발자가 알고 있으리라 생각합니다. 하지만 페어 프로그래밍은 혼자서 프로그래밍하는 것보다도 더 많은 시간과 체력을 소비합니다. 시간이 넉넉하다면 모든 작업을 페어 프로그래밍할 수도 있겠지만 아쉽게도 시간이 그리 많은 상황은 아니었습니다. 하지만 다행히도 헥사고날 아키텍처를 적용하게 되면 페어 프로그래밍하면 좋은 작업과 그렇지 않은 작업이 쉽게 파악이 된다고 생각됩니다. 페어로 작업하기 좋은 부분은 Adapters를 제외한 요소들이고 개별로 작업하기 좋은 부분은 Adapters 쪽입니다. 그 이유는 Domain Objects, Port, Use Case는 핵심 비즈니스 로직을 다루기 때문에 페어와 의견을 일치시켜야 하고 개별로 작업하게 되면 서로의 작업이 서로에게 영향을 미칠 수도 있습니다. 따라서 작업이 끝난 이후에 또다시 두 작업을 통합하는 불필요한 작업이 필요할 수도 있습니다. 따라서 이 세 가지 요소는 페어 프로그래밍을 하는 것이 더 효율적이라고 느껴졌고 반면에 Adapter는 Port, Use Case와 같은 Interface를 구현한 구현체이기 때문에 개별로 작업을 하더라도 문제 될 부분이 없습니다.

마치며

저의 짧은 개발 경력에서 당연하게도 MVP 개발은 처음이었기에 ‘최소한의 기능이니 금방 만들겠지?’라는 예상과 달리 MVP 개발이라서 고민해야 할 요소도 만만치 않았습니다. 개발에 관련된 기획은 하나도 이뤄진 게 없었기 때문에 ‘어떤 데이터’를 받아서 ‘어떻게 처리’하고 ‘어떤 정보를 저장’할 것인가? 모두 고민해야 했고, 이 모든 개발 기획은 비즈니스의 특성을 고려해서 진행해야 했습니다. 심지어 비즈니스의 세부 사항은 언제든지 변경될 수 있다는 사실도 염두에 둬서 개발해야 했습니다.

개발 외적으로 걸리는 시간이 많아 정해진 기한 안에 MVP 모델을 완성할 수 있을지 걱정이 되었지만, 비즈니스에 대한 이해도가 점차 늘어나면서 막상 코드를 짜는 순간에는 막힘없이 술술 개발을 해나갈 수 있었습니다. 비즈니스에 대한 이해도가 중요하다는 사실을 다시 한번 몸소 깨닫게 된 소중한 경험이었습니다. 그리고 무엇보다도 맘시터의 서비스에 기여했다는 점이 뿌듯했습니다.

아이언맨 MVP(= 마크1)

물론 아쉬운 점도 있었습니다. MVP 개발의 특성상 빠르게 비즈니스 임팩트를 내야 하다 보니 코드를 이쁘게 짜야 한다는 개발자의 불문율과도 같은 금기를 깨트리며 코드를 작성하는 때도 많았습니다. 내가 작성한 코드가 곧 레거시 코드라고 생각하니 마음이 마냥 편치 않았습니다. B2C 교육 사업 출시 이후에도 후속 작업으로 Clean Up을 진행할 수 있었고 그 덕분에 조금이나마 만족할만한 코드 퀄리티를 챙겼다고 생각합니다. 이번 프로젝트를 통해서 비즈니스 임팩트를 빠르게 챙기면서도 좋은 코드, 좋은 설계를 해나가기 위해서는 많은 경험과 꾸준한 공부만이 답이라고 느꼈고 앞으로 더 부지런히 학습해야겠다는 다짐을 하는 계기가 되었습니다.

이제부터가 시작이겠죠?
한 발짝 한 발짝 맘시터 서비스를 발전시켜나가고 더 나아가 아이 돌봄 생태계 활성화를 위해 노력하는 개발자가 되겠습니다.

긴 글 읽어주셔서 감사합니다!