2020년 하반기 네이버 공채 1차 / 2차 면접 후기

1년 전, 기억을 되살리기엔 너무 오래전 이야기지만 다른 사람들에게 도움이 될까 싶어서 꺼내보려고 한다.
사실 이 후기를 1년 전에 적었어야 했는데 불합격 후 멘탈을 다시 부여잡는데 시간이 오래 걸렸다. 다시 취준을 시작하는 것이 좀 힘들기도 했고 부족한 점이 뭔지 차근차근 살펴보는 시간도 필요했기 때문에 이제야 글을 쓰게 되었다. 그리고 2021년 하반기 네이버 서류 합불 발표와 함께, 면접 일정이 잡혔다는 소식을 접하게 되면서 면접을 준비하는 사람들에게 도움이 되고자 조금 작성해보려 한다.

물론, 이 글은 면접 전에 작성했던 정보 보안 서약서 때문에 조심스러운 부분도 있다. 하지만, 네이버뿐만 아니라 다른 기업들도 비슷하게 기술 면접을 진행할 것이고 네이버뿐만 아니라 기술 면접을 준비하는 모든 분들을 대상으로 작성하였다. 그동안 내가 기술면접을 보고 나서 생각했던 부분들을 작성하였기 때문에 그 부분을 참고해서 보면 좋을 것 같다. "이런 문항이 나온다!" 보다는 "이렇게 준비하면 좋다!" 혹은 "이렇게 준비했으면 더 좋았을 걸!"이라는 내용을 담을 것이다. 때문에 뻔한 내용일 수 있다는 점... 물론 문제가 된다면 연락 부탁드립니다.

1차 면접

코딩 테스트와 서류 합불 발표가 뜨고 1차 면접 일정이 잡혔다. 서류 발표가 20년 10월 16일이었고 면접 일정은 10월 20일 날 잡혔다. 그리고 면접은 10월 23일(금요일)이었다. 아직도 기억나는 게 이때 내가 42 서울 피신을 진행 중일 때라 정신이 없었는데 더불어 면접도 급하게 준비한다고 바빴다. 피신에서 매주 금요일은 시험을 보는 데, 시험 시간과 면접 시간이 겹치는 바람에 클러스터 근처에 스터디룸을 빌리고 시험 중간에 나와서 면접을 보았다.

중고 신입은 면접 일자가 토요일에 잡히는 듯 보였고 생신입은 평일에 배정되는 듯 보였다. 물론 모든 사람이 그렇게 배정되는 것은 아니지만 면접 일자를 변경할 수 없으니 네이버에서 최대한 배려를 해주신 것 같았다. 나는 당시 대학교 4학년이었고 졸업 예정자였기 때문인지 금요일에 면접을 보게 되었다.

사람마다 1차 면접 내용이 다른 것 같지만 나는 CS 위주의 질문을 많이 받았다. 크게 알고리즘, 운영체제, 네트워크 ! IT 기술 면접에서 흔하게 나오는 질문들이 나온다. 아, 그리고 모든 면접이 그렇듯 1분 자기소개는 준비해 가야 한다. (물어보지 않는 기업들도 있었지만, 거의 99%가 자기소개를 준비해 가는 것이 좋고 네이버 역시 간단한 자기소개로 면접이 시작된다.)

# 알고리즘

