본문으로 이동

AI 시대에 개발자로 일하며 느낀 것들

ChatGPT가 처음 등장했을 때, 나는 AI가 개발자를 대체한다는 말에 크게 공감하지 못했다. 단순 마크업 작업조차 확장성 있는 구조로 픽셀 퍼펙트한 산출물을 뽑아내지 못했기 때문이었다.

하지만 얼마 지나지 않아 모델의 성능이 빠르게 향상됐고, Cursor와 같은 코딩 에이전트가 등장했다. 유튜브에서는 비개발자의 바이브 코딩 영상이 인기를 끌었으며 ‘AI의 개발자 대체’와 자극적인 키워드가 만연했다. 물론 나도 AI를 학습과 업무에 잘 사용하고 있었지만 그때까지도 공포 마케팅 정도로 치부하며 넘어갔던 것 같다.

그러던 작년 말, Claude Opus 4.5 모델을 사용해보면서 생각이 달라지기 시작했다. CLI 기반 코딩 에이전트에 작업을 전적으로 위임하는 방식이 실제 업무에 적용 가능한 수준에 도달해 있었기 때문이다.

이 흐름은 단순히 새로운 도구의 등장이 아니었다. 개발 패러다임을 바꾸는 변화였다.

AI Native로의 전환

지금까지는 요구사항을 바탕으로 구조를 설계하고 단계적으로 세부 구현하는 것이 개발자의 역할이었다.

이제는 문제를 어떻게 정의하고 어디까지 AI에게 위임할 것이며, 어떤 방법으로 검증할 것인지에 초점이 맞춰진다.

비즈니스 요구사항을 세분화하여 작은 단위로 에이전트에 위임하고, 그 안에서 각 분야별 전문가 역할을 수행하는 서브 에이전트들이 사일로 단위로 협업하는 구조이다.

  • 에이전트(Agent): 하나의 목표를 중심으로 작업을 수행하고 결과를 만들어내는 AI 실행 단위
  • 서브 에이전트(Sub-agent): 에이전트 내부에서 각 분야별 역할을 나누어 담당하는 전문화된 하위 단위

그렇다면 어떻게 AI라는 동료와 잘 협업할 수 있을까?

LLM 이해하기

AI와 원활하게 협업하려면, 간단하게라도 LLM(대규모 언어 모델)이 어떻게 동작하는지 알아볼 필요가 있다.

LLM(대규모 언어 모델)은 인간의 뇌를 모방한 수십억 개 이상의 파라미터(가중치)를 가진 심층 인공 신경망이다. 트랜스포머(Transformer) 아키텍처를 기반으로 방대한 데이터를 사전 학습하여 문맥 이해, 텍스트 생성, 번역 등 복잡한 자연어 처리 작업을 수행하는 생성형 AI 기술이다.

이러한 사전 학습 뿐만 아니라, 파인 튜닝과 강화 학습을 거쳐 탄생한 것이 Claude Opus 4.7과 같은 최신 모델이다.

  • 파인튜닝(Fine-tuning): 사람이 만든 양질의 데이터를 모델에 학습시키는 것
  • 강화학습(Reinforcement Learning, RLHF): 주어진 질문에 대해 사람이 더 선호하는 답변에 높은 확률을 부여하도록 추가 학습시키는 것

AI 생산성 높이기

LLM이 항상 정답을 제공하는 것은 아니다.

AI를 도구가 아닌 사람처럼 대하는 관점이 중요하다. 아무리 뛰어난 사람도 명확한 요구사항과 제약 조건, 참고 자료가 없다면 좋은 결과를 내기 힘들다. AI도 마찬가지다.

이를 위해 필요한 것이 바로 컨텍스트 엔지니어링(Context Engineering)이다. 요구사항을 명시적으로 드러내고, 문제의 배경과 제약, 기대 결과를 구조화하여 전달하는 과정이다.

해당 글 작성일 기준으로 대부분의 에이전트에 적용된 내용이지만, 스탠포드가 가르치는 AI생산성 10배 높이는 방법 | 제레미 어틀리에서 아래와 같은 방법을 제시한다. 가볍게 보고 넘어가기 좋다.

  • 사고 과정 추론
  • 퓨샷 프롬프팅
  • 리버스 프롬프팅
  • 역할 부여
  • 롤플레잉

