구글 플레이스토어 첫 앱 출시기 <안뜰>

 

 

IT 동아리에서 1월부터 시작해 팀원들과 꾸준히 진행한 '안뜰'이 드디어 9월 초에 구글 플레이 스토어에 배포되었다 !

 

안뜰 플레이 스토어 링크 🌱
https://play.google.com/store/apps/details?id=com.umc.anddeul&hl=ko

 

 

첫 앱 출시기 시작합니다 💨

 

 

 

🌱 안뜰

 

'안뜰'은 가족 간 소통을 위한 소규모 SNS 어플리케이션입니다

 

 

주요 기능은 이렇게 4가지가 있습니다

1. 우리 가족만을 위한 작은 SNS 💌

게시글에 사진이나 음성을 올려 서로의 일상을 공유해보세요!
이모지로 게시물에 반응을 남겨보세요.

2. ‘따듯한 잔소리’ 기능

내 가족에게 애정 어린 잔소리가 필요할 때!
가족의 페이지에 직접 체크리스트 만들어주세요 : 상대방의 페이지에 방문해 직접 체크리스트를 만들어보세요.
⇒ 상대방이 체크리스트를 완수하면 알림으로 알려드릴게요.

3. 우리 가족 우체통

가족에게 마음을 담은 편지 보내기
하루 한번, 매일 가족의 관계를 애틋하게 해줄 수 있는 질문을 제공합니다.

질문에 대한 답변을 작성하고, 받는 이를 선택해서 보내보세요!
→ 편지를 쓰면 우리 가족 정원을 꾸밀 수 있는 포인트를 얻을 수 있어요.
+) 타자를 치기 어려운 사용자를 위해 녹음 기능도 제공합니다.

4. 안뜰 정원 꾸미기: 마음을 나눌수록 성장하는 정원 💗

서비스 사용 중 얻은 포인트로 가족과 함께 화분을 길러보세요.
마음을 나누고 우리 가족의 안뜰을 꽃 피워 보세요!

 

 

 

 

 

🌱 팀

기획자 1명, 디자이너 1명, 백엔드 3명 (중간에 한분이 나가서 최종적으론 2명,,), 안드로이드 3명

 

 

 

 

 

🌱 기획

기획은 기획자님이 와이어프레임을 토대로 설명을 해주시고 본격적으로 개발에 들어가기 전에 실질적으로 구현하기 힘들 것 같은 부분이나, 이렇게 만들었을 때 사용자들이 불편할 것 같은 부분들을 회의하고 수정하는 단계를 거쳤다

 

따로 기획자님이 계셔서 앱 아이디어에 대한 큰 틀이 잡혀져 있는 것은 좋았지만

기획자님과의 협업은 처음이였는데 왜 개발자랑 기획자랑 의견 충돌이 많이 일어난다고 하는지 알 것 같았다

(싸웠다는 말은 아닙니다.. ㅎㅎ)

 

그렇지만 오히려 좋았다!

 

이런 저런 의견을 이야기하면서 나도 앱에 대한 이해도가 훨씬 올라갔고 사용자 입장을 더욱 많이 고려하게 되었다

우리도 앱을 개발할 때 어떤 기능을 어떻게 초점을 맞춰서 구현해야 할지에 대해 더 고민할 수 있게 되었고, 기획자님이 추후에 어떤 기능들을 더 추가하고 싶은지, 나중에 새로운 기능이 추가될 가능성을 열어두고 어떻게 개발하면 될지 등에 대해 생각하는 시간을 가질 수 있어서 부딪히고 계속해서 회의한 시간들이 의미있었다

 

그리고 회의를 하며 생각보다 개발을 하는 사람과 직접 개발을 하지 않는 사람의 입장 차이가 크다고 느껴졌다

 

예를 들어 우리는 마이페이지를 하단 바텀 네비게이션에 두어 사용자에게 직관적으로 보이게 두고 싶었는데 기획자님은 홈에서 버튼을 몇 단계 타고 들어가 마이페이지를 보이게 하고 싶어하셨다

나는 이렇게 하면 화면이 계속 쌓이기도 하고 SNS 종류인 우리 앱의 특성 상 사용자 입장에서 본인 피드를 확인하기 너무 어렵지 않을까 하는 생각이 들었다

 

물론 다행히 서로 이야기를 통해 여러 부분을 잘 조율했다

 