알고리즘은 크게 이론과 라이브 코딩으로 나뉘게 된다.
이론은 다들 알고리즘이나 자료구조 시간에 배웠던 이론들을 다시 정리하는 시간을 가지면 좋을 것 같다. 지금 생각해보면 삼성 알고리즘 특강이 많이 도움이 되었을 것 같다. (20년도에 네이버 면접을 보았고 21년에 삼성 알고리즘 특강을 들었다) 지금까지 배운 알고리즘을 정리하면서 어떤 문제가 생겼을 때 어떤 알고리즘을 쓰는 것이 효율적인지 정리하는 것이 좋다. 네이버뿐만 아니라 다른 기업에서도 코딩 면접에서는 시간 복잡도와 공간 복잡도를 물어보는 경우가 많다. 단순히 이런 알고리즘에는 시간 복잡도가 뭔지 암기하는 것이 아니라 코드를 보면 시간 복잡도는 얼마인지 공간 복잡도는 얼마인지 계산할 줄 알아야 된다.
라이브 코딩은 문제가 주어지고 그에 맞는 코드를 작성하면 된다. 작년 네이버 공채 면접은 손 코딩으로 진행되었는데 면접에 따라 화면 공유를 해서 라이브 코딩을 한 경우도 있었다(네이버 웹툰 인턴 면접은 화면 공유로 진행했었다). 문제는 생각보다 단순하고 어렵지 않다. 내가 생각했을 땐 코딩 테스트를 합격하고 면접을 본 사람이라면 라이브 코딩에서 나오는 문제는 쉽다고 느낄 확률이 높다. 라이브 코딩에서 중요한 건 면접관들과의 소통이라고 생각한다. 라이브 코딩에 주어지는 문제는 대개 코딩 테스트에 쉽고 단순하기 때문에 허점이 있다. 절대 코딩 테스트에서 나오는 것처럼 처리해야 할 모든 예외처리를 알려주지 않는다. 이 때는 면접관들과 이런 경우 어떻게 처리하면 좋은지(예. 배열을 반환해야 하는 메서드를 작성해야 할 경우, 아무것도 없는 상태를 반환하고 싶을 때 null을 반환할지 []을 반환할지 [0]을 반환할지, 물론 문제 상황에 따라 어떤 것을 리턴해야 좋을지는 다를 것이다.) 대화하면서 작성하는 것이 중요한 것 같다. 단순히 코딩 능력을 보는 것이 아니라 주어진 문제에서 어떤 것을 보았고 어떻게 면접관과 소통하며 해결해 나갈 것인지를 확인하는 질문이라고 생각한다. 크게 걱정을 하지 않아도 되는 점이 코드를 보고 면접관분들이 질문을 해주시는 과정 속에(이런 경우는 어떻게 하면 될까요?, 지금 코드는 이런 것은 반영하지 않은 것 같은데요.) 코드를 작성하면 수월하게 해결할 수 있을 것이다. 보통 이런 경우 꼬리물기 질문이 계속된다. 코드를 작성하는 것뿐만 아니라 코드 한줄한줄마다 정당성을 부여하면서 말로 정리하는 연습을 하면 좋을 것 같다.

# 네트워크, 운영체제 및 기타 CS 지식

이 부분에 대해선 말해줄 것이 크게 없다. (깃허브만 가도 정리해주신 분들이 엄청 많다.) 오히려 말하고 싶은 것은 그런 것에 너무 의존하지 말라는 말을 드리고 싶다. 면접 전 스스로 고민할 시간이 무조건 필요한 것 같다. CS 질문 같은 경우 연관된 개념 이론들이 많아서 꼬리물기 질문이 계속될 수밖에 없다. 꼬리물기 질문을 받다 보면 당연히 막히는 구간이 생길 것이다. 그런 질문에 대답을 잘하는 것이 중요한 것 같다. 다양하게 생각해보는 것만으로도 좋은 준비가 될 수 있고 실제 개발에선 어떻게 해결하는지 찾아보고 가면 더 좋을 것 같다. (예를 들어 A와 B의 차이에 대해서 설명하다가 면접관이 그래서 무엇이 좋은 것 같나요? 혹은 본인이 개발한다면 어떤 것을 사용하실래요? 묻는 질문에 대답을 할 때 단지 "어떤 것"만 언급하는 것이 아니라 논리적이고 합당한 이유도 대답하면 좋다. 대답을 했을 땐 그런데 이런 단점도 있지 않을까요? 이런 것은 어떻게 해결하실래요? 와 같은 꼬리 질문이 시작된다.)

# CS 면접 준비 관련 깃허브

https://github.com/ksundong/backend-interview-question

