코드 생성에서 개발 라이프사이클 전체를 AX로

-AI 코딩에서 테스트·운영까지, 개발 프로세스는 어떻게 바뀌어야 할까-

1. AI에게 코딩을 맡기는 방식이 달라졌다

AI를 개발에 본격적으로 사용하게 된 지 불과 몇 달 만에 직접 코드를 작성하는 경우가 거의 없어졌습니다. 처음에는 필요한 기능을 설명하고 코드를 만들어달라고 하는 정도였으나, 지금은 AI와 개발 목표를 계획하고 상세 계획을 세운 뒤 구현과 검증까지 진행하고 있습니다.

또한 AGENTS.md를 통해 프로젝트의 구조와 규칙을 미리 알려주고 그 규칙 안에서 작업하게 만들었고, SKILL.md를 통해 작업별로 필요한 컨텍스트만 집중해서 제공하기도 합니다. AGENTS.md가 프로젝트 전반에 항상 적용되는 공통 규칙이라면, SKILL.md는 현재 작업에 필요한 지식과 작업 방법을 선택적으로 제공하는 역할에 가깝습니다. 하나의 작업에서 여러 Skill을 조합해 사용할 수도 있습니다.

상황에 따라 여러 모델을 역할별로 나누어 사용하기도 합니다. 복잡한 분석과 설계는 성능 좋은 모델에게, 토큰 소모가 큰 코드 생성은 상대적으로 저렴한 모델에게 맡깁니다. 이후 다른 모델을 이용해 누락이나 구현 완성도 등을 교차 검증하기도 합니다. 여러 모델을 사용하는 이유는 비용을 줄이면서 서로 다른 관점으로 결과를 검토하기 위해서입니다. 물론 부자라면 최상급 모델만 사용하는 것도 좋습니다.

2. 어마어마한 양의 코드, 테스트를 통과했으니 안심해도 될까?

AI를 이용하면 이전보다 훨씬 짧은 시간에 많은 양의 코드를 만들어낼 수 있습니다. 문제는 코드의 양이 늘어난 만큼 사람이 일일이 검토하기는 더 어려워졌다는 것입니다. AI에게 기능 구현을 요청하면 이제 코드만 작성해주는 것도 아닙니다. 필요한 테스트 코드도 함께 만들어줍니다. 빌드도 성공합니다. JUnit 테스트도 모두 통과합니다. 다른 AI에게 코드 리뷰를 요청해도 특별한 문제가 없다고 합니다.

그렇다면 이제 안심해도 될까요? 조금 생각해보면 그렇지는 않습니다. 코드를 만든 것도 AI이고, 어떤 테스트가 필요한지 판단한 것도 AI입니다. AI가 필요하다고 생각한 테스트 몇 개를 통과했다고 해서 그 프로그램이 충분히 안전하다고 할 수는 없습니다. 물론 이것은 AI가 만든 코드만의 문제는 아닙니다. 우리가 직접 프로그램을 만들던 시절에도 100% 완벽한 소프트웨어는 없었습니다. 충분한 테스트를 거쳐 배포했는데도 운영 중 예상하지 못했던 문제가 발생했고, 우리는 로그를 확인하고 원인을 분석하고 코드를 수정했습니다. 그리고 같은 문제가 다시 발생하지 않도록 테스트를 추가했습니다.

이 과정은 오래전부터 해오던 소프트웨어 엔지니어링입니다. AI가 코드를 만든다고 해서 이 원리가 달라지는 것은 아닙니다. 다만 코드 생성 속도가 훨씬 빨라졌기 때문에, 이제는 검증 방법도 그 속도에 맞춰 달라져야 하지 않을까 하는 생각이 듭니다. 특히 단순한 화면 오류와 다음과 같은 문제는 같은 수준으로 볼 수 없습니다.

• 다른 사용자의 데이터에 접근할 수 있는 권한 문제

• 비정상적인 입력을 이용한 공격

• 동일 요청이 여러 번 처리되는 문제

• 여러 요청이 동시에 들어왔을 때 발생하는 데이터 오류

• 결제나 정산 금액이 잘못 처리되는 문제

• 개발자가 전혀 생각하지 못했던 실행 순서

코드를 만드는 방법이 AI 시대에 맞게 바뀌고 있다면, 검증하는 방법 역시 같이 바뀌어야 합니다.

3. 테스트 자동화에도 AI를 붙여보자

예를 들어 회원 정보 수정 API를 하나 만들었다고 해보겠습니다. 보통은 다음과 같은 테스트를 생각할 수 있습니다. 사람이라면 몇 가지를 확인하고 넘어갈 수 있지만, AI에게는 여기서 훨씬 더 많은 변형 시나리오를 만들어보도록 할 수 있습니다.

그렇다고 별도의 거대한 테스트 시스템을 처음부터 만들어야 하는 것은 아닙니다. 이미 AI 코딩 도구는 프로젝트의 코드를 읽고, 명령을 실행하고, 테스트 결과와 오류 로그를 확인할 수 있습니다. 기존에 사용하던 JUnit 테스트를 실행하게 하고, 실패 결과를 분석한 뒤 새로운 테스트 케이스를 추가하도록 하는 것부터 시작할 수 있습니다. 웹 화면이라면 Playwright나 Selenium 같은 기존 브라우저 자동화 도구를 이용할 수 있고, 보안 검증에는 ZAP 같은 도구를 활용할 수 있습니다. 최근의 Playwright처럼 AI를 이용한 테스트 생성과 수정 기능 자체를 제공하는 도구도 등장하고 있습니다.

