Jins' Dev Inside

웹 서버는 Stateless 프로토콜인 HTTP 를 사용하기 때문에 웹사이트에서 인증을 관리하기 위한 방안이 필요하다.

로그인을 한 유저들에 대해 권한이 필요한 매 요청마다 재로그인을 시킬수는 없는 일이다.

그렇기 때문에 웹사이트는 일반적으로 유저의 접속 정보를 관리하기 위한 몇가지 방안을 사용한다.

1. Session 기반 인증

세션 기반인증을 위해 Session 과 Cookie 가 사용된다. 다음 Flow 로 인증 절차가 진행된다.

 - 유저가 로그인을 하고 세션이 서버 메모리 상에 저장된다. 이 때 세션을 식별하기 위한 Session Id 를 기준으로 정보를 저장한다.

 - 브라우저에 쿠키로 Session Id 가 저장된다.

 - 쿠키에 정보가 담겨있기 때문에 브라우저는 해당 사이트에 대한 모든 Request 에 Session Id 를 쿠키에 담아 전송한다.

 - 서버는 클라이언트가 보낸 Session Id 와 서버 메모리로 관리하고 있는 Session Id 를 비교하여 Verification 을 수행한다.

Session 기반 인증은 다음과 같은 장단점을 갖는다.

+ 세션 기반 인증 방식은 구현이 상당히 명확하다는 장점이 있다. 또한 실제 서버에서 로그인 상태 확인이 굉장히 유용하다.

+ 상대적으로 안전하다. 서버측에서 관리하기 때문에 클라이언트 변조에 영향받거나 데이터의 Stale (손상) 우려가 없다.

- 유저들의 세션에 대한 정보를 서버 메모리에 들고 있게 된다는 부담이 있다.

- 서버 메모리에 세션 정보가 저장되기 때문에 Scale Out / Scale In 이 부담이 될 수 있으며, 결국에는 유저 상태에 무관하게 동작할 수 있도록 Data-Driven 아키텍처가 요구된다.

- 멀티 디바이스 환경에서 로그인 시 신경써줘야할 부분들이 생긴다. 

2. Token 기반 인증

Token 기반 인증의 방법으로 많은 웹 서버들은 JWT(JSON Web Token) 을 사용한다.

Token 기반 인증 방식과 Session 기반 인증 방식의 가장 큰 차이점은 유저의 정보가 서버에 저장되지 않는다는 점이다.

Flow 는 다음과 같다.

 - 유저가 로그인을 하고 서버에 세션을 이용해서 정보를 기록하는대신, Token 을 발급한다.

 - 클라이언트는 발급된 Token 을 저장한다 (일반적으로 local storage 에 저장한다.)

 - 클라이언트는 요청 시 저장된 Token 을 Header 에 포함시켜 보낸다. 

 - 서버는 매 요청시 클라이언트로부터 전달받은 Header 의 Token 정보를 Verification 한 뒤, 해당 유저에 권한을 인가한다.

Flow 에서 차이를 확인할 수 있듯, Session 기반 서버가 서버측에 정보를 기록하는 반면, Token 기반 인증은 Token 에 대한 Verification 만 수행할 뿐 저장은 클라이언트에서 수행한다.

Token 기반 인증은 다음과 같은 장단점을 갖는다.

+ 클라이언트에 저장되기 때문에 서버의 메모리에 부담이 되지않으며 Scale 에 있어 대비책을 고려할 필요가 없다

+ 멀티 디바이스 환경에 대한 부담이 없다.

- 상대적으로 Stale (손상) 의 위험이 크다.

- 결국 구현을 하다보면 서버측에 token blacklist 를 관리하게 될 가능성이 있고 그렇게 되면 서버측 메모리의 소모가 발생하게 된다

- Token 은 일반적으로 Session ID 보다 길다.

- XSS 공격에 취약할 수 있어 가능한 민감한 정보는 포함시키지 않을 필요가 있다.

최근에는 Scaling 이슈와 멀티 디바이스 이슈로 Token 방식이 좀 더 핫한 느낌이지만, Session 방식도 여전히 많이 쓰인다.

두 방식 모두 장단점이 있기 때문에 적합한 구조를 선택하는 것이 좋겠다.

사실 보안쪽에 문외한이다보니 처음 배웠을 때 아주 생소한 개념이었다.

하지만 백엔드에 종사하다보니 얼마나 중요한지 알게되었고, 다시 한번 정리를 해보았다.

사실 Threat Modeling 이라는 단어는 비단 IT에서만 쓰는 용어는 아니고, 위험 요소에 대해 평가해보는 전반에 걸쳐 사용되는 언어이다.

하지만 IT 용어로써 Threat Modeling 이란 MS 사에서 대중화한 개념으로 잠재적인 위협을 모델링하고 이를 완화할 수 있도록 할 수 있는 프로세스를 말한다.

