본문으로 건너뛰기

The AI Engineering Skills Map Part 3 — Fundamentals

Studies · 2026-08-28 · 손봄 2026-09-20

번역본. 원문: The AI Engineering Skills Map Part 3 — Fundamentals.md (Andrew Ng, The Batch / DeepLearning.AI)

AI 개발자에게 소프트웨어 엔지니어링 기초가 여전히 필수인 이유

친애하는 여러분,

에이전틱 코딩과 함께 소프트웨어 엔지니어링 기초는 어떻게 달라졌을까요? 코딩 에이전트에게 코드 작성을 전부 맡기더라도, 소프트웨어 기초를 이해하는 일은 원하는 트레이드오프를 하도록 에이전트를 조종하기 위해, 나아가 애초에 어떤 트레이드오프가 존재하는지 알기 위해 중요합니다. 또한 AI 애플리케이션을 만들 때 AI 코어는 대개 더 넓은 소프트웨어 애플리케이션을 통해 표현되며, 그 애플리케이션의 형태를 잡는 것은 숙련된 엔지니어입니다.

소프트웨어 기초를 이해하지 못한 채 바이브 코딩하는 초심자도 간단한 애플리케이션은 만들 수 있습니다. 그러나 이 경우 코딩 에이전트가 지연 시간, 가용성, 일관성, 신뢰성, 유지보수성, 단순성, 비용 등에서 나쁜 트레이드오프를 선택하는 일이 잦습니다. 대부분의 경우 개발자는 그런 트레이드오프가 존재한다는 사실조차 몰랐고, 따라서 자신의 애플리케이션 맥락에 맞는 결정을 내리도록 에이전트를 조종하지 못했습니다.

이번 레터는 AI 엔지니어링 역량 연구에서 드러난, 소프트웨어 엔지니어링에서 알아야 할 가장 중요한 것들을 설명합니다. 다음에 능숙해야 합니다.

20260920-image

  • 풀스택 애플리케이션 구축
  • 데이터 관리
  • 시스템 아키텍처 설계
  • 안전하고 신뢰할 수 있는 시스템 만들기
  • 확장과 프로덕션 운영

풀스택 애플리케이션 구축. 에이전틱 코딩 덕분에 예전에는 프런트엔드 개발자나 모바일 개발자처럼 더 전문화된 역할을 하던 많은 개발자가 이제 더 넓은 풀스택 역할을 맡을 수 있게 되었습니다. 코딩 에이전트는 개발 과정에서 자신이 덜 익숙한 부분을 도와줄 수 있습니다. 그러나 풀스택이 실제로 어떻게 동작하는지 이해하는 것은 중요합니다. 숙련된 개발자는 UI 컴포넌트, 캐싱, 페이지 렌더링, API 선택과 설계, 인증, 상태 및 세션 관리, 비동기 처리, 데이터 영속성, 테스트, 보안, 접근성 등 프런트엔드와 백엔드 시스템의 핵심 구성 요소와 개념을 이해합니다.

데이터 관리. 데이터는 특별한 주의를 받을 자격이 있습니다. 소프트웨어가 그 위에 세워지는 토대이면서, 상대적으로 바꾸기 어렵기 때문입니다(에이전트가 마이그레이션을 도와준다 해도 그렇습니다). 데이터를 관리할 줄 알면 접근 패턴을 짚어 보고 그것을 근거로 무엇을 얼마나 오래 저장할지 정할 수 있습니다. 적절한 데이터 모델을 식별하고, 알맞은 저장 유형(관계형 테이블, 문서, 키-값, 그래프 등)과 인프라를 고를 수 있으며, 이는 다시 속도, 확장성, 가용성, 신뢰성, 비용에 영향을 줍니다. 트랜잭션과 동시성을 이해하고, 데이터를 깨끗하고 일관되며 최신인 상태로 유지하는 법을 압니다. 필요할 때는 프라이버시, 거버넌스, 규정 준수를 제대로 갖출 수 있습니다. 데이터 생애주기를 관리할 줄 압니다.

애플리케이션이 진화하면 그에 맞춰 데이터 아키텍처를 진화시키는 법도 알아야 합니다. 데이터 관리 방식을 정하는 데는 사람이 제공하는 맥락이 상당히 필요합니다. AI 시스템은 자신의 입력 컨텍스트를 여러분의 데이터 소스에서 얻으므로, 데이터 아키텍처를 잘못 고르면 AI는 자신이 무엇을 모르는지조차 모르게 됩니다. 그래서 관련 맥락을 갖고 AI 엔지니어링에 능숙한 사람, 바로 여러분의 숙련된 개입이 있어야 이를 바로잡을 수 있습니다. 전통적 소프트웨어나 사람이 아니라 에이전트를 위한 데이터 인프라를 어떻게 만들 것인가 역시 빠르게 진화하는 영역이므로, 분야의 변화에 맞춰 모범 사례를 계속 조정해야 합니다.