https://github.com/WeareSoft/tech-interview

https://github.com/gyoogle/tech-interview-for-developer

# 2차 면접

사실 떨어질 것 같았던 1차 면접이 붙었다. 얼떨떨한 기분이 먼저 들었던 것 같다. 물론 공식적인 경쟁률은 알려진 적이 없지만, 그때 당시 합격자들끼리 추정하던 카더라 2차 면접 경쟁률은 2:1 정도였던 것 같다. (더 아래일 수도 더 위일 수도... 사실 네이버 인사팀 말고는 아무도 모르는 것 아닌가?) 2시간정도 진행되던 1차 면접과는 다르게 2차 면접은 1시간 동안 진행하는 면접이었기 때문에 끝나고 좀 더 마음이 편했다. 20년 11월 13일에 1차 면접 합격자 발표가 떴고 11월 20일에 2차 면접을 보았다.
2차 면접은 자기소개서와 포트폴리오를 바탕으로 한 기술 면접이었다.
면접을 준비하기 전 포트폴리오와 자기소개서를 꼭 정리를 해야한다. 그리고 포트폴리오에 깃허브가 있다면 깃허브 정리를 하면서 코드를 한 번 더 확인하고 코드 리팩토링을 할 수 있으면 진행하는 것을 추천한다. 면접관님들이 무조건 확인을 하기 때문에 깃허브나 블로그를 한 번씩 정리하는 것이 좋다. 블로그에 남긴 글은 한번 읽으면서 상기시키고 가는 것이 꼭 필요하다. 면접 도중에 블로그에 있는 글에 대해 물어보는 경우도 있었다. 내가 정확히 알고 있는 것이 맞는지, 까먹은 것은 아닌지, 잘못된 개념을 블로그나 깃에 올린 것은 아닌지 확인하면서 정리하는 시간이 무조건 필요하다고 생각된다. 깃허브, 블로그 등 안 하는 것보다 하는 것이 낫지만, 기록을 한다면 제대로 알고 기록을 하는 것이 중요하다고 생각했다.
포트폴리오는
1. 어떤 기술을 사용했는지
- Spring, JPA, MyBatis, AWS EC2/RDS/S3, Golang, Javascript ES6, React, Vue, JWT, Redis, Mysql 등등
- 그 기술에 대한 전반적인 이론도 알아야 됨. 예) Spring이라면 IoC가 무엇인지, Redis를 사용한 이유는 무엇인지, JWT와 다른 인증 방식의 차이점은 무엇인지 등
2. 기술 - 어떤 문제가 발생했고 어떻게 해결했는지
- N+1 Query 문제 해결, 코드 리팩토링 과정, 배포 시 생긴 문제 등
3. 사람 - 어떤 문제가 발생했고 어떻게 해결했는지
- 팀내 불화, 책임감이 없는 팀원, 백엔드 혹은 프런트 팀원의 부재, 촉박한 마감기한 등
4. 비즈니스 로직을 어떻게 구현했는지
- 그 기능이나 서비스가 왜 필요했는지
- 그래서 비즈니스 로직을 어떤 식으로 짰는지, 2번과 연결 지어 정리

2차 면접은 "이 프로젝트를 진행하면서 이만큼이나 고민했어요.", "저는 회사에서 이만큼 기여할 수 있어요." 혹은 "저는 이 정도까지 열정이 있는 사람이에요" 라는 것을 보여주는 것이라고 생각한다. 그리고 본인의 장점은 무엇인지, 단점은 무엇인지, 그 단점을 극복하기 위해 어떤 노력을 해왔는지 이런 것들을 개발, 본인 포트폴리오와 엮어 설명하면 더 좋을 것이라고 생각된다.