가령, 구조적 취약점이나 방화벽 등 보안장치의 부재와 같은 위협들이 모델링의 대상이 될 수 있다. 

위협 모델링의 목적은 시스템의 특성과 방어 시스템을 고려했을 때 어떤 부분에 있어서 방어가 필요하고 보안상 취약할 수 있는지 가능성을 찾는 것으로 특히 특정한 위협포인트에 대해 미지수일 경우 가능한 취약점을 찾는 것이 되겠다.

또한 공격자의 입장을 시뮬레이션해보고 공격 측면(Attack Surfaces) 을 찾아내는 일이 포함된다.

그렇기 때문에 Threat Modeling 이 가능하려면 먼저 다음을 알아야 한다.

    - 시스템의 구조 (Architecture)

    - 시스템의 보안 상태

    - 보호해야하는 가치있는(Valueable) 자산이 무엇인지

    - 가능한 공격자 후보군

위협요소 탐지를 위한 Threat Modeling 방법론으로 주로 언급되는 4가지를 정리해본다.

  1. STRIDE : 다음의 머릿글자만 딴 약어이며 다음 6가지에 대한 위협을 측정한다.

Spoofing(공격자가 권한이 있는 사용자인척 위장하는 공격 방식)

Tampering(목적을 위해 시스템 내부 데이터를 악의적 수정해서 공격)

Repudiation(악의적 활동 이후에 해당 활동에 대해 부인하는 것)

Information Disclosure(보호된 정보에 대한 노출)

Denial of Service(서비스에 대한 믿을 수 있는 접근을 바탕으로 한 공격. 분산해서 공격하는 것을 DDoS라 한다.)

  2. DREAD : 다음의 머릿글자만 딴 약어이다. MS 에서는 현재 제공되고 있지 않는 것으로 보이지만 OpenStack 등에서는 여전히 쓰이고 있는 방법이라 한다.

Damage Potential(취약점이 노출되었을 경우 발생 가능한 피해량)

Reproducibility(재공격 당하기 쉬운 정도)

Exploitability(공격을 하기 위해 필요한 공수)

Affected Users(위협이 얼마나 많은 유저에게 노출되는지)

Discoverability(얼마나 위협을 탐지하기 쉬운지)

위의 수치의 평균을 Risk 로 정의한다.

  3. P.A.S.T.A : Process for Attack Simulation and Threat Analysis 의 약어로 비즈니스 컨텐츠 및 기술 요구 사항에 따라 7단계로 프로세스가 구성된다. 방법의 목적은 직접 위협 요소를 검증하고 위협 요소들에 대해 점수를 부여해서 분석하고 완화시키기 위한 방법을 개발자에게 제시하는 것이다.

  4. VAST : Visual, Agile, and Simple Threat modeling 의 약어로 인프라 및 시스템 전체에 대한 모델링이 필요하며 Agile 프로세스에 위협 모델링 정보를 Visualize 할 수 있는 부분을 포함한다. 그렇기 때문에 전문적 지식없이 간단하게 진행되며 그를 지원해줄 수 있는 어플리케이션이 요구된다.

개발자 입장에서는 놓치기 쉬운 측면이고 정책적인 부분 또한 강하지만 OWASP(Open Web Application Security Project) 에서도 강조하고 있는 보안 위험을 대하는 구조화된 접근 방식이다.

