Keep the Experience Natural, Easy, Light

2023 ~ 2026년 AI 사용법의 진화

interfacer_han — Fri, 1 May 2026 16:42:12 +0900

#1 개요

#1-1 What

2022년 말 ChatGPT 출시 이후 LLM은 빠르게 대중화되었다. 개발자들은 2026년 지금까지도 현재진행형으로, LLM이 더 잘 응답하거나 행동하도록 설계하는 기법을 연구하고 있다. 가장 대표적인 기법 3가지를 시간순으로 나열해본다.

#1-2 주의할 점

본 게시글의 제목에 '진화'라는 단어를 썼다. 그래서 "(비교적) 오래된 기법은 혹시 도태된 것인가?"라고 생각할 수도 있지만, 그렇지 않다. 모든 기법은 전부 중요하다. '진화'는 '개발자 관심사의 이동 경로'일 뿐, 모든 기법은 충실히 지켜야 한다 (세대교체가 아니라 동시 병행).

#2 프롬프트 엔지니어링

#2-1 WhatㆍWhy

"어떻게 질문해야 잘 대답하는가?" (입력 최적화)

입력 → 출력의 구조에서 입력을 조작해 좋은 출력을 기대한다. "가는 말이 고와야 오는 말도 곱다"라는 속담은 LLM에도 적용되기 때문이다.

#2-2 How

역할 부여 (Role Prompting)

"너는 초등학교 교사야. 초등학생이 이해하기 쉬운 방식으로 설명해."

어떤 존재로서 답해야 하는지를 지정해ㆍ관점ㆍ태도ㆍ전문성 프레임을 변경한다.

Chain-of-Thought Prompting (CoT)

"A, B, C의 단계별로 생각해."

모델이 사고하는 순서(= 추론 전개 방식)를 정한다

ReAct (Reason + Act)

"생각하고, 행동하고, 관찰하고, 다시 생각해."

모델이 추론과 외부 행동을 번갈아 수행하는 패턴을 설계한다. '행동 후 피드백 기반 수정' 기법이라는 점에서 현대 AI 에이전트의 원형이 되는 기법이기도 하다

#3 컨텍스트 엔지니어링

#3-1 WhatㆍWhy

"어떤 정보를 떠먹여 줘야 잘 대답하는가?" (정보 공급)

컨텍스트 윈도우(Context window)는 LLM 모델이 가진 일종의 램(RAM)이다. 컴퓨터의 RAM과 마찬가지로 무한한 크기가 아니기 때문에, 적당한 크기의 정확한 정보를 적재적소에 제공하는 것이 필요하다.

이는 프롬프트 엔지니어링의 한계로 이어진다. 양질의 질문만으로는, LLM 모델의 물리적 한계(컨텍스트 윈도우 크기)를 극복할 수 없는 것이다.

또 다른 이유: 비용 절감

질문(요청)에 담긴 정보(컨텍스트)가 커질수록 LLM의 컴퓨팅 비용과 응답이 시간 급증한다. 반면, 같은 정보를 '반복 전달'(= 2번 이상 전달)하는 경우에는 (정보가) 캐시 처리되어 비용이 거의 10분의 1로 줄어든다. AI 사용료를 아끼기 위해서라도 컨텍스트 엔지니어링은 필요하다.

#3-2 종류

System Context: 에이전트가 항상 참조하는 기본 설정
Conversation Context: 대화 과정에서 누적되는 정보
Tool & Environment Context: 도구 실행으로 얻는 실시간 정보

#3-3 '다다익램'은 LLM에서도 통할까?

'다다익램'은 컴퓨터의 RAM 크기는 클수록 좋다는 의미다. LLM의 RAM인 컨텍스트 윈도우에게도 일반적으로는 통하는 말이다. 컨텍스트 윈도우가 커질수록 긴 대화를 잘 기억하고, 연속적인 작업도 잘 수행한다. 하지만 아래의 2가지 주의 사항을 고려해야 한다.

Lost in the Middle: LLM이 전체 컨텍스트의 첫 부분과 끝부분은 잘 지키지만, 중간(Middle) 부분에 있는 컨텍스트일수록 무시할 확률이 높은 현상을 의미한다. 컨텍스트 윈도우의 크기가 커질수록 많은 정보(컨텍스트)를 넣을 수 있지만, 그에 비례해서 Lost in the Middle 현상 제어의 필요성도 커진다.
작업대(컨텍스트 윈도우)에 관련 없는 (쓰레기) 정보가 넘치면 모델의 판단이 '오염'되어 결과의 질이 저해된다. 무작정 많이 넣는 것만이 능사는 아니다.

#3-4 How

Retrieval-Augmented Generation (RAG)

"모르는 건 알아서 검색해."

필요한 정보를 외부 저장소에서 알아서 찾게 풀어준다. 웹(구글 등), DB의 특정 레코드, Notion 문서, 구글 드라이브 등 검색(접근)할 수 있는 매개체를 활용하게 만든다.

Context Packing

"(LLM이 RAG 등을 활용해 가져온) 정보들을 알아서 최적화해"

컨텍스트 윈도우 안에 정보 조각들을 어떤 우선순위와 압축도로 넣을지 결정한다. 이른바 선택과 집중이다.

Chunking

검색ㆍ저장ㆍ삽입을 용이하게 하려고 정보(문서 파일 등)를 적절하게 작은 크기의 조각(Chunk) 단위로 잘라두는 것.

~~Chunking은 RAG이나 Context Packing처럼 LLM이 동작 중(런타임)에 하는 일이 아니라 사람이 하는 일이다.~~ 요즈음엔 런타임 Chunking도 많아졌다고 한다.
혹은, 사람이 LLM에게 (본격적인 핵심 질문을 하기 전에) 미리 시켜둘 일이다.

#4 하네스 엔지니어링

#4-1 Why

"원하는 대답을 강요하려면 어떻게 해야 하는가?" (실행 통제)

하네스 엔지니어링 전까지 LLM에게 질문(요청)한다는 것은, 곧 부탁하는 것과 같았다. 왜냐하면 LLM은 그 원리상, 뜬금없는 대답을 할 수도 있기 때문이다. 그럴 때의 시간 낭비를 막기 위해서, LLM이 반드시 내가 원하는 답을 내놓도록 강제할 필요성이 생겼다. Structured Output 등 (지엽적인) 실행 통제 기법은 이미 존재했으나, 이를 좀 더 체계화하고 (전체적으로) 확장할 필요를 느낀 것이다.

주의할 점

사실 '강제'라는 표현은 직관적인 설명을 위해 과장한 감이 없지 않다. 여기서 말하는 '강제'란,

"특정 파일 속 소스 코드 실행"같이 거의 100%의 일관성을 지닌 요청
여전히 '부탁'처럼 보일 순 있으나, 프롬프트 엔지니어링 및 컨텍스트 엔지니어링의 패러다임 때와 비교하면 훨씬 더 명령적(↔ 선언적)인 요청
(똑똑하지만 동시에) 불안정한 LLM을 안정적으로 일하게 만드는 기술

(1)부터 (3)까지의 모두를 포함한다.

#4-2 What

LLM을 말(Horse)로 비유하자면, 하네스 엔지니어링은 말에 마구(Harness)를 씌워 내가 원하는 행동을 하도록 조종(강제)하는 것이다. 구체적으로는 아래와 같은 절차를 설계하는 걸 하네스 엔지니어링이라 부른다.

Agent가 Context를 바탕으로 Plan을 세우고,
Tool / MCP를 사용해 실행하고,
Hook과 Skill로 품질을 제어하고,
Human이 감독한다. (출처)

AI Agent는 알아서 판단하고 계획해서 결과를 내는 AI를 의미한다. 즉, AI Agent 구축엔 하네스 엔지니어링이 반드시 들어가야 한다. 실무적으로는 둘을 같다고 봐도 된다. 그 때문에 바로 아래에서 이어지는 #4-3에서, 하네스 엔지니어링의 기법과 AI Agent 구축 기법을 구분하지 않고 서술했다.

