이런 상황이라면
경력은 쌓이는데 실력이 그만큼 늘고 있는지 의심스러운 사람에게 맞는다. 팀장이 되었지만 팀을 어떻게 성장시켜야 할지 감이 없는 사람에게도 좋다. 반대로 특정 언어나 프레임워크의 구체적인 기술서를 찾는다면 이 책은 아니다.
한눈에 보기
이 책은 "어떻게 하면 더 빨리 실력이 늘까"라는 질문을 개인에서 팀으로 옮긴다. 김창준은 소프트웨어 일을 혼자 머리로 푸는 문제가 아니라, 사람들 사이에서 학습이 일어나는 과정으로 본다. 그래서 초점이 기술 스택이나 도구가 아니라 "학습"과 "협력"에 놓인다. 실력이 늘지 않는 이유를 재능이나 노력의 양이 아니라, 피드백이 늦고 도전 난이도가 안 맞는 환경에서 찾는다. 팀에 대해서도 마찬가지다. 뛰어난 사람을 모으는 것보다 어떻게 일하느냐가 성과를 더 크게 가른다고 말한다. 애자일도 방법론 목록이 아니라 "짧은 주기로 배우는 태도"로 다시 정의된다.
기존의 개발자 성장 담론이 "무엇을 공부할 것인가"에 답했다면, 이 책은 "어떤 조건에서 배우는가"에 답한다. 좋은 책 목록이나 로드맵 대신, 실수를 드러낼 수 있는 분위기와 빠른 피드백 고리를 만든다. 혼자 3년 공부한 사람보다, 잘하는 사람 옆에서 같이 일한 1년이 더 클 수 있다는 관점이다. 개인기를 키우는 이야기와 팀을 바꾸는 이야기를 굳이 분리하지 않는다는 점도 다르다. 학습은 결국 관계 안에서 일어난다는 것이 이 책의 일관된 전제다.
핵심 인사이트
- 01
실력은 시간이 아니라 피드백의 밀도로 는다
같은 10년을 일해도 어떤 사람은 10년치가 되고 어떤 사람은 1년을 열 번 반복한다. 차이는 자기 행동의 결과를 얼마나 빨리, 얼마나 정확히 확인하느냐에서 생긴다. 결과를 몇 달 뒤에야 알게 되는 일은 아무리 반복해도 학습이 되지 않는다. 코드를 짜고 몇 초 뒤에 테스트 결과를 보는 사람과, 배포 후 분기 리뷰에서 문제를 듣는 사람은 다른 속도로 자란다. 그래서 성장을 원한다면 공부량을 늘리기 전에 피드백 주기를 먼저 줄여야 한다. 이건 의지 문제가 아니라 작업 방식 설계의 문제다.
- 02
너무 쉬우면 지루하고 너무 어려우면 불안하다
학습이 가장 잘 일어나는 구간은 실력보다 아주 조금 어려운 일이다. 실력에 비해 과제가 쉬우면 지루해지고, 과제가 훨씬 어려우면 불안해서 회피하게 된다. 흔한 오해는 무조건 어려운 일을 맡아야 큰다고 믿는 것이다. 감당 못 할 프로젝트에 던져진 사람은 배우는 대신 버티기만 하다 끝난다. 중요한 건 난이도를 고정된 조건으로 두지 않는 것이다. 일이 너무 어려우면 쪼개서 난이도를 낮추고, 너무 쉬우면 제약을 걸어 올리면 된다.
- 03
뛰어난 사람을 모으는 것보다 어떻게 일하느냐가 크다
팀 성과는 구성원 개인 역량의 합으로 결정되지 않는다. 정보가 어떻게 흐르고, 문제가 얼마나 일찍 드러나고, 서로 얼마나 자주 개입하는지가 더 크게 작용한다. 실제로 각자 뛰어난 사람들이 모였는데도 결과가 평범한 팀은 흔하다. 각자 자기 몫만 잘하고 경계에서 생기는 문제를 아무도 건드리지 않기 때문이다. 반대로 평범한 사람들이 자주 붙어서 일하면 실수를 빨리 잡아낸다. 그래서 팀을 바꾸려 할 때 채용부터 떠올리는 건 순서가 틀렸다.
- 04
심리적 안전 없이는 아무것도 학습되지 않는다
모르는 걸 모른다고 말할 수 없는 팀에서는 배움이 멈춘다. 사람들은 질문 대신 추측하고, 실수를 드러내는 대신 감춘다. 감춰진 실수는 늦게 발견되고, 늦게 발견된 문제는 훨씬 비싸진다. "바보 같아 보일까 봐" 묻지 않은 질문 하나가 며칠의 삽질로 돌아오는 장면은 어느 팀에나 있다. 안전은 분위기가 좋다는 뜻이 아니라, 나쁜 소식을 일찍 말해도 손해 보지 않는다는 뜻이다. 리더가 자기 실수를 먼저 말하는 것이 가장 값싼 시작점이다.
- 05
협력은 성격이 아니라 훈련 가능한 기술이다
협력을 잘하는 사람을 흔히 성격 좋은 사람으로 오해한다. 하지만 함께 일하는 능력은 타고난 기질보다 익힌 방식에 가깝다. 같이 화면을 보며 코드를 짜고, 서로의 생각을 소리 내어 말하고, 작업을 잘게 잘라 자주 합치는 것은 모두 배울 수 있는 동작이다. 내향적인 사람이라 협업이 안 된다는 말은 대개 방법을 배운 적이 없다는 뜻이다. 기술을 익히듯 협력도 연습량에 따라 는다. 그래서 팀에 필요한 건 좋은 사람을 찾는 일이 아니라 같이 일하는 연습을 설계하는 일이다.
- 06
애자일은 도구 목록이 아니라 짧게 배우는 방식이다
많은 조직이 스탠드업과 스프린트를 도입하고도 아무것도 나아지지 않는다고 말한다. 형식만 옮겨오고 그 형식이 만들려던 학습 고리는 빠졌기 때문이다. 애자일의 핵심은 회의 이름이 아니라, 불확실한 것을 일찍 시도해서 빨리 틀리는 데 있다. 매일 15분 모여 진행 상황만 보고하는 스탠드업은 형식은 있으나 배움이 없다. 반대로 이름 붙은 절차가 없어도 매주 실제 사용자에게 확인받는 팀은 이미 애자일하다. 그래서 물어야 할 질문은 "우리가 애자일한가"가 아니라 "우리는 무엇을 얼마나 빨리 배우고 있나"다.
이렇게 적용한다
상황몇 달째 같은 종류의 업무를 반복하는데 성장하는 느낌이 없을 때
지금 하는 일의 피드백 주기가 얼마나 되는지부터 잰다. 결과 확인에 일주일이 걸린다면 하루로, 하루가 걸린다면 한 시간으로 줄일 방법을 하나 찾는다. 테스트 자동화든 중간 공유든, 확인 간격을 줄이는 쪽이 새 강의를 듣는 것보다 먼저다.
상황팀에 어려운 과제가 떨어졌는데 아무도 먼저 손대지 않을 때
과제를 통째로 배분하지 말고, 하루 안에 끝나는 크기로 쪼개 난이도를 낮춘다. 그다음 가장 불확실한 조각을 둘이 붙어서 먼저 시도한다. 목적은 완성이 아니라 무엇을 모르는지 빨리 확인하는 것이다.
상황회고를 하는데 매번 좋은 말만 오가고 바뀌는 게 없을 때
리더가 먼저 자기 판단 실수 하나를 구체적으로 말한다. 그리고 문제를 사람이 아니라 절차로 옮겨서 "누가"가 아니라 "어느 지점에서 늦게 알았나"를 묻는다. 마지막에 다음 주에 바꿀 행동 하나만 정하고 끝낸다.
ACTION ITEMS
오늘 바로 할 수 있는 것.
- ✓지금 맡은 일에서 결과를 확인하기까지 걸리는 시간을 적어 보고, 그것을 절반으로 줄일 방법 하나를 오늘 실행한다.
- ✓이번 주 업무 중 하나를 골라 동료와 한 시간 같이 화면을 보며 작업하는 시간을 잡는다.
- ✓너무 어려워 미뤄 둔 작업을 하루 안에 끝나는 조각 세 개로 쪼개 적는다.
- ✓오늘 회의에서 모르는 것 하나를 그대로 소리 내어 질문한다.
- ✓최근 실수 하나를 팀 채널에 먼저 공유하고, 무엇을 늦게 알았는지 한 줄로 덧붙인다.
- ✓지금 팀이 무엇을 배우고 있는지 한 문장으로 적어 보고, 답이 안 나오면 그 자체를 다음 회고 주제로 올린다.
밑줄 그은 문장
“혼자 빨리 가는 것보다, 팀의 학습 속도를 올리는 편이 결국 빠르다.”
이 책이 답하지 않는 것
구체적인 기술 지식이나 아키텍처 설계를 다루는 책이 아니라서, 당장의 코드 문제를 푸는 데는 도움이 되지 않는다. 또 여러 갈래의 짧은 글을 모은 구성이라 한 주제를 끝까지 파고드는 체계적인 안내서를 기대하면 아쉬울 수 있다. 조직 전체의 제도나 평가 체계를 바꾸는 문제도 이 책의 범위 밖이다.
이 통찰의 근거가 궁금하다면?
원서·번역서 정보와 가격은 판매처에서 확인하세요.
※ 구매 링크는 제휴 활동의 일환이며, 이를 통해 일정액의 수수료를 제공받습니다. 구매자에게 추가 비용은 발생하지 않습니다.
비슷한 주제의 책
NEWSLETTER
매일 아침, 새로운 인사이트
하루의 시작을 도와줄 책 한 권의 핵심과 실천 과제를 보내드립니다.