시스템 아키텍처 설계. 소프트웨어와 데이터 풀스택의 주요 구성 요소를 이해하면, 이 조각들을 어떻게 조립할지 더 잘 결정할 수 있습니다. 좋은 시스템 설계를 하려면 그 소프트웨어가 무엇을 하려는 것인지(사용자는 몇 명인가? 지연 시간은 얼마나 중요한가? 비용은 얼마나 중요한가? 등)를 이해해야 하며, 그래야 애플리케이션 플랫폼, 프런트엔드와 백엔드의 경계, 시스템 분해, 애플리케이션 상태의 배치, 아키텍처 입도(모놀리스 대 마이크로서비스)에 대한 선택을 할 수 있습니다. 또한 스택(프로그래밍 언어, 런타임, 컴포넌트·프런트엔드·백엔드 프레임워크, 데이터 기술)도 골라야 하는데, 때로는 후보를 실험으로 평가한 뒤 하나를 정하게 됩니다.

나아가 올바른 아키텍처는 프로젝트 단계에 따라 움직이는 표적입니다. 빠른 프로토타입을 만들기 위해 고른 단순한 아키텍처가 첫 프로덕션 시스템에 맞는 아키텍처가 아닐 수 있고, 그것 또한 애플리케이션이 확장되면서 바뀔 수 있습니다. 이런 결정을 내리려면 소프트웨어 구성 요소와 애플리케이션 맥락 양쪽에 대한 깊은 기술적 지식이 필요하며, 그래야 더 나은 트레이드오프를 하도록 아키텍처를 설계하고 또 진화시킬 수 있습니다.

안전하고 신뢰할 수 있는 시스템 만들기. 신뢰할 수 있는 시스템을 만들려면 시스템의 정확성을 검증할 테스트 전략을 세울 줄 알아야 합니다. 단위 테스트와 통합 테스트를 어떤 비율로 둘지, 어떤 프레임워크를 쓸지, 커버리지는 어느 수준으로 할지 말입니다. 또한 발생 가능한 실패를 전제로 설계할 줄 알아야 합니다. 예컨대 API가 레이트 리밋에 걸리는 것 같은 실패를 어떻게 처리할지, 우아한 성능 저하(graceful degradation)를 어떻게 내장할지, 실패의 폭발 반경을 어떻게 최소화할지입니다. 여기에 더해, 소프트웨어를 먼저 작성한 뒤 나중에 보안을 고민하는 대신 "시프트 레프트" 흐름은 보안 작업을 생애주기의 더 앞단(전통적 프로젝트 일정에서 왼쪽)으로 옮기고 있습니다. 모든 개발자가 풀스택 개발자가 되어 가듯, 이제 많은 개발자가 부분적으로 보안 엔지니어이기도 합니다. 이제 AI 도구로 코드의 취약점을 스캔하고, 의존성에 공급망 인젝션이 있는지 확인하고, 클라우드 설정에서 공격 표면을 살펴볼 수 있습니다. 그러나 이를 잘 해내려면 여전히 보안에 대한 지식이 어느 정도 필요합니다.

확장과 프로덕션 운영. 실제 사용자에게 서비스하려면 소프트웨어를 프로덕션에 배포할 줄 알아야 합니다. 소프트웨어 개발 생애주기(SDLC)를 실행할 줄 알면 도움이 되는데, 여기에는 빌드와 테스트 외에도 배포 환경 구성, 릴리스 전략 결정, 배포 자동화(CI/CD) 적용, 서비스형 인프라(IaaS)에 대한 이해가 포함됩니다.

프로덕션 운영에는 관측 가능성 도구 도입, 알림 설정, 인시던트 관리가 필요합니다. 마지막으로 애플리케이션을 확장하려면 실제 부하를 이해하고, 서버를 확장하고 로드 밸런싱하는 법, 데이터 인프라를 샤딩·인덱싱·복제로 적응시키는 법, 또는 시스템이 규모에 적응하도록 아키텍처를 변경하는 법을 알아야 합니다. 끝으로 버전 관리, 코드 리뷰, 의존성 유지보수, 기술 부채 관리 같은 코딩 모범 사례를 이해하면 시간이 지나도 시스템을 계속 진화시킬 수 있습니다.

코딩 에이전트는 AI 구성 요소가 전혀 없는 소프트웨어를 포함해 우리가 소프트웨어를 만드는 방식을 바꿔 놓았습니다. 코딩 문법 암기 같은 일부 코딩 지식은 쓸모를 잃어 가고 있습니다. 그러나 소프트웨어가 어떻게 동작하는지 깊이 이해하는 개발자는 이해 없이 바이브 코딩하는 사람을 압도적으로 앞섭니다.

소프트웨어 기초를 (AI와 더불어) 이해하면 소프트웨어가 무엇을 할 수 있고 무엇을 할 수 없는지 파악하는 데도 도움이 됩니다. 이는 코딩 에이전트를 어떻게 쓸지, 빌드의 방향을 어떻게 잡을지에 중요한 맥락이 됩니다. 이 두 가지를 다음 두 편의 레터에서 다루겠습니다.

계속 만들어 나가세요!

Andrew