자기소개서·구두 답변 초안

1. 1분 자기소개

안녕하세요. 저는 성능 문제의 원인을 측정하고, 검증한 범위 안에서 개선하며, 팀이 일관되게 유지할 수 있는 구조를 만드는 개발자 박명재입니다.

UNIBUSK에서는 공연 등록 폼에서 입력 하나가 넓은 컴포넌트 트리를 리렌더시키는 문제를 발견했습니다. React DevTools Profiler와 console.count로 원인을 확인했고, watch()와 formState.errors의 구독 범위를 useWatch()와 useFormState({ name })로 분리해 렌더 함수 실행 횟수를 75회에서 1회로 줄였습니다.

Dessert Front Dashboard에서는 Seller와 Admin을 함께 운영하기 위한 모노레포와 공용 UI 패키지 구조를 설계했고, FSD 파일 배치와 의존성 규칙을 문서화했습니다. 기능 구현뿐 아니라 팀원이 같은 기준으로 코드를 읽고 수정할 수 있는 환경을 만들고자 했습니다.

ItNew에서도 문제를 추측으로 해결하기보다 사용자 영향과 원인을 확인하고, 서비스의 데이터 흐름과 AI 기반 개발 워크플로우를 팀이 유지할 수 있는 형태로 개선하는 개발자가 되고 싶습니다.

2. 지원동기

ItNew에 지원한 이유는 AI·위치 데이터·인증 기술을 실제 운영 서비스의 문제 해결로 연결하는 방향이 인상적이었기 때문입니다.

공식 홈페이지와 채용공고를 보며, 제주 당일배송 서비스 ERLN은 물류·모빌리티 운영을, MemoryMint와 MinTrigger는 행사 운영과 인증·검증 흐름을 서비스화하는 방향으로 이해했습니다. 단일 기술을 보여주는 데 그치기보다, 기술이 실제 운영 흐름 안에서 쓰이도록 만드는 점에 관심이 갔습니다.

저는 UNIBUSK와 Real World에서 API 요청 흐름, 인증 처리, 서버 데이터와 UI 상태의 연결, 성능 병목 개선을 다뤘습니다. Dessert Front Dashboard에서는 Seller 주문 대시보드를 개발하며 주문 상태, 결제 금액, 필터 조건처럼 운영자가 판단에 사용하는 데이터가 화면에서 일관되게 전달되도록 신경 썼습니다.

ItNew에서도 기술의 결과가 API와 UI, 운영 흐름 안에서 신뢰할 수 있게 전달되도록 구현하고 검증하는 개발자로 기여하고 싶습니다.

지원동기 꼬리 질문 대비

Q. Location AI가 무엇이라고 이해했나요?

Location AI를 깊게 구현해 본 경험은 없지만, ItNew의 서비스 맥락에서는 위치 데이터를 기반으로 운영 의사결정을 돕는 AI 기술로 이해했습니다. 예를 들어 물류 서비스인 ERLN에서는 수거지와 배송지, 차량 위치, 이동 거리, 시간 제약, 배송 우선순위 같은 데이터를 바탕으로 배차나 경로를 더 효율적으로 판단하는 데 활용될 수 있다고 봤습니다.

제가 Location AI 모델 자체를 직접 설계해 본 경험이 있는 것은 아니지만, 이 포지션에서는 위치 기반 판단 결과가 API, 데이터 모델, 운영 화면으로 어떻게 이어지는지 이해하는 역량이 중요하다고 생각합니다. 예를 들어 추천 경로, 예상 시간, 배송 상태, 예외 상황 같은 정보는 단순히 화면에 표시되는 값이 아니라, 서버의 판단 결과와 운영 정책이 사용자에게 전달되는 지점입니다.

그래서 저는 프론트엔드 구현에만 한정해서 보기보다, API 응답 구조와 상태 관리, 예외 처리, 사용자가 신뢰할 수 있는 UI 표현까지 함께 고려하는 방식으로 기여할 수 있다고 봅니다.

Q. 블록체인이 무엇이라고 이해하고 있나요?

