Day 2 학습 : 모듈화와 오버 엔지니어링 방지

첫날 실습을 통과하고 이제 Day2로 넘어왔습니다!
1일차보다 훨씬 구체적인 테크닉을 배우는 시간이었는데요,
처음에는 “이 정도면 뭐든 만들 수 있겠는데?”라는 근자감이 생겼지만…
워워~ 차분히 꾸준히 배워보기로 했습니다.

🛑 바이브 코딩의 최대의 적 : 오버 엔지니어링

  • 문제점
    모호한 지시는 불필요한 코드를 만들고,
    일관성/안정성/가독성을 해치는 주범이 됩니다.
  • 해결책
    “정확한 지시”를 내려 확대 해석을 방지해야 합니다.
    (1일차에서도 강조했던 부분!)

🧩 모듈화란?

특정 기능을 한 번에 다 개발하는 대신, 작은 단위(모듈)로 나누어 관리하는 방식입니다.

  • 개발자 관점: 한 파일에 전부 때려넣는 게 아니라 기능별 파일로 쪼갠 뒤 main 파일에서 불러오는 것.
  • 비개발자 관점: 큰 프로젝트를 작은 조각으로 나눠서 관리하는 느낌.

🍱 도시락 예시
밥, 반찬, 국, 디저트를 한 통에 다 섞어버리면 보기에도 안 좋고 먹기도 불편합니다.
칸을 나눠 정리하면 깔끔하고 편하죠? -> 이게 바로 모듈화!
즉, 기능별로 ‘칸’을 나누는 것과 같습니다.

📌 모듈화가 필요한 이유

  • 관리성 : 고장 난 부분만 고치면 됨
  • 재사용성 : 다른 프로젝트에서도 활용 가능
  • 협업 효율 : 각자 다른 모듈을 맡아 동시에 개발 가능
  • 코드 가독성 : 구조가 정리돼 보기 좋음

🖥️ 모듈화 기준 : 상호작용 vs 비즈니스 로직

  • 상호작용 (presentation)
    사용자 입출력 담당. 디자인이 바뀌면 수정되는 부분.
  • 비즈니스 로직 (business logic)
    핵심 기능 수행 담당.

💡 1일차 게임 예시:

  • 상호작용: 사용자 입력 처리, 게임 상태 UI
  • 비즈니스 로직: 캐릭터 위치·낙하물 위치·점수 계산 엔진

이렇게 분리해두면, 디자인만 바꿔도 기능은 그대로 유지됩니다.
반대로 분리하지 않으면 “디자인만 바꿨는데 기능 버그 발생” 같은 문제가 생길 수 있습니다.

✍️ 모듈화 응용 프롬프트 활용법

바이브코딩 취지 = 요구사항만 입력, 분석은 AI에게 맡기기

다음 요구사항을 구현하기위한 최소한의 모듈화 설계 진행하라.
반드시 다음 순서를 따라야한다.
1. 요구사항을 분석하여 자세한 user flow, data flow를 작성한다
...
(이후 완벽한 프롬프트는 교육자료에 제시된 내용 활용)

---

(여기에 요구사항 붙여넣기)

주의: 결과에서 모듈이 너무 많으면 오버 엔지니어링!

가이드라인

  • 기능 1개당: 상호작용 1~3개 + 비즈니스 로직 1개
  • 단순 UI: 상호작용 1개, 비즈니스 로직 없음

🔧 오버 엔지니어링 방지 프롬프트
너무 많은 모듈이 포함되어, 오버 엔지니어링 상태다.
단순화하여 다시 최종본을 응답하라.

👉 이렇게 단순화 프롬프트를 던지면
cursor, claude code, windsurf 등 AI 툴에 적용 가능!

✨ 마무리

오늘 배운 모듈화는 단순히 코드 관리 기술이 아니라
협업, 유지보수, 그리고 오버 엔지니어링을 막는 핵심 전략이라는 걸 깨달았습니다.

Day2 실습도 완료했으니, 곧 실제 후기도 공유해 보겠습니다!

Leave a comment