이 글은 무신사 테크 블로그에 게시된 원문입니다.
2026년 노트: 이 글을 쓸 당시에도 AI로 인한 변화는 이미 진행 중이었지만, 그 이후로 변화는 더욱 가속되고 있습니다. ‘How(어떻게)‘에서 ‘Why(왜)‘로의 전환은 이미 시작됐지만, AI는 그 너머 — ‘What(무엇을 만들 것인가)’ 까지 밀어붙이고 있습니다. AI 코딩의 등장으로 구현 비용이 급격히 낮아지면서, ‘마이크로(How)‘는 예상보다 훨씬 빠르게 범용화되고 있습니다. ‘Why’를, 그리고 특히 ‘What should we build?‘를 묻는 ‘매크로’ 관점은 이제 단순히 가치 있는 것을 넘어 필수가 되었습니다. 돌아보면 이 글의 시각이 오히려 지금 더 유효하고, 어쩌면 당시엔 충분히 강하게 이야기하지 못했을 수도 있습니다. 지금 벌어지고 있는 변화를 읽는 하나의 렌즈로서 다시 공유합니다.
부제: 시니어의 ‘벽’을 넘는 ‘매크로 코딩’ 이야기
안녕하세요, 무신사에서 Distinguished Engineer이자 전사 테크리드 로 일하고 있는 김상범(Tao)입니다.
무신사 테크 블로그에 처음으로 글을 쓰게 되었습니다. 앞으로 다양한 주제와 생각을 공유드리고자 하며, 첫 번째 주제로 현재 제가 무신사에서 수행하고 있는 저의 역할인 ‘Senior IC(Individual Contributor)’ 로의 성장에 대해 이야기해 보려 합니다.
저는 소위 Senior IC 로서 무신사 전사 관점에서의 주요 의사 결정에 참여하고 있는 엔지니어 로 일하고 있습니다. 제가 이 역할을 오래 수행하다 보니, 커리어와 성장에 대한 질문을 자주 받습니다. 마침 무신사에서도 매니저가 아닌 IC 역할이 공식적인 커리어 패스(Career Path)로 자리 잡으면서, 저는 이 ‘새로운 성장의 사다리’를 동료들에게 소개하는 일을 꾸준히 하고 있습니다.
테크톡, 1:1 미팅 등 다양한 사내 채널에서 나눈 이 이야기가, 무신사 동료뿐만 아니라 더 많은 엔지니어분들께도 도움이 되길 바라는 마음으로 블로그의 첫 주제로 선정했습니다.
1. 성장의 ‘벽’을 느끼는 당신에게
이 글은 주니어 딱지를 떼고 시니어로 나아가려는, 혹은 이미 시니어 타이틀을 달고 있지만 다음 스텝이 막막한 엔지니어들을 위한 글입니다.
혹시 이런 고민을 하고 있지 않나요?
- “클린 코드, 리팩토링, TDD… 나를 열심히 하는데 왜 성장이 정체된 것 같지?”
- “내 코드는 분명 좋아지고 있는데, 왜 회사에서의 영향력(Impact)은 그만큼 커지지 않을까?”
- “시니어 개발자라는데, 주니어 때와 하는 일이 크게 다르지 않은 것 같다.”
- “내 연봉은 왜 ‘벽’에 부딪힌 것처럼 더 이상 오르지 않을까?”
만약 위 질문 중 하나라도 해당된다면, 아마도 당신은 ‘관점의 확장’이 필요한 시점일 수 있습니다. 저는 이 성장의 ‘벽’을 넘는 열쇠가 ‘마이크로(Micro) 코딩’ 에서 ‘매크로(Macro) 코딩’ 으로 관점을 확장하는 데 있다고 생각합니다.
2. 당신의 코딩은 ‘마이크로’인가요, ‘매크로’인가요?
성장이라는 주제를 이야기하고 엔지니어 여러분의 이해를 돕기 위해 제가 정의한 두 가지 관점입니다.
‘마이크로(Micro) 코딩’
- ‘점(Point)‘의 관점입니다.
- 변수명, 함수 로직, 클래스 설계, 테스트 커버리지, 코드 컨벤션 등 ‘코드 자체’의 품질과 ‘지금 이 기능’의 구현에 집중합니다.
- 훌륭한 개발자의 기본기이자 강력한 미덕입니다. 클린 코드, TDD, 리팩토링 등이 모두 이 영역에 속합니다.
‘매크로(Macro) 코딩’
- ‘흐름(Flow)‘의 관점입니다.
- 이 코드가 전체 시스템과 비즈니스에 어떤 영향을 미치는지에 집중합니다.
- ‘점’들이 모여 어떻게 ‘선’과 ‘면’을 이루는지, 더 큰 그림을 보는 것입니다.
많은 엔지니어가 ‘마이크로 코딩’의 달인이 되는 것을 목표로 하지만, 어느 순간 그 관점만으로는 해결할 수 없는 문제(혹은 연봉 테이블)의 ‘벽’을 만나게 됩니다.
Engineer’s Job Title and Scope (with Gemini)
[자가 진단] 나는 ‘매크로’ 관점을 가지고 있을까?
스스로 ‘매크로’ 관점을 얼마나 가졌는지 점검해 볼 수 있는 몇 가지 질문을 던져봅니다.
- 최근 한 달간의 코드 리뷰에서, 변수명 지적 외에 ‘이 로직의 실패 흐름(Failure flow)‘이나 ‘비즈니스 임팩트’를 지적한 적이 있는가?
- 현재 개발 중인 기능이 어떤 비즈니스 KPI(e.g., 구매 전환율)에 기여하는지 30초 안에 설명할 수 있는가?
- 문제를 해결할 때, ‘일단 구현(How)‘하는 것보다 ‘왜(Why) 이걸 해야 하는지’를 먼저 질문하고 더 나은 ‘흐름’을 역제안한 경험이 있는가?
- 1년 뒤 트래픽이 10배가 되어도 지금의 아키텍처가 버틸 수 있다고 확신하는가?
- 내가 만든 API가 실패했을 때, 나를 호출한 서비스(Caller)와 내가 호출하는 서비스(Callee)에 어떤 연쇄 장애가 일어날지 그려지는가?
만약 위 질문에 ‘Yes’라고 답하기 어렵다면, 당신은 ‘마이크로’ 관점에 머물러 있을 가능성이 높습니다.
3. ‘매크로 코딩’은 무엇이 다른가?
그렇다면 ‘매크로 코딩’의 관점은 구체적으로 무엇이 다를까요?
관점 1: ‘점’이 아닌 ‘흐름(Flow)‘을 봅니다.
‘마이크로’ 관점이 ‘이 함수는 스파크(Spark) 코드를 어떻게 짜야 더 효율적일까?‘에 집중한다면, ‘매크로’ 관점은 ‘이 스파크 잡(Job)이 실패하면 데이터 파이프라인 전체가 멈추는데, 실패 시 복구(Recovery) 흐름은 어떻게 설계할 것인가?‘를 함께 고민합니다.
코드가 ‘점’이라면, 데이터와 요청은 ‘흐름’입니다. ‘매크로’ 관점은 이 ‘흐름’이 막히거나 터졌을 때를 대비한 ‘배수로나 우회로’를 설계하는 것입니다. (e.g., 재시도(Retry), 서킷 브레이커(Circuit Breaker), 데드 레터 큐(DLQ))
관점 2: ‘어떻게(How)‘보다 ‘왜(Why)‘를 묻습니다.
‘마이크로’ 관점은 주어진 티켓(Task)을 ‘어떻게’ 잘 구현할지에 집중합니다. 반면 ‘매크로’ 관점은 ‘왜’ 이 티켓이 지금 우리에게 주어졌는지를 먼저 질문합니다.
- Micro: “이 버튼을 누르면 유저 정보가 팝업으로 뜨게 만들어야지.”
- Macro: “유저 정보를 ‘팝업’으로 띄우는 게 최선인가? ‘왜’ 유저 정보를 봐야 하지? 차라리 팝업 없이 더 중요한 정보만 넛지(Nudge)로 보여주는 게 비즈니스 목표(e.g., 구매 전환)에 더 도움 되지 않을까?”
‘왜’를 묻는 것은 PM이나 기획자의 영역을 침범하는 것이 아니라, ‘기술로 비즈니스 문제를 더 잘 해결하려는’ 시니어 엔지니어의 핵심역량 입니다.
관점 3: ‘코드’가 아니라 ‘API 너머’를 봅니다.
제가 경험한 실례입니다. 한 엔지니어가 “A 서비스에 API를 호출하는데 자꾸 HTTP 타임아웃이 나요. 저의 로직은 문제가 없는데 A 서비스가 문제인 것 같아요"라고 보고했습니다.
- ‘마이크로’ 관점은 ‘내 코드’의 경계에서 멈춥니다. “내 코드는 이상 없다. 호출한 A 서비스가 응답을 안 준다. 내 책임은 여기까지다.”
- ‘매크로’ 관점은 ‘API 너머’를 봅니다. “A 서비스는 ‘왜’ 타임아웃이 날까? A 서비스의 로그를 같이 볼까? 혹시 A 서비스가 의존하는 B 서비스가 죽은 건 아닐까? 아, A 서비스가 동기(Sync) 호출을 너무 많이 물고 있구나. 이걸 비동기(Async) 큐 구조로 바꾸자고 제안해야겠다.”
‘매크로’ 관점은 ‘내 코드’의 성공이 아니라 ‘전체 흐름’의 성공을 목표로 합니다. 시스템은 유기적으로 연결되어 있으며, 문제 해결의 실마리는 종종 내 코드의 ‘경계 너머’에 있습니다.
4. ‘도장’이 아닌 ‘공장’을 설계합니다.
‘마이크로’와 ‘매크로’의 차이를 비유하자면, ‘도장’과 ‘공장’의 차이입니다.
- ‘마이크로’ 관점은 ‘도장’을 정교하게 파는 ‘장인’ 에 가깝습니다. 얼마나 아름답고 오류 없는 도장을 만드느냐에 집중합니다.
- ‘매크로’ 관점은 그 도장을 1초에 1만 개씩 찍어내는 ‘공장’ 을 설계하는 ‘아키텍트’ 에 가깝습니다. 도장 자체의 품질은 기본이고, 이 도장을 ‘어떤 흐름’으로, ‘어떻게 대량 생산’하며, ‘공장이 멈췄을 때 어떻게 복구’할지를 설계합니다.
- 이것은 아름다운 장인 정신에 더해, 거스를 수 없는 ‘산업화’의 현실이자, 스케일과 임팩트의 문제입니다.
몇년전 일본에서 ‘도장(Hanko)‘을 찍어주는 자동화 로봇이 도입되어 화제가 되었습니다. 이 현상을 어떻게 바라봐야 할까요?
도장 로봇을 기반으로 상상해본 공정 라인 (with Gemini)
이는 ‘마이크로’ 관점에만 너무 매몰되었을 때 발생할 수 있는 현상을 상징적으로 보여줍니다. 아무리 정교하게 ‘도장 찍는 기술(마이크로)‘을 연마해도, 그 프로세스 자체를 자동화하는 ‘기계’가 등장하면 개인의 장인 정신은 무의미해질 수 있습니다.
하지만 여기서 한 걸음 더 나아가야 합니다.
진정한 ‘매크로’ 관점은 ‘도장 찍는 로봇’을 효율적으로 만드는 것일까요? 아니면, 앞서 ‘공장’의 비유처럼 “왜 지금 도장을 찍고 있지? 이 흐름을 전자 서명(e-Signature)으로 대체할 순 없을까?” 라고 질문하는 것일까요?
‘도장 로봇’은 어쩌면 ‘어떻게(How)‘를 극단적으로 자동화했지만, ‘왜(Why)‘라는 근본적인 질문이 빠진, ‘잘못된 흐름’을 고도화한 예시일 수 있습니다. ‘매크로’한 관점은 이처럼 ‘장인 정신’이나 ‘기계(자동화)‘에 머무르는 것이 아니라, ‘현재의 흐름 자체’가 올바른지 끊임없이 의심하고 더 큰 ‘산업화’의 변화를 읽고 주도하는 것을 의미합니다.
도장 파는 개발자 vs 공장 짓는 개발자 (with Gemini)
5. 글을 마치며: 당신의 성장(연봉)은 어디에 베팅되어야 할까요?
‘마이크로 코딩’은 엔지니어의 단단한 반석입니다. 이 반석이 없다면 ‘매크로’는 사상누각에 불과합니다.
하지만 대부분의 조직과 교육은 ‘마이크로’에 집중되어 있습니다. ‘클린 코드’는 모두가 외치지만, ‘비즈니스 흐름’을 설계하는 법은 아무도 알려주지 않습니다.
기업의 입장에서 필요한 리더는 ‘마이크로’를 기반으로 ‘매크로’를 상상할 수 있는 엔지니어입니다. 수요와 공급의 법칙에 따라, ‘매크로’ 관점을 가진 엔지니어의 희소성은 높게 평가받을 수밖에 없습니다.
당신의 성장이 정체되어 있다고 느낀다면, 어쩌면 당신의 연봉이 ‘벽’에 부딪혔다고 느낀다면, 지금 당신의 노력이 ‘도장’을 파는 데만 집중되어 있지는 않은지, ‘공장’을 짓는 더 큰 그림에 베팅해야 할 때는 아닌지 되돌아볼 시간입니다.
마지막으로 이글을 작성하는데 큰 도움을 주신 팀무신사의 Senior IC 분들께 감사하다는 말 드리며 마무리하겠습니다.
감사합니다.
사족 1: ‘마이크로’와 ‘매크로’는 층위일 뿐, 우열의 문제가 아닙니다.
이 글을 읽고 “아, 그럼 마이크로 코딩은 중요하지 않다는 건가?“라고 오해하지 않으셨으면 합니다. 마치 거시 경제와 미시 경제적 관점이 모두 중요하듯이 둘 다 모두 중요한 관점입니다. ‘매크로’만 상상하고 ‘마이크로’가 부실하면 그것은 ‘사상누각’에 불과합니다. 단단한 ‘마이크로’라는 반석 위에 ‘매크로’ 관점이 더해질 때 비로소 강력한 시너지가 납니다. 마이크로에 너무 신경쓰다가 매크로를 놓지지 말자가 포인트일뿐 합니다.
또한 이 글은 누가 더 뛰어난 엔지니어인지를 논쟁하고자 하는 글이 아닙니다. 단지, 대부분의 엔지니어링 조직과 교육이 ‘마이크로’에 집중되어 있어 상대적으로 ‘매크로’의 중요성이 간과되기 쉬우며, 기업의 입장에서 필요한 리더는 마이크로를 기반으로 매크로를 상상할 수 있는 엔지니어를 필요로 하니, 수요와 공급의 관점에서 ‘매크로’ 관점을 가진 엔지니어의 희소성이 (연봉 협상에서) 더 높게 평가받을 수 있다는 현실적인 이야기를 하고 싶었습니다.
사족 2: 이 글은 모든 시니어 엔지니어를 위한 글이 아닙니다.
시니어 엔지니어의 역할은 조직마다, 개인의 성향마다 다릅니다. 누군가는 ‘마이크로’의 끝을 파고들어 특정 분야의 ‘장인(Specialist)‘이 되어 독보적인 가치를 만들 수 있습니다. (e.g., 커널 튜닝, 컴파일러, 3D 렌더링 엔진 등)
이 글은 특정 도메인의 스페셜리스트가 아닌, 저와 같이 ‘비즈니스 문제를 기술로 해결하는’ Product Engineer 의 성장에 초점을 맞춘 글임을 밝힙니다.
사족 3: ‘Engineering Surface’에 대하여
본문에서 ‘도장’의 표면을 비유로 들었습니다. 이는 엔지니어링에서 흔히 말하는 ‘Engineering Surface’ 혹은 ‘Surface Area’ 개념과 맞닿아 있습니다.
‘Engineering Surface’란 시스템이 외부 세계와 소통하는 모든 ‘접점’을 의미합니다.
- API 명세: POST /users 같은 엔드포인트와 JSON 구조.
- 함수 시그니처: calculatePrice(user, item)의 입력과 출력.
- 클래스 인터페이스: 외부에서 호출 가능한 Public Method.
‘마이크로’ 관점의 장인은 이 ‘Surface’를 얼마나 정교하고 깔끔하게 깎아내는가에 집중합니다.
하지만 ‘매크로’ 관점은 이 ‘Surface’를 다르게 봅니다. MSA(Microservice Architecture) 관점에서, 하나의 서비스가 책임지는 ‘Surface’가 너무 거대하고 복잡해진다면(e.g., API가 100개가 넘어가고 관리가 안 된다면), 이는 ‘Surface’가 너무 비대하다는 신호이며 곧 서비스 분리의 근거가 됩니다. 즉, ‘매크로’ 관점은 ‘Surface’ 자체의 아름다움뿐만 아니라, 이 ‘Surface’의 적절한 ‘크기’와 ‘경계’ 를 설계하는 것입니다.