개발자가 서비스 운영 측면에서 커뮤니케이션 비용을 줄이는 방법

개발자는 회사 서비스에 주도적으로 기여할 수 있는 부분이 많다. 회사 내의 각 직군들은 각자의 방법으로 서비스에 기여하고 있지만, 개발자는 업무 특성상 시스템 내부에서 서비스를 바라볼 수 있기 때문에 다른 직군보다 기여할 수 있는 요소를 파악하기 쉽기 때문이다.

개발자가 서비스 운영 비용을 줄이는 데에는 다양한 방법이 있을 테지만, 이 포스팅에서는 '커뮤니테이션 비용' 측면에서 이야기해보려고 한다. 이걸 위해 엔지니어링 지식이나 엄청난 기술 역량이 필요하지는 않다. 토이 프로젝트에서도 작게 시도해볼 수 있는 부분이 많으니, 한번 생각해보자!

고객님, 잠시만 기다려주세요

김개발이 진행 중인 프로젝트에서 외부 API를 응답하는 데에 10초가 소요된다(!) User flow상 해당 API는 5분 내로 3~4번 호출될 것이기 때문에 김개발은 속도 향상을 위해 처음 API의 결과를 캐싱하기로 한다. 총 소요 시간을 줄인 김개발은 뿌듯했다. 하지만 김개발이 예상하지 못했던 것은 고객이 최초 API 결과가 캐싱되는 것을 기다리지 않고 계속 요청하는 일이었다.

한 번에 10초가 걸리는 외부 API 요청

외부 API는 나의 시스템에서 컨트롤할 수 없는 영역이기 때문에 더 이상의 속도 개선이 어렵다. 컨트롤할 수 없는 영역에 대해서 내부적으로 더 이상의 개선이 힘들다면, 외부에 그 상황을 간접적으로 노출하는 방법도 있다. 사용자가 영문도 모른 채 기다리는 게 아니라, 작은 프로그래스 바나 메시지를 통해 서비스가 열심히 일을 하고 있음을 알려주는 것이다.

고객님의 정보를 분석 중입니다.
■■■■□□□□□□ 42%

(소근소근) 이 정도로 오래 걸리면 서비스 출시 전에 회사 내부에서 이슈가 될 테니 미리 고민해보는 것도 좋다.

휴먼 에러에 대한 친절한 메시지(1) - 비즈니스 부분

비즈니스 상 자주 발생하는 휴먼 에러들이 있다.

예를 들어, 당뇨 환자의 혈당을 측정하는 자가 진단 기기는 비정상적인 혈당이 감지되면 오류가 발생한다. 대부분의 경우 과자나, 아이스크림 등 달콤한 음식을 먹고 손을 씻지 않는 상태에서 손가락의 피를 채혈을 했기 때문에 혈당이 굉장히 높게 측정되는 것이다.

회사에서 운영중인 서비스 중 하나는 비정상적인 혈당입니다 라는 말 대신에 비정상적인 혈당입니다. 혈당 측정기를 종료 후 손을 씻고 다시 측정해주세요. 라고 안내를 바꾼 뒤에 회사로 들어오는 CS가 상당 부분 줄어들게 되었다고 한다.

사실 이런 부분은 서비스를 운영해봐야 알 수 있는 것들이 많다. CS에 대해 어느 정도 팔로우 하다가 고객에게 안내가 필요하겠다는 생각이 들면 팀 내부 혹은 기획자와 논의하여 안내 방법을 결정하자. 도메인 지식과 비즈니스에 대한 이해도가 많은 이들이 모여 상의하면 더 친절한 메시지를 줄 수 있을 것이다.

휴먼 에러에 대한 친절한 메시지(2) - 공통 부분

대부분의 서비스에는 로그인 기능이 존재한다. 그렇지만 같은 로그인 절차라도 서비스마다 처리 방식이 다르다.