#4-3 How

Planning
사용자의 요청(질문) 즉 복잡한 과제를 나눠서, 실행할 수 있는 Workflow로 바꾸는 것. 일반적으로 AI는 Workflow를 세운 뒤 사용자에게 보여주고 이대로 진행할지를 먼저 확인받는다. 저위험 과제의 경우엔 승인 없이 그냥 즉시 실행하기도 한다.

Sub Agent에 위임
#3-3에서 말했던 Lost in the Middle 등의 이유로, 단일 에이전트에게 많은 일을 시키면 컨텍스트를 까먹는 현상이 발생한다. 따라서, AI Agent를 여러 Sub Agent를 나누는 구조가 나오게 되었다. Sub Agent의 역할은 프론트엔드 전문, 백엔드 전문, DB 설계 전문, 테스트 전문 등으로 다양하게 나뉠 수 있다. 또, 여러 Sub Agent를 관리하는 Agent를 Orchestrator Agent라 부른다.

개략적인 동작 방식은 아래와 같다.

Orchestrator Agent가 각 Sub Agent에 '작업을 분배'(= Fan Out)
각 Sub Agent는 병렬적으로 독립적인 컨텍스트와 도구를 가지고 작업 수행 후 반환
Orchestrator Agent가 반환된 결과를 통합(= Fan In)

Tool, Plugin, Model Context Protocol (MCP)

Tool: 개별 함수
Plugin: Tool 묶음
MCP: 모든 Tool과 Plugin을 어떤 AI 모델에서도 쓸 수 있게 하는 표준화된 인터페이스로 연결
(≈ 충전 케이블 타입을 USB-C로 통일했던 과거의 사례)

에이전트의 손과 발이 되어, 실제 세계와의 상호작용을 하는 기법들이다. 좀 더 엄밀하게 말하자면, Tool은 AI가 호출할 수 있는 기능의 단위, Plugin은 어떤 기능들을 하나의 패키지로 묶은 배포용 단위다.

Skill & Hook

Skill: 에이전트가 특정 작업을 수행할 때 참조하는 Best Practice 문서
Hook: 특정 조건 만족 시 어떤 일을 하라고 강제

에이전트의 행동을 제약하는 기법들이다. Hook에는 아래와 같은 4가지 종류가 있다.

Pre-action: 에이전트가 행동하기 전 수행
Post-action: 에이전트가 행동한 후 수행
Validation: 에이전트 출력의 품질 검증
Notification: 특정 조건 충족 시 인간에게 알림

Human In The Loop (HITL)

AI 동작의 중간 또는 최종 단계에서, 인간 판단이 결과에 영향을 주도록 설계하는 것. 앞서 설명한 Planning에서 설명했듯, Agent가 실행할 일련의 계획을 사람에게 먼저 확인받고 진행하는 것도 HITL의 일부다. HITL은 2종류로 나뉜다.

Task-level HITL: 개별 작업 승인/수정
- AI가 짠 Planning 검토
- AI 산출물의 결과 검수
- 민감하거나 애매한 동작 수행 전 확인받기
System-level HITL: 전체 루프 성능 평가/개선
- Prompt 수정
- 제목 생성 Skill 교체
- 검수 Rule 추가
- 코드 생성 후 테스트 단계 추가

#4-4 실습

추가 예정 (다음 게시글로 이어짐).

#4-5 용어에 대한 논쟁

테스트/배포 자동화 (CI/CD), 성능 평가 파이프라인(흐름) 등의 개념은 LLM이 대중화되기 한참 전에 나왔다. 저 개념들을 LLM을 활용해 구현했을 뿐인데, 그걸 굳이 "하네스 엔지니어링"라는 신조어로 재포장하는 것에 대해 거부감이 있었다고 한다.

하지만 컨텍스트 엔지니어링의 한계 즉, 부탁의 한계를 극복한다는 점에서 기존 컨텍스트 엔지니어링과 명확하게 구분되는 신조어는 필요하다고 생각한다. 그리고 프로그래밍에 대한 비전공자들의 접근성이 좋아진 요즘, 더 시적(?)인 용어는 개념의 부드러운 인지를 돕는다.

물론 어느 쪽이든, 용어 속에 있는 본질은 알아야 할 테다.

#5 요약

ChatGPT 이후, 개발자들은 '챗봇'의 잠재력을 끌어내 '에이전트'로 만드는 기법들을 고안해 냈다.

#6 출처

Swemo - Iteration 5: MVP 1 구현 (2/3)

interfacer_han — Tue, 21 Apr 2026 18:23:25 +0900

#1 개발 목표 (Iteration Goal)

#1-1 이상(Ideal)과 징검다리

Iteration 5: MVP 1 구현 (2/3)

Iteration 4의 토대 위에 기본 기능들을 구현했다. 이어지는 Iteration 6에서 추가적인 리팩토링 후 MVP를 마무리한다.

#1-2 개발 범위

이번 개발 범위 (In Scope)

카테고리 추가, 이름 변경, 삭제 기능
메모 수정, 삭제 기능
메모 콘텐츠(MemoContent) 제거 기능
리팩토링
1. MemoViewModel가 지닐 필요가 없는 과도한 프로퍼티를 MemoUiState 쪽으로 옮김
2. MemoViewModel의 일부 이벤트들이 재사용성을 가지도록 수정
3. MemoViewModel의 이벤트들에 (직관적으로 읽히도록) 주석 추가
4. MemoScreen에 구조적으로 화면의 하나의 Dialog만 표시되도록 설계

#2 변경 내역 (커밋 목록)

#2-1 Iteration 5-1: MemoRepository에 함수 추가 및 MemoDao 가독성 업데이트

관련 개발 범위

카테고리 추가, 이름 변경, 삭제 기능
메모 수정, 삭제 기능

주요 변경점

MemoRepository에 Iteration 5에서 사용할 여러 함수를 (선제적으로) 추가
MemoDao 함수들의 이름을 가독성과 통일성을 고려해 변경하고 역할별로 (섹션으로 나눠) 정돈

참고

#2-2 Iteration 5-2: MemoViewModel 리팩토링

현재 MemoViewModel이 Category 인스턴스를 직접 보유하고 그걸 MemoUiState에 넘겨주고 있다. MemoViewModel이 불필요한 책임을 떠맡고 있기에, 이를 고쳐서 ViewModel은 Category.id만 조작하게 두었다. 그리고 그 Category.id에 종속되어 업데이트되는 Category 인스턴스가 MemoUiState 속에 들어가도록 변경했다.

관련 개발 범위

리팩토링
- MemoViewModel가 지닐 필요가 없는 과도한 프로퍼티를 MemoUiState 쪽으로 옮김

주요 변경점

현재 카테고리를 직접 저장(보유)하지 않고, selectedCategoryId를 단일 진실 공급원으로 삼아 파생하도록 변경
determineCategory()로 기본 선택과 유효하지 않은 선택값 복구 로직을 정리
카테고리 변경이나 MemoEditor 토글이 편집 중인 Memo에 영향을 주지 않도록 수정
State 관리 코드 가독성 개선

코드 스니펫

// 기존 코드
private val selectedCategory = MutableStateFlow<Category?>(null)

---
// 변경한 코드
private val selectedCategoryId = MutableStateFlow<Long?>(null)

// 이제 selectedCategory는 selectedCategoryId로부터 파생되는 상태
// MutableStateFlow가 아니기 때문에, 임의로 조작할 수 없다 (= 책임에서 해방)
private val selectedCategory: StateFlow<Category?> = combine(
    categories,
    selectedCategoryId,
    ::determineCategory
).stateIn(
    scope = viewModelScope,
    started = SharingPolicy,
    initialValue = null
)

참고

[GitHub] 이 작업의 Commit

#2-3 Iteration 5-3: Dialog 상태를 enum 형 UI 로컬 상태로 전환