처음엔 기획해주신대로 개발하면 되겠지 싶었는데 생각보다 함께 논의해야 할 부분들이 많았고, 이 과정에서 사용자 입장을 많이 고려해보게 되었다

그리고 역시 팀원들끼리 서로 의견을 많이 나눠야 더 좋은 시너지를 낼 수 있는 것 같다

 

 

 

 

 

🌱 디자인

피드백과 수정의 현장 ..

 

 

디자이너님과의 협업도 처음이였는데 개발 초기엔 디자이너님이 해주신 디자인과 직접 에뮬에 돌렸을 때 버튼이나 UI 요소들의 크기가 묘하게 달라서 굉장히 애를 먹었다

 

디자이너님은 px 기준으로 작업을 해서 넘겨주시고 우린 dp 단위로 작업을 해서 생겼던 문제인 것 같다 😂

 

그리고 초반엔 다양한 기기에 대한 대응을 생각하지 못해서 디자이너님이 해주신대로 크기 지정을 해서 만들었는데 나중엔 최대한 dp 지정보단 constraintLayout과 match_parent를 많이 활용해서 수정하였다

 

피그마에 있는 디자인을 안드로이드 스튜디오에서 xml로 작업하다보면 약간은 디자인과 다르게 나오는 부분들이 있었는데 주위 현업자분들께 여쭤보니 일정 부분은 어쩔 수 없는거라고 하셨다 최대한 디자이너님이 작업해주신대로 똑같이 나오면 좋겠지만 불가능한 부분은 디자이너님과 상의해서 조율해나가야 한다고..!

처음엔 내가 마냥 디자인의 디테일을 잘 몰라서 제대로 표현해내지 못하나 싶었는데 상상과 구현의 현실에서 약간의 갭 차이는 어쩔 수 없는 부분인 것 같다

 

그리고 화면에서 볼 때와 달리 직접 기기에서 돌리면 크기가 너무 작아 눌리지 않는 버튼들이 있어 이런 부분도 디자이너님과 상의하며 크기를 조절했는데 이 과정에서 디자인을 눈으로 볼 때와 직접 사용할 땐 또 정말 다르다는 생각이 많이 들었다

 

특히 핸드폰은 작은 화면 속에서 손가락으로 터치를 해야하니 사용성을 방해해선 안된다는 것을 많이 느꼈다

역시 기획도 디자인도 개발도 뭐든 사용자 중심으로 생각해야 한다고 많이 느꼈다 

 

 

 

 

 

🌱 개발하면서 느낀 점

 

1) 전체적인 코드 구조

 

안드로이드 팀원 2명과 함께 협업을 하기 위해서 앱 모듈 내에 각 파트 별 패키지를 만들고 또 그 안에 model, network, service 패키지를 나누어 작업을 진행하기로 했다

 

함께 한 안드로이드 팀원분들이 모두 안드로이드 프로젝트가 처음이라 내가 이렇게 나눠서 작업하자고 주도했는데 사실 나도 초반엔 패턴 적용이나 아키텍처에 대해 잘 알지못해서 나름 코드 분리를 하려고 패키지를 나눠서 진행했던 건데 지금 보니 코드 분리가 거의 안되어있는 수준 ..ㅎㅎ

 

그래도 나중엔 중복되는 코드를 조금이나마 줄여보고자 TokenManager, RetrofitManager를 따로 만들어 토큰과 retrofit 사용 시 TokenManager, RetrofitManager에서 함수를 호출하여 사용하도록 수정했다

하나씩 수정을 하다보니 코드 양이 조금씩 줄어드는 모습을 보고 이래서 코드를 분리하고, 계속해서 로직을 수정하는구나 싶었다

 

그리고 이후엔 토스트바를 띄우는 UI 코드들도 함수로 만들고 토큰 유효기간이 끝났을 시 로그아웃 api를 호출하는 등의 확장함수도 만들어서 적용을 하려고 수정하고 반영해보았다

 

중간에 다른 프로젝트에 클린 아키텍처를 적용해서 진행하고 배우며 안뜰에선 비교적 패턴이나 아키텍처를 적용하지 못했던 부분이 많이 아쉬웠지만 통 코드를 조금씩 분리해 나가며 코드 분리의 중요성을 직접 고생하며 다 느낀 것 같다 ㅎㅎ

 

 

 

2) 버전 별 대응

 

