AI 에이전트(Codex)를 이용해 Amazon Rekognition으로 사진을 분석하는 iOS 앱을 개발했습니다.

필자 자신은 코드를 작성하지 않았습니다.

한편, 개발 중에는 AWS와 GitHub 인증, 터미널 조작, 실기기 검증, 사양 판단을 수행했습니다. 따라서 단순히 자연어로 지시만 내렸다고 해서 완성된 것은 아닙니다.

본고에서는 개발 경위와 역할 분담을 정리하고, AI 에이전트를 초보자의 학습에 이용할 때의 이점과 과제를 고찰합니다.

기술 구성과 구현 상세는 다음 기사에서 소개하고 있습니다.

소스 코드는 GitHub에 공개되어 있습니다.

참고로, 이번 앱은 App Store에서 배포하지 않았습니다. 목적이 "AI 에이전트를 사용해 보는 것"이었기에, Xcode에서 자신의 단말로 설치하여 사용하는 개발용 앱에 머물렀습니다.

필자는 Web 앱 개발 경험이 있으며, 다음 주제로 iOS 앱을 만들고 싶어 했습니다. 또한, 업무에서 AWS를 이용하고는 있지만 AI 관련 서비스를 다룰 기회는 없었습니다.

이에 따라 다음 3가지를 목적으로 소규모 앱 개발을 시작했습니다.

• iOS 앱 개발을 경험하기
• AWS의 AI 서비스를 실제로 이용하기
• AI 에이전트를 이용한 개발 방법을 검증하기

SwiftUI, iOS 앱 개발, Amazon Rekognition에 대해서는 초보자입니다. 사전 학습을 마친 뒤 개발하는 것이 아니라, 먼저 동작하는 것을 만들고 그 결과물을 교재로 삼아 이해를 심화하는 방침을 채택했습니다.

개발한 것은 iPhone에서 선택하거나 촬영한 사진을 Amazon Rekognition으로 분석하여, 검출된 라벨(Label)과 신뢰도(Confidence)를 표시하는 앱입니다.

주요 기능은 다음과 같습니다.

• 사진 라이브러리에서 이미지 선택
• 카메라를 통한 촬영
• 이미지 축소 및 압축
• Amazon Rekognition을 통한 라벨 검출
• 분석 결과 표시
• SwiftData를 이용한 이력 저장

백엔드에는 API Gateway, Lambda, S3, Amazon Rekognition을 사용하였으며, AWS SAM으로 구축했습니다.

이번에 Swift, JavaScript, YAML 등의 코드는 AI 에이전트가 작성했습니다.

설계, 구현, 테스트, 빌드, 문서 정비도 AI 에이전트가 담당했습니다.

필자가 수행한 작업은 다음과 같습니다.

• 개발 목적과 요구사항 제시
• 터미널에서의 커맨드 실행
• AWS와 GitHub 인증
• IAM 권한 설정
• Xcode와 실기기를 이용한 동작 확인
• 에러 내용과 스크린샷 공유
• 디자인과 사양에 관한 판단
• 공개 범위 결정

따라서 "코드를 작성하지 않았다"는 것과 "개발에 관여하지 않았다"는 것은 동의어가 아닙니다. 구현 작업은 AI 에이전트가 담당했고, 인간은 목적 설정, 권한 허가, 동작 평가, 사양 결정을 담당했습니다.

이용 전에는 터미널 조작에 더해, 생성된 코드를 어느 정도 읽어야 개발을 진행할 수 있을 것이라고 예상했습니다.

실제로는 필요한 인증을 수행한 후, AI 에이전트가 넓은 범위의 작업을 지속적으로 처리했습니다.

구체적으로 AWS 측에서는 SAM 템플릿과 Lambda 함수를 작성하여 API Gateway, Lambda, S3, Rekognition 등을 이용하는 환경을 구축했습니다. GitHub에서는 인증 후 리포지토리(Repository)를 생성하고, README 정비, 비밀 정보 확인, 코드 공개를 수행했습니다.

앱에 대해서도 구현뿐만 아니라 빌드까지 실행되었습니다. 필자는 빌드된 앱을 실기기에서 조작하고, 문제가 있으면 결과를 AI 에이전트에게 보고했습니다.

코드의 단편을 제시하는 것뿐만 아니라, 구현부터 검증까지를 하나의 작업으로서 지속했다는 점이 기존의 대화형 AI와의 큰 차이점이었습니다.

개발은 다음 절차를 반복하며 진행했습니다.

요구사항을 전달한다
↓
AI 에이전트가 설계·구현한다
...

예를 들어, 분석 버튼을 눌렀을 때 API 접속처가 설정되지 않았다는 에러가 표시되었습니다. 에러 내용을 공유하자 AI 에이전트는 Xcode 설정과 Info.plist를 조사하여, API URL을 앱에서 참조할 수 있도록 수정했습니다.

