1. 들어가며
하나의 화면이 사용자에게 전달되기까지는 생각보다 많은 과정을 거칩니다. 기획부터 퍼블리싱 요청, 개발, 테스트까지 하나의 흐름으로 이어집니다. 이번에는 퍼블리싱을 제외한 대부분의 과정을 직접 맡아 진행했습니다.
이 글은 결과물에 대한 소개보다는 그 과정을 돌아보는 기록입니다. 한 사이클을 직접 경험하면서 어떤 고민을 했는지, 어디에서 어려움을 느꼈는지, 그리고 다음에는 무엇을 개선할 수 있을지 정리해 보려고 합니다.
2. 기획 — 개발자가 아닌 사용자의 관점에서
기획 단계에서 가장 많이 고민했던 것은 사용자의 사용 흐름이었습니다. 개발을 하다 보면 구현이 단순한 방향으로 자연스럽게 생각이 기울 때가 있습니다. 하지만 사용자가 실제로 어떤 행동을 반복하게 될지를 먼저 떠올리려고 했습니다.
대표적인 예가 목록에서 항목 상태를 변경하는 기능이었습니다. 개발 관점에서는 행을 클릭해 상세 화면으로 이동한 뒤 값을 수정하고 저장하는 방식이 가장 단순합니다. 화면 구조도 명확하고 구현 난이도도 낮습니다.
하지만 실제 사용 시나리오를 생각해 보니 사용자는 여러 항목을 확인하면서 상태를 빠르게 수정하는 경우가 많았습니다. 상세 화면을 반복해서 이동하는 방식은 항목 수가 많아질수록 불필요한 클릭과 화면 전환이 계속 발생했습니다.
그래서 목록 화면에서 바로 상태를 변경할 수 있는 인라인 수정 방식을 선택했습니다. 구현 과정에서는 행 단위 상태 관리, 저장 실패 시 복구 처리, 낙관적 업데이트 등 추가 작업이 필요했습니다. 개발 공수는 늘어났지만 사용자가 반복적으로 수행해야 하는 작업을 줄일 수 있었습니다.
물론 모든 의사결정을 사용자 편의만으로 할 수는 없습니다. 일정과 공수라는 현실적인 제약도 존재합니다. 다만 어떤 선택을 하더라도 그 이유를 명확하게 인지하는 것이 중요하다고 느꼈습니다. 사용자 경험을 위해 감수한 선택인지, 일정상 타협한 선택인지 구분할 수 있어야 이후 개선 방향도 더 분명해지기 때문입니다.
3. 퍼블리싱 요청 — 전달보다 중요한 것은 정리
이번 사이클에서 가장 많이 배운 단계는 퍼블리싱 요청 과정이었습니다. 퍼블리싱 자체는 전담 팀이 담당했지만, 제가 맡은 역할은 단순히 작업을 넘기는 것이 아니라 상대가 작업할 수 있는 상태로 정리하는 것이었습니다.
처음에는 화면의 기능과 구조를 설명하는 것만으로 충분하다고 생각했습니다. 하지만 실제 협업 과정에서는 제가 당연하게 생각했던 정보가 상대에게는 그렇지 않은 경우가 많았습니다. 화면의 상태나 동작 방식, 예외 상황에 대한 기준이 명확하지 않으면 자연스럽게 추가 논의와 수정 작업이 발생했습니다.
또 하나 느낀 점은 작업을 시작하기 전 충분한 공감대가 중요하다는 것이었습니다. 각자 머릿속에 그리고 있는 화면이 조금씩 다를 수 있기 때문에, 이를 미리 맞추지 않으면 작업 이후에 다시 조정하는 비용이 생각보다 크게 발생했습니다.
결국 퍼블리싱 요청은 단순한 전달 업무가 아니었습니다. 내가 이해한 내용을 얼마나 명확하게 정리하고 공유할 수 있는지가 협업의 효율을 크게 좌우했습니다. 이번 경험을 통해 협업에서 발생하는 많은 문제는 작업 능력의 문제가 아니라 정보 전달의 문제일 수 있다는 점을 체감했습니다.
앞으로는 작업을 요청하기 전에 한 번 더 정리하고, 상대방이 같은 그림을 그리고 있는지 확인하는 과정에 더 많은 시간을 쓰게 될 것 같습니다.
4. 개발 — 준비가 되어 있을수록 단순해진다
이번 작업에서 개발 단계 자체는 큰 어려움 없이 진행되었습니다. 백엔드와 프론트엔드를 모두 직접 담당했지만, 예상보다 막히는 부분은 많지 않았습니다.
처음에는 이유를 크게 생각하지 않았는데, 돌이켜보니 개발이 수월했던 것은 앞 단계에서 어느 정도 방향이 정리되어 있었기 때문이었습니다. 무엇을 만들어야 하는지, 화면이 어떤 상태를 가져야 하는지, 사용자는 어떤 흐름으로 기능을 이용하는지가 비교적 명확했습니다. 덕분에 개발 과정에서는 새로운 결정을 내리기보다 이미 정리된 내용을 구현하는 데 집중할 수 있었습니다.
프론트엔드와 백엔드를 함께 담당한 점도 도움이 되었습니다. 일반적으로는 API 인터페이스나 데이터 구조를 조율하는 과정이 필요하지만, 이번에는 하나의 흐름으로 바라보며 작업할 수 있었습니다. 프론트엔드에서 필요한 형태를 고려해 API를 설계할 수 있었고, 반대로 백엔드 구조를 이해한 상태에서 화면을 구현할 수 있었습니다.
이번 경험을 통해 개발의 난이도는 코드를 작성하는 순간에만 결정되는 것이 아니라는 점을 다시 느꼈습니다. 앞 단계에서 얼마나 고민하고 정리했는지가 이후 개발 과정의 복잡도를 크게 좌우했습니다. 개발이 쉬웠다는 사실보다, 왜 쉬울 수 있었는지를 돌아보게 된 작업이었습니다.
관련 사례들을 찾아보니, 일부 팀에서는 개발보다 설계와 화면 정의에 더 많은 시간을 투자한다는 이야기가 인상적이었습니다. 처음에는 개발 속도가 느려 보일 수 있지만, 실제로는 구현 단계의 수정 비용을 크게 줄여 전체 리드타임을 단축하는 방식이었습니다.
이번 작업을 진행하면서 왜 그런 방식을 선택하는지 조금은 이해할 수 있었습니다. 개발 단계에서 빠르게 진행될 수 있었던 이유 역시 구현 과정보다 앞선 단계에서 많은 결정이 이루어졌기 때문이었습니다.
5. 테스트 — 생각보다 부족했던 마지막 단계
가장 아쉬움이 남는 단계는 테스트였습니다.
이번에는 별도의 테스트 코드를 작성하지 않았고, 완성된 화면을 직접 확인하는 방식으로 검수를 진행했습니다. 기능이 많지 않은 상황에서는 충분히 가능한 방법이었고, 실제로 큰 문제 없이 마무리할 수 있었습니다.
다만 작업을 마친 뒤 돌아보니 테스트가 사람의 기억에 많이 의존하고 있다는 생각이 들었습니다. 화면이 늘어나고 수정이 반복될수록, 이전에 확인했던 기능을 다시 점검해야 하는 일이 계속 발생합니다. 지금은 감당 가능한 수준이지만 규모가 커질수록 같은 방식이 유지되기는 어려워 보였습니다.
특히 정상적인 화면 흐름은 자연스럽게 확인하게 되지만, 데이터가 없거나 오류가 발생하는 상황처럼 예외적인 케이스는 상대적으로 놓치기 쉽다는 점도 느꼈습니다. 개발 과정에서는 이런 상태를 충분히 고려했다고 생각했는데, 막상 검수 단계에서는 정상 시나리오에 집중하게 되는 경우가 많았습니다.
회고를 정리하면서 다른 팀들의 테스트 방식도 찾아보게 되었습니다. 모든 기능을 테스트 코드로 관리하기보다는, 사용자가 가장 자주 이용하는 핵심 흐름만 자동화하고 나머지는 수동 검수를 병행하는 방식이 생각보다 많이 사용되고 있었습니다. 특히 E2E 테스트를 통해 주요 시나리오만 검증하거나, 스토리북(Storybook)을 활용해 화면 상태를 관리하는 사례들이 인상적이었습니다.
아직은 현재 프로젝트 규모에 비해 다소 이른 선택일 수 있지만, 반복적으로 검수하는 작업이 늘어난다면 충분히 검토해 볼 만한 방법이라고 느꼈습니다. 모든 것을 한 번에 바꾸기보다 지금의 방식에 작은 안전장치를 하나씩 추가하는 방향이 현실적일 것 같습니다.
6. 마치며
이번 작업에서 가장 의미 있었던 점은 화면 하나가 사용자에게 전달되기까지의 과정을 처음부터 끝까지 경험해 볼 수 있었다는 것입니다.
이전에는 기획, 퍼블리싱, 개발, 테스트를 각각의 독립된 단계로 생각했던 것 같습니다. 하지만 직접 전 과정을 거치면서 각 단계가 서로 강하게 연결되어 있다는 점을 체감할 수 있었습니다. 앞 단계에서 정리된 내용은 다음 단계를 수월하게 만들었고, 반대로 모호했던 부분은 뒤로 갈수록 더 큰 비용으로 돌아왔습니다.
또한 다른 역할의 관점에서 생각해 볼 기회도 얻었습니다. 단순히 요청을 보내고 결과를 받는 입장이 아니라, 어떤 정보가 필요하고 어떤 부분에서 어려움이 발생하는지를 조금이나마 이해하게 되었습니다. 덕분에 협업 과정에서 무엇을 더 준비해야 하는지에 대해서도 많이 배우게 되었습니다.
이번 회고는 결과물에 대한 기록이라기보다 과정에 대한 기록에 가깝습니다. 무엇을 만들었는지도 중요하지만, 그것이 만들어지는 과정을 한 번 온전히 경험해 본 것이 더 큰 수확이었습니다. 다음에는 이번에 발견한 부족한 부분들을 조금씩 보완하면서 더 나은 한 사이클을 만들어 보고 싶습니다.
jun