Macrohard 키노트를 듣고 - AI 시대 엔지니어로 살아남는다는 것

AWS Unicorn Day 2026 키노트 중 "30명의 AI 피어와 4명의 휴먼 엔지니어"라는 도발적인 제목의 세션이 있었다. Macrohard라는 팀이 어떻게 일하는지 공유하는 자리였는데, 듣는 내내 "지금 내가 하고 있는 일의 정의 자체를 다시 써야겠다"는 생각이 들었다. 세션 내용을 정리하기보다는, 내가 들으면서 무엇을 깨달았는지 남겨두려고 한다.

Macrohard라는 회사가 던지는 질문

Macrohard는 일론 머스크가 던진 농담에서 시작된 컨셉이다. 마이크로소프트 같은 소프트웨어 회사는 물리적 제품을 만들지 않으니, AI로 회사 전체를 시뮬레이션할 수 있지 않겠냐는 발상이다. Task Management, QA, 데이터 분석 — 소프트웨어 회사에서 사람이 하던 모든 일을 AI가 흉내낼 수 있다면, 회사는 어떻게 구성되어야 하는가.

발표자의 한마디가 머리에 박혔다.

"하반기에도 팀 내에서 소프트웨어를 직접 만들고 있다면, 뭔가 크게 잘못된 것이라고 생각한다."

처음엔 거부감이 들었다. "내가 코드를 쓰는 게 뭐가 잘못이지?" 그런데 이어진 설명을 들으면서 그 거부감이 사실 핵심을 가리키고 있었다.

가장 충격적이었던 한 줄: "성과 평가의 기준은 Process의 변화 가속도"

내가 평가받는 기준은 "무엇을 만들었느냐" 가 아니라 "내 일하는 방식 자체를 얼마나 빠르게 바꿔나갔느냐" 라는 것이다.

이게 왜 충격이었느냐 하면, 그동안 나는 무의식적으로 다음과 같이 생각하고 있었기 때문이다.

• 좋은 워크플로우를 발견하면 그걸 정착시킨다
• 익숙한 도구로 빠르게 일을 끝낸다
• 새 도구는 여유 있을 때 천천히 본다

이 세 가지가 전부 안티패턴 이라는 얘기였다. 도구가 매주 바뀌는 환경에서 "정착"이라는 단어는 곧 "정체"와 같은 의미가 된다.

지금 내가 Claude Code, Cursor, Codex CLI 중 무엇을 쓰는지는 사실 별로 중요하지 않다. 중요한 건 내가 이번 주에 작년의 나보다 일하는 방식을 얼마나 바꿨는지 다. 이걸 점검하는 루틴이 없었다는 걸 깨달았다.

"도구"가 아니라 "가치"가 먼저다

세션에서 반복해서 강조한 게 있다. 매일 새 도구가 쏟아지는 시대에 모든 걸 따라가는 건 불가능하니, "내가 달성하려는 일의 가치"를 먼저 정의해야 한다 는 것.

이 정의가 없으면 새 도구를 만날 때마다 overwhelmed된다. 가치를 모르니 어떤 도구가 내 일에 유효한지 판단할 수 없고, 결국 SNS에서 화제인 도구를 무작정 깔아보다 시간을 흘려보낸다. 익숙한 흐름이다.

발표자는 1:1 미팅을 다음 세 질문으로 시작한다고 했다.

1. 지금 내가 정의한 내 일은 무엇인가
2. 그것이 왜 임팩트가 있는가
3. 비용은 무엇이고, 병목은 어디인가

이 질문을 스스로에게 주 단위로 던지지 않으면, "AI 시대 엔지니어"라는 추상적 정체성에 휘둘리게 된다. 내 역할을 주 단위로 정의하고 점검한다 는 표현이 인상적이었는데, 분기/반기 단위로만 자기 일을 돌아보던 내 호흡이 너무 느리다는 걸 자각했다.

자동화보다 강력한 질문: "아예 안 해도 되는 일 아닌가?"

자동화를 잘하는 방법에 대한 얘기인 줄 알았는데, 발표자가 더 강조한 건 그 앞 단계였다.

지양해야 할 접근:

• "이 반복 작업을 자동화하자"
• "내 일을 AI에게 어떻게 위임하지?"

지향해야 할 접근:

• "왜 이게 반복되는가? 반복되는 것이 맞는가?"
• "그 일을 왜 하고 있지? 목적이 뭐고, 이점이 뭐고, 비용은 뭐지?"
• "아예 안 해도 되는 일 아닌가?"

자동화는 존재해야 마땅한 일을 더 잘하는 도구 인데, 그동안 나는 "있는 일을 어떻게든 자동화하는 것" 만으로 만족하고 있었다. 진짜 레버리지는 자동화 한 단계 위, "이 일 자체가 필요한가?"를 묻는 데 있다는 것을 새삼 깨달았다.

모두가 모든 것을 — 자동화 담당이 따로 없다

Macrohard에는 "AI 자동화 담당 엔지니어"가 따로 없다. 모든 개인에게 자신의 워크플로우를 자동화해야 하는 압박 이 직접적으로 주어진다. 프론트/백/인프라/디자인의 직무 경계도 두지 않는다.

이게 가능한 이유를 발표자는 이렇게 설명했다.

