기술 역량 평가에서 통과하는 코드의 특징

1. "기능 구현 다 했는데 왜 탈락이죠?"

기술 역량 평가를 진행하면서 가장 많이 듣는 질문입니다. "요구사항 다 구현했고, 버그도 없는데 왜 탈락인가요?"

냉정하게 말하면, 기능 구현은 기본(Baseline)입니다. 기술 과제는 "네가 이걸 만들 수 있니?"를 묻는 게 아니라, "너랑 같이 일해도 괜찮겠니?"를 묻는 과정이기 때문입니다.

오늘은 평가자 입장에서 "이 사람은 무조건 합류시키고 싶다"와 "이 사람은 좀..."이 갈리는 결정적 포인트들을 정리해 드립니다.

---

1.5. 흔한 실수 - 오버 엔지니어링 (Over-engineering)

주니어 개발자들이 가장 많이 하는 실수입니다. "나 이만큼 아키텍처 잘 알아!"를 뽐내고 싶어서, 투두 리스트 하나 만드는데 Clean Architecture, DDD, RxJS를 다 때려넣습니다.

평가자의 생각: "이 사람, 실제로 간단한 기능 하나 만드는 데 3일 걸리겠네."

Best Practice:

• 과제의 규모에 맞는 아키텍처를 선정하세요.
• "원래는 이렇게 해야 하지만, 과제 규모상 MVP 패턴으로 했습니다"라고 주석이나 문서에 적는 것이 백배 낫습니다.

---

2. 과제 전형 (Take-home Assignment) - 코드가 아니라 문서를 본다

많은 지원자가 App.js를 얼마나 예쁘게 짰는지에 목숨을 겁니다. 하지만 평가자가 가장 먼저 보는 파일은 README.md입니다.

탈락하는 유형:

• 실행 방법(npm start)조차 안 적혀 있음.
• "그냥 짜봤습니다" 식의 무미건조한 커밋 메시지 (update code).
• 환경 변수(.env) 설정법이 누락되어 실행 불가.

합격하는 유형:

• 실행 가이드: 한 번의 복붙으로 실행되게 해둠.
• 기술적 의사결정: "왜 Redux 대신 Zustand를 썼는지", "왜 폴더 구조를 이렇게 잡았는지"를 문서화함. 단순 구현보다 설계의 근거가 훨씬 중요합니다.
• 트러블슈팅: 과제를 하다 막힌 부분과 어떻게 해결했는지(혹은 못 했는지)를 솔직하게 적음.

"코드는 혼자 짜지만, 제품은 같이 만듭니다." 문서를 못 쓰는 개발자와 일하고 싶은 사람은 없습니다.

문서화 예시 (Good README.md)

# Project Name

