AI는 내가 비효율적이라고 했고, 리크루터는 듣지 말라 했지만, 나는 결국 반대편에 앉았다.

출처: Dev.to

이 이야기는 “비효율적”이라고 라벨링된 엔지니어에 관한 이야기입니다 — 시스템은 그가 충분히 좋지 않다고 판단했고, 경영진은 오직 그 시스템만을 보았습니다. 그는 두 달 동안 누가 틀렸는지 증명하려 애썼고, 결국 클라이언트 측 검토 패널에 서게 되었습니다.
실제 커뮤니티 멤버가 공유한 경험을 바탕으로 한 이야기입니다. 비슷한 이야기가 있다면 연락 주세요. 다음 이야기는 여러분일 수도 있습니다.
수요일, 오전 10:14.

저는 7년 전에 작성된 저장 프로시저와 씨름하고 있었습니다. 떠난 사람이 남긴 위키 페이지에는 딱 한 줄의 문서만 있었습니다:

“이 트리거의 로직? 코드를 보세요. 기억이 안 나요.”

Slack이 울렸습니다. 전사 알림이 도착했습니다:
[System Notification] AI Estimation Engine v1.0 is now live

채널이 폭발했습니다.

Mike (프론트엔드): “방금 써봤어요. ‘로그인 페이지 스타일 업데이트’ — 0.5일로 추정됐네요. 제가 PM과 3일 동안 주고받던 그 일 기억나요? AI는 그걸 오후 한 번에 끝낸다고 생각해요.”

Dave (백엔드): “내 데이터 마이그레이션 — ‘데이터베이스 마이그레이션, 두 외부 시스템 통합.’ AI가 2일이라고 하네요. 맞아요.”

Alex: “누가 LinkedIn을 업데이트하고 있나요? 🙋”

열두 명이 손을 들었습니다.

저는 손을 들지 않았습니다. 시스템을 열고 작업을 입력했습니다:

Payment module — Fix historical data reconciliation (7년 된 저장 프로시저, 원 개발자는 퇴사, 문서 부족)

시스템이 반환했습니다:

# AI Estimation Engine - API Response
# POST /api/v1/estimate
# Request:
{
  "task": "Fix historical data reconciliation",
  "repo": "payment-module",
  "context": "7-year-old stored procedure, no docs, dev left"
}
# Response:
{
  "estimated_days": 1.5,
  "confidence": "high",
  "model": "estimate-engine-v1",
  "training_data_coverage": "95%"
}

스크린을 5초간 바라보며 생각했습니다. 농담이냐고요?

채널에 답변하지 않았습니다. 대신 estimation-log 라는 개인 저장소를 만들고 첫 번째 항목을 기록했습니다:

2026-03-12 | P-4103 | Payment module | AI: 1.5d | Actual: — | Tracking

월말이 되자 성과 이메일이 도착했습니다.

Subject: Your Monthly Efficiency Score — Needs Attention

Your AI estimation efficiency score: 39%
84%

그 숫자를 오래도록 바라보았습니다. 팀 내 최저점이었습니다.

매니저와 리뷰를 진행하면서 제 기록을 제시했습니다.

“제가 맡은 작업을 보세요 — 결제 모듈, 데이터 마이그레이션, 레거시 시스템 통합. 코드베이스는 2019년 것이고, 원 개발자는 떠났으며, 단위 테스트 커버리지는 5% 미만입니다. AI는 전혀 다른 프로젝트를 학습한 것이죠.”

매니저는 제 기록을 보지 않았습니다.

“시스템이 말하길 당신은 기준에 못 미친다고 합니다.”

저는 시스템이 레거시 복잡성을 고려하지 않는다며 반박했습니다. 매니저는 시스템이 95% 정확하다고 주장했습니다.

“그 95%는 최신 코드, 테스트 커버리지, 문서가 충분한 프로젝트에 대한 것입니다. 제 작업은 전혀 해당되지 않아요.”

