도구가 없어서 막히는 게 아닙니다.
넘기는 방식이 틀려서 막히는 겁니다.

이미 ChatGPT도 써봤고, Claude도 써봤고, 결과물도 몇 번 뽑아봤습니다.
그런데 이상하게 포트폴리오는 잘 안 나옵니다.

초안은 나옵니다.
문장도 그럴듯합니다.
근데 내 경험처럼 안 느껴지고, 다시 읽어보면 붕 떠 있고, 조금만 수정하려고 해도 처음부터 다시 손대게 됩니다.

그래서 결국 이런 상태가 됩니다.

만든 건 있는데 정리가 안 되고,
정리하려고 하면 문장이 내 것이 아니고,
AI를 썼는데도 작업 속도는 빨라진 것 같지 않은 상태.

이 글은 그 이유를 다룹니다.

이 글에서 다루는 것
브리핑 설계, 단위 쪼개기, 교차검증.
이 세 가지를 갖추면 같은 AI를 써도 결과물이 달라집니다.

처음 상태: 없는 게 아니라 흩어져 있었다

최근 함께 작업한 분도 비슷한 상태였습니다.

AI를 아예 안 써본 분은 아니었습니다.
이미 여러 툴을 써봤고, 결과물도 어느 정도 뽑아본 상태였습니다.
프로젝트 경험도 있었고, 정리해둔 노션도 있었고, 작업 중 남겨둔 기록도 있었습니다.

문제는 그게 보여줄 수 있는 구조가 아니었다는 점입니다.

어딘가에는 다 있었습니다.

프로젝트 설명도 있었고, 배운 점도 있었고, 작업 과정도 있었고, 생각한 흔적도 있었습니다.
그런데 그것들이 포트폴리오 문서가 아니라 작업 중인 사람의 메모 상태로 흩어져 있었습니다.

많은 사람들이 여기서 이렇게 말합니다.

“아직 보여줄 게 없어요.”

그런데 실제로는 없는 경우보다,
있는데 아직 보여줄 수 있는 형태가 아닌 경우가 더 많습니다.

포트폴리오에서 상대가 보고 싶은 건 결과물만이 아닙니다.
이 사람이 어떤 기준으로 판단했고, 어떤 맥락에서 만들었고, 무엇을 강점으로 가져가려는지가 읽히는 구조입니다.

그 구조가 없으면, 만든 게 많아도 포트폴리오가 없는 것처럼 느껴집니다.
그리고 그 상태로 AI에 넘기면 결과가 붕 뜹니다.
AI는 비어 있는 맥락을 자기 방식으로 메우기 때문입니다.

그 기본값은 대체로 비슷합니다.
어디서 본 것 같은 문장들, 평균적인 자기소개, 무난하지만 힘이 없는 포트폴리오.

브리핑이 빠져 있었다

세션에서 가장 먼저 한 일은 AI에게 문장을 시키는 게 아니었습니다.
그 전에 AI가 무엇을 기준으로 봐야 하는지부터 정리했습니다.

핵심은 브리핑입니다.

AI는 내가 어떤 사람인지 모릅니다.
이 문서를 누가 읽는지, 어떤 포지션을 목표로 하는지, 어디까지 강조해야 하는지, 무엇은 넣으면 안 되는지 알지 못합니다.

이 정보 없이 요청하면, AI는 빠진 맥락을 알아서 채웁니다.
문제는 그 채움이 내 상황에 맞지 않는다는 점입니다.

브리핑에 최소한 들어가야 하는 것은 네 가지입니다.

• 역할: AI가 어떤 시점에서 이 작업을 봐야 하는지
• 독자: 이 문서를 누가 읽는지
• 목적: 이 문서가 어떤 상황에서 쓰이는지
• 제약 조건: 길이, 형식, 제외해야 할 것 같은 경계선

이 차이는 생각보다 크게 납니다.

예를 들어 많은 사람이 실제로는 이런 식으로 요청합니다.

브리핑이 약한 요청

“커리어 전환용 포트폴리오 자기소개 문단 써줘. 이전 경력도 강점으로 녹이고 싶어.”

→ “다양한 경험을 바탕으로 문제 해결에 강점을 가진 지원자입니다. 이전 경력을 통해 쌓은 역량을 바탕으로…”

틀린 말은 아닙니다.
문제는 누구에게 어떻게 읽혀야 하는지가 빠져 있어서, 결과가 무난한 평균값으로 떨어진다는 점입니다.

같은 내용을 이렇게 바꾸면 결과가 달라집니다.

브리핑이 갖춰진 요청

“나는 7년 리테일 도메인 경력이 있는 커리어 전환 취준생이야.
지원 포지션은 백엔드고, 이전 경력이 ‘잡경험’이 아니라 도메인 이해로 읽혀야 해.
독자는 스타트업 개발팀장이고, 포트폴리오 첫 문단에 들어갈 소개 문장이라 두 줄 이내로 써줘.
추상적인 성실함보다, 왜 이 경력이 개발 판단에 연결되는지가 드러났으면 좋겠어.”

→ “리테일 현장에서 쌓은 7년의 도메인 이해가 API와 데이터 흐름을 설계할 때의 판단 기준이 됩니다. 현업 맥락을 놓치지 않는 백엔드 개발자로 전환하는 것이 제 포지션입니다.”

세션에서도 이 차이를 바로 확인했습니다.

브리핑 없이 뽑은 결과물은 문장 자체는 멀쩡했지만, 누구에게 어떤 강점으로 읽혀야 하는지가 흐렸습니다.
반대로 브리핑을 갖춘 뒤의 문장은 훨씬 선명했습니다.

반응도 명확했습니다.

“아, 이게 제가 하고 싶었던 말이에요.”

좋은 결과물은 보통 문장을 잘 써서 나오는 게 아닙니다.
앞에서 무엇을 분명하게 넘겼느냐에서 갈립니다.

단위를 쪼개지 않으면 AI도 흐려진다

브리핑이 정리되었다고 바로 문서 전체를 한 번에 만들지는 않았습니다.
그다음에 한 일은 작업 단위를 쪼개는 것이었습니다.

많은 사람들이 여기서 한 번 더 막힙니다.

자기소개, 프로젝트 설명, 문제 해결 사례, 협업 방식, 회고까지
전부 한 번에 넣고 “포트폴리오 정리해줘”라고 하면
AI는 겉보기에는 많이 만들어주는 것 같지만 실제로는 흐려집니다.

앞에서 강조한 강점이 뒤에서 사라지고,
프로젝트 설명은 따로 놀고,
문서 전체의 톤도 흔들립니다.

이건 AI가 멍청해서가 아닙니다.
처리해야 할 맥락이 너무 많아지면 우선순위가 흔들리기 때문입니다.

그래서 작업을 항목별로 나눴습니다.

자기소개는 자기소개대로,
프로젝트 설명은 프로젝트 설명대로,
강점 문장은 강점 문장대로,
각 항목마다 필요한 자료와 브리핑만 따로 붙였습니다.

이 방식의 장점은 분명합니다.

전체를 한 번에 던질 때보다,
AI가 지금 무엇에 집중해야 하는지가 선명해집니다.

문장의 밀도가 올라가고, 수정도 쉬워집니다.
무엇보다 왜 이 문장이 나왔는지 추적할 수 있게 됩니다.

세션 마지막에 나온 반응도 그 지점이었습니다.

“더 세부적으로 나눠서 정리해야겠다는 걸 느꼈어요.”
“이렇게 나눠서 하는 게 맞는 방향이라는 걸 알겠어요.”

중요한 건 AI가 많이 만들어주는 것이 아닙니다.
사람이 통제할 수 있는 단위로 작업이 분해되어 있느냐입니다.

한 세션이 만든 초안을 다른 세션으로 검증했다

초안이 나왔다고 끝이 아니었습니다.
오히려 그때부터가 중요했습니다.

많은 사람이 AI 결과물을 받으면 그걸 거의 완성본처럼 취급합니다.

하지만 실제로는 그 초안 안에도 구멍이 남아 있는 경우가 많습니다.

그래서 같은 내용을 다른 세션으로 다시 검토했습니다.

이 과정에서 꽤 자주 나오는 문제가 있습니다.

예를 들면 이런 식입니다.

자기소개 문단에서는 도메인 경험을 핵심 강점으로 세웠는데,
프로젝트 설명 파트로 가면 그 강점이 전혀 이어지지 않는 경우.

혹은 지원 포지션은 백엔드인데,
문서 전체 톤이 너무 기획자 서사처럼 정리되어 있는 경우.

앞에서는 협업과 맥락 이해를 장점으로 잡아놓고,
뒤에서는 성과를 개인 작업처럼만 서술해서 흐름이 끊기는 경우도 있습니다.

혼자 읽을 때는 잘 안 보입니다.
문장 단위로는 다 멀쩡해 보이기 때문입니다.

하지만 다른 세션으로 교차검증하면 이런 구조적 불일치가 드러납니다.
한 세션이 자연스럽게 넘긴 부분을, 다른 세션은 문제로 짚어냅니다.

이번에도 그랬습니다.
초안 자체는 꽤 잘 나와 있었지만, 전체 맥락을 이어 보면 앞에서 세운 포지션이 뒤에서 약해지는 부분이 있었습니다.
그 피드백을 반영해 다시 다듬자 문서가 훨씬 단단해졌습니다.

AI를 잘 쓰는 사람은 보통 한 세션의 첫 결과를 그대로 믿지 않습니다.

초안을 만들 세션과, 구멍을 찾을 세션을 분리합니다.

그 차이가 결과물의 밀도를 바꿉니다.

마지막에 가장 중요한 걸 확인했다

작업이 거의 마무리됐을 때, 마지막으로 한 가지를 분명히 짚었습니다.

이해하지 못한 문장은 포트폴리오에 넣지 않는 것.

이건 생각보다 중요합니다.

포트폴리오를 제출하면 결국 질문을 받게 됩니다.