## 실행 방법
\`\`\`bash
cp .env.example .env
npm install
npm run dev
\`\`\`

## 기술적 의사결정
- **Zustand 사용 이유:** Redux는 보일러플레이트가 너무 많고, Context API는 렌더링 최적화가 어렵습니다. 이 프로젝트 규모에서는 Zustand가 가장 효율적이라 판단했습니다.
- **폴더 구조:** 기능(Feature) 단위로 분리하여 응집도를 높였습니다.

## 트러블슈팅
- **문제:** API Rate Limit에 걸림.
- **해결:** 로컬 캐싱을 적용하여 API 호출 횟수를 줄임.

---

2.5. 라이브 코딩 기술 평가의 비밀 (Live Coding)

과제 전형을 통과하면 보통 라이브 코딩을 합니다. 여기서 중요한 건 "문제를 푸는 것"보다 "사고 과정(Think Aloud)을 보여주는 것"입니다.

꿀팁:

1. 입 다물고 코딩하지 마세요. "지금 배열을 순회하려고 하는데요..."라고 계속 중얼거리세요.
2. 질문하세요. "입력값의 범위는 어떻게 되나요?" "엣지 케이스는 무시해도 되나요?"
3. 막히면 도움을 요청하세요. 리뷰어는 당신을 탈락시키려는 저승사자가 아니라, 미래의 동료입니다. "이 부분에서 막혔는데 힌트 좀 주실 수 있나요?"는 감점 요인이 아닙니다.

---

3. 라이브 코딩 (Live Coding) - 침묵은 금이 아니라 독이다

라이브 코딩의 목적은 '문제를 푸는 것'이 아니라 '푸는 과정을 보여주는 것'입니다.

탈락하는 유형:

• 문제 받자마자 아무 말 없이 키보드부터 두드림. (30분 뒤에 엉뚱한 거 만들고 있음)
• 막혔을 때 힌트를 줘도 "아뇨 제가 할게요"라며 고집 피움.

합격하는 유형:

• 질문부터 함: "입력값의 범위는 뭔가요?", "엣지 케이스 처리는 필요한가요?" 하며 요구사항을 명확히 함.
• 말로 코딩함: "지금은 O(N^2)으로 먼저 짜고, 나중에 최적화하겠습니다"라고 자신의 의도를 중계함.
• 힌트를 잘 받아먹음: 리뷰어의 힌트를 "같이 문제를 해결하는 시그널"로 받아들임.

평가자는 '슈퍼 코더'를 뽑는 게 아니라 '대화가 통하는 동료'를 뽑고 있습니다.

---

4. 시스템 설계 (System Design) - 정답은 없다, 근거만 있을 뿐

"유튜브를 설계해 보세요." 이 질문에 정답이 있을까요? 없습니다.

탈락하는 유형:

• 특정 기술 스택 하나만 고집함. ("무조건 NoSQL 써야 해요. 요즘 힙하거든요.")
• 확장성(Scalability) 고려 없이 기능만 나열함.

합격하는 유형:

• 트레이드오프(Trade-off)를 논함: "SQL은 정합성이 좋지만 확장이 어렵고, NoSQL은 확장은 쉽지만 정합성 관리가 필요합니다. 이 시스템은 조회 위주니까 NoSQL을 선택하겠습니다."
• 가정(Assumption)을 세움: "DAU가 1,000만 명이라고 가정하고 설계하겠습니다."

모든 기술 선택에는 장단점이 있습니다. 그걸 알고 선택하는지와 모르고 유행따라 선택하는지는 천지차이입니다.

---

4.5. 리뷰어를 내 편으로 만드는 대화법

기술 평가는 "나 혼자 잘났음"을 뽐내는 자리가 아닙니다. 리뷰어를 "내 동료"로 만드는 과정입니다.

1. 두괄식 답변: "결론부터 말씀드리면 X입니다. 왜냐하면 Y이기 때문입니다." (리뷰어의 피로를 줄여줍니다.)
2. 모르면 모른다고 하기: "그 부분은 정확히 모르겠습니다. 하지만 제 추측으로는..." (솔직함이 낫습니다. 아는 척하다 걸리면 치명상입니다.)
3. 역질문: "팀에서는 코드 리뷰 문화를 어떻게 유지하고 계신가요?" (관심도를 보여주는 가장 좋은 방법입니다.)

---

5. 마무리 - 기술 역량 평가는 시험이 아니라 협업 시뮬레이션이다

기술 평가를 '정답을 맞춰야 하는 시험'이라고 생각하면 긴장되고 굳어버립니다. 하지만 기술 평가는 "우리가 서로 기술적으로 잘 맞을까?"를 확인하는 협업 시뮬레이션에 가깝습니다.

1. 과제: 내 코딩 스타일과 문서화 능력을 매력적으로 어필하세요.
2. 라이브 코딩: 내가 얼마나 대화가 잘 통하는 사람인지 보여주세요.
3. 시스템 설계: 내가 얼마나 깊게 고민해봤는지(Insight)를 뽐내세요.

탈락했다고 해서 당신이 실력 없는 개발자인 건 아닙니다. 그저 그 팀의 핏(Fit)과 안 맞았을 뿐입니다. 오늘도 git commit을 날리는 여러분을 응원합니다.

---

---