블록체인은 데이터를 블록 단위로 연결하고, 여러 참여자가 같은 기록을 검증할 수 있게 만든 분산 원장 기술로 이해하고 있습니다. 핵심은 한 번 기록된 데이터의 위변조를 어렵게 만들고, 특정 기록이 언제 생성됐고 어떤 상태였는지 검증 가능하게 만드는 데 있다고 봅니다.

ItNew 서비스 맥락에서는 MinTrigger나 MemoryMint에서 인증서, 참여 기록, 검증 이력처럼 신뢰성이 중요한 데이터를 다룰 때 블록체인을 활용할 수 있다고 이해했습니다. 다만 제가 블록체인 프로토콜을 직접 구현한 경험이 있는 것은 아니기 때문에, 면접에서는 구현 경험을 과장하기보다 인증·검증·이력 추적을 위한 신뢰 계층으로 이해하고 있다고 답하겠습니다.

Q. ERLN, MemoryMint, MinTrigger를 각각 어떻게 이해했나요?

ERLN은 제주 당일배송을 중심으로 한 물류 서비스로 이해했습니다. 여기서는 AI 기반 스마트 배차, 경로 최적화, 배송 상태 관리처럼 위치와 운영 데이터가 실제 배송 흐름으로 이어지는 점이 중요해 보였습니다.

MemoryMint는 행사 운영 자동화 서비스로 이해했습니다. QR 기반 입장, 출석 관리, 인증서 발급처럼 행사 현장에서 반복되는 운영 업무를 디지털화하고, 참여 이력이나 인증 정보를 관리하는 서비스라고 봤습니다.

MinTrigger는 블록체인 기반 인증·검증 API 또는 B2B SaaS에 가까운 서비스로 이해했습니다. 특정 데이터나 이벤트의 신뢰성을 검증하고, 외부 서비스가 이를 API로 활용할 수 있게 하는 방향이라고 이해했습니다.

Q. 이 기술들을 왜 프론트엔드 지원동기와 연결했나요?

제가 관심을 가진 지점은 특정 기술 이름 자체보다, 복잡한 데이터를 사용자가 이해하고 행동할 수 있는 서비스 흐름으로 바꾸는 부분입니다. ERLN에서는 배차·경로·배송 상태 데이터가 운영 화면이나 사용자 화면으로 표현되어야 하고, MemoryMint나 MinTrigger에서는 인증·검증 결과가 사용자가 신뢰할 수 있는 UI와 API 흐름으로 연결되어야 합니다.

저는 UNIBUSK와 Real World에서 데이터 패칭 구조, 인증 흐름, 상태 분리, 에러 처리 같은 부분을 다뤘습니다. 그래서 ItNew에서도 AI나 블록체인 자체를 직접 연구하는 역할보다는, 그 결과가 실제 서비스 화면과 API 흐름에서 안정적으로 전달되도록 만드는 프론트엔드 개발자로 기여할 수 있다고 연결했습니다.

3. 가장 자신 있는 경험

가장 자신 있게 설명할 수 있는 경험은 UNIBUSK 공연 등록 폼의 렌더링 문제를 측정하고 해결한 과정입니다.

처음에는 React Hook Form의 비제어 컴포넌트 패턴을 사용했기 때문에 입력 시 리렌더가 적을 것이라고 예상했습니다. 하지만 Profiler로 확인해보니 watch('teamName') 한 줄 때문에 상위 컴포넌트가 폼 값을 구독하고, 하위 트리 전체가 영향을 받고 있었습니다.

이를 해결하기 위해 글자 수 표시만 담당하는 하위 컴포넌트로 useWatch()를 옮겼습니다. 이후에도 일부 필드에서 리렌더가 남아 있었고, 원인은 formState.errors 전체 객체 구독이었습니다. 최종적으로 useFormState({ name })로 각 필드가 자기 에러만 구독하도록 바꿨습니다.

검증은 Profiler와 console.count를 함께 사용했습니다. Profiler로 영향 범위를 보고, 실제 렌더 함수 실행 여부는 console.count로 확인했습니다. 그 결과 렌더 함수 실행 횟수가 75회에서 1회로 줄었습니다.