사용자 경험을 위해서라도 한 화면에 Dialog는 하나만 떠 있어야 한다. 그리고 Dialog가 많아짐에 따라 선언적으로 관리할 필요도 느꼈다. 따라서, 'Dialog 표시'의 플래그 역할을 하는 State를 선언하고, 그 State의 변화에 맞춰 MemoScreen에 Dialog가 뜨도록 설계했다.

관련 개발 범위

리팩토링
- MemoScreen에 구조적으로 화면의 하나의 Dialog만 표시되도록 설계

주요 변경점

앞으로 여러 종류의 Dialog를 표현해야 하므로, 복수 개의 Dialog가 화면에 중첩되는 현상 또는 가독성 저해를 대비해 'Dialog 표시 플래그 State'를 ViewModel에서 UI로 내림
State를 Boolean 형이 아닌 enum 형으로 변경해 여러 다이얼로그를 표현할 수 있으면서, 오직 하나의 Dialog만을 화면에 띄우도록 구조적으로 강제

코드 스니펫

internal fun MemoScreen(
    ...
    dialogState: MemoScreenDialog?, // 추가됨
    ...
) {
    ...

    when (dialogState) {
        MemoScreenDialog.CATEGORY_ADD -> {
            AddCategoryDialog(
                ...
            ) {
                ...
            }
        }

        MemoScreenDialog.CATEGORY_RENAME -> {
            ...
        }

        MemoScreenDialog.CATEGORY_DELETE -> {
            ...
        }

        null -> Unit // Dialog가 닫힌 상태 의미
    }
}

참고

[GitHub] 이 작업의 Commit

#2-4 Iteration 5-4: 카테고리 추가, 이름 변경, 제거 기능 추가

Iteration 4 및 Iteration 5-1 ~ 5-3에서서 행한 밑작업 토대 위에 카테고리 조작 관련 기능을 구현했다.

관련 개발 범위

카테고리 추가, 이름 변경, 삭제 기능

주요 변경점

카테고리 이름 변경과 제거를 위한 드롭다운 메뉴 구현
카테고리 추가, 이름 변경, 삭제를 위한 여러 Dialog 구현
구현한 Dialog를 MemoScreenDialogHost에 추가
CategoryDao에 정의해놓은 함수를 MemoViewModel과 MemoScreen을 거쳐 Dialog까지 전달

스크린샷

참고

[GitHub] 이 작업의 Commit

#2-5 Iteration 5-5: 메모 제거 구현

Iteration 4 및 Iteration 5-1 ~ 5-3에서서 행한 밑 작업 토대 위에 메모 제거 기능을 구현했다.

추가로, Iteration 5-3에서 만든 'Dialog 표시 플래그' State를 enum에서 sealed interface로 변경했다. 왜냐하면, 메모를 제거할 때 어떤 메모를 제거하는지에 대한 정보를 ViewModel에게 알려줘야 하기 때문이다. sealed interface로 묶을 '메모 제거 Dialog 플래그'가 Memo.id를 받도록 선언해야, 사용자가 '메모 제거 Dialog'에 있는 '삭제' 버튼을 클릭했을 때 발생하는 이벤트에 Memo.id 인수를 실어 (MemoViewModel로) 보낼 수 있다.

관련 개발 범위

메모 삭제 기능

주요 변경점

MemoScreenDialog를 enum 형에서 sealed interface로 변경
Memo 아이템을 길게 눌러 DeleteMemoDialog를 띄움
Dialog에서 버튼을 한 번 더 눌러 해당 Memo 제거

코드 스니펫

// 제거한 코드
enum class MemoScreenDialog {
    CATEGORY_ADD,
    CATEGORY_RENAME,
    CATEGORY_DELETE
}

---
// 추가한 코드
sealed interface MemoScreenDialog : Serializable {
    data object CategoryAdd : MemoScreenDialog {
        private fun readResolve(): Any = CategoryAdd
    }

    data object CategoryRename : MemoScreenDialog {
        private fun readResolve(): Any = CategoryRename
    }

    data object CategoryDelete : MemoScreenDialog {
        private fun readResolve(): Any = CategoryDelete
    }

    data class MemoDelete(val memoId: Long) : MemoScreenDialog
}

이 구조에서, MemoScreenDialog형 데이터가 MemoDelete로 그 값을 변경하려면 memoId도 함께 넣어주어야 한다.

참고

[GitHub] 이 작업의 Commit

#2-6 Iteration 5-6: 메모 업데이트 구현

MemoCard 클릭 시, MemoEditor에 해당 MemoCard의 Memo 정보가 MemoEditor로 복사되게 만들었다. 이 상태에서는 MemoEditor의 '전송' 버튼이 '수정' 버튼으로 변경된다. 그리고 수정 버튼을 클릭하면 Memo가 업데이트된다.

관련 개발 범위

메모 수정 기능

주요 변경점

메모 클릭 시 에디터에 해당 메모를 복사
에디터가 "등록 모드", "수정 모드" 둘 중 하나가 되도록 변경
에디터의 모드에 따라 메모를 추가(Insert)하거나 수정(Update)
메모 삭제 시, 해당 메모를 에디터에서 수정 중이었으면 에디터 초기화
카테고리 삭제 시, 해당 카테고리에 속하는 메모를 에디터에서 수정 중이었다면 에디터 초기화

스크린샷

참고

[GitHub] 이 작업의 Commit

#2-7 Iteration 5-7: MemoContent 제거 구현

"-" 버튼을 클릭하면 MemoContent가 한 줄씩 지워지게 만들었다.
MemoContent.text가 수정될 때마다 내부적으로 전제 Memo를 갈아끼우는 식으로 데이터베이스 조작이 이뤄졌는데, 이제 MemoContent의 변화가 해당 전체 Memo를 건들이지 않고 해당 MemoContent가 저장된 장소만 업데이트하도록 개선했다.

관련 개발 범위

메모 콘텐츠(MemoContent) 제거 기능

주요 변경점

MemoContent 제거 버튼 및 동작 구현
MemoEditor에서 Memo를 수정할 때마다 전체 Memo가 갱신되는 구조 대신, MemoContent 별로 갱신되게 만듦
MemoContent가 하나도 없는 Memo는
- (UI) Insert 및 Update 버튼을 비활성화
- (ViewModel) Insert 및 Update 이벤트에서도 (분기문으로) 걸러줌
새 MemoContent의 label 값이 MemoContent의 갯수에 기반하는 대신, 마지막 MemoContent의 label 값에 기반해 생성되게 함

스크린샷

참고

[GitHub] 이 작업의 Commit

Swemo - Iteration 4: MVP 1 구현 (1/3)

interfacer_han — Wed, 1 Apr 2026 14:32:40 +0900

#1 개발 목표 (Iteration Goal)

#1-1 이상(Ideal)과 징검다리

이상(Ideal)

내가 직접 쓰고 싶은 앱이 아닌데, 남에게 어떻게 권유할 수 있을까? 앞으로 추가할 기능의 아이디어를 얻기 위해서든, 개발 의욕을 위해서든, 버그 발견을 위해서든 제작자의 실사용은 필수다.

지금까지의 작업 결과물을 토대로, 당장 내가 사용할 수 있는 앱을 만든다. 메모장 대용으로 사용할 수 있기만 하면 그만이므로, 완성도에는 신경 쓰지 않아야 할 것이다. CategoryㆍMemoㆍMemoContent 각각에 대한 CRUD만을 구현한다.

Iteration 4: MVP 1 구현 (1/3)

현재까지 구현한 것을 중간 마무리하여 첫 번째 MVP를 만든다. Iteration 4에서는 실제 데이터베이스 추가 및 해당 DB에 메모를 추가하는 기능까지만 구현한다. 이어지는 Iteration 5에서 나머지 기능들까지 구현하고 Iteration 6에서 코드 리팩토링까지 한 후에, 첫 번째 MVP를 마무리하겠다.

#1-2 개발 범위

이번 개발 범위 (In Scope)

