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

description: |

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

[? 질문] 프론트엔드 vs 백엔드 중 “적성에 맞는 한 분야”만 고집하는 고민은 정말 유의미한가[^2]
[= 답] 본질적으로 경계가 무의미하며, 개발자는 “프론트/백”이 아니라 제품의 문제를 해결하는 사람으로 존재해야 한다.[^3]

[? 질문] 개발자가 진짜로 집중해야 할 대상은 기술 스택(React, API, 인프라 등)인가, 아니면 다른 무엇인가[^4]
[= 답] 기술 자체가 아니라 제품과 사용자이며, 프로그래밍은 문제 해결을 위한 도구일 뿐이다.[^5]

[? 질문] “한 가지만 하기도 벅찬데요”라는 태도는 왜 위험한가[^6]
[= 답] 웹 개발은 결국 하나의 제품을 완성하는 일이고, 제품의 표현·동작·운영(프론트/백/인프라)은 연결되어 있으므로 “안 하겠다”는 태도는 직업적 목적(문제 해결)과 충돌한다.[^7]

2. 큰 그림[^8]

이 콘텐츠는 프론트엔드와 백엔드의 차이를 둘러싼 커뮤니티/회사 내 갈등(“프론트가 적성”, “백이 적성”, “우열”)을 출발점으로, 그 구분이 왜 본질이 아니며 개발자가 무엇에 집중해야 하는지를 설명한다.[^9] 또한 IT가 “누구에게나 쉽다”고 말할 수 있는 이유를 “정답(답)이 문서로 명시되는 분야”라는 관점에서 제시하고, 그 쉬움이 오히려 개발자가 가져야 할 태도(두려움 대신 존경, 제품 중심 사고)로 이어진다고 주장한다.[^10]

• 개발에서 프론트엔드(UI)와 백엔드(API)는 모두 인터페이스이며, 둘 다 “사용자”를 가진다.[^11] 다만 UI는 비개발자까지 훈수/검열이 많고, API는 사용자가 개발자로 한정되어 품질 문제가 방치되기 쉽다는 현실을 지적한다.[^12]
• 개발자는 기술(스택)로 자신을 정의하기보다, 자신이 만드는 제품과 그 제품을 쓰는 사용자의 문제 해결로 자신을 정의해야 한다.[^13]
• 커리어 선택에서도 “이 회사는 React를 써서”가 아니라 “이 회사는 이 도메인의 이 문제를 풀어서”를 기준으로 삼아야 더 좋은 프로그래머/더 높은 시장가치로 이어진다고 말한다.[^14]

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

3.1 커뮤니티에서 반복되는 “프론트 적성/백 적성” 논쟁에 대한 선언[^16]

영상은 개발 커뮤니티나 회사 개발팀에서 흔히 나오는 말, 즉 “저는 프론트가 적성에 맞아요”, “저는 백이 적성에 맞아요” 같은 발화가 지금도 이어지고 있다는 관찰로 시작한다.[^17]
이어 화자는 다소 도발적으로 자신의 결론을 먼저 던진다.

• [c 백과 프론트의 경계는 무의미하다]라는 주장이다.[^18]
• 그리고 “저는 하나만 하기도 벅찬데요”라는 반응이 나오면, 화자는 “죄송하지만 안 하는 게 맞다”라고까지 말한다.[^19]

여기서 화자는 예상 반박을 선제적으로 언급한다.
즉, “백엔드와 프론트엔드가 전문화되어 있는데 그게 무슨 소리냐”라는 항의가 나올 수 있음을 인정하고, “혈압을 부여잡고 조금만 더 들어달라”고 요청한다.[^20]
이 도입부의 기능은 두 가지다.

1. 논쟁의 흔한 프레임(프론트 vs 백)을 ‘일단 내려놓고’ 더 큰 관점으로 보자는 문제 제기[^21]
2. “한 가지만 하겠다”는 태도 자체가 개발자의 목적의식과 연결될 때 어떤 의미인지 뒤에서 해명하겠다는 예고[^22]

3.2 “IT가 누구에게나 쉽다”는 역설: 쉬움/어려움의 기준을 ‘정답의 존재’로 정의[^23]

화자는 자신이 IT 업(일)을 좋아하는 이유가 “역설적으로 누구에게나 쉽기 때문”이라고 말한다.[^24]
다만 이 말이 오해를 부를 수 있기에, 본격적으로 “쉬운 것”을 말하기 전에 “어려운 것”이 무엇인지부터 설명하겠다고 전개한다.[^25]

3.2.1 현실 세계(리얼 월드)의 “어려움”: 정답이 불명확하고, 경로가 분기되며, 성공 확률이 극단적으로 낮음[^26]

화자는 물리학 연구실에 다녔던 친구와 자신(현재 비즈니스를 하는 사람들)을 대비시키며, 현실 세계에는 “노답”인 상황이 정말 많다고 말한다.[^27]
그리고 “300억을 벌고 싶다”는 예시를 든다.[^28]

