이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
팀 프로젝트에서 재무 담당 팀원과 함께 정산 기능을 개발하면서 비개발 직군과의 소통 방식을 처음 체계적으로 고민했습니다. 가장 중요하다고 느낀 건 도메인 용어를 합의하는 것이었는데, 개발자가 쓰는 트랜잭션과 회계가 쓰는 거래는 의미가 달랐고 초반에 이를 혼용하니 설계 오해가 생겼습니다.
공용 용어 정의서를 문서로 남겨두고 양쪽이 참조하게 하니 커뮤니케이션 오해가 크게 줄었습니다. 기술 설명을 할 때는 구현 방법보다 비즈니스 결과를 중심으로 말하는 것이 회계 담당자에게 더 명확하게 전달됐고, 데이터베이스 트랜잭션보다 한 번에 다 반영되거나 아무것도 반영되지 않는다는 표현이 더 이해하기 쉬웠습니다. 지금도 비개발 직군과 소통할 때는 상대방의 관심사 언어로 맞춰 말하는 습관을 유지하고 있습니다.
회계 부서와의 소통 경험에서 배운 것이 이후 비개발 직군 전체와 소통하는 방식에 영향을 줬습니다.
스타트업 인턴 시절 회계 담당자에게 데이터 처리 결과를 설명해야 하는 자리가 있었습니다. 제가 사용한 기술 용어를 잘 이해하지 못하는 것을 느꼈지만, 어떻게 설명해야 할지 몰랐습니다. 결국 담당자가 회의에서 '그래서 숫자가 어떻게 된다는 건가요?'라고 직접 물었고, 그때서야 설명 방식이 잘못됐다는 것을 알았습니다.
이후 비개발 직군에게 설명할 때 '이 시스템이 어떻게 작동하는가'보다 '이 시스템이 당신의 업무에 어떤 변화를 주는가'를 먼저 말하는 것을 원칙으로 삼았습니다. 회계에게는 계산이 정확하게 반영되는지, 마감 일정에 맞는지가 핵심이었고, 그 부분을 먼저 전달하면 소통이 빨라졌습니다.
상대방이 무엇을 궁금해하는지를 먼저 파악하는 것이 설명의 출발점이라는 원칙이 이 경험에서 자리 잡혔습니다.
회계 부서와 소통하면서 제가 양보해야 했던 자리가 있었습니다.
개발 관점에서는 특정 계산 로직을 한 번에 처리하는 것이 더 효율적이었는데, 회계 담당자는 중간 계산 결과를 단계별로 확인하고 싶다는 요청을 했습니다. 개발자 입장에서는 불필요한 중간 단계처럼 느껴졌지만, 회계 업무에서는 감사 시 각 단계가 맞는지 확인하는 것이 중요하다는 것을 설명을 들으면서 이해했습니다.
중간 결과를 로그로 남기고 조회할 수 있는 기능을 추가했습니다. 개발 복잡도가 조금 늘었지만 회계 담당자가 스스로 수치를 확인할 수 있게 됐고, 이후 같은 유형의 질문이 줄었습니다.
기술적으로 효율적인 것과 업무적으로 필요한 것이 다를 수 있습니다. 상대방의 요청이 처음에 불필요하게 느껴질 때, 그 요청의 배경을 먼저 이해하는 것이 협업에서 더 나은 결과를 만드는 자리가 있다는 생각이 남아 있습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 넥스트증권 SW·IT 일반 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.