인성 면접 질문 리스트

⭐ 이 면접의 핵심 (반드시 기억)

서비스 개발 본부장(2차 면접에 들어오는 인물)이 직무 인터뷰 Q10 "본부 내 신규채용을 할 때 자주 하는 질문은?"에서 밝힌 채용 절차·평가 기준 원문입니다. 이 문서 전체가 아래 두 축(의사소통·인성)을 근거로 구성되었습니다.

채용 절차 (본부장 원문)

• "본부 신규 채용 절차는 면접이 두 번 있어요. 1차는 실무진 면접, 2차에서는 임원진 면접인데 저는 보통 2차 면접으로 들어가고요."
• "1차에선 실무진들이 함께 일을 할 수 있는 사람인가 아닌가 판단하고, 피드백이 좋을 경우 2차에서는 거의 채용을 하긴 해요."

→ 나는 이미 1차를 통과했으므로, 2차는 "기술 재검증"이 아니라 아래 두 가지를 확인하는 자리입니다. 위축될 필요 없이, 대화가 되는 사람이라는 것만 보여주면 됩니다.

2차에서 보는 두 가지 (우선순위 순)

1. 의사소통 (첫 번째) — "임원진 면접을 볼 때 첫번째로 주요 깊게 보려고 하는 것은 의사소통 부분을 보는 것 같아요. 저는 대화를 통해서 문제점을 찾아가고 해결을 해나가려고 하는데 대화가 안 되는 분이라고 판단되면 실무진 면접에서 좋은 평가를 받았다고 하더라도, 과감하게 (탈락 의견을) 실무진들에게 이야기해요."
   → 1차 기술 평가가 좋아도 "대화가 안 되면" 결과가 뒤집힐 수 있는 유일한 요소. 답변의 화려함보다 "질문을 정확히 이해하고, 명확하게 대화가 통하는가"가 최우선입니다.
2. 인성 (두 번째) — "두 번째는 인성 질문을 많이 하는 것 같아요."
   → 이 문서의 1~2순위 질문 대부분이 인성 질문인 이유입니다.

그래서 답변할 때 (의사소통 관점)

• "논리적으로 대화가 되는 사람"이라는 인상이 최우선입니다 — 화려한 답보다 명확한 전달력.
• 질문의 의도를 못 알아들었으면 되묻는 것이 "대화가 안 되는 것"보다 낫습니다.

본부장이 원하는 개발자상 (같은 인터뷰 Q11 "직무 희망자에게 한마디" 원문)

의사소통·인성과 함께, 본부장은 이상적인 개발자상을 구체적으로 밝혔습니다. 이 인재상에 부합하는 답변을 하면 강한 인상을 줄 수 있습니다.

• "개발자도 분류가 되는 부분이 있거든요. . 보통 신입사원들을 보면 시키는 것들 위주로만 많이 해요. … 그것에만 익숙해지면 더 이상의 성장은 없거든요."
• "제가 1년 차 때 혼자서 프로젝트를 처음부터 끝까지 해보다 보니까 그 순간에 오는 깨우침 같은 것들이 있더라고요."
• "연차가 적을 때는 실패해도 좋으니까, 욕먹어도 좋으니까 이것저것 시도해 보는 것이 좋아요. … 배우는 기간일 때 혼자서 이것저것 많이 경험하며, 실패도 경험을 해보고 다양한 경험을 얻는 개발자가 되면 좋겠다."
• "항상 모든 순간이 어렵고, 두렵거든요. 그 두려움을 잘 극복할 수 있으면 좋을 것 같아요."

→ 본부장이 원하는 사람 = 시키는 것만 하는 Coder가 아니라, 주도적으로 다양하게 시도하고 실패를 두려워하지 않는 Developer.

이 개발자상을 답변에 활용하는 법

• 공백기(Q8)를 강점으로 전환: 공백기를 "혼자서 이것저것 시도하고 실패도 겪으며 다양하게 경험한 기간"으로 프레이밍하면, 약점이 오히려 본부장의 인재상과 정확히 맞아떨어집니다. "시키는 것만 익숙해지면 성장이 없다"는 본부장의 말과, 스스로 프로젝트를 파고든 공백기 경험을 연결하세요.
• 주도성의 근거 제시: UNIBUSK 렌더링 문제를 스스로 측정해 파고든 것, Dessert 모노레포 전환을 먼저 제안한 것 등이 "시키는 것만 하는 Coder가 아니다"라는 직접 증거입니다 (project-experience-notes.md).
• 정면으로 겨냥할 질문: Q14(지시 vs 스스로 찾아서), Q15(잇뉴에 맞는 이유)에서 이 개발자상을 직접 조준해 답하세요.
• 실패·시행착오는 숨기지 마세요 — 본부장이 직접 권장한 태도입니다.

🔴 1순위 — 반드시 준비

잇뉴 인터뷰 최빈출 + 첫 5분 안에 거의 확실히 나오는 질문입니다.

Q1. 1분 자기소개

"무엇을 했는지"보다 "왜 그렇게 판단했는지"가 잘 드러나는지 점검. 상세한 실무진(1차)용 버전은 cover-letter.md 참고.

2차 임원용 초안 (기술 용어를 덜어내고 사용자·팀 영향과 주도성을 강조한 버전)

안녕하세요. 저는 문제를 추측으로 넘기지 않고, 원인을 직접 측정해서 확인한 뒤 개선하는 신입 개발자 박명재입니다.

UNIBUSK 프로젝트의 고도화 단계에서 페이지별로 렌더링 성능을 측정하던 중, 공연 등록 폼에서 글자 하나를 입력할 때마다 관련 없는 화면 전체가 불필요하게 다시 그려지는 문제를 발견했습니다. 측정 도구로 정확히 어느 부분에서 문제가 발생하는지 확인했고, 원인을 짚어 고쳤습니다. 그 결과 불필요한 리렌더링 없이 입력값만 반영되게 됐습니다.

다른 프로젝트에서는 두 개의 서비스를 함께 운영하다 보니 팀원마다 코드를 다르게 작성하는 문제가 있었습니다. 저는 공통으로 쓰는 UI를 하나로 묶고, 파일을 어디에 둘지에 대한 기준을 문서로 만들어 팀이 같은 방식으로 코드를 읽고 고칠 수 있게 했습니다.

두 프로젝트를 진행하면서 스스로 문제를 발견해 원인을 확인하기도 하고, 팀원들과 논의해 기준을 만들기도 했습니다. 그 과정에서, 문제를 해결하는 것만큼 그 해결을 팀이 함께 유지할 수 있는 형태로 남기는 것도 중요하다는 걸 배웠습니다. 잇뉴에서도 이런 방식으로, 사용자에게 도움이 되는 부분을 확인하고 팀과 함께 개선해나가는 개발자가 되고 싶습니다.

Q2. 잇뉴에 지원한 이유 / 어떤 점에 매력을 느꼈나요?

2차 임원용 초안 (오래된 회사 이해를 README.md 기준으로 갱신하고, 나열식 문장을 줄인 버전)

잇뉴에 지원한 이유는, 복잡한 기술을 실제 사람들이 쓰는 서비스 문제로 풀어내는 방향이 인상적이었기 때문입니다.

제가 이해한 바로는 제주 당일배송 서비스 ERLN은 물류 운영을 다루고, MemoryMint는 증서를 만들고 발급·관리하는 서비스이며, MinTrigger는 그 블록체인 기술을 다른 서비스에 API 형태로 제공하는 역할을 합니다.

