잡 인터뷰에서 항상 질문받는 상투적 질문들이 같은 말을 계속해서 반복하고 있다는 것을 눈치채셨나요?

무슨 말인지 아실 거라고 믿어요.

예를 들어:

• 5년 전에 당신은 무엇을 보고있습니까?
  또는 심지어:
• 당신의 가장 큰 약점은 무엇이라 생각합니까?

잠깐 쉬어볼게요. 이러한 질문에 대답하고 있는게 큰 약점일까 생각할 정도에요! 어쨌든 이건 제가 말하려는 건 아니구요.

이와 같은 질문들이 진부할도 수 있지만 중요한 이유는 그것들이 당신에 대한 실마리를 주기 때문입니다. 당신의 현재 마음가짐, 태도, 관점들이요.

대답할 때는 반드시 주의해야 하는데 아마도 그 무언가를 나중에 후회할 수도 있기 때문입니다. 오늘 저는 프로그래밍 세계에서 비슷한 종류의 질문 한 가지에 대해 이야기하려 합니다:

• 객체 지향 프로그래밍의 주요 목적은 무엇인가요?

저는 이 질문을 받기도 하고 주기도 한 양쪽 입장에 있어왔습니다. 이것은 꽤 자주 질문되는 주제 중 하나이기 때문에 몰라서는 안됩니다.

주니어와 신입 단계의 개발자라면 보통 대답해야만 합니다. 왜냐면 면접관들이 다음 세 가지를 말하기 쉬운 방법이기 때문입니다:

1. 후보자가 이번 인터뷰를 준비했는가?
   즉각적인 대답을 듣는다면 추가점입니다 - 면접에 진지한 접근을 보여주니까요.
2. 후보자가 튜토리얼 단계를 지났는가?
   객체 지향 프로그래밍(OOP)의 원리에 대해 이해하는 것은 당신이 튜토리얼에서 복사 붙여넣기를 하는 단계를 넘어섰다는 것을 보여줍니다 - 이미 그러한 것들을 더 높은 관점에서 보고 있으니까요.
3. 후보자의 이해도가 깊고 좁은가?
   이 질문에 대한 완성 수준은 종종 대부분의 다른 주제에 대한 완성 수준과 동일합니다. 저를 믿어보세요.

객체 지향 프로그래밍의 네 가지 원리는 캡슐화(encapsulation), 추상화(abstraction), 상속(inheritance), **다형성(polymorphism)**입니다.

이러한 단어들은 어쩌면 주니어 개발자에게 무섭게 들릴지도 모르겠습니다. 또한 위키피디아의 복잡하고, 과도하게 긴 설명들이 종종 혼란을 가중시키곤 합니다.

제가 각각의 개념에 대해 간단하고 짧으면서도 명료한 설명을 전달하고 싶어하는 이유입니다. 어쩌면 아이에게 설명하는 것 처럼 들릴수도 있지만 사실은 제가 인터뷰를 볼 때 이러한 대답들을 정말 듣고 싶습니다.

캡슐화(encapsulation)

우리가 어떤 프로그램을 가지고 있다고 합시다. -프로그램 안에 정의된 규칙에 따라서- 서로 전달을 주고 받는 몇 가지 논리적으로 다른 객체들을 가지고 있습니다.

캡슐화는 각각의 객체들이 클래스 안에서 그들의 상태를 프라이빗(private) 유지할 때 획득할 수 있습니다. 다른 객체들이 그 상태에 대한 직접 접근할 수 없습니다. 대신 그들은 -메소드라고 불리는- 퍼블릭(public) 함수 목록만을 호출할 수 있습니다.

그래서 객체는 자신의 상태를 메소드를 통해 관리합니다 - 그리고 어떤 다른 클래스라도 예외적으로 허용되지 않는 이상 그것을 건드릴 수 없습니다. 만약 해당 객체와 전달을 주고받고 싶다면 제공된 메소드를 사용해야만 합니다. 하지만 (기본적으로) 그 상태를 변경할 수 없습니다.

작은 심즈(Sims) 게임을 만들고 있다고 가정해봅시다. 사람들이 있고 고양이 한 마리가 있습니다. 다른 사람들과 고양이들이 각자 소통합니다. 우리는 캡슐화를 적용하고 싶으니 모든 "고양이" 로직을 Cat 클래스 안에 캡슐화 합니다. 아마 아래와 같이 보일 것입니다:

