페이지 제작 어드민 개발 중 받은 피드백과 성장

2026.01.20 - [Develop] - 페이지 제작 어드민, 무엇을 개선했을까? 💭

2026.02.17 - [Develop] - 페이지 제작 어드민 개발 중 받은 피드백과 성장

 

1. 아쉬웠던 것 & 개선했던 것

1-1. 우선순위가 다른 태스크에 비해 너무 밀리기 시작했다

- 페이지 어드민은 '데이터 마이그레이션'으로 인해 오류 발생 가능성이 큰 기능이다.

- 블랙프라이데이나 Focus 프로젝트와 기간과 겹쳤다가는 큰일이었다. (앞선 것들은 전사 프로젝트들이다!)

- 거래액이 전사 목표인 이상, 대형 프로젝트 기간을 어떻게든 피해서 배포했어야 했다
- 시간이 지나면서 어드민 main 브랜치와 페이지 어드민 브랜치간의 간극이 생겼다. 

- 중간에서 맞춰가야 하는 부분들이 많아지면서 일이 늘어났다.

 

1-2. 리소스가 갑자기 부족하게 되었다

- 프론트에서는 찰리(프론트엔드 개발자)가 병가로 빠지게 되어서 시작하신 작업을 이어 받아야 했다.

- 인수인계 및 코드에 익숙해져야 하는 시기가 있어 시간이 걸렸다.
- 백엔드에서도 예상치 못하게 퇴사가 있었다. 이 기능을 맡은 개발자의 업무가 가중화 되었다.

 

1-3. 데이터 마이그레이션 (장점과 단점이 둘 다 있음)

- 페이지 어드민을 시작할 때 기존 데이터를 새로운 데이터 구조로 마이그레이션 하자는 계획을 잡았었다. 개발 시간이 더 늘어났다.
- 페이지 편집 어드민 기능과 마이그레이션이 동시에 이루어지는 것에 대해서 의구심을 가졌다.
- DB 마이그레이션이 불가피하다면 데이터를 제대로 잡고 가기에 적기임은 맞다.

- 결과적으로 오래 걸렸지만 지금 필요한 과정임에 동의한다.

 

이하 등장하는 제이콥이라는 인물은 이 프로젝트의 Project Owner이며, 에밀리는 백엔드 개발자이다.

 

1-4. 어드민 개발 초기 나의 코드 집착 의사결정

1-4-1. 어떤 상황이었나

- 페이지 어드민을 인수인계 받아 모르는 코드가 많은 상황이었다.
- 다른 개발자들이 main 브랜치에서 작업한 것을 페이지 어드민 브랜치에 병합해야 했다.

- 메인에 있는 코드들을 이해해하고, 이 것을 어드민에서는 어떻게 바꿀지 고민하는 시간이 들었다.

- 모르는 코드들에 대한 불안감이 들었다.
- 어드민에서 당장 개발해야 하는 기능들이 있었다. 이 것들 클로드코드로 빠르게 개발했다. 

- 클로드가 개발한 것들이 잘 잘동하는 것을 확인했다. 기능만 보고 코드를 꼼꼼히 보고 넘어가지 않았다. 그래서는 안 되었다.
- 나중 되어서 코드를 덜 봤으니, 내가 코드를 더 봐야 한다는 주장을 했다. 시간이 금인데 역행하는 의견이었다.

 

 

1-4-2. 무슨 피드백을 받게 되었나

- 제이콥과 에밀리에게 피드백을 받았다.

- 코드에 대한 집착을 내려두어야, 페이지 어드민이 더 빠르게 나아갈 수 있다는 피드백을 주었다.

- 코드에 대한 ‘완벽주의’라는 단어를 사용하셨고, 내가 그랬음에 동의했다.
- 기능이 제대로 동작하도록 QA에 집중하도록 주장을 굽혔다. 결과적으로 잘 한 결정이었다.

- 이후에 개발이 더욱 빨라지게 되었다. 빨라지니 일정이 가시적으로 보였다. 

- 백엔드 사이드에서 개발이 필요한 부분을 더 빠르게 요청드릴 수 있게 되었다.

- PO와 백엔드 사이에서 싱크가 더 빠르게 맞추어졌다.
- QA에 쓸 수 있는 시간이 많아졌다. QA를 3번 이상 돌려서 오류 & 개선을 96개의 항목이나 진행했다. 

- 반복 QA와 개선이 안정성에 많은 도움을 주었다.

1-5. 개발 중반 lazy한 의사소통

1-5-1. 어떤 상황이었나?

- 개발을 하는 중간에 제이콥과 에밀리에게 개발 일정에 대한 제대로 된 산정을 제공하지 않았다.
- 어드민을 배포하기 전에 어떤 개발이 얼마나 남았는지에 대해서 확실한 답을 하지 못했다.
- 제이콥의 입장에서는 잔여 작업이 무엇인지를 알아야 일정 산정을 하는데 답답했겠다.

 

 

1-5-2. 내 생각

- 페이지 어드민에서 나오는 에러와 사이드 이펙트에 대한 책임이 나에게 걸려 있다고 생각했다.
- 개발 자체는 많이 남지 않았다. 코드 하나라도, 기능을 하나라도 나 혼자라도 보는 시간이 필요하다고 생각하게 되었다. 

