간호대 외주 후기

0. 건너뛰어도 되는 배경 설명

2016년 3월, 과 후배의 소개로 학교의 간호대학에서 안드로이드 앱 외주를 진행했었다. 이 때 백엔드 친구 / iOS 친구 / 안드로이드 나, 이렇게 셋 이서 첫 미팅을 진행했었다. 미팅을 끝내니 iOS 개발은 원하지 않으신다고. 다음 미팅에 백엔드 친구와 나만 참여했다. 왜 한 명 비냐고 여쭤보시기에 iOS 담당하던 친구라서 빠졌다고 설명드리니 약간 서글퍼하셨다. (iOS를 할 껄 그랬나…)

2017년 11월. 작년에 외주했었던 그 연구실에서 연락이 왔다. 옆 연구실 교수님이 이번에 연구 주제에 어플리케이션이 들어가는데 혹시 소개시켜드려도 되냐고. 흔쾌히 승락하고 12월에 개발미팅을 시작했다.


1. 간호대(?)의 특성

내가 두 번의 간호대 외주를 하면서 느낀 간호대의 특징을 설명한다. 아마, 간호대 뿐만이 아닌 개발과 직접적으로 연관없는 모든 범주의 클라이언트는 비슷한 특성을 가지고 있을거라 생각하지만, 내가 경험한 비-개발 클라이언트는 간호대가 유일하다. 이와 같은 이유로 이 절의 제목으로 간호대의 특성으로 하는 것을 양해바람.

a. 예쁜 디자인 << 낮은 단가

이 분들이 “나”에게 외주를 맡긴 이유는 굉장히 간단하다. 연구를 위해. 팬시한 디자인은 필요없다. 이미 환자를 쓸 수 있게 할 권력(?)이 있으니까. 물론 이건 간호대를 떠나서 모든 교수들은 그런 권력이 있다는게 함정.

각설하고, 예쁜 디자인을 싫어하는 것은 아니다. 하지만 둘 중에 고르라면 싼 가격을 원한다. 그 점에서 내가 기존의 외주 업체들을 비벼볼 수 있는 여지가 생긴다. 내가 이 외주에 조인하게된 것을 생각해보자. 지인의 소개라는 이유도 믿음직해서라면, 거짓말까지는 아니지만 조금 설명이 부족하다. 앱, 백엔드, 어드민까지 기능적으로 문제가 없으면서, 싸고, 적당히 믿을만한 개발자라서가 아닐까.

b. 방법을 모르는 상태

방법을 알았으면 당연히 외주를 찾아보지 않았을 것이다. 하지만 이 모르는 정도는 생각보다 심각했다. 개발 프로세스를 모르고 구조를 모르면 커뮤니케이션 비용이 증가한다. 다음은 내가 겪은 그런 커뮤니케이션의 한 예다.

  • A: “서버는 AWS를 사용하면 될까요? 아니면 간호대학의 공용 서버가 있나요?”
  • B: “앱 개발하는데 서버가 필요한가요?”
  • A: “로그를 모아서 보려면… 필요하죠”

그 외에 (위에서 이미 언급했던) iOS와 Android의 개발이 다르다는 것. 앱 스토어 계정 등록에 비용이 발생된다는 것. 외주 시세를 나 본인에게 물어본다는 점. 개발 프로세스를 어떻게 잡을지. 3주만에 앱이 나오냐는 질문 등이 있었다.

c. 가까움

같은 학교의 단과대였다. 열심히 산 타서 학관-채플-음대-치대를 지나면 간호대학이 나온다. 걸어서 15분. 부담없이 점심시간에 만나서 미팅도 가능했고 6시 이후에도 미팅을 잡는 게 쉬웠다. 그 외에도 연구자 등록번호라든가, 같은 학교라서 행정적인 일 처리가 수월했다든가, 동문이라서 이런 저런 편의를 서로 봐주는 훈훈함이 있다든가. 매번 맛있는 밥을 얻어먹었다든가…


2. 선택한 스택과 그 이유

a. 개발 산출물