고양이를 먹일 수 있습니다. 그러나 고양이가 얼마나 배가 고픈지는 직접 변경할 수 없습니다.

여기 고양이의 "상태"는 프라이빗 변수(private variables) mood, hungry, energy입니다. 또한 프라이빗 메소드 meow()를 가지고 있습니다. 원할 때마다 호출할 수 있고 그 외 다른 클래스들은 meow를 할 때 고양이를 말할 수 없습니다.

그들이 할 수 있는 것은 **퍼블릭 메소드(public methods)**안에 정의된 sleep(), play(), feed()입니다. 각각은 내부 상태를 어떤 식으로 수정하고 어쩌면 meow()를 불러올 수도 있습니다. 그렇게 프라이빗 상태와 퍼블릭 메소드 사이 결합이 만들어집니다.

이것이 캡슐화입니다.

추상화(abstraction)

추상화는 캡슐화에 자연적 연장으로 생각될 수 있습니다.

객체 지향 디자인에서 프로그램들은 종종 엄청나게 큽니다. 그리고 구분된 객체들이 서로 다른 것들과 많이 소통합니다. 그래서 이와 같은 대규모 코드 베이스(codebase)를 수년 동안 -도중에 변경하면서- 유지하는 것은 어렵습니다.

추상화는 이러한 문제를 쉽게 하기 위한 개념입니다.

추상화를 적용한다는 것은 각각의 객체가 반드시 그를 사용하는 하나의 상위 개념 동작 방식(mechanism)에만 노출되어야 합니다.

동작 방식은 내부 구현 상세 내용을 숨겨야만 합니다. 다른 객체들에게 연관된 동작들만 밝혀야 합니다.

생각해봅시다 - 커피 머신 하나를요. 후드 아래에서 많은 것을 하고 시끄러운 소리를 만들어냅니다. 그러나 당신이 해야 하는 일이라고는 커피를 넣고 버튼을 누를는 것이 전부입니다.

동작 방법은 선호하도록 사용하기 쉬워야만하고 시간이 지날 수록 거의 바뀌지 않아야만 합니다. 이것을 어떠한 다른 클래스라도 그게 어떻게 일하는지 "알지" 못하는 채로 호출하는 퍼블릭 메소드들의 작은 집합이라고 생각하세요.

추상화의 또 다른 실생활 예제요?
휴대폰을 어떻게 사용하는지 생각해보세요:

휴대폰은 복잡합니다. 그러나 그걸 사용하는 것은 간단합니다.

휴대폰과 상호 작용은 단지 몇 개의 버튼을 사용하는 것 뿐입니다. 후드 아래 어떤 일이 일어나고 있냐구요? 당신이 알 필요가 없습니다 - 구현 상세 내용은 숨겨져 있습니다. 알아야 할 것은 짧은 동작 집합일 뿐입니다.

구현은 바뀌지만 -예를 들어, 소프트웨어 업데이트처럼- 당신이 사용하는 추상화에 극히 드문 영향을 미칩니다.

상속(inheritance)

자, 캡슐화와 추상화가 어떻게 우리가 대규모 코드 베이스를 개발하고 유지하는데 도움이 될 수 있는지 보았습니다.

그런데 혹시 객체 지향 프로그래밍 디자인의 또 다른 흔한 문제를 알고 있나요?

객체는 종종 매우 비슷합니다. 그것들은 일반 로직을 공유합니다. 그러나 그것이 완전히 같지는 않습니다. 어...

그래서 우리는 어떻게 일반 로직을 재 사용하고 독자적인 로직을 별개의 클래스 안에 추출할 수 있을까요? 이것을 달성하기 위한 방법 한 가지가 상속입니다.

이것은 또다른 (부모) 클래스에서부터 파생된 하나의 (자녀) 클래스를 만드는 것을 의미합니다. 이런 방식으로 우리는 계층을 형성합니다.

자녀 클래스는 부모 클래스의 모든 필드와 메소드를 (공통 부분) 재 사용하고 자체적인 것을 (독립 부분) 구현할 수 있습니다.

예를 들어:

사립 선생님은 Teacher 종류의 하나입니다. 그리고 Teacher는 Person의 한 종류입니다.

