PHP를 다뤄본 적 없는 제가, AI와 함께 PHP 앱을 만들기 전에 생각하고 있는 인간의 책무

생성 AI(Generative AI)의 진화로 인해, 이전에는 접해 본 적 없던 언어나 프레임워크를 사용해서 애플리케이션을 형태 있게 만들기가 쉬워졌습니다. 평소에는 C#이나 Azure를 중심으로 개발하고 있는 저도 GitHub Copilot과 함께 PHP 애플리케이션을 만들어 보려고 합니다.

계기는 'AI가 코드를 작성하고, AI가 리뷰하는 시대에 인간의 일은 무엇이 될까'라는 의문입니다. 코드 작성 부분을 AI에게 맡길 수 있다면, 개발자는 더 이상 언어를 배울 필요가 없을까요? AI가 자신의 코드를 리뷰해 준다면, 사람에 의한 리뷰는 불필요한 것일까요?

먼저 말씀드리자면, 이 글을 쓰고 있는 시점에서는 PHP 앱 개발이 이제부터입니다. 발표에서는 실제로 앱을 만들고, 구현 및 리뷰, 개선의 과정을 검증할 예정이지만, 여기에 적은 내용은 그 실전을 마친 후의 경험담은 아닙니다. PHP Conference Kansai에 제출한 프로포저(proposal)를 출발점으로 삼아, 슬라이드를 작성하기 전에 '무엇을 확인하고 싶은지', '어떤 관점에서 개발을 되돌아볼 것인지'를 정리하는 시나리오입니다.

이 글에서는 실제로 일어난 듯한 성공 사례나 실패 사례를 미리 쓰는 것이 아니라, 앞으로의 개발에서 관찰하고 싶은 것을 생각합니다. 요구사항 정의(Requirement Definition), 품질 보증(Quality Assurance), 접근성(Accessibility), 보안(Security), 설계 판단이라는 관점을 통해, AI에게 맡길 업무와 인간이 판단 및 책임을 지는 업무의 경계를 탐색해 보고자 합니다.

저는 평소 C#이나 Azure를 중심으로 다루고 있어 PHP 개발 경험은 거의 없습니다. 이번에 굳이 익숙하지 않은 언어를 선택한 것은, AI의 도움을 받아 구현한다면 미지의 언어라도 애플리케이션을 만들 수 있는지 시험해 보고 싶기 때문입니다.

또 하나 확인하고 싶은 것이 있습니다. AI가 코드를 작성해 줄 때, 저는 그 코드를 어떤 근거로 받아들이거나 수정 요청을 하게 될까요? 익숙한 언어라면 평소의 방식이나 기존 설계를 단서 삼아 판단할 수 있는 순간이 있습니다. 모르는 언어에서는 그런 안정감을 그대로 사용할 수 없습니다.

하지만 개발에서 결정해야 할 것은 구문(Syntax)만이 아닙니다. 무엇을 만들 것인지, 누가 사용할 것인지, 무엇을 충족하면 완성으로 볼 것인지. 이것들은 PHP의 문법을 외운다고 해서 자동으로 결정되는 것이 아닙니다. AI가 구문이나 구현안을 보조할 수 있어도, 애플리케이션의 목적이나 제약은 별도로 생각해야 합니다.

PHP를 선택한 것은 언어 학습 그 자체를 목적으로 삼기 위함이 아닙니다. 미경험의 기술에 직면하면서, 언어 지식과 개발자의 책무를 분리하여 생각하기 위해서입니다. 개발 후에 되돌아볼 때도 'AI가 PHP 코드를 작성했는지'뿐만 아니라, '그 코드가 목적에 부합한다고 저는 어떻게 확인했는지'를 질문하고 싶습니다.

AI에게 코드 생성을 요청하려면, 먼저 의뢰를 전달해야 합니다. 하지만 단순히 '애플리케이션을 만들어 주세요'라고 의뢰하는 것만으로는 완성된 상태를 정할 수 없습니다. AI는 작동하는 코드를 제안할 수는 있지만, 무엇을 해결하기 위한 앱인지, 누구에게 사용하기 쉬운지 등을 저 대신 결정해 줄 수는 없습니다.

예를 들어, 폼(form)이 있는 앱을 만든다고 가정해 봅시다. 화면에 입력란과 전송 버튼이 있고, 전송 후에 결과가 표시되면 일단 기능은 된 것처럼 보일 수 있습니다. 하지만 입력에 오류가 있을 때 무엇을 알려줘야 하는지, 입력 내용이 유실되지 않는지, 키보드만으로 조작할 수 있는지, 의도하지 않은 데이터를 받지 않는지 같은 조건들도 고려해야 합니다.

