설계 없이 개발 시작했다가 전부 뒤엎은 경험

개발자 현직자 솔직 경험담

설계 없이 개발 시작했다가
전부 뒤엎은 경험

3주 만에 완성한 코드를, 설계 없이 짰다는 이유로 처음부터 다시 짠 이야기.

사이드 프로젝트로 소규모 예약 관리 서비스를 만들 때였다. 기획서를 받자마자 바로 컴포넌트부터 짜기 시작했다. "일단 화면부터 빨리 보여드리고 싶다"는 마음이 컸다. 3주 동안 열심히 만들었고, 첫 데모에서는 반응도 나쁘지 않았다. 근데 두 번째 요구사항이 추가되는 순간 전체 구조를 처음부터 다시 짜야 했다. 그때 배운 게 있다면, 빠르게 시작하는 것과 제대로 시작하는 것은 완전히 다른 얘기라는 것이다.

설계 없이 개발 시작했다가 전부 뒤엎은 경험

3주첫 개발 소요 기간

78%재작업 시 폐기된 코드 비율

5일설계 후 재개발 소요 기간

1. "일단 만들면서 생각하자"는 착각

예약 관리 서비스의 핵심 기능은 시간대별 예약 슬롯을 관리하는 것이었다. 처음엔 예약 하나를 Booking 컴포넌트 안에서 상태로 직접 관리했다. 화면 하나 완성하는 재미에 빠져서, 데이터 구조를 어떻게 설계할지는 전혀 고민하지 않았다.

// 초반 - 예약 상태를 컴포넌트 안에서 직접 관리 function BookingCalendar() { const [bookings, setBookings] = useState([ { id: 1, time: "10:00", name: "김OO" }, ]); // 예약 추가, 취소, 중복 체크 로직이 전부 이 컴포넌트 안에 뒤섞여 있음 }

1주 차, 2주 차까지는 문제가 없었다. 근데 "같은 시간에 여러 좌석을 예약할 수 있어야 한다"는 요구사항이 추가되자 완전히 무너졌다. 예약 하나당 좌석 하나만 가정하고 짠 구조라, 좌석 개념을 끼워 넣으려니 이미 만든 컴포넌트 전체를 뜯어고쳐야 했다.

⚠ 그때 깨달은 것 설계 없이 시작한 코드는 요구사항이 딱 하나만 추가돼도 전체가 흔들렸다. 화면이 빨리 나온다고 해서 개발이 빠른 게 아니라, 오히려 나중에 몇 배로 갚아야 하는 빚이었다.

2. 팀 리더의 한마디 — "이거 데이터부터 다시 그려봐요"

결국 좌석 개념을 추가하려다 코드가 완전히 꼬여서 리더에게 도움을 요청했다.

리더 지금 컴포넌트 안에 예약, 좌석, 시간대가 다 뒤섞여 있는데, 이걸 그대로 두고 기능만 추가하면 앞으로 계속 이렇게 힘들 거예요. 화면 말고 데이터 구조부터 다시 그려볼래요?

나 지금까지 만든 걸 다 버려야 하는 건가요...

리더 컴포넌트는 남아도, 데이터를 다루는 방식은 처음부터 다시 짜야 할 것 같아요. 지금 뜯어고치는 게 나중보다 훨씬 싸요.

처음엔 3주 동안 만든 걸 버린다는 게 너무 아까웠다. 근데 화면 대신 데이터 구조부터 종이에 그려보니, Booking, Seat, TimeSlot이 서로 다른 개념인데 하나로 뭉쳐 있었다는 게 명확히 보였다.

3. 다시 그린 설계 — 이번엔 화면보다 데이터가 먼저였다

재설계할 때는 화면을 그리기 전에 세 가지 개체의 관계부터 정리했다.