• [? 지금 300억을 벌고 싶다면, 어떻게 해야 하는지 감이 오냐]는 질문을 던지며, 대부분은 명확한 경로를 떠올리기 어렵다는 점을 암시한다.[^29]
• 화자는 2021년 기사(자료)를 언급하며, 한국에서 약 7000명, 즉 **0.013%**만이 “300억 수준의 무리한(?) 금액을 벌 수 있는 방법을 안다”는 식으로 설명한다.[^30]
• 그리고 그 “방법”도 하나가 아니라 투자/사업/상속 등으로 갈라지는 여러 방법론의 분기가 존재한다고 덧붙인다.[^31]

화자의 결론은 “돈을 버는 것 자체가 정답이 어렵다”는 것이다.[^32]
즉, 현실의 어려움은 ‘노력’의 문제가 아니라, 애초에 정답이 명료하게 주어지지 않거나, 정답이 여러 갈래로 분기하며, 소수만 접근 가능한 암묵지로 남아 있다는 구조적 어려움이라는 맥락이다.[^33]

3.2.2 IT(앱/웹 개발)의 “쉬움”: 답이 문서로 존재하고, 좋은/나쁜 패턴이 명시됨[^34]

반대로 화자는 “나는 애플리케이션을 어떻게 만들어야 되는지 알고 있다”고 말한다.[^35]
더 나아가 “원한다면 현재도 알고 있다”고 하며, 지식이 과거에 머문 게 아니라 지금도 유효하다고 말한다.[^36]

그 근거는 다음처럼 제시된다.

• 웹/앱을 만드는 것은 확실하다.[^37]
• “문서에 다 나와 있다”: 문서가 “이건 해라”, “이건 안 좋은 패턴이다” 같은 형태로 모범 답안/금기 사항을 명시해준다는 것이다.[^38]
• 그래서 [h 답이 있다]고 강조한다.[^39]

이 대목에서 화자가 말하는 ‘쉬움’은 “누구나 금방 한다”가 아니라, 정답 탐색이 가능한 구조(문서/레퍼런스/베스트 프랙티스가 존재)라는 의미로 이해된다.[^40]

[!IMPORTANT] “쉬운 분야”의 정의(영상 맥락) 화자가 말하는 IT의 “쉬움”은 난이도가 낮다는 뜻이 아니라, 정답(또는 좋은 답에 가까운 것)이 공개된 형태로 존재하고 그에 접근할 수 있다는 뜻으로 사용된다.[^41]

3.3 글쓰기(사고력)와 개발의 연결: 질문과 답을 찾는 능력이 목적을 선명하게 만든다[^42]

화자는 이전 영상에서 “글쓰기를 못하는 게 맞다면 개발을 계속하는 것을 생각해보라”고 말한 적이 있다고 상기시킨다.[^43]
그 이유를 여기서 다시 연결한다.

• 결국 우리는 “답을 찾아 나서야” 하기 때문이다.[^44]
• 질문에는 “인생 단위의 큰 질문”도 있고, “작업 단위의 작은 질문”도 있다.[^45]
• 글쓰기를 잘한다는 것은 “이런 답과 질문을 잘 찾는 것”과 연결된다고 말한다.[^46]
• 그렇게 되면 “목적이 흐릿해지지” 않는다고 덧붙인다.[^47]

여기서 글쓰기는 단순한 문장력 문제가 아니라, **문제를 정의하고(질문), 해결안을 도출(답)**하는 사고 과정의 상징으로 기능한다.[^48]
그리고 오늘 영상의 주제(프론트/백 논쟁)는 결국 “개발자가 존재하는 목적”을 묻는 문제로 확장된다.[^49]

• 화자는 “오늘은 백엔드와 프론트엔드를 통해서 개발자가 존재하는 목적을 알아보겠다”고 선언한다.[^50]

3.4 기술을 대하는 태도: 존경은 하되 두려움은 갖지 말라 (사람이 만든 것이므로 따라가면 된다)[^51]

화자는 기술에 대해 가져야 할 기본 태도를 제시한다.

• 기술에 대한 존경은 갖되, 두려움은 갖지 말라고 한다.[^52]
• 기술 역시 “사람이 하나하나 만든 것”이므로, 하나하나 차근차근 따라가면 “누구나 다 만들 수 있다”고 말한다.[^53]
• 다만 “시간은 걸릴 수 있다”는 현실적 단서도 붙인다.[^54]

이 파트는 앞의 “IT는 정답이 문서로 존재한다”와 결을 같이 한다.
즉, 기술은 신비한 영역이 아니라 학습 가능한 인공물이며, 겁먹기보다 구조적으로 접근하라는 메시지다.[^55]

3.5 프론트엔드(UI) vs 백엔드(API): 둘 다 인터페이스이며 둘 다 사용자(고객)를 가진다[^56]

