🎙️ 심플 디자인 밋업 정리

🧭 밋업의 목적

이번 밋업은 단순히 "좋은 코드가 뭘까?"에 대한 정답을 알려주는 자리가 아닙니다.

스타트업 어드바이저의 시각에서, 팀과 개인이 코드 품질을 어떻게 고민하고 객관화할 수 있는지에 대한 사고의 흐름과 기준 도출 과정을 함께 공유하고자 한 자리입니다.

📖 핵심 주제: 좋은 코드란 무엇인가?

✅ 우리가 흔히 말하는 "좋은 코드" 기준

• 가독성이 좋아야 한다
• 중복 코드가 없어야 한다
• 짧고 간결해야 한다
• 구조적으로 잘 짜여 있어야 한다

하지만, 이 기준은 사람마다 다르게 해석되며, 애매하고 추상적인 경우가 많습니다.

그래서 이번 밋업에선 이 원칙들이 어떤 맥락에서 유효한지, 진짜 의미는 무엇인지를 파고들었습니다.

🔍 발표자의 관점에서 본 좋은 코드

💡 핵심 요약:

"중복이 없고, 구성요소가 최소화된 코드"

1. 중복 제거는 어떻게 해야 하는가?

🙅 중복처럼 보이는 것 = 항상 제거 대상이 아님

• extract method 남용의 문제
  • 긴 함수 → 무조건 짧게 쪼개는 건 오히려 코드 품질 하락
  • 너무 쪼개면 함수들을 “왔다 갔다”하게 되어 실행 흐름 파악이 어려워짐
  • 디익스트라의 "goto considered harmful"와도 연결됨
    • goto의 문제: 흐름 제어를 예측하기 어려움
    • 너무 많은 함수 분할 = “함수 간 점프”가 생김
    • 해결 방법: 점프가 생기지 않는 구조로 분리할 것

📌 요약: 함수를 짧게 만들되, 흐름을 유지하고 부작용을 피하는 방향으로 설계

💬 조건절 중복

• if문이 많아질수록 확산 가능성이 높음
  • ex) if user.role == "admin" 같은 조건들이 여러 곳에 흩어짐
• 해결 방법: 다형성을 이용한 클래스 추출
  • 각 조건을 객체로 표현해서 분기 로직 제거

🧱 필드/속성 중복

• 백엔드에서는 엔티티의 필드가 반복적으로 Getter/Setter, DTO, Service 등에서 반복됨
  • → Spring Data Rest로 엔티티만 정의하고 API 자동화 가능
• 프론트엔드에서는 유효성 검사가 서버/클라이언트 양쪽에서 이중으로 필요
  • 이런 중복은 제거 가능한가? → OpenAPI 스키마 활용
    • 엔티티 → TypeScript 타입 → Form 자동 생성까지 연결

실전 팁: schema-first 방식 + 코드 자동 생성 도구를 병행하면 중복을 많이 줄일 수 있음

2. 구성요소는 어떻게 줄이는가?

⚙️ 줄일 수 있는 요소들

• 클래스
• 메서드
• 변수
• 상수
• 디렉토리 구조

"작으면 작을수록 좋다"는 게 핵심이지만, 그 전에 한번에 이해되는 수준이어야 함

⚠️ 과도한 일관성 유지의 문제

• 팀 내 디렉토리 구조를 억지로 맞추는 경우 (e.g. controller/service/repository 반복)
• Spring Data Rest vs. DTO 기반 개발
  • 디렉토리는 일관되지만, 실제 사용성은 떨어질 수 있음
  • 디렉토리 깊이가 깊어지면 오히려 명령어 길어지고 유지보수 어려워짐

✅ 중복과 구성요소 줄이기의 결합 전략

• 중복 제거 = 의존성도 제거
  • 모양이 똑같다면, 기능도 비슷할 가능성 높음 → 의존성 파악 쉬움
• 무조건 제거할 필요는 없지만, 일단 시도해보면 판단 근거가 생김

🔍 코드 품질을 높이는 이유

1. 비즈니스 가치를 더 빨리 전달하기 위함
   • 빠른 개발 = 좋은 품질의 코드가 전제되어야 가능
   • 리팩터링을 안 해서 시간이 없는 게 아님 → 처음부터 품질을 고려하지 않아서 시간이 없어지는 것
2. 고객 니즈는 개발 중 계속 바뀜
   • 초반에 완벽하게 설계하려 하지 말고, 변화를 수용 가능한 구조를 만드는 게 중요

🛠️ 자동화는 언제, 어떻게?

🙅 무조건 자동화는 위험

• 복잡한 것을 자동화하면 → 복잡성이 구조로 고착됨
• → 수정이 더 어려워짐

✅ 올바른 순서

1. 단순화
2. 그 다음 자동화

도요타 생산 방식(Toyota Way)에서도 강조

"불합리한 과정을 그대로 자동화하지 말고, 먼저 단순하게 만들라"

🧗 심플 디자인은 쉬운가?

드라이퍼스 모델(Dreyfus Model)로 접근

• 초보자: 규칙 기반 → 명확한 지침 필요
• 전문가: 직관 기반 → 경험으로 유연하게 판단

따라서…

• 초보자는 일단 극단적으로 심플하게 개발해보며 중복, 구성요소, 단어까지 모두 줄여보는 실험 필요
• 그 과정에서 자신만의 기준을 정립할 수 있음

💬 발표 중 주요 Q&A 및 인사이트

질문	요점
중복 제거가 항상 옳은가?	제거해보지 않으면 판단 불가. 모양이 같으면 중복일 가능성 큼
클린코드/리팩터링은 일관성 중요?	일관성은 수단일 뿐, 좋은 코드 그 자체는 아님
컨벤션의 필요성?	네이밍 등은 단순 문제. 팀 내 협의로 해결 가능
추상화와 심플 디자인의 충돌?	extract method는 추상화와 다른 문제. 기능 단위 추출이 목적이면 적절
비즈니스 가치와 좋은 코드의 균형?	극단적으로 좋은 코드 시도 → 그 과정에서 균형 지점 발견 가능

🎯 마무리: 우리가 얻어야 할 것

• 좋은 코드를 위해 어떤 질문을 던져야 하는지 알게 됨
• 객관적 사고 → 신뢰할 수 있는 주관적 기준 형성
• 심플 디자인은 결과가 아닌 과정
• 팀 내 코드 품질 논의를 위한 공통 언어와 기준 마련에 도움