2차 면접을 준비하면서 포트폴리오와 블로그를 더 찾아봤는데, 두 가지가 인상 깊었습니다. 하나는 포트폴리오였는데, 자체 기술을 만들어보는 데 그치지 않고 공공기관이나 기업과의 프로젝트를 통해 실제 운영 문제를 해결하는 데까지 이어간다는 점이었습니다. 다른 하나는 블로그의 직무 인터뷰였는데, 직급 없이 대화하는 분위기와 구성원들이 겪은 일을 솔직하게 이야기하는 모습을 보면서 이 팀과 함께 만들어가고 싶다는 마음이 들었습니다.

저는 UNIBUSK와 Real World에서 인증 처리, 서버 데이터와 화면 상태를 연결하는 일을 했고, Dessert Front Dashboard에서는 기능 구현보다 모노레포 구조 설계와 온보딩 자료 작성에 집중했습니다. 공용 UI 패키지를 분리하고 FSD 컨벤션을 문서화해서, 새로 합류한 팀원이 코드를 빠르게 이해하고 같은 기준으로 작업할 수 있게 했습니다.

잇뉴에서도 기술이 실제로 사용자나 운영자에게 도움이 되는 형태로 전달되는지 확인하고, 이 팀과 함께 만들어가고 싶습니다.

꼬리 질문 — 블록체인이 무엇인가요?

블록체인은 여러 참여자가 같은 기록을 공유하고 검증하는 분산형 기록 구조라고 이해하고 있습니다. 기록은 이전 기록과 암호학적으로 연결돼 있어서, 이미 쌓인 기록을 임의로 바꾸면 변경 사실을 검증할 수 있습니다.

그래서 여러 기관이나 사용자가 같은 기록을 신뢰해야 하는 인증서 발급, 이력 추적, 위변조 검증에 활용할 수 있습니다. 잇뉴의 MemoryMint나 MinTrigger도 이런 신뢰와 검증의 문제를 해결하는 데 블록체인을 활용하는 것으로 이해하고 있습니다.

다만 블록체인에 기록했다고 해서 처음 입력한 정보가 항상 사실이라는 뜻은 아니고, 비용·성능·개인정보 측면의 제약도 있습니다. 그래서 중앙 데이터베이스로 충분한 문제인지, 여러 주체가 기록을 함께 검증해야 하는 문제인지를 먼저 판단해야 한다고 생각합니다.

Q3. 개발자가 되기로 한 이유는 무엇인가요?

2차 임원용 초안

개발을 하게 된 계기는 코드를 작성한 결과가 화면에 바로 반영되는 경험이 재미있었기 때문입니다. 작은 변경도 사용자가 보는 화면과 동작을 바꿀 수 있다는 점에서, 제가 만든 결과를 즉각 확인하고 개선할 수 있다는 매력을 느꼈습니다.

프로젝트를 진행하면서는 단순히 화면 하나를 만드는 데서 더 나아가, 서비스를 직접 만들고 실제 사용자의 흐름을 경험해보고 싶다는 목표가 생겼습니다. 사용자가 서비스를 어떻게 이용하는지, 어디에서 불편을 느끼는지, 사용량이 늘어날 때 어떤 문제가 생기는지를 보고 개선하는 개발자가 되고 싶습니다.

아직 많은 사용자가 사용하는 서비스를 운영해본 경험은 없지만, 그래서 더욱 실제 사용자와 트래픽이 있는 환경에서 기능을 만들고 개선하는 경험을 쌓고 싶습니다. 프론트엔드는 제가 만든 변화가 사용자 경험으로 가장 빠르게 드러나는 영역이라 생각해 계속 성장하고 싶은 분야입니다.

Q4. 최근(이전) 프로젝트에서 어떤 업무를 담당하셨나요?

project-experience-notes.md — UNIBUSK/Dessert/Real World 담당 범위. 팀 규모·역할은 이력서·source/portfolio.md 원문 기준으로 정확히 확인.

2차 임원용 초안 (잇뉴 직무 인터뷰의 "개념 먼저 → 자연스러운 예시" 구조를 참고하되, 격식체로 정리한 버전)

프로젝트마다 제가 맡은 역할은 조금씩 달랐습니다. 화면을 직접 만드는 역할을 맡기도 했고, 팀이 함께 일할 수 있는 구조를 만드는 역할을 맡기도 했습니다.

UNIBUSK는 버스킹 공연 장소를 찾고 홍보하는 서비스로, 8명 팀에서 프론트엔드 두 명 중 한 명으로 참여해 공연 등록·상세 화면과 카카오 로그인, 프로필 영역을 개발했습니다.

Dessert Front Dashboard는 역할이 달랐습니다. 12명 규모의 팀에서 저는 화면 개발보다 모노레포 구조를 설계하고 팀이 지킬 컨벤션을 문서화하는 역할을 주로 맡았고, 그 위에서 관리자 대시보드와 공용 패키지 개발도 함께 진행했습니다.

Real World는 블로그 플랫폼으로, 프론트엔드부터 백엔드까지 혼자 설계하고 개발한 프로젝트입니다.

cover-letter.md/이전 초안과 달라진 점:

• 프로젝트를 나열하고 "정리하면"으로 봉합하는 보고서식 구조 제거 — 잇뉴 직무 인터뷰(김은정 Q4, 이재현 Q2)는 역할을 개념으로 먼저 정의하고 경험을 자연스럽게 예시로 흘려보내는 구조였음
• 다만 블로그 인터뷰 특유의 캐주얼한 구어체("~것 같아요", "~했어요")는 가져오지 않음 — 편한 분위기에서 나온 발언처럼 들려 면접에서는 확신 없어 보일 위험. 구조는 가져오되 어투는 면접용 격식체 유지
• 팀 규모(8명/12명/1인)를 먼저 말해 전체를 혼자 한 것처럼 들리는 과장을 피함

말할 때: 세부 문제 해결 과정(렌더링 최적화, Hydration Pattern 등)은 Q5·Q13 같은 꼬리질문에서 풀 것.

Q5. 가장 기억에 남거나 인상 깊었던 프로젝트는?

project-experience-notes.md 참고. Q1(자기소개)에서 이미 UNIBUSK 얘기를 썼으므로 Q5는 Dessert Front Dashboard로 잡되, 실제로 있었던 팀원과의 논의(초기 아키텍처 설계 중 FSD widgets 레이어를 두고 의견이 갈렸던 것)를 중심으로 구성. 처음엔 본인도 공식 문서 기준이 맞다고 생각했지만, 팀원과의 대화 후 판단이 실제로 바뀐 경험이라 "듣고 그냥 수긍"이 아니라 "대화를 통해 문제를 함께 풀어간" 사례로 다룸.

2차 임원용 초안

가장 기억에 남는 프로젝트는 Dessert Front Dashboard에서 팀 컨벤션 문서를 만들어간 과정입니다.

초기 폴더 아키텍처를 설계할 시점에, 저는 FSD 공식 문서를 기준으로 widgets 레이어까지 포함한 구조가 맞다고 생각했습니다. 그런데 팀원이, 지금 프로젝트 규모에서는 widgets 레이어에 실제로 들어갈 내용이 많지 않을 텐데 지금부터 나누면 폴더 구조만 복잡해지고 관리 부담만 커질 수 있다는 의견을 제시했습니다.

이 의견에 대해서 다른 팀원들의 의견을 들어보고, 저 역시 지금 규모와 관리 비용을 고려했을 때 팀원의 의견이 맞다고 판단했습니다. 그래서 widgets 레이어를 제거한 구조로 조정했고, 변경된 기준을 온보딩 자료·컨벤션 문서에 담아 팀 전체가 같은 구조로 코드를 작성할 수 있게 했습니다.