이전의 개발들은 주로 배포까진 생각하지 않았기 때문에 에뮬레이터 혹은 테스트폰에서 실행하는 게 끝이였다

그래서 대부분 나는 늘 최신 버전의 에뮬을 사용하기 때문에 버전 분기에 많이 신경을 쓰지 않았는데 갤러리와 같은 권한을 받아야 하는 것들은 버전 분기를 꼼꼼하게 해줬어야 했다

 

    private fun isPhotoPickerAvailable(): Boolean {
        return if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.TIRAMISU) {
            true
        } else if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.R) {
            getExtensionVersion(Build.VERSION_CODES.R) >= 2
        } else {
            false
        }
    }
    
    
     private fun settingBtn() {
        binding.homeFloatingBt.setOnClickListener {
            if (isPhotoPickerAvailable()) {
                startPhotoPicker()
            } else {
                checkPermission()
            }
        }
    }

➡️ 포토피커 버전 별 분기

 

안뜰에선 포토피커를 사용하며 갤러리를 열 때 버전 분기를 해줬었는데 포토피커가 Android 12 일부 버전 이상부터 지원을 해주기 때문에 그 이전 버전에선 그냥 문서 편집기가 열려서 조금 당황스러웠다 그리고 이미지 다중 선택을 위해 포토피커를 사용했던 것인데 문서 편집기에선 다중 선택이 안되기 때문에 낮은 버전을 위한 이미지 선택은 또 다른 방법을 구현해야 하는 게 참 고민이 많았다

 

그래서 처음엔 버전 별 포토피커를 열지 or 기본 갤러리를 열지만 분기처리해서 대응해주면 된다고 생각했는데 이런 사항들을 모두 대응하려면 생각보다 버전 별 대응에서 뻗어나가는 코드들이 더 많이 필요했다

 

그렇지만 다양한 사용자를 위해선 어쩌겠어 해야지 .. 😂

 

 

 

3) 안드로이드 공식 문서 참고하기

 

이전에 개발을 하다가 모르는 부분이 있을 땐 대부분 구글링을 하며 개발 블로그 글들에 의지를 많이 했었는데 이번에 안뜰을 진행하며 안드로이드 공식 문서를 조금씩 찾아보게 되었다

 

공식 문서를 한글로 번역하면 표현들이 조금 어색해지긴 하지만 어떻게 사용해야 할지 모르는 기술들에 대한 상세한 가이드와 예제 코드가 잘 제공되어 있었고, 보다 안정적이고 효율적으로 앱을 개발하는 데에 도움이 되었던 것 같다

 

나는 특히 위에서 얘기했던 포토 피커나 갤러리와 관련된 기능들, 버전 분기, 런처 사용 등을 할 때 도움을 많이 받았다 갤러리는 기본적으로 안드로이드에서 제공해주는 앱이기 때문에 따로 내가 컨트롤 할 수 없는 부분이라 어려웠는데 이 때 공식 문서를 읽으며 갤러리를 최대한 활용할 수 있는 방안을 많이 찾아봤던 것 같다

 

그리고 공식 문서를 뒤적이며 새로운 인사이트도 종종 얻어가서 앞으로 안드로이드 공식 문서를 더 적극적으로 활용해야겠다는 생각이 들었다 ㅎㅎ

 

 

 

4) 기획자 & 디자이너와의 협업

 

혼자 개발을 할 때는 버튼의 위치라던가, 기능의 일부를 수정하고 싶다던지 할 때 그냥 혼자 바꾸고 싶은대로 바꾸면 됐었는데 기획자 & 디자이너님과 함께 협업을 하다보니 어떤 문구 하나를 추가한다던지 버튼 위치나 크기를 수정한다던지 사소한 것 하나 변경을 할 때에도 기획자님을 거쳐, 디자이너님을 거치고나서야 수정을 할 수가 있었다

내 마음대로 수정을 하면 기획의 본래 의도가 왜곡될 수 있고, 디자인의 완성도가 떨어질 수 있기 때문에 모두의 컨펌을 받아야 했다 (물론 협업이니 당연한 과정 !)

 

그래서 간단한 수정 사항이 생겨도 기획자님 - 디자이너님 - 개발자 한 사이클을 돌아야 했기 때문에 시간이 꽤 걸릴 때도 있었지만 체계적으로 일을 분담하고 그 과정에서 각자 자신의 역할에 집중하여 서로의 의견을 공유할 수 있는 기회가 많이 생겨서 좋았다

