이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
캡스톤 프로젝트에서 시스템 전체 아키텍처를 처음 직접 설계했습니다. 기능 요구사항만 정리했다가 나중에 성능·가용성·보안 같은 비기능 요구사항을 놓쳤다는 걸 알게 됐습니다. 이후엔 아키텍처 설계 시 트래픽 예측치, 응답 시간 목표, 장애 복구 시간을 먼저 정의하는 방식을 익혔습니다. 도메인 경계도 중요한데, 서비스 간 결합이 너무 높으면 변경할 때 파급 범위가 커진다는 걸 직접 겪었습니다. 통합 지점에서는 외부 시스템 변경에 느슨하게 결합된 인터페이스를 설계하는 것도 고려했습니다. 운영 관점에서는 로그·지표·알림이 설계 단계부터 포함돼야 배포 후 문제를 빠르게 파악할 수 있다는 걸 배웠습니다.
아키텍처는 당장 만들 기능보다 미래 변경 비용을 줄이는 설계라는 게 지금 갖고 있는 생각입니다.
아키텍처 결정을 내릴 때 개발팀 외의 이해관계자에게 설명해야 하는 상황이 생겼습니다. 마이크로서비스 전환이 필요한지 논의했는데, 기술적 설명만 하면 비즈니스 관점에서 왜 필요한지 납득이 어려운 결이 있었습니다. 이해관계자에게는 현재 배포에 걸리는 시간과 장애 발생 시 영향 범위를 먼저 설명했습니다. 아키텍처 선택이 서비스 안정성과 개발 속도에 어떻게 연결되는지를 비용과 리스크 기준으로 설명했더니 더 빠르게 논의가 진행됐습니다. 기술 용어 없이 설명하는 과정에서 오히려 본인이 선택의 이유를 더 명확히 정리하게 됐습니다. 이해관계자 설명은 아키텍처 결정을 검증하는 또 다른 방법이라는 것을 이 경험에서 배웠습니다.
프로젝트에서 팀이 두 개로 나뉘어 각자 다른 모듈을 개발했는데, 시간이 지나니 두 모듈 사이의 경계가 팀 경계와 정확히 일치하게 됐습니다. 처음에는 우연이라고 생각했는데, Conway의 법칙을 배우고 나니 조직 구조가 아키텍처를 닮는 결이 자연스럽다는 것을 이해했습니다. 두 모듈이 강하게 결합돼 있어서 한 팀의 변경이 다른 팀에 영향을 주는 일이 반복됐습니다. 이를 줄이기 위해 모듈 간 인터페이스를 명확히 정의하는 작업을 먼저 진행했습니다.
아키텍처를 설계할 때 팀 구조를 함께 고려해야 한다는 것을 이 경험에서 처음 체감했습니다. 기술 설계와 조직 설계가 분리된 것이 아니라 서로 영향을 주는 결이라는 것이 남았습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 현대카드/현대커머셜 풀스택 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.