이 경험에서 중요한 점은 특정 API를 사용했다는 사실보다, 문제를 추측하지 않고 측정한 뒤 원인에 맞는 위치에서 해결했다는 점입니다.

4. 복잡하거나 예측하지 못했던 문제 해결 경험

UNIBUSK의 Kakao OAuth2 로그인 구현 중 로컬 환경에서만 인증 쿠키가 저장되지 않는 문제가 있었습니다.

처음에는 CORS 설정이나 클라이언트 요청 옵션 문제라고 생각했지만, 로그인 요청, Kakao 리다이렉트, 쿠키 저장, 후속 API 요청 흐름을 단계별로 나눠 확인했습니다. Chrome 개발자 도구로 리다이렉트 전후 요청과 쿠키 저장 위치를 확인한 결과, 로그인 성공 후 전달된 쿠키가 백엔드 도메인에 저장되어 프론트엔드 요청에 기대한 방식으로 포함되지 않는다는 점을 확인했습니다.

Route Handler, 터널링, IP 기반 쿠키 도메인, Middleware 접근 등을 검토했지만 각각 한계가 있었습니다. 최종적으로 백엔드가 로그인 성공 후 임시 Authorization Code를 프론트엔드 콜백 URL로 전달하고, 프론트엔드는 동일 출처 Proxy를 통해 이 코드를 토큰으로 교환하는 방식으로 인증 흐름을 바꿨습니다.

이 경험을 통해 서버가 쿠키를 내려준다는 사실만으로 인증이 보장되는 것이 아니라, 브라우저의 도메인별 쿠키 저장 정책과 요청이 이어지는 실행 흐름까지 함께 봐야 한다는 점을 배웠습니다.

5. 좋은 코드란 무엇이라고 생각하나요?

제가 생각하는 좋은 코드는 세 가지 기준을 만족하는 코드입니다.

첫째, 다른 팀원이 열었을 때 의도를 빠르게 파악할 수 있어야 합니다. UNIBUSK에서 글자 수 표시 로직을 TeamNameCharCount로 분리한 것처럼, 이름과 책임이 일치하면 코드를 읽는 비용이 줄어듭니다.

둘째, 결합도는 낮고 응집도는 높아야 합니다. Dessert Front Dashboard에서 FSD 컨벤션을 정리할 때 단방향 의존성, Public API, Cross-import 금지 원칙을 세워 슬라이스 내부 구현이 외부에서 직접 참조되지 않도록 했습니다.

셋째, 팀이 반복해서 지킬 수 있어야 합니다. 좋은 구조를 한 사람이 알고 있는 것과 팀 전체가 같은 기준으로 유지하는 것은 다릅니다. 그래서 파일 suffix, Query와 Mutation 배치 기준, 작업 파이프라인을 문서화했습니다.

좋은 코드 꼬리 질문 대비

Q. 결합도와 응집도가 무엇인가요?

결합도는 한 모듈이나 컴포넌트가 다른 모듈에 얼마나 의존하고 있는지를 의미합니다. 결합도가 높으면 한쪽 구현이 바뀔 때 다른 곳까지 함께 수정해야 할 가능성이 커집니다.

응집도는 하나의 모듈이나 컴포넌트 안의 코드들이 같은 목적과 책임을 중심으로 모여 있는 정도입니다. 응집도가 높다는 것은 하나의 파일이나 컴포넌트가 명확한 하나의 역할을 수행한다는 뜻입니다.

예를 들어 UNIBUSK에서 글자 수 표시 로직을 상위 폼 컴포넌트에 섞어두면 폼 전체가 입력값 변화에 영향을 받았습니다. 반대로 TeamNameCharCount처럼 글자 수 표시 책임을 가진 컴포넌트로 분리하면, 필요한 값만 구독하고 책임도 더 명확해집니다.

Q. 결합도가 높고 응집도가 낮은 코드는 어떤 문제가 생기나요?