왜 이렇게 구성했는지,
이 판단은 어떤 경험에서 나온 건지,
이 프로젝트에서 본인이 실제로 한 역할은 무엇인지.

그 질문에 자기 말로 답할 수 없다면,
그건 포트폴리오가 아니라 AI가 정리해준 문서에 가깝습니다.

AI는 구조를 제안할 수 있고,
문장을 다듬을 수 있고,
빠진 부분을 짚어줄 수 있습니다.

하지만 그 문장을 이해하고,
설명 가능하게 만들고,
내 경험으로 다시 소화하는 건 사람의 일입니다.

이 지점에서 잠깐 멈칫하는 반응이 나왔습니다.
AI가 정리해준 표현을 그대로 넣으려 했던 부분이 있었다고 했습니다.

그래서 다시 확인했습니다.

설명할 수 없는 건 넣지 않는다.
이해한 것만 넣는다.

이 원칙이 있어야, AI를 써도 결과물이 내 것이 됩니다.

세션이 끝난 뒤 남아야 하는 것

이 작업은 한 번의 문장 첨삭으로 끝나는 종류가 아닙니다.

브리핑 설계,
작업 단위 분해,
초안 생성,
교차검증,
최종 자산화.

이 과정을 한 번 경험하면 중요한 게 남습니다.

문서 하나가 완성되는 것보다,
다음 작업에도 반복해서 쓸 수 있는 방식이 남습니다.

브리핑 템플릿,
작업 단위를 나누는 기준,
세션 간 교차검증 프롬프트,
초안을 이해 가능한 문장으로 다시 바꾸는 기준.

이것들이 남아야 다음 포트폴리오도, 다음 프로젝트 정리도 혼자 돌릴 수 있습니다.

제가 만들고 싶은 건 결과물 한 장이 아닙니다.
결과물이 계속 나오게 하는 구조입니다.

포트폴리오가 없는 게 아니라, 아직 제대로 넘기지 않은 것이다

많은 사람들이 AI를 쓰고도 같은 자리에서 맴돕니다.

초안은 나왔는데 정리가 안 되고,
정리는 했는데 내 것 같지 않고,
다듬으려고 하면 처음부터 다시 시작하게 됩니다.

이때 필요한 건 더 새로운 툴이 아닙니다.

브리핑을 갖추는 것,
작업 단위를 쪼개는 것,
교차검증으로 구멍을 찾는 것,
그리고 이해한 것만 남기는 것.

이 순서를 아는 사람과 모르는 사람은
같은 AI를 써도 결과물에서 차이가 납니다.

포트폴리오가 없는 게 아닐 수 있습니다.
이미 해본 일은 있는데, 아직 제대로 넘기지 못한 상태일 수 있습니다.

관련글

막막한 사람에게 지도를 그려주는 건 전문가가 아닙니다.
막막함 자체를 구조화하는 과정이 지도를 만듭니다.

부트캠프를 듣고 있는데도,

막상 지원하려 하면 멈추는 사람들이 있습니다.

기술이 부족해서만은 아닙니다.

이전에 해온 일과 지금 배우는 기술이 하나의 이야기로 연결되지 않기 때문입니다.

몇 년을 일했는데도, 그 시간이 채용 시장에서는 쓸모없는 시간처럼 느껴질 때가 있습니다.

스스로도 그렇게 느끼기 시작하면, 포트폴리오를 만들기 전부터 이미 위축됩니다.

최근 그런 상태의 수강생과 1시간짜리 세션을 진행했습니다.

겉으로 보면 평범한 직무 전환 케이스였습니다. 수강 중, 결과물은 애매하고, 어떤 직무를 목표로 해야 할지도 불분명한 상태. 그런데 이 케이스의 핵심은 기술 수준이 아니었습니다. 문제는 이미 가진 경험이 채용 시장에서 읽히는 언어로 번역되지 않고 있다는 점이었습니다.

2시간 뒤, 이 수강생 앞에는 하나의 로드맵이 놓였습니다. 어떤 포지션이 유리한지, 어떤 회사군을 노려야 하는지, 기존 결과물을 살릴지 새로 만들지, 만든다면 어떤 주제로 어디까지 만들어야 하는지, 그리고 앞으로 몇 달 안에 뭘 해야 하는지가 한 페이지에 정리돼 있었습니다.

없던 경력이 생긴 게 아닙니다. 원래 있던 경험이, 이제야 지원 가능한 형태로 보이기 시작한 겁니다.

문제는 공부량이 아니라 구조 부재였다

이 수강생의 상태를 겉으로만 보면 흔히 이렇게 해석하기 쉽습니다.

"실력이 부족한가 보다. 더 공부해야겠네." 하지만 실제로는 그게 아니었습니다.

여러 해의 실무 경험이 있었습니다.

예산 처리, 비용 관리, 내부 프로세스 운영 같은 업무를 직접 다뤄본 경력.

겉으로 보면 지원하려는 직무와 거리가 있어 보이지만, 아무것도 없는 경력도 아닙니다.

문제는 그 경험이 지원 전략으로 연결되지 못하고 있었다는 점입니다.

이 경험이 어떤 도메인에서 강점이 되는지,

어떤 회사군에서 유리하게 작동하는지,

어떤 방향으로 번역해야 면접에서 살아나는지.

이 기준이 없으니 이미 가진 경험도 쓸모없는 것처럼 느껴졌던 겁니다.

구조가 없는 상태에서 지식을 더 쌓아도 방향은 더 흐려집니다.

이번 세션의 목표는 그래서 단순했습니다.

더 많이 배우게 하는 것이 아니라, 이미 가진 경험을 실행 가능한 방향으로 구조화하는 것.

AI를 써서 막막함을 실행 계획으로 바꿨다

세션 전 상태는 이랬습니다. 가고 싶은 방향조차 없었지습니다.

이 케이스는 직무 전환 사례였지만, 본질은 특정 직군의 문제가 아닙니다.

많은 사람이 비슷한 방식으로 자기 경험을 설명하지 못해 멈춥니다.

세션 후에는 달랐습니다.

실무 도메인 경험을 살려 어떤 회사군을 노릴지 정해졌고,

기존 결과물을 재정리할지 새로 만들지 A/B로 판단했으며,

만들 경우 어떤 주제로 어디까지 만들어야 하는지까지 내려왔습니다.

AI를 통해 막연한 "이쪽으로 가고 싶다"가 생겼고,
그 이후에는 지원 전략과 실행 계획까지 붙은 셈입니다.

이걸 만드는 데 쓴 방식은 단순했습니다.

먼저 경력 데이터를 AI에게 넣어 강점 영역과 지원 가능한 도메인을 분석했습니다.

수강생 본인도 처음 보는 자기 분석 결과였습니다.

오래 다뤄온 실무 경험이, 특정 회사군에서 오히려 유리한 포지션이 될 수 있다는 방향이 나왔습니다.

다음으로 그 결과를 지원 전략 문서로 정리했습니다.

가능한 포지션, 결과물 방향, 목표 시점까지의 타임라인.

대화로 끝나는 것이 아니라 다음에 꺼낼 수 있는 형태로 저장했습니다.

그리고 그 문서를 다른 AI에게 넘겨 현실성을 검증했습니다.

같은 내용을 서로 다른 AI에게 보여주면 보는 각도가 달라집니다.

이번에도 충돌이 일어났습니다.

"범위가 주어진 기간 대비 넓다"는 피드백이 나왔습니다.

처음 만들어진 계획이 다소 이상적이었던 겁니다.

이 피드백을 다시 반영해 범위를 줄이고 실행 계획으로 바꿨습니다.

최종적으로 A안과 B안, 두 가지 선택지가 나왔고, 수강생이 직접 하나를 골랐습니다.

AI가 해준 건 '결정'이 아니라 '번역'이었다

여기서 중요한 걸 짚어야 합니다.

이 과정에서 AI를 여러 번 사용했습니다.

하지만 핵심은 "AI를 몇 개 썼는가"가 아닙니다.

AI가 해준 것은 흩어진 경력을 정리하고,

가능한 방향을 좁히고,

실행 계획을 제안하고,

범위를 줄이고,

일정까지 구체화하는 것이었습니다.

즉 사람이 이미 갖고 있던 경험을, 채용 시장에서 읽히는 언어로 다시 정렬해준 것입니다.

경력은 있었지만 경력처럼 보이지 않았고,

강점은 있었지만 강점처럼 정리되지 않았습니다.

AI는 바로 그 중간 번역기를 해줬습니다.

커리어 컨설팅 시장에는 이런 작업을 수백만 원짜리 서비스로 파는 곳들이 있습니다.

그 비용의 상당 부분은 "경험을 언어로 번역하는 과정"에 들어갑니다.

그 과정을, 지금은 AI로 훨씬 빠르게 할 수 있습니다.

물론 AI가 모든 걸 대신해주진 않습니다.

다만 사람 혼자서는 흐릿하게 느끼던 것을 선명한 선택지로 바꿔주는 속도는 압도적으로 빠릅니다.

그리고 마지막 판단은 언제나 사람이 합니다.

AI를 잘 쓰는 사람은 AI에게 결정을 떠넘기는 사람이 아닙니다.
AI를 이용해 판단 가능한 상태를 만드는 사람입니다.

진짜 지표는 '열정'이 아니라 다음 행동이다

세션 마지막에 수강생이 이렇게 말했습니다.

"열정이 생겨요."

좋은 반응입니다.

하지만 저는 이런 말을 성공 지표로 보지 않습니다.

첫 세션에서는 누구나 조금 들뜰 수 있습니다.

중요한 건 그 다음입니다.

다음 주에 실제로 손을 움직였는지,

A안과 B안 중 무엇을 선택했는지,

기록을 남기기 시작했는지.

진짜 변화는 감정이 아니라 행동에서 확인됩니다.

그래도 분명한 건 있습니다.

"어디서부터 시작해야 할지 모르겠다"는 상태와,

"다음 주까지 뭘 해야 할지 알겠다"는 상태는 완전히 다릅니다.

