이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
팀 프로젝트에서 팀원이 내 코드를 이해하는 데 오래 걸린다는 피드백을 받은 뒤 읽기 쉬운 코드 작성에 의식적으로 집중하게 됐습니다. 가장 먼저 바꾼 건 변수명과 함수명이 의도를 충분히 담도록 긴 이름을 허용하는 것이었습니다. 짧고 불분명한 이름이 줄고, 코드 리뷰 시 맥락 설명 없이도 흐름을 파악할 수 있게 됐습니다.
단일 책임 원칙을 적용해 함수 하나가 한 가지 일만 하도록 쪼개니, 테스트도 쉬워지고 수정 시 영향 범위도 예측하기 쉬워졌습니다. 코드는 컴퓨터가 아닌 사람이 읽는다는 관점으로 리뷰하게 됐고, 지금도 작성 후 다음 날 다시 읽어서 처음 보는 사람이 이해할 수 있는지를 점검하는 루틴을 유지하고 있습니다.
학부 프로젝트에서 변수명을 a, tmp, val처럼 짧게 쓰는 습관이 있었는데, 코드 리뷰에서 팀원이 "이 변수가 뭘 의미하는지 모르겠다"는 댓글을 여러 개 달았습니다. 혼자 쓸 때는 머릿속으로 기억하면 됐는데, 함께 읽을 때는 읽는 사람의 시간을 뺏는다는 걸 그때 처음 실감했습니다. 이후 변수와 함수 이름을 이 코드를 처음 보는 사람이 설명 없이 이해할 수 있는가를 기준으로 짓기 시작했습니다.
errorMessage, filteredUserList처럼 역할이 드러나는 이름으로 바꾸자 리뷰 댓글이 절반 이하로 줄었습니다. 이름 하나가 주석 다섯 줄을 대체할 수 있다는 걸 이 경험으로 배웠고, 이름을 짓는 데 쓰는 1분이 이후 읽는 사람의 10분을 아낀다는 생각을 갖게 됐습니다.
인턴 프로젝트에서 데이터 처리 함수 하나가 100줄을 넘어가면서, 어디서 어떤 처리가 일어나는지 따라가기 어렵다는 피드백이 왔습니다. 유효성 검사·변환·저장이 한 함수 안에 섞여 있었습니다. 처음에는 어디서 나눌지 기준이 없어서 막막했는데, 변경 이유가 다른 부분은 다른 함수로 분리한다는 원칙을 배웠습니다. 유효성 검사, 변환, 저장을 각각 15줄 이내의 별도 함수로 나눴더니 각 함수가 한 가지만 하는 구조가 됐습니다. 한 함수를 변경할 때 다른 함수를 건드릴 필요가 없어졌고, 테스트도 훨씬 짜기 쉬워졌습니다.
코드는 작동보다 읽힘이 먼저라는 걸 이 경험으로 배웠고, 이후 함수 길이가 30줄을 넘으면 쪼개야 한다는 기준을 스스로 갖게 됐습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 누아 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.