디노 블로그

(AI) 아는 건 빼고 인수인계 해줘

DinoDev — Tue, 16 Jun 2026 14:47:22 +0900

저번에 글 두 개를 썼다.

하나는 내 지식으로 정리해줘 - 공부하다 알게 된 걸 AI한테 시켜서 옵시디언 지식저장소에 키워드 노트로 쌓는 이야기였다.

다른 하나는 인수인계 해줘 - 내가(또는 AI가) 한 작업을 신입한테 가르치듯 하나씩 설명받으면서 능동적으로 학습하는 이야기였다.

그런데 둘을 한동안 쓰다 보니 어딘가 계속 아쉬웠다. 두 개가 따로 놀고 있었다.

뭐가 아쉬웠나

인수인계를 받다 보면 이런 일이 자꾸 생겼다.

이미 아는 개념인데 AI가 처음부터 친절하게 다 설명한다. @Transactional이 뭔지, JPA 지연 로딩이 뭔지… 나 그거 이미 노트로 정리해뒀는데. 듣고 있으면 시간이 아까웠다. 신입한테 0부터 가르치는 톤이라, 정작 내가 궁금한 "이 작업에서 뭘 왜 그렇게 했는지"는 한참 뒤에야 나왔다.

반대로 인수인계 중에 진짜 처음 보는 개념이 나오면 "아 이거 정리해두면 좋겠다" 싶은데, 그러려면 인수인계가 끝난 뒤에 따로 또 "이거 노트로 정리해줘"를 해야 했다. 흐름이 뚝 끊겼다.

결국 지식저장소와 인수인계가 각자 돌고 있었던 거다. 내가 뭘 아는지는 지식저장소에 다 적혀 있는데, 정작 인수인계는 그걸 모르는 채로 매번 처음부터 다 설명하고 있었다.

그래서 스킬을 바꿨다

생각은 단순했다. 인수인계 스킬이 내 지식저장소를 먼저 읽게 하면 되잖아?

규칙도 단순하게 잡았다.

지식저장소에 노트가 있는 개념 → 나 아는 거니까 "이건 이미 정리해두셨으니 넘어가고" 하고 한 줄로 짚고 지나간다. 대신 이번 작업에서 그걸 어떻게 썼는지에만 집중한다.
노트가 없는 개념 → 모르는 거니까 처음부터 자세히 설명한다. 그리고 설명이 끝나면 "이거 일반적인 개념인데, 노트로 정리해둘까요?" 하고 물어본다.

말 한마디로 스킬 문서를 그 자리에서 고쳐줬다.

실제로 받아봤다

규칙을 넣고 작업 하나를 인수인계 받아봤다. (회사에서 출결 도메인을 새로 만든 작업이었다.)

도입부부터 달랐다. AI가 먼저 내 지식저장소 인덱스를 쭉 읽더니, "이미 노트가 있는 건 아시는 내용이라며 간단히, 없는 건 자세히 설명하고 저장할지 여쭤보겠습니다" 하고 선언하고 시작한다.

Spring Layered Architecture는 내가 이미 노트로 정리해둔 개념이라, "이건 아시는 내용이니 넘어가고"라며 한 줄로 짚고 곧장 이번 작업에서의 적용으로 넘어갔다. (참고로 여기서 내가 노트를 잘못 매칭한 것까지 잡아냈는데, 그건 덤이었다.)

"정리해줘" 한마디에, 옵시디언 규칙(폴더 분류, 템플릿, wikilink 연결, 인덱스 갱신)에 맞춰 노트를 알아서 만들어줬다.

뭐가 좋아졌나

이렇게 바꾸고 나니 두 가지가 확 좋아졌다.

첫째, 인수인계가 짧고 밀도 높아졌다. 아는 건 빠르게 넘기고 모르는 것에만 시간을 쓰니까. 신입한테 다 풀어주는 톤이 아니라, "기초는 아는 동료"한테 핵심만 짚어주는 톤이 됐다. 딱 내가 원하던 거였다.

둘째, 인수인계 한 번에 지식저장소가 같이 자란다. 작업하다 새로 배운 걸 그 자리에서 노트로 떨어뜨리니까, 나중에 따로 정리하는 수고가 사라졌다. 지식저장소와 인수인계가 드디어 하나로 연결된 거다.

마무리

인수인계를 받으면 지식저장소가 자라고, 지식저장소가 자라면 다음 인수인계는 더 짧아진다. 알수록 설명이 줄고, 모르는 것만 남는다. 이 루프가 꽤 마음에 든다.

1년 뒤엔 인수인계가 얼마나 짧아져 있을지, 지식저장소는 얼마나 두꺼워져 있을지 궁금하다.

(AI) 인수인계 해줘

DinoDev — Fri, 12 Jun 2026 00:59:03 +0900

나는 2017년부터 7년 동안 Android 개발을 했고 2024년부터 지금까지 우아한형제들에 재직하면서 우아한테크코스의 모바일 안드로이드 코치로 교육을 하고 있다.

AI 시대가 오면서 Android 개발자, Backend 개발자와 같이 특정 플랫폼에서 개발하는 것보다, AI를 적극적으로 사용해서 바이브코딩으로 여러 플랫폼 위에서 개발할 수 있는 시대가 되고 있다고 느낀다.

우아한테크코스 모바일 안드로이드 8기 크루(학생)들에게도 Android 교육을 했지만, 레벨2 후반부에서는 AI를 사용해서 Android가 아닌 아이폰 앱이나 플러터, 아두이노와 같이 다른 플랫폼을 개발하도록 교육을 하고 있다.

그러면서 나도 AI를 이용해서 다른 플랫폼을 개발할 줄 알아야 한다고 생각해서, LMS+라는 교육 플랫폼 개발을 시작했다.

기존에 있는 LMS+ 프로젝트는 우리 팀의 슈퍼 백엔드 개발자인 구구(강현구)와 검프(김태정)가 백엔드와 프론트엔드 지식이 없어도 AI만 사용해서 제품을 만들 수 있도록 AI 도구를 많이 마련해뒀다. 그래서 만들고자 하는 기능을 Jira 티켓으로 잘 정리해두고 IntelliJ에서 claude code로 "Jira 이슈 번호 xxx 작업 해줘"라고 하면 알아서 브랜치 만들고 작업 범위 정하고 테스트 코드까지 작성한다. 그리고 내가 MR(우형은 Gitlab을 사용)을 올려달라고 하면 MR 본문까지 작성해주는 너무나도 편리한 기능까지 마련되어 있다.

AI가 만들어 주는 것을 내가 학습하지 않고 100% 맡기면, 나중에 버그가 발생했을 때 해결할 수 없다는 이야기를 수도 없이 들었다. 그런 이유로 AI를 써서 제품은 만들더라도, 내 이름으로 커밋하는 작업만큼은 내가 제대로 알고 있어야 한다고 생각했다.

백엔드를 잘 모르는 내가 어떻게 작업한 내용을 제대로 알 수 있을지 고민이었다. 그러면서 내가 안드로이드를 처음에 어떻게 배웠지? 하고 생각해보니, 시니어 개발자에게 인수인계를 받으면서 프로젝트에 대한 이해도 하고 안드로이드 공부도 같이 할 수 있었다.

그래서 나는 AI에게 "너가 시니어 개발자가 되어서 이번 작업한 내용을 신입개발자에게 알려준다고 생각하고 하나씩 천천히 알려주도록 하고 이것을 스킬로 만들어줘"라고 했다. 스킬에는 변경한 코드, 그렇게 작성한 이유, 이해에 필요한 개념 순서로 설명하도록 정리해뒀다. 그리고 나는 LMS+를 AI에게 개발시키고, MR을 올리기 전에 꼭 "인수인계 해줘"라고 지시했다.

그러면 AI는 나를 신입개발자로 인식하고 시니어 개발자의 관점에서 하나하나 작업을 친절하게 알려줬다. 그러면서 나는 Spring에 대한 지식도 공부하면서 LMS+에 있는 코드들도 빠르게 학습할 수 있게 됐다.

그렇게 나는 시니어 대신 AI에게 인수인계를 받으며 새로운 플랫폼을 배우고 있다. AI 시대가 됐다고 배우지 않아도 되는 게 아니라, 배우는 방법이 달라진 것뿐이라는 걸 직접 겪어보고 나서야 알게 됐다.

AI가 코드를 다 짜주는 시대여도 커밋에 남는 이름은 결국 내 이름이다. 아직 백엔드를 잘 안다고 말할 수는 없지만, "인수인계 해줘" 덕분에 적어도 내가 올린 MR은 설명할 수 있는 개발자가 됐다. 다음에는 어떤 플랫폼을 개발하게 될지 모르겠지만, 그때도 똑같이 AI에게 개발을 시키고 인수인계를 받으면서 하나씩 내 것으로 만들어 갈 생각이다.

(AI) 내 지식으로 정리해줘

DinoDev — Thu, 11 Jun 2026 23:47:06 +0900

요즘 내가 어떤 것을 알고, 어떤 것을 모르는지 정리해보고 싶어졌다.

그렇다고 아는 것을 머리에서 하나하나 다 꺼내서 정리하고 싶지는 않았다. 대신 모르는 것을 마주칠 때마다 AI와 함께 정리하면서, 나만의 지식 DB를 만들어야겠다고 생각했다.

최근 Hermes가 OpenClaw를 대신해서 사용하기 좋다는 소식을 듣고, 집에 있는 맥북에어 M5 기본형에 설치하고 Telegram과 연결했다. 덕분에 아이폰이든 맥북이든, 내가 접근할 수 있는 모든 디바이스에서 AI와 이야기할 수 있게 됐다.

쓰는 방법은 간단하다. 개발 공부하면서 모르는 게 있거나 지식으로 정리하고 싶은 게 생기면 Telegram으로 AI와 이야기를 나눈다. 그리고 "내 지식에 정리해줘"라고 한마디만 하면 AI가 나의 iCloud에 정리해준다.

그리고 정리한 지식을 잊지 않도록, 매일 아침 9시마다 내 지식을 기반으로 면접 문제 5개를 보내달라고 해뒀다.

이게 생각보다 효과가 좋았다. 출근길에 AI가 보내준 면접 문제를 풀다 보면, 며칠 전에 정리했던 내용이 자연스럽게 다시 떠오른다. 그냥 정리만 하고 끝났을 때보다 확실히 기억에 오래 남는다. 모르는 걸 정리하고, 그걸 질문으로 다시 돌려받는 이 루프가 만들어진 뒤로는 "이거 저번에 봤는데 뭐였지?" 하는 순간이 눈에 띄게 줄었다.

아는 것을 정리하는 게 아니라 모르는 것을 쌓아가는 방식이라, 부담 없이 계속하게 된다. 이 지식 DB가 1년 뒤에 얼마나 쌓여 있을지 기대된다.

다이빙로그-58 세부 말라파스쿠아 - calanggaman

DinoDev — Sat, 3 Jan 2026 22:23:21 +0900

환경

날짜: 2026.01.03

나라: 필리핀

위치: 말라파스쿠아

다이브 포인트: calanggaman