사실 면접 후기라는게 어쩌면 진부한 글(정말 진부했다...)이 될 수 있는데, 아무튼 적어보았다. 나는 비록 최종 면접에서 불합격을 했지만, 정말 좋은 경험이었다.(나의 장점.. 긍정충..) 주위에 친한 개발자 선배들도 없었고 혼자 취업 준비를 했기 때문에 이런 경험은 더 뜻깊었던 것 같다. 또, 피드백을 받는 것을 정말 좋아하는데 개발 경력이 최소 10년 이상인 사람이 내 코드를 읽고 내가 하는 말을 들으면서 조언을 해주고 같이 이야기한다는 것이 너무 감격스러웠고 그 시간이 정말 정말 소중했다. 현실적이지만 합격하든 불합격하든 면접도 나를 성장시키는 또 하나의 발판이라고 생각한다. 면접을 준비하는 기간에도, 면접을 하는 그 시간에도 정말 많은 것을 배울 수 있고 많은 것을 생각할 수 있는 시간을 가지게 된 것 같다.

# 프로세스란?

실행중인 프로그램

# ps 명령어

- Process 와 관련 linux 명령어는 ps 입니다.

$ ps -ef
  UID   PID  PPID   C STIME   TTY           TIME CMD
    0     1     0   0  4:57PM ??         0:07.21 /sbin/launchd
    0    69     1   0  4:57PM ??         0:00.61 /usr/sbin/syslogd

# Kill 명령어

- 프로세스에 시그널을 보내는 명령어이다.

1. kill 시그널 리스트 확인

$ kill -l
 1) SIGHUP	 2) SIGINT	 3) SIGQUIT	 4) SIGILL	 5) SIGTRAP
 6) SIGABRT	 7) SIGBUS	 8) SIGFPE	 9) SIGKILL	10) SIGUSR1
11) SIGSEGV	12) SIGUSR2	13) SIGPIPE	14) SIGALRM	15) SIGTERM
16) SIGSTKFLT	17) SIGCHLD	18) SIGCONT	19) SIGSTOP	20) SIGTSTP
21) SIGTTIN	22) SIGTTOU	23) SIGURG	24) SIGXCPU	25) SIGXFSZ
26) SIGVTALRM	27) SIGPROF	28) SIGWINCH	29) SIGIO	30) SIGPWR
31) SIGSYS	34) SIGRTMIN	35) SIGRTMIN+1	36) SIGRTMIN+2	37) SIGRTMIN+3
38) SIGRTMIN+4	39) SIGRTMIN+5	40) SIGRTMIN+6	41) SIGRTMIN+7	42) SIGRTMIN+8
43) SIGRTMIN+9	44) SIGRTMIN+10	45) SIGRTMIN+11	46) SIGRTMIN+12	47) SIGRTMIN+13
48) SIGRTMIN+14	49) SIGRTMIN+15	50) SIGRTMAX-14	51) SIGRTMAX-13	52) SIGRTMAX-12
53) SIGRTMAX-11	54) SIGRTMAX-10	55) SIGRTMAX-9	56) SIGRTMAX-8	57) SIGRTMAX-7
58) SIGRTMAX-6	59) SIGRTMAX-5	60) SIGRTMAX-4	61) SIGRTMAX-3	62) SIGRTMAX-2
63) SIGRTMAX-1	64) SIGRTMAX

2. 주요 시그널

3. 프로세스에 시그널 보내기

$ kill [option] PID

# 1234(PID) 프로세스 종료 
$ kill -9 1234
$ kill -SIGKILL 1234

 같이 보면 좋은 글 

https://frogand.tistory.com/187

Sass의 소개, 설치와 간단한 명령어 사용법

1. Introduction

Sass(Syntactically Awesome StyleSheets)는 CSS per-processor(전처리기)로서 CSS의 한계와 단점을 보완하여 보다 가독성이 높고 코드의 재사용에 유리한 CSS를 생성하기 위한 확장(extension) 기능이다.

CSS의 간결한 문법은 배우기 쉬우며 명확하여 프로젝트 초기에는 문제가 없어 보이지만 프로젝트의 규모가 커지면서 수정이 빈번히 발생하여 쉽게 지저분해지고 유지보수도 어려워진다.