이 경험을 통해, 팀이 함께 유지할 수 있는 기준을 만들려면 제가 알고 있는 원칙만큼 팀원들의 실제 상황 판단도 함께 반영해야 한다는 걸 배웠습니다.

이 프로젝트를 고른 이유:

• Q1과 다른 프로젝트라 "레퍼토리가 하나"라는 인상을 피할 수 있음
• widgets 레이어 결정 하나로 범위를 좁히지 않고, "컨벤션 문서를 만드는 과정에서 팀원 의견을 반영한 결과"라는 더 큰 흐름으로 프레이밍해, 일회성 사건이 아니라 일관된 협업 태도로 보이게 함
• "제 생각이 항상 맞는 건 아니다"라는 자기 의심형 문장 대신, "팀 전체가 같은 기준으로 코드를 작성하게 된 결과"를 앞세워 더 자신감 있는 톤으로 전달
• "공식 문서가 틀렸다"가 아니라 "기준은 맞지만 상황에 맞게 적용하는 방식이 다르다"는 구조라, 원칙을 존중하면서도 유연하게 판단한다는 인상을 줄 수 있음
• 팀원 의견을 듣고 재고하는 과정이 들어 있어, 본부장이 말한 "대화를 통해 문제를 찾고 해결해나가는" 의사소통 정의에 부합함

이전 초안과 달라진 점:

• 이전 버전은 "팀원이 의견을 냈고 저는 동의했다"는 즉시 수긍형 구조라 단조롭다는 피드백을 반영해, 본인의 초기 입장(공식 문서 기준)과 그 입장이 바뀐 계기(팀 규모 고려)를 모두 넣어 실제 대화·재고 과정이 드러나게 했음
• 그 다음 "제가 확신했던 방식도 대화로 더 나은 방향으로 바뀌었다"는 표현은 공식 문서가 틀렸다는 뉘앙스를 풍겨서, "공식 문서는 여전히 맞는 기준이지만 프로젝트 규모에 맞게 유연하게 적용했다"는 쪽으로 수정 — 정답을 아는 것과 상황에 맞게 적용하는 것을 별개 역량으로 구분
• 도입부·결론이 "초기 아키텍처 설계"로 좁아져 있던 것을 수정: 실제 기억은 "아키텍처 설계와 컨벤션 문서를 만드는 과정 전체에서, 내 의견만 고집하지 않고 팀원 의견을 수용한 것"이므로, widgets 레이어는 그 과정의 대표 예시("예를 들어")로 위치를 옮기고 도입부·결론은 "과정 전체"로 넓힘
• "제가 처음 생각한 방식이 항상 맞는 건 아니어서"라는 자기 의심형 도입부를 수정: 겸손을 강조할 필요 없이, "팀원과 논의해 팀 전체가 같은 기준으로 코드를 작성할 수 있게 만든 결과"를 앞세우는 쪽이 더 자연스럽다는 피드백을 반영. widgets 레이어 논의는 그 결과를 만들어낸 과정의 한 예시로 유지
• 모노레포·공유 패키지 관련 세부 내용은 이 답변에서 제외 — Q11(협업 방식)나 Q15(잇뉴에 맞는 이유) 같은 꼬리질문에서 다룰 것

말할 때: "공식 문서가 틀렸다"는 인상을 주지 않도록 주의. 핵심은 "컨벤션 문서를 만드는 과정에서, 내가 세운 기준이라도 팀원 의견을 듣고 반영해서 팀 전체가 같은 기준을 갖게 했다"는 결과 중심 톤 유지. 꼬리질문으로 "왜 그 의견이 맞다고 판단했나요?"가 들어오면 "프로젝트 초기라 레이어를 세분화할 만큼 화면·기능이 많지 않았고, 오히려 관리 부담만 커질 수 있어 동의했다" 정도로 답할 것.

Q6. 본인의 강점은 무엇인가요?

인성면접 필수 질문 + 본부장이 "인성 질문 많이 한다"고 언급

2차 임원용 초안

저의 강점은 문제가 생겼을 때 바로 해결책부터 적용하기보다, 먼저 가설을 세우고 검증하면서 원인을 좁혀가는 점입니다.

UNIBUSK에서 카카오 로그인은 배포 환경에서는 정상 동작했지만, 로컬 환경에서는 쿠키가 저장되지 않는 문제가 있었습니다. 저는 두 환경의 차이가 도메인과 요청 흐름에 있을 것이라고 가설을 세웠습니다. 이후 로그인 전후 요청과 쿠키 저장 위치를 비교해, 프론트엔드와 백엔드의 도메인이 달라 백엔드가 내려준 쿠키가 로컬 환경의 클라이언트에 저장되지 않는다는 점을 검증했습니다.

확인한 내용을 백엔드 팀원에게 공유하고, 쿠키를 바로 전달하던 기존 흐름 대신 임시 인증 코드를 전달하도록 설계를 함께 수정했습니다. 이후 프론트엔드에서 같은 출처의 요청으로 인증 코드를 교환해, 로컬과 배포 환경 모두에서 정상적으로 로그인되는 것을 확인했습니다.

저는 혼자 빠르게 답을 정하기보다, 검증한 사실을 바탕으로 관련된 사람과 문제를 다시 정의하고 해결 방향을 만드는 방식을 중요하게 생각합니다.

Q7. 본인의 약점은 무엇인가요?

2차 임원용 초안

제 약점은 새로운 문제를 만나면 해결에 필요한 범위보다 더 깊게 파고들어 작업 시간이 길어질 수 있다는 점입니다. Real World 프로젝트에서 처음으로 백엔드를 직접 구현할 때 이 점을 경험했습니다. 3주 안에 MVP를 완성하려 했지만, 백엔드 구조와 구현 방식을 충분히 이해하려는 과정에 예상보다 많은 시간을 썼고, 결과적으로 일정이 약 1주 늦어졌습니다. 결과물의 완성도도 중요하지만, 정해진 시간 안에 사용자에게 필요한 핵심 기능을 먼저 전달하는 판단이 부족했다는 점을 배웠습니다.

이후 UNIBUSK처럼 마감이 명확한 팀 프로젝트에서는 개발 중 더 깊게 학습하고 싶은 주제가 생기면 바로 파고들기보다 핵심 용어와 참고 링크를 Notion에 기록해 두었습니다. 우선순위 작업과 프로젝트 기간이 끝난 뒤 그 내용을 다시 학습하고 블로그 글로 정리했습니다.

지금은 학습을 미루는 것이 아니라, 현재 일정에 필요한 학습과 이후에 확장할 학습을 구분하려고 합니다. 덕분에 팀 일정에 영향을 주지 않으면서도 배움을 계속 이어갈 수 있었습니다.

Q8. 경력 공백기 (2023 데브코스 수료 ~ 2025.12)

본인 특수사항이라 반드시 하나의 스토리로 준비. 아래 세부 질문으로 쪼개서 물어볼 수 있음.

• 이 기간 동안 무엇을 하셨나요?
• 취업까지 시간이 걸린 이유는 무엇이라고 생각하시나요?
• 그 기간 동안 실력이 뒤처졌다고 느낀 부분이 있었나요? 어떻게 보완하셨나요?
• 그 시기에 다른 회사 지원 경험이 있었나요? 결과가 어땠고 왜 그랬다고 생각하나요?
• 그 시기의 실패나 시행착오가 있었다면 무엇인가요? (숨기지 않아도 됨 — 본부장 발언 참고)
• 공백기 이후 다시 개발자로 도전하게 된 계기나 전환점은 무엇인가요?