취업 준비에서 가장 무서운 건 느리게 가는 것이 아닙니다.

아무 방향도 없는 채로 같은 자리를 계속 맴도는 것입니다.

방향이 생기면 속도는 나중 문제입니다.

방향이 없으면 속도는 아예 의미가 없습니다.

없는 경력을 만드는 게 아니라, 있는 경험을 다시 보이게 하는 것

많은 사람들이 정말로 경력이 없어서 막히는 게 아닙니다.

이미 가진 경험이 있는데,

그것이 시장 언어로 정리되지 않아서 막힙니다.

실무 경험은 도메인 이해가 되고,

반복한 업무는 요구사항 감각이 되고,

현업과의 소통 경험은 협업 역량이 됩니다.

경력의 가치가 갑자기 새로 생긴 게 아닙니다.

원래 있던 가치가 제대로 읽히기 시작한 것입니다.

이번 사례는 특정 직무 전환 케이스였지만,

이런 구조는 개발자에게만 필요한 것이 아닙니다.

직무 전환을 준비하는 사람,

실무 경험은 있는데 포지셔닝이 안 되는 사람,

이력서에는 적혀 있는데 강점으로 읽히지 않는 사람 모두에게 똑같이 필요합니다.

저는 이 과정이 결국 번역이라고 생각합니다.

없는 것을 만들어내는 게 아니라,

이미 있는 것을 지원 가능한 형태로 다시 쓰는 일.

그 번역이 되면,

사람의 표정이 달라집니다.

"나는 아무것도 없다"에서

"아, 내가 가진 걸 이렇게 쓸 수 있구나"로 넘어가기 때문입니다.

많은 사람들에게 필요한 건 더 많은 정보가 아니라,

이미 가진 경험을 다시 읽히게 만드는 구조일지도 모릅니다.

비슷한 글

실시간 시뮬레이션에서 가장 먼저 흔들리는 축은 물리 현상보다 시간인 경우가 많습니다. 시간이 흔들리면 데이터의 선후 관계가 흐려지고, 이는 시스템 신뢰도 저하로 직결됩니다. 본 글은 화려한 월드 구성보다 오차 발산을 제어하는 시간 모델을 최우선 전제로 두고, 각 레이어를 데이터 생산 관점으로 정렬하는 설계 관점을 정리합니다.

0. 근본 전제: 오차 발산을 제어하는 시간 모델

초기 설계에서는 엔진 기본 Tick에 의존하기 쉽습니다. 그러나 프레임레이트 변동성은 누적 오차를 만드는 주요 요인이며, 재현성을 떨어뜨립니다.

• 프레임 기반(Variable Step): 환경에 따라 불안정하며 재현성이 확보되기 어렵습니다.
• 고정/통제된 시간 모델(Controlled Timestep): 설계 난도는 높지만 수치적 안정성을 확보할 수 있으며, 장기 실행에서도 결과 발산을 억제하는 검증 가능한 기반이 됩니다.

이 전제가 잡혀야 시뮬레이터는 시각 도구를 넘어 데이터 생산 장치로서 의미를 갖습니다.

1. 월드 레이어: 시각적 재현이 아닌 측정 가능한 좌표계

월드는 배경이 아니라 기준 레퍼런스(Reference Frame)입니다.

• 정밀도 우선: 외부 스캔/지도 데이터를 이식할 때 좌표계와 스케일의 일관성이 무너지면 센서 데이터의 물리적 설명력이 약해집니다.
• 표준화: 원점, 축 방향, 단위를 명확히 규정하여 월드의 퀄리티가 아니라 측정의 정밀도에 집중합니다. 이를 통해 센서 레이어가 단순 렌더링이 아닌 계측 단계로 진입할 수 있습니다.

2. 센서 레이어: 화면 출력이 아닌 측정 장치(Measurement Device)

센서는 시각적 결과물이 아니라, 정의된 규칙에 따라 데이터를 추출하는 측정기로 취급해야 합니다.

• 모델링 분리: 카메라, LiDAR 센서를 구현할 때 렌더링 파이프라인과 물리적 측정 규칙(필터, 노이즈, 왜곡 모델)을 분리합니다.
• 인사이트: 그럴듯한 이미지를 생성하는 것보다, 데이터 생성 조건(Time-stamp, Noise Model)이 명확해야 검증 가능성이 확보됩니다. 조건이 불명확하면 재현성과 검증 가능성이 떨어집니다.

3. 에이전트 레이어: 알고리즘과 동역학의 분리

에이전트의 움직임을 구현할 때 경로 계획(Algorithm)과 물리적 거동(Dynamics)을 분리하여 설계합니다.

• 디버깅 가시성: 의사결정의 문제인지, 제어 및 물리 모델의 한계인지를 구분할 수 있습니다.
• 확장성: 알고리즘을 교체하더라도 물리적 신뢰성을 유지하며 트래픽 모델로 확장할 수 있습니다.

에이전트가 의도대로 움직이더라도, 실시간 시스템에서는 연산 지연과 통신 지연이 인과율을 흔들 수 있습니다.

4. 시스템 동역학 및 지연(Latency) 관리

실시간 시뮬레이션에서 연산 자원과 정확도는 트레이드오프 관계입니다.

• 최적화 전략: 실시간성을 유지하면서 수치해석적 정확도를 유지할 수 있는 임계점을 정의합니다.
• 지연 모델링: 네트워크 송수신/하드웨어 제어에서 발생하는 지연이 인과율에 미치는 영향을 설계 단계에서 고려합니다. 지연이 반영되지 않으면 실제 환경 적용에서 오차가 확대될 수 있습니다.

5. 데이터 레이어: 재현 가능성과 추적성(Traceability)

데이터의 가치는 양이 아니라 수집 조건의 명확성에서 결정됩니다.

• 메타데이터 고정: 좌표계, 타임스탬프, 노이즈 규칙, 시나리오 ID를 결합합니다.
• 구조화: 생성 데이터가 어떤 조건에서 도출되었는지 역추적 가능해야 데이터로서의 자격을 갖습니다.

6. 송수신 레이어: 시스템 인터페이스의 경계 정의

시뮬레이터는 단독 프로그램이 아니라 시스템의 구성 요소입니다.

• 프로토콜 정리: TCP/UDP, gRPC, MQTT, CAN 등 통신 규격과 유실/동기화 규칙을 정의합니다.
• 경계 정의: 입력과 출력의 경계가 잡혀야 검증 가능한 시스템으로 운영할 수 있습니다.

7. 검증 레이어: 폐쇄 루프(Closed-loop)의 완성

검증이 없는 데이터 생산은 반복될수록 왜곡될 수 있습니다.

• 재현성 테스트: 동일 조건에서 동일 결과가 도출되는지(Determinism)를 모니터링합니다.
• 표준 준수: OpenDRIVE, OpenSCENARIO 등 표준 규격을 고려하고 시나리오 기반 엣지 케이스를 검증합니다.

요약하면, 성공적인 디지털 트윈 시뮬레이션은 엔진 성능이 아니라 오차가 발산하지 않는 시간 모델 위에서 각 레이어를 데이터 생산 관점으로 정렬하는 설계 역량에 달려 있습니다. 발산하지 않는 시스템만이 개선과 확장을 허용합니다.

디지털 트윈은 단순한 구현을 넘어, 시간·센서·데이터·검증이 맞물리는 공학적 설계 문제로 확장됩니다.
본 글의 7단계 레이어 설계(시간 모델→월드→센서→에이전트→지연→데이터→연동/검증)를 실제 프로젝트에 적용하거나, 현재 구조의 발산이나 비재현 이슈를 정리하고 싶다면 연락 주시면 됩니다. 멘토링 및 기술 자문도 열어두었습니다.

• Email: chessire@naver.com
• LinkedIn: DM(프로필 링크)

CPU는 연산보다
데이터를 가져오는 방식에
훨씬 민감하다.

CPU 최적화를 연산을 줄이는 일로만 보면, 체감 성능이 잘 안 나옵니다. 실전 병목은 대개 계산(ALU)이 아니라 메모리 접근(Load/Store)에서 터집니다. CPU는 load => execute => add 같은 일을 파이프라인으로 겹쳐서 처리할 수 있지만, 데이터가 제때 도착하지 않으면 실행 유닛은 그냥 놀게 됩니다.

1) 패러다임 전환: 연산이 아니라 물류(Load/Store)가 문제다

CPU 내부엔 역할 분리가 있습니다.

• LSU(Load/Store Unit): 메모리를 읽고/쓰는 담당
• ALU/FPU/SIMD: 실제 계산 담당

코드가 느릴 때 계산량이 많아서일 수도 있지만, 더 흔한 케이스는 이겁니다.

• 계산은 준비됐는데 로드가 늦어서 실행이 멈춘다.
• 실행 중에 다음 데이터를 추가로 로드하려다가 캐시 미스로 브레이크가 걸린다.

그래서 최적화의 시작점은 연산 줄이기가 아니라 캐시 히트율을 올리는 데이터 배치입니다.

2) 캐시의 작동 원리: CPU는 64B ‘박스’ 단위로 움직인다

캐시는 바이트 단위로 움직이지 않습니다. 보통 캐시 라인(Cache Line) 단위(대부분 64B)를 최소 단위로 가져오고 버립니다.

여기서 지역성이 나옵니다.

• 공간 지역성(Spatial): 다음에 접근할 메모리가 인접해 있다.
• 시간 지역성(Temporal): 방금 접근한 메모리를 곧 다시 쓴다.

즉, 우리가 코드를 예측 가능하게 만든다는 말의 실체는 대부분 이겁니다.

• 인접 데이터를 연속으로 쓰게 만들고(공간)
• 최근에 쓴 데이터를 다시 쓰게 만들면(시간)
• 캐시 히트율이 올라가고, 로드 지연이 줄어듭니다.

3) 예측 실패보다 무서운 설계 실수: 캐시 미스는 4C로 보자

