개발 이야기

AI 와 함께 앱 개발하기

규샤인 — Sun, 24 Aug 2025 23:42:59 +0900

최근 재미있는 실험(?) 을 하였는데요.

이번에 처음으로 Flutter를 사용해 하나의 앱을 개발하게 되었고, 이 과정을 공유 드리려고 합니다.

글을 시작하기 앞써 필자는 안드로이드 앱 개발을 10년 이상, iOS 앱 개발을 약 3년이상 개발 경력을 갖고 있습니다.

들어가기 앞써

Flutter로 개발한 프로젝트는 Dobilbe 이라는 앱입니다.

DoBible은 바쁜 일상 속에서도 단 한 줄의 말씀으로 마음의 중심을 잡고, 하루를 새롭게 시작할 수 있는 앱입니다.

왜 시작하였는가?

이번 프로젝트의 가장 큰 특징은 공식 문서나 강의 없이, 오로지 AI(ChatGPT)의 도움만으로 앱을 완성했다는 점입니다.

Flutter 는 하나의 언어로 여러 플랫폼을 만들 수 있는 장점이 있습니다. 예를들어 코드 1개로 안드로이드, iOS 앱을 출시 할 수 있습니다. 그러다 보니 네이티브(Android, iOS)의 UI 구성 방식이나 상태 관리, 네비게이션 등 기존 네이티브 개발과는 다른 철학을 가지고 있는 프레임워크 입니다.

이번 프로젝트의 시작은 단순한 호기심에서 시작하였는데요. 평소라면 문서나 튜토리얼부터 살펴봤겠지만, 이번에는 AI의 응답만으로 어디까지 개발이 가능할까? 라는 호기심에서 실험을 시작했습니다.

참고로 공부는 하지 않았습니다. 대신 AI 에게 질문했습니다.
Flutter의 구조는 물론, 세부 위젯 활용 방법조차 모르던 상태였지만, 필요한 것이 생기면 그때그때 질문하며 구현하는 방식으로 진행했습니다.

어떻게 질문 하였는가?

AI 로 개발을 할 때에 가장 중요한 것은 어떤 프롬프트를 작성하는가? 라고 생각됩니다.

프롬프트는 AI에게 원하는 결과를 얻기 위해 입력하는 텍스트 지시문입니다.

AI 의 프롬프트는 웹 브라우저의 검색과 다르게 문장으로 프롬프트를 작성할 수록 좋은 피드백을 받을 수 있습니다. 그래서 저의 첫 프롬프트는 AI 에게 ‘개발하고자 하는 앱의 배경과’과 ‘앱 화면 구성 방법’ 에 대해서 질문을 하였습니다.

생각보다 AI 의 답변은 구체적이었습니다.

메인화면, 말씀 뽑기화면, 설정 화면까지 전체적인 앱의 구성에 대한 정의를 내려주었고, 화면 구성 방향을 제시 해주었습니다.

무엇보다 구성 예시를 제안하면서 각 구성요소의 역할이 무엇인지 자세히 알려주었습니다.

페이지 기획의 큰 그림이 어느 정도 완성되어, 이제 본격적으로 개발을 시작했습니다.

스플래시 화면을 구성하고, '오늘의 말씀'을 보여주었는지 여부에 따라 서로 다른 엔드포인트 화면으로 이동할 수 있도록 로직을 만들 계획을 갖고 프롬프트에 입력하였습니다.

AI의 피드백을 보면서 놀란것은 구현 방식에 대한 설명과 그와 맞는 예제 코드를 제공한다는 것입니다.

제공한 예제 코드에 대한 설명도 함께 제공하여, 코드에 대한 이해하는데 어려움이 없었습니다. 그러다보니 제공한 코드를 그대로 사용하는 것이 아닌 제공된 코드를 바탕으로 재구성하여 개발하였습니다.

JSON 데이터 구성

단순히 프롬프트를 입력하는 것만으로 기획과 개발이 가능하다는 점을 확인했고, 데이터 구성도 프롬프트를 통해 시도해보았습니다.

데이터 구성 JSON 으로 데이터를 구성하고 이 JSON을 어떻게 파싱해야하는 것에 대해서도 AI 가 할 수 있는지 실험을 하였습니다.

먼저는 필요한 JSON 을 생성해달라고 하였습니다. 예를 들어서 ‘사람들에게 힘이 되는 문구 100개를 만들어줘’ 와 같이 JSON 을 AI 에게 요청하면 100개의 문구로 구성된 JSON을 제공해줍니다.

여기서 더 나아가 JSON 구성도 변경할 수 있습니다. reference, referenceFullName, Topics 와 같이 필드를 추가해서 변경해달라는 프롬프트를 작성하였고, AI는 의도에 맞게 JSON을 재구성하여 제공하였습니다.

JSON 이 구성되었으니 파싱을 해야했습니다. 이번에도 AI 에게 JSON 파싱하는 방법에 대해서 물어봤습니다.

JSON 파싱 시 필요한 Dart 모델 구성과 JSON 파싱 방법을 코드로 알려주어 적용하는데 어려움이 없었습니다.

개발에 필요한 질문을 AI에게 던졌고, 그 응답을 기반으로 코드를 수정·적용하면서 빠르게 기능을 완성해 나갔습니다. 개발 경력이 있다보니 AI의 답변을 그대로 사용하기 보다 응용해서 사용하였고, AI 응답에 추가된 설명을 보면서 개발 학습이 되면서 간단한 기능은 직접 개발하면서 진행하였습니다.

에러에 대한 처리

개발 시 에러가 발생하면 에러 메시지는 그대로 붙여넣고 원인을 파악하고, 대안을 얻는 방식이었습니다.

에러 메시지만 던져도 AI가 그동안 질문한 것과 맥락을 파악해서 그런지 프로젝트에 맞는 답변을 주었습니다.