버전 A — 솔직한 상세 답변

데브코스 수료 후 공백이 길어진 가장 큰 이유는, 현업에 들어가기 전에 가능한 많은 기술을 완벽하게 익혀야 한다고 생각했기 때문입니다. 충분히 준비되지 않은 상태로 팀에 들어가면 적응하지 못하거나 다른 사람에게 부담이 될 수 있다는 두려움이 있었습니다.

그래서 학습 범위를 계속 넓히고 프로젝트의 완성도를 높이는 데 집중했습니다. 하지만 기술은 공부할수록 더 배울 것이 생겼고, '이 정도면 준비됐다'고 판단하는 기준을 계속 미루게 됐습니다. 지금 돌아보면 현업 적응은 모든 기술을 미리 아는 것이 아니라, 모르는 것을 빠르게 확인하고 우선순위에 맞춰 팀과 해결해가는 능력이라는 점을 충분히 이해하지 못했습니다.

이 생각을 바꾸기 위해 완벽한 준비를 기다리기보다, 정해진 기간 안에 결과를 만드는 경험을 의도적으로 늘렸습니다. Real World를 통해 서비스 전체 흐름을 직접 경험했고, UNIBUSK와 Dessert에서는 다른 직군·팀원과 함께 마감과 우선순위 안에서 문제를 해결했습니다. 특히 더 깊게 공부하고 싶은 내용은 현재 작업을 멈추지 않도록 Notion에 기록해 두고, 우선순위 작업이 끝난 뒤 학습하고 블로그로 정리하는 방식으로 바꿨습니다.

공백이 길어진 점은 제 판단이 부족했던 결과라고 생각합니다. 다만 그 경험을 통해 완벽함을 기다리기보다, 현재 필요한 일을 책임 있게 수행하고 모르는 것은 빠르게 배우며 팀과 소통하는 방식이 더 중요하다는 점을 배웠습니다. 이제는 부족한 부분을 숨기거나 혼자 완벽히 채우려 하기보다, 학습 범위와 우선순위를 관리하며 팀에 기여하는 개발자가 되려고 합니다.

버전 B — 1분 압축 답변

공백이 길어진 이유는 당시 제가 준비의 기준을 잘못 세웠기 때문입니다. 현업에 들어가기 전 더 많은 기술을 알아야 한다고 생각했고, 그 결과 학습과 프로젝트 완성도에만 시간을 쓰며 지원과 협업 경험을 충분히 늘리지 못했습니다.

하지만 프로젝트를 진행하면서 현업 적응은 모든 것을 미리 아는 것이 아니라, 모르는 부분을 빠르게 확인하고 우선순위를 정해 팀과 해결하는 능력이라는 점을 배웠습니다. 이후에는 마감이 있는 팀 프로젝트에 참여했고, 학습이 필요한 내용은 현재 작업과 분리해 기록한 뒤 후속 학습으로 이어가는 방식으로 바꿨습니다.

공백이 길어진 점은 제 판단이 부족했던 결과입니다. 다만 같은 기준으로 다시 준비하지 않도록, 지금은 완벽한 준비를 기다리기보다 맡은 일을 끝까지 수행하고 부족한 부분은 빠르게 배우며 팀에 기여하는 방식으로 바꿨습니다.

사용 기준: 첫 질문에는 버전 B로 답하고, 면접관이 공백기의 구체적 이유·생각 변화·보완 행동을 물으면 버전 A의 내용을 이어서 설명할 것.

Q9. 잇뉴가 어떤 회사라고 이해하고 계신가요? (지원동기와 겹침, 참고용)

README.md 서비스 3개(ERLN·MemoryMint·MinTrigger) 참고. 2차 회사 이해도 확인

2차 임원용 초안

잇뉴는 AI와 블록체인 기술을 자체 기술로만 보유하는 데 그치지 않고, 제주 지역의 실제 운영 문제에 연결하는 회사라고 이해하고 있습니다. ERLN은 당일배송 운영에서 스마트 배차와 경로 최적화를 다루고, MemoryMint는 행사 운영과 인증서 발급을, MinTrigger는 인증·검증·이력 추적 기능을 다른 서비스가 API로 활용할 수 있게 제공합니다.

특히 물류, 행사·인증, 공공·민간 프로젝트처럼 도메인은 달라도 데이터에서 판단을 만들고 그것을 현장 실행으로 연결한다는 공통점이 인상적이었습니다. 공개 자료로는 각 제품의 실제 적용 범위까지 단정하기 어려운 부분도 있어, 입사 후에는 어떤 사용자와 운영 문제를 가장 우선하고 있는지 먼저 이해하며 기여하고 싶습니다.

🟡 2순위 — 준비 권장

인터뷰 2~3회 등장 or 잇뉴 평가 기준과 직결되는 질문입니다.

Q10. 지금까지 개발하면서 가장 보람 있거나 뿌듯했던 순간은?

2차 임원용 초안

제가 가장 뿌듯함을 느끼는 순간은 문제가 발생했을 때 겉으로 보이는 현상만 고치는 것이 아닌, 원인을 찾아 의도한 흐름이 정상적으로 동작하게 만들었을 때입니다.

UNIBUSK에서 공연 등록 화면의 입력 문제를 발견했을 때도, 단순히 화면이 느리다는 현상에서 멈추지 않고 어떤 입력이 어느 부분에 영향을 주는지 확인해 원인을 찾았습니다. 이후 필요한 부분만 수정해, 사용자가 입력할 때 관련된 화면만 자연스럽게 반응하도록 개선했습니다.

특히 제가 해결한 문제가 사용자에게는 불편 없이 기능을 사용할 수 있는 경험으로, 팀에는 이후에도 참고할 수 있는 문제 해결 과정으로 남을 때 가장 보람을 느낍니다.

Q11. 이전 팀에서는 다른 직군과 어떻게 협업하셨나요?

cover-letter.md 협업 Q1~Q8 참고. 본부장 "의사소통" 핵심

버전 A — 직군별 관점 조율 중심

직군마다 중요하게 보는 기준이 다르다는 점을 먼저 확인하려고 했습니다. UNIBUSK의 공연 등록 플로우를 논의할 때 기획에서는 사용자가 복잡하지 않게 입력하는 흐름을 중요하게 봤고, 개발에서는 이전 단계 이동이나 중간 이탈 시 입력값을 어떻게 보존할지가 우려였습니다.

그래서 어느 쪽 방식이 맞는지부터 주장하기보다, 사용자가 등록을 끝까지 완료하려면 어떤 상태가 언제 유지돼야 하는지로 논의 기준을 바꿨습니다. 그 결과 단계별 입력 흐름은 유지하면서, 입력 상태·단계 간 스냅샷·서버 상태를 분리해 구현했습니다.

저는 기술 용어로 설득하기보다, 그 선택이 사용자 경험·일정·수정 비용에 어떤 영향을 주는지로 설명하려고 합니다. 합의한 내용은 문서나 이슈로 남겨 다음 작업에서도 같은 이해를 유지하는 것을 중요하게 생각합니다.

버전 B — 일정·중간 공유·점진적 조율 중심

다른 직군과 협업할 때는 먼저 이번 작업의 일정, 사용자에게 필요한 결과, 그리고 함께 결정해야 할 항목을 맞추려고 합니다. 완성된 결과물을 기다리기보다, 사용자 흐름이나 아직 결정되지 않은 쟁점을 중간에 공유해 방향이 맞는지 확인하는 방식을 선호합니다.

