AI를 쓰는 엔지니어인가요, AI에도 불구하고 일하는 엔지니어인가요?

같은 도구, 다른 결과물

올해 들어 두 부류의 엔지니어를 가까이서 봤어요. 격차가 눈에 띄게 벌어지고 있습니다.

둘 다 ChatGPT를 켜놓고 일합니다. 둘 다 Claude Pro를 결제했고, Cursor도 써봤어요. 겉으로 보면 모두 ‘AI를 쓰는 엔지니어’예요. 그런데 한쪽은 같은 시간에 결과물을 세 배로 뽑아내며 승진하고, 다른 쪽은 소진되어 있어요. 조용히 “AI는 아직 멀었다”라고 결론 내리면서요.

차이는 구독 목록이 아니에요. 바로 자세입니다.

업계가 잘못 묻고 있는 질문

요즘 묻는 질문은 대개 여기에 머무릅니다. “무슨 AI 도구 쓰세요?” “AI 중심으로 일하세요?” “최신 모델 써보셨어요?”

겉으론 그럴듯하지만 실적과는 잘 안 이어져요. 제 주변에도 모든 유료 구독을 다 쓰면서도 밤 11시에 보일러플레이트를 직접 치는 사람이 있어요. “프로덕션 코드는 AI를 못 믿겠다”는 이유로요. 반대로 6개월 전에 처음 Claude Pro를 결제했는데 이미 주간 업무의 40%를 자동화한 사람도 있습니다.

도구는 비슷한데 결과는 완전히 달라요.

2026년에 누가 앞설지 가르는 진짜 질문은 이겁니다. AI를 ‘관리’하나요, 아니면 그냥 ‘참고’ 쓰나요?

참고 쓰는 모습은 이렇습니다. 프롬프트를 던지고, 70%짜리 답을 받고, 한숨 쉬고, 스스로 다시 씁니다. 그걸로 시간을 아꼈다고 스스로 위안하지만 동시에 “역시 AI는 아직 멀었어”라는 선입견을 굳히죠. 이 과정을 일주일에 수십 번 반복하면서 ‘AI 도입’이라고 부릅니다.

관리하는 모습은 다릅니다. 모델을 지난주에 입사한 신입 엔지니어처럼 대합니다. 똑똑하고 빠르지만 우리 코드베이스 맥락은 0, 클라이언트가 진짜 원하는 건 0, 지난 아키텍처 결정의 배경도 모릅니다. 그래서 온보딩을 시켜요. CLAUDE.md를 건넵니다. 규제 PDF를 읽힙니다. “좋은 결과물의 기준”을 명세로 줍니다. 그리고 실패하면 신입을 탓하지 않아요. 온보딩을 고칩니다.

채용하고, 해고하고, 워크플로우를 소유하라

작은 팀을 키워본 창업자라면 압니다. 좋은 결과물은 똑똑한 사람만 뽑는다고 나오지 않아요. 그 사람이 일하는 ‘워크플로우’를 설계할 때 비로소 나옵니다. 워크플로우가 곧 제품이고, 사람은 실행자예요.

AI를 전제로 일하는 엔지니어들은 이 교훈을 더 일찍 체화했을 뿐이에요.

Pante나 BuildChain을 다룰 때 저는 ‘Claude Code를 쓴다’고 생각하지 않습니다. 가상의 작은 팀을 돌립니다. 그 안에 Claude Code는 3~4개 역할 중 하나예요. 기획, 구현, 리뷰, 때로는 조사 담당. 각 역할마다 시스템 지시문이 있고, 컨텍스트 할당량이 있고, ‘완료의 정의’가 분명합니다. 결과가 어긋나면 프롬프트를 다시 돌리지 않아요. 역할 자체를 다시 설계합니다.

이게 채용/해고의 근육입니다. AI 에이전트를 ‘역할 자리’에 채용합니다. 직무기술서를 줘요. 두 번 돌려도 성과가 없으면 해고합니다. 모델을 바꾸거나, 지시문을 바꾸거나, 범위를 좁혀요. 정 들었다고 부진한 에이전트를 계속 끌고 가지 않습니다. 신입을 재배치하듯 같은 원칙으로 움직여요.

반대로 지는 쪽은 AI를 매직 8볼처럼 다룹니다. 흔들고, 답 보고, 화내고, 또 흔듭니다. 역할이 없고, ‘역할 자리’도 없고, 워크플로우가 없어요. 채팅창만 있고 흐름은 없습니다.

한국 빌더의 진짜 시험대 — 도메인이 들어왔을 때

차이는 도메인이 끼어드는 순간 잔인하게 드러납니다. 제 일상도 이 지점이에요.

건설 BIM 엔지니어이거나, 토스 같은 핀테크에서 사기 탐지 룰을 설계하거나, 당근의 커뮤니티 모더레이션 파이프라인을 운영하거나, 쿠팡의 물류 라우팅을 다루고 있다면 아실 겁니다. 범용 조언은 현업에 닿는 순간 깨집니다. ChatGPT는 협력업체에 보낼 정중한 메일은 잘 씁니다. 하지만 400페이지짜리 시방서 PDF를 읽고 구조도면과 충돌하는 조항을 찾아내진 못해요. 클래시 리포트를 보고 다음 주 콘크리트 타설을 지연시킬 12개 항목을 우선순위로 정하지도 못합니다.