아이디를 소문자로 관리하는 경우, 사용자가 Caps lock이 걸려있는 상태로 대문자 입력 시 소문자로 입력하세요. 라는 불필요한 안내 대신에 시스템이 내부에서 소문자로 치환하여 처리할 수 있다. 하지만 비밀번호 같은 경우 사용자가 입력한 값을 그대로 처리해야 하기 때문에 Caps lock이 걸려 있다고 로그인 하단에 안내를 해준다.

내가 경험한 서비스 중 최악의 로그인 실패 경험은 Alert메시지+ID/PW클리어+포커스 아웃이다. 로그인 실패 시 Alert 메시지가 발생한다.

로그인 실패 시 Alert 메시지 발생

메시지 확인 창을 누르면 ID/PW가 클리어되고(ID는 유지해줘도 되잖아), 포커스가 딴데로 튄다(그래서 또 눌러야함).

로그인 실패 후 Alert 창을 닫은 상태

그리고 만족스러웠던 로그인은, ID 대소문자를 구분하지 않고 로그인 실패 시에는 PW만 지워지고 포커스가 유지되는 거였다.

Alert 메시지처럼 사용자의 흐름을 방해하는 안내 방법은 되도록 자제하도록 하자. Alert 메시지는 서비스 사용자의 숙련도, 해당 케이스의 반복되는 정도, 그리고 실패 시 위험정도(?)에 따라 사용 여부를 결정하는 게 좋겠다. 로그인 시도 같은 경우 여러 서비스에서도 경험해보았기 때문에 사용자들이 숙련이 되어있고, 한번 실패하면 여러 번 시도할 수 있다. 그래서 Alert 메시지 보다는 다른 방식으로 안내하는 게 좋을 것 같다.

그리고 이런 메시지 처리는 보통 예외처리와 같이 시스템 전반에 공통적인 룰로 적용하는 것이 관리하기 좋다. 비즈니스 부분과 공통적인 부분에 대한 에러처리를 케이스별로 생각해두는 것도 도움이 된다.

외부 장애에 대한 서비스 대응

외부 API 서버가 장애가 나거나, 이상한 값을 던지면 그 영향으로 나의 서비스에서 오류가 발생한다. 우리 서비스에서 오류가 난 게 아니더라도 사용자는 맨 앞에서 서비스를 책임지는 곳에 문의를 한다.

사용자 : 이거 왜 안되나여?
사내 대응팀(CS) : 개발자님, 이거 왜 안되나여?

개발자 : 이거, 우리 서비스 문제는 아니네요.

사내 대응팀(CS) : ?
사용자 : ?

여기서 문제는, 외부의 문제를 그대로 자사 서비스에 노출했다는 점이다. 일단 에러가 나지 않는 것 처럼, 서비스가 정상적으로 운영될 수 있도록 생각해보고, 장애를 빨리 대처할 수 있는 프로세스를 구축하자!

1. 장애 발생 시, 개발자가 제일 빨리 알 수 있도록 슬랙 등을 통해 메시지를 받게 구현(근데 모든 오류 말고 치명적인 오류들만 선별, 너무 자주오면 슬랙 안보게됨) → 많은 고객이 알기 전에 장애 대처

2. 사용자에게는 오류 상황 안내(Alert메시지 등) → 자사로 오는 CS 줄이기

외부와의 커뮤니케이션을 위한 로그 쌓기

위 상황과도 연결되는 내용이다. API 이력, 특히 외부와의 인터페이스 내역은 로그를 남겨두는 것이 좋다. 로그는 서로를 보호해주는 기능을 한다. 외부와 인터페이스 송수신 시, 장애가 발생하면 보통 원만하게 넘어가기는 한다. 개발자들은 오류 내용을 보고 각자의 시스템에 문제가 없는 지 다시 살펴 보고, 개발자들의 말을 해석해서 대신 전달하는 팀(영업팀, 기획팀 등)은 외부와 커뮤니케이션한다. (근데 말이 길어지면 개발자끼리 대화하게 된다.)

