우리는 AI와 이렇게 개발합니다

안녕하세요.

AI 시대에 여러분은 AI를 어떻게 개발 활동에 활용하고 있으신가요?

궁금한 코드가 있을 때 AI에게 물어보기도 하고, 코드를 작성해 달라고 요청하기도 하고, 요즘은 Coding Agent에게 기능 하나를 통째로 맡기는 경우도 많아졌습니다.

저희도 처음에는 크게 다르지 않았습니다. 필요한 기능을 설명하고 AI에게 코드를 작성하게 하고, 결과를 확인하고, 문제가 있으면 다시 수정해 달라고 요청했습니다.

그런데 AI가 점점 더 많은 일을 할 수 있게 되면서 조금 다른 문제가 보이기 시작했습니다.

작업의 범위가 커지고 여러 파일을 수정하거나, 기존 구조를 파악하거나, 테스트를 수행하고 설정과 데이터베이스까지 다루기 시작하면 단순히 “이 기능을 만들어 주세요”라고 요청하는 것만으로는 부족했습니다.

AI가 요구사항을 다르게 이해하거나 예상보다 넓은 범위를 수정하기도 했습니다. 반대로 당연히 함께 변경될 것이라고 생각했던 부분을 빠뜨리는 경우도 있었습니다.

그래서 자연스럽게 AI에게 전달하는 정보가 많아졌습니다.

이 작업의 목적은 이것입니다.

이 부분은 수정하지 마세요.

현재 구조는 이렇게 되어 있습니다.

이 조건은 반드시 유지되어야 합니다.

작업이 끝나면 이 테스트를 수행해 주세요.

여기까지 진행되면 더 이상 진행하지 말고 결과를 알려주세요.

처음에는 이것도 결국 조금 긴 Prompt라고 생각할 수 있습니다. 그런데 계속 사용하다 보니 조금 다른 생각이 들었습니다.

사람과 AI가 함께 실제 개발을 하려면 둘 사이에도 일종의 작업 인터페이스가 필요한 것이 아닐까요?

사람끼리 일할 때도 단순히 “이것 좀 만들어 주세요”라고만 하지는 않습니다. 무엇을 만들 것인지 이야기하고, 문제를 검토하고, 범위를 결정하고, 필요한 경우 설계를 논의합니다. 실제 작업 뒤에는 결과를 확인하고 다음 일을 결정합니다.

AI와 함께 개발한다고 해서 이 과정이 사라지는 것은 아니었습니다. 오히려 AI가 더 많은 일을 직접 수행할수록 이런 과정이 더 중요해졌습니다.

하나의 AI에게 모든 것을 맡겨야 할까요?

또 하나 흥미로웠던 부분은 AI의 역할이었습니다.

저희는 하나의 AI에게 처음부터 끝까지 모든 것을 맡기는 것보다, 생각하고 결정하는 과정과 실제 작업을 수행하는 과정을 역할로 구분해서 사용하기 시작했습니다.

한쪽에서는 사람과 AI가 계속 대화합니다.

• 우리가 해결하려는 문제가 정확히 무엇인가요?
• 이렇게 변경하면 다른 부분에는 어떤 영향을 줄까요?
• 방법 A와 방법 B 중 어떤 것이 나을까요?
• 보안이나 운영 측면에서 예상되는 문제는 없을까요?
• 이번 작업에서는 어디까지 하는 것이 적절할까요?

이 과정에서는 바로 코드를 수정하지 않습니다. 사람과 AI가 충분히 이야기하면서 문제를 이해하고, 가능한 방법을 검토하고, 작업의 범위를 결정합니다.

어느 정도 결론이 나면 그 내용을 실제 작업을 수행할 AI에게 전달합니다. 저희는 이때 사용하는 문서를 작업지시서(Task Instruction)라고 부르기 시작했습니다.

작업지시서에는 왜 이 작업을 하는지, 어디까지 작업해야 하는지, 무엇을 변경하면 안 되는지, 반드시 유지해야 하는 조건과 검증 방법, 결과로 남겨야 할 것, 어떤 상황에서 멈추고 사람에게 판단을 넘겨야 하는지 등을 필요에 따라 함께 전달합니다.

