https://www.youtube.com/watch?v=Du1aeNElueA

description: |-

1. 이건 꼭 알아야 한다[^1]

[? 질문] 야근하고 최신 기술을 열심히 공부하는데도, 왜 연봉과 영향력은 제자리인가[^2]
[= 답] 많은 개발자가 개발 감각을 알고리즘 풀이/프레임워크 숙련 같은 코딩 구현 스킬로 착각하고 있으며, 정작 가치와 우선순위를 가르는 감각을 못 키우기 때문이다.[^3]

[? 질문] 개발 감각이란 정확히 무엇이며, 코딩 스킬과 무엇이 다른가[^4]
[= 답] 개발 감각은 “코드를 예쁘게 짠다”가 아니라, 수많은 문제 중 지금 진짜 풀어야 할 문제를 짚고, 그 문제의 핵심을 가장 값싸고 단순하게 해결할 기술적 포인트와 우선순위를 정하는 능력이다.[^5]

[? 질문] 개발 감각은 어떻게 훈련할 수 있는가[^6]
[= 답] 최신 기술 글만 소비하는 “달콤한 인풋”을 줄이고, (1) 잘 만든 오픈소스의 설계 문서·PR 토론/RFC를 읽어 타협의 역사와 의사결정을 배우고, (2) 실제 서비스 장애 회고록을 읽어 “현실에서 작동하는 코드” 관점으로 안전장치/약한 고리를 점검하는 훈련을 해야 한다.[^7]

2. 큰 그림[^8]

이 콘텐츠는 “내가 개발자로서 재능(감각)이 있는지”를 뜬구름 잡는 이야기가 아니라, 개발 감각을 코딩 실력과 분리해 정의하고, 실무에서 그 감각이 어떻게 드러나는지(요구사항을 받았을 때의 행동)와 어떻게 단련하는지(읽어야 할 것/물어야 할 질문)를 구체 사례로 설명한다.[^9] 또한 “기술적으로 멋진 선택”보다 “사용자 가치와 사업/제품 목적에 맞는 우선순위”가 영향력과 결과를 만든다는 관점을 반복해서 강조한다.[^10]

• 개발 감각은 최신 기술/아키텍처 과시가 아니라, 문제의 본질과 우선순위를 가려 “가장 싸게” 해결하는 능력이다.[^5]
• 같은 요구사항(실시간 채팅)도 감각 있는 개발자는 기술 스택 나열이 아니라 일순위 가치를 묻고, 필요하면 더 단순한 방식(HTTP)으로 먼저 검증한다.[^11]
• 감각은 “인풋 중독”이 아니라, 오픈소스 토론/RFC·장애 회고를 통해 **트레이드오프(무엇을 얻고 무엇을 버리는지)**를 체화하며 길러진다.[^12]

3. 하나씩 살펴보기[^13]

3.1 “열심히 하는데 왜 그대로지?”라는 불안에서 출발[^14]

화자는 영상 시작과 함께, 많은 개발자가 공감할 만한 상황을 제시한다. “오늘도 야근을 하고 최신 기술 스터디도 누구보다 열심히” 하지만,[^15] 어느 순간 이런 자문이 든다고 한다:

• “[? 내가 40살이 돼도 이러고 살아야 하나?]”[^16]
• “[? 왜 나의 연봉은 제자리이고 영향력은 딱히 늘지 않을까?]”[^17]

그리고 이 질문에 대해 화자는 원인을 단번에 특정한다. 문제는 성실함 부족이 아니라, 코딩 스킬과 개발 감각을 “처참하게 착각”하고 있기 때문이라는 것이다.[^3] 즉, 노력의 방향이 어긋나 있으니 결과(연봉/영향력)가 안 따라오는 구조라는 진단이다.[^3]

여기서 화자는 흔한 오해를 구체적으로 지목한다. 많은 사람들이 아래 능력들을 개발 감각으로 착각한다고 말한다.[^18]

• 알고리즘 문제 풀이 능력[^18]
• 최신 프레임워크 사용 능력[^18]

화자는 이 오해를 “위험한 환상”이라고 부르며, 오늘 그 환상을 “완전히 부서”겠다고 선언한다.[^19] 이 선언은 이후 전개(정의 → 예시 → 훈련법) 전체의 목표가 된다.[^19]

3.2 개발 감각은 “구현 스킬”과 다른 영역: 사업 감각 비유로 분리하기[^20]

화자는 개발 감각을 설명하기 위해 먼저 비유를 든다. “코딩맨 사업 감각이 마케팅 감각과 다르듯” 개발 감각도 코딩 구현 스킬과 “완전히 다른 영역”이라고 말한다.[^21]
즉, 같은 ‘일을 잘한다’ 범주로 묶이지만, 실제로는 서로 다른 능력 축이라는 프레이밍이다.[^21]

