3년 만에 다시 돌아온 스타트업, 생존형 엔지니어링을 넘어

3년 만에 다시, 스타트업

3년 전, 나는 "그래도 또 스타트업에 갈 거냐"는 질문에 망설임 없이 "예스"라고 적으며 글을 맺었다. 그리고 정말로, 그때의 다짐대로 다시 스타트업에 들어와 개발자로 일하고 있다.

그때의 나와 지금의 나는 무엇이 달라졌을까. 3년 전 써 둔 글을 다시 펼쳐 읽으며, 그동안 겪은 이야기와 조금은 달라진 마음가짐을 정리해보려 한다.

정신없이 시작된 인수인계

인원이 적은 스타트업에서 새로운 사람을 뽑는 경우는 대체로 둘 중 하나다. 기존 인력이 빠져나가 그 빈자리를 메워야 하거나, 사업이 커지면서 손이 더 필요해지거나. 나는 전자였다.

전임 개발자가 건강 문제로 급하게 자리를 비우게 되면서 채용이 진행됐고, 마침 일자리를 찾고 있던 나에게 오퍼가 왔다. 양쪽 모두 급했던 만큼 절차도 빨랐다. 오퍼를 수락하고 3~4일 만에 곧바로 출근했다.

전임자는 인수인계를 위해 본인의 업무를 최대한 문서로 정리해 두었다. 다만 그 문서는 '업무 기록'이었지, '신규 입사자를 위한 온보딩 가이드'는 아니었다. 그사이에도 마감이 박힌 정부 프로젝트는 굴러가야 했고, 이미 운영 중인 서비스의 이슈 대응도 멈출 수 없었다. 모든 걸 한꺼번에 붙잡을 수는 없으니, 무엇에 먼저 손을 댈지부터 정해야 했다.

사실 새 조직에 들어간다는 건, 단순히 새로운 코드를 익히는 일만은 아니었다. 이미 한 번 조직에서 밀려나 본 적이 있는 사람에게는 '내가 이곳에서 필요한 사람인지'를 다시 증명해야 하는 일에 가까웠다. 그 걱정이 마냥 나쁘지만은 않았다. 덕분에 나는 첫날부터 손을 놓고 있을 수 없었고, 무엇부터 붙잡아야 할지 빠르게 살펴볼 수 있었다.

한마리의 토끼를 잡아라

엔지니어링 관련 책을 읽다 보면 자주 등장하는 단어가 있다. 바로 '트레이드오프(trade-off)'다. 하나를 얻으려면 다른 하나를 내려놓아야 한다는 뜻이다. 빠른 개발 속도를 원한다면, 그만큼 높은 품질과 안정성은 어느 정도 양보해야 한다.

내 앞에 놓인 일은 한두개가 아니었다.

• 마감이 정해진 정부 프로젝트
• 운영 중인 서비스의 CS 대응
• 온보딩을 통한 사업·도메인 이해
• 기존에 구축된 인프라 아키텍처 분석

당장 급해 보이는 일은 많았지만, 이 모두를 동시에 끌고 갈 수는 없었다. 그래서 아이젠하워 매트릭스를 빌려 '급한 일'과 '중요한 일'의 축으로 해야 할 일들을 정리해봤다.

가장 먼저 잡아야 할 토끼는 분명했다. 전임자가 떠난 뒤에도 운영 중인 시스템의 이슈는 계속 터질 것이고, 그걸 감당하려면 시스템과 도메인을 이해하는 일이 무엇보다 급했다. 그래서 전임자가 자리를 비우기 전에, 사용 중인 AWS 서비스와 접근 방법을 프로젝트별로 정리해 직접 설명해달라고 부탁드렸다.

반복되는 루틴 업무는 페어로 함께 진행하며 조금씩 넘겨받았고, 덕분에 운영 업무는 빠르게 손에 익힐 수 있었다. 마지막으로 정부 프로젝트는 외주 인력에게 맡기는 방향으로 설득한 뒤, 그들이 처리해야 할 업무 목록을 빠르게 정리해 넘기며 온전히 위임했다.

