크루 닉네임 투핸더입니다. 주말동안 야무지게 놀다가 일요일 밤 자기 전에 생각나서 끄적이는 회고록입니다.일요일에 적다가 미션 제출 찐빠나서 월요일에 마무리했다.SS 연극안드로이드 트랙 미션 시작 (KanbanBoard Mission)첫 번째 PR 제출 및 피드백 반영두

2026-03-01에 작성한 회고록입니다.우테코 레벨 1이 시작되고 한 주가 지났습니다. 지난 일주일간 어떤 걸 했고 뭘 느꼈는지 정리하고 공유하고자 합니다.우테코 OT여러 코치님들의 닉네임과 앞으로의 생활이 어떤 식으로 흘러갈지 알 수 있었습니다.온보딩 미션 (연극,

처음 계획을 세울 당시에는 “분량이 많긴 해도 열심히 하면 4주 안에 할 수 있지 않을까?”하는 생각으로 계획을 세웠습니다.하지만 언제나 그렇듯 현실은 계획대로 흘러가지 않았고, 계획을 세울 당시에 생각나지 않았던 일정, 생각하지 못한 변수 등 여러 요소들로 인해 처음

어노테이션 사용을 통해 선언에 추가적인 메타 데이터를 연관시킬 수 있음어노테이션 설정 방식에 따라 소스코드, 컴파일된 클래스 파일, 런타임에 대해 작동하는 도구를 통해 메타데이터에 접근할 수 있음어노테이션 적용 방법 → @와 어노테이션 이름을 선언 앞에 작성함수, 클래

변성 → 기저 타입이 같고 타입 인자가 다른 타입의 관계를 설명하는 개념변성을 잘 활용하면 타입 안전성을 보장하는 API를 만들 수 있음어떤 함수가 리스트의 원소를 추가하거나 변경한다면 타입 불일치가 생길 수 있어 Any 타입에 String 타입을 넘길 수 없음원소를

JVM의 제네릭스 → 타입 소거를 사용해 구현실행 시점에 제네릭 클래스의 인스턴스에 타입 인자 정보가 들어있지 않다는 의미타입 소거는 어떤 영향을 미치는가?함수를 inline으로 선언해 제약을 우회하는 방법실체화된 타입 파라미터타입 검사와 캐스팅코틀린의 타입 인자 정보

제네릭스를 사용해 타입 파라미터를 받는 타입을 정의할 수 있음제네릭 클래스에 구체적인 타입을 넘기면 타입을 인스턴스화 할 수 있음컴파일러는 자동으로 author의 타입이 List임을 추론함빈 리스트를 정의할 때는 타입 인자를 명시해줘야 함타입 파라미터를 받음호출 시 구

람다 안에서 return → 그 람다를 호출한 함수의 실행이 종료되고 반환됨return이 선언된 람다를 호출한 함수를 반환하게 만드는 return 문을 “비로컬 return”이라고 함return이 바깥 블록을 반환시키는 경우 → 인라인 함수에서만 가능람다식에도 로컬 r

람다 → 익명 클래스로 컴파일람다식마다 새로운 클래스가 생김람다가 변수를 캡처한 경우 호출할 때마다 새로운 객체가 생김같은 기능을 하는 코드를 직접 실행하는 것보다 효율성이 떨어짐inline 변경자를 통해 선언inline 변경자가 선언된 함수를 호출하면 컴파일러는 그

고차 함수 → 다른 함수를 인자로 받거나 반환하는 함수람다 or 함수 참조를 통해 함수를 값으로 표현할 수 있음이를 통해 함수를 인자로 넘기거나 반환 받는 것이 가능filter 함수도 고차 함수임람다를 인자로 받기 때문이제 고차 함수를 정의하는 방법을 알아본다. 고차

프로퍼티 접근자 로직을 매번 재구현할 필요 없이 쉽게 구현할 수 있음자신의 값을 필드가 아닌 DB 테이블, 브라우저 세션, 맵 등에 저장할 수 있음위임 → 작업을 도우미 객체가 처리하도록 맡기는 디자인 패턴도우미 객체 = 위임 객체도우미 객체를 직접 작성할 수도 있지만

구조 분해를 사용하면 복합적인 값을 분해해서 별도의 여러 지역 변수를 한꺼번에 초기화할 수 있음일반 변수 선언과 비슷해 보이지만 = 왼쪽에 여러 변수를 괄호로 묶음구조 분해 선언은 관례를 사용함 → componenN 이라는 함수를 호출data 클래스의 주 생성자에 들

컬렉션에서 가장 자주 쓰는 연산인덱스로 원소를 읽거나 쓰기어떤 값이 컬렉션에 속해 있는지 검사이 연산들은 연산자 구문으로 사용할 수 있음인덱스 접근 → collectionindex원소가 컬렉션이나 범위에 속해 잇는지 검사 → in 연산자코틀린의 인덱스 접근 연산자 →

코틀린은 기본 타입 뿐만 아니라 객체에 대해 비교 연산을 수행할 수 있음자바에서는 equals나 compareTo를 호출해야 함코틀린에선 산술 연산자를 사용하여 코드를 간소화 할 수 있음== 연산자 → equals 메서드로 컴파일관례를 적용한 것!= 연산자도 equal

자바 → 기본 타입에 대해서 만 산술 연산자를 사용할 수 있음String 값에 대해 + 연산자를 사용할 수 있음클래스에 메서드를 호출하는것 보다 산술 연산자를 사용하는 편이 편할 때가 있음BigInteger 클래스에서 add를 호출하는것 보다 + 연산을 사용하는 편이

많은 크루들이 KPT 회고 방식을 적용하여 작성한 글들을 읽어보며 ‘나도 적용해볼까?’라는 생각이 들었습니다.그래서 3주차 회고록에는 KPT를 적용해 저의 3주차를 돌아보고자 합니다.공부한 내용7장, 널이 될 수 있는 값8장, 기본 타입, 컬렉션, 배열9장, 컬렉션 오

인자로 쓰인 타입에도 물음표( ? )를 붙이면 null을 저장할 수 있음list<Int?> → Int? 타입을 저장할 수 있음Int 또는 null을 저장할 수 있음List<Int?>리스트 자체는 항상 null이 아님리스트에 들어가는 각 원소는 null이 될

코틀린 → 원시 타입과 래퍼 타입을 구분하지 않음그 이유와 작동 원리Object, void 등의 자바 타입과 코틀린 타입의 대응 관계원시 타임 → 값이 직접 들어감참조 타입 → 메모리 상의 객체 위치가 들어감원시 타입은 값에 대한 메서드를 호출할 수 없음원시 타입을 래

자바의 타입 시스템은 코틀린의 null 가능성을 지원하지 않음모든 값을 쓸 때마다 null 검사를 해줘야 하는가?@Nullable 어노테이션이 붙은 코드 == 코틀린의 null이 될 수 있는 타입널 가능성 어노테이션이 없는 경우 자바의 타입은 코틀린의 플랫폼 타입이 됨

객체를 일단 생성한 후 나중에 초기화하는 프레임워크들이 많음안드로이드, JUnit 등등…코틀린에는 클래스안의 null이 될 수 없는 프로퍼티를 생성자가 아닌 특별한 메서드에서 초기화할 방법이 없음프로퍼티를 null이 될 수 있는 타입으로 선언하면 모든 프로퍼티 접근에