매니저는 “회사 표준은 시스템이 말하는 대로입니다. 그것이 우리 기준입니다.” 라고 답했습니다.

다투지는 않았습니다. 책상으로 돌아가 estimation-log에 또 한 줄을 추가했습니다:

2026-03-26 | P-4162 | Payment module hotfix | AI: 1d | Actual: 5d | 그들은 숫자만 보니깐 기록해 둡니다

그 뒤로 AI 추정치가 현실과 맞지 않을 때마다 기록을 남겼습니다. 이는 반항이 아니라, 얼마나 자주 맞고 틀리는지, 어디서 부서지는지를 알고 싶었기 때문이었습니다.

시간이 지나면서 이것은 습관이 되었습니다. 어느 날 밤, 67개의 항목을 셌습니다. 두 달 동안의 기록이었습니다.

금요일 밤, 9:30 PM

AI가 “2시간”이라고 추정한 데이터 마이그레이션을 고치고 있었습니다. 문제는 6년 전 퇴사한 사람이 남긴 ETL 스크립트에 있었습니다. 원 주석은 이렇게 적혀 있었습니다:

# Why is this here? — I don't know. It works.
# — by Frank, 2020

휴대폰이 진동했습니다. LinkedIn 알림.

Lydia (리크루터):

제가 답장했습니다:

“아마도 잘못 찾으신 것 같아요 — 저는 팀에서 가장 비효율적인 엔지니어로 평가받았거든요.”

Lydia는 스크린샷을 보냈습니다. 제 GitHub: 13개의 레포, 메인에 머지된 PR 3개, 400+ 스타를 받은 오픈소스 프로젝트.

Lydia는 이렇게 적었습니다:

“시스템이 저를 잘못 측정한 게 아니라, 잘못된 대상을 측정하고 있었습니다.”

30초간 그 문장을 바라보았습니다. 그녀가 맞았습니다. 시스템이 저를 잘못 측정한 것이 아니라, 전혀 다른 것을 측정하고 있었던 겁니다.

ETL 터미널을 닫고 estimation-log를 열었습니다. 상위 항목들은 다음과 같습니다:

2026-05-30 | P-4817 | Compliance logging | AI: 1wk | Actual: — | Project hasn't started yet
2026-05-23 | P-4782 | Cross-team data bridge | AI: 5d | Actual: 23d | +360%
2026-05-16 | P-4749 | Payment module v2 fix | AI: 2d | Actual: 9d | AI says it's my fault

67개의 기록. 두 달간의 데이터. 아무도 몰랐던 레포에 쌓여 있었습니다.

Lydia에게 세 마디를 보냈습니다:

“언제 만나면 될까요?”

클라이언트 CEO가 직접 저를 인터뷰했습니다.

CEO: “우리는 Q3 리뷰에 들어갈 벤더들을 검토하고 있습니다. 실제 숫자를 말할 수 있는 사람, 혹은 허위로 포장된 숫자를 구분할 수 있는 사람이 필요합니다. 모두 3개월 납기를 제시하고 있는데, 어느 쪽이 가능한지 알려 주세요.”

저: “제가 할 수 있습니다.”

그는 제 이전 회사를 묻지 않았고, 저도 언급하지 않았습니다.

3일 뒤 제안이 들어왔습니다. 연봉은 두 배가 되었고, 새로운 직함은 Client‑Side Technical Review Lead였습니다.

첫 출근 날, 이메일을 열었습니다. 첫 메시지는 이렇게 적혀 있었습니다:

Q3 Vendor Review. Next Wednesday.

클릭했더니 첫 번째 행에 제 이전 회사가 보였습니다. 담당자는 전 매니저, 입찰 금액은 $4.6M.

창을 닫지 않고 터미널을 열었습니다:

# curl -s https://git.oldcompany.com/api/v3/repos/estimation/readme
#
# Returns 200.

AI를 배포한 날부터 공개된 읽기 전용 접근 권한이 그대로 남아 있었습니다.

터미널을 닫고 이메일을