#1 Pragmatic Philosophy
1장 실용주의 철학
💻 실용주의 프로그래머: Topic 1 당신의 인생이다
1. 당신의 인생을 스스로 만든다는 것
“나는 당신의 기대대로 살기 위해 이 세상에 있는 게 아니고, 당신도 내 기대대로 살기 위해 이 세상에 있는 게 아니다.”
브루스 리의 이 말로 챕터는 시작한다. 저자는 우리 각자가 자신만의 인생을 살아야 한다고 말한다. 당신의 인생은 당신이 살아가는 방식이며, 당신이 만들어가는 결과다. 많은 개발자들이 불만 속에 살아간다. 현재의 업무에 갇혀 있다고 느끼거나, 자신의 성과를 몰라준다고 생각하며, 급여가 적다고 불평하거나, 팀 분위기가 자신에게 맞지 않는다고 느낀다. 미국이나 유럽으로 이민을 가고 싶어 하거나, 재택근무를 갈망하기도 한다. 하지만 정작 묻고 싶다.
“왜 직접 바꾸지 않습니까?”
우리가 흔히 말하는 ‘구조적 제약’은 사실 개인의 선택에서 비롯되는 경우가 많다. 소프트웨어 개발은 비교적 자유로운 분야다. 수요가 많고, 지식의 장벽이 높지 않으며, 원격 근무도 가능한 직종이다. 우리가 가진 기회는 결코 적지 않다. 그럼에도 많은 개발자들이 변화를 회피한다. 상황이 좋아지길 기다리고, 회사가 교육을 제공해주길 바라며, 그저 광고를 보듯 ‘더 나은 직장’을 바라기만 한다. 하지만 실용주의 프로그래머는 그렇지 않다. 스스로의 삶을 직접 수정하고 리팩토링한다. 그게 바로 이 책이 강조하는 첫 번째 태도다.
2. 에이전시(Agency)를 가진 사람
“당신에게는 에이전시가 있다.”
이 문장은 짧지만 강력하다. ‘에이전시’란 자신이 스스로의 행동을 결정하고 통제할 수 있는 힘을 뜻한다. 환경이 나를 지배하는 것이 아니라, 내가 환경을 바꿀 수 있다는 믿음이다. 물론 주변 상황의 영향을 완전히 피할 수는 없다. 하지만 진짜 실용주의 프로그래머는 문제를 외부로 돌리지 않는다. 문제를 고치기 위해 스스로 움직이고, 더 나은 선택을 만들어낸다.
마틴 파울러(Martin Fowler)는 말했다.
“당신은 당신의 코드의 주인이다. 당신의 조직을 바꿀 수 있다.”
이 문장은 단지 소프트웨어의 소유권을 말하는 게 아니다. 삶의 태도를 말한다. 우리는 늘 시간이 없다고 말하지만, 실제로는 ‘시간이 없다’기보다 ‘시간을 쓸 의지’를 잃은 경우가 많다. 새로운 기술을 배우는 대신 유튜브를 보고, 회사의 구조를 탓하면서도 이직 준비는 하지 않는다. 실용주의 프로그래머는 이런 패턴을 끊는다. 스스로 결정권을 가진 사람, 즉 에이전시를 가진 사람으로 산다.
3. 기회를 스스로 잡아라
“원격 근무를 하고 싶은가? 가능하지 않다고 들었는가? 그렇다면 다른 곳을 찾아라.”
이 문장은 단순하지만 실용주의의 본질을 담고 있다. 이 업계는 언제나 기회로 가득하다. 기술은 빠르게 변하고, 경계는 허물어진다. 중요한 건 그 변화 속에서 주도적으로 움직이는 태도다. 누군가 기회를 가져다주기를 기다리지 말고, 직접 행동해서 그 기회를 잡아야 한다. 불평 대신 실험을, 회피 대신 시도를 택하는 것이 바로 실용주의 프로그래머의 방식이다.
이 챕터는 단순히 “주체적으로 살아라”는 교훈이 아니다. 프로그래머라는 직업은 그 자체로 자유와 선택의 가능성이 큰 일이다. 그렇기에 더더욱 ‘스스로의 인생을 책임지는 태도’가 중요하다. 환경 탓, 조직 탓, 시장 탓을 하기 전에 묻자. “내가 진짜 원하는 건 무엇이고, 그걸 위해 오늘 무엇을 선택했는가?” 실용주의 프로그래머는 바로 그 질문에서 출발한다.
💻 실용주의 프로그래머: Topic 2 고양이가 내 소스 코드를 삼켰어요
1. 책임을 피하지 않는 태도
“약점을 보이는 것에 대한 두려움이 가장 큰 약점이다.”
이 장의 핵심은 한마디로 ‘책임’이다. 실용주의 철학의 출발점은 자신의 행동과 결과에 책임을 지는 것이다. 자신의 경력 개발, 학습, 프로젝트, 일상적인 업무까지 모두 스스로의 몫이다. 실용주의 프로그래머는 자신의 경험에 대해 책임을 지고, 자신의 실수나 한계를 회피하지 않는다. 오히려 그것을 인식하고 개선하려는 노력을 중시한다. 책임을 진다는 것은 단순히 문제를 인정하는 것이 아니라, 문제를 자신의 영역 안으로 끌어들여 해결하려는 태도다. 설계가 잘못되었거나 테스트가 부족했거나 일정이 밀렸더라도, 변명보다 중요한 건 그 뒤의 행동이다. 전문가는 완벽하지 않지만, 실수를 숨기지 않는다.
2. 팀 내 신뢰
무엇보다 중요한 것은 팀 내의 신뢰다. 동료가 당신을 믿고 의지할 수 있어야 하고, 당신 또한 동료에게 의지할 수 있어야 한다. 신뢰가 있어야 협업이 가능하고, 창의적인 아이디어도 자유롭게 오간다. 하지만 신뢰를 잃는 것은 아주 사소한 일에서 비롯된다.
예를 들어, 어떤 개발자가 비밀 연구 프로젝트 중에 고양이가 실험용 장비를 망가뜨렸다고 해보자. 수개월간의 노력 끝에 드디어 결과물을 앞두고 있었는데, 보고서에는 이렇게 적혀 있다.
“죄송합니다. 레이저가 없네요. 고양이가 빨간 점을 쫓아다니더니 그걸 좋아해서 그냥 집에 놓고 왔습니다.”
이런 식으로 책임을 회피한다면 팀 내 신뢰는 순식간에 무너진다. 서로를 믿지 못하는 환경에서는 협업이 불가능하다. 실용주의 프로그래머는 신뢰를 지키기 위해 솔직함을 택한다. 잘못을 숨기거나 변명하기보다, 문제를 투명하게 드러내고 해결책을 함께 모색한다.
3. 변명하지 말고 대안을 제시하라
“고양이가 내 소스 코드를 삼켰어요.”
이건 실무에서 우리가 자주 하는 말과 다르지 않다. “서버가 이상했어요.” “테스트 환경이 꼬였어요.” “기획이 늦게 나와서요.” 하지만 실용주의 프로그래머는 그렇게 말하지 않는다. 다른 사람을 탓하거나 변명을 늘어놓는 대신, 대안을 함께 제시한다.
무언가 잘못되었다면 그 이유를 분석하고, 같은 실수를 반복하지 않기 위한 방법을 찾아야 한다. 예를 들어 빌드 실패가 발생했다면 “CI가 깨졌어요.”가 아니라 “CI 설정의 버전 충돌이 원인입니다. 수정 후 재배포하겠습니다.”라고 말하는 것이다. 변명은 문제를 남겨두지만, 대안은 문제를 끝낸다.
“어설픈 변명 말고 대안을 제시하라.”
누군가에게 문제가 생겼다고 보고하기 전에 한 번 생각해보라. 그 말을 고양이에게 한다면 이해할까, 상사에게 한다면 설득될까. 변명은 감정적 해명에 불과하지만, 대안은 신뢰를 만든다. 실무에서도 마찬가지다. 코드 리뷰에서 “시간이 없어서요”보다는 “이번엔 임시로 처리했지만 다음 배포 주기엔 리팩토링하겠습니다.”가 훨씬 신뢰를 얻는다.
4. 실용적 책임감
책임이란 모든 걸 통제하겠다는 뜻이 아니다. 예측 불가능한 상황은 언제든 생긴다. 중요한 건 그 상황을 어떻게 받아들이느냐다. 문제가 생겼을 때 “이건 제 통제 밖이에요”라고 말하는 대신, “이 문제는 제 영역을 넘어서지만 이렇게 대응하겠습니다”라고 말하는 태도. 그게 실용주의 프로그래머다.
결국 이 장의 메시지는 단순하다. 누구나 실수할 수 있다. 하지만 변명으로 시간을 낭비하느냐, 대안으로 신뢰를 얻느냐는 선택의 문제다. 문제를 인정하고 개선책을 제시하는 순간, 당신은 이미 전문가로 한 단계 성장한다.
이 장의 교훈은 명확하다. 고양이가 소스 코드를 삼켰다고 말하기 전에, 그 소스를 다시 짜거나 구할 방법을 찾는 사람. 그 사람이 바로 실용주의 프로그래머다.
💻 실용주의 프로그래머: Topic 3 소프트웨어 엔트로피
1. 소프트웨어에도 엔트로피가 있다
소프트웨어 개발은 물리 법칙과는 무관해 보이지만, 현실은 그렇지 않다. 우리가 코드를 작성하고 수정하는 한, 시스템은 점점 더 복잡해지고 질서가 흐트러진다. 물리학에서 말하는 **엔트로피(entropy)**처럼 말이다. 코드의 구조가 무너지고 일관성이 사라질수록, 개발 환경은 점차 ‘부패’한다. 우리는 이를 흔히 “소프트웨어의 부패” 또는 “기술 부채(technical debt)”라고 부른다. 이 부패는 천천히, 그러나 확실하게 진행된다. 작은 예외를 허용하고, 급한 수정으로 일관성을 포기하고, 정리하지 않은 코드를 그대로 두는 순간 시스템의 엔트로피는 증가한다. 그리고 그 결과는 언제나 같다 — 한때는 깔끔했던 코드베이스가 점점 복잡해지고, 결국엔 누구도 손대기 두려운 ‘무질서한 덩어리’가 되어버린다.
2. 부패의 시작: 깨진 창문
“깨진 창문을 내버려 두지 말라.”
이 챕터의 가장 유명한 문장이다. 건물의 유리창 하나가 깨졌는데 아무도 고치지 않으면, 사람들은 그 건물이 관리되지 않고 있다고 느낀다. 얼마 지나지 않아 낙서가 생기고, 쓰레기가 쌓이고, 결국 그곳은 완전히 버려진다. 이 ‘깨진 창문 이론’은 소프트웨어에도 똑같이 적용된다. 코드의 잘못된 설계, 주석 없는 함수, 테스트되지 않은 모듈, 무시된 버그 리포트 — 이런 작은 결함 하나가 프로젝트의 신뢰도를 서서히 무너뜨린다. 누군가 “이 정도는 괜찮겠지”라고 말하는 순간, 다른 사람들도 같은 생각을 하게 된다. 그렇게 방치된 작은 문제는 팀 전체에 전염되며, “어차피 다들 이렇게 하잖아”라는 무기력을 퍼뜨린다.
3. 엔트로피를 관리하는 방법
깨진 창문을 발견하면 즉시 고쳐라. 시간이 없어서 못 고치더라도, 최소한 “이 부분은 확인 중”이라는 표시를 남겨라. 아무런 조치 없이 방치하는 것이 가장 위험하다. 잘못된 설계나 버그는 언제든 생길 수 있다. 문제는 그것을 어떻게 다루느냐다. 실용주의 프로그래머는 나쁜 코드의 존재를 숨기지 않고, 오히려 드러내고 수정 계획을 세운다. “지금은 완벽하지 않지만, 개선 중입니다”라는 투명한 태도가 팀의 신뢰를 지킨다. 또한 프로젝트 내에서 반복적으로 발생하는 오류를 ‘패턴’으로 인식하고, 이를 자동화하거나 도구로 보완할 방법을 찾는다. 테스트 커버리지를 점검하고, 리뷰 프로세스를 강화하고, 코드 스타일을 일관되게 유지하는 모든 행동이 엔트로피를 낮추는 일이다.
4. 우선, 망가뜨리지 말라
“깨진 창문은 없어야 한다.”
엔트로피를 완전히 없애는 것은 불가능하지만, 증가 속도를 늦출 수는 있다. 문제는 늘 ‘작은 무관심’에서 시작된다. 책에서는 실제 예시로, 어느 집이 오랫동안 청소되지 않아 벽에 낙서가 생기고 구조적 손상까지 이어지는 과정을 설명한다. 소프트웨어에서도 동일하다. 코드가 한 번 더럽혀지기 시작하면, 그 안에서 새로운 문제가 끊임없이 자라난다. 따라서 실용주의 프로그래머는 “망가뜨리지 않는 것”을 최우선으로 둔다. 급한 수정이나 임시 방편의 코드는 나중에 더 큰 비용으로 돌아온다. 완벽한 해결보다 더 중요한 것은, 시스템의 질서를 유지하려는 꾸준한 관리 습관이다.
엔트로피는 코드의 자연스러운 속성이지만, 그것을 방치하는 것은 개발자의 선택이다. 깨진 창문 하나를 고치는 일은 사소해 보이지만, 팀의 문화와 코드의 품질을 지키는 가장 실질적인 행동이다. 명심하자.
“깨진 창문을 내버려 두지 말라.”
💻 실용주의 프로그래머: Topic 4 돌멩이 수프와 삶은 개구리
1. 돌멩이 수프의 교훈
전쟁이 끝나고 귀향하던 세 명의 군인이 있었다. 그들은 허기졌지만 마을 사람들은 낯선 손님에게 음식을 내어줄 생각이 없었다. 그러자 군인들은 냄비에 물을 끓이기 시작하고, 돌멩이 세 개를 조심스레 넣었다. 호기심이 생긴 마을 사람들은 다가와 물었다.
“이건 뭐하는 거요?” “돌멩이 수프요.”
군인들은 “감자를 조금 넣으면 더 맛있을 것 같은데요.”라고 말했고, 마을 사람 중 하나가 감자를 가져왔다. 또 다른 사람은 소금, 또 다른 사람은 고기를 가져왔다. 결국 마을 전체가 조금씩 재료를 보태며 커다란 수프가 완성됐다. 모두가 함께 나누어 먹은 그 수프는 그들 중 누구도 혼자서는 만들 수 없던 음식이었다.
이 이야기는 단순한 우화가 아니다. 돌멩이 수프는 작은 계기를 통해 사람들의 협력을 이끌어내는 과정을 상징한다. 실용주의 프로그래머에게 이는 매우 중요한 태도다. 변화를 원한다면 완벽한 계획보다, **누군가의 호기심을 자극할 수 있는 ‘돌멩이 하나’**가 더 큰 힘을 발휘한다.
2. 변화를 이끄는 시작점
“변화의 촉매가 되라.”
이 장의 핵심 문장이다. 조직의 시스템은 처음에는 정적인 듯 보이지만, 누군가가 작게 움직이면 그것이 파문처럼 퍼진다. 새로운 코드 리뷰 문화를 제안하거나, 테스트 자동화를 도입하거나, 문서화를 조금씩 시작하는 것 — 모두 돌멩이 수프의 첫 단계다. 처음부터 완벽한 개선안을 내세우기보다는 작게 시작해서 다른 사람들의 참여를 유도하라. 작게 실험하고, 그 결과를 공유하며, “이거 괜찮지 않아요?” 하고 자연스럽게 팀을 움직이는 것이다.
돌멩이를 던진다는 것은 리스크가 있지만, 그만큼 변화의 불씨가 된다. 사람들은 눈앞의 완벽한 혁신보다 “해볼 만한 작은 변화”에 더 쉽게 동참한다.
3. 삶은 개구리의 경고
“큰 그림을 기억하라.”
이 장의 또 다른 절반은 ‘삶은 개구리’ 이야기로 이어진다. 개구리를 냄비에 넣고 서서히 물을 데우면, 개구리는 뜨거워지는 줄도 모른 채 결국 삶아져 죽는다. 변화를 너무 서서히 겪으면 위험을 감지하지 못하고, 무감각해진다는 뜻이다. 소프트웨어 프로젝트에서도 비슷하다. 작은 문제들이 쌓여 시스템이 점점 복잡해지는데도 아무도 그 심각성을 인식하지 못한다. “이번만 예외로 하자”, “다음 버전에서 정리하자” 같은 말들이 반복되며, 어느새 프로젝트는 되돌릴 수 없는 상태로 향한다.
실용주의 프로그래머는 이런 “점진적 타락”을 경계해야 한다. 작은 이상 신호를 무시하지 말고, 방향이 잘못되고 있다는 징후를 빠르게 포착해야 한다. 그리고 문제를 바로잡을 수 있는 시점에 행동해야 한다.
4. 균형 잡힌 시선
이 두 이야기는 상반된 듯하지만, 사실 하나의 메시지를 전한다. “변화를 두려워하지 말되, 흐름 속에서 방향을 잃지 말라.” 돌멩이 수프는 ‘작은 시작의 용기’를, 삶은 개구리는 ‘변화에 대한 경계’를 상징한다. 우리는 새로운 시도를 주저하지 말아야 하지만, 동시에 작은 타협이 쌓여 큰 부패로 이어지지 않도록 주의를 기울여야 한다.
팀의 분위기를 바꾸고 싶다면, 먼저 작은 실험을 제안하라. 하지만 그 실험이 전체 구조에 어떤 영향을 미칠지 잊지 말라. “시작하되, 관성에 휘둘리지 말라.” 이 균형이 바로 실용주의 프로그래머의 핵심이다.
군인들은 돌멩이로 수프를 만들었지만, 진짜 중요한 건 사람들을 움직이게 한 그들의 태도였다. 반면 개구리는 변화를 인식하지 못해 죽었다. 작은 시작으로 팀을 변화시킬 수 있다면, 그 돌멩이를 던지는 용기를 가지자. 그러나 그 변화가 올바른 방향으로 가고 있는지, 늘 큰 그림을 점검하라.
“돌멩이 수프를 끓이되, 개구리 수프를 만들지 마라.”
💻 실용주의 프로그래머: Topic 5 적당히 괜찮은 소프트웨어
1. 완벽주의의 함정
“우리는 종종 뭔가 나아지게 하려다가 괜찮은 것마저 망친다.”
셰익스피어의 말처럼, 완벽함을 추구하다 오히려 본질을 놓치는 경우가 많다. 일본의 한 회사에 IC(집적 회로)를 주문한 이야기가 대표적이다. 발주서에는 ‘결함 비율(defect rate)’이 포함되어 있었는데, 며칠 후 도착한 상자에는 정확히 그 비율만큼 불량품이 담겨 있었다. 완벽을 요구했지만 결과적으로는 “결함이 있는 것이 정상” 이라는 메시지를 돌려받은 셈이다. 이 일화는 완벽주의가 얼마나 비현실적인지 보여준다. 특히 소프트웨어 세계에서는 더 그렇다. 완벽한 시스템은 존재하지 않는다. 시간, 예산, 기술적 제약이 있는 현실 속에서 개발자는 항상 “적당히 괜찮은( good enough )” 수준의 균형점을 찾아야 한다.
2. ‘적당히 괜찮다’의 진짜 의미
‘적당히 괜찮은 소프트웨어’란 무책임하게 대충 만든 코드를 의미하지 않는다. 이는 사용자의 요구를 만족시키되, 불필요한 완벽함을 포기한 상태를 뜻한다. IEEE 저널에서 에드워드 유든(Edward Yourdon)은 이렇게 말했다.
“적당히 괜찮은 소프트웨어는 현실적인 제약 안에서 충분히 훌륭하다.”
즉, 완벽한 코드보다 중요한 건 사용자에게 필요한 기능을 제때 제공하는 것이다. 시스템의 성공 여부는 코드의 우아함이 아니라, 사용자의 만족과 효용에서 결정된다. 기술적으로 완벽하더라도 아무도 사용하지 않는다면, 그것은 ‘좋은 코드’가 아니다. 실용주의 프로그래머는 이러한 사실을 인정하고, 완벽보다 현실적 완성도를 추구한다.
3. 사용자를 설계의 중심에 두라
“품질을 요구사항으로 만들어라.”
적당히 괜찮은 소프트웨어를 만들려면 사용자의 입장에서 출발해야 한다. 개발자는 종종 스스로의 기준에 맞춰 ‘좋은 코드’를 추구하지만, 그 코드가 실제 사용자의 문제를 해결하지 못한다면 의미가 없다. 따라서 품질은 개발자의 미학이 아니라 사용자의 요구사항이 되어야 한다. 버그가 완전히 없을 필요는 없지만, 사용자가 일을 마치는 데 지장이 없어야 한다. 완벽하게 아름다운 코드보다 ‘지금 당장 필요한 문제를 해결하는 코드’가 더 가치 있다.
또한 개발 과정에서 사용자를 적극적으로 참여시켜라. 그들이 무엇을 필요로 하고, 어떤 부분에서 불편을 느끼는지를 직접 듣는 과정이 ‘적당히 괜찮은 수준’을 판단할 가장 정확한 방법이다. 좋은 소프트웨어는 개발자의 만족보다 사용자의 효율로 측정된다.
4. 멈춰야 할 때를 알아라
“그림은 팔꿈치에서 멈춘다.”
예술가가 캔버스를 완성하려다 계속 덧칠을 반복하면, 결국 작품은 망가진다. 프로그래밍도 마찬가지다. 기능을 하나 추가할 때마다 복잡성이 늘어나고, 완벽에 가까워질수록 오히려 유지보수성과 명료함은 떨어진다. 그렇기에 실용주의 프로그래머는 “멈춰야 할 때” 를 알고 있다.
때로는 95%의 완성도에서 멈추는 것이 최선이다. 남은 5%를 채우려다 50%를 잃는 경우가 너무 많다. 완벽은 환상이고, 실행 가능한 코드는 언제나 불완전하다. 따라서 불필요한 개선 욕심을 내려놓고, 현재 상태로 충분히 작동한다면 그 자체로 완성이라 여겨야 한다.
5. 균형 잡힌 현실주의
실용주의 프로그래머는 완벽과 타협 사이의 회색 지대를 이해한다. 그들은 “좋은 코드”란 문학적 아름다움이 아니라 문제를 해결하는 능력에서 비롯된다고 믿는다. 지나친 완벽주의는 배포를 늦추고, 반대로 과한 타협은 품질을 해친다. 따라서 중요한 건, 언제 멈추고, 어디까지 개선할지를 판단하는 감각이다.
결국, 이 장의 메시지는 명확하다. 적당히 괜찮은 소프트웨어란, 현실의 제약 안에서 최고의 결과를 내는 것이다. 사용자가 만족하고, 개발자가 유지보수할 수 있으며, 시스템이 지속적으로 동작한다면 그것이 바로 ‘완벽하게 괜찮은’ 소프트웨어다.
💻 실용주의 프로그래머: Topic 6 지식 포트폴리오
1. 지식에 대한 투자는 언제나 최고의 이윤을 낳는다
“지식에 대한 투자가 언제나 최고의 이윤을 낸다.”
벤저민 프랭클린의 이 말은 단순히 격언이 아니라, 프로그래머의 생존 전략이다. 우리가 가진 기술과 경험은 시간이 지나며 가치가 떨어진다. 사용하는 언어, 프레임워크, 도구는 몇 년마다 바뀌고, 한때 혁신적이었던 기술은 금세 낡은 지식이 된다. 다시 말해, 지식은 소모성 자산(expiring asset) 이다. 따라서 프로그래머는 자신의 ‘지식 자산’을 주기적으로 갱신하고 재조정해야 한다. 마치 투자자가 포트폴리오를 관리하듯이, 우리는 지식의 위험과 수익을 고려해 균형 있게 투자해야 한다.
2. 지식 포트폴리오란 무엇인가
지식 포트폴리오는 우리가 알고 있는 모든 기술적 사실과 경험의 총합이다. 이를 관리하는 원칙은 금융 투자와 remarkably 닮아 있다.
꾸준히 투자하라. 매일, 매주, 조금씩 배우는 습관이 복리 효과를 만든다.
장기적인 안목을 가져라. 단기 트렌드에 휩쓸리지 말고, 근본적인 기술 원리에 투자하라.
위험과 보상의 균형을 맞춰라. 익숙한 기술에만 머무르지 말고, 새로운 기술에도 일정 비율로 도전하라.
싸게 사고 비싸게 팔라. 신기술이 주목받기 전에 미리 배우면 리스크는 크지만, 보상은 훨씬 크다.
정기적으로 점검하고 재조정하라. 더 이상 유효하지 않은 기술은 과감히 버리고, 새로운 영역을 채워 넣어라.
이 다섯 가지 원칙은 개발자의 경력을 장기적으로 성장시키는 투자 전략과 같다.
3. 포트폴리오를 만드는 방법
① 주기적인 투자 학습은 꾸준함이 핵심이다. 한 번의 폭발적인 집중보다, 짧더라도 매주 일정 시간을 학습에 투자하는 것이 훨씬 효율적이다. 매달 새로운 기술을 배우거나, 한 달에 한 권의 기술 서적을 읽는 식으로 꾸준함을 습관화하라.
② 다각화 한 분야에만 몰입하지 말고, 인접 분야의 기술에도 눈을 돌려라. 백엔드 개발자라면 프론트엔드나 인프라, 혹은 데이터 분석에도 관심을 가져야 한다. 기술 외에도 디자인, 협업, 비즈니스 도메인에 대한 이해는 당신의 가치를 배가시킨다.
③ 리스크 관리 모든 기술이 성공하지는 않는다. 새로운 언어나 프레임워크가 유행처럼 등장하지만, 금세 사라지는 경우도 많다. 너무 한쪽 기술에만 올인하지 말고, 다양한 스택을 적절히 섞어 리스크를 분산하라.
④ 싸게 사고 비싸게 팔기 기술도 주식과 같다. 아직 주목받지 않은 신기술을 일찍 배워두면, 시장이 커질 때 그만큼 큰 기회를 잡을 수 있다. 트렌드가 정점을 찍었을 때 배우기 시작하면 이미 늦었다.
⑤ 재조정 산업은 빠르게 변한다. 지난달에 인기 있던 기술이 다음 달엔 도태될 수도 있다. 정기적으로 자신이 사용하는 기술 스택을 점검하고, 낡은 도구를 교체하라.
4. 무엇을 배워야 하는가
매년 새로운 언어를 하나 이상 배워라. 새로운 언어는 사고 방식을 바꾼다. 객체지향 언어를 쓰던 개발자가 함수형 언어를 배우면, 문제를 보는 시야가 확장된다.
기술 서적을 한 달에 한 권씩 읽어라. 웹 기사와 달리 책은 깊이 있는 사고를 제공한다. 현재 프로젝트와 직접 관련이 없어도, 다양한 관점을 쌓는 것이 중요하다.
기술 외의 책도 읽어라. 우리는 사람을 위해 시스템을 만든다. 인문학, 커뮤니케이션, 심리학 같은 분야의 지식은 ‘소프트 스킬’을 강화한다.
세미나나 컨퍼런스에 참여하라. 새로운 아이디어를 얻고, 같은 분야 사람들과 연결될 수 있는 좋은 기회다.
지역 커뮤니티에 참여하라. 작은 모임이라도 실제 개발자들의 문제 해결 방식을 직접 보고 배울 수 있다.
5. 학습 태도와 사고방식
지식 포트폴리오의 핵심은 **‘배우는 방법을 배우는 것’**이다. 스스로 질문하고, 스스로 탐구하라. 모르면 검색하고, 아는 사람에게 물어보라. 배움은 혼자 하는 행위이지만, 지속 가능하게 만드는 것은 네트워크다.
“찾을 수 없다면, 찾아줄 수 있는 사람을 찾아라.”
또한 배움은 계획적으로 이루어져야 한다. 시간은 언제나 부족하므로, 미리 독서 시간과 학습 루틴을 마련하라. 병원 대기실, 출퇴근 시간, 짧은 휴식 — 이런 틈틈이 배우는 습관이 결국 격차를 만든다.
6. 비판적 사고
“읽고 듣는 것을 비판적으로 분석하라.”
비판적 사고는 지식 포트폴리오의 질을 결정한다. 새로운 기술이나 이론을 접할 때, 그 내용을 무비판적으로 받아들이지 말라. ‘왜 이 방법이 좋은가?’, ‘누구에게 이익이 되는가?’, ‘다른 선택지는 없는가?’ 같은 질문을 던져라.
특히 인기 있는 기술이나 책을 접할 때는 더욱 경계하라. 유행은 쉽게 바뀌고, 마케팅은 종종 과장된다. 겉으로 보기엔 최신이지만, 실질적 가치가 없는 경우도 많다. 비판적으로 읽고, 다양한 관점을 통해 스스로 판단하는 능력이 진짜 실용주의자의 무기다.
결국 지식 포트폴리오는 **‘스스로 성장하기 위한 시스템’**이다. 꾸준한 투자, 다각화된 학습, 비판적 사고를 통해 지식을 갱신하고 낡은 것을 버리며 새로운 것을 채워넣는 과정. 이 순환이 바로 프로그래머로서의 경쟁력이다.
“지식에 대한 투자가 언제나 최고의 이윤을 낸다.” 이 문장은 단순한 조언이 아니라, 평생에 걸쳐 실천해야 할 원칙이다.
💬 실용주의 프로그래머: Topic 7 소통하라!
1. 아이디어보다 중요한 것은 ‘전달력’
“나는 무시당하느니 차라리 삽살이를 풀어보는 시선이 낫다고 봐요.” – 메이 웨스트(Mae West)
우리는 종종 “좋은 아이디어면 알아서 통하겠지”라고 생각한다. 하지만 실제로는 ‘무엇을 말하느냐’보다 ‘어떻게 전달하느냐’가 더 중요하다. 아무리 훌륭한 코드나 혁신적인 해결책이 있더라도, 그것을 동료나 고객과 제대로 소통하지 못하면 아무 의미가 없다.
개발자는 회의, 보고, 이메일, 코드 리뷰 등 다양한 방식으로 소통한다. 코드는 단순히 기계에 대한 명령문이 아니라, 사람과의 대화 수단이다. 즉, 미래의 나 자신이나 동료 개발자에게 남기는 메시지인 셈이다. 따라서 “좋은 개발자”는 뛰어난 코드를 작성하는 사람만이 아니라, 생각을 명확하게 표현하고 공유할 수 있는 사람이다.
2. 청중을 이해하라
“전달하는 내용보다, 상대가 어떻게 이해했는지가 진짜 의미다.”
소통의 핵심은 ‘내가 얼마나 똑똑한가’가 아니라, ‘상대가 얼마나 이해했는가’에 있다. 프로젝트 회의에서 복잡한 기술적 이야기를 늘어놓는 대신, 상대의 배경지식과 관점을 고려해 표현 방식을 바꿔야 한다.
예를 들어, 시스템 개선안을 제시할 때 “이건 기존 모듈의 비동기 호출을 최적화한 구조예요.”보다는 “이 변경으로 응답 속도가 두 배 빨라집니다.”처럼 ‘효과 중심의 언어’로 번역하는 것이 훨씬 낫다. 즉, 청중의 언어로 말하라.
3. 말하고 싶은 게 있다면 먼저 정리하라
회의나 보고 전에, 무엇을 말하려는지 명확히 정리하는 습관을 가져야 한다. 글을 쓸 때는 초안을 작성하듯, 말할 때도 핵심을 정리해야 한다. “이 회의에서 내가 얻고 싶은 결론은 뭘까?”, “상대가 기억해야 할 한 문장은?” 이 질문을 스스로에게 던져보면, 대화의 흐름이 한결 명확해진다.
특히 리더나 클라이언트와 대화할 때는, 상대가 원하는 바를 파악하고 그들의 ‘우선순위 언어’로 말해야 한다. 기술적 세부사항보다 비즈니스적 가치, 일정, 리스크 완화 같은 키워드를 활용하면 좋다.
4. 때를 골라라
전달 시점 또한 메시지의 일부다. 금요일 오후 퇴근 직전, 혹은 회식 후의 미팅은 최악의 타이밍이다. 대화가 필요한 순간이라면, 상대의 컨디션과 맥락을 고려한 타이밍을 잡아라. 때로는 “지금 말해도 될까요?”라는 한 문장이 훨씬 많은 공감을 만든다.
5. 스타일을 조절하라
모든 소통은 상대의 스타일에 맞춰야 한다. 어떤 사람은 간결하고 데이터 중심의 보고를 좋아하고, 어떤 사람은 스토리텔링과 사례 중심의 설명을 선호한다. 상대의 반응을 관찰하며, 톤, 속도, 시각자료의 수준을 조절하라. 이것은 단순한 예의가 아니라, ‘실용적인 전달 기술’이다.
6. 문서화하라
“말은 사라지지만, 문서는 남는다.”
프로그래머의 세계에서 문서화는 종종 귀찮은 일로 여겨지지만, 사실상 가장 강력한 소통 도구다. 코드에 주석을 남기는 일은 **‘코드와 대화하는 문서화’**다. 기술적 결정의 이유, 대안, 배경을 기록해두면 다음 세대 개발자들이 실수를 반복하지 않게 된다. 문서는 팀 전체의 기억 저장소이며, 프로젝트의 생명력을 연장하는 유일한 수단이다.
7. 멋지게 전달하라
좋은 아이디어일수록 멋지게 보여야 한다. 단순히 내용을 잘 말하는 것을 넘어, 시각적 완성도와 구조적 깔끔함이 메시지의 신뢰도를 높인다. 정리된 슬라이드, 보기 쉬운 마크다운 문서, 간결한 문체 하나가 전달력을 배가시킨다.
8. 응답하라
누군가에게 질문을 받았다면, “지금은 답을 드릴 수 없습니다”라도 응답하라. 무응답은 무례함으로 해석될 뿐이다. 빠른 회신은 상대의 신뢰를 얻는 가장 확실한 방법이다. 단 한 줄이라도, “확인했습니다. 검토 후 회신드리겠습니다.” 가면 충분하다.
9. 온라인에서도 똑같이
이메일, 슬랙, 블로그 등 텍스트 기반의 의사소통에도 동일한 원칙이 적용된다. ‘보내기’ 버튼을 누르기 전 반드시 다시 읽어라. 맞춤법, 자동 수정, 불필요한 감정 표현을 점검하라. 특히 이메일에서는 형식과 맥락이 신뢰를 만든다.
10. 정리: 소통은 기술이다
효율적인 소통은 단순한 커뮤니케이션 능력이 아니다. 그것은 개발자의 또 다른 생산성 도구이며, 협업의 품질을 결정짓는 실용적 기술이다.
요약하자면,
청중을 이해하라.
말하고 싶은 것을 정리하라.
때를 골라라.
스타일을 조절하라.
문서화하라.
응답하라.
그리고, 무엇을 말하느냐보다 어떻게 말하느냐를 연습하라.
Last updated