Sass는 다음과 같은 추가 기능과 유용한 도구들을 제공하여 CSS의 한계를 보완하고 있다.

- 변수의 사용

- 조건문과 반복문

- Import

- Nesting

- Mixin

- Extend/Inheritance

Sass의 장점

- CSS보다 심플한 표기법으로 CSS를 구조화하여 표현할 수 있다.

- 스킬 레벨이 다른 팀원들과 작업 시 발생할 수 있는 구문의 수준 차이를 평준화할 수 있다.

- CSS에는 존재하지 않는 Mixin 등의 기능을 활용하여 CSS 유지보수 편의성을 큰 폭으로 향상시킬 수 있다.

2. Install

브라우저는 Sass의 문법을 알지 못하기 때문에 Sass(.scss) 파일을 css 파일로 컴파일(트랜스파일링)해야 한다. 따라서 Sass 환경 설치가 필요하다.

Sass는 Ruby로 처음 개발 되어 Ruby Sass를 C++로 포칭한 Libsass, node.js 환경에서 Libsass를 사용할 수 있는 node-sass 등 다양한 포팅 버전이 등장하였다. Sass는 최근에 Dart Sass로 재구현되었다.

다음 명령을 사용하여 Sass를 설치한다.

$ npm install -g sass

3. Command

1. version

$ sass --version
1.30.0 compiled with dart2js 2.10.4

2. 트랜스파일링

sass-project 디렉터리를 생성하고 트랜스파일링할 foo.scss 파일을 아래와 같이 생성하자.

$site_max_width: 960px
$font_color: #333;
$link_color: #00c;
$font_family: Arial, sans-serif;
$font_size: 16px;
$line_height: percentage(20px / $font_size);

body {
  color: $font_color;
    
  // property Nesting
  font: {
    size: $font_size;
    family: $font_family;
  }
    
  line-height: $line_height;
}

#main {
  width: 100%;
  max-width: $site_max_width;
}

트랜스 파일링할 SCSS 파일의 경로와 트랜스파일링 후 생성될 css 파일의 경로를 지정한다.

# foo.scss를 트랜스파일링해서 foo.css를 생성
$ sass foo.scss:foo.css

foo.scss 파일이 트랜스파일링되어 다음과 같이 foo.css 파일이 생성된다.

body{
  color: #333;
  font-size: 16px;
  font-family: Arail, sans-serif;
  line-height: 125%;
}

#main {
  width: 100%;
  max-width: 960px;
}

특정 디렉터리 내의 모든 scss 파일을 css 파일로 일괄 트랜스파일링해서 지정한 디렉터리에 저장하려면 인풋 디렉터리와 아웃풋 디렉터리를 지정한다.

# sass input-directory-path:out-put-directory-path
$ sass src/sass:dist/css

npm scripts를 사용하면 매번 긴 명령어를 입력하지 않고 좀 더 간단히 명령어를 사용할 수 있다. 프로젝트 디렉터리에 아직 package.json이 없다면 다음 명령으로 package.json을 생성한다.

$ npm init -y

생성된 package.json을 다음과 같이 수정한다.

{
  "name": "sass-project",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "build:sass": "sass src/sass:dist/css"
  },
  "keywords": [],
  "author": "",
  "license": "ISC"
}

이제 다음과 같은 명령어로 좀 더 간단히 트랜스파일링할 수 있다.

$ npm run build:sass

3. style

scss 파일을 트랜스파일링하여 css 파일을 생성할 때 2가지 스타일 중 하나를 선택할 수 있다.

expanded

표준적인 스타일의 css 파일이 생성된다. 기본값이다.

$ sass --style expanded src/sass:dist/css
$ sass src/sass:dist/css
# 같은 결과가 만들어진다.

compressed

가능한 빈공간이 없는 압축된 스타일의 css 파일이 생성된다.

$ sass --style compressed src/sass:dist/css

4. watch

watch 옵션은 scss 파일의 변경을 감지하여 변경될 때마다 scss 파일을 트랜스파일링하여 css 파일을 자동 업데이트한다.

