'뀨'의 Android - dev-blog

2025년에 난 뭘 했을까..?

o0뀨0o — Mon, 9 Feb 2026 02:07:02 +0900

오늘은 25년에 나는 무엇을 했는지 회고하는 블로그를 작성해보려 한다.
상반기 중반기 하반기 이렇게 3단계로 나눠서 이야기하겠다!

1. 상반기(1월 ~ 4월)

나는 2학년 때 포트폴리오와 이력서를 완성시켜 두고 방학 때 계속해서 피드백을 받아가며 수정하던 시기였다.

겨울방학을 시작하자마자 태윤이와 주말을 제외하고 하루도 빠지지 않고 학교로 나와서 같이 공부하며 시간을 보냈다.(1달? 2달 정도) 방학에 매일 늦게라도 학교에 나오는 게 지금 생각하면 정말 귀찮을 것 같은데 그때는 어떻게 그렇게 했는지 모르겠다.. 때로는 학교에서 공부하다가 24시간 카페로 가서 또 공부를 하곤 했다.(정신력으로 버텼다..) 그냥 이때는 개발이나 공부나 모든 것이 재밌던 시기였다.

이렇게 생활을 하다 보니 1차 포트폴리오와 이력서가 빨리 만들어져서 입사지원을 해볼 수 있었다.
4곳을 지원해서 한 곳의 회사에서 연락이 왔다.
나름 규모가 있었던 회사였지만 아쉽게도 채용까지 이어지진 못했다.

중간중간에 해커톤이 있어서 친구들과 같이 나가서 재밌게 개발하고 놀고 왔던 기억도 있다..
이때 나는 아이디어만 내고 팀원들이 개발을 주로 했었는데 최우수상을 타서 기분만 좋았다.

겨울방학은 한 줄로 정리하면 공부하며 즐길 것도 다 즐겼던 지금 생각해도 만족스러운 시기였다.

3, 4월에도 뭐 항상 똑같이 포트폴리오와 이력서를 완성도 있게 계속해서 수정하고 공부했었다.
졸업앨범 사진도 찍으면서 이제 진짜 졸업이 얼마 안 남았다는 생각도 들어 취업에 대한 압박감이 생기기 시작한 시기이기도 하다.

2. 중반기(5월 ~ 8월)

이 시기는 두려움과 걱정으로 가득 찬 시기였다.

5월에는 여보야라는 광주기업의 회사에 입사할 수 있는 기회가 생겼다.
솔직히 여보야 만큼 나에게 좋은 회사가 없다고 생각했다. 왜냐하면 나는 서울로 가기보다는 지방에 있기를 더 선호했고 여보야에는 우리 학교의 선배들도 있었기 때문이다.

나는 이번 기회를 무조건 잡아야 한다고 생각하고 지원을 하고 서류합격을 하였다.
서류합격 이후 나는 면접준비를 바로 시작하고 얼마 되지 않아 면접을 봤지만.. 결과는 좋지 않았다.
이때 조금 현타가 많이 왔던 것 같다.
그냥 나의 모든 행동을 돌아보며 자책을 했던 것 같다.

주변 사람들한테는 티 내지 않고 평소에 하던 대로 생활을 이어갔다.

여름방학이 시작하고는 친한 2학년 후배들이랑 태윤이랑 상혁이 이런 친구들이랑 카공을 많이 하면서 이력서를 다시 한번 갈아엎었다.
그리고 처음으로 학교에서 몰래 잠도 자봤다.. 정말 덥고 힘들었지만 재밌는 경험이었다.

8월에 개학하고는 좋은 소식이 정말 많이 있었다.
배드민턴 교육감배를 우승하고 취업까지 했던 달이였다.

하지만 한 가지 큰 문제가 있었다...

3. 하반기(9월 ~ 12월)

이 시기는 취업으로 인한 걱정, 스트레스보다 오히려 재밌게 보냈던 시기였다.

위에서 말한 큰 문제는 합격한 회사가 아직 내가 가기도 전인데 너무 나와 문화가 정 반대인 회사였기 때문이다.
나는 연봉을 적게 주더라도 무언가를 배울 수 있는 분위기를 가장 선호한다. 즉, 적어도 회사에 같은 전공의 사수 한 명쯤은 있어야 한다고 생각을 했다.
하지만 이 회사는 사수도 없고, 혼자서 일을 해야 한다는 사실이었다.
그래서 엄청나게 고민하고 그냥 이 회사를 안 가겠다고 스스로 결정했지만 학교 선생님들은 그래도 한 번은 가보는 게 좋지 않냐 라는 느낌으로 말해서 어쩔 수 없이 입사를 하게 되었다.

역시나 입사를 하고 나와 너무 맞지 않고 성장할 수 없는 회사에 적응해 가는 내가 걱정이 되어 할당받은 업무는 끝내고 퇴사하였다.

퇴사하고는 오히려 별 생각이 없었다.

그냥 하던 대로 하자라는 생각만 있었다.
포트폴리오와 이력서를 다시 한번 갈아엎고 여러 사람들에게 피드백을 받았다.

9월 말에는 또 다른 회사에 합격하여 입사할지 최종 결정을 해야 했었다.
하지만 해당 회사도 판단했을 때 미래가 보이지 않아서 입사를 거절했다.

이 이후로는 그냥 학교생활을 제대로 즐겼다.
취업 스트레스로 남은 학교생활을 망치기 싫었기 때문이었다.

선생님들이 언제 취업할 거냐, 다시 언제 나갈 거냐, 열심히 하고 있냐 등등 계속해서 취업 압박을 하셨지만 앞에서만 열심히 하고 있다고 하고 뒤에서는 그냥 놀았다.

10월은 그냥 시원하게 놀았던 것 같다.

11월이 되면서 슬슬 현타가 오기 시작했다.

이렇게 아무것도 안 하고 놀기만 하니깐 나 자신이 오히려 무너지고 있다는 생각을 했다.
그래서 졸업식 때까지 빨간 날 주말 하루도 빠지지 않고 todo 작성과 일기를 쓰며 최소한의 루틴을 만들어가려 노력했다.

처음부터 목표를 크게 잡으면 빨리 무너지기 마련이다.

그래서 나는 간단하게 책 한 파트씩 읽기 혹은 내가 도와주고 있던 8기 학교기업 프로젝트에 대한 계획을 세부적으로 작성했다.(잘 지켜지지 않은 날도 많이 있었다.)

todo 희망편

todo 절망편

꾸준히 무언가를 한다는 것에 초점을 두었기 때문에 그래도 만족스럽다.

졸업에 가까워지면서 조금 해이해지긴 했다...