이는 특정 PHP 기능에 대한 이야기가 아닙니다. 요구사항으로 전달되지 않은 조건은 코드에도 테스트에도 반영되기 어렵습니다. AI가 구현을 빠르게 진행할수록, 모호한 요구사항 그대로 만들기 시작했을 때 무엇을 기준으로 결과를 평가할 수 있을지 가려지기 쉽습니다.

따라서 개발을 시작하기 전에, 적어도 목적(Purpose), 사용자(User), 기대하는 동작(Expected Behavior), 제약(Constraint), 수용 조건(Acceptance Criteria)을 정리해 두고 싶습니다. 모든 구현 방법을 미리 결정하는 것이 아니라, 무엇을 해결하고 싶은지, 어떤 상태를 성공으로 할 것인지를 명확히 하는 것입니다. 거기서부터 비로소 AI의 제안을 목적에 비추어 확인할 수 있습니다.

익숙하지 않은 언어로 개발하면서, AI에게는 구문이나 작성 방식 설명, 구현 후보, 오류 원인 조사, 테스트 및 개선 관점 도출 등을 도움받을 생각입니다. 인간 혼자 진행할 경우, 조사부터 시작하는 단계에서 다음에 시도해 볼 안(案)을 얻는 것은 큰 도움이 될 것입니다.

다만, 제안을 받아낼 수 있는 것과 그 제안을 채택할지 판단하는 것을 맡길 수 있는 것은 별개입니다. AI가 제시한 코드가 PHP 문법적으로 성립하더라도, 애플리케이션의 요구사항에 맞는다고는 할 수 없습니다. 실행 가능한 것, 안전한 것, 사용자에게 이해하기 쉬운 것, 그리고 미래 변경에 견딜 수 있는 것 또한 각각 다른 확인 과정입니다.

개발을 시작하기 전에 생각하고 있는 역할 분담을 다음과 같이 정리했습니다. 이는 실전 후의 평가가 아니라, 개발 중에 검증해 볼 가설입니다.

'AI가 코드를 작성하고, AI가 리뷰하는' 흐름은 자연스럽게 느껴질 수 있습니다. 작성자 외에 별도로 리뷰를 요청하여 문제점을 지적받으면, 확인이 완료된 것처럼 보일 때도 있습니다. 앞으로 AI에게 리뷰를 요청할 때는, 결과를 그대로 채택하기보다 그 지적을 어떻게 다룰지 관찰하고 싶습니다.

리뷰의 지적이 타당한지 판단하려면, 애초에 무엇을 충족해야 하는지를 알아야 합니다. AI가 개선안을 제안해도, 그 변경이 요구사항을 충족하는 데 필요한 것인지, 다른 문제를 야기하지는 않는지는 애플리케이션의 목적과 사용자를 바탕으로 판단해야 합니다.

테스트도 마찬가지입니다. 테스트가 성공했다는 결과는, 실행한 테스트가 확인한 범위 내에서 문제가 발견되지 않았음을 의미합니다. 그렇다면 그 테스트가 필요한 동작을 확실히 하고 있는 걸까요? 실패할 조건이나 사용자에게 중요한 조작을 포함하고 있을까요? 구현 후에, 테스트 결과뿐만 아니라 테스트 범위를 어떻게 정했는지도 되돌아볼 생각입니다.

AI의 리뷰를 놓친 부분을 줄이고 생각할 계기를 늘리는 데 사용할 수 있는지 여부는 실제로 시도해 보고 확인하고 싶은 부분입니다. 반면에, 리뷰를 받았다는 사실 자체를 품질의 증명으로 대체할 수는 없습니다. 코드와 테스트의 의미를 이해하고, 무엇이 확인되었고 무엇이 미확인인지 설명할 수 있는 상태로 만드는 것. 그 책임은 변경을 받아들이는 인간에게 남는다고 생각합니다.

애플리케이션의 품질을 생각할 때, 화면이 표시되고 주요 조작이 가능하다는 것으로 끝내고 싶지 않습니다. 사용자가 어떤 환경에서, 어떤 조작 방식을 사용하고 있는지에 따라 같은 화면이라도 사용성은 달라집니다.