교과서적 분류는 3C(Cold/Capacity/Conflict)지만, 멀티코어까지 다루려면 4C가 더 정합적입니다.

4C Cache Miss

1. Cold (Compulsory) Miss
   처음 접근이라 캐시에 없어서 발생.
2. Capacity Miss
   캐시 용량 자체가 부족해서, 담아두지 못하고 밀려남.
3. Conflict Miss
   캐시에 공간은 있는데 매핑/세트 충돌 때문에 교체가 과하게 발생.
   특히 stride 패턴이 캐시 인덱스와 맞물리면 계속 갈아엎는 현상이 나옵니다.
4. Coherency Miss (일관성 미스)
   다른 코어가 내가 들고 있던 캐시 라인을 수정해서 Invalidate가 걸린 경우.
   이게 나중에 말할 False Sharing의 바로 그 뿌리입니다.

여기서 중요한 건, 미스를 예측 실패 하나로 뭉개면 원인 진단이 틀어진다는 점입니다.
Capacity인지, Conflict인지, Coherency인지에 따라 처방이 완전히 달라집니다.

4) Stride 프리패처: CPU는 일정 보폭을 좋아한다

하드웨어 프리패처는 다음 줄을 무조건 읽어오기만 하지 않습니다. 규칙적인 보폭(Stride)을 학습합니다.

예를 들어:

• [0] -> [4] -> [8] -> [12] 처럼 일정하면
  → 4칸씩 뛴다는 점을 학습하고 미리 끌어옵니다.

반대로,

• stride가 너무 크거나(Large Stride)
• 접근 주소가 불규칙하게 튀면(Random)
  → 프리패처가 포기하거나 정확도가 떨어집니다.

이 지점이 CPU가 좋아하는 데이터 배치의 현실적인 기준입니다.
연속 배열 + 규칙적 루프는 프리패처, 캐시, SIMD까지 한 번에 정렬됩니다.

5) 구조체 설계의 정석: 무조건 alignas가 아니라 데이터 구겨넣기(Packing)가 먼저다

정렬(Alignment)은 분명 도움이 됩니다. 특히 캐시 라인을 걸치지 않게 만들거나, 멀티스레드에서 라인 공유를 피하는 데도 쓰입니다. 하지만 무작정 alignas(64)부터 박으면 이런 문제가 생깁니다.

• 구조체가 작아도 64B 패딩이 붙어 캐시 오염(cache pollution)이 생김
• 결과적으로 실제 유효 데이터 대비 로드량이 늘어서 히트율이 떨어질 수 있음

그래서 우선순위는 보통 이 순서가 맞습니다.

1. 필드 재배치 / 타입 정리로 패딩을 줄인다.
2. 남는 공간은 자주 쓰는 필드로 메꿔서 64B를 꽉 채운다. (패킹)
3. 그래도 필요할 때만 alignas(64) 같은 강제 정렬을 쓴다.

그리고 여기서 다음 글 떡밥이 자연스럽게 이어집니다.

• 구조체를 64B 정렬하는 이유는 속도만이 아니라
  멀티코어에서 False Sharing(거짓 공유)를 피하기 위한 목적도 큽니다.
  (서로 다른 스레드가 같은 캐시 라인을 건드리면 Coherency Miss가 폭발합니다.)

6) AoS vs SoA: 데이터의 본질이 아닌 접근 패턴으로 결정한다

여기서 정답을 단정하면 항상 사고가 납니다. 결론은 하나입니다.

AoS/SoA는 취향이 아니라,
루프의 형태로 결정한다.

AoS (Array of Structures)

• 개체 하나를 잡고 여러 필드를 같이 만지는 패턴에 유리
• 단점: 특정 필드만 훑을 때 불필요한 데이터까지 같이 로드될 수 있음

struct Agent { float pos, vel, health; };
Agent agents[100];

SoA (Structure of Arrays)

• 같은 필드를 대량으로 훑는 패턴(예: pos만 10만 개 업데이트)에 유리
• 장점: 캐시/프리패처/SIMD와 궁합이 좋은 경우가 많음
• 단점: 개체 단위로 여러 필드를 동시에 만지면 오히려 산개 접근이 될 수 있음

struct AgentGroup { float pos[100], vel[100], health[100]; };

※ 참고로 Epic Games의 Unreal Engine 쪽에서 ECS 계열(예: Mass 같은 접근)을 떠올릴 수 있는데, 엔진 기능 자체보다 중요한 건 “내 루프가 무엇을 연속으로 훑는가”입니다. 기능 이름보다 접근 패턴이 먼저입니다.

7) 현대 하드웨어의 복잡성: L3 포함 정책은 유연해지는 추세

마지막으로, 멀티코어 시대에 L3 정책 이야기를 안 하면 반쪽입니다.

• L1/L2: 코어 전용, 빠르고 작음
• L3: 여러 코어가 공유, 상대적으로 크고 느림

여기서 Inclusive / Non-Inclusive 얘기가 나오는데, 포스팅에서 중요한 태도는 이겁니다.

• 제조사별 경향성은 참고 가치가 있지만
• 최근에는 코어 수 증가와 L3 효율 문제 때문에
  두 진영 모두 정책을 더 유연하게 가져가는 추세라는 점을 같이 적는 게 신뢰도가 높습니다.

즉, 브랜드로 단정하기보단 마이크로아키텍처/제품군 기준으로 확인하는 게 맞습니다.
(특히 서버/워크스테이션 라인업은 정책이 다르게 나타나는 경우가 많습니다.)

여기서 Intel / AMD 비교를 할 때도 단정이 아니라 확인이 핵심입니다.

이 글의 결론, “캐시를 설계하라”

CPU 최적화는 결국 이 두 문장으로 요약됩니다.

1. 연산보다 로드가 먼저 병목이다.
2. 캐시는 라인 단위로 움직이고, 미스는 4C로 구분해야 한다.

다음 글에서 이어설명할 주제는 아래와 같습니다.

• Coherency Miss와 False Sharing
• 왜 alignas(64)가 속도가 아니라 멀티코어 안정성의 문제인지
• 그리고 멀티스레드에서 캐시 라인을 어떻게 분리/배치할지

이전글

다음글

Coherency Miss(일관성 미스)로 보는
캐시 라인 전쟁과 해결 전략,
alignas(64)는 속도가 아니라
멀티코어 안정성이다.

싱글 스레드 최적화는 보통 캐시 히트율로 설명이 끝납니다.
하지만 멀티스레드에 들어가면 캐시 미스의 얼굴이 하나 더 늘어납니다.

Coherency Miss(일관성 미스).

이건 캐시에 없어서가 아니라, 다른 코어가 내 캐시 라인을 건드려서 내 캐시가 무효화(invalidate)되는 미스입니다. 즉, 데이터가 원래 캐시에 있었는데도, 멀티코어 환경 때문에 있었지만 없어진 것이 됩니다.

1) Coherency Miss란 무엇인가

멀티코어 CPU는 각 코어가 L1/L2 같은 빠른 캐시를 따로 들고 있습니다.
그럼 문제가 생겨요.

• 코어 A가 어떤 메모리 주소 X를 캐시에 들고 있음
• 코어 B도 같은 주소 X를 캐시에 들고 있음
• 코어 B가 X를 쓰기(write) 하면?
• 코어 A가 들고 있던 X는 더 이상 최신이 아님

그래서 CPU는 캐시 일관성 프로토콜(MESI 계열)로 누가 최신인지를 맞춥니다.
이때 흔히 일어나는 현상이:

• invalidate(무효화): 다른 코어가 수정한 라인을 내 캐시에서 폐기
• 다음에 내가 읽을 때는 다시 가져와야 함 → coherency miss

이게 Coherency Miss의 정체입니다.
핵심은 데이터가 멀리 있어서 느린 게 아니라, 서로 방해해서 느린 것입니다.

2) False Sharing: 같은 데이터를 공유한 적이 없는데 공유가 발생한다

False Sharing(거짓 공유)은 더 악질입니다.

두 스레드가 서로 다른 변수를 쓰는데도 느려져요.
왜냐하면 캐시는 변수 단위가 아니라 캐시 라인(보통 64B) 단위로 일관성을 맞추기 때문입니다.

예를 들어, 같은 캐시 라인 안에 아래 두 변수가 들어있다고 하자.

• counterA (스레드 A가 계속 증가)
• counterB (스레드 B가 계속 증가)

둘은 다른 변수고, 논리적으로는 공유가 아닙니다.
하지만 캐시 라인 단위로 보면 둘은 같은 64B 박스 안에 들어 있음.

그러면 벌어지는 일:

1. 스레드 A가 counterA++
   → 해당 캐시 라인(64B)을 쓰기 가능한 최신 상태로 만들기 위해 독점화
2. 스레드 B가 counterB++
   → 똑같은 캐시 라인을 독점화하려고 함
   → A 쪽 라인 invalidate
3. A가 또 counterA++
   → 다시 라인 가져오고 invalidate 반복

이게 흔히 말하는 ping-pong입니다.
캐시가 공처럼 튕기면서 coherency 트래픽이 폭발하고, 성능이 급격히 떨어집니다.

즉, False Sharing은 데이터 공유가 아니라
캐시 라인 공유가 문제입니다.

3) 왜 alignas(64)는 속도가 아니라 안정성인가

많은 사람들이 alignas(64)를 빠르게 하려고 붙입니다.
하지만 멀티스레드에서 alignas(64)의 진짜 목적은 다른 쪽입니다.

서로 다른 스레드가 쓰는 데이터가 같은 캐시 라인에 들어가지 않게 보장하는 것.

즉, False Sharing을 구조적으로 차단하는 장치입니다.

여기서 속도라는 표현이 위험한 이유가 있어요.

• 싱글 스레드에서 alignas(64)는 오히려 패딩이 늘어 캐시 효율을 떨어뜨릴 수 있음
• 멀티스레드에서 alignas(64)는 패딩을 감수하더라도 coherency 폭발을 막아 성능을 안정화함

