AI Agent는 개발 방식을 어떻게 바꿀까

Agent는 상황을 인식하고, 필요한 일을 계획하고, 도구를 사용해 실제 행동까지 수행하는 시스템에 가깝다.

 

이 글에서는 AI Agent의 개념부터 Agentic AI의 구조, 소프트웨어 개발 주기에서 AI가 바꿀 수 있는 부분,

그리고 개발자가 여전히 책임져야 하는 검증과 유지보수까지 정리한다.

 

Agent는 무엇인가

Agent라는 단어는 원래 대리인, 중개인, 행동 주체라는 의미를 가진다.

 

AI에서 말하는 에이전트(Agent)는 상황이 발생했을 때 자신이 가진 정보와 도구를 바탕으로

적절한 처리를 자동으로 수행할 수 있는 반독립적인 프로그램이라고 이해할 수 있다.

 

여기서 중요한 표현은 반독립적이다.

완전히 마음대로 움직인다는 뜻은 아니다.

사람이 목표나 권한 범위를 정해주고, 그 안에서 에이전트가 판단하고 행동한다는 뜻에 가깝다.

 

일반 LLM은 보통 질문을 받으면 답변을 생성한다.

예를 들어 사용자가 “이 코드 리뷰해줘”라고 하면, 일반 LLM은 코드에 대한 설명이나 개선점을 텍스트로 알려준다.

 

반면 Agent는 단순히 말만 하지 않는다. 필요한 파일을 열고, 테스트를 실행하고, 실패 로그를 확인하고,

코드를 수정한 뒤 다시 테스트할 수 있다.

 

즉 일반 LLM이 “답변하는 AI”라면, Agent는 “목표를 수행하는 AI”에 가깝다.

비유하자면 일반 LLM은 상담원에 가깝고, Agent는 실제로 업무를 처리하는 비서에 가깝다.

 

 

Agentic AI를 구성하는 두 가지 관점

Agentic AI를 이해할 때 중요한 기준은 자율성(Autonomy)과 숙련도(Proficiency)다.

 

자율성은 상황에 적합한 판단을 스스로 내릴 수 있는지를 의미한다.

 

예를 들어 “회의 일정을 잡아줘”라는 요청을 받았을 때, 캘린더를 확인해야 하는지,

참석자에게 메일을 보내야 하는지, 빈 회의실을 찾아야 하는지 판단하는 능력이 자율성이다.

 

숙련도는 적절한 도구를 능숙하게 사용할 수 있는지를 의미한다.

 

LLM은 기본적으로 다음 토큰을 예측하는 모델이다.

그래서 계산, 검색, 파일 수정, API 호출 같은 작업은 외부 도구의 도움을 받는 편이 더 정확하다.

예를 들어 “8 × 9 × 2 × 3 ÷ 1.34” 같은 계산을 LLM이 머릿속으로 흉내 내듯 생성하면 틀릴 수 있다.

하지만 계산기 도구를 호출하면 정확한 값을 얻을 수 있다.

 

이처럼 기본 LLM에 도구(Tool)와 기억(Memory)을 붙인 구조를 보강된 LLM(Augmented LLM)이라고 볼 수 있다.

 

도구는 계산기, 검색기, 데이터베이스, 브라우저, 코드 실행기, API 같은 외부 기능을 의미한다.

기억은 이전 대화나 작업 결과를 저장하고 다음 판단에 활용하는 능력을 의미한다.

결국 Agentic AI는 LLM이라는 뇌에 도구라는 손과 발, 기억이라는 메모장을 붙인 구조라고 볼 수 있다.

 

 

 

Agent는 어떻게 동작할까

Agent의 동작 흐름은 크게 인식, 계획, 행동, 관찰로 볼 수 있다.

 

인식(Perception)은 현재 상황을 파악하는 단계다.

사용자 요청을 읽거나, 화면을 확인하거나, 파일 내용을 읽는 일이 여기에 해당한다.

 

계획(Planning)은 목표를 달성하기 위한 순서를 정하는 단계다.

어떤 파일을 먼저 열지, 어떤 테스트를 실행할지, 어떤 API를 호출할지 결정한다.

 

행동(Action)은 실제로 도구를 사용하는 단계다.

