스타트업 적응기 2: 내 기술의 10%는 1000배가 되었다. - 협업

Preview 

이전 글 스타트업 적응기 1. 내 기술의 90%는 0달러가 되었다. 에 이어지는 글입니다. 

이전 글에서 적었던 AI 코딩 시대 때문에 0의 가치가 된 90%의 기술은 다양한 프레임워크, 기술 스택과 세부 문법이나 사용법과 관련된 것들이었습니다. 그렇지만 전 오히려 (아직까지) AI 코딩이 재밌습니다. 개발이 단축되니 더 다양한 분야에 시간을 쓸 수 있게 되었습니다. 레거시와 기존 코드를 더 빠르고 안전하게 건들일 수 있게 되었습니다. 

링크드인 글 을 통해 입사 후 어떤 행동을 했는지 적었습니다. 링크드인도 자세히 적긴했지만, 블로그에선 좀 더 자세한 이야기를 적어봤습니다. 이번 글은 신규 입사 후 AI를 통해 팀원들께 "신뢰 자산"을 얻게된 과정입니다.

AI를 통해 생산성을 내려다가 내가 감당하기 어려워지지 않으려고했습니다. 코드와 팀 내 프로세스, 모니터링, 운영 등의 환경을 먼저 이해하고 개선하고자 했습니다.

 

입사 후 신뢰 자산을 얻기 위한 태도와 AI 활용들

1. 입사 첫 날 PR을 날리자

아무리 작은 것이라도 말이죠. 회사에 입사를 추천해주신 분이 첫 날에 너무 급하게 생각하지 말라고 하셨지만, 저는 필요하다고 생각했습니다. 신규 입사자의 첫 PR이 언제 나오는지는 팀 내 온보딩이 얼마나 잘 이루어졌는지 판단하는 지표로도 쓰입니다. 그만큼 빠르게 업무 프로세스를 익힐 수 있는 방법입니다. 무엇보다 어차피 해야하는 일들인데 늦게 물어보면 팀원들은 속으로 "아직도 이것도 못해?" 라는 생각이 들수도 있고 시간이 갈 수록 스스로도 물어보기 어려워지기 때문에 빠르게 부딪치고자했습니다.

docker 로 인프라를 키고 seed 데이터가 제대로 안된 것들은 dev 환경을 바라보도록 하면서 겨우 프로젝트를 키고 graphql playground를 호출하는데 성공했지만, 역시 첫날에 의미있는 커밋을 하기는 힘들었습니다. 겨우 admin README에 있는 오탈자를 고치는 걸 찾아서 겨우 PR을 만들었지만 공유하기에도 민망할 정도로 작은 일이었습니다. 이 과정이 의미가 없다고 볼 수 있었지만, 팀 내에 태도에 대한 어필을 할 수 있다고 생각합니다. 또 신규 입사자 시선에서 프로세스를 이해하는데 큰 도움이 되었습니다.

 

2. AI 코딩 에이전트를 "생성"보다 "분석"에 먼저 사용했습니다

AI 코딩 에이전트의 강점은 새로운 코드를 만드는 것도 있지만, 제가 느끼기에는 레거시 코드 분석과 리팩토링에 더 큰 힘을 발휘합니다.

이전 글에서 말씀드렸듯 저는 주로 Java / Kotlin / Python 환경에서 개발했습니다. TypeScript 기반 코드베이스를 이해하고 수정하는 데에는 분명 장벽이 있을 수 있습니다. 그래서 저는 AI에게 몇 가지 관점의 질문을 던지며 코드베이스 분석을 먼저 요청했습니다.
그러자 Claude는 Git history까지 따라가며 컨텍스트를 설명해 주었습니다. 심지어 모바일(FE) 프로젝트 주소를 주고 분석을 시키니 어떤 화면에서 어떤 API를 호출하는지 정리해 주었습니다.
덕분에 저는 핵심 페이지의 주요 요청을 우선적으로 확인할 수 있었고, 코드베이스를 훨씬 빠르게 이해할 수 있었습니다.

