이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
소프트웨어 개발 생명주기에서 코드 리뷰와 소스 관리가 중요한 이유는 혼자 작성한 코드의 오류를 스스로 발견하기 어렵기 때문입니다. 다른 사람의 시각이 논리 오류나 엣지 케이스를 잡아내는 데 효과적입니다. 코드 리뷰는 품질 검증이자 팀 내 지식 공유의 채널이기도 합니다. 소스 관리에서는 브랜치 전략을 명확히 두는 것이 협업 충돌을 줄입니다. 기능별 브랜치를 분리하고, 리뷰 후 병합하는 흐름을 유지합니다. 팀 프로젝트에서 Git을 사용하면서 커밋 메시지를 의미 있게 작성하는 것이 나중에 변경 이력을 추적하는 데 얼마나 중요한지를 직접 경험했습니다. 잘못된 커밋 메시지로 인해 디버깅 시간이 늘어난 경험도 있습니다.
코드 리뷰와 소스 관리는 개인 습관이 아니라 팀 문화로 정착될 때 효과가 납니다.
코드 리뷰를 처음 받았을 때 내가 당연하다고 생각한 변수명이 리뷰어에게 전혀 다른 의미로 읽힌다는 걸 알았습니다. 팀 프로젝트에서 제가 작성한 코드에 '이 변수가 무엇을 나타내는지 이름만 보고 알 수 없다'는 리뷰가 달렸습니다. 작성할 때는 맥락을 알고 있어서 의미가 명확하게 느껴졌지만, 다른 사람에게는 그렇지 않았습니다. 그 이후로는 변수명과 함수명을 지을 때 '처음 보는 사람도 이름만 보고 뜻을 알 수 있는가'를 기준으로 검토하게 됐습니다.
리뷰 피드백 메모를 모아두면 반복되는 지적 패턴이 보였고, 다음 코드에 미리 반영할 수 있었습니다. 코드는 기계가 읽는 게 아니라 사람이 먼저 읽는다는 걸 그때 이해했습니다. 지금은 PR을 올리기 전에 명명이 자명한지 한 번 더 확인합니다.
소스 관리를 제대로 쓰기 전까지는 파일명에 날짜를 붙여 버전을 관리하다가 어느 버전이 올바른 것인지 헷갈린 경험이 있었습니다. 팀 프로젝트에서 최종_v3_수정_진짜최종.py 같은 파일이 5개가 되자 어느 것이 배포에 쓰인 버전인지 아무도 확신하지 못하는 상황이 됐습니다. Git을 도입한 뒤 커밋 이력으로 특정 시점의 코드를 바로 찾을 수 있게 됐고, 버그가 어느 커밋에서 들어왔는지 bisect로 찾는 데 20분이면 충분해졌습니다.
git log --oneline으로 변경 이력을 보면 수동 비교 없이 흐름이 파악됐습니다. 파일명 버전 관리와 Git의 차이를 경험하고 나면 돌아가기 어렵다는 걸 그때 배웠습니다. 지금은 작은 변경이라도 커밋 단위를 쪼개서 이력이 읽히게 남기는 습관을 유지합니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 삼성전자 공통직무·미지정 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.