버튼을 클릭하거나, API를 호출하거나, SQL을 실행하거나, 코드를 수정한다.

 

관찰(Observation)은 행동 결과를 확인하는 단계다. 테스트가 성공했는지, API 응답이 정상인지, 화면이 원하는 상태로 바뀌었는지 확인한다.

이 흐름은 ReAct(Reason + Act)와도 연결된다.

 

ReAct는 추론하고, 행동하고, 그 결과를 관찰한 뒤 다시 추론하는 방식이다.

예를 들어 “서울 오늘 날씨 알려줘”라는 요청이 들어오면 Agent는 먼저 실시간 정보가 필요하다고 판단한다.

이후 날씨 API를 호출하고, 응답 결과를 관찰한 뒤 사용자에게 현재 날씨를 알려준다.

단순 답변 생성과 달리, 외부 환경과 상호작용한다는 점이 Agent의 핵심이다.

 

 

 

소프트웨어 개발에서의 Agent 사례

Agent는 소프트웨어 개발 과정에서도 다양한 방식으로 활용될 수 있다.

 

결함 위치 자동 식별 기술인 AutoFL은 실패한 테스트가 주어지면 코드를 탐색하면서 버그가 있을 만한 위치를 찾아낸다.

여기서 중요한 점은 단순히 코드 전체를 보고 추측하는 것이 아니라, 테스트 결과와 커버리지(Coverage), 코드 조각(Snippet), 함수 호출 정보를 활용한다는 점이다.

 

커버리지는 테스트가 실제로 실행한 코드의 범위를 의미한다. 어떤 코드가 테스트 중 한 번도 실행되지 않았다면 해당 부분은 검증되지 않았다고 볼 수 있다.

 

AutoFL 같은 구조는 실패한 테스트를 보고, 관련 코드를 조회하고, 실행된 범위를 확인하면서 버그 위치를 좁혀간다. 사람이 디버깅할 때 로그와 테스트 결과를 보며 원인을 추적하는 과정과 비슷하다.

 

DroidAgent는 안드로이드 앱 자동 테스트를 수행하는 Agent 사례다.

앱이 주어지면 다양한 시나리오를 계획하고 실행한다. 예를 들어 회원가입 버튼을 누르고, 이메일을 입력하고, 다음 화면으로 이동하고, 실패하면 다시 다른 입력을 시도한다.

 

이 구조에는 Planner, Observer, Reflector 같은 역할이 등장한다.

 

Planner는 무엇을 할지 계획한다. Observer는 현재 화면이나 상태를 관찰한다.

Reflector는 실패 원인을 되돌아보고 다음 행동을 수정한다.

즉 Agent는 단순히 버튼을 누르는 자동화 도구가 아니라, 현재 상태를 보고 다음 행동을 조정하는 시스템에 가깝다.

 

AutoSD는 설명 가능한 프로그램 자동 수정 기술이다. 핵심은 과학적 디버깅(Scientific Debugging) 방식이다.

 

과학적 디버깅은 가설을 세우고, 실험하고, 결과를 관찰하고, 결론을 내리는 방식으로 디버깅하는 접근이다.

 

예를 들어 다음과 같은 코드가 있다고 해보자.

return n % 2 == 0 and n > 8

그런데 테스트는 f(8) == True를 기대한다.

이 경우 8 > 8은 거짓이므로 테스트가 실패한다.

Agent는 “n > 8 조건이 문제일 수 있다”는 가설을 세우고, n >= 8로 바꾸는 실험을 해본 뒤 테스트를 다시 실행할 수 있다.

 

이 과정은 단순히 코드를 한 번에 고치는 것이 아니라, 원인을 추정하고 검증하면서 수정하는 방식이다.

 

 

 

반독립적 Agent와 완전 자율형 Agent

Agent의 자율성에도 범위가 있다.

 

AutoFL, AutoSD, DroidAgent 같은 시스템은 반독립적 에이전트 구조에 가깝다.

 

사람이 먼저 Agent가 수행할 업무를 단계별로 쪼개고, 가능한 행동과 흐름을 정한다. LLM은 그 안에서 핵심적인 결정을 내리며 작업을 추진한다.