플로터는 멀리 플랫폼을 지원하지만 에러에 대한 처리는 플랫폼에 대한 이해가 있어야 수정할 수 있습니다.

플랫폼에 나오는 이슈까지 AI 도움으로 해결 하면서 플랫폼 특성의 이슈를 빠르게 해결하며 개발에 속도를 높일 수 있었습니다.

앱 아이콘 구성하기

1인 개발자로써 가장 어려운 것은 디자인 입니다. 이 디자인 부분을 AI의 도움으로 어느정도 해결하였습니다.

원하는 색상과 앱의 컨셉을 간단히 기록하여 이것과 부합되는 아이콘 만들어줄 것을 요청하였고,

그 결과 받은 앱 아이콘 기반으로 앱 아이콘을 구성하였습니다.

아쉽게도 제가 사용한 AI 툴에서 제공하는 앱 아이콘은 앱에 바로 사용은 힘들어서, 디자인 시안 기반으로 앱 아이콘을 디자인 하여 적용하였습니다.

마무리

바이브 코딩이라는 말이 요즘 주변에서 쉽게 들을 수 있습니다. 자연어인 프롬프트 기반으로 코딩하는 바이브 코딩은 개발 언어를 모르는 개발자에게 개발 속도를 올릴 수 있는 코딩 방법이라고 생각합니다.
이번 개발 과정은 단순히 검색의 연장선이 아닌, 대화 기반 개발에 가까웠습니다. AI 와 대화를 앱의 구조부터 상세 기능까지 대부분이 아래 흐름으로 진행되었습니다.

"이런 걸 만들고 싶어."
AI가 구조 제안 및 코드 스니펫 제공
코드 적용 및 수정
예상치 못한 이슈 발생 → 다시 질문
(반복)

이처럼, 개발 과정 전체가 질문과 응답의 흐름으로 구성되었고, 저는 그 흐름을 빠르게 따라가며 앱을 완성할 수 있었습니다.

Flutter를 처음 접한 입장에서, AI를 통해 질문하고 구현하는 방식만으로도 앱을 개발할 수 있다는 경험은 인상 깊었습니다. 물론 기존의 개발 지식과 경험이 기반이 되었지만, 이번 프로젝트를 통해 공부의 흐름 자체가 질문 중심으로 변화하고 있다는 것을 실감하게 됐습니다.

이번 프로젝트를 통해 질문력만으로도 앱을 만들 수 있다는 결론을 내릴 수 있었습니다. 앞으로의 개발 문화와 환경이 변화될 것으로 생각됩니다. 질문을 잘하는 개발자가 높은 대우를 받는 날이 머지않은 거 같습니다.

오늘의 말씀 앱 DoBible 출시

규샤인 — Wed, 9 Apr 2025 12:15:00 +0900

Android

다운로드 가기

iOS

다운로드로 이동

DoBible 개인정보 처리 방침

규샤인 — Wed, 9 Apr 2025 00:20:34 +0900

본 개발자가 작성한 앱은 개인정보보호법에 따라 이용자의 개인정보 보호 및 권익을 보호하고 개인정보와 관련한 이용자의 고충을 원할하게 처리할 수 있도록 다음과 같은 처리방침을 두고 있습니다.

1. 개인정보의 처리 목적

- 광고ID(AdID) 수집 목적
Google은 사용자에게 더 많은 선택권을 제공하기 위해 광고 및 분석 작업에 사용할 수 있는 재설정 가능한 식별자인 앱용 광고ID를 도입했습니다. 이 식별자는 여러 용도가 있지만 대표적으로 게재할 광고를 맞춤설정하고 앱 사용 방식을 파악하는데 유용합니다.
예를 들어 광고를 게재한 뒤에 마케팅 측에서 문맥광고, 게재빈도 설정, 전환 추적, 보고 및 보안, 사기 감지 작업을 수행할 수 있습니다.

자세히 : https://support.google.com/googleplay/answer/3405269

광고 ID - Google Play 고객센터

Google Play는 사용자 관리 기능의 향상을 위해 광고 및 분석에 사용할 수 있는 재설정 가능한 식별자인 앱용 광고 ID를 도입했습니다. 이 식별자는 여러 용도가 있지만 특히나 광고를 맞춤설정하고

support.google.com

가. 애드몹 관련 정보
- 애드몹 : https://admob.google.com/home/

2. 개인정보의 처리 및 보유 기간
앱은 정보 주체로부터 개인정보를 수집 할 때 동의 받은 개인정보 보유 이용기간 또는 법령에 따른 개인정보 보유 이용기간 내에서 개인정보를 처리 보유하며 구체적인 개인정보 처리 및 보유 기간은 다음과 같습니다.

가. 개발자가 데이터를 수집하거나 저장하지 않습니다.

