왜 변수 네이밍 컨벤션을 본문에 실었는지...?(내용은 괜찮으나 책의 주제와 연관관계가 강해보이지 않음)
별점
4.3/5.0(체계 있는 본문의 구성, 심도가 있음, 추천+)
대상 독자
작문의 질 향상을 원하는 인원(Best)
블로그를 시작하는 주니어 개발자
선행 도서
없음
관련 도서
개발자를 위한 글쓰기 가이드
느낀 점
해당 서적은 오류 문구 정의, 가이드 문서 작성, 장애 보고서 작성 등의 중요 문서 작성 후 검토할 때 많이 참고할 것 같다. 그만큼 본문의 구성은 깊이가 있다. 좋은 문서를 작성할 수 있도록 안내해주는 종합 지침서의 느낌을 받았다. 필자의 표현이 너무 추상적이다. 어떻게 종합 지침을 하였는지 서술하겠다. 해당 서적의 파트 중 하나인 "릴리스 노트 작성법"을 축약하였다. 대강 저자는 아래와 같이 최종 문서를 어떻게 구성하는지 상세하게 설명한다.
프로젝트의 개선/릴리스 내역 정리
내역의 중요도 분류
내역의 주제별 분류
사용자 관점, 문구 수정
문구 요약
문서 틀에 맞게 적재적소 문구 삽입
끝으로 개발자와 글쓰기의 연관관계를 정리한다. 전적으로 필자의 생각이다. 좋은 개발자의 요소 중 하나는 테크니컬 라이팅 능력이다. 주요 골자는 소통이다. "페이퍼를 이용한 소통". 개발자는 명세서, 설계서, 분석서 등의 문서들을 활용하여 기술과 프로젝트 정보를 효율적으로 전달해야 한다. 소통이 왜 필요해요? 소통은 문제 해결을 위한 선행 행위다. 그래서 개발자에게 있어, 문서 작성 능력은 선택 사항이 아닌 필수 사항이다. 필자가 중요하게 생각하는 문서 작성 능력은 다음과 같다.
사용자 관점에 맞는 문서 구조화 능력
쉽게 얘기하면 문서는 객체 지향 개발 방법론의 "객체" 처럼 구조적이었으면 좋겠다. 객체처럼 역할, 책임, 상태, 행위가 있고 이를 통해 상호 협력(소통)을 할 수 있으면 비로소 그것은 좋은 문서가 아닐까 생각한다.
본 게시물은Vault 공식 문서의 내용과 필자의 생각을 정리하였다. Vault는 무엇인지, 어디에 사용하는지, 왜 사용하는지, 어떻게 사용하는지 서술한다. Vault를 처음 접하는 인원은 Vault의 흐름과 골격을 이해할 수 있는 시간을 갖는다. 또한 Vault를 실질적으로 사용해보는 시간을 갖는다. Vault는 Dev 서버 모드를 지원한다. Dev 서버 모드는 사전 설정이 되어있는 데모 서버라고 생각하면 좋다. 사용자는 해당 데모 서버에서 Vault를 학습할 수 있다. 시간이 괜찮으면 Vault HA를 구성한다(시간이 있으면...).
hashicorp사의 Vault(볼트) - Java-Spring With Vault - 6
Vault Docker 환경 구성
[개요]
yum 패키지 설치 기능을 사용하여 Vault 환경을 구성할 수 있다. 이번에는 Docker를 활용하여 Vault 환경을 구성한다. 해당 환경을 구성하기 위해 Docker는 당연히 사용하며, Docker-Compose까지 사용한다. 디렉토리의 구조는 아래와 같다. 환경 구성 후 가동 및 테스트 API만 호출한다.
본 게시물은Vault 공식 문서의 내용과 필자의 생각을 정리하였다. Vault는 무엇인지, 어디에 사용하는지, 왜 사용하는지, 어떻게 사용하는지 서술한다. Vault를 처음 접하는 인원은 Vault의 흐름과 골격을 이해할 수 있는 시간을 갖는다. 또한 Vault를 실질적으로 사용해보는 시간을 갖는다. Vault는 Dev 서버 모드를 지원한다. Dev 서버 모드는 사전 설정이 되어있는 데모 서버라고 생각하면 좋다. 사용자는 해당 데모 서버에서 Vault를 학습할 수 있다. 시간이 괜찮으면 Vault HA를 구성한다(시간이 있으면...).
$vi ./.bash_profile
VAULT_ADDR='http://127.0.0.1:8200'
export VAULT_ADDR
$source ./.bash_profile
// 또는
$ export VAULT_ADDR='http://127.0.0.1:8200'
// 확인
$set | grep VAULT_ADDR
[Vault 서버 가동 및 초기화]
Vault 서버 가동
"-config"에는 config.hcl의 경로를 지정한다.
$vault server -config=/home1/irteamsu/vault/config.hcl &
Vault 서버 초기화 및 Unsealing
Vault 서버 가동 후 최초 1회 초기화 작업을 진행한다. 해당 초기화 작업으로 Vault 설정정보에 따라 SSS 분할키와 Root 토큰을 생성한다. 별도의 설정 정보가 없을 경우 threshold는 (3, 5)이다. 즉 5개의 분할키를 부여하며, 원본을 만들기 위해서는 최소 3개의 분할키가 필요하다. 필자의 경우 프로덕트 환경이 아니기 때문에 아래의 분할키와 Root 토큰을 keyinfo.txt 파일에 보관하였다.
$vault operator init
2021-06-15T16:43:36.202+0900 [INFO] core: pre-seal teardown complete
Unseal Key 1: Iv9H20vmAUMkDaAfyuar2rSWyGnZgvBOhQPl7df4lrib
Unseal Key 2: G7SnjSZPOaZwkMX9rvCyK8ssdoIMAdAYu+oDo1b9uZ+j
Unseal Key 3: jNfpkii4QiJsuIUVwkuIm1jjIz+bzh5oalsfevXGs5Wc
Unseal Key 4: NnruCilytFhgdQ4zCQmKeSrrV4e8Ijws663trVHAamyl
Unseal Key 5: pqb+bP30/wAraxLITsnjza1ibDyqKIcAHTEZkDzf902W
Initial Root Token: s.ZPBA2pFTJEtmlaUfIEHk1Lq6
Vault initialized with 5 key shares and a key threshold of 3. Please securely
distribute the key shares printed above. When the Vault is re-sealed,
restarted, or stopped, you must supply at least 3 of these keys to unseal it
before it can start servicing requests.
Vault does not store the generated master key. Without at least 3 key to
reconstruct the master key, Vault will remain permanently sealed!
It is possible to generate new unseal keys, provided you have a quorum of
existing unseal keys shares. See "vault operator rekey" for more information.
서버 가동, 초기화 작업을 완료하였다. 그러나 Vault는 아직 "Sealed" 상태이다. 위의 분할키는 Vault의 상태를 "Unsealed" 상태로 전이할 수 있다.
위의 작업을 완료하면 Sealed false 값을 확인할 수 있다. Root 토큰으로 로그인한 사용자는 "vault operator seal" 명령을 사용하여 Vault 서버에 Sealing을 할 수 있다. root 사용자의 경우, vault operator seal을 통해 sealing을 다시 할 수 있다. 이제 Vault를 마음껏 사용할 수 있다.
[Vault 가동 스크립트 작성]
Vault를 기동할 때 "Unsealing" 절차는 필수이다. 해당 절차의 편리를 위해 스크립트를 작성한다. 스크립트는 아래와 같다.
start.sh
#!/bin/bash
partOfKey1=$1
partOfKey2=$2
partOfKey3=$3
if [ "$#" != 3 ]
then
echo "argument is not 3"
exit
else
vault server -config=/home1/irteamsu/vault/config.hcl &
sleep 1
echo -ne '\n'
vault operator unseal $1
vault operator unseal $2
vault operator unseal $3
fi
stop.sh
#!/bin/bash
pid=`ps aux | grep 'vault server' | grep -v grep | awk '{print $2}'`
if [ -z "$pid" ]
then
echo "server is not running"
else
echo "shutdown..."
kill -9 $pid
fi
추가 분기를 사용하여 kill -9, -15 옵션을 결정할 수 있다. 필자는 그냥 "-9"를 사용하였다. 프로덕트 환경의 경우, "-15" 옵션을 위한 분기 사용을 권한다.
$curl \
--header "X-Vault-Token: $VAULT_TOKEN" \
--request PUT \
--data '{"policy":"# Dev servers have version 2 of KV secrets engine mounted by default, so will\n# need these paths to grant permissions:\npath \"secret/data/*\" {\n capabilities = [\"create\", \"update\"]\n}\n\npath \"secret/data/foo\" {\n capabilities = [\"read\"]\n}\n"}' \
-D - http://127.0.0.1:8200/v1/sys/policies/acl/my-policy
이렇게 Dev 모드가 아닌 실제 서버를 설정하였다. 해당 서버는 vault 커맨드를 사용하여 제어할 수 있으며, REST API를 사용하여 제어할 수 있다. 본 게시글은 curl 명령과 함께 REST API를 사용하였다. 실질적으로 프로덕션 레벨에서는 클라이언트 토큰을 생성 후, Secret을 제어하는 것이다. 해당 사항은 Java/Spring환경을 구성한 후 테스트 예정이다.
본 게시물은Vault 공식 문서의 내용과 필자의 생각을 정리하였다. Vault는 무엇인지, 어디에 사용하는지, 왜 사용하는지, 어떻게 사용하는지 서술한다. Vault를 처음 접하는 인원은 Vault의 흐름과 골격을 이해할 수 있는 시간을 갖는다. 또한 Vault를 실질적으로 사용해보는 시간을 갖는다. Vault는 Dev 서버 모드를 지원한다. Dev 서버 모드는 사전 설정이 되어있는 데모 서버라고 생각하면 좋다. 사용자는 해당 데모 서버에서 Vault를 학습할 수 있다. 시간이 괜찮으면 Vault HA를 구성한다(시간이 있으면...).
$vault policy list
$vault policy read default
$vault policy write my-policy - << EOF
# Dev servers have version 2 of KV secrets engine mounted by default, so will
# need these paths to grant permissions:
path "secret/data/*" {
capabilities = ["create", "update"]
}
path "secret/data/foo" {
capabilities = ["read"]
}
EOF
$vault token lookup
$vault token create -policy=my-policy
$export VAULT_TOKEN="$(vault token create -field token -policy=my-policy)"
$vault kv put secret/creds password="my-long-password"
$vault kv put secret/creds password="my-long-password-1"
$vault kv get secret/creds //(안됨)
$export VAULT_TOKEN="s.kZw14yyEbEIkDSRRSLEsVM8M" //(root 토큰)
$vault kv get secret/creds(됨)
설명
토큰 생성 시 정책을 적용할 수 있다.
정책은 Secret에 대해 접근제어를 실시한다.
정책 "my-policy의 설명은 다음과 같다.
"secret/data 이하의 경로에 대해 create와 update 작업을 실시할 수 있다(udpate는 put을 통한 갱신 작업).
"secret/data/foo에 해당하는 경로는 read 작업을 실시할 수 있다.
다음의 설명은 생략한다.
[Vault 사용 - AppRole]
위의 "토큰 생성" 부분에서 Vault는 사용자의 토큰을 인증 절차 없이 생성한다. 이유는 다음과 같다. 현재 적용된 토큰은 "루트 토큰"이다. 그래서 인증 절차 없이 사용자의 토큰을 생성할 수 있다. 그러나 일반적인 상황에서는 인증 절차가 필요하다. 대표적인 인증 절차는 ID/PW 방식을 사용할 수 있다. Vault의 AppRole은 식별값(ID)/인증값(PW)을 이용해서 토큰을 발급한다. 또한 정책을 적용할 수 있으며, 토큰에 적용 가능하다.
// approle 확인
$vault auth list | grep 'approle/'
// 리스트업이 되지 않을 경우, approle 활성화
$vault auth enable approle
// approle 확인
$vault auth list | grep 'aaprole/'
//approle에 my-role(사용자) 생성
$vault write auth/approle/role/my-role \
secret_id_ttl=10m \
token_num_uses=10 \
token_ttl=20m \
token_max_ttl=30m \
secret_id_num_uses=40 \
token_policies=my-policy
// approle 조회
$vault list auth/approle/role
$vault read auth/approle/role/my-role
$vault read auth/approle/role/my-role/role-id
$vault read -field=role_id auth/approle/role/my-role/role-id
// ROLE_ID(식별자) 환경 변수 적용 및 조회
$export ROLE_ID="$(vault read -field=role_id auth/approle/role/my-role/role-id)"
$set | grep -e VAULT -e ROLE_ID
// SECRET_ID 설정(AppRole 인증을 위한 비밀번호 개념과 비슷하다.)
// SECRET_ID(인증값) 환경 변수 적용 및 조회
// vault write를 별도로 진행해도 괜찮다.
$export SECRET_ID="$(vault write -f -field=secret_id auth/approle/role/my-role/secret-id)"
$set | grep -e SECRET_ID -e VAULT -e ROLE_ID
// 토큰 요청
// approle 인증 완료 후, 토큰을 반환받을 수 있다.
$vault write auth/approle/login role_id="$ROLE_ID" secret_id="$SECRET_ID"
필자는 항상 개발과 글쓰기를 동반하였다. 동향 조사, 설계 문서, 가이드 문서 등의 작성을 필수라고 생각하였으며 작성하는 것은 부담이 없었다. 시간이 지나, 필자가 글을 잘 쓰는지? 검증의 작업이 필요했다. 검증은 위와 같이 책으로 진행하였다. 결과는 참패. 필자는 글을 못 쓴다. 필자의 나쁜 버릇은 다음과 같다.
~통해, ~대해, ~이용하여
피동태
복잡한 번역체 느낌
간결하지 않은 문장
적은 시간의 검토와 재작성
또한 필자는 2년 전에 블로그에 작성한 글을 보고 놀랐다. 손이 발이 되는 작문력이다. 끔찍하다.
글 쓰는 것은 추가 연구가 필요하다. 기술 문서 또는 책을 볼 때 "문장 구성"을 같이 봐야겠다. 좋은 "문장 구성"은 스크랩하여 레퍼런스로 활용해야겠다.
본 게시물은 Vault 공식 문서의 내용과 필자의 생각을 정리하였다. Vault는 무엇인지, 어디에 사용하는지, 왜 사용하는지, 어떻게 사용하는지 서술한다. Vault를 처음 접하는 인원은 Vault의 흐름과 골격을 이해할 수 있는 시간을 갖는다. 또한 Vault를 실질적으로 사용해보는 시간을 갖는다. Vault는 Dev 서버 모드를 지원한다. Dev 서버 모드는 사전 설정이 되어있는 데모 서버라고 생각하면 좋다. 사용자는 해당 데모 서버에서 Vault를 학습할 수 있다. 시간이 괜찮으면 Vault HA를 구성한다(시간이 있으면...).
hashicorp사의 Vault(볼트) - Java-Spring With Vault - 6
개요
HashiCorp의 Vault는 민감한 데이터를 안전하게 저장하는 저장소이다. 민감한 데이터의 종류는 다음과 같다. 1)Secret 2)Credential 3)Password 4)Enctyption-Key 등이다. 이와 같이 기밀성이 요구되는 정보는 DBMS에 단순 저장하면 안 된다. Vault는 위의 개체들을 암호화하여 안전하게 저장한다.
용어 정의
Storage Backend
Vault의 암호화된 Secret을 보관하는 곳이다.
Barrier
Barrier는 Vault의 일부 구성요소를 감싸고 있다. 때문에 Vault와 Storage Backend 간의 통신은 Barrier를 거쳐야 하며, Barrier가 프록시 역할(대문 역할)을 한다. Barrier의 구성요소들은 서로 Trust 한 관계를 유지/성립한다.
Vault는 암호화된 데이터만 밖으로 나오게 한다.
Vault는 Barrier의 상태가 “unsealed”가 되어야 접근할 수 있다.
Secret Engine
Secret의 관리를 책임진다.
Secret 관련 작업은 Secret Engine으로 전달하고 Engine의 구현체마다 상이한 방식으로 저장한다.
Secret Engine의 인터페이스를 활용하여 DB, File System 또는 유저가 정의한 방식으로 저장한다.
Audit Device
모든 Vault의 Request/Respones는 Audit Device에 의해 감사 로깅이 된다.
Auth Method
Vault에 접근하는 클라이언트를 인증한다.
인증된 클라이언트의 토큰을 반환한다.
Client Token
HTTP에서의 세션 ID와 같은 토큰을 반환한다.
Vault의 REST API를 사용하는 경우 HTTP 헤더에 토큰을 적재한다.
Secret
Vault에서 관리하는 비밀 객체이다.
Secret은 일정 주기를 가지며, 해당 주기가 만료되면 폐기해야 한다.
아키텍처 개요
High level overview of vault
[전체 흐름]
Vault는 기밀성이 요구되는 데이터(이하 Secret)를 안전하게 보관하는 저장소이다. Vault를 사용하기 위해서는 “unsealing”과초기화 작업이 필요하다. Vault 서버 초기화 시 Vault는 “sealed” 상태이다. “Unsealed-Key”는 “sealed” 상태를 “unsealed” 상태로 전이할 수 있다. “unsealed” 상태가 되면 Barrier안에 있는 Vault의 모든 기능 및 구성요소에 원활하게 접근할 수 있다.
Vault에서 실질적으로 Secret을 암/복호화하는 키는 "Encryption-Key"이다.
“Encryption-Key”는“Secret”을 안전하게 암/복호화한다. “Secret”들은 “Storage backend”에 보관하며, “Secret”에 접근하기 위해서는 REST API를 사용한다. REST API는 Create, Register, Rotate, Destroy 등의 명령을 제공하며, "Secret"을 제어할 수 있다. REST API를 사용하기 위해서는 "토큰 인증"과 "토큰에 상응하는 정책 인가" 작업이 필요하다.
[고가용성]
Vault는 HA를 구성할 수 있다. HA의 구조는 Active-Standby 구조이다. 오픈 소스 버전의 경우 Standby는 Read-Only 기능을 제공하지 않는다. Standby에 요청이 들어오면 요청을 Active에 포워딩한다. Read-Only 기능은 엔터프라이즈에서 제공한다. 그래도 오픈 소스 버전에서 Hot-Standby를 제공하기 때문에 Failover는 문제없다. 제일 큰 단점은 Standby의 read-only의 미지원이다. Product 레벨에서 Vault를 사용하기 위해서는 해당 기능이 제일 필요할 것 같다.
Replication 방식은 PostgreSQL의 방식과 같이 Active-Standby 구성이며, Active의 변경/추가/삭제된 것에 대한 로그(WAL, Write Ahead Log)를 Standby에 전송한다. 데이터 처리에 있어 보통의 DBMS과 같이 WAL 기법을 사용하는 것 같다.
[보안 특성]
Vault와 클라이언트 상호 인증은 제공하지 않는다. 다만 서버에서 제공하는 네트워크 계층 보안, TLS를 제공한다.
정상 토큰을 보유한 주체는 리소스("Secret")에 접근할 수 있다.
토큰 인가 정책은 리소스에 접근하는 주체를 제어한다.
Secret에 접근하는 모든 행위를 감사 로깅한다.
"Secret"을 암호화하여 Storage Backend에 저장한다.
Vault의 Barrier를 통과하는 모든 요청과 반환은 AES-256(GCM)으로 암호화한다. IV의 경우, 자동으로 임의로 생성한다.
SSS(Shamir Secret Sharing) 알고리즘으로 MasterKey를 분리 보관한다.
[Key 회전(갱신)]
rekey 명령은 Unsealed-Key와 Master-Key를 갱신한다. 갱신된 Master-Key는 Encryption-Key를 재암호화하며,갱신된 Unsealed-Key는 SSS에 의해 다시 분리하여 보관하여야 한다.
rotate 명령은 Encryption-Key를 갱신한다. 기존 Encryption-Key는 별도의 keyring에 보관한다. 후의 요청들은 새로운 Encryption-Key로 암호화를 한다. Keyring에 있는 Encryption-Key는 복호화 용도에만 사용한다. 이와 같이 사용하면 re-encryption을 수행하지 않아도 괜찮다(keyring에 예전 Encryption-Key를 다 보관하고 있다. 갱신에 의미가 있나?).
[정책]
사용자는 Identifier/Authentication값을 요청한다. 요청 성공 시 토큰을 반환받는다. 해당 토큰은 다음과 같이 화이트 리스트 정책을 갖고 있다
# This section grants all access on "secret/*". Further restrictions can be # applied to this broad policy, as shown below. path "secret/*" { capabilities = ["create", "read", "update", "delete", "list"] } # Permit reading secret/foo/bar/teamb, secret/bar/foo/teamb, etc. path "secret/+/+/teamb" { capabilities = ["read"] } # Policies can also specify allowed, disallowed, and required parameters. Here # the key "secret/restricted" can only contain "foo" (any value) and "bar" (one # of "zip" or "zap"). path "secret/restricted" { capabilities = ["create"] allowed_parameters = { "foo" = [] "bar" = ["zip", "zap"] } }
본 시리즈는 이직을 하기까지에 대한 모든 생각과 일어난 현상 그리고 느낀 점을 기재한 사항이다. 해당 시리즈에서 언급되는 회사들은 감히 필자가 왈가왈부할 수 없는 회사이다. 단순 연봉, 그 이상의 가치를 실현할 수 있고, 필자한테는 과분한 좋은 회사들이다. 공개정보만 기재하는 것을 원칙으로 진행할 것이며 Private한 정보는 추상화할 것이다.
먼저, 해당 시리즈는 원하는 회사 또는 대기업을 신입 공채로 들어간 훌륭한 인재한테는 해당사항이 없는 시리즈이다.
2021년 6월 초 입사를 하였다. 입사는 매주 월요일에 가능했고 출근 일은 오전 10시 30분이다. 아침에 자택에서 가볍게 나왔지만 첫날부터 지각할 뻔했다. 분명 네이버 지도는 1시간을 얘기했는데 1시간 20분이 걸렸다. 그래도 다행이다!!! 회사에 25분에 도착했다. 숨 돌리고 해당 일 입사자들과 함께 인사과에서 진행해주는 OT를 진행하였다. 입사 전부터, OT를 하면서, 지금까지 필자가 하는 똑같이 하는 말 "미쳤다. 미쳤어. 세상에!", 필자가 강원도에서 살다 상경했을 때의 필자 모습을 여기서 보고 있었다. 필자는 아직까지 회사에서 촌놈 딱지를 떼지 못 한 기분이 든다. 이와 같은 기분을 이런 주관을 객관화하기 위해 필자가 회사에 입사해서 지금까지의 장점으로 생각하는 항목을 간략하게 개괄식으로 나열하고자 한다.
회사의 장점
참고로 필자는 촌놈이다. 타인이 당연하게 생각하는 것을 필자는 당연하게 생각하지 않을 수 있다.
요약: 미쳤다.
처우(연봉, 복지)가 미쳤다.
입사 전 기기 구매 금액의 할당과 장비 선택권을 부여받아 놀랐다.
진정한 탄력 근무제이다(자율적인 근무 지원).
22시~6시를 제외한 탄력근무 가능
8시 출근 14시 퇴근 가능
9시 출근 21시 퇴근 가능
한 달 근무 시간만 채우면 됨(8시간 * 5일 * 4주), 휴게 시간도 자유
위의 탄력 근무제를 통해 회사는약간의 손해를 보더라도다수의 업무 효율성을 재고해주는 느낌을 받음.
회사의 이런 신뢰를 진심으로 존중하여 제대로 이행을 할 것이다.
사내 개발 플랫폼(개발 플랫폼은 진짜 시리즈 연재가 필요할 정도다.)
IntelliJ 사용 가능(진짜 좋다. 상용 소프트웨어 구매 지원. 벌써 2개 구매했다!!! 학교 계정 ㅂㅂ!!)
wiki의 존재(축적된 노하우)
사내 정기/상시 기술 세미나/컨퍼런스의 존재
사내 교육 플랫폼 제공(개발자 상호 교육 인프라 구성)
쾌적한 사무실, 좌석별 파티션 존재, 나뭇잎 지붕 제공
사원증이 있다. 활용할 곳이 많다!
사내 카페가 있다!
기술 스터디 게시판의 존재(진짜 좋아)
외국어 스터디 게시판의 존재
온라인/오프라인 교육비의 지원
아침 준다ㅠㅠㅠ
아 충성 충성!!!!!!!!!
느낀 점
충성을 다 하겠습니다.
필자는 단 기간 회사에서 받은 느낀 점은 다음과 같다. "개발자의 원활한 과업 수행 및 달성, 그리고 개발자의 성장" 이 사항에 초점에 맞추어 모든 인프라가 생긴 것 같다. 그리고 구성원들의 노력에 의해 만들어진 것 같다. 정말 필자가 원하던 개발자 문화가 존재한다. 필자가 생각하는 개발자 문화는 기술의 공유, 배움의 열정, 개발 플랫폼의 존재 등이 있다. 현재 이와 같은 장점들로 인해 뽕을 다량으로 취했다. 좋은 개발자 문화 인프라에 푹 빠져버렸다. 이 뽕이 언제 빠질지 모르겠지만 해당 근간과 기반을 충분히 활용하여 열심히 일하고 꾸준히 공부해야겠다!!!
마무리 - 6개월을 향해
해당 시리즈의 막은 6개월 후이다. 6개월 후 회사에 적응하여 6개월의 느낌과 상황을 마지막 시리즈에 서술할 예정이다. 필자는 적응하기 위해 무조건 절대로 노력할 것이다. 그리고 일을 잘하기 위해 꾸준히 공부할 것이다. 6개월 후에 다음의 약속을 지키고 싶다.
메인 업무, 서브 업무 적응 완료
IT 북스터디 1권 완료(그룹)
북스터디 1권 완료(싱글)
이렇게... 필자는 [5년/10년/15년] 중장기 목표 중 5년을 달성했다. 다음의 [5년/10년/15년] 중장기 목표 달성을 위해 필자는 6개월 후에(업무 적응 후에) 외국어 스터디를 꾸준히 진행할 예정이다. 힘내자!!! 파이팅이다!!!
본 시리즈는 이직을 하기까지에 대한 모든 생각과 일어난 현상 그리고 느낀 점을 기재한 사항이다. 해당 시리즈에서 언급되는 회사들은 감히 필자가 왈가왈부할 수 없는 회사이다. 단순 연봉, 그 이상의 가치를 실현할 수 있고, 필자한테는 과분한 좋은 회사들이다. 공개정보만 기재하는 것을 원칙으로 진행할 것이며 Private한 정보는 추상화할 것이다.
먼저, 해당 시리즈는 원하는 회사 또는 대기업을 신입 공채로 들어간 훌륭한 인재한테는 해당사항이 없는 시리즈이다.
필자의 첫 회사이다. 대략 5년 가까이 근무했다. 좋은 사람들이랑 재밌게 일 했다. 웃긴 일도 서러운 일도 보람찬 일도 많았다. 많은 사람들과 다양한 상황들을 마주하면서 같이 근무했다. 좋은 인연도 있었고 좋지 못한 인연도 있었다. 이렇게 필자가 걸어온 길을 뒤돌아보면서, 필자의 발자취를 보면 만감과 희비가 교차한다. 솔직히 쓸 내용이 많지 않을 것 같아서 해당 본문을 시리즈에 넣을지에 대한 여부를 많이 고민했다. 그래도 필자와 5년은 함께한 곳인데 짧게나마 필자의 여운을 살포시 글에 남으면 그것 또한 좋지 않을까 생각이 든다.
돌아보며
회사 생활하면서 많은 사람과 재밌게 일 했고 감사드리지만 필자의 사수였던 팀장이었던 우리 팀장님이 제일 기억에 남는다. 항상 필자를 응원해주신 고마운 분이다. 항상 기술적으로 더 많은 것을 알 수 있도록 도와주셨고, 회사의 한도 내에 어떻게든 모든 것을 지원해주시려고 많은 노력을 해주셨다. 너무 좋은 분이다. 필자에게 "필자는 더 좋은 곳에서, 더 넓은 곳에서 다양한 사람들과 일 했으면 하는 바람이 크다. 꾸준히 준비해서 이직을 잘했으면 좋겠다." 이런 말씀을 매번 해주셨다. 필자가 여기까지 올 수 있었던 것은 주변의 많은 친지인들 께서 도와주신 것도 있지만 우리 팀장님의 응원이 제일 크다 생각한다. 회사에서 좋은 사람들을 만나는 것은 정말 천운인데 필자는 그런 운을 가진 것 같다. 정말 좋은 분들을 만난 것 같다. 팀장님 뿐만 아니라, 내가 많이 괴롭혔던 우리 팀원들과 매번 뒤에서 묵묵히 봐주신 부서장님과 항상 코어 기술을 알려주신 코어팀 어르신들, 기술뿐만 아니라 인간적으로 많이 챙겨주셨다.
필자의 회사 생활을 평가하자면 "좀 아쉬운 부분이 존재하지만 대체적으로 열심히 잘 한것 같다!" 필자는 과업을 성공적으로 달성하기 위해 해당 과업에 정말 열심히 했으며, 필자의 역량 강화를 위해 꾸준히 공부하였다. 아직도 많이 부족하지만 계속 공부할 것이다. 다소 아쉬운 부분은 팀원을 제대로 챙기지 못한 부분과 감정적으로 행동한 부분이다. 타인에 대해 감정적으로 행동해서 관계를 망친 부분과 팀원을 좀 더 챙겨줬으면 하는 많은 아쉬운 점이 존재한다. 반면교사, 타산지석 다음에 이런 상황이 오면 절대 이전과 같은 상황을 만들지 말아야겠다.
아름답고 화려한 식기와 찻잔이라도 무엇을 담느냐에 따라 가치가 다르다. 허름하고 그지같은 바가지에 진수성찬이 함축된 수라를 담고 있으면 그 가치는 다르다. 그리고 위의 음식들을 음미하는 주체에 따라 모든 것이 결정된다. 필자는 다음과 같다.
거지가 바가지에 진수성찬이 함축된 음식을 맛 봤다.
필자의 회사를 욕하는 것이라 이해할 수 있다. 아니다. 다만 아쉬움을 표현하는 것이다. 진수성찬에 대해 존경과 존중을 표하며 진수성찬을 제대로 소화하지 못한 그릇에 아쉬움을 표할 뿐이다.
인수인계
필자를 많이 배려해줬다. 인수인계를 크게 진행하지 않고 필요 문서와 필요한 사항에 대해서만 인수인계를 진행했다. 그래도 필요한 것에 대해 문서화는 제대로 하고 갔으니 걱정은 안 하겠다만... 아마 그 문서를 이해하기 위해 많은 분석과 공부가 필요할 것이다... 이 이상의 걱정과 근심은 위선이다.
인수인계는 큰 어려움 없이 좋게 마무리됐고 필자는 퇴사를 하였다.
마무리
필자는 네이버 클라우드 최종 합격과 동시에 바로 직속상관들께 얘기했다. 위에서 언급한 팀장님은 퇴사한 지 한 달 정도 됐었다. 팀장님이 퇴사하기 전에 미리 팀원들에게 언질이라도 주라는 말씀을 하셨지만 그게 정말 쉽지 않았다. 미리 언질이라도 줬는데 이직이 물거품이 되고 실패로 치닫았을 때의 상황을 고려했어야 했다. 그러기 때문에 필자한테는 그럴 계제가 없었다. 이런 부분에 대해서는 이기적일 수밖에 없다 생각하며 필자는 이기적이어야 하는 게 맞다고 생각한다.
일주일이라도 더 쉬기 위해 처우 협의 시작도 안 했는데 바로 보고했고 보고는 빨리 이루어졌다. 휴가를 연달아 쓰고 싶지만 새로 들어온 필자의 부사수가 눈에 밟혀 그렇게 하지는 않았다. 주 2회 출근하며 신입 케어를 하다 퇴사하였다. 신입은 똑똑한 친구라 잘할 것 같다.
코로나19로 인해 많은 사람들과 동시에 자리를 갖지 못했다. 그래도 네 명씩 각개 격파를 하며 시간을 보냈다. 모든 사람과의 시간은 못 보낸 것 같다. 예기치 못한 일도 발생했거니와 시간 맞추는 게 쉽지는 않았다.
본 시리즈는 이직을 하기까지에 대한 모든 생각과 일어난 현상 그리고 느낀 점을 기재한 사항이다. 해당 시리즈에서 언급되는 회사들은 감히 필자가 왈가왈부할 수 없는 회사이다. 단순 연봉, 그 이상의 가치를 실현할 수 있고, 필자한테는 과분한 좋은 회사들이다. 공개정보만 기재하는 것을 원칙으로 진행할 것이며 Private한 정보는 추상화할 것이다.
먼저, 해당 시리즈는 원하는 회사 또는 대기업을 신입 공채로 들어간 훌륭한 인재한테는 해당사항이 없는 시리즈이다.
솔직히 네이버 클라우드는 NBP 때부터 유심히 봐온 기업 중 하나이다. 2018년 당시 필자는 특정 제품을 개발하고 있었다. 해당 제품의 경쟁 또는 선도 업체 제품들의 분석을 진행하고 있었다. 그중, NBP가 있었다. 그래서 한참 신기해서 이것저것 구경한 기억이 있다. 그때 당시 "네이버 본사, 카카오 본사 떨어지면 그다음 바로 여기 지원해 봐야지!!!" 이런 되지도 않는 생각과 함께 해당 회사를 Wish-List에 추가하였다. 뭐 결국에는 네이버 본사는 지원도 안 했고, 생각과 다르게 판단하고 결정했으니... 사람 일, 모르는 것 같다 ㅋㅋㅋㅋㅋ!!
필자는 네이버 클라우드를 Wish-List에 추가한 이유는 다음과 같다.
필자가 하고 있는 제품을 솔루션이 아닌 SaaS 서비스로 출시했기 때문이다.
부가적인 이유는 아래와 같다.
솔루션이 아닌 서비스를 개발하고 싶었다. 운영 환경을 경험하고 싶었고 대용량 트래픽을 경험하고 싶었다.
개발을 잘하는 동료들과 개발하고 싶었다.
3.5~4차 산업혁명에 준하는 기술을 배워보고 싶었다. 4차 산업 혁명 키워드 중에 수학, 통계 지식이 요구되지 않는 것은 클라우드이다. 그래서 클라우드 베이스, 서비스 개발을 하고 싶었다(병1신 같지만 진짜 저렇게 생각했다.).
IT 대기업 계열사이다. 때문에, IT 인프라, 개발자를 위한 체계가 좋을 것이라 생각했다.
2020년 6월 경 헤드헌터로부터 네이버 클라우드 면접 제의가 왔다. 시리즈 1의 설명과 같이 준비가 되지 않았고 해당 기회는 위기가 됐다. 그래서 진심, 다음을 기약하며 포기했다. 해당 헤드헌터의 메일은 따로 보관했다.
2021년 1월 이직 준비를 시작했고 1개월이 지난 시점, 해당 헤드 헌터한테 메일을 보냈다. 그러나 네이버 클라우드 인사가 바쁜 관계로 3~4월부터 진행이 가능하다고 답변이 왔다. 그러려니... 네이버 클라우드 채용 홈페이지, 백앤드 개발에 상시 지원 후 이직 준비를 계속했다. 그런데 말입니다. 3월 15일에 네이버 클라우드 채용 사이트에서 상시 채용 공고가 무더기로 올라왔다. 2018년 특정 제품을 개발한 그 팀에서 올린 공고도 같이 있었다(예상, 그러나 예상은 맞았다).
프로젝트는 실질적으로 내가 진행했고 거짓말 없이 경력기술서에 전부 기재했기 때문에 크게 막히는 것은 없었다. 가끔 경력 이직이 위의 질문에 대해 문제가 되는 경우가 존재한다. 해당 문제는 메타 인지 부족에서 비롯한다. 만약 본인은 해당 프로젝트를 A-Z까지 전부 진행했을 지라도 인터뷰어가 프로젝트의 일부분에 대한 질문 또는 요약을 요청하면 막상 제대로 답변 못 하는 경우가 존재할 수 있다. 머리는 알고 있는데 정리가 되지 않아서 그런 것이다. 이와 같은 이유로 인해 경력 이직자의 경우, 본인의 프로젝트, 과거 기록들을 쭉 훑어보고 리뷰 시간을 갖는 것을 권고한다.
과장이 딱 한 개 존재한다. "프로젝트 진행 인원을 과장했다." 이유는 다음과 같다. 필자의 '개발' 프로젝트는 거의 혼자 진행했다(20% 정도는 팀장님과 같이 진행). 초창기 1년 차에 팀장님이 많이 도와주셨다(설계 진행, 필자의 설계 검증, 서포트 라이브러리 개발). 그러나 2년 차부터는 설계 검증만 해주시고 그 외의 모든 사항은 필자가 맨땅에 헤딩하고 삽질하면서 혼자 개발했다.
과장의 이유는 다음과 같다.
프로젝트의 신뢰성 저하
필자의 협업 능력 저평가
[프로젝트의 신뢰성 저하]
정말 싫었다. 필자는 진짜 야근, 공부, 연구, 설계, 개발하며 어떻게든 멱살 잡고 진행해 온 프로젝트이다. 프로젝트가 마무리되어도 지속적인 리뉴얼을 통해 프로젝트를 개선하였다. 실질적으로 Product 됐고 납품도 꽤 됐다. 필자의 노력, 기술, 프로젝트의 모든 행보가 부정될 것 같은 기분이 들었다.
부정될 수 있는 이유는 다음과 같다. 어떠한 시스템을 개발했는데 혼자 개발했다고 하면 신뢰가 가는가? 필자는 신뢰보다는 의심을 할것 같다.
[필자의 협업 능력 저평가]
혼자 개발했다는 것은 협업을 하지 않은 것을 얘기한다. 협업/협력 소통을 안 했다는 것은 위의 사항보다 더 큰 얘기이다. 아무리 기술력이 좋고 일을 잘해도 협력/협업 소통이 안되면 모든 것이 의미가 없다. 위의 말마따나 필자가 협력/협업 소통을 안 한 것처럼 보이지만 아니다... 많이 했다... 단 프로젝트 개발에 대해서는 혼자 했지 그 외의 설치(납품), TF, 연구, 연구과제 등은 동료들과 협업을 많이 했고 소통도 많이 했다. 전문적이지는 않지만, 한 개의 나쁜 습관을 제외하면 협업 수준은 일반적이다.
======================
[1차 면접, 라이브 테스트]
네이버 클라우드는 코딩 테스트 없이 바로 1차 면접을 진행했다. 라이브 테스트가 존재하였다. 라이브 테스트 과정은 다음과 같다.
화면 공유 실시
특정 사이트 접속(웹 메모장)
메모장에서 문제 풀이(코드 작성)
코드 설명
필자의 경우, 문제는 디자인 패턴이었다. 다행히 필자가 알고 있는 패턴이 나왔다. 코드로 쭉 작성하고 설명을 했다. 실수 한 개를 했는데 그 실수는 구두 설명으로 커버를 쳤다. 괜찮은 경험이었다.
그리고!!!
1차 합격을 했다. 정-말 좋았다. 진짜 좋았다. 다른 회사들 전형은 솔직히 무감각했는데 네이버 클라우드만큼은 정말 기뻤다. 주변에 자랑하고 싶을 정도였다...!!!
1차 합격과 함께 두 가지 미션을 받았다. 인성 검사와 레퍼런스 체크 협조
레퍼런스 체크
레퍼런스 체크는 대행 기업이 존재하였다. 해당 기업의 상호가 정말 인상적이었다. 레퍼런스 체크를 진짜 잘할 것만 같은 상호이었다....ㅋㅋㅋㅋ!!!! 레퍼런스 체크 진행은 two way다.
주로 물어본 것은 프로젝트를 진짜 진행했는지와 단점, 장점, 협업 능력, 팔로우쉽, 리더십 등이다. 진짜 필자의 모든 면을 낱낱히 검증하였다.
레퍼런스 체크 대행사가 과연 비밀리에 어떻게 진행했는지 정말 궁금하다...
인성 검사
인성 검사로 인해 합/불 판단 기준은 있는지 없는지 모르겠다. 인성 검사 합/불 안내 메일은 없었고 바로 2차 면접 안내 메일을 받았다.
인성검사 방식은 현대자동차 HMAT 인성검사와 유사한 방식이다. 정말 솔직히 진행했다. 매번 똑같이 말하지만 인성 검사는 솔직히 해야 한다. 다양한 질문으로 신뢰성 체크를 진행하기 때문이다. 솔직히 하더라도 "책임감", "적극성" 등의 업무 친화적 가치관을 겸비한 상태로 솔직히 한다. 해당 인성검사도 마찬가지이다. 집중력을 잃지 않고 조용한 분위기 해서 하는 것을 권고한다. 4~6문제 당 20~30초? 씩 할당된다. 해당 시간 안에 문제를 답하지 못하면 끝이다. 쉬울 것 같지만 집중력을 한번 잃는 순간 끝이다. 명심하자!!
2차 임원 면접
2차 임원 면접은 원격이 아니다. 네이버 클라우드에서 대면 면접을 실시했다. 그 와중에 재밌는 사항이 존재했다. 마스크를 받았는데... 입 모양이 보이는 마스크이다. TV 연예인들이 종종 착용하는 마스크이다.
(ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ)
익숙해지기 위해 마스크는 미리 착용하였다(일부로 KF94가 아닌 KF-AD 끼고 왔는데...).
2차 면접은 20분 동안 진행했다. 질문의 구성은 다음과 같다.
아이스 브레이킹: 역량 기반으로 자기소개(직무 기반으로 자기소개와는 다른 것이니 주의!!)
프로젝트 관련 질문(50%)
인성 질문(40%)
기술 질문(10%)
약간 의외였다. 필자의 느낀 점은 딱 하나다. "네가 정말 궁금해!" 정말 필자한테 관심이 있고 궁금해서 이것저것 물어보는 느낌을 받았다.
면접관은 5명이고 1M 간격으로 앉아 있었다. 자기소개하는 도중 한 분만 쳐다보다 아차 생각해서 5명 골고루 몸의 방향을 바꿔가며 시선처리를 하였다.
면접은 짧았지만 짧아서 다행이다. 임원 면접은 부담감이 너무 커서 차라리 짧은 게 정신건강에 좋다 생각한다...!!!!! 하하하하하하!!!!!!!!!!!!
면접 프로세스 완료 후, 결과까지
8일 후 저녁, 최종 합격 메일을 받았다.
8일 동안 진짜 지옥이었다. 솔직히 현대 오토에버, 카카오, 라인, 기타 등등은 이러지 않았다. 근데 네이버 클라우드만큼은 1시간~30분 단위로 메일함 새로고침을 매번 눌렀다. 또한 업무 집중도 안됐고 답답했다.
본 시리즈는 이직을 하기까지에 대한 모든 생각과 일어난 현상 그리고 느낀 점을 기재한 사항이다. 해당 시리즈에서 언급되는 회사들은 감히 필자가 왈가왈부할 수 없는 회사이다. 단순 연봉, 그 이상의 가치를 실현할 수 있고, 필자한테는 과분한 좋은 회사들이다. 공개정보만 기재하는 것을 원칙으로 진행할 것이며 Private한 정보는 추상화할 것이다.
먼저, 해당 시리즈는 원하는 회사 또는 대기업을 신입 공채로 들어간 훌륭한 인재한테는 해당사항이 없는 시리즈이다.
필자의 카카오 채용 공고 지원은 시리즈 1장에서 언급한 "업무 도메인 변경 전략?"을 사용했다. 솔직히 업무 도메인의 유지 또는 변경은 필자 입장에서는 상관 없다. 왜냐하면 두 전략은 장점이 명확했기 때문이다.
업무 도메인은 정말 다양하다. 예를 들면 업무 시스템 개발, 동영상 스트리밍 서비스 개발, 클라우드 서비스 개발, 보안 모니터링 서비스 개발 등과 같이 진짜 다양하다. 여기서 공통적인 장점은 "배울 수 있다.", "새로운 경험을 한다.", "성장한다."에 있다. 다만 업무 도메인이 바뀌다보니 해당 업무를 배우는 시간이 필요하다.
업무 도메인이 변경되지 않아도 배울 수 있는 장점은 여전히 존재한다. 다만 추가 이점은 업무에 빨리 적응할 수 있다는 것이다.
그런데!!
위의 사항은 전적으로 필자의 입장이다. 인터뷰어의 입장은 전혀 다른 것 같다. 아마, 업무 도메인이 다른 경력은 그냥 신입과 진배없을 것이다(필자의 생각). 지금 생각해보니 충분히 그럴 것 같다. 필자 경험상, 업무 도메인이 다른 개발자가 같은 업무 도메인의 경력 개발자 만큼 퍼포먼스를 보여주기 위해서는 최소 1년의 시간이 필요하다. "최소"이다. 배우는 것이 느리고 배움과 성장을 원하지 않는 사람은 더 오래걸릴 수 있고 배움을 빠르게 하는 사람은 6개월이 걸릴 수 있다. 또는 극히 드물게 그 이상의 퍼포먼스를 보여주는 개발자도 존재할 것 이다. 뭐 사바사 케바케다. 그러나 전적으로, 보편적으로 최소 1년의 시간은 필요하다 생각한다. 기업은 이와 같은 상황을 반기지 않을 것이다.
그래서 필자는 서류 탈락의 고배를 많이 먹었다 생각한다!!!(필자의 역량 부족을 이렇게 핑계되면서 정신승리한다!!!!!)
그런데 중소기업은 약간 다르다. 중소기업의 경우, 경력직 채용이 많이 힘들다보니 업무 도메인이 달라도 기술 스택이 같으면 채용하는 편이다. 음 모든 기업이 그러지는 않겠지만 전적으로 그러는 것 같다.
각설하고, 카카오 네 번 지원하였다. 세 번은 코테의 기회조차 주지 않고 서류 탈락을 당해버렸다. 참 고마우면서 얄미운 것은 답변은 정말 빠르다~ 하하하하하!!!!!!ㅠ(그것도 하루만에...)
카카오/또카오/마카오
아재아재하다.
[카카오, 신규 서비스 서버 개발자 모집 - 서류탈락]
나중에 얘기를 들어보니 해당 채용을 올린 실무진(팀)은 멜론 서비스를 개발하는 곳 이었다.
신규 서비스를 개발하면 업무 도메인을 변경하더라도 동료들과 같이 배우면서 할 것 같아 지원했다.
응~ 탈락~
첫 번째 탈락, 이직 준비 초기이다보니 크게 동요하지 않고 넘어갔다.
[카카오 뱅크, 대규모 경력 채용 - 서류탈락]
두 번째 탈락, 이 때 여자친구가 놀리면서 "또 카카오? 또~? 또 떨어졌어?"
그래, 또 떨어졌다.
딱히 지원 이유는 없다. 뱅킹 쪽으로 해봐도 재밌을 것 같아서 지원했다.
그걸 알았는지~! 역량이 부족했는지~! 탈락~!
두 번째 탈락부터 슬슬...
[카카오, 커리어 부스트 프로그램, 클라우드 - 서류탈락]
세 번째 탈락, 여자친구가 웃으면서 "또 지원했어? 카카오? 또~? 또또또? 또카오~~?"
ㅡㅡ;;
세 번째 탈락부터 멘탈이 나갔다. 커리어 부스트 프로그램은 설명회까지 들은지라 기대도 컸다.
설명회에서 "업무 도메인이 달라도 된다. 커리어 부스트 취지 자체가 업무 도메인 변경을 위해서이다."
해당 공고는 보안이면서 CERT 관련 보안이며, 필자는 보안이면서 암호/PKI 관련 보안이다. 같은 보안이지만 업무 도메인은 결코!! 전혀 다르다. 그래도 어느정도 비슷한 부분은 존재한다.
솔직히 해당 공고의 면접 경험이 제일 좋았고 포기해서 정말 아까운 전형 중 하나다.
필자는 해당 전형을 어떻게 준비하고 진행하고 임했는지, 어떤 경험을 얻었는지 해당 본문에서 서술하겠다!
메일 히스토리
필자에게 이런 영광이 있다니 정말로 가문의 영광이다!! 으하하하하!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
필자가 작성하면서 드는 생각이지만 여전히 정말 감사하다. 진짜 주변 친지인들에게 정말 감사드리다!! 하하하!!!!
면접 프로세스
카카오 채용 사이트 상시 채용 공고
지원서/자기소개서/경력기술서 작성 및 제출
코딩 테스트
원격 인터뷰(직무/기술 면접)
1차 인터뷰(직무/기술 면접)
2차 인터뷰(임원 면접)
*메일 및 카카오톡 메신저를 이용해서 합격/불합격 여부 통보
*그 후 유선을 통해 면접 일정 협의
카카오에서 제일 편리한 것은 카카오 채용사이트에서 지원자의 전형 현황을 편리하게 확인할 수 있는 것이다.
자기소개서
자소서는 자유 양식 2500자이다.
아싸리! 세상에 하늘아 감사합니다ㅋㅋㅋㅋ!!!!
필자가 제일 좋아하는 유형이다. 필자가 갖고 있는 자소서 FAQ 항목을 자유자재로 사용할 수 있다.
다음과 같이 자소서를 작성하였다.
직무를 기반으로 자기소개
역량을 기반으로 자기소개-1
역량을 기반으로 자기소개-2
협업을 기반으로 자기소개
네 가지 항목의 글자 수는 약 2000자이다.
코딩테스트
총 세 개의 문제이다.
코딩 테스트의 난이도는 높지 않았다.
DP 문제 제외하고는 쉬웠다.
두 개의 문제는 구현
한 개의 문제는 DP
또 DP이다... DP만 보면 토 나온다!!!
카카오 블라인드/신입/인턴 코딩 테스트를 반절 이상 풀 수 있으면 경력직 코테는 충분히 패스할 수 있지 않을까?
생각한다(케바케, 사바사, 부바부).
그런데... 두 번째 문제에서 약간 뻘짓을 해버리는 바람에 이게 흠이 되어버렸다.
절대적으로 쉽고 쉬운 문제인데 좀 다른 방식으로 풀려고 하다보니 걍 망했다..
풀긴 풀었으나... 멍청하게 풀었다...
원격 인터뷰
코로나 시대, 요즘 보통의 면접은 거의 원격으로 이루어지고 있다. 필자 또한 네이버 클라우드 최종 면접을 제외하고는 전부 원격 면접으로 진행하였다. 이제는 카카오가 얘기하는 원격 인터뷰, 의미가 있나 생각이 든다. 용어의 혼란을 야기한다!!! 카카오 채용 프로세스를 겪어보지 못한 주변 지인과 얘기할 때 매번 다음과 같은 웃긴 상황이 생긴다.
지인: 카카오 1차 면접 봤어?
필자: 아직이요. 원격 인터뷰 진행 중이에요.
지인: 요즘에 다 원격이잖아??
필자: 1차 면접 보기 전에 원격인터뷰라고 면접이 있어요. 얘네 명칭이 좀 헷갈린데, 그냥 1차 기술 면접이 두 번인 것 같아요.
지인: ??; 아... 그래ㅋ
그냥 드는 생각이지만, 1차 인터뷰를 두번 하는 느낌이다. 차라리 1차 직무/기술 면접, 2차 직무/기술면접, 3차 임원 면접 이렇게 분류하는게 좋지 않을까 생각이 든다. 쿠팡은 뭐 5차까지 인터뷰 한다는 카더라가 있는데 말이다.
여튼 각설하고 면접 경험은 좋았다. 정말 좋았다.
면접 시간은 약 50분, 면접 질문은 다음과 같다.
코테 관련 질문(10%)
공고의 담당 업무 관련 질문(30%)
전반적인 기술 질문(50%)
필자의 인적 사항이 궁금해서 하는 질문(10%)
코테에 대해 리뷰하는 것이 정말 좋았고 왜 이렇게 개발했어요? 라는 질문이 정말 맘에 들었다.
코테에서 필자가 개발한 스타일을 토대로 파생 기술 질문도 좋은 경험이었다.
그리고 인터뷰이가 인터뷰어의 질문 의도를 제대로 파악하지 못 하는 경우 한 번, 두 번, 세 번 다르게 질문 하면서 의도 전달을 열심히 해줬다. 그리고 인터뷰어가 뭔가 털털하게 얘기하니까 같이 일 했다면 괜찮겠다~ 생각이 들었다.
그리고, 보안 모니터링 시스템 개발이 곧 CERT인데 필자는 이를 망각하고 CERT 관련 FAQ를 1도 준비하지 않고 면접에 임해서 관련 질문은 말아먹었다. 그리고 기술 질문, 디자인 패턴 관련 질문에서 어이없게 말아 먹었다. 알고 있는 사항인데 인터뷰어의 의도를 제대로 이해하지 못 했다.
고로 원격 인터뷰에서 불합격 할 줄 알았다!!!
그런데 다행이다. 합격이다!!!
1차 인터뷰
1차 인터뷰의 인터뷰어는 한 분이 더 추가됐다.
면접 시간은 40~50분? 면접 질문은 다음과 같다.
약간의 인성 질문(10%)
전반적인 기술, 프로젝트에서 했던 기술 질문(70%)
공고의 담당 업무 관련 질문(20%)
CERT 관련 질문에 대응하기 위해 CERT 하는 지인한테 바로 연락해서 1시간 동안 같이 CERT 관련 면접 전략을 짰다. 우리 아저씨한테 정말 고맙다!!! 근데 효과는 미미했다!! CERT 관련 질문 시원하게 말아먹었다 ㅋㅋㅋㅋㅋㅋㅋㅋㅋ!!!
원격 인터뷰와 다르게 1차 인터뷰에서 기술 질문에 대답 못 한게 5개?? 정도 됐다.
필자 업무 특성 상 경험하지 못 해 대답을 시원하게 못 한 부분도 있지만 필자가 공부하지 않은 부분도 있기 때문에 필자의 역량 하자이다ㅠㅠㅠㅠ...
참 재밌는 경험을 하나 했다.
쓰리 댑스 상사의 부당한 지시!!! 잘 대답했는지 모르겠지만 솔직히 저런 상황이 오면 진짜 어떨까...
네이버 개발자 사건이 있다 보니 깊은 생각에 빠지게 된다...;
마지막으로 인터뷰어께서 "만약 2차 잘 되고 처우 협상 잘 되면 언제 입사할 수 있냐~?"
위와 같은 질문으로 인하여! 어찌어찌 잘 되겠구나~ 생각이 들었다.
1차 인터뷰 완료 후 이벤트 발생
1차 인터뷰 완료 당일 네이버 클라우드 최종 합격 메일을 받았다.
미쳤다 미쳤어!!!!
여기서부터 고민이 시작했다.
카카오도 합격하면 어떻게 하지??
그 고민의 과정과 결과는 시리즈 9 에서 확인할 수 있다.
2차 인터뷰
예상과 함께 1차 인터뷰는 합격이다.
솔직히 필자는 면접이나 P는 긴장을 잘 안하는 편이다.
그런데 연륜이 묻어있는 분들이 인터뷰어로 나오시니깐 갑자기 가슴이 쿵쾅쿵쾅 거렸다...!!!
인터뷰어는 대략 40여개의 질문을 하였다.
인성 질문(90%)
공고의 담당 업무 관련 질문(10%)
역시 10%의 CERT 질문에 대한 답변은 시원스럽게 말아먹었다 ㅋㅋㅋㅋㅋㅋㅋㅋ 아 진짜.. CERT만 보면 PTSD 온다.
2차 인터뷰하면서 느낀 것은 정말 개발자가 하고 싶고, 개발이 좋고, 열정이 있으면 충분히 돌파할 수 있는 질문들이다...
다만, FAQ 만들고 연습을 해야지 조리있게 잘 답변할 수 있다^^!!!
후기
필자에게는 정말 고마운 채용 공고였다. 배울 수 있는 직무/기술 면접을 겪었고, "아! 이게!! 진짜 임원 면접이지!!" 라고 생각할 수 있는 임원 면접을 겪었다. 좋은 경험을 선물해준 인터뷰어들께 감사하다!!!! 역량이 많이 부족한 필자에게는 정말 과분한, 미치도록 과분하고 필자에게 그 이상의 가치를 선사해줄 수 있는 회사이다(솔직히 필자는 학창시절부터 네이버, 카카오 둘다 가고 싶었다!!!). 하지만 결국 선택이 필요했고 필자는 다른 회사를 선택했다. 후회는 없지만 아쉽다.