이미 언급했지만, 내 깃랩에 3가지 레포가 새로 생겼다. 앱, 백엔드, 어드민. 앱은 환자의 활동들을 쉽게 기록하기 위해, 백엔드는 그 기록을 데이터베이스에 저장하기 위해, 마지막으로 어드민은 데이터베이스에 저장된 환자와 로그를 관리하기 위해 만들었다.  각각 선택한 스택을 살펴보자.

b. 앱

  • Ionic: 별로 다른 선택지가 없었다. 다시 자바로 Android를 짤 용기도 없었고, 코틀린을 배울 생각도 없었다. React를 잘 하니 React Native도 물망에 올랐었지만, 이 때가 아니면 또 언제 TypeScript를 써보겠냐며 Angular기반의 ionic을 선택했다. 참고로 Ionic은 angular.js 기반일 때부터 잘 써오던 프레임워크라서 러닝커브도 작을 것이라 생각했었다.
  • Angular: 그리고 그 러닝커브는 생각보다 험난했는데 이건 모두 Angular 때문이다. 게다가 새로운 Ecosystem에 들어갔을 때 가장 큰 문제점인, 이게 어디를 모르는 건지 <- 조차 모르는 상태로 더욱 더 미궁에 빠졌던 것 같다. 돌이켜 생각해보면 의외로 TypeScript는 적응하기 힘들지 않았다는게 함정. 대부분의 역경은 Angular로부터 기인했다.
  • Redux: 왜 mobx를 쓰지 않았냐고? 이게 외주였기 때문이다. 생각보다 Angular에서 잡아먹힌 러닝타임 때문에 더 추가적인 학습을 하면서 느긋하게 진행할 수가 없는 상황이 왔었다. 여기서 무리하게 mobx를 선택하지 않았음이 백 번 천 번 옳았다. (고 생각하고 싶다.)
        이전에 써본 경험이 있었고, 내 사고 방식도 mobx에 익숙해지는 것 까지 기다릴 수 없을 것 같았다. 이에 대한 경험은 여기에 정리해놨으니 궁금하신 분들은 참고. 여담으로 진짜 열심히 써서 영어로 번역까지 해놨는데, 오히려 번역 후 더 유입이 줄어들었다. 앞으로 번역해서 포스팅을 업데이트 하는 일은 없을 듯.
  • Redux Saga: 요약하자면, Favorite Side-Effect handler for Redux
  • Echarts: 환자 로그 데이터를 시각화하는데 사용했다. 여기서 찾지 못하는 그래프나 다이어그램이 있다면 그냥 처음부터 포기하는 것을 추천.

c. 어드민

  • Vue: 이 때는 아직 Vue에 더 젖고 싶은 타이밍이였다. 한창 element-ui를 열심히 쓸 때기도 했고, 직전에 Vue + Bootstrap4로 flurry라는 웹앱도 막 만들어봤던 차에 element-ui를 연구실에서 써보고 홀딱 반해렸다. 연구실에서 만들던 서비스도 (완만한 러닝커브 덕에) Vue를 쓰고 있었으니, 적당히 설정같은 것들을 가져와서 간단하게 만들었다.
  • element-ui: React에서 유명한 antd를 Vue에서 만든 구현체. 좋다.
  • axios, moment, webpack, javascript: 다들 쓰는 axios, moment, webpack을 사용했다. 여기서까지 TypeScript를 쓰면 역시나 기한을 맞추지 못할 것 같아서 + 연구실에서 사용하던 설정은 JS이기 때문에 JS를 그대로 사용했다.

d. 백엔드

  • node + express + javascript: 역시나 여기서도 TypeScript를 사용하지 않은 이유는 상동. 다만, koa를 써보지 못한 것이 아쉬워서 이후 프로젝트에서는 모두 koa를 사용하고 있다.
  • jwt: 무난한 인증 토큰
  • nodemon: live reload는 개발의 축복
  • mariadb + sequelize: 모아진 로그 데이터를 추후에 export 할 예정이였으니 굳이 NoSQL을 선택할 이유가 없었다. 이러니 저러니 해도 나름 데이터베이스 연구실 석사로 (엣-헴) SQL이 편하기도 하고.

