brunch

You can make anything
by writing

C.S.Lewis

by 희경 Mar 12. 2023

개발자들과 일하기

수포자에게 매출 어드민 페이지라니요

올해부터 개발 팀장이 되고 나서 작은? 프로젝트를 진행 중이다. 고백하자면 나는 미술을 전공했기 때문에 일찍이 수학을 포기했던 일명 수포자였는데, 이런 내가 매출과 마진율을 계산하는 어드민페이지를 만들고 있다. 수식을 계산해야 되는 일이나 숫자와 관련된 일을 하게 될 줄은 꿈에도 몰랐는데 거기에다 회계나 세금 관련 입력창들이 고구마 줄기 뽑듯 줄줄이 따라 나오는 것이다. 어쨌든 약 3개월째 매출과 마진, 그리고 정산과 관련된 어드민 페이지를 진행하면서 개발자들이 했던 질문들을 토대로 개발자들과 일할 때 고려하면 좋을 몇 가지를 적어본다.

소수점은 어디까지 보여주면 될까요?

특히나 이번에 진행하고 있는 어드민 페이지는 내 인생에서 경험할 수 있는 사칙연산 끝판왕이라고 생각되는데, 계산식이 많고 숫자도 1원 단위로 떨어지는 것들이 많아 소수점으로 떨어지는 숫자들이 많다. 이 페이지 전체를 기획하고 디자인하는 데 있어 나는 페이지 전체를 바라보고 기능이나 사용자에 대해서만 생각했는데 같이 작업하는 프런트엔드 개발자가 이런 질문을 던진 것이다. 응? 소수점??? 당황하지 않고.. 회계 관련 부서에 어떻게 처리하면 좋을지 물어보며 숫자라는 것이 얼마나 중요하게 다뤄야 하는지 알게 되었고, 개발자들이 작은 인풋창에 입력될 숫자 형태의 변수에도 세심하게 대응해야 한다는 사실이 놀라웠다. 이것 외에도 인풋창에 -, + 둘 다 입력해도 되는지, 소수점을 끊을 거라면 반올림을 할 건지 절삭을 할 건지도 말이다. 지금까지 숫자를 그림처럼 인식했던 디자이너에게 이번 프로젝트는 참 고역이었다.

사용자 권한은 어떻게 부여하면 될까요?

지금까지 내가 기획하고 디자인했던 프로젝트의 유형은 서비스 페이지였다. 사용자의 유입 경로나 로그인 이후 사용자 타입 정도만 신경 썼었는데, 어드민 같은 관리자 페이지는 회사의 중요한 정보들이 집약되어 있는 곳이기 때문에 사용자를 구분하는 것부터 기획이 되어야 하는 것을 몰랐다. 이 어드민의 사용자는 극히 제한적이긴 했지만 나중을 고려해서 부서별로, 각 팀장 레벨 별로, 마스터 권한이 있는 사람까지 고려해 사용자 관리 페이지도 개발에 추가되었다. 파면 팔수록 나오는 개발 요건들.. 개발자들이 싫어하는 만큼 기획자도 변수를 싫어하는데 업무에서 이 변수가 발생하지 않을 가능성은 정말이지 단언컨대 0%인 것 같다. (이제 나는 변수가 발생해 급하게 문제를 해결해야 할 때 짜릿한 쾌감을 느끼는 경지에 이르렀다.. 변태 맞음.)

에러 페이지는 어떻게 하죠?

어떤 페이지를 디자인할 때 기획자나 디자이너는 서비스 페이지 그 자체에만 집중한다. 그렇기 때문에 네트워크 에러가 발생한다거나 사용자 정보가 없다거나 품목 리스트에 데이터가 없다거나 했을 때의 페이지의 모습은 뒤로 미뤄두다 보니 빠뜨리게 되는 경우가 종종.. 아니 많다. 사실 개발해야 하는 페이지들을 리스트업 하고 차근차근 진행되면 문제는 없겠지만, 그렇게 정리하더라도 놓치는 것들이 많다. 다양한 상황에서 에러가 생기는데 이때마다 대응할 수 있는 카피들을 미리 준비해 놓으면 좋을 것 같다는 생각이 들었다. 프로젝트를 진행할 때마다 카피를 만들기도 해서 중구난방이었는데, 에러 상황 별 필요한 메시지와 필수적으로 필요한 페이지들을 리스트업 한 디폴트 문서를 만들어서 매 프로젝트를 진행할 때마다 꺼내서 추가하고 바꾸며 체크해 나가면 좋을 것 같다.

결국엔 매뉴얼이 필요하다?

큰 서비스를 운영하는 다른 회사는 어떻게 관리하고 있는지 모르겠지만 인원이 한정적인 스타트업의 경우엔 자신들의 경험에 의존해 매뉴얼화를 진행하기 때문에 시기가 너무 늦어지기도 하고, 그렇다고 경험이 많은 시니어라고 해도 문서화를 하는 작업을 섣불리 했다간 계속해서 변경되는 내용들을 문서화하다가 결국 당사자가 퇴사하는 경우 그 문서는 빛도 못 보고 사라지는 일이 적지 않다. 사실 문서화하는 것은 시간과 인력이 필요한 일이다. 대체로 모든 직장인들이 프로젝트를 시작하고 끝내는데 바빠 이런 것들을 놓치곤 한다. 프로젝트를 진행하며 중간중간 시간이 될 때마다 문서화하는 습관이 필요하다. 끝나고 나서의 회고록도 중요하다. 그리고 제일 중요한 건 프로젝트가 시작될 때 개발자들에게 필요한 페이지와 기능들에 대해 같이 문서를 작성하고 빠뜨린 부분은 없는지 계속해서 크로스 체크를 해야 하는 것이다.

처음부터 잘 짜인 기획서를 주면 좀 좋아요?

그런 기획서가 있을 리 만무하지만 프로젝트 초반부터 개발자를 참여시켜 개발자가 중요하게 생각하는 부분들을 채워나가야 나중에 발견하는 변수를 줄일 수 있다. 이제 두 번째 페이지를 만들었고 세 번째 배포는 추가 개발 요건들과 정산 관련 페이지 기획과 개발이 남아있다. 갈 길은 아직도 멀었지만 개발자들이 중요하게 생각하는 부분과 내가 중요하게 생각하는 부분이 이렇게 다르구나 하는 것들을 깨닫는 하루하루가 이어져 가고 있다. 이곳은 학교가 아니라 회사이지만 한 챕터씩 페이지들이 완성되고 QA를 진행할 때마다 하나씩 배워가고 있음에 감사한 마음이다.

아 SQL 공부해야 하는데.. 손이 안 갑니다. 어쩌죠?

keyword