스타트업 적응기 3: 내 기술의 10%는 1000배가 되었다. - AI를 잘 쓰기 위한 시도

Preview 

스타트업에 입사한지 3개월이 되었습니다. 이전에 글에서 쓴 것처럼 AI를 통해 완전 다른 규모와 다른 기술 스택의 회사였지만 빠르게 실무를 맡아 진행할 수 있었습니다. 

회사 온보딩 중 6주차에 중간 평가를 받았었는데요. HR에서도 이정도로 좋았던 분이 없었다는 극찬 아닌 극찬을 받았습니다. 굉장히 직설적이고 고쳐야할 점 위주로 진행했었는데 이번에는 가벼운 티타임 정도로 평가가 마무리 되었습니다.  

그래서인지 온보딩이 끝났을 때 다른 미팅이 없이 정규직으로 전환이 되었습니다. 

그렇다면 이전 글에 이어서 전략적으로 회사에 잘 녹아들기 위해(온보딩) 어떤 일들을 했는지 적어보겠습니다. 

 

AI를 활용하면 더 쉽게 회사에 적응할 수 있습니다. 

이전 글을 요약하면 다음과 같습니다.

• AI 코딩 에이전트로 코드 베이스 분석 및 이해하는데 사용
  • AI한테 백엔드 코드들 뿐아니라 호출하는 프론트엔드 코드의 요청 부분까지 분석에 활용
• 온보딩 과정을 문서화하며 팀원들 신뢰를 구축
  • 최대한 빠르게 업무 프로세스 경험, 빠르게 질문 (PR)
  • 구전되던 프로세스들을 정리하고 클로드 스킬화

AI는 새로운 작업을 하는 것도 좋지만, 기존 코드 베이스를 분석하고 이해하는데 더 탁원한 성능을 보입니다. 

그리고 이런 협업을 위해 신뢰를 쌓고 콘텍스트를 익히는 과정이 1000배가 된 10% 기술이라고 생각합니다.  

 

오늘은 AI 코딩을 통해 더 많이, 더 빠르게 시도해볼 수 있었던 것들에 대해 정리해보려고 합니다.

1. 도메인 이해도가 부족해도 할 수 있는 일부터 개선해보자

3일 차에 장애가 발생했습니다. 

원인은 현재 배포 버전이 아닌 버전이 빌드되어 latest로 되어있었기 때문에 벌어졌습니다. 업무 시간에 있었던 일이지만 문제는 저녁에 발생했습니다. 유저 요청이 많은 시간대에 auto scaleout 이 되면서 문제가 생긴 것이었습니다. 

다음 날 장애 대응 리뷰 회의에서 냉큼 제가 한다고 했습니다. 배포 과정을 개선하는 건 도메인 지식이 필요한 일은 아니었고 수정 사항도 크지 않아기 때문에 오히려 부담이 덜했습니다. 

github action은 업무에서 사용하진 않았지만 사이드프로젝트와 강의를 하면서 이해도가 높았습니다.ci/cd 과정도 별로 다를 건 없었고 빠르게 작업했습니다.

개선 과정에서 build 결과물의 네이밍 규칙 등 자잘한 개선사항을 논의드렸고 꽤 많은 부분들이 accept 되어 배포에 같이 나갔습니다.

팀 입장에서 온지 1주일도 안되었기 때문에 제 결과물을 아직 신뢰하기 어렵기 때문에 검증하는 기간이 좀 있었습니다. 그래서 검증 결과(스크린샷), 알람 동작 여부까지 적극적으로 공유했습니다.

도메인 이해도(동작 이해도)가 부족하면 놓치는 게 있을 수 밖에 없습니다. 그러니 AI를 잘 써서 코드를 제대로 짜온다고 해도 신규 개발자 스스로가 검증할 수가 없습니다. 하지만 위와 같이 도메인 이해도가 부족해도 개선할 수 있는 일들이 꽤 많습니다. 그런 일들부터 시작하면 좀 더 빠르게 전체 시스템과 프로세스를 이해할 수 있습니다.

 

2. 업무 제안을 하고 싶다면 우선 동료들에게 스몰토크를 걸어서 콘텍스트를 확인하자 (여론을 조성하자) 

업무를 할당받거나 기존 팀의 업무 프로세스를 익히다 보면 개선할 수 있을 만한게 보이기도 합니다. 

하지만 이런 업무 개선 제안들은 현실적으로 하기 어려웠습니다.

1. 기존 프로세스를 선택한 이유가 존재
2. 우선순위가 낮아서 반려
3. 제안한 사람이 기존일에 더해서 진행해야하는 구조

이런 개선 작업을 함부로 제안을 하면 우선순위가 낮아서 반려가 되거나 승인이 되더라도 제안한 사람이 기존일에 더해서 하게되는 구조가 대부분이기 때문에 쉽게 하지 못합니다.

 

그러나 이제 AI 덕분에 마음 껏 업무 제안을 할 수 있습니다. 오히려 기획이 개발 속도를 못 따라오기도 합니다. AI Agent 세션을 하나 더 켜놓으면 되기 때문입니다. 이렇게 리소스가 남을 때 최대한 팀 내에 기술 부채와 AI 코딩 환경에서 빠르게 업무를 처리할 수 있는 환경인지 이야이기해야합니다. 다만 이런 이야기를 함부로 하기 어렵습니다.

기존 프로세스를 선택한 다른 이유가 존재할 때가 문제입니다. 이런 건 콘텍스트를 모르는 신규 입사자가 함부로 이야기하기 어려운 부분입니다. 그래서 그냥 가볍게 옆에 있는 동료분께 스몰토크 형태로 물어봤습니다.

