DeviceInfo

 2026 북중미 월드컵(미국·캐나다·멕시코 공동 개최)의 8강전이 오늘(7월 12일) 아르헨티나와 스위스의 경기를 끝으로 모두 마무리됐습니다. 이제 남은 팀은 단 네 팀. 흥미로운 점은 대회 전 FIFA 랭킹 1~4위였던 프랑스, 아르헨티나, 스페인, 잉글랜드가 그대로 4강에 올랐다는 것입니다. 월드컵 역사상 처음 있는 일이라고 하니, 남은 세 경기가 얼마나 치열할지 짐작이 갑니다. 이 글에서는 오늘 끝난 8강 결과 요약, 4강 대진표와 한국시간 기준 준결승 일정, 그리고 경기별 관전 포인트를 한 번에 정리해 드립니다. 8강전 결과 한눈에 보기 날짜(현지) 경기 결과 7월 9일 프랑스 vs 모로코 프랑스 2-0 승 7월 10일 스페인 vs 벨기에 스페인 2-1 승 7월 11일 잉글랜드 vs 노르웨이 잉글랜드 2-1 승 (연장) 7월 12일 아르헨티나 vs 스위스 아르헨티나 3-1 승 (연장) 아르헨티나 vs 스위스 – 디펜딩 챔피언의 뒷심 오늘 경기의 주인공은 역시 디펜딩 챔피언 아르헨티나였습니다. 전반 10분 알렉시스 맥 알리스터의 선제골로 앞서갔지만, 후반 67분 스위스에 동점골을 허용하며 경기는 연장으로 향했습니다. 승부를 가른 건 연장 후반이었습니다. 112분 훌리안 알바레스가 결승골을 터뜨렸고, 라우타로 마르티네스가 쐐기골을 보태며 3-1로 경기를 끝냈습니다. 90분 내내 끈질기게 버틴 스위스의 조직력도 인상적이었지만, 토너먼트에서 이기는 법을 아는 팀은 따로 있었습니다. 잉글랜드 vs 노르웨이 – 벨링엄의 날 어제 열린 잉글랜드전은 주드 벨링엄의 원맨쇼였습니다. 안드레아스 스켈데루프에게 선제골을 내주며 끌려가던 잉글랜드는 전반 종료 직전 벨링엄이 동점골을 넣었고, 연장에서 다시 벨링엄이 결승골을 터뜨리며 홀란드의 노르웨이를 집으로 돌려보냈습니다. 잉글랜드 입장에서는 '메이저 대회 우승'이라는 오랜 숙원에 다시 한 걸음 다가선 승리였습니다. 4강 대진표와 준결승 일정 (한국시간) 경기 한국시간 장소 프랑스 vs 스페인 7월 15일(수)...