이어서 나이키 예시를 들어 “가치/철학을 내세우는 것”과 “사람들이 실제로 돈을 내고 선택하는 이유”가 다를 수 있음을 설명한다.[^22] 화자는 나이키가 “도전 정신이라는 가치”를 내세운다고 해도, 사람들이 “가치 하나 때문에 운동화를 사지는 않는다”고 말한다.[^22]

이 비유를 개발로 옮겨오면, 개발자가 자랑하는 “우아한 아키텍처”나 “SOLID 원칙”은 정작 사용자나 협업자에게 중요한 관심사가 아닐 수 있다는 결론으로 이어진다.[^23] 화자는 여기서 관심 주체를 구체적으로 열거한다:

• 사용자는 물론[^24]
• 함께 일하는 PM이나 디자이너도 “전혀 관심 없다”[^24]

그리고 그것은 “그저 당신의 구현 스킬 자랑일 뿐”이라고까지 말한다.[^25] 즉, 내부적 만족(기술적 멋)과 외부적 가치(제품 성공/사용자 만족)는 분리될 수 있으며, 개발 감각은 전자보다 후자 쪽에 가깝다는 문제의식을 깔아둔다.[^25]

여기서 화자는 개발 감각의 **부정의 정의(“~이 아니다”)**를 먼저 못 박는다:

• [h 개발 감각은 코드를 예쁘게 짜는 능력이 아니다] [^5]

그리고 곧바로 **정의(“~이다”)**를 제시한다. 개발 감각은 다음을 해내는 능력이다.[^5]

1. 지금 풀어야 할 수많은 문제들 중에서
2. “어떤 문제가 진짜 풀어야 할 문제인지”를 짚어내고
3. “문제의 핵심을 가장 값싸게 해결할 기술적 포인트”를 찾아내는 것[^5]

여기에는 두 개의 축이 함께 들어 있다.

• 문제 선택 능력: 무엇이 ‘진짜 문제’인가를 가른다.[^5]
• 해결 전략 능력: 그 문제를 가장 저렴(시간/복잡도/비용 최소)하게 풀 포인트를 찾는다.[^5]

3.3 “감각 있는 개발자”의 관찰법: 성공한 앱을 분해해 본질을 찾는다[^26]

화자는 감각 있는 개발자를 “성공한 사업을 벤치마킹하는 사업가”에 비유한다.[^27] 여기서 포인트는 ‘겉모습을 따라 하기’가 아니라 ‘성공의 핵심 요인을 구조적으로 파악’하는 태도다.[^27]

화자는 예시로 토스나 당근마켓 같은 성공한 앱을 언급한다.[^28] 감각 없는 시선은 이런 수준에서 멈춘다고 말한다:

• “UI 멋있다”[^28]
• “이런 기술 썼겠지”[^28]

반면 감각 있는 개발자는 여기서 멈추지 않고, 분해 질문을 던진다.[^29]

• “[? 이 기능이 성공한 핵심 요소를 세 가지로 분해한다면 무엇인가?]”[^29]
• “[? 가장 결정적인 한 가지는 무엇인가?]”[^30]

화자는 감각 있는 개발자는 이런 것을 “본능적으로 파악”한다고 말한다.[^31] 즉, 개발 감각의 중요한 구성 요소는 **핵심 요인 추출(구조화/우선순위화)**이며, 단순 관찰이나 기술 추측이 아니라 “성공의 결정 요인을 뽑아내는 사고 습관”이라는 주장이다.[^31]

3.4 실시간 채팅 요구사항 사례: 감각 없는 접근 vs 감각 있는 접근[^32]

화자는 “실시간 채팅 기능을 만들라”는 요구사항이 떨어졌다는 상황을 가정하며, 개발 감각이 실제로 어떻게 갈리는지 비교한다.[^33]

3.4.1 감각 없는 개발자의 첫 반응: 기술 스택 나열부터 시작[^34]

화자는 감각 없는 개발자가 “무엇부터 하겠냐”는 질문에 기술부터 나열한다고 한다.[^35] 예시는 다음처럼 이어진다.[^35]

• “실시간이니까 웹소켓을 쓰고”[^35]
• “메시지 큐는 역시 카프카가 좋겠군”[^35]
• “UI는 리액트로 가야겠지”[^35]

이 묘사는, 요구사항의 표면 단어(“실시간”)에 즉각 반응해 그 단어와 연관된 유명 기술을 선택하는 패턴을 보여준다.[^35] 즉 “기술의 정답 찾기” 게임으로 바뀌어 버린다는 비판이다.[^35]

3.4.2 감각 있는 개발자의 첫 반응: 회의를 멈추고 ‘가치’를 묻는다[^36]