화자는 프론트엔드와 백엔드를 가장 단순한 형태로 정의한다.

• 프론트엔드 개발자: UI를 짜는 사람[^57]
• 백엔드 개발자: API를 짜는 사람[^58]

그리고 즉시 결론을 확장한다.

• 둘 다 인터페이스다.[^59]
• 다시 말해 UI와 API는 모두 사용자가 있다.[^60]

여기서 “사용자”는 단지 최종 고객만이 아니라, UI의 사용자는 최종 사용자/비즈니스 구성원일 수 있고, API의 사용자는 다른 개발자(프론트/모바일/외부 파트너)일 수 있다는 맥락으로 읽힌다.[^61]

3.6 현실(리얼 월드)의 비대칭: UI는 모두가 검열하지만, API는 개발자만 보니 망가지기 쉽다[^62]

화자는 UI와 API가 같은 “인터페이스”임에도, 현실에서는 피드백 구조가 다르다고 말한다.

3.6.1 UI는 “모든 이가 사용자”가 될 수 있어 검열/훈수가 과도하다[^63]

• UI는 여러 가지 검열을 받는다.[^64]
• 예로 마케터, 디자이너, 심지어 “회사 로비에 앉아 있는 경비원 아저씨”까지 훈수를 둔다고 말한다.[^65]
• 그 이유를 “모든 이가 사용자가 될 수 있기 때문”이라고 설명한다.[^66]

즉 UI는 눈에 보이고 누구나 체감할 수 있어 의견이 쉽게 붙고, 그 결과 프론트엔드는 외부 피드백에 지속적으로 노출된다는 진술이다.[^67]

3.6.2 API는 사용자가 개발자로 한정되어 품질이 ‘조용히’ 나빠질 수 있다[^68]

• API의 경우는 UI와 다르다: 사용자가 개발자로 한정된다고 말한다.[^69]
• 그리고 이 비대칭이 “뭐가 문제냐”고 묻고는, 노골적인 표현으로 “API는 엉망으로 만들어도 뭐라고 하는 경우가 적다”고 말한다.[^70]

특히 화자는 조직 문화가 더 악화되는 조건을 추가한다.

• 프론트엔드가 백엔드보다 “하등하다”는 식의 위계가 잡힌 곳이라면 문제가 더 심각해진다.[^71]
• 왜냐하면 그때는 API 품질에 대해 “뭐라고 할 수 있는 사람”이 없는 상황까지 생길 수 있기 때문이다.[^72]

이 파트에서 화자는 프론트/백 논쟁이 단지 역할 차이가 아니라, 품질 책임 구조와 조직 내 권력 관계로 이어져 제품 품질을 훼손할 수 있음을 지적한다.[^73]

3.7 프론트/백/인프라 우열을 가르는 현실에 대한 문제 제기: “웹 개발자로 오롯이 존재”해야 한다[^74]

화자는 솔직한 감정으로, IT 기술을 가지고 “백/프론트/인프라의 우열”을 따지는 현실이 아쉽다고 말한다.[^75]
그리고 자신의 정체성 규정을 제안한다.

• [h 웹 개발자라면 웹 개발자로 오롯이 존재해야 한다]고 말한다.[^76]
• “백엔드 개발자”나 “프론트엔드 개발자”로만 나와서는 안 된다고 주장한다.[^77]
• 웹 브라우저 지식부터 인프라 지식까지 알아야 “웹 개발자”라고 할 수 있다고 말한다.[^78]

여기서 화자는 “상황상 자신이 맞는 파트가 있을 수 있다”는 현실도 인정한다.[^79]
즉, 업무 분업/전문화 자체를 부정하기보다, 그것이 정체성의 감옥이나 우열/무시로 변질되는 것을 경계한다.[^80]

• 따라서 “어떤 기술이건 두려움을 가질 필요는 없다”는 태도를 다시 강조한다.[^81]

3.8 다른 파트의 기술을 무시하는 것은 ‘제품’을 무시하는 것: HTML/CSS 하대를 예로 든다[^82]

화자는 “누군가 다른 파트의 기술을 무시한다면 결국 이것을 무시하는 것”이라고 말하며, 그 “이것”이 무엇인지 질문처럼 던진다.[^83]

[? 이게 뭘까요]
[= 제품(그리고 제품이 표현·작동하는 실제 기반)]이라는 방향으로 예시를 통해 답한다.[^84]

구체 사례로, HTML/CSS 지식을 무시하거나 하대하는 백엔드 개발자를 본 적이 있을 것이라고 한다(최소한 인터넷에서라도).[^85]
하지만 화자는 제품이 “표현되는 곳”이 웹이며, 웹은 “HTML 문서에 표현”이라고 말한다.[^86]

• 따라서 HTML을 무시하거나 이해도가 떨어진다는 것은, 자신이 만들고 있는 제품에 대한 이해도가 떨어진다는 뜻이라고 결론낸다.[^87]