만약 우리 프로그램이 공립과 사립 선생님들 뿐만 아니라 학생과 같은 다른 종류의 사람들을 함께 관리할 필요가 있다면, 우리는 이 클래스 계층을 구현할 수 있습니다.

이러한 방식으로 각각의 클래스는 부모 클래스에서 일반 로직을 재활용하면서 그들에게 필요한 것만을 추가할 수 있습니다.

다형성(polymorphism)

가장 복잡한 단어에 다다랐습니다! 다형성은 그리스어로 "다향한 형태"를 의미합니다.

자, 우리는 이미 상속의 힘을 알고 그걸 기쁘게 사용합니다. 그런데 여기 이 문제가 나타납니다.

부모 클래스가 그로부터 상속된 몇 개의 자녀 클래스를 가지고 있다고 해 봅시다. 때때로 우리는 모든 이러한 클래스들이 혼합되어 담겨있는 컬렉션(collection) -예를 들어 리스트-을 사용하고 싶을 수 있습니다. 또는 우리가 부모 클래스를 위해 구현된 어떤 메소드를 가지고 있는데 그것을 자녀 클래스를 통해서도 사용하고 싶은 것입니다.

이것은 다형성을 사용함으로써 해결할 수 있습니다.

간단히 말해 다형성이란 어떤 클래스를 클래스의 부모 클래스와 정확히 동일하게 사용하여 혼합된 타입에 대한 혼란이 발생하지 않도록 하는 방법을 제공합니다. 그러나 각자의 자녀 클래스들은 그 자체로 자신의 메소드를 유지합니다.

이것은 보통 어떤 (부모) 인터페이스를 재사용하도록 정의를 내리면서 발생합니다. 이 방법은 많은 일반 메소드들을 그려냅니다. 그리고나서 각각의 자녀 클래스들이 그 자신의 버전으로 이 메소드를 구현합니다.

언제든지 어떤 컬렉션 (예를 들어 리스트) 또는 어떤 메소드가 (공통의 메소드가 정의되어진) 부모 클래스 타입의 객체를 기대할 때마다, 언어는 공통 메소드의 올바른 구현 통해 계산하는지만 -어떤 자녀 클래스가 전달되든지 상관없이- 신경 쓰면 됩니다.

기하학 도형들을 구현한 스케치를 살펴보세요. 도형들은 면적과 둘레를 계산하기 위해 일반 인터페이스를 재사용합니다:

삼각형, 원, 사각형은 이제 같은 모음집 안에 사용될 수 있습니다.

부모 Figure Interface를 상속하는 세 가지 도형을 가지는 것으로써 triangles, circles, rectangles이 혼합된 배열을 생성할 수 있습니다. 그리고 그들을 같은 형태의 객체로 취급합니다.

그러면 이 배열이 어떤 구성 요소의 면적을 계산하려 할 때, 올바른 메소드가 찾아지고 실행됩니다. 만약 그 구성 요소가 삼각형이라면 삼각형의 CalculateSurface()가 호출됩니다. 만약 그것이 원이라면 원의 CalculateSurface()가 호출되고 하는 식입니다.

어떤 도형이 스스로의 매개 변수(parameter)를 이용해 동작하는 함수를 가지고 있다면 세 번씩 -삼각형, 원, 사각형을 위해 각각 한번씩- 정의할 필요가 없습니다.

정의를 한번하고 Figure를 변수(argument)로 받아들일 수 있습니다. 삼각형, 원, 또는 사각형 어떤 것을 통과하던지 -그것들이 CalculateParameter()를 구현한다는 전제하에서- 그들의 종류는 상관 없습니다.

도움이 되었으면 좋겠습니다. 잡 인터뷰에서 이것과 정확히 같은 설명을 직접 사용할 수 있습니다.

만약 여전히 무언가 이해하기 어렵다면 아래 댓글로 질문하는 걸 망설이지 마세요.

다음 단계는?

항상 인터뷰 질문에 오르는 고전적인 것들 중 한가지를 대답할 수 있게 준비된 것은 대단한 일입니다 - 그러나 때때로 인터뷰 자체를 받지 못할 수 있겠죠.