이 과정을 통해서도 내가 생각하지 못했던 기획이나 디자인 부분에 대해서도 많이 배우고 번뜩 하는 부분도 꽤 있었다

 

데모데이를 준비하는 과정에서 백엔드분이 이모지를 남기는 API를 완성을 못하셔서 개발자들끼리 (안드로이드 & 백엔드) 급한대로 이모지 대신 인스타그램처럼 단순하게 하트를 눌렀다 취소하는 방식으로 변경하자는 의견이 나왔었고, 추후에 기획자님에게 전달을 했더니 기획자님이 그렇게 변경하면 기존의 의도와 너무 달라지기 때문에 안될 것 같다는 반대 의견을 주셨고 그 때 조금 아차 싶으면서도 기획의 의도를 다시 바로잡을 수 있어서 다행이라는 생각을 했다 그러면서 나도 해당 기능의 의도에 다시 생각해보며 어떻게 해야 해당 기능의 의도를 더 잘 표현하며 구현해낼 수 있을까에 대한 고민을 하게 만들어준 시간이었다

 

 

 

 

 

🌱 출시를 준비하며 느낀 점

 

1) 반응형 UI

 

1월 중순부터 2월 초까지 데모데이를 준비하며 개발했던 안뜰을 배포를 위해 수정을 시작하자 정말 고쳐야 할 것들이 많았다

데모데이는 테스트 폰에서, 우리의 통제 하에서 진행이 되지만 배포는 다양한 기종에 대응을 해야하기 때문에 이 부분이 어렵고 힘들었다

 

다양한 기종에 대응하는 것 가장 첫번째인 UI부터 반응형 UI로 모두 수정을 시작했다

이미지 같은 경우 일부는 어쩔 수 없이 dp로 지정을 해줘야 하는 경우를 제외하곤 width, height는 최대한 지정된 Dp값 보다는 주변의 View와의 관계들로 설정하고 wrap_content, match_parent를 최대한 활용했다

 

그리고 유용하게 많이 사용했던 속성 중 하나가 layout_constraintDimensionRatio=”1:n” 인데 이미지의 크기를 비율로 설정할 수 있는 속성이다 특히 화면 가로 크기에 꽉 차게 정방향 사진 피드를 올릴 때 아주 유용하게 잘 썼다 !

가로는 match_parent를 하면 되는데 가로에 맞게 기기마다 달라지는 세로 크기를 어떻게 구할지 고민이였는데 layout_constraintDimensionRatio=”1:1” 속성 하나면 해결 !

 

 

 

2) 실제 사용자 환경

 

출시는 반응형 UI와 더불어 더 이상 테스트폰이 아닌 진짜 사용자 핸드폰에서 실행되어야 하기 때문에 사용자 환경과 그와 연관된 다량의 데이터들을 생각해야 했다 

 

특히 이와 관련해서 개인적으로 가장 아쉬웠던 부분은 게시글을 작성할 때 커스텀 갤러리 형식으로 구현을 해야 하는 파트가 있었는데 데모데이 때는 커스텀 갤러리로 구현을 했지만 배포를 준비하며 앱의 안정성을 생각해서 기본 갤러리를 여는 방식으로 수정했던 것이다

 

데모데이 때는 테스트 폰의 갤러리에 사진이 많이 없어서 갤러리를 불러오는데 많은 시간이 걸리지 않았지만 실제 유저의 핸드폰엔 굉장히 많은 사진이 있기 때문에 불러오는 과정에서 안정성을 보장하기가 쉽지 않았고 이러한 구현을 나 혼자 해내기엔 조금 부족해서 일단 안정성을 우선으로 생각해 기본 갤러리를 여는 방식으로 수정하였다

 

( + 이때 갤러리를 어떻게 구현할지 정말 고민이 많았는데

1) 기획에 맞게 어떻게든 커스텀 갤러리 구현

2) 포토피커 사용

3) 외부 라이브러리 사용

 

1번은 아무리 생각해도 현실적으로 불가능 할 것 같았다 사진을 불러오는 데에만 한 세월이 걸릴 것 같았고 어떻게 보면 글을 올리는 것이 SNS의 메인 기능인데 메인 기능부터 제대로 사용하지 못한다면 앱의 의미가 없는 것 같았다

