이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
인턴 때 코드 리뷰 문화가 막 생기기 시작한 팀에 합류해서 아키텍처 원칙을 어떻게 퍼뜨릴 수 있을지 고민했습니다. 처음엔 설계 원칙을 문서로 정리해서 공유했는데, 문서보다 코드에서 패턴이 반복되는 게 더 빠른 전파 방식이라는 걸 느꼈습니다. 리뷰를 통해서 레이어 경계를 넘는 직접 접근이 생길 때마다 이유를 설명하는 코멘트를 남기는 방식을 썼습니다.
린터 룰을 추가해서 특정 패턴이 자동으로 감지되도록 했더니, 도구가 규칙을 상기시키는 역할을 해줬습니다. 팀 내 교육은 별도 세션보다 PR 리뷰에서 예시 코드를 함께 보는 자리가 더 잘 흡수됐습니다. 아키텍처 원칙을 퍼뜨리는 건 설계 문서를 쓰는 것보다 리뷰에서 반복 노출시키는 것이 더 실질적이라는 걸 그때 배웠습니다.
규칙은 코드베이스에 살아 있어야 원칙이 되고, 문서에만 있으면 참고 자료가 됩니다.
소프트웨어 아키텍처 원칙을 팀에 적용하면서 그 효과를 실제로 확인한 경험이 있습니다. 레이어 경계를 명확히 하는 원칙을 도입하기 전에는 코드 리뷰에서 구조 관련 논의가 자주 나왔고, 같은 지적이 반복되는 경우가 있었습니다. 린터 룰로 일부 패턴을 자동으로 감지하게 하고, 리뷰에서 구조 위반을 지속적으로 피드백하니 몇 주 후부터 같은 유형의 지적이 줄어들었습니다. 수치로 정확히 측정하지는 못했는데, PR 리뷰에서 구조 관련 코멘트 수가 줄어든 것을 관찰할 수 있었습니다. 아키텍처 원칙은 한 번 설명으로 전파되는 것이 아니라 코드에서 반복적으로 확인받는 과정에서 팀 전체의 습관으로 자리잡는다는 것을 이 경험에서 배웠습니다. 도구와 리뷰가 함께 작동할 때 원칙이 코드베이스에 실제로 반영되는 속도가 빨라진다는 것도 알게 됐습니다.
소프트웨어 아키텍처 원칙을 꾸준히 적용한 코드베이스와 그렇지 않은 코드베이스에서 새로운 기능을 추가하는 경험을 비교해볼 수 있었습니다. 원칙이 잘 적용된 코드는 새로운 기능을 추가할 때 영향 범위를 예측하기 쉬웠고, 기존 코드를 크게 수정하지 않아도 원하는 변경을 할 수 있었습니다. 그렇지 않은 코드에서는 하나를 수정하면 다른 곳에서 예상치 못한 영향이 생기는 경우가 많았고, 변경 전에 어느 부분이 영향받는지를 확인하는 데 시간이 들었습니다. 이 차이가 코드베이스에 쌓이면서 나중에 기능 추가 속도의 차이로 이어진다는 것을 직접 경험했습니다. 아키텍처 원칙을 지키는 비용은 초기에는 보이지 않지만, 코드베이스가 커질수록 그 가치가 드러난다는 것을 이 경험에서 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 삼성전자 풀스택 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.