다음을 참고하자 - (https://www.owasp.org/index.php/Threat_Modeling_Cheat_Sheet)

위협 모델링은 운영이 편리하고 취약점을 공유할 수 있는 부분이 큰 장점으로, 그에 따라 위험을 공유하고 같이 협력해서 대처할 수 있다는 큰 장점이 있다.

하지만 중요함에도 이를 적절하고 의미있게 실행하기는 쉽지 않은데, Best Practice 가 많지 않고 향후 위협 가능성보다는 현재의 위협에 초점을 두고 취약점 위주의 분석이 주가 되기 때문이다.

개발자 뿐만 아니라 시스템 전반에 걸친 모두의 협력이 지속적으로 이루어져야 가능한 부분이 아닐까 생각이 든다.

분산 환경의 처리는 일반적인 환경의 구성과 많이 다르며 분산시스템의 특이성에 대한 개념들이 있다.

특히나 자주 듣게 되는 단어 중 하나는 결과적 일관성(Eventual Consistency) 라는 개념으로, 분산 시스템(Distributed System) 을 운영하게 되면 흔치않게 접하게 된다.

이는 개념과 관련된 이론이 그만큼 중요한 내용임을 반증한다.

먼저 예로 들은 Eventual Consistency 에 대해 설명하자면 이는 분산 컴퓨팅(Distributed Computing) 에서 고가용성(High Availability)을 보장하기 위한 방법의 하나로

"주어진 데이터에 대한 변경이 없다면 해당 Element 에 대한 모든 Access 는 가장 최근에 변경된 내용을 가리킨다" 는 정의를 말한다.

분산 시스템에서 데이터를 조회할 때 모든 시스템이 동일한 데이터를 가질 수 있다고 보장할 수는 없으며 결과적 일관성은 어느 시점에는 데이터가 다를 수 있지만, 결국에는 모든 시스템이 최신의 데이터를 가질 수 있도록 보장된다는 내용이다.

이는 BASE 원칙의 일종으로 분류되기도 한다. BASE 원칙이란 다음의 원칙들이 포함된다.

- Basically Available : 일반적인 Read / Write 에 대한 동작이 "가능한만큼" 지원된다.

(여기서 가능한만큼 이라 함은, 동작이 가능하나 Consistency 에 대한 보장이 되지않는다는 점이다.)

- Soft state : Consistency 가 보장되지 않기 때문에 상태(State) 에 대해 Solid 하게 정의하지 못하다.

- Eventually consistent : 위에 언급된 Eventual Consistency 개념에 따라 충분한 시간이 흐르면 모든 시스템 환경 내에서 데이터는 최신의 데이터가 보장된다.

BASE 원칙은 전통의 트랜잭션 시스템을 위한 ACID 원칙에 반대된다. 이는 분산 환경에서 나타나는 특징이기 때문이다.

이러한 특징에 대해 CAP Theorem 은 다음 3가지 조건을 모두 만족하는 분산 시스템을 만드는 것이 불가능함을 정의한다.

- 일관성(Consistency) : 모든 시스템의 데이터는 어떤 순간에 항상 같은 데이터를 갖는다.

- 가용성(Availability) : 분산 시스템에 대한 모든 요청은 내용 혹은 성공/실패에 상관없이 응답을 반환할 수 있다.

- 내구성(Partition Tolerance) : 네트워크 장애 등 여러 상황에서도 시스템은 동작할 수 있다.

분산환경 특징 상 3가지 성질을 모두 만족할 수는 없고, 일반적으로 다음과 같이 선택된다.

- CP (Consistency & Partition Tolerance) : 어떤 상황에서도 안정적으로 시스템은 운영되지만 Consistency 가 보장되지 않는다면 Error 를 반환한다. (어떤 경우에도 데이터가 달라져서는 안된다.)

이는 매 순간 Read / Write 에 따른 정합성이 일치할 필요가 있는 경우 적합한 형태이다.

- AP (Availability & Partition Tolerance) : 어떤 상황에서도 안정적으로 시스템은 운영된다. 또한 데이터와 상관없이 안정적인 응답을 받을 수 있다. 다만 데이터의 정합성에 대한 보장은 불가능하다. (특정 시점에 Write 동기화 여부에 따라 데이터가 달라질 수 있다.)

이는 결과적으로는 일관성이 보장된다는 Eventual Consistency 를 보장할 수 있는 시스템에 알맞는 형태이다.

서버시스템 및 분산시스템에 있어서 핵심적인 개념이므로 잘 정리해두고 아키텍처를 고려할 때 항상 생각해두자

Amazon Web Service 에서 제공되는 EBS (Elastic Block Store) 서비스는 대규모의 워크로드에도 안정적인 퍼포먼스를 보여줄 수 있는 Block Storage Service 의 일종이다.

서비스로써는 일종의 하드디스크를 제공해준다고 이해하면 쉽다.

따라서 제공되는 서비스도 그에 알맞게 SSD, 프로비저닝된 IOPS(SSD) 등의 서비스가 제공된다.

가용영역(Availability Zone) 내에 자동으로 복제되며 스냅샷을 S3 에 저장하는 방식으로 안정적으로 운영된다.

다음과 같은 라이프사이클(Life Cycle)을 지닌다.

(1) 생성 : 사용되지 않은 볼륨을 사용할 수 있게끔 할당하는 작업이다.

(2) 연결 : 만들어진 EBS 볼륨을 EC2 인스턴스와 연결한다.

(3) 사용 : 포맷된 형태로 EC2 인스턴스에 탑재되어 사용된다.

(4) 스냅샷 생성 : Block Store 의 상태에 대한 스냅샷을 생성하고 S3 에 기록된다.

(5) 분리 : 연결된 EC2 인스턴스에서 분리된다.

(6) 삭제 : 할당된 볼륨의 사용을 해제한다.

EBS 는 기존 EC2 인스턴스가 휘발성을 가진 로컬스토리지라는 특성으로 인해 인스턴스 중지 시 데이터의 손상이 발생한다는 점을 보완하기 위해 별도로 운용될 수 있는 스토리지 시스템이다.

하드디스크의 특성을 지님에도 고가용성 및 안정성을 갖춘 설계 덕분에 이슈 상황에서도 데이터 유실을 방지할 수 있도록 데이터를 복제하고 스냅샷을 활용해 복원시킬 수 있는 솔루션을 지니고 있다.

또한 자체적으로 데이터 암호화를 제공하고 파일시스템으로써 동작하기 때문에 S3 와 같은 스토리지 서비스에 비해서도 매우 빠른 성능을 보여준다.

또한 사용한만큼 지불되는 S3와 달리 프로비저닝한 만큼만 요금을 지불한다.

클라우드 서비스를 잘 모르는 경우 익숙치 않을 수 있는 서비스이지만 비용 대비 효용성이 좋고 편의성이 우수하기 때문에 사용하기 좋은 서비스이다.

2019년 10월, 꿈에 그리던 회사에 합격 통보를 받았다.

개발자로서 만 4년의 경력 중 가장 치열하고 힘들었던 2019년 한해 였지만 그 동안의 경험을 통해 이룩해낸 성취가 뿌듯함을 느끼게 해주었다.


첫 직장으로 삼성전자에서 2년을, 두번째 직장으로 LINE 에 경력직으로 입사했으며, 이제는 꿈에 그리던 외국계 기업에서 세번째 커리어를 시작한다.

경력대비 많은 이직을 한 편에 속해서 지인들로부터도, 개인적으로 코드를 리뷰해주는 학생들로부터 질문을 많이 받는데, 그 때 도움이 될 수 있도록 해주었던 조언들을 정리해보았다.

이제 막 커리어를 시작하는 개발자들에게는 좋은 도움이 될 것 같아 개발자로서의 진로에 관한 지극히 개인적인 경험과 생각을 공유해본다.

절대 이 내용은 개발자에게 회사를 선택하는 기준을 제시하는 가이드북이 아니며, 단지 친한 형이 개인적인 생각 말해주는 셈 쳐줬으면 좋겠다.

어떤 커리어를 쌓고싶은가?

생각보다 어려운 질문이다.

학생 때의 나는 막연히 세계적으로 명성이 자자한 구루(GURU) 가 되고싶었지만, 뭘 어떻게 해야하는지도 몰랐고 어떤 회사에서 일하고 싶은지도 몰랐다. (글쓰고 생각해보니 그때도 구글에서 일하고 싶긴 한 것 같다...ㅎ)

그리고 불분명한 생각으로 경력을 시작하게 되면 3가지 케이스로 나뉘게 된다.

1. 돈을 목표로 하는 경우

2. 워라밸(Work and Life Balance)을 목표로 하게되는 경우

3. 꿈을 따라가는 경우

어느게 좋다고 할 수도 없고, 운좋다면 2~3가지를 동시에 만족시켜주는 기업에서 일하게 될 수도 있다. (부럽습니다)

문제는 어떤 곳에서 일하게 되더라도 본인이 행복할 수 있는가, 일에서 만족감을 얻을 수 있는가 최우선이 되어야할 것이다.

그리고 더 문제는 그 사실도 모두가 아는 뻔한 정답이다.

만약 본인이 만족하면서 일을 하고 계신 분이라면 시간 절약을 위해 뒤로가기를 권고드린다.

이 앞으로는 지극히 뻔한 얘기이기 때문이다.

아래 내용은 한창 방황하던 혹은 뭘 하고 싶은지 커리어가 뭔지도 모르고 취직을 준비하던 과거의 나와 같은 분들을 위해 쓴 경험담에 기반한 글이다.

잘 갖춰진 프로세스와 화려한 커리어를 원한다면 대기업을

대기업 개발자로 경력을 계발해보는 건, 완벽한 프로세스 위에서 잘 적응할 수 있는 인재가 되는 것과 같다.

이건 좋은 의미와 나쁜 의미를 전부 포함한다.

- 장점

이미 갖춰진 선진 프로세스를 익히고 사업을, 서비스를 배우는 데 있어서 대기업은 훌륭한 옵션이다.

당신이 모르는 부분이 많다면 사내 인프라만 잘 활용해도 성장할 수 있는 여지는 아주 크다.

또한 뛰어난 네임 밸류 는 커리어 계발에 있어서 큰 도움이 된다. 

비단 후광 효과 뿐만 아니라 책임감, 업계나 기술을 보는 시야 등이 강제적으로 확장된다.

좁은 시야의 확장은 자신의 인생에 있어서 중요한 Value 를 찾게해주기도 한다.

당연히 비즈니스 기회가 많이 보이지 않을까?

그리고 가장 큰 장점으로는 이직을 목표로 하고있다면 당연히... 전직장 연봉은 자신의 몸값에 큰 지표가 된다. ^^;;

사회 생활을 해본 분들은 절감하겠지만... 시장에서 자신의 가치는 올리기가 정말 쉽지않다.

대기업에서는 평균적으로 높은 테이블의 연봉을 보장하며, 이는 나와서도 도움이 될 수 있다.

- 단점

주도적이 되지 못할 가능성이 크다. 이것도 사람마다 하기 나름이고 회사 나름이라 일반화시킬 수는 없다.

하지만, 우리나라 회사에서는 대게 시키는 일을 하게 된다.

대기업은 모든 체계에 대한 작업이 이미 이루어져있는 경우가 많다.

가령 당신이 입사해서 당신이 회사에 기여할 수 있는 훌륭한 코드를 만들 수 있다고 할 때, 이미 해당 기능은 비슷한 생각을 한 누군가에 의해 만들어져 있거나 다른 훌륭한 오픈소스가 사내에 적용되어 있을 가능성이 높다.

그렇기 때문에 이 때 당신의 능력은 회사에 '당신만의 훌륭한 것' 을 기여하기보다는 '회사의 훌륭한 시스템' 을 얼마나 잘 활용하는지로 계발되고 평가되어질 가능성이 높다.

그렇기 때문에 자신이 빛나고 싶다면 회사의 시스템에 의해 역량이 묻히지 위한 노력이 필수적이다.

자신이 홀로 빛나고 싶다면 대기업은 쉽지않다. 물론 홀로 빛나는 천재들도 분명 계시지만...

필자를 비롯해 대부분은 그렇지 않다. ㅜㅜ

어떻게보면 경쟁이 치열하다는 의미로 해석될 수 있겠다.

- 대표기업 : Samsung, LG 등

- 전략

당연히 실력이다. 하지만 즉시 투입되어 사용할 수 있는 업무 활용능력 보다는 잠재력 이라고 하고싶다.

대기업은 원하는 인프라를 모두 제공해줄 수 있고, 직원들을 키우는데 있어서 아낌없이 투자한다.

하지만 가장 중요한건 그 투자 이상의 회수이다. 

즉, 시니어 / 임원급이 아닌 이상에야 잠재력이 뛰어난 인재를 뽑아서 키우는 전략이 주가 되기 때문에 그 점을 중점적으로 생각해보면 된다.

협업도구의 까다로운 설정을 능숙하게 한다던지, 데이터베이스의 쿼리나 협업도구를 훌륭하게 쓰는 건 훌륭한 자질이고 기술이지만 대부분의 대기업이 1순위로 보는 능력은 아니다.

특히 주니어라면 알고리즘, 자료구조 등 CS 기본기가 가장 중점이 되며 이 들을 보는 이유는 사고력과 학습능력이다.

회사에 필요한 어떤걸 주더라도 빠르게 학습하고 응용해서 경쟁력을 갖출 수 있는 인재가 되도록 준비를 해보면 좋겠다.

그리고 중요한건 "쫄지말자". 대기업이어도 사람 뽑는 이유는 하나다. 인재가 필요하기 때문이다.

대기업이라고 갑이고 본인이 을 인 경우가 아니며 본인이 인재라면 "갑의 입장" 이 되어볼 수 있다.

추천 지식 : 개발언어 기초지식, 자료구조, 알고리즘, Soft Skills (기술 이외의 것들 - 사회성이나 말하는 방법 등이 포함된다.)

보다 주도적인 개발이 좋다면 Software 개발 중심의 회사로

앞서 언급한 대기업 중에 Software 개발이 중심이 아닌 회사들도 많이 있다.

또한, 의외로 Software 개발 중심의 비즈니스 모델을 가지거나, 비즈니스 모델과 무관하게 Software 경쟁력이 뛰어난 회사들도 있다. 

- 장점

개인적인 경험에서 얘기를 한다면, 모든 케이스를 일반화할 수는 없지만 소프트웨어 중심의 서비스 회사에서 배울 수 있는 경험은 개발자로서 아주 소중한 경험이 된다.

개인적으로 역량을 개발하고 토이프로젝트를 진행하는 것 이상으로 팀 단위로 구성된 팀에서 잘 갖추어진 서비스를 신규 개발 및 런칭해보고 운영해보는 경험은 개인 공부로는 쌓기 힘든... 커리어에 있어서 큰 자산이 된다.

그리고 많은 회사에서는 이런 종류의 경험들은 Senior Developer 가 됨에 따라 개인의 가치를 높이는 무기가 되기도 한다.

또한 소프트웨어 개발자로서 얻을 수 있는 Domain 지식이 좀 더 많을 수 있다.

이부분은 연구중심의 회사와 서비스중심의 회사가 다를 수 있는 부분이라 "Case by Case" 라고 하겠지만,

Software 개발에 있어서는 도메인적 지식의 폭이 더 넓어지고 깊어질 수 있다.

당연히 미리 만들어진 체계를 쓰는 대신 새로 자신이 공부해서 만들어내거나 신기술을 적용할 수 있다면, 그 자체로도 도메인적 지식이 습득되고 자기발전으로 이어지지않을까?

자신이 욕심내서 하는만큼 실력이 발전하고, 좋은 회사라면 자신의 개발 실력에 알맞는 평가까지도 받을 수 있는 좋은 선택지가 될 수 있다.

- 단점

업무가 많을 가능성이 정말 크다.

특히 잘 짜여진 체계가 없는 회사이거나 개발자 개인의 역량이 아주 중요한 스타트업에 경우...

개발자는 슈퍼맨이 될 가능성이 크다.

어쩌면 Software Architecture 의 중대한 부분에 대한 의사결정부터, 코드 레벨의 마이크로튜닝까지를 모두 담당하게 될 것이고, 비즈니스 환경에서 계속 바뀌는 요구사항은 수시로 코드를 뒤엎게 만들고 리팩토링까지 요구한다.

이 모든 경험이 개인의 발전에 있어서 큰 도움이 된다고 생각할 수도 있다. (실제로도 노력은 배신하지 않는다.)

다만, 본인이 너무 힘들다면 생각해보자.

우리는 개발하기 위해 태어난 사람이 아니라 행복하기 위해 노력하는 사람들이다.

- 대표기업 : Naver, Kakao 등

- 전략

많은 경우 개발자로서 대기업에 입사하는 것보다 쉽지않다.

네임 밸류만 보고 무시하고 대충 준비하는 사람들이 간혹 보이는데...

큰코 다칠 정도로 난이도가 있는 경우가 대부분이다.

잠재력도 물론 중요하지만 업무에 바로 투입될 수 있는 업무 활용능력이 좀 더 중요하다.

요구하는 인재상에 따라 다르겠지만 예시를 들자면, 주어진 문제에 대한 해결 능력에 대해 토론할 일보다 프레임워크의 특성을 설명해볼 일이 많다.

(물론 문제해결능력은 매우 중요하다.)

그렇기 때문에 자신의 실력을 증명할 수 있는 포트폴리오나 Github 같은 부분들은 큰 도움이 될 것이다.

필자처럼 블로그를 운영해보는 경험도 면접시에는 큰 도움이 된다.

추천 지식 : 개발언어 기초지식, 자료구조, 운영체제, 네트워크, 도메인 지식들

그 외...

경험해본 내용을 바탕으로 대기업과 소프트웨어기업으로 분류해서 얘기를 해보았다.

많은 질문을 받는 외국계에 대한 내용도 향후 기술할 수 있었으면 좋겠다.

필자는 현재 회사에 열심히 적응 중이고, 많은 것을 배워나가는 중이다.

향후 외국계에 대해서도 포스트를 업데이트하게되길 바란다. :)

