우문현답
愚 問 賢 答
회사별 면접직군별진행 방식
    홈›회사별›PTKOREA›ML 엔지니어›질문 상세
    問
    PPTKOREAML 엔지니어인성·가치관2026년 출제

    자신만의 코드 설계 철학이나 좋은 코드에 대한 기준이 무엇인지 말씀해 주세요.

    답변 미리보기

    제가 가장 가까이 두는 기준은 "6개월 뒤의 내가 읽었을 때 이해가 가는가" 입니다. 변수명과 함수 분리가 잘 됐다면 주석이 없어도 의도가 보이는데, 이 기준이…

    예상 답변 시간
    60~90초
    예상 꼬리질문
    3회
    난이도
    난이도 중상
    출제 빈도
    높음
    INTERVIEWER'S INTENT · 면접관의 의도

    이 질문, 네 갈래로 뜯어봅니다.

    면접관이 이 한 문장으로 확인하려는 것들. 각 갈래를 알면 답의 뼈대가 잡혀요.

    問
    01
    본인의 기준이 분명한가?
    가독성·테스트 가능성·확장성 중 어떤 축을 본인이 가장 가까이 두는지 흔적이 답에 있어야 합니다. '좋은 코드를 짠다' 수준의 답은 면접관이 '어떤 게 좋은 거예요?'를 추가로 묻는 자리가 자주 보입니다.
    骨
    02
    기준이 어디서 왔는가?
    책·코드 리뷰·실패 경험 중 본인의 철학이 어디서 빚어졌는지 흔적이 있어야 합니다. 추상적 표현만 늘어놓는 답은 깊이가 부족해 보이는 자리가 흔합니다.
    語
    03
    현실의 타협을 다루는가?
    이상과 마감·팀 합의 사이에서 어떻게 타협했는지 흔적이 있어야 합니다. 이상만 말하는 답은 실무 감도가 약하다는 결로 통합니다.
    本
    04
    본인 코드를 점검하는 흔적이 있는가?
    리뷰·리팩토링·자기 회고를 본인이 어떻게 다루는지 짚는 자리입니다. '잘 짠다' 수준의 답은 자기 객관화가 약해 보이는 결로 보입니다.
    말로 해봐야 는다
    읽는 것과 말하는 건 다릅니다.
    이 질문, 소리 내어 답해 볼까요?
    PTKOREA 면접관 페르소나가 이 질문을 던지고, 당신의 답에 꼬리질문으로 되물어요.
    음성으로 답해보기
    가독성을 먼저 두고 리뷰와 실패에서 기준을 다져온 결약 71초마감·완성 우선순위 설정 후 기술부채로 관리하며 개선 순서화 결시간 경과 재검토와 DRY 리팩토링으로 품질 개선 결
    예시 답변 1
    약 71초

    가독성을 먼저 두고 리뷰와 실패에서 기준을 다져온 결

    제가 가장 가까이 두는 기준은 "6개월 뒤의 내가 읽었을 때 이해가 가는가" 입니다. 변수명과 함수 분리가 잘 됐다면 주석이 없어도 의도가 보이는데, 이 기준이 처음 코드 리뷰에서 "이 코드가 무슨 일을 하는지 모르겠다"는 피드백을 받고 생겼습니다. 테스트 가능성도 중요하게 생각하는데, 외부 의존성이 깊게 결합된 코드는 나중에 바꾸기 어렵다는 걸 실제 기능 수정에서 겪었습니다. 그래서 의존성 주입 방식을 쓰고, 단위 테스트를 먼저 짜는 습관이 생겼습니다. 마감이 촉박할 때는 임시 하드코딩을 두고 TODO 주석으로 명시한 뒤 정리하는 방식으로 타협하는데, 이 부채가 쌓이지 않도록 스프린트 말에 정리하는 규칙을 스스로에게 두고 있습니다.

    이 결의 특징
    '6개월 뒤의 내가 읽었을 때 이해가 가는가'라는 가독성 기준이 코드 리뷰에서 '무슨 일을 하는지 모르겠다'는 피드백을 받은 뒤 생겼다는 흔적이 있습니다. 의존성 주입과 단위 테스트 우선 작성 습관이 실제 기능 수정 어려움 경험에서 도출되고, 마감 시 임시 하드코딩을 TODO 주석으로 명시해 스프린트 말에 정리하는 타협 구조가 살아 있는 결이 자주 보입니다.
    이 결이 통하는 자리
    코드 철학이 추상 원칙이 아닌 세 개의 구체 경험(리뷰 피드백, 기능 수정 어려움, 마감 타협)에서 나왔을 때 통합니다. '이상을 고집하는 것이 아니라 언제 타협하고 언제 지킬지를 구분한다'는 원칙이 실제 운영 방식으로 닫힌 자리에서 면접관의 꼬리질문이 줄어드는 결이 보입니다.
    예시 답변 2

    마감·완성 우선순위 설정 후 기술부채로 관리하며 개선 순서화 결

    이상적인 코드 설계와 현실 마감 사이에서 타협 지점을 찾아야 하는 자리가 있었습니다. 팀 프로젝트에서 레이어 구조를 더 분리하고 싶었는데, 발표 마감이 3일 남은 시점이었습니다. 완전한 구조를 고집하면 핵심 기능조차 완성하지 못할 수 있다는 걸 인식했고, 팀원들에게도 판단 이유를 먼저 공유했습니다. 저는 일단 동작하는 버전을 먼저 완성한 뒤, 구조를 개선하는 순서로 접근하기로 했습니다. 타협한 부분은 기술 부채 메모에 구체적으로 남겨두고, 발표 후 리팩토링 목록으로 정리해 실제로 개선을 진행했습니다. 이 경험이 코드 설계 철학과 현실 사이에서 어느 쪽도 무너지지 않는 결을 찾는 방식이 됐습니다. 좋은 설계를 포기한 게 아니라, 마감 후 개선이라는 순서를 선택한 것이었습니다. 코드 설계 결은 이상을 고집하는 것이 아니라 언제 타협하고 언제 지킬지를 구분하는 자리에서 단단해집니다.

    이 결의 특징
    마감 3일 전 레이어 구조 분리 욕구와 핵심 기능 미완성 위험 사이에서 '동작하는 버전 먼저 + 리팩토링 목록 남기기'라는 순서를 선택하고 발표 후 실제 개선을 진행한 흔적이 있습니다. 판단 이유를 팀원에게 먼저 공유했다는 협업 감각이 함께 살아 있는 결이 자주 보입니다.
    이 결이 통하는 자리
    '설계를 포기한 게 아니라 마감 후 개선이라는 순서를 선택한 것'이라는 인식이 기술 부채 메모와 리팩토링 목록이라는 구체 도구와 연결됐을 때 통합니다. 팀원에게 판단 이유를 공유했다는 흔적이 살아 있는 자리에서 실무 타협 감각이 보이는 결이 자주 보입니다.
    예시 답변 3

    시간 경과 재검토와 DRY 리팩토링으로 품질 개선 결

    코드를 제출하고 나서도 시간을 두고 다시 읽어보는 결을 만들어두고 있습니다. 제출 직후엔 잘 짰다고 생각한 부분도, 며칠 뒤에 다시 보면 함수가 너무 길어졌거나 변수명이 모호한 자리를 발견하게 됩니다. 한 팀 프로젝트에서 제출 후 일주일이 지나 코드를 다시 열었더니, 같은 로직이 세 군데에 복사된 걸 발견했습니다. 그때 별도 함수로 분리하고 DRY 원칙을 적용했더니, 이후 기능 추가할 때 수정해야 하는 파일이 하나로 줄었습니다. 이 경험이 있고 나서는 기능 구현이 끝난 뒤에도 스스로 리팩토링 목록을 만드는 습관이 생겼습니다. 완성 직후에 보이지 않던 문제가 시간이 지나면 보이는 이유는, 코드를 처음 본 눈으로 다시 읽게 되기 때문입니다.

    자기 검토는 타인에게 받는 코드 리뷰와는 다른 시야를 줍니다. 코드 점검 결은 완성된 순간이 아니라, 시간이 지난 후 낯선 눈으로 다시 읽는 자리에서 생깁니다.

    이 결의 특징
    제출 후 일주일 뒤 같은 로직이 세 군데 복사된 것을 발견하고 DRY 원칙을 적용해 이후 기능 추가 시 수정 파일이 하나로 줄어든 흔적이 있습니다. '제출 직후엔 잘 짰다고 생각한 부분도 며칠 뒤 다시 보면 문제가 보인다'는 시간 경과 재검토의 가치를 리팩토링 목록 습관으로 전환한 결이 자주 보입니다.
    이 결이 통하는 자리
    '시간이 지난 후 낯선 눈으로 다시 읽는다'는 자기 검토 방식이 타인 코드 리뷰와 다른 시야를 준다는 인식과 연결됐을 때 통합니다. 세 군데 복사 발견→DRY 적용→수정 파일 감소라는 전후 흐름이 살아 있는 자리에서 면접관의 꼬리질문이 줄어드는 결이 보입니다.
    !
    위 답변은 여러 풀이 중 한 가지 예시입니다. 정답이 아니며, 외워서 그대로 말하면 면접관이 다음 질문을 그 자리에서 시작하는 경우가 많습니다. 본인의 프로젝트·기준·숫자로 다시 짜는 자리로만 쓰세요.
    ✕자주 빠지는 자리

    같은 실수가 반복돼요. 이것만 피해도 절반은 갑니다.

    • ✕떨어뜨린 옵션이 1개라도 있는가? "이게 답이었어요"만으로는 의사결정이 아니라 그냥 선택입니다.
    • ✕선택 기준이 그 프로젝트에 한정되는가? "성능이 좋아서"는 일반론, "우리 트래픽이 X 패턴이라서"가 본인의 답입니다.
    • ✕결과 숫자 1개를 정확히 말할 수 있는가? P95·QPS·적중률 — 무엇이든 1개. 숫자가 없으면 직감으로 한 일처럼 들리기 쉽습니다.
    • ✕지금 다시 한다면 어떻게 할지 답할 수 있는가? "잘했다"보다 "이건 다르게 했을 것 같다"가 더 깊은 인상을 남깁니다.
    ▶이어질 꼬리질문

    진짜 면접은 두 번째 질문부터예요. 이 답 뒤에 따라올 법한 것들.

    壹본인의 코드가 나쁘다고 느낀 적이 있나요?
    貳팀의 코드 스타일과 본인 철학이 다를 때 어떻게 다루시나요?
    參코드 리뷰에서 가장 자주 짚는 부분은 무엇인가요?
    이제, 직접 답해볼 차례예요.
    눈으로 읽은 답은 면접장에서 나오지 않아요. PTKOREA 면접관과 이 질문으로 한 번 대화해 보세요.
    이 질문으로 모의면접 해보기
    또는, 다음 질문으로

    같은 흐름에서 자주 이어지는 질문들이에요.

    토스 · 백엔드
    본인이 생각하는 좋은 코드 또는 설계 철학에 대해 말씀해 주실 수 있나요?
    이 질문 보기
    트립비토즈 · 백엔드
    작성한 코드의 품질을 높이기 위해 어떤 방법들을 사용하고 있는지 설명해 주세요.
    이 질문 보기
    크몽 · 영상·프로덕션
    자신의 기획 의도를 논리적으로 설명한 경험이 있다면, 그 과정과 결과를 말씀해 주세요.
    이 질문 보기
    유진그룹 · 재무·회계 일반
    자신만의 학습 방식이나 일하는 방식을 구체적으로 설명해보세요.
    이 질문 보기
    안내 · 이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 실제 출제·회사 공식 입장과는 무관하며, 정정 요청 시 24시간 내 반영합니다. 자세히
    개인정보처리방침이용약관문의
    © 2026 우문현답. All rights reserved.
    이 페이지 목차
    01면접관의 의도02답변의 결03실수·꼬리질문04관련 질문
    말로 해봐야 는다
    이 질문, PTKOREA 면접관과
    음성으로 답해볼까요?
    모의면접 해보기
    첫 회 무료 · 종료 즉시 음성 폐기