결국 새로운 테스트 도구를 처음부터 만드는 것이 아니라, 이미 사용하던 JUnit, Playwright, Selenium, ZAP 같은 도구의 앞뒤에 AI를 붙이는 것입니다. 코드 생성에서 이미 하고 있는 것처럼, 테스트에서도 시나리오를 만들고 → 실행하고 → 결과를 확인하고 → 부족한 테스트를 다시 추가하는 과정을 반복하게 하는 것입니다.

이것만으로도 개발자가 직접 생각하고 작성해야 했던 테스트의 상당 부분을 줄일 수 있을 것 같습니다. 하지만 여기서도 하나의 한계는 남습니다. 아무리 많은 테스트를 만들어도 결국 개발 단계에서 생각해낸 범위 안에서 움직이고 있다는 점입니다. 그렇다면 우리가 미처 생각하지 못한 문제는 어디에서 찾을 수 있을까요?

4. 운영에서 얻은 데이터를 테스트로 되돌릴 수 없을까?

아무리 테스트를 많이 해도 실제 운영에서는 예상하지 못했던 문제가 발생합니다. 이것도 새로운 이야기는 아닙니다. 기존에도 운영 로그와 모니터링 정보를 확인해 문제의 원인을 찾고, 수정한 뒤 같은 문제가 다시 발생하지 않도록 테스트를 추가해왔습니다.

예를 들어 운영 중 이런 문제가 발생했다고 해보겠습니다. 기존에는 개발자가 로그를 확인하고 원인을 찾아 수정했을 것입니다. AI를 이용하면 운영 기록에서 문제의 원인 후보와 재현 조건을 찾아내고, 이를 새로운 테스트로 만들어볼 수 있습니다. 그리고 실제 발생한 문제 하나에서 끝나는 것이 아니라, 비슷한 문제가 발생할 수 있는 다른 조건까지 확장해서 테스트를 만들어볼 수도 있습니다. 예를 들어 응답 지연 뒤 사용자가 다시 요청해서 문제가 발생했다면, 재시도가 여러 번 발생하는 경우나 여러 요청이 동시에 들어오는 경우까지 추가로 만들어보는 것입니다. 결국 중요한 것은 운영에서 얻은 경험을 한 번의 장애 처리로 끝내지 않고, 다음 테스트에 다시 반영하는 것입니다.

사실 이것 역시 완전히 새로운 방식은 아닙니다. 오래전부터 사용해오던 방식입니다. AI 시대라고 해서 기존의 소프트웨어 엔지니어링이 사라지는 것은 아닙니다. 오히려 기존 방식 위에 AI를 더해, 사람이 많이 하던 분석, 새로운 테스트 케이스를 생각하는 일, 운영에서 발견한 문제를 다시 테스트에 반영하는 일까지 조금씩 자동화해 나가는 것에 가깝습니다.

5. 거대한 솔루션이 있어야 시작할 수 있을까?

아직 제가 이 전체 구조를 직접 구현해본 것은 아닙니다. 그래서 구체적인 구현 방법을 단정적으로 이야기하기에는 공부해야 할 부분도 많습니다. 하지만, 필요한 기술의 상당 부분은 이미 존재합니다.

• Java 테스트에는 JUnit

• 브라우저 테스트 자동화에는 Selenium이나 Playwright

• 보안 테스트에는 ZAP

• 흐름을 연결하는 자동화 도구로 n8n

• 내부 코드나 운영 데이터를 외부로 보내기 어려운 경우에는 로컬 LLM

예를 들어 아주 단순하게는, 로컬 LLM이 테스트 시나리오를 만들고, JUnit이나 Playwright, Selenium, ZAP 같은 도구가 이를 실행합니다. 그 결과와 로그를 다시 AI가 분석해 새로운 테스트를 추가하는 흐름을 생각해볼 수 있습니다. 내부 코드나 운영 데이터를 외부로 보내기 어려운 환경이라면 이 AI를 로컬 LLM으로 구성할 수도 있습니다. n8n 같은 도구는 이 과정을 연결하는 역할을 할 수 있습니다.

예를 들어 아주 단순한 그림이라면 다음과 같습니다.

처음부터 거대한 시스템을 만들 필요는 없습니다. 지금 코드 생성에서 하고 있는 것처럼, 하나의 작업부터 AI에게 맡겨보고 효과가 있다면 조금씩 자동화 범위를 넓혀가면 됩니다.

마치며

요즘 많은 기업들이 AX(AI Transformation)를 이야기합니다. 하지만 고객의 업무와 시스템을 AI 중심으로 바꾸겠다고 하면서, 정작 그것을 만드는 우리의 개발 방식은 예전과 똑같다면 조금 이상하지 않을까요? AI를 이용해 코드를 만드는 것은 그 변화의 시작일 뿐이라고 생각합니다. 코드를 만드는 방식이 AI로 인해 바뀌었다면 테스트하는 방식도, 테스트 결과를 분석하는 방식도 AI를 이용해 바뀌어야 합니다.

물론 이 모든 것을 한꺼번에 바꿀 수는 없습니다. 하나씩 바꾸다 보면 결국 소프트웨어를 만드는 전 과정 자체가 AI 시대에 맞게 달라질 것입니다. 지금 중요한 것은 완벽한 코드를 한 번에 만드는 것이 아니라, 완벽하지 않은 소프트웨어의 문제를 더 빨리 발견하고, 더 빨리 검증하고, 그 경험을 다음 개발에 다시 반영할 수 있는 구조를 만드는 것이라고 생각합니다.

코드 생성에서 시작된 변화가 검증과 운영까지 하나씩 이어질 때, 비로소 개발 프로세스도 AX 시대로 들어가는 것이 아닐까요?

zacca