실제 Database 구현
메모 추가 기능
MVP를 위한 UI 업데이트
1. IME에 반응하는 UI
2. LabelChipGroup 제거
  - 아이디어 자체를 폐기하는 게 아니라, 당장의 MVP 구현을 위해 제거
  - Iteration 4에서 제거 후 나중에 다시 추가

범위 외 (Out of Scope)

메모 삭제 기능
메모 속 MemoContent 개별 삭제 기능
메모 수정 기능
카테고리 추가 기능
카테고리 삭제 기능
카테고리 이름 수정 기능

#2 변경 내역 (커밋 목록)

#2-1 Iteration 4-1: IME에 반응하는 UI

실사용을 위해서, 우선 UI가 IME에 반응하지 않는 점을 수정한다.

관련 개발 범위

MVP를 위한 UI 업데이트
- IME에 반응하는 UI

주요 변경점

App의 Window가 IME에 영향받지 않도록 설정
MemoEditor가 IME에 맞춰 움직이도록 구현
Iteration 1-3에서 테스트용으로 뒀던 topBar 속 버튼을 제거하고, 해당 버튼이 지녔던 기능을 MemoEditor 속 "Send" 버튼에 할당

스크린샷

참고

[GitHub] 이 작업의 Commit

#2-2 Iteration 4-2: LabelChipGroup 등 제거

LabelChipGroup은 일단 삭제했다. 당장 구현할 MVP에서 보이기에는 완성도가 떨어지고 시간도 없기 때문이다.
- 하지만, LabelChipGroup은 본 앱의 핵심 UI 요소이기 때문에 나중에 어떤 형태로든 다시 추가될 것이다.
이전에 구상했던 설계에 걸맞게, 아이템이 오래된 메모부터 아래쪽에서 올라오게 수정했다.

관련 개발 범위

MVP를 위한 UI 업데이트
- LabelChipGroup 제거

주요 변경점

MemoFeed의 아이템이 아래에서 위로 올라오는 형태로 변경
MemoEditor에서 "-" 버튼 제거
LabelChipGroup 제거
MemoContentTextField 디자인 살짝 다듬음

스크린샷

코드 스니펫 - MemoFeed

package com.example.memo.components

...

@OptIn(ExperimentalMaterial3Api::class)
@Composable
fun MemoFeed(
    memos: List<Memo>,
    modifier: Modifier
) {
    LazyColumn(
        modifier = modifier,
        reverseLayout = true,
    ) {
        items(memos.asReversed()) { memo ->
            Spacer(modifier = Modifier.height(4.dp))
            MemoCard(memo = memo)
        }
    }
}

reverseLayout = true 로 레이아웃 컨테이너를 뒤집고, 그 뒤집힌 컨테이너에 아이템을 역순(asReversed)으로 준다. 이러면 최신 메모일수록 아래에 있고 최초 스크롤바의 위치도 맨 아래에서 시작하는, 이른바 채팅 UI가 된다.

참고

#2-3 Iteration 4-3: MemoContent 추가 버튼 구현

MVP를 위한 UI 업데이트를 마무리한다
MemoEditor를 통해 FakeMemoRepository에 메모를 추가하는 기능을 구현했다

관련 개발 범위

MVP를 위한 UI 업데이트
메모 추가 기능

주요 변경점

MemoEditor 속에 MemoContent 추가 버튼 구현
MemoEditor로 메모 입력 → (FakeMemoRepository에) 메모 추가 기능 구현

스크린샷

참고

[GitHub] 이 작업의 Commit

#2-4 Iteration 4-4: id 프로퍼티의 데이터형 변경

내부 데이터베이스를 사용할 예정이므로, id는 서버 환경처럼 String 타입으로 둘 필요가 크지 않다고 판단했다. 오히려 전통적인 방식대로 숫자형 데이터를 사용하는 편이 저장, 조회, 관리 측면에서 더 적절하다고 본다.
MemoContent는 Memo에 종속된 항목이기 때문에 별도의 id 프로퍼티를 두지 않았다. 그러나 앞으로 다른 Memo로 이동시키는 기능 등이 추가될 가능성이 높다고 판단해, 선제적으로 id 프로퍼티를 추가했다.
- 식별자가 뒤늦게 필요해지면 데이터 구조 + 사용처 전반을 함께 수정해야 할 수 있어, 여기에서 미리 반영하는 편이 더 안정적이라고 판단했다.

관련 개발 범위

실제 Database 구현

주요 변경점

Model 클래스들의 String 형 "id" 프로퍼티의 데이터형을 Long 형으로 변경
MemoContent에 (Long 형) "id" 프로퍼티 추가

참고

#2-5 Iteration 4-5: database 모듈 구현

database 모듈을 선언 후 간단하고 정석적인 데이터베이스를 구현했다

관련 개발 범위

실제 Database 구현

주요 변경점

database 모듈 추가 및 기본적인 데이터베이스 구현
.gitignore 업데이트

참고

#2-6 Iteration 4-6: 내부 데이터베이스와 연동

Iteration 4-5에서 만든 데이터베이스를 사용한다.

관련 개발 범위

메모 추가 기능

주요 변경점

FakeMemoRepository → FakeMemoRepositoryImpl로 이름 변경
database 모듈을 의존하는 MemoRepositoryImpl 구현
MemoViewModel에 FakeMemoRepositoryImpl 대신 MemoRepositoryImpl 주입

스크린샷

참고

[GitHub] 이 작업의 Commit

AI 혁신 뒤에 남는 것

interfacer_han — Wed, 18 Feb 2026 09:34:14 +0900

#1 혁신 뒤에 남는 것

모든 혁신은 공통으로 하나의 일을 해왔다. 바로, '미련한 짓'의 범위를 늘려온 것이다. 혁신이 일어나면 새로운 능력이 생기는 것과 동시에, 예전엔 당연했던 일부 행동이 비합리적 선택으로 변모한다. 혁신 뒤에 남는 것은, 버려야 할 과거의 잔재다.

엑셀 등장 이후, 수기로 장부 쓰기는 미련한 일이 되었다.
검색엔진 등장 이후 백과사전을 뒤지는 행위도 마찬가지다.
내비게이션 등장 이후, 종이지도를 펴는 일 역시 (특별한 경우를 제외하면) 거의 사라졌다.

따라서 중요한 질문은 이것이다: AI 혁신이 이뤄진 지금, 무엇이 미련한 짓인가?

#2 AI 혁신 뒤에 남는 것은...

#2-1 초안

이제 어떤 분야든, 준전문가 수준의 초안을 즉시 만들어 볼 수 있다. 따라서 빈 화면에서 모든 것을 처음부터 작성하려는 시도는 미련한 짓이 된다.

#2-2 반복

특히 프로그래밍에서 그렇다. 반복되는 패턴을 직접 타이핑하고, 구조를 매번 처음부터 세우고, 기계적으로 구현을 반복하는 일은 자기 학대나 다름이 없다. 그래도 개발자가 집중해야 할 것은 여전히 남아 있으며, 그중 일부는 아래와 같다.

프로그램 구조 결정
트레이드-오프 판단
사용자(인간) 행동에 대한 통찰
...

#2-3 지식 학습

과거에는 경험을 쌓아야만 알 수 있는 것들이 많았다. 이제는 비교, 요약, 대안 검토, 가정의 검증이 거의 즉시 가능하다. 단순 반복을 통한 축적은 점점 학습이라기보다 자동화로 대체될 작업에 가까워지고 있다.

#2-4 직관 (암산)

AI의 가장 큰 특징은 정답을 잘 맞히는 것이 아니라, 대안을 거의 무한히 만들어낼 수 있다는 점이다. 따라서 하나의 직관만 믿고 단일한 설계를 고집하는 태도는 미련하다. 다른 구조는 없는지, 더 나은 설계는 없는지, 이 가정이 틀렸다면 어떻게 되는지 이 질문을 하지 않는 것이 오히려 더 큰 비용이 된다. 질문하는 (거의) 동시에 AI발 초안을 받아서 직접 보고 판단 할 수 있으니 말이다. 직관(直觀)이 아닌 직관(직접 관람)을 하라는 말이다.

