# 발표 내용 (텍스트 정리본) > `발표.md`에서 **화면 문구 + 발표자 노트**만 추려 정리한 읽기·연구용 텍스트입니다. > (이미지/도식 연출 등 제작 지침은 제외) --- ## P1 · 표지 > 코더를 넘어 > 프로그래머로 > > 주니어 개발자가 팀의 신뢰를 얻는 방법 > > > ○○○ · 넥슨 안녕하세요. 넥슨에서 17년째 게임 서버를 만들고 있는 ○○○입니다. 오늘은 '코더를 넘어 프로그래머로'라는 제목으로, 주니어 개발자분들과 함께 나누고 싶은 이야기를 준비했습니다. 편하게 들어주시면 감사하겠습니다. --- ## P2 · 잠깐, 용어부터 > 잠깐, 용어부터 > > '코더'와 '프로그래머' > — 정착된 정의가 아니라, 통념에서 빌려온 용어 오늘 '코더에서 프로그래머로'라는 이야기를 드릴 텐데요, 시작하기 전에 한 가지 솔직하게 짚고 싶은 것이 있습니다. 사실 이 두 단어는 어딘가에 정착된 정의가 있다기보다, 통념에서 빌려온 용어에 가깝습니다. 학술적으로 정해진 것도, 업계에서 똑같이 통용되는 것도 아니고요. 그래서 오늘은 그 통념적인 의미로 빌려 쓰려고 합니다. '코더'는 주어진 일을 그대로 해내는 사람, '프로그래머'는 실무에서 주변 동료들에게 인정받는 사람 정도의 의미로 생각해 주시면 될 것 같습니다. --- ## P3 · 발표의 한계 > 정답이 아니라, > 개인의 경험을 바탕으로 한 의견입니다 그리고 미리 말씀드리면, 이 구분도 앞으로 드릴 이야기도 굉장히 주관적이고 개인적일 수 있습니다. 정답이라기보다는, 제 경험과 주변 동료들과의 토론을 바탕으로 정리한 하나의 의견이라고 봐주시면 좋겠습니다. 그래서 오늘 뭔가 대단한 충격을 드리거나 '이게 정답이다'라고 말씀드리려는 것은 아닙니다. 여러분이 성장해 나가시는 길에 작은 참고 하나가 되면 좋겠다는 마음으로 준비했습니다. --- ## P4 · 오늘 나누고 싶은 이야기 > 상상했던 '프로그래머'의 모습과 > 막상 마주하는 일은 다릅니다 > > "이런 것까지 제가 해야 하나?" 프로그래머라는 직업을 처음 가질 때, 누구나 머릿속에 그리던 모습이 있습니다. 대중이 떠올리는 프로그래머의 이미지도 있고요 — 좋게든, 나쁘게든 말이죠. 그런데 막상 일을 해보면, 생각했던 것과는 사뭇 다른 일들을 하게 됩니다. 그러다 보면 '이런 것까지 제가 해야 하나?' 하는 마음이 들 때가 생기죠. 오늘은 바로 그런 것들에 대한 이야기입니다. --- ## P5 · 오늘의 순서 > 오늘의 순서 > > 1. 코딩 그리고 그 너머의 무언가 > 2. 피드백 > 3. 생각의 전파와 기록 > 4. 일정 관리 > 5. 정리 오늘 순서는 이렇습니다. 먼저 코딩 너머의 무언가가 왜 필요한가를 짧게 짚어보고, 그다음 프로그래머가 신경 쓰게 되는 세 가지 — 피드백, 생각의 전파와 기록, 그리고 일정 관리 — 를 차례로 보겠습니다. 마지막에는 가볍게 정리하겠습니다. --- ## P6 · 1장. 코딩 그리고 그 너머의 무언가 > 1 > > 코딩 그리고 > 그 너머의 무언가 먼저, 바탕 이야기부터 하겠습니다. --- ## P7 · 코딩 그 너머? > 우리의 기본은 코딩 > 그런데 그 너머는 무엇이고 왜 필요한가? 개발자의 출발점이자 토대는 코딩입니다. 이건 변하지 않는 부분이라고 생각합니다. 코딩을 잘하는 것은 여전히, 그리고 앞으로도 중요하고요. 그런데 — 여기서부터는 제 주관적인 생각입니다만 — 그 '너머'에는 무엇이 있고, 또 왜 필요할까요? 저는 실무가 코딩 이상의 것을 필요로 하기 때문이라고 생각합니다. --- ## P8 · 상상과 현실 > 입사 전엔 → 앉아서 코딩, 구조 설계… '너드'한 작업을 떠올리지만 > 실제로는 → 회의 · 문서 정리 · 명세 수정해서 돌려보내기 > > ⇒ 코딩 아닌 일의 비중이, 생각보다 높습니다 입사하기 전에는, 개발자가 되면 종일 자리에 앉아 코딩을 하고, 구조를 설계하고, 뭔가에 깊이 몰두하는 '너드' 같은 일을 주로 할 거라고 상상하기 쉽습니다. 그런데 막상 일을 해보면, 회의를 하고, 문서를 정리하고, 명세서를 검토해서 수정 의견을 돌려보내고… 이렇게 코딩 그 자체가 아닌 일의 비중이 생각보다 훨씬 높습니다. 처음에는 조금 의아하게 느껴질 수도 있지만, 이건 곁다리가 아니라고 생각합니다. --- ## P9 · 코딩(기본) + 실무 역량(그 위에) > ┌───────────────────────┐ > │ 실무 역량 (코드 바깥) │ ← 그 위에 더하는 층 > ├───────────────────────┤ > │ 코딩 (토대) │ ← 기반이 되는 층 > └───────────────────────┘ > > 둘 다 '배우고 늘리는 기술' 그래서 저는 이렇게 봅니다. 코딩이라는 기본 위에 '실무 역량'을 한 겹 더 얹는 것, 그게 실무가 요구하는 모습이 아닐까 합니다. 여기서 실무 역량이란, 코드 바깥에서 '일이 되게 만드는' 힘입니다. 동료와 맞춰 가고, 빈틈을 미리 보고, 일정을 예측 가능하게 만들고, 완성도를 챙기는 일이라고 할 수 있습니다. 다행인 점은, 이것도 타고나는 센스가 아니라 코딩처럼 배우고 늘릴 수 있는 기술이라는 것입니다. 오늘은 그 실무 역량을 세 가지로 나눠 보겠습니다. 피드백, 생각의 전파와 기록, 그리고 일정 관리입니다. --- ## P10 · 2장. 피드백 > 2 > > 피드백 > — 받은 일을 '그대로' 받지 않기 첫 번째는 피드백입니다. 받은 일을 '그대로' 받지 않는 것에서 시작합니다. --- ## P11 · 명세서의 빈틈, 누구의 몫일까 > 명세서의 빈틈, > 누구의 몫일까? 작업 명세서가 충실하지 못하다고 느낀 적, 있지 않으신가요? '왜 이런 예외 케이스 처리가 빠져 있지?' 하고 답답했던 적은 없으신가요? 여기서부터는 제 주관적인 생각입니다만, 저는 명세서의 빈틈을 찾아 메우는 역할이 디자이너보다 오히려 프로그래머에게 있다고 보는 편입니다. 물론 절대적인 것은 없습니다. 디자이너도 빈틈없는 명세를 만들기 위해 노력해야 한다고 생각합니다. 다만 논리적으로 빈틈없는 디자인에 대한 책임의 꽤 많은 비중은 프로그래머에게 있다고 봅니다. --- ## P12 · 왜 그게 프로그래머의 몫일까 > 디자인은 '목적을 구체화'하는 일, > 프로그래밍은 '빈틈없는 설계'를 하는 일 왜냐하면 기획이나 디자인을 하는 분은 '목적을 위해 시스템이나 컨텐츠를 구체적으로 그려내는 사람'이라, '안전하고 빈틈없는 결과물'을 만드는 것과는 결이 조금 다른 방향으로 일하게 되기 때문입니다. 반대로 안전하고 빈틈없는 설계를 해내는 것 자체는 프로그래머의 일이라고 할 수 있습니다. 그러니 오히려 프로그래머가 빈틈없는 명세를 완성하는 데 큰 역할을 할 수 있다고 생각합니다. 그럼 그 '빈틈 메우기'를 어떻게 하면 좋을지, 세 가지 원칙으로 풀어보겠습니다. --- ## P13 · 원칙 1 — 목적 이해 > 원칙 1 > > "어떻게"가 아니라 "무엇을 위해" > — 목적을 먼저 이해한다 첫 번째 원칙은, 명세서가 '무엇을 위한 것인지' 그 목적을 먼저 이해하는 것입니다. 명세를 그대로 받아들이지 않고, 요청자와 문답을 통해 이게 실제로 무엇을 노리는지를 분명히 파악하는 것이죠. 왜 목적을 알아야 할까요? 명세는 '무엇을 어떻게'까지는 적지만, 현실의 모든 디테일을 담지는 못합니다. 구현하다 보면 명세에 없는 빈칸을 수없이 만나게 되는데요, 목적을 알면 그 빈칸을 스스로 옳게 채울 수 있습니다. --- ## P14 · (예시) 출석 이벤트 > "출석 이벤트를 만들어 주세요" > > 명세 그대로 → 출석판·일자별 보상·연속 보너스·누락 처리 (복잡) > 목적은? → '초반 접속 유저에게 선물 → 재접속 유도' > 그러면 → ✉ 우편 접속 보상으로 충분 예를 들어보겠습니다. '출석 이벤트를 만들어 주세요'라는 요청을 받았다고 해보겠습니다. 그대로 받으면 출석판 UI, 일자별 보상, 연속 출석 보너스, 누락 처리까지 꽤 복잡한 시스템을 다 만들어야 합니다. 그런데 목적을 물어보니 원하는 것은 의외로 단순했습니다. '초반에 접속하는 유저들에게 선물을 줘서 재접속을 유도하고 싶다'는 것이었죠. 목적이 그렇다면 굳이 복잡한 출석 시스템이 아니어도 됩니다. '그러면 우편으로 접속 보상을 주는 방식은 어떨까요?'라고 훨씬 가벼운 길을 제안할 수 있습니다. 명세만 봤다면 그 시스템을 다 만들었을 일을, 목적을 이해했기에 더 단순하게 풀 수 있는 것입니다. 물론 우편으로 보상을 지급하는 것이 출석 시스템보다 더 좋다는 뜻은 아닙니다. 현실성을 고려할 때 더 가벼운 작업으로 가는 편이 좋은 경우도 있다는 점에서 착안한, 단순한 예시입니다. --- ## P15 · 원칙 2 — 적극 역제안 > 원칙 2 > > "어렵다"로 끝내지 말고, > 목적에 맞는 대안을 두 번째 원칙은, 피드백과 역제안에 적극적이어야 한다는 것입니다. 빈틈을 발견하는 데 그치지 않고, '어렵다'로 끝내는 대신 목적에 맞는 대안을 함께 내미는 것이죠. 왜냐하면 그게 프로그래머의 역할이라고 생각하기 때문입니다. 발견은 메움으로 이어져야 의미가 있고, '어렵다'고 선만 그으면 요청자는 막막해질 뿐입니다. --- ## P16 · "기술은 제가, 재미는 당신이" > "기술은 제가 챙길 테니, > 재미에 집중하세요" 그리고 한 걸음 더 — 이렇게 적극적으로 메우겠다는 것을 요청자에게 '미리' 알리는 것 자체가 중요하다고 봅니다. 요청자가 '이게 기술적으로 될까'를 혼자 걱정하기 시작하면, 그 불안 때문에 과한 제약을 걸어서 재미를 깎는 디자인을 가져오기 쉽기 때문입니다. '엣지 케이스나 기술적인 빈틈은 제가 메울 테니, 재미를 만드는 본업에 집중해 주세요' — 이런 신호가 역할을 제자리로 돌려서, 결국 더 좋은 게임을 만든다고 생각합니다. --- ## P17 · (사례) 실시간 랭킹 > "실시간 갱신은 어렵겠지…" > — 디자이너가 과거 경험상 미리 긋는 제약 > > 하지만 요즘은, 도구·설계에 따라 가능한 경우도 많다 > (그걸 디자이너가 판단하긴 어렵다) > > → "제약·피드백은 제가 챙길 테니, > 목적에 맞게 명세를 먼저 만들어 주세요" 사실 랭킹 시스템을 작업할 때 이런 걸 자주 느꼈습니다. 많은 디자이너분들이 랭킹을 디자인하면서, '랭킹 갱신을 실시간으로 하기는 어려울 수 있다'는 점을 미리 염두에 두시더라고요. 아마 이전에 그런 경험을 많이 하셨기 때문일 겁니다. 하지만 요즘은 도구도 많이 발전했고, 설계나 목적에 따라서는 실시간 갱신이 충분히 가능한 경우도 많습니다. 다만 이걸 디자이너분이 직접 판단하기는 어렵죠. 그래서 저는 '기술적인 제약이나 피드백은 필요할 때 제가 미리 드릴 테니, 우선 디자인의 목적에 맞게 명세서를 만들어 주세요'라고 의견을 전하는 편입니다. 그렇게 하는 것이 훨씬 더 좋은 결과물로 이어진다고 생각합니다. --- ## P18 · 원칙 3 — 주객전도 경계 > 원칙 3 > > 내 역할은 '피드백'까지, > 결정은 요청자의 몫 세 번째 원칙은, 자신의 역할을 분명히 이해하는 것입니다. 우리는 구현자이고, 요청자가 결국 그 컨텐츠의 결정권자입니다. 적극적으로 의견을 내고 논의를 이끌되, 주객이 전도되어 우리가 결정을 내리려 해서는 안 된다고 생각합니다. 이 선만큼은 단호하게 지켜야 한다고 생각합니다. 특히 디자인 자체에 대한 평가, '이거 별로다' 같은 말은 절대로 하지 않아야 합니다. 우리가 제안하는 것은 디자인의 좋고 나쁨이 아니라 '목적을 이루는 더 나은 길'이니까요. 그래서 원칙 2의 적극성과 원칙 3의 선 지키기는 충돌하지 않습니다. 적극적으로 제안하되, 결정은 요청자의 몫으로 남기는 것입니다. --- ## P19 · 3장. 생각의 전파와 기록 > 3 > > 생각의 전파와 기록 > — 주고받기를 넘어, 퍼뜨리고 남기기 두 번째는 생각의 전파와 기록입니다. 피드백이 일을 '주고받을 때'의 소통이었다면, 이번에는 제 생각을 '퍼뜨리고 남기는' 쪽이라고 할 수 있습니다. --- ## P20 · 잘 만드는 것 못지않게, 전파하고 남기기 > 잘 만드는 것 못지않게, > 전파하고 남기기 > > — 우리는 프로덕트를 계속 '유지·발전'시키는 사람 좋은 결과물을 만드는 것은 중요합니다. 그런데 그것 못지않게 중요한 것이 있다고 생각합니다. 제가 무엇을, 왜, 어떻게 만들었는지를 주변에 전파하고 흔적으로 남기는 일입니다. 왜냐하면 우리는 프로덕트를 한 번 만들고 끝내는 사람이 아니라, 계속 유지하고 발전시켜야 하는 사람들이기 때문입니다. 그러려면 제 머릿속에만 있는 판단과 의도가, 저와 동료 사이에, 그리고 저와 '미래의 저' 사이에 공유되어 있어야 합니다. 공유되지 않은 생각은 시간이 지나면 저조차 다시 해독해야 하는 비용이 되더라고요. --- ## P21 · 원칙 1 — 읽기 좋은 코드 > 원칙 1 > > 읽기 좋은 코드 > = 가장 가까운 '전파' 첫 번째는, 너무 당연한 이야기지만 그만큼 중요해서 굳이 원칙 하나로 두었습니다. 읽기 좋은 코드를 쓰는 것입니다. 코드는 한 번 쓰이고 수십 번 읽힙니다. 읽기 좋은 코드는 그 자체로 가장 가까운 '전파'라고 생각합니다. 문서나 주석은 따로 찾아봐야 하지만, 코드는 늘 거기 있으니까요. 명확한 이름, 적절히 쪼갠 구조, 과한 영리함보다 단순한 명료함 — 결국 미래의 독자에게 의도를 바로 건네는 일입니다. --- ## P22 · 원칙 2 — 먼저 전파 > 원칙 2 > > 다 만든 뒤 통보가 아니라, '먼저' > > 작은 공유 하나가 > 다시 만들 일을 크게 줄인다 두 번째는, 생각과 방향을 '먼저' 전파하는 것입니다. 다 만든 뒤에 통보하는 것이 아니라, 만들기 전이나 만드는 중에 생각을 먼저 꺼내 놓고, 이 방향이 괜찮은지 미리 확인을 받는 것이죠. 왜 굳이 먼저 꺼낼까요. 먼저 공유하면, 제가 모르고 있던, 이미 구현돼 있는 기능을 가져다 쓰는 편이 낫다는 걸 알게 되기도 합니다. 또 제가 미처 보지 못한 점을 누군가 미리 짚어 주기도 하고요. 결국 가벼운 공유 하나로, 들일 작업의 양과 다시 만들게 될 확률을 꽤 크게 줄일 수 있습니다. 다 만든 뒤에 어긋난 걸 알면 되돌리기 어렵지만, 먼저 꺼내 두면 훨씬 값싸게 고칠 수 있으니까요. --- ## P23 · 먼저 전파하는 법 > '먼저 전파'를 실천하는 법 > > · 작업 방향을 먼저 문서로 — 누구나 볼 수 있게 열어두기 > · 피드백이 꼭 필요하면 — 1~2명에게 콕 집어 부탁 > · 주기적 회의(스크럼 등)가 있으면 — 한두 줄 요약 + 링크면 충분 그럼 '먼저 전파'를 실제로 어떻게 하면 좋을까요. 거창할 필요는 없습니다. 기본은, 작업의 방향성을 먼저 간단히 문서로 적어 두고 누구나 원하면 볼 수 있게 열어두는 것입니다. 만약 그 방향에 대해 피드백을 적극적으로 받고 싶은 상황이라면, 한두 명에게 콕 집어 봐달라고 부탁하면 됩니다. 그리고 스크럼처럼 주기적인 회의가 있다면, 작업 방향을 한두 줄로 축약해서 링크와 함께 공유하는 정도로도 충분합니다. --- ## P24 · 원칙 3 — 왜를 기록 > 원칙 3 > > 코드는 '무엇'은 보여줘도 '왜'는 못 한다 > → 문서·주석·커밋·PR에 '왜'를 남긴다 세 번째는, 의도와 판단 근거를 기록으로 남기는 것입니다. 결과물인 코드만 남기지 않고, '왜 이렇게 만들었는지', '왜 이런 판단을 할 수밖에 없었는지'를 함께 남기는 것이죠. 코드는 '무엇을' 하는지는 보여주어도 '왜'는 잘 보여주지 못하기 때문입니다. 그래서 문서, 주석, 커밋 메시지, 그리고 MR이나 PR 설명에 그 '왜'를 함께 남겨 두는 것이 좋다고 생각합니다. --- ## P25 · (예시) '왜'를 복원하다 > "왜 이렇게 짰지?" — 코드만으론 막힐 때 > > (낡았어도) 문서 · 커밋 메시지 · PR 논의 > → "아, 이런 제약 때문이었구나" 실제로, 한참 뒤에 문제가 터졌을 때 코드만 봐서는 도무지 이해가 안 되는 순간이 옵니다. 그때 단서가 되는 것이, 조금 낡았더라도 설계 문서와 커밋 메시지, 연관된 PR의 논의입니다. 거기서 '아, 그때 이런 제약 때문에 일부러 이렇게 둔 것이구나' 하고 풀립니다. 기록은 미래의 누군가, 대개 미래의 제 자신이 '왜'를 복원할 수 있게 해줍니다. --- ## P26 · 4장. 일정 관리 > 4 > > 일정 관리 > — 내 '진행 상황'도 공유 대상 세 번째는 일정 관리입니다. 생각만 공유 대상이 아닙니다. 제 '진행 상황', 즉 일정도 똑같이 공유해야 한다고 생각합니다. --- ## P27 · 주기적으로 공유하기 > 일정 관리의 핵심 > = 주변에 '주기적으로' 공유하기 일정 관리도 엄연히 업무의 일부입니다. 다만 일정을 잘 예측하고 그대로 잘 지키는 것, 이건 당연한 목표지만 왕도가 없는 것 같습니다. 경험으로 감을 키우는 수밖에 없으니 길게 다루지는 않겠습니다. 정작 이야기하고 싶은 것은 따로 있습니다. 제 작업 일정을 주변, 그러니까 요청자나 매니저, PM에게 주기적으로 공유하는 것입니다. '늦어지고 있어요', '생각보다 빨라요', '제대로 끝날 것 같아요', '지금 이만큼 됐어요' 같은 신호를 꾸준히 보내는 것이죠. --- ## P28 · 왜 공유가 중요한가 > 문제는 '틀어짐'이 아니라, > 주변이 '모르는' 것 > > (내 지연 = 남의 지연) 왜 중요한가 하면, 정직하게 산정해도 일정은 틀어지기 마련이기 때문입니다. 문제는 틀어지는 것 자체가 아니라, 그것을 주변이 모르고 있는 것입니다. 게다가 제 일정은 늘 누군가의 일정과 연결되어 있습니다. 제 서버 API를 클라 팀이 기다리고 있다면, 제 지연이 곧 그 팀의 지연이 되는 것이죠. 그래서 꾸준한 공유가 팀에게 미리 대응할 시간을 벌어줍니다. --- ## P29 · '짠' 공개가 위험한 이유 > 다 만들어 '짠' 공개하면, > > 그동안 방향이 어긋나 있어도 > 막판에야 알게 된다 또 하나의 이유가 있습니다. 다 만들어서 '짠' 하고 한 번에 공개하고 싶은 마음이 들 때가 있습니다. 즐거운 일이지만, 사실 위험합니다. 그동안 방향이 어긋나 있었더라도 막판에야 알게 되고, 문제가 숨어 있었다면 그때 한꺼번에 터지기 때문입니다. 그래서 결과를 한 번에 보여주기보다, 과정을 중간중간 나누는 편이 안전하다고 생각합니다. --- ## P30 · 원칙 1 — 정직하게 > 원칙 1 > > 과장도, 축소도 ✕ > — 있는 그대로 그럼 그 공유를 할 때 지킬 만한 원칙이 몇 가지 있습니다. 첫째, 과장도 축소도 하지 않는 것입니다. 일정을 부풀리거나 줄여 말하면, 그것을 바탕으로 세운 주변의 계획이 통째로 틀어집니다. 어차피 정직하게 산정해도 어긋나는데, 거기에 왜곡까지 얹으면 손쓸 수 없게 됩니다. 좋게 보이려는 욕심이나 불안 때문에 숫자를 비틀지 않고, 있는 그대로 공유해야 한다고 생각합니다. --- ## P31 · 원칙 2 — 막힘 공유 > 원칙 2 > > 막힘·슬럼프를 숨기지 않기 > — 일찍 꺼내 도움받기 둘째, 느린 진척이나 슬럼프를 숨기지 않는 것입니다. 진도가 안 나가거나 막혔을 때 숨기고 싶은 것이 사람 마음이지만, 그게 가장 위험합니다. 최소한 상급자에게는 솔직하게 알리고, 해결 방법을 미리 함께 논의하는 것이 좋습니다. 혼자 끙끙대다 막판에 터뜨리는 것보다, 일찍 꺼내어 도움을 받는 편이 모두에게 낫다고 생각합니다. --- ## P32 · 원칙 3 — 선택지 함께 > 원칙 3 > > 지연을 알릴 땐 > '문제'가 아니라 '선택지'를 셋째, 지연을 알릴 때는 '문제'만이 아니라 '선택지'를 함께 건네는 것입니다. '늦어요'라는 사실만 던지면 받는 사람은 막막합니다. 한 걸음 더 나아가서, '이대로면 늦지만, 이렇게 하면 됩니다'까지 함께 내미는 것이죠. 예를 들면 '지금 속도면 마감을 넘기는데, B 기능을 다음 빌드로 미루면 맞출 수 있고, 범위를 그대로 가면 며칠이 더 필요합니다. 어느 쪽이 나을까요?' 하고 말씀드리는 것입니다. 우선순위 조정이나 범위 축소 같은 선택지와 그 trade-off를 정리해서, 상대가 판단하기 쉽게 만들어 드리는 것이죠. 결정 자체는 요청자나 매니저의 몫입니다. 이건 앞서 2장에서 말씀드린 '어렵다고 끝내지 말고 대안을 함께'와 똑같은 자세입니다. 일정 공유를 '보고'에서 '협업'으로 끌어올리는 지점이라고 생각합니다. --- ## P33 · 누구에게, 어떻게 공유하나 > 누구에게 — 진행을 '책임지는' 사람 > (매니저 · PM · 리드) > > 수단은 가벼워도 된다(비동기 · 기록) > 단, '올려둠' ≠ '그 사람이 봤다' 마지막으로, 누구에게 어떻게 공유하느냐입니다. 가장 중요한 것은, 그 일의 진행을 책임지는 사람 — 보통은 매니저나 PM, 팀 리드겠죠 — 에게 확실히 닿게 하는 것입니다. 일정이 흔들릴 때 우선순위를 조정하고 대응을 결정하는 분들이 바로 그들이기 때문입니다. 수단 자체는 무겁지 않아도 됩니다. 꼭 직접 불러서 회의할 필요는 없고, 팀 채널이나 문서, 이슈 같은 곳에 비동기로 적어 두는 것으로도 충분할 때가 많습니다. 다만 한 가지만 기억하면 좋겠습니다. '공적인 공간에 올려뒀으니 됐다'와 '책임지는 사람이 실제로 봤다'는 다릅니다. 그분이 보는 자리에 올리거나, 필요하면 '여기 있으니 참고해 주세요' 하고 콕 집어 알려서, 정보가 정말 가닿게 하는 것까지가 공유라고 생각합니다. --- ## P34 · 정리 — 실무 역량, 세 가지 > 실무 역량, 세 가지 > > ① 피드백 — 목적 이해 + 적극 역제안 > ② 전파·기록 — 먼저 공유 + 의도/근거 남기기 > ③ 일정 관리 — 주기적·정직하게 공유 이제 정리해 보겠습니다. 여기까지가 실무 역량 세 가지였습니다. 코딩은 우리의 기본이고, 그 위에 한 겹씩 더하는 실무 역량 셋을 이야기했습니다. 피드백은, 명세의 목적을 먼저 이해하고 빈틈에 적극적으로 역제안하는 것. 생각의 전파는, 제 생각과 방향을 먼저 공유하고 의도와 근거를 기록으로 남기는 것. 일정 관리는, 진척과 리스크를 주변에 주기적으로, 정직하게 공유하는 것이었습니다. --- ## P35 · 결국은 '함께 일하는 법' > "이런 것들도 결국, > 우리의 업무입니다" > > — 코딩을 넘어 '함께 일하는 법'도 하나의 능력 이 셋을 관통하는 하나는, 결국 '내가 코딩을 잘하는 것'을 넘어 '다른 사람과 함께 일하는 법'을 배우는 것이라고 생각합니다. 그리고 이것은 곁다리가 아니라 그 자체로 하나의 '일'이자 '능력'입니다. 코딩이 그렇듯, 배우고 늘릴 수 있고요. 처음에 '이런 것까지 제가 해야 하나' 싶은 순간들이 온다고 말씀드렸죠. 네, 이런 것들도 결국 우리의 업무라고 생각합니다. --- ## P36 · AI 시대에 대해 — 개인적인 생각 > AI 시대에도 — 개인적인 생각 > > 같은 원칙이 'AI와의 협업'에도 통하고, > '일이 굴러가게 하는 힘'은 오히려 더 중요해질지도 마지막으로, AI 이야기를 조금 드리고 싶습니다. 'AI가 다 해주는 시대에 이런 게 무슨 의미가 있나' 싶으실 수도 있습니다. 그런데 제 경험은 조금 달랐습니다. AI도 결국 인간의 말과 일하는 방식을 흉내 내는 존재이기 때문입니다. 그래서 일정 관리만 빼면, 오늘 이야기한 원칙들 — 목적을 분명히 하고, 의도를 설명하고, 맥락을 기록으로 남기는 것 — 을 지킬수록 AI와도 훨씬 더 잘 협업이 되더라고요. 게다가 코딩 그 자체는 점점 AI가 대신할 수 있게 되니, 오히려 이 일이 잘 굴러가게 만드는 스킬, 그러니까 실무 역량이 더 중요해질지도 모릅니다. 물론 이것은 어디까지나 제 개인적인 생각입니다. --- ## P37 · 마무리 > 감사합니다 > > 작은 참고가 되었기를 바랍니다 · Q&A 오늘 드린 이야기가 정답은 아니지만, 여러분이 성장해 나가시는 길에 작은 참고 하나가 되었으면 좋겠습니다. 들어주셔서 감사합니다. 질문 있으시면 편하게 해주시기 바랍니다. ---