출시 이후를 먼저 설계하는 이유

개발이 끝난 서비스를 넘겨받아 보면 비슷한 장면을 반복해서 마주합니다. 화면은 잘 나와 있는데, 문구 하나 바꾸려면 개발자를 불러야 합니다. 기능은 있는데 운영자가 쓸 수 있는 관리자 화면이 없습니다.

처음 만들 때는 이런 것들이 잘 보이지 않습니다. 눈에 보이는 화면이 먼저 급하고, 관리자 화면이나 예외 처리는 나중 일처럼 느껴지기 때문입니다.

그래서 순서를 바꿉니다

넥스트데브는 기능 목록을 받으면 먼저 이 서비스가 6개월 뒤에 어떤 모습으로 운영되고 있을지를 묻습니다. 누가 데이터를 넣고, 무엇이 매일 바뀌고, 어떤 숫자를 보게 될지. 그 답이 나와야 화면 구조와 데이터 구조를 정할 수 있습니다.

이 과정은 초기 일정을 조금 늘립니다. 대신 출시 이후 같은 화면을 다시 뜯는 일을 줄입니다. 전체 비용으로 보면 거의 항상 이쪽이 쌉니다.

기준 세 가지

• 운영자가 개발자 없이 바꿀 수 있는 범위를 최대한 넓힌다
• 기능을 더할 때 기존 화면을 건드리지 않아도 되게 나눈다
• 장애가 나면 어디가 문제인지 바로 보이게 로그와 알림을 남긴다

화려한 원칙은 아니지만, 오래 굴러가는 서비스는 대부분 이 세 가지를 지키고 있었습니다.