반면 감각 있는 개발자는 “회의를 멈춰 세우고 질문”한다고 말한다.[^37] 여기서 화자가 실제로 던지는 질문은 다음과 같다.[^37]

• “[? 잠깐만요. 이 채팅의 핵심 목적이 뭔가요?]”[^37]
• “[? 여기서 절대 실패하면 안 되는 일순위 가치는 무엇이죠?]”[^38]

즉, 구현 방식이 아니라 목적/가치/실패 허용 불가 조건을 먼저 명확히 한다.[^38]

그리고 그 답(일순위 가치)이 무엇이냐에 따라 기술 선택이 완전히 달라질 수 있음을 보여준다.[^39] 화자는 특정 상황을 제시한다:

• 일순위 가치가 “화려한 실시간”이 아니라
• “메시지 누락 없는 안정적인 전달”이라면[^39]

이때 감각 있는 개발자는 “과감하게” 이렇게 제안한다.[^40]

• [= “초기 버전에서는 그냥 HTTP로 바로 테스트해 보죠.”] [^40]
• [= “안정성을 일단 빠르게 확보하고 테스트해 보죠.”] [^41]

여기서 핵심은 “기술적으로 덜 멋져 보일 수 있는 선택”을 해도, 일순위 가치(안정성) 달성에 더 빠르고 싸게 도달한다면 그게 감각이라는 주장이다.[^41]

3.4.3 조직/협업 관점의 현실 묘사: 개발자는 당황, 비개발자는 안정성만 원한다[^42]

화자는 이 선택(HTTP로 먼저 가자)이 개발 팀에는 “살짝 당황”을 줄 수도 있다고 인정한다.[^43] 그 이유는 흔히 ‘실시간’이라는 요구사항에 ‘웹소켓’ 같은 전형적 해법을 기대하기 때문이다.[^43]

하지만 PM/기획 쪽은 기술적 세부를 “무슨 말인지 잘 모르겠”기 때문에, 결과적으로는 “일단 안정성만 잘 확보되면 된다”는 반응을 보인다고 한다.[^44]
즉, 협업의 다수 이해관계자에게 중요한 것은 “멋진 기술 선택”보다 “요구 가치의 충족(안정성/누락 없음)”이라는 현실을 강조한다.[^44]

그리고 결과는 다음처럼 정리된다.[^45]

• 당신의 아이디어(HTTP로 먼저)는 “최고의 UI/UX”를 보장하진 않지만[^45]
• 사용자들이 “꽤나 만족스러워하는 기능”을[^45]
• “적당한 노력”으로 완성하게 해준다.[^45]

나아가 “어쩌면 이대로 쭉 가볼 수도 있겠”다는 말로, 초기의 단순한 구현이 장기적으로도 충분할 수 있음을 열어 둔다.[^46] 즉, 처음부터 복잡도를 올리는 것이 항상 정답이 아니라는 메시지다.[^46]

3.5 스타벅스 비유로 재강조: ‘실시간’ 환상 vs ‘안정 전달’ 본질[^47]

화자는 갑자기 스타벅스 성공요인을 가져와 비유한다.[^48] 스타벅스의 핵심은 “커피 맛”이 아니라 “입지, 즉 접근성”이라는 말로, 제품의 본질적 성공 요인이 우리가 흔히 떠올리는 ‘정면의 품질’과 다를 수 있음을 상기시킨다.[^49]

이 비유를 개발로 다시 연결한다.[^49]

• 개발 감각은 “실시간”이라는 기술적 환상보다[^49]
• “안정적인 전달”이라는 본질을 꿰뚫어보고[^49]
• 그것을 “가장 단순하게 구현할 우선순위”를 정하는 힘이다.[^49]

즉, 개발 감각 = 본질 파악 + 단순한 구현 + 우선순위 결정의 결합이라는 정의가, 채팅 예시와 스타벅스 비유로 반복 강화된다.[^49]

3.6 감각이 없을 때 벌어지는 전형적 결과: 화려한 기술, 미완의 기능, 유실되는 메시지[^50]

화자는 개발 감각이 없는 개발자 집단의 전형적 상황을 “일주일 뒤에 얼마나 만들었냐고 물어보면”이라는 형태로 묘사한다.[^51]

겉으로는 진행이 좋아 보인다.[^51]

• “아주 빠르고 화려하게 웹소켓을 쓰고 있다”고 말한다.[^51]

하지만 실상은 치명적이다.[^52]

• “기능은 붙지 않았고”[^52]
• “메시지는 조금씩 유실”된다.[^52]

즉, 겉보기에 ‘실시간’ 기술 도입은 했지만, 일순위 가치(누락 없는 전달)를 달성하지 못했다는 것이다.[^52] 그리고 “가장 중요한 기능을 완성하지 못한 채 야근만 하고 있다”고 말한다.[^53]

