외부 원문 링크
AI 시대 개발자를 위한 6가지 필수 역량
Figma 가 정리한 "AI 시대에 살아남는 엔지니어" 6가지 역량. 핵심은 자동화가 아니라 증강이며, 의미 있는 일은 끝까지 사람이 한다.
핵심 요약
Figma 의 Marcel Weekes(VP of Engineering)·Jake Albaugh(Developer Advocate)이 정리한 6가지 역량: (1) 자동화를 넘어 증강으로 보기 — 의미 있는 일은 자동화하지 말 것. (2) 바이브 코딩으로 문제 공간 탐색 — 한두 경로가 아니라 동시에 여러 시도. (3) 에이전트와 도구 활용 (MCP) — Figma Dev Mode MCP 처럼 컨텍스트를 정확히 전달해 출력 충실도 보장. (4) PR 셀프 리뷰 — LLM 에 PR 을 먼저 넣어 중복·누락 사전 점검. (5) 에이전트 팀 관리 — 마크다운으로 지침/맥락 작성, 인턴 멘토링처럼. (6) 한계까지 부딪혀 보기 — 도구의 능력을 이해하려면 직접 써봐야 한다.
AI 도구는 비용 절감 수단이 아니라 "가능성을 키우는 증강"이다. 같은 시간에 더 많은 경로를 탐색하고(바이브 코딩), 디자인-개발 사이 컨텍스트를 정확히 전달하고(MCP), 작은 단위로 쪼개 여러 에이전트를 관리하는("인턴 관리") 메타 스킬이 새 직무 능력으로 자리 잡고 있다.
기술 면접에서 "AI 어떻게 쓰세요?" 질문이 늘고 있고, 단순히 "Copilot 씁니다"는 약하다. 이 글은 6가지 역량을 행동 사례와 함께 제시해, 본인 경험을 매핑해 답할 수 있는 프레임을 준다.
학습 포인트
면접 답변으로 연결할 학습 포인트입니다.
AI = 비용 절감 ❌, 증강 ✅
Aaron Levie 인용: "AI 를 비용 절감으로 보면 잘못 본 것". 같은 인력으로 더 많은 가능성을 탐색하는 도구이며, 가장 의미 있는 일(왜 만드는가, 사용자 공감) 은 사람이 끝까지 들고 있어야 한다.
"AI 가 코드 짜주니까 엔지니어 덜 필요"라는 도식. 답해야 할 질문은 "무엇을, 누구를 위해, 왜" 이며 이게 자동화 안 되는 부분.
바이브 코딩 = 문제 공간 탐색
한두 가지 경로만 살펴보지 않고 여러 시안을 동시에 만들어 비교. Figma Make 처럼 "여러 결과물을 동시에 보고 피드백" 받는 방식이 핵심. 결국 "디자인 사고를 코드 단계까지 끌어올리는" 도구.
AI 출력을 "답안"으로 보고 그대로 채택하기. 핵심은 옵션을 늘려 비교하는 데 있다.
MCP 로 컨텍스트 전달 — 결과 충실도의 차이
MCP (Model Context Protocol) 는 AI 도구가 외부 소프트웨어와 통신하는 표준. 예: Figma Dev Mode MCP 서버는 디자인 컴포넌트·접근성 규칙·라이브러리 원칙 같은 컨텍스트를 LLM 에 전달해 "막연한 코드" 가 아닌 "라이브러리 관행에 맞는 코드" 를 생성하게 한다.
프롬프트에 컨텍스트를 거의 안 주고 "Cursor 가 이상하게 짠다" 고 평가. 입력 컨텍스트를 챙기지 않은 결과는 도구 탓이 아니다.
PR 셀프 리뷰 — 중복 발견을 LLM 에 위임
Figma 엔지니어들은 PR 을 LLM 에 먼저 넣어 "이미 구현된 부분을 다시 작성했네요" 같은 중복을 감지. 사람 리뷰어도 놓치는 코드베이스 횡단 패턴을 LLM 이 잘 본다.
셀프 리뷰를 "결과 신뢰"로 보지 말고 "체크리스트 엔진"으로 보기. 마지막 판단은 사람이.
에이전트 팀 관리 — 마크다운이 인터페이스
문제를 작은 단위로 쪼개 여러 에이전트가 병렬로 작업, 결과를 통합하는 메타 스킬. 마크다운으로 "이 부분을 고려해 줘, 이미 만들어 둔 이 해법을 참고해 줘" 같은 지침을 작성하는 능력이 "인턴 멘토링"과 동등.
"AI 에 큰 일 한 번에 시키기". 문제 분해가 안 되어 있으면 에이전트가 많아도 출력 품질이 안 올라간다.
선입견을 넘어서 — 직접 부딪혀 보기
"이 도구는 이건 못 해" 라는 선입견을 깨려면 직접 한계까지 써봐야 한다. Jake Albaugh 도 Dev Mode MCP 를 직접 쓰기 전엔 유용성을 몰랐다고 인정. 친숙도 자체가 채용 시장에서 차별점이 된다.
기사·트윗만 읽고 도구를 평가하기. 본인 워크플로에 넣어보지 않은 평가는 신뢰도가 낮다.
읽는 순서
- 1이론
MCP 의 정의·구조, "자동화 vs 증강" 프레임, 바이브 코딩의 의도를 정리.
- 2구현
본인 워크플로에서 (1) PR 셀프 리뷰, (2) 디자인-구현 핸드오프에 MCP 사용, (3) 작은 작업을 여러 에이전트로 병렬화 — 세 가지를 실제로 시도해 비교.
- 3실무
팀에 "AI 사용 사례 공유" 짧은 회고를 도입해 우리 코드베이스에서 가장 효과 큰 패턴이 무엇인지 데이터로 축적.
- 4설명
면접에서 "AI 활용" 질문에 6역량 프레임 + 구체 사례 + 한계 인지로 30초 답변을 만들어 둔다.
면접 연결 질문
[감점 답변] "Copilot 자동완성 씁니다". [좋은 답변] 구체 사례로 답: (1) PR 작성 후 LLM 에 먼저 넣어 중복/누락 점검, (2) 디자인 컨텍스트를 MCP 로 전달해 컴포넌트 라이브러리 관행에 맞는 코드 생성, (3) 큰 작업은 마크다운 브리프로 쪼개 여러 에이전트에 병렬 위임. 무엇이 빨라졌고 무엇은 여전히 사람이 해야 하는지 까지 답하면 깊이가 보인다.
[감점 답변] "AI 가 아직 부족하다". [좋은 답변] (1) 컨텍스트 점검: 충분한 코드/디자인/관행 정보를 줬는지. (2) 태스크 분해: 너무 큰 단위인지. (3) 검증 루프: 출력 후 테스트·리뷰로 피드백을 줬는지. 도구 평가 전에 입력·태스크·피드백 세 축을 체크하는 습관이 핵심.
[감점 답변] "AI 와 연결해 준다". [좋은 답변] (1) 컨텍스트 충실도: 디자인 시스템·접근성 규칙·라이브러리 관행을 LLM 에 정확히 전달, (2) 결정론적 도구 호출: 외부 시스템과의 통신을 표준화해 출력 일관성, (3) 재사용 가능한 어댑터: 한 번 정의한 MCP 서버를 여러 AI 도구가 공유. 단순 "프롬프트에 붙여넣기"보다 한 단계 위의 통합.
자기 점검
"창의적인 일" 같은 추상어로 답. 면접관은 구체 사례를 듣고 싶다.
"좋은 프롬프트" 라는 모호한 답. 인턴 비유의 핵심은 "무엇을, 왜, 어떻게 검증"의 명세화.