사실 어드민이나 백엔드는 크게 중요하지가 않았다. 백엔드도 형태나 호칭만 달랐지 거의 게시판 만들기 급의 난이도였고, 어드민도 단순히 유저를 추가하거나 유저의 로그들을 검색, 통계보기 정도였으니까. 그래서 초기에 Redux 등의 설정을 한 것을 제외하면 대부분 Angular와 Ionic과의 싸움, 특히 스크린을 따면서 시간을 보냈던 것 같다.


3. 디자인

“필요 없었다! 레이아웃과 스토리보드는 모두 내가 정했다!!”…라고 자랑하기에는 워낙 별 것 없는 스펙이였다. 참고할 다른 앱들도 많았고, 이전에 개발했던 앱 화면 구성과 크게 달라지는 것 없이 진행할 수 있었다. 다만, 아무래도 간호대 분들이 갑이니 내가 너무 딱딱 정해서 자 이렇게 하겠습니다요~ 해버리면 서로 머쓱질 것 같았다. 적당히 1안과 2안을 준비해서 1안과 2안의 비교우위를 설명하고 개인적으로는 이것이 이런 이유로 더 적합하지 않을까 (심미성, 사용성, 개발용이성 등) 로 설득하면 대부분 따라와주셨다. 물론, 내가 생각하지 못했던 사용 흐름에서는 1안이 별로일 수도 있겠다며 2안을 선택한 경우도 있었지만!

그럼 남는 디자인적 요소는 아이콘 및 간단한 일러스트류였다. 대충 지금 기억나는 요소들로는 초기 앱 실행시 보여지는 슬라이드에 들어갈 이미지들, 메뉴들 아이콘, 별자리 보드(이후에 더 자세히 설명한다) 등이 있었다. 팔은 안으로 굽는다고, 과의 후배이자 선배인 친구(?)에게 부탁했다. 학부는 후배였는데 내가 2년 휴학하면서 석사는 선배가 되어버린 동갑내기 친구인데, 이전에 출판 디자인도 했었다며 간호대 미팅에서 추천을 했었고, 출판 디자인을 했었다는 소식에 친구는 그 자리에서 다른 외주까지 받아낸 것은 비밀. 아, 역시 세상은 학연과 지연이다.

본론으로 돌아와서, 우리 쪽에서 Primary Color를 정했다. 이전에 작업했던 B형 간염에는 나름 메이저(?)한 질병이라 특화된 에방 캠패인 색깔인 민트색이 있었는데 여기는 또 그런 색깔은 없어서, 친구가 좋아하는 색으로 갔던 것 같다.

별자리 보드를 설명하자. 환자들의 연령대가 어렸다. 아이들의 지속적인 참여를 위해 하루에 기록해야하는 유형의 로그들을 모두 작성한 경우 별자리 보드에 해당 날짜의 별이 회색에서 노란색으로 바뀌는 별자리 보드를 만들었다. 28, 29, 30, 31일의 배경 보드를 만들고, 하나의 노란색 별만 불러와서 적당히 위치를 맞춰줄까 했었다. 하지만, 이 삐뚤뺴뚤한 별자리를 31번 재조정할 (=노가다) 자신이 없었다. 친구도 개발자니 이해해주었고, 같은 크기의 4개의 배경 보드와 31개의 노랑별 이미지를 겹쳐서 렌더링 하는 방식을 취했다. 이게 시간을 더 절약할 것 같아서!

여담으로 아이들이 잠자기 전에 항상 별자리 보드만 보다가 잠든다는 소식을 듣고 매우 훈훈해졌다. 훈–훈


마무리

  1. 가까워서 정말 좋았다.
  2. TypeScript에 빠져버렸다. (<< 가장 중요)
  3. Input 시간 대비 Output에 매우 만족했다.
  4. 아이들이 잘 써줘서 행복도 +1 사회 공헌도 +1가 된 느낌.
  5. 본격적인 퀄리티를 뽑으려면 Ionic으로는 조금 무리가 있지 않을까. 이런 간단한 외주가 아니고 내가 앱을 개발해야하는 상황이면 다음 스택은 React Native로 개발하고 싶다.

Leave a Reply