예를 들어, 마우스로 조작하는 것과 키보드만으로 동일한 기능에 도달할 수 있는 것은 같지 않습니다. 입력 오류를 표시하는 것과 어느 항목에 무엇이 문제인지 사용자가 이해할 수 있게 하는 것도 같지 않습니다. 이것들은 이번 앱에서 확인된 결과가 아니라, 개발 시 생각해 보고 싶은 예시입니다.

AI에게 확인 항목이나 구현안을 내보게 할 수는 있을 것입니다. 그럼에도 불구하고, 어떤 사용자의 어떤 어려움을 해소하고 싶은지, 어떤 상태를 확실히 해야 하는지를 결정하기 위해서는 요구사항과 이용의 맥락이 필요합니다. AI에게 '접근성(accessibility)'에 대응하도록 요청하는 것에서 그치지 않고, 확인하고 싶은 사용자 경험을 인간이 정하고 구현 후에 실제 조작으로 확인하고 싶습니다.

발표할 때도, 단순히 '대응을 요청했다'는 사실뿐만 아니라, 어떤 관점을 어떻게 검증했고 어디는 미확인으로 남았는지 나누어 전달하고 싶습니다. 자동화된 범위와 인간이 확인할 필요가 있는 범위를 구별하는 것이 품질을 성실하게 공유하기 위해 필요합니다.

보안(security)에 대해서도, AI에게 리뷰를 요청한다고 해서 모든 위험이 사라지는 것은 아닙니다. 코드의 일부에 알려진 문제가 없는지 묻거나, 입력이나 권한 처리를 확인하는 것은 유용하다고 생각됩니다. 반면, 무엇을 보호해야 하는지, 어떤 데이터를 다루는지, 누가 어떤 조작을 허용되는지가 모호한 상태라면, 지적의 타당성을 평가하는 것도 어려워집니다.

예를 들어, 같은 입력란이라도 받는 내용이나 저장소, 사용자의 권한에 따라 확인해야 할 것은 달라집니다. 범용적인 체크 항목을 실행하는 것과 그 애플리케이션 고유의 위험을 이해하는 것은 별개입니다. 실제로 무엇을 다룰지 결정한 후에, 어떤 위험이 관련되는지를洗い出す(도출해 내야) 필요가 있습니다.

개발 후에 확인하고 싶은 것은, AI가 몇 건 지적했는지에만 그치지 않습니다. 어떤 전제에 기반하여 확인했는지, 어디까지 확신할 수 있었는지, 남은 리스크를 어떻게 다룰 것인지입니다. AI의 지적이 적다는 것을 안전의 근거로 삼지 않고, 이용과 데이터에 대한 책임으로서 보안을 생각하고 싶습니다.

AI는 여러 구현 방법을 제안할 수 있습니다. 후보들을 비교하고, 각각의 장점이나 주의점을 설명해 준다면, 저 혼자서는 발견하지 못했던 선택지에 마주칠 수도 있을 것입니다.

다만, 선택지들을 나열하는 것과 하나를 고르는 것은 별개의 작업입니다. 현재 요구사항을 충족하는지 여부뿐 아니라, 나중에 사양을 변경하기 쉬운지, 다른 사람이 이해할 수 있는지, 문제가 생겼을 때 조사해 볼 수 있는지 같은 조건들을 고려해야 합니다. 어떤 조건을 우선순위로 둘지는 애플리케이션의 목적이나 규모, 개발 및 운영하는 사람들에 따라 달라집니다.

익숙한 언어라면 기존 설계나 팀의 관습에 비추어 판단하기 쉬울 수도 있습니다. 경험이 없는 언어에서는 그 전제를 바로 활용할 수 없는 경우가 있습니다. 그렇기 때문에 AI의 설명을 읽은 후, 제가 무엇을 이해했고 무엇이 아직 확실하지 않은지 구분하고 싶습니다.

AI에게 구현안을 생각하게 하는 것과 그 안을 채택하는 것은 별개의 단계입니다. 개발 시에는 미래의 변경이나 유지보수까지 고려했을 때, 어떤 선택지를 고르고 왜 그렇게 결정했는지를 기록해 두고 싶습니다. 설계 판단에 필요한 정보를 AI로부터 얻을 수 있는지뿐만 아니라, 마지막으로 판단하기 위한 지식이나 확인 과정도 되돌아볼 예정입니다.