가장 큰 문제는 변경 영향 범위가 예측하기 어려워진다는 점입니다. 하나의 수정이 관련 없는 화면이나 기능까지 깨뜨릴 수 있고, 테스트해야 할 범위도 넓어집니다.

응집도가 낮으면 한 파일이나 컴포넌트 안에 여러 책임이 섞입니다. 예를 들어 UI 표시, API 호출, 폼 검증, 권한 처리, 데이터 변환이 한곳에 모이면 코드를 읽을 때 어디가 어떤 책임인지 파악하기 어렵고, 일부만 재사용하거나 교체하기도 어렵습니다.

그래서 저는 좋은 코드를 "동작하는 코드"에서 끝내지 않고, 변경 이유가 비슷한 것끼리 모여 있고 외부와의 의존 방향이 명확한 코드로 보려고 합니다. Dessert Front Dashboard에서 단방향 의존성, Public API, Cross-import 금지 원칙을 정리한 것도 이런 변경 비용을 줄이기 위한 목적이었습니다.

6. 본인의 약점과 보완 방식

저의 약점은 익숙한 문제를 만나면 원인을 충분히 확인하기 전에 알고 있는 해결책부터 떠올리는 경향이 있다는 점입니다.

UNIBUSK의 렌더링 문제에서도 처음에는 React.memo()를 적용하면 해결될 것이라고 생각했습니다. 하지만 Profiler로 확인한 실제 원인은 props 변경이 아니라 상위 컴포넌트에서 폼 값을 구독하던 구조였습니다. 따라서 메모이제이션보다 구독 위치를 필요한 하위 컴포넌트로 옮기는 것이 더 적절했습니다.

이후에는 바로 해결책을 적용하기보다 문제가 발생하는 조건과 영향을 받는 범위를 먼저 확인합니다. 적어도 하나 이상의 대안을 검토하고, 각각의 장단점과 검증 방법을 비교한 뒤 구현하는 방식으로 보완하고 있습니다.

7. AI 코딩 에이전트 활용에 대한 답변

AI 코딩 에이전트는 생산성을 높일 수 있지만, 최종 책임은 개발자에게 있다고 생각합니다.

제가 AI에게 위임할 수 있다고 보는 영역은 반복 코드 초안 작성, 대안 탐색, 문서 요약, 테스트 케이스 아이디어 정리입니다. 반면 인증, 권한, 캐시, 사용자 데이터, DB 정합성처럼 보안과 아키텍처에 영향을 주는 부분은 AI의 제안을 그대로 적용하지 않고 직접 검증해야 합니다.

검증 기준은 네 가지입니다. 요구사항을 실제로 만족하는지, 타입과 테스트로 검증 가능한지, 보안상 위험한 데이터 흐름이 없는지, 기존 코드베이스의 구조와 컨벤션을 깨지 않는지입니다.

예를 들어 React 렌더링 문제에서 AI가 React.memo()를 제안하더라도, 실제 원인이 상위 구독이라면 문제 위치가 맞지 않습니다. 그래서 저는 AI의 답을 결론으로 받아들이기보다 가설 중 하나로 보고, Profiler, Network, 테스트, 타입체크 같은 도구로 검증하는 방식을 선호합니다.

8. ItNew에서 기여할 수 있는 부분

제가 바로 기여할 수 있는 부분은 세 가지입니다.

첫째, React·Next.js 기반 화면에서 렌더링과 초기 로딩 병목을 측정하고 개선하는 일입니다. UNIBUSK에서 폼 렌더링, Code Splitting, Hydration Pattern을 직접 측정하고 적용한 경험이 있습니다.

둘째, API와 UI 상태의 경계를 명확히 나누는 일입니다. 서버 상태, 클라이언트 상태, 폼 상태를 구분하고 TanStack Query, Zustand, React Hook Form을 각각 목적에 맞게 사용한 경험이 있습니다.

셋째, 팀이 유지할 수 있는 구조와 문서를 만드는 일입니다. Dessert Front Dashboard에서 모노레포, 공용 UI 패키지, FSD 컨벤션, 작업 파이프라인을 정리한 경험이 있습니다.

