Jins' Dev Inside

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

특히나 자주 듣게 되는 단어 중 하나는 결과적 일관성(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 같은 부분들은 큰 도움이 될 것이다.

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

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

그 외...

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

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

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

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

하지만...?

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

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

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

그리고...

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

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

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

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

마지막으로...

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

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

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

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

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

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

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

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

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