UNIBUSK의 공연 등록 플로우를 논의할 때도 기획에서는 사용자가 복잡하지 않게 입력하는 흐름을 중요하게 봤고, 개발에서는 이전 단계로 돌아가거나 중간에 이탈했을 때 입력 내용을 어떻게 다룰지 확인이 필요했습니다. 저는 어느 방식이 더 낫다고 바로 주장하기보다, 사용자가 등록을 끝까지 완료하려면 무엇을 먼저 결정해야 하는지로 논의 기준을 바꿨습니다. 그 결과 단계별 입력 흐름은 유지하되, 이전 단계 이동과 입력값 유지가 필요한 조건을 함께 정리할 수 있었습니다.

이 경험을 통해 협업은 처음부터 완벽한 계획을 만드는 것보다, 일정 안에서 핵심 흐름과 남은 쟁점을 계속 공유하며 조정하는 과정이라고 배웠습니다. 합의한 내용과 다음 확인 항목은 문서나 이슈로 남겨, 다음 작업에서도 같은 이해를 유지하려고 합니다.

Q12. AI 툴(ChatGPT/Copilot 등)을 어떻게 쓰나요? 장단점은?

cover-letter.md AI 코딩 에이전트 답변, job-requirements-qa.md Q10~Q14 참고. 잇뉴는 AI-native를 강조하므로 중요한 질문

2차 임원용 초안

저는 AI를 코드 생성 도구로만 쓰기보다, 작업을 시작하기 전에 이슈를 구조화하고 놓친 조건을 찾는 보조 도구로 사용했습니다.

구체적으로는 공용 프롬프트 양식에 이슈의 목표, 우선순위, 요구사항, 관련 문서와 제약 조건을 넣고, 작업 범위와 구현 초안, 확인이 필요한 질문, 예외 상황을 정리해 달라고 요청했습니다.

다만 AI가 만든 초안을 그대로 구현하지는 않았습니다. 기획 의도와 다르게 해석한 부분은 없는지, 실제 코드 구조와 맞는지, 사용자가 실패할 수 있는 예외 상황이 빠지지 않았는지를 직접 확인했습니다. 필요한 경우 기획자나 팀원에게 다시 질문한 뒤 구현 범위를 정했습니다.

1차 면접을 통해 좋은 프롬프트 하나만으로는 결과 품질을 보장할 수 없다는 점도 더 분명히 인식했습니다. 최근에는 프롬프트 자체보다 AI가 참고할 맥락, 사용할 도구, 검증 방식, 사람이 최종 판단하는 지점을 함께 설계하는 하네스 엔지니어링과 루프 엔지니어링 개념을 학습하고 있습니다. 아직 제가 이 구조를 직접 설계한 경험은 없지만, 잇뉴에서 실제로 운영하는 방식을 이해하고 제 작업에도 적용해보고 싶습니다.

결국 AI를 잘 쓴다는 것은 생성 속도보다, 제안의 전제와 한계를 설명하고 최종 결과에 책임질 수 있는지라고 생각합니다.

Q13. 프로젝트하면서 힘들었던 점과 극복 방법은?

project-experience-notes.md — 렌더링 문제, Cross-Domain Cookie 등

2차 임원용 초안

가장 어려웠던 점은 UNIBUSK MVP 단계에서 일정과 각 직군의 작업 진행도를 충분히 함께 관리하지 못했던 경험입니다. 당시에는 각자 맡은 기능을 구현하는 데 집중했고, 작업 간 의존 관계나 현재 막힌 지점을 팀 전체가 제때 파악할 수 있는 구조가 부족했습니다. 그 결과 협업 과정에서 다음 작업을 기다리거나 조율해야 하는 상황이 생겼습니다.

고도화 단계에서는 이 문제를 보완하기 위해 제가 Notion 칸반 보드를 관리하며 일정과 작업 상태를 수동으로 정리했습니다. 팀원이 데일리 계획을 작성하지 않은 경우에는 개별적으로 확인해 업데이트를 요청했고, 초반에는 작업 현황을 공유하는 데 도움이 됐습니다. 다만 고도화 기간이 끝나갈수록 수동 관리의 부담이 커졌고, 일부 작업의 상태가 제때 갱신되지 않는 한계도 확인했습니다.

이 경험을 통해 Jira 같은 도구와 자동화를 활용하면 반복적인 현황 수집 부담은 줄일 수 있다는 점을 배웠습니다. 동시에 도구만으로 팀의 참여를 만들 수는 없다고 생각합니다. 다음에는 관리 방식부터 정하기보다, 왜 상태 공유가 필요한지와 갱신 주기·담당자를 팀과 먼저 합의하고, 입력 부담을 최소화한 뒤 정기적으로 막힌 지점을 함께 점검하겠습니다.

Q14. 업무를 지시받는 것이 편한가요, 스스로 찾아서 하는 것이 편한가요?

"Developer vs Coder" 발언과 직결되는 질문

2차 임원용 초안

처음에는 업무의 목표와 우선순위를 충분히 이해하는 것이 먼저이고, 그 안에서 개선할 문제는 스스로 찾는 방식이 가장 좋다고 생각합니다. 방향을 확인하지 않은 주도성은 팀의 우선순위와 어긋날 수 있기 때문입니다.

예를 들어 UNIBUSK에서는 기능 구현 후에도 공연 등록 폼의 실제 렌더링을 측정해 불필요한 갱신을 발견했고, Dessert에서는 새 서비스가 추가되는 상황에서 공용 자원과 컨벤션을 어떻게 유지할지 먼저 제안했습니다. 다만 이런 제안도 혼자 결정하지 않고, 문제의 근거와 대안을 공유해 팀의 판단으로 만들었습니다.

맡은 일을 정확히 완료하는 것을 기본으로 하되, 사용성과 운영에 도움이 되는 다음 문제까지 발견해 대화로 풀어가는 개발자가 되고 싶습니다.

Q15. 본인이 잇뉴에 잘 맞는 사람이라고 생각하는 이유는?

README.md 개발 문화 섹션의 인재상(I-T-N-E-W)과 연결

2차 임원용 초안

저는 주어진 화면을 구현하는 데서 멈추기보다, 사용자가 실제로 불편한 지점과 팀이 반복해서 비용을 쓰는 지점을 찾아보려는 편입니다. 다만 그 문제를 제 방식으로만 풀기보다, 근거를 공유하고 다른 직군·팀원의 관점을 반영해 함께 유지할 수 있는 형태로 만드는 것을 중요하게 생각합니다.

성능 문제를 측정해 개선한 경험, 팀 규모에 맞춰 FSD 구조를 조정하고 컨벤션을 문서화한 경험이 그 예입니다. 잇뉴가 여러 기술을 현장 서비스와 운영 문제에 연결하는 것처럼, 저도 기술 선택을 사용자·운영자·동료에게 어떤 도움이 되는지 기준으로 판단하고 싶습니다.

신입으로서 모르는 영역은 빠르게 질문하고 배우되, 단순히 지시를 기다리기보다 관찰한 문제와 개선안을 먼저 꺼내는 구성원이 되겠습니다.

Q16. 앞으로 3개월, 6개월, 1년 동안 어떤 것을 공부할 계획인가요? 그 이유는요?

2차 임원용 초안

입사 초기 3개월에는 새 기술을 넓게 늘리기보다 제품, 사용자, 배포 흐름, 팀의 의사결정 방식을 정확히 이해하는 데 집중하겠습니다. 작은 기능이라도 요구사항부터 운영 지표·장애 대응까지 연결해 보며, 팀의 코드와 업무 언어를 빠르게 익히겠습니다.

