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 같은 부분들은 큰 도움이 될 것이다.

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

 

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

 

 

그 외...

 

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

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

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

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

 

 

하지만...?

 

 

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

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

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

 

그리고...

 

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

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

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

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

 

 

마지막으로...

 

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

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

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

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

 

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

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

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

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

 

 

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

 



우리나라에도 훌륭한 IT 기업들이 많이 있지만, 많은 개발자들은 이른바 FAANG 이라고 언급되는 Facebook, Apple, Amazon, Netflix, Google 에서 한번쯤 일하고 싶은 꿈을 갖고 있을 것이라고 생각합니다.


본 포스팅을 보면서 혹시 외국계 기업의 취업을 목표로 하고 계신 분이라면 많은 도움을 받을 수 있었으면 좋겠습니다.



1. GlassDoor


해외기업 중 탑급으로 일컬어지는 FAANG 의 경우 너무나도 유명하지만 들어가기도 쉽지 않을 뿐더러 좋은 외국계 회사가 FAANG 만 있는 것도 아닙니다.


실제로, FAANG 급의 연봉을 주면서 좋은 워라밸(Work And Life Balance)을 보장해주는 알짜기업들이 상당히 많습니다. ^^


혹시 제의를 받거나, 관심있는 공고가 떴다면 기본조사는 해봐야겠죠? 





GlassDoor : https://www.glassdoor.com/index.htm


아시는 분들은 아시는 유명한 기업 평점 사이트인 GlassDoor 입니다.


우리나라에는 잡플래닛과 같은 사이트들이 있지만, 해외에서 가장 인지도 높은 사이트 중 하나는 GlassDoor 입니다.


기업의 이름을 검색하는 것만으로도 연봉정보나, 실무자들의 리뷰들을 얻을 수 있기 때문에 구직시 아주 유용하게 사용되는 정보입니다.



2. MOOC 웹사이트


MOOC( Massive Open Online Course) 는 새롭게 떠오르고 있는 온라인 교육 플랫폼입니다.


그 중에서도 개인적으로 이용해본 2가지 사이트를 추천드립니다.



Udacity : https://www.udacity.com/


먼저 Udacity 는 실무 중심의 교육 플랫폼입니다. "Google 사의 XX 엔지니어가 알려주는 안드로이드 강좌" 와 같은 컨셉으로

강의가 진행되며, 상당히 실무에 밀접한 강좌가 진행됩니다. 


장점이라면, 학부강의나 인터넷, 서적 등에서 알기 어려운 실무들에 대해 염두하고 강의가 진행된다는 점입니다.


하지만 아쉬운 점은 대부분 유료강의인 데다가, 입문 강의 이상을 배우긴 쉽지 않습니다.





Coursera : https://www.coursera.org/


Udacity 가 실무중심이라면 Coursera 는 다분히 Academic 합니다. 


주로 대학교 교수님들의 강의가 많으며, 배우기 어려운 대학과정의 원론을 배우기에 적합합니다. 


특히 비전공자로써 소프트웨어 개발자를 목표로 하고 계시다면, 이곳에서 컴공 관련 기초 과목들을 들으시는 것을 추천합니다.


개인적으로는 기술먼저 배우는 것보다 교과과정의 기본을 통해서 숙달하는 것이 좋아보이기 때문입니다.



그 외에도 최근에 많은 MOOC 들이 있고, 대부분의 필요한 수업들을 들을 수 있습니다.


대부분 영어로 수업이 진행되기 때문에 영어로 기술적인 내용을 이해하고 학습하는 능력을 기르는데 큰 도움이 될 것입니다.


해외 취업을 목표로 하신다면 엔지니어라도, 수업을 따라가고 수료할 수 있을 정도로 영어 능력을 기르시는 게 좋습니다.




3. LeetCode


우리나라에는 아직 모르시는 분들이 많이 있으신 것 같아서 포스팅해보았습니다.


실제로 이미 외국계 직장인 포털등에서는 Bible 로 통하고 있는 LeetCode 입니다.


구글에서 시작되어 이제는 많은 외국계 기업에서 대세인 인터뷰 방식인 화이트보드 코딩 테스트와 동일한 형태의 연습을 해볼 수 있습니다.


문제 수도 정말 많고, 지속적으로 업데이트 중인 곳이라 잘 알아두시고, 꾸준히 문제를 풀며 연습하면 큰 도움이 될 듯 합니다.




https://leetcode.com/


당연히 모든 알고리즘 문제는 영어로 설명되어있고, 문제에 대한 토론도 영어로 이루어집니다. 