이 방식은 허용되지 않은 액션을 수행할 수 없다는 장점이 있다. 정해진 레일 안에서 움직이기 때문에 상대적으로 안전하다.

 

반면 Claude Code, Cursor 같은 개발 도구의 Agent는 더 높은 자율성을 가진 형태에 가깝다.

 

사용자가 “이 기능 만들어줘”라고 최종 목표를 주면,

Agent가 필요한 단계를 스스로 구성하고 실행에 옮긴다.

파일을 만들고, 코드를 수정하고, 테스트를 실행하고, 에러를 보고 다시 수정할 수 있다.

 

다만 자율성이 높아질수록 위험도 커진다.

잘못된 파일을 수정하거나, 원하지 않는 명령을 실행하거나, 보안상 민감한 작업을 수행할 수 있기 때문이다.

그래서 완전 자율형 Agent에는 사용자 승인, 권한 제한, 샌드박스(Sandbox), 도구 제한 같은 안전장치가 필요하다.

 

 

 

소프트웨어 개발 주기에서 AI가 바꾸는 것

소프트웨어 개발 주기(Software Development Life-Cycle)는 일반적으로 요구사항, 설계, 구현, 검증, 유지보수의 흐름으로 볼 수 있다.

AI는 이 모든 단계에 영향을 줄 수 있지만, 각 단계에서의 역할은 다르다.

 

구현(Implementation)은 AI가 가장 직접적으로 도와줄 수 있는 영역이다.

예를 들어 “Spring Boot로 회원가입 API를 만들어줘”라고 하면 AI는 Controller, Service, Repository, DTO 같은 코드를 어느 정도 생성할 수 있다.

이 흐름은 과거 기계어에서 고차원 언어로 추상화 수준이 높아진 것과 비슷한 면이 있다.

기계어는 사람이 이해하기 어렵지만, C, Java, Python 같은 고차원 언어는 사람이 읽기 쉬운 방식으로 컴퓨터에게 명령할 수 있게 해주었다.

 

AI 코드 생성은 한 단계 더 나아가 자연어로 의도를 전달하고 코드를 얻는 방식이다.

하지만 이전의 추상화와 다른 점도 있다.

프로그래밍 언어는 엄밀하지만 자연어는 모호하다. “회원가입 기능 적당히 만들어줘”라는 말에는 비밀번호 암호화, 이메일 중복 검사, 인증 메일, 예외 응답 형식 같은 정보가 빠져 있다.

 

컴파일러는 엄밀한 코드를 정해진 규칙으로 변환하지만, LLM은 모호한 자연어를 바탕으로 그럴듯한 코드를 생성한다.

따라서 AI가 생성한 코드는 반드시 검증이 필요하다.

 

 

생산성은 코드 줄 수가 아니다

AI가 구현을 도와줄수록 “얼마나 많은 코드를 작성했는가”는 덜 중요한 기준이 된다.

생산성의 진정한 척도는 하루에 적은 코드의 줄 수가 아니다.

 

좋은 개발자는 불필요한 코드를 줄이고, 단순하고 안정적인 구조를 만든다.

AI가 코드를 많이 생성해줄 수 있는 시대에는 다음과 같은 능력이 더 중요해진다.

 

문제를 정확히 정의했는가.

불필요한 복잡도를 줄였는가.

테스트 가능한 구조인가.

보안과 예외 상황을 고려했는가.

운영 중 문제가 생겼을 때 추적 가능한가.

 

결국 생산성은 코드 양보다 문제 해결의 품질에 가깝다.

 

 

 

설계는 왜 더 중요해질까

설계(Design)는 시스템을 어떻게 만들지 구조를 정하는 일이다.

 

소프트웨어 아키텍처(Software Architecture)는 전체 시스템을 구성하는 요소를 정의하고,

그 요소들 간의 구조적인 관계를 수립하는 것이다.

 

예를 들어 쇼핑몰 서비스를 만든다면 회원, 상품, 주문, 결제, 알림 기능을 어떻게 나눌지 결정해야 한다.

주문이 생성될 때 결제를 먼저 처리할지, 재고를 언제 감소시킬지, 결제 실패 시 주문 상태를 어떻게 되돌릴지 같은 흐름도 설계해야 한다.

 