그래서 alignas(64)는 평균 성능 상승이 아니라
최악의 경우를 제거하는 안정성 장치에 가깝습니다.

4) 멀티스레드에서 캐시 라인을 분리/배치하는 실전 전략

아래는 현업에서 바로 적용하는 순서입니다.

(1) 쓰기를 분리하라: write-hot 데이터부터 격리

False Sharing은 거의 항상 write-write 또는 write-read에서 터집니다.
그래서 먼저 찾아야 하는 건:

• 여러 스레드가 자주 쓰는 변수(카운터, 플래그, 상태값, work queue head/tail 등)

이런 변수는 각 스레드 전용 구조체로 분리하거나, 최소한 캐시 라인을 분리해야 합니다.

(2) Thread-local(스레드 로컬)로 바꾸고 마지막에 합쳐라

공유 카운터를 매번 증가시키는 대신:

• 스레드별 로컬 카운터에 누적
• 프레임 끝/작업 끝에 한 번 합산(reduction)

이건 캐시 최적화라기보다 coherency 최적화입니다.

(3) 구조체를 역할로 쪼개라: read-mostly vs write-hot

AoS/SoA와 같은 결로, 멀티스레드에서도 데이터는 성격이 갈립니다.

• read-mostly(거의 안 변함): 공유해도 비교적 안전
• write-hot(자주 변함): 공유하면 폭발

write-hot만 따로 빼서 alignas(64)를 주는 식으로,
전체 구조체에 무작정 패딩을 박지 않는 게 포인트입니다.

(4) 캐시 라인 패딩 패턴(실전 템플릿)

가장 흔한 패턴:

struct alignas(64) ThreadCounter
{
	std::atomic<uint64_t> value;
	char pad[64 - sizeof(std::atomic<uint64_t>)];
};

핵심은 변수 하나를 64B 박스 하나에 고정시키는 것.
이러면 서로 다른 스레드의 카운터가 같은 라인에 섞일 일이 없습니다.

(5) 큐/링버퍼는 헤더와 테일을 분리한다

멀티프로듀서/멀티컨슈머 구조에서 자주 터지는 포인트가:

• head / tail
• size / flags

이런 메타데이터가 같은 캐시 라인에 붙어있으면 False Sharing이 쉽게 납니다.
헤더와 테일을 다른 캐시 라인으로 분리하면 체감이 크게 바뀌는 경우가 많습니다.

5) 체크리스트: 이 증상이면 False Sharing을 의심해라

• 스레드를 늘렸는데 성능이 안 오르거나 오히려 떨어진다
• CPU 사용률은 높은데 처리량이 늘지 않는다
• 특정 공유 카운터/플래그를 제거하면 성능이 갑자기 좋아진다
• 동일 코드를 단일 스레드로 돌리면 안정적이다

이 경우는 연산 최적화가 아니라
coherency/false sharing 최적화를 먼저 의심하는 게 맞습니다.

마무리

Coherency Miss와 False Sharing은 캐시가 부족해서가 아니라
캐시가 서로 싸워서 생기는 성능 붕괴입니다.

그래서 alignas(64)는 “빠르게 만들기”가 아니라
멀티코어에서의 안정성(최악 제거)을 위한 설계 도구입니다.

다음글

기술 블로그를
AI로 운영한 3개월
그리고 솔직한 숫자

시간을 줄이면 퀄리티가 떨어진다고 생각했습니다.
아니었습니다.

마케터도 작가도 아닌데

 
AI 관련 영상이나 글을 보면 다들 쉽게 되는 것처럼 보입니다. 프롬프트 하나 넣으면 기획서가 나오고, 버튼 하나로 콘텐츠가 완성됩니다. 그런데 막상 내 업무에 대입해보면 뭔가 어긋납니다. 결과물이 어색하거나, 어디서부터 시작해야 할지 모르겠거나. 저도 그랬습니다. 마케터도 아니고 작가도 아닌데, 블로그를 제대로 운영할 수 있을까 싶었습니다.
 
개발자로 십수 년을 살았습니다. 글을 잘 쓴다는 말을 들어본 적도 없고, 콘텐츠 기획이라는 개념은 더더욱 낯설었습니다. 기술 블로그는 쓰는 사람이 좋아서 쓰는 거지, 운영이라는 단어를 붙이기엔 어딘가 거창한 느낌이었습니다. 그냥 알고 있는 걸 정리해서 올리는 공간 정도로 생각했습니다. 꾸준히 쓰는 것만으로도 충분하다고 스스로를 설득하면서요.
 
그런데 12월부터 방식을 바꿨고, 3개월이 지났습니다.

비수기에 나온 숫자

1월 374PV, 2월 694PV. 한 달 사이 86% 성장입니다.

 
숫자를 꺼내기 전에 맥락을 하나 짚겠습니다. 기술 블로그는 구조적으로 PV가 낮은 장르입니다. 타겟이 좁고, 검색 유입도 느리고, 바이럴이 거의 없습니다. 일반적인 라이프스타일 블로그나 재테크 블로그와 단순 비교하기 어려운 장르입니다. 게다가 이 기간은 블로그 비수기였습니다. 연초는 대부분의 기술 블로그가 조용해지는 시기거든요. 검색량도 줄고, 새로운 유입도 뜸해집니다. 그 타이밍에 이 숫자가 나올 줄은 저도 솔직히 몰랐습니다.
 

 
참여율 40%대도 마찬가지입니다. 기술 글은 훑고 나가는 독자가 많습니다. 제목 보고 들어왔다가 첫 문단에서 이탈하는 경우도 흔합니다. 40%면 끝까지 읽는 사람이 상당하다는 뜻입니다. 시간을 줄였는데 오히려 더 읽히는 글이 됐다는 게 스스로도 흥미로웠습니다. 퀄리티를 지키면서 속도를 올리는 게 가능하다는 걸, 숫자로 확인한 순간이었습니다.

방향을 잡는 쪽은 언제나

글을 쓰기 전에 AI와 먼저 이야기합니다. 주제 선정부터 같이 합니다. 이 글이 지금 나올 타이밍인지, 비슷한 글과 어떻게 달라야 하는지를 먼저 검토합니다. 단순히 "이런 글 써줘"가 아니라, 시장에서 이 글이 어떤 위치를 가질 수 있는지를 같이 따져봅니다.
 
실제 사례가 있습니다. GPU 역사 시리즈를 연재하던 중에 UE5 편을 쓸 시점이 됐을 때, AI와 함께 이 글이 링크드인에서 반응을 얻을 수 있는지 분석했습니다. 기술 직군 독자들이 어떤 맥락에서 이 주제에 관심을 가질지, 어떤 각도로 접근하면 공유가 일어날 수 있는지를 같이 정리했습니다. 그 예측이 정확히 통했습니다. 운이 아니라 기준이 있었습니다.
 
주제가 잡히면 저는 5분 안에 초안 구조를 씁니다. 완성된 글이 아니어도 됩니다. 흐름만 잡히면 됩니다. 그걸 AI에게 넘기고, 나온 결과물을 다시 다른 AI와 함께 교차검토합니다. 퇴고까지 끝내면 글 한 편에 30분 내외입니다. 이미지 생성, 태그, slug 추천까지 포함해서입니다. 예전에 글 한 편 쓰는 데 몇 시간씩 붙잡혀 있던 것과는 완전히 달라진 흐름입니다.
 
중요한 건 AI가 글을 쓴 게 아니라는 겁니다. 구조는 제가 잡았고, AI는 그 위에서 움직였습니다. 무엇을 쓸지, 왜 이 순서인지, 어떤 독자를 향한 글인지는 전부 제가 결정했습니다. AI는 그걸 실행하고 다듬는 역할이었습니다. 편집자 겸 마케터와 일하는 느낌이었는데, 방향을 잡는 쪽은 언제나 저였습니다. 그 차이가 결과물의 밀도를 갈랐다고 봅니다.

순서가 가지는 의미

ChatGPT로 초안을 잡는 건 객관적인 거리를 만들어주기 때문입니다. 제 생각에 너무 가깝게 붙어 있으면 글이 좁아지는데, ChatGPT가 그 거리를 잡아줬습니다. 지금은 Claude로 같은 역할을 가져왔고요.
 
Gemini는 다른 이유로 씁니다. 구글 검색 중심으로 학습된 모델이다 보니, 일반 독자가 어떻게 읽을지를 체크하는 데 쓸 만합니다. ChatGPT로 파고들고, Gemini로 대중성을 살짝 곁들이는 식입니다.
 
부수적으로는 Gemini, ChatGPT, 그리고 저 셋이서 돌아가며 교차검증을 하니까 할루시네이션이 걸러지기도 하고요.
 
도구를 많이 쓴 게 아니라, 각 도구가 잘 하는 걸 구분해서 배치한 겁니다.

십수 년이 남긴 감각

십수 년을 개발자로 일하면서 비개발 직군과 항상 같이 일했습니다. 기획자, PM, 마케터, 운영팀. 그분들의 언어로 기술을 설명하고, 업무 흐름에 맞춰 개발 결과물을 이어붙이는 게 일상이었습니다. 다양한 도메인을 거치면서 자연스럽게 생긴 감각이 있습니다. 개발을 모르는 현직자가 새로운 도구 앞에서 어디서 막히는지, 그리고 그 막히는 지점을 어떻게 돌아갈 수 있는지에 대한 감각입니다.
 
AI 앞에서도 비슷한 장면이 반복됩니다. 영상 보고 따라 해봤는데 내 업무엔 안 맞았던 경험, 결과물은 나왔는데 어딘가 어색해서 쓰질 못하는 경험. 막히는 지점이 도구가 아니라 구조에 있는 경우가 대부분입니다. 내 업무의 흐름을 먼저 잡고, 그 위에 AI를 얹는 순서가 필요한데, 그 순서를 잡는 방법을 가르쳐주는 곳이 많지 않습니다. 대부분의 AI 교육이 도구 사용법에서 멈추는 이유이기도 합니다.
이번에 블로그를 직접 운영하면서 다시 확인한 것들이었습니다. 코딩이 하나도 없는 워크플로우로, 기술 블로그 비수기에 86% 성장이 가능했습니다. 이게 블로그만의 이야기가 아니라는 걸, 기획서를 쓰고 보고서를 만들고 콘텐츠를 생산하는 현직자라면 아마 감이 오실 겁니다.

