https://www.youtube.com/watch?v=7T9bj5XW7ks
description: |-
1. 이건 꼭 알아야 한다^1
[? 질문] 개발자 지망생이 포트폴리오를 준비할 때, 채용/외주/SI 관점에서 “보자마자 1초 컷”이 나지 않으려면 무엇을 갖춰야 하는가^2
[= 답] 포트폴리오는 단순 기능 나열이 아니라 (1) 아키텍처 이해를 전제로, (2) 한 분야에 “미쳐본” 덕후력(깊이), (3) 사용자가 이상하게 쓸 때까지 상정한 **예외처리·디테일(품질)**을 증명해야 하며, 이 3가지는 결국 “좋은 서비스를 만들 정신(소양)”을 보여주는 장치다.[^3]
[? 질문] 면접관/대표는 포트폴리오의 무엇을 보고 실제 질문을 던지는가[^4]
[= 답] 프론트는 브라우저 렌더링 가정/앱 생명주기, 백엔드는 사용자→서버까지 API 연결 흐름, 정적·동적 서버 구분, 더 나아가 통신 원론(소켓 통신 등) 차이 같은 “구조적 이해”를 확인하는 질문을 먼저 던진다.[^5]
[? 질문] “기본”처럼 보이는 것들이 왜 실제 채용에서 강력한 차별점이 되는가[^6]
[= 답] 많은 지원자들이 기본(아키텍처/디테일/예외처리/사용자 경험)을 놓치기 때문에, 기본만 지켜도 채용자 입장에선 “기본을 했고 거기에 플러스까지 했다”로 보이며 결과적으로 더 사랑스럽고 매력적인 지원자로 평가된다.[^7]
2. 큰 그림[^8]
이 콘텐츠는 개발자 지망생들이 가장 자주 묻는 “포트폴리오를 어떻게 준비해야 하는가”에 대해, 외주·SI 및 채용(면접) 실무자 시각에서 포트폴리오를 평가하는 기준을 4가지 원칙(실질적으로 3가지 핵심 원칙 + ‘그 원칙을 잊지 말라’)로 풀어 설명한다.[^9] 영상은 실제로 포트폴리오를 검토하고 면접 질문을 던지는 방식, 그리고 “이런 흔적이 남아 있으면 바로 뽑고 싶어진다”는 사례를 통해, 무엇이 1초 컷을 만들고 무엇이 합격 가능성을 올리는지 구체적으로 보여준다.[^10]
- 핵심 메시지 1: 아키텍처 이해가 없으면 포트폴리오를 “아예 보지 않는다”는 수준으로 중요하다.[^11] 따라서 구조를 설명하고 질의응답이 가능해야 한다.[^12]
- 핵심 메시지 2: 얕고 넓은 나열보다, 한 분야에 깊게 파고든 **개발 덕후력(탐구의 깊이)**이 포트폴리오에서 강하게 드러나면 팀이 감탄할 정도의 임팩트를 만든다.[^13]
- 핵심 메시지 3: 기능 구현을 넘어 예외처리·디테일·UX 품질을 고민한 흔적(로그인 가드, 이미지 로딩 부드러움, 인터랙션 전환 등)이 “서비스 만들 준비가 된 사람”으로 보이게 만든다.[^14]
3. 하나씩 살펴보기[^15]
3.1 오프닝: “정보 없이 마이페이지만 뿅” 나오면 면접 분위기가 이상해진다[^16]
영상은 특정 상황을 던지며 시작한다. 포트폴리오/서비스에서 아무런 정보도 없이 마이 페이지가 ‘뿅’ 하고 노출되는 식의 허술한 흐름을 보면, 검토자 입장에서 “순간 바로 면접 분위기가 이상해진다”는 뉘앙스로 문제를 제기한다.[^17] 즉, 사용자가 기대하는 기본 안전장치(로그인 필요 페이지의 접근 제어 등)조차 고려하지 않은 결과물이 “1초 컷”에 가깝게 작용할 수 있음을 암시하며 서두를 연다.[^18]
이어서 진행자는 본인을 소개하고(미스터 디벨로), 최근 개발자 지망생들과 함께한 자리에서 공통 질문이 있었다고 말한다.[^19] 그리고 그 질문이 무엇이었는지 맞춰보게 하는데, 답은 “포트폴리오를 어떻게 준비하면 되는지”였다.[^20] 진행자는 현장에서 설명하려다 본인도 가물가물해서 포기했다고 말하며, 오늘 영상에서 그 질문들을 바탕으로 “미스터 디벨로(팀/대표)가 어떤 시각으로 포트폴리오를 보는지”를 정리하겠다고 예고한다.[^21] 또한 “뼈가 되고 살이 되는 정보”를 가져왔다며 집중을 요청한다.[^22]
3.2 원칙 1: 아키텍처 이해 — 없으면 아예 보지도 않는다[^23]
본격적으로 “대표님이 면접과 포트폴리오 검토를 어떤 시각으로 하느냐”를 묻고, 큰 틀에서 네 가지 원칙으로 포트폴리오를 본다고 말한다.[^24] 그중 첫 번째 원칙은 매우 단호하다.
- [c 포트폴리오에서 프로젝트 아키텍처를 얼마나 이해했는지가 1번이며, 아키텍처가 없으면 아예 보지도 않는다][^25]
여기서 “아키텍처를 본다”는 표현이 추상적일 수 있으니, 진행자가 “아키텍처 보고 어떤 식으로 질문하는지 팁”을 요청한다.[^26]
3.2.1 프론트엔드에 던지는 대표 질문들: 렌더링 가정, 앱이면 생명주기[^27]
대표는 프론트와 백엔드를 나누어, 프론트엔드의 경우 가장 처음 물어보는 질문이 있다고 말한다.[^28] 핵심은 “브라우저가 렌더링할 때 어떤 가정으로 되는지”를 묻는 것이다.[^29] 즉, 화면이 그려지는 과정/원리를 어느 정도 설명할 수 있는지로 기본기를 확인한다는 흐름이다.[^30]
또한 포트폴리오가 웹이 아니라 앱(예: 모바일 앱)이라면, **생명 주기(lifecycle)**를 어떻게 이용했는지 묻는 식으로 질문을 바꾼다고 한다.[^31]
정리하면, 프론트 포트폴리오에서 단순히 UI가 존재하는지가 아니라:
- 브라우저 렌더링 관련 기본 이해[^32]
- 앱이라면 생명주기 기반 설계/구현 흔적[^33]
을 말로 풀어낼 수 있는지 확인한다는 뜻이다.[^34]
3.2.2 백엔드에 던지는 대표 질문들: 사용자→서버 API 흐름, 정적/동적 서버, 통신 원론(소켓 포함)[^35]
백엔드의 경우, 대표는 API 연결할 때 이용자부터 서버까지 어떤 순서로 연결되는지를 묻는다고 한다.[^36] 즉 “요청이 어디서 시작해서 어떤 컴포넌트를 거쳐 처리·응답되는지”의 흐름을 설명할 수 있는지 확인하는 질문이다.[^37]
그 다음으로는 정적 서버가 무엇인지, 동적 서버가 무엇인지를 물으며 서버 개념을 점검한다.[^38]
더 어렵게는 통신에 대해 “원론적인 질문”을 던지고, 소켓 통신과의 차이를 묻는다고 말한다.[^39] 이는 단순 구현 경험이 아니라, 통신 방식의 개념적 차이를 이해하고 있는지 확인하려는 의도다.[^40]
[!TIP] 원칙 1을 포트폴리오에 녹이는 방향(영상이 암시하는 정답) “이걸 만들었습니다”가 아니라, 렌더링/생명주기/요청-응답 흐름/정적-동적/통신 방식을 내 프로젝트 구조에 연결해 설명할 수 있도록 준비하라는 의미다.[^41]
3.2.3 이 질문들에 답하면 어느 정도로 “좋게” 보이나: 300명 중 5%[^42]
진행자는 “지금 개발 지식이 와다다 나왔다”며, 시청자에게 메모하라는 식으로 반응한다.[^43] 그리고 “이 질문에 대답할 수 있으면 어떻게 좋게 보냐”고 묻는다.[^44] 대표는 “거의 7부 능선 넘었다고 봐야 된다”고 표현한다.[^45]
이어서 실제 수치를 제시한다. 최근 백엔드 개발자를 뽑았는데 지원자 300명 중 5% 정도만 답변했던 것 같다고 말한다.[^46] 즉, 이 정도 질문에 답할 수 있는 사람 자체가 많지 않으며, 답변 가능하면 상위권으로 보인다는 맥락이다.[^47] 진행자는 “이해한 것만 잘 녹여서 면접에서만 잘 말해도 충분히 좋은 결과를 얻을 수 있겠다”고 정리하고, 대표도 동의한다.[^48] 마지막으로 대표는 다시 한 번 못 박는다.
- [c 아키텍처는 진짜 필수다][^49]
3.3 원칙 2: “개발 덕후력” — 넓고 얕게보다 한 분야에 미쳐본 깊이[^50]
두 번째 원칙으로 대표는 “포트폴리오에서 얼마나 개발 덕후의 한계가 나는가”를 본다고 한다.[^51] 이전 영상에서도 “개발 덕후”를 언급했으며, 덕후는 서로를 알아본다는 표현으로, 포트폴리오에서 덕후의 피지컬(실력·집착·탐구 흔적)이 확실히 드러난다고 설명한다.[^52]
3.3.1 팀이 감탄한 포트폴리오 사례: 디자인 요소 없이 텍스트/코드, 대신 소켓 통신에 “미쳐있던” 사람[^53]
대표는 실제로 팀원들과 함께 본 포트폴리오에서 “와 진짜 뭐고 이거, 장난 아니다”라는 감탄이 나왔던 경험을 말한다.[^54] 흥미로운 점은 그 포트폴리오가 “텍스트랑 코드만” 있고 디자인 요소는 거의 없었다는 것이다.[^55] 그럼에도 불구하고 인상적이었던 이유는, 그 사람이 백엔드의 소켓 통신에 너무 심취해 있었기 때문이다.[^56] 대표는 이를 “그때 미쳐 있는 거죠”라고 표현한다.[^57]
그 포트폴리오는 소켓 통신 기반으로 3개가 있었고, 소켓으로 할 수 있는 다양한 형태를 구현했다.[^58]
- 1대1 세팅[^59]
- 1대다(다수) 세팅[^60]
- 실시간 이미지 전송[^61]
- 캐치마인드처럼 선을 그리면 그 선이 바로 상대방에게 보이는 기능(실시간 드로잉 동기화)[^62]
대표와 진행자는 “신입이라는 가정 하에 이 정도는 거의 없다고 봐도 무방”하다고 말하며, 본인들도 신입 때는 이런 수준까지 생각하지 못했다고 인정한다.[^63] 즉, “깊게 파고든 결과물”은 신입 포트폴리오에서 희소하고, 그래서 더 강하게 차별화된다는 논리다.[^64]
+++ 상세 예시: 왜 ‘캐치마인드처럼 선이 실시간으로 보이는 기능’이 덕후력의 증거가 되는가(영상의 맥락 재구성) 이 기능은 단순 채팅처럼 텍스트만 전송하는 수준을 넘어, 사용자의 입력(좌표, 선 굵기/색, 드로잉 이벤트)을 실시간 이벤트 스트림으로 상대에게 전송하고, 상대 화면에서 같은 타이밍에 렌더링해야 성립한다.[^65] 즉, 소켓 통신을 “써봤다”가 아니라, 소켓이 필요한 문제(낮은 지연, 지속 연결, 이벤트 동기화)에 맞춰 기능을 끝까지 밀어붙인 흔적이 된다.[^66] +++
3.3.2 더 놀란 포인트: AWS 임대 대신 ‘안드로이드 공기계’로 서버를 만든 발상[^67]
대표는 또 하나 “따로 놀랐던 것”을 말한다.[^68] 보통 신입들은 마지막 단계에서 AWS 같은 서버를 임대해서 쓰는데, 그 지원자는 안드로이드 공기계에 서버를 만들었다는 것이다.[^69] 대표는 “발상 자체가 너무 독특”하고 “덕후 아니면 할 수 없다”, “이 사람 뽑아야겠다”는 생각이 들었다고 말한다.[^70]
즉, 덕후력은 단지 기술 스택이 많아서가 아니라, 문제를 풀기 위해 비정형적인 방법까지 시도하는 집요함/호기심/실행력으로 드러난다는 메시지다.[^71]
3.3.3 회사가 선호하는 개발자상: 넓고 얕게보다 “한 가지 분야에 미친” 사람[^72]
대표는 개발 덕후를 신입에서 보기 힘든데, 지원자가 “어마어마한 덕력”을 가진 경우 얼마나 큰 메리트인지 강조한다.[^73] 그리고 회사가 지향하는 바를 명확히 말한다.
- [h 넓고 얕은 지식보다, 특히 개발자라면 한 가지 분야에 미쳐서 깊게 판 개발자를 선호한다][^74]
그 이유로, 그런 개발자들이 다른 걸 하게 되거나 다른 언어를 하게 될 때 “훨씬 더 포텐이 터진다”는 믿음을 제시한다.[^75] 즉, 깊이를 만든 사람이 확장도 잘한다는 인재관이다.[^76]
따라서 시청자에게도 “코딩을 좋아한다면 특정 분야를 덕질한 뒤 피지컬을 표현할 수 있는 포트폴리오를 만들어 지원하면, 통찰력 있는 대표라면 바로 알아본다”고 조언한다.[^77]
3.4 원칙 3: 예외처리/디테일 — 사용자는 의도대로 쓰지 않는다[^78]
여기서 화자가 바뀌며(인사 담당자 관점), 포트폴리오에서 보는 요소로 “본인이 한 프로젝트에서 어느 정도 예외처리를 했는가”를 말한다.[^79] 예외처리를 모르는 사람을 위해 아주 일상적인 서비스 사례를 들어 설명한다.[^80]
3.4.1 무신사 마이페이지 예시: 로그인 없이 링크를 때리면 어떻게 되나[^81]
쇼핑몰 서비스(무신사)를 예로 든다. 마이페이지에 접근하려면 당연히 로그인이 필요하며, 그래야 구매한 옷과 배송 정보를 확인할 수 있다.[^82]
그럼 여기서 질문을 던진다.
[? 로그인하지 않고 무신사 마이페이지 링크를 직접 때리고 들어가면 어떻게 될까][^83]
[= 로그인하라는 알림 메시지가 뜨고 로그인 창으로 넘어가야 한다][^84]
이 흐름은 “당연한 서비스”지만, 사이드 프로젝트를 하는 사람들 중에는 이 당연함을 놓치는 경우가 있다는 것이다.[^85] 그래서 면접/검토 상황에서 “마이페이지를 로그인 없이 들어가 봐라”라고 시켜보면, 생각이 있는 사람 vs 없는 사람이 명확히 갈린다고 말한다.[^86]
- 생각이 있는 사람: 로그인 상태가 아니면 무신사처럼 로그인 페이지로 이동시키는 로직이 있다.[^87]
- 생각이 없는 사람: 아무 정보도 없이 마이 페이지만 뿅 하고 나온다.[^88]
그리고 이런 경우 검토자 입장에선 “면접 분위기가 이상해진다”는 표현으로, 신뢰가 흔들리는 순간이 생긴다고 설명한다.[^89]
[!IMPORTANT] 원칙 3의 본질(영상의 핵심 문장) 사용자는 우리가 의도한 대로 절대로 서비스를 쓰지 않기 때문에, 사용자가 어떻게 “이상하게” 쓸지를 고민하며 만든 흔적(디테일/예외처리)이 남아 있으면 좋은 평가를 받는다.[^90]
3.4.2 “최근에 디테일 신경 쓰는 프론트 개발자” 채용 사례: 이미지 로딩 UX를 끝까지 다듬음[^91]
대화는 “최근에 디테일을 굉장히 신경 쓰는 분을 모셔왔다”는 이야기로 이어진다.[^92] 최근 프론트 개발자를 뽑았는데, 이 사람이 예외처리/디테일에서 “덕후 중 덕후”였다고 평가한다.[^93]
그 사람이 집중했던 문제는 사이트 구동 중 이미지가 늦게 보이는 현상이었다.[^94] 일반적으로는 파일 사이즈를 줄이는 정도로 끝날 수 있는데, 이 지원자는 다른 접근을 했다.[^95]
구체적으로:
- 이미지 확장자를 **png에서 웹용 확장자(‘웹 확장자’로 표현)**로 바꿔서 서버에 올렸다.[^96]
- 서버에서 불러올 때도 “바로 불러오기”가 아니라, 틱틱거리지 않게(끊김/버벅임 완화) 하는 어떤 기능/기법을 써서 더 부드럽게 이미지가 나오게 했다.[^97]
여기서 중요한 포인트는 “이미지 한두 개일 때는 작은 차이”지만, 페이지가 넘어갈 때마다 부드럽게 넘어가는 경험이 누적되면 유저는 서비스를 “편안하게” 받아들이고 “잘 만들었다”고 느낀다는 것이다.[^98] 즉, 디테일은 체감 품질을 크게 바꾼다.[^99]
화자는 이를 “자그만하지만 서비스가 주는 질은 0에서 100 차이처럼 어마어마하게 날 수 있다”고 표현한다.[^100]
3.4.3 인터랙션 디테일(쓱싹샥): 버튼/전환이 딸깍이냐, iOS처럼 부드럽냐[^101]
대표가 좋아하는 포인트로 “쓱싹 샥”을 언급하며, 버튼이 눌릴 때/꺼질 때, 화면 전환이 부드럽게 이어지는 것을 예로 든다.[^102]
프론트 개발자 포트폴리오를 볼 때, 웹 화면이 “딸깍” 나오게 만드는 사람이 많고, 그런 사람이 80%가 넘는다고 말한다.[^103] 반면 20% 정도는 iOS에서 화면이 넘어가듯 부드러운 방식으로 배경/이미지 처리를 하는 사람이 있다고 한다.[^104]
그리고 결론은 다음과 같다.
- 그런 20%는 “진짜 서비스를 만들 준비가 된 분들”이다.[^105]
- 단순 기능 구현이 아니라, 사용자가 볼 때 어떤 느낌을 받길 원하는지까지 고려한다.[^106]
- 그래서 회사는 그런 사람들을 적극 채용하려고 한다.[^107]
3.4.4 포트폴리오에 무엇을 담아야 하나: 오류 상황을 상정하고, 해결과정의 사고/근거까지 말로 설명하라[^108]
진행자는 포트폴리오를 만드는 개발자라면:
- 자신의 작품에서 다양한 오류 사항을 생각해보고[^109]
- 그 오류를 어떻게 해결할지 고민하고[^110]
- 실제로 해결하면서 실력이 올라가니, 그 흔적을 포트폴리오에 넣으면 좋다고 말한다.[^111]
이어서 대표는 “해결할 때 어떤 생각을 가지고 했는지, 본인 근거가 확실하고, 그걸 면접에서 잘 얘기하면 면접은 따놓은 당상”이라고 말한다.[^112] 즉, 결과물만 보여주는 것이 아니라 문제-원인-해결-검증의 서사를 말로 방어 가능하게 준비하라는 뜻이다.[^113]
[!TIP] “예외처리/디테일”을 포트폴리오 문서로 바꾸는 방법(영상의 요구사항을 문서화)
- “로그인 없이 접근 시 리다이렉트” 같은 케이스를 재현 단계와 함께 적기
- “이미지 지연 로딩/전환 버벅임” 같은 UX 문제를 측정/체감 포인트로 설명하기
- 해결책을 선택한 근거(왜 png→웹 확장자, 왜 부드럽게 로딩)까지 붙이기
- 면접에서 그 선택을 구두로 방어할 수 있게 정리하기[^114]
3.5 원칙 4(마지막): “첫 번째~세 번째 원칙을 잊지 마라” — 원칙은 특별한 게 아니라 소양이다[^115]
진행자가 “또 있냐”고 묻자, 대표는 “마지막 원칙이 남았다”고 한다.[^116] 그런데 그 마지막 원칙은 조금 특이하게 제시된다.
- “첫 번째, 두 번째, 세 번째 원칙을 잊지 마라.”[^117]
대표는 이것이 특별한 게 아니라며, 투자 대가 워렌 버핏의 예시를 든다.[^118]
- 첫 번째 원칙: 절대로 돈 잃지 마라[^119]
- 두 번째 원칙: 첫 번째 원칙을 잊지 마라[^120]
얼핏 당연한 말처럼 보이지만 “진짜 맞는 말”이라고 강조한다.[^121] 그리고 앞에서 길게 설명한 1~3 원칙은 사실 개발자가 당연히 가져야 할 “소양 같은 일”이라고 정리한다.[^122]
대표가 다시 정리하는 1~3 원칙의 의미는 다음과 같다.[^123]
- 서비스를 만들어내기 위해 시스템 구조를 얼마나 체계적으로 이해하고 있는가[^124]
- 개발자로서 탐구하려는 노력, 계속 공부하려는 의지가 있는가[^125]
- 퀄리티 좋은 서비스를 만들기 위해 노력하고 다른 사람(사용자) 생각을 했는가[^126]
진행자는 “듣고 보니까 결국 포트폴리오도 포트폴리오인데 소양까지 담겨 있다”고 반응하며, 대표의 빌드업을 칭찬한다.[^127]
3.5.1 결론: “좋은 개발자”는 기술만이 아니라 서비스를 만들 정신을 가진 사람[^128]
대표는 “진짜 좋은 개발자를 뽑는 것”은 단순히 “기술만 할 수 있는 개발자”가 아니라, “이런 서비스를 만들 정신이 있는 개발자”가 가장 중요하다고 말한다.[^129] 그리고 “개발이 다가 아니다”라는 문장을 명언처럼 주고받는다.[^130]
마지막으로 오늘 소개한 원칙들을 마음에 두고 개발 공부와 포트폴리오를 준비하면 “차별점 있는 포트폴리오”를 만들 수 있다고 격려한다.[^131]
또한 “오늘 얘기가 기본 같아서 당연히 아는 거 아니냐”라고 느낄 수 있지만, 뽑는 입장에서는 이 기본만 지켜도 “기본을 했는데 플러스까지 조금만 더 했어?”처럼 보여서 훨씬 예뻐 보인다고 말한다.[^132] 즉, 기본의 충족 자체가 희소한 현실을 전제한다.[^133]
영상은 “포트폴리오를 어떻게 만들어야 하는지 알아봤다”로 마무리하며, 좋아요/구독 요청과 함께 개발·AI 관련 질문을 댓글로 남기면 자세히 답변하겠다고 안내한다.[^134]
4. 핵심 통찰[^135]
- [c 포트폴리오에서 ‘아키텍처 부재’는 검토 대상에서 탈락할 수 있는 수준의 치명적 결함으로 취급된다][^136]
- 실행: 프로젝트 소개에 구조/흐름(프론트 렌더링 가정, 백엔드 요청 흐름, 통신 방식)을 반드시 포함하고 면접에서 말로 설명 가능하게 준비한다.[^137]
- [h “넓고 얕은 나열”보다 “한 분야에 미친 깊이(덕후력)”가 신입 포트폴리오에서 희소한 강점이 된다][^138]
- 실행: 특정 주제(예: 소켓, 성능, 렌더링, 배포 등)를 정하고, 그 주제로 2~3개의 변주 프로젝트/기능을 끝까지 밀어붙인 흔적을 만든다.[^139]
- [h 예외처리와 디테일은 단지 친절함이 아니라 ‘서비스를 만든 사람’임을 증명하는 신뢰 신호다][^140]
- 실행: 로그인 가드, 비정상 접근, 로딩 지연, 전환 애니메이션, 실패/에러 메시지 등 “사용자가 이상하게 쓰는 상황”을 목록으로 만들고 대응 로직을 문서화한다.[^141]
- [m UX의 “쓱싹샥” 같은 미세한 부드러움이 누적되면 서비스 품질을 0→100처럼 바꿀 수 있다고 평가된다][^142]
- 실행: 버튼/전환/이미지 로딩에서 ‘딸깍’ 느낌을 줄이고, 부드러운 전환·지연 로딩·포맷 최적화 같은 개선을 적용한 뒤 비교를 제시한다.[^143]
- [h 면접은 결과물 전시가 아니라, 문제를 발견하고 해결한 ‘사고 과정+근거’를 말로 방어하는 자리다][^144]
- 실행: 각 개선/예외처리 항목마다 “왜 문제인가→어떻게 재현했나→대안→선택 근거→결과”를 준비해 구술 답변 연습을 한다.[^145]
- [m ‘마지막 원칙’(첫 원칙들을 잊지 말라)은, 포트폴리오가 기술 체크리스트가 아니라 개발자의 소양(구조 이해·탐구·사용자 배려)을 드러내야 한다는 메타 원칙이다][^146]
- 실행: 포트폴리오 문서 첫 페이지에 프로젝트 소개보다 “내가 어떤 기준으로 서비스를 만들었는가(구조/깊이/품질)”를 드러내는 서술을 배치한다.[^147]
5. 헷갈리는 용어 정리[^148]
아키텍처: 프로젝트의 구조와 구성요소가 어떤 방식으로 연결·동작하는지에 대한 체계(프론트 렌더링/앱 생명주기, 백엔드 요청 흐름, 통신 방식 등 설명 가능해야 함).[^149]
소켓 통신: 통신 주제의 원론 질문에서 등장하는 방식으로, 대표는 다른 통신과의 차이를 묻는다고 언급(지속 연결 기반의 실시간 기능 구현 사례로 제시됨).[^150]
정적 서버 / 동적 서버: 백엔드 면접 질문에서 구분을 요구하는 서버 개념(대표가 포트폴리오 기반으로 질문한다고 언급).[^151]
예외처리: 사용자가 의도와 다르게 이용할 때(예: 로그인 없이 마이페이지 접근) 시스템이 올바른 안내/차단/전환을 하도록 처리하는 것.[^152]
생명주기(lifecycle): 앱 환경에서 상태 변화/화면 전환 등의 흐름을 어떤 방식으로 활용했는지 묻는 질문의 기준으로 언급됨.[^153]
참고(콘텐츠 정보)[^154]
- 제목: 1초 컷 당하는 포트폴리오 특[^155]
- 채널: 미스터 디벨로 (MR.DEVELLO)[^155]
- 길이: 9분 27초[^155]
- 키워드: 외주개발, SI개발, 개발자포트폴리오, 포트폴리오, 개발포트폴리오, 개발자[^155]
- 링크: https://www.youtube.com/watch?v=7T9bj5XW7ks[^155]
[^3]: @[08:13] "시스템 구조... 탐구... 퀄리티 좋은 서비스... 다른 사람들 생각" / @[08:33] "이런 서비스를 만들 정신이 있는 개발자가 중요" [^4]: @[00:55] "아키텍처를 보신다고 했는데... 어떤 식으로 질문" [^5]: @[01:07] "브라우저 렌더링... 앱 생명주기" / @[01:21] "이용자부터 서버까지 순서" / @[01:33] "정적 서버... 동적 서버" / @[01:38] "통신... 소켓 통신과 차이" [^6]: @[08:58] "오늘 얘기한게 좀 기본 같아서..." [^7]: @[08:58] "기본만 지켜줘도... 플러스 할 때... 너무나 이뻐 보이고" [^8]: @[00:30] "어떤 시각으로... 포트폴리오" [^9]: @[00:45] "크게 네 가지 원칙" / @[08:13] 1~3원칙 재정리 [^10]: @[02:26] "감탄" 사례 / @[04:16] 예외처리 기준 / @[05:47] 이미지 디테일 채용 사례 [^11]: @[00:45] "아키텍처... 없으면 아예 보지도 않거든요" [^12]: @[01:07]~@[01:42] 프론트/백엔드 질문 예시 [^13]: @[02:16] "개발 덕후의 한계" / @[03:52] "한 가지 분야에 미쳐" [^14]: @[04:16] "예외 처" / @[06:56] "사용자가... 어떤 느낌... 고려" [^15]: @[00:30] "이야기 나누려고 합니다" [^16]: @[00:00] "아무런 정보도 없이 마이 페이지만 뿅" [^17]: @[00:00] "면접 분위기가 이상해지면서" [^18]: @[05:05] "마이 페이지만 뿅... 면접 분위기 이상" [^19]: @[00:08] "미스터 디벨로" [^20]: @[00:15]~@[00:20] "궁금해하는게... 포트폴리오" [^21]: @[00:25] "가물가물해서 포기" / @[00:30] "어떤 시각으로... 보는지" [^22]: @[00:36] "뼈가 되고 살이 되는 정보... 집중" [^23]: @[00:45] "첫 번째는... 아키텍처... 없으면 아예 보지도" [^24]: @[00:45] "네 가지 원칙" [^25]: @[00:45] "아키텍처... 없으면 아예 보지도 않거든요" [^26]: @[00:55] "통 아키텍처를 보고... 팁" [^27]: @[01:07] 프론트 질문 소개 [^28]: @[01:07] "프론트... 딱 처음에 물어보는 질문" [^29]: @[01:07] "브라우저를 렌더링할 때" [^30]: @[01:07] 렌더링 질문 언급 [^31]: @[01:07] "앱이라면 생명 주기" [^32]: @[01:07] "브라우저... 렌더링" [^33]: @[01:07] "앱... 생명 주기" [^34]: @[01:07] 질문 방식 설명 [^35]: @[01:21]~@[01:42] 백엔드 질문 소개 [^36]: @[01:21] "API 연결... 이용자부터... 어떤 순서" [^37]: @[01:21] 연결 순서 질문 언급 [^38]: @[01:33] "정적 서버... 동적 서버" [^39]: @[01:38] "통신... 소켓 통신과 차이" [^40]: @[01:38] 원론 질문 언급 [^41]: @[01:07]~@[01:42] "이런 식으로 많이 물어보고" [^42]: @[01:57]~@[02:04] "7부 능선" / "300명 중 5%" [^43]: @[01:45] "와다다... 메모" [^44]: @[01:53] "이 질문에 대답... 좋게 보시나요" [^45]: @[01:57] "거의 7부 능선" [^46]: @[02:04] "300명 중에서 5%" [^47]: @[02:04] 낮은 비율 언급 [^48]: @[02:04]~@[02:08] "면접에서... 좋은 결과" / "맞습니다" [^49]: @[02:14] "아키텍처는 진짜 필수입니다" [^50]: @[02:16] "두 번째는... 개발 덕후" [^51]: @[02:16] "덕후의 한계" [^52]: @[02:19]~@[02:22] "덕후는 서로를 알아본다" [^53]: @[02:41]~@[03:15] 소켓 통신 포트폴리오 사례 [^54]: @[02:26]~@[02:32] "와 진짜... 감탄" [^55]: @[02:41] "텍스트랑 코드만... 디자인 요소는 하나도" [^56]: @[02:52] "소켓 통신에 너무 심취" [^57]: @[02:52] "미쳐 있는 거죠" [^58]: @[03:02] "세 개 포트폴리오" [^59]: @[03:02] "1대1 세팅" [^60]: @[03:02] "1대 다수 세팅" [^61]: @[03:02] "실시간 이미지 전송" [^62]: @[03:02]~@[03:15] "캐치 마인드처럼... 선을... 보여주는 기능" [^63]: @[03:15]~@[03:22] "신입... 거의 없다" / "신입 때... 못" [^64]: @[03:15]~@[03:22] 희소성 강조 [^65]: @[03:02]~@[03:15] 실시간 기능 나열 [^66]: @[03:02]~@[03:15] 소켓으로 할 수 있는 것들 강조 [^67]: @[03:30]~@[03:38] 안드로이드 공기계 서버 [^68]: @[03:22]~@[03:26] "따로 있잖아요" [^69]: @[03:30] "aws... 임대" 대비 / "안드로이드 공기계에 서버" [^70]: @[03:38]~@[03:45] "발상... 덕후 아니면... 뽑아야겠다" [^71]: @[03:38] 발상/덕후 연결 [^72]: @[03:52]~@[03:59] "넓고 얕은" vs "한 가지 분야" [^73]: @[03:45]~@[03:52] "덕후... 어마어마한 덕력" [^74]: @[03:52] "넓고 얕은... 한 가지 분야에 미쳐" [^75]: @[03:59] "다른 언어... 포텐" [^76]: @[03:59] 확장성 논리 [^77]: @[04:07] "덕질... 피지컬... 통찰력 있는 대표" [^78]: @[04:16]~@[05:27] 예외처리 설명 [^79]: @[04:16] "예외 처를... 봐요" [^80]: @[04:16] "예시" [^81]: @[04:16]~@[04:51] 무신사 예시 [^82]: @[04:16]~@[04:36] "마이페이지... 로그인" [^83]: @[04:39] "링크를 직접 때리고 들어간다면" [^84]: @[04:44]~@[04:51] "로그인 하라고... 로그인 창" [^85]: @[04:51] "당연한 서비스인데" [^86]: @[04:58]~@[05:05] "생각... 명확히 갈려요" [^87]: @[05:05]~@[05:14] "로그인 페이지로 이동" [^88]: @[05:05]~@[05:14] "마이 페이지만 뿅" [^89]: @[05:14]~@[05:21] "면접 분위기... 이상" [^90]: @[05:21]~@[05:27] "사용자들은... 절대로... 이상하게 쓸까" [^91]: @[05:34]~@[06:18] 프론트 채용 사례 [^92]: @[05:27] "모셔 왔잖아요" [^93]: @[05:43]~@[05:47] "덕후 중 덕후" [^94]: @[05:47]~@[05:53] "이미지가 늦게 보이는" [^95]: @[05:53] "일반적으로는... 끝" [^96]: @[05:53]~@[06:00] "png... 웹 확장자" [^97]: @[06:00]~@[06:07] "틱틱거리면서... 기능... 부드럽게" [^98]: @[06:07]~@[06:18] "페이지 넘어갈 때마다... 유저들이 편안" [^99]: @[06:18] 품질 인식 언급 [^100]: @[06:23] "0에서 100... 어마어마한 차이" [^101]: @[06:30]~@[06:56] "쓱싹 샥" / 80% vs 20% [^102]: @[06:35]~@[06:39] "버튼... 쓱... 화면 전환" [^103]: @[06:39]~@[06:47] "딸깍... 80% 넘어요" [^104]: @[06:47]~@[06:52] "20%... iOS... 부드러운" [^105]: @[06:52] "서비스를 만들 준비" [^106]: @[06:56] "어떤 느낌... 고려" [^107]: @[07:02] "적극 채용" [^108]: @[07:13]~@[07:36] 오류/해결/면접 [^109]: @[07:13] "다양한 오류 사항" [^110]: @[07:13] "오류를 어떻게 해결" [^111]: @[07:13] "실력이 올라가기 때문에... 넣어서" [^112]: @[07:32]~@[07:36] "근거 확실... 면접은 따놓은" [^113]: @[07:32] 사고/근거 강조 [^114]: @[07:13]~@[07:36] 오류 해결과 근거를 말하라는 취지 [^115]: @[07:39]~@[08:13] 마지막 원칙/버핏 비유 [^116]: @[07:39] "마지막 원칙" [^117]: @[07:43] "첫 번째... 세 번째 원칙을 잊지 마라" [^118]: @[07:47] "워렌 버핏" [^119]: @[07:47] "절대로 돈 잃지 마" [^120]: @[07:47] "첫 번째 원칙을 잊지 마라" [^121]: @[07:51] "진짜 맞는 말" [^122]: @[07:59]~@[08:13] "소양 같은 일" [^123]: @[08:13] 1~3원칙 재정리 [^124]: @[08:13] "시스템 구조... 체계적으로" [^125]: @[08:13] "탐구... 계속 공부" [^126]: @[08:13] "퀄리티... 다른 사람들 생각" [^127]: @[08:29]~@[08:31] "소양까지 담겨" [^128]: @[08:33]~@[08:39] 좋은 개발자 정의 [^129]: @[08:33] "정신이 있는 개발자... 중요" [^130]: @[08:35]~@[08:39] "개발이 다가 아니다" [^131]: @[08:46]~@[08:51] "차별점 있는... 포트폴리오" [^132]: @[08:58]~@[09:06] "기본만 지켜줘도... 플러스" [^133]: @[09:06] "조금만 더 했어 하면" [^134]: @[09:11]~@[09:21] 마무리 멘트 [^135]: @[08:13]~@[09:06] 전체 결론부 취지 [^136]: @[00:45] "없으면 아예 보지도" [^137]: @[01:07]~@[01:42] 질문 리스트 [^138]: @[03:52] "한 가지 분야에 미쳐" [^139]: @[03:02]~@[03:15] 소켓 기반 변주 기능들 [^140]: @[05:21]~@[05:27] "사용자... 이상하게" [^141]: @[04:58]~@[05:14] 마이페이지 예외처리 [^142]: @[06:23] "0에서 100" [^143]: @[05:53]~@[06:18] 이미지 최적화/부드러운 로딩 [^144]: @[07:32] "근거... 면접" [^145]: @[07:13]~@[07:36] 오류 해결/설명 [^146]: @[07:43]~@[08:13] 마지막 원칙과 소양 정리 [^147]: @[08:13] 1~3 원칙 요약 [^148]: @[01:07]~@[06:52] 용어들이 등장하는 구간 [^149]: @[00:45] 아키텍처 필수 / @[01:07]~@[01:42] 질문 예시 [^150]: @[01:38] "소켓 통신" / @[03:02]~@[03:15] 소켓 프로젝트 사례 [^151]: @[01:33] "정적 서버... 동적 서버" [^152]: @[04:16] 예외처리 / @[04:39]~@[05:14] 마이페이지 접근 예시 [^153]: @[01:07] "생명 주기" [^154]: @[00:08]~@[09:21] 영상 전반 메타 [^155]: 사용자 제공 메타데이터(제목/채널/길이/키워드/링크)