개발 프로젝트 회고

프로젝트 회고

이번에 안경을 도매로 판매하는 회사의 영업사원들을 위한 웹/앱을 메인 개발자로 진행을 했습니다.

즉, 100명 이상의 영업사원이 대금을 받으러 다닐 때 사용하는 웹/앱을 만들었습니다.
(웹 프론트 개발과 Flutter 개발을 맡아서 진행하였습니다)

디자이너분과의 문제

이때 디자이너분과 처음 합을 맞추는 것이어서 디자이너분이 어떠한 방식으로 일을 하고 있는지 파악하는 시간이 필요했습니다.
그러나 급하게 완성해야 해서 서로를 파악하는 시간이 부족했고 삐걱대기 시작했습니다....

디자이너분은 회사에 거의 8년 이상 계셨던 분이어서 다른 팀원들은 디자이너분이 만들어 놓은 대로 많이 따랐습니다.
그리고 저는 신입이지만 뭔가 잘하고 싶은 마음에 하나하나 같이 이야기하고 좀 저의 의견도 들어갔으면 했지만, 이것이 좀 좋지 않게 발생했던 것 같습니다.

처음 웹/앱으로 개발하기 때문에 다양한 디바이스에서 보여야 하는 것이지만 px로 디자인이 되어있었고 변형하는 것을 원하지 않았습니다.
그렇지만 의욕이 넘쳤던 저는 디바이스의 브라우저마다 글자와 레이아웃 등을 잘 보이고 유연하게 대응하기 위해 rem, em과 같은 단위로 사용하기를 원했습니다.

그리고 기능별로 component를 묶는 것은 어떤가요?, letter-spacing 등의 처리를 해주실 수 있나요?, 화면이 넓어질 때 layout도 넓어지는 것이 어떻나요? 등 의견을 제시했지만 제가 너무 직접적으로 말을 하여 자존심이 상하셨고 다른 팀원들의 이야기를 들어보니 디자이너분과 일을 할 때 그냥 다 맞추었고 구현이 힘든 부분만 이야기를 나눴다는 이야기도 듣게 되었습니다.

뭔가 디자이너분의 입장에서 생각하니 건방진 신입이 계속 요구하는 것이 못마땅했을 것 같았고 디자이너분이 일하는 스타일을 파악하지 않고 진행하여 디자이너분을 배려하기보다는 저의 스타일을 강요했었나?라는 생각도 하게 되었습니다.

다음부터 새로운 디자이너분과 일을 진행하게 되면 팀원들에게 물어보고 디자이너분에게 맞춘 후 저의 의견을 추가하는 식으로 진행을 해야겠습니다.

내가 PM + 메인 개발자?

우리 회사는 PM이 없습니다. 그래서 개발자가 PM의 역할 일정 관리 등을 다 같이 진행해야 했습니다.
제가 메인으로 개발을 진행하기는 했지만, 개발팀원 2분(저보다 사수... 다른일이 메인이고 서브로 도와주는 역할), 디자이너분 이렇게 4명에서 진행을 했습니다.

처음에는 무엇을 해야 할지? 정말 몰라서 프로젝트의 전체를 보지 못하고 저의 개발 일만 보게 되었습니다.
팀원들과 소통했는데 한 곳에 정리가 되지 않고 slack, Figma, Notion 각각 정리하여 간단한 회의를 통해 나눴지만, 놓친 부분이 생기기 시작했습니다.

그래서 저의 개발 선배들한테 물어보니 '해당 내용들을 정리해 보는 것은 어때?'라는 어드바이스를 받게 되어 Notion에 새롭게 생성된 문제점들, 해당 과정을 Notion에 다음과 같이 정리하며 프로젝트를 진행하였습니다.

그런데 각자의 밑은 추가적인 일들이 많아 서로서로 소통이 원활하지 않을 때가 있었습니다. 처음에는 '바빠서 같이 이야기할 시간이 없겠지?'라고 혼자 생각하고 그냥 진행했는데 점점 check을 못 한 문제들이 하나둘씩 발생했습니다.
그래서 '혹시 오전, 오후에 같이 간단하게 모여서 이야기할 수 있을까요?'라고 물어봤더니 다들 흔쾌히 허락을 해주셨습니다. 이때 진짜 아차 했습니다. 이젠 혼자서 짐작하지 않고 직접 물어보며 진행하게 되었습니다.

웹/앱 개발

영업직원들을 위한 웹/앱으로 Svelte로 웹을 개발한 후 앱으로 감싸는 작업을 진행해야 했습니다.
기존의 방법은 Android, iOS 따로따로 만들어 웹을 앱으로 감쌌지만, 이때는 Device의 기능을 사용하지 않았습니다.
그렇지만 PAY 현재 앱은 Device 정보 가져오기, 위치 정보 가져오기, 위치 정보 허용 여부, 공유(프린터) 기능을 사용해야 했습니다.