이러한 컨텍스트 엔지니어링의 대표적인 결과물이 스킬이다. 거창한 코드나 AI 모델이 아닌 단순한 Markdown 파일이다. Vercel에서는 실제 프로덕션 사례에서 검증된 React Best Practices 저장소를 공개하기도 했다.

최근에는 LLM의 스케일링 법칙(Scaling Laws)은 한계라는 의견이 많아지면서 모델 경쟁보다는 상위 레이어인 에이전트 하네스(Agent Harness)의 중요성이 더 높아지고 있다.

하네스는 모델을 감싸고 있는 제어 프레임워크로, AI 오케스트레이터 역할을 한다. 하네스는 다음과 같은 핵심 기능을 처리한다.

  • 인간의 개입(human‑in‑the‑loop) 관리
  • 서브 에이전트 조정
  • 파일 시스템 접근 제어
  • 프롬프트 사전 설정 관리
  • 라이프사이클 hooking
  • 실행 계획 및 흐름 관리

출처: 2025 Was Agents. 2026 Is Agent Harnesses. Here’s Why That Changes Everything.

이러한 기능을 구현한 오픈 소스로는 superpowers와 같은 프로젝트가 있다.

결국, AI 생산성을 높이려면 모델 자체뿐만 아니라 이를 둘러싼 설계와 에이전트 관리가 핵심이다. 이 점을 이해했다면 “구글 드라이브 만들어줘”와 같은 원샷 프롬프트만으로는 프로덕트를 완성할 수 없다는 것을 알 수 있을 것이다.

실전 에이전트 활용

Claude Code 공식 문서의 모범 사례를 살펴보면 핵심 전제는 단 하나이다.

컨텍스트 윈도우(Context Window)가 채워질수록 성능이 저하된다. 컨텍스트 윈도우는 관리해야 할 가장 중요한 리소스이다.

이 전제를 기반으로 문서가 제시하는 핵심 패턴은 다음과 같다.

  • 작업을 검증할 방법 제공하기
  • 먼저 탐색하고, 그 다음 계획하고, 그 다음 코드 작성하기(plan mode)
  • 프롬프트에서 구체적인 컨텍스트 제공하기
  • 풍부한 콘텐츠 제공하기
  • 지침(CLAUDE.md) 작성하기

명확한 컨텍스트와 작업 가이드를 제공하기 위해 정교하게 문서화해야 하며, 할루시네이션 방지를 위해 세션 관리와 컨텍스트 윈도우 재설정에 신경써야 한다는 내용이다.

현재 모델의 컨텍스트 윈도우는 계속 확장되고 있으며, 자동 압축과 요약 기술도 발전하고 있다. 그뿐만 아니라, 코드베이스를 분석하여 md 파일을 자동으로 생성해주는 방향으로까지 진화하고 있다.

하지만 결국 무엇을 왜 만들어야 하며 어떻게 검증하고 판단할 것인가는 사람이 정해야 한다. 잘 설계된 오픈 소스를 참고하는 것도 좋고, 직접 사용해보면서 프로젝트에 적합한 지침을 만들어가는 것이 중요하다고 생각한다.

소프트웨어 엔지니어로서 바라보는 AI

지금까지는 AI를 둘러싼 기술적 흐름을 살펴보았다. 여기서부터는 AI 동료와 함께 일하면서 느끼고 고민한 것들을 솔직하게 적어보려 한다.

새로운 개발 언어의 등장

요즘 주변 개발자들이 일하는 방식을 보면 코드 작성보다 MD 파일 작성에 대부분 시간을 할애한다. 자연어로 잘 작성된 스킬은 함수처럼 동작하며 지침은 그 자체로 프로덕트를 지탱하는 스펙이 된다. 코드 위로 자연어라는 추상화된 레이어가 올라온 것이다.

일각에선 부정적인 의견도 있다. “코드 한 줄 작성하지 않는 게 개발인가”, “장인 정신은 어디로 갔는가”라는 반응이다. 공감되는 내용이지만 프로그래밍 언어가 발전해온 역사를 보면 이러한 변화는 자연스러운 흐름이라고 생각된다.

그래서 실제로 도움이 되었는가

