발표 슬라이드 (PPT 연출 설계)

단계: 내용(발표_초안.md) → 스크립트 → 슬라이드 분할 → 〔현재〕 화면 연출(A 미니멀 + 핵심만 B) + 이미지 연출
[화면] = 슬라이드에 실제로 보일 것(모노스페이스 목업). A = 핵심 한 줄 / B = 대비·도식·흐름.
[연출] = 이미지/도식 지침. 이미지 프롬프트 = 비주얼가이드.md의 〔기본 기반〕 + 〔배치 토큰〕 + 아래 〔목적 · 요소〕 를 이어 붙여 생성.
[발표자 노트] = 말할 스크립트(그대로). 화면은 '노트 요약'이 아니라 '말을 보조하는 시각' — 디테일은 전부 말로.
TODO(본인): ○○○ 이름 / 🎤 경험담 / 도식 실제 디자인 / 이미지 생성 / 미세 조정 — 총 42p

P1 · 표지 〔표지 · A〕

[화면]

        코더를 넘어
        프로그래머로

   주니어 개발자가 팀의 신뢰를 얻는 방법


                              ○○○ · 넥슨

[연출] 이미지 · 풀블리드 16:9 (제목 얹을 여백) — 아래 블록 복사

Editorial illustration on a dark near-black background, cool teal/cyan as the primary accent (matching the deck), balanced by a warm secondary accent (soft amber) and off-white linework; muted and desaturated, subtle film grain, soft glow lighting, quiet and warm yet purposeful mood. Not monochrome — the warm accent keeps it from becoming a flat teal-on-black wash. No text, no letters, no logos.
16:9, leave a calm uncluttered area for the title text.
Set the talk's quiet, hopeful tone — a coder quietly growing into a programmer.
A single developer seen small at a simple desk, with soft teal glow shapes gently rising and broadening around them, suggesting growth and a wider world opening up. Calm, hopeful, lots of dark space.

[발표자 노트]

안녕하세요.
넥슨에서 17년째 게임 서버를 만들고 있는 ○○○입니다.
오늘은 '코더를 넘어 프로그래머로'라는 제목으로, 주니어 개발자분들과 함께 나누고 싶은 이야기를 준비했습니다.
편하게 들어주시면 감사하겠습니다.

P2 · 잠깐, 용어부터 〔내용 · A〕

[화면]

   잠깐, 용어부터

   '코더'와 '프로그래머'
   — 정착된 정의가 아니라, 통념에서 빌려온 용어

[연출] 이미지 없음 · 타이포 — '잠깐, 용어부터' 작은 청록 라벨 + 두 용어를 가볍게 대비.

[발표자 노트]

오늘 '코더를 넘어 프로그래머로'라는 이야기를 드릴 텐데요, 시작하기 전에 한 가지 솔직하게 짚고 싶은 것이 있습니다.
사실 이 두 단어는 어딘가에 정착된 정의가 있다기보다, 통념에서 빌려온 용어에 가깝습니다.
학술적으로 정해진 것도, 업계에서 똑같이 통용되는 것도 아니고요.
그래서 오늘은 그 통념적인 의미로 빌려 쓰려고 합니다.
'코더'는 주어진 일을 그대로 해내는 사람, '프로그래머'는 실무에서 주변 동료들에게 인정받는 사람 정도의 의미로 생각해 주시면 될 것 같습니다.

P3 · 발표의 한계 〔내용 · A〕

[화면]

   정답이 아니라,
   개인의 경험을 바탕으로 한 의견입니다

[연출] 이미지 없음 · 타이포 — 짧은 문장 중앙 배치, 차분하게. 강조어('의견')만 청록.

[발표자 노트]

그리고 미리 말씀드리면, 이 구분도 앞으로 드릴 이야기도 굉장히 주관적이고 개인적일 수 있습니다.
정답이라기보다는, 제 경험과 주변 동료들과의 토론을 바탕으로 정리한 하나의 의견이라고 봐주시면 좋겠습니다.
그래서 오늘 뭔가 대단한 충격을 드리거나 '이게 정답이다'라고 말씀드리려는 것은 아닙니다.
여러분이 성장해 나가시는 길에 작은 참고 하나가 되면 좋겠다는 마음으로 준비했습니다.

P4 · 오늘 나누고 싶은 이야기 〔내용 · A〕

[화면]

   상상했던 '프로그래머'의 모습과
   막상 마주하는 일은 다릅니다

   "이런 것까지 제가 해야 하나?"

[연출] 이미지 · 풀블리드 16:9 (질문 텍스트 얹을 여백) — 아래 블록 복사

Editorial illustration on a dark near-black background, cool teal/cyan as the primary accent (matching the deck), balanced by a warm secondary accent (soft amber) and off-white linework; muted and desaturated, subtle film grain, soft glow lighting, quiet and warm yet purposeful mood. Not monochrome — the warm accent keeps it from becoming a flat teal-on-black wash. No text, no letters, no logos.
16:9, leave a calm uncluttered area for the title text.
Empathize with the wry bewilderment of facing non-coding work — "do I really have to do all this?".
A programmer at a desk who wants to code, gently encircled by non-coding task symbols — meeting speech bubbles, documents, schedules, sticky notes. Mildly overwhelmed, slightly wry posture. Not stressful or dramatic.

[발표자 노트]

프로그래머라는 직업을 처음 가질 때, 누구나 머릿속에 그리던 모습이 있습니다.
대중이 떠올리는 프로그래머의 이미지도 있고요 — 좋게든, 나쁘게든 말이죠.
그런데 막상 일을 해보면, 생각했던 것과는 사뭇 다른 일들을 하게 됩니다.
그러다 보면 '이런 것까지 제가 해야 하나?' 하는 마음이 들 때가 생기죠.
오늘은 바로 그런 것들에 대한 이야기입니다.

P5 · 오늘의 순서 〔목차 · A〕

[화면]

   오늘의 순서

   1. 코딩 그리고 그 너머의 무언가
   2. 피드백
   3. 생각의 전파와 기록
   4. 일정 관리
   5. 정리

[연출] 이미지 없음 · 타이포 — 5항목 리스트. (장 전환마다 재등장해 현재 위치를 청록으로 강조하는 용도로 재사용 가능)

[발표자 노트]

오늘 순서는 이렇습니다.
먼저 코딩 너머의 무언가가 왜 필요한가를 짧게 짚어보고, 그다음 프로그래머가 신경 쓰게 되는 세 가지 — 피드백, 생각의 전파와 기록, 그리고 일정 관리 — 를 차례로 보겠습니다.
마지막에는 가볍게 정리하겠습니다.

P6 · 1장. 코딩 그리고 그 너머의 무언가 〔챕터 · A〕

[화면]

   1

   코딩 그리고
   그 너머의 무언가

[연출] 이미지 · 풀블리드 16:9 (큰 숫자 '1'·제목 여백) — 아래 블록 복사

Editorial illustration on a dark near-black background, cool teal/cyan as the primary accent (matching the deck), balanced by a warm secondary accent (soft amber) and off-white linework; muted and desaturated, subtle film grain, soft glow lighting, quiet and warm yet purposeful mood. Not monochrome — the warm accent keeps it from becoming a flat teal-on-black wash. No text, no letters, no logos.
16:9, leave a calm uncluttered area for the title text.
Convey one more layer added on top of the coding foundation.
A solid base platform reading as a 'foundation', with a second translucent layer gently settling on top of it; abstract and calm. The teal grounds it, a warm amber edge marks the added layer. A sense of "one more layer added".