다음으로, 저는 고용인들이 주니어 개발자에게서 어떤 것을 보고 싶어하는지에, 구직 활동을 할 때 여럿 중에서 어떻게 돋보일 수 있는지 초점을 맞춰보려 합니다.

지켜봐주세요.

즐겁게 읽으셨나요? 응원하고 싶다면 커피 한 잔 사 주세요 :)

CSS는 어렵지만 관대합니다. 이 관대함으로 우리는 CSS에 이런저런 스타일을 시도해볼 수 있습니다.

페이지는 여전히 로드됩니다. "충돌"은 없습니다.

페이지 너비와 높이와 관련하여 HTML 요소에 무엇을 설정해야 하는지 알고 있습니까? Body 요소는 어떻습니까?

두 요소 모두에 스타일을 그냥 냅다 적용하고 잘되기를 바라고 있나요?

그렇다면 당신 혼자만 그런 건 아닙니다.

이 질문에 대한 답은 직관적이지 않습니다.

맞습니다. 저는 과거에 두 요소에 어떤 속성을 적용해야 하는지 정확히 고려하지 않고 스타일을 적용했습니다.

다음과 같이 HTML과 body 요소 모두에 CSS 속성이 적용된 것을 흔하게 보았을 것입니다.

html, body {
     min-height: 100%;
}

이게 중요한가요?

네, 그렇습니다.

위 스타일 정의는 문제를 만듭니다.

두 요소 모두에 최소 높이를 100%로 설정해도 예상한 대로 body 요소가 페이지를 채울 수 없습니다. 개발자 도구에서 계산된 스타일 값을 확인하면 body 요소의 높이가 0입니다.

한편, HTML 요소는 브라우저에서 페이지의 보이는 부분과 동일한 높이를 갖습니다.

크롬 개발자 도구의 다음 스크린샷을 보세요.

body 요소에는 상단의 막대로 표시된 기본 8px 여백이 있습니다. 높이 값은 0입니다.

왜 이런 일이 일어날까요?

백분율을 크기 값으로 사용하려면 body 요소가 해당 백분율을 기반으로 부모를 참조해야 합니다.

HTML 요소는 페이지의 보이는 부분과 동일한 높이 값을 갖는 뷰포트를 참조합니다. 하지만 우리는 HTML 요소의 최소 높이만 설정했지... 높이 값은 설정 안 했습니다.

따라서 body 요소에는 100%가 무엇인지 결정할 때 참조할 상위 높이 값이 없습니다.

그리고 문제가 보이지 않을 수 있습니다.
페이지 body를 채울 만큼 충분한 콘텐츠로 시작했다면 이 문제를 눈치채지 못했을 수 있습니다.

그리고 더 알아보기 어렵게 하기 위해 두 요소 또는 그중 하나만 배경색을 설정하면 뷰포트가 해당 색상으로 가득 차게 됩니다. 이것은 body 요소가 뷰포트만큼 높다는 인상을 줍니다.

아닙니다. 높이는 여전히 0입니다.

위의 이미지는 다음 CSS가 있는 페이지에서 가져온 것입니다.

html, body {
    min-height: 100%;
}
body { background-color: dodgerblue; }

역상속?

이상하게도 HTML 요소에 별도의 배경색을 설정하지 않으면 body 요소의 배경색으로 가정합니다.

그렇다면 반응형 페이지의 이상적인 전체 높이 설정 방법은 무엇일까요?

오랫동안 답은 다음과 같았습니다.

html {
    height: 100%;
}
body {
    min-height: 100%;
}

이렇게 하면 HTML 요소가 상위 뷰포트를 참조하고 뷰포트 값의 100%와 동일한 높이 값을 가질 수 있습니다.

HTML 요소가 높이 값을 수신할 때 body 요소에 할당된 최소 높이 값도 해당 값으로 제공됩니다.

이렇게 하면 콘텐츠가 보이는 페이지보다 커지면 body가 더 커질 수도 있습니다.

유일한 단점은 HTML 요소가 보이는 뷰포트의 높이 이상으로 커지지 않는다는 것입니다. 하지만 body 요소가 HTML 요소보다 커지는 것은 허용되었습니다.

최신 해결책은 간단해졌습니다.

body { min-height: 100vh; }

이 예제는 vh(뷰포트 높이) 단위를 사용하여 body 요소가 뷰포트의 전체 높이를 기반으로 최소 높이 값을 설정할 수 있도록 합니다.

