• Loose coupled • MSA • Event Process • Autoscaling - instance termination • Data Lake
Why systems need to interchange Large Data?
• Realtime Data Processing • Business Metric • Service Metric • Application Log • System Metric • Longterm Data Processing • Realtime Event Triggering • Separation service instance and data instance
빠른 commit및 2 phase commit의 lock을 제외하기 위하여 asynchronouse로 설정한다.
이럴 경우, replication delay가 존재한다.
Partition tolerance
하다고 말할 수 는 있음
모든 노드에 동일 데이터가 복제되기 때문
Consistency
- Transaction을 지원하여 일관성을 보장하지는 않음.
replication 사이에 데이터 유실이 발생할 수 있음.
2. Mysql : Cluster version
shared nothing 방식
다중 노드에서 쓰기 읽기 가능 -> sharing하였기 때문
Partition Tolerance
- cluster edition에 한해서 multi cluster 를 지원하지만 어떻게 sharding해야할지는 사용자가 나눠야 한다. 이로서 cluster에 대해서 consistency와 availiabilty를 유지하면서도 performance를 어느정도 만들어내지만 단점은 전체 데이터 조회시는 전체 cluster를 scan해야하며, 이로서 특정 데이터는 partition에 dependency가 있다. 즉 partitioning tolerance는 만족하지 못한다.
2. Oracle 관련
- Oracle DataGuard
오라클 또한 Oracle DataGuard란 옵션을 이용하여, replication 노드를 구성하면, master slave로 구성이 되며,
한쪽이 Active, 다른 한쪽은 inactive or readonly로 구성한다.
(readonly로 구성하면, 일년에 3일 이상 가용하면 비용이 발생하는데, 그래서 옵션구매를 하는 것이 Oracle ActiveDataGuard ) 이다.
현업에 계신 모든 사람들이 여기에 많은 의견을 낼 수 있으리라 생각하며, 실제로도 또한 그러하다. 신입 조차도 자신의 인터뷰 경험을 방법으로 좀 더 나은 방법이 뭐가 있겠냐 하면 많은 아이디어를 밤새 내 놓을 수 있으리라, 많은 인터뷰 방법, 인터뷰 질문들, 추천, 단계별 채용, 검증 방안 ... 그렇게 통과한 사람들은 여러분의 주위에서 일하고 있는데 다들 원래 뽑고자 했던 인재의 이미지와 매칭이 되어 있는가?
요즘은 채용에 AI를 도입하여 공정한 면접과 지표화된 결과를 받으려 한다. 블라인드 면접을 해야고 주장을 하는 것 보면 얼마나 사람은 자기에 주관적인 면접을 한다는 반증인가?
최근에 면접관을 어쩔 수 없이 맡게 되어, 이렇게 정리를 하면서도, 마음이 불편하다. 나 또한 사람을 평가할 수 있는 위치에 있는 것도 아닌거니와 인터뷰에 있는 기술에 대해서 설명을 다 할 정도가 되는가는 나 스스로 알기에, 나 또한 이 인터뷰 문제를 보며 새로이 배운다. 좀 더 솔직히 말하자면, 배우고 이전에 익혔어도 여전히 새롭다.
재능이란 것을 수치화 하는 많은 시도가 있었으며 이러한 것이 쉬운 일이 아님을 잘 알지만, 이러한 것이 잘 되지 않는다고 하여서 앞으로도 이러한 시도가 진행되지 않을 것이라고는 그 누구도 확답하지 않을 것이다. 이 글을 쓰는 시점에서 사람의 재능은 우리가 예측하고, 상상한 것보다 뛰어다고 믿고 이러한 재능에 지식도 있지만, 열정이라는 한 부분을 측정할 수 있는 것에서도 고민해보고 이를 찾아 낼 수 있는 질문도 고민해보고자 한다.
나의 현재 큰 인터뷰의 방식은 다음과 같으리라, 인터뷰 시간, 1시간 30분이라면, 45분 정도는 기본적이고 짧은 시간에 답변할 수 있는 그럼 질문을 다양한 주제, 영역에서 물어보아 그 사람의 기술적 지식을 학교, 프로젝트, 경험과 상관없이 확인한다.
그리고 45분은 지식과 상관없이 자신이 좋아하는 기술적 주제 혹은 자신의 기술적 경험 중에서 얼마나 그걸 극복하기 위해서 자신을 불태웠는지를 측정할 수 있는 질문들을 고민해보고 적고자 한다.
아 그리고 지금은 모든 질문을 공개하지는 않을거지만, 질문만 장황하고 답변이 없는 그런 글은 만들지 않을 것이다. 내가 명확하게 답변할 수 없는 것들을 질문하지 않으리라, 그리고 이러한 답변도 공개하여 내가 먼저 아는 것이 지식이 되는 것이 아닌 좀 더 진리를 찾아 갈 수 있는 그럼 질문과 답변을 공유하여 꼭 인터뷰가 아니더라고 이를 통해 내 지식과 견해를 늘릴 수 있는 곳이되고록 해야하겠다.
좋은 엔지니어란 이란 정의를 채우기는 힘들지만,
좋은 엔지니어링 팀을 만드는데 같이 고민을 하고 기여를 하는 엔지니어라고 정의를 한다면,
좋은 엔지니어링 팀만 정의하면 되는데 일전에 페북에서 보았던 글을 기억하면 다음과 같은 것을 할 수 있는 팀을 좋은 엔지니어링 팀이다 라고 하는데 공감했던 것 같다.
다음 글을 참조
2018.4.30일 작성
========
2023.07.08
이 글을 다시보며, 글이 뭔가 결론을 못 내린 것도 있는 느낌이었고, 저장된 걸 보니 2018년이었다. 그 사이 우리가 예상치 못했던 코로나도 지났었고, 나 또한 여러가지 경험을 해 보면서 좋은 엔지니어에 대한 그 간의 경험과 생각을 정리해보아야 겠다는 생각이 든다.
코로나 :
코로나 터진 이후로, 코로나를 에상못했다고 했지만, 코로나때 코로나를 알기 위해서 코로나 관련된 책을 읽을 결론은 우리가 알지 못했지만 벌써 이와 관련된 사람들과 단쳬는 이러한 심각성과 영향을 경고했었다. 코로나 이후로 우리의 문화도 많이 바뀌었다. 회식을 늦게까지 하지 않고, 재택 문화가 많이 자리 잡혔다. 온라인 관련 사업이 그 사이 많이 늘었다. IT가 필요 없던 분야에서 까지 IT를 도입하기 위한 노력이 예전보다 많아졌다. 그래서 개발자는 더 부족해진 느낌이다. 반면 코로나 때 많은 중소형 소프트웨어 업체의 경영이 어려워졌다.
원격/재택 업무 :
코로나 이전에는 각종 보안이유와 관리 이유를 들어서 못하던 기업들이 어쩔 수 없이 폐쇄 및 격리를 해야되다보니 더 이상 시대의 기류를 막지 못하여 재택의 문을 열었다. 그렇다고 의사 결정하시는 분들의 의식이 오픈되는 건 아니였으니 하는 업무는 그대로이다. 기존의 룰과 보안정책, 좀 더 효율적인/생산적인 근무 환경을 고려하기 보다는 최대한 열어주지 않는 쪽으로 그대로 유지되는 모습을 많이 보았다. 그러면서 자연스럽게 재택이라는 문화가 자리 잡은 듯 하다.
IT기업 :
온라인으로 뭔가를 해야된다는 탓에 기존에 IT가 전혀 필요 없던 곳까지 시스템/앱/모바일 등을 도입하려고 한다. 여기에는 실제 효율화 보다는 세상이 바뀌니 뭔가 IT를 도입해서 돈을 벌고 싶다는 건데, 대부분은 개발자를 넣어서 자기가 하던 업무 그대로를 IT로 옮겨놓는 것에 불과해 개발자의 인건비 및 IT 인프라 비용으로 지출이 많아서 IT 사업을 한다는 것이 돈이 많이 든다는 결 체험하신 분들이 많아진 듯 하다. 대신 IT로 뭔가 수익을 이루어 내기는 쉽지 않은 것 또한 깨달으신 분들도 많다.
이직 :
코로나 기간동안에는 채용도 쉽지 않았고, 이직도 쉽지 않았다. 다들 가만히 있는 분위기 였다. 언제 끝날지를 모른다는 생각에 먼 미래 보다는 당장의 급한 불과 현상 유지를 하는 쪽으로 가깝게 운영된 듯 하다. 초기에 top management쪽에 계신 분들이 코로나 3년 간다고 본다라고 했던 말이 실제로 그랬다. 어떻게 그 분들은 그걸 예측했을까? 그 분들에게는 우리와는 다른 정보가 유통되는 걸까 하는 생각이 들었다.
코로나가 풀리는 시기에는 기존의 억눌렸던 것이 나와서 많지만 조용한 변화가 많이 이루어졌던 것 가다. 많은 사람의 변동이 있었지만, 거리두기가 몸에 베여서 실제 조금 옆에는 무슨 일이 일어났는지 관심도 없고 소식의 전파도 느려진 것 같다.
격차 :
IT의 변화의 정도가 큰 곳에 계신 분들과 코로나 이전과 비슷한 환경에 계신분들과의 기술/문화의 격차가 더 커진 듯 하다. 같은 문화/조직 하에서도 변화가 심한 곳과 느린 곳의 차이는 누구의 표현을 빌리자면 도시와 시골의 느낌이였고, 다른 문화/회사에 계신 분들과 교류해보면, 소외 이직을 하시는 분들이 그 회사가 좋은 곳이지만, 4-5년간 똑같은 업무만 하고 있고, 이러다 도태될까봐 이직을 결심했다고 하거나 혹은 제가 있던 회사에서 top이 였고 자신감으로 이직했지만 새로운 곳에 와보니 그 동안 제가 뭘했지? 나는 할 수 있거나 아는게 왜 이렇게 없을 까? 라고 느꼈다고 하신 분들의 피드백이 기억에 남는다.
팀 :
그 사이 하나의 팀을 만들어 보기도 하였고, 팀 내에서 갈등이 많았던 팀에서 조율도 해보았고, TF로 만들어진 팀에서 극도로 적은 인원으로 버텨보기도 하였고, 크리티컬한 팀이 망가져서 다시 리빌드도 해보았다. 새로운 팀을 만드는 건 기존 방식으로는 도저히 안되니 Agile이 가능한 팀을 만들어보자였는데, 결국은 Agile이 아니라 Spec만들고 Spec 협의하고 도장찍고 개발할 수 밖에 없는 계약관계에서 Agile하게 빨리 개발하자가 목표가 되더라. 누가 비유하던데, 코끼리가 치타처럼 뛰게 만들게 하는 방법이라는 것을 요구하는 것과 같은 결론이다. 결론은 다들 짐작하리라 본다. 팀 내 갈등이 많았던 사례는 기존에 있던 레거시 시스템을 개선하기 위해서 문서와 개발 중 뭐가 먼저 중요하야이다. 문서가 없으니 개발을 못한다와 개발을 하면서 문서를 만들어 나가자로 뭐가 더 옳은지를 위해서 오래동안 논의했지만 결론이 안났다, 당연히 결론이 안나는 문제를 결론을 내자고 하는 케이스이다. 시간만 낭비하고 갈등만 켜지다가 결국 사람이 떠나가는 것으로 가는 수순을 밟는다. TF로 만들어진 팀은 처음에는 잘 운영되지만 결국 중심의 부재로 이곳저곳에서 간섭을 받는다. 결국 미생이다. 크리티컬한 팀이 망가져서 리빌드 하면 둘 중 하나인데, 성공하느냐 실패하느냐이며, 성공하면 안정화 되고, 그럼 크리티컬한 팀이기 때문에 누군가 이 팀을 차지한다. 실패하면 책임을 지거나 아니면 성공할 때까지 푸시를 받는다.
면접 :
여러 팀을 거치면서, 여러 사람과 같이 개발하고, 여러 사람을 면접하고 채용하면서, 2018년에 채용했던 사람이 어떻게 변화해 가는지도 추적해 보았고, 내가 직접 적인 영향을 주었을 때와 주지 않았을 때 어떻게 갈지도 보아왔다. 채용의 기준을 많이 올려서 보기도 해보았고, 다른 사람의 채용 노하우도 듣고 그대로 따라 해보기도 해 보았다. 하지만 좋은 엔지니어를 판단하는 기준은 여전히 모호하다. 오래전에 나는 괜찮다고 판단했지만 많은 분들이 우려했던 나보고 책임질 수 있겠냐는 질문을 받았던 후보자들이 들어와서 지금 성장하는 것을 보면 그 때 보았던 기준이 여전히 우효한 것 같다. 자신의 환경을 바꾸기 위한 방향과 그 노력이다. 여전히 그 분들은 그러한 노력을 하고 계신다. 나도 그 분들을 보면서 그러한 노력을 조금 더 해보자고 다짐하곤 한다.
그런 변화 속에서 좋은 엔지니어를 키우는 것과 찾는 노력을 해왔으며, 2018년 보다는 insight가 생긴 듯 하고, 결론은 아래와 같다.
좋은 엔지니어란 아래와 같은 질문에 답을 할 수 있어야한다.
1. 개발에 더 나은 방향을 선택하는가?
2. 개발에 모르는 것에 대해서 질문하는가?
3. 개발을 즐기는가?
4. 개발로 인류를 이롭게 하는가?
여기에서 중요한 점은
이 4가지 질문에 모두 Yes이냐가 아니라 1-4가 No이더라도 다음의 질문에 Yes라고 답할 수 있느냐이다.