[발표자 노트]

먼저, 바탕 이야기부터 하겠습니다.

P7 · 코딩 그 너머? 〔내용 · A〕

[화면]

   우리의 기본은 코딩
   그런데 그 너머는 무엇이고 왜 필요한가?

[연출] 이미지 없음 · 타이포(질문 슬라이드). 원하면 P6의 '층' 모티프를 작게 재사용.

[발표자 노트]

개발자의 출발점이자 토대는 코딩입니다.
이건 변하지 않는 부분이라고 생각합니다.
코딩을 잘하는 것은 여전히, 그리고 앞으로도 중요하고요.
그런데 — 여기서부터는 제 주관적인 생각입니다만 — 그 '너머'에는 무엇이 있고, 또 왜 필요할까요?
저는 실무가 코딩 이상의 것을 필요로 하기 때문이라고 생각합니다.

P8 · 상상과 현실 〔내용 · B 대비〕

[화면]

   입사 전엔  →  앉아서 코딩, 구조 설계… '너드'한 작업을 떠올리지만
   실제로는   →  회의 · 문서 정리 · 명세 수정해서 돌려보내기

   ⇒ 코딩 아닌 일의 비중이, 생각보다 높습니다

[연출] 이미지 · 풀블리드 16:9 (좌우 분할, [화면] 설명은 최소화) — 아래 블록 복사

Editorial illustration on a dark near-black background, cool teal/cyan as the primary accent (matching the deck), balanced by a warm secondary accent (soft amber) and off-white linework; muted and desaturated, subtle film grain, soft glow lighting, quiet and warm yet purposeful mood. Not monochrome — the warm accent keeps it from becoming a flat teal-on-black wash. No text, no letters, no logos.
16:9, leave a calm uncluttered area for the title text.
Instantly contrast the imagined vs the actual job of a programmer.
Split composition. Left half: a developer alone in calm deep focus, coding at a glowing screen, serene and 'cool'. Right half: the same developer surrounded by meetings, documents, sticky notes and chatting colleagues, visibly busier. The contrast between the two halves is the focal point.

[발표자 노트]

입사하기 전에는, 개발자가 되면 종일 자리에 앉아 코딩을 하고, 구조를 설계하고, 뭔가에 깊이 몰두하는 '너드' 같은 일을 주로 할 거라고 상상하기 쉽습니다.
그런데 막상 일을 해보면, 회의를 하고, 문서를 정리하고, 명세서를 검토해서 수정 의견을 돌려보내고… 이렇게 코딩 그 자체가 아닌 일의 비중이 생각보다 훨씬 높습니다.
처음에는 조금 의아하게 느껴질 수도 있지만, 이건 곁다리가 아니라고 생각합니다.

P9 · 코딩(기본) + 실무 역량(그 위에) 〔내용 · B 도식〕

[화면]

   ┌───────────────────────┐
   │  실무 역량 (코드 바깥)  │   ← 그 위에 더하는 층
   ├───────────────────────┤
   │  코딩 (토대)           │   ← 기반이 되는 층
   └───────────────────────┘

   둘 다 '배우고 늘리는 기술'

[연출] 이미지 · 풀블리드 16:9 (메타포 · 여백에 텍스트 얹기 가능) — 아래 블록 복사

Editorial illustration on a dark near-black background, cool teal/cyan as the primary accent (matching the deck), balanced by a warm secondary accent (soft amber) and off-white linework; muted and desaturated, subtle film grain, soft glow lighting, quiet and warm yet purposeful mood. Not monochrome — the warm accent keeps it from becoming a flat teal-on-black wash. No text, no letters, no logos.
16:9, with generous calm negative space in the upper area for an optional text overlay.
Evoke "I grow a capability and add it myself": a Christmas tree is the solid base built over time, and a person places the star that completes it.
A metaphor, NOT a chart or diagram: a clearly recognizable Christmas-tree silhouette (a simple conical evergreen) as the dependable base, glowing teal — but kept minimal and UNDECORATED, with no baubles, tinsel, lights or busy ornaments, just the clean tree shape so its identity reads from the silhouette alone. A small human figure on a step/ladder reaches up to gently place a radiant amber star at the very top as the finishing, crowning piece. The star is intentionally a little oversized so it reads as clearly important — not a tiny speck — and is the luminous focal point, no less important than the tree; keep the tree from dwarfing the star. The act of placing it conveys adding a capability one has grown oneself. Leave open, uncluttered space above/beside for text. Warm, quietly hopeful.

[발표자 노트]

그래서 저는 이렇게 봅니다.
코딩이라는 기본 위에 '실무 역량'을 한 겹 더 얹는 것, 그게 실무가 요구하는 모습이 아닐까 합니다.
여기서 실무 역량이란, 코드 바깥에서 '일이 되게 만드는' 힘입니다.
동료와 맞춰 가고, 빈틈을 미리 보고, 일정을 예측 가능하게 만들고, 완성도를 챙기는 일이라고 할 수 있습니다.
다행인 점은, 이것도 타고나는 센스가 아니라 코딩처럼 배우고 늘릴 수 있는 기술이라는 것입니다.
오늘은 그 실무 역량을 세 가지로 나눠 보겠습니다.
피드백, 생각의 전파와 기록, 그리고 일정 관리입니다.

P10 · 2장. 피드백 〔챕터 · A〕

[화면]

   2

   피드백
   — 받은 일을 '그대로' 받지 않기

[연출] 이미지 · 풀블리드 16:9 (큰 숫자 '2'·제목 여백) — 아래 블록 복사

Editorial illustration on a dark near-black background, cool teal/cyan as the primary accent (matching the deck), balanced by a warm secondary accent (soft amber) and off-white linework; muted and desaturated, subtle film grain, soft glow lighting, quiet and warm yet purposeful mood. Not monochrome — the warm accent keeps it from becoming a flat teal-on-black wash. No text, no letters, no logos.
16:9, leave a calm uncluttered area for the title text.
Convey the feedback chapter idea — not accepting received work as-is, but questioning and reshaping it.
A person receives a simple geometric shape handed from one side, and instead of passively accepting it, actively reshapes and refines it with their hands; a quiet sense of thoughtful improvement.

[발표자 노트]

첫 번째는 피드백입니다.
받은 일을 '그대로' 받지 않는 것에서 시작합니다.

P11 · 명세서의 빈틈, 누구의 몫일까 〔내용 · A〕

[화면]

   명세서의 빈틈,
   누구의 몫일까?

[연출] 이미지 · 풀블리드 16:9 (기획자 ↔ 프로그래머 대비, 질문 얹을 여백) — 아래 블록 복사

Editorial illustration on a dark near-black background, cool teal/cyan as the primary accent (matching the deck), balanced by a warm secondary accent (soft amber) and off-white linework; muted and desaturated, subtle film grain, soft glow lighting, quiet and warm yet purposeful mood. Not monochrome — the warm accent keeps it from becoming a flat teal-on-black wash. No text, no letters, no logos.
16:9, leave a calm uncluttered area for the title text.
Pose the question "whose job is it to fill the gaps in a spec?" by contrasting a game designer and a game programmer.
A game designer on the left (creative cues — a pen, sketches, an idea spark) and a game programmer on the right (code/keyboard cues), facing each other. Between them lies a shared specification sheet with a clearly visible gap — a missing piece or hole — softly highlighted in amber as the focal point. Both regard the gap, leaving it an open question whose responsibility it is. Balanced left-right composition, calm space above for the question text. Warm, quietly thoughtful.

