이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
인턴 때 버그를 잡으려고 console.log를 파일 곳곳에 찍었다가 나중에 지우는 것을 깜빡해서 배포 코드에 로그가 올라간 적이 있습니다. 그 이후로 개발 환경에서만 로그가 출력되도록 환경 변수로 분기하는 방식을 써보았습니다. 팀 코드에 적용하진 못했지만 개인 프로젝트에서는 환경별로 로그 레벨을 다르게 설정하는 유틸 함수를 직접 만들었습니다. 처음에는 너무 복잡하게 만들었다가 실제로 안 쓰게 되는 경험을 하였고, 단순한 버전으로 다시 작성하였습니다.
디버깅 도구는 실제로 매일 쓸 수 있을 만큼 단순해야 한다는 것을 배웠습니다. 팀에서 사용하는 방식에 맞춰 빠르게 흡수하면서 현재 환경에서 개선할 수 있는 작은 부분부터 시작하고 싶습니다.
졸업 프로젝트에서 리렌더링이 너무 많이 일어나는 문제가 있었는데, React DevTools Profiler를 처음 써봤어요. 처음엔 어떤 숫자를 봐야 하는지 몰라서 그냥 화면만 구경했어요. 유튜브 튜토리얼을 두 시간 보고 나서야 불필요한 리렌더링이 발생하는 컴포넌트를 특정하는 방법을 알게 됐어요. 문제는 부모 컴포넌트 상태 변경이 무관한 자식까지 전파되는 거였는데, React.memo와 useMemo를 써서 성능을 개선했어요. 근데 남발했다가 메모이제이션 비용이 더 커지는 케이스도 경험했어요. 그 실패 덕분에 실제로 문제가 있을 때만 최적화 도구를 쓴다는 원칙을 가지게 됐어요.
사이드 프로젝트를 배포했는데 사용자가 오류를 만나도 저한테 안 알려지는 게 불안했어요. 직접 에러 핸들링 코드를 만들어서 에러 발생 시 슬랙으로 메시지가 가도록 구현했는데, 처음에 API 키를 클라이언트 코드에 하드코딩하는 실수를 했어요. 배포 후 30분 만에 키가 노출됐고, 바로 키를 재발급하고 환경 변수로 옮기는 작업을 긴급으로 했어요. 이 경험이 아니었다면 보안 기초를 소홀히 했을 것 같아요. 현재는 에러 메시지에 스택 트레이스와 발생 시각을 함께 포함시켜서 어디서 왜 났는지 바로 파악할 수 있게 했어요.
디버깅 환경 개선은 결국 문제를 빨리 찾고 빨리 고치는 루프를 짧게 만드는 것이라고 생각해요.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 SK inc.(AX) SW·IT 일반 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.