하지만...?

"포스팅에서 기술한 기업 타입 별 장/단점이나 면접 준비 전략 모두" 일반화시킬 수 있는 지식이 아닌 필자의 개인적인 경험이라고 봐주시면 좋겠다.

빠져나갈 구멍을 만드려는게 아니라 실제로 그렇다.

회사마다 조직별로, 부서별로 특색은 정말 천차만별이며 특히 면접은 면접관의 가치관이 반영될 수밖에 없다.

그리고...

가장 중요한 건 자신이 어떤 사람이며 어떤 커리어를 추구하는 지를 생각해보는 것. 그 자체인 것 같다.

정답은 없다. 개발자로 시작했지만 다른 커리어를 밟아도 좋고, 다른 커리어를 밟다가 뒤늦게 개발을 시작해도 늦지않다.

또 어떤 회사에서 어떤 일을 하는지도 여러분의 가치를 정해주지 않는다. 가치평가는 스스로만 내릴 수 있다.

사회생활을 시작한다면 어떤 일을 할 때 좀 더 행복할 수 있는지, 자신의 인생에 있어서 더 중요한 목표가 무엇인지 고민해볼 시기이다.

마지막으로...

면접 탈락은 은근히 큰 내상으로 다가온다.

자존감이 낮아지는 것도 문제이지만 특히 이직이라면 면접 때마다 휴가를 써야하지 않은가...?

