거절하지 못한 후회 목록을 남긴다.
디자인 먼저 개발하시죠
그러면 안된다. 그 디자인과 연결된 기능이 언제 없어질지 모른다. 없어질 이유는 많다. 기획이 변경된다. 서버 개발이 미루어진다. 서버 개발이 불가능하다. 이번 릴리즈에는 포함하지 않는다. 릴리즈 일정이 확 앞당겨졌다. 다른 컴포넌트 가져다 쓰기로 했다. 등등
나중에 ‘그 디자인은 1주일 동안 만들긴 했지만 사용하지 않아서 지금은 없어요’라고 누구에게 하소연할 것인가? 서버 개발은 늦추어지고 우선 눈에 보이는 것이 디자인이라면 자꾸 고치게 된다. 처음 만들 때 드는 시간보다 더 많은 시간을 고치는 데 사용할지도 모른다. 1년 일하고 돌아보니 1달 만들 작업을 12번 반복한 경험이 있다면 어떤 느낌인지 감이 올 것이다. 멀리서 들려오는 말이 비수다. 하~ 이 버튼을 언제까지 만들고 있는 거야? 반응형이 아니잖아? 기능이 없는 디자인을 먼저 개발하면 안된다. 다자인의 끝은, 없다. 멈출 뿐.
디자인 없이 프레임워크 컴포넌트를 사용해서 개발하시죠
이러면 안 된다. 결국 나중에 디자인이 제공되면 프레임워크 컴포넌트 일부가 디자인과 다르다는 것을 알게 되고 프레임워크에서 제공되는 기능으로 디자인과 기능 변경을 시도하다가 안되면 커스텀 컴포넌트를 새롭게 만들게 되고 커스텀 컴포넌트가 점점 늘어나다가 이 커스텀 컴포넌트와 기존 프레임워크 컴포넌트가 서로 동작과 모양에서 일치가 안 되는 것을 발견하게 되고 이를 맞추는 작업을 하다가 포기하고 결국 대부분의 컴포넌트를 커스텀으로 만들게 되고 돌아보니 프레임워크 컴포넌트보다 여러 가지 면에서 부족하다는 것을 알게 되고 프레임워크 컴포넌트를 사용하자고 하는 순간부터 이제는 컴포넌트 디자인을 바꿀 수 없다고 이야기할걸 하면서 아쉬워하고 차라리 처음부터 모두 커스텀 컴포넌트로 갈걸 하면서 후회하고 그도 안되면 CSS 없이 HTML로만 기능을 구현할걸 하고 자책하고 이런 과정에 사용한 시간이 너무 아깝고 결과는 시원찮고 기차는 이미 떠났고…
서버 연동은 서버 개발되는 것을 보면서 차차 하시죠
그러면 안된다. 함수의 인자와 리턴 값을 구체적으로 정하는 것처럼 API 요청 옵션과 리턴 값의 명세를 정확히 받아야 한다. 레스트 풀 API를 사용한다면 에러 코드 목록과 그 의미는? (HTTP code를 사용할지 200 돌려주고 그 내부에 code를 사용할지), 공통 처리 에러 코드는 401은? 500은?, URL은 (GET, PATCH, …), 쿼리는?, 헤더 옵션은?, 인증은?, CSRF는?, 데이터를 돌려준다면 모든 데이터를 포함하는 예제는?. 웹 소켓을 사용한다면, 재접속 룰은?, 메시지 종류는?, 프로토콜은?, 데이터 포맷은?.
서버 개발되기 전에 이 문서를 받아야 한다. 한꺼번에 모두 다 받아야 한다. 그렇지 않으면 계속해서 서버 문서를 보고 확인하고 코드를 고치는 과정을 반복하게 될 것이다. 문제가 발생할 때마다 서버가 변경되었다는 어설픈 변명을 하는 개발자가 되는 것은 정말 불편하다.
문서에는 버전이 꼭 적혀 있어야 한다. 지금 서버에 최신 버전이 동작하고 있다고 누군가 알려준다면 그것 말고 버전을 알려달라고 요구해야 한다. 버전은 문서와 코드의 연결고리다.
알아서 동작하게끔만 만들어 주세요.
알겠다고 돌아서면 안 된다. 요청하는 사람의 마음을 알 수 없음으로 내 마음을 알려주어야 한다. 모든 색상은 검은색으로 폰트 크기는 16px 폰트는 시스템 디폴트로 팝업은 window.alert, window.confirm, window.prompt 만 사용하며 모든 텍스트는 왼쪽 정렬 input, select 모두 CSS 없이 HTML 그대로 사용하고 아이콘은 없고 브라우저는 크롬만 지원하고 반응형은 없고 모바일은 지원하지 않고 헤더, 왼쪽 메뉴, 바디, 푸터 구조로 가고 푸터를 포함하여 아래 스크롤하고 인증은 서버에서 제공하는 한 개의 토큰을 사용하고 10분마다 갱신하고 서버 연동은 레스트 풀 API만 사용하고 XSS 지원하고 CSRF 지원하지 않고 한글만 지원하고 단위 테스트는 없고 스토리 북은 사용하지 않고 센트리는 넣지 않고 로그인 페이지를 포함 3페이지를 가지고 추가로 에러 페이지는 한 개만 가지고 텍스트 줄 바꿈은 line-height만 사용하고 언어는 한글만 지원하고… 포기하지 말자.
우선 사용할 기능입니다. 임시로 만들어주세요.
이렇게 하면 안 된다. 이번만이라는 특별한 기간은 없다. 요청한 사람이 내일 퇴사할지도 모른다. 주간 보고서에 ‘임시로 사용할 기능을 추가했습니다.’라고 적을 수는 없다. 잘못하면 임시 개발자가 된다. 1단계 완료라고 적을 수 있어야 한다. 우선, 임시 이런 말은 없다. 정확히 어디까지가 1단계인지 정의해야 한다.
우선 개발하세요
그러면 안된다. 명확하게 지정해야 한다. 기획서를 세세히 나누어서 단계를 지정해야 한다. 1단계에서는 요기 저기를 개발합니다. 1단계 개발 중에 1단계가 변경되면 변경된 부분은 1단계가 아니고 2단계입니다. 차가운 것이 아니다. 명확하지 않은 업무는 언젠가 터지는 폭탄 같은 것이고 잠들 때마다 고민하게 되고 회의 때마다 조마조마하다. 단계별로 나누어진 기획서는 우리 모두를 꿀잠 자게 해 준다. 내가 어떤 계획으로 어떤 일을 하고 있는지 온 회사 사람이 알도록 광고하자. 회의 때마다 상시 시켜주거나 문서로 만들고 링크라도 공유해야 한다. 일 준 사람만 내가 무슨 일을 하는지 알고 있다면 위험하다. 아무 일도 하지 않는 것처럼 보일 수 있다. 우선 개발하면 안 된다. 계획이 있어야 한다. 그래야 성공도 있고 실패도 있다.
모바일 용으로 한 페이지만 만들어주세요.
함박웃음을 지으면서 문제없다고 이야기하면 안 된다. 어쩌면 가로 폭이 짧고 UX가 조금 달라진다고 생각할지도 모르지만 그렇지 않다. 모바일 장치 종류, 모바일 장치에서 사용하는 브라우저 종류는 생각보다 다양하며 데스크톱 브라우저와는 동일하게 동작한다고 보장할 수 없다. 메모리도 작고 네트워크 속도도 느리다. 브라우저에서 지원하는 API도 서로 다를 수 있다. 정확하게 몇 대의 장치를 대상으로 개발해야 하는지 확인해야 한다. 예를 들면
아이폰 8의 최신 크롬 브라우저 xx.xx 버전 이상
이렇게 명확한 레퍼런스 폰을 지정해야 한다. 지정된 폰을 기반으로 개발하고 같은 폰으로 QA에서 테스트해야 한다.
모바일 버전을 요구할 경우 큰 버튼을 작은 버튼으로 만드는 정도의 수고로만 생각할 수도 있다. 10 페이지가 있는데 1페이지만 모바일 용이라면 상호 페이지 이동이 가능한지도 물어봐야 한다. 모바일 장치를 어떻게 구분하려고 하는지도 물어봐야 한다. 네이버나 다음처럼 pc 버전 보기 버튼이 있는지도 확인해야 한다.
이런 여러 제한사항을 미리 말하지 않아서 여기저기서 여러가지 폰을 들고 와서 동작이 안된다고 이야기하는 순간 아무 생각도 안 날 것이다. 이런 상황이 오기 전에 놀라지 않게 미리 알려주어야 한다. 덥석 미디어 쿼리를 사용하면 되겠지 반응형 책을 한 권 샀으니 문제없겠지 하면서 코딩의 관점에서 접근했다가는 쓴 맛을 보게 될 것이다.
기획, 디자인, 서버 그리고 프런트엔드를 포함한 어느 하나에서 문제 혹은 불편한점이 발견되면 프런트엔드를 가장 먼저 바라보게 된다. 그때 수많은 눈치를 보면서 머뭇거리는 자신을 상상해 보자. 그러면 지금 거절은 좀 더 쉽게 할 수 있다. 힘들어도 올바른 방향으로 가자고 설득해야 했다. 후회한다.
