기술검토 : 자동전화, PDS, 오토콜, VoIP
내가 제안서를 쓰면서 배우게된 것들
제안서를 쓴다는건, 기술의 구성요소를 이해한다는 것과 같다
1.
요즘은 제안서를 쓴다. 그게 내 일이 되었다. 다만 문제는 다양한 클라이언트들이 원하는 것들을, 나는 잘 알지 못한다는 것이다. 나도 내가 겪어본 것들을 알 뿐, 모든걸 알지는 못한다. 그래서 '기술검토'라는 이름 아래 그들이 요청을 분석하고, 들여다본다. 그리고 그 과정에서 이 프로젝트에는 무엇이 들어가야하는지. 또 어떤 기술들이 필요한지. 어떤 개발자가 필요한지를 들여다보게된다. 나는 이런 과정을 '기술검토 과정'이라고 부른다.
기술검토는 상대가 만들려하는 서비스가 무엇인지 확인하는 과정이다. 플랫폼은 어떤 구성인지, 어떤 사용자 타입들이 있는지. 그 정보를 구현하려면 어떤 특정 정보를 알아야하는지. 기술적으로 구현이 어렵거나 불가능해지는 지점은 없는지. 프로젝트에 진입하기 이전에 현실적인 내용들을 파악하는 과정이다. 제안서를 쓰기 전에, 단순히 그 대상을 파악하는 과정. 실제로 대부분의 기획자는 바로 이 과정에서 가장 많은 지식들을 얻게된다.
2.
내가 최근에 기술검토를 한 내용들 중에 하나는 '안드로이드 스마트폰' 기준에서 전화를 걸어, 녹음된 내용을 들려주고싶다는 내용이었다. 전화를 걸고, 녹음된 내용을 들려주고... 별로 어렵지 않겠는데? 처음에는 그렇게 생각했다. 하지만 내용을 찾아보니, 상황이 전혀 달랐다. 그 클라이언트는 단순히 '전화를 거는기능'을 넘어서서, 내부에 상담원이 있었고, 그들이 할 일을 덜어주는 기능을 원하는 거였다.
'자동 전화걸기 + 전화통화 성공시 녹음된 내용 들려주기 + 특정 키를 누르면 상담원을 바꿔주기'라는 숨어있는 기능들이 있었다. 그리고 내가 이 내용을 찾아내게된건, '안녕하십니까 고객님'으로 시작되는 광고성 전화를 받은 경험이 있어서였다. 내가 맨 처음 이 기술을 분석하려 파고든것은, 안드로이드 12 버전 이후의 phonecall API 문서였다. 기존에 내가 아는 상식대로라면, 안드로이드는 전화걸기 시작, 실패, 성공 등을 파악할 수 있었다. 그러니 전화를 특정 전화번호로 거는것도 당연히 가능하다고 생각했다.
https://developer.android.com/guide/topics/connectivity/telecom/selfManaged?hl=ko
하지만 실제로 내용을 확인해보니, 안드로이드에서는 '전화를 걸 수는 있어도, 특정 내용을 상대에게 들려주는' 건 불가능했다. 그러니까 전화통화를 시작한다는건, 사람이 이야기를 해야한다는 이야기였다. 여러 문서들을 뒤져봤지만 그 안에서도 나온건 '통화에 대한 녹음을 다중으로 처리할 수는 있다는 결과였다. 다만 여전히 음성입력을 임의로 처리할 수는 없었다.
3.
내가 그 다음에 찾아보기 시작한건 VoIP 전화였다. Voice over Internet Protocol이라는 의미의 약자. 인터넷 기반의 전화니 전화를 거는 기능도 DB에서 처리할수있지 않을까. 그런 생각을 했기 때문이었다. 결과적으로 이 생각은 맞으면서도, 틀린 대답이었다. VoIP 전화는 인터넷 통신망을 통해 목소리를 전달했지만, 전화를 거는 것 자체에 대한 권한은 얻어올 수가 없었다. 심지어 전화를 받았을 때, 그 사람에게 '특정 문자 URL을 전달'하는 기능조차 수행하기가 어려웠다. 왜냐하면 개별 스마트폰에 걸려온 전화번호를, DB에 전송하는 역할을 하려면 무언가가 계속해서 '걸려오는 전화'나 '상대에게 거는 전화'를 지켜보고있어야하기 때문이다.
그러니까 결국 안드로이드 기준으로, 전화를 걸어온 상대나, 내가 거는 상대의 전화번호를 계속 체크해 DB에 쏴주는 과정이 필요하단 거였다. 단순히 SMS 보내기조차 이렇게 복잡한데, 심지어 전화걸기는 더욱 복잡했다. 전화를 건 다음에 그 전화통화 자체를 제어할 수 있는 방법이 없었기 때문이다. 나는 여기에서 계속 의문이 들었다. 분명 '스팸광고'를 전화로 때려대는 업체들이 있지않은가? 그들은 대체 어떤 방법으로 그런 일을 해내는걸까? 결국 내갸 찾아낸 키워드는 PDS / Auto Call이라는 개념이었다.
자동으로 전화를 걸어주고, 상담원에게 연결해주는 기능오토콜 개념을 판매중인 솔루션 업체
http://www.eicn.co.kr/page/autocall.php
http://www.ktt114.com/sub_2.php?t1=4#sub_2_tab1
4.
찾아보니 여러 업체들이 비슷한 형태로 '자동 전화연결' 후 메시지를 틀어주는 솔루션을 판매중이었다. 심지어 특정 액션 이후에 상담원으로 연결시키는 기능도 대부분 제공하고있었다. 하지만 정작 이런 서비스가 어떤 방식으로 이뤄지는가는 알 수가 없었다. 대부분의 서비스가 '서버' 형태를 가진 솔루션이었고, 동시에 정확한 기술구현 방식을 풀어 말해주지 않고있었다. 그러나 내가 알고싶은건 실제로 이 기능을 구현하기위해 어떤 기술이 필요한지. 또 어떤 개발언어로 이뤄져있는 것인지에 대한 부분이었다. 그래서 좀 더 내용을 찾아보던 과정에서, VoIP 전화를 새로 개발하는 방식에 대한 자료를 찾게됐다.
네이버 D2 - 발표자료 : Go 언어 기반의 전화망 서비스 구축
https://d2.naver.com/helloworld/5827706
https://d2.naver.com/helloworld/0814313
이 자료에서 마침내 알게된것들 중 하나는, 우리가 쓰는 전화기는 단순히 '인코딩, 디코딩'의 개념으로 음성정보를 풀어낼 뿐. 실제 전화를 연결하는 기능을 하는곳은 따로 있다는 거였다. 그리고 그 정보가 바로 '교환기'라는 녀석이었다. 이 교환기에서 무슨 일이 일어나는지를 알면, 인터넷 전화기를 컨트롤 할 수 있는 기술도 알 수 있을것 같았다. 그래서 내용을 확인해보니, 그 안에 다시 SIP라는 기술이 사용된다는걸 알 수 있었다.
회색 박스 영역이 사설 교환기를 나타내는 지점
SIP 장비가 아날로그 전화와 IP 전화기를 연결해주는 과정내용이 좀 복잡해보이지만, 내용을 정리하면 대충 이렇다. 아날로그 전화기는 'ISDN'이란 방식으로 통신을 하고있다. IP 전화기는 그와는 다르게 SIP 라는 방식으로 통신을 한다. 서로 방식이 다르지만, 전화선을 기반으로 한 일반 아날로그 전화기와 랜선을 기반으로한 전화기는 서로 통신이 가능하다는 것. 그러니까 결국 '전기신호'로 내용을 인코딩하고, 디코딩하는 단계를 거칠 뿐, 전달하는 정보규격은 거의 동일하다는 이야기였다. 그렇다면 이 SIP라는 녀석을 알아내면, 답이 보이는게 아닐까? 마침내 알아낸 SIP는 실제 IP VoIP 전화와 거의 다르지않은, 핵심기술이었음을 알게됐다.
https://blog.naver.com/romanst/220635666592
5.
네이버 D2에서 나온 자료들을 다시 살펴보면, 결국 어떤 방식으로 전송을 하건. 전화는 전화선이나, 랜선을 통해 특정 패킷정보를 압축해서 전화를 걸게된다. 그리고 그 정보의 규격은 서버에 그대로 남게된다. 그걸 뜯어서 보여준것이 아래의 그림이다. 어떤 전화가 '어디에서, 어떤 정보를 갖고, 누구에게 전달이 되었는지'를 정리해준 것이다. 단지 그 형태가 조금씩 차이가 있을 뿐, 그 안에는 'IP정보'가 들어있었다. 인터넷에 접속할 때, 우리가 쓰는 URL도 사실상 IP주소로 변환된다. 그래서 그 IP주소에 http:// 로 시작하는 URL을 연결해둔 것이 Http 주소값이다.
IP 전화도 마찬가지였다. 특정 IP를 향해서 보내는 정보이다보니 '어떤 IP'에서 시작해서, '어떤 목표 IP'로 가는지에 대한 정보가 적혀있었다. 그러니 VoIP 전화든, SIP 전화든 간에 'IP주소'를 건드리고, 그 정보들을 실제로 보내주는 역할을 하는 녀석이 있다는 거였다. 그리고 그 역할을 하는게 전화망 서버였다. 그러니 네이버 클로바의 AI 음성비서도 자체적인 전화망 서버를 만들기 위해 GO 언어를 썼다는 내용을 알 수 있었다. GO 언어는 C언어와 C++로 만들어진 언어이니. 결국 '디바이스를 다루는 기계어' 기반으로 해당 정보를 컨트롤 할 수 있다는 걸 알게되는 순간이었다.
자세히 보면 128과 224로 시작하는 IP 정보가 적혀있다.우리가 찾는 기능은, 이미 솔루션으로 만들어졌을 가능성이 높다.
6.
결과적으로 왜 네이버나, 다른 PDS / 오토콜 업체들이 '서버' 단위로 서비스를 판매하는지도 알 수 있었다. 서버를 만들어야 실제 전화걸기를 처리하는 '가상 전화망'을 만들 수 있었다. 그리고 전화기능을 서버상에서 다루려면, 일반 전화보다 VoIP 전화가 더 편리하다는 것도 알게됐다. 결국 짧게 정리해보면, VoIP 전화기를 기반으로 그 전화에서 뽑아져나온 데이터를 '어디에 보낼지' 전화망 서버 기준으로 RTP란 패킷형태로 입력을 해주면 된다는 거였다. (물론 이게 내가 제대로 이해한 것인지는 잘 모르겠다)
또한 이런 서버를 컨트롤하기위해서는 C 언어나 C++ 언어를 바탕으로 '서버'를 이용해 '정보를 전송해주는 역할'을 해줘야한다는 것도 알게됐다. 서버라는건 결국 PC고, 그 PC를 다루는 언어가 기계어인데, 그걸 변환한게 C언어이니. C와 C++ 계열 언어인 GO로도 PC나 서버를 다룰 수 있었던 것. 결국 전화를 중간에 가로채거나, 다른 인원에게 연결시켜줄 수 있었던 것도, 중간에 전화망 서버가 특정 패킷을 컨트롤 할 수 있었기 때문이었다. 특정 ARS 녹음음악을 들려줄 수 있었던 것도, '가상의 전화망'을 통해서 특정 음원을 들려주는 형태로 처리했다는 거였다.
결국 - 맨 처음 질문이었던, 안드로이드 통화에서 녹음된 목소리를 들려주려는 방식은 실패로 돌아갔다. 안드로이드 OS에서는 전화통화라는 것 자체를 '전화망' 레벨에서 건드릴 수가 없기 때문이다. 그러니 별도의 서버에서 '가상 통화망'을 구현하고, VoIP 정보를 포함해 Web에서 실제 전화로 통화를 거는 기능을 구현해야했다. 이걸 Web to Phone 전화라고 하는데, 우리가 자주 쓰는 ZOOM 같은 서비스도, 사실상 Web to Web의 가상전화망을 사용한 서비스란것도 알게됐다.
https://explore.zoom.us/ko/virtual-phone-system/
ZOOM에서 제공하는 VoIP 전화 서비스. ZOOM의 영상통화나 전화통화는 모두 가상전화망을 통해 전송된다7.
대부분의 기술검토는 이런 '꼬리에 꼬리를 무는' 개발 언어와, 기존 솔루션에 대한 분석과정으로 이어진다. 그 과정에서 이 기술이 갖고있는 핵심내용을 분석할 수 있으려면, 개발에 대한 상식이 상당히 많은 영역을 차지한다. 또한 이런 내용을 자체적으로 개발하는 방향 외에도 이미 나와있는 여러 솔루션들을 파악해두는 것도 상당히 중요하다. 그들이 나와 비슷한 고민을 해서 만들어낸 것이 응용 솔루션이니까. 그들이 어떤 기술을 쓰고있는지를 파악하면 역으로 그들의 기술을 비슷하게 만들어낼 수 있다는 이야기가 된다.
나중에는 기술 검토를 복잡하게 하지 않아도 '아 그 기술, OO와 ㅁㅁ가 합쳐져서 만들어지지' 라고 말할 수 있는 때가 오게되겠지. 그 전까지는 이런 개고생을 계속해서 할 수 밖에 없다. 그게 기획자가 해야하는 기술검토 업무고, 이런 과정에서 경험치와 지식을 얻게되니까. 어찌보면 앞으로도 피할 수 없는 문제가 될 거라고 생각한다. 이런 과정을 얼마나 더 깊이있게 해낼 수 있는지. 그리고 얼마나 '정확히 캐치해서 제안서로 쓸 수 있는지'가 문제가될 것 같다. 결국 내가 기술의 구성요소를 제대로 이해하지못하면, 이 기술을 구현할 수 있는지를 판단할 수 없다.
-
아는 만큼 이야기할 수 있고, 보이는 만큼 설득할 수 있다. 그건 어디까지나 변하지않는 지점일것 같다.