이 논리는 “프론트 기술 = 덜 중요” 같은 위계를 반박하는 방식으로 작동한다.
즉, 제품이 사용자에게 도달하는 마지막 표현층(HTML/CSS/UI)을 무시하면 제품 자체를 제대로 이해할 수 없다는 주장이다.[^88]

3.9 기술 기반이 아니라 제품 기반으로 생각하라: “개발자”라는 단어 자체가 문제를 만든다[^89]

화자는 “우리가 말하는 이것은 제품”이라고 못 박는다.[^90]
그리고 사고의 기준을 전환하라고 말한다.

• [c 우리는 기술 기반이 아니라 제품 기반으로 생각해야 한다]는 주장이다.[^91]

이어서 화자는 “개발자”라는 말 자체부터 문제가 있다고 느낀다고 말한다.[^92]
그 이유는 “개발자라는 단어와 인식”이 자꾸 기술과 제품을 떨어뜨려 놓으려 하기 때문이라는 것이다.[^93]

화자는 흔히 있을 법한 태도를 풍자적으로 묘사한다.

• “개발자는 개발을 해주는 것”이고
• “제품이 좋은지 나쁜지는 내 알 바 아니야”
• “당신이 원하는 건 뭐죠?” 같은 식으로, 기술 제공자/하청적 태도로 빠질 위험을 지적한다.[^94]

그리고 시청자에게 연속 질문을 던지며, 무엇을 원하는지 스스로 점검하게 만든다.

• [? 좋은 회사인가요]
• [? 좋은 연봉, 좋은 기술인가요]
• [? 아니면 좋은 제품이 맞나요][^95]

질문의 요지는 커리어 판단 기준이 기술/연봉/브랜드에 치우치지 않았는지, 혹은 제품에 대한 관점이 있는지를 돌아보라는 것이다.[^96]

3.10 “기술에 투자하는 시간만큼 제품에 투자하라”: 사용자 관점과 제품 집착, DDD의 맥락[^97]

화자는 다시 한 번 시청자에게 실질적인 자기 점검 질문을 던진다.

• 기술에 투자하는 시간만큼 제품에 시간을 투자하고 있는가[^98]
• 사용하는 사람의 입장에서 생각하고 있는가[^99]

그리고 외부 근거(사상/방법론)를 연결한다.

• 아마존과 AWS를 만든 창업자(문맥상 제프 베이조스)가 “고객 집착”을 말했다고 언급한다.[^100]
• 또한 **DDD(도메인 주도 개발)**은 해당 소프트웨어를 쓰는 사용자에게 더 집중하기 위한 “몸부림”이라고 설명한다.[^101]

여기서 화자는 DDD를 단순한 설계 기법이 아니라, “사용자/도메인 문제”에 가까이 가기 위한 태도와 연결한다.[^102]

3.11 더 좋은 프로그래머가 되는 길: 기술 스택이 아니라 ‘도메인 선택’으로 커리어를 설계하라[^103]

화자는 “특정 도메인의 전문성을 갖추는 것”이 중요하다고 말하면서, 그것이 단순히 기술만 갈고 닦아서 되는 게 아니라고 주장한다.[^104]
즉, 좋은 프로그래머가 되려면 기술 연마만으로는 부족하고, 문제를 품고 있는 현장(도메인)에 들어가야 한다는 취지다.[^105]

그래서 회사 선택 조언으로 이어진다.

• 더 좋은 프로그래머가 되고 싶다면 회사를 선택할 때 도메인을 신경 써서 선택하라고 말한다.[^106]
• “이 회사는 React를 쓰기 때문에 간다”가 아니라
  “이 회사는 이런 도메인에서 이런 문제를 풀기 때문에 간다”로 바뀌면, 더 넓은 관점에서 자신이 할 수 있는 일을 바라보게 된다고 주장한다.[^107]

또한 화자는 이 관점 전환이 보상(연봉)과도 연결된다고 말한다.

• 이렇게 되면 “연봉은 신경 쓸 필요조차 없게 된다”[^108]
• “이미 높을 거기 때문”이라고 단언한다.[^109]

이 문맥에서 연봉은 목표라기보다 결과이며, 도메인 문제 해결 역량이 쌓이면 시장가치가 자연히 따라온다는 논리 구조다.[^110]

[!TIP] 회사 선택 질문을 바꾸기 “무슨 프레임워크 쓰나요?”에서 멈추지 말고, “이 제품/도메인에서 어떤 사용자의 어떤 문제를 풀고 있나요?”로 질문을 바꾸라는 메시지다.[^107]

3.12 커리어 불안(프론트로 시작하면 망한다 등)에 대한 반박: 헛소리보다 ‘자기 신뢰’와 문제 해결 태도[^111]

화자는 이 영상을 보는 사람들에게 “자신감을 가졌으면 한다”고 말한다.[^112]
그리고 업계에서 들리는 흔한 겁주기/단정들을 언급한다.