Java 또는 Kotlin 기반 Spring Boot를 실무 프로젝트의 주 스택으로 사용한 경험은 제한적입니다. 다만 백엔드 구조 자체를 처음 접하는 상태는 아니고, Spring Boot 기초 강의를 통해 IoC/DI, 어노테이션 기반 구성, AOP를 통한 횡단 관심사 분리 같은 핵심 개념을 학습했습니다.

이후 Real World 프로젝트에서는 NestJS로 Controller, Service, Repository의 책임을 나누고, Service를 직접 생성하지 않고 DI 컨테이너를 통해 주입받는 구조로 서버를 설계했습니다. Spring Boot의 Bean 생명주기, JPA, 트랜잭션 전파, Spring Security 같은 생태계 세부 경험은 보완해야 하지만, 계층 분리, DI 중심 설계, REST API, RDBMS 기반 데이터 모델링 경험을 바탕으로 팀의 Spring Boot 코드베이스를 빠르게 읽고 연결해 나가겠습니다.

9. 협업 및 갈등 해결

Q1. 다른 직군과 의견 충돌이 발생했던 경험이 있나요? 어떻게 해결했나요?

UNIBUSK에서 공연 등록 폼을 설계할 때, 사용자가 한 번에 모든 정보를 입력하는 방식과 단계별로 나눠 입력하는 방식 사이에서 논의가 있었습니다. 기획 측면에서는 입력 흐름을 단순하게 유지하고 싶었고, 개발 측면에서는 공연 정보, 장소, 이미지, 팀 정보처럼 상태의 성격이 달라 한 화면에서 모두 관리하면 검증과 상태 복구가 복잡해질 수 있다고 봤습니다.

저는 먼저 제 의견을 바로 설득하려고 하기보다, 기획자가 중요하게 보는 지점과 개발에서 우려하는 지점을 나눠서 이야기했습니다. 기획 쪽에서는 사용자가 복잡하게 느끼지 않는 흐름이 중요했고, 개발 쪽에서는 이전 단계로 돌아가거나 중간에 이탈했을 때 입력값을 어떻게 유지할지가 중요했습니다.

그래서 논의의 기준을 "어느 방식이 더 좋은가"가 아니라 "사용자가 공연 등록을 끝까지 완료하려면 어떤 정보가 언제 유지되어야 하는가"로 바꿨습니다. 이 기준으로 단계별 입력 흐름은 유지하되, 이전 단계 이동과 입력값 유지가 필요한 조건을 함께 정리했습니다. 이후 기술적으로는 현재 입력값, 단계 간 스냅샷, 서버 데이터를 분리해 구현했습니다.

그 결과 기획 의도였던 단계별 입력 흐름을 유지하면서도 개발 측면의 상태 관리 리스크를 줄일 수 있었습니다. 이 경험을 통해 직군 간 의견 차이는 누가 맞는지를 가르는 문제가 아니라, 각자가 중요하게 보는 제약을 드러내고 사용자 흐름 기준으로 다시 합의하는 과정이라고 느꼈습니다.

Q2. 기획자나 디자이너를 설득할 때 기술적인 내용을 어떤 방식으로 풀어서 설명하나요?

Dessert Front Dashboard에서 초기 디자인 시안을 프론트엔드에 적용할 때 비슷한 경험이 있었습니다. 초기 시안에서는 typography, color, spacing 값이 페이지마다 개별적으로 지정되어 있었고, 같은 역할의 텍스트나 버튼도 조금씩 다른 값이 사용되고 있었습니다.

개발 입장에서는 이 상태로 구현하면 Tailwind 설정이나 공통 스타일로 재사용하기 어렵고, 페이지가 늘어날수록 같은 UI를 매번 따로 맞춰야 했습니다. 다만 디자이너에게 "Tailwind config로 관리하기 어렵습니다"라고만 말하면 개발자의 내부 문제처럼 들릴 수 있다고 생각했습니다.