계속 즐겁게 학교 생활을 하다가 12월이 넘어가고 이제는 진짜 취업을 해야 할 것 같아서 다시 포트폴리오와 이력서를 보완하고 지원을 넣기 시작했다..

결국은 졸업식 하루전날에 취업을 하였다!

중간에 많은 내용들이 빠져서 내용 구성이 이상하게 느껴질지 모르겠다.
하지만 나의 필력은 여기까지가 한계인 것 같다..

더 많은 일들도 많아 다소 어색하게 느껴질 수 있겠지만, 이 시기는 나에게 솔직하고 중요한 시간이였다.

4. 2026년에는 목표가 있어?

당연히 목표가 있다.

1. 취업했다고 본인 전공 공부를 게을리하지 말자

* 개인적인 학습 계획을 세워두었고, 꾸준히 이어갈 예정이다.

* 안드로이드

* ai

2. 운동(배드민턴) 규칙적으로 하기

* 지난주부터 실천 중이다.

* 월 수 금 퇴근하고 배드민턴 하기!

3. 경제공부하기

* 개발 외에도 스스로 부족하다고 느낀 부분을 보완해 나가보자!

4. 내 자신에게 관대해지지 말자

* 쉽게 만족하지 말자

이렇게 나의 2025년 회고록과 2026년 목표 및 계획을 일부 작성해 봤다!
화이팅@!

로버트 C. 마틴 "Clean Code"를 읽어보여 느낀점 - part1

o0뀨0o — Tue, 25 Nov 2025 18:27:24 +0900

이번 포스트에서는 로버트 C. 마틴의 "Clean Code"라는 도서를 읽어보며 느낀 점을 써보려 한다.

1. "Clean Code"를 읽게 된 이유

요즘 필자 본인은 학교에 있는 시간이 많아지면서 그동안 생각만 하고 읽어보지 못했던 도서들을 읽을 시간이 생겨 이번 기회에 많은 책들을 읽게 되었다.

그중 하나가 로버트 C. 마틴의 "Clean Code"이다.

매일 아침에 하루 계획을 세울 때 하루 한 파트씩 읽기로 고정시켜 두고 계속해서 읽는 중이다.
지금은 제11장 "시스템"까지 읽었다.

2. 제11장까지 읽으며 느낀 점

먼저 이해하기 어려운 파트들을 존재해서 읽는데 시간이 조금 오래 걸렸다.

이번에는 제1장, 2장, 4장에 대한 이야기를 해보겠다.

제1장 - 깨끗한 코드

깨끗한 코드는 단순히 동작만 하면 되는 코드와는 수준이 다르다.

저자가 강조하는 깨끗한 코드는 "한 가지 일을 잘" 하면서도 명확하게 그 목적과 구조를 드러내는 코드이다.

즉, 처음 보는 개발자도 설계자의 의도를 쉽게 파악할 수 있어야 한다는 것이다.

실제로 지금까지 본인이 했었던 프로젝트에서 코드를 짤 때 가독성을 생각하며 짜긴 했지만 그 코드가 정말 가독성이 좋다고 말할 수 있을까?라는 질문을 하며 진짜 가독성이 좋은 코드에 대해서 다시 생각해 볼 수 있는 기회가 되어 좋았다.
또한 실무에서 잠깐에 급급해 작성한 더러운 코드는 결국 팀 전체의 생산성을 해치게 되고 결국은 이런 더러운 코드를 이해하고 유지보수하느라 작업 속도가 느려지게 되고 일정이 촉박해짐에 따라 계속해서 더러운 코드를 짜는 악순환이 반복되는 상황이 생기는 것을 실제로 봤었기 때문에 더 느끼는 것이 많았다.
그리고 "보이스카우트 원칙"이 가장 기억이 남았다. 이는 지나가기 전보다 더 깨끗하게 유지하는 습관을 가져야 한다는 것이다.
앞으로 개발하면서 위와 같은 느낀 점을 토대로 개발에 임해야겠다.

제2장 - 의미 있는 이름

의미 있는 이름 이는 코드의 이름이 단순한 식별자의 넘어서 의도를 명확하게 전달하는 중요한 역할을 한다는 점을 강조하는 것이다.
코드의 변수, 함수, 클래스 이름은 그 자체로 목적과 역할을 설명할 수 있어야 불필요한 주석 없이도 누가 보아도 쉽게 이해할 수 있는 깨끗한 코드가 된다.

그릇된 정보를 주면 안 된다. 와 영어 이름을 쓸 때는 발음과 검색이 쉽게 하여 협업과 유지보수를 용이하게 해야 한다.
이러한 부분을 읽으며 지금까지 프로젝트에서 필자 본인이 함수 이름을 정할 때 위와 같은 고민을 하지 않고 그냥 생각나는 대로 찍어냈다는 사실을 인지하고 반성했다.
나중에 기회가 된다면 기존 프로젝트에서 네이밍 컨벤션을 합의하고 일관되게 사용하여 코드 품질을 향상해보려 한다.

제4장 - 주석

해당 파트는 깨끗한 코드 작성에서는 주석이 기본적으로 없어야 한다는 원칙을 제시한다.

주석은 코드가 자신의 의도를 스스로 표현하지 못하는 부분을 보완하는 필요약이며 가능하면 주석 없이도 코드가 명확하게 의도를 드러내도록 작성해야 한다라고 강조한다.

주석이 가져오는 문제점은 주석이 부정확하거나 오래되면 읽는 이를 혼란에 빠뜨리고, 코드보다 더 신뢰할 수 없는 정보가 될 수 있고, 주석을 단 뒤 코드가 변경되면서 주석을 갱신하지 않은 경우가 많은데 이는 나쁜 정보가 되어 오히려 이해하기 어렵게 만든다.

필자 본인은 해당 부분을 읽고 어느 정도 동의하는 부분도 있었지만 꼭 그렇지 않은 부분도 있다고 생각했다.
주석을 단 뒤 코드가 변경되고 다시 주석을 갱신하지 않는 경우는 정말 좋지 않다고 생각하지만 주석이 오히려 이해를 돕고 중요한 맥락이나 이유를 전달하는 데 필수적인 경우도 분명 있다고 생각한다.
복잡한 알고리즘의 의도 설명, 코드에서 바로 알기 어려운 결정 이유, 중요한 경고와 같은 경우이다.
그래서 필자 본인은 주석이 그렇게 나쁘지 않다고 생각한다.

3. 결론

내가 느낀 최종 결론은 코드 품질 향상에 대해서는 배울 점이 많다고 생각하지만 모든 조언과 원칙들을 무조건 수용하기에는 무리가 있다고 생각한다.