// 재설계 후 - 개념을 분리한 데이터 구조 type TimeSlot = { id: string; time: string; }; type Seat = { id: string; label: string; }; type Booking = { id: string; timeSlotId: string; // TimeSlot 참조 seatId: string; // Seat 참조 customerName: string; }; // 좌석 추가, 시간대 추가가 각각 독립적으로 가능해짐 const getAvailableSeats = (timeSlotId: string, bookings: Booking[]) => allSeats.filter(seat => !bookings.some(b => b.timeSlotId === timeSlotId && b.seatId === seat.id) );

데이터 구조를 먼저 정리하고 나니, 정작 컴포넌트는 오히려 더 단순해졌다. 각 컴포넌트가 하나의 개념만 다루도록 나뉘면서, 좌석을 추가하거나 시간대를 늘리는 기능도 큰 리팩토링 없이 붙일 수 있었다.

설계 없이 짠 코드

1개 컴포넌트에 3개 개념

요구사항 하나 추가에 전체 재작업 필요

데이터 구조부터 짠 코드

개념별로 독립된 타입

새 요구사항은 대부분 확장만으로 해결

78%

폐기된 기존 코드

22%

재사용 가능했던 코드

4. 재작업이 오히려 더 빨랐던 이유

D+0

종이에 Booking, Seat, TimeSlot 관계를 그리며 데이터 구조부터 설계. 화면은 전혀 그리지 않음.

D+1

타입 정의와 핵심 로직(예약 가능 여부 확인 함수)만 먼저 작성. 컴포넌트 없이도 로직 테스트가 가능했음.

D+3

컴포넌트를 다시 짜기 시작. 데이터 구조가 명확하니 컴포넌트 분리 기준도 자연스럽게 정해짐.

D+5

기존 3주 걸렸던 기능을 5일 만에 복원, 게다가 처음부터 요구하지 않았던 좌석 관리 기능까지 포함해서 완성.

💡 이후로 바뀐 습관 이제는 기능을 만들기 전에 관련된 개념들을 종이에 명사로 먼저 적어본다. "이게 다른 개념인가, 같은 개념인가"만 구분해도 데이터 구조의 절반은 정해진다. 화면은 그 다음이다.

설계 없이 시작 — 진행 속도 체감7 / 10

 

요구사항 추가 시점 — 진행 속도 체감1 / 10

 

설계 후 재개발 — 진행 속도 체감9 / 10

 

최종 결과

처음 3주보다 재설계 후 5일이 훨씬 빠르게 느껴졌다. 빠르게 시작하는 것처럼 보였던 방식이 사실은 가장 느린 길이었다는 걸, 코드를 통째로 갈아엎고 나서야 몸으로 배웠다.

"화면을 먼저 그리고 싶은 유혹이야말로, 설계를 건너뛰게 만드는 가장 큰 함정이었다."

개인 사이드 프로젝트 규모에서의 경험을 바탕으로 작성했으며, 대규모 서비스에서는 설계 수준과 기간이 상황에 따라 크게 달라질 수 있다. 프로젝트 규모와 팀 상황에 맞게 설계 깊이를 조절하는 게 좋다.

결론

설계 없이 시작한 개발은 처음엔 빨라 보이지만, 요구사항이 하나만 추가돼도 그 대가를 몇 배로 치르게 된다는 걸 직접 겪고 나서야 체감했다. 화면을 그리기 전에 데이터와 개념부터 정리하는 짧은 시간이, 결과적으로 전체 개발 시간을 크게 줄여준다는 것도 배웠다. 지금 "일단 만들면서 생각하자"는 유혹을 느끼고 있다면, 종이 한 장 꺼내서 핵심 개념부터 적어보는 걸 권하고 싶다.

여러분도 비슷한 경험이 있으신가요?

설계 없이 시작했다가 갈아엎었던 경험이나, 그 과정에서 얻은 교훈이 있다면 댓글로 공유해주세요. 지금 비슷한 고민을 하고 있는 다른 개발자분들께 큰 도움이 될 것 같습니다.