이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
함수나 변수 이름을 수정하게 된 가장 흔한 계기는 코드 리뷰에서 다른 사람이 다르게 이해하는 상황이었습니다. 같은 이름을 보고 두 가지 해석이 가능하다면 그 자체가 위험 신호였고, 리뷰 코멘트가 오히려 이름을 바꾸는 좋은 명분이 됐습니다.
이름을 바꾸기 전에 팀과 먼저 합의했습니다. 개인 판단으로 바꾸면 익숙한 이름이 사라져 팀원이 혼란을 겪을 수 있기 때문에, 슬랙이나 PR 코멘트에서 새 이름과 이유를 짧게 공유하고 반대 의견을 먼저 들었습니다.
실제 수정은 IDE의 전체 교체 기능을 활용했습니다. 수동으로 찾아 바꾸면 일부가 누락되는 실수가 생기기 때문에, 자동 교체 후 테스트를 돌려 동작이 바뀌지 않았는지 확인했습니다. 이름 변경이 버그를 만들지는 않지만 예상치 못한 곳에서 참조되는 경우도 있어 검증이 중요했습니다.
코드 리뷰를 받다가 "이 함수가 뭘 하는지 이름만 봐선 모르겠다"는 코멘트를 받은 경험이 있습니다. getData라는 이름이었는데, 무엇을 가져오는지가 이름에서 전혀 드러나지 않았습니다.
수정 전에 IDE의 참조 검색으로 해당 함수가 몇 곳에서 쓰이는지를 먼저 파악했습니다. 17곳에서 쓰이고 있어서 한 곳씩 직접 바꾸는 대신 IDE 리팩토링 기능으로 일괄 변경했습니다. `fetchUserOrderHistory`로 바꾸니 함수 이름만 봐도 역할이 바로 읽혔습니다.
이 경험으로 이름 수정은 범위를 먼저 파악하고 도구를 활용해 안전하게 해야 한다는 걸 배웠습니다. 좋은 이름 하나가 코드 리뷰 코멘트를 줄였습니다.
변수 이름을 바꾼 뒤 같은 파일에서 리뷰 질문이 눈에 띄게 줄어드는 걸 경험했습니다. 이전엔 flag, temp, data 같은 이름이 많아서 코드 리뷰마다 "이게 뭐냐"는 질문이 반복됐습니다.
팀과 함께 "이름이 설명이다"라는 원칙을 합의하고, 최소 2개의 단어 조합으로 의미를 담는 방식을 정했습니다. isLoading, hasPermission, selectedUserId처럼 상태와 의미가 드러나는 이름을 쓰기 시작했습니다. 리뷰에서 이름 관련 질문이 줄고 로직 관련 피드백이 늘었습니다.
이 경험으로 가독성 개선은 느낌이 아니라 리뷰 질문 수 변화로 확인할 수 있다는 걸 배웠습니다. 이름이 바뀌면 대화의 주제가 바뀝니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 넛지헬스케어 모바일 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.