아키텍처 인터뷰 도전: 개발자 설계 사고력 테스트
이 과제는 SOLID 원칙, 단일 책임 원칙(SRP), 시스템 유연성에 대한 이해를 평가합니다. 지원자는 기존 직원 급여 계산 구조(또는 클래스)를 확장하여 관리자도 포함할 수 있도록 해야 하며, 동시에 PDF 보고서도 생성해야 합니다. 핵심 제약 조건은 기본 급여 대비 동일한 KPI 및 보너스 비율을 유지하되, 관리자의 기본 급여는 더 높아야 한다는 점입니다. 시스템은 미래의 변경 사항에도 최소한의 영향을 받으며 대응할 수 있어야 합니다.
Go 언어에서는 struct를 사용하고, 클래스 기반 언어라면 class를 활용합니다. 표면적으로는 간단해 보이지만, 이 과제는 설계 위반을 파악하고 확장 가능한 아키텍처를 구축하는 능력을 시험합니다.
일반적인 실수와 AI 기반 해결책
대부분의 지원자는 SRP 위반을 간과합니다. 원래 구조는 급여 계산과 보고서 생성을 함께 처리하고 있습니다. 올바른 접근법은 책임을 분리하는 것입니다.
AI 기반 해결책은 구성(composition)과 인터페이스를 활용합니다:
- 공통 필드(급여율, KPI %, 보너스 %)와 메서드(
CalculateBase,CalculateKPI,CalculateBonus)를 가진 기본Employeestruct. CalculateSalary() *Report메서드를 가진 인터페이스SalaryCalculator.Manager는Employee를 구성하며 기본 급여에 다중값을 적용합니다.- 어떤
SalaryCalculator든 받아들일 수 있는 전용ReportGenerator. - 초기화를 담당하는 생성자
NewEmployee와NewManager.
문제점: 하나의 보고서 생성기는 미래의 차이(예: 직접 보고하는 직원 수, 다른 KPI 스케줄)를 고려할 수 없습니다. 이로 인해 조건문 로직이나 코드 재작성이 필요해지며, OCP 원칙을 위반하게 됩니다.
문제 설명 속 숨겨진 난이도
문제 지문은 의도적으로 함정을 포함하고 있습니다.
- SRP 위반: "급여를 계산하고 보고서를 만드는 클래스". 지원자는 이를 분리해야 합니다.
- 오류 있는 일반화: "동일한 KPI 및 보너스 비율". 각 역할별로 공식이 독립적으로 변화할 수 있습니다.
- 역할의 단순화: "기본 급여만 다릅니다". 관리자는 독립적인 비즈니스 엔티티이며, 고유한 KPI와 책임 영역을 가집니다.
강한 후보들은 명확화 질문을 던집니다: 공식은 어떻게 변할까요? 보고서에 어떤 데이터가 포함될까요? 새로운 역할은 계획되어 있나요?
지원자 평가 기준
코드보다 사고 방식에 초점을 맞춥니다.
- 질문의 질: 요구사항을 명확히 하고, 숨겨진 가정을 드러냅니다.
- 논리적 근거: 설계 선택의 이유를 설명합니다 (SOLID, 구성 vs 상속).
- 유연성: 시스템의 진화를 위한 계획 (역할 추가, 보고서 형식 확장).
- 장단점 분석: 제안된 해결책의 자기 비판적 검토.
- 테스트 가능성: 구성 요소들이 격리되고 단위 테스트가 가능하도록 설계되었습니다.
추천 아키텍처
실용적인 해결책 (Go 스타일, 클래스 기반 언어에도 적합):
- 인터페이스:
- SalaryCalculator: 기본, KPI, 보너스, 총액 계산 메서드.
- ReportDataProvider: 보고서에 필요한 데이터 제공 (급여, 추가 필드).
- ReportTemplate: Generate(ReportDataProvider) PDF.
- 구현체:
- EmployeeSalary와 ManagerSalary는 SalaryCalculator를 구현합니다.
- EmployeeReport와 ManagerReport는 ReportTemplate를 구현하며, 각각 해당 SalaryCalculator에 대한 참조를 보유합니다.
- 팩토리:
NewReport(templateType string, calc SalaryCalculator) ReportTemplate.
장점:
- 새로운 역할 추가가 쉬움 (예:
DirectorSalary+DirectorReport). - 보고서 생성기 내에서 조건문 로직이 필요 없음.
- 구성은 컴포넌트 간 재사용을 가능하게 합니다.
핵심 교훈
- SRP 강화: 계산과 보고는 별개의 관심사입니다.
- OCP 준수: 기존 코드를 수정하지 않고 새로운 역할을 추가할 수 있습니다.
- 상속보다 구성: 장기적인 시스템 적응성을 가능하게 합니다.
- 팩토리 패턴으로 캡슐화: 생성 로직의 복잡성을 숨깁니다.
- 지원자의 질문: 깊이 있고 성찰적인 분석을 나타냅니다.
— Editorial Team
아직 댓글이 없습니다.