비슷한 글

빠르게 생성하고, 다시 검증한다.
프로세스가 만들어내는 리뷰 품질

 지난 포스팅인 [개발자의 종말, 구현자의 시작]에서 언급했던 AI 워크플로우를 기억하시나요? 단순히 코드를 짜는 단계를 넘어, 이제는 전체적인 시스템을 설계하고 AI를 적재적소에 배치해 효율을 극대화하는 구현자(Implementer)의 시대가 왔음을 말씀드렸습니다.
 오늘은 그 철학을 실천에 옮긴 사례를 공유하려 합니다. 바로 저에게 할당된 십수 명의 언리얼 엔진 수강생을 위한 'AI 코드 리뷰 시스템' 구축기입니다. 여러 프로젝트를 동시에 코드 리뷰하는 물리적 한계를 어떻게 Cursor와 프롬프트 엔지니어링으로 개선했는지, 제가 정의한 5단계 워크플로우에 맞춰 설명해 보겠습니다.

1. 요구사항 분석 (Requirement Analysis)

"물리적 한계와 품질 사이의 갈등"
 십수 명의 학생이 제출하는 코드를 매주 혼자 리뷰하면서 일관된 품질을 유지하는 것은 현실적으로 고부하입니다. 하지만 교육자로서 '대충' 할 수는 없죠. 제가 정의한 핵심 요구사항은 다음과 같았습니다.

• 일관성: 리뷰어의 컨디션에 상관없이 동일한 기준(심각도, 컨벤션 등) 유지.
• 근거 중심: "이게 더 좋아요" 식의 추상적 조언이 아닌, 정확한 파일 위치와 라인을 명시할 것.
• 성장 가이드: 단순 오타 수정을 넘어 다음 제출물에서 개선해야 할 '학습 방향성' 제시.

2. 설계 (Design)

"멀티 스테이지 검증 시스템"
 AI의 가장 큰 적은 '할루시네이션(환각)'입니다. 할루시네이션 가능성을 낮추기 위해 단일 프롬프트가 아닌 [리뷰 생성 => 리뷰 검증]이라는 2단계 구조를 설계했습니다. 또한, 이전 버전의 코드와 현재 버전을 비교 분석할 수 있는 '비교 모드'를 도입해 실력 향상 폭을 측정하도록 기획했습니다.

3. 프롬프트 작성 (Prompt Engineering)

"룰은 강제하되, 관찰에 기반할 것"
 설계한 내용을 바탕으로 Cursor에서 사용할 두 가지 핵심 프롬프트를 작성했습니다.

코드 리뷰 프롬프트

 이 프롬프트는 리뷰의 '뇌' 역할을 합니다. 추측성 표현을 철저히 금지하고, 모든 지적에 대해 (파일경로:라인범위) 근거를 요구합니다. 특히 Blocking(필수 수정)과 Non-blocking(권장)을 명확히 구분해 학생이 우선순위를 파악할 수 있게 했습니다.

코드 리뷰 검증 프롬프트

  AI가 작성한 리뷰를 다시 AI가 검사하는 '감시자' 프롬프트입니다. 1차 리뷰는 생산성을 위해 생성하고, 2차 검증은 형식 / 근거 / 금지 표현 위반을 줄여 결과물 편차를 낮추기 위해 분리했습니다. 룰 누락은 없는지, 섹션이 붕괴되거나 표현이 일탈되는 등, 리뷰의 룰 위반을 줄여 일관성을 확보합니다. code-review-tutoring.md가 변경 및 확장될 때, 리뷰 결과물이 룰을 계속 준수하는지 점검하는 장치로 사용합니다.

4. 튜닝 및 검증 (룰 준수)

"AI가 놓친 것은 없는가?"
 실제 수강생의 코드를 넣어보며 프롬프트를 튜닝했습니다. 처음에는 AI가 지나치게 관대한 피드백을 남기는 경향이 있어, 문장 톤은 단정하게 유지하되, 지적은 구체적 근거와 영향 중심으로 나오도록 규칙을 강화했습니다. 그래서 개인 평가 / 감정 표현 금지 룰을 강화해 철저히 "사실 => 근거 => 영향"의 구조로 출력되도록 교정했습니다.
 verify 프롬프트는 단순한 검사를 넘어, 시스템의 확장성을 담보하는 장치가 되었습니다. '학습 방향성'이나 '코드 퀄리티 분석' 같은 새로운 평가 기준을 추가할 때마다, 이 감시 장치가 결과물의 형식이 무너지지 않도록 파수꾼 역할을 해주었기 때문입니다.

5. 사용 (Usage)

# path1에 있는 코드들에 대해 코드 리뷰를 진행
/code-review-tutoring @path1

# path1에 대한 코드 리뷰를 진행하고 path2(이전 버전)와 비교하여 코드 퀄리티 변화도 출력
/code-review-tutoring @path1 @path2

# 직전 리뷰 텍스트에 대해 룰 위반 여부만 분석
/verify-code-review-tutoring

 
"튜터의 역할: 최종 큐레이터"
 이제 저는 여러 프로젝트의 코드를 처음부터 끝까지 읽는 대신, AI가 정리해 준 [강점/약점/학습 방향성] 보고서를 먼저 검토합니다.

1. Cursor가 프롬프트에 따라 1차 리뷰 생성.
2. 검증 프롬프트로 룰 위반 여부를 체크.
3. 최종적으로 제가 내용을 분석하고 정제하여 학생에게 전달.

  Agent 사용 이전에는 한명의 코드 리뷰를 진행하는데에 30분에서 1시간 이상이 소모되었습니다. 시간이 부족하면 근거(파일 / 라인)까지 정교하게 남기기 어려웠습니다. 하지만 이러한 리뷰 시스템을 도입한 후에는 Cursor가 언급한 코드와 그 근처 코드들만 읽으면 되었고, 해당 코드가 왜 좋은 코드인지에 대한 리뷰 근거(파일:라인 / 함수 / 클래스)와 영향 설명을 함께 제공했습니다. 핵심 구간을 우선 확인할 수 있게 된 것입니다. 그래서 저는 더 짧은 시간에 근거 기반으로 코드 리뷰를 진행할 수 있었습니다. 그렇게 학생들은 훨씬 더 구체적이고 일관된 피드백을 받을 수 있게 되었습니다.

마치며: 구현자로서의 첫걸음

 이 시스템은 단순히 업무를 자동화한 것이 아닙니다. 튜터라는 역할을 수행함에 있어 나의 전문성이라는 엔진을 AI라는 부스터에 달아 효율을 극대화한 결과물입니다.
 수강생 십수 명에 대한 코드 리뷰가 소모만 되는 작업이 되지 않도록 반복되는 분석, 정리 파트를 자동화하고 저는 판단이 필요한 지점(설계 의도, 트레이드오프, 학습 방향성)에 시간을 더 배분할 수 있게 되었습니다. 오히려 더 깊이 있는 가이드에 집중할 여력이 생겼죠. 여러분도 본인의 업무에서 반복되는 '분석과 정리'의 패턴을 찾아보세요. 그것이 바로 여러분이 '구현자'로서 첫발을 내디딜 지점입니다.

긴 글을 마무리하며, 이 워크플로우가 어떤 분들에게 특히 필요했는지 궁금합니다.
아래 중 어디에 해당하시나요? 번호로 댓글만 남겨주시면 큰 힘이 됩니다.

1. 현업 개발자: PR/코드리뷰가 병목이고, 근거 기반 리뷰 표준화가 필요하다.
2. 팀 리더 / 테크리드: 리뷰 품질을 개인 역량이 아니라 팀 프로세스로 만들고 싶다.
3. 1인 / 프리랜서 / 창업 준비: 반복되는 분석·정리를 줄이고 납기/품질을 안정화하고 싶다.
4. 관심 독자: AI 워크플로우/프롬프트 설계 사례를 계속 보고 싶다.

현재 진행 중인 업무에 AI를 접목시킬 때, 어디를 자동화하고, 어디서 사람이 판단해야 하는지 설계가 고민이라면

방명록(또는 이메일)로 편하게 남겨주세요.

방명록 바로가기

이메일 주소 : chessire@naver.com

이전글

UE5, 성능 손실 없이 더 많은 디테일을.
그리고 완전한 동적 라이팅을 향해.

 UE4 후기에서 DX11(SM5)은 Compute Shader로 고정된 파이프라인의 틀을 느슨하게 만들었습니다. 반면 Tessellation은 더 많은 기하 디테일을 가능하게 했지만 성능, 크랙, 편차라는 숙제를 남겼습니다.

 UE5는 DX12 시대의 조건에서 "성능 손실 없이 더 많은 디테일을, 그리고 완전한 동적 라이팅을" 이라는 도전을 하게 됩니다. 언제나 핵심은 구조 변화입니다. DX12는 GPU 작업을 드라이버가 자동 최적화해주던 시대에서 엔진이 명시적으로 자원을 배치하고 스케줄링하는 시대로 전환시켰습니다. 그렇게 Nanite와 Lumen은 이 전환을 전제로 설계되었습니다. 그 결과, 렌더링 파이프라인의 고정된 경계가 이전보다 훨씬 약해질 수 있었습니다.

UE4에서 남은 숙제: 디테일과 라이팅

 UE4 후기의 DX11(SM5)은 Compute Shader를 통해 고정 파이프라인 외 연산 모델을 제공했고, Tessellation은 기하 디테일을 실시간으로 늘릴 수 있게 했습니다. 하지만 이 두 축은 어디까지나 가능성이었지 기본값은 아니었습니다. Tessellation은 성능 비용이 컸고, 크랙과 균열 문제와 하드웨어 편차도 존재했습니다. 또한 동적 라이팅은 여전히 제작 파이프라인에서 타협이 요구되는 영역이었습니다.