이번 포스트에서는 제1장, 2장, 4장에 대해 다뤘지만 다음 포스트에서는 다른 파트에 대한 필자 본인에 대한 생각을 써보려 한다.

내가 만든 프로젝트를 구글 스토어에 올려보자! - part2

o0뀨0o — Mon, 1 Sep 2025 20:48:48 +0900

오랜만에 블로그를 써보려 한다.
이번 주제는 저번 "내가 만든 프로젝트를 구글 스토어에 올려보자! - part1 [블로그]"에 이어 part2를 작성해보려 한다.

1. 비공개 테스트 완료??

먼저 모두가 알다시피 비공개 테스트를 완료해야 다음 단계로 넘어갈 수 있다.

하지만 필자 본인은 아쉽게도 2주 동안 진행한 비공개 테스트에 실패하였다.

한동안 실패한 이유에 대해 생각하다 "진돕게(진짜 개발자는 개발자를 돕는다.)"라는 비공개 테스트나 다른 질문들에 대해서 질문과 답변을 주고받는 커뮤니티를 찾게 되어 들어가게 되었다.

그러다? 해당 커뮤니티의 노션 페이지를 보게 되었다.

이럴 수가.. 나는 항상 테스터 인원을 모을 때 학교메일(s000000@gsm.hs.kr)로 모으고 있었다..

다시 학교메일이 아닌 일반 계정을 사용해서 다시 진행해 본 결과 프로덕션 신청이 풀리는 것을 확인할 수 있었다!

2. 프로덕션 신청을 해보자

위와 같이 프로덕션 신청 버튼이 활성화되었다면..

위와 같이 프로덕션 액세스 신청을 하기 위한 정보들을 입력해주어야 한다.

입력한 이후는..

이렇게 프로덕션 액세스 권한 신청을 접수했다는 카드가 나오고 기다리면 구글에서 검토를 한 이후에 다음 단계로 넘어갈 수 있다.

3. 앱 스토어에 올려보자!

성공적으로 통과되었다면 이렇게 앱 출시로 넘어가게 됩니다!

그 이후로는 버전 생성 및 게시에 나온 순서대로 따라 하고 비공개 테스트에서 했던 것과 같이 똑같이 앱 번들에 올리고 게시 개요에서 변경 사항을 보내고 성공적으로 통과가 된다면? 앱이 실제 구글 플레이에 배포가 되는 것을 볼 수 있다!

구글 플레이 화면

관리자 페이지

오늘은 이렇게 비공개 테스트가 아닌 실제 배포하는 과정을 담은 part2를 작성해 보았다.
기회가 된다면 앱 관리를 하며 생기는 문제들을 해결해볼까 한다.

접근 제한자 알맞게 사용하고 있니?

o0뀨0o — Tue, 24 Jun 2025 11:57:36 +0900

우리가 보통 개발을 할 때 해당 언어의 접근 제한자의 사용에 대해서 고민해 보는 일이 생기게 될 것이다.
그렇기 때문에 오늘은 안드로이드 개발에서 접근 제한자를 어떤 상황에 따라서 사용하게 되는지에 대해서 알아보겠다!

1. 코틀린 접근 제한자

먼저 모두가 알듯.
코틀린 접근 제한자의 종류는 public, private, protected, internal 이렇게 4가지가 있다.

각각 간단하게 알아보자면...

1.1) public

모든 모듈 및 패기지에서 사용이 허용된다.

즉, 가장 넓은 범위의 제한자이다.

1.2) private

오직 선언된 클래스 안에서만 접근 가능하다.

1.3) protected

상속받는 인터페이스, 클래스 또는 자식 클래스에서만 접근이 가능하다.

1.4) internal

같은 패키지, 클래스 안의 상속 관계에 있는 하위 클래스에서 접근이 가능하다.

2. 어떤 상황에서 사용하면 좋을까??

2.1) public

먼저 public은...

* Activity, ViewModel, Repository 등 외부에서 직접 사용할 수 있어야 하는 클래스들

* 공용 API 또는 외부 라이브러리에서 사용할 수 있게 열어두는 컴포넌트

* 모듈 간 의존 관계에서 다른 모듈이 접근해야 하는 경우

// 예: 외부 모듈에서 사용할 수 있도록 공개
class SignInViewModel : ViewModel() {
    ...
}

2.2) private

private은...

* 특정 Composable이 해당 파일 내에서만 쓰일 경우

* ViewModel 안에서 상태를 변경하는 내부 함수나 변수

* Preview 용 함수

// 다른 파일에서는 접근할 수 없음
private fun SignInHeader() {
    Text(text = "로그인")
}

// ViewModel 내부에서만 상태를 업데이트
class SignInViewModel : ViewModel() {
    private val _uiState = MutableStateFlow(...)
}

// 해당 파일에서만 쓰이는 Preview 코드
@Preview
@Composable
private fun ExamplePreview() {

}

2.3) internal

internal은....

* 모듈 내부에서만 재사용되는 Composable 또는 클래스

* 도메인 로직, 유틸 클래스 등 외부에서 접근할 필요가 없는 기능

* 모듈화 구조에서 내부 구현 숨기기

// 이 컴포넌트는 같은 모듈 안에서만 사용 가능
internal fun ErrorSnackbar(message: String) { ... }

2.4) protected

protected는...

* 주로 상속 기반의 구조에서 사용

* 커스텀 뷰나 추상 클래스, BaseViewModel 등에서 자식 클래스에게만 열어줄 때

// BaseViewModel 내부 상태를 자식 ViewModel이 조작 가능
abstract class BaseViewModel : ViewModel() {
    protected fun handleError(error: Throwable) { ... }
}

class SignInViewModel : BaseViewModel() {
    fun signIn() {
        // BaseViewModel의 handleError 호출 가능
    }
}

3. 접근 제한자 사용하면 어떤 이득이 있어??

먼저 본인의 생각은....

접근 제한자를 올바르게 사용하면 클래스나 함수의 사용 범위를 명확히 하여 코드의 안정성과 가독성을 높일 수 있다고 생각한다.

즉, 기능별 역할이 명확히 분리되어, 코드 구조가 더 이해하기 쉬워지고 가독성이 향상된다.

오늘은 이렇게 접근 제한자가 어떤 상황에서 사용되는지에 대해서 간단하게 알아보아서 좋았다.

GC, 넌 누구야....

o0뀨0o — Tue, 17 Jun 2025 19:51:12 +0900

오늘은 평소에 생각하지 않고 넘겼었던 GC(가비지 컬렉터)에 대해서 알아보도록 하겠다.

1. GC가 뭐야?

GC는 메모리 관리 기법 중 하나이고, 동적으로 할당했던 메모리 영역 중에서 필요 없게 된 영역을 알아서 해제해 주는 기법이다.