그럼에도 마지막이 더 날카롭다. 그들은 “그리고는 뿌듯해”한다고 한다.[^54] 즉, 결과 중심이 아니라 “기술 적용 자체”에서 성취감을 얻는 태도가 문제라는 비판이다.[^54]

3.7 개발 감각은 어떻게 기르나: “기술 구현 너머의 것”을 읽어라 + 인풋 중독을 끊어라[^55]

화자는 이제 훈련법으로 넘어가며, 먼저 “그럼 이 감각은 어떻게 기를 수 있을까요?”라고 질문 형태로 전환한다.[^56]

여기서 화자는 또 하나의 비유를 든다. “사업가가 입문, 역사, 철학을 읽듯” 개발자도 “기술구 너머의 것”을 읽어야 한다고 말한다.[^57] (문장상 ‘기술구’는 ‘기술 구현’ 또는 ‘기술 그 너머’ 취지로 읽히며, 핵심은 기술 사용법 이상의 맥락을 보라는 주장이다.)[^57]

이 대목에서 화자는 강한 행동 지침을 준다.[^58]

• “최신 기술 아티클만 읽는 것을 멈추세요.”[^58]
• “공부로 도망치지 마세요.”[^59]

그리고 왜 그것이 문제인지 이름을 붙인다:

• “그건 그저 달콤한 인풋 중독”이다.[^60]
• “진짜 공부는 따로 있다.”[^61]

즉, ‘최신 글 읽기’ 자체를 부정한다기보다, 그것만으로는 감각(우선순위/타협/현실 문제)을 못 기른다는 경고로 기능한다.[^61]

3.8 훈련법 1: 오픈소스의 설계 문서·PR 토론·RFC를 읽어 “타협의 감각”을 익혀라[^62]

화자는 첫 번째 훈련법으로, “잘 만든 오픈소스 프로젝트”의 다음 자료를 읽으라고 한다.[^63]

• “초기 설계 문서”[^63]
• “PR(풀 리퀘스트)의 토론 기록”[^63]

여기서 핵심은 결과물(코드/기능)이 아니라, 그 결과물이 나오기까지의 의사결정 과정을 보라는 것이다.[^63]

화자는 언어 설계의 예시로, “단순함을 종교처럼 따르는 언어”를 언급하며(구체 언어명은 직접 말하지 않지만), 그 언어에 “왜 제네릭은 없냐”는 원성이 있었다고 소개한다.[^64]
그리고 중요한 포인트는, 이것이 겉보기엔 “단순 하나의 이슈”처럼 보여도[^65] 실제로는 “제네릭이라는 주제 하나에 대해 수백 개가 넘는 토론”이 오갔다는 점이다.[^66]

화자가 이 사례로 말하려는 바는 다음으로 정리된다.[^67]

• 사람들이 “왜 이 기술을 선택했고”[^67]
• “무엇을 포기했는지”[^67]
• 그 “치열했던 타협의 역사”를 복기하는 방법이라는 것[^67]

즉, 개발 감각의 실체를 “트레이드오프를 읽어내는 능력”으로 본다.[^67]

이어서 더 구체적 예시로 “리액트의 서버 컴포넌트 PR”을 언급한다.[^68] 그리고 대규모 레포지토리에서는 새로운 기능과 관련된 스펙을 정의할 때 “RFC 단계에서 많은 토론이 오간다”고 부연 설명한다.[^69]

여기서 화자는 아주 구체적인 수치를 말한다:

• “240개의 토론 끝에 단 하나의 설계 문서 파일이 붙었다.”[^70]

이 수치(240)는 “합의/타협”이 얼마나 큰 비용과 과정을 요구하는지 상징적으로 보여준다.[^70]

그리고 다시 대비 구도를 만든다.[^71]

• 감각 없는 개발자는 “사용법만 익히지만”[^71]
• 감각 있는 개발자는 “이 토론을 읽으며 타협의 감각을 익힌다”[^71]

마지막으로 리액트 팀의 타협을 한 문장으로 요약해 보여준다:

• “클라이언트의 경험을 위해 서버의 복잡성을 기꺼이 감수”했다.[^72]

이 문장은 “무엇을 얻기 위해(클라이언트 경험)” “무엇을 포기/부담했는지(서버 복잡성)”라는 트레이드오프 프레임을 선명하게 드러내며, 화자가 말하는 개발 감각의 훈련 방향을 구체화한다.[^72]

[!TIP] 오픈소스에서 ‘감각’을 뽑아내는 읽기 포인트
코드 자체보다 “왜 이런 결정을 했는가 / 어떤 대안이 있었나 / 무엇을 버렸나 / 어떤 부작용을 감수하나” 같은 질문으로 PR·RFC 토론을 읽을 때, 기술 선택의 우선순위와 타협을 체화할 수 있다는 것이 화자의 주장이다.[^67]