로그를 쌓지 않는 경우에는 오류가 왜 발생했는지 추측할 수 밖에 없기 때문에 서로의 말을 믿기 어렵다. 그렇게 되면 '우리 시스템은 괜찮은데, 너네 뭐 잘 못 수정한 거 아니야?' 라는 뉘앙스가 나오기 쉽다. 외부와 소통하는 팀에서는 개발자의 말밖에 믿을 수 없기 때문에, 개발팀에서 자료에 근거하지 않고 추측성의 의견을 낸다면 조금 당황스러울 수 있다. 서로 기분이 상하지 않기 위해서는 로그를 보고 request와 response를 토대로 분석하는 것이 좋다.

둘 중 어느 서비스에서 영향도를 예측하지 못하고 수정을 했을 수도 있고, 서로 협의하지 못했던 비즈니스 케이스가 존재할 수도 있다. 로그를 쌓는 것은 서비스 구현에서 급하지는 않지만, 서비스 운영에 있어서는 매우 중요한 부분이다. 로그는 서비스의 일부분으로 생각하는 것이 좋다.

롤백할 수 있는 단위로 커밋하기

커밋은 롤백할 수 있는 단위로 구성하자. 이런 커밋 단위는 예상치 못한 장애가 발생했을 때 빠르게 롤백 포인트를 잡을 수 있도록 도와준다. 서비스 장애가 나면 개발자만 땀나는 건 아니다. 일단 원인 파악이 빨리 되지 않을 것 같다면 롤백부터 해보자. 후우, 생각만해도 살 떨리네. 그리고 이걸 지키려고 노력하면 커밋 단위가 자연스럽게 요구사항 단위, 혹은 더 작은 기능 단위로 자연스럽게 묶이는 것 같다. 비즈니스 히스토리가 단계별로 남기게 되니 훗날 인수인계 받는 개발자에게도 도움이 되지 않을까? 어찌 되었든 미래의 나에게는 도움이 되는 것 같다.

나에게 온 질문은 답변까지 담당하기

개발자가 아닌 팀원이 볼 때 '이 일은 누구한테 물어봐야지?' 싶은 일들이 많이 있다. 사실 개발자들이야 이런 요구사항이 프론트엔드 쪽인지, 서버 쪽인지, 그리고 그 일의 담당자는 누구인지 추측할 수 있겠지만 다른 팀원이 볼 때에는 어느 팀에 물어봐야할 지 조차 모를 수 있다.

기획자 : 개발자님, 이거 변경이 필요한데 혹시 가능한가요?
나 : 아, 이거 제 쪽이 아니니까 A님(서버개발자)한테 여쭤보세요.

본인이 구현하지 않는 기능에 대한 질문을 답변하는 것은 개발자의 책임도, 개인에게 명확히 할당된 업무도 아니다.
물론 담당자를 알려주는 것 자체는 나쁘지 않지만 그분(기획자)에게 발생되는 커뮤니케이션 비용은 개발자인 내가 치루는 비용보다 클 것이다.
만약 개발자가 질문에 대한 간단한 답변(설명)과 담당자 소개, 그리고 어떻게 진행해야하는 지에 대한 짧은 안내를 하면 서로 일하기 수월하지 않을까?

기획자 : 개발자님, 이거 변경이 필요한데 혹시 가능한가요?
나(개발자) : 아, 이 기능은 제가 담당하고 있지만 세부 요구사항 구현은 A님(서버개발자)님이 담당하고 있어요.
제가 이 부분은 전달해서 기획자님께 답변해달라고 할게요.

혹은 다른 팀의 업무라 자세한 내용을 모를 경우에는 이렇게 대답할 수도 있다.

나(개발자) : 아, 이 부분은 클라이언트에 영향이 가는 부분이에요.
서버에서는 이미 구현된 부분이라 클라이언트쪽에만 확인하면 될 것 같아요.
담당자는 *** 기능을 맡고 있는 B님(프론트앤드개발자)이니 이분께 여쭤보세요.

---

회사에서 발생하는 커뮤니케이션 비용을 줄이고, 서비스의 품질을 높이는 방법은 더 있을 것이다. 틈틈이 발견하면 추가해보겠다 :)

(+) 2020.11.15 : 나에게 온 질문은 답변까지 담당하기