앞서 논의한 배경색과 마찬가지로 HTML 요소에 높이 값을 설정하지 않으면 body 요소에 지정된 높이와 동일한 값을 가정합니다.

따라서 이 해결책은 이전 해결책에 있는 HTML 요소 오버플로를 방지하고 두 요소 모두 콘텐츠와 함께 커집니다!

vh 단위를 사용하면 과거에는 일부 모바일 브라우저 문제가 발생했지만, Chrome 및 Safari는 현재 표시 영역 단위와 일치하는 것으로 보입니다.

페이지 높이가 가로 스크롤바를 유발할 수 있음

잠시만요, 뭐라고요?

"페이지 너비"라고 말하지 않았나요?

아니요.

또 다른 일련의 이상한 이벤트에서 페이지 높이가 브라우저에서 가로 스크롤바를 활성화할 수 있습니다.

페이지 콘텐츠가 뷰포트 높이보다 커지면 세로 스크롤바가 활성화됩니다. 이에 따라 가로 스크롤바도 즉시 나타날 수 있습니다.

그럼 해결책은 뭔가요?

페이지 너비 설정으로 시작하는 것을 알면 잠을 더 잘 잘 수 있겠네요.

이 스크롤바 문제는 HTML이나 body 요소뿐만 아니라 모든 요소가 100vw(뷰포트 너비) 단위로 설정될 때 발생합니다.

뷰포트 단위는 세로 스크롤바가 차지하는 약 10픽셀을 고려하지 않습니다.

따라서 세로 스크롤바가 활성화되면 가로 스크롤바도 표시됩니다.

전체 너비로 페이지를 설정하는 방법

어쩌면 그냥 하지 않습니다.

HTML과 body 요소에 너비를 설정하지 않으면 기본적으로 전체 크기의 화면이 됩니다. auto 이외의 너비 값을 설정하는 경우 먼저 CSS 재설정을 활용하는 것이 좋습니다.

기억하세요, 기본적으로 body 요소에는 모든 면에 8px의 여백이 있습니다.

CSS 재설정은 이 여백을 제거합니다. 그렇지 않으면, 여백을 제거하기 전에 너비를 100%로 설정하면 body 요소가 영역을 벗어납니다. 제가 사용하는 CSS 재설정은 다음과 같습니다.

* { 
    margin: 0;
    padding: 0;
    box-sizing: border-box;
}

너비를 원하는 대로 설정하는 방법

항상 너비를 설정할 필요는 없지만 저는 보통 그렇게 합니다.

단순히 습관일 수도 있습니다.

body 요소에서 너비를 100%로 설정하면 전체 페이지 너비가 됩니다. 이것은 본질적으로 너비 값을 설정하지 않고 기본값을 허용하는 것과 같습니다.

body 요소를 더 작은 컨테이너로 사용하고 HTML 요소가 페이지를 채우도록 하려면 body에 최대 너비값을 설정할 수 있습니다.

다음은 예입니다.

html { background-color: #000; } 
body {
    min-height: 100vh;
    max-width: 400px;
    background-color: papayawhip; 
    margin: 0 auto;
}

결론

HTML 요소에 높이 값이 제공되지 않은 상태에서 body 요소의 높이 및/또는 최소 높이를 100%로 설정하면 높이가 발생하지 않습니다(콘텐츠를 추가하기 전).

하지만 HTML 요소에 너비 값이 제공되지 않은 상태에서 body 요소의 너비를 100%로 설정하면 전체 페이지 너비가 됩니다.

이것은 직관적이지 않고 혼란스러울 수 있습니다.

반응형으로 전체 페이지 높이를 설정하려면 body 요소 최소 높이 값을 100vh로 설정하세요.

페이지 너비를 설정하는 경우 100vw 이상 100%를 선택하여 예기치 않은 가로 스크롤바를 방지하십시오.

전체 화면 크기이면서 콘텐츠와 함께 커지는 HTML 페이지의 CSS 높이 및 너비 설정 방법을 보여주는 YouTube 채널의 자습서를 남겨 드리겠습니다.

CSS 너비와 높이를 설정하는데 더 선호하는 다른 방법이 있으신가요?

방법을 알려주세요!