그렇게, 도무지 맞물리지 않을 것 같던 톱니바퀴가 천천히 돌아가기 시작했다.

 

첫 PM으로써의 역할, 미숙해도 괜찮아

정부 프로젝트를 진행하다 보니, 백엔드가 관여해야 할 부분이 생각보다 많았다. 네트워크와 보안, 데이터베이스, 서버 스펙처럼 먼저 협의해 결정해야 할 사항들이 아직 정해지지 않은 채 남아 있었기 때문이다. 그러다 보니 자연스럽게 내가 PM 역할까지 맡게 되었다.

PM은 처음이라 서툰 부분도 있었다. 하지만 직접 워커로 부딪혀 본 경험이 의외의 무기가 됐다. 일이 어디서 막히고 무엇 때문에 늘어지는지를 몸으로 알고 있었던 덕에, 대부분의 협의와 소통은 생각보다 어렵지 않게 풀렸다.

다만 솔직히, PM 역할 자체는 생각보다 까다로웠다. 협의나 소통이 어려웠다기보다, 코드를 깊게 파고들고 싶을 때마다 사람과 일정, 요구사항을 다시 정리하느라 손을 멈춰야 했기 때문이다. 코드만 붙잡고 있고 싶은 마음이 굴뚝같을 때가 많았다. 그래도 그 조율을 누군가 하지 않으면 결국 개발도 앞으로 나아가지 못한다는 걸 알았기에, 손을 놓을 수는 없었다.

내가 PM으로서 가장 먼저 한 일은 세 가지였다.

첫째, 업무를 눈에 보이게 만들었다. 진행 상황을 한눈에 볼 수 있는 대시보드를 빠르게 도입하고, 그동안 메신저로 흩어져 오가던 업무 흐름을 하나의 프로세스로 정리했다. 소통 비용과 미스커뮤니케이션이 눈에 띄게 줄었다.

둘째, 병목을 걷어냈다. 대표적인 게 API 명세였다. 스프레드시트에 일일이 손으로 정리하던 작업을, 팀원의 피드백을 받아 Swagger로 대체했다. 반복되는 일은 자동화로 넘기니, 같은 시간에 훨씬 많은 일이 돌아갔다.

셋째, 요구사항과 일정을 명확히 했다. 무엇을 언제까지 할지 구체적으로 정리한 뒤, 그 일정에 맞춰 외부 업체와 내부 인력이 협의할 사항들을 빠르게 확정 지었다. 덕분에 데드라인에 맞춰 기능 구현과 테스트까지 마칠 수 있었다.

기술 부채와 신뢰의 상관 관계

정부 프로젝트가 후반부에 접어들 무렵, 또 하나의 큰 숙제가 기다리고 있었다. 클라우드에서 운영하던 인프라를 온프레미스 환경으로 옮기는 일이었다. 다행히 네트워킹을 통해 알게 된 개발자분과 함께 계약하여 지방을 오가며 작업했고, 순탄하진 않았지만 AWS에 의존하던 서비스와 기능을 하나씩 분석해 점진적으로 걷어낼 수 있었다.

문제는, 앞으로 한 발 내딛는 동안 뒤에서 발목을 잡는 것들이 있었다는 점이다. 기존에 개발해 둔 시스템들이 하나둘 말썽을 부리기 시작했다. 원인은 스타트업의 고질병, 기술 부채였다.

'일단 동작하게만' 만들어 둔 기능들은, 사용자가 늘고 유즈케이스가 많아질수록 숨어 있던 문제를 수면 위로 드러냈다. 그리고 그 문제들은 고스란히 고객의 불편으로 이어졌다. 정부 프로젝트에 매달리는 동안 이런 신호들이 방치됐고, 제품에 대한 신뢰도 조금씩 깎여 나가고 있었다.

처음 이 레거시를 마주했을 때는 솔직히 막막했다. 하지만 코드를 들여다볼수록, 만든 사람을 탓하는 마음보다 전임자 분이 먼저 떠올랐다. 이걸 대체 어떻게 혼자서 다 감당했을까. 주니어 백엔드 개발자 혼자서 3년간 이만한 규모를 끌고 오느라 얼마나 막막하고 고생스러웠을지, 그제야 눈에 들어왔다.