- 프론트 코드 파일 변화가 500개가 넘어가는 상황이었다. 이 코드에 대한 책임이 나한테 있으니 더 방어적인 선택을 했다.

- 이 것이 팀원들과 생각이 달랐다. 팀원들의 생각이 맞았다.

 

 

1-5-3. 피드백

- 페이지 어드민 관련해서 제이콥과 에밀리가 나에게 답답한 부분이 있었을 것이라 생각했다. 

- 그런 눈초리가 몹시 느껴졌다. 그 날 스크럼이 끝나고 나에게 이런저런 피드백을 달라고 요청했다.  

- 심신의 안정을 위해서 커피를 내리고 자리에 앉았다. 천천히 끝까지 얘기를 들었다.

- 에밀리가 코드 단에서 에러를 발견한다는 것은 몹시 어려운 일이라고 얘기했다. 

- 손으로 하는 QA위주로 가야한다는 의견을 주었다.

- 제이콥 역시 QA를 두세번 하더라도, 얼른 태스크를 마무리하고 QA 단계에 돌입해야 한다는 의견을 주었다.

- 양쪽에서 이렇게 말해주니, 나중에 프론트 코드가 형편없더라도 핑계거리가 생겼다는 마음에 안심하게 되었다.

 

- 더 빠른 의사소통을 위해, 배포까지 일정을 모두 적어두는 캘린더를 만들어서 관리했다. 

- 모든 구성원이 어떤 작업이 남았고 언제까지 끝나는지를 가시화 할 수 있었다. 
- QA를 N번 돌리게 되었다. 페이지 어드민 개발의 현주소를 알게 되었다. 

- 제이콥이 타 부서와 소통할 때에 자신 있게 얘기하게 되었다. 

- 외부적으로 일이 진척되고 있는 것으로 보였고, 실제로도 그랬다.

 

 

2. 잘 했다고 보이는 점

 

- 개발이 완벽하지 않더라도 최대한 빠르게하고 QA를 여러번 돌린 것

    - 다시 돌아봐도 좋은 피드백과 좋은 의사결정이었다.

 

- 앱 안정성을 최우선으로 두고 개발

    - 배포 10일 전부터 안정성 확인 및 개선을 제외하고는 개발하지 않는 결정을 내렸다.

    - 수정해야 하는 것들이 나와도, 이 것을 기준으로 의사결정했다.

- 300개 정도의 앱 관련 코드 변화를 모두 확인한 것
    - 모노레포를 사용하기 때문에 모든 코드 변화를 따지면 file change가 500개가 넘었다.
    -  기존 앱에 있던 코드들을 어드민에서 가져와 사용하기 때문에, 앱 관련 코드 변화가 300개가 넘었다.
    -  안정성이 최우선이라면 최소한 앱 관련한 모든 코드는 이해하고 있어야 한다고 판단했다.
    -  대신 어드민 관련한 코드는 반복된 QA를 믿기로 했다.

- 배포 나가기 직전까지 핵심 페이지를 반복 체크한 것
    - 홈, 자주 방문하는 기획전, 타임딜, 랭킹, 상품 상세 페이지, 로그인, 결제
    - 이 것들이 중요한 퍼널이라고 판단했다. 배포 나가기 직전까지 이들을 반복 체크했다. 웹 앱 어드민 모두.

 

- 생각보다 에러가 없이 잘 끝났다. 배포 이후에 버그 리포트 채널은 고요했다.

- 에밀리와 철야를 하면서, 정신줄 부여 잡고 QA를 진행했다.
    - (피곤했다) 홈, 타임딜, 랭킹 등 핵심 페이지에서 UI 렌더링이 제대로 되는지 체크하였다.
    - (피곤했다) 마이그레이션 대상 페이지를 에밀리와 꼼꼼히 확인했다.
    - (피곤했다) 장바구니 담기와 결제가 잘 진행되는지 확인하였다.
    - 최종 체크 중, 타임딜 타이머에서 무한 리렌더링이 발생하던 것을 확인하고 해결하였다. 

    - 밤새도록 더블체크를 하다가 에밀리가 랭킹 페이지가 수상하게 느린 것을 발견하고 얘기해줬다.

    - 이거 없었으면 라이브 에러가 발생했고 자고 있던 우리들은 난리가 났을 것이다.

- 개밥먹기를 열심히 했다

    - 개밥먹기란?

    - 아예 기획전을 만들어보지 않은 사람들도 만들 수 있을 정도로 편한가 알아볼 마음으로 여럿 만들었다

    - 기존 기획전 페이지를 어드민으로 그대로 만들어도 봤다.

- 페이지 어드민 MD 사용하게 하기 + 사용 방법에 대해 미리 싱크 맞추기
    - 배포 1주 전에 필요한 기능이 혹시라도 누락되었는지 피드백을 들어 개선했다.

    - 배포 이후에는 기존 어드민을 사용하지 못하니, 반드시 필요한 일이었다.

- UI/UX 모든 것을 나와 찰리가 했다. 개발이 제 시간에 끝날 수 있는데에 도움이 되었다 생각.
    - 디자인 리소스 들지 않고 소통비용도 적어 더 빨랐다. 물론 좋은 UX를 기대하기는 어렵다.

 

 

 

다시 나의 회고를 보아하니 내가 읽고 있던 책과 비슷하게 회고하고 있음을 발견했다.

실패를 통과하는 일 - 박소령