개발자의 마음을 들여다 본 적 있나요?
개발자의 언어를 이해하기 위한 소소한 팁
개발 관련 전공을 하지 않은 서비스 기획자라면 개발자와의 커뮤니케이션에 어려움을 겪을 때가 많다.
최근 아주 사소한 용어로 혼란이 있었다. 구조 논의를 하며 우리는 '파일'이라는 용어를 사용하고 있었는데, 나는 압축된 Zip파일 내 낱개 파일을 '파일'이라고 사용하였고 개발자는 낱개 파일을 모두 포함한 Zip 파일을 '파일'이라고 부르고 있었다. 둘 다 '파일'로 부를 수 있겠지만 대화하며 묘하게 핀트가 안 맞아 답답함을 느끼던 중 혹시나 하는 마음에 질문을 했다.
"지금 말씀하시는 파일이 압축 폴더 내 낱개 파일 맞나요?"
"아뇨. 압축됐으니까 당연히 zip 파일을 파일이라고 말한 거죠."
논의 과정에서 서로 다르게 부르고 있었음을 알아차리지 못하고 결론이 났다면 내가 예상하지 못한 구조로 개발됐을 수도 있다.
개발자와 업무 하며 기획자의 역할 중 가장 중요하다고 생각하는 것이 바로 커뮤니케이션이다. 이번 글에서는 기획과 개발 사이의 커뮤니케이션을 하게 되는 배경과 대화 과정에서 개발자를 더 잘 이해하기 위한 노하우들을 기록하고자 한다.
개발자가 질문하는 이유
인터넷에서 새로운 요리 레시피를 찾아 따라 하고 있는데 “소금 적당히”라고 적혀 있다면 어떨까? ‘적당히’는 뭘 기준으로 해야 할지 잠시 고민하지 않을까?
개발자가 질문을 하는 이유는 기획의 정의가 잘 이해되지 않거나 추가 정의가 필요하기 때문이다. 그래서 기획서는 최대한 명확한 용어로 기재해야 한다.
예를 들어, 게시일시 표기를 희망하는 영역에 대해 정의할 때도 “게시일시 표기”보다는 “게시일시(yyyy.mm.dd hh:mm) 표기”와 같이 예시를 포함하여 초를 제외하고 분까지 표기할지 등을 함께 작성하는 것이 더 명확하다.
기획서는 최대한 명확한 표현을 사용하여 작성한다. 예시와 함께.
‘당연히' 되는 건 없다.
스마트폰을 익숙하게 사용하다 보면 종종 착각할 때가 있다. 이 정도는 OS에서 알아서 해주는 게 아닐까?
하지만 컴퓨터를 움직이게 하기 위해서는 우리의 생각보다 아~주 아~주 사소한 것까지 개발자의 코딩이 필요하다. (개발자는 말썽쟁이 컴퓨터를 육아 중이다.)
컴퓨터가 생각하는 것처럼 작동된다면 개발자가 코딩을 했다는 것을 의미하고, 코딩을 했다는 건 개발자의 의도가 담겼다는 것이고, 그 의도는 기획과 맞춰져야 한다. 그래서 기획자와 개발자는 사소하고 당연한 것까지도 상세하게 문서에 정리하여 커뮤니케이션해야 한다.
예를 들어, 어떤 앱에 들어갔더니 네트워크가 연결되어 있지 않을 때 노출되는 팝업이 있다. "네트워크 연결이 필요합니다."이 팝업 창이 뜨는 것도 당연한 것이 아니다. 앱 사용이 먹통이 되었을 때 사용자들이 앱이 작동하지 않음을 궁금해할 것을 미리 계산하여 팝업 창에 대해 정의하고 개발된 것이다.
주니어 기획자들이 쉽게 할 수 있는 말 중 하나가 "이 페이지랑 똑같이 해주세요."라고 요청하는 것인데, 사용자 눈에 똑같아 보이더라도 각각의 페이지 정책이 어떻게 되어 있는지, 하다 못해 노출되는 팝업의 문구라도 변경이 필요한 건 없는지 꼼꼼하게 살펴보아야 한다.
상세하게 정의하지 않으면 개발자는 이럴 땐 어떻게 처리하길 원하는지 질문하기 위해 메신저 창을 열 수밖에 없다. 그렇지 않으면 여러 번 수정하는 일이 생기기 때문이다.
컴퓨터가 스스로 하는 건 없다. 가능한 상세하게 기획해야 한다.
어떤 개발자에게 질문해야 할까?
기획자가 개발자와 일을 하다 보면 역할에 따라 다양한 개발자를 만나게 된다. UI를 담당하는 개발자, 서버를 담당하는 개발자, 클라이언트(앱 또는 웹)를 담당하는 개발자 등등.
특히 서버 개발자와 클라이언트 개발자는 각각 어떤 업무를 하는지, 어떤 영역으로 나눠져 있는지 이해하면 좀 더 빠르게 담당자를 찾아 문의할 수 있다.
컴퓨터는 요청과 응답의 구조로 작동된다. 클라이언트가 요청을 보내고 서버는 각각의 요청에 대한 응답을 보내준다. 이 요청과 응답을 원활하게 하기 위해 클라이언트와 서버 담당자가 정해 놓은 수신호 같은 체계가 있다.
"이 기능은 여기로 요청하면 이렇게 응답하겠다." (*보통 현업에서는 '응답한다' 보다는 '서버가 내리면 클라이언트에 뿌려진다’고 표현한다.)
이걸 API라고 하는데, 서버개발자가 목업(규칙)을 만들어 공유하면 클라이언트 개발자는 목업에 따라 요청을 보내도록 개발하게 된다. 기획자가 이 API를 이해한다면 개발 구조를 좀 더 쉽게 파악할 수 있다.
API의 개념에 대해서는 아래의 글이 잘 설명하고 있어 대신한다.
https://maily.so/grabnews/posts/b2341a
API에 대해 궁금하다면 OpenAPI를 통해 규격을 참고해 보는 것도 방법이다. Open API란 다른 서비스에서도 데이터를 활용할 수 있도록 API 규격을 공개한 것을 말한다. 예를 들어 카카오가 아닌 다른 서비스에서도 카카오에 가입한 아이디와 패스워드를 통해 로그인이 가능할 때가 있는데, 이는 해당 서비스가 카카오에서 공개한 API 규격에 따라 요청을 했기 때문에 가능하다. 그럼 카카오에서 제공하는 개발자를 위한 "카카오 디벨로퍼" 페이지를 보며 API를 이해해 보자.
https://developers.kakao.com/docs/latest/ko/kakaologin/rest-api
로그인 요청 API의 시퀀스 다이어그램을 살펴보면 'Service Client'와 'Service Server'가 있다. 사용자가 카카오 소셜 로그인을 이용할 수 있도록 제공하고 싶은 타 서비스의 클라이언트(앱)와 서버를 의미한다. 그리고 우측에 'kakao Auth Server'는 해당 계정으로 로그인 요청이 왔을 때 카카오 회원에 대한 인증을 보내주는 카카오의 서버를 의미한다.
사용자가 타 서비스에서 [카카오 소셜 로그인 하기] 버튼을 누르면 해당 앱에서 자사의 서버로 카카오 로그인 요청을 보낸다. 그럼 해당 앱의 서버는 응답해 줄 수 있는 정보가 카카오에 있기 때문에 [1] 번과 같이 카카오 인증 서버로 카카오에게 요청을 보낸다.
'카카오, 우리 사용자가 너네 계정으로 로그인하고 싶어 해.'
그럼 요청을 받은 'Kakao Auth Server'에서는 다시 해당 앱으로 '그럼 카카오 계정의 아이디랑 패스워드 입력받아줘.'라고 응답한다.
이때 뜨는 창이 '카카오의 계정과 비밀번호를 입력하는 로그인 창이다.' (로그인이 되어 있는 경우에는 카카오 앱이 열렸다가 닫히기도 한다.)
이런 식으로 컴퓨터가 클라이언트의 요청과 서버의 응답을 통해 이뤄진다는 것을 이해하고 나면 컴퓨터가 어떻게 작동되는지 상상하는 것이 조금 더 수월해진다. 이 구조를 이해하면 앱을 검증하다가 에러가 발생했을 때, 어떤 개발자에게 알려야 버그를 더 빠르게 해결할 수 있을지 파악이 가능하다.
개발 구조를 이해해 볼수록
담당 개발자를 더 빨리 찾을 수 있다.
이렇게 클라이언트와 서버의 역할을 이해하게 되면 서비스 배포 후 발생할 수 있는 리스크를 줄이기 위한 작업 주체를 정할 때도 도움이 될 수 있다.
응답만 변경할 수 있게 서버만을 활용하기
사용자들은 앱 마켓에서 특정 버전의 앱을 다운로드한다. 그리고 이렇게 다운로드된 앱을 서비스 회사에서 업데이트하여 다시 마켓에 올리면 사용자들은 상위 버전의 앱을 쓰기 위해 앱 업데이트를 해야 한다. 그래서 2.0 버전의 앱에 새로 추가된 기능은 1.0 버전의 앱을 사용하는 사용자는 쓸 수 없다.
이런 환경에서 만약 1.0 버전의 앱에서 수정하고 싶은 내용이 있다면 어떨까? 개발자는 새로운 버전으로 수정하여 앱을 마켓에 올리고 심사를 통과한 후 사용자에게 전달되더라도 사용자들이 앱 업데이트를 하지 않으면 계속해서 수정되지 못한 앱을 사용해야 한다.
그런데 만약 수정하는 방법이 클라이언트에서는 요청 방식을 수정하지 않더라도 서버에서 응답만 다르게 해 줄 수 있다면 앱을 업데이트하지 않아도 수정된 내용으로 사용자들에게 전달하는 것이 가능하다.
어떻게 가능할까? 비유를 해보자.
엄마(클라이언트)가 외출하며 냉장고 두 번째 칸에 있는 김밥을 꺼내 먹으라는 쪽지를 남겼다. 그런데 그 사이 집에 있던 동생(서버)이 김밥을 자기 방으로 가져갔다. 이제 난 냉장고 두 번째 칸에서 김밥을 찾을 수 없다. (에러 발생)
꼭 엄마가 '김밥이 동생 방에 있다.'라는 새로운 쪽지로 써줘야 할까? 만약 동생이 김밥을 다시 냉장고 두 번째 칸으로 옮겨 놓을 수 있다면 엄마의 쪽지를 수정하지 않아도 김밥을 찾을 수 있다.
외출한 엄마가 집에 돌아와 첫 번째 쪽지를 버리고 새로운 쪽지를 작성하여 내게 전달하는 것은 번거롭고 새 쪽지를 쓰더라도 내가 그 쪽지를 못 볼 수도 있다. 그러나 집에 있는 동생이 김밥을 다시 제 자리에 가져다 놓는다면 나는 김밥을 얻을 수 있다.
서버는 집에 있는 동생처럼 클라이언트보다는 비교적 쉽게 응답을 바꿀 수 있다. 그러나 클라이언트는 외출한 엄마처럼 요청하는 정보를 수정하는데 어려움이 있다. 과거의 버전을 제거하고 새로운 버전을 생산해서 제공해야 하기 때문이다. 그 버전은 사용자에 따라 전달되지 않을 수도 있다.
그래서 변동성이 있거나(ex. 변경이 필요한 데이터, 시의성이 있는 영역의 노출) 리스크가 있다고 판단되는 요소들은 앱 업데이트 없이 수정될 수 있도록 서버에서의 처리를 정의하여 리스크 가능성을 줄이는 것도 방법이다.
개발 구조를 이해할수록 기획에서부터 이런 부분을 고려해서 서버의 처리 영역과 클라의 처리 영역을 정의하는 것이 가능하다.
데이터는 어딘가에 저장되고 있다.
요청과 응답으로 작동되는 컴퓨팅 구조에서 적절한 응답을 하기 위해 어딘가에 데이터가 저장되고 있다. 이때 어떤 데이터가 어떤 형태로 저장되고 있는지 이해를 하고 있어야 기획자는 어떤 서비스가 가능한 지 파악할 수 있다.
대부분의 서버는 데이터를 많이 저장할수록 비용이 많이 발생하고 처리 속도가 느려진다. 그래서 데이터를 저장하고 보관하는 기간에 대해 정의를 함께하는 경우가 많다. 또 데이터의 처리 속도가 느려지는 것을 방지하기 위해 연산이 많이 필요한 기능은 메인보다는 다른 영역에 노출되도록 변경하거나 실시간 처리가 아닌 하루 단위로 배치를 돌리는 등 대안을 기획하는 것이 필요하다.
예를 들어, 한 게임 회사에서 서버의 용량과 비용을 고려하여 한 캐릭터의 아이템 거래 데이터를 최신 3개월 동안만 보관하기로 했다. 그러나 마지막 로그인으로부터 5개월 후 로그인한 고객이 보관함에서 아이템이 사라진 것을 발견했다. 고객은 1:1 문의를 통해 확인을 요청했지만 거래 데이터가 3개월 동안만 보관되어 회사는 고객의 사라진 아이템에 대해 거래 여부를 확인할 방법이 없다.
기획자는 이러한 일이 발생하지 않도록 고객이 이 사실을 사전에 인지할 수 있는 안내 페이지를 미리 기획하거나 또는 3개월의 보관 기간이 사용성에 좋지 않다면 더 긴 기간 동안 보관될 수 있도록 꼭 필요한 데이터만 남기거나 로그인 시점에만 데이터를 남기는 등 대안을 찾아 기획하는 것이 좋다.
또 데이터를 새로 저장하게 된다면 오래된 데이터는 언제 제거해도 되는지 시점을 정해줘야 성능 및 서비스 운영에 무리가 없다.
그렇다면 기획을 할 때 데이터 관련해서 어떤 것들을 체크해 보면 좋을지 정리해 보자.
[기획 시 고려해야 하는 데이터 관련 체크리스트]
1. 새로 서버에 저장이 필요한 데이터 구분 (ex. 별도 테이블을 만들어야 서비스가 가능한 지)
2. 첨부한 데이터의 서버 저장 시점 (ex. 이미지 첨부 시 또는 저장 완료 시)
3. 화면에서 데이터를 업데이트해 주는 시점 (ex. 매일 갱신이 필요한 지 또는 pull to refresh 시 갱신 데이터를 보여줄 것인 지)
4. 데이터를 삭제해도 서비스에 이슈가 없는 시점 (ex. 서버를 고려해서 30일간의 알림만 제공하고 삭제할지 등)
5. 데이터 갱신까지 걸리는 처리 속도에 따른 대안 (ex. 배치 데이터의 활용, 캐싱 활용 등)
6. 노출이 딜레이 될 때 처리 방식 (ex. 로딩 아이콘, 에러 팝업 등)
데이터의 보관과 처리에 대해
고려해 보자
서비스 제공을 위해 필요한 데이터에 대한 정보가 있다면 논의가 훨씬 수월하다. 기능을 제공하려면 지금 가지고 있는 데이터로 가능한 지 또는 새로운 데이터 작업이 필요한 지 등을 상상해 볼 수 있다면 어떤 개발자를 회의에 초대해야 하는지, 어떤 내용을 추가로 논의해야 하는지 짐작해 볼 수 있다.
각 영역과 역할을 담당하고 있는 개발자가 모여 논의를 하기 때문에 기획자는 필요한 인력을 모두 초대하여 처음부터 한 자리에서 논의가 잘 이뤄질 수 있도록 하는 게 중요하다.
이번 편에서는 개발자의 언어를 이해하기 위한 소소한 팁들을 작성해 보았는데, 무엇보다 커뮤니케이션을 위해 중요한 건 서로의 관점과 역할, 배경 지식이 다르다는 것을 이해하는 마음이 아닐까? 함께 작고 귀여운 월급을 받으며 하나의 목표로 달려가고 있는 우리. 동료라는 것을 잊지 말고 모두 부드러운 커뮤니케이션으로 평화로운 하루하루를 이어 나가기로 해요.(약속)