눈치보면서 휴가 썼는데 사소한 실수로 탈락의 고배를 마시는 건 정말 속쓰린 일이다. 

또, 만약 비전공자라면 어떻게 준비를 해야하는지부터가 막막할 수 있다.

절대 겁먹지말고, 탈락에 슬퍼하지 말자.

필자도 본인이 원하던 회사에 입사하기 전까지 무수한 탈락의 고비를 마셨다.

실패를 담담하게 받아들이고 보완해서 재도전하면 될 일이다.

어렵기로 유명한 "소울류 게임" 을 죽지않고 깬다면 게임을 할 이유가 없다.

개발자로 처음 발을 디딘 이들에게 위의 이야기가 도움이 되었으면 좋겠다.

포트 미러링은 소프트웨어 개발자에게 친숙한 단어는 아니다.

포트미러링은 흔히 알려진 포트 포워딩과는 다른 개념으로, 네트워크 스위치 상 포트에 전달되는 네트워크 패킷을 다른 포트로 복사하는 개념이다. 

이 때 복제되는 대상 포트를 Mirroring Port 라 하며, 복제된 포트를 Mirrored Port 라고 한다.

포트 미러링은 주로 Mirroring Port 의 Ingress 트래픽을 모니터링해서 서버에 연결되는 패킷에 대해 감청하는 목적(Ingress Filtering) 으로 사용되며, 용도에 따라 Egress 트래픽을 모니터링하기도 한다.