AI 에이전트의 발전으로 코드 작성 시간이 줄어든 건 사실이지만 생산성이 크게 향상되었다고 체감하긴 어려웠다.

부족한 문서화와 테스트 코드, 복잡한 비즈니스가 얽힌 레거시 코드 베이스로는 제대로 된 결과물을 뽑아내기 어려웠기 때문이다. 규모가 큰 회사일수록 이런 기술 부채가 쌓여있기 마련인데 내가 속한 조직도 그렇다.

업무 프로세스의 구조적인 문제도 한몫했다. 프론트엔드와 마크업이 분리되어 개발되는 구조는 컴포넌트 기반 개발을 어렵게 만들었다. 디자인 시스템도 같은 이유로 유지보수 되지 못하고 방치되었다. 이렇게 파편화된 UI는 개발과 디자인 생산성을 모두 떨어뜨렸다.

요즘은 이런 문제들을 하나씩 풀어가고 있다. AI가 부족한 리소스를 채워줄 거라는 믿음이 생겼기 때문이다. 하지만 생산성이 올라간 만큼 코드 퀄리티에 대한 고민도 깊어졌다. 에이전트 간 리뷰나 자동화도 시도해보고 있지만 트레이드오프를 판단하는 건 경험이 더 필요할 것 같다.

어떤 개발자가 될 것인가

AI의 등장으로 개발자의 방향성이 크게 세 갈래로 나뉘는 것 같다.

  • 개발자(Developer): AI와 함께 직접 코드를 작성하는 길이다.
  • 개발 팀장(Tech Lead): AI 에이전트들을 이끌며 기술적 판단과 결과물을 책임지는 역할이다. 많은 개발자가 자연스럽게 이동하고 있는 방향이다.
  • 제품 책임자(Product Owner): 코드에서 한 걸음 물러나 제품 정의, 기획, 비즈니스 전략에 집중하는 길이다. 개발자로 오래 살아온 사람에겐 쉽지 않고 배울 것도 많다.

어떻게 보면 주니어에서 시니어로 넘어가며 누구나 했던 고민과 크게 다르지 않다. 코드에서 한 발짝 벗어나 사람을 관리하는 쪽으로 갈 것인가. 아니면 기술적으로 더 깊이 파고드는 전문가가 될 것인가.

사실 나는 개발자 쪽에 더 가깝다. 아직 엔지니어로서 채워야 할 것이 많다고 느끼기 때문이다. 그 위에 리드의 역할을 얹어가고 싶다.

왜 우리는 프로그래밍을 ‘언어’라고 부를까? 글처럼 작성자의 의도와 철학이 코드에 담기기 때문이라고 생각한다. 잘 작성된 코드에는 분명한 미감이 있다. 에이전트에 의해 무분별하게 코드가 생성되는 흐름이 아쉬운 이유다.

물론 개발은 예술이 아니라 비즈니스의 수단이다. 코드의 아름다움 그 자체가 상품이 되는 경우는 드물다. 하지만 유지보수가 소프트웨어 생명 주기의 대부분인 이상, 읽기 좋고 고치기 쉬운 코드를 만들어내는 감각은 여전히 필요하다.

결국 중요한 건 기술과 비즈니스 사이에서 균형을 잡는 능력이다. 이런 감각은 경험에서 나오기 때문에 의식적으로 채워나가야 할 부분이다.

마치며

AI를 대하는 태도는 달라졌지만 나는 여전히 AI가 모든 개발자를 대체하진 않을 거라고 생각한다. 성공한 프로덕트에서 묻어나는 철학과 취향을 효율만 추구하는 AI가 대체할 수 없다고 보기 때문이다.

물론 채용 시장은 차갑다. 주니어는 기회가 없고, 시니어는 자신이 쌓아온 것들이 흔들리는 걸 느낀다. 하지만 AI 시대에도 함께 일하고 싶은 동료의 기준은 크게 달라지지 않았다고 느낀다. 변화에 빠르게 적응하면서도 기술적 깊이를 잃지 않는 사람. 맡은 일에 책임감을 갖고 배려할 줄 아는 사람. 결국 일을 잘하는 사람이 AI도 잘 쓴다. 나도 그런 동료가 되고 싶다.