UE5는 이 숙제를 DX12 시대의 운영방식 위에서 다시 설계하였습니다.

 많은 최적화가 드라이버 레이어에서 흡수되었던 DX11과는 달리 DX12에서는 자원 상태 전이(배리어), 파이프라인 상태(PSO), 리소스 바인딩 같은 비용을 엔진이 더 직접 관리하는 방향으로 움직였습니다. 이 변화는 기능 하나의 추가라기보다는 렌더러 설계가 CPU와 GPU의 협업(Scheduling, Batch, Caching) 중심으로 이동했다는 의미가 큽니다.

 여기에 SM6의 Wave Intrinsics는 같은 웨이브(실행 그룹) 안의 lane들이 데이터를 교환 / 집계하는 연산을 가능하게 해 컬링이나 희소 데이터 패킹 같은 알고리즘에서 유리한 도구가 되었습니다. UE5의 바로 이런 Compute 중심, 데이터 지향 설계가 전제된 시대에 맞춰 Nanite와 Lumen가 탄생하게 되었습니다.

Nanite: 기하 디테일 문제를 바꾸다.

 에픽게임즈는 Nanite를 가상화된 기하(Virtualized Geometry) 시스템으로 정의했습니다. 내부 메시 포맷과 렌더링 기술을 사용해 픽셀 스케일 디테일과 높은 오브젝트 수를 목표로 하며 화면에 보이는 디테일만 처리하도록 설계되었습니다. 또한 포맷은 고압축일뿐더러 세밀한 단위의 스트리밍과 자동 LOD까지 지원합니다.

 이러한 내용이 중요한 이유는 UE4의 Tessellation이 표면을 더 쪼개는 증분적 디테일이었다면 Nanite는 디테일을 가진 원본을 받아들이되 런타임에서 가시성과 스트리밍으로 비용을 제어한다는 운영적 디테일로 축이 이동했기 때문입니다. 즉, UE5는 디테일을 늘리는 기술을 셰이더 단계의 기교가 아니라 데이터 포맷과 스트리밍, 그리고 컬링 파이프라인 전체의 문제로 끌어올리게 됩니다.

 Nanite가 해결하려는 문제는 삼각형을 더 그리는 법이 아닙니다. 삼각형이 너무 많아진 시대에 "그것을 어떻게 운영할 것인가?"라는 물음에 대한 해법입니다. 즉, 내부 포맷으로 잘게 쪼개진 기하 데이터를 필요한 순간에만 스트리밍하고, 화면에 기여하지 않는 단위를 대규모로 컬링하며, 그 결과를 GPU 중심으로 빠르게 누적하고 결정해야 합니다.

 이런 구조에서는 리소스 상태 전이나 바인딩, 파이프라인 상태 같은 비용이 반복적으로 등장할 수 밖에 없고, 이를 엔진이 명시적으로 통제하지 못하면 운영 자체가 불가능해집니다. 그래서 Nanite는 DX11처럼 드라이버 최적화에 기대기보다는 DX12의 명시적 모델 위에서 스케줄링, 배치, 캐싱을 엔진이 직접 설계하는 방향을 전제로 하게 됩니다. 또한 SM6의 웨이브 단위 협업은 이런 대규모 컬링과 패킹 과정에서 같은 실행 그룹 내부의 데이터 집계를 더 효율적으로 만들 수 있는 기반이 됩니다.

 이 지점에서 DX12(SM6)는 선택이 아니라 조건이 됩니다. 왜냐하면 Nanite는 얼마나 많은 삼각형을 그릴 수 있는지를 넘어, 보이는 클러스터만 남기고 나머지는 버리는 GPU 주도 파이프라인을 전제하기 때문입니다.

Lumen: Bake 대신 Realtime을 기본값으로

 에픽 문서를 보게되면 Lumen은 디퓨즈 간접광을 해결하며, 표면에서 반사된 색이 주변에 번지는 컬러 블리딩과 메시가 간접광을 가려 생기는 간접 그림자까지 포함한다고 하였습니다. 또한 반사(Reflections)까지 포함해 "동적 GI + 동적 반사"를 하나의 시스템으로 다룬다는 것을 설명합니다.

 Lumen의 핵심은 동적 GI와 동적 반사를 옵션으로 더하는 것이 아니라 장면 변화(시간, 조명, 오브젝트, 카메라)에 따라 라이팅을 지속적으로 갱신하는 것을 기본 전제로 둔다는 점입니다. 이때 엔진은 광원, 표면, 가시성 정보를 반복적으로 업데이트하고, 그 과정에서 생성되는 데이터를 안정적인 GPU 작업으로 스케줄링 해야 합니다.

 DX11처럼 많은 비용이 드라이버 레이어에서 흡수되던 모델에서는 이런 지속 갱신이 커질수록 제어가 어렵고, 반대로 DX12에서는 엔진이 배리어와 PSO, 리소스 바인딩을 포함한 실행 흐름을 명시적으로 설계할 수 있기 때문에 시스템 차원에서 동적 라이팅을 기본값으로 유지하는 운영 방식을 만들 수 있었습니다.

 즉, Lumen은 단지 새로운 조명 기법이 아니라 DX12 시대의 엔진이 운영하는 방식을 전제로 성립하는 시스템입니다.

 그렇기에 UE5 신규 프로젝트에서는 기본적으로 활성화되지만 기존 레거시로 인해 UE4에서 UE5로 변환한 프로젝트에서는 자동으로 활성화되지 않습니다. 이는 기존 프로젝트의 라이팅 패스를 망가뜨리거나 변경하지 않기 위한 조치로 명시되어 있습니다. 즉, Lumen은 단순한 옵션이 아니라, 제작 파이프라인의 기준선을 바꾸는 기능으로 취급됩니다.

 UE4에서 동적 광원 수를 늘리는 접근이 CS 기반 컬링 같은 최적화를 요구했다면, UE5는 그 연장선에서 "동적 라이팅 그 자체를 기본값으로 두려면 무엇이 필요한가?"를 끊임없이 고찰하여 시스템차원으로 풀어낸 결과로 Lumen을 선보이게 됩니다.

맺음말

 UE4(DX11 / SM5)는 고정 파이프라인을 깨기 시작했지만, 여전히 LOD는 사람이 설계하고, 라이팅은 베이크에 기대어 있었습니다. 하지만 UE5의 Nanite와 Lumen은 이 전제를 흔들었습니다.

• 기하는 LOD 설계에서 가상화와 가시성 기반 운영으로 이동한다.
• 라이팅은 베이크된 정답에서 실시간 해답을 기본 목표로 둔다.

 따라서 UE5를 이해하는 핵심은 기능 소개가 아닙니다. DX12(SM6) 시대에 엔진이 GPU를 운영하는 방식이 바뀌어버렸고, Nanite와 Lumen은 그 운영 방식에 맞춰 렌더링을 데이터와 시스템 문제로 재정의 했다는 점에서 시사하는 바가 큽니다.

고정된 형식을 넘어 유연함을 추구하며 발전하는 GPU와 언리얼 엔진. 발전에는 끝이 없겠지만, 앞으로가 기대가 되는 GPU의 역사 시리즈를 마치겠습니다.

긴 시리즈를 마무리하며, 이 기술적 흐름에 공감해 주신 분들이 어떤 분들인지 궁금합니다.
아래 중 어디에 해당하시나요? 번호로 댓글만 남겨주시면 큰 힘이 됩니다.

1. 취준생 / 학생: 엔진 내부 원리를 파헤쳐 압도적인 포트폴리오를 만들고 싶다.
2. 현업 개발자: UE5 운영에서 최적화 vs 효율 사이에서 고민 중이다.
3. 기술 결정권자: 엔진과 GPU 흐름을 읽고 팀의 기술 방향을 정해야 한다.
4. 그 외 / 관심 독자: 일단 시리즈가 재미있어서 계속 보고 싶다.

특정 주제로 더 깊게 다이브하거나, 실무 적용 관점의 정리가 필요하다면 방명록(또는 이메일)로 편하게 노크해 주세요.

방명록 바로가기

이메일 주소 : chessire@naver.com

이전글

완벽한 실행자와 불완전한 가설
—
사람의 실수가 사라지지 않는 이유

최근 공개되는 AI 데모들을 보면, 개발 업무의 상당 부분이 빠르게 자동화되는 흐름은 부정하기 어렵습니다.

설계 초안 작성부터 구현, 테스트 코드 생성, 문서화까지 그럴듯한 결과가 빠른 속도로 나오고 있습니다.

이 지점에서 자연스럽게 질문이 생깁니다.

AI가 설계부터 구현까지 수행하는 시대에, 사람의 ‘추론 능력’은 어디에서 가치를 가지는가?

이 글은 그 질문에 대해, 감정적 위로가 아니라 정의·구분·한계·실무적 함의 중심으로 정리한 글입니다.

1. 전제: AI의 강점은 생산과 재조합에 있다.

우선 AI의 성과를 축소해서 해석할 이유가 없습니다.

현재의 AI는 아래 영역에서 이미 실무적으로 유의미합니다.

• 요구사항이 비교적 명확할 때의 코드 생성 및 리팩터링 보조
• 기존 패턴/라이브러리 사용법의 빠른 검색 및 샘플 구성
• 문서/테스트/로그 템플릿화, 리뷰 초안 생성
• 유사한 문제를 빠르게 풀어내는 재조합 속도

이 강점은 기술적으로 보면 자연스럽습니다.

대규모 데이터에서 패턴을 압축하고, 그 패턴을 조건에 맞춰 재배열하는 방식은

특히 In-Distribution(학습 분포와 유사한 조건)에서 높은 성능을 보이기 때문입니다.

여기까지는 논쟁이 아닙니다.

실무자라면 체감하는 영역입니다.

2. 구분: 추론을 한 단어로 뭉치면 오해가 발생한다.