• “프론트엔드로 커리어 시작하면 똥망한다”[^113]
• “백엔드로 확장하기 어렵다”[^114]

이에 대해 화자는 “제발 그런 헛소리를 믿기보다 자신을 믿으라”고 말한다.[^115]

여기서 “자신을 믿는다”는 것이 막연한 낙관이 아니라, 곧바로 특정한 자세로 정의된다.

• [h 진짜 문제가 무엇인지 찾고, 문제를 해결하라는 자신감]이라고 말한다.[^116]

즉, 프론트/백 구분에 대한 불안 대신, 문제를 정의하고 해결하는 능력/태도를 커리어의 중심에 두라는 주문이다.[^117]

3.13 최종 정리: 제품 문제 해결에 집중하면 프론트/백 차이도, 심지어 프로그래밍도 ‘매몰’될 필요가 없다[^118]

화자는 시청자가 이제 “백/프론트 차이에 매몰되지 않고 진짜 봐야 할 것”을 알게 됐다고 말한다.[^119]
그리고 자신의 메시지를 정리한다.

• 기술에 매몰되지 말고, 이 기술이 향하는 곳을 보라고 한다.[^120]
• 보통의 회사라면 대부분 그곳(기술이 향하는 곳)은 “제품”일 것이라고 말한다.[^121]
• 제품의 문제 해결에 집중하는 순간:
  • 백엔드와 프론트엔드의 차이는 물론[^122]
  • 심지어 프로그래밍에도 얽매일 필요가 없다고 말한다.[^123]
• 이유: 프로그래밍은 문제 해결을 위한 “도구”일 뿐이기 때문이다.[^124]

이 결론은 영상 초반의 [c 경계 무의미] 선언을 “제품 중심 문제 해결”이라는 더 상위의 목적론으로 정당화한다.[^125]

3.14 인용으로 마무리: “개발자=코딩하는 사람”이 아니라 “비즈니스 문제 해결자”, 때로는 코딩을 안 하는 게 최선일 수 있다[^126]

화자는 배민에서 CTO에서 CEO가 된 김범준 대표의 말을 인용한다.[^127]

• “개발자라면 스스로를 코딩하는 사람으로 정의하지 않았으면 좋겠다”[^128]
• “결국 우리에게 주어진 비즈니스 문제를 해결하는 사람으로 생각하는 것이 좋겠다”[^129]
• “때로는 문제를 해결하는 가장 좋은 방법이 정책을 바꾸고 프로그래밍을 안 하는 것일 수도 있다”[^130]

이는 영상 전체의 메시지를 한 문장으로 강화한다: 개발의 본질은 코드가 아니라 문제 해결이며, 해결 수단은 반드시 코드일 필요가 없다는 것이다.[^131]

마지막으로 화자는 시청자에게 행동을 권한다.

• 추천 영상 보지 말고 유튜브를 끄고[^132]
• “진지하게 다음에 대해서 글로 써보거나 생각해보라”고 말한다.[^133]
• 주제는:
  • 내가 왜 개발자를 하려는지[^134]
  • 개발자는 애초에 왜 있는지/무슨 직업인지[^135]
• 다음 영상에서는 프로그래밍과 제품, 창업 등에 대해 더 이야기하겠다고 예고하며 마무리한다.[^136]

4. 핵심 통찰[^137]

1. 프론트(UI)와 백(API)은 역할이 달라도 본질적으로 모두 인터페이스이며, 인터페이스는 항상 사용자를 전제한다.[^59]
   • 사용자가 있는 이상 “우열”보다는 “사용자를 위한 품질/명확성”이 평가 기준이어야 한다.[^60]
2. UI는 피드백이 과잉이고 API는 피드백이 부족해 품질이 방치되기 쉽다—조직의 위계가 붙으면 더 악화된다.[^70]
   • 실행: API에도 명확한 사용자 피드백 루프(문서화, 리뷰, 컨슈머 관점 테스트)를 강제로 만들어야 한다.[^72]
3. 기술은 두려움의 대상이 아니라, 사람이 만든 학습 가능한 도구다. 시간은 걸리지만 따라가면 누구나 만들 수 있다.[^53]
   • 실행: “나는 프론트 체질/백 체질” 같은 정체성 고정 대신, 제품 문제 해결에 필요한 기술을 단계적으로 확장한다.[^54]
4. “HTML/CSS 같은 표현 계층을 무시”하는 태도는 기술 취향 문제가 아니라 제품 이해도 결핍의 신호가 될 수 있다.[^87]
5. 개발자의 정체성은 기술 스택이 아니라 제품 기반이어야 한다.[^91]
   • 실행:
     • 기술 학습 시간만큼 제품/사용자 학습 시간(도메인 지식, 사용자 여정, 고객 불만)을 확보한다.[^98]