(여기서 Ingress 는 들어오는 방향을, Egress 는 나가는 방향을 의미한다고 이해하면 좋다.)

또한 네트워크 엔지니어 / 관리자라면 디버그 및 분석 용도로 사용하는 기술이기도 하다.

다음은 포트포워딩과의 개념을 비교한 자료이다.

포트포워딩이 인식된 IP Address 및 Port 를 포워딩된 다른 주소로 매핑시키는 개념이라면, 포트미러링은 패킷을 복제하는 개념이라고 이해하면 쉽다.

Dynamic Contents 와 Static Contents 의 차이는 명확하다.

용어가 생소하더라도 개념은 익히 알려진 내용일 것이다. 그럼에도 짚고 넘어가자면,

Static Contents 는 유저/지역 등 어떤 기준을 막론하고 같은 데이터, 즉 정적 데이터를 말하고,

Dynamic Contents 는 유저/지역 또는 어떤 기준에 대하 다를 수 있는, 동적 데이터를 말한다.

쉽게 이해하자면 변수와 상수의 차이 정도로 보면 쉽다.

너무나도 간단한 개념이지만, 캐싱의 관점에서는 또 다르게 적용될 수 있다.

Static Contents 의 캐싱은 간단하다. 단순히 변하지않는 정적 데이터를 캐싱해주면 된다.

