면접 시 받았던 질문 중 기억에 남거나 대답을 잘 못했던 것에 대한 회고이다.
또는 회사 인재상, 핵심 가치 등 기반한 예상 질문에 대해 준비한 답변이다.
ChatGPT, 구글 gen ai search 등으로 생성한 “컬쳐핏” 면접 질문에 대한 답변이다.
창업가 정신
창업 생각?
없었는데 생겼다. 계기는 강의 콘텐츠를 외주 형식으로 만들어 주는 일을 하게 된 것이었다. 새로운 ‘고객’이 눈 앞에 아른거렸다(회사 일만 하던 그전엔 고객 자체를 크게 실감 못했던 것 같다). Customer obsession(1. 고객 집착(Customer Obsession) )을 크게 공감, 실감했다.
내가 기술의 장인이 되어야 하고 팀과 프로젝트가 성공해야 하는 이유는 간단했다. 고객에게 가치를 전달하기 위해서다. 관점이 바뀐 이후로 회사의 고객 뿐만 아니라 심지어 팀원과 다른 구성원들도 다르게 보였다(나는 ‘내부’ 고객에게 가치를 전달해야 하는 직무로 일한다).
한때 “돈을 벌 수 없다면 비즈니스가 아닌가?”라는 주제로 오래 고민했다. 비즈니스는 아닐 수도 있겠다. 하지만 나를 성장시키는 원동력은 고객에게 가치를 전달하는 것이다. 배포(deployment)는 아무것도 아니었다. 그 후 고객에게 다가가 가치를 전달하는(deliver) 것이 더 중요하다.
위에서 언급한 외주 프로젝트의 결과는 크게 만족스럽지 않다. 계속 도전할 것이다. 창업도 크게 다르지 않다고 생각한다. 회사 생활만으로는 제한적인, 다양한 고객 그리고 고객을 더 가까이 느낄 수 있는 기회이다. 그리고 이것은 회사에서의 나의 직무를 더욱 단단하게 만든다.
스트레스 관리
운동을 (아주 열심히!) 한다
. (참!) 건강하다. 열정을 나뭇가지에 태울 수는 없어서 장작이 되려고 한다.
. (참!) 건강하다. 열정을 나뭇가지에 태울 수는 없어서 장작이 되려고 한다.회사 기술, 프로세스, 코드가 엉망??이라 스트레스 받을 때가 있다. best practice 공부하며 힐링한다. 공부한 것은 이어서 회사에도 녹여내고 비즈니스 가치와 일치시켜서 성과로 만들려고 한다.
가장 OO한 프로젝트
도전적인
개발 순환 과정에 부하테스트를 도입
기술과 문화, 두 가지 측면에서 도전적이었다.
처음으로 기술적 리드와 A to Z를 한 프로젝트이다. 그전까진 소프트웨어 엔지니어에서 DevOps로 직무 전환 후, 많은 것들이 이미 구축된 온프렘 환경에서 일을 했다. 그런데 부하테스트를 위한 stage 환경을 만들기 위해 인프라부터 아키텍트까지 작은 프로젝트의 전부를 경험했다.
장애를 재현하고 개선할 수 있는 좋은 개발 문화를 이끌어낸 프로젝트이다. 당시 장애 대부분의 원인은 DB였다. 쿼리 또는 스키마 최적화를 해야했다. 그러나 대부분 개발자는 DB 튜닝에 대한 막연한 두려움이 있었다. 개발자 스스로 운영할 수 있도록, 장애 관련 수정 영향에 대한 가시성을 높이고 이를 부하테스트 시스템의 결과 리포트에 반영했다. 또 개발했던 경험을 바탕으로, 개발자와 코드를 함께 보며 적극적으로 문제를 해결했다. 개발자의 어려움을 같이 고민하고 의견을 시스템에 반영했다. 시간은 꽤 걸렸지만 장애와 관련하여 개발자 스스로 Dev”Ops” 할 수 있도록 하였다. 나 역시 내가 만든(Dev) 부하테스트라는 제품에 대해서 Ops 한 것이다.
임팩트 있는(보람 있는)
(클라우드) 비용을 줄였던 경우
Karpenter 도입을 통한 비용 최적화: EC2 컴퓨팅 30% 절감
S3 비용 최적화: 월 약 39~52% 절감
https://flavono123.github.io/posts/s3-cost-optimization/ (an old post)
우선 숫자로써 임팩트가 명확하다(e.g. xx% 비용 절감). 그리고 반복적인 수작업을 통해서가 아니라 기술이나 정책 도입을 통해 해결했기 때문에 보람이 있다. 결국 문제를 해결하기 위해선, 클라우드 컴퓨팅 그리고 서비스 이면의 ‘기술’을 이해하고 적용해야 했다. 비용이 엔지니어링의 일급 시민이라 생각한 계기가 됐다. FinOps처럼 좀 더 회사의 재무 경영과 밀접한 프로젝트도 진행해보고 싶다.
문제 해결
장애 상황 대처
항상 선조치 해야 한다. 최대한 빨리 서비스가 가용하도록 만들어야 한다. MTTR(Mean Time To Repair, 평균 복구 시간)을 낮추어 고객에게 미치는 부정적인 영향과 회사가 전달하려는 가치가 떨어지는 것을 최소화 해야 한다.
장애 상황에 대한 가시성, 알림이 없었다면 보완해야 한다. 가능한 영역에서 예방책도 좋으나, 장애는 현실 세계에서 필연으로 발생할 수 밖에 없다. 이러한 인식과 문화가 자리 잡도록 해야 한다.
성공적으로 온콜을 운영하거나 부검(post-mortem)을 해본적이 없어서 아쉽다. 당시 상황에선 이에 대한 이해, 필요성, 동기 등이 충분히 논의되지 않았다. 앞으로는 장애를 관리해야 한다는 인식을 가진 팀원들과 또 그러한 문화 속에서 ‘수명이 10년 줄어들 “뻔한”’ 장애를 대처, 관리해보고 싶다.
DevOps
많은 실패에서 배운 것
WIP
팀 워크
좋은 팀이란?
자주 이야기해야 한다. 경력에 있는 회사 모두 재택/원격으로 일했다. 소통이 단절되는 순간이 생긴다. 자신의 영역만 처리하고 핸드오프하는 방식은 “일하는 방식(메타) 자체”를 성장시킬 수 없다고 생각한다. 진보와 새로운 시도가 없는 현재의 방식에서’만’ 효율적이다. 효율적인 팀 워크를 위한 비효율적인 ‘짓’들이 필요하다고 믿는 편이다. 팀원들의 사적 친밀감 역시 중요하게 생각한다. 이런 것들의 필요성은 과거 같이 일한 개개인(동료/멘토/리더)에게서 느꼈다. 문화로써도 좋은 팀을 만들고 경험해보고 싶다.
커뮤니케이션
“precise and concise 오버커뮤니케이터”
기본적으로 오버 커뮤니케이터다. 개발자들과 기술 이야기 듣고 하는 것이 재밌다. 직군이 같지 않더라도 관련 컨텍스트를 고봉밥으로 얹어 주는걸 좋아한다 .
.하지만 간단, 명료하게 이야기 해야 한다. 그런 피드백도 꽤 받는다. 개선하기 위해 글을 읽고 쓴다. 특히 여럿이 또는 배경지식과 컨텍스트가 상이한 사람끼리, 글은 아주 효율적인 의사소통 수단이다.
지난 분기(4Q 23)에 28개의 블로그 글을 썼다. 작은 프로젝트(ADR)의 한국어 번역 작업도 원저자와 협의하여 진행하고 있다. 앞으론 플랫폼 엔지니어링 관련 글 번역에 기여하려고 한다.
변화 관리
기본적으로 diff를 작게 만들고 적용, revert 하는 사이클을 빠르게 해야 한다.
기술적 변화
새 기술을 도입하는건 재밌다. 문제는 기존 시스템에 영향을 최소화하며 도입해야 한다.
Karpenter를 도입하면서 기존 스케쥴링 제약엔 영향이 적도록/없도록, 새로운 객체를(Provisioner/AWSNodeTemplate) 기존 것(nodegroup, launch template)에 일대일 대응시켰다. 기대했던 비용 절감 관련한 부분(인스턴스 크기 제약)만 변화를 주었다.
변화를 작게 하면서도 충분히 빠르게 도입할 수 있어야 한다. 장애로 이어질 수 있는 중요한 부분이나 예측이 되는 위험은 PoC를 충분히 해야하지만, 그거면 충분하다. 엣지 케이스나 경험하지 못한 상황은 발생하기 마련이다.
조직적 변화
변화하는 상황에서 회사/팀의 목적과 나의 비전을 정렬(align)시키는 것이 중요하다.
팀의 구조와 일하는 방식이 많이 변화하던 때가 있었다. 그때 나는 소수로서(DevOps가 1-2명이었다) 변화에도 스스로 구심점을 찾는 것이 중요했다. 혼자이기 때문에 다른 팀에 끼어 회의를 하기도 했고, 나에겐 비효율적으로 느껴지는 부분도 있었다. 하지만 회사는 ‘빠른 실행력’이라는 목표 때문에 그런 결정을 내린 것이다. 변화를 수동적으로 따르지 않기 위해선 나 자신만의 업무 방식을 가지는 것이 중요하다.
협업 관련한 자신의 철학이 있어야 조직의 변화에서 생산적인 피드백을 줄 수 있다. 나의 경우, ‘더 빠르게’를 요구하는 회사의 상황에서 정책과 문화, 인식으로써 협업 과정을 만드는 것을 역설했다. 이런 것은 시간이 조금 걸리기 때문에 회사가 원하는 것과는 상충했다. 하지만 필요하다고 생각하기에 나의 업무 프로세스와 동의하는 주변 동료들에게 조금씩 전파하고 있다.
그래도 빠른 변화를 시도하는 조직은 건강하다고 생각한다. 빠른 변화는 ‘목적’을 위함이다. 그것이 정책과 같은 더 큰 틀에서 벗어나지 않도록 ‘비전’이 중요하다고 말하고 싶다.
지속 학습
새로운 것을 배우는데에 두려움은 없다. 새로운 것을 모르는 것에 두려움이 있다. 기술적 FOMO를 앓고 있다. 이런 시각으로 보면 배워야 ‘할’ 것이 너무 많기 때문에 가지치기(pruning) 그리고 선택과 집중이 필요하다.
어떤 기술에 집중할까에 대한 답변은 주변 그리고 트렌드에서 얻는 것이 중요하다고 생각한다. 모든걸 다 해보기엔 너무 많은 것이 있지만, 그 중 정말 가치 있고 쓸모 있는 것을 배워야 하기 때문이다. 욕심을 버리는 연습을 매일 한다. 주변을 통해 나 자신과 이 기술의 가치를 객관화한다. 그러기에 어떤 동료들과 함께 있느냐가 너무 중요하다. 업무에 LLM이라 말할 수 있는 AI 기술들을(ChatGPT, copilot, warp, …) 적극적으로 사용하게 된 것도 회사 환경과 동료들의 영향이다.
그리고 회사 외부로도 나아가 커뮤니티 그리고 트렌드도 빠르게 습득하려고 한다. 우선 한국 커뮤니티에서 트렌드를 리드하고 싶다는 생각에 플랫폼 엔지니어링 관련 커뮤니티에서 발표를 계획 중이다.
장기 목표
5년 후 커리어 목표
한국에서 “플랫폼 엔지니어”하면 가장 먼저 떠오르는 사람이 되려고 한다.
우선, ‘플랫폼 엔지니어링’이 나에게 가장 어울리는 직무라 생각한다. 코드로 일하고 결과는 제품으로써 (내부) 고객에게 가치를 전달하는 것이다. 크게 내가 속한 엔지니어링(DevOps, SRE, 클라우드, …) 직무에 다른 역할이 무기가 될 수도 있다(예를 들면, 아키텍트, 인프라/시스템 등). 나는 코드로 일하는게 제일 좋다. 그런데 트렌드가 이와 맞물린거 같다. 이런 비전과 목표가 비슷한 회사/팀에서 일한다면, 5년보다 더 빨리 가능하지 않을까?
갈등 해결
의견 충돌(해결) 경험
최선의 설득 방법은 보여줌으로 증명하는 것이다.
당시 사내 자동화 CLI 툴을 개발하기로 했다. 나는 go로 만들고 싶었다. 쿠버네티스 관련 자동화를 하려고 했는데 go의 API가 가장 좋아보였다. 반면, 팀장은 (go 개발자이다) CLI 만들기에 너무 무거운 기술이라고 반대했다. 파이썬으로 만들라고 했다. 프로젝트 진전 없이 논의만 길어졌다. 2주 정도. 시간이 아까워서 파이썬으로 만들기로 했다. 처음엔 프로젝트를 진행하는데 파이썬으로도 큰 문젠 없었다. 하지만 CLI 프레임워크가(typer) (MVC와 같은) 화면 구성과 데이터 관련한 컴포넌트와 생명주기 부분이 약해서 프로그램 성능이 떨어지는 것을 경험했다.
그 이후 다른 자동화 툴을 go로 만들었다. 이쪽의 프레임워크는(bubbletea) 그런 문제가 없었다. 팀장도 인정하게 되었다(개발은 혼자 했어서 좀 더 내 의견을 주장했어도 됐을까 싶다). 다시 복기해보면, 설득하기 위한 2주의 시간이 아깝게 느껴졌다. 빠르게 PoC 정도의 툴을 만들어서 보여줄까 싶었다. 다음엔 가장 좋게 설득할 수 있는 방법인 보여줄 수 있는 PoC 만들기를 해보려 한다. 그 과정에서 기술적인 배움도 생기고 스스로 판단에 대한 객관화 작업이 될테다.
동기 부여
좋은 동료, 사람들과 함께 성장하는 환경에서 동기가 생긴다.
나는 현재 개인 기여자로서(indivisual contributor) 성장하길 희망한다. 엔지니어 직무의 본질인 ‘엔지니어링’을 가장 주무기로 만들고 싶다. 그런데 개인의 성장이라 하더라도 혼자서 잘할 수 없다고 생각한다. 자극과 영감을 주고 받는 것 뿐만 아니라 검증과 객관화 과정을 통해 실제로 엔지니어링이 더 단단해 질 수 있다.