그래서 저는 이를 "같은 의미의 제목이나 버튼이 화면마다 조금씩 다르면 사용자 입장에서도 일관성이 떨어질 수 있고, 이후 스타일을 수정할 때 모든 페이지를 각각 고쳐야 해서 디자인 일관성을 유지하기 어렵다"는 식으로 설명했습니다.

그 후 typography, color, spacing을 역할 기준으로 정리해 공통 스타일로 재사용할 수 있게 맞추는 방향을 제안했습니다. 이 경험을 통해 기술적인 제약을 설명할 때는 도구 이름보다, 디자인 일관성, 수정 비용, 사용자 인지 관점으로 바꿔 말하는 것이 더 효과적이라고 느꼈습니다.

Q3. 요구사항이 모호할 때 어떻게 대응하나요?

요구사항이 모호할 때는 바로 구현부터 시작하지 않고, 먼저 사용자의 행동 흐름과 예외 상황을 질문으로 정리합니다. 예를 들어 “공연 등록을 할 수 있어야 한다”는 요구만 있으면 정상 등록뿐 아니라 중간 이탈, 이전 단계 이동, 필수값 누락, 서버 실패, 이미지 업로드 실패 같은 조건을 함께 확인해야 합니다.

그다음 기획자나 디자이너에게 “이 경우 사용자가 어떤 상태를 기대하나요?”, “저장되지 않은 입력값은 유지되어야 하나요?”, “실패 시 다시 시도할 수 있어야 하나요?”처럼 판단이 필요한 질문을 구체적으로 드립니다. 이렇게 해야 개발자가 임의로 정책을 정하지 않고, 제품 의도에 맞는 구현을 할 수 있다고 생각합니다.

면접에서 이 질문을 받으면, 저는 요구사항을 기술 작업으로 바로 변환하기보다 먼저 상태, 예외, 우선순위를 정리한다고 답하겠습니다. 특히 ItNew처럼 여러 직군이 함께 서비스를 만드는 환경에서는 요구사항의 빈칸을 조용히 추측해서 채우는 것보다, 빠르게 드러내고 합의하는 방식이 중요하다고 생각합니다.

Q4. 디자이너와 구현 가능성 또는 일정 때문에 의견이 다르면 어떻게 하나요?

먼저 디자인 의도를 확인합니다. 특정 UI가 단순히 예쁘기 때문에 들어간 것인지, 사용자의 실수를 줄이거나 정보를 더 잘 이해시키기 위한 의도인지에 따라 대안이 달라지기 때문입니다.

그다음 구현 비용과 리스크를 구체적으로 설명합니다. “어렵습니다”라고 말하기보다, 어떤 부분이 비용을 만드는지, 일정 안에서 가능한 대안은 무엇인지, 이번 배포에서 반드시 필요한 범위와 이후 개선 가능한 범위를 나눠 이야기하려고 합니다.

예를 들어 복잡한 애니메이션이나 상호작용이 일정상 부담된다면, 첫 배포에서는 핵심 정보 구조와 접근성을 유지한 정적 UI로 구현하고, 이후 사용자 반응이나 일정에 따라 인터랙션을 추가하는 방식을 제안할 수 있습니다. 중요한 것은 디자인을 줄이는 것이 아니라, 디자인 의도를 해치지 않는 현실적인 구현 범위를 함께 찾는 것이라고 생각합니다.

Q5. 기획자나 PO가 빠른 출시를 요구하지만 기술 부채가 우려되면 어떻게 설득하나요?

먼저 출시 목표 자체를 반대하지 않습니다. 일정이 중요한 상황에서는 모든 구조를 이상적으로 만들 수 없기 때문에, 사용자에게 바로 영향을 주는 핵심 경로와 나중에 갚아도 되는 부채를 구분해야 한다고 생각합니다.

설득할 때는 “이 구조는 안 좋습니다”처럼 추상적으로 말하지 않고, 어떤 위험이 언제 비용으로 돌아오는지 설명합니다. 예를 들어 API 응답 타입이 느슨하거나 상태 소유권이 불명확하면 지금은 빨라 보여도 이후 기능 추가 때 같은 데이터를 여러 곳에서 수정해야 하고, 버그 원인을 추적하기 어려워질 수 있습니다.

