Google AI Studio에서 프롬프트(Prompt)로부터 Android 앱을 생성할 수 있는 기능이 소개되었습니다.

공식 블로그에 따르면, Google AI Studio 상에서 프롬프트를 입력함으로써 Kotlin 기반의 Android 앱을 생성하고, 브라우저 상의 Android Emulator에서 동작 확인을 할 수 있다고 합니다.

게다가 생성한 앱은 실제 기기에 설치하거나, Google Play의 내부 테스트 트랙(Internal Test Track)에 공개하거나, ZIP 또는 GitHub를 통해 Android Studio로 인계하는 것도 가능하다고 합니다.

상당히 큰 변화라고 느껴졌기에, 이 기사에서는 Android 엔지니어의 관점에서 궁금한 점들을 정리해 보겠습니다.

이번에 소개된 내용을 대략적으로 정리하면, 다음과 같은 것들을 할 수 있는 것으로 보입니다.

• 프롬프트로부터 Android 앱을 생성할 수 있음
• Kotlin 기반의 앱을 작성할 수 있음
• 브라우저 상의 Android Emulator에서 동작 확인 가능
• 실제 기기에 설치 가능
• Google Play의 내부 테스트 트랙에 공개 가능
• ZIP 또는 GitHub를 통해 Android Studio로 인계 가능

지금까지 AI에 의한 앱 개발 지원이라고 하면 코드 보완(Code Completion)이나 일부 구현의 생성이라는 인상이 강했지만, 이번에는 앱의 초안(Draft)을 만드는 단계까지 일임할 수 있는 수준으로 다가온 인상입니다.

가장 궁합이 좋을 것 같은 것은 프로토타입(Prototype) 제작이라고 생각합니다.

예를 들어, 다음과 같은 용도로는 상당히 편리할 것 같습니다.

• 신규 앱 아이디어 검증
• 사내용 간단한 데모 제작
• UI 이미지의 초안 작성
• 기획 단계에서의 화면 이미지 공유
• 비엔지니어(Non-engineer)와의 인식 맞추기

특히 기획 단계에서는 어떤 앱으로 만들고 싶은지를 문장으로 설명하는 것보다, 실제로 동작하는 것이 있는 편이 인식을 맞추기 쉬운 상황이 있습니다.

그런 의미에서 Google AI Studio로 빠르게 앱의 원형을 만들 수 있게 된 것은 상당히 크다고 느꼈습니다.

최근의 Android 개발은 Jetpack Compose 중심의 흐름이 더욱 강해지고 있습니다.

이번과 같은 AI에 의한 앱 생성에서도, 선언적 UI(Declarative UI)인 Compose와는 궁합이 좋을 것 같습니다.

XML 레이아웃의 경우, 화면 정의, 어댑터(Adapter), 뷰홀더(ViewHolder), 프래그먼트(Fragment)나 액티비티(Activity)의 구현 등 구성이 나뉘기 쉽습니다.

반면 Compose의 경우, UI 구조를 Kotlin 코드로 표현할 수 있기 때문에 AI가 화면 구조를 생성하기 쉬울 것이라고 느낍니다.

물론, 생성된 코드가 그대로 실무 품질이 될지는 별개의 문제입니다.

다만, AI에 의한 Android 앱 생성과 Compose 중심의 개발 스타일은 상당히 자연스럽게 이어질 것 같다는 인상입니다.

한편, 실무에서 그대로 사용할 수 있느냐 하면 그 부분은 신중하게 생각할 필요가 있습니다.

특히 신경 쓰이는 점은 다음과 같습니다.

• 아키텍처(Architecture)가 적절한가
• 상태 관리(State Management)가 파탄 나지 않았는가
• 에러 처리(Error Handling)가 고려되었는가
• 보안(Security) 측면에서 문제가 없는가
• 유지보수하기 쉬운 구성인가
• 테스트하기 쉬운 코드인가
• 기존 프로젝트의 규칙에 맞는가

개인 개발이나 프로토타입이라면 다소 거칠더라도 동작한다는 것 자체에 가치가 있습니다.

하지만 팀 개발이나 장기 운용하는 프로덕트(Product)에서는 동작하는 것만으로는 불충분합니다.

