설계 단계에 대한 최종 회고

---

1. 설계 과정에서 무엇을 배웠는가

• 초기 설계는 불완전할 수밖에 없다는 것
  완벽한 기획은 존재하지 않으며, 실제 구현에 들어가기 전이라도 끊임없이 수정과 보완이 필요하다는 점을 배웠다.

• 계획 수립에도 구체성이 절대적으로 필요하다는 것
  "좋은 성능", "빠른 응답"처럼 추상적인 목표만 설정하면 실제 설계 시 구체적 선택(모델, 서버 등)에서 오히려 혼란이 커진다는 것을 체감했다.

• 의사결정 기준을 명확히 세워야 한다는 것
  비용, 성능, 확장성, 유지보수성 등 어떤 기준을 최우선으로 할지 합의 없이 계획하면, 이후 설계 변경이 반복된다는 점을 배웠다.

• 리스크를 미리 정의하고 감수하는 법
  모든 요소를 완벽하게 준비할 수 없기 때문에, 어떤 부분에서 위험을 감수할지(예: 모델 선정) 명확히 정해두는 것이 중요하다는 걸 배웠다.

---

2. 설계 과정에서 겪었던 어려움과 시도

주요 어려움

• 모델 선정 시 구체적 기준 미흡
  처음에는 모델 성능만 보고 선택하려 했지만, 실제 추론 환경(T4 서버 사양, 비용)과 맞지 않는 경우가 발생할 뻔했다.

• 서버 인프라 구조 확정 지연
  On-premis와 GCP와 AWS를 혼용할지 여부를 빠르게 결정하지 못해, 초기 구조 정의에 시간이 지연되었다.

• 기능 단위 명확화 부족
  자연어 검색, 모임 추천, 일정 추천 API를 어떻게 구분할지 초기 단계에서 구체화하지 못했다.

• Guardrail 적용 범위 애매함
  단순 개인정보 검열이 목표인지, 입력 검증까지 포함할지 계획 단계에서 기준을 세우지 못해, 이후 혼선이 발생했다.

시도 및 교정

• 모델 선정 시, 단순 성능이 아닌 T4 환경 최적화(4-bit 양자화, LoRA 적용)를 기준으로 재설계
• 서버 인프라를 AI 서버(GCP), 웹 서버(AWS) 로 명확히 분리
• API 흐름을 기능 단위별로 분리하고, RESTful Convention에 맞춰 재정의
• Guardrail의 목적을 재정의하여 모델 안정성을 위한 입력 필터링으로 확장

---

3. 해결하지 못한 부분

• Auto-scaling 등 인프라 확장 설계
  계획 당시 인지했으나, 실제로 구체적인 오토스케일링 정책까지 설계하지 못하고 '추후 과제'로 미뤄짐.

• Guardrail 상세 설계
  PyDynamic 등을 검토했지만, 실제 어떤 기준으로 어떤 위험 입력을 차단할지 구체 시나리오를 만들지 못함.

---

4. 프로젝트 기획을 통해 느낀 점

• 구체적 기준 없는 기획은 설계 지연을 초래한다
  모든 선택에는 명확한 판단 기준이 필요하며, 그렇지 않으면 논의가 반복되고, 초기 설계가 지연된다.

• 리스크를 무시하면 나중에 더 큰 비용을 치른다
  초기에는 Guardrail, 인프라 확장 등을 "나중에 생각하자"고 미뤘지만, 실제 설계 후반부에서 큰 부담으로 돌아왔다.

• 설계는 "최적"이 아니라 "타협"의 결과다
  비용, 성능, 품질, 확장성 사이에서 모든 것을 만족시키는 것은 불가능하며, 어떤 요소를 우선순위로 둘지 팀 내 합의가 가장 중요했다.

• Planning은 진행 중 끊임없이 업데이트되어야 한다
  초기 계획은 반드시 현실에 맞춰 지속적으로 수정되어야 하며, 이를 부담스럽게 생각하지 말고 자연스러운 과정으로 받아들여야 한다는 점을 느꼈다.

---

최종 결론

본 프로젝트의 설계 과정은 완벽하지 않았지만,

• 핵심 기능을 정의하고
• 제한된 리소스와 환경에 맞는 현실적인 아키텍처를 도출하고
• 주요 리스크를 인지한 상태로 시스템 통합을 준비했다는 점에서

기획 및 설계 관점에서 성공적인 학습 경험이었다고 평가할 수 있다.
향후 프로젝트에서는

• 초기 기준 설정 강화,
• 리스크 대비 계획 수립,
• 설계-구현 연결 강화를 목표로 삼아야 할 것이다.