Intro
회사에 입사를 하고 온보딩 기간을 끝나면서 본격적으로 실제로 서비스가 될 프로덕트를 개발하게 됐다. 12월 중순부터 거의 한달 동안 모든 시간을 이 프로젝트에 쏟았던 것 같다.
엄청난 규모의 프로젝트를 진행한 것은 당연히 아니고 추후에 메인 서비스에 추가하게 될 서비스의 프로토타입을 만드는 프로젝트였다.
규모는 작았지만 돈을 벌 수 있는 서비스를 만들어 본 경험이 없다보니 생각보다 많은 고난과 역경 그리고 배움이 있었다.
1. UI/UX
먼저, UI/UX에 대해 많은 고민과 경험을 할 수 있었다.
UI는 와이어프레임이 나와 있어서 기본적으로 와이어프레임을 따라 화면을 구성했지만 개발을 하면서 추가했으면 하는 부분들(Ex. 에러가 발생했을 때 보여지는 Modal, Form Validataion 오류 등)을 추가를 하여 개발을 진행했다.
User Interaction이 많은 페이지를 만들다 보니 자연스레 유저 입장에서 개발을 하게 되고 내가 놓친 부분들은 이따 얘기할 지옥의 QA에서 걸러져서 조금 더 사용자 친화적인 서비스를 만들 수 있었다.
어떻게 하면 사용자가 조금 더 편하고 쉽게 이용할 수 있을까에 대한 고민, 다시 말해 UX에 대한 고민을 많이 했고 이를 화면으로 보여주기 위해 노력했다.
2. UI 라이브러리
빠른 기간 안에 서비스를 출시해야 되다 보니 Table이나 Calendar 같은 구현 난이도가 높은 Component들을 직접 구현하기는 무리가 있을 것이라고 생각해서 UI 라이브러리를 이용하여 화면을 구성하게 됐다.
사용하면서 느낀 점은 정말 편리하고 쉽게 강력한 기능을 사용할 수 있지만, 스타일을 커스터마이징 하기는 귀찮은 부분이 있었다.
또한 컴포넌트가 제공하는 props를 사용하지 않았을 때 예상치 못한 오류를 만날 가능성이 있다는 것을 알았다.
CheckBox 컴포넌트를 사용할 때 이상하게 자꾸 내 생각과 다르게 동작(이벤트 버블링 발생)하길래 원인을 못찾고 있었는데 공식 문서를 잘 살펴보니 onChange가 아니라 onClick를 사용하여 발생한 문제였다.
정리하면 강력하고 편리한 기능을 단 한줄로 사용할 수도 있지만, 예상치 못한 동작을 방지하기 위해 주의 깊게 사용해야한다는 걸 느꼈다.
3. 서버 데이터 가공
위에서 말했듯 UI 라이브러리를 사용했기 때문에 난 그저 data를 넣기만 하면 Table이 딱 하고 만들어졌다. 하지만 각 컴포넌트가 요구하는 data의 형식을 맞춰서 넣어줘야 했기 때문에 서버에서 받아온 데이터를 가공해야만 했다.
마치 코딩 테스트를 보는 것처럼 서버 데이터에서 필요한 데이터를 추출하고 이를 원하는 형식으로 변환하면서 서버 데이터를 이리저리 가공해서 사용했었다.
생각해보니 UI 라이브러리의 또다른 불편함이 이런 점이 있을 수 있을 것 같다.
마치 전능하신 내가 이런 엄청난 기능을 제공해주니, 너는 예를 갖춰 적절한 데이터를 만들어 넣거라. 라고 말하는 것만 같다.
4. 환경 변수 관리
그동안 환경 변수는 모조리 env 파일 안에 끼어 넣어 process.env.~~~ 처럼 사용하곤 했었다.
환경 변수를 사용하는 것이 민감한 변수를 은닉하는 것도 있지만 환경에 따라 다른 변수를 사용하거나 사용하는데 그동안 나는 이런 점을 전혀 이용하지 않고 있었다.
이번 프로젝트는 Development, QA, Production 환경이 있었고 각각의 환경마다 제공되는 기능들이 조금씩 달랐다.
예를 들어, QA 환경에서는 테스트를 위해 시작 일자를 현재 보다 이전으로 수정 가능하게 하는 반면 Production 환경에서는 시작일자를 현재 보다 이전으로 수정이 불가능하게 만드는 것처럼 각 환경에 맞는 기능들을 분리하여 프로젝트를 진행했다.
그렇기 때문에 .env.development, .env.qa, .env.production 으로 env 파일을 분리하고 각각의 파일 내부에서 각 환경을 의미하는 변수를 선언하여 배포가 되더라도 어떤 환경인지 구분 가능하게 만들었다.
5. 지옥의 QA
QA는 뭐랄까.. 그동안 단 한번도 겪어보지 못했던 색다른 경험이었다.
진짜 끊임없이 수정하고 수정하고 수정하고 수정했다.
데이터가 보여지는 순서 변경과 같이 간단한 것부터 Input의 넓이와 높이, 1px 단위의 스타일 수정처럼 아주 디테일한 사항을 물론이거니와 개발 단계에서 추가되는 다른 기능들과 이에 따른 테스트까지 정말 QA 기간이 실제 개발하는 기간보다 더 바빴던 것 같다.
이번 프로젝트에서는 총 3차 QA까지 진행이 됐다.
꽤나 많은 페이지를 작업하다보니 생각보다 놓친 부분이 많이 존재해서 1차 QA에서는 정말 많은 부분들을 수정했다.
❗️
여기서 정말 뼈저리게 느낀게 TDD의 필요성이다.
개발을 하면서 프론트엔드 테스트 코드를 작성하여 QA 기간 발생할 수 있는 예외들을 최대한 사전에 처리하는게 더 좋은 개발 방식이라는 생각을 하게 됐다.
2차 QA에서는 추가된 기능들에 대한 이슈 대응과 서버에서 받아오는 에러 코드에 맞는 에러 메세지를 유저에게 보여주는 작업을 위주로 진행했다.
일괄적인 에러 메세지를 보여주게 되면 유저 입장에서는 어떤 부분 때문에 오류가 났는지 알 수 있는 방법이 없고 이는 곧 UX를 저하시키며 결국은 서비스를 이용하지 않게 되는 결과까지 이어질 수 있는 부분이기에 굉장히 친절하게 오류가 발생한 부분에 대한 설명을 해줬다.
3차 QA에서는 지금까지의 이슈 사항들과 기존에 오류 없이 진행된 사항들에 대한 총체적인 리뷰가 진행됐다.
2차 QA까지 완료하고 이제 진짜 수정할 건 없다.. 라고 생각을 했지만 어디서 그렇게 이슈들이 나오는지 정말 놀라웠다..
다행히도 크리티컬한 이슈가 아니고 즉각적으로 대응할 수 있는 이슈다보니 출시에 크게 문제가 되진 않았다.
❗️출시하기 전까지도 굉장히 마음이 졸였던건 비밀..😂😂😂😂
어찌됐든 저찌됐든 모든 과정이 끝나고 무사히 1.0.0버전 배포를 마치게 됐다..👏👏👏
사실 서비스가 출시되고 나서야 진짜 개발이 시작하는거라고 생각하고 아직은 서비스가 안정화되지 않은 시기라 언제나 이슈에 대응할 준비를 해야겠지만 당장은 기분이 너무 홀가분하고 여유가 생겼기에 이렇게 끄적끄적 글을 써봤다.
++
글을 쓰는 이 와중에 Version 2 기획 회의가 시작된다는 얘기가 들린다..
무엇이 나를 성장하고 힘들게 만들지는 언제가 될 지 모르는 다음 포스트에서 계속됩니다...