* 동적으로 할당했던 메모리 영역은 Heap 영역. -> 여기서 힙 영역은 애플리케이션 실행 중에 생성되는 객체 인스턴스를 저장하는 영역이다.
* 필요 없게 된 영역은 어떤 변수도 가리키지 않게 된 영역을 의미.

C나 C++ 같은 경우는 Heap 영역의 메모리를 관리하기 위해 코드 레벨에서 할당받고 해제를 해주어야 했다. 또한 할당받은 메모리 영역을 제대로 해제하지 않아 Memory Leak이 발생하기도 하였다.

GC를 도입한다면 수동으로 메모리를 관리하던 것에 대한 에러를 해결할 수 있다..

개발자의 실수로 인한 메모리 누수를 막을 수 있고, 해제된 메모리에 접근하는 오류와 해제된 메모리를 또 해제하는 이중 해제 또한 막을 수 있다.

하지만 어떤 메모리 영역이 해제의 대상이 될지 검사하고 해제하는 일은 우리의 프로그램이 해야 하는 일을 방해하는 요소가 될 수도 있다.

특히 실시간 통신이 강조되는 프로그램일 경우에는 GC의 사용이 부적절할 수 있다.

2. GC는 알겠는데, 해제할 메모리 영역들을 어떻게 판단함?

GC 알고리즘에 대해서 설명하기 전에 Root Space에 대해서는 간단하게 스택 변수, 전역 변수 등 heap 영역 참조를 담은 변수라고 생각하면 편하다.

2.1) Reference Counting 알고리즘

Reference Count라는 별도의 숫자를 가지고 있습니다. 여기서 Reference Count는 몇 가지 방법으로 해당 객체에 접근할 수 있는지를 뜻합니다.

해당 객체에 접근할 수 있는 방법이 하나도 없다면.. 즉, Reference Count가 0이 다다르면 GC의 대상이 되는 것입니다.

하지만 Reference Counting 알고리즘은 순환참조의 한계점이 존재합니다.

2.2) Mark and Sweep 알고리즘

Mark and Sweep 알고리즘은 Reference Counting의 순환참조 문제를 해결할 수 있다.

해당 방식은 루트에서부터 해당 객체에 접근 가능한지를 해제의 기준으로 생각하고 루트부터 그래프 순회를 통해 연결된 객체를 찾는다.(이것이 마크임)

연결이 끊어진 객체들은 지우는 방식입니다.(이것이 Sweep)

* 루트로부터 연결된 객체는 Reachable

* 연결되지 않았다면 Unreachable

그림에서는 Sweep 이후에 분산되어 있던 메모리가 깔끔하게 정돈되어 있는데 이를 메모리 파편화를 막는 Compaction이라고 한다. 다만 Compaction은 필수가 아니다.

이와 같이 Mark and Sweep 기법을 사용하면 루트로부터 연결이 끊긴 순화참조되는 객체들도 모두 지울 수 있다.

간단하게 Mark and Sweep의 특징은 의도적으로 GC를 실행시켜야 하고, 애플리케이션 실행과 GC 실행이 병행된다.

3. JVM의 GC?? Heap 영역? - 의도적으로 GC를 실행시켜야 한다.

크게 Young Generation과 Old Generation으로 나뉜다.

* Young Generation에서 발생하는 GC는 Minor GC라고 부른다.

* Old Generation에서 발생하는 GC는 Major GC라고 부른다.

Young Generation은 또 세 영역으로 나뉘게 된다. -> Eden, Survival 0, Survival 1 영역으로 나뉨.

* Eden은 새롭게 생성된 객체들이 할당되는 영역임.

* Survival 영역은 Minor GC로부터 살아남은 객체들이 존재하는 영역임. -> Survival 영역에는 특별한 규칙이 하나 있는데 0 혹은 1 둘 중 하나는 꼭 비어있어야 한다.

age-bit는 Minor GC에서 살아남을 때마다 1씩 증가합니다.

Eden에 새롭게 생성된 객체들이 전부 채워지면 Minor GC 발생 -> Survival로 이동 -> 또다시 Eden에 새롭게 생성된 객체들이 전부 채워지면 다시 Minor GC 발생 -> Survival로 이동(age-bit 증가) -> Old Generation으로 이동(Promotion) -> Old Generation 전부 채워짐 -> Major GC 발생(Major 시간 > Minor 시간)

4. GC 실행 방식 - 애플리케이션 실행과 GC 실행이 병행된다.

먼저 어떤 방식들로 애플리케이션 실행과 GC의 실행되는지 알아보기 전에 Stop The World라는 개념을 알고 가야 한다.

Stop The World는 GC를 실행하기 위해 JVM이 애플리케이션 실행을 멈추는 것이다.

4.1) Serial GC

Serial GC는 단일 스레드를 활용하여 GC 작업을 처리하는 방식이다.

Stop The World

Serial GC는 애플리케이션 스레드가 많아도 GC는 단 하나의 스레드로만 처리되며, GC 도중 애플리케이션은 멈춰 있다.

장점

구현이 단순하고 안정적이다.

CPU가 적고 스레드가 적은 환경에 적합하다.

작은 힙 사이즈에는 오히려 빠르게 동작할 수 있다.

단점

멀티 스레드 환경에서는 비효율적이다.

GC 도중 전체 애플리케이션이 중단되기 때문에 지연시간이 길다.

대규모 서버나 실시간성이 중요한 시스템에는 부적합하다.

4.2) Parallel GC

Parallel GC를 여러 개의 스레드로 GC 작업을 처리하는 방식이다.

Stop The World

GC 자체가 병렬로 처리되어 빨리 끝나기 때문에 애플리케이션의 일시정지는 짧아집니다.

장점

멀티 코어 환경에서 뛰어난 GC 처리 성능을 보여준다.

GC 시간이 짧고 효율적이다.

단점

여전히 Stop The World가 발생한다.

응답 지연 시간에 민감한 프로그램에서는 부적합하다.

GC 스레드가 많아지면 GC 자체는 빨라지지만, CPU 리소스 경쟁이 생길 수 있다.

4.3) G1 GC

G1 GC는 지연시간을 예측 가능하게 하면서도 전체 처리량도 확보할 수 있도록 설계된 GC이다.

Stop The World

G1GC도 Stop The World가 발생하기는 하지만 전체 힙을 수거하지 않고 일부 Region만 수거하고, GC 작업도 병렬처리를 하기 때문에 애플리케이션의 중단 시간이 짧고 예측 가능하다.

장점

지연 시간과 처리량을 동시에 고려한다.

Heap이 클수록 효율적이다.

Stop The World 일지라도 일부만 발생하기 때문에 예측 가능하다.

