[PonsLink] PonsLink 기술 회고: 33편의 아카이브를 읽는 지도

PonsLink의 기술 회고를 여러 편 쓰고 나서야 반복되는 질문이 보였다. 새 기능을 붙였는가보다, 어느 책임을 어느 계층에 둘 것인가가 매번 더 어려운 결정이었다.

방, 요청, 결제, 실시간 연결은 겉으로는 서로 다른 주제다. 하지만 실제 운영에서는 한 사용자의 흐름으로 이어진다. 한 곳의 이름을 쉽게 정하면 다른 곳의 상태와 권한 설명도 함께 흔들렸다.

기능 목록으로는 설명되지 않는 제품

PonsLink를 영상 통화, 파일 공유, 요청 폼 중 하나로만 설명하면 각각의 기능은 맞아도 사용 흐름은 빠진다. 사용자는 요청을 남기고, 상대의 판단을 기다리고, 권한을 얻은 뒤 방에 들어간다. 끝난 뒤에는 기록을 다시 찾는다.

어느 단계 하나만 잘 만들어도 전체 경험이 자동으로 좋아지지 않았다. 연결이 성공해도 요청이 비어 있으면 상담은 시작되지 않고, 결제가 성공해도 입장 권한이 바로 생기는 것은 아니었다.

반복해서 돌아온 경계

회고에서 계속 확인한 경계는 요청과 세션, 결제와 입장, 화면 상태와 내부 상태였다. 이들을 한 이벤트로 묶으면 구현은 단순해 보이지만 실패했을 때 설명할 수 없게 된다.

반대로 책임을 나누면 코드와 문장이 함께 길어진다. 대신 사용자가 왜 기다리는지, 운영자가 어느 단계에서 개입해야 하는지, 재시도할 수 있는 사건인지 구분할 수 있다.

회고를 쓰는 이유

이 기록의 목적은 기술 선택을 자랑하는 데 있지 않다. 당시 무엇을 몰랐고, 어떤 실패 뒤에 경계를 바꿨는지를 남기는 데 있다. 다음 기능을 만들 때 같은 이름을 다시 만나도, 이전 결정의 조건을 확인할 수 있어야 한다.

그래서 각 회고에서 결과만 남기지 않고 문제 장면과 반례, 다시 고른 책임을 함께 적는다. 그래야 “왜 이렇게 만들었나”라는 질문에 당시의 상황으로 답할 수 있다.

마치며

PonsLink의 기술적 모양은 한 번에 정해지지 않았다. 방을 만들고, 요청을 붙이고, 결제와 권한을 나누는 과정에서 책임의 위치가 조금씩 바뀌었다. 회고는 그 변경을 다음 판단에 사용할 수 있는 형태로 보관하는 일이다.