#3 결론

그래서 내가 스스로에게 던지는 질문은 이것이다. 나는 아직 무엇을 미련하게 계속하고 있는가?

인터넷 이후 세대는 인터넷을 배우지 않았다. 그냥 썼다. 엑셀도 마찬가지다. 익히기 위해 사용한 것이 아니라, 필요해서 쓰다 보니 익숙해졌다. AI도 결국 같은 종류의 도구가 될 것이다. 나는 AI를 '이해'하려고 하지 않을 것이다. AI를 '잘' 쓰는 사람이 되려고도 하지 않을 것이다. 대신 AI 때문에 더 이상 할 필요가 없는 일을 버리는 사람이 될 것이다. 아마, 혁신 뒤에 남는 차이는 결국 그것뿐일 테다.

Swemo - Iteration 3: 메모 화면의 State & Event 체계 정리

interfacer_han — Sun, 8 Feb 2026 20:01:32 +0900

#1 개발 목표 (Iteration Goal)

#1-1 이상(Ideal)과 징검다리

이상(Ideal)

사용자 관점에서 직관적인 메모 앱을 만들어야 한다. 사용자의 의도에 걸맞은 행동을 유도할 수 있어야 하고, 사용자가 의도가 드러나는 결과를 보여주어야 한다.

Iteration 3: 메모 화면의 State & Event 체계 정리

지금까지 구현한 UI는 일종의 뼈대에 불과했다. 이 뼈대에 붙일만한 '살'이란, 사용자 행동에 의한 상호작용(Event) 그리고 상태(State)의 변화다. 앱에서 사용자에게 제공할 '직관적인 행동'이 무엇인지를 정의하고, (좋은 방향으로) 업데이트 해나가야 한다.

#1-2 개발 범위

이번 개발 범위 (In Scope)