6개월에는 제가 맡은 영역에서 반복되는 품질 문제를 하나 이상 발견해 개선해보고 싶습니다. 프론트엔드에서는 성능, API 상태 관리, 컴포넌트 재사용성, 테스트 중 실제 서비스의 병목에 맞는 주제를 선택하겠습니다.

1년에는 기능을 안정적으로 맡는 것을 넘어, 새로 합류한 사람도 이해할 수 있는 문서나 컨벤션으로 팀에 기여하고 싶습니다. 계획 자체보다 제품의 우선순위에 맞춰 학습 주제를 조정하는 것이 중요하다고 생각합니다.

Q17. 여가·취미 생활은 어떻게 보내시나요?

잇뉴 인터뷰 5회 등장. 답변 부담은 적으니 가볍게 준비

2차 임원용 초안

여가에는 웹소설을 읽는 것을 좋아합니다. 개발할 때는 문제를 오래 고민하고 해결책을 판단해야 하는 경우가 많아서, 쉬는 시간에는 별도의 결정이나 깊은 고민을 요구하지 않는 가벼운 이야기를 읽으며 머리를 환기합니다.

반대로 생각이 복잡하거나 정리가 필요한 일이 있을 때는 짧게 산책합니다. 잠시 작업에서 거리를 두고 걸으면서 여러 선택지를 다시 살펴보고, 무엇을 먼저 해야 할지 우선순위를 정리하려고 합니다.

저에게 웹소설은 충분히 쉬는 시간이고, 산책은 복잡한 생각을 차분히 정리하는 시간입니다.

꼬리질문 준비: 실제로 좋아하는 웹소설 장르와 최근 재미있게 읽은 작품 한두 개를 준비할 것.

Q18. 최근에 관심 있는 기술이나 이슈가 있나요?

2차 임원용 초안

최근에는 프론트엔드에서 자바스크립트로 직접 처리하던 인터랙션과 애니메이션을, CSS만으로 더 간결하고 선언적으로 구현할 수 있는 흐름에 관심이 있습니다. 다만 새 기능이라는 이유만으로 바로 적용하기보다, 지원 브라우저 범위와 점진적 향상 가능 여부, 접근성, 운영 환경에서의 안전성을 먼저 확인해야 한다고 생각합니다.

백엔드 쪽에서는 NestJS와 Drizzle을 사용하는 모노레포에서 Zod 스키마를 기준으로 프론트엔드와 백엔드의 입출력 타입을 함께 관리하는 방식에도 관심이 있습니다. API 계약을 한곳에서 관리하면 타입 불일치로 생기는 오류를 줄일 수 있기 때문입니다.

AI 쪽에서는 프롬프트 하나를 잘 작성하는 것보다, AI가 참고할 맥락과 검증 방식을 어떻게 설계해야 결과를 신뢰할 수 있는지에 관심이 있습니다. 하네스·루프 엔지니어링도 이 맥락에서 학습하고 있지만, 아직 직접 설계한 경험은 없어 개념을 이해하고 실제 활용 사례와 연결하는 단계입니다.

프론트엔드 생태계는 Korean FE Article 커뮤니티를 중심으로 보고, AI 관련 동향은 GeekNews를 통해 확인하고 있습니다.

⚪ 3순위 — 여유 되면

주로 "가정형 상황 대처" 질문이라 잇뉴 인터뷰엔 거의 없고, 답변 원칙만 잡아두면 즉석 대응이 가능합니다.

상황 대처

Q19. 서비스 오픈 한 달 전에 치명적인 오류를 발견했다면 어떻게 하시겠습니까?

2차 임원용 초안

먼저 혼자 수정부터 하기보다 오류의 재현 조건, 사용자 영향, 데이터 손상·보안 위험, 우회 가능 여부를 빠르게 확인하겠습니다. 치명적이라는 판단 근거를 제품·개발·운영 담당자에게 즉시 공유하고, 오픈 유지·범위 축소·일정 조정 중 어떤 선택이 가능한지 함께 결정하겠습니다.

수정 방향은 임시 차단이나 우회책과 근본 해결책을 나눠 제시하겠습니다. 특히 데이터 정합성이나 보안 문제라면 일정 압박보다 안전을 우선하겠습니다. 조치 뒤에는 회귀 테스트와 모니터링 기준을 정하고, 원인과 재발 방지 항목을 기록하겠습니다.

Q20. 마감일이 임박했는데 완료하지 못한 상황이라면 어떻게 하시겠습니까?

2차 임원용 초안

완료하지 못할 가능성을 알게 된 시점에 바로 공유하겠습니다. 마감 직전에 알려야 하는 상황을 만들지 않기 위해, 현재 완료율과 막힌 이유, 남은 작업을 작게 나눠 지속적으로 보겠습니다.

공유할 때는 단순히 늦는다고 말하기보다 사용자 핵심 흐름을 지키는 최소 범위, 줄일 수 있는 부가 범위, 추가 지원이 필요한 부분을 함께 제안하겠습니다. 합의 없이 품질을 낮추거나 무리하게 약속하지 않고, 팀이 판단할 수 있는 정보를 제공하는 것이 제 역할이라고 생각합니다.

Q21. 희망하지 않는 업무나 부서에 배치된다면 어떻게 하시겠습니까?

2차 임원용 초안

우선 그 업무가 제품과 팀에 왜 필요한지, 제가 어떤 역할을 기대받는지부터 이해하겠습니다. 선호와 무관하게 맡은 업무에서 신뢰를 만드는 것이 먼저라고 생각합니다.

다만 장기적으로 프론트엔드 역량을 어떻게 활용·성장시킬 수 있는지는 리더와 솔직하게 대화하겠습니다. 현재 업무를 성실히 수행하면서도, 제가 잘할 수 있는 영역과 배우고 싶은 방향을 공유해 팀의 필요와 제 성장 방향이 만나는 지점을 찾겠습니다.

Q22. 긴급한 업무가 두 건 동시에 생긴다면 어떻게 처리하시겠습니까?

2차 임원용 초안

두 일을 동시에 붙잡기보다 사용자 영향, 보안·데이터 위험, 서비스 중단 범위, 마감 시점을 기준으로 우선순위를 빠르게 정하겠습니다. 혼자 판단하기 애매하면 관련 담당자에게 두 이슈의 영향도를 확인해 결정 근거를 맞추겠습니다.

한 업무를 처리하는 동안 다른 업무가 방치되지 않도록 현황·예상 대응 시간·필요한 도움을 공유하고, 가능하면 역할을 나누겠습니다. 긴급 상황일수록 빠르게 처리하는 것과 동시에 팀이 같은 상황 인식을 갖는 것이 중요합니다.

Q23. 회사의 중요 업무와 개인적인 일이 동시에 생긴다면 어떻게 하시겠습니까?

2차 임원용 초안

회사의 중요한 업무는 책임 있게 대응하되, 개인적인 일이 피할 수 없는 사안이라면 가능한 빨리 상황과 영향 범위를 공유하겠습니다. 숨기거나 무리해서 두 가지를 모두 처리하겠다고 약속하는 것은 오히려 팀에 리스크를 줄 수 있다고 생각합니다.

인수인계 가능한 상태로 작업을 정리하고, 대체 담당이나 일정 조정이 가능한지 리더와 협의하겠습니다. 평소에도 진행 상황과 결정 맥락을 남겨두는 습관이 이런 상황에서 팀의 부담을 줄인다고 생각합니다.

근무 조건·조직 적합성

