1. Introduction
📌 Again with the retrospectives?
"또 회고야?"
그렇다, 또 회고다.
정확히는 신입으로 일하면서 취한 전략을 적고, 이를 자가 검토하기 위함이다.
나를 위해 적은 글이라 읽는 사람은 전혀 고려하지 않았다.
그래도 명색이 기술 블로그라 기술 포스팅 비중을 더 높이고 싶으나, 최근에 포트폴리오 첨삭을 하느라 개인 공부 시간이 많이 줄어든 턱에 적을 소재가 별로 없다.
이렇게 많이 들어올 줄 나도 몰랐지...곧 상반기 채용 시즌이라, 인당 8~9시간씩 집중해서 봤더니 두통이 도져서 환기할 겸 적게 되었다.
연말 느낌도 내볼 겸~
나는 2차 면접에서 '책임감'과 '팔로우십'을 강조했었다.
합격하려고 급조한 발언이 아니라, 지금도 중요하다고 생각하고 스스로 내뱉은 발언들이 거짓이 아님을 입증하고 싶었다.
언제나 진실만을 말하겠다는 자신의 철학을 준수하기 위함이자, 이것이 나를 믿고 뽑아준 팀원들과 회사에 보답할 수 있는 유일한 길이라 생각했기 때문이다.
그래서 입사 이후 지금까지 가장 많이 고민하고 연구하던 것은 '내가 어떻게 팔로워십을 발휘할 것인가'에 대한 전략이었다.
단순히 수동적으로 따르는 것이 아니라, Context를 이해하고, 능동적으로 정보를 수집하여, 팀의 일원으로서 목표 달성에 기여하고자 했다.
2. Situation Analysis
📌 Difficulties
회사 생활에 어려움이 있냐 하면 솔직히 없다.
'첫 사회 생활을 이런 곳에서 하면 나중에 다른 곳에서 적응 못 하는 거 아닌가'라는 두려움이 생길 정도로 너무 잘 대해 주신다.
하지만 업무에 어려움이 있었느냐고 한다면, 그렇다.
코딩은 별로 어렵지 않았다.
모르면 공부하면 되고, 급하면 서칭하거나 AI 시키면 될 일이다.
새로운 기술을 학습하는 것은 내게 오락과 같은 것이라 스트레스를 받지도 않는다.
그러나 문제를 정의하기 위한 context가 너무 부족하다.
엔지니어가 '문제를 해결한다'라고 이야기 할 때는 올바른 문제 인식과 정의가 선행되어야 한다.
스타트업이면 빨리 만들어서 회사 수익 창출에 기여해야 할 것이고, 대기업이면 좋은 소프트웨어를 만드는 것에 초점이 맞춰질 것이다.
팀원이 적으면 간결한 아키텍처가 좋을 것이고, 이해 관계자가 많으면 소통하기 쉬운 소프트웨어 구조를 설계할 필요가 있을 것이다.
업무의 중요도가 높으면서 긴급한 안건(보통 버그)은 상황 재현해보고 테스트 작성해서 빨리 구멍을 틀어막는 것이 중요한 반면, 어떤 업무는 일의 전체 흐름을 파악하여 정책 변경의 영향 범위를 신중하게 분석한 후 프로세스를 구축해야 할 수도 있다.
위에서 바라보면 모두 똑같은 "문제"지만, 이 문제들을 어떻게 해석하고 정의하여 최종 솔루션으로 나아갈 지 판단하기 위해선 충분한 context가 필요하다.
하지만 초창기에 업무를 할당받고 설계를 하려고 하는데, 이 때는 뭐 용어부터 이해가 가질 않았었다.
기술적인 용어가 아닌 비즈니스 용어들이 줄줄이 나열되어 있을 때도 있고, 종종 사내 조직이 어떻게 협력하여 움직이는지 이해해야 코드나 아키텍처가 이해가는 경우도 있었다.
문제 정의는 무슨, 뭐가 문제인지도 모르겠는데 이걸 어쩌라는 건지.
일전에 "코드에 기교를 부리지 마세요"라는 포스팅을 작성한 근본적인 원인도 여기서 비롯했었다.
정보 결핍으로 파생된 불안감은 코딩 역량이라도 보여야 한다는 강박으로 이어졌고, 이 탓에 상황에 맞지도 않은 기교를 부리는 결과를 창출해낸 것이다.
그렇다면 어떻게 이 정보 결핍 상태를 극복할 것인가?
나는 예전에 즐겨했던 문명이라는 게임을 현재 상황에 빗대어 생각해보기로 했었다.
📌 Clear the Fog
문명이라는 게임을 들어봤는가.
나는 이 게임을 정말 좋아했었다.
게임을 처음 시작하면 반드시 도시를 세우고, 정찰병을 보내 주위 안개를 걷어내야 한다.
내 근처에 어떤 플레이어가 있는지, 주위에 경계해야 할 야만인이 있는지, 개척할 만한 가치가 있는 영토가 있는지 등을 파악하기 위해서 필수불가결한 작업이다.
그래야 어떤 기술을 먼저 연구하고, 어떤 병사를 뽑고, 어디에 다음 도시를 세울 지 전략이라는 것을 세울 수 있기 때문이다.
회사에 첫 입사를 하면 문명의 시작과 비슷하다.
모든 것이 안개로 뒤덮여있는 곳에서 시작하고, 근처의 플레이어가 누군지 탐색하고, 내가 가진 자원을 어디에 투자해야 할 지 신중하게 전략을 선택해야 한다.
다만 차이가 있다면, 같은 신규 플레이어임에도 나는 고대 시대고 동료는 철기 시대일 수 있다는 점.
그리고 이미 이 게임을 오래 해본 고인물(시니어)들은 일부 지역을 제외한 모든 안개를 없애놓고, 그들만의 시스템과 네트워크들을 이미 구축해두었다는 부분이다.
이러한 정보의 차이가 선택에 많은 영향을 준다.
산맥을 넘어갔다가 존재하지도 않는 야만인과 마주쳐 정찰병이 죽기라도 할까봐 덜덜 떨고 있을 수도 있고,
주위에 바다가 있는 것을 몰라서 이동이 어려운 열대 우림을 헤치며 힘겹게 안개를 걷어내고 있다거나,
시니어 분께서 어떤 방향으로 영토를 확장하자고 결정을 내렸을 때, 그 지역에 대한 정보가 보이지 않아서 이해가 안 가거나, 필수 기술력이 부족해 따라가지 못할 수도 있다.
그래서 내가 입사 후 가장 먼저 취한 행동은 정보를 수집하는 것이었다.
3. Data Collection
📌 Question
초기에 정보를 수집하는 가장 좋은 방법은 질문이고, 다행히도 신입은 뉴비 가호가 걸려있기에 무엇이든 질문할 수 있었다.
하지만 혼자서도 나름의 생각하는 시간은 가지고 싶었고, 특히 업무에 집중하고 계신 상태를 방해하고 싶지 않아서 채팅방에 질문을 브로드 캐스팅하는 방법을 애용했었다.
그러다 9월 말쯤, 리더님께서 저녁을 사주시며 "혼자 생각이 너무 많다. 좀 더 자유롭게 질문을 던져봐라"라는 조언을 해주신 적이 있었다.
'엥, 제가요??'
난 내가 바보라는 것을 자각하고 있기에, 딱히 모르거나 부족한 점을 들키는 점이 두렵지 않았다.
또한 언제나 가장 높은 우선순위에 지식을 놓기 때문에, 지식을 얻을 수만 있다면야 창피함따위 사사로운 감정에 불과했다.
그저 여기서 혼자 고민하는 시간마저 제외한다면, 그건 그저 갓난쟁이 아닌가라는 대한 의문이 들었을 뿐이다.
하지만 뒤이어 다른 리더님께서 "상대를 고려한 질문은 질문이 아니다"라는 조언을 해주셨었다.
질문을 드릴 때 내심 '그래도 혼자 이런 시도를 해봤다'를 어필해보려고 구구절절 말이 길어질 때도 있었는데, 정말 순수하게 내가 모르는 것과 이해하고 싶은 것, 그리고 검증하고 싶은 가설에 대해 마구 질문을 해도 된다구요? (여긴 천국인가?)
물론 그럼에도 질문의 효율을 높이기 위해 여러 전략을 고민해보고, 한 번 알려주신 내용을 두 번 묻지 않게 정보를 인덱싱하는 과정은 필요하다고 생각한다.
하지만 적어도 모르는 게 당연한 것조차 두 번 고민해보지 않아도 된다는 것을 공인해주셨으니, 나는 이 찬스를 기꺼이 사용하고 있는 중이다. (뉴비 가호가 깨지기 전에 하나라도 더 뽑아내야 한다.)
📌 Document
좋은 조직일 수록 문서가 잘 정리되어 있다.
이걸 직접 찾아보는 경우도 있고, MCP를 연결해서 시스템 구조, 비즈니스 용어 등을 몽땅 끌고 와서 rule을 세팅해두거나, 나를 위한 문서를 만들기도 한다.
때론 정보가 없거나, 오랫동안 갱신되지 않은 문서들도 존재한다.
이건 기회다! 오히려 이런 문서를 찾아내 갱신하거나, 새로 작성하는 일은 신입의 역할 중 하나라고 생각한다.
문명 게임을 하다보면 열심히 플레이해서 미래 시대에 도달했는데, 예전에 뽑아놓고 존재를 잊어버린 고대 시대 유닛이 돌아다니고 있는 경우가 존재한다.
시니어 분들처럼 안개를 열심히 걷어내서 많은 정보를 수집할 수 있게 되면, 그 만큼 고려할 것이 많아지기에 사소한 디테일은 놓치기 쉬워지기 때문이다.
그러니 이 쯤에서 다시 질문을 해야 한다.
"이 고대 시대 유닛은 필요한 건가요? 아니라면 업데이트가 필요한가요?"
그런 레거시가 존재하는 이유가 있을 수도 있으니 확인은 해보고, 필요 없다면 정리해서 문서 양을 줄이고, 필요하다면 직접 갱신하는 것이 본인이 기억하는 데도 도움이 된다.
📌 Record
나는 적어도 2가지는 꾸준히 기록한다.
- 질의응답 리스트
- 대면/비대면으로 한 질문과 답변 (다른 팀원이 한 질문까지도 기록)
- 코드 리뷰
- 중요한 정책 결정 사항에 대한 논의
- 팀의 암묵적 지식("개발 완료"의 기준, 배포 전 체크 리스트 등)
- 엔지니어링 노트
- 작업 별 문제 분석부터, 문제 정의, 솔루션 고안, 구현 및 배포 전략, 트러블 슈팅과 이후 고찰 등 모든 것.
세세할 수록 좋지만, 이 모든 것을 기억할 수는 없다.
애초에 내가 모두 기억할 필요가 있는가?
기록만 해두고 AI 시켜서 정리해뒀다가, 필요할 때 쓸 수 있는 환경만 마련해줘도 충분하다.
내가 전에 했던 질문을 또 할 것이 두렵다면, AI한테 질의응답 리스트 정리한 폴더 내 파일들 검색해서 찾아봐달라고 할 수도 있다.
다양한 방면으로 써먹을 곳이 많다.
4. Value Creation
📌 Context-driven Ploblem Definition
지금이라고 엄청난 성장을 이룩한 건 아니지만, 적어도 처음에 비해 의사 결정 과정에 사용하는 정보의 범위가 많이 달라졌다.
그동안 축적한 정보에는 시스템 구조나 업무 플로우 뿐만 아니라, 팀원들 개개인 성향까지도 포함되는데, 이 데이터들을 기반으로 나의 문명을 어떻게 이룩할 지 계획이라는 것을 세울 수 있는 기틀을 다졌다.
이제 영토를 확장하고, 다음 연구할 기술을 선택할 차례다!
입사 직후 "무엇을 학습할 것인가"라는 질문을 마주했었다.
처음엔 막연히 "신입 개발자의 역량 강화"라고만 정의했고, 보통 신입에게는 개발 원론 서적을 추천해주니 이런 것들을 찾아 읽고 있었다.
하지만 이것들은 이미 다 알고 있는 내용들이었고, 이제와서 객체 지향이니 뭐니, 지긋지긋할 정도로 혼자 탐구했던 내용들을 다시 읽어보는 건 어지간히도 따분한 일이었다.
그래서 분위기를 더 관찰해보니, 원칙을 더 공부하는 것보다 팀 컨벤션에 따라 변화를 주는 것이 더 중요한 상황이라, 차라리 "실질적으로 기여할 수 있는 역량 강화"로 문제를 재정의하는 것이 좋아보였다.
이해가 부족한 OpenSearch와 Kafka 내부 구조와 쿼리 튜닝에 대해 좀 더 분석해보고, 실용주의 프로그래머의 내용을 실천해보거나, AI 엔지니어링에 더 많은 시간을 투자하는 것이 조직에 기여하는 역량을 기르는데 훨씬 합리적이었다.
(혼자 AI Agent 만들어보겠다고 사내 인프라 뒤져보다가 알게 된 정보들이 리더님께 도움이 되었을 때 대-만족한 적이 있었다.)
업무 측면에서는 두 가지 변화가 가장 컸던 것 같다.
- 개발 기간 산정
- before: '이 기능을 구현하는 데 며칠이 걸리지?' 정도만 고려하고, 개발 기간 산정을 위해 필요한 문제 정의 시간에도 많은 투자가 필요.
- after: 우리 팀의 업무 프로세스와 작업 복잡도에 따른 별도 코드 리뷰 회의 필요성, 다음 릴리즈 기간, 업무 중요도와 다른 업무와의 관계성 등을 함께 고려하여 결정. (여전히 예측이 빗나가는 경우가 많긴 하다.)
- 작업 프로세스
- before: 좋은 소프트웨어의 원칙을 기반으로 한 주변 레거시 코드들과의 조화, 작업 유형에 따른 서브 태스크 분할 등. 내 작업 내용이 가장 큰 관심사.
- after: 작업이 영향을 주는 컴포넌트들을 분석하여 배포 전략과 필수 테스트 케이스, PR에 담겨야 하는 정보, 오버/언더 엔지니어링 경계, 지속되는 실수를 방지하기 위한 자신의 작업 프로세스 셀프 개선, 필요한 추가 context를 효과적으로 수집하는 방법, 내 아이디어를 팀원에게 납득시키기 위해 PR에 담아야 할 내용 등. 전체 프로세스와 팀 문화도 고려.
안개를 어느정도 걷어내니, 단순히 '빠르게 성장하겠다!'라는 의욕을 넘어, '승리 조건을 위한 최적의 결정이 무엇인가'를 합리적으로 고민할 수 있게 된 것이 가장 기분이 좋았다.
✒️ 여전히 미흡했던 부분
얼마 전, 어떤 태스크를 할당받았다.
영향 범위를 분석해보니 A, B, C 컴포넌트에 걸쳐있었고, 작업 특성 상 C를 배포하려면 A, B 배포가 선행되어야 했다.
그런데 B 컴포넌트 배포 후 실행이 완료되어야 C를 배포할 수 있는데, 이게 하루만에 끝날 양이 아니었고, 무결성 검사도 필요하다고 판단하여 다음과 같이 보고했었다.
"A, B는 이번 릴리즈에, C는 다음 릴리즈에 배포하겠습니다."
그런데 A, B 컴포넌트 배포할 때 다른 태스크도 같이 반영해달라는 요구가 추가되었고, 혹시나 어려울 것 같으면 릴리즈를 다음으로 미루는 것까지 고민해봐도 좋다는 말씀을 주셨었다.
확인해보니 해당 태스크 또한 A, B 컴포넌트에 영향을 주는 사안이었는데, 나는 두 태스크가 완전 별개의 작업이라 생각하여 "해당 작업을 이번 릴리즈에 반영하기는 어려울 것 같아서, 일단 이번 태스크만 배포하겠습니다."라고 말씀을 드렸었다.
그러나 "뭔가 포인트가 다른 것 같은데, 추가된 태스크가 해결이 안 되면, 배포 나가도 되는 건 사실 A 컴포넌트밖에 없어요."라는 답변을 받았었다.
이 말씀을 듣고 한 10분동안 고민을 했던 것 같다.
'대체 왜지, 적어도 작업해둔 거라도 먼저 배포해두는 것이 전체적으로 빨라지는 것 아닌가..?'
이 고민의 해답은 두 태스크가 별개의 것이라는 전제를 부시고 난 후에야 비로소 이해가 갔는데,
이후 추가된 태스크가 정책 전반에 영향을 주는 사안이라서,
이게 변경되지 않으면 앞선 태스크가 배포가 되어도 의미가 없었던 것이었다.
즉, 각 태스크 별로 기술적인 의존성을 파악해 컴포넌트 간 연결을 하는 것은 성공했으나,
비즈니스 의존성으로 인한 정책에 대해선 완전히 놓치고 있던 것이었다.
어렵다 어려워.
앞으로는 비즈니스 의존성에 대해서 고민하는 과정도 포함시켜야 할 것 같다.
📌 Proactive Gap Filling
기존에 존재하던 인수인계서를 수정하다가, 최근에는 아예 새롭게 작성하고 있다.
'신입인데 인수인계? 벌써 이직 고려하시나요?'라는 질문을 받기도 하지만, 한 번 쓰고 끝이 아니라 계속 발전시키는 목적으로 사용하기 위함이다.
인수인계서를 신입 때 작성하는 것은 나와 미래에 들어올 신입 모두에게 이득이다.
- 내가 잘 모르고 있는 프로세스를 적다가 스스로 알게 되거나, 잘못 알고 있던 내용을 사수분이 캐치해서 바로잡아주실 수 있다.
- 같은 신입의 입장에서 서술했기에 디테일이 시니어가 작성한 내용과 사뭇 다르다. '모르는 것'에 대한 공통점이 많기에 미래의 신입에게 더 도움이 될 수 있다.
또한 최근에는 Boy Scout Rule을 가슴에 새기고 있다.
단순히 코드에 국한하지 않고, 오래 갱신되지 않은 문서나 보완이 필요한 정보, 업무에서 개선되어야 할 프로세스(시니어분들은 너무 익숙해져서 비효율인 것을 발견하지 못하는 경우도 있다) 등을 하나라도 더 찾아내려고 노력 중이다.
📌 Knowledge Sharing
내가 배운 것을 공유한다고 해서 딱히 큰 도움이 되지 않을 것이라는 두려움.
그러한 두려움은 나도 가지고 있다.
이런 건 '그래서 뭐, 난 신입인데 어쩌라고.' 마인드를 장착하면 한결 편안해진다.
그리고 애초에 신입에겐 '기대 안 함'이 디폴트라서, 내가 이상한 걸 들고가도 '당연한 상황'이기에 무조건 본전이다.
사실 이러한 행위는 스스로를 '신입'이라는 프레임에 끼워 맞추는 기저 심리를 깨부시는데 도움이 된다.
내가 하는 것들은 모두 기초적인 것이라 여기게 되고, 잘 모르니까 선뜻 의견을 제시하기 어려워지고, 이러한 심리적 요인이 자신의 한계를 결정짓게 하여 수동적인 태도를 고착시키게 만든다.
그러니 진정한 followership을 기르고자 한다면, 프로 의식을 키우기 위해서라도 눈 감고 내질러봐야 한다.
도움이 될지 안 될지 판단하는 것은 그들의 몫이다.
(단, '아님 말고' 식의 부정확한 정보를 던지는 건 자중해야 한다. 이게 습관인 사람의 말은 신뢰하기 어려워진다.)
이러한 활동의 일환으로 10월 말에 사내 게시판에 내가 맡은 업무를 수행하는 과정에 있었던 의사 결정 과정과 문제 해결 플로우를 가득 담아 글을 하나 작성했었고,
최근에는 OpenSearch에서 deep pagination을 할 때, search after에 PIT을 적용했을 때 어떤 차이가 있는지 분석해서 PR과 블로그에 작성한 포스팅을 공유했었다.
또한 평소에 코드 리뷰, PR, 채팅방에도 넌지시 이것저것 던져보고 있다.
그냥 신입이라 귀엽게 보는 경우도 있긴 한데, 가끔은 팀원분들이 새로 알게 되었다는 말씀을 해주시면 제법 뿌듯.
그런데 애초에 이걸 귀 귀울여 들어주는 문화가 마련되어 있기에 가능한 게 아닌가 싶긴 하다.
5. Conclusion
📌 항상 마지막에 소주제 뭐 쓸지 고민이 되는데, 생각이 안나서 아무거나 채워 둠.
Followership을 잘못 해석하면 위 영상같이 변질될 수도 있기에 조심해야 한다.
근데 사실 나도 저거 해보고 싶은데, 타이밍을 못 잡아서 아직 못 해봤다.
입사 후 6개월이 지난 지금.
나는 얼마나 많은 안개를 걷어냈을까.
솔직히 말하면 여전히 안개 투성이다.
이제 겨우 한숨 돌릴 수 있을 정도로 탐색은 해놨는데, 사수 분께서 하고 계신 작업을 내가 할 수 있는지 생각해보면 아직 멀었다.
비즈니스 의존성을 놓쳐서 삽질할 뻔한 사례처럼 여전히 놓치는 것들 투성이다. (진짜 무서운 건 이야기해주기 전까진 놓친 줄도 모르는 것도 많다는 사실)
뭐, 근데 조급해 한다고 딱히 달라지는 것도 없고.
지금처럼 계속 정찰병 보내서 안개 걷어내고, 추가된 정보로 정책과 전략을 재수립하고, 새로운 기술을 꾸준이 연마해나가면 되지 않을까.
+ 계속 문명 예시를 들었더니 간만에 문명이 하고 싶다는 생각을 죽이느라 힘들었다. 🥲