Region 기반 구조로 인해 단편화가 줄어든다.

단점

GC 로직이 복잡해서 추가적인 메모리/CPU 오버헤드 존재한다.

초소형 애플리케이션에서는 오히려 성능이 저하될 수 있다.

매우 짧은 응답 지연이 필요한 실시간 시스템에는 부적합하다.

평소에 알고만 있고 잘 몰랐었던 GC의 동작 원리 종류들에 대해서 알아볼 수 있는 기회가 되어 좋았다!

프로젝트의 의존 관계와 그래프를 뽑아보자

o0뀨0o — Wed, 7 May 2025 16:19:22 +0900

오늘은 Android Module 간의 관계를 그래프와 텍스트로 출력해 주는 Gradle 플러그인을
사용하여 간단하게 프로젝트의 의존 관계와 그래프를 알아보도록 하겠다.

1. 계기

먼저 의존 관계에 대한 그래프를 뽑아보게 된 계기는..

최근에 불필요한 중간 계층을 삭제하는 리팩터링을 하게 되었다.

하지만?

리팩터링을 한 이후에 잘 변경이 되었는지 각 모듈 간 의존 관계를 확인할 수 있는 방법이 없어 고민을 하다...

의존 관계에 대한 그래프를 출력해 주는 플러그인을 사용하여 확인하면 좋겠다!라는 생각을 하여 사용하게 되었다.

2. 사용법

1. Root Project단의 build.gradle.kts 파일에서 plugins에 아래와 같이 코드를 입력해 준다.

plugins {
    id("com.vanniktech.dependency.graph.generator") version "0.7.0"
}

2. 터미널에 아래와 같은 명령어를 입력해 준다.

아래와 같이 입력을 해주었다면 root_project/build/reports/project-dependency-graph의 경로에 png와 svg 같은 파일이 생성된 것을 확인할 수 있을 것이다.

./gradlew generateProjectDependencyGraph

3. 결과

실제로 확인한 결과 필자 본인이 원한대로 UI(feature) ->Data의 흐름으로 의존 관계가 형성이 되어있는 것을 확인하였다.

4. 플러그인 깃허브 주소

https://github.com/vanniktech/gradle-dependency-graph-generator-plugin

GitHub - vanniktech/gradle-dependency-graph-generator-plugin: Gradle plugin that generates dependency graphs from your project.

Gradle plugin that generates dependency graphs from your project. - vanniktech/gradle-dependency-graph-generator-plugin

github.com

이번에는 간단한 의존 관계 그래프를 출력하는 여러 방법 중 한 가지를 알아보았다.
다음 포스팅에서는 계기에서 잠시 언급하였던 중간 계층을 삭제하는 리팩터링에 대한 내용을 작성해 보겠다!

내가 만든 프로젝트를 구글 스토어에 올려보자! - part1

o0뀨0o — Tue, 29 Apr 2025 14:34:51 +0900

오늘은 지금 현재 본인이 진행 중인 구글 스토어에 앱을 배포하는 과정에 대해 말해보겠다.

1. 구글 플레이 콘솔에서 계정 구매하기

구글 스토어에 본인이 개발한 앱을 올리기 이전에 먼저 구글 플레이 콘솔 계정을 구매해야 한다.
여기서 주의할 점은 미성년자의 신분으로 결제나 계정을 생성하게 되면 추후에 진행할 본인인증과 같은 절차에서 제출해야 하는 서류에서 어려움을 겪을 수 있어 되도록이면 성인의 신분으로 계정을 생성하는 것을 추천한다.

* 필자 본인은 담당 선생님이 대신 결제해 주셨다.

2. 본인인증하기

계정을 구매 후 생성이 되었다면.. 이제는 본인 인증을 해야 한다..

필자 본인은 본인인증 부분에서 가장 애를 먹었다.

그 이유는 본인임을 증명하기 위해 첨부해야 하는 서류들을 구하기 너무 어려웠기 때문이다.

담당 선생님의 도움으로 계속해서 서류들을 제출해 봤지만.. 3일 동안 인증하지 못했다는 메시지만 받고 구글링을 해보니 주민등록증, 운전면허증으로도 인증이 가능하다는 사실을 발견하고 운전면허증을 제출하니 얼마 되지 않아 본인인증이 완료되었다는 메시지를 받았다...ㅋㅋ

그 이후에 진행되는 전화번호인증, 구글 플레이 콘솔 앱에서 액세스 가능한지 인증이 두 개는 빠르게 해결 가능하다.

3. 앱 생성하기

처음에 생성을 하게 되면 아래와 같은 앱 설정을 요구하는데 해당 부분에서는 어려운 부분 없이 나오는 설명대로 따라서하면 모두 쉽게 완료할 수 있다.

다음은 비공개 테스트를 진행하면 된다.

필자 본인은 해당 부분이 프로덕션 액세스 신청을 하기 위한 절차 중 가장 어려울 것이라고 생각이 되어 어떻게 하면 되는지 설명을 하겠다.

먼저 2주 동안 진행하는 테스트에 참여할 테스터 12명 이상을 모아야 한다.

테스터를 모으는 과정 자체가 조금 어렵다고 느껴질 것 같다. 하지만 주변 지인(친구, 직장 동료, 가족 등..)을 통해서 쉽게 모을 수 있을 것이다..(아마도....)

테스터를 다 모았다면 이제 테스트를 허용하는 국가를 설정해야 하는데 필자 본인은 대한민국 한정으로만 사용하는 앱이기 때문에 대한민국만 체크하였다.

국가 및 지역도 설정했다면.. 이제는 비공개 버전을 출시해야 한다.

출시하기 이전에 해당 프로젝트의 안드로이드 스튜디오에서 어플을 배포할 수 있는 형태로 빌드를 해주어야 한다.

1. 안드로이드 스튜디오 메뉴에서 Build -> Generate Signed App Bundle / APK... 를 클릭

2. Android App Bundle에 체크하고 Next 클릭

3. 본인이 보유한 유효한 서명을 선택한 상태에서 Next 클릭

3-1. 혹시 처음이라 서명이 없다면?

Create new를 클릭하여 빈칸을 채워주면 된다.

Password, Key Alias는 절대 까먹으면 안 되기 때문에 문서화 해두길 바란다..

필자 본인은 Certificate 부분에서 그냥 이름만 명시하였다.

이후에 3번과 같이 입력을 해주고 Next 클릭

4. Build Variants에서 release를 선택 후 Create 클릭

5. 지정된 경로 확인

Create 이후에는 이렇게 지정된 경로에. abb 확장자 파일을 찾을 수 있다.