[발표자 노트]

작업 명세서가 충실하지 못하다고 느낀 적, 있지 않으신가요?
'왜 이런 예외 케이스 처리가 빠져 있지?' 하고 답답했던 적은 없으신가요?
여기서부터는 제 주관적인 생각입니다만, 저는 명세서의 빈틈을 찾아 메우는 역할이 디자이너보다 오히려 프로그래머에게 있다고 보는 편입니다.
물론 절대적인 것은 없습니다.
디자이너도 빈틈없는 명세를 만들기 위해 노력해야 한다고 생각합니다.
다만 논리적으로 빈틈없는 디자인에 대한 책임의 꽤 많은 비중은 프로그래머에게 있다고 봅니다.

P12 · 왜 그게 프로그래머의 몫일까 〔내용 · A〕

[화면]

   디자인은 '목적을 구체화'하는 일,
   프로그래밍은 '빈틈없는 설계'를 하는 일

[연출] 이미지 없음 · 타이포 — 두 역할(디자인 vs 프로그래밍)을 좌우/상하로 대비.

[발표자 노트]

왜냐하면 기획이나 디자인을 하는 분은 '목적을 위해 시스템이나 컨텐츠를 구체적으로 그려내는 사람'이라, '안전하고 빈틈없는 결과물'을 만드는 것과는 결이 조금 다른 방향으로 일하게 되기 때문입니다.
반대로 안전하고 빈틈없는 설계를 해내는 것 자체는 프로그래머의 일이라고 할 수 있습니다.
그러니 오히려 프로그래머가 빈틈없는 명세를 완성하는 데 큰 역할을 할 수 있다고 생각합니다.
그럼 그 '빈틈 메우기'를 어떻게 하면 좋을지, 세 가지 원칙으로 풀어보겠습니다.

P13 · 원칙 1 — 목적 이해 〔내용 · A〕

[화면]

   원칙 1 — 목적을 먼저 이해한다
   "어떻게"가 아니라 "무엇을 위해"

   실천 → 목적을 내가 이해한 대로 역질문
        "이거 결국 ○○ 하려는 거 맞죠?"

[연출] 이미지 없음 · 타이포 — '원칙 1' + 그 실천(목적 역질문)을 한 화면에.

[발표자 노트]

첫 번째 원칙은, 명세서가 '무엇을 위한 것인지' 그 목적을 먼저 이해하는 것입니다.
명세를 그대로 받아들이지 않고, 요청자와 문답을 통해 이게 실제로 무엇을 노리는지를 분명히 파악하는 것이죠.
왜 목적을 알아야 할까요?
명세는 '무엇을 어떻게'까지는 적지만, 현실의 모든 디테일을 담지는 못합니다.
구현하다 보면 명세에 없는 빈칸을 수없이 만나게 되는데요, 목적을 알면 그 빈칸을 스스로 옳게 채울 수 있습니다.
실천은 간단합니다.
명세를 받으면, 제가 이해한 목적을 제 말로 바꿔 되묻습니다.
'이거 결국 이걸 하려는 거 맞죠?'처럼요.
사소해 보여도, 인식이 어긋나 있었다면 구현을 시작하기 전에 여기서 잡힙니다.

P14 · (예시) 출석 이벤트 〔예시 · B 대비〕

[화면]

   "출석 이벤트를 만들어 주세요"

   명세 그대로  →  출석판·일자별 보상·연속 보너스·누락 처리 (복잡)
   목적은?      →  '초반 접속 유저에게 선물 → 재접속 유도'
   그러면       →  ✉ 우편 접속 보상으로 충분

[연출] 이미지 · 패널 1:1 (대비표와 나란히) — 아래 블록 복사

Editorial illustration on a dark near-black background, cool teal/cyan as the primary accent (matching the deck), balanced by a warm secondary accent (soft amber) and off-white linework; muted and desaturated, subtle film grain, soft glow lighting, quiet and warm yet purposeful mood. Not monochrome — the warm accent keeps it from becoming a flat teal-on-black wash. No text, no letters, no logos.
1:1 square, self-contained composition, plain deep near-black background so it blends seamlessly into the dark slide.
Contrast a complex solution and a simple one that both reach the very same goal.
A metaphor, NOT a machine: two routes leading to one and the same destination — a single small gift at the goal point. The left route is a long, tangled, looping, overcomplicated path; the right route is a short, clean, direct line. Both arrive at the identical goal, showing the simple route reaches the same place with far less effort. The direct route glows warm amber; the tangled one stays cool teal. Abstract and clean, quietly clever — no gears or machinery.

[발표자 노트]

예를 들어보겠습니다.
'출석 이벤트를 만들어 주세요'라는 요청을 받았다고 해보겠습니다.
그대로 받으면 출석판 UI, 일자별 보상, 연속 출석 보너스, 누락 처리까지 꽤 복잡한 시스템을 다 만들어야 합니다.
그런데 목적을 물어보니 원하는 것은 의외로 단순했습니다.
'초반에 접속하는 유저들에게 선물을 줘서 재접속을 유도하고 싶다'는 것이었죠.
목적이 그렇다면 굳이 복잡한 출석 시스템이 아니어도 됩니다.
'그러면 우편으로 접속 보상을 주는 방식은 어떨까요?'라고 훨씬 가벼운 길을 제안할 수 있습니다.
명세만 봤다면 그 시스템을 다 만들었을 일을, 목적을 이해했기에 더 단순하게 풀 수 있는 것입니다.
물론 우편으로 보상을 지급하는 것이 출석 시스템보다 더 좋다는 뜻은 아닙니다.
현실성을 고려할 때 더 가벼운 작업으로 가는 편이 좋은 경우도 있다는 점에서 착안한, 단순한 예시입니다.

P15 · 원칙 2 — 적극 역제안 〔내용 · A〕

[화면]

   원칙 2

   "어렵다"로 끝내지 말고,
   목적에 맞는 대안을

[연출] 이미지 없음 · 타이포 — '원칙 2' eyebrow + 핵심 문구 크게.

[발표자 노트]

두 번째 원칙은, 피드백과 역제안에 적극적이어야 한다는 것입니다.
빈틈을 발견하는 데 그치지 않고, '어렵다'로 끝내는 대신 목적에 맞는 대안을 함께 내미는 것이죠.
왜냐하면 그게 프로그래머의 역할이라고 생각하기 때문입니다.
발견은 메움으로 이어져야 의미가 있고, '어렵다'고 선만 그으면 요청자는 막막해질 뿐입니다.

P16 · 실천 — 빈틈을 짚고, 대안을 낸다 〔실천 · A〕

[화면]

   빈틈을 짚고 → 대안을 낸다

   1. 빈틈을 정리해 되묻기
      · 빠진 듯하면   → "이 경우도 고려되었을까요?"
      · 어려워 보이면 → "먼저, 어떤 의도로 이렇게 하셨어요?"

   2. 의도를 알고도 위험하면
      → 간단한 이유 + 대안을 함께

[연출] 이미지 없음 · 타이포 — 빈틈 역질문(두 종류) → 대안 역제안.

