생각하고 선택하자
소마 시작 전부터 내가 정말 원하던 것 중 하나는 '생각하고 개발하기'였다. Expert님께서 어떤 것이 소마를 하면서 가장 걱정이 되냐고 물으실 때는 '예전처럼 개발할까봐' 즉, 설명할 수 없는 코드를 짜고, '커뮤니티가 크다'는 것이 유일한 이유가 되는 선택을 하는 것이었다.
그래서 나는 소마 기간 동안 내가 선택하는 것에 대해 나름의 이유를 다 붙여보려고 한다. 그 마음가짐으로 첫번째 스프린트에서 내가 결정한 것에 대해 아래에 적어본다.
휴대폰 진동 라이브러리
스토리 : 사용자는 타이머를 사용한다.
진동을 주는 라이브러리로는
-
플러터 기본 sensor package
-
vibrate 1.7.3 : 진동 전용 dependency 중에선 가장 괜찮았으나 null-safety 지원하지 않아서 사용 불가
a. vibration 1.7.4-nullsafety.0 : 일부 iOS 기기 에서 동작하지 않는 이슈가 있으나 해결되지 않음(유사 PR 발견)
(1)sensor package는 진동의 세기가 너무 약해서 좀 더 진동 세기가 강한 (3)flutter_vibrate 적용
걷는 속도 측정 방법
스토리 : 사용자는 걷는 속도에 대한 피드백을 받는다.
스마트 워치가 없는 경우 사용자에게 적절한 피드백을 제공하는 데에 속도가 굉장히 중요하게 작용하므로 최대한 명확한 근거를 가지고 판단하려고 애썼다.
첫번째 시작과 같은 고민을 Expert님께 말씀드렸을 때, Expert 님께서 ADRArchitextural Decision Records을 권해주셨다. 템플릿은 Michael Nygard의 템플릿을 사용했다. Expert님께서 보여주셨던 것과 유사한, 기본적인 형태처럼 여겨졌기 때문이다.
*ADR을 Expert님께 보여드리고 뒤늦게 알게된 사실은, ADR은 방법론이 아닌 아키텍처 부분에서 사용하는 것이라고 들었다. 다 쓰면 되는 줄 오해하고 있었다...그렇지만 좀 더 체계적으로, 쉽게 선택 이유를 작성할 수 있는 데에서 의미가 있었다.
상태
제안됨, 수락됨, 거부됨, 더 이상 사용되지 않음, 대체됨 등과 같은 상태는 무엇입니까?
수락됨
문맥
우리가 보고 있는 이 결정이나 변경의 동기가 되는 문제는 무엇입니까?
Q. 웨어러블 디바이스를 못쓰고 가속도센서만 사용했을 때 강도를 구별할 수 있는 방법은? 를 참고했을 때 사용자의 이동 속도를 측정하는 것은 웨어러블 디바이스 없이 휴대전화만을 가지고 사용자의 운동 적정도를 판단하기 위한 주요한 사안입니다.
일반적으로 사용자의 이동 속도를 측정하는 방법에는 크게 1. 가속도 센서 2. GPS가 있습니다.
- 가속도 센서는 x축, y축, z축 방향으로 센서가 탑재된 스마트폰의 가속도를 측정할 수 있는 모션 센서입니다. 수학적 공식에 따라(적분) 가속도를 통해 속도를 연산할 수 있습니다.
- GPS는 인공위성의 전파를 이용하여 관측자가 이동하는 속도에 따라 파장이 길어지거나 짧아지는 차이를 측정(도플러 편차)하여 지도상의 위치 정확도와 별개로 안정적으로 속도를 계산합니다. 이 경우, 개발자는 GPS가 계산해서 내려주는 Location 데이터를 이용합니다.
속도를 가져올 수 있는 package에는 여러 가지가 있을 수 있으나 대개 위치 정보와 함께 속도 정보를 리턴하고 있습니다. 패키지는 Flutter에서 Null safety를 지원하는 패키지로 한정하여 탐색하였습니다.
-
- LocationData API를 통해 위치, 위치 정확도, 고도,속도, 속도 정확도를 가져옵니다.
- Listen to Location 으로 어플의 백그라운드에서 위치 정보를 받아옵니다.
- 처음으로 위치 정보 사용시 자동으로 Permission을 요청합니다.
-
- Last known location 으로 디바이스의 이전 위치를 가져옵니다.
- getPositionStream 으로 지속적으로 위치 변화를 감지하고 업데이트 받을 수 있습니다. 이 과정에서 위치 정보의 정확도와 최소 이동 거리, 시간 제한을 두어 더욱 정확한 위치 값을 얻을 수 있니다. 위치 정확도에 관한 정보는 안드로이드와 iOS 14+ 부터 사용할 수 있습니다.
결정
우리가 제안 및/또는 하고 있는 변경 사항은 무엇입니까?
- 사용자 이동 속도 측정 방법은 GPS를 제안합니다.
- 가속도 센서와 달리 개발자 측에서 연산을 할 필요가 없이 비교적 정확하고 안정적으로 값을 내려옵니다. 이는 개발자가 할 수 있는 연산 실수를 방지합니다.
- 개발 리소스를 줄일 수 있습니다. Waki는 위치 정보 수신을 위해 GPS 사용이 필수적인 상태입니다. GPS에서 제공하는 Location 데이터에서 속도 정보를 이용한다면 다른 의존성이나 방법을 강구하는 리소스를 아낄 수 있습니다.
- 패키지는 location을 사용할 것을 제안합니다.
- geolocator의 경우 현재 iOS에서는 속도가 계속 -1로 출력되는 문제가 있습니다.
- location 패키지의 경우 수동으로 권한 여부를 확인할 필요가 없습니다.
- locaton 패키지의 속도의 정확도가 더 높습니다.
- location 패키지를 이용하면 속도의 정확도를 확인할 수 있지만 geolocator 패키지에서는 그렇지 않습니다.
결과
이 변경으로 인해 무엇을 하는 것이 더 쉬워지거나 더 어려워지는가?
- GPS package 내부에 속도를 측정한 값이 함께 들어오므로 별도의 계산 과정을 거칠 필요가 없습니다.
- 속도 정확도를 높이기 위해 추가적인 방안이 필요해질 수 있습니다.
- 결과적으로 데이터의 송수신 횟수가 늘어나므로 성능에 관한 케어가 필요합니다.
- 어플의 백그라운드에서 LocationData를 받아오는 것이 불가능한 경우, Listen to Location에서 제공하는 위치 정보를 바탕으로 속도를 계산해야합니다.
느낀점
내가 개발하던 방식이 완전히 틀린 게 아니었다
지금까지 내가 개발 구현을 해왔던 방식은 아래와 같다.
공부라고 할 만한 건 없다. 마감 기한을 맞추기에 급해서 열심히 검색하고, 그 코드를 가져다 썼다. 그리고 동작하는 코드는 다시 들여다보지 않았다. 그러다보니 자연스럽게 내가 작성했다는 코드이지만 설명을 자신있게 할 수 없었다. 패키지의 선택의 이유를 묻는다지만, 내가 내세울만한 이유는 '커뮤니티가 커서요'가 전부였다. 커뮤니티가 큰 것은 중요한 이유가 될 수 있는 것은 맞지만, 모든 선택의 과정에서 그것이 유일한 이유가 된다면 그것이 나의 '검색해서 가져다쓰기 좋은 것'을 사용한 개발 방식을 드러내는 것 같아 부끄러웠다. 좋게 말하면 생산성 있는 코드, 솔직하게 말하면 내 코드같지 않은 내 코드였다.
그래서 뭔가 소프트웨어 마에스트로를 하면 시간이 비교적 넉넉하니 쫓기지 않고, 공부를 충분히 하면서, 선택도 충분히 고심해가면서 할 수 있을 것이라고 생각했다. 그리고 그런 방식은 내가 지금까지 해왔던 개발 방식은 흔적조차 남지 않은, 무언가 새로운 태도라고 생각했으며 그것을 함양할 수 있을 것이라고 생각했다.
하지만 아니었다. 멘토링을 받으며 내가 개발-공부하던 방식이 오히려 맞다는 것을 알았다.
한 멘토님의 멘토링을 받으면서 느낀 게, 생산성 좋긴 한데. 여기서 말하는 생산성은 내 코드를 내가 하나도 설명 못할 정도의 생산성을 말하는 게 아니었다. 하핫.
전담 멘토님의 멘토링을 받으며 나는 Chapter라는 것을 새롭게 알게되었는데, 이건 개인적으로 하는 공부를 말하는 것이었다. 내가 하던 방식이 틀린 게 아니라, 나는 그저 Chapter를 하지 않았을 뿐인 것이다. 멘토링을 통해 Sprint때는 내가 원래 하던 방식으로 개발을 해야하며, 내가 원하는 그 부분은 Chapter를 통해 충족하는 것이라는 걸 알았다.
어쩐지, 마감 기한이 넉넉하다고 말하는 개발자를 본 적이 없었는데, 다들 어떻게 자기 코드를 설명하고 그러는지 궁금했는데. 개인 공부 시간에 이런 걸 할 수도 있겠구나. 처음 알게 되었다.
Agile이란
사용자 중심으로 생각하는 것.
그것으로 사용자를 위한 서비스를 만들어나가는 것.
빠르게 하는 것이 Agile이 아니다.
처음에 생각했던 거랑 완전히 달라지고 있는데...
처음 생각대로...나는 취업을 하기 위해 내 개발방식을 고쳐야한다고 생각했고, 그러기 위해서라면 천천히 개발을 해야한다고 생각했다. Agile은 개발을 빨리 하게 해서 나를 힘들게 할 것같았기에 Agile한 개발, Lean한 개발은 모두 집어치울 생각이었다.
개발 공부만 하고 싶다고 생각했다. 마케팅도 할 필요 없고, 소비자 반응은 소마가 끝나기 전 딱 한 번 배포를 하고, 그곳에 달리는 리뷰를 볼 수 있는 정도면 충분하다고 생각했다. 물론 안봐도 상관없다고 생각했고.
그런데 서비스를 구상하고, 내가 기술적으로 얻고 싶고 경험한 것을 생각하다보니... 사용자의 반응이 중요하게 됐다. 사용자가 있어야 내가 경험하고 싶은 이슈를 경험할 수 있겠다는 생각이 들었다.
취업 자리에서 내가 보여줘야할 것은 '함께 일하고 싶은 사람'이라는 것을 새로 알게되었다. 그러기 위해서 나는 Agile이 필요했고, 사용자 중심적 사고가 필요했다. 그래서 Jira를 사용하고 Ground Rule을 정하고, 스프린트를 시행하고 리뷰하고 회고하고 있다.
처음에 하려던 계획과는 엄청 틀어졌지만...목표를 이루는 방법이 바뀌었을 뿐 내가 원래 하고자 했었던 것을 할 수 있을 것이라는 생각이 든다.