일반적으로 API 등에서 Meta data 를 캐싱하는 경우 In memory 에 캐싱하거나 혹은 설정값으로 관리하는 경우가 많다.

Meta data 가 아닌 종류의 리소스들이라면 CDN 이라는 훌륭한 솔루션이 있고, Cache-invalidation 정책만 조절하여 관리해준다.

반면 Dynamic Contents 의 캐싱은 조금 다르다. 계속 변하는 컨텐츠이기 때문에 자체만으로는 캐싱이 불가능하다.

가령 "Wellcome Home" 과 "Wellcome Tom" 이라는 두 종류의 웹페이지가 있다고 해보자. 앞선 페이지는 Static web page 이고 다음 페이지는 Dynamic web page 이다.

Static web page 의 캐싱은 간단하며, 단순히 해당 페이지(컨텐츠)를 저장하지만, Dynamic web page 의 경우 동적 요소를 따로 분리해서 로직으로 저장해주고(web page 의 경우 javascript 객체로 매핑시켜줄 수 있겠다.) static contents 만 캐싱해서 응답을 재구성하다.

CDN 및 캐시 솔루션 중에는 Dynamic Contents 에 대한 캐싱을 서비스해주려는 노력들이 꽤 있다.

가령 AWS 의 CloudFront 같은 경우 별도의 Backbone Network 를 구성해서 오리진 서버(비즈니스 로직이 처리될 서버)까지의 Latency 를 줄이고 Region 을 확장하는 방식으로 노력을 하고 있다.

서버 / 네트워크쪽 혹은 클라우드쪽 일을 하는 엔지니어라면 베어메탈 서버라는 단어를 심심치않게 들을 수 있다.

Bare-metal Server 란 간단히 요약하자면, "싱글 테넌트 물리 서버 장비(Single tenant physical server)" 라고 할 수 있겠다.

근래 들어 가상화된 서버와 클라우드 호스팅과 비교되어 많이 등장하는 개념으로, "싱글 테넌트" 이기 때문에 물리 장비 하나에서 여러 가상 호스트가 떠있지않은, 그야말로 전통의 서버 인프라라고 할 수 있겠다.

최근에는 Data Center 를 구축해서도 안에 Multi-tenant 환경을 구축해놓는 방식이 많은데, 그 방식이 아닌 서버 머신 하나에 하나의 환경이 구축되는 환경을 말한다.

클라우드 환경에서 AWS 의 솔루션들을 사용하는 데 있어서 AWS Auto Scale 은 그 꽃이라고 할 수 있다.

AWS 의 Auto Scale 솔루션은 서비스의 스케일링(Scaling) 을 자동화할 수 있게 해주는 클라우드 인프라 솔루션이다.

AWS 의 Auto Scaling Group / Launch Configuration / Scaling Plan 와 같은 핵심 구성 요소들을 포함한다.

오토 스케일링 정책을 통한 설정을 바탕으로 몇 개의 인스턴스를 운용할지, 어떤 시점에 Scale 을 늘리고 어떤 시점에 낮출지 결정할 수 있다.

