어느 날 회의를 마치고 자리에 돌아오니 하루의 많은 시간이 지나 있었습니다.

예전 같았으면 회의가 이렇게 많은데 개발은 언제 해야 할까 하는 생각부터 들었을 것 같습니다. 실제로 집중해서 코드를 작성할 시간이 줄어드는 것은 여전히 부담입니다.

그런데 최근에는 회의가 많아진 이유를 조금 다르게 보게 되었습니다.

예전에는 정해진 내용을 구현하는 일이 많았습니다

몇 년 전까지만 해도 프로젝트의 순서는 비교적 분명했습니다.

기획과 디자인이 정리되고 원장이나 코어 서비스의 방향이 어느 정도 확정된 뒤 채널 개발자가 화면을 만들고 API를 연결하는 경우가 많았습니다.

이때의 중요한 질문은 주어진 요구사항을 어떻게 안정적으로 구현할 것인가였습니다. 개발자는 프로젝트의 뒤쪽에서 완성된 기준을 코드로 바꾸는 역할에 가까웠습니다.

하지만 앱과 웹, 여러 서버가 함께 움직이는 서비스에서는 구현 전에 정하지 않으면 안 되는 것이 많아졌습니다.

경계의 문제는 한 팀이 정하기 어려웠습니다

WebView를 어디까지 앱 화면처럼 보이게 할지, GNB와 바텀시트가 함께 움직일 때 누가 상태를 제어할지, 로그인 후 사용자를 어느 화면으로 돌려보낼지 정해야 했습니다.

전자서명도 앱에서 성공 결과를 받는 것만으로 끝나지 않았습니다. 웹이 만든 원문과 앱이 서명한 데이터, 서버가 실제로 처리할 요청을 어떤 기준으로 비교할지 인증과 앱, 서버 담당자가 함께 봐야 했습니다.

이런 문제는 각 팀이 자기 영역만 구현한 뒤 연결해서 풀기 어렵습니다. 경계의 기준이 늦게 정해지면 화면마다 다른 방식이 생기고, 이미 만든 기능을 다시 수정해야 할 수 있습니다.

그래서 채널 개발자가 구현 전에 참여하는 회의가 자연스럽게 늘었습니다.

회의도 개발의 일부가 될 수 있었습니다

모든 회의가 필요한 것은 아닙니다. 결론 없이 현황만 공유하거나 책임을 나누기 위한 회의는 개발 시간을 줄일 뿐입니다.

반면 역할의 경계를 정하고 다음 구현의 기준을 남기는 회의는 코드 작성 이전의 개발에 가까웠습니다.

회의가 끝난 뒤 다음 내용이 분명해지는지를 기준으로 보게 되었습니다.

  • 앱, 웹, 서버가 각각 책임질 범위
  • 정상 흐름과 예외 흐름의 처리 주체
  • 공통 모듈이나 인터페이스로 남길 내용
  • 아직 구현으로 확인해야 하는 가정
  • 변경 시 함께 검토해야 할 영역

결정이 문서와 개발 요청, 공통 규칙으로 이어진다면 다음 개발자가 같은 문제를 다시 논의하는 시간을 줄일 수 있습니다.

역할이 코드 밖으로 조금 넓어졌습니다

채널 개발자의 역할은 화면과 API를 구현하는 데서 끝나지 않았습니다.

고객이 앱과 웹의 경계를 느끼지 않도록 여러 영역의 기준을 연결하고, 구현 전에 충돌할 수 있는 지점을 찾아 함께 결정하는 일이 늘었습니다.

회의가 많아졌다는 사실 자체를 긍정적으로 보려는 것은 아닙니다. 다만 필요한 결정을 앞에서 내리는 시간이라면 뒤에서 반복되는 수정과 해석의 차이를 줄일 수 있습니다.

요즘은 개발 시간을 코드 작성 시간으로만 보지 않게 되었습니다. 여러 팀이 같은 기준에서 구현을 시작할 수 있게 만드는 일도 채널 개발자가 만드는 결과 중 하나라고 생각합니다.