개인의 개발 프로세스 개선

최근 규모가 작은 회사로 이직하면서 오랜만에 기획자, 디자이너, 백엔드 개발자와 협업하며 기능 개발을 진행하게 되었다.

그 과정에서 내가 생각보다 미숙하게 일을 진행하고 있었다는 것을 깨닫게 되었다.
특히 기능을 개발하는 과정에서 사용자 흐름이나 API 구조를 충분히 검토하지 않은 상태에서 구현을 시작하는 경우가 많았다.

돌이켜보면 이전에 근무했던 비교적 규모가 있는 회사에서는 이런 부분을 크게 고민하지 않았던 것 같다.

기능 정의서, 화면 명세, 사용자 흐름 등이 비교적 체계적으로 문서화되어 있었고, 반 강제적으로 여러 단계를 거쳐 함께 흐름을 검증한 상태에서 개발이 시작되는 경우가 많았다.
그래서 프론트엔드 개발을 진행하면서도 사용자 흐름은 사전에 함께 단계적으로 검증되었기에 기획 문서를 신뢰하고 구현을 진행하는 경우가 많았다. (서비스 기획의 규모가 훨씬 큼에도 불구하고 논리적 흐름이 이상한 부분도 현재의 회사보다 상대적으로 적었다.)

당시에는 그런 환경 덕분에 절차에 따라 플로우가 검증된 상태로 일이 진행되어 큰 문제 없이 개발할 수 있었다. 하지만 규모가 작은 조직에서 기능 개발을 진행하다 보니, 기능 흐름을 더 적극적으로 검증해야 할 필요성을 느끼게 되었다.

그래서 디자이너나 기획자에게 해당 부분들을 자주 말하다보니 눈치가 보이기도 하고, 참견하는 느낌이라서 죄송하기도 했다. ㅜㅜ 아무튼 이번 글에서는 간단하게 내가 어떤 방식으로 일을 진행했고, 무슨 문제가 있었는지 말하고 앞으로 어떻게 할 지 정리해보았다. (아직 바뀐 개발 프로세스로 일하진 않았다.)

개발 프로세스 (AS-IS)

회사에 입사하고 1주일 만에 바로 Credit 기능 개발을 맡게 되었다.

개발을 시작할 때 참고한 문서는 다음 세 가지였다.

• 크레딧 정책 문서

• 크레딧 화면 명세서

• 크레딧 디자인 화면

이 문서들을 기반으로 사용자 흐름을 이해하고, UX적으로 이상하거나 이해가 안 되는 부분을 기획자에게 피드백하며 개발을 시작했다.
당시에는 사용자 흐름에 큰 문제가 없어 보였다. 다만 지금 돌아보면 하나 놓친 것이 있었다.
CS 정책 문서였다.

당시에는

"사업자 등록증을 누군가 확인하고 상태를 변경해주는구나"

정도의 이해만 하고 넘어갔다. 하지만 지금 다시 돌아간다면 반드시 이렇게 질문했을 것이다.

"사업자 등록증 확인 후 상태 변경을 하는 프로세스에 대한 문서가 따로 있나요?"

문제의 발견

문제는 백엔드 API를 연결하며 비즈니스 로직을 정리하는 과정에서 발생했다.
이 과정에서 사용자 흐름의 치명적인 결함을 발견했다. 이 결함은 그대로 출시할 경우 실제 운영이 불가능한 수준의 허점이었기 때문에 반드시 수정되어야 했다.

결국 다음과 같은 일이 발생했다.

1. 사용자 흐름 수정

2. 기획 문서 수정

3. 디자인 영향 확인

4. 개발 코드 수정

즉, 이미 개발이 진행된 상태에서 전체 프로세스를 다시 점검해야 했다.

결과적으로 팀 전체가 추가적인 비용을 치르게 되었고, 특히 프론트엔드가 가장 많은 커뮤니케이션 비용을 부담하게 되었다.

프론트엔드는 특성상

• 기획자

• 디자이너

• 백엔드

모두와 소통해야 하기 때문이다.

정리하면 당시의 프로세스는 다음과 같았다.

기획 → 디자인 → 개발 → 개발 중 문제 발견 → 전체 수정

이 구조에서는 뒤늦게 발견된 사용자 흐름의 결함이 팀 전체의 비용으로 전파된다.

개발 프로세스 (TO-BE)

이 경험 이후 나는 목표했던 일정 내에 일을 마무리하지 못했다는 점에서 개인적으로 자존심이 상했다.

그래서 문제를 개발 능력의 부족이 아니라 프로세스의 문제라고 생각했고 개발을 시작하기 전 어떤 과정을 거쳐야 하는지 다시 정리해 보았다.

내가 정리한 개선 프로세스는 다음과 같다.

기획 검증 → 디자인 확인 → 개발

핵심은 개발 전에 사용자 흐름을 충분히 검증하는 것이다.

이렇게 하면 사용자 흐름의 문제는 기획자와의 대화 단계에서 해결할 수 있다.

즉,

• 디자이너

• 백엔드

• 개발 코드

까지 영향을 전파시키지 않는다.

내가 생각한 이 프로세스의 장점

이 방식의 가장 큰 장점은 문제의 영향 범위를 최소화할 수 있다는 것이다.

문제가 발생했을 때

• 기획 단계 → 기획자와 해결

• 디자인 단계 → 디자이너와 해결

• 개발 단계 → 코드 수정

처럼 단계별로 문제를 격리할 수 있다.

나는 이것을 AS-IS에서의 프론트엔드의 단일 장애 지점(Single Point of Failure)에서 벗어나는 과정이라고 생각한다.

프론트엔드가 프로세스를 조금만 개선해도 팀 전체의 커뮤니케이션 비용을 크게 줄일 수 있다고 느꼈다.

결론

여태껏 많은 협업을 하면서 느낀 것은 하나였다.

아무리 뛰어난 기획자, 디자이너, 개발자라도

100% 완벽한 결과물을 처음부터 만들어내는 경우는 없다. 100%의 확률로 오류를 범한다.

실제로 잘 나가는 서비스들도 종종 이런 문제를 겪는다.

• 네이버 페이의 수 시간의 서비스 장애

• 토스 증권의 엔화 급락 버그

• 카카오톡의 잘못된 기획으로 인한 사용자 반발

결국 중요한 것은 누가 실수를 하지 않는가가 아니라

문제를 얼마나 빠르게 발견하고 개선할 수 있는 구조를 가지고 있는가

라고 생각한다.

그래서 팀에서는 항상

• 문제를 발견하고

• 프로세스를 개선하고

• 더 나은 방식으로 바꾸려는

문화가 필요하다고 느꼈다.

그리고 내가 다니는 회사는 비교적 작은 규모의 조직이라 각자가 하나의 영역을 크게 책임지는 구조에 가깝다.
말하자면 일종의 1인 군단처럼 움직이는 상황이 자주 발생한다.

그래서 한 사람이 발견하지 못한 문제는 그대로 다음 단계로 넘어가기 쉽고, 반대로 한 사람이 문제를 잘 발견하면 전체 프로세스가 크게 개선되기도 한다.

이런 환경에서는 개인의 개발 능력뿐만 아니라 문제를 발견하고 질문하는 능력, 그리고 프로세스를 개선하려는 태도가 더욱 중요하다고 느꼈다.