현실적인 방식은 최소한의 안전장치를 남기는 것입니다. 타입 정의, 에러 처리, 핵심 상태의 소유권, TODO가 아닌 후속 이슈 기록처럼 나중에 팀이 이어받을 수 있는 흔적은 남기고, 나머지는 일정에 맞춰 범위를 줄입니다. 빠른 출시와 유지보수성은 항상 대립하는 것이 아니라, 지금 반드시 지켜야 할 기준을 정하는 문제라고 생각합니다.

Q6. 시간이 촉박한 상황에서는 무엇을 최우선으로 하나요?

시간이 촉박할수록 먼저 사용자가 반드시 통과해야 하는 핵심 흐름을 확인합니다. 모든 기능을 같은 중요도로 보지 않고, 결제, 주문, 인증, 등록처럼 실패하면 사용자가 목적을 달성하지 못하는 경로를 우선합니다.

그다음 반드시 지켜야 할 안전장치와 줄일 수 있는 범위를 나눕니다. 예를 들어 타입 정의, 필수 에러 처리, 권한 검증, 데이터 정합성처럼 장애나 잘못된 데이터로 이어질 수 있는 부분은 최소한으로라도 지켜야 합니다. 반면 부가적인 인터랙션, 고급 필터, 세부 애니메이션, 내부 구조 개선 일부는 후속 작업으로 분리할 수 있습니다.

면접에서 답한다면, 저는 "일정을 맞추기 위해 품질을 포기한다"가 아니라 "사용자와 서비스에 직접 영향을 주는 핵심 품질을 먼저 지키고, 나머지는 범위를 조정한다"고 말하겠습니다. 그리고 미룬 작업은 기억에 의존하지 않고 후속 이슈나 문서로 남겨 팀이 다시 이어갈 수 있게 하겠습니다.

꼬리 질문: 실제 프로젝트에서 이런 판단을 해본 적이 있나요?

UNIBUSK에서 비슷한 경험이 있었습니다. MVP를 6주 안에 기획, 디자인, 개발까지 진행해야 했기 때문에 모든 기능을 같은 깊이로 구현하기는 어려웠습니다. 그래서 먼저 사용자가 서비스를 사용하는 데 반드시 필요한 핵심 흐름을 기준으로 우선순위를 정했습니다.

예를 들어 사용자가 공연을 탐색하고, 공연 상세를 확인하고, 공연을 등록할 수 있는 흐름을 우선했습니다. 공연 등록에서는 입력값 유지, 필수값 검증, 서버에서 받아오는 데이터와 사용자가 입력 중인 상태의 분리를 먼저 신경 썼습니다. 이 흐름이 불안정하면 부가 기능이 있어도 사용자가 실제 목적을 달성하기 어렵다고 판단했기 때문입니다.

반면 핵심 흐름을 해치지 않는 세부 인터랙션이나 내부 구조 개선은 MVP 이후에도 개선할 수 있는 영역으로 봤습니다. 이 경험을 통해 시간이 촉박할수록 더 많은 것을 한 번에 하려 하기보다, 사용자 목적 달성에 직접 연결되는 기능과 최소 안전장치를 먼저 지키는 것이 중요하다고 느꼈습니다.

Q7. 팀원이 본인의 기술 제안에 동의하지 않으면 어떻게 하나요?

먼저 제 제안이 실제 문제를 해결하는지 다시 확인합니다. 익숙한 기술이나 제가 선호하는 구조라는 이유만으로 설득하려 하면 팀 입장에서는 부담이 될 수 있기 때문입니다.

UNIBUSK에서 Next.js 버전 선택을 두고 의견이 달랐던 경험이 있습니다. 팀원은 최신 버전인 Next.js 16을 사용하고 싶어 했지만, 프로젝트 진행 당시 우리가 고려하던 Cloudflare 배포 어댑터에서 해당 버전 지원이 충분하지 않았습니다.