[발표자 노트]

그럼 그 빈틈은 어떻게 메울까요.
먼저, 제가 본 빈틈을 정리해서 되묻는데, 빈틈은 두 종류더라고요.
그냥 빠진 것 같은 부분은 '이런 경우도 고려가 되었을까요?'라고 가볍게 묻습니다.
반대로 구현이 어렵거나 불가능해 보이는 부분은, 곧장 '이건 안 됩니다'라고 하지 않으려 합니다.
대신 '이 부분이 구현이 좀 까다로운데, 어떤 의도로 이렇게 디자인하셨는지 먼저 여쭤봐도 될까요?'라고 의도부터 파악합니다.
제가 미처 못 본 이유가 있을 수 있으니까요.
그렇게 의도까지 이해하고도 여전히 어렵거나 위험하다고 느껴지면, 그때 비로소 간단한 이유와 함께 대안을 역제안합니다.
막연히 '어렵다'가 아니라, '이래서 위험하니 이렇게 하면 어떨까요'까지 함께요.

P17 · "기술은 제가, 재미는 당신이" 〔내용 · A〕

[화면]

   "기술은 제가 챙길 테니,
    재미에 집중하세요"

[연출] 이미지 · 패널 1:1 (대사와 나란히) — 아래 블록 복사

Editorial illustration on a dark near-black background, cool teal/cyan as the primary accent (matching the deck), balanced by a warm secondary accent (soft amber) and off-white linework; muted and desaturated, subtle film grain, soft glow lighting, quiet and warm yet purposeful mood. Not monochrome — the warm accent keeps it from becoming a flat teal-on-black wash. No text, no letters, no logos.
1:1 square, self-contained composition, plain deep near-black background so it blends seamlessly into the dark slide.
Convey that the programmer firmly supports from below so the designer can focus entirely on creative, fun work.
Reuse the same two characters as the spec-gap image: a game designer and a game programmer. Below, the programmer forms a solid, dependable base — steadily holding up a platform with firm hands, like a sturdy foundation, glowing teal. On top of that support the game designer creates freely and playfully — sketching and shaping a bright, imaginative form, glowing warm amber. A clear vertical relationship: firm base below enabling free creation above. Warm and reassuring.

[발표자 노트]

그리고 한 걸음 더 — 이렇게 적극적으로 메우겠다는 것을 요청자에게 '미리' 알리는 것 자체가 중요하다고 봅니다.
요청자가 '이게 기술적으로 될까'를 혼자 걱정하기 시작하면, 그 불안 때문에 과한 제약을 걸어서 재미를 깎는 디자인을 가져오기 쉽기 때문입니다.
'엣지 케이스나 기술적인 빈틈은 제가 메울 테니, 재미를 만드는 본업에 집중해 주세요' — 이런 신호가 역할을 제자리로 돌려서, 결국 더 좋은 게임을 만든다고 생각합니다.

P18 · (사례) 실시간 랭킹 〔사례〕

[화면]

   "실시간 갱신은 어렵겠지…"
   — 디자이너가 과거 경험상 미리 긋는 제약

   하지만 요즘은, 도구·설계에 따라 가능한 경우도 많다
   (그걸 디자이너가 판단하긴 어렵다)

   → "제약·피드백은 제가 챙길 테니,
      목적에 맞게 명세를 먼저 만들어 주세요"

[연출] 이미지 · 패널 1:1 (사례 텍스트와 나란히) — 아래 블록 복사

Editorial illustration on a dark near-black background, cool teal/cyan as the primary accent (matching the deck), balanced by a warm secondary accent (soft amber) and off-white linework; muted and desaturated, subtle film grain, soft glow lighting, quiet and warm yet purposeful mood. Not monochrome — the warm accent keeps it from becoming a flat teal-on-black wash. No text, no letters, no logos.
1:1 square, self-contained composition, plain deep near-black background so it blends seamlessly into the dark slide.
Show the old assumption "real-time is hard" giving way to "today it's doable".
A leaderboard/ranking board with a faded "impossible" barrier sign in front being lifted or crossed out, revealing a live, updating ranking behind; the sense of an old constraint quietly dissolving.

[발표자 노트]

사실 랭킹 시스템을 작업할 때 이런 걸 자주 느꼈습니다.
많은 디자이너분들이 랭킹을 디자인하면서, '랭킹 갱신을 실시간으로 하기는 어려울 수 있다'는 점을 미리 염두에 두시더라고요.
아마 이전에 그런 경험을 많이 하셨기 때문일 겁니다.
하지만 요즘은 도구도 많이 발전했고, 설계나 목적에 따라서는 실시간 갱신이 충분히 가능한 경우도 많습니다.
다만 이걸 디자이너분이 직접 판단하기는 어렵죠.
그래서 저는 '기술적인 제약이나 피드백은 필요할 때 제가 미리 드릴 테니, 우선 디자인의 목적에 맞게 명세서를 만들어 주세요'라고 의견을 전하는 편입니다.
그렇게 하는 것이 훨씬 더 좋은 결과물로 이어진다고 생각합니다.

P19 · 원칙 3 — 주객전도 경계 〔내용 · A〕

[화면]

   원칙 3

   내 역할은 '피드백'까지,
   결정은 요청자의 몫

[연출] 이미지 없음 · 타이포 — '원칙 3' eyebrow + 핵심 문구 크게.

[발표자 노트]

세 번째 원칙은, 자신의 역할을 분명히 이해하는 것입니다.
우리는 구현자이고, 요청자가 결국 그 컨텐츠의 결정권자입니다.
적극적으로 의견을 내고 논의를 이끌되, 주객이 전도되어 우리가 결정을 내리려 해서는 안 된다고 생각합니다.
이 선만큼은 단호하게 지켜야 한다고 생각합니다.
특히 디자인 자체에 대한 평가, '이거 별로다' 같은 말은 절대로 하지 않아야 합니다.
우리가 제안하는 것은 디자인의 좋고 나쁨이 아니라 '목적을 이루는 더 나은 길'이니까요.
그래서 원칙 2의 적극성과 원칙 3의 선 지키기는 충돌하지 않습니다.
적극적으로 제안하되, 결정은 요청자의 몫으로 남기는 것입니다.

P20 · 실천 — 역제안의 '강도'를 구분한다 〔실천 · A〕

[화면]

   역제안의 '강도'를 구분해 알린다

   · 꼭 필요한 방향 전환   (안 하면 문제)
   · 권장하는 방향        (가능하지만 유지보수·난이도상 이게 나음)

   (취향이면 → 그냥 "제 취향이에요"라고 가볍게)

[연출] 이미지 없음 · 타이포 — '필수 vs 권장' 강도 구분을 또렷이.

[발표자 노트]

그리고 이게 가장 중요하다고 생각하는데요.
제 역제안이 '꼭 필요한 방향 전환'인지, 아니면 '권장하는 방향'인지를 구분해서 상대에게 분명히 알리는 것입니다.
'이건 안 바꾸면 문제가 생기니 꼭 반영되어야 해요'와 '이건 지금도 가능하지만, 유지보수나 작업 난이도를 생각하면 이쪽이 더 나을 것 같아요'는 무게가 전혀 다르니까요.
이 강도를 함께 알려주면, 상대도 무엇을 반드시 반영하고 무엇을 선택적으로 받아들일지 판단하기가 쉬워집니다.
개인적인 취향에 가까운 의견이라면, 그건 그냥 '제 취향이에요'라고 가볍게 덧붙이면 되고요.
물론 최종 결정은 여전히 그분의 몫이고요.