기술을 아는 것과 설계를 잘하는 것은 다르다.

Java 문법을 아는 것과 좋은 백엔드 시스템을 설계하는 것은 다르다.

Spring을 쓸 줄 아는 것과 장애에 강한 시스템을 만드는 것도 다르다.

 

도구를 아는 것과 좋은 구조를 만드는 것은 다른 능력이다.

AI가 구현을 많이 도와줄수록 개발자에게는 시스템 전체를 조망하는 능력이 더 중요해진다.

앞으로 소프트웨어 엔지니어에게 요구되는 능력은 단순 구현보다 아키텍처 설계 능력에 가까워질 수 있다.

 

 

 

요구사항은 좋은 프롬프트와 연결된다

요구사항(Requirement)은 무엇을 만들지 정의하는 단계다.

 

전통적인 소프트웨어 개발에서도 요구사항은 자연어에 의존할 수밖에 없다.

사용자는 보통 코드가 아니라 말로 요구한다.

 

“로그인이 됐으면 좋겠어요.”

“관리자가 회원을 관리할 수 있으면 좋겠어요.”

“결제 실패 시 사용자에게 알려주세요.”

이런 말을 개발자가 분석해 정확한 요구사항으로 바꾸어야 한다.

AI 시대에는 요구사항을 명확히 쓰는 능력이 좋은 프롬프트를 쓰는 능력과 연결된다.

표현하지 않은 기능은 구현을 보장할 수 없다.

 

예를 들어 “회원가입 기능 만들어줘”라는 요청에는 너무 많은 정보가 빠져 있다.

 

이메일 중복 검사는 해야 하는지, 비밀번호는 어떻게 암호화할지, 인증 메일이 필요한지, 실패 응답 형식은 어떻게 할지 명확하지 않다.

 

반면 다음과 같이 작성하면 훨씬 좋은 결과를 기대할 수 있다.

회원가입 API를 구현한다.
이메일은 중복될 수 없다.
비밀번호는 BCrypt로 암호화한다.
닉네임은 2자 이상 10자 이하로 제한한다.
중복 이메일이면 409 Conflict를 반환한다.
입력값이 잘못되면 400 Bad Request를 반환한다.
회원 생성 시 createdAt을 저장한다.

AI가 좋은 코드를 만들게 하려면 사람이 먼저 좋은 요구사항을 작성해야 한다.

 

 

비기능 속성은 왜 중요할까

기능 요구사항은 시스템이 무엇을 해야 하는지를 말한다.

 

로그인할 수 있어야 한다. 게시글을 작성할 수 있어야 한다. 결제할 수 있어야 한다. 이런 것들이 기능 요구사항이다.

반면 비기능 속성(Non-functional Attribute)은 시스템이 얼마나 빠르고, 안전하고, 안정적으로 동작해야 하는지를 말한다.

 

예를 들어 다음과 같은 것들이 비기능 속성이다.

응답 시간은 1초 이하여야 한다.

비밀번호는 암호화되어 저장되어야 한다.

장애 발생 시 주문 데이터가 유실되면 안 된다.

동시에 1만 명이 접속해도 버텨야 한다.

개인정보 접근 로그를 남겨야 한다.

 

자동차, 의료, 금융 같은 산업에서는 비기능 속성이 특히 중요하다.

예를 들어 차량 소프트웨어에서는 ISO26262 같은 기능 안전 기준이나 ISO21434 같은 사이버보안 기준을 고려해야 할 수 있다.

중요한 점은 마지막에 테스트만 통과하면 되는 것이 아니라, 요구사항 단계부터 안전과 보안을 고려해야 한다는 것이다.

 

 

 

검증은 Agent 자동화의 핵심이다

검증(Verification)은 만든 소프트웨어가 의도한 대로 동작하는지 확인하는 과정이다.

AI Agent가 코드를 만들 수 있다고 해도, 그 코드가 맞는지 확인하는 검증이 없으면 자동화는 위험해진다.

 

닫힌 검증 루프는 Agent 자동화의 필수 요소다.

닫힌 검증 루프란 다음 과정이 자동으로 반복되는 구조다.

코드 작성
→ 테스트 실행
→ 실패 확인
→ 코드 수정
→ 테스트 재실행
→ 성공할 때까지 반복