다이빙 센터: 요한 다이브(https://www.johandive.com/)

날씨: 해

조류: 없음

시야: 중간

다이빙

휴식 시간: 48분

시작 시간: 11:37

시작 잔압: 200bar

최대 수심: 16m

다이브 시간: 49분

종료 시간: 12:26

종료 잔압: 60bar

탱크 크기: 11L

탱크 재질: 알루미늄

탱크 종류: Nitrox 32%

수온: 29도

장비

웨이트: 6kg(Belt-6kg)

슈트: Wet(2.5mm)

메모

거북이 완전 가까이봄. 거북이한테 한대 맞음 ㅠ

다이빙로그-57 세부 말라파스쿠아 - calanggaman

DinoDev — Sat, 3 Jan 2026 22:19:47 +0900

환경

날짜: 2026.01.03

나라: 필리핀

위치: 말라파스쿠아

다이브 포인트: calanggaman

다이빙 센터: 요한 다이브(https://www.johandive.com/)

날씨: 해

조류: 없음

시야: 중간

다이빙

휴식 시간: 53분

시작 시간: 10:05

시작 잔압: 200bar

최대 수심: 18m

다이브 시간: 44분

종료 시간: 10:49

종료 잔압: 60bar

탱크 크기: 11L

탱크 재질: 알루미늄

탱크 종류: Nitrox 32%

수온: 29도

장비

웨이트: 6kg(Belt-6kg)

슈트: Wet(2.5mm)

메모

다이빙로그-56 세부 말라파스쿠아 - calanggaman

DinoDev — Sat, 3 Jan 2026 22:19:12 +0900

환경

날짜: 2026.01.03

나라: 필리핀

위치: 말라파스쿠아

다이브 포인트: calanggaman

다이빙 센터: 요한 다이브(https://www.johandive.com/)

날씨: 해

조류: 없음

시야: 중간

다이빙

휴식 시간: 분

시작 시간: 8:23

시작 잔압: 200bar

최대 수심: 25m

다이브 시간: 49분

종료 시간: 9:12

종료 잔압: 60bar

탱크 크기: 11L

탱크 재질: 알루미늄

탱크 종류: Nitrox 32%

수온: 29도

장비

웨이트: 6kg(Belt-6kg)

슈트: Wet(2.5mm)

메모

다이빙로그-55 세부 말라파스쿠아 - kimud shoal

DinoDev — Sat, 3 Jan 2026 20:36:44 +0900

환경

날짜: 2026.01.02

나라: 필리핀

위치: 말라파스쿠아

다이브 포인트:

다이빙 센터: 요한 다이브(https://www.johandive.com/)

날씨: 해

조류: 없음

시야: 중간

다이빙

휴식 시간: 62분

시작 시간: 12:53

시작 잔압: 200bar

최대 수심: 18m

다이브 시간: 47분

종료 시간: 13:40

종료 잔압: 60bar

탱크 크기: 11L

탱크 재질: 알루미늄

탱크 종류: Air

수온: 29도

장비

웨이트: 6kg(Belt-6kg)

슈트: Wet(2.5mm)

메모

파도가 조금 있어서 다른 배들은 먼저 갔고 우리는 남아서 마지막 다이빙을 진행했다.

바다 속에는 우리만 있어서 그런지 환도상어가 아주 가까이 와서 좋은 영상을 찍을 수 있었다.

다이빙로그-54 세부 말라파스쿠아 - kimud shoal

DinoDev — Sat, 3 Jan 2026 20:34:13 +0900

환경

날짜: 2026.01.02

나라: 필리핀

위치: 말라파스쿠아

다이브 포인트: kimud shoal

다이빙 센터: 요한 다이브(https://www.johandive.com/)

날씨: 해

조류: 없음

시야: 좋음

다이빙

휴식 시간: 49분

시작 시간: 11:04

시작 잔압: 200bar

최대 수심: 23m

다이브 시간: 47분

종료 시간: 11:51

종료 잔압: 70bar

탱크 크기: 11L

탱크 재질: 알루미늄

탱크 종류: Air

수온: 29도

장비

웨이트: 6kg(Belt-6kg)

슈트: Wet(2.5mm)

메모

큰 환도상어 한마리와 작은 환도상어 한마리를 볼 수 있었다.

다이빙로그-53 세부 말라파스쿠아 - monad shoal

DinoDev — Sat, 3 Jan 2026 20:31:27 +0900

환경

날짜: 2026.01.02

나라: 필리핀

위치: 말라파스쿠아

다이브 포인트: monad shoal

다이빙 센터: 요한 다이브(https://www.johandive.com/)

날씨: 해

조류: 없음

시야: 중간

다이빙

휴식 시간: 분

시작 시간: 09:29

시작 잔압: 200bar

최대 수심: 15m

다이브 시간: 46분

종료 시간: 10:15

종료 잔압: 80bar

탱크 크기: 11L

탱크 재질: 알루미늄

탱크 종류: Air

수온: 29도

장비

웨이트: 6kg(Belt-6kg)

슈트: Wet(2.5mm)

메모

첫 다이브는 체크 다이빙으로 진행함

(Unity) GetComponent 완벽 정리: 기본부터 최적화까지 (feat. InChildren, InParent)

DinoDev — Fri, 26 Dec 2025 10:32:25 +0900

안녕하세요! 유니티로 게임을 개발하다 보면 가장 많이 치는 코드가 무엇일까요? 아마도 transform.position 다음으로 GetComponent가 아닐까 싶습니다.

"내 오브젝트에 붙은 다른 컴포넌트를 가져오고 싶다!" 혹은 "내 자식 오브젝트의 스크립트를 제어하고 싶다!" 할 때 필수적인 이 함수들.

오늘은 **GetComponent 4대장(기본, InChildren, InParent, plural)**의 정확한 차이점과, 실무에서 꼭 지켜야 할 성능 최적화 꿀팁까지 정리해 보겠습니다.

1. 가장 기본: GetComponent<T>()

가장 흔하게 사용하는 함수입니다. "현재 스크립트가 붙어 있는 바로 그 GameObject" 안에서 컴포넌트를 찾습니다.

탐색 범위: 내 GameObject 하나.
특징: 찾고자 하는 컴포넌트가 없으면 null을 반환합니다.

void Start()
{
    // 내 오브젝트에 붙어있는 Rigidbody 가져오기
    Rigidbody rb = GetComponent<Rigidbody>();
    
    if (rb != null)
    {
        rb.AddForce(Vector3.up * 10);
    }
}

2. 자식들 다 나와: GetComponentInChildren<T>()

나(현재 오브젝트)를 포함하여 내 하위(자식, 손자...) 계층 구조를 뒤져서 컴포넌트를 찾습니다.

탐색 범위: 나(Self) + 모든 자식(Children) 오브젝트.
주의점:
1. 나 자신부터 검사합니다. 내 오브젝트에 해당 컴포넌트가 있다면 자식 껀 무시하고 내 껄 반환합니다.
2. 깊이 우선 탐색(DFS) 방식으로 찾으며, 하나라도 찾으면 즉시 탐색을 종료하고 반환합니다.
3. 비활성화(activeSelf == false)된 오브젝트는 기본적으로 무시합니다 (오버로딩으로 포함시킬 수 있음).

// 내 자식들(혹은 나) 중에 MeshRenderer가 있으면 하나만 가져와!
MeshRenderer childMesh = GetComponentInChildren<MeshRenderer>();

3. 부모님 계신가요: GetComponentInParent<T>()

이번엔 반대로 위쪽(부모)으로 올라가며 탐색합니다.

탐색 범위: 나(Self) + 부모(Parent) + 부모의 부모...
특징: 역시 나 자신부터 검사합니다. 주로 UI 버튼에서 상위 캔버스의 특정 스크립트를 찾거나, 캐릭터의 파츠(손, 발)에서 몸통(Main Body) 스크립트를 찾을 때 유용합니다.

// 내 위쪽 계층에 있는 PlayerController 스크립트 찾기
PlayerController player = GetComponentInParent<PlayerController>();

4. 싹 다 긁어모아: GetComponents<T>() (뒤에 's' 주의!)

위의 함수들은 조건에 맞는 컴포넌트를 '딱 하나'만 찾아옵니다. 하지만 한 오브젝트에 BoxCollider가 3개 붙어있다면요? 혹은 자식들에 있는 모든 Enemy 스크립트를 관리하고 싶다면요?

이때 s가 붙은 함수들을 사용합니다. (GetComponents, GetComponentsInChildren 등)

반환 타입: 해당 컴포넌트들의 **배열(T[])**을 반환합니다.

void Start()
{
    // 내 자식들에 있는 모든 'Monster' 스크립트를 가져와서 배열에 담음
    Monster[] monsters = GetComponentsInChildren<Monster>();

    // 반복문으로 전체 제어
    foreach (Monster m in monsters)
    {
        m.Die(); // 전멸 시키기
    }
}

[중요] 실무 개발자의 성능 최적화 Tip

GetComponent 시리즈는 편리하지만, 내부적으로 GameObject를 뒤지는 연산이 들어가기 때문에 비용이 꽤 비싼 함수입니다.

1. 절대 Update() 문에 넣지 마세요!

초보자들이 가장 많이 하는 실수입니다.

// ❌ 최악의 예시 (매 프레임마다 찾으러 다님)
void Update() {
    GetComponent<Rigidbody>().velocity = Vector3.zero;
}

// ✅ 좋은 예시 (캐싱 사용)
Rigidbody rb;

void Start() {
    rb = GetComponent<Rigidbody>(); // 시작할 때 한 번만 찾아서 저장
}

void Update() {
    rb.velocity = Vector3.zero; // 저장된 변수 사용
}

2. TryGetComponent를 애용하세요 (Unity 2019.2+)

최신 유니티 버전에서는 TryGetComponent 사용을 권장합니다. 컴포넌트를 가져오는 동시에 null 체크까지 안전하게 처리하며, 메모리 할당(GC) 측면에서도 미세하게 더 유리합니다.

// 이렇게 쓰세요!
if (TryGetComponent<Rigidbody>(out Rigidbody rb))
{
    // rb가 null이 아닐 때만 실행됨
    rb.mass = 10;
}

마치며

오늘은 유니티 스크립팅의 기초인 GetComponent 패밀리에 대해 알아보았습니다.

내꺼 찾을 땐: GetComponent
자식꺼 찾을 땐: GetComponentInChildren
부모꺼 찾을 땐: GetComponentInParent
여러 개 찾을 땐: GetComponents

이 4가지만 상황에 맞춰 잘 쓰고, 캐싱(Caching)만 습관화한다면 여러분의 코드는 훨씬 깔끔하고 빨라질 것입니다.

(Unity) 인스펙터 창을 깔끔하게! [Header] 속성 완벽 가이드

DinoDev — Sat, 20 Dec 2025 15:45:10 +0900

유니티로 게임을 개발하다 보면 MonoBehaviour 스크립트에 수많은 public 변수나 [SerializeField] 변수들이 쌓이게 됩니다.

변수가 5개, 10개를 넘어가기 시작하면 Inspector(인스펙터) 창은 그야말로 혼돈의 도가니가 되곤 하죠. 어떤 게 이동 속도인지, 어떤 게 공격력인지 한눈에 들어오지 않아 스크롤을 위아래로 내리며 시간을 낭비한 경험, 다들 있으시죠?

오늘은 코드 한 줄로 여러분의 인스펙터 창을 전문가처럼 깔끔하게 정리해 주는 [Header] 속성에 대해 알아보겠습니다.

1. [Header] 속성이란?

[Header]는 유니티 인스펙터 창에서 변수들 위에 굵은 제목(라벨)을 달아주는 속성(Attribute)입니다.

기능적으로 게임 로직에 아무런 영향을 주지 않지만, 개발자(또는 레벨 디자이너)가 인스펙터 창을 볼 때 변수들의 카테고리를 시각적으로 구분해 주는 아주 강력한 도구입니다.

사용법

사용법은 매우 간단합니다. 변수 선언부 바로 위에 [Header("제목")]만 적어주면 됩니다.

[Header("보여질 텍스트")]
public int myVariable;

2. 실제 예제로 비교하기

RPG 게임의 플레이어 스크립트를 작성한다고 가정해 봅시다. 체력, 마나, 이동 속도, 점프력, 공격력, 공격 범위 등 수많은 변수가 섞여 있다면 어떻게 보일까요?

❌ [Header] 적용 전

변수들이 아무런 구분 없이 나열되어 있어 가독성이 떨어집니다.

using UnityEngine;

public class PlayerStats : MonoBehaviour
{
    public float health = 100f;
    public float mana = 50f;
    public float moveSpeed = 5f;
    public float runMultiplier = 1.5f;
    public float jumpForce = 10f;
    public int attackDamage = 20;
    public float attackRange = 2.5f;
    public float attackSpeed = 1.2f;
}

✅ [Header] 적용 후

변수들을 성격에 맞게 그룹화하여 인스펙터에서 훨씬 직관적으로 보입니다.

using UnityEngine;

public class PlayerStats : MonoBehaviour
{
    [Header("Base Stats")] // 기본 스탯 그룹
    public float health = 100f;
    public float mana = 50f;

    [Header("Movement Settings")] // 이동 관련 설정 그룹
    public float moveSpeed = 5f;
    public float runMultiplier = 1.5f;
    public float jumpForce = 10f;

    [Header("Combat Settings")] // 전투 관련 설정 그룹
    public int attackDamage = 20;
    public float attackRange = 2.5f;
    public float attackSpeed = 1.2f;
}

이제 인스펙터 창을 보면 "Base Stats", "Movement Settings", "Combat Settings"라는 굵은 제목 아래에 변수들이 예쁘게 정렬된 것을 볼 수 있습니다.

3. 함께 쓰면 좋은 꿀팁 속성들

[Header]만 써도 훌륭하지만, 다음 속성들과 함께 사용하면 인스펙터의 가독성이 200% 상승합니다.

1) [Space]

[Header]는 제목을 달아주지만, 위쪽 변수와 간격을 벌려주지는 않습니다. 그룹 간에 시원한 여백을 주고 싶다면 [Space]를 사용하세요.

[Space(10)] // 10픽셀만큼 띄우기
[Header("Movement Settings")]
public float moveSpeed;

2) [Tooltip]

변수에 마우스를 올렸을 때 설명을 띄워주는 기능입니다. 협업할 때 필수적입니다.

[Header("Combat")]
[Tooltip("플레이어의 기본 공격 데미지입니다.")]
public int damage;

4. 주의사항

따옴표 필수: [Header("제목")] 안에는 반드시 큰따옴표("")로 문자열을 감싸야 합니다.
첫 번째 변수에만: 그룹의 가장 첫 번째 변수 위에만 적어주면 됩니다.
Private 변수: private 변수라도 [SerializeField]를 사용해 인스펙터에 노출시킨다면 [Header]를 적용할 수 있습니다.

마무리

작은 습관이 개발 속도를 바꿉니다. 지금 당장 여러분의 복잡한 스크립트를 열어 [Header] 한 줄을 추가해 보세요. 나중에 이 코드를 다시 볼 미래의 자신과, 함께 일하는 동료들이 여러분에게 고마워할 것입니다!

(Unity) transform.position은 Vector3인데, 왜 Vector2 변수에 그냥 들어갈까?

DinoDev — Sat, 20 Dec 2025 15:11:10 +0900

안녕하세요! 유니티로 2D 게임을 개발하다 보면 문득 의아한 점이 생깁니다.

우리는 분명 transform.position은 3D 좌표인 Vector3 타입이라고 배웠습니다.

그런데 실제 코드를 짤 때는 Vector2 변수에 그냥 대입해도 아무런 에러가 나지 않습니다.

void Update() {
    // Vector3 타입을 Vector2 변수에 넣는데 에러가 안 난다?
    Vector2 myPos = transform.position; 
}

혹시 유니티가 2D 모드라서 알아서 타입을 바꿔준 걸까요? 아닙니다. 여기에는 C# 언어의 아주 편리하면서도 재미있는 비밀이 숨겨져 있습니다.

오늘은 겉으로 보이는 현상뿐만 아니라, 그 내부에서 일어나는 실제 코드의 동작 원리(암시적 형변환과 연산자 오버로딩)까지 깊이 있게, 하지만 아주 쉽게 파헤쳐 보겠습니다.

1. 팩트 체크: Unity는 뼈속까지 3D 엔진이다

가장 먼저 확실히 짚고 넘어가야 할 사실이 있습니다. 여러분이 2D 프로젝트를 생성했더라도, transform.position은 언제나 Vector3 (x, y, z) 타입입니다.

유니티의 인스펙터 창을 자세히 보세요. 2D 스프라이트라도 Transform 컴포넌트에는 항상 X, Y, Z 세 가지 축이 모두 존재합니다.

단지 2D 게임에서는 우리가 Z축을 잘 안 쓰거나, 카메라가 평면으로 비춰주고 있을 뿐이죠.

그렇다면, 왜 3개짜리 데이터(Vector3)가 2개짜리 그릇(Vector2)에 쏙 들어가는 걸까요?

2. 마법의 정체: 암시적 형변환 연산자 (Implicit Operator)

이 현상은 유니티의 버그가 아니라, C# 문법을 이용해 유니티 개발자들이 미리 만들어둔 변환 규칙 덕분입니다.

이를 전문 용어로 연산자 오버로딩(Operator Overloading) 중에서도 암시적 형변환(Implicit Conversion)이라고 부릅니다.

우리가 보는 Vector3 구조체의 내부 코드를 뜯어보면(실제로는 컴파일되어 있지만), 대략 아래와 같은 형태의 특수 함수가 숨겨져 있습니다.

Vector3 내부의 비밀 코드

public struct Vector3
{
    public float x;
    public float y;
    public float z;

    // 핵심: 'implicit operator' 키워드
    // 의미: "누군가 나(Vector3)를 Vector2로 쓰려고 하면, 이 함수를 몰래 실행해."
    public static implicit operator Vector2(Vector3 v)
    {
        // Vector3의 x, y만 따서 새로운 Vector2를 반환 (z는 버림)
        return new Vector2(v.x, v.y);
    }
}

Vector2 내부의 비밀 코드

반대로 Vector2에도 비슷한 코드가 들어있습니다.

public struct Vector2
{
    public float x;
    public float y;

    // 의미: "누군가 나(Vector2)를 Vector3로 쓰려고 하면, 이 함수를 실행해."
    public static implicit operator Vector3(Vector2 v)
    {
        // x, y는 그대로 쓰고, z 자리에 0을 채워서 반환
        return new Vector3(v.x, v.y, 0);
    }
}

즉, 개발자가 일일이 변환 함수를 호출하지 않아도 컴파일러가 알아서 이 타입은 저 타입으로 바꿀 수 있다고 약속되어 있어라고 판단하고 변환 코드를 끼워 넣는 것입니다.

3. 컴파일러가 하는 일 (자동 통역)

여러분이 코드를 작성하고 플레이 버튼을 누르면, 컴파일러는 여러분의 코드를 기계가 이해할 수 있게 번역합니다. 이 과정에서 어떤 일이 일어날까요?

작성한 코드

Vector3 pos3D = new Vector3(10, 20, 5);
Vector2 pos2D = pos3D; // 그냥 대입

컴파일러가 실제로 변환한 코드

Vector3 pos3D = new Vector3(10, 20, 5);
// 컴파일러: "타입이 다르네? 아! implicit operator가 정의되어 있구나. 함수를 호출하자."
Vector2 pos2D = Vector3.op_Implicit(pos3D); // 변환 함수 자동 호출

우리가 (Vector2)라고 명시적으로 형변환을 적지 않아도 되는 이유는, 컴파일러가 이 약속된 규칙을 보고 알아서 처리해주기 때문입니다.

4. 왜 명시적(Explicit)이 아니라 암시적(Implicit)일까?

C#에서는 보통 데이터 손실이 일어나는 변환(Vector3에서 z값이 사라지는 상황)은 명시적(Explicit) 키워드를 사용해서, 개발자가 (Vector2)pos3D 처럼 직접 캐스팅을 하도록 강제하는 것이 원칙입니다. 실수를 방지하기 위해서죠.

하지만 유니티는 게임 개발의 편의성을 선택했습니다.

"2D 게임을 만들 때 transform.position은 무조건 Vector3인데, 이걸 매번 (Vector2)transform.position이라고 캐스팅해서 쓰게 하면 개발자들이 너무 귀찮지 않을까? 그냥 자동으로 되게 해주자!"

이러한 유니티 엔지니어들의 배려 덕분에 우리는 코드를 훨씬 간결하게 작성할 수 있게 된 것입니다.

5. 주의! 초보자가 자주 겪는 Z축 실종 사건

하지만 이 편리함에는 함정이 있습니다. 바로 Z축 데이터의 손실입니다. 암시적 변환이 일어날 때, Vector2에서 Vector3로 갈 때는 Z가 무조건 0으로 채워진다는 점을 잊으면 안 됩니다.

버그가 발생하는 코드 예시

내 캐릭터가 현재 (5, 5, -10) 위치에 있어서 카메라에 잘 보인다고 가정해 봅시다. (Z가 -10이라서 카메라 앞에 있음)

void Update() {
    // 1. 현재 위치를 Vector2로 가져옵니다. 
    // 여기서 Z값(-10)은 버려집니다! -> (5, 5)
    Vector2 tempPos = transform.position; 
    
    // 2. X 좌표만 살짝 움직입니다.
    tempPos.x += 1f; 

    // 3. 다시 적용합니다. 
    // 이때 Vector2 -> Vector3 변환이 일어나면서 Z는 자동으로 '0'이 됩니다.
    transform.position = tempPos; 
    
    // 결과: 내 캐릭터 위치는 (6, 5, 0)이 되었습니다.
    // 원래 있던 -10이 0으로 바뀌면서, 배경 뒤로 숨거나 카메라에서 사라질 수 있습니다!
}

올바른 해결 방법

Z축 값을 유지하면서 X, Y만 바꾸고 싶다면, Vector2 변수에 담았다가 다시 넣는 것보다는 아래처럼 새로운 Vector3를 만드는 것이 가장 안전합니다.

// Z값은 원래 내 Z값을 그대로 유지!
transform.position = new Vector3(newX, newY, transform.position.z);

요약

transform.position은 2D 프로젝트여도 무조건 Vector3 타입입니다.
Vector2로 그냥 써도 되는 이유는 유니티 내부 코드에 정의된 암시적 형변환(Implicit Operator) 기능 덕분입니다.
컴파일러가 이 규칙을 보고 자동으로 변환 함수를 연결해 줍니다.
편리하지만 변환 과정에서 Z값이 0으로 초기화되거나 사라질 수 있으니, 깊이(Depth)가 중요한 게임에서는 주의해야 합니다.

[AI 시대의 생존 전략] 개발자가 집중해야 할 ‘나머지 30%’의 가치

DinoDev — Fri, 19 Dec 2025 14:12:37 +0900

생성형 AI의 등장으로 개발의 패러다임이 바뀌고 있습니다. 코드를 작성하는 속도는 비약적으로 빨라졌고, 누구나 그럴듯한 결과물을 만들어낼 수 있는 시대가 되었습니다. 하지만 이것이 개발자의 종말을 의미할까요? 아닙니다. 오히려 개발자의 '진짜 역량'이 더욱 중요해지는 시기가 도래했습니다.

개발자는 이제 AI가 잘하는 70%의 영역을 적극적으로 위임하고, 인간만이 할 수 있는 나머지 30%의 핵심 역량에 집중해야 합니다. 오늘은 시니어와 주니어, 각 연차별로 이 30%를 채우기 위해 어떤 전략을 취해야 하는지 이야기해보려 합니다.

1. 시니어 개발자: 전략가이자 멘토가 되어야 한다

시니어 개발자는 단순히 '코드를 빨리 짜는 사람'이 아닙니다. AI라는 강력한 도구를 손에 쥔 지금, 시니어의 역할은 '나무를 베는 인부'에서 '집을 짓는 건축가'로 확장되어야 합니다.

도메인 지식과 직관을 통한 결정 (Decision Making)

AI는 수많은 나무를 순식간에 베어다 줄 수 있습니다. 하지만 "어떤 나무를 베어야 하는가?", "이 자재로 어떻게 튼튼한 집을 지을 것인가?"를 결정하는 것은 결국 사람입니다. 시니어 개발자는 오랜 경험에서 축적된 도메인 지식과 문제 발생 가능성을 꿰뚫어 보는 직관(Intuition)을 발휘해야 합니다. AI가 해결할 수 없는 비즈니스의 맥락과 기술적 결정은 여전히 여러분의 몫입니다.

'물고기 잡는 법'을 가르치는 멘토링

주니어 개발자가 AI를 통해 코드를 쏟아낼 때, 시니어는 단순히 그 코드를 리뷰하고 실수를 잡아주는 것에 그쳐서는 안 됩니다.

검증하는 방법을 전수하세요: 주니어가 AI의 결과물을 스스로 검토하고 테스트하는 방법을 가르쳐야 합니다.
판단력을 길러주세요: "이 코드가 왜 문제인지", "더 나은 아키텍처는 무엇인지"에 대한 전략적 사고를 공유해야 합니다.

앞으로 시니어의 가치는 판단력, 전략적 사고, 그리고 후배를 육성하는 리더십에서 증명될 것입니다.

2. 주니어 개발자: '작동하는 코드' 그 이상을 보라

AI 어시스턴트 덕분에 코딩과 테스트 작성에 드는 물리적인 시간은 획기적으로 줄었습니다. 하지만 주니어 개발자는 그 줄어든 시간을 '편안함'이 아닌 '깊이'를 더하는 데 써야 합니다.

숲을 보는 눈: 아키텍처와 요구사항

단순 구현보다 중요한 것은 전체 그림을 이해하는 것입니다.

기존 시스템의 이해: 레거시 아키텍처를 충분히 파악하고, 요구사항을 명확하게 명시할 수 있어야 합니다.
일관성 유지: AI가 생성한 코드가 기존 프로젝트의 패턴과 일관성을 유지하는지 검토해야 합니다.
보안과 엣지 케이스: AI가 놓치기 쉬운 보안 취약점이나 극단적인 상황(Edge Case)을 찾아내는 눈을 길러야 합니다.

❓ 'Why'를 질문하는 습관

AI가 작성한 코드를 맹신하지 마세요. 주니어 개발자는 항상 "왜?"라는 질문을 던져야 합니다.

"AI는 왜 이 방식을 선택했는가?"
"이 코드는 줄 단위로 어떤 역할을 하는가?"

AI에게 코드 설명을 요청하여 기초 지식을 다지고, AI가 내린 결정이 타당한지 판단하는 사고력을 길러야 합니다. 최종 결정권자는 AI가 아니라 바로 '나'이기 때문입니다.

️ AI 안전망 없는 '야생'의 훈련

아이러니하게도 AI를 잘 쓰기 위해서는 가끔 AI를 끄는 시간이 필요합니다.

맨땅에 헤딩하기: AI 없이 스스로 문제를 해결하고 디버깅하는 연습을 하세요. 이 과정이 없으면 AI가 없을 때 아무것도 할 수 없는 개발자가 됩니다.
철저한 검증: LLM이 짠 코드는 '잘 돌아갈 것'이라는 믿음 대신, '틀렸을지도 모른다'는 의심을 가져야 합니다. 포괄적인 유닛 테스트와 수동 테스트를 통해 비즈니스 로직을 철저히 검증하는 습관을 들이세요.

결국 '안목'의 싸움

코드를 작동하게 만드는 것은 이제 누구나 할 수 있는 일이 되었습니다. 하지만 좋은 코드 구조를 설계하고, 유지보수하기 좋은 스타일을 만들며, 비즈니스 가치를 창출하는 안목은 AI가 대신해 줄 수 없습니다.

AI는 훌륭한 러닝메이트입니다. 하지만 그 속도를 제어하고 올바른 방향으로 이끄는 것은 결국 개발자 본인의 기본기와 통찰력임을 잊지 마시기 바랍니다.

바이브 코딩(Vibe Coding)의 핵심 원칙 12가지

DinoDev — Thu, 18 Dec 2025 21:34:35 +0900

최근 개발 생태계에서 AI는 단순한 도구를 넘어 협업의 파트너로 자리 잡았습니다. 하지만 AI에게 모든 것을 맡기는 '자동 조종' 방식은 때로 예상치 못한 버그와 기술 부채를 남기기도 합니다.

진정한 의미의 바이브 코딩(Vibe Coding)은 감(Vibe)에만 의존하는 것이 아니라, AI와의 명확한 경계를 설정하고 주도권을 유지하는 데서 시작됩니다. 바이브 코딩을 위한 핵심 원칙 12가지와 그에 대한 저의 생각을 공유합니다.

1. 명확한 커뮤니케이션: AI는 마법사가 아닌 '주니어'다

AI와의 협업에서 가장 중요한 것은 명확성입니다. AI는 우리의 마음을 읽는 것이 아니라, 우리가 제공한 텍스트를 기반으로 동작하기 때문입니다.

원하는 내용을 구체적이고 명확하게 전달한다.
- 모호한 지시는 모호한 코드를 만듭니다. 맥락(Context)을 충분히 제공할수록 AI의 출력 결과는 우리가 의도한 정답에 가까워집니다
AI를 주니어 개발자처럼 감독한다.
- 실력이 좋지만 경험이 부족한 주니어에게 업무를 맡길 때처럼, 명확한 가이드라인을 주고 결과물을 꼼꼼히 살피는 태도가 사고를 방지합니다.
AI에게 생각을 맡기지 않는다.
- 비즈니스 로직의 본질과 핵심 설계 결정은 인간의 영역입니다. AI는 '구현'의 효율을 높여주는 도구이지 '의사결정'의 주체가 되어서는 안 됩니다.

2. 엄격한 품질 관리: 신뢰하되 검증하라

AI가 생성한 코드가 당장 에러 없이 작동한다고 해서 '완성'된 것은 아닙니다. 시스템 전체의 안정성을 유지하기 위한 엄격한 기준이 필요합니다.

항상 AI의 출력을 원래 의도와 맞는지 검증한다.
- AI는 확률적으로 단어를 선택하기 때문에 논리적 비약이 생길 수 있습니다. 검증은 불필요한 의심이 아니라 품질 관리를 위한 필수 과정입니다.
인간이 작성했든 AI가 생성했든 모든 코드는 반드시 리뷰를 거친다.
- 코드의 출처보다 중요한 것은 '코드의 품질' 그 자체입니다. 이 원칙은 전체 시스템의 신뢰도를 유지하는 최후의 보루가 됩니다.
이해하지 못하는 코드는 머지하지 않는다.
- '돌아가니까 일단 넣자'는 태도는 관리가 불가능한 기술 부채를 만듭니다. 개발자가 코드에 대한 장악력을 유지해야만 추후 유지보수가 가능합니다.

3. 체계적인 프로세스: 기록과 분리

AI와 함께 개발 속도를 높일 때일수록, 나중에 발생할 문제를 방지하기 위해 흔적을 잘 남겨야 합니다.

코드를 생성하기 전에 미리 규칙을 정한다.
- 컨벤션이나 아키텍처 가이드를 미리 정의하는 것은 AI에게 정확한 '지도'를 쥐여주는 것과 같습니다. 이 과정이 결과물의 일관성을 결정합니다.
AI 변경 사항을 분리할 수 있도록 별도의 커밋을 수행한다.
- 나중에 발생할 수 있는 버그의 원인을 추적하고, AI가 개입한 범위를 명확히 파악하기 위한 매우 실무적이고 효과적인 전략입니다.
문서, 주석, 아키텍처 결정 기록(ADR)을 우선시 한다.
- 코드는 결과물일 뿐입니다. 왜 이러한 구조를 선택했는지에 대한 논리적 기록은 AI가 대신해 줄 수 없는 인간 개발자의 고유한 자산입니다.

4. 팀 문화로의 통합: 공유와 지속적인 개선

AI 활용 능력을 개인의 기술로만 두지 않고, 팀 전체의 생산성으로 전환하는 과정이 필요합니다.

AI 사용을 개발 관련 소통의 자연스러운 부분으로 생각한다.
- AI를 특별한 치트키가 아니라 코드 리뷰어, 페어 프로그래밍 파트너처럼 팀의 일원으로 수용할 때 협업의 시너지가 발생합니다.
효과적인 프롬프트를 공유하고 재사용한다.
- 시행착오를 통해 얻은 효율적인 소통 방식을 팀의 자산으로 만들면, 조직 전체의 작업 효율이 상향 평준화될 수 있습니다.
정기적으로 성찰하고 이터레이터를 개선한다.
- 기술 환경은 계속해서 변합니다. 우리가 AI와 협업하는 방식이 여전히 최선인지 주기적으로 돌아보고 개선하는 태도가 진정한 바이브 코딩의 완성입니다.

마치며

바이브 코딩은 단순히 편하게 코딩하는 기술이 아니라, 인간 개발자가 더 높은 수준의 설계와 의사결정에 집중할 수 있도록 AI와 리듬을 맞추는 과정입니다.

(Unity) 근처 적을 스캔하고 최단 거리 대상 찾기

DinoDev — Sat, 13 Dec 2025 23:37:47 +0900

게임 개발을 하다 보면, 캐릭터가 주변의 적이나 아이템을 자동으로 감지하고 그중에서 가장 가까운 대상을 선택해야 하는 경우가 정말 많습니다.

유니티 2D 환경에서 Physics2D.CircleCastAll을 활용하여 주변 목표물을 효과적으로 스캔하고, 가장 가까운 대상을 정확하게 찾아내는 방법에 대한 스크립트를 공유하고 분석해 보겠습니다.

핵심 스캐너 스크립트 살펴보기

이 스크립트는 Scanner라는 이름으로 MonoBehaviour를 상속받으며, 주변을 원 형태로 스캔하는 역할을 합니다.

public class Scanner : MonoBehaviour
{
    public float scanRange;
    public LayerMask targetLayer;
    public RaycastHit2D[] detectedTargets;
    public Transform nearestTarget;
    // ... (메소드)
}

변수 해설

scanRange: 우리가 주변을 탐색할 원의 반지름(반경)입니다. 인스펙터 창에서 쉽게 조절하며 탐색 범위를 시각적으로 확인할 수 있습니다.
targetLayer: 가장 중요한 설정입니다! 적이나 목표물 등 감지하고자 하는 대상이 속한 레이어를 지정합니다. 불필요한 오브젝트(배경, 벽 등)를 걸러내는 필터 역할을 합니다.
nearestTarget: 최종적으로 감지된 대상 중에서 가장 가까운 대상의 Transform이 여기에 저장됩니다.

스캔 작동 원리

CircleCastAll의 마법주변 감지는 물리 업데이트 주기인 FixedUpdate에서 실행됩니다. 이는 물리 관련 작업의 안정성을 높여줍니다.

void FixedUpdate()
{
    detectedTargets = Physics2D.CircleCastAll(
        transform.position, // 기준 위치 (나 자신)
        scanRange,          // 탐색 범위 (반지름)
        Vector2.zero,       // 방향 (고정된 원 형태이므로 zero)
        0f,                 // 거리 (고정된 원 형태이므로 0)
        targetLayer         // 탐색할 레이어 마스크
    );

    nearestTarget = FindNearestTarget();
}

`Physics2D.CircleCastAll`을 사용한 이유

이 메소드는 특정 지점(transform.position)에 반경 scanRange를 가진 원을 만들었을 때, 그 원 안에 겹치는 모든 2D 충돌체 정보를 배열(detectedTargets)로 반환합니다.

direction과 distance를 Vector2.zero와 0f로 설정함으로써, 우리는 "현재 위치에 고정된 원 안에 무엇이 있나?"를 묻는 OverlapCircleAll과 거의 동일하게, 하지만 좀 더 유연하게 정보를 얻어낼 수 있습니다.

최단 거리 탐색 알고리즘

가장 가까운 적을 찾아서detectedTargets 배열에는 스캔 범위 내 모든 적의 정보가 담겨 있습니다.
이제 이 중에서 가장 가까운 단 하나의 대상을 골라내야 합니다.

Transform FindNearestTarget()
{
    float nearestDistance = Mathf.Infinity;
    Transform result = null;

    foreach (RaycastHit2D hit in detectedTargets)
    {
        // 1. 기준점과 현재 감지된 대상 간의 실제 거리 계산
        float distance = Vector2.Distance(transform.position, hit.transform.position);

        // 2. 현재 대상의 거리가 지금까지 발견한 '최단 거리'보다 짧은가?
        if (distance < nearestDistance)
        {
            // 3. 더 가까운 대상을 찾았으므로 값 업데이트
            nearestDistance = distance;
            result = hit.transform;
        }
    }
    return result; // 가장 가까운 대상의 Transform 반환
}

우선, nearestDistance를 Mathf.Infinity (무한대)로 초기화합니다. 이렇게 하면 배열의 첫 번째 대상과의 거리가 무조건 최단 거리가 됩니다.
detectedTargets 배열을 foreach 루프로 돌며 모든 대상을 확인합니다.
Vector2.Distance를 이용해 실제 거리를 계산하고, 현재 기록된 nearestDistance와 비교하여 가장 작은 값을 계속 갱신합니다.

최종적으로 루프가 끝났을 때, result에 저장된 Transform이 바로 우리 캐릭터와 가장 가까운 대상이 되는 것입니다!

(Unity) 회전하는 오브젝트 구현 가이드

DinoDev — Fri, 12 Dec 2025 18:13:20 +0900

유니티에서 플레이어 주변을 회전하는 무기나 오브젝트를 어떻게 구현하는지에 대해 알아보겠습니다.

흔히 뱀파이어 서바이버(Vampire Survivors)와 같은 게임에서 볼 수 있는 시스템을 만드는 기초가 될 수 있습니다.

1. 구현 목표 및 미리 보기

우리가 만들고자 하는 것은 다음과 같은 기능을 가진 스크립트입니다:

지속적인 회전: 오브젝트 자체가 특정 속도로 계속 회전합니다.
자식 오브젝트 배치: 회전하는 오브젝트를 부모로 삼아, 여러 개의 자식 오브젝트(무기)를 원형으로 균등하게 배치합니다.

2. C# 스크립트 분석

using UnityEngine;

public class Weapon : MonoBehaviour
{
    // [공개 변수] 유니티 에디터에서 설정 가능
    public GameObject prefab; // 회전하는 무기/오브젝트의 프리헵
    public int count;         // 배치할 무기/오브젝트의 개수
    public float speed;       // 오브젝트의 회전 속도

    // 매 프레임마다 호출됨
    void Update()
    {
        // Z축을 기준으로 'speed * Time.deltaTime'만큼 회전합니다.
        // Time.deltaTime을 곱하여 프레임 속도와 상관없이 일정한 속도로 회전하게 만듭니다.
        transform.Rotate(0, 0, speed * Time.deltaTime);
    }

    // 오브젝트들을 배치하고 위치를 업데이트하는 함수
    void Batch()
    {
        for (int i = 0; i < count; i++)
        {
            Transform bullet;
            if (i < transform.childCount)
            {
                bullet = transform.GetChild(i); // 기존에 생성된 자식 오브젝트 재사용 (최적화)
            }
            else
            {
                bullet = Instantiate(prefab).transform; // 새 자식 오브젝트 생성
                bullet.parent = transform; // 현재 오브젝트를 부모로 설정
            }

            // 위치 및 회전 초기화
            // 부모를 기준으로 로컬 위치를 원점(0,0,0)으로, 로컬 회전을 기본값으로 리셋합니다.
            bullet.localPosition = Vector3.zero;
            bullet.localRotation = Quaternion.identity;

            // 회전 및 위치 적용 (원형 배치)

            // 1. 회전 계산: 'count' 개수만큼 360도를 균등하게 나눕니다.
            Vector3 rotVec = Vector3.forward * 360 * i / count;

            // 2. 오브젝트를 계산된 각도만큼 회전시킵니다.
            bullet.Rotate(rotVec);

            // 3. 오브젝트의 '위' 방향(local up)으로 1.5f만큼 이동시킵니다.
            // 이렇게 하면 부모의 중앙에서 'rotVec' 각도로 1.5f 떨어진 위치에 배치됩니다.
            bullet.Translate(bullet.up * 1.5f, Space.World); 
            // 참고: 'Space.World' 대신 'Space.Self'를 사용하면 더 자연스러운 무기 배치를 할 수도 있습니다.
        }
    }
}

3. 스크립트 주요 기능 설명

A. 회전 구현 (`Update` 함수)

void Update()
{
    transform.Rotate(0, 0, speed * Time.deltaTime);
}

transform.Rotate(x, y, z)는 현재 오브젝트를 주어진 축을 기준으로 회전시키는 함수입니다.
우리는 Z축(0, 0, 1)을 기준으로 speed에 비례하여 회전시킵니다.
Time.deltaTime을 곱해줌으로써 게임이 어떤 프레임 속도로 실행되든 일정한 회전 속도를 유지하게 합니다.

B. 자식 오브젝트 배치 (`Batch` 함수)

Batch 함수는 count 변수에 지정된 개수만큼 자식 오브젝트를 부모 주변에 원형으로 배치합니다.

1. 오브젝트 생성 및 재사용

if (i < transform.childCount)
{
    bullet = transform.GetChild(i); // 기존 자식 오브젝트 재사용
}
else
{
    bullet = Instantiate(prefab).transform; // 새 자식 오브젝트 생성
    bullet.parent = transform; // 현재 오브젝트를 부모로 설정
}

성능 최적화: 이미 생성된 오브젝트가 있다면 재사용하고, 부족할 경우에만 새로 생성합니다. 이는 무기를 업데이트할 때 불필요한 메모리 할당을 줄여줍니다.

2. 원형 위치 계산

// 1. 회전 계산: 'count' 개수만큼 360도를 균등하게 나눕니다.
Vector3 rotVec = Vector3.forward * 360 * i / count;

// 2. 오브젝트를 계산된 각도만큼 회전시킵니다.
bullet.Rotate(rotVec);

// 3. 오브젝트의 '위' 방향(local up)으로 1.5f만큼 이동시킵니다.
bullet.Translate(bullet.up * 1.5f, Space.World);

이 세 줄이 핵심입니다.

먼저 전체 360도를 count 개수로 나누어 각 오브젝트가 가져야 할 균등한 각도를 계산합니다.
오브젝트를 해당 각도만큼 회전시킨 후, 오브젝트의 현재 '위' 방향(local up)으로 특정 거리(예: 1.5f)만큼 이동시킵니다.
결과적으로, 모든 자식 오브젝트는 부모 오브젝트의 중심에서 1.5f 떨어진 원형 궤도에 배치됩니다.

4. 유니티 적용 방법

새 스크립트 생성: WeaponSample.cs 이름으로 C# 스크립트를 생성하고 위 코드를 붙여넣습니다.
부모 오브젝트 준비: 빈 게임 오브젝트(Empty Object)를 하나 만들고 이름을 WeaponParent 등으로 지정합니다. 이 오브젝트에 WeaponSample.cs를 부착합니다.
자식 프리헵 준비: 회전 무기로 사용할 3D 모델이나 2D 스프라이트를 프리헵으로 만들어 준비합니다.
변수 설정:
- WeaponParent 오브젝트를 선택하고, Inspector 창에서 Prefab 슬롯에 준비한 자식 프리헵을 드래그하여 넣어줍니다.
- Count (예: 5)와 Speed (예: 100) 값을 설정합니다.
Batch() 함수 호출: 게임 시작 시 또는 무기의 개수가 바뀔 때마다 다른 스크립트에서 WeaponParent 오브젝트의 Batch() 함수를 호출해 주면 원형 배치가 완료됩니다.

다이빙로그-52 길리 트라왕안 - Meno slope

DinoDev — Fri, 14 Nov 2025 09:59:35 +0900

환경

날짜: 2025.11.11

나라: 인도네시아

위치: 길리 트라왕안

다이브 포인트: Meno slope

다이빙 센터: 선샤인 다이브(https://www.sunshinedive.com/)

날씨: 해

조류: 약함

시야: 좋음

다이빙

휴식 시간: 61분

시작 시간: 10:56

시작 잔압: 200bar

최대 수심: 30m

다이브 시간: 49분

종료 시간: 11:45

종료 잔압: 40bar

탱크 크기: 11L

탱크 재질: 알루미늄

탱크 종류: Air

수온: 30도

장비

웨이트: 6kg(Belt-6kg)

슈트: Wet(2mm) 반팔 반바지

메모

다이빙로그-51 길리 트라왕안 - Deep Turbo

DinoDev — Fri, 14 Nov 2025 09:55:29 +0900

환경

날짜: 2025.11.11

나라: 인도네시아

위치: 길리 트라왕안

다이브 포인트: Deep Turbo

다이빙 센터: 선샤인 다이브(https://www.sunshinedive.com/)

날씨: 해

조류: 약함

시야: 좋음

다이빙

휴식 시간: 분

시작 시간: 09:22

시작 잔압: 200bar

최대 수심: 28m

다이브 시간: 33분

종료 시간: 09:55

종료 잔압: 30bar

탱크 크기: 11L

탱크 재질: 알루미늄

탱크 종류: Air

수온: 29도

장비

웨이트: 6kg(Belt-6kg)

슈트: Wet(2mm) 반팔 반바지

메모

다이빙로그-50 길리 트라왕안 - Turtle Heaven

DinoDev — Fri, 14 Nov 2025 09:20:00 +0900

환경

날짜: 2025.11.11

나라: 인도네시아

위치: 길리 트라왕안

다이브 포인트: Turtle Heaven

다이빙 센터: 선샤인 다이브(https://www.sunshinedive.com/)

날씨: 해

조류: 약함

시야: 좋음

다이빙

휴식 시간: 52분

시작 시간: 10:57

시작 잔압: 200bar

최대 수심: 23m

다이브 시간: 48분

종료 시간: 11:45

종료 잔압: 50bar

탱크 크기: 11L

탱크 재질: 알루미늄

탱크 종류: Air

수온: 30도

장비

웨이트: 6kg(Belt-6kg)

슈트: Wet(2mm) 반팔 반바지

메모

다이빙로그-49 길리 트라왕안 - Shark point

DinoDev — Fri, 14 Nov 2025 09:15:04 +0900

환경

날짜: 2025.11.11

나라: 인도네시아

위치: 길리 트라왕안

다이브 포인트: Shark point

다이빙 센터: 선샤인 다이브(https://www.sunshinedive.com/)

날씨: 해

조류: 약함

시야: 좋음

다이빙

휴식 시간: 분

시작 시간: 09:29

시작 잔압: 200bar

최대 수심: 27m

다이브 시간: 36분

종료 시간: 10:05

종료 잔압: 30bar

탱크 크기: 11L

탱크 재질: 알루미늄

탱크 종류: Air

수온: 29도

장비

웨이트: 6kg(Belt-6kg)

슈트: Wet(2mm) 반팔 반바지

메모

다이빙로그-48 길리 트라왕안 - SUN SET

DinoDev — Tue, 11 Nov 2025 22:55:08 +0900

환경

날짜: 2025.11.11

나라: 인도네시아

위치: 길리 트라왕안

다이브 포인트: SUN SET

다이빙 센터: 선샤인 다이브(https://www.sunshinedive.com/)

날씨: 해/구름

조류: 약함

시야: 좋음

다이빙

휴식 시간: 198분

시작 시간: 14:32

시작 잔압: 200bar

최대 수심: 22m

다이브 시간: 46분

종료 시간: 15:18

종료 잔압: 30bar

탱크 크기: 11L

탱크 재질: 알루미늄

탱크 종류: Air

수온: 29도

장비

웨이트: 6kg(Belt-6kg)

슈트: Wet(2mm) 반팔 반바지

메모

다이빙로그-47 길리 트라왕안 - Bounty Wreck

DinoDev — Tue, 11 Nov 2025 22:51:31 +0900

환경

날짜: 2025.11.11

나라: 인도네시아

위치: 길리 트라왕안

다이브 포인트: Bounty Wreck

다이빙 센터: 선샤인 다이브(https://www.sunshinedive.com/)

날씨: 해/구름

조류: 약함

시야: 좋음

다이빙

휴식 시간: 46분

시작 시간: 10:30

시작 잔압: 200bar

최대 수심: 22m

다이브 시간: 45분

종료 시간: 11:15

종료 잔압: 50bar

탱크 크기: 11L

탱크 재질: 알루미늄

탱크 종류: Air

수온: 30도

장비

웨이트: 6kg(Belt-6kg)

슈트: Wet(2mm) 반팔 반바지

메모

다이빙로그-46 길리 트라왕안 - Halik

DinoDev — Tue, 11 Nov 2025 22:43:58 +0900

환경

날짜: 2025.11.11

나라: 인도네시아

위치: 길리 트라왕안

다이브 포인트: Halik

다이빙 센터: 선샤인 다이브(https://www.sunshinedive.com/)

날씨: 해/구름

조류: 약함

시야: 좋음

다이빙

휴식 시간: 분

시작 시간: 09:00

시작 잔압: 200bar

최대 수심: 21m

다이브 시간: 44분

종료 시간: 09:44

종료 잔압: 50bar

탱크 크기: 11L

탱크 재질: 알루미늄

탱크 종류: Air

수온: 29도

장비

웨이트: 6kg(Belt-6kg)

슈트: Wet(2mm) 반팔 반바지

메모

Unity 내장 오브젝트 풀(Object Pool) 사용하기

DinoDev — Mon, 13 Oct 2025 00:13:34 +0900

게임을 만들다 보면 총알, 이펙트, 몬스터처럼 짧은 시간 동안 반복적으로 생성되고 파괴되는 오브젝트를 자주 다룬다.
이런 경우 단순히 Instantiate()와 Destroy()를 반복하면 성능 저하와 GC(Garbage Collection) 부하가 발생한다.

이 문제를 해결하기 위한 대표적인 패턴이 바로 오브젝트 풀(Object Pool) 이다.

Unity 2021 버전 이후부터는 UnityEngine.Pool 네임스페이스에
내장 풀 시스템이 추가되어, 직접 구현하지 않아도 효율적인 풀을 쉽게 사용할 수 있다.

오브젝트 풀(Object Pool) 이란?

“필요할 때마다 새로 만들지 말고, 미리 만들어둔 오브젝트를 재사용하자.”

오브젝트 풀은 자주 사용되는 오브젝트를 미리 생성해두고 필요할 때 꺼내서 쓰고, 다 쓰면 비활성화 후 다시 보관하는 구조다.

예를 들어, 슈팅 게임에서 총알을 Instantiate()로 계속 만들면

생성 시 메모리 할당
파괴 시 GC 수집
이 반복되며 프레임 드랍이 발생할 수 있다.

하지만 오브젝트 풀을 사용하면 한 번 만들어진 총알을 재활용하므로 성능이 일정하게 유지된다.

Unity 내장 풀 시스템 소개

Unity는 UnityEngine.Pool 네임스페이스 아래에 제너릭 기반의 ObjectPool<T> 클래스를 제공한다.

이 클래스를 사용하면 오브젝트 생성, 회수, 삭제 등의 과정을 콜백 기반으로 손쉽게 관리할 수 있다.

기본 사용 예시

아래는 ObjectPool<GameObject>를 이용해 Enemy를 관리하는 간단한 예시다.

using UnityEngine;
using UnityEngine.Pool;

public class EnemySpawner : MonoBehaviour
{
    [SerializeField] private GameObject enemyPrefab;
    private ObjectPool<GameObject> enemyPool;

    [SerializeField] private int initialPoolSize = 10;
    [SerializeField] private int maxPoolSize = 50;

    void Awake()
    {
        // 오브젝트 풀 초기화
        enemyPool = new ObjectPool<GameObject>(
            createFunc: CreateEnemy,
            actionOnGet: OnTakeFromPool,
            actionOnRelease: OnReturnedToPool,
            actionOnDestroy: OnDestroyPoolObject,
            collectionCheck: false,
            defaultCapacity: initialPoolSize,
            maxSize: maxPoolSize
        );
    }

    // Enemy 오브젝트 생성
    private GameObject CreateEnemy()
    {
        var enemy = Instantiate(enemyPrefab);
        enemy.GetComponent<Enemy>().SetPool(enemyPool);
        return enemy;
    }

    // 풀에서 꺼낼 때 호출
    private void OnTakeFromPool(GameObject enemy)
    {
        enemy.SetActive(true);
    }

    // 풀에 반환될 때 호출
    private void OnReturnedToPool(GameObject enemy)
    {
        enemy.SetActive(false);
    }

    // 풀 크기를 초과해 제거될 때 호출
    private void OnDestroyPoolObject(GameObject enemy)
    {
        Destroy(enemy);
    }

    // Enemy 스폰 및 초기화
    public void SpawnEnemy(Vector3 position)
    {
        var enemy = enemyPool.Get();
        enemy.GetComponent<Enemy>().Init(position);
    }
}

Enemy 스크립트 예시

Enemy가 사라질 때 스스로 풀로 돌아가도록 구성한다.

using UnityEngine;
using UnityEngine.Pool;

public class Enemy : MonoBehaviour
{
    private ObjectPool<GameObject> pool;
    private int maxHp = 100;
    private int currentHp;

    public void SetPool(ObjectPool<GameObject> objectPool)
    {
        pool = objectPool;
    }

    // 위치와 상태를 초기화하는 함수
    public void Init(Vector3 spawnPosition)
    {
        currentHp = maxHp;
        transform.position = spawnPosition;

        // 추가 초기화: 애니메이션, AI 상태 등
        // Rigidbody 속도 초기화 필요 시 여기서
        var rb = GetComponent<Rigidbody>();
        if (rb != null) rb.velocity = Vector3.zero;
    }

    public void TakeDamage(int damage)
    {
        currentHp -= damage;
        if (currentHp <= 0)
        {
            Die();
        }
    }

    private void Die()
    {
        pool.Release(gameObject);
    }
}

주요 파라미터 설명

파라미터	설명
createFunc	오브젝트를 새로 생성할 때 호출되는 함수
actionOnGet	풀에서 오브젝트를 꺼낼 때 호출 (예: SetActive(true))
actionOnRelease	오브젝트를 다시 반환할 때 호출 (예: SetActive(false))
actionOnDestroy	풀 크기를 초과해 제거될 때 호출
collectionCheck	중복 반환 감지 여부 (디버깅용, 성능 저하 가능)
defaultCapacity	초기 생성 개수
maxSize	최대 풀 크기 (초과 시 actionOnDestroy 호출)

장점

✅ 직접 구현 불필요
기존에 직접 Queue나 Stack으로 풀을 만들 필요가 없다.

✅ 일관된 인터페이스
Get(), Release() 메서드만으로 간단히 제어 가능.

✅ 성능 최적화
내부적으로 C++ 레벨에서 관리되어
직접 구현한 C# 풀보다 메모리 관리가 효율적이다.

✅ 자동 메모리 관리
최대 크기 초과 시 자동으로 파괴(OnDestroy)가 호출된다.

⚡ 실무 적용 팁

공통 풀 관리 클래스 작성하기
여러 종류의 오브젝트를 관리한다면,
풀 초기화를 통합 관리하는 PoolManager 클래스를 두는 것이 좋다.
비활성화 시 상태 초기화하기
오브젝트를 반환할 때(actionOnRelease)
위치, 체력, 속도 등 상태를 초기화하면 다음 재사용 시 안정적이다.
maxSize 적정선 정하기
너무 크게 잡으면 메모리 낭비,
너무 작으면 빈번한 생성/파괴가 다시 발생한다.
플레이 환경에 맞는 균형 잡힌 크기를 실험적으로 정하자.

정리

	직접 구현한 풀	Unity 내장 풀
구현 난이도	높음	매우 쉬움
제너릭 지원	직접 구현 필요	기본 지원
자동 관리	❌	✅
성능	좋음	더 안정적
유지보수	어려움	용이함

결론

Unity 2021 이후 버전에서는 내장 오브젝트 풀(ObjectPool) 을 적극 활용하자.
Instantiate() / Destroy()의 반복을 줄이면 프레임 안정성이 크게 향상된다.
적, 총알, 이펙트 등 자주 생성·파괴되는 오브젝트에 필수적이다.
ObjectPool<T>는 가독성, 안정성, 성능을 모두 잡은 Unity의 정답 같은 기능이다.

Unity에서 tag 비교할 때 CompareTag()를 사용해야 하는 이유

DinoDev — Sun, 12 Oct 2025 23:46:21 +0900

Unity에서 객체의 태그를 비교할 때 보통 아래 두 가지 방법 중 하나를 사용한다.

if (gameObject.tag == "Enemy") { ... }

또는

if (gameObject.CompareTag("Enemy")) { ... }

두 코드는 같은 결과를 낼 것처럼 보이지만, Unity 공식 문서에서도 CompareTag() 사용을 권장한다.
그 이유를 하나씩 살펴보자.

1. CompareTag()는 문자열 비교가 아니다

gameObject.tag == "Enemy"는 순수한 문자열 비교 연산이다.
이 말은 곧 매 프레임마다 문자열을 읽고 비교하는 비용이 발생한다는 의미다.

Unity의 tag는 내부적으로 문자열 해시 ID로 관리된다.
CompareTag()는 이 해시 값을 직접 비교하므로 문자열 연산 없이 훨씬 빠르게 처리된다.

✅ 즉, CompareTag()는 "string 비교"가 아니라 "정수 ID 비교"에 가깝다.

⚡ 2. 태그가 존재하지 않을 때의 안정성

다음 코드를 보자.

if (gameObject.tag == "Enemy")

이 경우, 만약 해당 GameObject의 태그가 삭제되었거나 존재하지 않는 태그라면 Unity는 tag 프로퍼티를 접근할 때 예외(UnityException)를 발생시킨다.

반면 CompareTag()는 태그가 존재하지 않더라도 안전하게 false를 반환한다.
즉, 실행 중에 에러로 게임이 중단되는 일이 없다.

✅ CompareTag()는 런타임 안전성까지 고려한 함수다.

3. 가독성과 의도 전달

CompareTag("Enemy")는 “이 객체가 특정 태그인지 비교한다”는 의도가 명확하다.
문자열 비교보다 의미적으로 분명하고, 코드 리뷰 시에도 한눈에 목적이 드러난다.

if (other.CompareTag("Player"))  // 이 객체가 'Player' 태그인지 확인

4. 실제 성능 차이

다음과 같은 테스트를 해보면, 수천 번의 비교에서는 눈에 띄는 차이가 없지만
Update() 안에서 매 프레임 여러 객체의 태그를 검사하는 상황에서는 차이가 커진다.

방식	평균 처리 속도 (상대값)	예외 발생 가능성
gameObject.tag == "Enemy"	느림	있음
CompareTag("Enemy")	빠름	없음

⚙️ CompareTag()는 Unity 내부적으로 C++ 레벨에서 최적화되어 있기 때문에
문자열 비교보다 항상 더 효율적이고 안정적이다.

결론

항목	tag == "Enemy"	CompareTag("Enemy")
비교 방식	문자열 비교	해시 기반 비교
성능	상대적으로 느림	빠름
예외 처리	태그 없을 때 예외 발생	안전하게 false 반환
가독성	일반적	의도가 명확함
권장 여부	❌	✅ Unity 공식 권장 방식

요약

CompareTag()는 문자열 비교가 아니라 내부 해시 비교로 빠르다.
존재하지 않는 태그에 접근해도 예외가 발생하지 않는다.
코드 의도가 명확해지고 유지보수성이 높아진다.
Unity 공식 문서에서도 항상 CompareTag() 사용을 권장한다.

✍️ 참고 문서

https://docs.unity3d.com/ScriptReference/GameObject.CompareTag.html

Unity에서 커맨드(Command) 패턴 활용하기

DinoDev — Sat, 11 Oct 2025 00:45:27 +0900

게임을 만들다 보면 이런 고민을 자주 하게 됩니다

플레이어가 입력한 행동(이동, 공격, 점프 등)을 기록하거나 되돌리고 싶을 때
AI, UI, 플레이어 모두 같은 방식으로 명령을 실행하게 만들고 싶을 때
입력 로직과 실제 행동 로직을 깔끔하게 분리하고 싶을 때

이럴 때 사용하기 좋은 디자인 패턴이 바로 커맨드(Command) 패턴입니다.

커맨드 패턴이란?

요청(행동)을 객체로 캡슐화해서, 실행·취소·재실행 등을 자유롭게 다룰 수 있게 하는 패턴

즉, “명령을 데이터처럼 다루는 방식”이에요.

버튼 클릭 → “공격 명령”
키보드 입력 → “이동 명령”
AI의 의사결정 → “점프 명령”

이런 행동들을 모두 같은 인터페이스로 실행할 수 있게 만들 수 있습니다.

⚙️ 커맨드 패턴의 기본 구조

클래스	역할
ICommand	명령의 인터페이스 (Execute, Undo 정의)
ConcreteCommand	실제 동작을 수행하는 명령 클래스
Invoker	명령을 실행하는 주체 (예: InputManager)
Receiver	실제 행동을 하는 객체 (예: Player, Character 등)

예제 시나리오 — “캐릭터 이동 및 공격”

방향키로 캐릭터를 이동하고, Space키로 공격하는 간단한 2D 게임 예제입니다.

1. ICommand 인터페이스

public interface ICommand
{
    void Execute();
    void Undo();
}

모든 명령은 Execute()로 실행되고, Undo()로 되돌릴 수 있습니다.

2. 실제 명령 클래스들 (Concrete Commands)

using UnityEngine;

public class MoveCommand : ICommand
{
    private Character _character;
    private Vector3 _direction;

    public MoveCommand(Character character, Vector3 direction)
    {
        _character = character;
        _direction = direction;
    }

    public void Execute()
    {
        _character.Move(_direction);
    }

    public void Undo()
    {
        _character.Move(-_direction);
    }
}

public class AttackCommand : ICommand
{
    private Character _character;

    public AttackCommand(Character character)
    {
        _character = character;
    }

    public void Execute()
    {
        _character.Attack();
    }

    public void Undo()
    {
        Debug.Log("공격은 되돌릴 수 없습니다.");
    }
}

3. 캐릭터 클래스 (Receiver)

using UnityEngine;

public class Character : MonoBehaviour
{
    public float moveSpeed = 3f;

    public void Move(Vector3 direction)
    {
        transform.position += direction * moveSpeed * Time.deltaTime;
        Debug.Log($"이동: {direction}");
    }

    public void Attack()
    {
        Debug.Log("공격!");
    }
}

4. 입력 처리 클래스 (Invoker)

using System.Collections.Generic;
using UnityEngine;

public class InputHandler : MonoBehaviour
{
    [SerializeField] private Character _character;

    private Stack<ICommand> _commandHistory = new Stack<ICommand>();

    private void Update()
    {
        ICommand command = null;

        if (Input.GetKey(KeyCode.W)) command = new MoveCommand(_character, Vector3.up);
        if (Input.GetKey(KeyCode.S)) command = new MoveCommand(_character, Vector3.down);
        if (Input.GetKey(KeyCode.A)) command = new MoveCommand(_character, Vector3.left);
        if (Input.GetKey(KeyCode.D)) command = new MoveCommand(_character, Vector3.right);
        if (Input.GetKeyDown(KeyCode.Space)) command = new AttackCommand(_character);

        if (command != null)
        {
            command.Execute();
            _commandHistory.Push(command);
        }

        if (Input.GetKeyDown(KeyCode.Z)) UndoLastCommand();
    }

    private void UndoLastCommand()
    {
        if (_commandHistory.Count > 0)
        {
            var lastCommand = _commandHistory.Pop();
            lastCommand.Undo();
        }
    }
}

실행 흐름 정리

단계	설명
1	InputHandler가 키 입력을 감지
2	해당 입력에 맞는 Command 객체 생성
3	Execute()로 명령 실행 (Character 행동 수행)
4	실행된 명령을 _commandHistory 스택에 저장
5	Z 키 입력 시 마지막 명령을 Undo()로 되돌림

커맨드 패턴의 장점

장점	설명
입력과 행동 분리	입력 로직을 바꿔도 행동 코드 수정이 필요 없음
️ 되돌리기/재실행 구현 용이	명령을 저장해두면 쉽게 Undo/Redo 가능
유연한 확장성	새로운 명령(예: 점프, 회피)을 쉽게 추가 가능
AI, 매크로 등에도 재사용 가능	동일한 명령 객체를 AI나 스크립트에서도 재활용 가능

⚠️ 주의할 점

너무 작은 동작마다 커맨드로 만들면 불필요한 객체 생성이 많아짐
→ 주로 “의미 있는 행동 단위”에만 사용하기
명령 저장(Undo)을 많이 사용한다면
스택 메모리 관리를 신경써야 함

확장 아이디어

AI 행동 시스템
- AI가 행동을 Command로 큐에 넣고 순서대로 실행
플레이어 리플레이 기능
- 명령 기록을 파일에 저장 후 재생
UI 버튼과의 연동
- 버튼 클릭 시 AttackCommand 실행 등

✅ 정리

커맨드 패턴은 **“입력과 행동을 분리”**해서
게임의 유연성과 유지보수성을 높이는 데 매우 유용한 패턴입니다.

Unity에서 이 패턴을 사용하면
입력, 행동, 되돌리기, AI, UI 모두 하나의 구조로 통일할 수 있습니다.

Unity에서 이벤트버스(Event Bus) 패턴 활용하기

DinoDev — Wed, 8 Oct 2025 08:48:55 +0900

Unity에서 게임을 개발하다 보면 여러 오브젝트가 서로 상호작용할 일이 많습니다.

예를 들어:

플레이어가 공격하면 UI 체력이 줄어야 하고
적이 피해를 받고 사망하면 점수 시스템이 반응해야 하고
사운드 매니저가 효과음을 재생해야 하는 경우

이때 직접 참조(player.OnAttack += ui.UpdateHealth)로 연결하면,오브젝트가 많아질수록 코드가 뒤엉키고 유지보수가 어려워집니다.

여기서 이벤트버스(Event Bus) 패턴이 유용합니다.

1️⃣ 이벤트버스(Event Bus)란?

Event Bus는 이벤트를 “중앙 허브”로 모아 관리하고, 필요할 때 전달하는 패턴입니다.

즉,

이벤트를 발행(Publish) 하는 오브젝트
이벤트를 구독(Subscribe) 하는 오브젝트

이 둘을 직접 연결하지 않고,중앙의 Event Bus를 통해 통신하게 하는 방식입니다.

장점:

오브젝트 간 결합도(Coupling) 최소화
이벤트 추가/삭제가 쉽고, 유지보수가 간단
여러 시스템에서 동일 이벤트를 동시에 처리 가능

2️⃣ 간단한 이벤트버스 구현 예제

EventBus 클래스

using System;
using System.Collections.Generic;

public static class EventBus
{
    // 타입별 이벤트 저장
    private static Dictionary<Type, Action<object>> _eventTable = new Dictionary<Type, Action<object>>();

    // 이벤트 구독
    public static void Subscribe<T>(Action<T> listener)
    {
        Type type = typeof(T);
        if (_eventTable.ContainsKey(type))
        {
            _eventTable[type] += (obj) => listener((T)obj);
        }
        else
        {
            _eventTable[type] = (obj) => listener((T)obj);
        }
    }

    // 이벤트 구독 해제
    public static void Unsubscribe<T>(Action<T> listener)
    {
        Type type = typeof(T);
        if (_eventTable.ContainsKey(type))
        {
            _eventTable[type] -= (obj) => listener((T)obj);
        }
    }

    // 이벤트 발행
    public static void Publish<T>(T eventData)
    {
        Type type = typeof(T);
        if (_eventTable.ContainsKey(type))
        {
            _eventTable[type]?.Invoke(eventData);
        }
    }
}

포인트:
T 타입별로 이벤트를 구분해서 발행하고, 구독자가 타입별로 받을 수 있도록 구현했습니다.

이벤트 데이터 정의

public class PlayerDamageEvent
{
    public int Damage;
    public PlayerDamageEvent(int damage)
    {
        Damage = damage;
    }
}

public class EnemyDeadEvent
{
    public int Score;
    public EnemyDeadEvent(int score)
    {
        Score = score;
    }
}

이벤트 발행 예제 (Publisher)

using UnityEngine;

public class Player : MonoBehaviour
{
    public void TakeDamage(int damage)
    {
        Debug.Log($"플레이어가 {damage} 데미지 받음");
        EventBus.Publish(new PlayerDamageEvent(damage));
    }
}

이벤트 구독 예제 (Subscriber)

using UnityEngine;

public class UIManager : MonoBehaviour
{
    private void OnEnable()
    {
        EventBus.Subscribe<PlayerDamageEvent>(OnPlayerDamage);
    }

    private void OnDisable()
    {
        EventBus.Unsubscribe<PlayerDamageEvent>(OnPlayerDamage);
    }

    private void OnPlayerDamage(PlayerDamageEvent e)
    {
        Debug.Log($"UI 업데이트: 플레이어 체력 감소 {e.Damage}");
    }
}

3️⃣ 이벤트버스 패턴 사용 시 주의점

메모리 관리
- 구독 후 반드시 해제(Unsubscribe) 필요
- 안 하면 씬 전환 시 메모리 누수 발생 가능
디버깅 어려움
- 이벤트가 어디서 호출되는지 추적하기 어려움
- 로그를 적극 활용하거나 이벤트 이름/타입을 명확히 작성
고빈도 이벤트 주의
- 프레임마다 호출되는 이벤트에는 적합하지 않음
- Update 내에서 매번 Publish 하는 것은 피해야 함

4️⃣ 이벤트버스를 활용한 장점

느슨한 결합	Publisher와 Subscriber가 서로 몰라도 됨
재사용성	같은 이벤트를 여러 시스템에서 동시에 처리 가능
확장 용이	새 Subscriber만 추가하면 기능 확장 가능

5️⃣ 실제 게임에서의 활용 예시

플레이어 공격 → 적 체력 감소 + UI 체력 감소 + 사운드 재생
적 사망 → 점수 증가 + 아이템 드롭 + 사운드 재생
게임 종료 → UI, 점수판, 효과음 등 여러 시스템 동시에 반응

핵심: 중앙 이벤트 버스를 통해 각 시스템을 독립적으로 연결

6️⃣ 마무리

Unity에서 이벤트버스 패턴을 사용하면:

복잡한 오브젝트 간 상호작용을 간단히 관리
유지보수성 높은 코드 구조를 만들 수 있습니다.

특히 큰 프로젝트나 여러 시스템이 얽힌 게임에서
상태 관리와 UI, 사운드, 점수 시스템 같은 다중 이벤트 처리가 필요할 때
이벤트버스 패턴은 매우 강력한 도구가 됩니다.

Unity에서 상태패턴으로 캐릭터 움직임과 공격 구현하기

DinoDev — Tue, 7 Oct 2025 17:16:43 +0900

유니티에서 캐릭터의 이동, 공격, 피격, 죽음 같은 행동을 관리할 때
조건문(if, switch)으로 상태를 구분하다 보면 코드가 점점 복잡해집니다.

이럴 때 유용한 설계 방법이 바로 상태패턴(State Pattern) 입니다.
이번 글에서는 상태패턴을 이용해 2D 캐릭터가 움직이고, 공격하고, 맞고, 죽는 간단한 예제를 만들어봅니다.

상태패턴이란?

상태패턴은 “객체의 상태에 따라 행동이 달라지는 것”을 각 상태를 클래스로 분리해서 관리하는 방법이에요.

보통 이렇게 바뀌죠

Before (조건문 기반)	After (상태패턴 기반)
if문이 점점 길어짐	각 상태별 클래스로 분리
상태 전환 시 코드 수정 많음	상태 클래스만 수정하면 됨
테스트 어려움	독립적 테스트 가능

예제 시나리오

이번 예제에서 캐릭터는 다음 5가지 상태를 가집니다.

상태설명

Idle	가만히 서 있는 상태
Walk	이동 중인 상태
Attack	공격 중 상태
Hit	피격되어 잠시 멈추는 상태
Dead	체력이 0이 되어 죽은 상태

프로젝트 구조

Scripts/
 ├── Character.cs
 ├── ICharacterState.cs
 ├── IdleState.cs
 ├── WalkState.cs
 ├── AttackState.cs
 ├── HitState.cs
 └── DeadState.cs

1. 상태 인터페이스 정의

모든 상태가 공통으로 가져야 하는 구조입니다.

public interface ICharacterState
{
    void OnEnter();
    void OnExit();
    void Update();
}

각 상태는 “들어올 때”, “나갈 때”, “프레임마다 실행할 때” 세 가지 함수를 가집니다.

2. Character 클래스 만들기

캐릭터는 현재 상태를 가지고 있으며, 입력을 받아서 상태를 바꿉니다.

using UnityEngine;

public class Character : MonoBehaviour
{
    private ICharacterState _currentState;

    // 상태 객체
    private IdleState _idleState;
    private WalkState _walkState;
    private AttackState _attackState;
    private HitState _hitState;
    private DeadState _deadState;

    // 이동 관련
    [SerializeField] private float _moveSpeed = 3f;
    private Vector2 _moveDir;

    // 체력 및 공격
    [SerializeField] private int _health = 100;
    private bool _canAttack = true;
    private float _attackCooldown = 1f;

    // 컴포넌트
    private Animator _animator;
    private SpriteRenderer _renderer;

    private void Awake()
    {
        _animator = GetComponent<Animator>();
        _renderer = GetComponent<SpriteRenderer>();

        _idleState = new IdleState(this);
        _walkState = new WalkState(this);
        _attackState = new AttackState(this);
        _hitState = new HitState(this);
        _deadState = new DeadState(this);
    }

    private void Start()
    {
        ChangeState(_idleState);
    }

    private void Update()
    {
        if (_currentState == _deadState)
            return;

        HandleInput();
        _currentState.Update();
    }

    private void HandleInput()
    {
        // 공격
        if (Input.GetKeyDown(KeyCode.Space) && _canAttack)
        {
            ChangeState(_attackState);
            return;
        }

        // 이동
        float x = Input.GetAxisRaw("Horizontal");
        float y = Input.GetAxisRaw("Vertical");
        _moveDir = new Vector2(x, y).normalized;

        if (_moveDir != Vector2.zero)
            ChangeState(_walkState);
        else
            ChangeState(_idleState);
    }

    public void Move(Vector2 dir)
    {
        transform.Translate(dir * _moveSpeed * Time.deltaTime);
        if (dir.x != 0)
            _renderer.flipX = dir.x < 0;
    }

    public void ChangeState(ICharacterState newState)
    {
        if (_currentState == newState)
            return;

        _currentState?.OnExit();
        _currentState = newState;
        _currentState.OnEnter();
    }

    public void TakeDamage(int damage)
    {
        if (_currentState == _deadState)
            return;

        _health -= damage;
        if (_health <= 0)
            ChangeState(_deadState);
        else
            ChangeState(_hitState);
    }

    public void SetAttackCooldown()
    {
        _canAttack = false;
        Invoke(nameof(ResetAttackCooldown), _attackCooldown);
    }

    private void ResetAttackCooldown() => _canAttack = true;

    public Vector2 GetMoveDir() => _moveDir;
    public Animator Animator => _animator;
}

3. 각 상태 클래스 만들기

IdleState

using UnityEngine;

public class IdleState : ICharacterState
{
    private readonly Character _character;

    public IdleState(Character character)
    {
        _character = character;
    }

    public void OnEnter()
    {
        Debug.Log("대기 상태 진입");
        _character.Animator.Play("Idle");
    }

    public void OnExit() { }

    public void Update() { }
}

WalkState

using UnityEngine;

public class WalkState : ICharacterState
{
    private readonly Character _character;

    public WalkState(Character character)
    {
        _character = character;
    }

    public void OnEnter()
    {
        Debug.Log("걷기 상태 진입");
        _character.Animator.Play("Walk");
    }

    public void OnExit() { }

    public void Update()
    {
        Vector2 moveDir = _character.GetMoveDir();
        _character.Move(moveDir);
    }
}

AttackState (공격 쿨타임 포함)

using UnityEngine;

public class AttackState : ICharacterState
{
    private readonly Character _character;
    private float _attackDuration = 0.5f;
    private float _timer;

    public AttackState(Character character)
    {
        _character = character;
    }

    public void OnEnter()
    {
        Debug.Log("공격 상태 진입");
        _character.Animator.Play("Attack");
        _character.SetAttackCooldown();
        _timer = _attackDuration;
    }

    public void OnExit() { }

    public void Update()
    {
        _timer -= Time.deltaTime;
        if (_timer <= 0)
        {
            _character.ChangeState(new IdleState(_character));
        }
    }
}

⚡ HitState (피격 상태)

using UnityEngine;

public class HitState : ICharacterState
{
    private readonly Character _character;
    private float _hitDuration = 0.3f;
    private float _timer;

    public HitState(Character character)
    {
        _character = character;
    }

    public void OnEnter()
    {
        Debug.Log("피격 상태 진입");
        _character.Animator.Play("Hit");
        _timer = _hitDuration;
    }

    public void OnExit() { }

    public void Update()
    {
        _timer -= Time.deltaTime;
        if (_timer <= 0)
        {
            _character.ChangeState(new IdleState(_character));
        }
    }
}

⚫ DeadState (죽음 상태)

using UnityEngine;

public class DeadState : ICharacterState
{
    private readonly Character _character;

    public DeadState(Character character)
    {
        _character = character;
    }

    public void OnEnter()
    {
        Debug.Log("죽음 상태 진입");
        _character.Animator.Play("Dead");
    }

    public void OnExit() { }

    public void Update() { }
}

상태패턴의 장점

✅ 각 상태가 독립적이라 수정이 쉽습니다.
✅ if문 없이 상태 전환이 깔끔합니다.
✅ 상태 추가(예: 점프, 스킬 등)가 간단합니다.

✨ 마무리

상태패턴은 복잡한 행동을 가진 캐릭터를 관리할 때 정말 강력합니다.
특히 유니티 같은 프레임 기반 구조에서는 “현재 상태가 어떤 로직을 실행할지”를 분리해두면 디버깅도, 확장도 훨씬 쉬워집니다.

Unity에서 추상 클래스 기반 Singleton 패턴 구현하기

DinoDev — Mon, 6 Oct 2025 20:59:44 +0900

게임을 만들다 보면, 전역에서 접근 가능한 매니저 객체가 필요합니다.
예를 들어 GameManager, AudioManager, UIManager처럼 하나만 존재해야 하는 클래스들 말이죠.

이럴 때 사용하는 대표적인 디자인 패턴이 바로 Singleton(싱글톤) 입니다.
이번에는 일반적인 싱글톤이 아니라, 추상 클래스를 기반으로 공통 로직을 재사용할 수 있는 구조로 만들어봅시다.

1️⃣ 기본 아이디어

Unity에서는 MonoBehaviour 기반의 싱글톤을 만들 때,
다른 클래스들이 동일한 패턴을 반복해서 작성하는 경우가 많습니다.
예를 들어 이런 형태를 여러 매니저가 각각 구현하곤 하죠

public class GameManager : MonoBehaviour
{
    public static GameManager Instance;

    void Awake()
    {
        if (Instance == null)
            Instance = this;
        else
            Destroy(gameObject);
    }
}

이런 중복을 줄이기 위해 제네릭 추상 클래스 Singleton<T>를 만들면,
모든 매니저가 상속만으로 동일한 싱글톤 동작을 자동으로 가지게 됩니다.

2️⃣ Singleton 추상 클래스 구현

using UnityEngine;

public abstract class Singleton<T> : MonoBehaviour where T : MonoBehaviour
{
    private static T _instance;
    public static T Instance
    {
        get
        {
            if (_instance == null)
            {
                // 씬에 존재하는 인스턴스 찾기
                _instance = FindFirstObjectByType<T>();

                // 없으면 자동 생성
                if (_instance == null)
                {
                    var obj = new GameObject(typeof(T).Name);
                    _instance = obj.AddComponent<T>();
                }
            }
            return _instance;
        }
    }

    protected virtual void Awake()
    {
        if (_instance == null)
        {
            _instance = this as T;
            DontDestroyOnLoad(gameObject); // 씬 이동 시에도 유지
        }
        else if (_instance != this)
        {
            Destroy(gameObject); // 중복 생성 방지
        }
    }
}

핵심 포인트

where T : MonoBehaviour : 제네릭 타입 T가 MonoBehaviour여야 한다는 제약 조건
FindObjectOfType<T>() : 씬 내 존재 여부 확인
DontDestroyOnLoad() : 씬 전환 시에도 유지
protected virtual void Awake() : 상속받는 클래스가 Awake()를 오버라이드할 수 있도록 허용

3️⃣ GameManager에 적용하기

이제 GameManager를 Singleton<T>를 상속받아 구현하면 됩니다.

using UnityEngine;

public class GameManager : Singleton<GameManager>
{
    public int score = 0;

    protected override void Awake()
    {
        base.Awake(); // 반드시 호출해야 함
        Debug.Log("GameManager Awake");
    }

    public void AddScore(int value)
    {
        score += value;
        Debug.Log($"현재 점수: {score}");
    }
}

이렇게 하면 GameManager는 자동으로 싱글톤 동작을 가지게 됩니다.
씬에 하나만 존재하도록 보장되고, 필요하면 자동 생성까지 이루어집니다.

4️⃣ 다른 스크립트에서 사용하기

public class Player : MonoBehaviour
{
    void OnTriggerEnter(Collider other)
    {
        if (other.CompareTag("Coin"))
        {
            GameManager.Instance.AddScore(10);
        }
    }
}

GameManager.Instance로 전역 접근이 가능하죠.
씬에 GameManager가 없어도 자동 생성되므로, 따로 등록할 필요가 없습니다.

5️⃣ 확장 가능한 구조

이 추상 클래스 기반 구조의 장점은, AudioManager, UIManager, SpawnManager 등 다양한 매니저 클래스가 모두 같은 로직을 상속받아 일관성 있게 동작한다는 것입니다.

public class AudioManager : Singleton<AudioManager>
{
    public void PlayBGM(string name)
    {
        Debug.Log($"BGM 재생: {name}");
    }
}

⚠️ 주의할 점

MonoBehaviour 기반 싱글톤이므로, Unity 씬 안에서만 유효합니다.
base.Awake()를 호출하지 않으면 인스턴스 초기화가 되지 않습니다.
멀티스레드 환경이나 순수 C# 유틸 클래스에는 일반 C# 싱글톤을 사용하는 게 좋습니다.

✅ 정리

항목설명

패턴	Singleton (제네릭 기반 추상 클래스)
장점	중복 제거, 일관된 싱글톤 관리, 자동 생성
사용 예	GameManager, AudioManager, UIManager 등
주의점	반드시 base.Awake() 호출, MonoBehaviour 한정

(Compose) Compose phase - 어떻게 화면을 그릴까?

DinoDev — Mon, 18 Aug 2025 20:16:22 +0900

"Jetpack Compose는 선언형 UI 툴킷입니다." 우리는 이 말을 정말 많이 듣습니다. 단지 상태(State)를 선언하면 UI가 마법처럼 그려진다고 하죠. 그런데 그 '마법' 뒤에서는 어떤 일이 일어나고 있을까요?

Compose가 UI를 화면에 표시하기까지의 과정을 이해하는 것은 단순히 지식을 넘어, 성능을 최적화하고 복잡한 UI 문제를 해결하는 데 매우 중요합니다. 오늘은 Compose의 핵심 동작 원리인 3단계 렌더링 파이프라인(Composition, Layout, Drawing)에 대해 알아보겠습니다.

1단계: Composition - 무엇을 보여줄까?

"어떤 UI를 보여줄지 결정하는 단계"

가장 먼저 Compose는 Composition 단계를 실행합니다. 이 단계에서 Compose 런타임은 우리가 작성한 @Composable 함수들을 호출합니다. 그리고 그 결과로 UI에 대한 '설계도'를 만듭니다. 이 설계도는 단순한 그림이 아니라, UI의 구조와 내용을 담고 있는 데이터 트리(UI Tree)입니다.

최초 컴포지션 (Initial composition): 앱이 처음 실행될 때, Compose는 모든 관련 컴포저블 함수를 실행하여 전체 UI 트리를 구축합니다.
리컴포지션 (Recomposition): 앱의 상태가 변경되면, Compose는 똑똑하게 해당 상태와 관련된 컴포저블 함수만 다시 호출하여 UI 트리의 필요한 부분만 업데이트합니다.

핵심: 이 단계는 오직 '무엇을' 보여줄지에만 관심이 있습니다. 각 UI 요소가 화면 어디에, 어떤 크기로 그려질지는 전혀 신경 쓰지 않습니다.

@Composable
fun Greeting(
    name: String
) {
    // 1. Composition 단계에서 이 Text 함수가 호출됩니다.
    // 2. "Hello $name!" 이라는 내용을 가진 UI 노드가
    //    UI 트리에 생성됩니다.
    Text(
        text = "Hello $name!"
    )
}

2단계: Layout - 어디에 배치할까?

"UI 요소의 크기와 위치를 결정하는 단계"

Composition 단계에서 '무엇을' 보여줄지 결정했다면, Layout 단계에서는 이것들을 '어디에, 얼마나 크게' 배치할지 계산합니다. 이 과정은 모든 UI 노드에 대해 측정과 배치를 수행하며, 2개의 단계(step)로 진행됩니다.

측정 (Measurement): 부모 노드가 자식 노드에게 "이런 제약 조건 안에서 얼마나 크기가 필요하니?"라고 묻습니다. 자식은 자신의 크기를 측정하여 부모에게 보고합니다.
배치 (Placement): 부모는 자식들의 크기 정보를 바탕으로, 각 자식을 자신의 좌표계 내의 정확한 x, y 위치에 배치합니다.

핵심: Modifier.size(), Modifier.padding() 등 레이아웃과 관련된 모든 수정자는 바로 이 단계에서 작동합니다. 부모가 주는 제약 조건(Constraints)과 자식 스스로의 요구사항(Intrinsic size)이 결합하여 최종 크기와 위치가 결정됩니다.

@Composable
fun UserProfile(
    name: String
) {
    // 1. Row가 Text에게 "얼마나 필요해?"라고 묻습니다.
    // 2. Text는 "Hello $name!"을 표시하는데 필요한 너비와 높이를 계산해 응답합니다.
    // 3. Row는 Text를 자신의 시작점(x=0, y=0)에 배치합니다.
    Row(
        modifier = Modifier.padding(
            all = 16.dp
        )
    ) {
        Text(
            text = "Hello $name!"
        )
    }
}

3단계: Drawing - 어떻게 그릴까?

"화면에 실제로 픽셀을 그리는 단계"

이제 모든 UI 요소의 종류, 크기, 위치를 알게 되었습니다. 마지막 Drawing 단계에서는 이 정보를 이용해 화면의 캔버스(Canvas)에 실제로 픽셀을 그립니다. 각 요소는 Modifier.drawBehind나 Modifier.border 같은 수정자를 통해 자신을 어떻게 그려야 하는지에 대한 지침을 가집니다.

핵심: Compose는 이 단계에서도 매우 효율적입니다. 만약 어떤 요소의 색상이나 내용이 아니라 위치만 변경되었다면, Compose는 해당 요소의 픽셀 정보를 다시 그릴 필요 없이 기존의 그래픽 데이터를 그대로 이동시켜 사용하기도 합니다.

⚠️ 주의: 리컴포지션 루프를 피하세요 (Recomposition Loop)

리컴포지션 루프란 이름 그대로 컴포저블이 스스로를 끊임없이 재호출하며 멈추지 않는 상태를 말합니다. 앱은 아무런 반응 없이 얼어붙고, CPU 사용량은 치솟게 되죠.

이 현상은 상태를 읽는(read) 단계에서 그 상태를 다시 쓰는(write) 경우에 발생합니다. 특히 Composition 단계뿐만 아니라 Layout 단계에서 상태를 변경할 때 미묘한 루프가 발생하기 쉽습니다.

❌ 잘못된 예시: 형제 컴포저블의 크기로 레이아웃 변경 시도

아래 코드는 이미지의 실제 높이를 측정하여 그 아래에 있는 텍스트의 상단 패딩을 동적으로 지정하려고 합니다. 하지만 이 구조는 즉시 리컴포지션 루프를 유발합니다.

@Composable
fun BadExample() {
    Box {
        var imageHeightPx by remember { mutableStateOf(0) }

        Image(
            painter = painterResource(R.drawable.rectangle),
            contentDescription = "I'm above the text",
            modifier = Modifier
                .fillMaxWidth()
                .onSizeChanged { size ->
                    // ❌ 나쁨: Layout 단계에서 측정한 값을 State에 기록합니다.
                    imageHeightPx = size.height
                }
        )
        Text(
            text = "I'm below the image",
            modifier = Modifier.padding(
                // 이 Text는 imageHeightPx 상태를 읽고 있습니다.
                // 위 Image에서 이 값이 변경되면 Text가 리컴포지션되고,
                // 전체 프로세스가 다시 시작되어 루프가 발생합니다.
                top = with(LocalDensity.current) { imageHeightPx.toDp() }
            )
        )
    }
}

✅ 올바른 해결책: 목적에 맞는 레이아웃 사용하기 (Column)

이미지 아래에 텍스트를 배치하는 것이 목적이라면, 복잡하게 크기를 측정하고 상태를 전달할 필요가 전혀 없습니다. 단순히 자식들을 수직으로 배치해 주는 Column 컴포저블을 사용하면 모든 문제가 해결됩니다.

Column은 내부적으로 자식들을 하나씩 측정하고 그 순서대로 아래에 배치하는 로직을 모두 처리해 줍니다. 이것이 바로 Compose의 선언적인 힘입니다.

@Composable
fun GoodExample() {
    // ✅ 좋음: Column은 자식들을 수직으로 차례대로 배치합니다.
    // 복잡한 측정이나 상태 전달 없이 원하는 UI를 명확하게 선언할 수 있습니다.
    Column {
        Image(
            painter = painterResource(R.drawable.rectangle),
            contentDescription = "I'm above the text",
            modifier = Modifier.fillMaxWidth()
        )

        Text(
            text = "I'm below the image"
        )
    }
}

만약 더 복잡한 layout을 그려야한다면 ConstraintLayout을 사용할 수 있습니다.

ConstraintLayout을 사용하면 한 요소의 아래(bottom)에 다른 요소의 위(top)를 연결하는 식으로 관계를 직접 선언할 수 있어, 리컴포지션 루프 없이 원하는 UI를 구성할 수 있습니다.

마치며

우리가 보는 Compose 화면은 아래와 같은 과정을 거쳐 완성됩니다.

상태 변경(State Change) → Composition (무엇을?) → Layout (어디에?) → Drawing (어떻게?) → 화면 표시

이 세 단계는 항상 같은 순서로 진행되며, 하나의 프레임을 완성하는 파이프라인처럼 작동합니다.

왜 이것을 알아야 할까요?

성능 최적화: 무거운 계산을 컴포저블 함수 안에 직접 넣으면, 리컴포지션이 일어날 때마다 해당 계산이 반복되어 버벅거림을 유발할 수 있습니다. 이는 Composition 단계에 부담을 주는 행위입니다.
커스텀 레이아웃: Layout 컴포저블을 사용하여 자신만의 커스텀 레이아웃을 만들려면, 측정(Measure)과 배치(Place)가 어떻게 동작하는지 반드시 이해해야 합니다.
디버깅: UI가 예상치 못한 위치에 그려지거나 크기를 차지한다면, 그것은 Layout 단계의 제약 조건(Constraints)과 관련이 있을 가능성이 높습니다.

이제 Compose의 '마법'이 조금은 더 명확하게 보이시나요? 이 세 가지 단계를 기억한다면, 여러분은 더 효율적이고 정교한 UI를 자신 있게 만들어 나갈 수 있을 겁니다.

블로그 글에 대해 궁금한 점이 있다면 아래 카카오톡 오픈채팅에 들어와서 질문해주세요

Android Kotlin Compose QnA

open.kakao.com

(Compose) Compose Side-Effect

DinoDev — Sun, 17 Aug 2025 22:58:00 +0900

Jetpack Compose의 세계에서 컴포저블(Composable) 함수는 '순수함수(Pure Function)' 와 같습니다. 동일한 상태(State)가 주어지면 항상 동일한 UI를 그려내는 '설계도' 역할을 하죠. 이 설계도는 상태가 변경될 때마다, 때로는 초당 수십 번씩 다시 그려질 수 있습니다. 이 과정을 리컴포지션(Recomposition) 이라고 부릅니다.

여기서 한 가지 중요한 규칙이 있습니다. "설계도를 그리는 과정에서 설계도 밖의 세상에 영향을 주어서는 안 된다."

만약 설계도를 그릴 때마다 스낵바를 띄우거나, 네트워크 요청을 보내거나, 데이터베이스에 데이터를 저장한다면 어떻게 될까요? 앱은 순식간에 통제 불능 상태에 빠지고, 수많은 버그와 성능 저하를 일으킬 겁니다.

하지만 현실의 앱은 '바깥 세상'과 소통해야만 합니다. 이처럼 컴포저블의 범위를 벗어나 앱의 상태를 변경하거나 외부와 통신하는 모든 작업을 사이드 이펙트(Side Effect, 부수 효과) 라고 합니다. Compose는 이 위험하고도 필수적인 작업을 안전하게 처리할 수 있도록, 마치 '특별 허가를 받은 통로'와 같은 강력한 API들을 제공합니다.

오늘은 이 '안전한 탈출구', 사이드 이펙트 핸들러들을 하나하나 깊이 있게 파헤쳐 보겠습니다.

LaunchedEffect: 컴포지션 시점의 비동기 작업 실행기

LaunchedEffect는 컴포저블이 처음 화면에 나타나거나(Composition), 특정 key 값이 변경되었을 때 코루틴을 실행하는 가장 기본적이고 널리 사용되는 사이드 이펙트 핸들러입니다.

언제 사용할까요?

화면이 처음 보일 때 초기 데이터를 로딩해야 할 때
특정 상태가 true가 되었을 때 스낵바를 표시하거나 다른 화면으로 이동하고 싶을 때
ViewModel의 StateFlow나 Channel 같은 이벤트를 구독하고 특정 UI 액션을 수행해야 할 때

key의 비밀: 재시작의 열쇠

key가 변경되면: 진행 중이던 기존 코루틴은 **취소(Cancel)**되고, 새로운 key와 함께 내부 코드가 처음부터 재시작됩니다.
key가 변경되지 않으면: 리컴포지션이 일어나도 코루틴은 재시작되지 않고 계속 실행됩니다.
key1 = Unit 또는 key1 = true: key 값이 절대 변하지 않으므로, 컴포저블이 처음 생성될 때 딱 한 번만 실행되고 화면에서 사라질 때까지 유지됩니다.

// 에러 상태에 따라 스낵바 보여주기

@Composable
fun MyScreen(
    viewModel: MyViewModel = hiltViewModel()
) {
    val uiState by viewModel.uiState.collectAsState()
    val scaffoldState = rememberScaffoldState()

    LaunchedEffect(key1 = uiState.errorMessage) {
        uiState.errorMessage?.let { message ->
            scaffoldState.snackbarHostState.showSnackbar(message)
            viewModel.consumeErrorMessage()
        }
    }
    
    Scaffold(scaffoldState = scaffoldState) { /* ... */ }
}

rememberCoroutineScope: 사용자 액션에 응답하는 비동기 작업

사용자가 버튼을 클릭하는 등, 리컴포지션과 상관없는 이벤트 콜백 내에서 코루틴을 실행하고 싶을 때 사용합니다. remember를 통해 컴포저블의 생명주기에 연결된 CoroutineScope를 얻어올 수 있습니다.

언제 사용할까요?

버튼 클릭 시 네트워크 요청을 보내고 로딩 인디케이터를 표시해야 할 때
사용자가 목록을 아래로 당겨 새로고침할 때

// 버튼 클릭 시 프로필 업데이트

@Composable
fun ProfileEditScreen(viewModel: ProfileViewModel) {
    val scope = rememberCoroutineScope()
    var isLoading by remember { mutableStateOf(false) }

    Button(
        onClick = {
            scope.launch {
                isLoading = true
                try {
                    viewModel.updateProfile()
                } finally {
                    isLoading = false
                }
            }
        },
        enabled = !isLoading
    ) { /* ... */ }
}

DisposableEffect: 리소스 생성과 정리가 쌍으로 필요할 때

컴포저블이 화면에 보이는 동안 리스너를 등록하고, 화면에서 사라질 때 해제해야 하는 경우처럼 진입(Setup)과 퇴장(Clean-up) 시점의 작업이 명확하게 쌍을 이룰 때 사용합니다.

언제 사용할까요?

LifecycleObserver를 등록하고 해제할 때
BroadcastReceiver를 등록하고 해제할 때

// 화면의 생명주기 이벤트 감지

@Composable
fun AnalyticsLogger(lifecycleOwner: LifecycleOwner = LocalLifecycleOwner.current) {
    DisposableEffect(key1 = lifecycleOwner) {
        val observer = LifecycleEventObserver { _, event ->
            if (event == Lifecycle.Event.ON_RESUME) logScreenView("enter")
        }
        lifecycleOwner.lifecycle.addObserver(observer)

        onDispose {
            lifecycleOwner.lifecycle.removeObserver(observer)
        }
    }
}

rememberUpdatedState: 최신 값을 참조해야 하는 장기 실행 작업

LaunchedEffect(Unit)처럼 단 한 번만 실행되는 코루틴 내부에서, 재시작 없이 컴포저블의 최신 상태나 람다를 참조해야 할 때 사용합니다.

언제 사용할까요? ⏱️

일정 시간 후 사라지는 화면에서, 사라지기 직전에 최신 상태를 기반으로 액션을 취해야 할 때
계속 실행되는 이펙트 안에서 부모로부터 받은 람다(onClick, onEvent)를 호출해야 할 때

// 최신 람다를 호출하는 타임아웃

@Composable
fun LandingScreen(onTimeout: () -> Unit) {
    val updatedOnTimeout by rememberUpdatedState(onTimeout)
    
    LaunchedEffect(Unit) {
        delay(3000L)
        updatedOnTimeout()
    }
}

SideEffect: Compose 상태를 외부와 공유하기

매 리컴포지션이 성공적으로 완료될 때마다 코드를 실행하고 싶을 때 사용합니다. Compose가 관리하지 않는 외부 객체나 라이브러리와 Compose의 상태를 공유하는 용도로 주로 사용됩니다.

언제 사용할까요?

현재 상태를 외부 분석(Analytics) 라이브러리에 전달할 때
외부 콜백을 통해 UI 상태를 외부에 알릴 때

// 분석 라이브러리에 현재 상태 전달

@Composable
fun UserProfileScreen(user: User) {
    // user 정보가 바뀔 때마다 리컴포지션이 성공적으로 끝나면 호출됩니다.
    SideEffect {
        Analytics.setUserProperty("userName", user.name)
        Analytics.setUserProperty("userTier", user.tier)
    }

    Text("사용자: ${user.name}")
}

produceState: 외부 스트림을 Compose State로 변환

Flow, LiveData, RxJava 등 외부의 비동기적인 데이터 스트림을 Compose가 즉시 사용할 수 있는 State로 변환해줍니다.

언제 사용할까요?

Flow나 다른 데이터 스트림을 구독하여 UI에 표시해야 할 때
네트워크나 데이터베이스로부터 오는 데이터 스트림을 State로 만들고 싶을 때

// Flow를 State로 변환하기

@Composable
fun <T> Flow<T>.collectAsStateWithLifecycle(
    initialValue: T
): State<T> {
    // 위치 정보 Flow를 구독하여 State<Location>으로 변환합니다.
    return produceState(initialValue = initialValue) {
        // 이 블록은 코루틴 스코프입니다.
        // Flow가 새로운 값을 방출(emit)하면 `value`가 업데이트됩니다.
        this@collectAsStateWithLifecycle.collect {
            value = it
        }
    }
}

snapshotFlow: Compose State를 외부 Flow로 변환

produceState의 정반대 역할을 합니다. Compose의 State 객체를 Kotlin Flow 로 변환하여, debounce, map, filter 등 풍부한 Flow 연산자를 활용할 수 있게 해줍니다.

언제 사용할까요?

사용자가 텍스트 입력을 멈췄을 때만 검색 API를 호출하고 싶을 때 (debounce)
스크롤 위치(LazyListState) 같은 Compose 상태의 변화를 ViewModel에서 감지하고 싶을 때

// 입력이 멈추면 자동 검색

@Composable
fun SearchScreen(
    viewModel: SearchViewModel
) {
    var text by remember { mutableStateOf("") }

    TextField(
        value = text,
        onValueChange = { text = it }
    )

    // text State가 변경될 때마다 Flow가 새로운 값을 방출합니다.
    LaunchedEffect(
        key1 = Unit
    ) {
        snapshotFlow { text }
            .debounce(500) // 500ms 동안 입력이 없으면
            .filter { it.isNotEmpty() } // 비어있지 않으면
            .collect { query ->
                viewModel.search(query) // 검색 실행
            }
    }
}

derivedStateOf: 불필요한 리컴포지션을 막는 계산된 State

derivedStateOf는 하나 이상의 State 객체를 기반으로 새로운 State를 계산하여 만듭니다. 핵심은, 내부 State가 바뀔 때마다 리컴포지션을 유발하는 것이 아니라, 계산된 최종 결과가 바뀔 때만 리컴포지션을 유발한다는 것입니다.

언제 사용할까요? ✨

여러 상태에 따라 UI의 가시성이 결정되는데, 이 계산이 자주 일어날 때
LazyListState의 스크롤 위치처럼 매우 빈번하게 변경되는 상태를 기반으로 다른 UI를 제어할 때

// 스크롤 위치에 따라 '맨 위로' 버튼 표시

@Composable
fun MyList() {
    val listState = rememberLazyListState()

    // firstVisibleItemIndex는 스크롤할 때마다 계속 바뀝니다.
    // 하지만 "맨 위로 가기" 버튼의 가시성은 (index > 0)의 결과, 즉 true/false가
    // 바뀔 때만 변경되면 됩니다. derivedStateOf가 바로 이 역할을 합니다.
    val showButton by remember {
        derivedStateOf {
            listState.firstVisibleItemIndex > 0
        }
    }

    Box {
        LazyColumn(
            state = listState
        ) { 
            // ... list content ...
        }

        AnimatedVisibility(
            visible = showButton,
            modifier = Modifier.align(Alignment.BottomCenter)
        ) {
            Button(
                onClick = { /* ... */ }
            ) {
                Text(text = "맨 위로")
            }
        }
    }
}

마치며

오늘 우리는 Compose가 제공하는 거의 모든 종류의 사이드 이펙트 핸들러를 깊이 있게 탐험했습니다. 각 핸들러는 저마다의 명확한 역할과 목적을 가지고 있으며, 이들을 올바르게 사용하는 것이 안정적이고 성능 좋은 Compose 앱을 만드는 핵심입니다.

블로그 글에 대해 궁금한 점이 있다면 아래 카카오톡 오픈채팅에 들어와서 질문해주세요

Android Kotlin Compose QnA

open.kakao.com

(Compose) Lifecycle - Composition의 탄생부터 소멸까지

DinoDev — Fri, 8 Aug 2025 17:13:03 +0900

Jetpack Compose를 사용하다 보면 우리는 상태가 바뀌면 UI가 알아서 업데이트된다는 마법을 경험합니다. 이 마법의 비밀은 Compose가 컴포저블의 생명주기(Lifecycle)를 어떻게 관리하는지에 숨어 있습니다.

오늘은 컴포저블이 컴포지션(Composition)에 들어와서 사라지기까지, 그 여정을 함께 따라가 보겠습니다. 이 글을 이해하면 왜 remember를 써야 하고, 언제 LaunchedEffect를 사용해야 하는지 명확한 그림을 그릴 수 있게 될 것입니다.

Composition?

Composition은 Compose가 컴포저블 함수들을 실행하여 UI를 설명하는 트리 구조를 만드는 과정입니다. 이 트리는 UI의 '설계도'와 같습니다. 이 설계도가 만들어지고, 변경되고, 사라지는 것이 바로 컴포저블의 생명주기입니다.

Composable의 생명주기

컴포저블의 생명주기는 컴포지션 안에서 세 가지 주요 이벤트를 겪습니다.

컴포지션에 진입 (Entering the Composition)
- 언제? Compose가 컴포저블 함수를 처음 호출하여 UI 설계도에 추가할 때입니다.
- 무슨 일이? 해당 컴포저블과 그 자식들이 처음으로 화면에 그려지기 위한 모든 단계를 거칩니다. (Composition -> Layout -> Drawing)
- 핵심: 이 시점에 초기 데이터를 불러오거나 애니메이션을 시작하는 등의 '일회성' 작업을 수행할 수 있습니다.
재구성 (Recomposition)
- 언제? 컴포저블이 관찰하는 State가 변경되었을 때입니다.
- 무슨 일이? Compose는 변경된 State를 사용하는 컴포저블만 다시 호출하여 UI 설계도를 업데이트합니다. 이때 Compose는 똑똑하게 변경이 필요한 부분만 다시 그리므로 매우 효율적입니다. 재구성은 매우 빈번하게, 심지어 애니메이션의 매 프레임마다 발생할 수 있습니다.
- 핵심: 컴포저블 함수는 재구성을 염두에 두고 항상 멱등성(idempotent)을 가지도록, 즉 여러 번 호출되어도 부작용(Side-effect) 없이 동일한 결과를 내도록 작성해야 합니다.
컴포지션에서 제거 (Leaving the Composition)
- 언제? 더 이상 UI 설계도에 해당 컴포저블이 포함되지 않을 때입니다. if 문의 조건이 false가 되거나 다른 화면으로 이동하는 경우가 해당됩니다.
- 무슨 일이? 컴포저블은 폐기(disposed)되며, 관련된 모든 리소스가 정리됩니다.
- 핵심: 이 시점에 사용 중이던 리스너를 해제하거나 관찰을 중단하는 등, 메모리 누수를 방지하기 위한 '뒷정리' 작업을 수행해야 합니다.

생명주기에 맞게 동작하는 코드 작성하기

그렇다면 이 생명주기 이벤트에 맞춰 어떻게 코드를 실행할 수 있을까요?

remember

remember는 재구성이 일어나도 값을 잃어버리지 않도록 메모리(기억)를 제공하는 마법 같은 함수입니다. remember가 없다면 재구성 시 모든 변수가 초기화되어 상태를 저장할 수 없습니다.

// remember가 없다면, 재구성될 때마다 count는 0으로 초기화됩니다.
var count by remember { mutableIntStateOf(0) }

Side-Effect

컴포저블의 생명주기 이벤트 시점에 특정 작업을 실행하려면 Side-Effect 핸들러를 사용해야 합니다.

LaunchedEffect

LaunchedEffect는 key가 변경되지 않는 한 컴포지션에 진입할 때 딱 한 번만 실행됩니다. 데이터를 불러오거나, 초기 설정을 하기에 완벽합니다.

LaunchedEffect(Unit) { // key로 Unit을 주면 한 번만 실행됨
    viewModel.loadData()
}

DisposableEffect

DisposableEffect는 컴포지션에서 제거될 때 onDispose 블록이 호출되어 뒷정리를 합니다.

DisposableEffect(Unit) {
    // ... 리스너 등록 등 자원을 사용하는 작업 ...
    onDispose {
        // ... 리스너 해제 등 뒷정리 작업 ...
    }
}

마치며

Compose의 생명주기는 전통적인 안드로이드 생명주기보다 훨씬 단순하고 예측 가능합니다. 단순하게 진입, 재구성, 제거 라는 3가지 이벤트를 기억하면 됩니다.

그리고 remember를 통해 재구성에도 살아남는 상태를 만들고, LaunchedEffect와 DisposableEffect 같은 핸들러를 통해 각 생명주기 시점에 필요한 작업을 안전하게 실행하는 것. 이것이 바로 Compose 생명주기를 이해하고 활용하는 핵심입니다.

블로그 글에 대해 궁금한 점이 있다면 아래 카카오톡 오픈채팅에 들어와서 질문해주세요

Android Kotlin Compose QnA

open.kakao.com

(Compose) Stateful vs Stateless

DinoDev — Thu, 7 Aug 2025 12:45:17 +0900

Jetpack Compose로 UI를 만드는 것은 레고(Lego) 블록으로 멋진 작품을 조립하는 것과 같습니다. Text, Button, Image 같은 기본 블록들을 가지고 우리는 무엇이든 만들 수 있죠.

그런데 만약 여러분이 만든 레고 블록이 특별한 임무를 부여받았다면 어떨까요? 예를 들어, '파란색 자동차의 왼쪽 바퀴'로만 사용될 수 있는 블록처럼 말입니다. 이 블록은 다른 어떤 작품에도 쓸 수 없는 '일회용' 부품이 되고 말 겁니다.

코드의 세계도 마찬가지입니다. 우리가 무심코 만든 컴포넌트가 혹시 '특정 상황에서만 동작하는' 일회용 부품이 되어가고 있지는 않나요? 오늘 우리는 우리의 컴포넌트를 어떤 작품에든 쓸 수 있는 만능 레고 블록처럼 만드는 설계 비법, Stateful과 Stateless의 세계로 떠나보겠습니다.

일회용 부품?

신입 개발자 '제이'는 오늘 팀의 칭찬을 한 몸에 받았습니다. '클릭하면 하트가 채워지는' 좋아요 버튼을 완벽하게 만들어냈기 때문이죠. 스스로 상태를 관리하는 이 똑똑한 버튼 덕분에 코드는 아주 간결했습니다.

며칠 후, 다른 팀원이 제이에게 부탁합니다. "제이님, 그 좋아요 버튼 정말 예쁘네요! 저희 화면에서는 '북마크' 아이콘으로 바꾸고, 클릭하면 서버에 저장 요청을 보내는 기능으로 재사용해도 될까요?"

그 순간 제이는 깨달았습니다. 자신의 '좋아요 버튼'은 하트 아이콘과 너무 단단하게 결합되어 있어, 다른 어떤 용도로도 재사용할 수 없다는 사실을요. 지금까지 제이는 일회용 부품을 만들고 있었습니다.

이처럼 멋지게 동작하던 코드가 재사용성이라는 벽에 부딪히는 순간, 우리는 더 나은 설계에 대해 고민하게 됩니다. Stateful과 Stateless 컴포넌트 설계법을 통해 다시는 이런 곤경에 빠지지 않는 방법을 알아봅시다.

Stateful

제이가 처음 만든 '좋아요 버튼' 컴포넌트는 자신의 상태를 remember를 통해 직접 만들고 관리하는 구조였습니다.

@Composable
fun StatefulLikeButton(modifier: Modifier = Modifier) {
    // '좋아요' 여부(isLiked)를 스스로 기억하고 관리한다.
    var isLiked by remember { mutableStateOf(false) }

    IconButton(
        onClick = { isLiked = !isLiked },
        modifier = modifier
    ) {
        Icon(
            imageVector = if (isLiked) Icons.Filled.Favorite else Icons.Filled.FavoriteBorder,
            contentDescription = "좋아요"
        )
    }
}

이 코드는 그 자체로 완벽하게 동작했습니다. 하지만 '좋아요'가 아닌 '북마크' 기능으로 재사용하는 것은 불가능했죠. 제이는 선임 개발자에게 조언을 구했고, '상태를 분리하라'는 힌트를 얻습니다.

Stateless

제이는 선임 개발자의 조언에 따라 자신의 버튼에서 '상태'와 'UI'를 분리하기로 결심합니다.

바보 컴포넌트 만들기

바보 컴포넌트를 만들라니 조금 이상하죠? 컴포넌트 스스로는 아무것도 할 수 없고 외부의 도움으로 동작하도록 만드는 것입니다.

먼저, 상태를 전혀 갖지 않고 오직 외부에서 시키는 대로 그리기만 하는 Stateless 컴포넌트를 만듭니다. 필요한 모든 데이터는 파라미터로 전달받고, 클릭 이벤트는 람다 함수를 통해 외부에 알리기만 합니다.

@Composable
fun StatelessLikeButton(
    isLiked: Boolean,          // 1. UI를 그리는 데 필요한 데이터를 외부에서 받는다.
    onLikeClick: () -> Unit,   // 2. 클릭 이벤트를 외부로 전달할 통로만 만든다.
    modifier: Modifier = Modifier
) {
    IconButton(
        onClick = onLikeClick,
        modifier = modifier
    ) { // 3. 클릭 시 전달받은 람다를 호출
        Icon(
            imageVector = if (isLiked) Icons.Filled.Favorite else Icons.Filled.FavoriteBorder,
            contentDescription = "좋아요"
        )
    }
}

상태를 부모 컴포넌트에게 위임하기(State Hoisting)

이제 이 '바보'가 된 버튼에게 상태를 전달하고 제어할 '똑똑한' 부모가 필요합니다. 부모 컴포저블을 만들고, 상태 관리를 그곳으로 끌어올립니다(Hoisting).

@Composable
fun ArticleScreen() {
    // 1. 상태(isUserLiked)를 부모 컴포넌트가 직접 소유하고 관리한다.
    var isUserLiked by remember { mutableStateOf(false) }

    Column {
        Text("Compose 설계의 모든 것")
        // ... (본문 내용)

        // 2. Stateless 자식에게 상태와 이벤트 핸들러를 전달한다.
        StatelessLikeButton(
            isLiked = isUserLiked,          // 상태는 아래로 내려주고 (State Down)
            onLikeClick = {                 // 이벤트는 위로 올려받는다 (Events Up)
                isUserLiked = !isUserLiked
            }
        )
    }
}

이 구조를 통해 데이터의 흐름은 '위에서 아래로(State Down)', 이벤트의 흐름은 **'아래에서 위로(Events Up)'**라는 명확한 단방향으로 정리되었습니다. 이것이 바로 상태 호이스팅 패턴의 핵심입니다.

더 고도화 하면?

이전까지는 좋아요 여부와 클릭했을 때 동작만 파라미터로 전달 받았는데 아이콘 이미지도 받는다면 재사용성이 극대화 됩니다.

@Composable
fun IconToggleButton(
    toggled: Boolean,
    onToggle: () -> Unit,
    toggledIcon: ImageVector,
    untoggledIcon: ImageVector,
    modifier: Modifier = Modifier,
    contentDescription: String? = null,
) {
    IconButton(
        onClick = onToggle,
        modifier = modifier
    ) {
        Icon(
            imageVector = if (toggled) toggledIcon else untoggledIcon,
            contentDescription = contentDescription
        )
    }
}

이렇게 되면 더이상 토글 관련된 기능을 가진 버튼 UI를 매번 만들지 않고 재사용해서 사용할 수 있습니다.

// 북마크 기능을 위한 부모 컴포저블
@Composable
fun BookmarkFeature() {
    // '북마크' 상태를 관리한다
    var isBookmarked by remember { mutableStateOf(false) }

    // 똑같은 IconToggleButton을 '북마크' 기능으로 재사용!
    IconToggleButton(
        toggled = isBookmarked,
        onToggle = {
            isBookmarked = !isBookmarked
            // server.saveToBookmark(...)  <-- 북마크 관련 로직 호출
        },
        toggledIcon = Icons.Filled.Bookmark,      // '북마크 On' 아이콘 전달
        untoggledIcon = Icons.Filled.BookmarkBorder, // '북마크 Off' 아이콘 전달
        contentDescription = "북마크"
    )
}

쉬운 테스트

이제 IconToggleButton을 아주 쉽게 테스트할 수 있습니다. 이제 IconToggleButton이 정말 재사용 가능한지, 그리고 올바르게 동작하는지 검증하고 싶습니다. 그는 단순히 모양만 테스트하는 것을 넘어, "버튼을 클릭했을 때, 우리가 전달한 onToggle 람수 함수가 정말로 실행되는가?"를 확인하는 테스트를 작성합니다.

@Test
fun `IconToggleButton을_클릭하면_onToggle_람다가_호출된다`() {
    // 1. Given (준비): 람다가 호출되었는지 확인할 추적용 Boolean 변수를 만든다.
    var isToggled = false

    composeTestRule.setContent {
        IconToggleButton(
            toggled = false,
            // 2. When (행동): 버튼이 클릭되면, 추적용 변수의 값을 true로 변경하는 람다를 전달한다.
            onToggle = { isToggled = true },
            toggledIcon = Icons.Filled.Favorite,
            untoggledIcon = Icons.Filled.FavoriteBorder,
            contentDescription = "좋아요 버튼"
        )
    }

    // `contentDescription`으로 버튼을 찾아 클릭 동작을 수행한다.
    composeTestRule.onNodeWithContentDescription("좋아요 버튼").performClick()

    // 3. Then (검증): 람다가 호출되어 isToggled 변수의 값이 true로 바뀌었는지 확인한다.
    assertTrue("onToggle 람다가 호출되지 않았습니다.", isToggled)
}

마치며

우리는 하나의 상태를 가진 컴포넌트가 어떻게 의도치 않게 '일회용 부품'이 될 수 있는지, 그리고 간단한 설계 원칙의 적용만으로 어떻게 재사용 가능한 컴포넌트로 진화할 수 있는지 구체적인 여정을 함께했습니다.

핵심은 Stateful 컴포넌트와 Stateless 컴포넌트가 어떻게 다른지 명확히 이해하고, '상태 호이스팅'이라는 다리를 통해 이 둘을 의도적으로 분리하는 것이었습니다.

Stateful 컴포넌트는 스스로 모든 것을 처리해 편리해 보이지만, 특정 기능과 단단히 결합되어 재사용이 어렵다는 명확한 한계를 가집니다.
Stateless 컴포넌트는 상태를 직접 관리하지 않아 '바보'처럼 보일지라도, 바로 그 특징 때문에 어떤 상황에서든 재사용할 수 있는 놀라운 유연성을 갖게 됩니다.

잘 설계된 Stateless 컴포넌트는 여러분의 가장 든든한 자산이 되어, 개발 속도를 높이고 버그는 줄여줄 것입니다.

블로그 글에 대해 궁금한 점이 있다면 아래 카카오톡 오픈채팅에 들어와서 질문해주세요

Android Kotlin Compose QnA

open.kakao.com

(Compose) Compose UI Test

DinoDev — Tue, 5 Aug 2025 14:10:06 +0900

우리는 이제 멋진 화면을 만들고, 목록을 표시하고, 화면을 이동하는 방법까지 알게 되었습니다. 하지만 우리가 만든 코드가 앞으로도 계속 올바르게 동작할 것이라고 어떻게 보장할 수 있을까요? 디자인을 조금 바꾸거나 로직을 리팩터링 했을 때, 앱의 다른 기능이 고장 나지는 않았는지 어떻게 확인할까요?

매번 눈으로 모든 화면을 클릭해보는 것은 지치고 실수하기 쉽습니다. 이럴 때 필요한 것이 바로 자동화된 UI 테스트입니다. 오늘은 Jetpack Compose로 UI 테스트 코드를 작성하는 기본 방법을 알아보겠습니다.

UI 테스트, 왜 귀찮은 일을 추가하면서까지 해야 할까요?

어느 화창한 오후, PM에게서 간단한 요청을 받습니다.

"결제 화면의 '구매하기' 버튼 색깔을 좀 더 눈에 띠는 파란색으로 바꿔주세요. 그리고 문구도 '결제하기'로 수정해 주세요."

'이 정도면 5분도 안 걸리지!'

나는 자신만만하게 해당 Composable을 찾아 Modifier.background(Color.Blue)와 Text("결제하기")로 수정합니다. @Preview로 보니 완벽합니다. 코드를 커밋하고, 빌드하고, 배포까지 일사천리로 진행합니다.

그리고 다음 날 아침, 재앙이 시작됩니다.

고객센터에 불이 나고, 팀 메신저는 폭발합니다. 이유는 단 하나.

"결제하기 버튼을 눌러도 아무 반응이 없어요!"

나는 가슴이 철렁 내려앉은 당신은 코드를 파헤치기 시작합니다. 원인은 황당했습니다. 버튼 스타일을 수정하면서, 실수로 clickable Modifier를 감싸고 있던 다른 Modifier 안으로 옮겨버렸고, 이로 인해 클릭 이벤트가 제대로 전달되지 않았던 것입니다.

색깔과 문구만 바꿨을 뿐인데, 앱의 가장 중요한 기능인 '결제'가 막혀버렸습니다. 회사는 금전적 손실을 입었고, 사용자들은 분노했으며, 나는 동료들에게 사과하며 급하게 핫픽스를 배포해야 합니다. 그날 하루는 온전히 이 문제 해결에 소모됩니다.

만약 UI 테스트가 있었다면?

위 시나리오를 다시 돌려보겠습니다. '결제하기' 버튼을 수정한 후, 습관처럼 미리 작성해 둔 UI 테스트를 실행합니다.

테스트 시나리오: "결제 버튼을 클릭하면, 결제 확인 화면으로 이동해야 한다."

@Test
fun `결제_버튼을_클릭하면_확인화면으로_이동한다`() {
    // 1. Given: 결제 화면을 띄운다.
    // 2. When: '결제하기' 버튼을 찾아 클릭한다.
    // 3. Then: '결제 확인'이라는 텍스트가 화면에 나타나는지 검증한다.
}

만약 이런 간단한 UI 테스트가 있었다면 회사는 금전적 손실을 입지 않았을 것이고, 사용자들은 분노하지 않았을 것이고, 동료들에게 사과하러 다니는 나는 없었을 것이고 핫픽스를 하지도 않았을 것입니다.

UI 테스트는 '보험'이자 '안전망'입니다.

우리가 UI 테스트를 하는 이유는 단순히 버그를 찾기 위함만이 아닙니다.

자신감을 얻기 위해: "이 코드를 고쳐도 다른 곳이 망가지지 않을 거야"라는 확신을 줍니다. 레거시 코드나 복잡한 로직을 두려움 없이 개선할 수 있는 자유를 줍니다.
시간을 아끼기 위해: 매번 모든 기능을 손으로 테스트하는 끔찍한 반복 작업을 자동화된 로봇에게 맡기는 것입니다. 테스트 코드 작성에 1시간을 투자하면, 미래의 수십, 수백 시간의 수동 테스트와 버그 수정 시간을 아낄 수 있습니다.
팀과 평화롭게 지내기 위해: 내가 수정한 코드가 동료의 코드를 망가뜨리는 일을 방지하고, 반대로 동료의 수정으로부터 내 코드를 보호합니다. 서로를 비난하는 대신, 테스트 코드가 조용히 문제를 알려줍니다.

UI 테스트는 귀찮은 추가 업무가 아닙니다. 프로 개발자로서 나의 결과물을 책임지고, 미래의 나에게 닥칠 재앙을 막아주는 가장 든든하고 현명한 안전장치인 것입니다.

테스트 환경 설정하기

Compose UI 테스트를 작성하려면 먼저 필요한 라이브러리를 추가해야 합니다.

app/build.gradle.kts 파일의 dependencies 블록에 다음을 추가하세요. (프로젝트를 처음 생성할 때 이미 추가되어 있을 수 있습니다.)

// UI 테스트를 위한 라이브러리 (androidTestImplementation)
androidTestImplementation("androidx.compose.ui:ui-test-junit4:1.8.3") // 버전을 확인하세요

// 디버그 빌드에서만 테스트 매니페스트를 사용하기 위함
debugImplementation("androidx.compose.ui:ui-test-manifest:1.8.3")

아마도 최신 프로젝트에서는 이렇게 직접 version을 명시하지 않고 bom 형태를 사용할 수 있습니다.

https://developer.android.com/develop/ui/compose/bom

재료명세서 사용 | Jetpack Compose | Android Developers

이 페이지는 Cloud Translation API를 통해 번역되었습니다. 재료명세서 사용 컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요. Compose 재료명세서 (BOM)를 사용하면 BOM

developer.android.com

테스트 코드는 app/src/androidTest/java/ 디렉터리 안에 작성합니다.

Compose 테스트의 3가지 핵심 요소

Compose 테스트는 대부분 아래 3단계를 따릅니다.

찾기: 테스트하려는 UI 요소(노드)를 화면에서 찾습니다.
검증: 해당 노드가 원하는 상태(예: 화면에 보이는지, 텍스트가 맞는지)인지 확인합니다.
행동: 해당 노드에 특정 동작(예: 클릭, 텍스트 입력)을 수행합니다.

이 과정을 코드로 구현하는 방법을 알아봅시다.

테스트 룰(Rule)

모든 Compose 테스트의 시작점입니다. 테스트 환경을 설정하고 Composable을 렌더링 하는 역할을 합니다.

import androidx.compose.ui.test.junit4.createComposeRule
import org.junit.Rule

class MyComposeTest {
    @get:Rule
    val composeTestRule = createComposeRule()
    // ... 테스트 코드
}

요소 찾기

composeTestRule을 통해 다양한 조건으로 노드를 찾을 수 있습니다.

onNodeWithText(): 특정 텍스트를 가진 노드를 찾습니다.
onNodeWithContentDescription(): Image나 IconButton의 contentDescription으로 찾습니다.
onNodeWithTag(): 테스트를 위한 전용 태그(testTag)로 노드를 찾는 방법입니다.

// Composable 코드에 testTag 추가하기
Text(
    text = "Hello",
    modifier = Modifier.testTag("GreetingText")
)

// 테스트 코드에서 testTag로 찾기
composeTestRule.onNodeWithTag("GreetingText")

검증과 행동

노드를 찾았다면, 이제 그 노드가 올바른지 확인하고 동작을 시킬 수 있습니다.

주요 검증 함수 (Assertions)
- assertIsDisplayed(): 화면에 보이는지 확인합니다.
- assertExists(): 화면에 보이지 않더라도 노드 트리에 존재하는지 확인합니다.
- assertIsEnabled() / assertIsNotEnabled(): 활성화/비활성화 상태인지 확인합니다.
- assertTextEquals("..."): 텍스트 내용이 일치하는지 확인합니다.
주요 행동 함수 (Actions)
- performClick(): 클릭합니다.
- performTextInput("..."): 텍스트를 입력합니다.
- performScrollTo(): 특정 위치로 스크롤합니다.

import androidx.compose.foundation.layout.Column
import androidx.compose.material3.Button
import androidx.compose.material3.Text
import androidx.compose.runtime.Composable
import androidx.compose.runtime.getValue
import androidx.compose.runtime.mutableIntStateOf
import androidx.compose.runtime.remember
import androidx.compose.runtime.setValue
import androidx.compose.ui.Alignment
import androidx.compose.ui.Modifier
import androidx.compose.ui.platform.testTag
import androidx.compose.ui.test.*
import androidx.compose.ui.test.junit4.createComposeRule
import org.junit.Rule
import org.junit.Test

class CounterAppTest {

    @get:Rule
    val composeTestRule = createComposeRule()

    @Test
    fun counter_app_test() {
        // 1. Given (준비): 테스트할 Composable을 화면에 렌더링합니다.
        composeTestRule.setContent {
            CounterApp()
        }

        // 2. When (행동): '더하기' 버튼을 찾아 클릭합니다.
        composeTestRule.onNodeWithTag("AddButton")
            .performClick()
        composeTestRule.onNodeWithTag("AddButton")
            .performClick()

        // 3. Then (검증): 카운터 텍스트가 '2'로 변경되었는지 확인합니다.
        composeTestRule.onNodeWithTag("CounterText")
            .assertTextEquals("클릭 횟수: 2")
    }

    @Composable
    fun CounterApp() {
        var count by remember { mutableIntStateOf(0) }
        Column(horizontalAlignment = Alignment.CenterHorizontally) {
            Text(
                text = "클릭 횟수: $count",
                modifier = Modifier.testTag("CounterText")
            )
            Button(
                onClick = { count++ },
                modifier = Modifier.testTag("AddButton")
            ) {
                Text("더하기")
            }
        }
    }
}

이 테스트는 CounterApp을 실행하고, '더하기' 버튼을 두 번 누른 뒤, 텍스트가 "클릭 횟수: 2"로 올바르게 표시되는지 자동으로 검증해 줍니다.

마치며

이번 블로그를 통해서 Compose UI Test의 기본을 알아봤습니다. 앞으로 테스트 코드 작성을 습관화한다면 버그 걱정 없이 훨씬 더 안정적이고 품질 좋은 앱을 만들 수 있습니다.

블로그 글에 대해 궁금한 점이 있다면 아래 카카오톡 오픈채팅에 들어와서 질문해주세요

Android Kotlin Compose QnA

open.kakao.com

(Compose) LazyColumn

DinoDev — Tue, 5 Aug 2025 12:12:15 +0900

연락처 목록, SNS 피드, 상품 리스트, 설정 화면까지... 앱을 만들다 보면 '목록'을 표시해야 하는 경우는 셀 수 없이 많습니다.

Compose를 처음 배울 때 Column 안에 for문을 돌려 UI를 추가하는 방법을 떠올릴 수 있습니다. 하지만 아이템이 10개, 20개를 넘어 100개, 1000개가 된다면 어떻게 될까요? 앱은 심하게 버벅이다가 결국 비정상 종료될지도 모릅니다.

이번에는 Compose에서 목록을 효과적으로 보여주기 위한 방법에 대해 알아보겠습니다.

왜 Column이 아닌 LazyColumn?

이 둘의 차이를 이해하는 것이 가장 중요합니다.

Column: Column 안에 있는 모든 자식 Composable을 한 번에 메모리에 올리고 화면에 그립니다. 1000개의 아이템이 있다면 1000개 전부를 렌더링하려고 시도하죠. 이는 엄청난 메모리 낭비와 성능 저하를 일으킵니다.
LazyColumn: 이름의 'Lazy(게으른)'에서 알 수 있듯, 지금 당장 화면에 보이는 아이템만 렌더링합니다. 사용자가 스크롤을 내리면, 화면 밖으로 사라지는 아이템은 메모리에서 재활용하고 새로 나타날 아이템만 그립니다. 이는 RecyclerView의 동작 원리와 같습니다.

Column은 1000페이지짜리 책을 한 번에 모두 인쇄하는 것과 같고, LazyColumn은 웹 브라우저가 화면에 보이는 부분만 로딩하는 것과 같습니다. 당연히 후자가 훨씬 효율적이죠!

LazyColumn 기본 사용법

LazyColumn의 사용법은 매우 직관적입니다. LazyColumn의 컨텐츠 블록 안에서 items라는 특별한 함수를 사용합니다.

import androidx.compose.foundation.lazy.LazyColumn
import androidx.compose.foundation.lazy.items
import androidx.compose.material3.Text
import androidx.compose.runtime.Composable

@Composable
fun SimpleList() {
    LazyColumn {
        // 100개의 아이템을 가진 리스트
        items(100) { index ->
            Text(text = "아이템 #$index")
        }
    }
}

조금 더 복잡한 예제를 살펴 보겠습니다.

// 1. 데이터 클래스 정의
data class User(val id: Int, val name: String)

// 2. 아이템 하나의 UI를 담당할 Composable
@Composable
fun UserCard(user: User) {
    Row(modifier = Modifier.padding(16.dp)) {
        Image(
            painter = painterResource(id = R.drawable.ic_profile),
            contentDescription = "Profile Picture"
        )
        Spacer(modifier = Modifier.width(8.dp))
        Text(text = user.name)
    }
}

// 3. LazyColumn과 연결
@Composable
fun UserList(users: List<User>) {
    LazyColumn {
        items(items = users) { user ->
            UserCard(user = user)
        }
    }
}

실제 앱에서는 보통 데이터 클래스의 리스트를 다루게 됩니다. 각 아이템의 UI를 별도의 Composable 함수로 분리하는 것이 좋은 습관입니다.

성능 최적화 하기

LazyColumn에서는 Compose의 성능 최적화를 위해서 key를 제공하고 있습니다. 이 key를 이용한다면 더욱 더 매끄러운 앱을 만들 수 있습니다.

items(
    items = users,
    // 각 아이템에 고유하고 안정적인 키를 제공합니다.
    key = { user -> user.id }
) { user ->
    UserCard(user = user)
}

key를 왜 사용해야 할까요?

리스트의 데이터가 변경(추가, 삭제, 순서 변경)될 때, Compose는 어떤 아이템이 어떤 것인지 구별해야 합니다.

key가 없으면: Compose는 아이템의 위치를 기준으로 판단합니다. 리스트 맨 앞에 아이템이 추가되면, Compose는 모든 아이템이 한 칸씩 밀렸다고 생각하고 전부 다시 그리는 비효율적인 작업을 할 수 있습니다.
key가 있으면: Compose는 user.id와 같은 고유한 key를 보고 아이템을 식별합니다. 리스트가 바뀌어도 "아, id가 5인 아이템은 그대로 있구나. 다시 그릴 필요 없겠네."라고 판단하여 꼭 필요한 부분만 업데이트합니다.

key 사용의 장점:

성능 향상: 불필요한 재구성(Recomposition)을 방지합니다.
상태 유지: 아이템이 가진 내부 상태(remember로 관리되는)가 유지됩니다.
애니메이션 최적화: 아이템 추가/삭제 시 애니메이션이 더 자연스러워집니다.

LazyColumn의 items에는 항상 고유하고 안정적인 key를 제공하는 습관을 들이세요. 보통 데이터의 id를 사용합니다.

블로그 글에 대해 궁금한 점이 있다면 아래 카카오톡 오픈채팅에 들어와서 질문해주세요

Android Kotlin Compose QnA

open.kakao.com

(Compose) Modifier

DinoDev — Mon, 4 Aug 2025 20:02:40 +0900

Jetpack Compose를 사용하다 보면 거의 모든 Composable 함수 끝에 modifier = Modifier... 코드가 따라붙는 것을 보셨을 겁니다. 처음에는 그저 "UI를 꾸미는 건가?" 싶지만, 사실 Modifier는 그 이상의 역할을 하는 Compose의 핵심 요소입니다.
이번 내용에서 Modifier가 무엇인지, 어떻게 작동하는지, 그리고 왜 중요한지에 대해 깊이 파고들어 보겠습니다.

Modifier란?

Modifier는 이름 그대로 Composable을 수정(Modify)하는 역할을 합니다. Composable의 크기, 모양, 여백, 배경색을 바꾸는 것부터 클릭, 스크롤, 드래그와 같은 사용자 입력을 처리하는 것까지, UI 요소에 대한 거의 모든 '부가 속성'을 설정하는 데 사용됩니다.

Modifier가 없다면 Text는 그저 글자일 뿐이고, Box는 투명한 사각형일 뿐입니다. Modifier를 통해 비로소 우리가 원하는 모습과 동작을 갖춘 UI 요소로 거듭나는 것이죠.

Modifier 사용하기

Modifier의 가장 큰 특징은 여러 수정을 체인(Chain) 형태로 이어 붙일 수 있다는 점입니다. 마치 레고 블록을 조립하듯, 필요한 기능들을 순서대로 연결하면 됩니다.

@Composable
fun ModifierExample() {
    Text(
        text = "Hello, Modifier!",
        modifier = Modifier
            .padding(16.dp) // 1. 바깥쪽에 16dp 여백을 준다.
            .background(Color.Yellow) // 2. 노란색 배경을 칠한다.
            .fillMaxWidth() // 3. 너비를 꽉 채운다.
            .clickable { /* 텍스트 클릭 시 동작 */ } // 4. 클릭 이벤트를 추가한다.
    )
}

이처럼 Modifier는 점(.)을 이용해 코드를 읽는 것만으로 어떤 속성들이 적용되었는지 명확하게 파악할 수 있습니다.

Modifier에서 순서가 중요합니다.

Modifier를 사용할 때 반드시 기억해야 할 단 하나의 규칙이 있다면, 바로 순서가 중요하다는 것입니다. 각 Modifier는 자신보다 먼저 선언된 Modifier가 적용된 결과물 위에 적용됩니다.

아래 두 코드의 결과를 비교해 볼까요?

Box(
    modifier = Modifier
        .padding(20.dp) // 1. 먼저 20dp의 여백(투명)을 만든다.
        .background(Color.Blue) // 2. 그 결과물에 파란 배경을 칠한다.
        .size(100.dp)
)

Box(
    modifier = Modifier
        .background(Color.Blue) // 1. 먼저 파란 배경을 칠한다.
        .padding(20.dp) // 2. 그 결과물 안쪽에 20dp 여백을 만든다.
        .size(100.dp)
)

이처럼 순서를 어떻게 정하느냐에 따라 UI가 완전히 달라질 수 있으므로 항상 적용 순서를 염두에 두어야 합니다.

그 외 Modifier 함수들

Modifier는 정말 종류가 많지만, 개발할 때 특히 자주 사용하는 것들은 다음과 같습니다.

크기와 관련된 Modifier
- size(size: Dp): 가로, 세로 크기를 지정합니다.
- fillMaxWidth(), fillMaxHeight(), fillMaxSize(): 가능한 최대 너비, 높이, 또는 전체 크기를 채웁니다.
- width(width: Dp), height(height: Dp): 너비나 높이만 개별적으로 지정합니다.
여백과 관련된 Modifier
- padding(all: Dp): 모든 방향에 동일한 내부 여백을 줍니다.
- padding(horizontal: Dp, vertical: Dp): 수평, 수직 여백을 개별적으로 줍니다.
모양과 관련된 Modifier
- background(color: Color): 배경색을 칠합니다.
- border(width: Dp, color: Color): 테두리를 그립니다.
- clip(shape: Shape): Composable을 특정 모양(예: CircleShape)으로 잘라냅니다.
동작과 관련된 Modifier
- clickable { ... }: 클릭 이벤트를 처리합니다.
- scrollable(...): 스크롤 동작을 가능하게 합니다.
레이아웃 가중치 (Row/Column 전용)
- weight(weight: Float): Row나 Column 내에서 차지하는 공간의 비율을 설정합니다.

마치며

Modifier는 Jetpack Compose에서 레이아웃을 만들고, 스타일을 입히고, 생명을 불어넣는 가장 기본적이면서도 강력한 도구입니다. 처음에는 순서가 헷갈릴 수 있지만, 몇 번만 직접 코드를 작성하며 순서를 바꿔보면 그 원리를 금방 터득할 수 있을 겁니다.

블로그 글에 대해 궁금한 점이 있다면 아래 카카오톡 오픈채팅에 들어와서 질문해주세요

Android Kotlin Compose QnA

open.kakao.com

(Compose) 상태(state)

DinoDev — Mon, 4 Aug 2025 19:06:28 +0900

안녕하세요! 지금까지 Text, Button, Image, Column, Row 등을 이용해서 화면에 정적인 UI를 그리는 법에 대해 소개했습니다. 하지만 앱은 사용자와 상호작용하며 UI가 계속 변화하게 됩니다. Compose에서는 상태(state)라는 핵심 개념을 이용해서 이것을 가능하게 합니다.

상태(state)란?

Compose에서 상태는 시간이 지남에 따라 변할 수 있는 모든 값을 의미합니다.

체크박스의 체크 여부(boolean)
사용자가 입력한 텍스트(String)
버튼을 누른 횟수(Int)
서버에서 받아온 데이터 목록(List <Data>)

이 모든 것이 상태가 될 수 있습니다. Compose에서는 상태가 변경되는 것을 감지하면 해당 상태를 사용하는 UI 부분을 자동으로 다시 그려줍니다. 이 과정을 Recomposition(재구성)이라고 부릅니다.

Compose는 상태가 변경되는 것을 어떻게 감지할까?

Compose에서는 mutableStateOf와 remember라는 두 가지 핵심 함수를 사용해서 변경을 감지합니다.

mutableStateOf(): Compose가 변화를 추적할 수 있는 특별한 상태 객체를 만드는 함수
remember { }: Compose가 재구성될 때 값이 초기화되지 않고 기억되도록 합니다.

import androidx.compose.foundation.layout.Arrangement
import androidx.compose.foundation.layout.Column
import androidx.compose.material3.Button
import androidx.compose.material3.Text
import androidx.compose.runtime.Composable
import androidx.compose.runtime.getValue
import androidx.compose.runtime.mutableStateOf
import androidx.compose.runtime.remember
import androidx.compose.runtime.setValue
import androidx.compose.ui.Alignment

@Composable
fun CounterApp() {
    // 1. mutableStateOf로 '상태'를 만들고, remember로 기억합니다.
    // 'by' 키워드를 사용하면 .value 없이 값을 바로 쓸 수 있어 편리합니다.
    var count by remember { mutableStateOf(0) }

    Column(
        horizontalAlignment = Alignment.CenterHorizontally,
        verticalArrangement = Arrangement.Center
    ) {
        Text(text = "버튼을 누른 횟수: $count")

        Button(onClick = {
            // 2. 버튼을 누르면 상태(count)의 값이 변경됩니다.
            count++
        }) {
            Text(text = "클릭하세요!")
        }
    }
}

var count by remember { mutableStateOf(0) }: count라는 이름의 상태 변수를 선언하고 초기값을 0으로 설정했습니다. remember로 감싸주었기 때문에, count 값이 1, 2, 3으로 변해도 화면이 재구성될 때 다시 0으로 돌아가지 않습니다.

count++: 버튼이 클릭되면 count 상태의 값이 1 증가합니다.

Compose는 count가 변경된 것을 감지하고, count를 사용하고 있는 Text(text = "...") 부분을 자동으로 다시 그립니다.

원시타입용 상태 홀더

아마도 mutableStateOf(0)를 사용했다면 Prefer mutableIntStateOf instead of mutableStateOf 워닝을 만나게 될 것입니다.

Compose에서는 Int, Long, Float, Double에 대한 원시타입용 상태 홀더를 제공하고 있습니다.

mutableIntStateOf(초기값): Int 타입을 위한 상태
mutableLongStateOf(초기값): Long 타입을 위한 상태
mutableFloatStateOf(초기값): Float 타입을 위한 상태
mutableDoubleStateOf(초기값): Double 타입을 위한 상태

// 1. 일반적인 방법
val countGeneric by remember { mutableStateOf(0) }

// 2. 원시 타입 특화 방법
val countPrimitive by remember { mutableIntStateOf(0) }

두 코드의 사용법은 완전히 동일하지만, 내부적으로는 중요한 차이가 있습니다. 바로 박싱(Boxing)의 유무입니다.

박싱(Boxing)이란?

Java와 Kotlin의 세계에서 Int, Float 같은 원시 타입은 객체(Object)가 아닙니다. 하지만 mutableStateOf<T>와 같은 제네릭(Generic) 함수는 모든 타입을 다루기 위해 내부적으로 객체(Any?)로 값을 다룹니다.

이때, 원시 타입인 Int를 객체 타입인 Integer로 포장하는 과정이 발생하는데, 이것을 박싱이라고 합니다.

mutableStateOf(0): Int 값 0이 Integer 객체로 박싱되어 저장됩니다.
mutableIntStateOf(0): Int 값 0이 박싱 과정 없이 원시 타입 그대로 저장됩니다.

박싱은 아주 작은 메모리 할당과 처리 비용을 유발합니다. 앱의 상태가 몇 개 안 되고 가끔 업데이트된다면 이 차이는 무시해도 좋을 만큼 미미합니다.
하지만 상태 변경이 매우 잦은 UI(예: 복잡한 애니메이션, 실시간으로 변하는 그래프, 스크롤에 따라 계속 계산되는 값)에서는 이런 작은 오버헤드가 쌓여 앱의 버벅거림(Jank)을 유발할 수 있습니다.
mutableIntStateOf와 같은 특화된 상태 홀더는 이 박싱을 피함으로써 불필요한 메모리 할당을 줄여 성능을 극대화합니다.

블로그 글에 대해 궁금한 점이 있다면 아래 카카오톡 오픈채팅에 들어와서 질문해주세요

Android Kotlin Compose QnA

open.kakao.com

(Compose) @Preview

DinoDev — Mon, 4 Aug 2025 17:27:28 +0900

Android 개발을 하다 보면 작은 UI 수정 하나를 확인하기 위해서 적으면 몇 초에서 많으면 몇십 분씩 빌드를 기다리는 일이 너무 번거롭고 지겹습니다. Jetpack Compose는 이런 것을 해결하기 위해 @Preview 어노테이션을 제공합니다. @Preview는 앱을 빌드해서 확인하지 않고 Android Studio에서 Compose UI가 어떻게 보일지 즉시 렌더링 해주는 기능입니다.

@Preview 사용법

@Preview의 사용법은 놀라울 정도로 간단합니다. 그저 @Composeable 함수 위에 @Preview를 추가하면 됩니다.

import androidx.compose.material3.Text
import androidx.compose.runtime.Composable
import androidx.compose.ui.tooling.preview.Preview

// UI를 구성하는 Composable 함수
@Composable
fun Greeting(name: String) {
    Text(text = "Hello, $name!")
}

// 위 Composable을 미리보기 위한 또 다른 Composable 함수
@Preview(showBackground = true) // Preview를 위한 어노테이션 추가
@Composable
fun GreetingPreview() {
    // 앱의 테마를 적용하면 더 정확한 미리보기가 가능합니다.
    MyApplicationTheme {
        Greeting("Android with Preview")
    }
}

이렇게 @Preview를 추가하는 순간 Android Studio의 Split View에 Greeting Compose UI가 렌더링 된 모습을 볼 수 있습니다. 코드를 수정하면 잠시 후 Preview 화면도 자동으로 업데이트됩니다. 만약 업데이트가 되지 않는다면 빌드를 하면 됩니다.

@Preview에 showBackground = true를 넣으면 Preview 화면에 배경을 추가해줘서 한눈에 보기 좋습니다.

@Preview 파라미터

@Preview에는 다양한 파라미터를 사용해서 Preview 화면을 더욱 다채롭게 만들 수 있습니다.

name

name을 사용하면 Preview에 이름을 지정할 수 있습니다.

@Preview(name = "기본 인사말")
@Composable
fun GreetingPreview() { ... }

@Preview(name = "긴 이름일 경우")
@Composable
fun LongNameGreetingPreview() {
    Greeting("Android Jetpack Compose is Awesome")
}

uiMode

앱에서 다크모드를 지원한다면 Preview에서 바로 다크모드 화면을 확인할 수 있습니다.

import android.content.res.Configuration

@Preview(name = "라이트 모드")
@Composable
fun LightModePreview() { ... }

@Preview(name = "다크 모드", uiMode = Configuration.UI_MODE_NIGHT_YES)
@Composable
fun DarkModePreview() { ... }

device

Preview에서 다양한 형태의 device를 지원합니다.

// 일반적인 스마트폰
@Preview(device = Devices.PHONE)
@Composable
fun PhonePreview() { ... }

// 태블릿
@Preview(device = Devices.TABLET)
@Composable
fun TabletPreview() { ... }

// 폴드
@Preview(device = Devices.FOLDABLE)
@Composable
fun FoldablePreview() { ... }

locale

다국어 테스트도 Preview에서 가능합니다.

@Preview(name = "한국어", locale = "ko")
@Composable
fun KoreanPreview() { ... }

@Preview(name = "영어 (미국)", locale = "en-US")
@Composable
fun EnglishPreview() { ... }

커스텀 @Preview 만들기

하나의 @Preview를 별칭을 지어서 만들 수도 있고 여러개의 @Preview를 묶어서 만들 수도 있습니다.

// 1. 여러 Preview 설정을 담은 커스텀 어노테이션 정의
@Preview(name = "라이트 모드", showBackground = true)
@Preview(name = "다크 모드", uiMode = Configuration.UI_MODE_NIGHT_YES, showBackground = true)
annotation class ThemePreviews

// 2. 간편하게 사용하기
@ThemePreviews
@Composable
fun MyComponentPreview() {
    MyApplicationTheme {
        Greeting("Android with Preview")
    }
}

이제 @ThemePreviews 어노테이션 하나만 붙이면 라이트/다크 모드 미리 보기가 한 번에 생성됩니다.

마치며

@Preview는 단순히 코드를 시각화하는 것을 넘어, 우리의 개발 사이클을 획기적으로 단축시키고 다양한 환경에서의 UI 품질을 보장하는 필수적인 도구입니다. 오늘 배운 팁들을 적극적으로 활용하여, 지루한 빌드 시간 대신 창의적인 UI 개발에 더 많은 시간을 쏟아보세요!

이제 @Preview와 함께 더 빠르고 즐거운 Compose 개발을 시작할 시간입니다.

블로그 글에 대해 궁금한 점이 있다면 아래 카카오톡 오픈채팅에 들어와서 질문해주세요

Android Kotlin Compose QnA

open.kakao.com

(Compose) Row, Column

DinoDev — Wed, 30 Jul 2025 15:56:11 +0900

안녕하세요! 이번 글에서는 Jetpack Compose의 가장 기본적이면서도 정말 많이 사용되는 컴포넌트인 Row와 Column에 대해 알아보겠습니다.

이전 블로그 글에서 Text와 Button과 Image에 대해서 알아보았는데 이 컴포넌트들을 배치하는 방법에 대해서는 다루지 않았습니다. 또한 XML을 사용해서 UI 개발을 하던 개발자가 Compose를 처음 접한다면 “뷰(View)에서 LinearLayout을 세로/가로로 쓰던 걸 Compose에서는 뭘로 하지?”라는 생각을 할 수 있어요.

바로 이때 등장하는 게 Row와 Column입니다.

Row와 Column이란?

Row: 자식 컴포넌트들을 가로 방향(수평)으로 배치
Column: 자식 컴포넌트들을 세로 방향(수직)으로 배치

뷰(View) 시절의 LinearLayout과 개념적으로 비슷하지만, 훨씬 가볍고 선언적으로 작성할 수 있어서 더 직관적이에요.

기본 사용법

가장 간단한 예제를 먼저 볼까요?

@Composable
fun SimpleRowAndColumn() {
    Column {
        Text("첫 번째 줄")
        Text("두 번째 줄")
        Text("세 번째 줄")
    }

    Row {
        Text("왼쪽")
        Text("가운데")
        Text("오른쪽")
    }
}

Column은 UI를 위에서 아래로 배치하고 Row는 UI를 왼쪽에서 오른쪽으로 배치합니다.

따라서 내가 수직으로 나열하고 싶을 때는 Column을 사용하고 수평으로 나열하고 싶다면 Row를 사용하면 됩니다.

Modifier로 스타일 조정

Row와 Column은 Modifier를 통해 크기, 배경, 패딩 등 다양한 스타일을 쉽게 줄 수 있습니다.

Column(
    modifier = Modifier
        .fillMaxWidth()
        .background(Color.LightGray)
        .padding(16.dp)
) {
    Text("첫 번째 줄")
    Text("두 번째 줄")
}

Arrangement와 Alignment

조금 더 고급 설정으로는 자식 컴포넌트들의 위치를 조절할 수 있습니다.

horizontalArrangement: Row에서 수평 정렬
verticalArrangement: Column에서 수직 정렬
verticalAlignment: Row에서 수직 정렬
horizontalAlignment: Column에서 수평 정렬

예를 들어, 가운데 정렬을 하고 싶다면 아래와 같이 사용하면 됩니다.

Row(
    modifier = Modifier.fillMaxWidth(),
    horizontalArrangement = Arrangement.Center
) {
    Text("가운데에 있는 텍스트")
}

Row와 Column 같이 활용하기

실제 앱에서는 Row와 Column을 적절히 섞어서 다양한 화면을 만듭니다. 예를 들어, 제목과 설명을 세로로 배치하면서, 오른쪽 끝에 버튼을 두고 싶다면 이렇게 작성할 수 있어요.

Row(
    modifier = Modifier.fillMaxWidth(),
    verticalAlignment = Alignment.CenterVertically,
    horizontalArrangement = Arrangement.SpaceBetween
) {
    Column {
        Text("제목", fontWeight = FontWeight.Bold)
        Text("설명 텍스트")
    }
    Button(onClick = { /* TODO */ }) {
        Text("버튼")
    }
}

마치며

Row와 Column은 Compose에서 정말 자주 쓰이는 기본 레이아웃 컴포넌트입니다. 처음에는 간단하게 시작하더라도, 다양한 Modifier와 Arrangement, Alignment를 조합하면서 원하는 UI를 만들 수 있어요.

블로그 글에 대해 궁금한 점이 있다면 아래 카카오톡 오픈채팅에 들어와서 질문해주세요

Android Kotlin Compose QnA

open.kakao.com

(Compose) Image

DinoDev — Tue, 29 Jul 2025 14:43:41 +0900

Jetpack Compose에서 이미지를 화면에 표시할 때 사용하는 Image 컴포넌트에 대해 소개합니다.

앱을 만들 때 사진, 그림, 아이콘 등을 보여주는 건 거의 필수 기능인데요, Compose에서는 이 과정을 어떻게 처리할 수 있을지 알아보겠습니다.

Image 컴포넌트란?

Image는 단순히 말해 화면에 비트맵, 벡터, URL로 불러온 이미지 등을 보여주는 UI 컴포넌트입니다.

Compose에서는 painter라는 개념을 이용해 이미지를 그리는데, 로컬 리소스뿐만 아니라 네트워크 이미지도 손쉽게 사용할 수 있습니다.

Image(
    painter = painterResource(id = R.drawable.sample_image),
    contentDescription = "샘플 이미지"
)

크기와 스타일 설정

Modifier를 이용하면 크기나 스타일을 쉽게 변경할 수 있습니다.

Image(
    painter = painterResource(id = R.drawable.sample_image),
    contentDescription = "샘플 이미지",
    modifier = Modifier
        .size(120.dp)
        .clip(CircleShape)
        .border(2.dp, Color.Gray, CircleShape)
)

네트워크 이미지 불러오기

로컬 리소스뿐만 아니라 URL로 이미지를 불러오기 위해서는 Coil과 같은 Image Loader 라이브러리를 사용해야 합니다.

AsyncImage(
    model = "<https://example.com/image.jpg>",
    contentDescription = "네트워크 이미지",
)

https://github.com/coil-kt/coil

contentScale로 이미지 맞추기

이미지를 영역에 어떻게 채울지 결정하는 속성은 contentScale입니다.

XML에서 ImageView의 scaleType과 동일한 속성입니다.

ContentScale.Crop: 영역을 꽉 채우도록 잘라서 보여주기
ContentScale.Fit: 이미지 전체를 맞추되 비율 유지
ContentScale.FillBounds: 비율 무시하고 영역에 딱 맞추기

Image(
    painter = painterResource(id = R.drawable.sample_image),
    contentDescription = null,
    contentScale = ContentScale.Crop,
    modifier = Modifier.size(150.dp)
)

블로그 글에 대해 궁금한 점이 있다면 아래 카카오톡 오픈채팅에 들어와서 질문해주세요

Android Kotlin Compose QnA

open.kakao.com

(Compose) Button

DinoDev — Tue, 29 Jul 2025 11:38:26 +0900

이번 글에서는 Jetpack Compose의 가장 기본적이면서도 사용자와 상호작용 할 수 있는 UI 컴포넌트인 Button에 대해 이야기해보려고 합니다.

Button 컴포넌트란?

Compose에서 버튼은 Button() 함수를 사용해 구현합니다.

예를 들어, 화면에 간단한 버튼 하나를 만들고 싶다면 이렇게 작성할 수 있습니다.

var count by remember { mutableStateOf(0) }

Button(onClick = { count++ }) {
    Text("클릭 수: $count")
}

onClick 파라미터에 클릭 시 동작을 넣고, 버튼 안에는 Text를 사용해 표시할 글자를 넣습니다. XML 시절보다 훨씬 간단하고 직관적입니다.

버튼에 색상과 모양 추가하기

Compose의 버튼은 다양한 속성을 통해 쉽게 스타일링할 수 있습니다.

Button(
    onClick = { /* 클릭 시 처리 */ },
    colors = ButtonDefaults.buttonColors(
        containerColor = Color(0xFF6200EE), // 배경 색
        contentColor = Color.White // 글자 색
    ),
    shape = RoundedCornerShape(32.dp) // 모서리를 둥글게
) {
    Text("스타일 버튼")
}

버튼 크기 조절하기

버튼의 크기도 쉽게 설정할 수 있어요.

Button(
    onClick = { /* 클릭 시 처리 */ },
    modifier = Modifier
        .width(200.dp)
        .height(50.dp)
) {
    Text("큰 버튼")
}

아이콘과 함께 사용하기

버튼에 아이콘을 추가해 사용자 경험을 높일 수도 있습니다.

Button(onClick = { /* 클릭 시 처리 */ }) {
    Icon(
        imageVector = Icons.Default.Favorite,
        contentDescription = "Favorite",
        modifier = Modifier.size(18.dp)
    )
    Spacer(modifier = Modifier.width(8.dp))
    Text("좋아요")
}

Modifier.clickable

버튼을 사용하지 않고 Text에 Modifier.clickable을 사용하면 사용자의 클릭 이벤트를 받을 수 있습니다.

Text(
    text = "여기를 눌러보세요",
    modifier = Modifier.clickable { 
        println("Text 클릭됨!") 
    },
    color = Color.Blue,
    fontSize = 16.sp
)

블로그 글에 대해 궁금한 점이 있다면 아래 카카오톡 오픈채팅에 들어와서 질문해주세요

Android Kotlin Compose QnA

open.kakao.com

(Compose) Text

DinoDev — Mon, 28 Jul 2025 16:38:19 +0900

안녕하세요! 이번 글에서는 Jetpack Compose를 공부하시는 분들이 가장 먼저 만나게 되는 컴포넌트 중 하나인 Text 컴포넌트에 대해 소개해보려고 합니다.

Text 컴포넌트란?

Text 컴포넌트는 화면에 글자를 보여주는 가장 기본적인 컴포넌트입니다.

XML 시대에는 <TextView>를 썼지만, Compose에서는 Text() 함수를 사용합니다.

사용법도 매우 직관적입니다.

Text(text = "안녕하세요, Compose!")

이렇게 한 줄만 작성해도 화면에 "안녕하세요, Compose!"라는 글자가 나타납니다.

Text의 다양한 속성

Compose의 Text는 단순히 문자열만 출력하는 용도가 아닙니다.

여러 가지 속성을 조합해 글자 스타일을 쉽게 바꿀 수 있습니다.

Text(
    text = "안녕하세요, Compose!",
    color = Color.Blue, // 색상 blue
    fontSize = 20.sp, // 크기 20sp
    fontWeight = FontWeight.Bold // 볼드체
)

이렇게 글자를 다양한 형태로 보여줄 수 있는 속성들이 있습니다.

이런 스타일을 더욱더 심화로 커스텀하기 위해서는 TextStyle을 활용합니다.

Text(
    text = "Compose로 스타일링!",
    style = TextStyle(
        fontSize = 18.sp,
        fontWeight = FontWeight.Medium,
        letterSpacing = 1.sp
    )
)

최대 줄 수를 지정하고 넘치는 경우 ... 으로 생략할 수도 있습니다.

Text(
    text = "이 문장은 꽤 길어서 여러 줄에 걸쳐 보여질 거예요.",
    maxLines = 2,
    overflow = TextOverflow.Ellipsis
)

마무리

이렇게 Compose Text를 사용하면 정말 간단하게 글자를 보여줄 수 있고, 여러 형태의 스타일도 쉽게 추가할 수 있습니다.

블로그 글에 대해 궁금한 점이 있다면 아래 카카오톡 오픈채팅에 들어와서 질문해주세요

Android Kotlin Compose QnA

open.kakao.com

(Git) git alias로 빠르게 사용자 정보 변경하기

DinoDev — Mon, 28 Jul 2025 15:27:45 +0900

개발을 하다 보면 같은 컴퓨터에서 여러 계정 정보로 git commit을 해야하는 경우가 있습니다. 예를 들면 회사컴퓨터에서 회사와 개인 프로젝트를 오가며 git user.name과 git user.email을 바꿔야 하는 상황이 있습니다.

매번 복잡하게 변경하는 것 보다 git alias를 활용해서 한 줄 명령어로 빠르고 간단하게 전환할 수 있는 방법이 있습니다.

alias란?

alias는 git 명령어를 짧은 이름으로 별칭을 만들어 빠르게 실행할 수 있도록 도와주는 기능입니다.

예를 들면, git status를 git st 처럼 줄여 쓸 수도 있고, 복잡한 명령어도 하나의 단축어로 만들 수 있습니다. 이번 블로그에서는 복잡한 명령어를 하나의 단축어를 만드는 것을 소개합니다.

alias 만들기

먼저 git 전역 설정 파일인 ~/.gitconfig에 alias를 추가합니다.

아래 예시처럼 회사용과 개인용을 변경하는 alias를 추가합니다.

[alias]
	set-work = "!git config --global user.name dino && git config --global user.email dino@company.com"
	set-personal = "!git config --global user.name sjjeong && git config --global user.email sjjeong1225@gmail.com"

위 명령어를 복사해서 사용하시고 user.name 뒤에 있는 것과 user.email 뒤에 있는 것만 본인 것에 맞게 변경하시면 됩니다.

alias 사용하기

git set-work
git set-personal

위 명령어를 실행해보고 cat ~/.gitconfig를 보면 [user] 영역이 내가 설정한 것으로 잘 변경된 것을 확인할 수 있습니다.

마무리

git alias를 이용하면 user.name과 user.email 변경하는 것 외에 평소 귀찮았던 설정 변경을 훨씬 빠르게 할 수 있습니다.

작업 환경에 맞게 alias를 커스터마이즈해서 더 효율적인 개발 환경을 만들어보세요!

블로그 글에 대해 궁금한 점이 있다면 아래 카카오톡 오픈채팅에 들어와서 질문해주세요

Android Kotlin Compose QnA

open.kakao.com

(Compose) Compose 소개

DinoDev — Thu, 24 Jul 2025 14:46:38 +0900

안드로이드 앱을 만들 때 UI를 어떻게 설계하고 구현할까? 가 가장 큰 고민입니다.

기존에는 TextView와 Button, ImageView와 같은 View를 XML에 정의하고, Kotlin에서 가져와 속성을 바꾸고 액션을 지정하며 화면을 만들었습니다.

이제는 더 쉽고, 현대적인 방법인 Compose를 사용해서 UI를 구현할 수 있습니다.

Jetpack Compose는 Google이 공식적으로 제공하는 선언형 UI 툴킷으로 최근 안드로이드 개발 표준으로 자리 잡고 있는 기술입니다.

Compose는 화면의 상태(state)에 따라 UI를 선언적으로 그려주는 프레임워크 라고 할 수 있습니다. 기존 View는 XML에 UI를 정의하고 Kotlin에서 findViewById()로 뷰를 가져와서 속성을 변경하고 액션을 지정했다면 Compose는 원하는 UI의 상태를 선언하기만 하면 Compose가 알아서 그려주는 형태입니다. 다시 말해서 UI를 어떻게 그릴 것인지 고민하는 게 아니라 무엇을 그릴 지를 고민하는 형태가 됐습니다.

예를 들면 버튼을 눌렀을 때 버튼의 숫자가 올라가는 UI를 만들어 봅시다.

@Composable
fun Counter() {
    var count by remember { mutableStateOf(0) }

    Button(onClick = { count++ }) {
        Text("Clicked $count times")
    }
}

Compose에서는 이렇게 Button과 Text를 선언하고 이것들이 어떻게 보일지 묘사하면 됩니다. count가 변경되면 UI도 알아서 업데이트됩니다. count가 변경되면서 UI를 직접 업데이트할 필요가 없습니다.

Compose는 어떻게 쓸까요?

Compose를 사용하기 위해 2가지를 알아야 합니다.

첫 번째로 @Composable 함수입니다.

@Composable 함수는 UI를 그리기 위한 가장 작은 단위입니다.

반환값이 없는 형태의 함수에 @Composable을 붙이면 UI를 그리기 위한 형태가 됩니다. 그리고 함수 안에 Text, Button, Column과 같은 컴포넌트를 사용해 화면을 구성합니다.

@Composable
fun Greeting(name: String) {
    Text(text = "Hello $name!")
}

두 번째로 상태 관리입니다.

Compose는 화면의 상태가 바뀔 때마다 UI를 새로 그리도록 설계되어 있습니다.

remember나 mutableStateOf 같은 것을 사용해야 합니다.

var text by remember { mutableStateOf("Hello") }

Compose의 장점은 무엇일까요?

Compose는 XML 없이 Kotlin 코드만으로 UI를 작성할 수 있습니다.
상태만 관리하면 UI가 자동으로 업데이트돼서 수동으로 업데이트했던 것보다 버그를 줄일 수 있습니다.
XML과 Kotlin을 같이 관리하지 않고 Kotlin만 관리하면 되기 때문에 코드가 간결해지고 가독성이 높아집니다.
@Composable 함수 단위로 UI를 구성할 수 있어 재사용성이 높습니다.
@Preview를 사용해서 앱을 실행하지 않고 UI를 빠르게 확인할 수 있습니다.

마지막으로

Jetpack Compose는 단순히 새로운 UI 도구가 아니라, 안드로이드 개발 방식 자체를 바꾸는 도구입니다.

처음에는 낯설고 코드 스타일도 다르지만, 한 번 익숙해지면 빠른 개발 속도와 유지보수 편리함 때문에 절대 예전으로 돌아가기 어렵다는 말이 나올 정도로 강력합니다.

블로그 글에 대해 궁금한 점이 있다면 아래 카카오톡 오픈채팅에 들어와서 질문해주세요

Android Kotlin Compose QnA

open.kakao.com

(Coroutine) 나는 Coroutine 동작 순서를 얼마나 잘 아는가?

DinoDev — Fri, 27 Jun 2025 11:52:11 +0900

여러분들은 CoroutineRaceGuesser Game을 아시나요?

만약 처음 보셨다면 여러분들은 이 블로그 글을 만난 것이 정말로 행운입니다.

왜냐면 저도 이것을 알기 전에는 제가 Kotlin Coroutine 동작 순서에 대해 잘 아는줄 알았거든요.

몇일 전에 제가 운영하는 스터디의 안드로이드 카카오 단체톡방에 흥미로운 링크가 공유되었습니다. 그것은 바로 Coroutine 동작 순서 퀴즈 였습니다.

저는 Coroutine 스터디를 5기째 운영하고 있어서 쉽게 문제를 풀 것이라 생각했는데 맘처럼 쉽게 풀리지 않아서 아직 많이 부족하고 잘 모르는구나 하고 느꼈습니다.

이 코드는 어떤 순서로 동작하나요?

suspend fun main() = coroutineScope {
    delay(2000)
    val value1 = async {
        delay(1000)
        println("B")
        delay(1000)
        "A"
    }
    println("D")
    println(value1.await())
    delay(1000)
}

A, B, D는 몇초의 시간을 기다리며 어떤 순서로 출력이 될까요??

정답을 메모장에 작성하고 더보기를 눌러서 확인해보세요.

2초 delay

1초 delay

(done)

생각했던 동작 순서와 일치하나요??

문제가 쉬웠나요? 어려웠나요? 아니면 재미있고 흥미로웠나요??

문제를 더 풀어보고 싶다면 아래 링크로 들어가서 도전해보세요!

https://marcinmoskala.com/CoroutinesRaceGuesser/

Coroutines Guesser Game

marcinmoskala.com

코루틴 공부를 제대로 하고 싶다면?

저 또한 코루틴을 제대로 알지 못하고 사용했는데 조세영님이 쓰신 코틀린 코루틴의 정석을 읽고, 이 책으로 코루틴 스터디를 5기 째 운영하며 많이 성장 했습니다. 만약 코루틴을 제대로 알고 사용하고 싶다면 이 책을 강추합니다!

인프런에 온라인 강의도 있습니다

https://inf.run/S9Do1

코틀린 코루틴 완전 정복| 조세영 - 인프런 강의

현재 평점 4.8점 수강생 524명인 강의를 만나보세요. 『코틀린 코루틴의 정석』 저자의 코틀린 코루틴 강의입니다. 이 강의에서는 코루틴에 대한 지식을 기초부터 핵심까지 다룹니다. 코루틴을

www.inflearn.com

[본 게시물은 파트너스 활동의 일환으로 소정의 수수료를 받을 수 있습니다.]

그 외에 다른 것들?

Kotlin Coroutine 외에 Compose나 Collection 관련 게임도 있습니다.

https://marcinmoskala.com/ModifierOrderGuesser/

ModifierOrderGuesser

marcinmoskala.com

https://marcinmoskala.com/CollectionProcessingGuesser/

CollectionProcessingGuesser

marcinmoskala.com

블로그 글에 대해 궁금한 점이 있다면 아래 카카오톡 오픈채팅에 들어와서 질문해주세요

Android Kotlin Compose QnA

open.kakao.com

다이빙로그-45 오키나와 6 산칭

DinoDev — Tue, 17 Jun 2025 12:10:02 +0900

환경

날짜: 2025.06.15

나라: 일본

위치: 오키나와

다이브 포인트: 산칭

다이빙 센터: 홍스타 다이브(http://hongstardive.com/)

날씨: 해

조류: 약함

시야: 매우 좋음

다이빙

휴식 시간: 113분

시작 시간: 13:31

시작 잔압: 190bar

최대 수심: 22m

다이브 시간: 42분

종료 시간: 14:13

종료 잔압: 60bar

탱크 크기: 11L

탱크 재질: 알루미늄

탱크 종류: Air

수온: 28도

장비

웨이트: 6kg(Belt-6kg)

슈트: Wet(5mm)

다이빙로그-44 오키나와 5 카메키치

DinoDev — Tue, 17 Jun 2025 12:08:59 +0900

환경

날짜: 2025.06.15

나라: 일본

위치: 오키나와

다이브 포인트: 카메키치

다이빙 센터: 홍스타 다이브(http://hongstardive.com/)

날씨: 해

조류: 약함

시야: 매우 좋음

다이빙

휴식 시간: 56분

시작 시간: 10:48

시작 잔압: 190bar

최대 수심: 22m

다이브 시간: 50분

종료 시간: 11:38

종료 잔압: 40bar

탱크 크기: 11L

탱크 재질: 알루미늄

탱크 종류: Air

수온: 27도

장비

웨이트: 6kg(Belt-6kg)

슈트: Wet(5mm)

다이빙로그-43 오키나와 4 크루키타

DinoDev — Tue, 17 Jun 2025 12:06:39 +0900

환경

날짜: 2025.06.15

나라: 일본

위치: 오키나와

다이브 포인트: 크루키타

다이빙 센터: 홍스타 다이브(http://hongstardive.com/)

날씨: 해

조류: 약함

시야: 매우 좋음

다이빙

휴식 시간: 분

시작 시간: 9:16

시작 잔압: 190bar

최대 수심: 22m

다이브 시간: 36분

종료 시간: 9:52

종료 잔압: 20bar

탱크 크기: 11L

탱크 재질: 알루미늄

탱크 종류: Air

수온: 26도

장비

웨이트: 6kg(Belt-6kg)

슈트: Wet(5mm)

다이빙로그-42 오키나와 3 나간누키타

DinoDev — Tue, 17 Jun 2025 12:05:07 +0900

환경

날짜: 2025.06.14

나라: 일본

위치: 오키나와

다이브 포인트: 나간누키타

다이빙 센터: 홍스타 다이브(http://hongstardive.com/)

날씨: 해

조류: 약함

시야: 매우 좋음

다이빙

휴식 시간: 90분

시작 시간: 13:25

시작 잔압: 190bar

최대 수심: 12m

다이브 시간: 44분

종료 시간: 14:09

종료 잔압: 60bar

탱크 크기: 11L

탱크 재질: 알루미늄

탱크 종류: Air

수온: 26도

장비

웨이트: 6kg(Belt-6kg)

슈트: Wet(5mm)

다이빙로그-41 오키나와 2 쿠에후키타

DinoDev — Tue, 17 Jun 2025 12:03:02 +0900

환경

날짜: 2025.06.14

나라: 일본

위치: 오키나와

다이브 포인트: 쿠에후키타

다이빙 센터: 홍스타 다이브(http://hongstardive.com/)

날씨: 해

조류: 약함

시야: 매우 좋음

다이빙

휴식 시간: 53분

시작 시간: 11:05

시작 잔압: 190bar

최대 수심: 10m

다이브 시간: 50분

종료 시간: 11:55

종료 잔압: 60bar

탱크 크기: 11L

탱크 재질: 알루미늄

탱크 종류: Air

수온: 26도

장비

웨이트: 6kg(Belt-6kg)

슈트: Wet(5mm)