그알것 — 그럼에도 알아야 할 것들
홈질문커뮤니티
로그인
그알것 — 그럼에도 알아야 할 것들

Service

  • 홈
  • 소개
  • 질문
  • 커뮤니티

My

  • 내 워크스페이스
  • 저장한 질문
  • 작성한 답변

Policy

  • 이용약관
  • 개인정보처리방침
  • 문의

© 2026 그알것 · What Still Matters

질문 목록Architecture
Architecture

레이어드 아키텍처란 무엇이며 싱크홀 안티 패턴은 무엇인가요?

실무4/5
설계5/5
인간4/5
기초3/5

면접관의 질문 의도

계층 정의만 외운 사람과, 계층을 둘지 말지·언제 건너뛸지를 트레이드오프로 설명하는 사람을 가르려는 질문이다. 싱크홀을 "나쁘다"로 끝내지 않고 _왜 생기고 언제 허용되는지_까지 풀 수 있는지 본다.

큐레이션 답변

학습 자료

레이어드 아키텍처는 표현·도메인·데이터 접근처럼 책임을 계층으로 나눠, 변경 영향 범위를 한 계층 안으로 가두는 구조다. 각 계층은 바로 아래 계층만 호출하고 위 계층의 사정은 모른다는 단방향 의존을 전제로 한다. 싱크홀 안티 패턴은 중간 계층이 자기 로직 없이 호출만 그대로 흘려보내는 상태를 가리킨다. 결국 "계층을 왜 두는가"라는 질문에 답이 안 나오면, 일관성이라는 명목으로 빈 껍데기가 쌓이는 셈이다.

좋은 답변 구조

  1. 01레이어드 아키텍처의 정의와 단방향 의존이라는 핵심 규칙을 먼저 짚는다
  2. 02싱크홀 안티 패턴이 무엇인지, 왜 생기는지를 중간 계층의 책임 부재로 설명한다
  3. 03일관성으로 얻는 이점과 빈 계층이 만드는 비용을 트레이드오프 축으로 정리한다
  4. 04어떤 상황에서 계층을 그대로 두고 어떤 상황에서 합치거나 건너뛰는지 기준으로 마무리한다

자주 실수하는 포인트

싱크홀을 "무조건 없애야 한다"로 단정하고, 일관성으로 얻는 가독성·온보딩 이점을 무시한다
계층 분리의 목적인 책임 분리는 빼고 "규칙이니까 통과시킨다"는 식으로 답한다
단방향 의존 규칙과 싱크홀(로직 부재)을 같은 문제로 묶어 설명한다
헥사고날·클린 아키텍처를 끌어와 비교는 하지만, 정작 이 팀에서 왜 그게 필요한지 기준은 못 댄다

실무 맥락

  • CRUD가 대부분인 어드민·내부 도구에서 서비스 계층이 리포지토리 호출만 감싸는 코드베이스
  • 도메인 규칙이 두꺼워지면서 컨트롤러나 리포지토리에 로직이 흘러 들어간 레거시 모듈
  • 여러 팀이 같은 모노리스를 만지며 계층 규칙을 강하게 강제하는 조직
  • 헥사고날·클린 아키텍처로 이전을 검토하면서 현재 계층의 실효성을 다시 따져보는 상황

본인 경험에 녹이는 힌트

서비스 계층이 위임만 하던 모듈에서 도메인 규칙을 끌어올리거나 계층을 합쳐본 경험이 있다면, 싱크홀 판단 기준으로 풀어낼 수 있다

팀 컨벤션으로 "계층 생략을 어디까지 허용하는지" 합의했던 일이 있다면, 일관성과 비용 사이의 선택 근거로 연결할 수 있다

코드 리뷰에서 "이 서비스 메서드 정말 필요한가"를 두고 갈렸던 경험이 있다면, 책임 부재형 계층을 진단하는 시각으로 정리할 수 있다

헥사고날·클린 아키텍처로 일부 모듈을 옮겨본 적이 있다면, 레이어드의 한계를 _현장 비용_ 관점에서 비교해 말할 수 있다

커뮤니티 인기 답변

전체 0개

아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.

관련 꼬리 질문

Q1어떤 기준에서 서비스 계층을 합치거나 건너뛰는 걸 허용하나요
Q2레이어드와 헥사고날·클린 아키텍처를 어느 시점에 갈아탈 만한 신호로 보나요
Q3싱크홀을 코드 리뷰나 정적 분석으로 미리 감지할 방법이 있을까요
Q4도메인 규칙이 거의 없는 CRUD 서비스에서도 레이어드를 강하게 유지할 가치가 있나요
아직 답을 쓰지 않았어요.
큐레이션 답변과 다른 사람 답변을 보고, 자기 언어로 답을 정리해보면 학습 효과가 가장 큽니다.
목차
  • 01면접관의 질문 의도
  • 02큐레이션 답변
  • 03좋은 답변 구조
  • 04자주 실수하는 포인트
  • 05실무 맥락
  • 06본인 경험에 녹이는 힌트
  • 07커뮤니티 인기 답변준비중
  • 08관련 꼬리 질문