사람 개발자도 비슷한 방식으로 일한다.

 

코드를 작성하고, 테스트를 돌리고, 실패 로그를 보고, 원인을 찾고, 다시 수정한다.

Agent가 이 루프를 가질 수 있다면 실패를 보고 다시 시도할 수 있다.

어떤 면에서 AI는 될 때까지 시행착오를 반복하고, 빠른 연산 속도로 여러 시도를 하고, 검증 결과를 통해 개선하는 시스템으로 볼 수 있다.

 

하지만 여기서 핵심은 검증이다.

검증이 없다면 AI는 틀린 결과를 만들어도 틀렸는지 알 수 없다.

 

 

오라클 문제는 자동 검증의 한계다

오라클 문제(Oracle Problem)는 소프트웨어 테스트에서 오래된 문제다.

여기서 오라클은 어떤 입력에 대한 올바른 출력이 무엇인지 알려주는 기준을 뜻한다.

 

예를 들어 add(2, 3)의 정답이 5라는 것을 알아야 테스트할 수 있다.

 

테스트는 결함의 존재를 밝힐 수는 있지만, 무결함을 증명할 수는 없다.

테스트 100개가 모두 통과했다고 해서 버그가 전혀 없다고 증명할 수는 없다.

아직 테스트하지 않은 입력이 있을 수 있기 때문이다.

 

자동 검증을 완전히 수행하려면 모든 입력에 대한 올바른 출력값을 아는 자동화된 오라클이 필요하다.

 

그런데 모든 입력에 대해 정답을 이미 알고 있는 완전한 오라클이 있다면,

애초에 프로그램을 따로 작성할 이유가 약해진다.

이것이 자동 검증의 역설이다.

 

AI가 테스트 코드까지 작성할 수 있다고 해도 이 문제는 남는다.

AI가 요구사항을 잘못 이해하면 코드와 테스트를 모두 같은 방향으로 잘못 만들 수 있다.

 

예를 들어 비밀번호는 8자 이상이어야 하는데 AI가 6자 이상으로 오해하고,

코드와 테스트를 모두 6자 기준으로 만들면 테스트는 통과한다. 하지만 실제 요구사항은 틀린 것이다.

 

그래서 AI가 만든 테스트도 사람이 요구사항 기준으로 검토해야 한다.

 

 

유지보수는 오래된 맥락을 이해하는 일이다

유지보수(Maintenance)는 이미 만든 소프트웨어를 계속 고치고 운영하는 일이다.

버그 수정, 기능 추가, 성능 개선, 보안 패치, 장애 대응이 모두 유지보수에 포함된다.

 

유지보수는 단순히 현재 코드만 읽는 일이 아니다.

기존 코드베이스와 변화의 역사를 함께 이해해야 한다.

예를 들어 코드에 이상한 예외 조건이 있어도, 과거 정책 변경이나 장애 대응 때문에 들어간 코드일 수 있다.

 

LLM은 한 번에 볼 수 있는 컨텍스트 길이에 한계가 있다.

대규모 프로젝트에는 코드뿐 아니라 테스트, 문서, 이슈 기록, 장애 기록, 회의 결정, 임시 예외 처리, 비즈니스 정책 변경이 쌓인다.

유지보수는 이 모든 맥락을 이해해야 하는 일이다.

 

그래서 AI가 도움을 줄 수는 있어도, 오래된 시스템의 유지보수를 완전히 대신하기는 어렵다.

 

소프트웨어의 유효기간도 코드마다 다르다.

한두 번 쓰고 버리는 데이터 정리 스크립트라면 AI가 만든 코드를 간단히 확인하고 사용할 수 있다.

 

하지만 금융 거래 시스템, 의료 시스템, 자동차 제어 시스템, 공장 모니터링 시스템처럼 오래 운영되고 안전이 중요한 시스템은 전혀 다르다.

검증, 리뷰, 로그, 변경 이력, 안전 기준, 운영 책임이 모두 필요하다.

 

 

 

코드리뷰는 사라질까

AI가 자연어만으로 개발을 가능하게 만든다면 코드 자체는 불필요한 디테일처럼 보일 수 있다.