"기존에는 이렇게 진행하는 거 같은데 이런 식으로 진행해도 될거 같은데 뭔가 이유가 있었나요?" 
"기존에 방식도 좋은 거 같은데 통일성이 없는 거 같아서 혹시 어떤 걸로 진행하면 좋을까요? 
"제가 잘못 이해하고 있는 걸까요?

 

업무 제안은 우선 팀원들의 공감대를 먼저 얻어야합니다. 가볍고 겸손한 말투로 시작해서 정말로 필요한지 아닌지 이전에 콘텍스트를 먼저 파악합니다. 그리고 정말 니즈가 있던 일이라면 이야기를 진행해나가면서 "제가 해볼까요?" 라는 말까지 할 수 있게 됩니다. 이렇게 여론을 조작(?)해놓으면 슬랙에 업무 제안을 적을 때 빠르게 좋아요가 달리게 됩니다.   

이 방법은 팀 내 회고 미팅에서도 마찬가지입니다. 회고 자리에서 생각나는 이야기를 하게 되면 어떤 맥락에서 나온 말인지도 모르고 수많은 사람들 앞에서 모든 과정을 조리있게 이야기하기 쉽지가 않습니다. 주변에 이해해주고 호응해줄 사람이 필요합니다. 

그리고 이야기를 하다보면 나와 내가 묻던 AI가 놓치는 부분도 발견할 수 있습니다.

3. Github 을 IDE로 써보자

AI 에이전트를 사용하다보면 처음에는 하나하나 모두 리뷰를 하지만 시간이 지나고 세션을 여러 개 만들고 Worktree를 나눠 진행하다보면 어느 순간 개발 속도를 주체하지 못하게 됩니다. Worktree를 통해 병렬로 여러 도구를 돌리게 되면 IDE도 매 Worktree 프로젝트를 새로 인덱싱을 하게되고 코드 변경을 따라가느라 메모리를 불태웁니다.

그래서 최근에 팀원 중 한 분이 github을 IDE처럼 사용하는 걸 보고 따라해보고 있습니다. Github에 PR draft 형태로 올리고 AI가 만들어준 코드를 리뷰하면서 의문점인걸 적고 로컬에서 리뷰를 읽고 다시 작업하라고 합니다. 그리고 각 워크트리에서 작업한 병합된 내용을 실행해보고 테스트 해보는 형태입니다. 코드가 마음에 들지 않다면 PR을 close하고 branch부터 다시 만들며 plan을 고칩니다. 대부분은 AI Agent가 PR 안의 review 메세지를 충실해반영해줍니다.

Github 만큼 Diff를 효과적으로 보여주는 플랫폼은 흔하지 않습니다. 로컬 메모리를 아끼면서도 작업 콘텍스트를 여러 세션에서 공유할 수 있는 꽤 효과적인 방법인 것 같습니다.

4. AI 를 비서 이상으로 쓰고 싶다면 (시나리오)데이터를 만들자

여러 AI Agent를 돌리면서도 더 중요해지는게 있습니다. 그건 바로 데이터 기반 테스트 시나리오입니다. 결국 원하는 결과가 나오는지 코드 변경이 생겼을 때 다른 부분에 영향이 있는지 체크하려면 테스트 코드가 필요합니다. 

기존과 다르게 테스트 코드의 생성이 쉬워졌습니다. 코드의 변화 속도가 매우 빨라지면서 실수할 확률도 높아졌습니다. 

그래서 최근에 기획을 들으면 Before - After의 데이터 변화를 달라고 합니다. 테스트 코드에 넣을 시나리오 데이터입니다.

테스트 코드를 AI를 통해 만드는 게 매우 간편해졌지만 테스트 시나리오와 데이터는 꼭 인간의 손을 거치며 내부 알고리즘과 결과 값은 생각해야해야 합니다. 그래야보다 안전하게 AI Agent를 활용할 수 있습니다. 

마무리 

스타트업에 적응한다는 건 단순히 기술 스택을 익히는 과정은 아니었던 것 같습니다.

어떤 방식으로 일이 흘러가는지 이해하고, 그 안에서 작은 개선을 시도해보고, 그 결과를 팀과 공유하면서 조금씩 신뢰를 쌓아가는 과정에 더 가까웠습니다.

AI 덕분에 코드를 더 빠르게 만들 수 있게 되었고, 이전보다 훨씬 많은 시도를 해볼 수 있게 되었습니다.

예전 같으면 우선순위에서 밀렸을 개선 작업도, 부담스러워서 꺼내지 못했던 제안도, 이제는 훨씬 가볍게 시작해볼 수 있습니다.

하지만 동시에 더 분명해진 것도 있습니다. AI가 코드를 대신 짜준다고 해서, 사람이 해야 할 일이 줄어드는 것은 아니었습니다.

오히려 무엇을 먼저 개선할지 판단하는 일, 왜 지금 방식으로 운영되고 있는지 콘텍스트를 이해하는 일, 여러 시도 중에서 실제로 팀에 도움이 되는 방향을 고르는 일은 더 중요해졌습니다.

 

제가 생각하는 내 기술의 10%는 바로 이런 부분입니다.

AI 시대에 코딩 그 자체의 가치는 떨어졌습니다. 다만 신뢰를 쌓고, 콘텍스트를 이해하고, 문제를 먼저 발견하고, 검증 가능한 형태로 일을 정리하는 능력의 가치만 남겨졌습니다.

아직 적응하는 과정이지만, 이 방식이 쌓일수록 더 많은 시도를 할 수 있고, 그 시도들이 실제 변화로 이어진다는 걸 느끼고 있습니다.