3번은 종종 Deprecated 되는 경우도 있고 해당 라이브러리 git에서 이슈들을 살펴보았는데 종종 버그가 있는 것 같아서 차라리 google에서 내준 라이브러리가 조금 더 안정성이 있지 않을까 싶어서 최종적으로 포토피커로 진행하게 되었다

 

이 과정에서 외부 라이브러리를 무작정 가져다 쓰기보단 해당 라이브러리의 이슈도 살펴보고 같은 기능을 다양한 방면으로 구현할 수 있음을 배웠다)

 

내가 유저로써 앱을 사용할 때 앱이 갑자기 꺼지는 경우가 가장 당황스러웠기 때문에 배포를 준비하며 안정성을 가장 우선으로 생각했던 것 같다 적어도 우리 앱을 사용하면서 앱이 갑자기 꺼지는 경우는 없었으면 했다

 

 

 

3) 구글 심사 준비

 

앱을 배포하기 위해서 안드로이드 스튜디오에서 늘 사용하던 기능들이 아닌 release build, 난독화 등을 진행하며 새로운 기능들을 처음 접하게 되었다

 

이전까지 안드로이드 스튜디오는 코드 구현용으로만 사용했었는데 몰랐던 다양한 기능들이 정말 많았다 특히 난독화는 필수는 아니지만 현업에서 필수라는 이야기를 들어서 진행해보았는데 겁을 먹은 거에 비해 어렵지 않았다

다만 "필요한 만큼" 난독화를 해주어야 해서 정답이 없는 "필요한 만큼"의 기준이 가장 어려웠던 것 같다 그래도 최대한 난독화를 하고 싶어서 최소한의 것들만 예외처리를 해주려고 했다

 

이렇게 안드로이드 스튜디오에서 배포 준비를 마치고 이제 드디어 Google Play Console에서 제대로 배포를 진행할 차례다 !

 

작년 (23년) 11월부터 배포를 위해선 20명 이상의 테스터들의 대상으로 2주 비공개 테스트를 필수로 진행해야 했는데 테스터를 모으는 것도 은근 쉽지 않았다 그래서 심사만 잘 받으면 금방 배포할 것이라고 생각했던 것과 달리 시간이 꽤나 소요됐던 것 같다

 

그래도 비공개 테스트를 하면서 몰랐던 버그도 많이 발견하고 똑같이 기기에서 실행하는 것이지만 테스트 폰에서 실행할 때와 테스터들의 기기에서 실행할 때는 또 다른 버그들이 발견되어서 당황스럽기도 하고 비공개 테스트의 중요성을 많이 깨달았다

 

 

🌱 출시 후 느낀 점

 

2차례의 구글 심사와 비공개 테스트를 거치고 다행히 리젝을 한번도 받지 않고 한번에 배포를 하게 되었다

다들 리젝을 많이 받던데 한번도 안받아서 감사하면서도 신기했다..ㅎㅎ

 

 

 

1) 에러처리

 

비공개 테스트와 배포 후 지인들에게 사용 후기와 새로 발견된 버그들을 들으며 참 기쁘기도 절망스럽기도(?) 했다

기종 별 예상치 못한 버그는 다양했고 에러가 나면 바로 로그가 뜨는 에뮬과 달리 사용자의 핸드폰에선 당장 에러 원인을 파악할 수가 없기 때문에 버그가 발생했다는 이야기를 들을 때마다 심장이 조마조마했다

 

기획자님도 우리도 에러 처리에 대한 부분을 크게 생각하지 못해서 에러 처리를 서버 연결을 실패했을 때에만 토스트 바를 띄우도록 에러처리를 해둬서 그 외의 상황에선 무엇 때문에 에러가 났는지 알기 어려웠다

주위 지인들이 테스트를 하며 버그가 생길 때마다 "이거 왜 안돼?" 라고 물어봐 주었는데 나는 아 이것 때문인가? 저것 때문인가? 혼자 생각을 하지만 사용자 입장에선 버튼을 눌러도 아무 반응이 없으니 당황스러울 수 있겠다는 생각이 들었다

 

에러 처리의 중요성을 새삼 느끼게 되었던 .. 🥲

 

그리고 서버가 몇몇 부분 제대로 동작하지 않는 부분이 있었는데 이런 부분이 조금 속상했다 (이래서 에러처리를 더 확실하게 해야 하는 거겠지..?)

 

 

 

2) 우리의 기획 의도는 ...

 