사람이 코드를 읽지 않는다면 코드리뷰도 필요 없어지는 것 아닐까라는 질문이 생긴다.

 

일부 관점에서는 코드리뷰보다 아키텍처에 대한 토론이 더 중요해질 수 있다.

구현 디테일보다 산출물과 시스템 구조에 더 집중하는 개발자가 AI를 더 잘 사용할 수 있다는 생각이다.

 

하지만 현재 시점에서 코드리뷰가 완전히 사라진다고 보기는 어렵다.

AI가 만든 코드도 요구사항을 오해할 수 있고, 보안 취약점을 만들 수 있고, 테스트하기 어려운 구조를 만들 수 있다.

 

다만 코드리뷰의 초점은 바뀔 수 있다.

예전에는 변수명, 반복문, 작은 구현 디테일도 많이 봤다면 앞으로는 요구사항 충족 여부, 테스트 가능성, 보안, 장애 대응, 아키텍처 적합성 같은 큰 관점이 더 중요해질 수 있다.

 

기계가 만든 코드를 기계가 리뷰하는 방식도 가능하다.

하지만 기계 리뷰도 같은 맥락을 놓치거나 같은 종류의 오류를 반복할 수 있다.

따라서 기계 리뷰는 도움이 되지만 최종 책임을 완전히 대신하기는 어렵다.

 

 

 

지금 개발자는 LLM을 어떻게 써야 할까

LLM을 사용할 때 가장 먼저 기억해야 할 것은 원리다.

 

LLM은 다음 토큰 자동완성 엔진(next token autocompletion engine)에 가깝다.

정답을 알고 말하는 존재가 아니라, 문맥상 자연스러운 다음 토큰을 생성하는 모델이다.

그래서 생성된 결과물의 품질이 보장되지 않는다는 점을 이해하고 써야 한다.

 

또 실무 환경에서는 항상 가장 강력한 상용 모델을 사용할 수 없을 수도 있다.

비용, 보안, 회사 정책, 데이터 반출 제한, 응답 속도, 온프레미스 환경 같은 제약이 있기 때문이다.

 

프롬프트 엔지니어링을 통해 그럴듯한 결과를 만들었다고 해서, 내가 그 개념을 모두 이해하고 작성한 것은 아니다.

AI가 Kafka Consumer 코드를 만들어줬다고 해서

내가 Kafka offset, consumer group, retry, idempotency를 이해한 것은 아니다.

 

AI가 만든 결과를 내 실력으로 만들려면 반드시 이해하고 설명할 수 있어야 한다.

 

또 소프트웨어 종류에 따라 AI 활용 효과와 위험도는 다르다.

데이터 분석 스크립트와 자동차 ECU는 같은 기준으로 다룰 수 없다.

간단한 자동화 스크립트는 빠르게 만들고 사용할 수 있지만, 안전 필수 시스템은 훨씬 높은 검증 기준이 필요하다.

 

주니어 개발자는 무엇을 준비해야 할까

AI 시대에도 보수적인 답은 여전히 유효하다.

 

생성된 코드라도 모두 이해하는 사람이 더 우위에 있다.

면접에서도 “이 코드를 왜 이렇게 작성했나요?”, “트랜잭션 경계는 왜 여기인가요?”, “동시성 문제는 없나요?” 같은 질문에 답할 수 있어야 한다.

 

미래지향적인 답도 있다.

코드는 점점 기계어처럼 되고, 사람은 시스템 디자인과 아키텍처에 더 집중해야 한다는 관점이다.

 

실제로 구현이 자동화될수록 요구사항을 명확히 정의하고, 시스템 구조를 설계하고, 결과를 검증하는 능력이 더 중요해진다.

기술에 국한되지 않은 답도 필요하다.

LLM의 지속가능성에는 비용, 저작권, 보안, 개인정보, 규제, 기업 정책, 전력 사용, 사회적 신뢰 같은 기술 외적인 요인이 많다.

 

결국 개발자는 AI 도구만 잘 쓰는 사람이 아니라, AI를 실제 시스템과 조직의 맥락 안에서 책임 있게 사용할 수 있는 사람이 되어야 한다.

 

아키텍처는 책으로만 배우기 어려운 영역이다.