다시 돌아와서 이제 locate를 클릭하면 파일을 볼 수 있는데.. 확인된 파일을 아래에 보이는 App Bundle 항목에 업로드해 주면 된다.

업로드 이후에 다음을 클릭하고..

개시개요로 이동 이후 "검토를 위해 변경사항 1개 전송" 버튼을 클릭하고 검토를 진행한 이후에 비공개 출시를 완료할 수 있다!

마지막으로 테스터 12명 이상이 비공개 출시 앱을 다운로드하고 아래와 같이 2주 동안 참여를 선택해주어야 한다.

필자 본인은 아직 프로덕션 신청은 하지 않고, 테스터 활동을 진행 중에 있다.!

오늘은 간단하게 본인이 만든 프로젝트를 비공개 테스트로 출시하는 과정까지 작성해 보았다.
다음에는 프로덕션 신청에 대한 블로그도 작성해 볼 예정이다!

Array와 List의 차이점 알고 있어?

o0뀨0o — Tue, 22 Apr 2025 11:39:05 +0900

오늘은 안드로이드 개발이나 Kotlin을 사용한다면 한 번쯤 들어봤을 질문..
"Array와 List의 차이"에 대해서 알아보겠다.

1. Array와 List 알고 있어?

Array

* 생성되는 순간 값은 고정이 되며 원소 삭제 및 추가 기능을 사용할 수 없다.

* Array안에서 값은 자유롭게 변환이 가능하다.

* val로 선언하든 var로 선언하든 같은 동작을 한다.

* arrayOf 키워드로 생성이 가능하다.

* 서로 다른 타입이 공존할 수 있다.

val mix = arrayOf("명훈", "입니다", 5, 2)

* Array끼리 서로 합치는 동작이 가능하다.

val audgns = intArrayOf(1, 2, 3)
val ggyu = intArrayOf(4, 5, 6)
val um = audgns + ggyu
println(um[5])  // 6

List

* 순서가 있는 자료형들의 집합이다.

* 불연속적인 메모리 공간을 점유하여 메모리 관리에 용이하다.(포인터로 값을 접근하는 것)

* List에서 인덱스는 그냥 몇 번째 정도인가의 의미를 가지게 된다.

* Null과 중복 데이터를 허용한다.

* 두 리스트가 서로 원소들의 인덱스, 내용이 서로 모두 같다면 같이 리스트로 간주한다.

* 값을 변경할 수 없는 리스트 -> Immutable List

val android = listOf("di", "hilt", "koin")
println(android)

* 값을 변경할 수 있는 리스트 -> Mutable List

val myList = mutableListOf("tuna", "salmon", "shark")
myList.remove("shark")

val numbers = mutableListOf(1, 2, 3, 4)
numbers.add(5)
numbers.removeAt(1)
numbers[0] = 0
numbers.shuffle()
println(numbers)

2. 장단점

Array 장단점

장...

* 인덱스를 활용한 검색이 용이하다.

* 연속된 메모리 공간을 활용하여 메모리 관리가 편하다.

단......

* 배열에서 값을 삭제해서 배열의 크기는 줄어들지 않기 때문에 메모리가 낭비가 될 수 있다.

* 정적타입이어서 배열 크기를 컴파일 이전에 지정해줘야 하는 번거로움이 있다.

* 배열 크기를 이후에 재조정하는 것이 불가능하여 불편하다.

List 장단점

장...

* 포인터를 사용하여 다음 값을 보고 있어 삽입, 삭제 동작이 빠르다.

* 동적 타입이어서 크기가 따로 정해져 있지 않아 자유자재로 이용이 가능하다.

* 메모리 재사용이 용이하다.

단.........

* 불연속적 메모리 공간을 사용하여 검색 기능에서는 좋지 않은 성능을 보여준다.

* 포인터를 통해 다음 값을 보기 때문에 포인터를 담기 위한 추가적인 메모리 공간이 필요하다.

3. 정리

* Array는 무조건 고정된 사이즈를 가진다(정적). List는 사이즈 변경이 가능하다(동적).

* List와 다르게 Array는 동등성 비교를 지원하지 않아 인덱스와 값이 모두 같더라도 false를 반환한다.

kotlin으로 개발을 할 때 자주 듣는 Array와 List의 차이에 대해 알아보는 시간이 되어 좋았다.
앞으로도 이러한 질문들에 대해 알아보도록 하겠다.

Lottie 애니메이션을 활용해보자..

o0뀨0o — Mon, 14 Apr 2025 20:14:11 +0900

오늘은 사용할 일이 없을 줄 알았던 Lottie를 사용하게 되어 필자 본인이 사용한 방법에 대해 알아보자.

1. 계기

최근 프로젝트에서 폼 생성을 성공하면 아래와 같은 생성 완료 화면이 나오는 디자인이 추가가 되어 해당 부분을 Lottie를 활용해서 구현하면 좋을 것 같아 사용해 보게 되었다.

2. Lottie 의존성 추가

사용할 모듈의 build.gradle.kts 파일에 아래와 같은 의존성 코드를 추가한다.

implementation 'com.airbnb.android:lottie:{version}'

3. res 파일에 raw 폴더 생성 후 Lottie Json 파일 추가

각자 가지고 있는 Lottie Json 파일을 res 파일에 raw 폴더를 생성한 이후 넣어주면 된다.

4. Lottie를 띄워보자

필자 본인은 그냥 로티를 별 다른 조건 없이 띄우기만 하면 되기에 animateLottieCompositionAsState()를 활용하여 progress를 직접 구해 사용하는 방식으로 구현을 하였습니다.

@Composable
fun CheckLottie(modifier: Modifier = Modifier) {
    // Lottie 애니메이션 구성(composition)
    val composition by rememberLottieComposition(
        LottieCompositionSpec.RawRes(R.raw.lottie) // res/raw 폴더의 애니메이션 JSON 파일
    )

    // 현재 애니메이션의 진행 정도 (0f = 시작, 1f = 끝)
    val progress by animateLottieCompositionAsState(
        composition = composition,
        iterations = 1, // 애니메이션을 한 번만 재생
    )

    // 애니메이션을 화면에 출력
    LottieAnimation(
        composition = composition, // 어떤 애니메이션을 그릴지 지정
        progress = progress,       // 현재 애니메이션의 재생 정도
        modifier = modifier.size(128.dp)
    )
}

5. 결과

평소에 알고만 있던 기술을 실제로 사용해 볼 수 있어 좋았다..

Coroutine Flow? 내 프로젝트에 적합할까?

o0뀨0o — Tue, 8 Apr 2025 17:22:49 +0900

오늘은 평소에 아무렇지 않게 사용 중이던 Coroutine Flow가 정말 내 프로젝트에 적합하고,
필자 본인은 왜 Coroutine Flow를 사용했는지에 대해서 알아보겠다.

