[AI] 전체 프로젝트 설계 회고 - 100-hours-a-week/5-yeosa-wiki GitHub Wiki

1. 전체를 설계하며 느낀 점

이전엔 해커톤처럼 기능만 빠르게 구현하던 경험밖에 없었는데, 이번엔 처음부터 끝까지 전체 시스템을 설계해보면서 단순히 돌아가는 코드만 만든다고 끝이 아니라는 걸 실감
기능 단위가 아닌 책임과 흐름 중심으로 시스템을 바라보게 되었고, “이 기능이 어디서 실행되어야 하는가?”, “확장되면 어떤 문제가 생길 수 있는가?” 같은 실무적인 질문을 스스로 던지게 되었음
기능 구현만으로는 부족하다는 걸 알게 됐고, 서비스가 커질수록 설계, 최적화, 구조 고민이 얼마나 중요한지 느낄 수 있었음
처음에는 클라우드나 백엔드 구조, 비동기 처리 같은 것에 익숙하지 않아 “한 번에 여러 요청이 들어오면 어떻게 처리되지?”같은 기본적인 개념도 잘 몰랐지만, 이번에 직접 구조를 만들고 테스트하면서 전체를 보는 시각을 갖추게 되었음
성능, 유연성, 유지보수성 중 어느 하나만을 최적화할 수는 없다는 것을 알게 되었고, 실제 운영 가능한 아키텍처는 균형 잡힌 현실적인 선택과 끊임없는 수정 과정을 통해 만들어진다는 점을 체감

지금까지는 그냥 내가 편한 기술, 익숙한 모델을 써왔지만, 팀 프로젝트에서는 모든 컴포넌트의 사용 근거가 필요하다는 걸 체감
- “왜 이 모델을 쓰는지”, “왜 이 구조가 적절한지”를 설명하려면 나 스스로 정확히 이해하고 있어야 하고, 이 과정에서 더 깊이 배울 수 있었음
- 기술을 쓸 ‘시점’과 ‘이유’를 판단할 수 있게 되었다는 점이 가장 큰 성장
단일 인스턴스를 기준으로만 설계했던 초기 구조에서, 다중 인스턴스로 확장되었을 때 생기는 문제들(캐시 공유, 메시지큐 분산, NAT 병목 등)을 처음으로 마주함
- 이 문제들을 해결해 나가는 과정에서 개념으로만 알고 있던 내용을 실제 상황 속에서 이해하게 되었음
캐싱, 배치 처리 등 최적화하기 위한 방법들을 실제로 적용하고 테스트해보면서 “이런식으로 개선해나갈 수 있구나”하는 깨달음을 얻었음
‘이게 정답이다’는 없고, ‘지금 이 환경에서 가장 현실적인 선택은 뭘까’를 끊임없이 고민해야 한다는 것이 인상 깊었음

설계를 진행하며 팀원끼리 단순히 역할만 나눈 게 아니라, 설계 과정 전체를 함께 고민하고, 서로 배운 것을 주기적으로 나누며 진행했음
각자 맡은 영역은 달랐지만 공부한 내용을 일주일에 두 번 이상 정기적으로 공유하면서, 혼자였으면 지나쳤을 부분들도 함께 채워갈 수 있었음
동료가 먼저 파악한 내용을 나에게 알려주면서 나도 자연스럽게 새로운 관점을 접할 수 있었고, 내가 먼저 공부한 내용을 설명하려고 준비하면서 내 생각을 구조화하는 습관도 생겼음
역할을 잘 수행하는 동시에, 공부와 성장도 같이 했다는 점이 정말 큰 의미있었고, “좋은 협업은 단지 일을 나누는 게 아니라 서로 배우는 흐름이 계속 이어지는 것”이라는 점을 깨달음
결과적으로 각자가 맡은 일을 잘 끝내는 것에서 그치지 않고, 서로를 도우면서 팀 자체가 더 높은 수준으로 나아갈 수 있었던 경험이었음

이번 프로젝트 설계에서 우리가 진짜로 해내고자 했던 것은 단순히 기능이 돌아가는 서비스를 만드는 것이 아니라 지속적으로 성장하고 확장할 수 있는 구조를 직접 설계하고 구현하는 것
모델을 고르고 붙이는 데 그치지 않고, “왜 이 구조여야 하는가”, “어떻게 나중에도 유지보수할 수 있을까”를 계속 질문하고, 질문에 대한 답을 하나씩 해결해가며 쉽게 무너지지 않는 서비스를 구축하고자 했음
우리는 이번 과정을 통해 당장의 MVP만을 위한 설계가 아니라 확장과 유지보수, 고도화까지 내다보는 설계 사고방식을 갖출 수 있었고, 이제는 어떤 문제든 “어떻게 구조화해서 해결할 것인가”라는 시야로 접근할 수 있음
앞으로 이 설계를 바탕으로 더 많은 사용자, 더 복잡한 기능, 더 안정적인 운영을 향해 나아갈 것이고, 그 과정에서도 항상 설계의 본질과 책임을 잊지 않고 우리가 직접 만든 시스템을 스스로 발전시켜 나갈 것