팀 인원, 마감 일정, 운영 비용, 기존 코드, 장애 이력, 서비스 규모, 보안 요구사항, 비즈니스 정책이 모두 설계에 영향을 준다.

그래서 주니어 개발자에게는 다양한 개발 경험을 통해 요구사항, 설계, 구현, 검증, 유지보수의 전체 흐름을 겪어보는 것이 중요하다.

 

질문과 답변

Q1. AI Agent란 무엇인가요?

AI Agent는 목표를 달성하기 위해 상황을 인식하고, 스스로 계획을 세우며, 도구를 사용해 행동할 수 있는 AI 시스템이다.

 

Q2. 일반 LLM과 Agent의 차이는 무엇인가요?

일반 LLM은 주로 텍스트 응답 생성에 집중하지만, Agent는 외부 도구를 사용하고 실제 행동을 수행할 수 있다.

 

Q3. Augmented LLM이란 무엇인가요?

Augmented LLM은 기본 LLM에 Tool과 Memory 같은 기능을 추가해 검색, 계산, API 호출 같은 외부 기능을 사용할 수 있도록 만든 확장형 LLM이다.

 

Q4. Agent에서 Tool이 왜 중요한가요?

LLM은 본질적으로 다음 토큰 예측 모델이기 때문에 정확한 계산이나 실시간 정보 조회에는 한계가 있다. 그래서 계산기, 검색기, DB 같은 외부 도구를 함께 사용한다.

 

Q5. ReAct 방식이란 무엇인가요?

ReAct는 Reason과 Act를 반복하며, 추론 후 행동하고 그 결과를 다시 관찰해 다음 행동을 결정하는 방식이다.

 

Q6. Agent에서 Memory는 왜 중요한가요?

이전 대화나 작업 결과를 기억해야 현재 상황을 이해하고 연속적인 작업을 수행할 수 있기 때문이다.

 

Q7. AutoSD의 핵심 아이디어는 무엇인가요?

AutoSD는 가설 생성, 실험, 검증 과정을 반복하는 과학적 디버깅 방식을 기반으로 자동 디버깅을 수행한다.

 

Q8. 완전 자율형 Agent의 위험 요소는 무엇인가요?

잘못된 코드 실행, 권한 오남용, 예상치 못한 행동 가능성이 있기 때문에 사용자 승인과 권한 제한 같은 안전장치가 필요하다.

 

Q9. 소프트웨어 개발 주기란 무엇인가요?

소프트웨어 개발 주기(Software Development Life-Cycle)는 소프트웨어를 만들고 운영하기까지의 전체 과정을 의미한다. 일반적으로 요구사항 분석, 설계, 구현, 검증, 유지보수 단계로 구성된다.

 

Q10. AI 시대에 구현 단계는 어떻게 달라질까요?

LLM이 코드 생성과 리팩토링을 도와주면서 구현 자체는 점점 자동화될 수 있다. 하지만 AI가 생성한 코드가 요구사항과 보안, 성능, 테스트 기준을 만족하는지는 개발자가 검증해야 한다.

 

Q11. 생산성을 코드 줄 수로 판단하면 안 되는 이유는 무엇인가요?

코드 줄 수가 많다고 좋은 소프트웨어가 되는 것은 아니기 때문이다. 오히려 적은 코드로 단순하고 안정적인 구조를 만드는 것이 유지보수성과 품질 측면에서 더 중요할 수 있다.

 

Q12. 소프트웨어 아키텍처란 무엇인가요?

소프트웨어 아키텍처(Software Architecture)는 시스템을 구성하는 요소를 정의하고, 그 요소들 사이의 관계와 전체 구조를 설계하는 것이다. 단순 구현보다 시스템 전체를 바라보는 능력이 필요하다.

 

Q13. AI 시대에 설계 능력이 더 중요해지는 이유는 무엇인가요?

구현은 언어모델의 도움으로 자동화되기 쉬운 반면, 설계는 요구사항, 도메인, 데이터 흐름, 보안, 성능, 장애 대응 등을 종합적으로 고려해야 하기 때문이다. 따라서 AI 시대에는 시스템 전체를 조망하는 설계 능력이 더 중요해진다.

 