좋은 점은 어려운 문제들의 경우 솔루션을 직접 제공해주기 때문에 솔루션을 분석하며 준비하기가 아주 좋습니다.


또한 저는 개인적으로 가장 좋게 보고있는 점인데... 다른 알고리즘 사이트들과는 다르게 "알고리즘" 만 다루지 않습니다.


실제 면접을 위한 System Design 이나 Database Design 능력 들도 문제로 주어지고 풀 수 있게 되어 있어서 매우 유익한 사이트라고 생각합니다.




4. Github



Github : https://github.com/

말할 필요가 없는 "깃허브" 입니다. 해외 뿐 아니라 국내의 많은 기업들도 깃허브를 포트폴리오의 좋은 척도로 생각하고 있기 때문에 깃 허브 를 관리하는 것은 매우 좋은 선택입니다.


이미 현직에 계신 분들이라면 대부분 사내 버전 관리툴을 이용하기 때문에 개인 Git 에 큰 의미를 둘 필요는 없을 수 있으나,


신입 개발자이거나 개인프로젝트 또는 오픈 소스에 관심이 많다면 Github 를 통한 포트폴리오는 아주 효과적일 수 있습니다.


개인적으로 관심있는 프로젝트가 있다면 Fork 하고, 다른 사람들에게 PR 을 줘보세요. 그리고 하고싶은 프로젝트가 있다면 당장 깃허브에 올려서 시작해보세요. 많은 현업 경험이 쌓일 것 입니다.


5. Linked In



LinkedIn : https://www.linkedin.com/



아마 많이 들어봤지만 (특히 학생분들이라면) 의외로 링크드인을 실제로 쓰는 분은 많지 않을 것입니다.


하지만, 링크드인을 통한 구직은 개발자로써, 특히 주니어라면, 가장 해외이직을 하는 데 있어서 편한 루트를 제공해주는 SNS 입니다.


링크드인은 자신의 포트폴리오와 경력을 관리하고, 이를 바탕으로 구직/구인을 할 수 있는 SNS 입니다.


해외의 많은 Head Hunter 들 및 인사팀(HR)이 링크드인을 전담하고 있으며 채용 시즌마다 많은 우수한 개발자들에게 러브콜을 날립니다.


자격이 된다면 원하는 기업의 원하는 포지션에 도전할 수 있는 최적의 기회를 제공해주는 곳이라고 생각합니다.




블로그를 방문해주시는 분들의 외국계 기업 취직의 꿈을 위해 큰 도움이 되길 바랍니다.





 Amazon S3(Simple Storage Service)파일을 저장하기 위한 스토리지로, REST API 를 인터페이스로 제공되는 File System 이라고 할 수 있다.

마치 Dictionary 혹은 Hash Table 자료구조 처럼 Key 를 갖고 있으며 해당 Key 에 대한 파일을 Object 형태로 제공하는 구조로 되어있다.

이런 형태의 Object storage는 파일 1개당 1byte부터 5TB 까지의 용량의 저장이 가능하다

Directory와 유사한 개념으로 Bucket이라는 개념을 갖으며 S3에 대한 데이터 신뢰도는 3Copy 사용시 99.99%를 보장한다.


 앞서 언급한대로 S3 에 접근하기 위한 인터페이스로는 File IO가 아닌 REST/HTTP 프로토콜을 지원한다.

즉, 웹사이트에 접근하듯 HTTP url 로 원격저장소의 파일에 접근할 수 있다. 예를 들어 다음 주소를 봐보자.


http://mybucket.s3.amazonaws.com/photos/garden.jpg


위와 같은 주소에서 mybucket은 버킷 이름을, photos/gargen.jpg는 해당 사진 파일에 대한 Key를 의미한다.

얼핏보면 흔한 홈페이지의 주소로 보이지만, 위의 주소는 S3 저장소에 저장되어 있는 사진 저장소의 garden.jpg 파일을 나타낸다. 즉, 해당 주소로 접근함으로써 우리는 garden.jpg 파일을 다운로드받을 수 있다. 마치 "내문서" 의 garden.jpg 처럼 말이다! 

접근할 수 있는 형태로 AWS는 2가지 방식을 지원한다.

 

- 경로 방식

 http://s3.amazonaws.com/버킷이름/키이름


- 가상 호스팅 방식

 http://버킷명.s3.amazonaws.com/키이름