Q24. 야근이 잦다면 괜찮으신가요?

2차 임원용 초안

서비스 이슈나 마감처럼 꼭 필요한 상황에서는 책임 있게 대응할 수 있습니다. 다만 야근이 반복된다면 개인의 의지 문제로만 보지 않고, 요구사항 변경, 우선순위, 인력 배분, 기술 부채 중 무엇이 원인인지 팀과 점검해야 한다고 생각합니다.

단기적으로는 최선을 다하되, 장기적으로는 같은 긴급 상황이 반복되지 않도록 일하는 방식을 개선하는 것이 더 건강한 협업이라고 생각합니다.

Q25. 워라밸에 대해 어떻게 생각하시나요?

2차 임원용 초안

워라밸은 일을 적게 한다는 의미보다, 업무 시간에 집중해 지속적으로 좋은 판단을 할 수 있는 상태를 만드는 것이라고 생각합니다. 개발은 문제를 오래 들여다보는 일이 많아서, 재충전 없이 계속 밀어붙이면 코드 품질과 소통 품질도 함께 떨어질 수 있습니다.

맡은 결과에는 책임을 지되, 일정과 리스크를 일찍 공유하고 업무를 지속 가능한 방식으로 운영하는 팀에서 더 좋은 성과가 난다고 생각합니다.

Q26. 조직 문화에 적응하는 본인만의 방법이 있나요?

2차 임원용 초안

처음에는 기존 방식이 왜 만들어졌는지 이해하는 데 시간을 쓰겠습니다. 코드 구조, PR, 이슈, 회의에서 반복되는 표현을 보며 팀이 중요하게 여기는 품질 기준과 의사결정 방식을 파악하겠습니다.

이해가 안 되는 부분은 혼자 추측하지 않고 작은 단위로 질문하겠습니다. 이후에는 제가 관찰한 개선점을 바로 바꾸기보다, 기존 방식의 장점과 변경 비용을 먼저 확인하고 제안하겠습니다. 적응은 제 방식을 관철하는 것이 아니라, 팀의 맥락을 이해한 뒤 더 나은 방법을 함께 만드는 과정이라고 생각합니다.

Q27. 신입 개발자들이 퇴사하는 이유가 뭐라고 생각하시나요?

2차 임원용 초안

이유는 하나로 단정하기 어렵지만, 기대 역할과 실제 업무가 다르거나, 질문하고 피드백받을 통로가 부족할 때 어려움을 크게 느낄 수 있다고 생각합니다. 신입은 모르는 것이 자연스러운데, 무엇을 어느 수준까지 스스로 해결해야 하는지 알기 어려울 수 있기 때문입니다.

그래서 저는 모르는 것을 숨기기보다 제가 확인한 내용과 막힌 지점을 정리해 질문하고, 받은 피드백은 다음 작업에 반영해 신뢰를 쌓으려 합니다. 회사도 구성원도 서로 기대를 투명하게 맞추는 대화가 중요하다고 생각합니다.

협업·리딩

Q28. 실력이 부족한 팀원과 함께 일해야 한다면 어떻게 하시겠습니까?

2차 임원용 초안

먼저 실력이 부족하다고 단정하기보다, 현재 과제에서 어떤 정보나 경험이 부족한지 확인하겠습니다. 설명이 부족했거나 업무 범위가 너무 크거나, 낯선 도메인일 수도 있기 때문입니다.

제가 아는 내용은 작은 단위로 나누어 맥락과 함께 공유하고, 코드 리뷰에서는 정답을 바로 제시하기보다 왜 그렇게 판단했는지 대화하겠습니다. 다만 일정이나 품질에 영향이 큰 부분은 혼자 감당하지 않고 리더와 공유해 역할과 지원 방식을 조정하겠습니다. 목표는 평가가 아니라 팀이 결과를 내고 함께 성장하는 것입니다.

Q29. 후배나 신입 팀원을 리딩해야 한다면 어떻게 하시겠습니까?

2차 임원용 초안

신입에게는 결과물뿐 아니라 왜 이 작업을 하는지, 무엇을 먼저 확인해야 하는지를 함께 설명하겠습니다. 바로 답을 주기보다 본인이 생각한 접근과 막힌 지점을 먼저 듣고, 필요한 만큼만 힌트를 드리는 방식이 성장에 도움이 된다고 생각합니다.

Dessert에서 온보딩 자료와 컨벤션을 정리했던 경험처럼, 개인의 기억에 의존하지 않고 문서·예시·리뷰 기준으로 반복 가능한 도움을 만들겠습니다. 저도 신입이기 때문에 권위로 이끌기보다, 함께 확인하고 배우는 태도를 유지하겠습니다.

Q30. 성향이 맞지 않는 사람과 팀이 된다면 어떻게 하시겠습니까?

2차 임원용 초안

성향이 다르다는 사실과 함께 일할 수 없다는 것은 다르다고 생각합니다. 먼저 상대가 어떤 방식으로 일하고 무엇을 중요하게 보는지 파악하겠습니다. 예를 들어 빠른 실행을 중시하는지, 충분한 검토를 중시하는지에 따라 갈등의 원인이 달라질 수 있습니다.

개인적인 호불호 대신 업무의 목표·근거·마감·결정 기준을 명확히 하며 소통하겠습니다. 계속 어려움이 있다면 감정적으로 쌓아두지 않고, 구체적인 상황을 기준으로 1:1 대화나 리더의 도움을 요청하겠습니다.

Q31. 피드백을 주거나 받았던 경험이 있나요?

2차 임원용 초안

Dessert에서 FSD 구조를 설계할 때 제가 widgets 레이어까지 포함하는 방향을 생각한 적이 있습니다. 팀원은 현재 규모에서는 실제 내용보다 폴더 구조와 관리 부담이 먼저 커질 수 있다고 피드백했습니다.

처음 기준을 세운 사람이 저였기 때문에 방어적으로 반응할 수도 있었지만, 다른 팀원의 의견과 현재 기능 범위를 함께 확인했습니다. 그 결과 widgets 레이어를 두지 않는 방향이 더 적절하다고 판단했고, 변경한 기준을 컨벤션 문서에 반영했습니다.

이 경험을 통해 피드백은 제 의견의 옳고 그름을 판정하는 일이 아니라, 팀이 유지할 수 있는 결정을 만드는 입력이라는 점을 배웠습니다. 저도 리뷰할 때는 사람 평가가 아니라 코드의 영향 범위와 대안을 중심으로 말씀드리려 합니다.

부가 질문

Q32. 개발자가 되지 않았다면 어떤 일을 하고 싶었나요?

사실 확인 후 사용할 답변 틀

개발자가 아니었다면 [실제 관심 분야 또는 경험]와 관련된 일을 했을 것 같습니다. 제가 그 분야에 관심을 갖는 이유는 [사람·문제·과정 중 실제로 중요하게 보는 지점] 때문입니다.

다만 지금은 그 관심을 가장 직접적으로 결과물로 만들 수 있는 일이 개발이라고 느낍니다. 개발을 통해 문제를 구조화하고 사람들과 해결책을 실험해볼 수 있다는 점이 저에게 가장 잘 맞습니다.

확인 메모: 그럴듯한 직업을 만들지 말고, 실제 관심사 한 가지로 교체할 것.

Q33. 리더에 가까운 편인가요, 팔로워에 가까운 편인가요?

2차 임원용 초안