Q14. 요구사항 분석이 프롬프트 작성과 연결되는 이유는 무엇인가요?

LLM은 사용자가 입력한 맥락과 지시에 따라 답을 생성한다. 요구사항이 모호하면 AI가 만든 결과도 모호하거나 잘못될 수 있다. 따라서 요구사항을 정확하고 명료하게 표현하는 능력이 좋은 프롬프트를 작성하는 능력과 연결된다.

 

Q15. 기능 요구사항과 비기능 속성의 차이는 무엇인가요?

기능 요구사항은 시스템이 무엇을 해야 하는지를 나타낸다. 예를 들어 로그인, 결제, 게시글 작성이 기능 요구사항이다. 비기능 속성은 시스템이 얼마나 빠르고 안전하고 안정적으로 동작해야 하는지를 나타낸다. 예를 들어 성능, 보안, 안정성, 가용성, 안전성이 여기에 해당한다.

 

Q16. 안전 기준은 왜 요구사항 단계부터 고려해야 하나요?

자동차, 금융, 의료처럼 안전과 보안이 중요한 산업에서는 단순히 마지막 검증을 통과하는 것만으로 충분하지 않다. 개발 과정 전체에서 안전 기준을 고려했다는 근거가 필요하므로 요구사항 단계부터 관련 기준을 반영해야 한다.

 

Q17. 검증(Verification)이란 무엇인가요?

검증은 소프트웨어가 요구사항대로 올바르게 동작하는지 확인하는 과정이다. 테스트, 코드 실행, 결과 비교 등을 통해 구현 결과가 의도와 맞는지 확인한다.

 

Q18. 닫힌 검증 루프가 AI 에이전트에 중요한 이유는 무엇인가요?

닫힌 검증 루프가 있으면 에이전트가 코드를 작성한 뒤 테스트를 실행하고, 실패 결과를 바탕으로 다시 수정할 수 있다. 즉 성공할 때까지 시행착오를 반복할 수 있기 때문에 자동화 수준이 높아진다.

 

Q19. 오라클 문제란 무엇인가요?

오라클 문제는 테스트에서 주어진 입력에 대한 올바른 출력이 무엇인지 판단하는 기준을 마련하기 어렵다는 문제다. 테스트는 결함의 존재를 밝힐 수 있지만, 모든 입력에 대해 무결함을 증명하기는 어렵다.

 

Q20. AI가 테스트 코드까지 작성하면 충분한가요?

충분하지 않을 수 있다. AI가 요구사항을 잘못 이해하면 코드와 테스트를 모두 같은 방향으로 잘못 작성할 수 있다. 따라서 AI가 작성한 테스트도 사람이 요구사항 기준으로 검토해야 한다.

 

Q21. 유지보수가 AI 시대에도 어려운 이유는 무엇인가요?

유지보수는 현재 코드뿐 아니라 코드가 변화해온 역사, 정책 변경, 장애 이력, 팀의 의사결정 맥락을 이해해야 하기 때문이다. LLM은 컨텍스트 길이에 한계가 있어 오래된 프로젝트의 모든 맥락을 완전히 이해하기 어렵다.

 

Q22. 코드리뷰는 AI 시대에 사라질까요?

완전히 사라지기보다는 초점이 바뀔 가능성이 크다. 구현 디테일에 대한 리뷰는 줄어들 수 있지만, 요구사항 충족 여부, 보안, 테스트 가능성, 아키텍처 적합성 같은 검증은 여전히 중요하다.

 

Q23. LLM을 사용할 때 가장 중요한 태도는 무엇인가요?

LLM이 다음 토큰을 예측하는 모델이라는 원리를 이해하고, 생성 결과의 품질이 보장되지 않음을 전제로 사용해야 한다. 따라서 결과를 그대로 믿기보다 테스트와 리뷰를 통해 검증해야 한다.

 

Q24. 주니어 개발자는 AI 시대에 어떤 역량을 키워야 하나요?

AI가 생성한 코드라도 이해하고 설명할 수 있는 기본기를 갖춰야 한다. 또한 요구사항 분석, 테스트, 유지보수, 시스템 설계 경험을 쌓아 전체 구조를 이해하는 역량을 키워야 한다.