‘AI에도 불구하고 일하는 엔지니어’는 여기서 결론을 내립니다. “진짜 엔지니어링에는 아직 안 돼.”

‘AI를 쓰는 엔지니어’는 다르게 정리합니다. “기본 상태 그대로는 안 돼. 그래서 준비된 상태로 만드는 워크플로우를 내가 짜야 해.”

결론이 다르면 커리어도 갈립니다.

두 번째 엔지니어는 곧바로 컨텍스트 시스템을 만듭니다. 프로젝트의 BIM 실행 계획을 모델에 주입하고, 국내 코드 개정안을 벡터 데이터베이스로 구성해요. Navisworks 내보내기 폴더를 감시해 충돌을 공종별로 분류하는 작은 에이전트를 붙입니다. 토스의 사기 탐지 팀이라면 룰 엔진과 LLM 분류기 사이의 인터페이스를 설계하고, 당근의 모더레이션 팀이라면 신고 패턴 → 사전 분류 → 휴먼 리뷰로 이어지는 파이프라인을 다듬습니다.

여기엔 로켓 사이언스가 없습니다. 전부 워크플로우 설계예요. 시니어 엔지니어가 해오던 그 기술을, 새로 온 신입에게 다시 적용하는 일입니다.

흥미로운 건 모델 자체가 아닙니다. 모델 주변에 당신이 짜놓은 워크플로우예요.

이번 주에 본인한테 돌려볼 세 가지 테스트

본인이 어느 쪽에 서 있는지 알고 싶다면 구독 목록은 접어두세요. 이번 주 업무에 이 세 가지를 바로 얹어 보세요.

1. 온보딩 테스트. 가장 자주 쓰는 AI 도구를 엽니다. 시스템 지시문, 프로젝트 파일, CLAUDE.md, 맞춤 지시문. 모델에게 ‘내가 누구고, 무슨 일을 하고, 좋은 결과물이 무엇인지’를 알려주는 장치가 있나요? 비어 있다면 아직 관리가 아닙니다. 그냥 참고 쓰는 중이에요.
2. 해고 테스트. 최근 30일 동안 성과가 없다는 근거로 모델이나 워크플로우를 중단하고 더 나은 것으로 교체한 적이 있나요? “새 도구 맛봤다”가 아니라, 측정된 이유로 폐기했는지요. 없다면 팀을 운영하는 게 아니라 도구를 모으는 겁니다.
3. 소유권 테스트. AI 결과가 틀렸을 때 첫 행동이 무엇인가요? “내가 다시 쓰자”면 여전히 병목입니다. “프롬프트를 바꾸자, 컨텍스트를 바꾸자, 역할을 다시 짜자”면 시스템을 설계하는 중이에요. 한쪽은 확장되고, 한쪽은 멈춥니다.

제가 존경하는 엔지니어들도 최소 하나는 걸립니다. 괜찮아요. 자세는 배울 수 있어요. 다만 가진 척하면 배울 수 없습니다.

이번 주 안에 할 일

이번 주에 반복하는 워크플로우 하나만 고르세요. 코드 리뷰든, 시방서 파싱이든, 물량 산출이든, 문서 작업이든. 제일 어려운 게 아니라 ‘제일 반복적인 것’으로요.

그리고 이렇게 해봅니다.

• 그 워크플로우를 다음 주 월요일 입사하는 신입에게 설명하듯 1페이지 브리프로 씁니다. 인풋, 아웃풋, ‘좋은 결과’의 모습, 흔한 실수 세 가지까지.
• 그 브리프를 Claude나 ChatGPT 등 사용하는 도구의 프로젝트 컨텍스트에 넣습니다. 시스템 지시문으로 만듭니다.
• 5일 동안 그 워크플로우를 AI와 함께 돌립니다. 어디서 실패하는지 기록합니다.
• 금요일에 브리프를 수정합니다. 프롬프트가 아니라 브리프를요. 도구를 튜닝하는 게 아니라 신입을 트레이닝한다고 생각하세요.

금요일쯤 불편한 사실 하나를 마주할 거예요. 브리프 쓰는 일이 그냥 하는 것보다 어렵다는 것. 그게 핵심입니다. 브리프가 곧 워크플로우고, 워크플로우가 곧 해자입니다. 경쟁자가 같은 구독을 결제해도 복사할 수 없는 유일한 자산이에요.

자세, 한 번 더

2026년에 이기는 엔지니어는 도구가 가장 많은 사람이 아닙니다. 어느 날 “AI의 사용자에서 AI의 관리자로 넘어가겠다”고 결심한 사람이에요.

이들은 모델을 역할에 채용합니다. 성과 없는 모델은 해고합니다. 모델이 일하는 워크플로우를 스스로 소유합니다. 그리고 누가 “AI 중심으로 일하세요?”라고 물으면 도구 목록이 아니라 지난주에 출시한 워크플로우로 답합니다.

이 글을 읽다 “나는 아직 반대쪽인 것 같은데”라는 걱정이 들었다면 잘된 겁니다. 올해 받을 수 있는 가장 값싼 신호예요. 해법은 새 구독이 아닙니다. 이번 주말 1페이지 브리프입니다. 책상 위에서 가장 지루한 그 워크플로우로요.

그게 자세입니다. 나머지는 다 연극이에요.