저는 단순히 "최신 버전이라 위험하다"고 말하기보다, 우리 프로젝트가 organization 단위로 배포되어야 했고 비용 제약도 있었기 때문에 배포 방식까지 함께 고려해야 한다고 설명했습니다. 만약 최신 버전을 선택해 Cloudflare 배포 경로가 막히면 다른 배포 환경을 선택해야 하고, 그에 따른 비용이나 설정 부담이 커질 수 있다고 이야기했습니다.

그래서 버전 선택 기준을 "최신인가"가 아니라 "현재 팀이 안정적으로 개발하고, 비용 안에서 배포까지 완료할 수 있는가"로 바꿔 논의했습니다. 이 경험을 통해 기술 선택은 개인의 선호가 아니라 안정성, 호환성, 배포 비용, 팀의 운영 가능성을 함께 보고 결정해야 한다고 느꼈습니다.

Q8. 협업에서 가장 중요하게 보는 기준은 무엇인가요?

제가 협업에서 가장 중요하게 보는 기준은 데드라인 안에서 팀이 같은 우선순위를 보고 움직이게 만드는 것입니다.

기획자, 디자이너, 개발자는 각각 중요하게 생각하는 기준이 다릅니다. 기획자는 사용자 가치와 출시 일정을 보고, 디자이너는 사용성과 일관성을 보고, 개발자는 구현 가능성과 유지보수 리스크를 봅니다. 이 기준이 정리되지 않으면 각자 열심히 일해도 중요한 작업의 순서가 달라질 수 있다고 생각합니다.

그래서 저는 협업할 때 먼저 이번 배포에서 반드시 지켜야 할 핵심 흐름이 무엇인지 확인하려고 합니다. UNIBUSK처럼 6주 안에 MVP를 만들어야 하는 상황에서는 공연 탐색, 상세 확인, 공연 등록처럼 사용자가 목적을 달성하는 핵심 흐름을 우선했고, 세부 인터랙션이나 후속 개선 가능한 부분은 범위를 조정했습니다.

이 과정에서 중요한 것은 단순히 제 의견을 말하는 것이 아니라, 왜 이 작업이 먼저인지, 미루는 작업은 어떤 영향이 있는지, 후속으로 어떻게 처리할지를 팀이 이해할 수 있게 공유하는 것이라고 생각합니다.

10. 역질문 후보

1. ItNew에서 현재 가장 집중하고 있는 서비스가 ERLN, MemoryMint, MinTrigger 중 어디인지, 신규 입사자가 먼저 투입될 가능성이 높은 제품은 무엇인지 궁금합니다.
2. 공고에 AI가 생성한 코드와 설계의 품질·보안·아키텍처 적합성 검토가 언급되어 있었는데, 실제 팀에서는 Claude Code나 Cursor를 어떤 워크플로우로 사용하고 계신지 궁금합니다.
3. 프론트엔드 기준으로 현재 가장 개선하고 싶은 품질 이슈가 초기 로딩, 상태 관리, 테스트, 디자인 시스템, API 연동 중 어디에 가까운지 궁금합니다.
4. 초·중급 개발자에게 입사 후 1~3개월 안에 가장 기대하는 역할은 기능 구현, 기존 코드 품질 개선, 문서화, AI 도구 활용 방식 정립 중 어디에 가까운지 궁금합니다.

11. 답변 시 주의할 점

• Spring Boot 실무 경험이 있는 것처럼 말하지 않습니다.
• AI 도구를 “잘 사용합니다”보다 “무엇을 위임하고 어떻게 검증하는지”로 설명합니다.
• 성능 수치를 말할 때 측정 도구와 검증 범위를 함께 말합니다.
• ItNew의 회사 설명은 확인한 공개 자료 범위에서만 말합니다.
• 프로젝트 수치를 과장하지 않고, 한계와 추가 검증 방법을 함께 말합니다.

참고한 공개 자료

• ItNew 원티드 채용공고: https://www.wanted.co.kr/wd/358179
• ItNew 공식 홈페이지: https://itnewcorp.com/
• ItNew 원티드 기업정보: https://www.wanted.co.kr/company/41725
• THE VC ItNew 기업정보: https://thevc.kr/itnew