프로그래밍 언어를 완전히 알지 못해도 어떤 코드가 핵심인지 어떤 개선점을 생각해 볼 수 있는지 파악하는 데 큰 도움이 되었습니다.

3. 우선 팀의 기존 프로세스를 받아들이고 이해하자 

스타트업에 간 이유 중 하나는 문화를 만들어보고 싶은 마음도 있었습니다. 하지만 그 전에 가장 우선적으로 생각한건 기존 프로세스를 받아들이고 이해한 다음에 이야기를 해야한다는 생각이었습니다. 겉핥기로 기존의 문화를 이야기하면 기존 시스템과 동료를 의도치 않게 폄하 하는 말을 하기도 합니다. 그리고 기존 상황은 그 상황에서 물리적, 자본적, 인적 리소스에서 최상의 결정이었다고 생각합니다. 저도 한 팀에서 오래 있으면서 제가 주니어 때 짠 코드를 다시 고친 적이 꽤 있습니다. 겉으로는 과거의 나를 욕하였지만, 그 상황에서의 나에겐 그게 정말 고민해서 만든 최선이었다는 걸 기억하고 있습니다. 그렇지만 현재 상황이 그 때랑 다르다면 해당 문화나 코드, 프로세스는 그에 맞게 변화해야합니다. 레거시를 이해하고 그 이후 레거시가 만들어진 만들어진 상황을 이해하면 자연스럽게 모두가 공감하는 개선 방향을 의논하고 제안할 수 있습니다.  

이 프로세스 중 제일 큰 걱정은 제가 하고 싶은 "바텀 업 형태의 제안이 통용이 되는 문화인가?" 였습니다.

유능한 인재가 평범해지는 건 주도적으로 제기한 의도들이 무시될 때 일어납니다. 그나마 솔직한 피드백을 받으면 괜찮지만, 숨겨지고 무시되는 경험을 한다면 무력감이 학습됩니다. 그리고 입사할 때 유능한 사람도 그저 시키는 일이나 하고 퇴근 시간만 기다리는 사람이됩니다.

다행히 제가 입사한 회사는 이런 분위기를 장려해주는 문화가 있었고 그러다보니 회사의 프로세스가 잘 되어있었습니다.

사람의 마음을 도메인으로 하는 회사인 만큼 사람 중심의 HR과 점심 팀미팅들이 있었습니다. 개발팀 내에도 PR 문화와 코드리뷰도 시스템에 녹아있었습니다. 그럼에도 부족한 것들이 많았고, 특히 AI 코딩으로 업무 방식이 전폭적으로 변경된 이후에 기존 좋았던 프로세스들이 병목이 되는 상황들도 있었고, 인력의 부족으로 무시되던 프로세스들도 있었습니다. 

그렇다면 기존 프로세스를 빠르게 이해하기 위해 어떤 행동을 했을까요?

 

4. 온보딩 과정에서 배운 것들을 문서로 정리하자

문서화 과정은 솔직히 귀찮습니다. 그러나 새로운 문화에 들어온 사람이 가장 빠르고 안정적으로 같이 일해도 괜찮은 사람이란 신뢰 자산을 쌓는 가장 안전하고도 확실한 과정이라고 생각했습니다.

우선 팀 문서에 제 이름으로된 온보딩 페이지를 만들고 배운 것들을 모두 정리했습니다. 기존 온보딩 페이지를 수정하지 않았습니다. 그 안의 내용들 중에 설명이 부족한 것도 제 페이지에 적었습니다. 잘못 이해하고 바꿀수도 있었기 때문입니다. 그리고 다른 분들에게 비교해보며 어떤 게 맞는지 어떤 게 부족한지 이야기할 수도 있었습니다. 온보딩 문서가 아는 사람의 시선에서 쓰이게 되면 너무 당연하게 여겨지는 것들이 있어서 오히려 디테일이 떨어질수도 있습니다. 신규 입사자의 눈에서 온보딩을 적는 건 꽤나 디테일하게 쓸 수 있습니다. 