AWS 배포에서도 IAM 권한 부족이나 AWS Budgets의 통화 설정으로 인한 에러가 발생했습니다. 이 경우에도 터미널 출력을 공유하여 원인 특정과 수정을 진행했습니다.

초보자가 에러의 원인을 미리 이해하지 못하더라도, 발생한 현상을 정확하게 공유함으로써 조사를 시작할 수 있다는 점은 유용했습니다.

AI 에이전트가 구현을 담당하더라도, 채택할 기능이나 품질 기준을 자동으로 결정할 수 있는 것은 아닙니다.

처음에 생성된 앱 아이콘에 대해 요소와 색상을 줄인 간결한 디자인을 지정했습니다. 완성된 것을 확인하고 구체적인 수정 방침을 전달함으로써 조정할 수 있었습니다.

첫 지시만으로 완성형을 정확하게 정의할 필요는 없었으며, 출력을 평가하면서 단계적으로 개선할 수 있었습니다.

당초에는 Rekognition이 반환하는 영어 라벨을 단말기 내 사전으로 일본어화했습니다. 하지만 사전에 존재하지 않는 단어가 영어로 남아 표시의 일관성을 확보할 수 없었습니다.

이 기능은 구현상으로는 동작하고 있었지만, 이용 시의 품질이 충분하지 않다고 판단하여 영어 표시로 되돌렸습니다.

구현 가능하다는 것이 채택해야 함을 의미하지는 않습니다. 최종적인 사양에는 실제로 이용한 인간에 의한 평가가 필요했습니다.

AI 에이전트를 이용하면 추가 기능을 짧은 시간 내에 구현할 수 있습니다. 반면, 기능의 증가에 비례하여 인간이 확인하고 이해해야 할 범위도 확대됩니다.

이번에는 "Amazon Rekognition을 이용한 이미지 해석을 경험한다"라는 당초의 목적에서 벗어나지 않도록 기능을 한정했습니다.

AI에 의해 구현 속도가 높아지더라도 인간의 이해가 같은 속도로 진행된다는 보장은 없습니다. 학습 목적의 개발에서는 구현 가능한 범위가 아니라, 자신이 검증하고 이해할 수 있는 범위를 기준으로 규모를 결정할 필요가 있습니다.

이번에 가장 판단하기 어려웠던 것은 AWS의 권한과 인증 정보의 취급입니다.

AI 에이전트에게 어디까지 권한을 주어도 되는지, API 키나 액세스 키를 어디서 관리해야 하는지에 대해 초학자가 독력으로 안전성을 판단하는 것은 어렵습니다.

이번에는 일반 공개하는 앱이 아니라 자신의 개발 환경에서 사용하는 앱입니다.

그럼에도 AWS 상에는 실제 리소스가 생성되기 때문에, 인증 정보의 유출이나 예상치 못한 요금을 고려할 필요가 있었습니다.

이번 구성에서는 다음과 같은 대책을 실시했습니다.

• AWS 액세스 키를 iOS 앱에 내장하지 않음
• S3 버킷을 비공개로 설정
• 임시 이미지를 S3 Lifecycle로 삭제
• Lambda마다 필요한 IAM 권한을 한정
• 환경 고유의 API URL을 GitHub에 등록하지 않음
• 공개 전에 비밀 정보가 포함되어 있지 않은지 확인
• AWS Budgets로 요금 알림을 설정
• API Gateway에 스로틀링 (Throttling)을 설정

AI 에이전트가 안전 대책을 제안·구현할 수 있어도, 권한을 허가하는 주체는 인간입니다.

AI 에이전트의 실행 범위가 넓어질수록 부여하는 권한의 목적과 범위를 확인할 필요성도 높아집니다.

불명확한 권한을 요구받을 경우에는 목적, 대상 리소스, 작업 후에 삭제할 수 있는지를 확인해야 한다고 생각했습니다.

앱은 완성되었지만, 필자가 SwiftUI, AWS SAM, Lambda, Presigned URL 등을 충분히 이해한 것은 아닙니다.

코드를 기술하지 않고 동작하는 성과물을 얻을 수 있는 것은 AI 에이전트의 이점입니다.

반면, 성과물의 완성을 기술 습득과 동일시할 수는 없습니다.

다만, 자신의 요구 사항에 기반하여 만들어지고 실제로 조작한 앱은 그 이후의 학습 교재가 될 수 있습니다. 일반적인 샘플 코드와 달리 각 기능이 추가된 경위나 발생한 에러를 파악하고 있기 때문에, 코드를 읽는 목적을 갖기 쉬워집니다.

기존에는 학습한 후 성과물을 만드는 순서를 상정했습니다.

