AI가 나를 더 빠르게 만든 건 아니다. AI는 더 많이 배우도록 용기를 주었다.

발행: 1일 전 (2025년 12월 28일 오전 05:27 GMT+9)

16 min read

원문: Dev.to

Source: Dev.to

위의 링크에 있는 글의 본문을 제공해 주시면, 해당 내용을 한국어로 번역해 드리겠습니다.

지난 몇 달 동안

우리의 일반적인 기능 작업과 함께, 저는:

CI 테스트 시간을 70 % 단축
API 요청을 30 % 감소
몇 달 동안 “언젠가” 영역에 머물렀던 기능들을 출시

이것은 제가 갑자기 더 나은 개발자가 되었기 때문이 아니라, AI가 제가 이전에 감히 건드리지 못했던 시스템의 부분들을 탐색하고 만져볼 수 있게 해 주었기 때문입니다.

Established Codebases의 현실

제가 합류했을 때, 기반은 이미 마련되어 있었습니다. 똑똑하고 경험 많은 동료들이 아키텍처 결정을 내리고, 기술 스택을 선택했으며, 우리 모두가 따르는 패턴을 정립했습니다.

상태 관리, 라우팅, 데이터 페칭, 인증 흐름 – 모두 설정됨
CI/CD 파이프라인이 구성됨
테스트 인프라가 구축됨

이것은 완벽하게 설계된 깔끔한 코드베이스가 아니었습니다. 어느 정도 기간 동안 운영된 대규모 시스템이라면 기술 부채, 특이한 결정, 때때로 눈살을 찌푸리게 하는 구현이 존재하기 마련이죠. 우리는 최근에 촉박한 마감 기한 속에서 대규모 시스템 전면 개편을 진행했습니다. 일부는 신중하게 이루어졌고, 다른 일부는 급하게 처리되었습니다. 이것이 바로 규모 있게 소프트웨어를 배포하는 현실입니다.

하지만 그게 흥미로운 부분은 아닙니다.

진짜 문제는: 성숙한 프로젝트에 합류하면 큰 결정을 내릴 수 없다는 점입니다. 여러분은 과정이 아닌 결과를 물려받게 됩니다. 관례를 따르지만, 대안을 탐색할 기회는 거의 없습니다.

저는 상태 관리 설정 안에서 작업할 수 있었지만, 왜 그것이 선택됐는지 혹은 어떤 트레이드오프가 있었는지는 평가하지 않았습니다.
CI 파이프라인은 존재했고 대부분 잘 동작했습니다. 이를 건드리는 것은 위험하고 불필요하게 느껴졌습니다.

여기에는 암묵적인 규칙이 있습니다. 대부분의 대기업 개발자라면 익숙할 “고장 나지 않으면 고치지 마라” 라는 규칙이죠. 수년간 프로젝트를 떠난 시니어 개발자들이 중요한 컨텍스트를 함께 가져가면서, 우리 나머지는 점점 더 기반을 건드리는 것을 주저하게 되었습니다. 완전히 이해하지 못한 무언가를 깨뜨릴 위험보다, 특이점을 우회하는 것이 더 낫다고 생각하게 된 것이죠.

게다가 직접 고객에게 보이지 않는 일들은 거의 우선순위가 높지 않았습니다. 제품팀은 눈에 보이는 기능을 합리적으로 우선순위에 두었습니다. 개발자 경험 개선? 인프라 작업? 결국엔 이루어지겠지만, 언제나 더 급한 일이 있었습니다.

이것이 성숙한 코드베이스의 숨은 비용 입니다. 여러분은 시스템 내에서 효율적으로 작업하게 되지만, 실제로 어떻게 동작하는지는 배우지 못하게 됩니다. 기반이 손대기 어려운 존재처럼 느껴지기 시작합니다.

AI 도입: 호기심 비용 낮추기