상황에 따라 둘 다 필요하다고 생각합니다. 목표와 방향이 이미 정해진 상황에서는 맡은 역할을 정확히 수행하고, 모르는 부분은 빠르게 확인하는 팔로워가 되어야 합니다. 반대로 기준이 없거나 반복 문제가 보이는 상황에서는 문제를 정리하고 논의를 시작하는 역할을 할 수 있습니다.

Dessert에서 컨벤션과 작업 흐름을 정리한 경험은 후자에 가깝지만, 그 과정도 제가 답을 정해 전달한 것이 아니라 팀원 의견을 모아 합의 가능한 기준을 만든 일이었습니다. 직함보다 지금 팀에 필요한 역할을 맡는 사람이 되고 싶습니다.

Q34. 혼자 개발하는 것과 팀으로 일하는 것 중 어느 쪽이 편한가요?

2차 임원용 초안

혼자 개발할 때는 빠르게 시도하고 전체 흐름을 깊게 경험할 수 있다는 장점이 있습니다. Real World를 혼자 만들며 프론트엔드와 백엔드의 연결을 이해한 경험이 그 예입니다.

다만 실제 서비스를 더 잘 만들기 위해서는 팀 개발이 더 중요하다고 생각합니다. 서로 다른 관점을 통해 제가 놓친 사용자·운영·디자인·기술 리스크를 발견할 수 있고, 결과를 한 사람이 아니라 팀이 계속 유지할 수 있기 때문입니다. 그래서 저는 혼자서도 책임 있게 파고들되, 중요한 판단은 팀과 투명하게 나누는 방식을 선호합니다.

Q35. 주변 사람들은 본인을 어떤 사람으로 평가하나요?

사실 확인 후 사용할 답변 틀

주변에서는 저를 [실제 평가: 예, 끝까지 확인하는 사람 / 약속한 일을 정리해 공유하는 사람]이라고 말하는 편입니다. 프로젝트에서 [실제 사례]처럼, 문제가 생기면 감으로 넘기기보다 원인과 다음 행동을 정리해 공유하려 했기 때문이라고 생각합니다.

저도 그런 평가를 유지하기 위해, 막힌 점을 혼자 오래 끌기보다 제가 확인한 내용과 필요한 도움을 구체적으로 말하려고 합니다.

확인 메모: 친구·팀원의 실제 표현 한 문장을 넣으면 가장 자연스럽다.

Q36. 프론트엔드 개발자에게 가장 중요한 역량은 무엇이고, 본인은 그것을 갖췄다고 생각하나요?

2차 임원용 초안

프론트엔드 개발자에게 가장 중요한 역량은 사용자 요구를 정확히 이해하고, 이를 여러 직군이 함께 판단할 수 있는 화면·상태·우선순위로 풀어내는 소통 능력이라고 생각합니다. 구현 기술은 중요하지만, 사용자가 무엇을 해야 하는지와 그 과정에서 어떤 실패가 생길 수 있는지를 놓치면 좋은 화면을 만들기 어렵습니다.

저는 UNIBUSK에서 기획과 개발의 우려를 사용자 등록 흐름으로 다시 정리해 합의한 경험이 있고, Dessert에서는 팀이 같은 구조를 이해하도록 컨벤션을 문서화한 경험이 있습니다. 아직 배우는 단계이지만, 문제를 정확히 질문하고 근거를 공유하며 함께 결정하는 태도는 갖추고 있다고 생각합니다.

Q37. 프론트엔드(해당 직무)의 매력이 무엇이라 생각하나요?

2차 임원용 초안

프론트엔드는 기술적인 결정이 사용자의 경험으로 바로 드러난다는 점이 매력적입니다. 입력 한 번이 불필요하게 화면 전체를 갱신하는 문제나, 로그인 흐름이 한 환경에서만 실패하는 문제처럼 작은 구현 차이가 사용자의 신뢰와 편의에 직접 영향을 줍니다.

동시에 기획, 디자인, 백엔드와 가장 자주 연결되는 위치라서, 서로 다른 요구를 하나의 일관된 경험으로 만드는 역할을 할 수 있습니다. 저는 그 과정에서 사용자에게 보이는 결과와 팀이 유지할 구조를 함께 고민할 수 있다는 점에 보람을 느낍니다.

Q38. 입사하신다면 잇뉴에서 이루고 싶은 목표가 있나요?

2차 임원용 초안

첫 목표는 빠르게 신뢰받는 동료가 되는 것입니다. 맡은 기능을 일정 안에 구현하는 데 그치지 않고, 요구사항의 모호한 부분과 사용자 영향, 운영상 예외를 미리 확인해 팀이 안심하고 함께 일할 수 있게 하겠습니다.

이후에는 제가 맡은 제품에서 반복되는 사용자 불편이나 개발·운영 비용을 하나 이상 발견해 개선하고 싶습니다. 성능, 상태 관리, 디자인 시스템, 테스트 중 무엇이 우선인지는 입사 후 제품의 실제 문제를 파악한 뒤 정하겠습니다. 공개 자료로 본 잇뉴의 제품들이 현장 실행을 중시하는 만큼, 저도 측정 가능한 사용자·운영 개선으로 기여하고 싶습니다.

Q39. 입사 후 3~5년 뒤 본인이 어떤 개발자가 되어 있길 바라나요?

2차 임원용 초안

3~5년 뒤에는 맡은 기능을 안정적으로 끝내는 개발자를 넘어, 문제를 발견했을 때 여러 직군과 함께 해결 방향을 만들고 끝까지 운영할 수 있는 개발자가 되고 싶습니다.

기술적으로는 프론트엔드 성능과 구조 설계 역량을 깊게 가져가되, API·데이터·배포 흐름까지 이해해 더 나은 질문을 할 수 있는 사람이 되고 싶습니다. 또한 제가 배운 기준을 코드 리뷰와 문서로 남겨, 새로 합류한 동료의 시행착오를 줄이는 데도 기여하겠습니다.

Q40. 도움이 되었던 대외활동이나 경험이 있다면?

2차 임원용 초안

SWYP 활동이 가장 도움이 됐습니다. 기획·디자인·개발 직군이 함께 제한된 기간 안에 서비스를 만들어야 했기 때문에, 기술적으로 가능한지뿐 아니라 사용자 흐름과 일정 안에서 무엇을 우선해야 하는지를 함께 논의하는 경험을 했습니다.

특히 UNIBUSK를 통해 기능을 구현한 뒤에도 성능과 인증 문제를 사용자 관점에서 다시 점검했고, 직군 간 의견이 다를 때는 각자의 제약을 사용자 목표로 다시 정리해 합의하는 방식을 배웠습니다. 혼자 공부할 때는 얻기 어려운 협업의 책임감과 소통 방식을 익힌 경험입니다.

Q41. 본인의 전공/배경이 이 직무에 어떻게 도움이 된다고 생각하나요?

사실 확인 후 사용할 답변 틀

제 전공·이전 경험에서 얻은 [실제 강점]은 개발에서도 도움이 된다고 생각합니다. 특히 [구체적 행동 또는 경험]을 통해, 문제를 구조화하고 상대가 이해할 수 있게 설명하는 방식을 배웠습니다.

전공이 개발과 직접 일치하지 않더라도, 개발에서는 기술 지식뿐 아니라 사용자·동료와 문제를 정확히 맞추는 역량이 중요하다고 생각합니다. 저는 그 배경에서 얻은 강점을 개발 경험과 연결해 계속 보완해왔습니다.

확인 메모: 전공과 이전 경력이 제공된 자료에 명시돼 있지 않아 초안으로 단정하지 않았다. 실제 전공·이전 경험을 한 문장으로 알려주면 면접용 답변으로 구체화할 수 있다.