장래에 수정하기 쉬운가, 다른 멤버가 읽을 수 있는가, 사양 변경을 견딜 수 있는가와 같은 관점이 필요해집니다.

개인적인 인상으로는, AI가 생성한 코드는 완성품이 아니라 초안으로서 다루는 것이 현실적이라고 생각합니다.

예를 들어, 다음과 같은 사용법입니다.

• Google AI Studio에서 앱의 원형을 만든다
• 화면 구성이나 조작감을 확인한다
• ZIP 또는 GitHub를 통해 Android Studio로 가져온다
• 엔지니어가 설계 및 구현을 정리한다
• 필요에 따라 기존 아키텍처로 편입시킨다

이 흐름이라면 AI의 속도감을 살리면서도 실무 품질로의 조정도 가능합니다.

반대로 생성된 것을 그대로 운영 환경(Production)에 투입하는 방식은 역시 아직 두려움이 있다고 생각합니다.

이러한 기능이 늘어나면 Android 엔지니어의 역할도 조금씩 변해갈 것 같습니다.

지금까지는 화면을 만들고, API를 연결하고, 상태를 관리하는 등의 구현하는 능력이 중심이었습니다.

물론 앞으로도 구현 능력은 중요합니다.

다만 거기에 더해, AI가 생성한 것을 보고,

• 이 설계에 문제가 없는가
• 이 상태 관리 (State Management)로 유지보수가 가능한가
• 이 구현 (Implementation)이 Android로서 자연스러운가
• 이 코드가 팀의 규칙에 부합하는가
• 이대로 진행해야 하는가, 아니면 다시 만들어야 하는가

를 판단하는 능력이 더욱 중요해질 것 같다는 생각이 듭니다.

즉, 코드를 작성하는 능력뿐만 아니라, 코드를 판별하는 능력의 가치가 올라가지 않을까요.

또 하나 신경 쓰이는 점은 비엔지니어 (Non-engineer)와의 거리입니다.

프롬프트 (Prompt)로부터 앱의 원형을 만들 수 있게 되면, 기획자나 디자이너가 먼저 간단한 앱 이미지를 만드는 사례도 늘어날지도 모릅니다.

그럴 경우, 엔지니어는 제로(0)에서부터 만들기보다는,

"이 방향성이라면 실현 가능하다"

"이 사양 (Specification)이라면 나중에 힘들어질 것이다"

"이 부분은 프로토타입 (Prototype)에서는 보이지 않지만, 구현상 고려가 필요하다"

와 같은 형태로, 더 이른 단계부터 기술적인 판단을 요구받게 될 것 같습니다.

이는 긍정적인 면도 있지만, 대충 만들어진 프로토타입이 그대로 사양으로 취급될 리스크도 있습니다.

따라서 AI로 만든 것은 어디까지나 검토용이며, 구현 방침과는 분리해서 생각할 필요가 있어 보입니다.

이번 내용을 보며 Android 앱 개발도 드디어 AI에게 일부를 도움받는 단계에서, AI와 함께 앱의 형태를 만들어가는 단계에 가까워졌다는 인상을 받았습니다.

특히 프로토타입이나 소규모 앱에서는 개발 초속이 상당히 달라질 것 같습니다.

한편 실무에서는 여전히 엔지니어의 판단이 중요합니다.

AI가 만든 것을 그대로 믿는 것이 아니라, 설계, 유지보수성, 보안성, 팀 개발에 대한 적합성을 살펴보며 다듬어 나갈 필요가 있습니다.

AI에 의해 Android 엔지니어가 불필요해지는 것이 아니라, Android 엔지니어에게 요구되는 역할이 조금씩 변해가는 것이라고 생각합니다.

AI에 의해 개발이 편리해지는 한편, AI를 도구로서 능숙하게 다루느냐, 반대로 AI에 휘둘리게 되느냐가 엔지니어로서의 차이로 이어지는 시대가 다가오고 있다고 느껴집니다.

우리 엔지니어로서도 AI를 대하는 방식이나, AI와 엔지니어의 최적의 역할 분담에 대해 수시로 고민해 나갈 필요가 있어 보입니다.