이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
클린 코드 작성에서 가장 주의하는 것은 함수와 변수 이름이 의도를 충분히 드러내는지입니다. 코드 리뷰에서 로직보다 이름 때문에 의도를 잘못 파악하는 경우가 많았는데, 좋은 이름 하나가 주석 여러 줄을 대체한다는 것을 경험했습니다. 함수는 한 가지 일만 하는 것을 원칙으로 정했는데, 함수가 길어질 때마다 분리할 지점이 있는지를 먼저 확인했습니다.
매직 넘버를 상수로 바꾸는 것도 습관으로 만들었는데, 숫자 7이 코드 안에 있으면 일주일인지 최대 재시도 횟수인지 알 수 없습니다. 중복 제거도 중요하게 생각하지만, 두 곳 이상에서 실제로 쓰일 때 합치는 방식을 선호합니다. 한계는 다른 사람이 읽기 좋은 코드와 내가 쓰기 편한 코드가 항상 일치하지 않는다는 점인데, 코드 리뷰가 이 차이를 줄여주는 역할을 한다고 생각합니다. 클린 코드는 다음 사람이 질문 없이 수정할 수 있는 상태를 만드는 것이 결임을 배웠습니다.
클린 코드를 의식하게 된 계기는 PR 리뷰에서 "이 함수가 무슨 일을 하는지 이름만 봐서는 모르겠다"는 피드백이었습니다. 기능은 맞게 구현됐는데 코드를 읽는 사람이 이해하는 데 시간이 걸리는 구조였습니다.
이후엔 함수 이름을 지을 때 "이 함수를 처음 보는 사람이 이름만 보고 의도를 알 수 있는가"를 기준으로 삼았습니다. isValidEmail보다 isEmailFormatValid가 더 명확했고, 짧은 이름이 항상 좋은 이름이 아니라는 걸 배웠습니다.
이 경험으로 클린 코드의 가독성은 주석이 아니라 이름에서 결정된다는 걸 배웠습니다. 잘 지은 이름은 설명이 필요 없는 코드를 만듭니다.
클린 코드를 쓰려다 보면 "이 코드가 클린한가"의 기준이 사람마다 다르다는 걸 경험했습니다. 제가 읽기 쉽다고 생각한 코드가 팀원에게는 너무 세분화되어 오히려 흐름을 따라가기 어렵다는 피드백이 오기도 했습니다.
이 경험으로 클린 코드는 절대 기준이 있는 게 아니라 팀이 함께 합의하는 기준이라는 걸 알게 됐습니다. 린팅 규칙이나 코드 스타일 가이드는 그 합의를 문서화한 것이고, 팀에 없다면 합의 자체를 만드는 것이 먼저였습니다.
이 경험으로 클린 코드는 혼자 잘하는 것이 아니라 팀이 같은 기준으로 읽는 코드를 만드는 것이라고 생각합니다. 기준이 달리면 리뷰가 소모적인 논쟁이 됩니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 삼성전자 풀스택 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.