백오피스 없이 수작업으로 버티던 운영 업무도 한계에 다다랐다. 신규 프로젝트에 인력이 쏠리자 대응이 늦어졌고, 그 여파는 제품 설치 일정에까지 번졌다.

결국 필요한 건 단순히 '시간을 더 갈아 넣는' 대응이 아니었다. 이 문제들이 왜 발생하는지 그 뿌리를 먼저 짚고, 가장 빠르게 끊어낼 해법이 필요했다.

AI와 함께 부채 갚기

이전 회사에서 AI에 의존해 업무를 진행하다, 팀장님에게 코드 품질에 대한 피드백을 받은 적이 있다. 그때는 '왜 이런 결과가 나왔을까'를 한참 곱씹었다.

이유는 명확했다. 당시 나는 프론트엔드와 타입스크립트 경험이 깊지 않았다. 그러다 보니 무엇이 안티패턴이고 무엇이 좋은 구조인지 판단할 기준이 없는 채로, 일단 '돌아가게 만드는 것'에만 집중했다. 게다가 참고할 수 있는 기존 코드마저 같은 문제를 안고 있었다. 결국 AI가 그 좋지 않은 코드를 컨텍스트로 참조하면서, 비슷하게 좋지 않은 결과물을 다시 만들어내는 악순환이 반복된 것이다.

AI는 좋은 컨텍스트를 주면 좋은 답을, 나쁜 컨텍스트를 주면 나쁜 답을 돌려준다.

이번 백오피스를 개발할 때는 같은 실수를 반복할 수 없었다. 그래서 역할을 나눴다. 클로드와 ChatGPT에게는 유지보수에 유리한 프론트 구조를 계속 리서치하고 정리하도록 맡겼다. 그동안 나는 실제로 이 서비스를 쓰는 사람들, 즉 CS 대응과 설치를 담당하는 직원분들을 직접 인터뷰하며 지금 필요한 기능과 그들이 겪는 문제를 파악했다.

 

인터뷰에서 드러난 핵심 요구사항은 두 가지였다.

• 담당자 한 명을 거치지 않고도, 현장에서 직접 기기 세팅을 끝낼 수 있는 환경
• 문제가 생겼을 때 실시간으로 상황을 파악하고 대응할 수 있는 시스템

기존에 만들어 둔 원격 관리 시스템은 모니터링과 간단한 대응까지는 가능했지만, 기기 설치 프로세스 자체를 체계적으로 효율화하진 못했다. 그래서 검증된 백엔드는 그대로 살리되 낡은 부분만 걷어내고, 최소한의 리소스로 새 솔루션을 올리기로 했다. 클로드 디자인으로 새로 구축한 디자인 시스템과 대중적인 프론트엔드 컨벤션에 맞춰, 빠르게 기능을 구현해 나갔다.

분산된 인프라가 치르는 비용

한때 MSA가 유행하면서, 많은 기업이 모놀리식 시스템을 잘게 쪼개기 시작했다. 분산 시스템의 매력은 분명하다.

• 도메인끼리 영향을 주지 않고, 독립적으로 또 빠르게 배포할 수 있다.
• 장애가 나도 그 영향 범위를 한 도메인 안에 가둘 수 있다.

하지만 그 반대편의 비용도 만만치 않다. 데이터가 흩어지고 트랜잭션이 쪼개지면서 복잡도가 올라가고, 안정적으로 운영하려면 추가적인 인프라와 설계가 따라붙는다. 결국 유지보수 비용과 운영 비용이 함께 불어난다.

우리 회사가 안고 있던 부채도 바로 여기에 있었다. 기존 레거시와 새로 개발한 시스템이 전부 분산된 채 돌아가고 있었고, 데이터 동기화마저 서버가 아니라 클라이언트 중심으로 이뤄지다 보니 데이터 손실로 인한 CS가 적지 않게 발생했다. 기기 하나를 등록하려면 두 개의 DB에 각각 데이터를 넣고, 애플리케이션 레벨에서 조인까지 해야 했다.

이대로 두면 계속 발목이 잡힐 게 눈에 보였다. 그래서 데이터베이스를 점진적으로 통합하고, 모놀리식으로 운영할 수 있도록 시스템을 다시 설계하기로 했다.

다행히 기기를 제어·관리하는 시스템의 데이터는 내부 인원만 사용·관리하는 데이터베이스라, 마이그레이션 자체는 크게 어렵지 않았다. 진짜 까다로운 건 중복된 테이블을 새로 모델링하는 일이었다. 결국 주 데이터베이스의 모델링을 기준으로 삼아, 중복된 컬럼과 데이터는 걷어내고 새로 필요한 컬럼과 테이블만 추가하는 방향으로 정리했다.

마이그레이션은 이렇게 진행했다. 먼저 AI에게 전체 스키마와 새로 모델링한 테이블 구조를 참고해 마이그레이션 SQL을 만들어 달라고 요청한 뒤, 그 파일을 밀어넣고 애플리케이션 서버가 바라보는 엔드포인트를 새 DB로 바꿨다. 배포가 진행되는 동안 정합성이 깨진 데이터는 별도 검증 쿼리로 하나씩 수작업으로 맞췄다. 그렇게 두 개의 DB는 하나로 합쳐졌고, 기기 등록과 관리를 한곳에서 처리할 수 있는 백오피스를 완성할 수 있었다.

 

생존형 엔지니어링을 넘어, 엔지니어링의 개인화

나무만 보지는 않게 되었다

이전 스타트업에서 처음 의사결정을 내려야 했을 때는, 사수의 피드백도 없고 경험도 많지 않은 주니어 시절이었다. 그래서 내가 제대로 설계한 게 맞는지, 이 방향을 제시하는 것이 정말 도움이 될지 확신이 서지 않았다. 늘 불안했고, 그 갈증을 채우려 무리해서라도 스터디와 업무를 병행하곤 했다.

그렇게 여러 번 실패도 겪고, 내가 입사하기 전 다른 엔지니어들이 내렸던 선택이 지금에 어떤 영향과 문제로 이어지는지를 직접 마주하고 나니, '이 선택을 하면 이런 결과로 이어지겠구나'가 점점 보이기 시작했다. 한때 나무가 아니라 숲을 보는 엔지니어가 되는 게 꿈이었던 나는, 아직 숲 전체를 본다고 확신하진 못한다. 다만 적어도 이제는 나무만 바라보지 않는다는 것은 느낄 수 있었다.

다만 나무만 보지 않게 되었다는 건, 생각보다 낭만적인 변화는 아니었다. 더 많은 것이 보인다는 건 더 많은 것을 신경 써야 한다는 뜻이기도 했으니까. 운영, 고객, 일정, 기술 부채, 그리고 이 코드를 언젠가 이어받을 다음 사람까지. 솔직히 짊어질 게 늘어 버거울 때도 있다. 그래도 이제는 그 무게를, 피하기보다 감당하는 자리로 조금씩 옮겨가고 있다는 생각이 든다.

AI가 바꾼 것, 그리고 그 이면

AI의 발전으로 여러 직무의 역할 경계가 희미해지고, 전문 지식이라는 진입 장벽도 많이 낮아졌다. 덕분에 기존에 안고 있던 여러 문제가 풀리기도 했지만, 그에 따른 부작용도 함께 따라왔다.

• 인지 부채
• 할루시네이션
• 편향된 관점
• 생각의 깊이가 얕아지는 것

AI로 모든 업무와 작업이 빨라졌다기보다는, 개인이 더 많은 것을 할 수 있게 되었다는 쪽에 더 가깝다는 생각이 든다. 더 빠르게 만드는 것은 결국 인간의 선택과 의지에 달려 있다고 생각한다. 맞는 방향으로 이끈다면 더 빨라질 것이고, 틀린 방향으로 간다면 오히려 전보다 느려질 수도 있다.