비공개 테스트를 진행하며, 출시 후에 사용자는 생각보다 더 직관적인 기능들에 관심이 많다는 것을 많이 느꼈다

조금이라도 숨겨져 있는 기능의 경우 모르는 분들도 많았고 덜 직관적인 부분들은 어떻게 사용하는 건지 모르는 분들도 계셨다

 

작은 핸드폰 화면의 특성 상 모든 버튼과 기능들에 주저리주저리 설명을 달아놓을 수 없으니 직관적으로 사용자가 어떤 기능인지 알 수 있게 하는 게 참 중요하다는 것을 많이 느꼈다 그리고 가족 앱이다보니 자녀 세대와 부모 세대가 같이 이용하는 것이 목적인데 자녀 세대와 부모 세대에서도 버튼의 모양이나 표시를 보고 이해도 차이가 조금 있다고 느껴졌다

 

사용자의 연령층이 올라갈 수록 더 직관적이고 쉽게 만들어야 하는 것 같다 ..!

 

그리고 피드에서 부담없이 일상을 공유하라는 의미에서 댓글을 없애고 이모지만 남길 수 있도록 구현을 해두었는데 우리의 기획 의도와 달리 왜 댓글이 없고 묻는 분들이 꽤 많았다 나중에 설명을 드리긴 했지만 앱을 처음 설치한 사람들에겐 기획 의도가 제대로 전달되지 않을 수 있겠구나 싶어서 조금 아쉬웠다

 

그래서 앱을 처음 설치했을 때 앱 가이드가 필요한가 하는 생각이 들었다

 

 

 

3) 크래시 리포팅

 

Google Play Console에서도 앱의 비정상 종료에 대한 리포트를 제공해주지만 뭔가 코드를 고치면서 바로바로 확인할 수 없어서 개인적으로는 조금 불편했다

 

그런데 그러던 도중 ..!

 

App Quality Insights에서 Google Play Console과 연결

 

안드로이드 스튜디오의 App Quality Insights에서 Google Play Console과 연동하니 안드로이드 스튜디오에서 어떤 기종에서 어떤 에러가 발생했는지 모두 확인 가능했다 !

 

위에서 말했듯 물론 Google Play Console에 가서도 에러 사항을 확인을 할 순 있었지만 뭔가 개인적으로는 작업하면서 에러 사항을 바로 확인하기에 조금 불편하다고 생각했는데 이 기능을 활용하니 안드로이드 스튜디오에서 어떤 에러가 발생했는지 바로 바로 확인하고 원인을 파악할 수 있어서 좋았다

 

테스터 핸드폰에서 이유도 모르는 에러가 발생한 채로 앱이 꺼질 때마다 참 당황스러웠는데 이런 부분들의 버그를 잡는데에 큰 도움이 될 것 같다

 

 

 

 

 

🌱 느낀 점

 

내가 만든 앱을 지인들이 사용하는 모습을 보고 뿌듯하기도 했지만 버그가 발생할 땐 정말 마음이 아팠다

 

한번 발생한 버그들로 유저들에겐 '이거 왜 안돼? 이 앱 잘 안되는데' 라는 인식을 남길 수 있다는 게 조금 슬프기도 하고 더 열심히 해야겠다는 원동력이 되기도 했다

 

특히 다양한 기종과 각자의 사용 환경에 모두 대응하는게 정말 쉽지 않다는 것을 느꼈고 새삼 우리가 사용하는 앱들에 대단함을 느꼈다 .. ㅎㅎ 나도 더 공부해서 안정성 있는 앱을 만들고 싶다는 생각이 많이 들었다

 

안뜰과 동시에 다른 프로젝트를 진행하며 아키텍처에 대해 많이 배웠는데 나중에 기회가 된다면 안뜰도 다시 아키텍처를 도입해 리팩토링을 진행하고 싶다 !!

 

이제 막 출시가 되어서 앞으로 팀원들과 더 이야기를 해봐야겠지만 유지보수를 할 수 있도록 해봐야지

사용자가 생기면 앱을 계속 개발할 큰 동기부여가 된다고 들었는데 간간히 들려오는 사용 후기를 들을 때마다 힘이 많이 났던 것 같다 :)

 

두번째 앱 출시기도 금방 작성할 수 있길 바라며

첫번째 앱 출시기 끝 !

 

 

안뜰 많관부 ~ 🌱🤍