$ sass --watch src/sass:dist/css

4. SASS vs SCSS

Sass에는 SASS 표기법(.sass)과 SCSS 표기법(.scss)이 있다. 이전 버전에서는 SASS 표기법이 기본 표기법이었으나 Sass3.0 부터 CSS 친화적인 SCSS 표기법이 기본 표기법이 되었다.

이전 글: [ES6] let, const와 블록 레벨 스코프 (1)

ECMA Script 6: let, const와 블록 레벨 스코프

1. const

const는 상수(변하지 않는 값)를 위해 사용한다. 하지만 반드시 상수만을 위해 사용하지는 않는다. const의 특징은 let과 대부분 동일하다. let과 다른 점만 살펴보겠다.

1. 선언과 초기화

let은 재할당이 자유로우나 const는 재할당이 금지된다.

const FOO = 123;
FOO = 456; // TypeError: Assignment to constant variable

주의할 점은 const는 반드시 선언과 동시에 할당이 이루어져야 한다는 것이다. 그렇지 않으면 다음처럼 문법 에러(SyntaxError)가 발생한다.

const FOO; // SyntaxError: Missing initailizer in const declaration

또한, const는 let과 마찬가지로 블록 레벨 스코프를 갖는다.

{
  const FOO = 10;
  console.log(FOO); // 10
}
console.log(FOO); // ReferenceError: FOO is not defined

2. 상수

상수는 가독성과 유지보수의 편의를 위해 적극적으로 사용해야 한다. 적절한 네이밍으로 상수를 선언하면 가독성과 유지보수성이 향상된다.

// 10의 의미를 알기 어렵기 때문에 가독성이 좋지 않다.
if (rows > 10) {
}

// 값의 의미를 명확히 기술하여 가독성 향상
const MAXROWS = 10;
if (rows > MAXROWS) {
}

const는 객체에도 사용할 수 있다. 물론 이때도 재할당은 금지

const obj = { foo: 123 };
obj = { bar: 456 }; // TypeError: Assignment to constant variable

3. const와 객체

const는 재할당이 금지된다. 이는 const 변수의 타입이 객체인 경우, 객체에 대한 참조를 변경하지 못한다는 것을 의미한다. 하지만 이때 객체의 프로퍼티는 보호되지 않는다. 다시 말하자면 재할당은 불가능하지만 할당된 객체의 내용(프로퍼티의 추가, 삭제, 변경)을 변경할 수 있다.

const user = { name: 'Kim' };

// const 변수는 재할당이 금지
// user = {}; // TypeError: Assignment to constant variable

// 객체의 내용은 변경할 수 있다.
user.name = 'Lee';

console.log(user); // { name: 'Lee' }

객체의 내용이 변경되더라도 객체 타입 변수에 할당된 주소값은 변경되지 않는다. 따라서 객체 타입 변수 선언에는 const를 사용하는 것이 좋다. 만약에 명시적으로 객체 타입 변수의 주소값을 재할당하여야 한다면 let을 사용한다.

3. var vs let vs const

- 변수 선언에는 기본적으로 const를 사용하고 let은 재할당이 필요한 경우에 한정하여 사용하는 것이 좋다.

- 원시 값의 경우, 가급적 상수를 사용하는 편이 좋다. 

- 객체를 재할당하는 경우는 흔하지 않기 때문에 const 키워드를 사용하여 의도치 않은 재할당을 방지하여 안전하게 사용하자.

- ES6를 사용한다면 var 키워드는 사용하지 않는다.

- 재할당이 필요한 경우에 한정해 let 키워드를 사용한다. 이때 변수의 스코프는 최대한 좁게 만든다.

- 변경이 발생하지 않아 재할당이 필요없는 원시 값과 객체에는 const 키워드를 사용한다. const 키워드만 재할당을 금지하므로 var, let보다 안전하다.

# 변경 가능성을 최소화하라.

## 불변 클래스(Immutable Class) ?