State down / Event up 구조 확립
- Screen은 ViewModel을 몰라야 함
- ViewModel은 Compose State를 몰라야 함
ViewModel 구현
- ViewModel 보유할 State와 UI 단에서 보유할 State (DrawerState 등)를 구분
- ~~이벤트 발생에 따른 State 업데이트를 위한 onEvent() 함수 보유~~
  - 전체 코드의 평균 가독성이 저해되기에 진행하지 않음 (참조: #2-2)
MemoUiState 클래스 구현
- ViewModel에서 관리할 모든 State를 Wrapping 한 클래스
~~MemoEvent 클래스 구현~~
- ~~Event sealed interface~~
- 전체 코드의 평균 가독성이 저해되기에 진행하지 않음 (참조: #2-2)
MemoScreen 업데이트
- 매개변수로 State 및 Event만 받도록 업데이트

범위 외 (Out of Scope)

Data layer 관련
IME, focus, scroll 관련
UI 다듬기
- 애니메이션
- 세부 레이아웃 미세조정
- 디자인 개선
성능(최적화) 관련
- derivedStateOf 최적화
- recomposition 분석
- snapshotFlow 사용

#2 변경 내역 (커밋 목록)

#2-1 Iteration 3-1: ViewModel 도입 및 State 정리

Swemo의 MemoScreen에는 MemoEditor가 존재하고, 이 컴포넌트에서 (앞으로의 구현에서) 꽤 복잡한 State 및 Event가 존재할 터다.

data class MemoUiState(
    val categories: List<Category> = emptyList(),
    val selectedCategory: Category? = null,
    val memos: List<Memo> = emptyList(),
    val allLabels: Set<String> = emptySet(),
    val editorState: EditorState = EditorState()
) {
    data class EditorState(
        val isVisible: Boolean = false,
        val editingMemo: Memo? = null
    )
}

그래서, MemoUiState 속에 inner class로 EditorState를 (별도로 분리해) 선언했다.

의존성 관리를 위해 Hilt 등의 라이브러리들을 추가했고, 마무리로 이 스크립트를 통해서 Now in Android와 버전 카탈로그에서의 프로터피명을 맞춰주었다.

관련 개발 범위

State down / Event up 구조 확립
ViewModel 구현
MemoUiState 클래스 구현

주요 변경점

MemoViewModel 도입 (의존성 주입은 Hilt를 이용)
MemoUiState로 MemoScreen의 모든 State를 객체 하나로 통합(Wrapping)

얻은 경험치

MemoScreen 매개변수에 들어갈 람다 함수를 함수 참조(Callable Reference)로 표기해 봤다. 가독성 면에서 훨씬 나았다.

참고

#2-2 Iteration 3-2: Event 관리를 위한 구조 설계

#2-1에 맞춰, 예전에 배운 방식대로 MemoEvent를 만들어서 Event 관리를 하려고 했다.

// 추가하려고 했던 코드

sealed interface MemoEvent {
    data class SelectCategory(val category: Category) : MemoEvent
    data class AddMemo(val memo: Memo?) : MemoEvent
    data class ChangeAddCategoryDialogVisibility(val visible: Boolean) : MemoEvent

    sealed interface MemoEditor : MemoEvent {
        data object ToggleVisibility : MemoEditor
    }
}

이렇게 Event를 sealed interface로 묶는 것이 보기에는 통합성 있어 보인다. 이후 MemoViewModel에 fun onEvent(event: MemoEvent)를 선언해서 MemoScreen으로부터 Event를 받는 방식으로 바꾸려 했다. 하지만 실제 프로젝트에 적용해 보니 문제가 발생했다.

// in MemoScreen.kt

ModalNavigationDrawer(
    ...
    drawerContent = {
        CategorySelector(
            ...
            onAddCategoryButtonClick = {
//              onAddCategoryDialogVisibilityChange(true)
                onEvent(MemoEvent.ChangeAddCategoryDialogVisibility(true)) // 복잡해졌다
            }
        )
    }
)

주석 처리된 코드가 원래 코드인데, 그 아래 코드와 같이 가독성이 나쁜 코드로 바꿔주어야 했기 때문이다. 따라서, 나중에 Event가 정말 많이 복잡해져서 집중 관리를 해줘야 할 필요가 생기기 전까지는 (MemoEvent 등으로) Event들을 묶지 않기로 했다.

결론적으로 이번 커밋에선, 아직 MemoScreen에 남아있던 이벤트 선언부들을 ViewModel로 올리고 코드를 약간 다듬는 정도로 마무리했다.

관련 개발 범위

State down / Event up 구조 확립

주요 변경점

MemoScreen에 남아있던 이벤트 선언부들을 ViewModel로 올림

코드 스니펫 - MemoScreen 호출부

MemoScreen(
    uiState = uiState,
    drawerState = drawerState,
    // events
    onCategorySelected = viewModel::selectCategory,
    onAddMemoClick = { viewModel.addMemo() },
    onMemoEditorToggleButtonClick = viewModel::toggleEditorVisibility,
    onAddCategoryDialogVisibilityChange = viewModel::changeAddCategoryDialogVisibility,
)

Event가 하나 추가될 때마다 람다 함수 매개변수가 하나씩 늘어날 것이다. MemoEvent 및 MemoViewModel.onEvent()가 있었다면, 모든 이벤트 람다 함수를 onEvent = viewModel::onEvent 로 퉁칠 수 있었을 것이다. 하지만 이런 이득보다, 다른 부분에서 발생하는 가독성적인 손실이 더 클 것이다.

얻은 경험치

당연하게도, 함수 참조(Callable Reference)는 매개변수가 없을 때만 쓸 수 있다.

참고

#3 개발 결과 (Iteration Outcome)

MemoScreen을 State down / Event up 구조로 전환하고, ViewModel 도입으로 UI가 ViewModel의 상태에 의존하게 만들었다. 이벤트의 추상화(MemoEvent)도 검토했지만, 가독성을 해하기에 일단 보류했다.

최소한의 행동경제학 - 행복

interfacer_han — Fri, 6 Feb 2026 15:22:10 +0900

#1 개요

"모든 선택에는 심리적 가격표가 붙어 있다."

책 '최소한의 행동경제학'의 여섯 번째 장.

#2 책 요약

#2-1 손실회피

'100%로 5만원 얻기'와 '50%로 100만원 얻고 50%로 50만원 잃기'의 이지선다가 있다. 기댓값만 보자면 '5만원 vs 25만원'이다. 하지만 대부분의 사람은 전자를 고른다. 얻게 될 때의 기쁨보다, 잃게 될 때의 고통을 더 크게 느끼기 때문이다.

#2-2 부킹 프라이스*

* 부킹 프라이스^{booking price}: 자신이 행복을 느끼는 데 필요한 최소한의 가격 또는 가치. 마음의 장부에 기록(booking)해두는 가격이라는 뜻.

환심을 사기 위해선 큰 선물보단 여러 번의 작은 선물이 좋다. 그렇다고 모래알처럼 작은 선물은 안 된다. 부킹 프라이스는 충족하는 선에서 쪼개라. 자신에게도 적용할 수 있다. '소확행' 아니, '부확행'을 자주 느끼는 인생 전략을 짜는 것이다.

#2-3 보유 효과

우리 뇌는 소유한 것을 (타인에게) 넘기는 걸 손실로 여기고 회피한다. 이 때문에 사람들은 물건이나 권력, 지위 등을 한 번 손에 넣게 되면 그걸 가지고 있지 않았을 때보다 훨씬 높게 평가한다. 제품의 경우 "7일 이내 무조건 환불", 구독형 서비스의 경우 "처음 한 달 무료"와 같은 홍보 문구는 상품에 대한 판매자의 자신감을 내비침과 동시에, 소비자의 보유 효과를 이용하는 것이다.

#2-4 결제와 소비의 디커플링

현금결제처럼 상품을 소비하는 시점과 비용을 지불하는 시점이 동시에 이루어지는 것을 '소비와 지불이 커플링(Copling)'되어 있다고 한다. '식권 30장 미리 구매'처럼 지불을 미리 하거나, 신용카드 결제처럼 나중에 하는 경우는 '소비와 지불이 디커플링(Decoupling)'되어 있다고 한다.

소비와 지불이 커플링 되어있을 때는 지불의 고통이 커진다. 그래서 소비를 절제하게 되지만, 그만큼 실제 소비 시의 만족감이 떨어진다. 지불의 고통은 현금 → 체크카드 → 신용카드 순으로 작아진다. 즉, 이 순서는 디커플링된 정도의 순서기도 하다. 소비와 지불이 디커플링될수록 소비하는 순간의 만족감이 높아지지만, 그만큼 씀씀이가 커지는 문제도 생긴다.

#2-5 상향 비교

남의 떡이 더 커 보인다. 가령 SNS에서 보이는 사람들의 모습을 보면, 대부분 나보다 더 잘 사는 것만 같다. 그 모습이 '최대한 부러움을 유발하려고 일부러 가공'한 이미지라는 걸 알고 봐도 그렇다. 비교는 어제의 나 및 미래의 나와 하는 것이다.

#2-6 자율성 + 유능성 + 관계성

자율성(Autonomy)은 자신의 의지에 따라 행동하고자 하는 마음이다. 학생으로 치면, "시키는 대로 시간표대로 생활하는 게 답답하다", "내가 하고 싶은 공부를 할 수 없다"라는 말로 흔히 표현된다.

유능성(Competence)은 능력을 발전시키고자 하는 것이다. 학생으로 치면, "왜 문제 풀이를 반복해서 하는지 모르겠다", "내 발전에 도움이 되지 않는 것 같다"라는 고민이 대표적이다.

관계성(Relatedness)은 주변 사람들과 어울리고자 하는 욕구다. 학생으로 치면, "어떤 친구와 다퉜다", "선생님 때문에 힘들다"하는 식이다.

3가지를 고려해서 직업을 선택하라. 개인의 스타일을 존중해주는 널널한 회사에 가거나, 창업을 택할 수도 있다. 내가 잘하고 좋아하는 일을 택하라. 마지막으로 좋은 사람들이 모인 곳을 택하라.

최소한의 행동경제학 - 돈

interfacer_han — Fri, 6 Feb 2026 15:17:44 +0900

#1 개요

"사람들은 반드시 필요해서 물건을 사는 것이 아니라, 자신이 원하는 것을 구매한다."

책 '최소한의 행동경제학'의 다섯 번째 장.

#2 책 요약

#2-1 심적 회계

비상금은 쓰기 싫다. 지금 당장 비상금을 쓰고 나중에 메우는 게 합리적인 경우에도 말이다. 같은 돈인데, 같지 않다. 용돈과 내가 직접 번 돈의 무게가 다른 것도 같은 맥락이다. 심적 회계는 우리가 마음속에서 돈을 여러 개의 통(식비, 문화비, 교육비, 예금 등)에 나눠 담는다는 의미다.

심적 회계는 합리적 의사결정을 방해하지만, 잘 이용하면 합리적 의사결정을 촉진하는 도구로 쓸 수도 있다. 첫째로, 돈이 드는 목표마다 '돈통'을 만들어두고 조금씩 저축하는 것이다. 둘째로, 공돈을 심적 회계에 포함하는 것이다. 우연히 받은 용돈을 막 쓰게 되는 건 심적 회계에 없던 공돈으로 취급되기 때문인데, 이 현상을 방지할 수 있다.

#2-2 비인지능력

키가 큰 사람일수록 돈을 잘 번다는 연구 결과가 있다. 정확히는, 15~16세에 또래보다 키가 컸던 사람들의 평균 소득이 높은 것이라 한다. 뒤늦게 폭발적으로 큰 사람들은 작은 사람들과 다르지 않았다. 사실, 키는 직접 요인도 아니었다.

이유는 바로 키가 큰 학생일수록 육체적 자신감이 있고, 그래서 성장기에 할만한 사회 활동(학생회, 동아리, 봉사 등)을 더 적극적으로 참여하기 때문이다. 그때 길러진 사회성(⊂ 비인지능력)이 죽을 때까지(!) 긍정적 영향을 준 것이다. 그러니, 키가 작다고 위축된 자녀가 있다면 응원해 주어야 한다. 중요한 건 키가 아니라 다양한 사회 경험이니까.

#2-3 프레이밍 효과

열쇠공 A는 1분 만에 샥하고 잠긴 문을 열었다. 열쇠공 B는 더운 여름날 2시간 동안 땀을 뻘뻘 흘리며 간신히 잠긴 문을 열었다. 어느 쪽이든 비용은 4만 원으로 같다. A 쪽 또는 B 쪽의 비용을 싸다고 느낄 수도 있고 비싸다고 느낄 수도 있다. 어느 기준ㆍ틀(프레임)인지에 따라서 말이다.

위의 사례에 적용해 볼 수 있는 2가지 프레임
- 일의 가치(비용)란, 상황의 신속한 해결이다.
- 일의 가치(비용)란, 내 눈앞에서 보인 노력과 시간이다.

#2-4 사회적자본

식당의 별점은 식당의 자산(자본)이다. 사회적으로(사람의 평가로) 형성되었기에 사회적자본이라 부른다. 자본이기에 안전성(신뢰성)도 존재하는데, 이는 주로 별점을 부여할 수 있는 플랫폼(에어비앤비, 네이버 지도, 당근마켓 등)을 얼마나 신뢰하는지에 달린다.

그렇다면 이렇게 말할 수도 있다: 특정 플랫폼ㆍ브랜드에 대한 '신뢰' 그 자체 또한 회사의 자산(자본)이다.

'적당한 가격의 무난한 옷'을 사려고 할 때 떠오르는 브랜드가 있는가? 아마 유니클로일 것이다. 매장에서의 경험ㆍ입을 때의 편안함ㆍ오래 입어도 멀쩡한 품질을 겪으며 형성되는 소비자의 인식(신뢰도)은, 유니클로의 사회적자본이다.

#2-5 인적 네트워크

단어 자체는 인간관계를 뜻하나, 말하고자 하는 바는 면식이 옅은 사람(느슨한 관계인 사람)의 중요성이다. 친하지 않은 사람일수록 내가 접하지 못한 정보를 가지고 있을 가능성이 높기 때문이다. 그 정보로 일자리를 구하거나 자신이 하는 일에 대한 도움을 받을 수 있다.

#2-6 휴리스틱*

* 휴리스틱^heuristic: 시간이 부족하거나 정보가 불충분할 때 합리적인 판단 대신 경험에 기반해 빠르고 쉽게 내리는 어림짐작(추론).

** 편익^benefit: 어떤 선택을 함으로써 얻게 되는 이익이나 만족감.

*** 기회비용^{opportunity cost}: ↖ 그 선택으로 인해 포기되는 것의 가치.

비 오는 날엔 유독 택시 잡기가 힘들다. 왜? "날씨가 안 좋을수록 사람들이 택시를 많이 이용하니까"라는 대답은 하수다. 정확히는 '택시 기사들이 돈을 많이 벌어서'다. 택시 기사는 본인이 정한 하루 매출 목표금액을 달성하면 퇴근하는 경우가 많다고 한다. 비가 오면 목표금액을 빨리 달성하니 퇴근 시간도 빨라지는 것이다.

익숙히 하던 대로(= 휴리스틱), 목표금액 달성 시 퇴근을 해버리는 전략은 돈벌이 면에서 합리적이지 않다. 비 오는 날처럼 손님이 많은 날일수록, 빠른 퇴근에 의한 편익**보다 기회비용***이 크기 때문이다.

최소한의 행동경제학 - 선택

interfacer_han — Fri, 6 Feb 2026 15:05:10 +0900

#1 개요

"결정의 순간에, 사람들은 논리보다 직관에 의존한다."

책 '최소한의 행동경제학'의 네 번째 장.

#2 책 요약

#2-1 앵커링 효과

'1만 원짜리 옷'과 '2만 원에서 50% 할인된 1만 원짜리 옷'은 같은 가격임에도, 자아내는 분위기가 분명 다르다. 고객이 처음 접한(인식한) 숫자(1만 원 vs 2만 원)가 다르기 때문이다. 고객은 후자의 옷을 더 좋은 것으로 판단할 가능성이 높다.

처음 접한 숫자는 마치 우리 뇌에 내리는 배의 닻(앵커^Anchor)과 같아서, '기준'으로서 뇌리에 각인된다. 가령 음식점에서 가장 비싼 메뉴, 의류 가게에서 가장 비싼 옷은 다른 메뉴나 옷의 가격을 상대적으로 싸게 느끼게 만드는 앵커다.

셀프 앵커링 효과도 존재한다. 예를 들어 특정 브랜드의 패딩이 비싸 보여도, 그걸 한 번 사서 입고 나면 그게 기준(앵커)이 되어버린다. 나중에 패딩이 낡아 새로 패딩을 사려고 하면, 앵커를 박아놓은 (비싼) 가격대의 패딩을 다시 사게 될 확률이 높다.

애플 특유의 폐쇄적인 생태계는 셀프 앵커링 효과를 유발한다. Windows나 Android 등 다른 생태계에 대한 호환성이 미비한 iOS에 한 번이라도 발을 들이면 빠져나가기 힘들다.

비슷한 효과 - 준거 가격

비싸다/싸다를 판단하는 기준이라는 점은 같지만, 서로 다른 효과다. 앵커링 효과가 '외부에서 주입된 숫자가 즉각적으로 판단을 왜곡하는 현상'이라면, 준거 가격(#2-6)은 '소비자에게 축적된 경험에서 형성된 가격'이다.

#2-2 왝더독

공짜 아이스크림을 위해 비 오는 날 긴 대기 줄을 기다리는 건 합리적일까? 웩더독은 개(dog)의 꼬리가 몸통을 흔드는(wag) 현상을 말한다. 기업들은 소비자들로 하여금, 몸통은 보이지 않게 꼬리는 집중하게 만든다.

때로는 공짜가 제일 비싼 법이다.

#2-3 매몰 비용

뷔페는 대부분 비싸다. 그래서 "본전은 뽑아야지"라는 생각으로 무심코 과식하게 된다. 이미 지불한(매몰된) 가격이 아깝다는 이유로, 스스로 손해를 입는 것이다. 물이 엎질러지지 않게 주의하되, 이미 엎질러졌다면 깨끗하게 포기하자.

#2-4 대조 효과

500만 원짜리 가죽시트는 비싼 것 같지만, 1억 원짜리 차의 500만 원짜리 가죽시트 옵션은 뭔가 그럴듯하다. '의자시트 하나에 500만 원이나 하는 절대 수치'라는 기준이, '자동차 가격의 5%밖에 안 되는 상대 수치'로 옮겨갔기 때문이다. 같은 값이어도 무슨 기준이냐에 따라 반응이 달라진다.

거의 같은 사례로, 사치품 매장은 입구 쪽에 초고가 제품을 전시하곤 한다. 해당 초고가 제품이 아닌 제품들이 비교적 싸게 느껴지도록 만들기 위함이다. '비싼 제품'이라는 인식이 '그나마 싼 제품'으로 바뀐다.

비슷한 효과 - 미끼 효과

대조 효과가 '비교 기준의 변화'로 목표(Target)의 가치나 매력을 왜곡시키는 전략이라면, 미끼 효과는 목표보다 '열등한 선택지'의 추가로 목표의 상대적 우위를 높이는 전략이다.

#2-5 한정된 인지적 자원*

* 인지적 자원^{cognitive resources}: 사람들이 작업을 수행하고 정보를 처리하는 데 필요한 정신적인 의미의 자원.

모든 '자원'이 그렇듯, 인지적 자원 또한 무한하지 않다. 우울하거나 힘들 때는 감정 관리 때문에 인지적 자원이 더 쉽게 동난다. 합리적인 사고는 (인지적 자원에 기반한) 인지적 노력의 결과인데, 이 말은 자원이 결핍되면 합리적 사고가 줄어들어 충동적으로 행동하게 된다는 것이다. 이것이 우울하거나 힘들 때 과소비가 발생하는 원리다.

#2-6 준거가격*

* 준거가격^{reference price}: 기준이 되는 최초의 가격 (정상가).

준거가격은 이른바 '국룰' 가격이다. 가령 PC방 요금의 국룰은 15년 넘게 '시간 당 1000원'을 유지하고 있다. 사람들에게 형성된 국룰 가격보다 낮은 가격은, '사면 이득'이라는 심리를 불러일으킨다. 그래서 필요없는 소비가 조장된다. 이는 비합리적 소비임에도, "싸게 잘 샀다"라며 자기합리화하게 만든다.

반대로 준거가격에 비해 비싼 값을 소비자가 기꺼이 지불할 때도 있다. 축제 부스에 있는 음식이나 영화관에서 파는 생수의 가격을 떠올려보라. 그 장소에서 사야 의미가 있는 물건들이기에 우리는 웃돈을 주고 구매하는 것이다.

붕어빵 가격의 요즘 국룰은 '1000원에 2개' 정도다 (1000원에 3개 시절은 이제 끝이 났다). 나의 경우 길을 걷다가 1000원에 3개 붕어빵을 파는 곳을 발견한다면, 배가 불러도 살 것 같다. 물건(붕어빵)이 아닌, 소비 그 자체를 위한 소비를 위해서.

비슷한 효과 - 앵커링 효과

비싸다/싸다를 판단하는 기준이라는 점은 같지만, 서로 다른 효과다. 준거 가격이 '소비자에게 축적된 경험에서 형성된 가격'이라면, 앵커링 효과(#2-1)는 '외부에서 주입된 숫자가 즉각적으로 판단을 왜곡하는 현상'이다.

최소한의 행동경제학 - 목표

interfacer_han — Fri, 6 Feb 2026 14:59:56 +0900

#1 개요

"사람들은 선택의 자유를 좋아하지만, 너무 많은 선택은 결정을 어렵게 만든다."

책 '최소한의 행동경제학'의 세 번째 장.

#2 책 요약

#2-1 순서 효과

상대 평가를 잘하려면 표본이 많이 필요하다. 그래서 심사 위원은 먼저 나오는 사람들에게는 높은 점수를 주지 않으려는 경향이 있다. 따라서 발표든 면접이든 순서상 나중에 하는 게 더 좋다.

#2-2 자기 절제 도구

데드라인이 중요하다는 사실은 이미 유명하다. 과제의 마감 시간을 잘게 나눠라. 이때, 나누는 주체는 (타인이 아닌) 본인일 때 더 좋다. 그래야 자신의 능력에 맞게 과제와 시간을 소분할 수 있고, 계획이 틀어지더라도 수월하게 통제할 수 있기 때문이다.

#2-3 자이가르닉 효과

드라마ㆍ웹툰은 다음 내용이 궁금해지는 시점에서 끊음으로써, 시청자의 탄식을 자아낸다. 찜찜해진 시청자는 빨리 다음 내용이 나오길 고대한다. '미완성 효과'로도 불린다. 또, '일단 시작하라' 효과라고도 부를 수 있겠다. 시작하는 순간부터 '완성' 전까지는 '미완성' 상태가 유지되므로.

공부를 지속하다 보면 '관성'이라고 표현할 만한, 어떤 에너지가 샘솟는 걸 느낄 수 있다. 그 에너지는 과제의 완료가 슬슬 가시화될 때쯤에 더 요동친다. 자이가르닉 효과였던 것이다.

#2-4 상태 의존 기억

우리는 시험에 대비하기 위해 모의고사를 치른다. 시험과 같은 환경에서 연습하기 위함이다. 이렇듯, 학습한 환경은 기억에 영향을 준다. "내가 뭘 하려고 했더라?"라는 의문을 해결하는 가장 강력한 방법을 우린 모두 경험적으로 알고 있다. 바로 조금 전까지 있었던 장소나 행했던 행동을 다시 복기하는 것이다. 시험을 치를 장소에 미리 가보자. 내가 발표할 장소에 가서 리허설을 해보자.

#2-5 공개 선언 효과

누구나 타인에게 인정받고 싶은 욕구를 지니고 있다. 그렇다면 당연히, 지키지도 못할 말을 하는 가벼운 사람으로도 보이기 싫을 것이다. 다른 사람들 앞에서 나의 목표를 공개적으로 선언해 보자. 우리는 의식ㆍ무의식적으로 해당 목표를 더 열심히 챙기게 된다.

#2-6 부화 효과

창의적인 문제 해결을 원한다면, 업무 중 적절한 휴식을 취해주어야 한다. 원리는 '망각'이다. 쉬는 동안 특정 해결법에 매몰되었던 나의 의식이 초기화(망각)되고, 의식이 쉬는 동안 무의식은 새로운 해결법을 떠올려 내게 알려준다.

최소한의 행동경제학 - 대화

interfacer_han — Fri, 6 Feb 2026 14:59:22 +0900

#1 개요

"가치는 절대적인 것이 아니라, 상대적인 기준에서 만들어진다."

책 '최소한의 행동경제학'의 두 번째 장.

#2 책 요약

#2-1 상호성의 법칙

작은 선물이 동반된 부탁은 거절하기 힘들다. 상대방의 호의에 보답(상호)하려는 마음 때문이다. 웃긴 건, '병 주고 약 주기'도 호의로 인식한다는 점이다. 처음에는 1만원을 요구했지만, 후에 3000원 요구로 인하'해준' 상대에게, 우리는 '호의'를 느낀다.

#2-2 사소한 칭찬의 힘

우리가 어린 시절에는 어른들에게 사소한 칭찬을 많이 들었다. 유년 시절이 종종 '잃어버린 천국'으로 묘사되는 이유 중 하나일 것이다. 이를 고려할 때, 사소한 칭찬을 싫어할 사람은 없다. 상대방이 칭찬을 귀찮아하거나 아부를 떠는 것으로 여긴다는 인식은 오해다. 어린이들은 칭찬을 받으면 기분이 좋은 게 티가 나지만, 점점 자라면서 티를 내지 않게 된 것뿐이다. 당연하겠지만, 터무니없는 억지 칭찬은 역효과만 난다.

#2-3 미끼 효과

'리그오브레전드 플래티넘 티어 플레이어'와 '오버워치 플래티넘 티어 플레이어' 둘 중 누가 더 게임을 잘하는가? 선뜻 대답하기 힘들다. 그러나 선택지에 '리그오브레전드 골드 티어 플레이어'가 추가되면, 사람들은 셋 중에서 '리그오브레전드 플래티넘 티어 플레이어'가 '오버워치 플래티넘 티어 플레이어'를 제치고 게임을 제일 잘 한다고 답한다. 상대방이 A와 B를 고민하고 있고 나는 상대방이 A를 고르길 원하는 상황이라면, A-를 추가 선택지로서 제시하라.

아이폰 16e는 가격 대 성능비가 낮은 것으로 유명하다. 어쩌면 아이폰 16e의 포지션은, 아이폰16을 더 매력적으로 보이게 만드는 앵커가 아니었을까.

비슷한 효과 - 대조 효과

미끼 효과가 목표(Target)보다 '열등한 선택지'의 추가로 목표의 상대적 우위를 높이는 전략이라면, 대조 효과는 '비교 기준의 변화'로 목표의 가치나 매력을 왜곡시키는 전략이다.

#2-4 낮은 공 기법

배달 앱에서 식당을 고를 때, 가격이 많이 낮은 식당이 눈에 띄곤 한다. 그러나 자세히 들여다보면, 처음 봤던 가격은 갖가지 수수료가 제외된 허수아비에 불과했다는 사실을 깨닫게 된다. 사람들은 자신이 결정한 것에 일관성을 지키려는 경향이 있다. 그러니 좋은 조건들을 먼저 제시해서 상대의 일관성을 만들어내는 전략은 유효하다. 단, 일회성이 짙은 전략이다. 앞서 말한 식당들이 과연 오래갈까? 나는 아니라고 본다.

#2-5 사회적 바람직성 편향

어떤 질문에 대답할 때, 솔직한 자신의 선호를 숨기고 대신 사회적으로 바람직하다고 여겨지는 쪽으로 답하는 경향이다. "요즘 어떻게 지내냐는 친구의 말에 그랜저로 대답했습니다"라는 광고 문구가 있다. 이 문구는 그랜저가 사회적으로 지니는 이미지를 '바람직(여기서는 경제적 성공)'한쪽으로 몰고 간다. 애플이 '힙'하고 '세련'된 이미지를 소비자의 뇌리에 각인하려고 기를 쓰는 것도 같은 맥락이다.

#2-6 거래효용*

* 거래효용: 물건의 실제 가격과 마음속 가격의 차이에 따라 느끼는 만족감.

실제 가치와 무관하게, 어렵게 얻었기 때문에 느껴지는 만족. 대기하는 줄이 긴 SNS 맛집에서 먹으면 식사의 만족도가 높아지는 이유다. 또 일부 기업들이, 판매하는 제품의 품귀 현상을 고의로 유도하는 이유다.

면접관들의 단골 질문은 "왜 지원했나요?"다. 이때, "집이랑 가까워서요."라고 대답하는 행위는 스스로 거래효용을 떨어뜨리는 것이다. 저 멀리서 힘들게 와야 하지만, 그럼에도 이 학교를 선택한 특별한 이유가 있다고 얘기하라. 이러면 면접관들의 관점에서 지원자의 거래효용이 높아져, 해당 지원자를 더 가치 있게 여기게 된다.