6. 커리어 선택 기준을 “React를 써서”에서 “이 도메인의 이 문제를 풀어서”로 바꾸면 관점과 시장가치가 넓어진다.[^107]
   • 실행: 이직/입사 검토 시 “도메인 문제와 사용자”를 먼저 질문하고, 기술은 그 다음에 본다.[^106]
7. 프로그래밍은 목적이 아니라 도구다. 때로는 정책 변경처럼 “코딩을 안 하는 것”이 최선의 해결책일 수 있다.[^130]

5. 헷갈리는 용어 정리[^138]

프론트엔드(UI): 사용자가 직접 보는 화면/상호작용을 구성하는 인터페이스를 만드는 영역으로, 영상에서는 “UI를 짠다”고 표현된다.[^57]
백엔드(API): 프론트/앱 등이 호출하는 기능과 데이터 접근을 제공하는 인터페이스를 만드는 영역으로, 영상에서는 “API를 짠다”고 표현된다.[^58]
인터페이스: 사용자(사람이든 다른 프로그램이든)가 시스템을 사용하는 접점. 영상에서는 UI와 API를 모두 인터페이스로 규정한다.[^59]
DDD(도메인 주도 개발): “해당 소프트웨어를 쓰는 사용자에게 더 집중하기 위한 몸부림”으로 언급되며, 도메인(문제 영역) 중심으로 개발을 정렬하려는 접근을 가리킨다.[^101]

---

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

• 제목: 프론트엔드와 백엔드의 차이로 고민하고 계시다면 | 개발자가 진짜로 집중해야할 것[^140]
• 채널: 점선잇기[^140]
• 길이: 7분 4초[^140]
• 링크: https://www.youtube.com/watch?v=UY_kBW8NrPM[^140]