1. 계기

필자 본인이 이러한 글을 작성하게 된 계기는..

지금까지 본인이 했었던 프로젝트에서는 왜 전부다 Flow를 사용했지?라는 의문이 들게 되어 각각 "기술적 측면", "유지보수 측면"에 대해서 여러 사람들과 이야기해 보았던 내용을 블로그에 작성하면 좋을 듯해서 작성하게 되었다..

2. 내 프로젝트에 적합할까?

오늘 블로그 주제인 내 프로젝트에 적합할까?라는 주제에 대해서 알아보기 전에 필자 본인이 이러한 생각을 하게 된 이야기를 들어보자..

Flow 관련 내용을 다시 공부하던 중.. Retrofit에서는 기본적으로 API 요청을 보낼 때 suspend 함수로 선언을 하게 되는데, suspend 함수는 코루틴으로 동작이 되고 네트워크 요청 같은 작업은 자동으로 별도의 스레드에서 처리되기 때문에, 사실 이것만으로도 비동기 처리가 잘 되어 있는 상태 아닌가?

그런데 이걸 굳이 또 Flow로 감싸는 게 의미가 있을까? 오버 엔지니어링 아닐까?

여러 프로젝트에서는 단발성 통신이 대부분을 이루고 있지만, Flow는 원래 데이터가 계속 흐를 수 있는 구조.. 즉, 스트림을 처리하기에 적합한데 이렇게 되면 그냥 suspend 함수 하나로 충분한데, 괜히 Flow로 감싸면 불필요하게 코드만 복잡해지는 거 같은데?

라고 생각을 해서 혼자서 단정 짓기보다는 다른 사람들의 의견도 들어보면 좋을 것 같아 같은 안드로이드 전공의 사람들과 이야기를 해보았을 때 두 가지 의견으로 갈렸다. 이러한 의견을 기술적, 유지보수적 측면으로 봐보자...

Q1) 단발성 통신에 굳이 Flow까지 도입하는 것은 과도한 설계가 아닐까? - 기술

* 해당 프로젝트의 통신은 거의 대부분 단발성 요청으로 이루어지고 있어 suspend 함수만 써도 비동기 처리를 동일하게 적용할 수 있음!

* Retrofit은 자체적으로 suspend 키워드를 지원하며, 내부적으로 Coroutine Dispatcher(IO)에서 실행되기 때문에, 추가적인 스레드 전환이나 Flow 도입 없이도 비동기 네트워크 처리를 안정적으로 수행할 수 있음!

Q2) 단발성이더라도 Flow로 통일하는 게 유지보수에 더 낫지 않나요? - 유지보수

* 실제 개발을 할 때는 API 뿐만 아니라 Room, SharedPreferences, DataStore, 파일 입출력 등 여러 가지 데이터 소스를 다루게 되는데.. 이들 각각은 서로 다른 방식으로 데이터를 처리해야 하기 때문에, UI에서 각 방식에 맞춰 따로 처리하면 코드가 복잡해질 수 있습니다.

LaunchedEffect(Unit) {
    // API
    val user = apiService.getUser()

    // Room
    val userList = userDao.getAllUsersOnce()

    // SharedPreferences
    val isDarkMode = withContext(Dispatchers.IO) {
        sharedPrefs.getBoolean("dark_mode", false)
    }

    // 파일
    val noticeText = withContext(Dispatchers.IO) {
        File(context.filesDir, "notice.txt").readText()
    }

    // 각각 별도로 관리하고, 에러 처리도 제각각 필요
}

* 위와 같은 데이터 소스를 모두 Flow를 활용해 공통으로 감싸면, ViewModel과 UI에서는 일관된 방식으로 데이터를 수집하고 처리할 수 있어 코드의 복잡도를 줄이고 관리가 쉬워질 수 있습니다.

val user by viewModel.user.collectAsStateWithLifecycle()
val userList by viewModel.userList.collectAsStateWithLifecycle()
val isDarkMode by viewModel.isDarkMode.collectAsStateWithLifecycle()
val noticeText by viewModel.noticeText.collectAsStateWithLifecycle()

// 모든 데이터 소스를 Flow로 통일한 경우

* 개발을 할 때 받아온 데이터를 변형하거나, 특정 조건에 맞춰 필터링하거나, UI에 필요한 형태로 가공해야 하는 일이 거의 항상 발생하게 되는데, 이때 map, filter, transform 등 중간 연산자를 사용하면 데이터 가공이 매우 편리함!

이렇게 나올 수 있는데 필자 본인의 의견은 기술적 측면에 더 가까웠지만 여러 사람들의 의견을 들어보고 유지보수적인 측면이 더 좋을 것 같다고 생각되어 단발성 통신에서도 Flow를 사용하여 처리하는 방법을 선택하였다.

suspend fun getAdminUserNames(): List<String> {
    val users = apiService.getUserList() // suspend 함수로 API 호출

    val admins = users.filter { it.isAdmin } // 가공 1: 관리자만 추림
    val sortedAdmins = admins.sortedByDescending { it.age } // 가공 2: 나이 순 정렬
    return sortedAdmins.map { it.name } // 가공 3: 이름만 추출
}
// 중간 연산자 사용 x

fun getAdminUserNames(): Flow<List<String>> {
    return apiService.getUserListFlow() // Flow<List<User>>
        .map { users ->
            users.filter { it.isAdmin }       // 중간 연산자: 필터링
                  .sortedByDescending { it.age } // 정렬
                  .map { it.name }              // 이름만 추출
        }
}
// 중간 연산자 사용 o

필자 본인의 결론은?

처음에는 "단발성 API에 굳이 Flow?"라는 생각을 했지만, 실제 개발을 하며 다양한 데이터 소스를 통합적으로 다루고, 변경에 유연하게 대응하는 과정에서 Flow의 강점을 느낄 수 있고, ViewModel 내부에서 API를 쓰든, DB를 쓰든, SharedPreference를 쓰든 UI는 항상 collectAsState()나 LaunchedEffect로 데이터를 받아서 사용하기 때문에 데이터 소스가 변경되더라도 UI는 영향을 받지 않도록 분리될 수 있기 때문에 미래에 더 좋은 개발 환경을 만들 수 있다고 생각되어 선택하였습니다.

3. 결론

결론은 필자 폰인 처럼 단발성 통신에 Flow를 사용하는 것이 반드시 정답이라고 할 수는 없다.

어떤 선택이 더 나은지는 결국 프로젝트의 성격, 팀의 스타일, 개발자의 선호도에 따라 선택하면 될듯하다!

'뀨'의 Android - dev-blog