학습한다
↓
이해한다
...

이번에 채택한 순서는 다릅니다.

성과물을 만든다
↓
동작과 구성을 확인한다
...

먼저 성과물이 존재함으로써 학습 대상이 구체적이 됩니다. 또한 불명확한 코드나 구성에 대해 그 자리에서 작성자인 AI 에이전트에게 질문할 수 있습니다.

학습이 진행된 후 관련 기능을 추가하면 성과물을 지속적인 교재로 이용할 수 있습니다.

코드를 기술하지 않은 성과물을 "내가 만들었다"라고 표현해도 될지는 신중하게 생각할 필요가 있습니다.

이번에 구현의 대부분은 AI 에이전트가 담당했습니다. 반면 필자는 목적, 요구 사항, 공개 범위, 품질 기준을 결정하고 실기 상에서 동작을 평가했습니다.

인간이 담당한 판단에는 다음이 포함됩니다.

• 무엇을 만들 것인가
• 어떤 기능을 채택할 것인가
• 어떤 기능을 철회할 것인가
• 어떤 권한을 허가할 것인가
• 어느 범위까지 공개할 것인가
• 어떤 상태를 완성으로 볼 것인가

이 역할 분담을 고려하면 "AI만 만들었다" 또는 "인간만 만들었다" 중 어느 쪽도 아닙니다.

"AI 에이전트와 공동으로 개발했다"라는 표현이 실태에 가깝다고 생각합니다.

중요한 것은 AI 이용을 숨기는 것이 아니라, 어떤 작업을 AI가 담당하고 어떤 판단을 인간이 담당했는지를 명확히 하는 것입니다.

이번 경험을 통해 AI 에이전트는 초보자의 학습 시작을 지원하는 수단으로서 유효하다는 것을 실감했습니다. 다만, 이용 시에는 몇 가지 점에 유의할 필요가 있다고도 생각합니다.

처음부터 일반 공개할 수 있는 프로덕트(Product)를 목표로 할 필요는 없습니다. 특정 기술을 하나 시도하는 등, 확인 가능한 범위로 목적을 한정하는 것이 구성과 코드를 추적하기 더 쉽습니다.

앱이 동작하더라도 내부 메커니즘을 이해한 것은 아닙니다. 완성 후에 코드, 권한, 데이터 저장 위치, 에러 처리, 요금 발생 조건 등을 반드시 자신의 눈으로 직접 확인해야 합니다.

AI 에이전트로부터 권한을 요구받았을 경우, 필요성과 대상 범위를 확인합니다.

불분명한 경우에는 허가하기 전에 이유와 리스크를 질문합니다.

단시간에 추가할 수 있다는 이유로 기능을 늘리면, 검증과 이해가 따라가지 못하게 됩니다.

학습 목적이라면, 인간이 설명할 수 있는 범위를 단계적으로 넓혀가는 것이 적합합니다.

동작하는 코드가 생성되더라도, 이용 시의 품질이 충분하다고 단정할 수는 없습니다. 실제 기기에서 조작하며 표시, 대기 시간, 에러 발생 시의 동작 등을 확인할 필요가 있습니다.

AI 에이전트는 결과물이 완성된 후에도 학습 지원에 이용할 수 있습니다.

예를 들어, 생성된 코드에 대해 다음과 같이 질문할 수 있습니다.

이 파일의 역할을 설명해 주세요.

왜 iPhone에서 Rekognition을 직접 호출하지 않나요?

이 IAM 권한을 더 제한할 수 있나요?

이 처리를 초보자용으로 순서대로 설명해 주세요.

다음에 어떤 기능을 구현하면 현재 구성을 이해하기 쉬워질까요?

자신의 이해도에 맞춰 설명을 요구할 수 있기 때문에, 생성된 결과물을 지속적인 교재로 이용할 수 있습니다.

이번에 코드를 작성하지 않고 AI 에이전트와 iOS 앱을 개발했습니다.

AI 에이전트는 코드 생성뿐만 아니라 AWS 환경 구축, 에러 조사, 빌드, GitHub를 통한 공개, 문서 작성까지 담당했습니다.

결과물이 완성되어도 인간 측이 기술을 이해한 것은 아닙니다. 하지만 먼저 자신의 관심에 기반한 결과물을 만듦으로써, 그 코드를 배우는 동기를 얻을 수 있습니다.

AI 에이전트를 지나치게 어려운 것으로 받아들일 필요는 없습니다. 반면, 생성된 결과물을 무조건적으로 수용해서도 안 됩니다.

먼저 작게 이용하며 결과를 검증하고, 이해하지 못한 부분을 확인합니다. 이러한 반복이,

AI 에이전트를 개발과 학습 양쪽 모두에 활용하기 위한 기본이 된다고 느꼈습니다.