Compose Runtime 내부 동작 정리: SlotTable → ChangeList → Applier → setContent Compose를 쓰다 보면 “상태 바뀌면 알아서 UI가 갱신된다” 정도로 이해하고 넘어가기 쉬운데, 내부에서는 꽤 체계적인 파이프라인이 돌아간다. 핵심은 한 문장으로 요약하면 이렇다. SlotTable에 컴포지션 상태를 저장하고, 변경은 ChangeList에 모아뒀다가, Applier가 실제 노드 트리에 반영한다. 이 글은 그 흐름을 SlotTable/ChangeList/Applier/setContent 관점에서 정리한 내용이다. 1) SlotTable: “현재 컴포지션 상태 저장소” SlotTable은 Compose Runtime이 Composition의 현재 상태 를 들고 있기 위해 사용하는 인메모리 구조다. 초기 composition 때 테이블을 채우고 이후 recomposition 때마다 갱신한다 remember 값, 호출 위치 기반 그룹 정보, 매개변수 관련 정보 등이 여기 쌓인다 즉, 런타임이 “지금 UI가 어떤 구조/상태인지”를 판단하는 기준이 SlotTable이다. 2) 내부 구조: 갭 버퍼 기반 + (groups, slots) 2개 배열 SlotTable은 “빠르게 읽고/수정”하기 위해 갭 버퍼(gap buffer) 아이디어를 활용한다. 구현 관점에서 크게 두 덩어리로 나뉜다. groups : 그룹(Composable 단위) 메타데이터를 저장하는 영역 slots : 그 그룹에 속하는 실제 데이터(예: remember 값)를 저장하는 영역 그리고 갭(gap) 이라는 “비어 있는 연속 구간”을 두고, 삽입/삭제/교체가 일어나면 갭을 이동시키면서 덮어쓰는 방식으로 비용을 줄인다. 예를 들어 조건 분기 UI가 있다면, 조건이 바뀔 때마다 트리를 다 갈아엎는 대신 기존 위치로 갭이 이동한 뒤 필요한 부분만 덮어쓰기 에 가까운 방식이 가능해진다. 3) NonRestartableComposable과 “그룹 타입” 감각 잡...

  – Composer, SlotTable, ChangeList를 중심으로 Jetpack Compose는 선언형 UI를 효율적으로 관리하기 위해 런타임에서 Composition의 상태 저장 과 UI 변경 적용 을 명확히 분리한다. 이를 위해 Compose Runtime은 Composer , SlotTable , ChangeList , 그리고 이를 실제 UI로 반영하는 Applier , Recomposer 라는 구성 요소들을 사용한다. 이 글에서는 Compose Runtime 내부에서 Composable이 실행되고, 상태가 저장되며, 변경 사항이 실제 UI로 반영되는 전체 흐름 을 중심으로 구조를 정리한다. 전체 흐름 요약 Composable 함수가 실행되며 Composer를 통해 슬롯 테이블(SlotTable) 에 현재 상태를 기록 이전 Composition과 비교해 필요한 UI 변경 사항을 변경 목록(ChangeList) 으로 모델링 Composition이 완료되면 ChangeList가 Applier 에 의해 실제 UI 트리에 적용 Recomposer 는 상태 변경을 감지하고 필요한 범위만 재구성(Recomposition) SlotTable – Composition 상태 저장소 SlotTable은 Composition의 현재 상태를 메모리에 저장하는 트리 구조의 데이터 구조 다. Composable 함수 호출 순서에 따라 그룹(Group) 단위로 정보가 저장되며, Recomposition 시 이전 상태와 비교하는 기준이 된다. 주요 역할 Composable 호출 위치와 identity 관리 파라미터, remember 값, CompositionLocal 값 저장 Recomposition 시 변경 여부 판단 Positional memoization을 통한 불필요한 재실행 방지 내부 구조 특징 Group 단위 저장 시작 마커 + 데이터 슬롯 + 종료 마커 조건문, ...

Compose 컴파일러: 선언형 UI  Compose의 전체 흐름을 한 줄로 요약하면 꽤 단순하다. 개발자가 @Composable 을 사용해 Kotlin 코드를 작성하면, Compose 컴파일러가 이를 런타임이 이해할 수 있는 형태로 바꾸고 , 런타임은 그 결과를 바탕으로 UI를 그리고 갱신한다. 하지만 이 변환 과정 안을 들여다보면, 생각보다 훨씬 많은 일이 벌어진다. 개발자가 작성하는 것은 단순한 Kotlin 소스 코드이지만, 컴파일 단계에서 Compose 컴파일러는 이 코드를 분석해 중간 표현(IR)을 재구성한다. 이때 런타임에 필요한 매개변수, 그룹 정보, 상태 추적을 위한 각종 메타데이터가 코드에 자동으로 주입된다. 이후 Compose Runtime은 이 변환된 코드를 실행하면서 슬롯 테이블이라는 인메모리 구조를 관리하고, 상태가 바뀌면 필요한 범위만 다시 그리는 Recomposition을 수행한다. 우리가 직접 다루는 Compose UI는 이 구조 위에서 동작하는 여러 클라이언트 중 하나일 뿐이다. 왜 Kotlin 컴파일러 플러그인인가 Compose가 기존의 kapt 기반 어노테이션 프로세서 대신 Kotlin 컴파일러 플러그인 을 선택한 이유는 명확하다. kapt는 컴파일 이전 단계에서 새로운 코드를 생성할 수는 있지만, 이미 작성된 코드의 구조를 바꾸지는 못한다. 반면 컴파일러 플러그인은 컴파일 과정에 직접 개입해 IR을 분석하고 수정할 수 있다. 이 덕분에 Compose는 언어를 “사용”하는 수준을 넘어, 언어의 동작 방식을 확장 하는 선택을 할 수 있었다. 이 방식의 가장 큰 장점은 빠른 피드백이다. Compose 컴파일러는 프론트엔드 단계에서 정적 분석을 수행하며, 잘못된 Composable 호출이나 타입 불일치를 컴파일 시점에 바로 알려준다. 우리가 IDE에서 즉시 보는 경고나 오류는 별도의 IDEA 플러그인이 보조하지만, 그 근본적인 판단은 컴파일러 플러그인에서 이루어진다. 어노테이션은 컴파일러와의 계약이다 Compose에서 어노테...

