brunch

You can make anything
by writing

C.S.Lewis

by 앤더슨 Jan 31. 2023

개발 지식 보강 후 다시 살펴본, 토스의 간편 송금

테크니컬 Flow Chart와 회고 [PMB 코드스테이츠 16기]




위의 글에서 이어지는 회고 내용입니다.



과연 2주 동안 나의 개발 지식은 얼마나 보강이 되었을까.?

한 번 살펴보는 시간을 가지도록 하자.





Flow Chart



As-Is 

이전에 그려본 Flow Chart


2주 전 제작한 토스 간편 송금의 Flow Chart



2주 전에는 단순히 고객의 간편 송금 여정을 담고 있는 Flow Chart를 작성했다면,

현재는 Client, Server, Data의 흐름과 구조가 포함된 조금 더 구체적이고 복잡한

Technical Flow Chart를 제작할 수 있게 되었다.




To-Be 

이후에 그려본 Flow Chart


UI Flow


토스 간편 송금 Technical Flow Chart


그리 복잡한 구조나, 서버와 데이터의 구조와 흐름을 잘 정리한 Technical Flow Chart는 아니지만

불과 며칠 전 고객 흐름만을 나타내는 Flow Chart 보다는

조금 더 복잡하고 구체적인 차트를 표현할 수 있게 되었다.


그렇다면, UI(User) / Client / Server / Database를 바라보는 나의 시선은 어떻게 바뀌었을까?



- UI(User Interface)


UI에 대한 관점은 크게 변하지 않은 것 같다.

UI는 고객에게 눈에 보이지 않는 소프트웨어 서비스의 실체를 보여주는 역할이며,

고객이 보는 화면 모든 것을 설계하는데, 고객이 입력한 입력값에 대한 결괏값을 실시간으로 보여줘야

하기 때문에, 백엔드(서버)와 보다 밀접하고 긴밀하게 소통하고 설계되어야 한다.


위의 제작된 이미지처럼,

고객이 계좌를 선택하는 화면, 입력하는 텍스트 상자, 누르는 버튼 등을 구현하는 역할이라고 생각하면 쉽다.




- Client


API 개념을 배우고 나선, Client을 바라보는 관점이 변화한 것 같다.

사용자가 필요한 정보를 클라이언트를 통해 서버로 전송하면 서버에서는

이 정보를 사용해 사용자에게 필요한 정보를 클라이언트로 전달하게 된다.

이 과정을 API라고 하는데 API의 시작점이자, 마무리 지점이 Client이다.


실제로 Flow Chart에서도 흐름과 행동 나타내는 중심에 존재하고 있으며,

Server에 데이터를 요청하고, 받아온 데이터를 표현하는 역할을 하고 있다.




- Server


인터넷 기반 서비스는 사용자가 클라이언트에 접속하면,

인터넷을 통해 사용자의 요청을 서버에서 전달하고 이를 처리해

인터넷을 통해 다시 클라이언트에 전달해 주는 구조이다.

API를 클라이언트가 요청한다면, 그 요청에 응답해 주는 것이 서버인 것이다.


위의 이체 / 송금 과정에서도 클라이언트의 요청에 따라 서버가 데이터 베이스의 데이터를 가져오고,

다시 클라이언트에 제공하는 처리 과정의 중심에 있다는 알 수 있다.

데이터를 주고받는 방식으로는 JSON, XML 등이 존재한다.




-Database



클라이언트를 통해 유입된 사용자의 요청들에 따라 서버는 필요한 기능을

수행해 클라이언트로 전송하게 되고, 서버는 요청한 기능을 수행하기 위해 데이터가 필요한데,

이 데이터들이 데이터베이스에 저장되어 있다.

데이터 베이스는 데이터를 저장하는 데이터 서버, 데이터를 관리하는 DBMS,

데이터를 다루는 언어인 SQL로 구성되어 있고, 고객 데이터 처리뿐 아니라

IT 서비스의 모든 데이터 처리는 데이터베이스에서 진행된다.


오픈 뱅킹 서비스 또한 클라우드 서비스를 통해서 데이터 베이스에 접근하여 정보를 가져오고,

생체 인식, 비밀 번호와 같은 데이터 역시 데이터 베이스에 저장되고, 요청하여 가져올 수 있다.



토스의 간편 송금 기술 구조



사실, 2주 전에 개발 지식을 공부하기 이전에 비해서 내용과 살이 붙지 않고 오히려 줄어든 것 같지만,

그 속은 PM이 접근하고 이해해야 하는 분명하고 명확한 지식을 잘 정돈하여 알맹이만 남도록

그 모양을 잘 재단한 것 같다. 

PM에게 요구되는 역량은, 깊은 개발 지식의 이해 같은 것이 아니다.

모든 이해 관계자들과의 원활한 소통, 즉 위에서 말하는 상호 작용을 돕는 API와 같은 존재가 되는 것이다.

API에 문제가 생기면 클라이언트는 서버에 데이터를 요청하거나 표현할 수 없고,

서버는 클라이언트에 데이터를 제공할 수 없다.

PM이 커뮤니케이션이 부족하여 상호 간 소통과 진행이 되지 않는 모습과 똑같다고 볼 수 있다.


이제는 2주간의 개발 지식을 통해서 무엇을 얻고, 무엇을 정리하여

나의 커뮤니케이션 스킬에 적용할 수 있는지가 아니라,

꾸준히 앞으로 계속 고민해 보며 2주가 아닌, 앞으로 들의 시간을 계속 배우고 재단하며 나아가야겠지만

지금껏 그랬듯 앞으로도 계속 잘 해낼 수 있을 것이라 생각한다.


2주 간의 개발 지식 증진 Project 완.









 



                     

매거진의 이전글 카카오톡 소셜 API 탐방기. (친구 목록 가져오기)
작품 선택
키워드 선택 0 / 3 0
댓글여부
afliean
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari