어느 날 개발자가 나 혼자 남았다

저희 서비스는 MAU 약 65만 명 정도가 되는, 작지 않은 규모의 서비스입니다. 연말, 연초에는 성수기여서 MAU가 100만이 훌쩍 넘어버리기도 합니다. 그리고 저희 팀은 25년 초에 약 10명 정도의 백엔드 + 프론트엔드 개발자들이 한 팀으로 일하도록 개편되었습니다. 25년 한 해 동안 많은 일이 있었는데, 오늘은 이 과정에 대해 이야기해보려 합니다.

갑작스러운 변화

AI의 발전과 상장 준비 등의 이유로 권고 사직이 시작되었습니다. 이때 알게 된 회사의 악순환 사이클이 있었습니다. 권고사직 → 주변 팀원들의 의욕 저하 → 이직 → 인력 부족 → 채용 → 다시 권고사직. 결국 이 사이클 속에서 개발팀에는 저 혼자만 남게 되었습니다.

혼자 남았을 때는 생각보다 막막했습니다. 저는 프론트엔드 개발자이지만 당장 백엔드 쪽 업무도 필요하면 해야했습니다. 이 글에서는 혼자서 서비스를 운영하면서 어떤 생각으로, 어떻게 일했는지 공유해보려고 합니다. 사실 전부 어찌 보면 당연한 것들이지만, 위기 상황에서 이런 '당연한 것들'이 얼마나 중요한지 다시 한번 깨달았습니다.

1. 자동화할 수 있는 것들을 자동화하자

바쁠수록 돌아가자

혼자 남으니 당장 쳐내야 할 일들이 산더미처럼 쌓였습니다. 하지만 여기서 중요한 선택을 해야 했습니다. 당장 눈앞의 일을 급하게 처리할 것인가, 아니면 조금 시간이 걸리더라도 자동화할 수 있는 것들을 자동화할 것인가.

저는 후자를 선택했습니다. 바쁠수록 기본에 충실해야 한다고 생각했기 때문입니다.

배포 자동화와 QA 요청 자동화

상장 준비를 이유로 Github Actions 비용절감도 진행됐습니다. 이로 인해 개발환경 CI/CD가 끊어져 있던 상황이었습니다. 이는 QA 담당자와 개발자 모두의 업무 효율을 떨어뜨리고 있다고 느꼈습니다.

경영진을 설득하여 CI/CD를 재연결하는 승인을 받았고, 다음과 같이 구성했습니다.

  • main 브랜치에 머지되면 개발 환경에 자동 배포
  • 배포 완료 시 QA 담당자에게 자동 노티
  • Github API로 PR 정보를 가져와 브랜치명에서 이슈 Key를 추출하고, 해당 Jira 티켓에 QA 담당자를 자동으로 태그
    • # GitHub Actions workflow 일부
    PR_DATA=$(gh api -X GET "repos/${{ github.repository }}/commits/$COMMIT_SHA/pulls" --jq '.[0]' 2>/dev/null || echo "")
    

    BRANCH_NAME=$(echo "$PR_DATA" | jq -r '.head.ref')
    echo "Found PR branch: $BRANCH_NAME"
    

    # 브랜치명에서 이슈 키 추출 (예: feat/fc-1234 → FC-1234)
    ISSUE_KEY=$(echo "$BRANCH_NAME" | grep -oiE 'fc-[0-9]+' | tr '[:lower:]' '[:upper:]' || true)

    기존에도 어느정도의 QA 자동화는 되어있었지만, CI/CD를 연결하고 브랜치명에서 이슈 Key를 추출하는 방식을 추가하니 PR 머지만 누르고 나면 QA 과정까지 한번에 연결되었습니다. 이 작업으로 배포 시간이 단축되었고, QA 담당자와의 커뮤니케이션도 훨씬 원활해졌습니다.

    수동으로 해주던 일들을 기능으로

    돌아보니 관성에 따라 요청이 들어오면 생각 없이 해주던 일들이 많았습니다. 이런 것들을 하나씩 기능으로 만들어나갔습니다.

    백오피스 UX 개선

    백오피스의 면세/과세 설정이 복잡해서 오설정이 자주 발생했고, 그때마다 제가 직접 쿼리를 날려서 수정해줘야 했습니다. 백오피스 UX를 직관적으로 개선하여 오설정을 최소화했습니다.

    메인페이지 Redirect 설정 자동화

    하루의 첫 접속 시 특정 페이지로 redirect하는 기능을 개발자가 수동으로 설정하고 있었습니다. 백오피스에서 직접 redirect URL을 등록할 수 있도록 Next.js의 middleware를 활용해 기능을 구현했습니다.

    컴포저 확대 적용

    "배너 내용 수정 요청드립니다. 가격이 3천원 올라갔어요.." 같은 요청들이 하루에도 몇 번씩 들어왔습니다. 신규 프로젝트에 상세 페이지 편집 기능을 최대한 활용하여 비개발자도 백오피스에서 직접 페이지를 수정할 수 있도록 했습니다.

    이러한 개선들로 반복적인 단순 작업 요청이 대폭 감소했고, 사업부의 작업 자율성도 향상되었습니다.

    AI를 적극 활용하기

    혼자서 모든 것을 다 할 수는 없었습니다. AI를 생산성 도구로 적극 활용했습니다. 다음을 저를 많이 도와줬던 AI 기능들입니다.

    Slack Jira App의 "Create issue from.."

    저희는 Jira로 이슈 관리를 하다보니, 웬만한 업무는 지라 티켓으로 만듭니다. Slack Jira App에서는 스레드에서 이슈를 바로 만들 수 있는 기능을 제공하는데요, AI가 스레드의 내용을 읽고 알맞게 이슈를 생성해줍니다. 클릭 한번으로 이슈를 만들 수 있게 되니 생산성이 향상되었습니다.

    Cursor의 "Generate commit message"

    커밋 메시지를 작성하는 일은 생각보다 꽤 귀찮은 일입니다. 게다가 바쁠때는 그 내용도 자세히 작성하지 못하게 되는 것 같습니다. 프로젝트 루트에 .cursorrules를 잘 활용하면 커서가 생성해주는 커밋메시지에 컨벤션도 적용할 수 있었습니다.

    Cursor Plan Mode로 복잡한 작업 계획

    Claude Code와 Cursor를 함께 사용하는데, 이러한 비용은 나름대로 회사에서 다 지원해주는 상황이었습니다. 조금 복잡한 작업을 할때에는, 기존 Agent 모드 말고 Plan Mode를 사용했는데 이게 저의 생산성을 크게 높여주었습니다. Agent 모드는 저에게 계획을 공유하지 않고 무작정 수정해버리다보니 더 많은 티키타카가 필요했지만, Plan Mode는 함께 계획을 작성하고 작업하니 더 예상할 수 있는 결과물이 나왔습니다.

    Claude Sub Agent & Figma MCP로 디자인 시스템 프롬프팅

    저희 프로젝트에는 디자인 시스템이 존재하는데, 이를 학습시킨 Sub Agent가 존재합니다. 사실 이 부분은 margin이나 소소한 면에서 아직 완벽하진 않지만, 해당 Sub Agent를 사용하고 Figma MCP를 곁들이면 초안으로 꽤 괜찮은 마크업을 생성해주었습니다. 추후에는 여기에 더해서 저희 디자인 시스템의 MCP를 만들어볼 생각도 해보고 있습니다.

    Atlassian MCP & Github MCP를 사용한 이슈 처리 워크플로우

    여러 기능들 중 가장 편하게 사용하는 기능입니다. 사실 현업에서 일을 하면 항상 꼭 대단한 업무만 있는 것은 아니라고 생각합니다. 간단한 배너 교체라던지, 사소한 버그 픽스라던지 간단하게 AI가 처음부터 끝까지 처리할 수 있는 수준의 업무도 많이 있었습니다. 이런 업무는 아예 프롬프트를 단계별로 미리 작성해서 프로젝트 루트의 prompts 폴더에 넣어두고, 필요할때마다 가져다 쓰고 있습니다. 프롬프트에서는 Atlassian MCP를 연결하여 지라 이슈 정보를 받아오고, 해당 지라 이슈 Key로 브랜치를 만들며, 작업 이후에는 Github MCP를 사용하여 PR까지 작성합니다. 저는 해당 작업이 진행될 동안 다른 작업을 하다가, 완료된 작업을 검토만 해주면 되었습니다.

    2. 코드의 품질을 유지하자

    PR 리뷰를 받을 수 없는 상황에서 일은 일대로 많아지니, 자꾸만 코드의 퀄리티가 떨어지는 것이 느껴졌습니다.

    Gemini 코드 리뷰 도입

    혼자서는 코드 리뷰를 받을 수 없었지만, AI는 가능했습니다. 다른 팀에서 사용하던 Gemini 코드 리뷰 시스템을 연결했습니다. PR을 생성하면 자동으로 코드 리뷰 코멘트가 달리도록 설정했습니다.

    완벽하지는 않았지만, 기본적인 코드 품질 체크를 자동화할 수 있었고 놓칠 수 있는 버그나 개선점을 발견하는 데 도움이 되었습니다.

    또한 이 Gemini의 코드 리뷰를 다시 한번 커서가 검토해서 보완하는 커밋을 올리는 워크플로우를 만들고, 각각 다른 모델의 AI가 서로 논의해서 PR을 다듬는 광경도 목격할 수 있었습니다.

    E2E 테스트 도입

    전사 장애를 한 번 경험한 적이 있었습니다. 혼자서 이런 상황을 대비하기 위해서는 안전망이 필요했습니다. Playwright를 활용한 E2E 테스트를 구축하기로 했습니다.

    주요 사용자 플로우에 대한 자동화 테스트를 작성하고, CI/CD 파이프라인에 통합하여 main 머지 전에 자동으로 실행되도록 설정했습니다.

    이 안전망 덕분에 배포 전 주요 기능의 동작 여부를 자동으로 검증할 수 있었고, 버그를 조기에 발견할 수 있었습니다. 무엇보다 혼자서도 안심하고 배포할 수 있다는 심리적 안정감이 컸습니다. 이를 토대로 여러 가지 리팩토링도 더 공격적으로 시도해볼 수 있었습니다.

    메이저 업그레이드와 성능 최적화

    E2E 테스트가 있으니 자신감이 생겼습니다. Next.js 13에서 16으로 메이저 버전 업그레이드를 진행했습니다. 의존성 패키지들도 함께 최신 버전으로 업데이트하고, 주요 Breaking Changes에 대응했습니다. codemod를 최대한 활용하여 작업을 진행했습니다.

    또한 MAU 65만 서비스임에도 성능 최적화에 소홀했던 부분을 개선했습니다. 특히 메인 페이지의 CLS(Cumulative Layout Shift) 문제가 심각했습니다. 이미지 로딩으로 인한 레이아웃 밀림 현상을 개선하고, Skeleton UI를 적용하여 로딩 상태를 명확히 표시했습니다.

    혼자 남으니 오히려 서비스 전체를 책임진다는 마인드가 심화되었습니다. 동료가 없으니 직업적인 성취가 부족하다고 느꼈고, 이런 부분에서 그것을 충족하려 했던 것 같습니다. 개발자로서 퀄리티를 챙길 줄 아는 능력을 기르고 싶었습니다.

    3. 혼자 살아남기 위한 마인드셋

    우선순위를 명확히 받자

    한 번에 4~5명의 이해관계자와 동시에 소통해야 하는 상황에서 모든 요청이 급해 보였습니다. 하지만 실제로 모든 것이 급할 수는 없습니다.

    각 요청의 우선순위를 명확히 확인하고, 비즈니스 임팩트와 긴급도를 기준으로 우선순위를 정렬했습니다. 다행히 회사에 우선순위 가이드라인이 있어서 이를 기준으로 삼을 수 있었습니다.

    "원래"라는 건 없다

    프론트엔드 개발자인 제가 백엔드 업무도 하게 되었습니다. 어느 날 쿼리를 날리고 있는 저를 발견했습니다.

    이런 모습이 AI로 도배된 세상에서 우리의 미래가 아닐까 생각했습니다. 역할의 경계를 넘어서 필요한 일을 하는 유연성이 필요합니다. "원래" 제 일이 아니라는 생각보다는, 비즈니스를 위해 필요한 일을 할 수 있는 능력을 기르는 것이 중요하다고 생각하게 되었습니다.

    마치며

    혼자 남았지만, 오히려 더 많은 것을 배웠습니다. 자동화의 중요성, 코드 품질 유지의 필요성, 그리고 '원래'라는 고정관념을 깨는 유연성을 배웠습니다.

    우리는 개발자입니다. 문제를 정의하고 해결하는 사람들입니다. 혼자 남았다고 해서 달라질 것은 없습니다. 이 과정에서 과정을 효율화하고, AI를 더 적극적으로 활용하는 경험을 하게 되어 한층 성장했다고 느껴졌습니다.

    현재는 백엔드 개발자 2명이 합류했고, 프론트엔드 주니어 개발자도 1명 채용중입니다. 채용 과정도 주도적으로 이끌어보는 경험을 하고 있는데요, 직접 프론트엔드 과제를 만들어보기도 하고, 면접 과정까지 주도적으로 진행하고 있습니다. 이에 대한 이야기도 나중에 남길 수 있다면 남겨보겠습니다. 긴 글 읽어주셔서 감사합니다. 새해 복 많이 받으세요.