인프런 커뮤니티 질문&답변
작성한 질문수
다작을 위한 개발방법론에 대해
해결된 질문
작성
·
192
1
안녕하세요.
강의 잘 듣고 있습니다.
다름 아니라, 다작을 손쉽게 하기 위한 개발방법론에 대해 문의드리려고 글을 남기게 되었습니다.
제가 이해한 바로는 클라이언트에는 실질적으로 서버로 appId정보를 바탕으로 UI정보 및 컨텐츠 정보를 요청하면, 데이터를 파싱하고 UI를 뿌려주는 역할을 하는 형태로 이해 했습니다.
이를 통해서, 특정 사용자에게 다른 UI/컨텐츠를 제공하여 A/B 테스트를 쉽게 해볼 수 도 있는 좋은 아이디어라고 생각하였습니다.
다만, UI 정보이다 보니, 색상이나 layout등은 실제로 Android Studio를 editor를 통해서 눈으로 보면서 확인을 하면서 개발을 하는게 더 용이 한게 아닐까 하는 생각을 했는데요.
(말씀하신 개발방법론을 그대로 적용한다면, 새로운 색상과 레이아웃이 구상하는 앱과 맞는지 보려면, 포스트맨을 통해 데이터를 밀어넣고 실제 앱을 띄워봐야 결과를 확인하는 형태일 것 같아 이게 더 개발이 빠른가 하는 의문이 들었습니다.)
이에 대한 개인적인 의견 부탁드려요.
(강사님의 다작 경험을 통해서 수치화된 값만 보아도 UI/layer out이 이제는 머리속에 떠올라서 효율적일 수 있는것인지.. 아니면 다른 분들께도 통용될 수 있는 방식일지 궁금합니다.)
답변 2
0
안녕하세요!
다작 프로세스에 관해서 조금더 몇가지 이야기를 더 드려보자면,
다작 프로세스는 앱을 처음 개발할 때부터 도입하기에는 오버스펙일 수 있습니다. 장기적으로는 좋을 수 있지만, 처음부터 도입하면 '배보다 배꼽이 큰' 상황이 될 수 있어 초기에는 추천드리지 않습니다.
이 프로세스는 보통 앱 개발 경험이 쌓이고, 반복되는 코드나 자주 사용하는 UI 패턴들이 눈에 띄기 시작할 때 도입하는 것이 효율적입니다. 즉, "이런 시스템이 있으면 앱 개발 속도를 더 올릴 수 있겠다"라는 깨달음이 오는 시점에서 도입하는 것이 좋습니다.
모든 것을 처음부터 고려해 설계하는 것이 이상적으로 들릴 수 있지만, 현실적으로는 초기에 무엇을 만들지도 명확하지 않은 상태에서 불필요한 기능까지 구현할 가능성이 높아집니다.
다작 시스템 도입 시점에는 이미 UI나 기능적 데이터가 어느정도는 축적되어 있어, UI나 레이아웃이 어떤 형태가 될지 대략적으로 예측할 수 있는 상태가 된다고 생각합니다. 이 시스템의 핵심은 기능별, UI별 구현 시간을 최소화하고 유연하게 처리하는 것입니다.
포스트맨을 통해 데이터를 넣고 실제 앱을 띄워 결과를 확인하는 부분에 대해서는, 맞습니다. 이런 과정이 필요하지만 효율성을 높일 수 있는 방법이 있습니다.
예를 들어 ViewPager와 여러 콘텐츠를 가진 앱의 경우, 전체 데이터를 한 번에 세팅하기보다 하나의 기능에 대한 내용만 먼저 세팅해두고 확인하는 접근법이 처음에는 효율적일 수 있습니다. 기능별로 나눠서 작은 단위로 테스트하면 작업 부담이 훨씬 줄어들겠죠.
이런 방식을 반복하다 보면 숙련도가 높아져 전체 데이터 세팅 자체도 빠르게는 5분, 길어도 20분 이내에 하나의 앱에 필요한 모든 데이터를 세팅할 수 있게 됩니다. 결과적으로 반복을 통해 익숙해지면 5~20분 만에 하나의 앱을 만들 수 있는 수준에 도달하게 됩니다.
반면, 이런 시스템 없이 일반적인 방식으로 개발한다면, 5~20분 안에 하나의 앱을 만드는 것은 사실상 불가능에 가깝습니다. 매번 새롭게 레이아웃을 디자인하고, 코드를 작성하고, 리소스를 관리하는 과정이 필요하기 때문입니다.
A/B 테스트 관련해서는, 다작 프로세스가 그런 기능도 제공할 수 있지만, 제가 추구하는 주된 목적은 특정 사용자에게 다른 UI를 제공하는 것보다는 하나의 앱을 빠르고 효율적으로 구현하는 데 있습니다.
결론적으로, 다작 시스템의 핵심 가치는 시간 효율성에 있습니다. 처음에는 적응 기간이 필요하고 시스템 구축에 투자가 필요하지만, 일단 익숙해지면 획기적인 개발 속도 향상을 경험할 수 있습니다
0
안녕하세요, 인프런 AI 인턴입니다. bs Jeon님.
질문주신 내용을 바탕으로 다작을 위한 개발 방법론에 대해 설명하고, 관련된 유사한 기존 답변을 제공하려고 합니다.
현재 말씀하신 방법론은 서버로부터 UI 정보와 컨텐츠 정보를 받아와 클라이언트가 이를 통해 필요한 화면을 렌더링하는 방식입니다. 이러한 구조는 UI/UX 변경에 유리하며 특히 A/B 테스트나 다양한 커스터마이즈된 UI 제공 시 장점이 있습니다. 다만 말씀하신 대로 개발자는 실시간 UI 확인이 어려울 수 있습니다. 이를 극복하기 위해 서버 데이터를 로컬 캐싱하거나 개발용 더미 데이터를 활용하여 Android Studio 환경 내에서도 UI 변화를 미리 시뮬레이션할 수 있는 방법을 고려해 볼 수 있습니다. 몇 가지 해결 방안으로는 다음과 같은 것이 있습니다:
로컬 개발 환경 구성: 로컬에 미리 정의된 JSON 혹은 XML 파일을 사용해 빠르게 화면을 테스트 해볼 수 있습니다. 이는 API 요청 없이 로컬 데이터만으로도 UI를 미리 확인할 수 있도록 합니다.
모의 서버 사용: 가벼운 모의 서버를 활용하여 개발 중인 UI를 즉시 테스트합니다. 이를 통해 포스트맨 없이도 필요한 UI 테스트가 가능합니다.
UI 요소 모듈화: 많이 사용하는 UI 컴포넌트를 모듈화하여, 재사용성과 빠른 UI 테스트를 가능하게 합니다.
더불어, 아래 URL에서 관련 질문이 다루어진 방식을 참고하실 수 있습니다:
- UI 자체를 DB에 의존하는 것에 관해: 여기서는 UI를 서버에서 받아오는 구조에 대해 장점 및 정책상의 제한 등을 논의합니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.