생성형 개발 도구로 학습 관리 시스템을 만들었지만 수강 신청부터 수료 판정까지의 운영 조건은 별도로 확인해야 했습니다. 바이오 파운드리 양성 LMS M사에서 실제 동작을 기준으로 누락된 요구사항과 예외 경로를 검증한 사례입니다.
수강 화면이 있고 신청 버튼이 동작합니다. 학습한 내용이 표시되고 수료 여부도 보여줍니다. 필요한 기능은 만들어졌는데, 이 상태로 교육 과정을 운영해도 될까요?
바이오 파운드리 양성 과정을 위한 LMS M사는 생성형 도구로 구축한 시스템이었습니다. 요청한 기능은 실행할 수 있었지만 명시하지 않았던 조건과 예외가 어디까지 반영됐는지는 정리되지 않은 상태였습니다.
2026년에 진행한 검증에서는 코드가 만들어진 방식보다 실제 교육 업무의 결과를 기준으로 삼았습니다. “기능이 있다”와 “필요한 조건에서 올바르게 동작한다”를 구분하는 것이 출발점이었습니다.
코드에 대한 인상 대신, 실행 결과를 기준으로 삼았습니다
AI가 작성한 코드라는 이유만으로 결과물을 낮게 평가할 필요는 없습니다. 반대로 코드를 빠르게 만들었다는 사실이 운영 준비를 증명해 주지도 않습니다.
착수 전에 검증 기준을 합의했습니다. 코드의 스타일이나 작성 방식을 평가하는 대신, 시스템을 실행해 확인한 동작으로 판단하기로 했습니다.
이 접근은 책임을 코드에서 사용자 경험으로 옮기는 일이기도 합니다. 내부 구현이 어떤 형태든 교육 운영자가 필요로 하는 조건을 충족해야 합니다. 코드에 처리하는 문장이 있다는 설명보다 그 조건에서 실제로 어떤 결과가 나오는지가 중요했습니다.
생성형 개발 도구를 활용한 시스템을 검증할 때도 이 기준은 같습니다. 도구가 무엇을 만들었는지보다 조직이 무엇을 운영하려는지를 먼저 설명할 수 있어야 합니다.
수강 신청부터 수료까지, 흐름으로 묶었습니다
핵심 검증 흐름은 수강 신청, 진도 인정, 수료 판정이었습니다. 각각의 화면만 확인하기보다 학습자가 교육 과정에 참여하고 결과를 얻는 흐름으로 살폈습니다.
이 세 단계는 서로 연결되어 있습니다. 신청한 사용자가 누구인지, 어떤 학습이 진도로 인정되는지, 그 결과가 수료 조건과 어떻게 이어지는지에 따라 운영 결과가 달라집니다.
예를 들어 진도가 화면에 표시된다는 사실만으로 수료 판정도 맞다고 할 수는 없습니다. 표시된 진도와 수료를 판단하는 조건이 같은 기준을 따르는지를 별도로 확인해야 합니다. 특정 오류를 발견했다는 뜻은 아닙니다. 기능 목록만으로 검증 범위를 정하면 이런 관계를 놓치기 쉽습니다.
프로젝트에서는 이런 핵심 흐름을 시나리오로 실행하고 결과를 남겼습니다. 기능이 있는지 확인하는 데서 멈추지 않고 합의한 동작이 실제로 나오는지까지 확인하는 방식이었습니다.
정원 초과와 중도 이탈도 운영 시나리오에 넣었습니다
정상적인 신청과 학습 완료만으로는 교육 운영을 충분히 설명하기 어렵습니다. 신청 정원이 차거나, 학습을 끝내지 않은 사용자가 생기거나, 권한이 다른 사람이 접근할 수 있습니다.
검증에는 정원 초과, 중도 이탈, 사용자 권한 차이에 따른 접근 조건을 포함했습니다. 처음 요청한 기능의 정상 경로 밖에서도 시스템이 어떤 결과를 내는지 확인한 것입니다.
예외 조건은 드물게 일어나는 일을 모두 상상해 넣는 작업과 다릅니다. 서비스가 실제로 운영할 규칙을 확인하는 일입니다. 정원과 수료, 권한은 화면 바깥의 운영 정책처럼 보이지만 시스템의 결과를 바꾸는 조건입니다.
이런 조건이 구현 과정에서 명시되지 않았다면 개발 도구가 조직의 의도를 대신 알 수는 없습니다. 검증에서 조건을 구체화하는 과정은 누락된 요구사항을 찾는 과정과도 연결됩니다.
설명과 실행이 다르면, 실행 결과를 다시 살폈습니다
코드에 특정 처리가 들어 있다는 설명과 실행 결과가 어긋날 수 있습니다. 이때 설명을 그대로 받아들이면 이미 동작한다고 가정한 상태로 검증을 끝낼 위험이 있습니다.
프로젝트에서는 합의한 조건에서 실행한 결과를 판단의 기준으로 두었습니다. 기대한 동작과 다르면 요구사항의 누락이나 보완이 필요한 지점으로 정리했습니다.
단순히 이상한 화면을 모으는 것이 아니라, 어느 조건에서 어떤 결과가 나왔는지 시나리오 단위로 기록했습니다. 수정 담당자가 다시 확인할 수 있고 운영 담당자도 어떤 규칙을 정해야 하는지 이해할 수 있는 형태가 필요했습니다.
이 기록은 생성형 개발 도구를 사용한 사람에게도 유용합니다. 다음 수정 요청을 “이상하니 고쳐 달라”가 아니라 “이 조건에서 이 결과가 필요하다”로 구체화할 수 있기 때문입니다.
납품한 것은 출시를 검토할 수 있는 근거였습니다
검증을 통해 누락된 요구사항과 추가 확인이 필요한 영역을 정리했습니다. 실행한 시나리오의 결과와 확인하지 못한 범위를 함께 남겼습니다.
모든 검증 항목이 준비되어 있지 않은 상태에서 출시 여부를 단정하기보다, 판단에 필요한 사실을 모으는 것이 중요했습니다. 어떤 흐름을 확인했고 어떤 조건은 더 살펴야 하는지 드러나면 다음 작업도 구체적으로 정할 수 있습니다.
기존 시스템을 검증한 결과는 보완할 요구사항과 다음 확인 범위로 이어졌습니다. 이후의 수정과 출시 결정은 이 기록을 바탕으로 별도로 진행해야 할 단계입니다.
개발이 빨라질수록 만들어진 결과가 업무의 조건을 충족하는지 확인하는 과정은 더 선명해야 합니다. M사에서는 실행 가능한 코드와 운영 가능한 교육 시스템 사이에 무엇이 남아 있는지를 기록으로 드러냈습니다.