그리고 Android, iOS 한 번에 처리하고 싶은 생각에 토의를 한 결과 한번에 사용가능하고 Device의 기능을 쉽게 제어 가능한 Flutter를 사용하여 개발하게 되었습니다.

처음 Flutter를 사용하여 개발을 진행하여서 어려웠지만 이때 공식 문서를 많이 보고 새로운 학습을 할 때 좀 더 빠르게 할 수 있을 것 같은 자신감도 가지게 되는 계기가 되었습니다.

진짜 Android와 iOS의 버전부터 CSS 허용 여부, Device 크기, OS 차이 등 고려한 것이 정말 많았습니다. (자세한 내용들은 하나씩 블로그에 올리겠습니다)

이러한 상황들을 고민하면서 특정 프레임워크, 라이브러리 익히는 것보다 문제 해결력이 중요라는 것을 알게 되었습니다.

성급한 배포 & 급박한 문제

기본 배포일을 23.08.31로 잡았습니다.
그렇지만 운영 테스트까지 완벽하게 끝나지 않은 상태에서 App Store에 올려도 인증 때문에 최소 1~2일은 걸릴 것이며 이때 테스트를 완료하면 된다.라는 예상을 가지고 새롭게 App Store를 올리는 방안이 아닌 기존에 있는 App Store를 덮어씌우는 방식으로 진행하였습니다. 또한 과거 앱을 사용하고 완전한 테스트가 마무리된 후 현재 앱을 업데이트하는 방식으로 나아가자라고 이야기가 되었습니다.

그런데 App Store 인증이 1일도 안 돼서 마무리되었고 사용자분들의 폰이 자동업데이트하는 경우가 생겨 새로운 앱을 바로 사용해야 했지만.. 해당 앱에서 가장 중요한 기능의 결제 기능이 동작하지 않았습니다.

테스트 서버에서는 잘 진행되었던 결제가 운영 서버로 가니 결제가 진행되지 않았습니다.
영업직원들이 사용하는 앱이고 월말, 월초다 보니 영업직원들의 실적에 아주 큰 영향을 미칠 수 있고 크게는 회사의 세금 문제까지도 이어질 수 있는 상황이었습니다.

상황을 파악해 보니 새로 만든 서버의 결제 관련 인증서가 만료되어서 생긴 문제점이었습니다.

현재 앱의 결제 구조를 보면 다음과 같이 PAY 현재 앱 <-> Node Server <-> 결제사로 되어 있습니다.

다행히도 과거의 앱은 결제가 잘 되는 상태였습니다.

과거 앱의 결제 구조를 보면 다음과 같이 PAY 과거 앱 <-> Java Server(관리하는 사람 없음) <-> 결제사로 되어 있습니다.

그래서 PAY 현재 앱 <-> Java Server <-> 결제사로 연결해야 했습니다.

그래서 팀원 대부분이 Java Server 코드와 PAY 과거 앱의 결제 관련 부분을 파악해야 했고 계속되는 영업직원들의 전화, 레거시 코드로 인해 당황스러움의 연속이었습니다.

저는 프런트프론트 쪽을 맡아서 진행하였고 PAY 과거 앱은 결제할 때 JSON을 사용하는 대신 form data를 사용했고 전송해야 하는 데이터 값도 대부분 수정해야 했습니다. 추가로 PAY 과거 앱의 구조가 디바이스 내의 storage에 정보를 저장하고 있는 형태여서 데이터 이전도 같이 이뤄줘야 했고 다들 엄청 혼란스러운 상황의 연속이었습니다.

다행히 Java Server와 잘 연결이 되어서 문제가 해결되었지만, 테스트의 중요성과 과거의 코드를 바로 없애지 말아야 하며 급할수록 침착해야 함 을 느낀 프로젝트였습니다.

이런 혼란스러움이 개발자로서 저를 많이 변화시켜 주어 자신감을 가지게 된 계기가 되었습니다.

리팩토링

영업사원들과 서비스팀에서 테스트 및 직접 사용을 하면서 피드백이 들어오기 시작했습니다.
큰 기업이 아니다보니 직접적으로 피드백을 들을 수 있었고 많은 양의 피드백을 정리하며 어떻게 대처해야 하는지도 배우고 있는 중입니다.
빨리 더 좋은 코드로 보답하고 블로그에도 대표적인 부분을 작성해서 올려야겠습니다.

마치며

사실 많이 지친 부분들도 있었지만 저를 더 잘 알게 되는 시간이었고 팀원들이 많이 도와준 덕분에 마무리를 했던 것 같습니다. 아직 iOS 심사를 받고 있고 추가 기능을 더해야 해서 다 끝난 것은 아니지만 큰 산은 넘은 것 같습니다.

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