Composable 함수 이해하기: Jetpack Compose의 핵심 개념 정리 Jetpack Compose에서 @Composable 함수는 UI를 직접 그리는 함수가 아니다. 대신 화면이 어떤 구조와 상태를 가져야 하는지를 설명하는 역할 을 한다. 이 설명들은 Compose 런타임에 의해 해석되어 메모리 안의 UI 트리, 즉 Composition 을 구성하거나 업데이트하는 데 사용된다. 이번 글에서는 Composable 함수가 어떤 방식으로 동작하는지, 그리고 왜 특정 규칙들이 중요한지 런타임 관점에서 정리해본다. Composable 함수의 본질: UI를 “그리는 것”이 아닌 “설명하는 것” 일반적인 Kotlin 함수는 입력값을 받아 결과를 반환한다. 반면 Composable 함수는 보통 값을 반환하지 않고( Unit ), 함수 실행 과정에서 UI 구조에 대한 정보를 방출한다. 이 과정은 Compose에서 흔히 emit(방출) 이라고 부르며, “여기에는 텍스트가 필요하고, 그 아래에는 버튼이 있다”와 같은 UI 설계도를 제출하는 것에 가깝다. Compose 런타임은 이 설계도들을 모아 인메모리 UI 트리를 구성한다. 즉, Composable 함수의 유일한 목적은 Composition을 생성하거나 최신 상태로 유지하는 것 이다. @Composable 어노테이션이 하는 일 @Composable 어노테이션은 단순한 표식이 아니다. 이 어노테이션이 붙은 순간, 컴파일러는 해당 함수를 특별한 호출 규칙과 실행 방식 을 가지는 함수로 변환한다. 대표적인 변화 중 하나는 컴파일 시점에 보이지 않는 매개변수인 Composer 가 함수에 추가된다는 점이다. 이 Composer는 Composable 함수와 Compose 런타임 사이의 중재자 역할을 하며, 부모 Composable에서 자식 Composable로 계속 전달된다. 이 구조 때문에 Composable 함수는 오직 다른 Composable 함수 안에서만 호출될 수 있다. Composer가 일관되게 전달되어야 전...

여름은 습도가 높은 계절인데도 유독 피부 당김을 호소하는 분들이 많습니다. 겉은 번들거리는데 속은 당기는, 이른바 '수부지(수분 부족형 지성)' 상태를 여름에 처음 경험하는 경우도 흔합니다. 왜 습한 여름에 오히려 피부 속 수분이 부족해지는지, 그리고 일상에서 어떻게 관리하면 되는지 원인부터 해결법까지 정리했습니다. 여름철 피부 건조의 3가지 원인 1. 에어컨 바람 에어컨은 실내 온도만 낮추는 게 아니라 습도도 함께 떨어뜨립니다. 하루 8시간 이상 냉방된 사무실에 있으면 피부 표면의 수분이 계속 증발하는 환경에 노출되는 셈입니다. 특히 바람이 얼굴에 직접 닿는 자리라면 건조 속도는 더 빨라집니다. 2. 강한 자외선 여름철 자외선은 피부 장벽을 약화시키는 주요 원인입니다. 피부 장벽이 손상되면 수분을 붙잡아두는 능력 자체가 떨어져서, 아무리 수분 제품을 발라도 금방 증발해 버립니다. 자외선 차단제를 꾸준히 바르는 것이 보습 관리의 시작인 이유입니다. 3. 과도한 세안 땀과 피지 때문에 하루에도 몇 번씩 세안을 하게 되는데, 세정력이 강한 클렌저를 자주 쓰면 피부에 필요한 유분까지 씻겨 나가 유수분 밸런스가 무너집니다. 세안 후 5분 안에 피부가 당긴다면 세안 습관을 점검해볼 필요가 있습니다. 실전 해결법: 순서가 핵심이다 여름 보습의 핵심은 '무겁게 덮는 것'이 아니라 '가볍게 채우고 잡아주는 것'입니다. 세안 직후 3분 이내 에 가벼운 수분 에센스로 피부 속 수분을 먼저 채워줍니다. 세안 후 시간이 지날수록 수분 증발이 빨라지므로 타이밍이 중요합니다. 수분크림으로 마무리 해 보습막을 만들어줍니다. 에센스만 바르고 끝내면 오히려 증발하면서 피부가 더 건조해질 수 있습니다. 냉방 환경에서는 미스트 를 하루 2~3회 보충합니다. 단, 미스트만 뿌리고 방치하면 역시 증발 시 수분을 빼앗기므로 가볍게 두드려 흡수시키는 것이 좋습니다. 피부 타입별 포인트 지성 피부라면 오일 성분이 적은 워터 타입 에센스가 부담이 없고, 건성 피...