이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
개발 중 설계 이슈가 생겼을 때 팀원들과 소통하는 방식은 먼저 문제를 재현 가능한 형태로 정리하는 것입니다. 막연하게 버그가 있다고 말하면 다른 사람이 이해하고 도움을 주기 어렵습니다. 어떤 조건에서 어떤 문제가 생기는지, 어디까지는 확인했고 어디서부터 모르는지를 명확히 해야 논의가 빠르게 진행됩니다. 프로젝트에서 설계 이슈가 생겼을 때 코드나 다이어그램을 함께 보면서 논의하는 방식이 말로만 하는 것보다 훨씬 효과적이었습니다. 의견이 다를 때는 어떤 기준으로 판단할지를 먼저 합의하면 감정 없이 논의할 수 있었습니다. 이슈 해결 방향이 정해지면 결정 내용을 짧게 문서에 남기는 것을 좋아합니다. 나중에 왜 그렇게 했는지를 기억하지 못하는 경우가 생기기 때문입니다.
설계 소통은 결론보다 과정을 남기는 것이 더 가치 있습니다.
설계 이슈 소통에서 의견이 달랐던 자리가 기술 논쟁이 아니라 서로가 어떤 자리를 중요하게 여기는지의 차이에서 생기는 자리라는 것을 경험했습니다. 상대가 왜 그 방향을 주장하는지를 먼저 파악하면 논의가 빠르게 좁혀지는 자리가 됩니다.
팀 프로젝트에서 데이터베이스 설계 방향이 달랐던 자리가 있었습니다. 처음에는 제 방식이 맞다고 주장했는데, 상대가 왜 다른 구조를 원하는지를 물어봤더니 나중에 확장할 자리를 고려한 것이라는 것을 알게 됐습니다. 그 자리에서 확장성 관점을 받아들이는 쪽이 더 나은 자리라는 것을 인정하고 방향을 바꿨습니다. 상대 관점을 먼저 물어보는 것이 논쟁보다 빠른 자리가 됩니다.
상대 이유를 먼저 파악하는 것이 설계 소통의 속도를 높이는 자리라고 생각합니다. 파악이 있어야 합의가 됩니다.
지금도 설계 이슈 소통은 옳고 그름보다 서로의 자리를 이해하는 것이 먼저인 자리라고 생각합니다. 이해가 있어야 소통이 됩니다.
설계 이슈 소통에서 그때마다 방식을 결정하면 매번 다른 방식으로 소통하게 되고, 팀원마다 기대하는 자리가 달라지는 문제가 생긴다는 것을 알게 됐습니다. 소통 방식을 원칙으로 합의해두면 이슈가 생겼을 때 방식을 결정하는 자리가 줄어드는 방식이 됩니다.
팀 프로젝트 초반에 이슈가 생겼을 때 어떻게 공유하고, 언제 회의를 열고, 결정을 어떻게 남기는지를 팀이 함께 합의한 경험이 있었습니다. 이 원칙이 있으니 나중에 이슈가 생겼을 때 방식을 논의하지 않고 바로 내용에 집중하는 자리가 됐습니다. 소통 원칙을 초반에 정해두는 것이 후반에 갈등을 줄이는 자리가 됩니다.
소통 원칙을 팀이 함께 정하는 것이 이슈 해결 속도를 높이는 자리라고 생각합니다. 원칙이 있어야 속도가 됩니다.
지금도 설계 소통은 이슈가 생긴 후 결정하는 것보다 이슈 전에 방식을 정해두는 자리라고 생각합니다. 방식이 있어야 소통이 됩니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 에스엘 공통직무·미지정 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.