그렇다고 모든 작업지시서를 거창하게 만들지는 않습니다. 작은 작업은 몇 줄이면 충분할 수 있습니다. 여러 시스템에 영향을 주거나 위험도가 높은 작업이라면 훨씬 더 명확한 조건이 필요합니다.

중요한 것은 문서의 길이가 아닙니다. 사람이 AI에게 실제 작업을 맡길 때 서로 무엇을 약속하고 있는지가 명확해야 한다는 것이었습니다.

작업이 끝났다고 정말 끝난 것일까요?

이렇게 작업을 맡기기 시작하니 또 다른 문제가 생겼습니다.

수정을 완료했습니다.

모든 테스트가 통과했습니다.

정상적으로 동작합니다.

물론 중요한 정보입니다. 하지만 프로젝트가 복잡해질수록 AI의 설명만 듣고 작업이 끝났다고 판단하기 어려웠습니다.

그래서 실제 테스트 결과, 변경된 파일, Git 상태, 데이터베이스 조회 결과, API 응답, 실행 로그 등 작업 결과를 확인할 수 있는 근거도 함께 남기도록 하기 시작했습니다. AI의 보고와 실제 확인 가능한 결과를 구분한 것입니다.

작업을 수행한 AI가 결과와 근거를 남기면 다시 사람과 AI가 그 내용을 검토합니다.

• 테스트는 통과했는데 우리가 원했던 방향이 맞나요?
• 요구사항을 잘못 이해한 부분은 없나요?
• 불필요하게 구조가 복잡해지지는 않았나요?
• 처음에 정했던 범위를 넘어선 변경은 없나요?
• 이제 다음 단계로 넘어가도 될까요?

문제가 발견되면 다시 논의합니다. 필요하면 기존 작업지시서를 수정하거나 새로운 작업지시서를 만들고 다시 작업합니다.

돌이켜보면 저희에게 중요했던 것은 AI에게 Prompt를 잘 작성하는 방법만은 아니었습니다.

AI와 어떻게 함께 생각할 것인지, 결정된 내용을 어떻게 실제 작업으로 전달할 것인지, AI가 수행한 일을 어떻게 확인할 것인지, 그리고 그 결과를 어떻게 다음 작업으로 이어갈 것인지가 더 큰 문제였습니다.

그래서 다시 SDLC를 생각해 보게 되었습니다

여기까지 오고 나니 한 가지 질문이 생겼습니다. 우리가 하고 있는 것이 단순히 기존 개발 방식에 AI Coding 도구 하나를 추가한 것일까요?

처음에는 그렇게 생각했습니다. 하지만 AI가 코드를 작성하는 것을 넘어 repository를 조사하고, 테스트하고, 실제 환경을 변경하고, 결과를 남기고, 다시 다음 작업으로 이어지는 과정까지 참여한다면 이야기가 조금 달라집니다.

AI가 개발 과정에 참여한다는 것을 전제로 Software Development Lifecycle 자체를 다시 구성해야 하는 것은 아닐까요?

저희는 이런 관점에서 AI Native SDLC라는 개념을 생각하고 있습니다.

거창한 새로운 표준을 선언하려는 것은 아닙니다. AI를 실제 개발에 계속 사용하면서 겪었던 시행착오와, 그 문제를 해결하기 위해 하나씩 만들어 온 방법들을 정리해 보려는 것입니다.

다른 개발자들이 AI Coding Agent를 사용하는 모습을 살펴보면 이름은 조금씩 다르지만 SPEC.md, PLAN.md, TASK.md, project rules, acceptance criteria 같은 artifact를 사용하는 경우를 볼 수 있습니다.

왜 서로 다른 사람들이 비슷한 방향으로 가고 있을까요?

어쩌면 AI가 더 많은 일을 할 수 있게 될수록 AI에게 단순히 무엇을 할지 알려주는 것보다 어떤 맥락에서, 어디까지, 어떤 조건으로 일을 맡길 것인지를 명확하게 만드는 일이 중요해지고 있기 때문인지도 모릅니다.

저희가 생각하는 AI Native SDLC는 “AI가 코드를 대신 작성하는 방법”에서 시작하지 않습니다. 조금 더 근본적인 질문에서 시작합니다.

AI가 실제 개발의 한 참여자가 된다면, 사람과 AI는 어떤 방식으로 함께 Software Engineering을 해야 할까요?