"AI가 개인의 역량 한계를 확장해주기 때문에 가능하다. 한 사람이 빠져도 서비스가 멈추지 않는 구조 (bus factor > 1)를 만들 수 있다."

내가 프론트엔드 개발자라는 정체성에 안주하는 동안, Macrohard의 비엔지니어는 이미 GitHub에 PR을 올리고 있다. 입사 첫 날에 비엔지니어도 GitHub 계정을 만들고 코드를 작성해본다는 얘기를 듣고 — 지금 회사에서 내가 "이건 엔지니어의 일이다"라고 그어놓은 선들이 사실 도구의 한계가 아니라 나의 정체성의 한계 였다는 걸 인정해야 했다.

도구에 정착하지 않는다 — Antifragility라는 개념

다른 사람이 잘 구축한 워크플로우를 그대로 가져다 쓰면 편하지만, 그렇게 하면 조직(과 개인)의 Antifragility가 무너진다. 도구가 바뀔 때마다 다시 배우는 비용보다, 잘못된 도구에 갇히는 비용이 더 크다는 얘기.

이 말이 와닿은 이유는, 그동안 내가 "잘 짜인 워크플로우를 그대로 따라가는 것"을 효율로 착각하고 있었기 때문이다. 누군가의 dotfiles를 그대로 복붙하고, 누군가의 Claude rule을 그대로 가져다 쓰는 식으로. 편하긴 한데, 그 과정에서 내 사고는 멈춰 있었다.

발표자가 인용한 한 문장이 며칠째 머릿속을 떠나지 않는다.

"AI를 쓰는 넌 지난 한 달 동안 얼마나 대단해졌어?"

이 질문에 자신 있게 답할 수 있어야, "AI 시대 엔지니어"라고 부를 자격이 있는 것 같다.

Engineer의 새로운 역할 — Code Clarity와 SRE

세션에서 정의한 엔지니어의 역할은 두 가지였다.

1. Code Clarity — 코드를 자연어처럼 작성해서 모든 팀원이 비즈니스 로직을 이해하고 고칠 수 있게 만든다
2. Site Reliability & Monitoring — 시스템이 안정적으로 동작하도록 한다

흥미로운 건 첫 번째 항목이다. 코드를 "예술적으로" 짜는 게 아니라 "비엔지니어가 읽고 고칠 수 있게" 짠다는 발상. 코드 가독성의 기준점이 동료 엔지니어가 아니라 마케터·PM·디자이너로 옮겨가는 셈이다.

실제로 발표에서 인상적이었던 사례:

• 마케터가 직접 Claude에게 GA 코드 수정을 요청하고 PR을 생성
• 비엔지니어가 명세를 작성하면 @claude PR로 코드 생성 → 엔지니어는 리뷰와 SRE에 집중
• CS 팀원이 Datadog 이슈에서 출발해서 직접 PR까지 작성

"실제로 동작하는 워크플로우의 80% 이상을 비엔지니어가 만든다"는 통계도 충격이었다. 엔지니어가 자동화의 가운데에 있는 게 아니라, 자동화를 위한 토양(코드 명확성 + 안정성)을 까는 사람 이 됐다는 것.

가져갈 것: 내 워크플로우에 적용하기

세션을 들으면서 메모해둔 액션 아이템들이다. 한 번에 다 할 순 없으니 천천히 적용해볼 생각이다.

1. 주 단위로 "내 일 정의" 점검 루틴 만들기 — 매주 월요일에 위의 세 가지 질문(내 일은 무엇 / 임팩트 / 병목)을 노션에 적기
2. 반복되는 일에 자동화 전에 "이거 안 해도 되는 일인가?" 부터 묻기 — 자동화는 두 번째 선택지로
3. 새 도구를 무조건 한 달에 하나는 진지하게 써보기 — Antifragility 유지를 위한 강제 노출
4. 내가 짜는 코드의 가독성 기준을 "디자이너가 읽을 수 있는가"로 두기 — 변수명·주석·구조 모두 이 기준으로 점검
5. 나만의 Skill / Slash Command 1주에 하나씩 만들고, 안 쓰면 정기적으로 삭제하기

요약

• Macrohard 키노트는 "소프트웨어 회사를 AI로 시뮬레이션한다"는 컨셉으로 출발해서, AI 시대 엔지니어가 어떻게 자기 정체성을 다시 정의해야 하는지에 대한 도발적인 메시지를 던졌다.
• 가장 충격적이었던 건 "성과 평가의 기준은 Process의 변화 가속도"라는 정의 — 무엇을 만들었느냐가 아니라 일하는 방식 자체를 얼마나 바꿨느냐가 평가 기준이라는 것.
• 자동화보다 더 강력한 질문은 "아예 안 해도 되는 일 아닌가?"이며, 도구에 정착하는 순간 개인과 조직의 Antifragility는 무너진다.
• 엔지니어의 새로운 역할은 Code Clarity(비엔지니어도 읽고 고칠 수 있는 코드)와 SRE이며, 실제 워크플로우의 80% 이상은 비엔지니어가 만든다.
• 가져갈 것은 주 단위 점검 루틴, "안 해도 되는 일인가" 질문 습관, 새 도구 강제 노출, 디자이너가 읽을 수 있는 코드 기준, 개인 Skill 만들고 비우기 — 다섯 가지로 정리했다.