2025년에 난 뭘 했을까..?

오늘은 25년에 나는 무엇을 했는지 회고하는 블로그를 작성해보려 한다.상반기 중반기 하반기 이렇게 3단계로 나눠서 이야기하겠다!

이렇게 나의 2025년 회고록과 2026년 목표 및 계획을 일부 작성해 봤다!화이팅@!

로버트 C. 마틴 "Clean Code"를 읽어보여 느낀점 - part1

이번 포스트에서는 로버트 C. 마틴의 "Clean Code"라는 도서를 읽어보며 느낀 점을 써보려 한다.

이번 포스트에서는 제1장, 2장, 4장에 대해 다뤘지만 다음 포스트에서는 다른 파트에 대한 필자 본인에 대한 생각을 써보려 한다.

내가 만든 프로젝트를 구글 스토어에 올려보자! - part2

오랜만에 블로그를 써보려 한다.이번 주제는 저번 "내가 만든 프로젝트를 구글 스토어에 올려보자! - part1 [블로그]"에 이어 part2를 작성해보려 한다.

오늘은 이렇게 비공개 테스트가 아닌 실제 배포하는 과정을 담은 part2를 작성해 보았다.기회가 된다면 앱 관리를 하며 생기는 문제들을 해결해볼까 한다.

접근 제한자 알맞게 사용하고 있니?

우리가 보통 개발을 할 때 해당 언어의 접근 제한자의 사용에 대해서 고민해 보는 일이 생기게 될 것이다.그렇기 때문에 오늘은 안드로이드 개발에서 접근 제한자를 어떤 상황에 따라서 사용하게 되는지에 대해서 알아보겠다!

오늘은 이렇게 접근 제한자가 어떤 상황에서 사용되는지에 대해서 간단하게 알아보아서 좋았다.

GC, 넌 누구야....

오늘은 평소에 생각하지 않고 넘겼었던 GC(가비지 컬렉터)에 대해서 알아보도록 하겠다.

평소에 알고만 있고 잘 몰랐었던 GC의 동작 원리 종류들에 대해서 알아볼 수 있는 기회가 되어 좋았다!

프로젝트의 의존 관계와 그래프를 뽑아보자

오늘은 Android Module 간의 관계를 그래프와 텍스트로 출력해 주는 Gradle 플러그인을사용하여 간단하게 프로젝트의 의존 관계와 그래프를 알아보도록 하겠다.

이번에는 간단한 의존 관계 그래프를 출력하는 여러 방법 중 한 가지를 알아보았다.다음 포스팅에서는 계기에서 잠시 언급하였던 중간 계층을 삭제하는 리팩터링에 대한 내용을 작성해 보겠다!

내가 만든 프로젝트를 구글 스토어에 올려보자! - part1

오늘은 지금 현재 본인이 진행 중인 구글 스토어에 앱을 배포하는 과정에 대해 말해보겠다.

오늘은 간단하게 본인이 만든 프로젝트를 비공개 테스트로 출시하는 과정까지 작성해 보았다.다음에는 프로덕션 신청에 대한 블로그도 작성해 볼 예정이다!

Array와 List의 차이점 알고 있어?

오늘은 안드로이드 개발이나 Kotlin을 사용한다면 한 번쯤 들어봤을 질문.."Array와 List의 차이"에 대해서 알아보겠다.

kotlin으로 개발을 할 때 자주 듣는 Array와 List의 차이에 대해 알아보는 시간이 되어 좋았다.앞으로도 이러한 질문들에 대해 알아보도록 하겠다.

Lottie 애니메이션을 활용해보자..

오늘은 사용할 일이 없을 줄 알았던 Lottie를 사용하게 되어 필자 본인이 사용한 방법에 대해 알아보자.

평소에 알고만 있던 기술을 실제로 사용해 볼 수 있어 좋았다..

Coroutine Flow? 내 프로젝트에 적합할까?

오늘은 평소에 아무렇지 않게 사용 중이던 Coroutine Flow가 정말 내 프로젝트에 적합하고,필자 본인은 왜 Coroutine Flow를 사용했는지에 대해서 알아보겠다.

이렇게 아무렇지 않게 사용 중이던 기술이 실제 프로젝트에 적합한지에 대해 알아보면서 Flow의 이해도가 더 높아질 수 있어 좋았다.

오늘은 25년에 나는 무엇을 했는지 회고하는 블로그를 작성해보려 한다.
상반기 중반기 하반기 이렇게 3단계로 나눠서 이야기하겠다!

이렇게 나의 2025년 회고록과 2026년 목표 및 계획을 일부 작성해 봤다!
화이팅@!

오랜만에 블로그를 써보려 한다.
이번 주제는 저번 "내가 만든 프로젝트를 구글 스토어에 올려보자! - part1 [블로그]"에 이어 part2를 작성해보려 한다.

오늘은 이렇게 비공개 테스트가 아닌 실제 배포하는 과정을 담은 part2를 작성해 보았다.
기회가 된다면 앱 관리를 하며 생기는 문제들을 해결해볼까 한다.

우리가 보통 개발을 할 때 해당 언어의 접근 제한자의 사용에 대해서 고민해 보는 일이 생기게 될 것이다.
그렇기 때문에 오늘은 안드로이드 개발에서 접근 제한자를 어떤 상황에 따라서 사용하게 되는지에 대해서 알아보겠다!

오늘은 Android Module 간의 관계를 그래프와 텍스트로 출력해 주는 Gradle 플러그인을
사용하여 간단하게 프로젝트의 의존 관계와 그래프를 알아보도록 하겠다.

이번에는 간단한 의존 관계 그래프를 출력하는 여러 방법 중 한 가지를 알아보았다.
다음 포스팅에서는 계기에서 잠시 언급하였던 중간 계층을 삭제하는 리팩터링에 대한 내용을 작성해 보겠다!

오늘은 간단하게 본인이 만든 프로젝트를 비공개 테스트로 출시하는 과정까지 작성해 보았다.
다음에는 프로덕션 신청에 대한 블로그도 작성해 볼 예정이다!

오늘은 안드로이드 개발이나 Kotlin을 사용한다면 한 번쯤 들어봤을 질문..
"Array와 List의 차이"에 대해서 알아보겠다.

kotlin으로 개발을 할 때 자주 듣는 Array와 List의 차이에 대해 알아보는 시간이 되어 좋았다.
앞으로도 이러한 질문들에 대해 알아보도록 하겠다.

오늘은 평소에 아무렇지 않게 사용 중이던 Coroutine Flow가 정말 내 프로젝트에 적합하고,
필자 본인은 왜 Coroutine Flow를 사용했는지에 대해서 알아보겠다.