P21 · 3장. 생각의 전파와 기록 〔챕터 · A〕

[화면]

   3

   생각의 전파와 기록
   — 주고받기를 넘어, 퍼뜨리고 남기기

[연출] 이미지 · 풀블리드 16:9 (큰 숫자 '3'·제목 여백) — 아래 블록 복사

Editorial illustration on a dark near-black background, cool teal/cyan as the primary accent (matching the deck), balanced by a warm secondary accent (soft amber) and off-white linework; muted and desaturated, subtle film grain, soft glow lighting, quiet and warm yet purposeful mood. Not monochrome — the warm accent keeps it from becoming a flat teal-on-black wash. No text, no letters, no logos.
16:9, leave a calm uncluttered area for the title text.
Convey one person's thought spreading to others while also being recorded.
A single figure's idea (a small glowing shape) ripples outward to a few nearby figures and at the same time flows down into an open notebook; a sense of spreading outward while leaving a lasting trace.

[발표자 노트]

두 번째는 생각의 전파와 기록입니다.
피드백이 일을 '주고받을 때'의 소통이었다면, 이번에는 제 생각을 '퍼뜨리고 남기는' 쪽이라고 할 수 있습니다.

P22 · 잘 만드는 것 못지않게, 전파하고 남기기 〔내용 · A〕

[화면]

   잘 만드는 것 못지않게,
   전파하고 남기기

   — 우리는 프로덕트를 계속 '유지·발전'시키는 사람

[연출] 이미지 · 패널 1:1 (문구와 나란히) — 아래 블록 복사

Editorial illustration on a dark near-black background, cool teal/cyan as the primary accent (matching the deck), balanced by a warm secondary accent (soft amber) and off-white linework; muted and desaturated, subtle film grain, soft glow lighting, quiet and warm yet purposeful mood. Not monochrome — the warm accent keeps it from becoming a flat teal-on-black wash. No text, no letters, no logos.
1:1 square, self-contained composition, plain deep near-black background so it blends seamlessly into the dark slide.
Show a thought in one's head reaching colleagues and one's future self.
A head/mind with a small idea-shape inside; gentle threads carry copies of it outward to a couple of other figures and forward to a calendar/clock (the 'future self'). A sense of connection and continuity over time.

[발표자 노트]

좋은 결과물을 만드는 것은 중요합니다.
그런데 그것 못지않게 중요한 것이 있다고 생각합니다.
제가 무엇을, 왜, 어떻게 만들었는지를 주변에 전파하고 흔적으로 남기는 일입니다.
왜냐하면 우리는 프로덕트를 한 번 만들고 끝내는 사람이 아니라, 계속 유지하고 발전시켜야 하는 사람들이기 때문입니다.
그러려면 제 머릿속에만 있는 판단과 의도가, 저와 동료 사이에, 그리고 저와 '미래의 저' 사이에 공유되어 있어야 합니다.
공유되지 않은 생각은 시간이 지나면 저조차 다시 해독해야 하는 비용이 되더라고요.

P23 · 읽기 좋은 코드, 그 위에 〔내용 · A〕

[화면]

   읽기 좋은 코드, 그 위에

   가독성 · 주석 · 좋은 변수명 = 기본 (코더의 영역)
   그것만으로 '무엇'은 전해진다

   그런데 그 위에, 무언가가 더 필요하다

[연출] 이미지 없음 · 타이포 — '기본(코더) → 그 위에' 위계가 드러나게.

[발표자 노트]

우리는 읽기 좋은 코드가 중요하다고 배웁니다.
명확한 변수명, 적절한 주석, 잘 쪼갠 함수 — 이런 것만으로도 제 의도가 충분히 전달된다고 느낄 수 있고요.
저도 그게 기본이라고 생각합니다.
사실 이건 코딩 그 자체, 말하자면 '코더의 영역'에 가깝습니다.
그런데, 이건 제 생각입니다만, 그 위에 무언가가 조금 더 필요하다고 느낍니다.
코드는 '무엇을, 어떻게' 만들었는지는 보여주지만, '왜 이렇게 했는지'와 '앞으로 어디로 가려는지'까지는 담지 못하기 때문입니다.
그래서 저는 코드라는 결과물의 '앞'과 '뒤'를 따로 꺼내 둡니다.
앞은 만들기 전의 '방향', 뒤는 만들고 난 뒤의 '이유'고요.
그게 지금부터 말씀드릴 두 가지 — '먼저 전파'와 '기록'입니다.

P24 · 원칙 1 — 먼저 전파 〔내용 · A〕

[화면]

   원칙 1

   다 만든 뒤 통보가 아니라, '먼저'

   작은 공유 하나가
   다시 만들 일을 크게 줄인다

[연출] 이미지 없음 · 타이포 — '원칙 1' eyebrow + 핵심 문구 크게.

[발표자 노트]

첫 번째는, 생각과 방향을 '먼저' 전파하는 것입니다.
다 만든 뒤에 통보하는 것이 아니라, 만들기 전이나 만드는 중에 생각을 먼저 꺼내 놓고, 이 방향이 괜찮은지 미리 확인을 받는 것이죠.
왜 굳이 먼저 꺼낼까요.
먼저 공유하면, 제가 모르고 있던, 이미 구현돼 있는 기능을 가져다 쓰는 편이 낫다는 걸 알게 되기도 합니다.
또 제가 미처 보지 못한 점을 누군가 미리 짚어 주기도 하고요.
결국 가벼운 공유 하나로, 들일 작업의 양과 다시 만들게 될 확률을 꽤 크게 줄일 수 있습니다.
다 만든 뒤에 어긋난 걸 알면 되돌리기 어렵지만, 먼저 꺼내 두면 훨씬 값싸게 고칠 수 있으니까요.

P25 · 먼저 전파하는 법 〔내용 · 방법〕

[화면]

   '먼저 전파'를 실천하는 법

   · 작업 방향을 먼저 문서로 — 누구나 볼 수 있게 열어두기
   · 피드백이 꼭 필요하면 — 1~2명에게 콕 집어 부탁
   · 주기적 회의(스크럼 등)가 있으면 — 한두 줄 요약 + 링크면 충분

[연출] 이미지 없음 · 타이포 — 3개 실천 항목 리스트.

[발표자 노트]

그럼 '먼저 전파'를 실제로 어떻게 하면 좋을까요.
거창할 필요는 없습니다.
기본은, 작업의 방향성을 먼저 간단히 문서로 적어 두고 누구나 원하면 볼 수 있게 열어두는 것입니다.
만약 그 방향에 대해 피드백을 적극적으로 받고 싶은 상황이라면, 한두 명에게 콕 집어 봐달라고 부탁하면 됩니다.
그리고 스크럼처럼 주기적인 회의가 있다면, 작업 방향을 한두 줄로 축약해서 링크와 함께 공유하는 정도로도 충분합니다.

P26 · 원칙 2 — 기록을 남긴다 〔내용 · A〕

[화면]

   원칙 2 — 기록을 남긴다
   (동료와 미래의 나를 위해)

   먼저 '결과' — 의도와 결과를 정리해서
      문서                       (제일 좋음)
        ↓ 부담되거나 작업이 작으면
      commit · PR 설명에 잘
        ↓ 베스트
      문서로 쓰고 commit · PR에 링크