나는 AI 코딩 도구에 처음이 아니었다. 2023년 초에 한 번 사용해봤고 정말 기대했지만, 현실은 기대에 못 미쳤다. 컨텍스트가 뒤섞이고, 제안이 미묘하게 실패했으며, AI가 만든 코드를 고치는 데 직접 코드를 짜는 것보다 더 많은 시간을 소비했다. 과대광고는 금세 사라졌다.

그런데 2025년 봄, Claude Code를 사용해보았다. 이번엔 뭔가 진짜로 달라졌다.

내가 깨달은 것은 AI가 주된 목적이 코드를 더 빨리 짜는 것이 아니라 탐색 비용을 낮추는 것이라는 점이다.

AI 덕분에 다음을 할 수 있었다:

익숙하지 않은 코드베이스의 부분을 탐색
기본적이거나 반복적인 질문을 마찰 없이 제시
아이디어를 빠르게 시도하고, 실제 적용 전에 검증

두세 번의 스프린트가 걸릴 것처럼 추정하던 작업들이 며칠 안에 가능해졌으며, 절대 타협 없이 진행할 수 있었다. 코드는 여전히 리뷰를 거쳐 우리 기준을 만족했지만, 문제를 파악하는 마찰이 크게 줄어들었다.

더 중요한 것은, 그 속도가 여유를 만들었다는 점이다—배달 위험 없이 탐색하고, 실험하고, 배우는 공간이 생긴 것이다. 그리고 이것이 내 업무 방식을 바꾸었다.

From Shipping Features to Learning the System

AI가 만든 여유 공간 덕분에, 나는 항상 *“시간이 있을 때 하면 좋은 것”*이라는 정신적 카테고리에 머물렀던 영역들을 탐색하기 시작했다. 실제로는 시간이 절대 없었다. 그런데 어느 순간, 시간이 생겼다.

몇 가지 예시들은 모두 같은 패턴을 따랐다: 위협적이거나 탐구가 부족한 무언가를 식별하고, 안전하게 실험하고, 결과를 검증하며, 그 과정에서 배우는 것.

Frontend caching

API 호출 패턴을 분석하고 캐싱 전략을 구현해 백엔드 요청을 약 30 % 감소시켰다. 이는 티켓 발매와 같은 트래픽이 많은 날에 백엔드 부하를 줄여 시스템을 더 견고하게 만들고, 인프라 비용도 낮추었다. AI가 없었을 때는 위험하게 느껴졌고, 알 수 없는 변수와 실패 가능성이 너무 많았다. AI 덕분에 시스템을 논리적으로 파악하고, 가정을 빠르게 테스트하며, 작동할 때까지 반복할 수 있었다.

Performance optimizations

무거운 컴포넌트에 대해 표준 패턴과 requestIdleCallback을 활용한 지연 로딩을 구현했다. requestIdleCallback은 메인 스레드가 유휴 상태일 때 비긴급 작업을 미룰 수 있게 해 주는 브라우저 API다. 나는 하루아침에 브라우저 스케줄링 전문가가 되지는 않았지만, 여러 접근 방식을 시도하고 결과를 측정해 몇 주에 걸친 사전 학습 없이도 의미 있는 개선을 배포할 수 있었다.

Testing infrastructure

우리의 통합 테스트 스위트는 850개 이상의 테스트를 포함하고 있었으며, 실행에 20 분 이상이 걸렸고, 흔히 불안정하다고 알려져 있었다. 파이프라인을 여러 번 재실행하는 것이 일상이었다. 나는 테스트 샤딩을 도입해 실행 시간을 5–7 분으로 단축하고, 불안정성을 거의 완전히 없앨 수 있었다. 이전에는 CI 설정이 너무 중요하고 불투명해서 건드리기 두려웠다. AI와 함께라면 점진적이고 안전하게 탐색할 수 있었다.

“Someday” features

대부분의 팀과 마찬가지로, 우리는 티켓조차 만들지 못한 아이디어들을 가지고 있었다—작업 중에 눈에 띄지만 우선순위가 낮을 것이라 생각되는 개선 사항들. 예를 들어 대화창과 시트 뷰를 확장하거나, 고객이 여정 중간 단계들을 볼 수 있게 하는 것 등이었다. AI 덕분에 오후에 개념 증명을 만들고, 디자이너에게 보여주며 피드백을 반영해 일주일 안에 배포할 수 있었다. 무한히 미뤄질 것 같던 기능들이 갑자기 현실이 되었다.