문제는 추론이라는 단어를 하나로 뭉칠 때 생깁니다.
실무에서 추론은 대략 두 층으로 나뉩니다.

1. 해결(Problem Solving): 주어진 문제를 푸는 능력
2. 정의(Problem Framing): 무엇이 문제인지 규정하고, 성공 조건과 제약을 설계하는 능력

AI는 1)에서 빠르게 강해지고 있습니다.
반면, 2)는 여전히 사람의 비중이 큽니다.

이유는 간단합니다.

• 목표가 다중(KPI 충돌)이고, 우선순위가 조직/비즈니스에 의해 결정됨
• 데이터가 부족하거나, 실험 비용이 커서 정답이 즉시 관측되지 않음
• 실패 원인이 코드 외부(운영/프로세스/사용자 행동/조직 구조)에 섞여 있음
• 요구사항 자체가 모순적이거나, 아직 합의되지 않은 상태가 흔함

이 상황에서 핵심은 정답을 맞히는 능력이 아니라, 판을 뒤집는 설계(새 논리 구조)입니다.

흔히 System 2(심사숙고)라고 부르는 영역이 여기에 해당합니다.

3. 핵심 주장: 사람의 ‘실수’는 결함이 아니라 기능.

여기서 반전으로 들어가겠습니다.
사람의 실수는 보통 부정확함으로 취급되지만, 특정 조건에서는 오히려 추론이 작동하고 있다는 신호가 됩니다.

이를 이해하려면, 두 개념을 구분해야 합니다.

• 환각(Hallucination): 근거가 부족한데도 그럴듯한 확정 답을 만들어내는 현상
• 가설(Hypothesis): 현재 증거가 부족하므로, 검증 가능하도록 후보 원인을 세우고 다음 관측/실험으로 이어지는 주장

AI도 가설을 제시할 수는 있습니다.

다만 실무에서 자주 발생하는 문제는, AI가 제시한 내용이 가설인지 확정인지 경계가 흐려질 때입니다.

말은 단정인데 근거는 빈약한 형태가 나오면, 현장에서는 리스크가 됩니다.

반면 인간의 실수는(정상적인 업무 프로세스 안에서는) 다음 형태로 나타날 때 가치가 있습니다.

1. 현재 데이터로는 결론이 나지 않음을 인정
2. 원인을 소수의 후보로 압축(가설화)
3. 검증 비용이 낮고 정보 이득이 큰 실험을 설계
4. 실패를 통해 시스템 모델을 업데이트

즉, 사람의 실수는 OOD(분포 외 상황)에서 세계 모델을 구성하려는 시도로 나타날 수 있습니다.
아이러니하지만, 데이터가 부족한 상황에서 사람이 하는 ‘틀림’은, 종종 검증 가능한 다음 행동을 낳습니다.

이 글에서 말하는 실수의 위대함은 단순한 감성적인 표현이 아니라 다음 의미입니다.

실수가 근거 없는 확신이 아니라 검증 가능한 가설의 형태를 띨 때, 그것은 추론의 결함이 아니라 추론의 작동 방식입니다.

4. 결론: 빌더(Builder)에서 아키텍트(Architect)로 이동해야 한다.

그렇다면 생존 전략은 명확해집니다.
AI가 강해질수록 사람에게 남는 영역은 “How”가 아니라 “What/Why” 쪽으로 이동합니다.

• What: 무엇을 만들 것인가(문제 정의, 성공 조건, 범위)
• Why: 왜 이것이 우선인가(가치, 리스크, 제약, 트레이드오프)
• 검증 설계: 무엇을 측정해야 실패를 빨리 알 수 있는가
• 경계 설정: 무엇을 고정하고 무엇을 가변으로 둘 것인가
• 책임: 그 판단을 그럴듯함이 아니라 증거로 정당화할 수 있는가

AI는 훌륭한 실행자이자 보조자입니다.
그러나 문제를 어떤 형태로 정의하고, 어떤 증거로 검증할지는 아직 사람이 주도해야 합니다.

그리고 이 영역이 자동화되기 어렵다는 이유는 기술 이전에 현실적입니다.

목표와 제약, 그리고 가치 판단은 결국 사람과 조직의 선택이기 때문입니다.

관련글

결국 Wave Intrinsics는
하드웨어의 물리적 구조를 소프트웨어 알고리즘의 영역으로 끌어들여,
GPU 성능을 한계까지 끌어올린 SM6의 정점입니다.

 지난 시간, DX11(SM5)의 등장과 함께 Compute Shader와 Tessellation이 어떻게 데이터와 워크로드 모델의 패러다임을 바꿨는지 살펴보았습니다. 이는 렌더링 엔진의 책임이 커졌음을 의미하며, 동시에 GPU 프로그래밍의 주도권이 하드웨어(고정 기능)에서 소프트웨어(개발자의 설계) 로 크게 이동하는 서막이기도 했습니다. DX12는 통제권을 개발자에게 돌려준 Low-level API의 전환이었고, SM6는 Wave Intrinsics로 하드웨어의 웨이브 실행 단위를 셰이더 코드에 노출시켰습니다.

Low-Level API, Thin API

 DX11에서의 리소스 상태 관리(추적 / 검증)는 드라이버의 몫이었습니다. 드라이버가 내부에서 암묵적으로 상태를 관리하고 검증과 최적화를 대신 수행해주었습니다. 이는 필연적으로 CPU 오버헤드를 동반했습니다. DX12는 이 API 레이어를 아주 얇게(Thin) 걷어냈습니다. 이제 리소스 배리어(Resource Barrier) 설정부터 메모리 배치(Heap 기반)까지 과거 드라이버가 수행하던 저수준 제어를 개발자가 명시적으로 다룰 수 있게 된 것입니다.

Command Queue와 병렬화

 단일 컨텍스트(Immediate Context) 기반이었던 DX11은 아무리 코어가 많아도 렌더링 명령은 제한적인 경로로 GPU에 전달되어야만 했습니다. 특히 중간에 상태 변경이나 검증 비용이 누적되면 CPU 병목이 커지기 쉬웠습니다. 반면 DX12는 멀티스레드 환경에서 여러 개의 Command List를 동시에 기록하고 이를 GPU로 제출할 수 있는 구조를 택했습니다. 이는 현대 멀티코어 프로세서의 성능을 최대로 끌어내며 CPU 병목을 완화한 핵심 동력이 되었습니다.

Bindless Resource

 과거 Draw Call 오버헤드의 큰 부분은 리소스 바인딩과 그에 따른 드라이버 검증 및 상태 변경 비용이었습니다. 즉, 드로우를 호출할 때마다 텍스처·버퍼 같은 리소스를 슬롯에 바인딩하고, 드라이버가 그 상태를 확인·정리하는 작업이 반복되면서 CPU 비용이 누적되었습니다. DX12에서는 이를 Descriptor Heap와 Descriptor Table 이라는 거대한 메모리 풀에 리소스를 몰아넣고 인덱스만 전달하는 Bindless 방식으로 개선했습니다. 덕분에 리소스 전환 비용을 최소화하고 GPU가 연산에만 집중할 수 있는 환경을 구축했습니다.

Wave Intrinsics

 SM6의 등장과 함께 추가된 기능 중 가장 혁신적인 것을 꼽으라면 단연 Wave Intrinsics입니다. 이는 GPU의 서브그룹 실행 단위(Warp 혹은 Wavefront)를 셰이더 코드에서 직접 다룰 수 있게 해줍니다. 같은 Wave 내 Lane들 사이에서 값을 교환하거나 집계(Reduction)할 수 있어서 그룹 공유 메모리(groupshared / LDS)와 배리어에 의존하던 패턴을 같은 Wave 내부에서는 더 싸게 연산할 수 있는 선택지를 제공하게 됐습니다.

1. groupshared / LDS + 배리어 의존도
    SM5까지의 모델은 스레드 그룹 단위로 데이터를 공유할 때 보통 groupshared(LDS)에 쓰고, GroupMemoryBarrierWithGroupSync()로 동기화한 뒤 읽는 패턴이 일반적이었습니다. 이때 메모리 접근 지연과 배리어 대기 시간이 최적화의 비용으로 작동하기 쉬웠습니다.
2. Wave 내부에서 레지스터 수준 교환 및 연산을 제공하다.
    SM6의 Wave Intrinsics는 일부 패턴에서는 이 메모리 단계를 대체하거나 줄일 수 있습니다. Wave 내부에 한해 Lane 간 값을 레지스터 수준으로 교환 및 연산할 수 있게 합니다. (단, wave 밖에서는 여전히 LDS/배리어가 필요합니다.)
   
   • WaveActiveSum() : Wave 내 합 (Reduction)
   • WaveReadLaneAt() : 특정 Lane 값 읽기 (Shuffle)
   • WavePrefixSum() : Prefix 연산
3. 통제가 만든 최적화의 선택지
    결과적으로 개발자는 하드웨어가 실제로 실행하는 서브그룹 단위를 전제로 알고리즘을 설계할 수 있게 되었고, 특정 워크로드에서는 groupshared(LDS)나 배리어 비용을 줄이는 방식으로 성능을 개선할 여지가 생겼습니다. (Occlusion / Visibility 계열 처리, 타일링 / 스캔 / 리덕션 기반 작업 등)

(참고: wave 크기는 벤더와 아키텍처, 설정에 따라 달라질 수 있습니다.)

맺음말

 우리는 지금까지 DX11에서 DX12로 넘어오며, GPU의 실행 모델과 리소스와 동기화 책임이 어떻게 더 명시화되어 왔는지 살펴보았습니다. 누군가에게 DX12는 드라이버가 해주던 일을 개발자가 더 많이 떠맡게 된 불친절한 변화였을지 모릅니다. 하지만 역설적으로 이 통제권은, UE5의 거대한 두 기둥인 나나이트(Nanite)와 루멘(Lumen) 같은 현대적 렌더링 기술을 뒷받침하는 중요한 기반이 되었습니다.

다음글

이전글