[^1]: @[00:00]~@[07:03] 영상 전체 내용. [^2]: @[00:00] “저는 프론트가 적성에 맞아요…(중략)…이런 얘기들이 이어지고 있습니다.” [^3]: @[00:14] “백과 프론트에 경계가 무의미합니다.” / @[06:06]~@[06:18] 제품 문제 해결에 집중하면 차이에 얽매일 필요가 없고 프로그래밍은 도구라는 결론. [^4]: @[04:26]~@[04:37] “좋은 회사…좋은 연봉 좋은 기술…아니면 좋은 제품” / @[05:59]~@[06:06] “기술에 매몰되지 않고…그곳은 제품”. [^5]: @[06:14] “프로그래밍은 문제 해결을 위한 도구 뿐이에요.” / @[06:22]~@[06:27] 코딩하는 사람으로 정의하지 말라는 인용. [^6]: @[00:16] “저는 하나만 하기도 벅찬데요.” [^7]: @[00:19] “안 하는게 맞습니다.” / @[03:21]~@[03:32] 웹 개발자는 브라우저부터 인프라까지 알아야 한다는 주장. [^8]: @[00:12]~@[06:59] 영상 전개(주제 소개부터 정리까지). [^9]: @[00:00]~@[00:26] 커뮤니티 논쟁 언급 및 반박 예고. [^10]: @[00:30]~@[01:44] IT가 쉬운 이유(문서/정답) / @[02:15]~@[02:28] 기술을 두려워 말라는 태도. [^11]: @[02:28]~@[02:35] “프론트엔드 개발자는 UI…백엔드 개발자는 API…둘 다 인터페이스.” [^12]: @[02:38]~@[03:07] UI는 검열 많고 API는 개발자만 사용자라 품질 방치 가능. [^13]: @[04:07]~@[04:13] “우리는…제품 기반으로 생각해야 합니다.” / @[04:37]~@[04:45] 사용자 입장 질문. [^14]: @[05:02]~@[05:21] 도메인 기반 회사 선택 조언. [^15]: @[00:00]~@[07:03] 시간 흐름에 따른 재구성. [^16]: @[00:00]~@[00:30] 도입부. [^17]: @[00:00]~@[00:07] “프론트…백…적성” 발화들. [^18]: @[00:14] “경계가 무의미합니다.” [^19]: @[00:16]~@[00:19] “하나만 하기도 벅찬데…안 하는게 맞습니다.” [^20]: @[00:22]~@[00:26] “전문화…무슨 소리…좀만 더 들어주시면…” [^21]: @[00:12]~@[00:16] 감히 말하겠다는 선언과 경계 무의미 주장. [^22]: @[00:16]~@[00:19] “벅차면 안 하는 게 맞다”로 태도 문제를 건드림. [^23]: @[00:30]~@[01:44] 쉬움/어려움 프레이밍. [^24]: @[00:30] “IT업을 좋아하는 이유…누구에게나 쉽기 때문.” [^25]: @[00:40]~@[00:44] 쉬움 전에 어려움부터 말하겠다는 전개. [^26]: @[00:44]~@[01:24] 현실 세계 예시(300억) 및 통계. [^27]: @[00:44]~@[00:53] 물리학 연구실 친구, 리얼 월드 노답 상황. [^28]: @[00:55] “당신이 지금 300억을 벌고 싶어요.” [^29]: @[00:58] “그러면 어떻게 해야 되는지 감이 오세요.” [^30]: @[01:01]~@[01:15] “2021년도 기사…7000명…0.013%…300억…” [^31]: @[01:15]~@[01:19] 투자/사업/상속 등 방법론 분기. [^32]: @[01:19]~@[01:24] “정답이 어렵다.” [^33]: @[01:07]~@[01:19] 소수만 아는 구조와 분기 언급. [^34]: @[01:24]~@[01:44] 앱/웹 개발은 확실, 문서에 답. [^35]: @[01:24] “저는…어떻게 만들어야 되는지 알고 있습니다.” [^36]: @[01:28] “또 그걸 원한다면 현재도 알고 있어요.” [^37]: @[01:34]~@[01:35] “웹이나 앱을 만드는 건 확실…” [^38]: @[01:35]~@[01:43] “문서에 다 나와…해라/안 좋은 패턴…명시” [^39]: @[01:43]~@[01:44] “답이 있습니다.” [^40]: @[01:35]~@[01:44] 문서 기반 정답 가능성 강조. [^41]: @[01:35]~@[01:44] “문서…명시…답이 있다”라는 흐름. [^42]: @[01:47]~@[02:09] 글쓰기와 질문/답. [^43]: @[01:47]~@[01:53] 이전 영상 언급. [^44]: @[01:53]~@[01:56] “결국 우리는 답을 찾아…” [^45]: @[01:56]~@[02:02] 큰 질문/작은 질문. [^46]: @[02:02]~@[02:07] “글쓰기를 잘한다…답과 질문을 잘 찾는다” [^47]: @[02:07]~@[02:09] “목적이 흐릿해지질 않겠죠” [^48]: @[01:53]~@[02:09] 답/질문 찾기=사고/정의 능력 프레이밍. [^49]: @[02:09]~@[02:15] “개발자가 존재하는 목적” [^50]: @[02:09]~@[02:15] “오늘은…목적…알아보도록” [^51]: @[02:15]~@[02:28] 기술 태도. [^52]: @[02:15] “존경…두려움 갖지…” [^53]: @[02:18]~@[02:22] “기술 역시 사람이…차근차근…누구나” [^54]: @[02:26] “물론 시간은 걸릴 수…” [^55]: @[02:15]~@[02:28] 사람/학습 가능성 강조. [^56]: @[02:28]~@[02:38] UI/API=인터페이스, 사용자 존재. [^57]: @[02:28]~@[02:31] “프론트엔드…UI를…” [^58]: @[02:31]~@[02:33] “백엔드…API…” [^59]: @[02:33]~@[02:35] “둘 다 인터페이스” [^60]: @[02:35]~@[02:38] “ui와 api는 모두 사용자가 있습니다” [^61]: @[02:35]~@[02:53] 사용자 범위 대비(모두 vs 개발자 한정). [^62]: @[02:38]~@[03:07] UI 검열 vs API 방치. [^63]: @[02:38]~@[02:49] UI 검열 이유. [^64]: @[02:38]~@[02:41] “ui는 여러가지 검열” [^65]: @[02:41]~@[02:44] 마케터/디자이너/경비원 아저씨 비유. [^66]: @[02:44] “모든 이가 사용자가 될 수…” [^67]: @[02:38]~@[02:49] UI 특성 설명. [^68]: @[02:49]~@[03:07] API 특성 및 문제. [^69]: @[02:49]~@[02:53] “api…사용자가 개발자로 한정” [^70]: @[02:55]~@[02:58] “api는 … 만들어도 뭐라고…적습니다” [^71]: @[02:58]~@[03:02] “프론트엔드가 백보다 하등…” [^72]: @[03:02]~@[03:07] “아무도 뭐라고 할 수 없는 상황” [^73]: @[02:49]~@[03:07] 피드백 구조+위계의 결합 문제. [^74]: @[03:11]~@[03:32] 우열 비판 및 웹 개발자 정체성. [^75]: @[03:11]~@[03:21] “우열…아쉬움” [^76]: @[03:21]~@[03:24] “웹 개발자라면…존재” [^77]: @[03:24]~@[03:27] “백/프론트 개발자로 나와서는…” [^78]: @[03:27]~@[03:32] 브라우저~인프라 지식. [^79]: @[03:32]~@[03:36] “상황상…맞는 파트” [^80]: @[03:21]~@[03:36] 분업 인정+정체성 경계. [^81]: @[03:36]~@[03:39] “두려움…필요” [^82]: @[03:39]~@[04:07] 무시=제품 무시 논리와 HTML 예시. [^83]: @[03:39]~@[03:46] “무시한다면…이것…이게 뭘까요” [^84]: @[03:55]~@[04:07] 웹=HTML 문서 표현, HTML 무시=제품 이해도 낮음. [^85]: @[03:46]~@[03:55] HTML/CSS 무시하는 백엔드 개발자 언급. [^86]: @[03:55]~@[04:00] “제품이 표현되는 곳은 웹…웹은 html 문서” [^87]: @[04:00]~@[04:07] “html 무시…제품 이해도 떨어짐” [^88]: @[03:55]~@[04:07] 표현층 경시 비판의 결론. [^89]: @[04:07]~@[04:26] 제품 기반 사고 및 ‘개발자’ 용어 비판. [^90]: @[04:07] “우리가 말하는 이것은 제품” [^91]: @[04:10]~@[04:13] “기술 기반 아니라 제품 기반” [^92]: @[04:13]~@[04:18] “개발자란 말 자체부터 문제” [^93]: @[04:18]~@[04:22] 기술과 제품을 떨어뜨리는 인식. [^94]: @[04:22]~@[04:26] “내 알 바 아니야…당신이 원하는 건…” [^95]: @[04:26]~@[04:37] 좋은 회사/연봉/기술/제품 질문. [^96]: @[04:26]~@[04:37] 연속 질문을 통한 기준 점검. [^97]: @[04:37]~@[05:02] 사용자 관점, 고객 집착, DDD. [^98]: @[04:37]~@[04:41] “기술…시간만큼 제품…” [^99]: @[04:41]~@[04:45] “사용하는 사람 입장” [^100]: @[04:45]~@[04:50] “아마존과 aws…고객 집착” [^101]: @[04:50]~@[04:57] “DDD…사용자에게 더 집중” [^102]: @[04:50]~@[04:57] DDD의 목적을 사용자 집중으로 설명. [^103]: @[04:57]~@[05:23] 도메인 선택과 커리어/연봉. [^104]: @[04:57]~@[05:02] “도메인 전문성…기술 갈고 닦는 것(만) 성취…” [^105]: @[04:57]~@[05:02] 도메인 전문성의 중요성 주장. [^106]: @[05:02]~@[05:06] “회사를 선택할 때 도메인…” [^107]: @[05:06]~@[05:21] React가 아니라 도메인 문제로 선택. [^108]: @[05:21]~@[05:23] “연봉은 신경 쓸 필요조차…” [^109]: @[05:23] “이미 높을 거기 때문” [^110]: @[05:02]~@[05:23] 도메인 관점→가치 상승 논리 흐름. [^111]: @[05:27]~@[05:52] 자신감/헛소리 반박/문제 해결 태도. [^112]: @[05:27]~@[05:31] “자신감을…” [^113]: @[05:31]~@[05:36] “프론트로 시작하면 똥망…” [^114]: @[05:31]~@[05:36] “백으로 확장 어렵다” [^115]: @[05:36]~@[05:42] “헛소리 믿기보다 자신을…” [^116]: @[05:42]~@[05:48] “진짜 문제…찾고…해결…” [^117]: @[05:44]~@[05:52] 매몰 탈피의 기준을 문제 해결로 제시. [^118]: @[05:52]~@[06:18] 정리 파트. [^119]: @[05:48]~@[05:52] “진짜 봐야 할 것…알게…” [^120]: @[05:59]~@[06:03] “기술에 매몰되지…” [^121]: @[06:03]~@[06:06] “대부분…제품” [^122]: @[06:06]~@[06:10] “백/프론트 차이는…” [^123]: @[06:10]~@[06:14] “심지어 프로그래밍에도…” [^124]: @[06:14]~@[06:18] “프로그래밍은…도구” [^125]: @[00:14]~@[00:19] 경계 무의미 선언이 @[06:06]~@[06:18] 제품 중심 결론으로 회수됨. [^126]: @[06:18]~@[06:48] 김범준 대표 인용 및 시청자 행동 촉구. [^127]: @[06:18]~@[06:22] “배민…cto에서 ceo…” [^128]: @[06:22]~@[06:27] “코딩하는 사람으로 정의…” [^129]: @[06:27]~@[06:31] “비즈니스 문제를 해결…” [^130]: @[06:31]~@[06:37] “정책 바꾸고…안 하는 것” [^131]: @[06:22]~@[06:37] 문제 해결자 정체성 강화. [^132]: @[06:37]~@[06:41] “추천 영상 보기보단 유튜브를 끄고” [^133]: @[06:41]~@[06:48] “글로 한번 써보거나 생각…” [^134]: @[06:48]~@[06:53] “왜 개발자를 하려는지” [^135]: @[06:48]~@[06:59] “개발자는 애초에 왜 있는지…” [^136]: @[06:59]~@[07:03] 다음 주제 예고 및 마무리. [^137]: @[02:28]~@[06:37] 주장들을 관통해 재구성. [^138]: @[02:28]~@[04:57] 용어가 직접 언급/정의되는 구간 기반. [^139]: 사용자 제공 메타데이터(제목/채널/길이/링크) + 영상 전반. [^140]: 사용자 메시지에 포함된 콘텐츠 정보(제목, 채널, 길이, 링크).