(Scaling 에 대해 잘 모른다면 다음 포스트를 참조하자. 

https://jins-dev.tistory.com/entry/Scaling-%EC%9D%98-%EC%A2%85%EB%A5%98%EC%97%90-%EB%8C%80%ED%95%9C-%EC%A0%95%EB%A6%AC)

이에 따라 Auto Scale 솔루션은 다음과 같은 장점들을 갖고 있다.

1. Cost Optimization

Scale 이 커져서 AWS 의 인프라들을 많이 사용하게 되면 비용이 증가하고 Scale 을 낮출 경우 비용을 절감시킬 수 있기 때문에 비용적인 측면을 같이 고려해서 사용해야 하며,

이러한 측면이 고려된 설계를 한다면 Auto Scale 을 통해 필요한만큼만 리소스를 사용함으로써 비용을 최적화할 수 있다.

(단, Auto Scale 솔루션 자체는 추가 비용이 들지 않는다.)


2. High Availability

Auto Scale 솔루션을 이용하면 Auto Scaling Group 에 대해 여러 Availability Zone 들에 고르게 인스턴스들을 할당하고 해제할 수 있다.

가령 Scale Out 을 통해 인스턴스들의 숫자가 많아질 때 하나의 영역에만 할당하는 것이 아니라 여러 영역에 고르게 분포시킬 수 있고, 해제할 때에도 균등하게 할당을 해제할 수 있다.

3. Well-Architectured Service

Auto Scale 을 통해 실제 요구량보다 많은 리소스를 사용하는 Over-Provisioning(오버 프로비저닝) 이나 실제보다 적은 리소스를 할당하는 Under-Provisioning(언더 프로비저닝) 을 방지할 수 있다.

이는 아키텍처를 설계함에 있어 유연성을 가져다줄 수 있다.


Auto Scale 솔루션은 다음과 같은 수명주기를 갖고 있다.

수명 주기에 따라 Scale Out 된 인스턴스들은 Pending 상태 이후 In-Service 상태로 전환되며 Scale In 될 때에는 Terminating 프로세스를 수행하게 된다.

진행 중인 인스턴스를 Attach 하거나 Detach 하는 과정 역시 라이프사이클에 포함된다.

위와 같은 수명 주기 내에서 Auto Scale 은 주로 CloudWatch 지표를 바탕으로 이벤트가 트리거되며 이벤트를 통해 Lambda 함수를 호출한다던지, SNS 알림을 생성한다든지 하는 다른 작업을 같이 진행할 수 있다

Amazon EC2 Auto Scaling API 에 대한 호출은 AWS CloudTrail 을 통해 추적해볼 수 있다.

JWT 란 JSON Web Token 의 약어로 필요한 모든 정보와 검증을 위한 Signature 를 포함하는 JSON 객체를 통해 만들어내는 토큰의 일종이다.

웹표준으로 지정되면서 계정에 대한 인증 및 API 사용에 있어서 권한 확인을 위한 Security Token 으로 사용된다.

토큰은 지정한 객체(주로 인증 정보가 된다.)를 JSON 화하여 만든 데이터를 암호화하고, 특정 키를 이용해 서명하게 된다. 따라서 발급된 토큰은 해당 서버 / 서비스가 인증한 Token 이라는 의미가 되고, 이는 권한 인증에 있어 Key 로 사용할 수 있게 된다.

JWT 토큰은 Header 와 Payload, Signature 의 3가지 부분을 포함한다.

자세한 설명은 다음을 참고하자.

(https://velopert.com/2389)

JWT 를 사용한 일반적인 인증 절차는 다음과 같다.

 (1) 허용된 API 로 토큰을 발급. 주로 회원가입 / 로그인 API 만을 Token 없이 접근 가능하도록 설계하고, 해당 API 들에서 토큰을 발급해준다.

 (2) JWT Token 이 발급된다.

 (3) 클라이언트는 모든 요청에 Token 을 Header 에 포함시켜서 전달한다.

 (4) 서버는 유효한 JWT 토큰의 경우 인증하고 API 의 사용을 승인시키지만 아닐 경우 401 오류를 표시한다.

이는 일반적인 Token 을 이용한 API 프로세스와 동일하다.

JWT 의 장점은 다음과 같다.

 - 간편한 사용 및 인증 절차

 - Horizontal Scalable

 - REST API 에 최적화된 키 인증 방식

 - Expired date 정보의 포함

 - 관리와 서버 부하에 있어 부담이 적음

반면 다음과 같은 단점도 있다.

 - 인증 정보가 커질 수록 토큰의 크기가 커진다

 - 모든 요청에 토큰 정보가 포함되므로 Token 의 크기가 Message 의 크기보다 커질 경우 비효율적인 통신 구조가 된다.

다음 예제는 JWT 토큰을 이용한 인증절차를 가장 알기 쉽고 직관적인 예제를 통해 설명한다.

구현이 처음이라면 강추 하는 예제이다.

https://medium.com/swlh/spring-boot-security-jwt-hello-world-example-b479e457664c