3.9 “오픈소스는 너무 방대해요”에 대한 대안: 사람(또는 AI)과 비교 토론하라[^73]

화자는 예상 반론을 먼저 던진다:

• “[? 오픈소스는 너무 방대하고 어렵다고요?]”[^74]

그리고 대안을 제시한다.[^75]

1. “사이드 프로젝트를 하는 팀원들과 이야기를 나눠 보라”[^75]
2. “친구들과 의견이 다를 때 다양한 방법을 두고 장단점을 천천히 비교해 보라”[^76]
3. “사회성이 떨어져서 친구가 없다면 AI를 활용해서 다른 방법과의 장단점을 꼼꼼히 비교해 보라”[^77]

이 파트의 요지는 ‘정답 기술 찾기’가 아니라 대안 비교와 장단점 평가를 반복하는 훈련이 감각을 만든다는 것이다.[^76]

그리고 화자는 중요한 경고 문장을 덧붙인다:

• [h 넣으면 무조건 좋은 기술은 없다] [^78]

즉, 어떤 기술을 추가하면 항상 비용이 발생한다.[^79] 화자는 비용의 형태를 두 가지로 말한다:

• “당신의 시간을 소비”하거나[^79]
• “코드의 복잡성이 조금씩 올라”간다[^79]

이는 “트레이드오프 감각”이 단지 오픈소스 사례에만 적용되는 게 아니라, 일상적인 기술 도입 의사결정에도 적용되어야 한다는 연결고리다.[^79]

3.10 훈련법 2: 서비스 장애 회고록을 읽어 ‘현실 세계에서 작동하는 코드’를 배워라[^80]

두 번째 훈련으로 화자는 “서비스의 장애 회고록 읽기”를 제안한다.[^81]

먼저 최근 사례로 “며칠 전 AWS가 장애가 나서 전 세계가 마비”되었다고 말한다.[^82] 그리고 그때 “수많은 개발자들”이 보인 전형적 반응을 묘사한다.[^83]

• “그저 상황이 해결되길 기다리며 새로 고침만 누르거나”[^83]
• “예상치 못한 야근을” 한다[^83]

하지만 문제는 거기서 멈춘다는 것이다.[^84]

• “왜 이런 일이 일어났는지에 대해서는 아무도 분석하지 않는다.”[^84]

화자는 여기서 실전의 정의를 다시 못 박는다:

• [c 개발자의 실전은 아름다운 코드가 아니라 현실 세계에서 작동하는 코드다] [^85]

즉, 개발 감각은 ‘클린 코드’ 담론만으로는 만들어지지 않고, 장애/실수/비정상 사용자 행동 같은 현실 변수를 견디는 관점에서 강화된다는 주장이다.[^85]

이어서 과거 사례를 하나 더 든다. “몇 년 전에도 AWS S3가 마비”된 적이 있고[^86] 그 사건은 “엔지니어 한 명의 단순한 오타 하나가 인터넷의 절반을 마비”시켰다고 말한다.[^87] (표현은 과감하게 과장/강조되어 있으며, 핵심은 사소한 실수가 초대형 장애로 번질 수 있다는 메시지다.)[^87]

그리고 중요한 포인트는, AWS가 이 과정을 “아주 상세한 회고록으로 남겨” 두었다는 것.[^88] 화자는 이것을 다음처럼 규정한다:

• “이것이 바로 감각 있는 개발자들의 비밀 교과서”[^89]

왜 회고록이 ‘교과서’냐에 대한 이유도 이어진다. 실제 서비스 운영에서 “재앙은 늘 사소한 곳에서 시작”하며,[^90]

• 개발자는 “반드시 실수를 하고”[^91]
• 사용자는 “절대 의도대로 움직이지 않으며”[^91]
• 재앙은 “언제나 예고 없이 찾아”온다[^91]

즉, ‘실수는 예외’가 아니라 ‘기본값’이라는 전제에서 시스템을 바라보는 관점이 필요하며, 그 관점이 개발 감각의 일부라는 흐름이다.[^91]

3.11 장애 회고록을 읽을 때 스스로에게 던질 질문: 우리 시스템/팀은 버틸 수 있나[^92]

화자는 회고록을 단순히 읽고 끝내지 말고, 스스로에게 질문을 던지라고 한다.[^93] 여기서 화자가 직접 제시한 질문은 다음과 같다.[^93]

• “[? 우리 시스템이었다면 이 오타 하나를 막을 수 있었을까?]”[^94]
• “[? 우리 팀에는 이런 실수를 해도 버틸 수 있는 안전 장치가 있는가?]”[^95]