[연출] 이미지 없음 · 타이포 — 결과 기록의 형태 우선순위(문서 → commit/PR → 문서+링크)를 단계로.

[발표자 노트]

두 번째는, 기록을 남기는 것입니다.
앞의 '먼저 전파'가 만들기 전 방향을 알리는 것이었다면, 이건 만든 과정과 결과를 흔적으로 남기는 쪽입니다.
동료와, 그리고 미래의 저를 위해서요.
먼저 '결과'부터 말씀드릴게요.
결과 기록은 이 작업이 '무엇을 의도했고 어떻게 끝났는지'를 정리해 두는 것입니다.
형태에는 우선순위가 있다고 생각해요.
가장 좋은 건 따로 문서로 정리하는 것입니다.
다만 문서가 부담되거나 작업이 작아서 과하다 싶으면, commit 메시지와 PR 설명에 잘 남기는 것만으로도 충분하고요.
베스트는, 문서로 정리한 다음 그 링크를 commit이나 PR에 걸어 두는 것입니다.
그러면 코드에서 출발해도 맥락까지 한 번에 닿을 수 있으니까요.

P27 · 기록 — 과정은 필요할 때, 가볍게 〔내용 · A〕

[화면]

   '과정' — 필요할 때, 가볍게

   · 형식 없이 — 문서든 개인 노트든
   · 늘 필수는 아니다
       (작업이 작거나, 명세대로면 없어도 됨)
   · 사소해 보여도, 적어두면 도움이 된다
   · 혼자 봐도 좋지만 — 열어두면 동료에게도

[연출] 이미지 없음 · 타이포 — 과정 기록(형식 없음 / 선택적 / 사소한 것도 / 열어두기) 4가지.

[발표자 노트]

그리고 '과정'입니다.
과정 기록은 훨씬 가벼워도 됩니다.
정해진 형식 없이, 문서든 개인 노트든 편한 곳에, 진행하면서 내린 결정이나 바꾼 것을 적어 두는 거예요.
이건 늘 필수는 아닙니다.
작업이 작거나, 특별한 과정 없이 명세대로 구현하는 경우라면 굳이 없어도 되고요.
그러니 필요하다고 느낄 때만 남기면 됩니다.
다만, 생각보다 사소해 보이는 것도 적어두면 나중에 큰 도움이 되더라고요.
처음엔 좀 부끄러워서 혼자만 보는 노트에 적어도 좋습니다.
그런데 의외로, 그걸 모두가 볼 수 있게 열어두면 동료들에게도 꽤 도움이 됩니다.

P28 · (예시) '왜'를 복원하다 〔예시 · A〕

[화면]

   "왜 이렇게 짰지?" — 코드만으론 막힐 때

   (낡았어도) 문서 · 커밋 메시지 · PR 논의
   → "아, 이런 제약 때문이었구나"

[연출] 이미지 없음 · 타이포. (선택) 돋보기로 오래된 문서/커밋 로그를 비추는 스팟 이미지(1:1) 가능.

[발표자 노트]

실제로, 한참 뒤에 문제가 터졌을 때 코드만 봐서는 도무지 이해가 안 되는 순간이 옵니다.
그때 단서가 되는 것이, 조금 낡았더라도 설계 문서와 커밋 메시지, 연관된 PR의 논의입니다.
거기서 '아, 그때 이런 제약 때문에 일부러 이렇게 둔 것이구나' 하고 풀립니다.
기록은 미래의 누군가, 대개 미래의 제 자신이 '왜'를 복원할 수 있게 해줍니다.

P29 · 4장. 일정 관리 〔챕터 · A〕

[화면]

   4

   일정 관리
   — 내 '진행 상황'도 공유 대상

[연출] 이미지 · 풀블리드 16:9 (큰 숫자 '4'·제목 여백) — 아래 블록 복사

Editorial illustration on a dark near-black background, cool teal/cyan as the primary accent (matching the deck), balanced by a warm secondary accent (soft amber) and off-white linework; muted and desaturated, subtle film grain, soft glow lighting, quiet and warm yet purposeful mood. Not monochrome — the warm accent keeps it from becoming a flat teal-on-black wash. No text, no letters, no logos.
16:9, leave a calm uncluttered area for the title text.
Convey sharing progress along the way while others wait on it.
A gently winding path/timeline with a few checkpoint markers; a figure mid-path calmly raising a small signal flag back toward others waiting further down the path. A sense of progress being signaled, and others depending on it.

[발표자 노트]

세 번째는 일정 관리입니다.
생각만 공유 대상이 아닙니다.
제 '진행 상황', 즉 일정도 똑같이 공유해야 한다고 생각합니다.

P30 · 주기적으로 공유하기 〔내용 · A〕

[화면]

   일정 관리의 핵심
   = 주변에 '주기적으로' 공유하기

[연출] 이미지 없음 · 타이포 — 핵심 한 줄. ('주기적으로' 청록 강조)

[발표자 노트]

일정 관리도 엄연히 업무의 일부입니다.
다만 일정을 잘 예측하고 그대로 잘 지키는 것, 이건 당연한 목표지만 왕도가 없는 것 같습니다.
경험으로 감을 키우는 수밖에 없으니 길게 다루지는 않겠습니다.
정작 이야기하고 싶은 것은 따로 있습니다.
제 작업 일정을 주변, 그러니까 요청자나 매니저, PM에게 주기적으로 공유하는 것입니다.
'늦어지고 있어요', '생각보다 빨라요', '제대로 끝날 것 같아요', '지금 이만큼 됐어요' 같은 신호를 꾸준히 보내는 것이죠.

P31 · 왜 공유가 중요한가 〔내용 · A〕

[화면]

   문제는 '틀어짐'이 아니라,
   주변이 '모르는' 것

   (내 지연 = 남의 지연)

[연출] 이미지 없음 · 타이포 — 대비 문구. '내 지연 = 남의 지연'을 강조 배치.

[발표자 노트]

왜 중요한가 하면, 정직하게 산정해도 일정은 틀어지기 마련이기 때문입니다.
문제는 틀어지는 것 자체가 아니라, 그것을 주변이 모르고 있는 것입니다.
게다가 제 일정은 늘 누군가의 일정과 연결되어 있습니다.
제 서버 API를 클라 팀이 기다리고 있다면, 제 지연이 곧 그 팀의 지연이 되는 것이죠.
그래서 꾸준한 공유가 팀에게 미리 대응할 시간을 벌어줍니다.

P32 · '짠' 공개가 위험한 이유 〔내용 · A〕

[화면]

   다 만들어 '짠' 공개하면,

   그동안 방향이 어긋나 있어도
   막판에야 알게 된다

[연출] 이미지 없음 · 타이포. (선택) 한 번에 '짠' 공개 vs 중간중간 공유를 작은 도식으로 대비 가능.

[발표자 노트]

또 하나의 이유가 있습니다.
다 만들어서 '짠' 하고 한 번에 공개하고 싶은 마음이 들 때가 있습니다.
즐거운 일이지만, 사실 위험합니다.
그동안 방향이 어긋나 있었더라도 막판에야 알게 되고, 문제가 숨어 있었다면 그때 한꺼번에 터지기 때문입니다.
그래서 결과를 한 번에 보여주기보다, 과정을 중간중간 나누는 편이 안전하다고 생각합니다.
사실 이건 3장에서 '생각을 먼저 전파하자'고 말씀드렸던 것과도 통하는 이야기입니다.
거기선 구현 방향을, 여기선 작업 일정을 — 둘 다 '다 끝난 뒤 한 번에'가 아니라 '진행하면서 미리미리' 꺼내 놓자는, 같은 마음이고요.