> 여기서 Region이 설정되어 있다면 s3 s3-regioncode 와 같이 바꿔주면된다. 예를들어 서부 유럽의 경우 s3-eu-west-1이 된다.



그 외에도 S3 는 파일시스템 이상으로 제공하는 부가기능으로써 다음과 같은 특징을 갖는다.


(1) Retaining (저장 기간이 지나면 자동으로 삭제), Versioning (파일에 대한 버전 관리), Encryption (Http/Server/Client 단의 암호화) 등과 같은 파일시스템 관리 서비스를 제공한다.


(2) S3는 데이터의 Prefix를 이용해 Partitioning을 수행하는데 이를 통해서 파일을 분산 저장한다. 이는 파티션 당 물리적인 IO를 줄임으로써 성능의 향상을 가져온다.


(3) S3 Multipart uploading Singlepart uploading 방식을 모두 지원한다.

여기서 싱글파트 업로드 방식은 클라이언트가 서버로 하나의 파이프를 통해 파일을 전송하는 방식이고멀티파트 업로드 방식은 클라이언트 서버 간의 여러 개의 파이프로 파일을 블록 단위로 쪼개서 전송하는 방식이다

멀티파트로 전송하게 되면 성능이 향상되고 블록 전송 실패시 해당 블럭만 재전송함으로써 에러 처리에도 뛰어남과 효율성을 보인다.


(4) S3 는 EC2 Repository 에 대한 Access 를 제공하는 서비스이기도 하다. EC2 또는 웹의 어디에서나 Data를 저장하고 관리할 수 있도록 지원하고, 웹 규모의 컴퓨팅 작업을 수행할 수 있도록 설계되어 있다.