즉, 회고록의 목적은 “남의 불행 구경”이 아니라, 내 시스템의 약점 찾기로 전환하는 것이다.[^95]

화자는 결론적으로, 이런 실패 사례를 통해 “시스템의 약한 고리를 찾아내는 훈련”을 할 때에야 비로소 개발 감각이 “진짜 실전 근육”으로 단련된다고 말한다.[^96]

[!IMPORTANT] 회고록 학습의 핵심 태도
장애 원인을 “그 사람 실수”로 끝내지 말고, “우리 시스템이라면 방지/완화가 가능했는가”로 바꿔 묻는 것이 감각 훈련이라는 것이 화자의 결론이다.[^94]

3.12 최종 결론: “어떻게 만들까” 이전에 “무엇이 1순위인가”, 그리고 “무엇을 포기할까”[^97]

화자는 마지막에 결론을 명확한 문장으로 정리한다.[^98]

• [c 이걸 어떻게 만들까를 고민하기 전에, 가장 중요한 일순위는 무엇인가를 생각해 보세요] [^98]
• [h 하나를 얻기 위해 어떤 걸 포기할지 고민해 보세요] [^99]

즉, 개발 감각은 ‘구현 테크닉’이 아니라 우선순위 결정과 트레이드오프 선택이라는 것이다.[^99]

그리고 이 메시지를 자기 사례로 연결한다. 화자는 “유튜브라는 프로젝트”에서 “업로드 속도를 얻기 위해” 현재 영상은 “그림과 음성을 포기”했다고 말한다.[^100] 즉, 어떤 목표(업로드 속도)를 위해 다른 품질 요소(그림/음성)를 희생하는 실제 트레이드오프를 보여준다.[^100]

이어서 “정답은 없다”고 말하며,[^101] 반대 판단도 가능했음을 인정한다:

• 업로드 속도를 늦추고 퀄리티를 올리는 판단이 “더 좋았을 수도” 있다.[^102]

이로써 화자는 트레이드오프 선택이 단선적 정답이 아니라 상황과 목표에 따른 판단임을 강조한다.[^102]

마지막 당부는 두 겹으로 제시된다.[^103]

1. “감각을 훈련하고 시간과 에너지를 중요한 곳에 쏟아”라[^103]
2. 프로젝트에서 무엇을 버릴지, 더 나아가 “나의 인생에서는 어떤 걸 포기할 수 있을지” 고민해 보라고 확장한다.[^104]

즉, 개발 감각은 단지 개발 스킬이 아니라, 제한된 자원(시간/에너지) 하에서의 선택과 집중이라는 삶의 태도와도 닿아 있음을 암시하며 마무리한다.[^104]

4. 핵심 통찰[^105]

1. 개발 감각은 “코딩을 잘하는 능력”이 아니라 “무엇을 풀지/어떻게 단순하게 풀지”를 가르는 능력으로 정의된다.[^5]

   • 실행: 요구사항을 받으면 기술 논의 전에 “일순위 가치/절대 실패하면 안 되는 것”부터 질문으로 확정하라.[^38]

2. 겉으로 멋진 기술(웹소켓/카프카/새 프레임워크) 도입은 결과(기능 완성/안정성)를 보장하지 않으며, 오히려 핵심 가치 미달 상태로 야근을 만든다.[^52]

   • 실행: 초기 버전은 더 단순한 구현(예: HTTP)으로 핵심 가치를 먼저 만족시키는 전략을 고려하라.[^40]

3. 감각의 실체는 트레이드오프(얻는 것 vs 포기하는 것)를 읽고 선택하는 힘이며, 이는 오픈소스의 PR/RFC 토론에서 가장 잘 드러난다.[^71]

   • 실행: 오픈소스 기능 “사용법” 문서만 보지 말고, 토론에서 어떤 대안이 기각됐는지/왜 복잡성을 감수했는지까지 읽어라.[^72]

4. “최신 기술 아티클만 읽는 공부”는 감각 훈련이 아니라 인풋 중독이 될 수 있으며, 실전 의사결정에는 별 도움이 안 될 수 있다.[^60]

   • 실행: 인풋(기사/강의) 시간을 줄이고, 대안 비교/의사결정 기록 읽기/회고 분석 같은 ‘판단 훈련’ 비중을 늘려라.[^76]

5. 실전은 장애와 실수를 전제로 한다. 장애 회고록은 “현실에서 작동하는 코드” 관점의 교과서다.[^85]

   • 실행: 회고록을 읽을 때 “우리 시스템이면 막을 수 있었나/버틸 안전장치가 있나”로 전환해 체크리스트를 만들어라.[^95]