- 해당 객체의 내부적인 값들을 변경할 수 없는 클래스를 의미한다. 불변 클래스는 해당 객체가 파괴되는 순간까지 절대 달라지지 않는다.

- 불변 클래스는 가변 클래스보다 설계하고 구현하기 쉽고, side-effect로부터 안전

- 예) String, Wrapper Class, BigInteger, BigDecimal - 설계 구현 사용이 쉽다.

- 오류의 여지가 적고 안전하다.

## 1. 불변 클래스의 5가지 규칙

1) 객체의 상태를 변경하는 메서드(변경자, setter)를 제공하지 않는다.

2) 클래스를 확장할 수 없게 한다. - extend (X)

3) 모든 필드를 final로 선언한다.

4) 모든 필드를 private로 선언한다.

5) 자신 외에는 내부의 가변 컴포넌트에 접근할 수 없도록 한다.

## 2. 불변 객체의 장점

0) 단순

- 불변 객체는 생성된 시점부터 파괴될 때까지 그대로 유지한다.

1) 근본적으로 스레드에 안전

- 여러 스레드가 동시에 사용해도 불변 객체이기 때문에 다른 스레드에 영향을 주지 않아 안전하게 공유하고 사용할 수 있다.

- 동기화할 필요가 없다.

2) 불변 객체는 안심하고 공유가 가능

- 스레드 간 영향을 주고 받을 수 없기 때문

- 방어적 복사도 필요없다> clone 메서드 복사 생성자 필요 없다.

- String 클래스의 복사 생성자는 되도록 사용하지 말자

3) 한번 만든 인스턴스는 최대한 재활용이 가능

- 자주 사용하는 인스턴스를 생성하여, 정적 팩터리를 제공할 수 있다.

4) 불변 객체는 자유롭게 공유할 수 있음은 물론, 불변 객체끼리는 내부 데이터를 공유할 수 있음

5) 객체를 만들 때 다른 불변 객체들을 구성요소로 사용하면 이점이 많다.

- 구조가 복잡해도 불변식 유지가 수월

6) 불변 객체는 그 자체로 실패 원자성을 제공한다.

- 실패 원자성: 메서드에서 예외가 발생한 후에도 그 객체는 메서드 호출 전 상태와 같은 유효한 상태를 가진다.

## 3. 불변 객체의 단점

- 값이 다르면 반드시 독립된 객체로 만들어야 한다. 값의 가짓수가 많으면 이를 모두 만드는데 큰 비용이 필요하다.

1) 흔히 쓰일 다단계 연산들이 예측이 될 때

- 다단계 연산 속도를 높여주는 가변 동반 클래스를 package-privated로 둔다.

- BigInteger는 연산 속도를 높여주는 동반 클래스로 package-privated로 되어있는 MutableBigInteger/SignedMutableBigInteger/BigSieve를 사용할 것으로 예상

2) 예측이 되지 않을 때

- 다단계 연산 속도를 높여주는 가변 동반 클래스를 public으로 둔다.

- 예) StringBuilder/StringBuffer: String 클래스의 연산 속도를 높이기 위함

## 4. 불변 클래스를 만드는 설계 방법

1. final 클래스로 상속을 막는다.

2. 정적 팩터리를 제공하는 방법

- 모든 생성자를 private 혹은 package-private로 만들고 public 정적 팩터리를 제공한다. (캐싱 기능 추가도 가능하다.) public이나 protected 생성자가 없으니 다른 패키지에서는 이 클래스를 확장하는 게 불가능하기 때문이다.

## 정리

- 모든 클래스를 불변으로 만들 수는 없기 때문에 클래스라도 변경 가능한 부분을 최소한으로 줄이는 것이 좋다.

- 클래스가 꼭 필요한 경우가 아니면 불변이어야 한다.

- 다른 합당한 이유가 없다면 모든 필드는 private final이어야 한다.

- 생성자는 불변식 설정이 모두 완료된 초기화가 완벽히 끝난 상태의 객체를 생성해야 한다.