P33 · 원칙 1 — 정직하게 〔내용 · A〕

[화면]

   원칙 1

   과장도, 축소도 ✕ — 있는 그대로
   추정도 '점'이 아니라 '범위 + 모르는 것'으로

[연출] 이미지 없음 · 타이포 — '원칙 1' eyebrow + 핵심 문구. '범위 + 모르는 것' 한 줄 강조.

[발표자 노트]

그럼 그 공유를 할 때 지킬 만한 원칙이 몇 가지 있습니다.
첫째, 과장도 축소도 하지 않는 것입니다.
일정을 부풀리거나 줄여 말하면, 그것을 바탕으로 세운 주변의 계획이 통째로 틀어집니다.
어차피 정직하게 산정해도 어긋나는데, 거기에 왜곡까지 얹으면 손쓸 수 없게 됩니다.
좋게 보이려는 욕심이나 불안 때문에 숫자를 비틀지 않고, 있는 그대로 공유해야 한다고 생각합니다.
그리고 일정을 추정할 때도 마찬가지예요.
'3일이요'처럼 숫자 하나로 못 박기보다, '2~4일이요, 단 ○○를 아직 몰라서 더 걸릴 수도 있어요'처럼 범위와 모르는 부분을 함께 말하는 편이 더 정직합니다.
정확히 맞히는 것보다, 내가 무엇을 모르는지를 솔직히 드러내는 게 더 중요하니까요.

P34 · 원칙 2 — 막힘 공유 〔내용 · A〕

[화면]

   원칙 2

   막힘·슬럼프를 숨기지 않기
   — 일찍 꺼내 도움받기

[연출] 이미지 없음 · 타이포 — '원칙 2' eyebrow + 핵심 문구 크게.

[발표자 노트]

둘째, 느린 진척이나 슬럼프를 숨기지 않는 것입니다.
진도가 안 나가거나 막혔을 때 숨기고 싶은 것이 사람 마음이지만, 그게 가장 위험합니다.
최소한 리더에게는 솔직하게 알리고, 해결 방법을 미리 함께 논의하는 것이 좋습니다.
혼자 끙끙대다 막판에 터뜨리는 것보다, 일찍 꺼내어 도움을 받는 편이 모두에게 낫다고 생각합니다.

P35 · 매일, 스스로 점검한다 〔실천 · A〕

[화면]

   매일, 스스로 점검한다 (아침 5분)

   · 내 진척이 계획대로인가? 밀리고 있진 않나?
   · 리더에게 알릴 게 있나?

   → 있으면, 먼저 리더와 논의
   → 필요하면 요청자에게도

[연출] 이미지 없음 · 타이포 — 셀프 점검 2~3질문 + 에스컬레이션(리더 → 필요시 요청자).

[발표자 노트]

정직하게, 그리고 막힘을 숨기지 않고 — 여기까지가 공유할 때 지킬 '자세'였습니다.
그럼 이걸 실제로 어떻게 해나갈까요. 지금부터는 '실천'입니다.
거창한 도구는 필요 없고, 저는 매일 아침 5분, 스스로 점검하는 습관을 권하고 싶습니다.
'내 진척이 계획대로인가, 혹시 밀리고 있진 않나, 리더에게 알릴 만한 게 있나'를 스스로 묻는 거예요.
그러다 알릴 게 보이면, 곧장 여기저기 퍼뜨리는 게 아니라 먼저 리더와 가볍게 논의합니다.
그리고 리더와 이야기해 본 뒤 필요하다 싶으면, 그때 요청자에게도 공유하고요.
이렇게 매일 짧게 점검하는 것만으로도, 문제가 곪기 전에 일찍 드러납니다.

P36 · 지연을 알릴 땐, 선택지와 함께 〔실천 · A〕

[화면]

   지연을 알릴 땐 — '문제'가 아니라 '선택지'를
      · 후순위로 미루기
      · 오래 걸려도 제대로
      · 간소화해서 넘기기

   안 떠오르면 → "잘 모르겠어요, 도와주세요"도 충분

[연출] 이미지 없음 · 타이포 — 선택지 메뉴 3개 + 마지막 '도와주세요'를 따뜻하게 강조.

[발표자 노트]

셋째, 지연을 알릴 때는 '문제'만 던지지 않고 '선택지'를 함께 건네는 것입니다.
'늦어요'라는 사실만 던지면 받는 사람은 막막하니까요.
밀리는 부분이 있다면, 저는 보통 이런 선택지를 들고 리더에게 물어봅니다.
가장 나은 건 대개 그 작업을 후순위로 미루는 것이고요.
미루기 어렵다면, 오래 걸리더라도 요청자에게 공유하고 제대로 만들거나, 아니면 간소화해서 넘기는 방법이 있습니다.
이렇게 선택지와 trade-off를 정리해 드리면, 상대가 판단하기 훨씬 쉬워집니다.
물론 결정 자체는 요청자나 매니저의 몫이고요.
이건 2장에서 말씀드린 '어렵다고 끝내지 말고 대안을 함께'와 똑같은 자세입니다.
다만, 좋은 선택지가 도무지 안 떠오를 때도 있습니다.
그럴 땐 어설픈 선택지를 억지로 짜내기보다, 그냥 '저는 잘 모르겠어요, 도와주세요'라고 솔직히 말하는 것도 충분히 좋은 공유라고 생각합니다.

P37 · 누구에게, 어떻게 공유하나 〔실천 · A〕

[화면]

   누구에게 — 진행을 '책임지는' 사람
   (매니저 · PM · 리더)

   수단은 가벼워도 된다(비동기 · 기록)
   단, '올려둠' ≠ '그 사람이 봤다'

[연출] 이미지 없음 · 타이포 — '누구에게 / 수단' 2단 레이아웃. "'올려둠' ≠ '봤다'" 강조.

[발표자 노트]

마지막으로, 누구에게 어떻게 공유하느냐입니다.
가장 중요한 것은, 그 일의 진행을 책임지는 사람 — 보통은 매니저나 PM, 리더겠죠 — 에게 확실히 닿게 하는 것입니다.
일정이 흔들릴 때 우선순위를 조정하고 대응을 결정하는 분들이 바로 그들이기 때문입니다.
수단 자체는 무겁지 않아도 됩니다.
꼭 직접 불러서 회의할 필요는 없고, 팀 채널이나 문서, 이슈 같은 곳에 비동기로 적어 두는 것으로도 충분할 때가 많습니다.
다만 한 가지만 기억하면 좋겠습니다.
'공적인 공간에 올려뒀으니 됐다'와 '책임지는 사람이 실제로 봤다'는 다릅니다.
그분이 보는 자리에 올리거나, 필요하면 '여기 있으니 참고해 주세요' 하고 콕 집어 알려서, 정보가 정말 가닿게 하는 것까지가 공유라고 생각합니다.

P38 · 정리 — 실무 역량, 세 가지 〔정리 · B 요약〕