사실 이건 남의 이야기가 아니다. 이번 백오피스와 마이그레이션 작업에서도 큰 방향과 청사진은 내가 잡았지만, 세부 구현의 상당 부분은 AI가 메웠다. 덕분에 빨리 구현할 수 있었지만, 그만큼 '내가 이걸 전부 설명할 수 있나' 싶은 인지 부채도 남았다. 그래도 이제는 그걸 굳이 숨기기보다, AI 시대의 엔지니어가 새로 안고 가야 할 몫으로 받아들이고 해결 방법을 고민하고 있다.

엔지니어링이 개인화되는 시대

지금 우리 회사도 비개발자분이 회사에 필요한 CRM 시스템을 직접 개발하고 구축하고 있다. 설계나 운영에 나는 관여하지 않는다. 그분들이 선택하고, 결정하고, 실행한다. 나는 그렇게 만들어진 시스템에 맞춰 업무를 진행하기도 하고, 필요에 따라 API를 개발하거나 좀 더 쉽게 풀 수 있는 방법을 제시하는 정도로만 거든다.

TDD와 익스트림 프로그래밍(XP)의 창시자로 잘 알려진 소프트웨어 엔지니어 켄트 벡(Kent Beck)은, ChatGPT를 처음 써본 뒤 이런 말을 남겼다.

내 기술의 90% 가치는 0달러가 되었고, 남은 10%의 레버리지는 1000배가 되었다. 나는 다시 조정해야 한다.

처음에는 다소 과장된 표현처럼 들렸지만, 시간이 지날수록 그 말의 의미를 조금씩 이해하게 되는 것 같다. 단순히 많이 아는 것, 빠르게 구현하는 것, 익숙한 도구를 잘 다루는 것만으로는 더 이상 충분하지 않을 것이다.

오히려 중요한 것은 무엇을 만들지 결정하는 힘, 문제를 정확히 바라보는 힘, 복잡도를 감당할 수 있는 수준으로 유지하는 힘, 그리고 결과물이 정말 옳은 방향으로 가고 있는지 판단하는 힘이다. 사라진 것은 기술의 전부가 아니라, 기술을 바라보던 예전의 기준이었는지도 모른다.

정말 높은 수준의 지식을 요구하는 전문적인 엔지니어링의 영역은 소수에게 남을 것이다. 그 외의 많은 일은, 전문성과 엔지니어에 의존하지 않고 개인과 조직, 회사가 스스로 필요한 것을 만들어 쓰게 될 것이다. 내가 원하는 것을 손쉽게 구현하는 편리함을 한번 맛본 사람들은, 다시 이전으로 돌아가지 않을 테니까.

예전의 나는 좋은 설계와 깊은 기술이 더 큰 가치를 만든다고 믿었고, 능력 있고 존경받는 엔지니어가 되고 싶었다. 지금도 그 마음이 완전히 사라진 건 아니다. 다만 시대가 바뀌고 일하는 방식이 바뀌는 만큼, 나도 '엔지니어'라는 이름 안에만 머물기보다 문제를 푸는 사람 쪽으로 무게를 조금씩 옮기고 있는지도 모르겠다.

그래서 앞으로 내가 어떤 엔지니어가 될 것이라고 지금 당장 확실히 말하긴 어렵다. 다만 한동안은 CS나 아키텍처 설계 책을 공부하기보다는, 비즈니스와 사람을 더 이해하는 데 시간을 쓸 것 같다. 그렇다고 엔지니어링을 완전히 놓진 않겠지만, 예전처럼 각 잡고 하기보다는 필요와 상황에 따라 하게 되지 않을까. 어쩌면 지금의 변화는 더 뛰어난 엔지니어가 되기 위한 다음 단계라기보다, 엔지니어라는 이름 바깥에서도 나를 증명해보려는 새로운 스텝에 가까운지도 모른다.

일단 회사 업무적으로 확실한 건, 옵저버빌리티를 더 확보하고 그동안 쌓인 레거시 부채를 어느 정도 정리하고 나면 앞으로 비즈니스는 더 쉽고 빠르게 실행할 수 있을 것이고, 의사결정의 기준도 전보다 한층 명확해질 것이다. 제품의 품질 또한 높아질 것이라 생각한다. 이건 확실하게 말할 수 있다.

부록

https://codediary21.tistory.com/133

스타트업을 다니면서 느꼈던 현실과 생각들