PHP를 사용하면 C#와는 구문도 관습도 다릅니다. 새로운 환경에 익숙해지기 위한 학습은 필요합니다. AI는 그 학습을 돕거나, 작성하기까지의 진입 장벽을 낮춰줄 것입니다.

하지만 언어가 바뀌어도 개발자가 답해야 할 질문은 남아 있습니다. 왜 이 앱을 만드는가? 누가 사용할 것인가? 무엇을 기준으로 정상 작동한다고 판단할 것인가? 어떤 리스크를 허용할 것인가? 변경 후에 무슨 일이 일어날지 어떻게 확인할 것인가?

이 질문들에 대한 대답은 PHP나 C#의 구문 속에 있지 않습니다. 언어나 프레임워크는 목적을 실현하기 위한 수단일 뿐입니다. AI에 의해 미지의 수단을 다루기 쉬워진다 해도, 목적을 정하고 결과를 평가하며 채택한 변경에 책임을 질 필요가 없어지지 않는다는 것이 현재 저의 가설입니다.

개발 전 단계에서 결론을 미리 내리지 않고, 구현·리뷰·개선을 진행하면서 이 가설을 확인해 보고 싶습니다. PHP 지식이 어느 정도 필요했었는지, AI의 설명만으로는 판단할 수 없었던 장면이 있었는지, 인간의 판단이 결과에 어떻게 영향을 미쳤는지를 말입니다. 실제로 일어난 것과 사전에 생각했던 것을 나누어 기록할 생각입니다.

제안서에서는 구현, 리뷰, 개선 과정을 통해 AI 단독으로 해결한 것, AI가 어려워했던 것, 인간의 판단이 필요했던 것을 공유한다고 썼습니다. 슬라이드로 만들기 전에, 개발 중에는 다음 세 가지 질문을 기록하고 싶습니다.

• 무엇을 AI에게 맡겼는가 — 구문 설명, 구현 후보, 리뷰, 개선안 등 어떤 요청을 했고 어디서 도움이 되었는지.
• 무엇을 확인했는가 — 생성된 코드나 테스트에 대해 목적에 맞다고 판단하기 위해 어떤 근거를 모았는지.
• 무엇을 인간이 결정했는가 — 요구사항, 품질, 접근성(accessibility), 보안, 설계 중 어떤 판단을 인간이 책임졌는지.

각 항목에 대해 잘된 점뿐만 아니라, AI의 제안을 채택하지 않은 이유나 확인하지 못한 범위도 기록할 것입니다. 구체적인 예시와 평가를 분리해 두면, 나중에 이야기를 구성할 때 인상만으로 AI의 능력이나 한계를 단정하는 것을 피할 수 있습니다.

PHP는 이 이야기의 입구일 뿐입니다. 청중에게 가져가게 하고 싶은 것은 PHP 작성법뿐만이 아니라, 자신이 평소 사용하는 언어나 AI 개발 상황에서도 무엇을 맡기고, 무엇을 확인하며, 무엇에 책임을 질 것인지 질문하는 시점입니다.

이 글을 쓰고 있는 지금 시점에서, PHP 앱의 개발은 이제부터입니다. 따라서 여기에 쓴 내용은 구현이나 검증의 결과가 아니라, 앞으로 확인하고 싶은 질문과 가설입니다.

AI는 익숙하지 않은 언어로 개발을 시작할 때 강력한 도움이 될 것이라 기대합니다. 코드 후보를 얻거나, 리뷰 시점을 늘리거나, 개선의 계기를 얻을 수 있을 것입니다. 반면에 요구사항을 결정하는 것, 품질을 측정 기준을 마련하는 것, 사용자에게 미치는 영향이나 보안상의 리스크를 생각하는 것, 설계의 트레이드오프(trade-off)를 선택하는 것은 AI의 제안만으로는 완료되지 않는다고 생각합니다.

언어가 바뀌어도 무엇을 AI에게 맡기고, 무엇을 인간이 맡길 수 없다고 판단할지. 그 판단의 축은 변하지 않을 것이 아닐까요. 앞으로의 개발을 통해 그 생각이 어디까지 확인될 수 있을지 지켜보겠습니다.

슬라이드를 만들 때는 사전에 세운 가설뿐만 아니라, 실제로 발생한 일, 확인된 것, 그리고 끝까지 알 수 없었던 것을 나누어 공유하고 싶습니다. AI 시대에 인간이 짊어져야 할 책무에 대해 PHP 앱을 만드는 과정을 통해 생각해 보겠습니다🧭