이 모든 일은 AI가 제공한 호기심 비용 감소 없이는 일어나지 못했을 것이다.

AI는 학습 장벽을 낮추었고—호기심을 다시 안전하게 느끼게 만들었다.

실제 병목 현상이 된 것

예상치 못한 더 넓은 통찰: 코드 작성이 더 이상 느린 부분이 아니다.

수년 동안 우리는 개발 시간을 주요 제약으로 여겨왔습니다. 스프린트는 구현 역량을 기준으로 계획되고, 기능은 코딩에 걸릴 시간을 기준으로 범위가 정해졌습니다. “시간이 없어서”라는 이유로 기술 부채가 쌓이기도 했습니다.

AI가 그 수식을 바꾸어 놓았습니다.

이제는 오후만에 기능에 대한 신뢰할 만한 개념 증명을 만들 수 있습니다. 하지만 그 기능을 승인받고, 디자인과 정렬하고, 이해관계자에게 검토받으며 로드맵에 배정하는 과정은 여전히 몇 주가 걸립니다.

새로운 병목은 코드 주변 모든 것:

의사결정 및 우선순위 지정
디자인 피드백 루프
팀 간 정렬
검토 및 릴리즈 프로세스

이는 불만이 아니라 관찰입니다. 개발 작업의 성격이 변하고 있습니다. 앞으로 성공할 개발자는 가장 빠른 타이피스트나 가장 깊은 전문가가 아니라, AI를 활용해 기술적 마찰을 제거하면서 소프트웨어의 인간적·조직적 측면을 잘 헤쳐 나갈 수 있는 사람입니다.

호기심과 신중함을 위한 초대

이미 확립된 코드베이스에서 작업하면서 시스템의 일부를 절대 건드리고 싶지 않다고 느낀다면, 이해합니다—저도 그 경험이 있습니다. 제 제안은 간단합니다: 시도 비용을 낮추기 위해 AI를 활용하세요.

AI는 단순히 작업 속도를 높여줄 뿐만 아니라 다시 호기심을 가질 수 있는 허가를 줍니다. 이를 활용해 보세요:

생각해 왔던 캐싱 레이어를 프로토타입으로 만들어 보기.
불안정한 테스트를 고쳐보려 시도해 보기.
“있으면 좋은” 아이디어에 대한 개념 증명을 구축하기.

시작하기 전에 완벽한 이해가 필요하지 않습니다—대부분은 무언가를 시도하고, 작동을 확인하고, 진행하면서 배우는 것으로 충분합니다.

하지만 호기심이 무모함을 정당화하는 라이선스는 아닙니다. AI는 마법이 아닙니다. 다음과 같은 위험이 있습니다:

미묘한 버그를 만들어낼 수 있음.
기존의 아키텍처 실수를 강화할 수 있음.
부주의하게 사용하면 잘못된 자신감을 줄 수 있음.

AI가 피하고 있던 시스템의 부분을 건드릴 수 있게 해 주지만, 판단을 대체해서는 안 됩니다—오히려 그 판단을 증폭시켜야 합니다.

지침 원칙

보안에 중요한 코드를 무작정 실험하지 마세요.
테스트, 동료 리뷰, 팀원 피드백에 크게 의존하세요.
모든 것을 검증하고 “미지에 대한 두려움”이 “맹목적인 신뢰”로 바뀌지 않도록 하세요.

우리처럼 빠르게 변하는 분야에서는, 안전하게 미지를 탐험할 수 있는 능력이 아마도 가장 귀중한 스킬일 것입니다. AI를 활용해 그 격차를 메우되, 언제나 손은 핸들에 올려 두세요.

비슷한 경험이 있다면, 여러분의 이야기를 듣고 싶습니다.