제가 이해한 정도 내에서 자유롭게 변경하고 수정하고 생각을 메모하는 온보딩 페이지를 만들었고 공개된 채널이지만 약간은 개인적인 구석 공간에서 정제된 언어로 배운 것들을 적으며 누적해갔습니다.

• 로컬에서 서버를 키는 것 (환경변수들)
• 모니터링
• 수시 업무
• 외부 요청 창구 들 
• 기술 스택
• 인프라 구조
• 배포 과정
• 코드 핵심 프로세스(봐야할 부분)
• 등등 

제가 직접 해보면서 겪은 것들과 해결 방법을 물어보며 문서로 남겼습니다. 그러면 스스로도 모르는 것들이 뭔지 뭘 알아야겠다라는 생각이 들었습니다. 

 

온보딩 글을 쓸 때마다 봐주세요라고 하진 않았습니다. 그래서 위에도 누적이란 단어를 썼는데요. 우선 전체적인 완성도를 가진 후 공유하려고 했습니다. 내가 쓴 것들이 애매하다싶은 부분이 있으면 모았다가 팀원께 정리한 문서가 있는데 시간 나실 때 맞는지 한번 읽어봐달라고 부탁드렸습니다.

이런 방식을 해보니 굳이 팀원분들의 시선을 의도적으로 뺏지 않아도 됩니다. 저도 다른 분들의 눈치를 볼 필요도 없이 제 속도로 병목 없이 이해해 나갈 수 있었습니다.

기존 팀원분들 입장에서도 새로 들어온 사람이 잘하고 있나 궁금할 때가 있습니다. 그러나 나와 직접적으로 얽히지도 않고 내 일이 바쁘기도 하고 낯 가림이 있다면 물어보기 어렵게 다가옵니다. 그럴 때도 개인의 온보딩 정리 문서가 힘을 발휘합니다. 내가 잘못 이해한 것 같으면 알려주실 수도 있고 댓글로 달아주실 수도 있습니다. 팀의 문서 정리방법이나 중요하게 여기는 정보들이 뭔지도 알 수 있습니다. 추후에 슬랙 채널에서 정보를 공유드릴 때 도움이 됩니다. 이렇게 배운걸 공개된 문서에 정리하는 게 서로가 인지적 부하가 적은 과정이었던 것 같습니다. 

어느 정도 양이 생기고 첫 번째 팀장 님과 개인 미팅에서 정리 중이라고 먼저 공유했습니다.  콘텐츠가 쌓이면서 팀원들에게 공유하고 기존 온보딩 최신화에 기여하는 방향으로 갔습니다. 그리고 이 나중에 팀의 온보딩 문서를 제 온보딩 문서 기반으로 최신화했습니다. 그리고 최신화한 문서를 온보딩 스킬형태로 사용하는 것들도 만들어서 팀에 공유할 수 있었습니다. 

 

새로 들어온 개발자의 AI 사용방안

AI가 발전하면서 제가 하고 싶었던 일에서 느끼던 개인적인 병목이 많이 사라졌습니다.
생산성이 올라가면서 더 많은 일을 시도할 수 있게 되었습니다. 하지만 단순히 AI를 코드를 더 많이 만들기 위한 도구로 사용하지 않았습니다.

오히려 동료를 돕고 협업을 더 잘하기 위해 먼저 활용했습니다. 
온보딩 기간 동안  "이 사람은 함께 일할 수 있는 사람이다"  라는 신호를 보내고 팀원들에게 신뢰 자산을 쌓는 것 그 목적을 위해 AI를 사용했습니다.

AI는 "하고 싶다" 라는 생각을 "할 수 있다" 로 훨씬 빠르게 바꿔주는 도구라는 것을요