이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
팀 프로젝트에서 다른 팀원의 코드를 읽으면서 이름 짓기의 중요성을 처음 체감했습니다. getData()나 temp 같은 이름이 있는 코드를 맥락 없이 읽으면 의도를 파악하는 데 불필요한 시간이 들었고, 이후 내 코드에서는 이름이 의도를 드러내는지를 먼저 검토하는 습관이 생겼습니다. 기준으로는 함수 이름에 동사를 쓰고 단일 행위를 표현하는지 확인하고, 변수는 타입보다 무엇을 담는지를 반영한 이름을 씁니다.
이름을 짓기 어렵다면 그 변수나 함수의 책임이 너무 많다는 신호인 경우가 많았는데, 이 기준이 리팩터링의 출발점이 되기도 했습니다. 지금도 이름이 불명확하면 일단 멈추고 책임 범위를 먼저 다시 정의하는 방식을 따릅니다.
팀 프로젝트에서 같은 역할을 하는 함수를 서로 다른 사람이 다른 이름으로 작성한 경우를 경험했습니다. 한 사람은 fetchUser로, 다른 사람은 getUser로 지었는데, 코드를 읽는 입장에서 두 함수가 하는 일이 다른 것인지 같은 것인지 파악하기 어려웠습니다. 이후 팀에서 이름 짓기 컨벤션을 맞추는 시간을 가졌는데, 비동기 외부 호출에는 fetch, 동기 로컬 접근에는 get을 쓰기로 합의했습니다. 컨벤션을 문서화하는 것도 중요했는데, 새로운 팀원이 합류했을 때 구두로만 전달하면 일관성이 유지되지 않는다는 것을 알게 됐습니다. 이 경험에서 이름 짓기는 개인의 판단만으로는 팀 단위에서 일관성을 유지하기 어렵고, 명시적인 합의와 기록이 함께 있어야 한다는 것을 배웠습니다. 이후 새로운 패턴이 생길 때마다 먼저 팀원들과 이름 기준을 확인하는 습관을 들이게 됐습니다.
코드 리뷰에서 이름 짓기 기준 차이가 드러나는 경험을 했습니다. 리뷰어가 변수 이름이 너무 축약됐다고 지적했는데, 작성한 입장에서는 컨텍스트가 명확해서 짧은 이름도 충분하다고 생각했습니다. 그 차이의 원인은 코드를 작성할 때와 나중에 읽을 때의 컨텍스트가 다르다는 점이었는데, 작성자는 당시 맥락을 알고 있지만 리뷰어는 그 맥락 없이 읽기 때문이었습니다. 이후에는 이름을 지을 때 해당 코드를 처음 보는 사람이 이 이름만으로 의미를 파악할 수 있는지를 기준으로 생각하게 됐습니다. 팀원들과 이름 짓기 기준을 공유하면서 각자가 가진 기준이 다양하다는 것도 알게 됐는데, 그 차이를 줄이는 것이 코드 리뷰 시간을 단축하는 데 도움이 됐습니다. 이름 짓기는 혼자 잘하는 것보다 팀 전체가 같은 기준을 공유하는 것이 더 중요하다는 것을 이 경험에서 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 넛지헬스케어 풀스택 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.