[화면]

   실무 역량, 세 가지

   ①  피드백      — 목적 이해 + 적극 역제안
   ②  전파·기록   — 먼저 공유 + 의도/근거 남기기
   ③  일정 관리   — 주기적·정직하게 공유

[연출]

배치: 직접 설계 도식 (AI 생성 아님)
목적: 토대(코딩) 위 실무 역량 3개를 한 장으로 요약 — P9 '두 층'을 회수.
구성: P9의 토대 블록 위에 ①피드백 ②전파·기록 ③일정 관리 세 항목을 얹은 모습.
      P9와 같은 시각 언어로 연결. 빌드로 셋을 하나씩 등장시켜도 좋음.

[발표자 노트]

이제 정리해 보겠습니다.
여기까지가 실무 역량 세 가지였습니다.
코딩은 우리의 기본이고, 그 위에 한 겹씩 더하는 실무 역량 셋을 이야기했습니다.
피드백은, 명세의 목적을 먼저 이해하고 빈틈에 적극적으로 역제안하는 것.
생각의 전파는, 제 생각과 방향을 먼저 공유하고 의도와 근거를 기록으로 남기는 것.
일정 관리는, 진척과 리스크를 주변에 주기적으로, 정직하게 공유하는 것이었습니다.

P39 · 결국은 '함께 일하는 법' 〔정리 · A〕

[화면]

   "이런 것들도 결국,
    우리의 업무입니다"

   — 코딩을 넘어 '함께 일하는 법'도 하나의 능력

[연출] 이미지 · 풀블리드 16:9 (마무리 문구 여백) — 아래 블록 복사

Editorial illustration on a dark near-black background, cool teal/cyan as the primary accent (matching the deck), balanced by a warm secondary accent (soft amber) and off-white linework; muted and desaturated, subtle film grain, soft glow lighting, quiet and warm yet purposeful mood. Not monochrome — the warm accent keeps it from becoming a flat teal-on-black wash. No text, no letters, no logos.
16:9, leave a calm uncluttered area for the title text.
Land the closing message — beyond coding, 'working together' is itself a skill.
A few figures around a shared piece of work in easy, warm collaboration — one of them the same developer from the cover. Quietly positive, a sense of belonging, echoing the cover so the talk comes full circle.

[발표자 노트]

이 셋을 관통하는 하나는, 결국 '내가 코딩을 잘하는 것'을 넘어 '다른 사람과 함께 일하는 법'을 배우는 것이라고 생각합니다.
그리고 이것은 곁다리가 아니라 그 자체로 하나의 '일'이자 '능력'입니다.
코딩이 그렇듯, 배우고 늘릴 수 있고요.
처음에 '이런 것까지 제가 해야 하나' 싶은 순간들이 온다고 말씀드렸죠.
네, 이런 것들도 결국 우리의 업무라고 생각합니다.
그리고… 끝으로, 한 가지만 더 나누고 싶습니다.

P40 · AI 시대에 대해 — 개인적인 생각 〔정리 · A〕

[화면]

   AI 시대에도 — 개인적인 생각

   AI도 결국 사람의 말·방식을 흉내 내는 존재
   → 오늘의 이야기가 'AI와 일할 때'도 그대로 통하더라

[연출] 이미지 · 패널 1:1 (문구와 나란히) — 아래 블록 복사

Editorial illustration on a dark near-black background, cool teal/cyan as the primary accent (matching the deck), balanced by a warm secondary accent (soft amber) and off-white linework; muted and desaturated, subtle film grain, soft glow lighting, quiet and warm yet purposeful mood. Not monochrome — the warm accent keeps it from becoming a flat teal-on-black wash. No text, no letters, no logos.
1:1 square, self-contained composition, plain deep near-black background so it blends seamlessly into the dark slide.
Convey that the same principles extend to collaborating with AI.
A person and a friendly abstract AI presence (a soft geometric teal form) working side by side over a shared shape/task — mirroring the human-to-human collaboration shown earlier. Calm and warm, not sci-fi or dramatic.

[발표자 노트]

요즘 빼놓을 수 없는 AI 이야기입니다.
'AI가 다 해주는 시대에 이런 게 무슨 의미가 있나' 싶으실 수도 있습니다.
그런데 제 경험은 조금 달랐습니다.
AI도 결국 사람의 말과 일하는 방식을 흉내 내는 존재이기 때문입니다.
그래서 오늘 이야기한 것들이, AI와 함께 일할 때도 거의 그대로 통하더라고요.
하나씩 짚어보겠습니다.

P41 · AI와 일할 때도 — 피드백·기록·일정 〔정리 · A〕

[화면]

   AI와 일할 때도, 그대로

   · 피드백 — AI에 '어떻게 피드백하나'가 결과 퀄리티를 좌우
   · 기록   — AI를 시켜서라도 과정·결과를 남겨야 맥락·일관성 유지
   · 일정   — 도구가 바뀌어도, 일정 관리는 여전히 내 몫

   → 코딩은 AI가 거들수록, 이 힘이 더 중요해질지도

[연출] 이미지 없음 · 타이포 — 세 가지(피드백/기록/일정)가 AI에서도 회수 + 마지막 한 줄 강조.

[발표자 노트]

먼저 피드백입니다.
AI에게 일을 시킬 때, '어떻게 피드백을 주느냐'가 결과물의 퀄리티를 정말 크게 좌우하더라고요.
명세를 그대로 던지지 않고 목적과 빈틈을 짚어 되묻듯이, AI에게도 그렇게 할수록 결과가 좋아졌습니다.
다음은 기록입니다.
AI와 길게 작업하다 보면 맥락이 흐려지기 쉬운데, AI를 시켜서라도 중간 과정과 결과를 남겨 두니 이후 작업의 맥락을 유지하고 품질을 일관되게 가져가는 데 큰 도움이 됐습니다.
마지막으로 일정입니다.
이건 도구가 AI로 바뀌어도 달라지지 않습니다.
AI를 쓰든 안 쓰든, 제 작업의 진척을 주변과 맞춰 가는 일정 관리는 여전히, 똑같이 중요했습니다.
그리고 코딩 그 자체는 점점 AI가 거들 수 있게 되니, 오히려 이 '일이 굴러가게 만드는 힘'이 더 중요해질지도 모릅니다.
물론 이것은 어디까지나 제 개인적인 생각입니다.

P42 · 마무리 〔마무리 · A〕

[화면]

   감사합니다

   작은 참고가 되었기를 바랍니다 · Q&A

[연출] 이미지 · 풀블리드 16:9 (감사 문구 여백) — 아래 블록 복사

Editorial illustration on a dark near-black background, cool teal/cyan as the primary accent (matching the deck), balanced by a warm secondary accent (soft amber) and off-white linework; muted and desaturated, subtle film grain, soft glow lighting, quiet and warm yet purposeful mood. Not monochrome — the warm accent keeps it from becoming a flat teal-on-black wash. No text, no letters, no logos.
16:9, leave a calm uncluttered area for the title text.
Leave a calm, grateful afterglow.
The developer from the cover, now standing a little more confidently, looking toward an open horizon of soft teal and amber light. Minimal, serene, a sense of quiet closing.

[발표자 노트]

오늘 드린 이야기가 정답은 아니지만, 여러분이 성장해 나가시는 길에 작은 참고 하나가 되었으면 좋겠습니다.
들어주셔서 감사합니다.
질문 있으시면 편하게 해주시기 바랍니다.