6. 개발 감각은 프로젝트뿐 아니라 삶의 자원 배분 문제로 확장된다. 무엇을 얻기 위해 무엇을 포기할지 결정하는 연습이 감각을 만든다.[^104]

   • 실행: 현재 프로젝트에서 ‘버릴 수 있는 것’ 1~3개를 명시하고, 그 대가로 얻는 가치를 문장으로 적어 의사결정을 명료화하라.[^99]

---

참고(콘텐츠 정보)[^106]

• 제목: 개발감각 있는지 확인하는 법[^106]
• 채널: 코딩맨[^106]
• 길이: 4분 41초[^106]
• 링크: https://www.youtube.com/watch?v=Du1aeNElueA[^106]
• 키워드(제공됨): 개발자, 연봉, 재능, 코딩, AWS, 장애, 이슈, 개발감각, 코딩감각, 논리력[^106]

[^1]: @[00:09] “코딩 스킬과 개발 감각을 처참하게 착각하고 있기 때문입니다.” [^2]: @[00:00] “오늘도 야근… 최신 기술 스터디…” / @[00:04] “내가 40살이 돼도…” / @[00:06] “왜 나의 연봉은…” [^3]: @[00:09] “코딩 스킬과 개발 감각을… 착각” / @[00:12] “많은 사람들이… 오해합니다.” [^4]: @[00:21] “개발 감각은 코딩 구현 스킬과 완전히 다른 영역” [^5]: @[00:39] “개발 감각은 코드를 예쁘게 짜는 능력이 아닙니다.” / @[00:42] “진짜 풀어야 할 문제… 가장 값싸게 해결…” [^6]: @[02:11] “그럼 이 감각은 어떻게 기를 수 있을까요?” [^7]: @[02:26] “오픈소스… 설계 문서… 토론 기록” / @[03:22] “서비스의 장애 회고록 읽기” [^8]: @[00:15] “위험한 환상을 완전히 부서 드리겠습니다.” [^9]: @[00:42] 문제 선정/값싸게 해결 정의 / @[01:06] 채팅 요구사항 사례 도입 [^10]: @[00:32] “우아한 아키텍처… 관심 없습니다.” / @[01:50] “기술적 환상보다… 본질” [^11]: @[01:19] “핵심 목적이 뭔가요?” / @[01:28] “초기 버전에서는 그냥 HTTP…” [^12]: @[02:19] “달콤한 인풋 중독” / @[02:40] “무엇을 포기했는지… 타협의 역사” [^13]: @[00:15] “오늘은… 부서 드리겠습니다.”(이후 전개 전반) [^14]: @[00:03] “하지만 문득 이런 생각이 듭니다.” [^15]: @[00:00] “오늘도 야근… 스터디…” [^16]: @[00:04] “내가 40살이 돼도…” [^17]: @[00:06] “왜 나의 연봉은… 영향력은…” [^18]: @[00:12] “알고리즘… 프레임워크… 오해” [^19]: @[00:15] “위험한 환상을 완전히 부서 드리겠습니다.” [^20]: @[00:21] “개발 감각… 다른 영역” [^21]: @[00:21] “사업 감각… 마케팅 감각… 개발 감각… 다른 영역” [^22]: @[00:27] “나이키가… 가치… 운동화를…” [^23]: @[00:32] “우아한 아키텍처나 솔리드 원칙” [^24]: @[00:35] “사용자는 물론… PM이나 디자이너도… 관심 없습니다.” [^25]: @[00:37] “그저 당신의 구현 스킬 자랑” [^26]: @[00:45] “감각 있는 개발자는… 사업가와 같습니다.” [^27]: @[00:45] “성공한 사업을 벤치마킹…” [^28]: @[00:48] “토스나 당근 마켓… UI 멋있다…” [^29]: @[00:53] “이 기능이 성공한 핵심 요소를… 세 가지…” [^30]: @[00:56] “가장 결정적인 한 가지는…” [^31]: @[00:59] “본능적으로 파악” [^32]: @[01:06] “채팅 기능… 요구 사항” [^33]: @[01:06] “실시간 채팅 기능… 상상” [^34]: @[01:09] “감각 없는 개발자는 기술부터 나열” [^35]: @[01:13] “웹소켓… 카프카… 리액트…” [^36]: @[01:17] “하지만 감각 있는 개발자는… 질문합니다.” [^37]: @[01:19] “이 채팅의 핵심 목적이 뭔가요?” [^38]: @[01:21] “절대 실패하면 안 되는 일순위 가치는…” [^39]: @[01:25] “일순위 가치가… 안정적인 전달이라면” [^40]: @[01:28] “초기 버전에서는 그냥 HTTP로…” [^41]: @[01:31] “안정성을… 빠르게 확보…” [^42]: @[01:35] “개발 쪽에서는… 당황… PM… 안정성…” [^43]: @[01:35] “개발 쪽에서는 살짝 당황…” [^44]: @[01:35] “PM… 잘 모르겠으니… 안정성만…” [^45]: @[01:38] “최고의 UI UX… 않지만… 만족… 적당한 노력” [^46]: @[01:42] “어쩌면 이대로 쭉가 볼 수도…” [^47]: @[01:45] “스타벅스 성공요인은…” [^48]: @[01:45] “스타벅스 성공요인은” [^49]: @[01:50] “커피 맛이 아니라… 접근성… 본질… 단순하게 구현” [^50]: @[01:59] “개발 감각이 없는 개발자들에게…” [^51]: @[01:59] “일주일 뒤… 아주 빠르고 화려하게…” [^52]: @[01:59] “기능은 붙지 않았고 메시지는… 유실” [^53]: @[02:03] “가장 중요한 기능을 완성하지 못한 채…” [^54]: @[02:06] “그리고는 뿌듯해합니다.” [^55]: @[02:13] “기술구 너의 것을 읽어야 합니다.” [^56]: @[02:11] “어떻게기를 수 있을까요?” [^57]: @[02:13] “사업가가… 개발자도… 읽어야” [^58]: @[02:15] “최신 기술 아티클만… 멈추세요.” [^59]: @[02:17] “공부로 도망치지 마세요.” [^60]: @[02:19] “달콤한 인풋 중독” [^61]: @[02:21] “진짜 공부는 따로 있습니다.” [^62]: @[02:26] “첫째, 잘 만든 오픈소스…” [^63]: @[02:26] “초기 설계 문서… 토론 기록” [^64]: @[02:29] “단순함을 종교처럼…” / @[02:33] “왜 제네릭은 없냐…” [^65]: @[02:36] “단순 하나의 이슈처럼…” [^66]: @[02:36] “수백 개가 넘는 토론” [^67]: @[02:40] “왜… 선택했고 무엇을 포기… 타협의 역사…” [^68]: @[02:43] “리액트의 서버 컴포넌트 PR” [^69]: @[02:47] “RFC 단계에서 많은 토론” [^70]: @[02:52] “240개의 토론 끝에…” [^71]: @[02:55] “사용법만 익히지만… 토론을 읽으며 타협의 감각” [^72]: @[02:58] “클라이언트… 서버의 복잡성… 타협” [^73]: @[03:01] “오픈 소스는 너무 방대…” [^74]: @[03:01] “오픈 소스는 너무 방대하고 어렵다고요?” [^75]: @[03:04] “팀원들과…” / @[03:08] “장단점… 비교…” [^76]: @[03:08] “다양한 방법… 장단점을… 비교” [^77]: @[03:12] “친구가 없다면 AI를 활용해서…” [^78]: @[03:17] “무조건 좋은 기술은 없습니다.” [^79]: @[03:19] “시간을 소비… 코드의 복잡성…” [^80]: @[03:22] “둘째, 서비스의 장애 회고록 읽기.” [^81]: @[03:22] “장애 회고록” [^82]: @[03:24] “AWS가 장애… 전 세계…” [^83]: @[03:26] “기다리며 새로 고침… 야근” [^84]: @[03:31] “왜… 아무도 분석하지 않습니다.” [^85]: @[03:35] “실전은… 현실 세계에서 작동하는 코드” [^86]: @[03:37] “AWS3가 마비…” [^87]: @[03:42] “오타 하나가 인터넷의 절반을…” [^88]: @[03:44] “상세한 회고록” [^89]: @[03:47] “비밀 교과서” [^90]: @[03:50] “재앙은 늘 사소한 곳에서…” [^91]: @[03:53] “반드시 실수… 의도대로… 예고 없이…” [^92]: @[03:56] “질문을 던져 보세요.” [^93]: @[03:56] “스스로에게 질문” [^94]: @[03:59] “우리 시스템이었다면…” [^95]: @[04:01] “안전 장치가 있는가?” [^96]: @[04:09] “실전 근육으로 단련” [^97]: @[04:13] “결론…” [^98]: @[04:13] “어떻게 만들까… 일순위는…” [^99]: @[04:18] “하나를 얻기 위해… 포기” [^100]: @[04:20] “업로드 속도… 그림과 음성을 포기” [^101]: @[04:22] “정답은 없습니다.” [^102]: @[04:26] “퀄리티… 더 좋았을 수도…” [^103]: @[04:28] “시간과 에너지를 중요한 곳에…” [^104]: @[04:32] “프로젝트… 인생… 포기” [^105]: @[00:42] 정의 / @[04:18] 포기(트레이드오프) / @[03:35] 실전 정의 [^106]: 사용자 제공 메타데이터(제목/채널/길이/링크/키워드) 및 영상 전체 맥락