2025년 첫 프로젝트 회고
소개
매번 프로젝트를 진행하다보면 아쉬운점이 항상 남는다. 앞으로는 매 프로젝트가 종료될 때마다 아쉬웠던 점들을 정리하고 어떻게 개선할 수 있었을지 생각해보며 같은 일을 반복하지 않으려 한다.
따라서 앞으로는 매 프로젝트가 진행될 때마다 회고를 남길려고 하는데, 우선 올해 첫 프로젝트였던 척추뼈 인식 및 각도 계산 서비스 프로젝트를 진행하며 겪었던 일들과 아쉬웠던 점, 좋았던 점들을 작성하려 한다.
이번 프로젝트는 미국의 의료기기 스타트업의 의뢰로 수술실에서 스마트폰을 통해 간단한 각도 측정 및 계산을 제공하는 시스템 개발이었다. 수술실이라는 특별한 환경, 온디바이스 AI, Canvas 조작 등 흥미로운 제한사항들이 엮여있어 다양한 시도를 해볼 수 있는 기회가 되었다.
개발준비
인원 분배
다른 팀원들과 모두 함께 고민하며 개발을 진행한다면 좋겠지만, 바쁜 일정속에서 함께 일하기란 생각했던 것보다 훨씬 힘들었다.
이번 프로젝트의 경우에도 빠르게 프로토타입을 개발하여 한달안에 그럴듯한 결과물을 보여줘야하는 상황이었고, Canvas로 여러 도형을 그리는 복잡한 상태를 조작하기에는 신입 개발자분의 역량이 조금 부족하다고 판단했다.
시간이 조금만 더 여유있었다면, 같이 일하는 프론트앤드 개발자분과 함께 작업을 진행하였겠지만, 초기 3달 정도의 예상 시간보다 시간이 훨씬 앞당겨진 3주라는 시간 안에 어느정도 완성도 있는 프로토타입 애플리케이션을 배포해야하는 상황이어서 다른 사람을 챙기면서 개발할 수 있는 여유는 없을 것 같았다.
복잡한 상태를 다룰 때 상태들이나 디자인 패턴 을 고려하지 않고 코드를 작성할 경우 이전 얼마나 더 많은 시간이 소요되는지 이전 프로젝트들을 통해 경험해보았다. 따라서 시간이 조금 걸리더라도 기본 뼈대를 최대한 잘 구축하는게 좋다고 판단하였다.
따라서 다른 Frontend 개발자분의 경우 아직 Flutter의 상태관리나 라이프사이클에 익숙해지는 것이 좋을 것 같다고 판단하여 기존 Flutter 프로젝트들의 운영과 유지보수 업무를 맡기고 이번 프로젝트의 경우 혼자서 개발에 들어갔다.
프로젝트 개발은 백엔드 두분이 빠르게 이미지 저장, 사용 로그 저장과 관련된 API 작업을 마치고 AI 개발자분들과 테스트 결과에 대한 피드백을 주고받으며 혼자서 프론트앤드 개발을 진행하였다.
이번의 경우 온디바이스 AI를 개발하는 과정에서 네이티브 코드에 대한 이해와 Flutter에 연결하기 위한 Flutter Plugin, Flutter Engine에 대한 이해가 필요했는데, 이 부분은 나도 아직 많이 부족하여 누구에게 잘설명해주기는 어렵다고 생각했고, 일단 만들어두고 나중에 수정하는 과정에서 제대로된 피드백을 주고받는게 나을거라 판단했다. 따라서 애플리케이션 개발은 혼자서 진행을 하였다.
iOS 환경에 대한 이해
온디바이스 AI를 적용하면서 가장 시급했던 문제점은 리소스 최적화였다.
물론 애플리케이션을 사용하는데 있어서 가장 중요한점은 일단 AI가 얼마나 정확하게 나오는가 일 것이다. 하지만 이 부분은 AI 전문가분들이 담당하고 있으므로 AI 결과에 대해서 는 내가 관여할 부분이 없었다.
결론부터 말하자면, iOS Neural Network를 활용하였고 AI 모델의 경우 싱글톤 구조로 실행되지 않더라도 항상 준비된 상태로 동작하도록 하였다. 또한 보다 정확한 계산을 위해 가장 큰 ML 모델을 사용하였고 GPU가 없는 경우에는 실행이 안되도록 배제하였다.
iOS의 경우 자체적인 소프트웨어로 AI모델을 사용하는 과정에서 GPU 사용을 조금 더 최적화 해주는 Neural Network 라이브러리를 제공해준다. 모델을 생성할 때 Config 설정에 .all로 설정해두면 CPU, GPU, Neural network 중 가능한 동작 방식을 찾아서 적용해두도록 되어있어 이 부분은 큰 어려움 없이 적용 가능했다.
하지만 GPU가 없는 기종에서가 문제가 되었는데, 내가 현재 사용하고 있는 Iphone 11 pro 모델의 경우 GPU 하드웨어가 없어, CPU로만 동작하였고 CPU로만 동작할 때에는 보다 많은 메모리공간을 사용하기 때문에 애플리케이션이 강제로 종료 되거나, 베터리 발열이 많아지는 등 문제가 발생했다.
이 부분에 있어서 나는 좀 더 작은 ML 모델을 사용할 때 성능 상에 큰 차이가 없다면 작은 모델을 사용하자는 입장이었고 회사의 다른 분들은 최대한 정확한 모델을 사용하기 위해 아이폰 13 이전의 기기들은 고려하지말고 개발하자는 입장이었다.
나의 의견은 최대한 다양한 사용자와 환경을 고려하는 것이었는데, 의견을 주고받는 과정에서 이 경우는 특별한 사용자들을 위해 배포하는 시스템이고 그 사용자들은 오래된 기기를 사용하지 않을 것이라는 의견에 공감하여 결국 GPU가 없는 환경은 고려하지 않도록 결정하였다.
이번 내용과 이전에 개발해온 프로그램들을 돌이켜보며 결국 애플리케이션은 특정 사용자를 목표로 만들어지고 그들의 요구사항만 만족할 수 있다면 좋은 애플리케이션이라고 할 수 있지않을까 생각하게 되었다.
결국 1%의 특별한 사용자를 고려하다가 99%의 사용자들이 조금씩 불편함을 겪어야 한다면 이는 잘못된 개발 방향일 것이다.
개발진행
프로젝트를 진행하면서 가장 신경썼던 부분은 사용성이었다. 결국 우리의 애플리케이션을 사용하는 사람들은 해당 분야에 있어서 훨씬 더 잘알고있는 전문가가들이다. 이러한 사람들이 우리의 애플리케이션을 사용하기 위해서는 결국 쉽고, 간편하다는 부분에 초점을 맞춰야 했다.
편의성과 활용성
'이번 프로젝트에서의 핵심 키워드가 뭘까' 생각해보면 편의성과 활용성이 아니었을까, 이 두 단어는 제품에 있어서도 코드 개발에 있어서도 계속해서 내 골머리를 앓게 했다.
제품에 있어서는 보다 사용자들이 쉽고 간편하게 사용하도록, 코드 개발에 있어서는 다른 개발자들이 코드를 유지, 보수하는데에 있어 보다 빠르게 파악할 수 있고 기존에 개발해둔 객체들을 잘 다룰 수 있도록하는 것이 이번 프로젝트의 목표였다.
먼저 서비스를 살펴보면 이번에 적용하는 캔버스 환경에서 iOS나 구글 맵 등의 보편적인 애플리케이션의 제스쳐 동작을 따라갈지, 조금은 다른 제스쳐 방식을 도입할지가 가장 큰 화두였다.
오래된 습관과 지식들은 쉽게 바꾸기 힘들다. 이는 휴대폰을 사용하는 사용자들에게서도 잘 확인할 수 있는데 동영상을 볼때를 생각해보자 많은 사용자들은 동영상이 한번 터치되었을 때는 재생, 정지가 되기를 기대하고 왼쪽/오른쪽을 더블탭 했을때는 뒤로/앞으로 10초가 스킵되기를 기대한다. 이는 오랜동안 PC 비디오 플레이어, 유튜브 등을 통해 학습된 것이다.
따라서 초기에는 최대한 iOS의 제스쳐 동작을 따라 같은 동작들 특히 지도 제스쳐를를 최대한 구현해주려 하였다. 더블탭을 했을 때에는 해당 부분을 확대해주고 한번 터치했을때는 해당 부분의 정보를 보여주거나 현재 보고있는 위치를 움직일 수 있도록 개발을 진행하였다.
하지만 이에 있어서도 지도에서 활용되던 제스쳐를 모바일 캔버스 환경에서 그대로 사용하려다보니 이상한 부분들이 많이 보였다. 따라서 회사 구성원 분들과 다시 의견을 주고 받으며 특정 상황에서 제스쳐가 어떤 동작을 하기를 기대하는지 다시 의견을 모아 개발을 진행하였고 기존의 지도에서 활용되던 제스쳐와는 많이 달라지게 되었다.
개발에 있어서도 내가 혼자 작성한 코드를 이후 다른 개발자분들이 확인했을 때 이해하기 쉽도록 하기 위해서는 어떻게 해야하는지가 핵심 문제였다.
이번 코드 개발에 있어서 핵심 키워드는 선언형, 추상화, 옵저버 패턴이었다.
개발자들의 필독서로 꼽히는 클린코드 책을 읽다보면 불필요한 주석은 오히려 코드가 더 복잡해보이도록 한다는 내용이 있다. 나도 이 부분에는 크게 공감하는데 주석이 있어야만 알 수 있는 코드는 어딘가 문제있는 코드일 가능성이 높 았다.
따라서 별도의 설명 없이 코드를 쉽게 파악하기 위해서는 어떻게 해야할지 고민중이었는데, 토스에서 프론트앤드 클린아키텍쳐에 대한 문서를 공유해주어 해당 내용이 많은 도움이 되었다.
결국 우리가 원하는 것은 그래서 이 화면은 어떻게 동작해? 에 대한 대답이다. 우리가 만드는 것은 코드가 아닌 제품이며 결국 우리의 목표는 제품을 어떻게 동작하도록 할 것인가 이다.
따라서 많은 회사들이 프론트앤드 개발을 할 때 적용중인 선언형 코드 작성방식을 조금은 이해하게 되었다. 특정 메서드들이 어떤 동작을 하는지 메서드명을 통해 충분히 알려줄 수 있다면 버튼을 수정하는데 데이터그리드 코드까지 확인할 일은 없을 것이다.
결국은 보여주기 위함
개발후기
프로젝트가 끝나고 나면 항상 아쉬움이 남는다.