또한 EC2 AMI(Amazon Machine Image) 저장을 위해 S3가 사용되며 AMI를 통한 인스턴스 실행저장 및 복구 등 비즈니스 지속성을 달성 가능하다. EC2는 스냅샷(백업 사본역시 S3를 사용해서 저장하고 관리 및 확장한다.


(5) S3는 정적 저장소이기 때문에 설계 시에 Application 이 사용하는 Region 과 Bucket Region 은 같게 맞춰주는 것이 성능 측면에서 좋다.

 

S3를 이용하여 App 설계 시 고려 사항에 대해 Amazon 3가지 정도로 제시한다.


(1)  Internal Errors 에 대한 재시도

Internal Error 가 발생했다면 이것은 Amazon S3 환경 내 오류로 요청을 재시도 할 것을 권고한다.


(2)  Slowdown 오류에 대한 어플리케이션 튜닝

Slowdown 은 리소스 초과에 대한 보호 매커니즘이 자주 요청될 때 발생하는 현상으로 요청 빈도를 줄이면 오류가 사라진다.


(3)  오류 격리

HTTP 오류코드보다 Amazon S3 오류코드가 많은 정보를 내포하므로 격리해서 이 오류 로그를 활용한다.



 

도커(Docker)란 리눅스(Linux) 기반의 컨테이너 런타임 오픈소스로 가상화 기술을 이용한 경량화된 컨테이너를 통해 환경을 격리시켜주고 관리해주는 솔루션이다.




 VM처럼 Docker Engine이 Host 위에서 Container들을 가상화 시켜 관리해주며 이런 환경을 Image 화 함으로써 격리된 환경에서의 모든 어플리케이션들과 리소스들, 그 Dependencies를 전부 포함한 격리된 환경을 구성하고 구조할 수 있다.

(여기서 Host 라 함은 대부분의 OS를 말하고, 그 위에 새로운 환경을 만들어낸다고 생각하면 처음에 이해하기 쉽다. 쉽게 이해해서 OS 안에서 새로운 OS를 구축하는데 그 방법이 VM 보다 훨씬 더 가볍게 이루어진다는 뜻이다.)


여기서 운영체제의 가상화에 대해 간단히 언급하자면 기존의 하드웨어 Machine 에 OS를 탑제하는 것을 가장 간단한 형태의 가상화(Virtualization) 이라고 한다. 


조금 더 경량화된 방식이자, OS 위에서 가상 머신을 돌리기 위한 방법이 반가상화(Paravirtualization) 라 하여, Host OS 위에 Guest OS 형태로 OS 를 별도의 소프트웨어 처럼 동작시키는 방안이 있다. 대부분의 VM Software 들... Virtual Machine 이나 VM Ware 는 반가상화 방식이다.


Docker 는 반가상화 방식보다 경량화된 Container 를 이용하며, 이는 Guest OS 조차 필요없는 운영체제 레벨의 가상화를 구현한다. 그대신 OS 레벨에서의 지원이 필요하기 때문에 아직은 Linux 만 제공되고 있다.



 도커는 Linux 커널이 제공하는 컨테이너 기술(LXC)을 이용하며, 격리된 Container 에서 독립적 작업을 할 수 있게 추상화해준는데, 이 Container 들을 관리해주는 것이 바로 Docker Engine 이다.

(Docker 의 자세한 기술 스택은 추가로 포스팅 하겠다.)


 이렇게 이미지화 한 Container Image들은 Git의 VCS(Version Control System) 처럼 관리 및 배포할 수 있다.(Docker Hub) 이렇듯 설치 및 이용이 빠르고 협업에 있어 손쉬운 패키징이 가능한 장점이 있다. 

이러한 장점들 때문에 Cloud 환경에서 여러대의 서버를 대상으로 환경을 구축하는 것이 매우 편리하며, 각 Instance 에 대한 환경의 일관성이 보장되기 때문에 서버 인스턴스들에 대한 효율적인 모니터링이 가능하다.


 컨테이너들의 효율적인 배포 및 관리와 모니터링 등을 할 수 있게 해주는 것을 Container Orchestration 이라 하며, 이들은 컨테이너의 배치 및 복제, 컨테이너 그룹에 대한 로드밸런싱,  장애 복구(Fail Over), Scaling, Access Control 등의 기능을 갖는다. 다음과 같은 툴들이 대표적이다.





- Kubernetes : 구글에서 만들었으며 최근 각광 받고 있는 Orchestration Tool 이다. VM 환경, Public Cloud 등 다양한 환경에서 작동이 가능하며 손쉽게 접할 수 있도록 지원한다.


- Docker Swarm : 여러개의 Docker 호스트를 클러스터링 하여 단일 Docker Host 를 운영하는 방식이며, 설정 및 운용이 간편하다. 하지만 Kubernetes 만큼 다양한 기능을 제공하진 않는 것으로 보인다.


- Apache Mesos : 확장성이 뛰어나며 다른 아파치 재단의 Hadoop, Hypertable, Spark 와 같은 시스템과 연동하여 쓰기 좋게 되어있다. 



요즘 정말 많이 볼 수 있고, 많은 IT 트렌드 기술들이 Docker 를 응용하여 나은 성능과 효율성을 가져가고 있다. 이미 자리잡은 핵심 기술인 만큼 심도 있게 공부해둘 필요가 있다.




Cloud Layer 계층적으로 서비스를 3가지의 종류로 나눈다.

다음 그림을 보면 이해가 간편하다. 다음 그림은 IT 프로비저닝 리소스들 별로 계층화하여 서비스별로 그루핑하여 잘 나타낸 그림이다.



-      IaaS : 위의 그림의 두번째 서비스를 말하며, Infrastructure As A Service 의 줄임말이다. Memory, Processor, Storage(File System), Network 등과 같은 하드웨어 레벨의 클라우드 서비스를 제공하는 계층을 말한다.

     인스턴스, Storage(Data), 게이트웨이 레벨의 서비스들을 제공하는 형태를 있다. 이 때 사용자는 직접 어플리케이션과 비즈니스에 필요한 데이터, OS 및 런타임/미들웨어들을 직접 선택할 수 있다. 그 외에 가상화나 서버 리소스, 보안적인 부분은 벤더에게 위임하게 된다. AWS 가 초창기부터 프로비저닝하는 방식이고 Microsoft, Google 등 후발주자들도 따라가는 추세이다.


-      PaaS : 위의 그림에서 세번째 서비스를 말하며, Platform As A Service 의 약자이다. 개발자가 개발을 있는 Cloud Platform 제공하는 형태를 말한다. 스토리지, 인스턴스 네트워크 Infrastructure 들에 대한 Platform 제공함으로써, 하나의 서버 형태로 사용가능하도록 한다. 사용자의 어플리케이션은 비즈니스를 위한 데이터와 연동하여 이 플랫폼을 이용하여 원하는 결과를 도출해낸다. 주로 Microsoft Azure 가 초창기에 이런 형태의 서비스를 많이 제공했으며 Machine Learning 플랫폼, Container 관리 플랫폼 등이 있다. 


-      SaaS : 위의 그림에서 네번째 서비스를 말하며, Software As A Service 의 약자이다. System 설치없이 Cloud 에서 이용할 있는 S/W 레벨을 제공하는 형태를 말한다. 대표적으로 Google Docs 같은 소프트웨어 서비스들이 있으며, 이런 개별 소프트웨어들이 클라우드 환경에서 사용할 있도록 제공된다.





멀티 테넌시(Multi Tenancy) : 다중 소유 라는 뜻으로, 자주 언급되는 단어임에도 생각보다 정리가 잘 되어있는 곳이 별로 없어서 정리해보았다.



 소프트웨어 멀티 테넌시란 소프트웨어 아키텍처의 한 종류로 하나의 Software Instance 가 하나의 서버 위에서 여러 개의 Tenant 를 서비스 한다는 의미이다.


여기서 테넌트란 소프트웨어 인스턴스에 대해 공통이 되는 특정 접근 권한을 공유하는 사용자들을 말한다. 멀티 테넌트 구조에서 Software 들은 모든 테넌트들에 대해 인스턴스의 일부분을 단독적으로 제공하기 위하여 설계되어 있다.


이는 개개의 소프트웨어 들이 각기 다른 테넌트들을 위해 서비스되는 멀티 인스턴스 구조와 상반된다.


 멀티 테넌시 환경에서 복수의 고객들은 동일한 데이터 스토리지 매커니즘과 함께 동일한 하드웨어의 동일한 OS에서 실행되는 동일한 Application 을 공유한다. 이는 구성 요소가 이양됨으로써 각 고객이 별도의 VM에서 구동되는 것처럼 보이게 하는 가상화와의 차이점이다.


 Multi Tenancy 란 하나의 소프트웨어를 여러 사용자가 함께 사용하는 것을 말한다. 사용자들은 프로그램을 수정하는 것이 아니라 서비스 제공자가 제공하는 설정 기능을 통해 자신에 맞게 커스터마이징해서 이용한다.


하나의 시스템으로 여러 고객이 사용하는데 고객마다 관리할 필요가 없기 때문에 관리비용도 적게 들고 유지보수가 간편하다. 하지만 하나의 DB로 관리한다는 것은 그만큼 위험도가 높다는 뜻이다.


 클라우드 컴퓨팅의 기본이 아키텍쳐를 공유하는 멀티 테넌시 시트템이다 라는 의견이 있으나 보안 문제가 우려가 되기 때문에 강력한 데이터 암호화 같은 기술이 병행되어야 한다. 많은 경우에 멀티 테넌시 시스템의 예시는 SaaS 의 형태라고 생각하면 된다

(SaaS 에 대해선 다음 링크 참조 : http://jins-dev.tistory.com/entry/%ED%81%B4%EB%9D%BC%EC%9A%B0%EB%93%9C-%EA%B3%84%EC%B8%B5-%EB%B0%8F-%EC%84%9C%EB%B9%84%EC%8A%A4-%EB%93%A4%EC%97%90-%EB%8C%80%ED%95%9C-%EC%86%8C%EA%B0%9C-IaaS-PaaS-SaaS?category=759992)

 

설명이 매우 추상적이라서 보충하자면 일반적인 멀티 테넌시란 하나의 소프트웨어 인스턴스로 여러 고객에게 서비스를 제공하기 위한 아키텍쳐 그 자체를 말한다


이 개념이 클라우드 컴퓨팅에 적용되면서 제공하는 서비스가 가상머신이라면, 서비스 Provider 는 하나의 컴퓨터에 여러 개의 독립된 가상 머신을 만들어 다수의 테넌트에게 이 컴퓨팅 리소스를 서비스 할 수 있게 된다. 그리고 이게 클라우드 서비스 개념의 출발이다.



 클라우드에서 공유 인프라 구축은 까다로운 문제이다. 전통적인 데이터센터 구조는 실 사용량에 비해 과도한 인프라가 구축되어 있어 리소스 활용률이 낮으며 이 때문에 클라우드 컴퓨팅을 통해 개별 어플리케이션, 그룹 또는 고객 간의 리소스가 공유되는 Multi tenant 환경을 이해하는 것이 중요하다.


 많은 기업들(Client)이 보안과 QoS(Quality Of Service) 를 염려하여 클라우드 인프라 구축 및 서비스에 대한 계약을 망설이고 있다. 이러한 이유로 개발된 Secure Multi tenant architecture의 멀티 테넌시의 4대 요소는 다음과 같다.


(1)   가용성 : 공유 인프라 한대에 장애가 발생하는 경우 다른 클라이언트에 영향을 줄 수 있기 때문에 장애가 발생할 수 있는 상황에서도 필요한 컴퓨팅, 네트워크 및 스토리지 리소스를 이용할 수 있도록 이중화 및 기타 메커니즘을 제공한다.


(2)   안전한 분리 : 한 테넌트는 어떤 상황에서도 다른 테넌트의 VM, 네트워크 또는 스토리지 리소스에 접근할 수 없어야 한다. 각 테넌트는 안전하게 분리되어 있어야 한다.


(3)   서비스 보장 : 정상적으로 운영되는 동안이나 장애가 발생했을 때나 특정 테넌트에서 비정상적인 부하가 발생했을 때에도 컴퓨팅, 네트워크, 스토리지가 분리되어 성능이 보장되어야 한다.


(4)   관리 : 모든 리소스를 빠르게 프로비저닝, 관리 및 모니터링할 수 있는 기능이 매우 중요하다. 관리를 단순화 함과 동시에 고객이 특정 벤더에 얽매이지 않도록 하는 것이 중요하다. 타사 어플리케이션 벤더 도 전체 환경에 대한 관리를 제공할 수 있도록 모든 단계에서 API 통합 지점과 Work flow를 상세히 기술하는 것이 중요하다.



Public Cloud에서 대부분의 서비스 제공자(Provider)들은 Multi tenant 모델을 사용한다. 하나의 서버 인스턴스의 사용을 제공하고 유지보수 및 배포가 용이하며 비용면에서 효율적이다.


이 때 public cloud provider는 당연히 각 Client에게 Hypervisor 레벨로의 접근을 허용하지 않으며 당연히 host-level utility (예를 들어 안티바이러스 등의 보안 프로그램들 또는 백업 프로그램들)의 설치 및 사용이 허용되지 않는다.

이러한 특성은 보안상의 영향 뿐 아니라 잠재적인 WAN / Cloud 에서의 Failure 을 포함한다.


 또한 Public Cloud Provider 들은 그들의 하드웨어를 소유하고 Software들을 제어할 수 있기 때문에 Tenant 들의 동의를 구하지 않고도 저수준의 업데이트를 하는 것이 가능하다. 일반적으로는 OS 에 대한 업그레이드 이전에 광범위한 테스트가 수반되나 이런 종류의 업데이트가 Client 들의 소프트웨어에 영향이 미치지 않는다고 장담할 수 없다.


 퍼블릭 클라우드 사용시 비용은 예측할 수 없는 경우가 많다. CPU, 메모리, I/O, 네트워크 리소스 등과 같은 경우 너무나도 많은 변수가 존재하며 이를 대응하기 위해서 효율적인 모니터링 툴이 필요하다.

 

 


최근 대세라고 할 수 있는 클라우드 기술의 중요한 개념들을 포스팅합니다. :)


 퍼블릭 클라우드, 프라이빗 클라우드, 하이브리드 클라우드를 나누는 기준은 서비스 제공주체(Cloud Service Provider) 가 된다.


 Private Cloud 자체적으로 데이터 센터 안에 클라우드 환경을 구축해서 사용하는 방식이다.

회사 내 IT 리소스들을 이용하려는 사용자가 자유롭게 어플리케이션을 개발, 운용할 수 있는 환경을 제공하는 것이 목표이며 기존 IT 인프라를 재활용하고 IT 서비스를 원하는대로 직접 구성 및 제공함에 있어 내부 효율성이 뛰어나다.

 또한 내부 통제가 가능하고 보안성 자체가 확보 가능하다.


 Public Cloud 서비스 제공업체(Vendor)가 구축한 서버, 스토리지 등 IT 인프라를 기업들이 사용료를 내고 이용하는 방식이다. 이를 통해 서비스 엑세스 비용이 절감되며 구현속도와 서비스적인 융통성이 향상된다.


즉 사설 클라우드가 자체적으로 필요한 부분을 보유 및 구축하고 재사용한다면 공용 클라우드는 서비스 제공자가 구축한 서비스를 구매하는 방식으로 구성된다

사설 클라우드는 기존 IT 인프라를 활용가능하다. 소규모더라도 구축 비용이 높고 공용 클라우드는 대규모에 적합하며 구축 비용 자체가 낮다

또한 사설 클라우드는 자체 보안시스템을 운용해야 하나 공용 클라우드는 보안 시스템 역시 제공이 된다.


 Hybrid Cloud Public Cloud Private Cloud의 이점을 모두 제공한다. 최근에는 VM의 공유 및 사설과 공용 간의 동기화 등으로 인해 하이브리드 클라우드 생태계가 발달함에 따라 점점 구분이 모호해지고 있다.

 


+ Recent posts