광고 및 광고분석 서비스에서(이하 Google) 수집하는 광고 ID에 관한 자세한 사항은 해당 서비스의 개인정보처리방침(https://policies.google.com/privacy?hl=ko)를 참고해 주시기 바랍니다.

3. 개인정보의 제 3자 제공
앱은 정보주체의 별도 동의, 법률의 특별한 규정 등 개인정보 보호법 제 17조에 해당하는 경우 외에는 개인정보를 제 3자에게 제공하지 않습니다.

4. 개인정보처리 위탁
위탁하는 업무의 내용 : 광고 및 광고 분석 서비스
Google 개인정보처리방침(https://policies.google.com/privacy?hl=ko)
Google 광고 개인정보 보호 및 약관 (https://policies.google.com/technologies/ads?hl=ko)

5. 처리하는 개인정보의 항목
- 광고ID(AdID) 수집 (과정에서 사용자의 IP수집이 포함될 수 있습니다.)
개발자 본인이 아닌 광고 및 광고 분석 서비스(이하 Google)에 의해 광고 식별자인 Android 광고 ID가 수집 될 수 있습니다.
이는 기기의 설정(Google 설정앱 -> Google -> 광고 또는 설정 -> 계정 -> Google -> 광고)을 변경함으로 사용을 거부 할 수 있습니다.
또한 광고 추적을 선택 해제한 사용자가 해당 식별자를 재설정하여 광고 추적을 선택 해제하기 전에 수집 및 전달된 리마케팅 데이터로부터 기기의 연결을 해제 할 수 있습니다.
Google 서비스에서 수집하는 정보는 각 서비스가 사용하는 저장소에만 수집, 저장되며 본 서비스에서 별도로 저장하지 않습니다.

6. 개인정보의 파기에 관한 사항
개발자가 데이터를 수집하거나 저장하지 않습니다.
광고 및 광고분석 서비스에서(이하 Google) 수집하는 광고 ID에 관한 자세한 사항은 해당 서비스의 개인정보처리방침(https://policies.google.com/privacy?hl=ko)을 참고해 주시길 바랍니다.

7. 개인정보 관리 책임자 및 담당자의 연락처
귀하께서는 앱의 서비스를 이용하시며 발생하는 모든 개인정보 보호 관련 민원을 개인정보 관리 책임자 혹은 담당부서로 신고하실 수 있습니다. 앱은 이용자들의 신고사항에 대해 신속하게 충분한 답변을 드릴 것입니다.
이름 : 신규찬
메일 : dev.faithpeole@gmail.com

안드로이드 앱 개발 네이티브, Kotlin Multiplatform, Flutter 어떤 것으로 해야하는가?

규샤인 — Fri, 7 Mar 2025 21:21:04 +0900

안드로이드 앱 개발 하는데 어떤 플랫폼을 선택해서 개발하는게 가장 효율적일까요?

안드로이드 개발 시 사용되는 대표적인 세가지 플랫폼을 소개하려고 합니다.

가장 기본이 되는 네이티브 SDK 을 활용해서 개발 시 장점과 단점, 멀티 플랫폼 Flutter을 활용 시 장점과 단점 마지막으로 Kotlin Multiplatform 줄여서 KMP 의 장점과 단점에 대해서 ChatGPT의 도움과 함께 정리한 내용을 포스트 하였습니다.

개발 도구 선택 시 도움 되면 좋겠습니다.

1️⃣ 네이티브 개발

네이티브 앱 개발의 정의 및 주요 특징은 무엇일까?

안드로이드 네이티브 앱 개발은 Java나 Kotlin과 같은 프로그래밍 언어를 사용하여 직접 개발하는 방식입니다.
Android SDK를 통해 디바이스의 하드웨어 기능에 직접 접근 가능합니다.

반면에 iOS는 object-c 또는 swift과 같은 프로그래밍 언어를 사용하여 개발하는 방식이고, xcode SDK 을 통해 디바이스 하드웨어 기능에 직접 접근 가능합니다.

네이티브 앱 개발의 장점에 대해 알아보자!

성능측면에서 보면 최적화된 성능 제공하며, 하드웨어 가속 기능 활용 가능합니다.

사용자 경험 측면에서 보면 각 플랫폼의 UI 가이드라인에 따라 설계되어 친숙한 인터페이스와 우수한 사용자 경험 제공합니다.

기능 접근성 측면에서 보면 카메라, 마이크, GPS 등 디바이스 기능을 완벽하게 활용 가능합니다.

보안성 측면에서 보면 플랫폼 별 보안 기능과 정책을 최대한 활용 가능합니다.

플랫폼 특화 기능 사용 측면에서 보면 각 플랫폼의 최신 기능을 즉시 사용 가능합니다.

네이티브 앱 개발의 단점은 없을까?

개발 및 유지 보수 비용 측면에서 보면 각 플랫폼마다 별도의 앱 개발 필요, 비용과 시간 많이 소모하게 됩니다.
시간 소모 측면에서 보면 다양한 플랫폼에 앱을 개발하려면 각양각색의 언어와 환경에 대한 전문 지식 필요합니다.

2️⃣ Kotlin Multiplatform (KMP) 개발

KMP 정의 및 주요 특징에 대해 알아보자

Kotlin 언어를 기반으로 다양한 플랫폼에서 실행되는 프레임워크 입니다.
KMP의 가장 큰 장점이라고 할 수 있는 한 번의 코드 작성으로 안드로이드, iOS, 웹, 데스크톱 등에서 동작 가능합니다.

KMP 의 장점은 무엇일까요?

코드 재사용성 측면에서 보면 비즈니스 로직과 유틸리티 함수를 여러 플랫폼에 걸쳐 재사용 가능합니다.

유지 보수 용이성 측면에서 보면 공통 코드 베이스 사용으로 버그 수정과 기능 업데이트가 용이 합니다.

플랫폼 별 공통의 아키텍처 구성이 가능합니다. 중요한 비즈니스 로직을 한 번만 개발하고 여러 플랫폼에서 재사용 가능하여 가장 큰 장점이라고 할 수 있습니다.

단점은 없을까요?

아무래도 멀티 플랫폼을 제공하다보니 플랫폼 특화 기능 제한이 있습니다. 각 플랫폼의 특화된 기능을 최대한 활용하기 어렵습니다.

커뮤니티와 지원이 아직은 부족합니다. 비교적 새로운 기술, 네이티브 개발 환경만큼의 폭넓은 지원 부족합니다.

3️⃣ Flutter 개발

Flutter 의 정의 및 주요 특징에 대해 알아보자!

Flutter는 Google 개발의 오픈 소스 UI 소프트웨어 개발 키트로써 구글의 지원을 받고 있는 플랫폼 입니다.

Flutter는 Dart 언어 사용하고 있으며, iOS, 안드로이드, 웹, 데스크톱에서 하나의 코드베이스로 앱 구축 가능합니다.

Flutter의 장점은 무엇일까?

개발 속도의 향상이 있습니다. 핫 리로드 기능으로 코드 변경 사항 즉시 반영, 개발 시간 단축 됩니다.
즉, 코드만 입렫하면 바로 화면에 반영 된 것을 볼 수 있습니다.

UI 일관성을 제공합니다. 단일 코드베이스로 모든 플랫폼에서 UI 일관성 유지 하게 됩니다.

성능측면에서는 네이티브 앱과 비슷한 수준의 성능 제공하게 됩니다.

Flutter 의 단점은 무엇일까?

파일 크기의 단점이 있습니다. 큰 파일 크기로 인해 다운로드 시간과 장치 저장 공간에 영향을 받습니다.

새로운 언어 학습 필요 합니다. Flutter는 Dart 언어로써 Dart 언어에 익숙하지 않은 분들은 학습 필요합니다.

하드웨어 기능 접근 제한이 있습니다. 특정 플랫폼의 고유 기능에 접근하는 데 제한이 있습니다.

결론

안드로이드 앱 개발에 있어 기술 선택은 프로젝트의 성공에 결정적인 요소입니다. 각 기술의 장단점을 잘 이해하고 프로젝트의 목표에 맞춰 적절한 기술을 선택하는 것이 중요합니다.

네이티브 개발은 최적의 성능을 필요로 하는 앱에 적합하며, Kotlin Multiplatform은 코드 재사용성과 유지 보수의 편리함을 중요시하는 프로젝트에, Flutter는 빠른 개발과 플랫폼 간 일관된 사용자 경험을 제공합니다.

좀 더 현업 입장에서 말씀드리자면, 인력이 부족하고 빠른 결과물을 만들어서 수익을 얻어야하는 스타트업에서 사용하기에는 Flutter로 개발하는 것을 추천 드립니다.

인력이 어느 정도 갖추어지며 안정적이며 최적화된 프로잭트를 진행해야 한다면 네이티브를 추천 드립니다.

Android, ios 를 개발 시 공통 비즈니스 로직을 갖은 코드는 Kotlin Multiplatform 로 라이브러리를 만들어서 사용 할 것을 추천 드립니다.

최종적으로 개발 팀의 전문성과 프로젝트 요구 사항을 기반으로 최적의 기술을 선택함으로써, 효율적이고 경제적인 개발 과정을 설계할 수 있습니다. 이 글이 안드로이드 앱 개발에 대한 기술 선택을 고민하는 데 도움이 되길 바랍니다.

클린아키텍처의 2개의 Mapper(Entity, View Model) 의 가이드

규샤인 — Fri, 31 Jan 2025 00:50:03 +0900

클린아키텍처에서 Entity 와ViewModel을 명확한 구분을 주고 있습니다. 여기서 ViewModel 는 MVVM 의 ViewModel이 아니라 View의 Data 즉, UI Data를 의미합니다.
클린아키텍처에서 이 두 데이터의 차이를 혼재되어 사용 할 수 있는데 이 두 데이터의 차이와 Android 에서는 클린아키텍처를 어떻게 사용하면 좋을지 공유하겠습니다.

클린아키텍처의 Mapper 의 역할

클린아키텍처에서는 두 개의 Mapper 가 존재합니다.

1. DTO → Entity Mapper
데이터를 네트워크, 데이터베이스 등 외부 소스에서 받아와 비즈니스 계층(Entity)로 변환합니다.
이 단계는 보통 Repository 계층에서 수행됩니다.

2. Entity → ViewModel (또는 UI 모델) Mapper
비즈니스 로직 처리 후, UI 계층에 맞는 데이터 구조(ViewModel 또는 화면 모델)로 변환합니다.
이 단계는 보통 Use Case 계층에서 수행됩니다.

여기서 말하는 ViewModel은 MVVM의 ViewModel과 다른 개념입니다.

두 개의 Mapper가 필요한 이유

클린 아키텍처의 핵심은 계층 간 독립성을 보장하는 것입니다. 각 계층의 책임을 분리하기 위해 데이터 변환이 계층 간에서 수행됩니다.

1. DTO → Entity Mapper
DTO(Data Transfer Object)는 외부 시스템(API, DB 등)에서 데이터를 받아오는 데 사용됩니다.
이 데이터를 도메인(Entity)에서 활용할 수 있도록 변환해야 합니다.
이런 작업이 필요한 이유는 DTO는 외부 시스템의 데이터 형식은 내부 비즈니스 로직과 다를 수 있습니다.

예를 들어서 API 에서 처리하는 비즈니스 로직은 DB 에 있는 데이터를 API 로 내리기 위한 작업만 한다면 Entity 에서 가져갈 비즈니스 로직은 달라질 수 있습니다.
Entity 는 외부 데이터에 대한 의존성을 줄이고, 비즈니스 로직의 독립성을 유지합니다. 여기서 비즈니스 로직에 UI 부분은 제외 됩니다.

2. Entity → ViewModel Mapper
Entity는 비즈니스 로직을 처리하기 위한 구조를 가지고 있습니다.
UI(ViewModel)는 화면에 적합한 구조와 데이터를 요구합니다.
Mapper를 한번 더 하여 ViewModel를 생성하는 이유는 Entity는 비즈니스 중심이므로, UI와 직접 연결되면 변경이 어려워질 수 있습니다.
화면에 맞는 형식으로 데이터를 가공해야 하므로 변환이 필요합니다.

어떻게 사용해야할까?

앱에서의 클린아키텍처는 독립적으로 구성하여 1:1 매핑을 가져가는 것보다 UI 의 속도가 중요하게 됩니다. 속도를 생각한다면 다음 두가지를 고려해볼 필요가 있습니다.

1. Entity와 ViewModel의 결합

모든 프로젝트에서 "완벽한 클린 아키텍처"를 강요할 필요는 없습니다. 다음과 같은 절충안을 고려할 수 있습니다:
Entity와 ViewModel 통합비즈니스 로직이 단순하다면, UI에 맞춘 데이터 구조를 Entity로 사용하는 것도 가능합니다.

하지만 이를 도메인 독립성이 필요 없는 간단한 애플리케이션에서만 적용해야 합니다.

클린아키텍처를 구성하며 도메인의 의존성을 가져갈 구조였다면 이 과정의 도입은 힘들 수 있으나 프로젝트 규모에 따라서 고려해 볼 수 있습니다.

2. Entity의 존재성 제거

API 가 UI 에 맞춰 설계되어 내려 온다면 Entity 로 변환은 필요 없어질 것입니다.

API 에서 받은 DTO 를 바로 사용하는 구조라면 entity에서 ViewModel의 mapper의 역할도 고려해 볼 필요가 있습니다. 프로젝트에 API 구조에 따라서 DTO를 바로 사용할 수도 있고, Mapper를 활용해서 DTO에 대한 비즈니스를 녹인 Entity 로 사용할 수 있습니다.

프로젝트 상황에 맞춰서 Entity의 존재는 생략될 수 있습니다.

Mapper의 가이드 라인

앞써 설명 드렸듯이 클린아키텍처에서의 Mapper 는 2번 이뤄지게 됩니다. 각 Mapper 에서 추가해야할 값들이 있습니다.

1. DTO → Entity 변환 시 값 추가가 적절한 경우

1.1. Entity에 필요한 필드가 DTO에 없을 때

API에서 제공하지 않는 데이터가 있지만,
Entity의 비즈니스 로직이나 데이터 구조상 반드시 필요한 경우 값을 추가할 수 있습니다.

예를들면 다음 세 가지의 필드를 추가 할 수 있습니다.

기본값을 설정해야 하는 필드 (예 : 기본 카운트 값, 기본 설정 값, UDID 같은 식별 값)
계산을 통해 도출해야 하는 값 (예: 은행 잔액)
시스템 내부에서 관리해야 하는 데이터(예: 생성 시점, 유효성 상태)

data class AccountEntity(
    val id: String,
    val email: String,
    val isDeleted: Boolean = false,
    val isVerified: Boolean = false,
    val id: String = UUID.randomUUID().toString(),
    val createdAt: LocalDateTime = LocalDateTime.now(),
    val updatedAt: LocalDateTime = LocalDateTime.now()
)

2. 비즈니스 로직을 지원하기 위해
Entity는 비즈니스 로직을 포함하므로, DTO에 없는 값이라도 비즈니스 로직을 수행하기 위해 추가할 수 있습니다.
예를 들면 사용자의 이메일 인증 여부를 저장하기 위해, 이메일 존재 여부로 isEmailVerified 값을 추가 할 수 있습니다.

data class AccountEntity(
    val id: String,
    val email: String,
    val isEmailVerified: Boolean = false
)

이처럼 Entity의 추가 필드는 비즈니스 로직이나 데이터 구조상 필요한 데이터를 구성할 수 있으며, UI 구성 시 필요한 데이터는 구성하지는 않습니다.

2. Entity → ViewModel

2.1. UI 를 위한 ViewModel
Entity의 비즈니스 로직이나 데이터 구조 상 필요 값이 존재하나 UI 구성 시 반드시 필요한 값 한 경우 추가할 수 있습니다.

리스트로 구성된 화면에서 데이터 타입별로 화면을 구성한다고 가정해 봅시다. 이때, UI 복잡도에 따른 리스트의 최적화를 위해 하나의 데이터 타입을 여러 개의 데이터(n개)로 분리하는 작업을 수행할 수 있습니다.

예시로 온라인 쇼핑 앱에서 상품 리스트 화면을 구성한다고 가정합니다.

API로부터 상품 데이터를 받아오지만, UI에서 각 상품을 일반 상품과 할인 상품으로 나누어 표시해야 합니다.

일반 상품은 이름과 가격만 표시하고,
할인 상품은 이름, 원래 가격, 할인된 가격, 할인율을 표시합니다.

이를 위해 하나의 상품 데이터를 일반 상품과 할인 상품으로 나누어 표시하는 작업을 `Mapper`로 처리할 수 습니다.

API Response (Entity)

{
  "id": "001",
  "name": "Wireless Mouse",
  "price": 25000,
  "discountPrice": 20000,
  "category": "Electronics"
}

ViewModel 구조

- RegularProductViewModel : 일반 상품
- DiscountedProductViewModel : 할인 상품

sealed class ProductViewModel {
    data class RegularProductViewModel(
        val id: String,
        val name: String,
        val price: Int
    ) : ProductViewModel()

    data class DiscountedProductViewModel(
        val id: String,
        val name: String,
        val originalPrice: Int,
        val discountPrice: Int,
        val discountRate: Int
    ) : ProductViewModel()
}

Mapper 구현

fun ProductEntity.toViewModels(): List<ProductViewModel> {
    val viewModels = mutableListOf<ProductViewModel>()

    // 일반 상품으로 추가
    viewModels.add(
        ProductViewModel.RegularProductViewModel(
            id = this.id,
            name = this.name,
            price = this.price
        )
    )

    // 할인 상품이 있는 경우 추가
    if (this.discountPrice < this.price) {
        val discountRate = ((this.price - this.discountPrice) * 100) / this.price
        viewModels.add(
            ProductViewModel.DiscountedProductViewModel(
                id = this.id,
                name = this.name,
                originalPrice = this.price,
                discountPrice = this.discountPrice,
                discountRate = discountRate
            )
        )
    }

    return viewModels
}

2.2. 화면 구성에 따른 UI 데이터

API 에서 내려온 데이터를 UI 최적화를 위한 재구성 할 수 있습니다.

앱 개발에서는 API에서 내려온 데이터를 그대로 UI에 사용할 수 없는 경우가 많습니다. 특히, 화면 최적화를 위해 데이터를 재구성해야 하는 경우가 발생합니다.

예를 들어, API에서 다음과 같은 형태의 게시글 데이터가 내려온다고 가정해 봅시다.

API Response (Entity)

{
  "id": "123",
  "title": "클린 아키텍처란?",
  "content": "클린 아키텍처는...",
  "author": {
    "name": "홍길동",
    "profileImage": "https://example.com/profile.jpg"
  },
  "tags": ["Android", "Architecture", "Kotlin"],
  "createdAt": "2025-01-30T12:00:00Z"
}

하지만 UI에서는 이를 그대로 표시하지 않고, 필요에 따라 데이터를 가공해야 합니다.

예를 들어:

- 날짜 형식을 `yyyy.MM.dd` 형태로 변환
- 태그를 `#Android #Architecture #Kotlin` 형태로 변환
- 작성자의 이름과 프로필 이미지를 별도로 표시

이를 위해 `Mapper`를 사용하여 데이터를 Entity → ViewModel로 변환합니다.

ViewModel (UI에서 사용하는 데이터)

data class PostViewModel(
    val id: String,
    val title: String,
    val content: String,
    val authorName: String,
    val authorProfileImage: String,
    val formattedTags: String,
    val formattedDate: String
)

Mapper 구현

fun PostEntity.toViewModel(): PostViewModel {
    return PostViewModel(
        id = this.id,
        title = this.title,
        content = this.content,
        authorName = this.author.name,
        authorProfileImage = this.author.profileImage,
        formattedTags = this.tags.joinToString(" ") { "#$it" },
        formattedDate = formatDate(this.createdAt)
    )
}

fun formatDate(isoDate: String): String {
    val formatter = DateTimeFormatter.ofPattern("yyyy.MM.dd")
    return LocalDateTime.parse(isoDate, DateTimeFormatter.ISO_DATE_TIME).format(formatter)
}

마무리

클린 아키텍처의 유지보수성과 효율성 사이에서 균형을 맞추는 것이 핵심입니다. 프로젝트 규모와 요구사항에 맞게 설계를 조정하면 불필요한 작업을 최소화할 수 있습니다.

다음 세가지을 참고하여 프로젝트의 규모와 특성에 맞춰 클린아키텍처를 구성하는데 도움이 되면 좋겠습니다.

1. 비즈니스 로직에 부합하는 값만 추가

추가하는 값이 도메인 로직을 명확히 지원하거나, 시스템 요구사항을 충족하는지 확인합니다. 프로젝트 특성에 맞춰 DTO → Entity의 변화는 생략 될 수 있습니다.

2. Mapper에서 변환 책임 분리

DTO → Entity 변환 시, 값을 추가하거나 가공하는 책임을 Mapper에 분리하여 관리합니다.

Entity → View의 변환 시 Use Case를 활용 합니다.

값 추가가 단순한 변환 이상의 비즈니스 로직을 포함한다면, Use Case 계층에서 처리하도록 설계합니다.

3. 추가된 값의 의미 명확히 문서화

코드에 주석이나 문서를 통해, 왜 특정 값이 추가 되었는지 설명합니다.

Sealed vs Enum 어떤걸 써야하나?

규샤인 — Thu, 7 Nov 2024 20:11:02 +0900

Kotlin 에는 Sealed class 라는 것이 있습니다. 이 Selaed 클래스를 Enum과 같이 사용하는 경우가 많은데요. 이 Sealed Class 를 Enum 대체로 작성하는 것이 옳은 것인지 이해 못하고 사용 하는 분들도 많은거 같습니다.
이번 포스트에서는 Sealead Class 에 대한 개념과 Enum 클래스의 개념을 정의하고 어떻게 사용하면 좋을지 이야기 해보겠습니다.

Sealed Class 넌 뭐니?

Sealed 라는 영단어의 뜻을 알면 Sealed Class 에 대해서 이해하기 도움이 될 것입니다. Sealed 는 봉인된 이라는 의미를 갖고 있는데 이 단어의 뜻과 같이 Sealed Class 클래스는 다른 클래스에서 상속하거나 확장할 수 없습니다. 즉, Sealed Class 에서는 SubClass를 생성할 수 없습니다. 이는 일반적으로 클래스 작성자가 추가적인 상속을 방지하고 특정한 디자인 선택이나 제한을 강제하기 위해 선택합니다.

예를 들어, Kotlin 에서는 다음과 같이 정의할 수 있습니다.

sealed class SealedClass
{
    // 클래스 멤버와 메서드
}

Selaed Class 의 장단점이 무엇일까?

Sealed 클래스의 장점
    - 명확하고 엄격한 디자인 결정을 제공하여 의도하지 않은 상속을 방지합니다.
    - 일부 상황에서 성능 이점을 제공할 수 있습니다. 컴파일러가 더 많은 최적화를 수행할 수 있습니다.

Sealed 클래스의 단점
    - 상속을 통한 코드 재사용이 불가능합니다.
    - 특정 디자인 패턴에 대한 제약을 가질 수 있습니다.

우리가 알고 있는 Enum (열거형)

`Enum(열거형)`은 프로그래밍에서 사용되는 데이터 형식으로, 특정 도메인과 관련된 상수 값들의 집합을 나타냅니다. Enum은 일련의 상수 값을 정의하고 각 값은 상징적인 이름과 연결됩니다. Enum은 특정한 관련된 값들의 고정된 집합이 있을 때 코드를 더 읽기 쉽고 유지 보수하기 좋게 만드는데 유용합니다.

예를 들어, Java에서 이렇개 코드가 구성될 수 있습니다.

enum DaysOfWeek
{
    Sunday,
    Monday,
    Tuesday,
    Wednesday,
    Thursday,
    Friday,
    Saturday
}

Enum의 장점

- 상수 값에 의미 있는 이름을 제공하여 코드의 가독성을 향상시킵니다.
- 기본 타입을 직접 사용하는 것보다 오류 가능성이 낮아집니다.
- 코드의 구조와 유지 보수성을 높여줍니다.

Enum의 단점
- Enum 값은 컴파일 시간에 고정되므로 동적인 값 집합에는 다른 데이터 구조보다 덜 유연합니다.
- Enum 값은 런타임에서 확장하거나 수정할 수 없습니다.

요약하면, `sealed` 클래스는 상속을 제한하여 클래스가 더 이상 확장되지 않도록 하며, `enum`은 고정된 상수 값들의 집합에 대해 이름을 정의하는 데 사용됩니다. 두 개념은 객체 지향 프로그래밍에서 각기 다른 용도로 사용되며 서로 다른 역할을 수행합니다.

마무리

`sealed` 클래스와 `enum` 클래스의 장단점을 알아봤습니다. kotlin 으로 작성된 코드라고 enum을 대신하기 위해서 selaed 클래스 사용하는 것은 지양해야합니다. 상속과 확장을 막기 위해서 sealed 클래스를 사용해야하며, 열거형으로 사용하기 위해서는 enum 클래스를 사용할 것을 권장합니다.

`enum class` 사용하는 것은 무겁다라고 말하는 개발자도 있습니다. enum class는 타입 안전성과 스코프 제약을 통한 명시적 설계를 제공하는 대신, 약간의 성능 및 메모리 오버헤드가 있을 수 있으며, 이를 "무겁다"고 표현하는 경우가 있습니다. 그러나 이러한 오버헤드는 일반적으로 매우 미미하며, 대다수의 경우 무시할 수 있을 정도로 열거형을 사용할 때는 `enum class` 를 사용해도 메모리에 크게 영향은 없을것으로 보입니다.

한줄요약
`sealed class` : 확장하지 않을 봉인할 class 구성 시 사용 할 것
`enum class` 열거형 표현 할 때 사용 할 것

참고 및 도움 준 사이트

* https://velog.io/@stn/Kotlin-Sealed-Classes-VS-Enum-Classes-VS-Sealed-Inferfaces
* CHAT GTP

[Android] 클린아키텍처에 대해서 살짝 맛보기

규샤인 — Tue, 29 Oct 2024 00:18:20 +0900

클린아키텍처에 대해 많은 관심을 갖고 다양한 회사에서 도입 및 시도하고 있습니다.
어떻게 구성해야 클린 아키텍처일까요?

이상적인 아키텍처에 대해서 로버트 C. 마틴에 의해서 소개 되었으며 복잡한 소프트웨어 시스템을 보다 관리 가능하고 유지보수 가능한 형태로 구축하기 위한 지침을 제공하였습니다.
로버트 C.마틴이 말한 클린 아키텍처의 기본적인 개념과 어떻게 Android 환경에서 도입하였는지에 대해서 Medium 에 글이 등재 했는데요. 등재한 글의 일부를 공유하겠습니다.

자세한 내용은 왜 Android 신규 프로젝트는 클린 아키텍처를 도입하였는가? 라는 기술블로그 에서 확인 할 수 있습니다.

클린 아키텍처를 왜 쓰는걸까?

http://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html

클린 아키텍처는 소프트웨어 시스템의 구조를 체계적으로 설계함으로써 여러 가지 장점을 제공하는데요.
가장 중요한 장점 중 하나는 시스템의 각 부분을 독립적으로 개발하고 테스트할 수 있는 환경을 조성할 수 있다는 점입니다. 또한 시스템의 변경이나 업그레이드가 필요할 때 전체 시스템을 다시 작성하지 않아도 되며, 특정 부분만 수정하는 것이 가능해집니다.

현업에서 일한다면 개발 후 운영의 앱 중 특정 부분의 수정을 요청하는 경우를 경험했을 것입니다.
A 회사는 Network 통신 라이브러리인 Retrofit의 Convert Factory를 Moshi Factory로 사용하고 있었습니다.
어느날 Moshi Facory가 아닌 Gson Convert Factory 으로 전면 변경하라는 기술 지침이 내려온다면 개발자는 프로젝트 안에서 Network 통신 하는 곳을 모두 찾아서 Moshi Factory 를 Gson Convert Factory 라이브러리로 변경하는 귀찮음과 코드를 찾는 수고가 발생할 수 있습니다.
또한 모든 부분을 변경하였다고 생각하였으나, 일부 코드의 미수정으로 인한 사이드이팩이 발생할 수도 있습니다.

이와 동일한 조건으로 Network 방식을 변경한다면 클린아키텍처로 구성된 코드에서는 Network 통신을 담당하는 Layer 만 확인 후 Network 통신 라이브러리를 변경작업하면 됩니다. 이렇게 한곳에서만 수정하면 모든 코드를 찾으면 하나씩 변경하는 수고는 적게되고 그만큼 사이드이팩에 대한 두려움도 줄어들 것입니다.

클린아키텍처 Android 환경 구성 어떻게 해야할까?

클린 아키텍처를 Android 의 구조에 맞춰서 개발하는 가이드라인은 Google Developer Document(Guilde to app architecture) 에 명시되어 있어 참고해서 개발할 수 있습니다. Google Developer Document 을 참고하기에 어렵다면 참고할 만한 다수의 블로그가 존재하기에 그것을 참고해서 작성하셔도 됩니다.

여기서 중요한 것은 각 계층인 Layer 를 분리해야합니다. 예를들어서 Presentation Layer, Domain Layer, Data Layer는 하나의 모듈에서 존재하는 것보다 각각 Module 구성을 하여 의존성을 낮추는게 중요합니다.

왜 Android 신규 프로젝트는 클린 아키텍처를 도입하였는가? 에 명시되어 있는 Flow 를 참고하시면 Presentation, Domain, Data Layer는 분리되어 있고, Domain은 어느 모듈도 의존하고 있지 않도록 구성되어 있습니다.

https://medium.com/cj-onstyle/android-%EB%B2%84%ED%8B%B0%EC%BB%AC-%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8%EC%9D%98-%ED%81%B4%EB%A6%B0-%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98-%EB%8F%84%EC%9E%85-a26d833e103c

클린아키텍처를 도입할 프로젝트의 개발 환경 및 비즈니스 로직의 구성에 따라서 Domain Layer 부분이 생략 될 수 도 있습니다.
Google 에서도 Domain 은 optional 하게 가이드하고 있어서 상황에 맞게 구성할 것을 추천드립니다.

Mapper 는 왜 존재할까?

Mapper는 API 에서 내려준 DTO(Data Transfer Object)를 UI에 적합한 Entity로 변경하는 기능을 담당하고 있습니다. 이 말은 클린아키텍처 구조에서 설명하자면, Data Layer에서 API 로 전달받은 DTO 를 Domain Layer 에서 UI 에서 사용하기 좋은 형태인 Entity로 변경한다고 보시면됩니다. 다시말해 UI 에서 사용할 데이터는 API에서 내려준 Data와 동일할 필요가 없으며, UI에 최적하게 재배치를 할 수 있는 환경을 Mapper가 제공한다고 이해하시면 됩니다.

Mapper 의 또 다른 존재 이유는 디버깅 환경 구성입니다.
API 가 개발 안된 상태에서 기능 개발은 어려움이 있어 대부분의 회사에서는 API 가 개발되기 전에 Mock 데이터를 제공하고 있습니다.
Mock 데이터 구성을 Mapper를 통해서 UI에 맞춰서 구성한다면, UI와 비즈니스로직 그리고 Mock 데이터 간의 코드 분리 및 의존성을 낮춰 추후 API 개발 완료 시 Mock 데이터에서 API 데이터로 연결만 변경하여 쉽게 Data 전환이 가능합니다.

마무리

클린아키텍처에 대해서 간단히 알아보고 어떻게 Android 에서 클린아키텍처를 구성에 대해서 간략히 가이드하였습니다.
아키텍처를 왜 사용하는지에 대해서 의문을 갖고 있는 분들이 있을 것입니다.

필자가 생각하기에는 아키텍처는 협업의 소통 도구라고 생각됩니다. 코드로 소통하는 개발자는 보통 사람과의 대화보다 명확히 의사 전달을 하고 있습니다. 따라서 인수인계를 위해서 몇 시간 회의실에서 인수인계를 진행하는 것보다 아키텍처를 소개하고 아키텍처의 구조에 맞춰 개발할 것을 가이드한다면, 코드의 통일성 및 가독성이 올라갈 것입니다. 이점을 참고해서 클린아키텍처를 도입하는 것을 고려해도 좋을거 같습니다.

클린아키텍처의 대한 자세한 내용은 Medium(왜 Android 신규 프로젝트는 클린 아키텍처를 도입하였는가? ) 에서 확인할 수 있으며, 본 기술블로그에 등재된 '같이보면 좋은글'의 클린아키텍처 관련 글을 읽는 것도 추천드립니다.

미션차이나센터 개인정보 취급방침

규샤인 — Tue, 22 Oct 2024 23:30:02 +0900

개인정보취급방침

1. 수집하는 개인정보 항목
이 앱은 사용자의 개인정보를 수집하지 않습니다. 다만, 앱의 정상적인 기능을 제공하기 위해 일부 기본적인 데이터(예: 앱 사용 기록, 오류 보고)가 자동으로 수집될 수 있습니다.

2. 개인정보 수집 목적
수집된 데이터는 앱의 성능 개선 및 오류 수정 목적으로만 사용됩니다. 이 정보는 어떠한 개인 식별 정보를 포함하지 않으며, 광고나 마케팅 목적으로 사용되지 않습니다.

3. 개인정보 보유 및 이용 기간
이 앱은 개인정보를 저장하지 않으며, 자동 수집된 데이터는 문제 해결 및 성능 개선을 위한 용도로만 사용된 후 즉시 삭제됩니다.

4. 개인정보 제3자 제공
사용자의 개인정보를 제3자에게 제공하지 않습니다.

5. 이용자의 권리
이 앱은 개인정보를 수집하지 않기 때문에 별도의 권리 행사는 필요하지 않습니다.

6. 개인정보 보호책임자
개인정보와 관련된 문의 사항이 있을 경우 아래의 연락처로 문의해 주시기 바랍니다.

이름 : 신규찬
메일 : dev.faithpeole@gmail.com

고시문헬퍼 개인정보 취급 방침

규샤인 — Sun, 22 Sep 2024 19:43:15 +0900

1. 개인정보의 처리 목적

광고 ID - Google Play 고객센터

support.google.com

가. 애드몹 관련 정보
- 애드몹 : https://admob.google.com/home/

스코어헬퍼 개인정보 취급 방침

규샤인 — Sun, 22 Sep 2024 19:42:51 +0900

1. 개인정보의 처리 목적

광고 ID - Google Play 고객센터

support.google.com

가. 애드몹 관련 정보
- 애드몹 : https://admob.google.com/home/