한 학기동안 수강하게 된 프론트엔드 수업이 마무리되어가고 있다. 나는 최종 프로젝트 과제로 레퍼런스 이미지에서 시각적 스타일 요소를 추출하여 새로운 UI 디자인을 생성하도록 도와주는 인터페이스인 Style Print를 제작하였다.

StylePrint는 여러 UI 레퍼런스 이미지를 업로드하면, 각 이미지에서 디자인 요소를 추출하고 이를 조합해 새로운 React/Tailwind UI 코드를 생성하는 프로젝트이다. 매주 현직 개발자 분으로부터 멘토링을 그룹별로 멘토링을 받았는데, 그 과정에서 중요한 건 AI가 결과를 만들어내는 것 자체가 아니라, AI가 만든 결과를 내가 판단할 수 있는 상태로 만드는 것이라는 사실을 알게되었다.

그럴듯한 결과의 문제

AI로 UI를 만들면 결과가 꽤 그럴듯하게 나온다. 색도 적당히 맞고, 레이아웃도 나쁘지 않아 보이고, Tailwind 코드도 일단 동작한다. 그런데 코드 자체 만으로는 내가 원했던 색을 쓴 건지, 레퍼런스의 어떤 부분을 가져온 건지, 접근성 기준은 만족하는지, 코드가 재사용 가능한지 판단하기 어려웠다.

특히 UI 레퍼런스를 여러 개 섞는 프로젝트에서는 더 그렇다. 예를 들어 색상은 1번 레퍼런스에서 가져오고, 타이포그래피는 2번에서 가져오고, 레이아웃은 3번에서 가져왔다고 해도, 최종 결과만 보면 이 조합이 의도대로 반영되었는지 알기 어렵다.

IntentSpec이라는 연결고리

그래서 이 프로젝트에서는 이미지에서 바로 코드로 가지 않고, 중간에 IntentSpec이라는 구조를 둔다. 레퍼런스에서 추출한 디자인 요소를 색상, 타이포그래피, 레이아웃, 간격, 컴포넌트 스타일 같은 facet으로 나누고, 어떤 요소가 어떤 레퍼런스에서 왔는지 기록한다.

대략 이런 식이다.

type IntentSpec = {
  chosen: {
    colorRefId?: string
    typographyRefId?: string
    layoutRefId?: string
    spacingRefId?: string
    componentStyleRefId?: string
  }
  normalized: {
    palette?: Record<string, string>
    typography?: object
    layout?: object
    spacing?: object
    componentStyle?: object
  }
  provenance: Record<string, Evidence>
  conflicts: ConflictCard[]
  repairs: RepairPlan[]
  coherenceScore?: number
}

처음에는 이 구조가 조금 번거롭게 느껴졌다. 그냥 이미지를 넣고 바로 코드를 생성하면 더 빠르지 않을까 싶었다. 하지만 진행할수록 이 중간 구조가 프로젝트의 핵심이라는 생각이 들었다.

IntentSpec이 있으면 “이 결과가 내 의도와 맞는가?”를 더 구체적으로 물을 수 있다.

• 색상은 의도한 팔레트를 썼는가?
• 타이포그래피 크기는 너무 작지 않은가?
• compact한 레이아웃인데 spacing이 과하게 넓지는 않은가?
• 생성된 코드가 원래 의도한 facet을 실제로 반영했는가?

AI가 만든 결과를 감으로 보는 것이 아니라, 비교하고 검토할 수 있는 대상으로 바꾸는 것이다.

AI가 할 일과 코드가 할 일

멘토링에서 받았던 피드백 중 하나는, 모든 것을 LLM에 맡기지 말고 결정론적으로 처리할 수 있는 것은 코드를 짜서 해결하는 게 더 낫다는 것이었다. 그래서 처음에는 LLM API가 모든 특성을 추출하도록 했지만, 토큰을 아끼고 시스템 안정성을 높이기 위해 특성별로 시스템을 바꾸었다. 색상 추출처럼 픽셀 기반으로 계산할 수 있는 것은 코드가 처리하는 반면, 이미지에서 레이아웃 분위기나 컴포넌트 스타일을 해석하는 일, 생성된 코드가 의도를 잘 반영했는지 audit하는 일은 AI를 사용한다. 마지막 React/Tailwind 코드 생성은 v0에 맡긴다. 이 구조를 만들면서 결국 AI가 잘하는 일과 사람이 기준을 세워야 하는 일을 분리해야 했고, 그렇게 했을 때 과정에서 무엇이 문제인지 추적할 수 있었고 결과적으로 결과물의 품질을 향상시키는 것도 도움이 되었다.

결국 중요한 건 나의 취향

멘토님이 특히 강조하셨던 건 '내 취향, 내 생각, 내 결정'이었다. 실제로 AI를 많이 쓸수록 이 말이 중요해졌다. AI는 내가 원하는 것을 알아서 잘 물어봐주지 않는다. 결과도 그럴듯하게 내놓기 때문에, 내가 대충 보면 그냥 넘어가게 된다. 결국 내가 무엇을 원하는지 모르면, AI가 만든 결과를 판단할 기준도 없어진다.

• 이 서비스의 핵심 목적은 무엇인가?
• 해당 목적을 가진 사용자는 디자이너인가, 프론트엔드 개발자인가, 아니면 빠르게 프로토타입을 만들고 싶은 사람인가?
• 결과물은 창의적인 시안이어야 하는가, 아니면 바로 붙여넣어 동작하는 코드여야 하는가?

이러한 질문에 답하는 과정에서 서비스의 방향성을 더욱 뾰족하게 만들 수 있었다.

AI 활용 범위

지금 프로젝트는 마무리 단계에 와 있다. 이제 각각의 기능이 의도한 대로 잘 움직이는지, 실제로 의도한 대로 reference를 잘 반영한 UI 디자인을 만드는지, 그럼에도 UI 디자인의 coherence나 심미성을 향상하기 위해서는 어떻게 해야할지를 검증해야 한다.

이러한 과정에서 AI의 도움을 받을 수 있을 것이라고 생각했다. '내가 직접 의도한 것'이 잘 작동하는지에 대한 기준을 내가 만들면, AI가 그것을 test를 통해 점수를 내고 iterative하게 수정하는 방식으로 지금까지 짠 코드를 리뷰할 예정이다.

마무리

이 프로젝트를 하면서 배운 것은 AI를 더 많이 쓰는 법이라기보다, AI가 만든 결과를 내가 이해하고 판단할 수 있게 만드는 법이었다.

AI는 빠르게 결과를 만든다. 하지만 그 결과가 내가 원한 것인지, 어떤 기준에서 좋은 것인지, 무엇을 고쳐야 하는지는 결국 내가 정해야 한다. 그래서 AI 시대에 더 중요해지는 것은 단순히 프롬프트를 잘 쓰는 능력이 아니라, 내가 원하는 것을 구조화하고, 판단 기준으로 바꾸고, 반복 가능한 검증 과정으로 만드는 능력인 것 같다.

결국 좋은 AI 활용은 내 일을 무작정 대신 시키는 것이 아니라, 내가 더 명확하게 결정할 수 있도록 돕는 구조를 만드는 일에 가까울 것이라고 생각한다.

The frontend class I took over the semester is coming to an end. For my final project, I created an interface called Style Print that helps extract visual style elements from reference images and generate new UI designs.

StylePrint is a project where you upload multiple UI reference images, extract design elements from each, and combine them to generate new React/Tailwind UI code. Each week, we received group mentoring from professional developers. Through this process, I realized that the important thing is not that AI produces results itself, but rather making AI-generated results comprehensible enough for me to evaluate them.

The Problem with Convincing Results

When AI creates UI, the results often look quite plausible. The colors fit reasonably well, the layout doesn’t look bad, and the Tailwind code works at first glance. But from the code alone, it’s hard to tell whether the colors used were what I intended, which parts of the reference it was taken from, whether accessibility standards were met, or if the code is reusable.

This is especially true when mixing multiple UI references in one project. For example, if colors come from reference 1, typography from 2, and layout from 3, it’s difficult to verify if the final combination was applied as intended just by looking at the output.

A Connecting Link Called IntentSpec

So in this project, instead of going directly from image to code, there’s an intermediate structure called IntentSpec. Design elements extracted from references are divided into facets like color, typography, layout, spacing, and component style, and it records which elements came from which references.

It looks roughly like this.

type IntentSpec = {
  chosen: {
    colorRefId?: string
    typographyRefId?: string
    layoutRefId?: string
    spacingRefId?: string
    componentStyleRefId?: string
  }
  normalized: {
    palette?: Record<string, string>
    typography?: object
    layout?: object
    spacing?: object
    componentStyle?: object
  }
  provenance: Record<string, Evidence>
  conflicts: ConflictCard[]
  repairs: RepairPlan[]
  coherenceScore?: number
}

At first, I felt this structure was a bit cumbersome. Wouldn’t it be faster to just input an image and generate code right away? But as the project progressed, I realized this intermediate structure was the core of the project.

With IntentSpec, you can ask more specific questions like "Does this result align with my intent?"

• Did it use the intended color palette?
• Is the typography size not too small?
• For a compact layout, is spacing not excessively wide?
• Did the generated code actually reflect the intended facets?

It turns AI outputs from something assessed by intuition into something that can be compared and reviewed concretely.

What AI Should Do vs. What Code Should Do

One piece of feedback from mentoring was not to delegate everything to the LLM; it’s better to code deterministic processes where possible. Initially, I had the LLM API extract all features, but to save tokens and improve system stability, I split the system by feature. For things like color extraction, which can be calculated pixel-wise, the code handles it. AI is used for interpreting layout mood or component style from images and auditing whether the generated code reflects the intent well. The final React/Tailwind code generation is handled by v0. Building this structure made clear what AI excels at and what requires human-set criteria. This separation also made it possible to track issues during the process and helped improve the quality of the results.

Ultimately, My Personal Preference Matters

A key point emphasized by my mentor was "My taste, my thoughts, my decisions." The more I used AI, the more this statement resonated. AI won’t necessarily ask the right questions for what I want. Because the results look plausible, I might overlook details. Ultimately, if I don’t know what I want, I have no standard to judge the AI’s output.

• What is the core purpose of this service?
• Is the target user a designer, frontend developer, or someone wanting to quickly prototype?
• Should the output be a creative mockup, or code ready to be copied and pasted and run immediately?

Answering these questions helped sharpen the direction of the service.

Scope of AI Utilization

The project is now in its final stages. Next, I need to verify whether each feature works as intended, whether the UI design indeed reflects the references as intended, and how to improve UI design coherence and aesthetics.

I believe AI can assist in this process. If I establish criteria for checking whether "what I intended" is functioning correctly, AI can evaluate the results through tests and iteratively suggest improvements, enabling code reviews of what I’ve built so far.

Conclusion

What I learned through this project is not just how to use AI more, but how to make AI-generated results understandable and evaluable by myself.

AI produces results quickly. But whether those results are what I wanted, what standards define good results, and what should be fixed — these are decisions I have to make. Therefore, in the AI era, more important than prompt-writing skills is the ability to structure what I want, turn it into evaluation criteria, and create repeatable validation processes.

Ultimately, good AI utilization is less about blindly delegating work and more about building frameworks that help me make clearer decisions.

JavaScript는 1995년, Brendan Eich가 단 10일 만에 만든 언어입니다. 당시 목적은 단순했습니다. 버튼 클릭 시 팝업을 띄우는 수준의 인터랙션을 웹페이지에 추가하는 것이었습니다.

문제는 웹이 예상보다 훨씬 빠르게, 훨씬 크게 성장했다는 점입니다. 2009년 Node.js가 등장하면서 JS는 서버까지 진출했고, Angular·React·Vue 같은 SPA 프레임워크가 폭발적으로 확산되면서 프론트엔드 코드 규모는 수십만 줄에 달하게 되었습니다. 그런데 JS는 여전히 "10일 스크립트 언어"의 설계를 그대로 유지하고 있었습니다.

function getUser(id) {
  // id가 숫자인지, 문자열인지, undefined인지 아무도 모릅니다
}

getUser()       // 그냥 실행됩니다
getUser("abc")  // 그냥 실행됩니다
getUser({})     // 그냥 실행됩니다 — 런타임에 터집니다 💀

결국 Microsoft가 2012년 해결책을 내놓았습니다. C#을 설계한 Anders Hejlsberg가 만든 TypeScript입니다. 핵심 철학은 단 하나였습니다.

"JS를 대체하지 않는다. JS에 타입만 얹는다."

2016년 Angular 2가 TypeScript를 공식 언어로 채택하면서 기업 프로젝트로 급속히 확산되었고, VS Code(그 자체가 TypeScript로 만들어진 에디터)가 업계 표준이 되면서 개발 경험의 차이가 눈에 띄게 벌어졌습니다. 오늘날 TypeScript는 Stack Overflow 개발자 설문에서 수년째 "가장 사랑받는 언어" 상위권을 차지하고 있습니다.

이 글에서는 JS를 이미 쓰고 있는 개발자를 위해, TypeScript의 핵심 문법을 실용적인 관점에서 소개해 보려고 합니다.

1. 타입 선언 기초: 변수와 함수에 타입 붙이기

TypeScript의 시작은 간단합니다. 변수와 함수에 타입을 명시하는 것입니다.

TypeScript 공식 문서에 따르면, TypeScript는 JavaScript의 모든 기능을 포함하며 그 위에 타입 시스템이라는 레이어를 추가합니다. 즉, 기존 JS 코드는 그대로 TS에서도 동작합니다.

// 변수 타입 선언
let username: string = "Alice";
let age: number = 30;
let isAdmin: boolean = false;

// 함수 파라미터와 반환 타입 선언
function greet(name: string): string {
  return `안녕하세요, ${name}님!`;
}

greet(123); // 컴파일 에러 — number는 string에 할당 불가
greet("Bob"); // 가능

JS였다면 greet(123)은 그냥 실행되어 "안녕하세요, 123님!"을 반환했을 것입니다. TS는 이 실수를 코드를 작성하는 순간 잡아냅니다.

타입 추론(Type Inference) 덕분에 항상 타입을 직접 적을 필요는 없습니다. 값을 바로 할당하면 TypeScript가 자동으로 타입을 파악합니다.

let count = 10; // TypeScript가 number로 추론합니다
count = "열";   // 컴파일 에러 — 이미 number로 확정됨

2. Interface와 Type: 객체의 모양 정의하기

실무에서는 단순한 원시 타입보다 객체를 다루는 경우가 훨씬 많습니다. TypeScript는 interface와 type 두 가지 방식으로 객체의 구조를 정의할 수 있습니다.

TypeScript 공식 문서는 복잡한 타입을 만드는 두 가지 대표적인 방법으로 인터페이스(Interfaces)와 타입(Types)을 소개하고 있습니다. 일반적으로 객체 구조에는 interface를 권장하며, 특수한 기능이 필요할 때만 type을 사용하도록 안내하고 있습니다.

// Interface로 객체 구조 정의
interface User {
  id: number;
  name: string;
  email: string;
  role?: string; // ? 는 선택적 속성 (없어도 됩니다)
}

function displayUser(user: User): void {
  console.log(`${user.name} (${user.email})`);
}

const alice: User = { id: 1, name: "Alice", email: "alice@example.com" };
displayUser(alice); // 가능

const broken = { id: 2, name: "Bob" }; // email 누락
displayUser(broken); // 컴파일 에러 — email 속성이 없습니다

type은 객체 외에도 유니온(Union) 타입 같은 복잡한 조합을 표현할 때 주로 사용합니다.

// Union 타입 — 여러 타입 중 하나를 허용합니다
type ID = number | string;

let userId: ID = 101;
userId = "user-abc"; // 둘 다 허용

// Literal 타입 — 특정 값만 허용합니다
type Status = "pending" | "approved" | "rejected";

function updateStatus(status: Status): void {
  console.log(`상태 변경: ${status}`);
}

updateStatus("approved");  // 
updateStatus("cancelled"); // 컴파일 에러 — 허용되지 않는 값

3. 제네릭(Generic): 타입을 파라미터처럼 다루기

제네릭은 처음에는 낯설게 느껴지지만, 한번 이해하면 TypeScript의 진가를 체감할 수 있는 기능입니다. 재사용 가능한 코드를 작성하면서도 타입 안정성을 유지하고 싶을 때 사용합니다.

예를 들어, API 응답을 처리하는 함수를 만든다고 가정해 보겠습니다.

// any를 쓰면 타입 안정성이 사라집니다
function fetchData(url: string): any {
  // ...
}

// Generic을 쓰면 반환 타입을 호출할 때 지정할 수 있습니다
async function fetchData<T>(url: string): Promise<T> {
  const response = await fetch(url);
  return response.json();
}

interface Post {
  id: number;
  title: string;
}

// 호출 시 타입을 지정합니다
const post = await fetchData<Post>("/api/post/1");
console.log(post.title); // 자동완성 + 타입 체크가 됩니다
console.log(post.author); // 컴파일 에러: Post에 author가 없습니다

<T>는 타입 파라미터입니다. 함수를 호출할 때 T 자리에 원하는 타입을 넣으면, TypeScript가 그 타입으로 함수 전체를 검사합니다. any를 쓰면 이 검사가 모두 무력화된다는 점에서, 제네릭은 any의 올바른 대안이라고 할 수 있습니다.

4. strictNullChecks: null과 undefined를 다루는 법

JavaScript에서 가장 흔한 에러 중 하나는 Cannot read properties of undefined입니다. TypeScript의 strictNullChecks 옵션은 이 문제를 컴파일 단계에서 차단합니다.

TypeScript 공식 문서에 따르면, strictNullChecks를 true로 설정하면 null과 undefined가 독립적인 타입으로 취급되어, 이를 일반 값처럼 사용할 경우 타입 에러가 발생합니다.

// strictNullChecks: true 설정 시

const users = ["Alice", "Bob", "Charlie"];
const found = users.find(u => u === "Dave"); // string | undefined

console.log(found.toUpperCase()); // found가 undefined일 수 있어 에러 발생

// 해결 방법 1: 옵셔널 체이닝
console.log(found?.toUpperCase()); // undefined면 그냥 undefined 반환

// 해결 방법 2: 타입 가드
if (found) {
  console.log(found.toUpperCase()); // 이 블록 안에서 found는 string
}

이처럼 TypeScript는 "이 값이 없을 수도 있다"는 사실을 코드 레벨에서 강제로 인지하게 만들고, 처리하도록 유도합니다. 런타임 에러가 아니라 작성 시점에 잡아주는 것입니다.

마무리

TypeScript는 JavaScript를 대체하는 새로운 언어가 아닙니다. JS 코드가 커지고 팀이 커질수록 발생하는 문제들을 해결하기 위한 도구입니다. 처음에는 타입을 하나하나 붙이는 게 번거롭게 느껴질 수 있습니다. 하지만 VS Code가 실시간으로 에러를 잡아주고, 자동완성이 정확해지고, 팀원의 코드가 자기 문서화되는 경험을 하고 나면, 타입 선언이 비용이 아니라 투자라는 것을 체감할 수 있습니다.

JavaScript was created in 1995 by Brendan Eich in just 10 days. The original goal was simple: to add basic interactivity to web pages, like popping up a message when a button is clicked.

The problem is that the web grew far faster and bigger than anyone expected. With the arrival of Node.js in 2009, JavaScript expanded to the server side, and SPA frameworks like Angular, React, and Vue exploded in popularity, increasing front-end codebases to hundreds of thousands of lines. Yet JavaScript’s design remained essentially that of "a 10-day scripting language."

function getUser(id) {
  // No one knows if id is a number, string, or undefined
}

getUser()       // runs fine
getUser("abc")  // runs fine
getUser({})     // runs fine — but crashes at runtime 💀

Eventually, Microsoft provided a solution in 2012: TypeScript, designed by Anders Hejlsberg, the creator of C#. Its core philosophy was simple.

"It doesn’t replace JS. It just adds types on top of JS."

When Angular 2 officially adopted TypeScript in 2016, it rapidly spread in enterprise projects. VS Code, built itself using TypeScript, became the industry-standard editor, making the difference in developer experience clear. Today, TypeScript consistently ranks among the "most loved languages" in Stack Overflow’s developer surveys.

This article aims to introduce the core TypeScript syntax from a practical perspective for developers already using JavaScript.

1. Basic Type Declarations: Adding Types to Variables and Functions

Getting started with TypeScript is simple: explicitly declare types on variables and functions.

According to the official TypeScript documentation, TypeScript includes all JavaScript features and adds a type system layer on top. Existing JS code runs unchanged in TS.

// Declaring variable types
let username: string = "Alice";
let age: number = 30;
let isAdmin: boolean = false;

// Declaring function parameter and return types
function greet(name: string): string {
  return `Hello, ${name}!`;
}

greet(123); // Compile error — number can't be assigned to string
greet("Bob"); // Valid

In plain JS, greet(123) would run and return "Hello, 123!". TS catches this mistake at coding time.

Type inference means you don’t always have to explicitly write types: TypeScript automatically infers a variable’s type when assigned.

let count = 10; // TypeScript infers number
count = "ten";   // Compile error — already inferred as number

2. Interface and Type: Defining Object Shapes

In real projects, you often deal with objects rather than simple primitives. TypeScript lets you define object structures using two main ways: interfaces and types.

The official TypeScript docs present interfaces and types as two primary ways to create complex types. Generally, interfaces are recommended for object shapes; types are reserved for special use cases.

// Define object structure with an interface
interface User {
  id: number;
  name: string;
  email: string;
  role?: string; // ? means optional property
}

function displayUser(user: User): void {
  console.log(`${user.name} (${user.email})`);
}

const alice: User = { id: 1, name: "Alice", email: "alice@example.com" };
displayUser(alice); // Valid

const broken = { id: 2, name: "Bob" }; // missing email
displayUser(broken); // Compile error — email property missing

Types are often used to represent complex combinations like unions beyond just objects.

// Union type — allows multiple types
type ID = number | string;

let userId: ID = 101;
userId = "user-abc"; // Both allowed

// Literal type — only specific values allowed
type Status = "pending" | "approved" | "rejected";

function updateStatus(status: Status): void {
  console.log(`Status changed to: ${status}`);
}

updateStatus("approved");  // Valid
updateStatus("cancelled"); // Compile error — not allowed

3. Generics: Treating Types Like Parameters

Generics may feel unfamiliar at first, but once understood, they reveal TypeScript’s true power: writing reusable code while maintaining type safety.

For example, imagine creating a function to handle API responses.

// Using any loses type safety
function fetchData(url: string): any {
  // ...
}

// Using Generics allows specifying return type at call time
async function fetchData<T>(url: string): Promise<T> {
  const response = await fetch(url);
  return response.json();
}

interface Post {
  id: number;
  title: string;
}

// Specify type when calling
const post = await fetchData<Post>("/api/post/1");
console.log(post.title); // Auto-complete + type checking
console.log(post.author); // Compile error: Post has no author

<T> is a type parameter. When calling the function, you provide the desired type for T, and TypeScript checks the entire function against it. Since using any disables this checking, generics are a robust alternative.

4. strictNullChecks: Handling null and undefined

One of the most common JavaScript errors is "Cannot read properties of undefined." TypeScript’s strictNullChecks option prevents this at compile time.

According to the official TypeScript documentation, setting strictNullChecks to true treats null and undefined as distinct types, causing errors if used like regular values.

// With strictNullChecks: true

const users = ["Alice", "Bob", "Charlie"];
const found = users.find(u => u === "Dave"); // string | undefined

console.log(found.toUpperCase()); // Error: found may be undefined

// Solution 1: Optional chaining
console.log(found?.toUpperCase()); // returns undefined if found is undefined

// Solution 2: Type guard
if (found) {
  console.log(found.toUpperCase()); // here, found is a string
}

TypeScript forces you to explicitly recognize and handle "this value might be absent," catching these issues during development instead of at runtime.

Conclusion

TypeScript is not a new language replacing JavaScript; it’s a tool designed to solve problems that arise as JS codebases and teams grow. Initially, adding types to every variable may seem tedious. But once you experience VS Code catching errors in real-time, enjoy precise auto-completion, and see your teammates’ code become self-documenting, you’ll realize type declarations are an investment, not a cost.

나는 인간-AI 상호작용(HCI) 분야를 연구하고 있는 문과 출신 대학원생이다. 전공자가 아니었기에, 개발에 관해 배운 건 학교 수업이 아니라 유튜브 강의, 블로그, AI와의 대화를 통해서였다. 대학원에 들어온 이후에는 연구를 하며 그때그때 필요한 것을 익히고 있다. 그렇게 독학하다 보니 뭔가 만들 수는 있는데, 내가 짠 코드가 잘 짠 코드인지, 표준적인 방식을 따르고 있는지 알 수 없었고, AI를 사용하며 이러한 의문은 심화되었다.

이에 학부생 권장 프론트엔드 수업을 듣기로 결심했다. HTML/CSS에서 시작해 JavaScript, 그리고 React까지 직접 짜보면서 프론트엔드 개발의 전체적인 구조를 이해할 수 있었고, 패러다임이 어떤 흐름으로 바뀌어왔는지를 몸으로 이해하고 싶었다.

수업 과정

수업 과제에서 가장 인상 깊었던 경험은 같은 서비스를 다른 방식으로 개발해보는 경험이었다. To-do 앱을 다른 문법으로 작성해보기도 하고, DB를 붙이며 프론트와 백엔드를 분리하기도 하였다. 

화면을 그리는 방법

첫 주는 JavaScript만으로 Todo 앱을 만들었다. 데이터는 배열 하나, UI는 DOM 조작으로 직접 그렸다.

function renderTodos() {
todoList.innerHTML = '';
todos.forEach(todo => {
const li = createTodoElement(todo);
todoList.appendChild(li);
});
}

할 일을 추가하면 배열에 넣고, 그다음 renderTodos()를 호출해 화면을 통째로 다시 그리도록 설계했다. 이 때, 데이터를 바꾸면 개발자가 직접 "이제 화면을 다시 그려라"고 명령해야 한다. 이 방식은 직관적이다. 하지만 한 가지 질문이 생겼다. 화면에 요소가 100개라면? 어떤 이벤트마다 어떤 요소를 다시 그려야 하는지 일일이 추적해야 한다. 앱이 커질수록 개발자가 챙겨야 할 것이 기하급수로 늘어난다. 일을 추가하면 배열에 넣고, 그다음 renderTodos()를 호출해 화면을 통째로 다시 그리도록 설계했다. 데이터를 바꿀 때마다 개발자가 직접 화면을 다시 그리라는 명령을 내려야 하는 방식이다. 직관적이긴 하지만, 앱의 규모가 커질수록 한계가 드러난다. 이벤트마다 어떤 요소를 갱신해야 하는지 일일이 추적해야 하고, 개발자가 챙겨야 할 것이 기하급수적으로 늘어난다.

데이터 저장

두 번째 Todo 앱에서는 Express 서버와 MongoDB를 연결했다. 이제 데이터는 브라우저 메모리가 아니라 데이터베이스에 저장된다. 새로고침해도 사라지지 않는다. 클라이언트는 더 이상 데이터를 직접 들고 있지 않고, 필요할 때 서버에 요청해서 받아온다.

export async function fetchTodos() {
    const res = await fetch(`${BASE_URL}/todos`);
    return res.json();
}

export async function createTodo(title) {
    const res = await fetch(`${BASE_URL}/todos`, {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify({ title, completed: false }),
    });
    return res.json();
}

컴포넌트 개념

React로 넘어오면서 에어비앤비 클론 코딩을 하게 되었다. 이 과정에서 UI를 독립적인 단위로 바라보는 컴포넌트 개념을 배웠다. 에어비앤비는 헤더, 검색창, 카드 목록처럼 역할이 구분되는 영역들로 이루어져 있었는데, React에서는 이 각각을 독립적인 컴포넌트로 분리한다.

<BrowserRouter>
    <Header onSearch={handleSearch} />
    <Routes>
        <Route path="/" element={<MainPage results={results} hasSearched={hasSearched} />} />
    </Routes>
</BrowserRouter>

HTML 태그처럼 쓸 수 있고, 필요한 데이터는 props로 전달한다. 각 컴포넌트는 자신에게 전달된 데이터에만 반응하기 때문에, 어떤 데이터가 바뀌었을 때 화면의 어느 부분이 바뀌는지 추적하기가 훨씬 쉬워진다.

상태 관리 방식도 달라졌다. 검색 결과를 useState로 선언해두면, setResults(data)를 호출하는 것만으로 관련 컴포넌트가 자동으로 다시 렌더링된다.

const [results, setResults] = useState([]);

const handleSearch = async ({ city, guests }) => {
    const data = await fetch(`/api/accommodates?${params}`).then(r => r.json());
    setResults(data);
};

AI와 기초 사이에서

수업 과제를 통해 기초를 다지는 과정에서 직접 불편한 문법을 겪어본 게 가장 기억에 남는다. 이전까지는 AI가 추천해준 최선의 프레임워크를 갖다 쓰기만 했었는데, 수동으로 DOM을 조작하는 것의 번거로움을 해결하기 위한 방안으로 React의 상태 관리가 존재하게 되었다는 것을 알게 되었다. 

AI는 훌륭한 도구다. 막히는 부분을 빠르게 풀어주고, 내가 생각지 못한 방향을 제안해주기도 한다. 하지만 AI가 내놓는 코드를 이해하려면 결국 기초 개념이 필요하다. 이 수업을 통해 앞으로 코드를 짤 때도 AI에게 코드를 물어보기 전에 먼저 '이 문제를 왜 이렇게 풀어야 하는가'를 스스로 설명해 보는 습관을 기르고자 한다. AI는 내가 이해한 것을 확장해주는 도구여야지, 이해를 대신해주는 도구가 되면 안 된다는 것을 의식하며 앞으로의 개발 지식을 학습하고 싶다.

I am a graduate student from the humanities research field of Human-AI Interaction (HCI). Since I am not a major in this area, I learned development not through school classes but via YouTube lectures, blogs, and conversations with AI. After starting graduate school, I have been learning what I need as I conduct research. Through self-study, I could make something, but I couldn't tell if my code was well-written or followed standard practices, and working with AI only intensified this doubt.

Therefore, I decided to take a recommended frontend course for undergraduates. Starting from HTML/CSS, through JavaScript, and then React, writing code myself helped me understand the overall structure of frontend development. I wanted to internalize how the paradigm has shifted over time.

Course Process

The most impressive experience in the assignments was developing the same service in different ways. For instance, writing a To-do app using different syntaxes and separating frontend and backend by connecting a database.

How the Screen is Rendered

In the first week, I built the Todo app using only JavaScript. Data was stored in a single array, and the UI was drawn directly through DOM manipulation.

function renderTodos() {
todoList.innerHTML = '';
todos.forEach(todo => {
const li = createTodoElement(todo);
todoList.appendChild(li);
});
}

When adding a task, it was appended to the array, and then renderTodos() was called to redraw the entire screen. At this point, whenever data changed, the developer had to manually command "now redraw the screen." This method is intuitive. But one question arose: what if there are 100 elements on the screen? For every event, you have to manually track which elements to redraw. As the app grows larger, the amount the developer needs to handle increases exponentially. Adding a task meant putting it into the array and then calling renderTodos() to redraw the entire screen. This approach requires the developer to explicitly command the screen to redraw every time the data changes. Although intuitive, its limitations become apparent as app size grows. For each event, you must track which elements to update, and the developer’s responsibilities increase exponentially.

Data Storage

In the second Todo app, I connected an Express server with MongoDB. Now, data is stored not in browser memory but in the database. It doesn’t disappear even after refreshing. The client no longer holds data directly but requests it from the server when needed.

export async function fetchTodos() {
    const res = await fetch(`${BASE_URL}/todos`);
    return res.json();
}

export async function createTodo(title) {
    const res = await fetch(`${BASE_URL}/todos`, {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify({ title, completed: false }),
    });
    return res.json();
}

Component Concept

Moving to React, I did clone coding of Airbnb. Through this, I learned the component concept, which views the UI as independent units. Airbnb consisted of distinct sections like headers, search bars, and card lists; React breaks each of these into independent components.

<BrowserRouter>
    <Header onSearch={handleSearch} />
    <Routes>
        <Route path="/" element={<MainPage results={results} hasSearched={hasSearched} />} />
    </Routes>
</BrowserRouter>

These can be used like HTML tags, and necessary data is passed via props. Each component reacts only to the data passed to it, so it becomes much easier to track which parts of the screen update when certain data changes.

The state management style also changed. If search results are declared with useState, calling setResults(data) automatically re-renders the related components.

const [results, setResults] = useState([]);

const handleSearch = async ({ city, guests }) => {
    const data = await fetch(`/api/accommodates?${params}`).then(r => r.json());
    setResults(data);
};

Between AI and Basics

What I remember most from building my basics through the course assignments was encountering inconvenient syntax firsthand. Until then, I had just used whatever AI-recommended best framework, but I came to understand that React’s state management exists to solve the hassle of manually manipulating the DOM.

AI is a terrific tool. It quickly solves blocks and suggests directions I might not have thought of. But to understand code generated by AI, fundamental concepts are ultimately necessary. Through this course, when I write code in the future, I want to cultivate the habit of first explaining to myself 'why this problem should be solved this way' before asking AI for code. I want to consciously learn development knowledge with the mindset that AI is a tool to expand what I understand, not to replace my understanding.

4월 중순, 제가 연구하는 분야 최대 국제 학술대회인 CHI(Conference on Human Factors in Computing Systems)에 참석하기 위해 스페인 바르셀로나에 다녀왔습니다. 저의 연구분야인 HCI(Human-Computer Interaction)는 사람과 기술이 어떻게 상호작용하는지를 탐구하는 학문으로, 공학·심리학·디자인 등 다양한 배경의 연구자들이 있는 융합 분야입니다. 최근 몇 년간은 AI와 사람이 어떻게 함께 일하고 소통할 수 있는지가 분야의 핵심 화두가 되고 있습니다. 제가 속한 연구실에서는 주로 LLM 기반 시스템을 직접 제작하고, 이를 실제 사람들에게 사용하도록 한 후 그 경험을 연구하는 user study 방식으로 연구를 진행하고 있습니다.

1. 다른 연구를 통한 아이데이션

CHI의 프로그램은 크게 세션, 워크숍/밋업, 포스터로 나뉩니다. 세션은 채택된 full paper를 저자가 직접 발표하는 자리고, 워크숍과 밋업은 특정 주제를 중심으로 소규모의 깊은 논의를 하는 자리입니다. 다른 연구자의 논문 발표를 들으며 제 연구에 대한 아이디어를 얻기도 하고, 유사한 연구에서 어떤 방법론을 택했는지 분석해 보기도 했습니다.

저는 주로 두 가지 주제에 초점을 맞춰 세션을 들었습니다. 요즘 관심 있게 연구하고 있는 멘탈 헬스 및 AI companion 분야, 그리고 새롭게 관심을 갖기 시작한 인터페이스 분야입니다. 그 중 가장 인상 깊었던 연구 중 하나는 GenAI 인터페이스 관련 세션에서 들었던 Texterial: A Text-as-Material Interaction Paradigm for LLM-Mediated Writing입니다. 텍스트 자체를 물질처럼 다루는 새로운 인터랙션 패러다임을 제안한 연구로, LLM 기반 글쓰기 환경에서 사용자가 텍스트를 물리적 재료처럼 자르고 붙이고 형태를 바꾸며 상호작용할 수 있는 방식을 focus group study를 통해 탐구했습니다. LLM 인터페이스의 패러다임이 단순 텍스트 입출력에서 햅틱, 모션, 현실 공간에서의 물리적 인터랙션으로 빠르게 확장되고 있다는 것을 느낄 수 있었습니다.

2. 예상과 달랐던 첫 발표 경험

저는 이번 학회에 포스터 발표자로 참석했습니다. '초기 경력자의 직장 스트레스 관리를 돕는 multi-agent LLM 챗봇'을 주제로 발표했는데, 학부 때 심리학을 전공한 것과 주변 직장인 친구들의 경험을 들은 것이 계기가 되어 연구 주제를 잡게 되었습니다.

포스터 발표는 넓은 연회장 같은 공간에 주제별로 포스터를 붙여두고, 관심 있는 사람이 다가오면 연구를 설명해주는 방식으로 진행됐습니다. 첫 발표라 여러 버전의 대본을 작성하고 연습해갔는데, 막상 현장에 가보니 대본을 외워간 게 거의 무의미했습니다. 상대방이 즉석에서 궁금한 것을 물어보고, 실시간으로 질문을 받으며 대화를 이어가는 구조였기 때문입니다. 덕분에 관심 분야가 비슷한 연구자들과 1:1로 깊게 이야기할 수 있는 기회가 되었습니다.

3. 네트워킹

CHI에는 학술 세션 외에도 비공식적인 교류의 자리가 많습니다. 그중 인상 깊었던 건 KAIST Night과 SNU Night이었습니다. KAIST Night은 초대권으로 외부인이 함께할 수 있는 자리였고, SNU Night은 서울대학교 내 HCI 연구실이 한자리에 모여 교류하는 형태로 진행되었습니다.

이틀 간의 네트워킹 파티에서 국내 연구자뿐 아니라 해외 연구실, 포닥, 네이버 AI 연구실 분들과도 교류할 수 있었습니다. 각자 어떤 연구를 하고 있는지, 연구실 분위기는 어떤지 같은 이야기부터 시작해서, 요즘 업계 트렌드나 커리어 방향에 정보 교류로 이어지기도 하였습니다. 특히 기억에 남았던 것은 주니어 연구자나 학생 입장에서 AI를 어떻게 활용해야 하는지에 대해 각자의 생각을 나눈 것이었습니다. AI에 의존하기보다 스스로 생각하는 힘을 키우는 것, 그리고 그게 결국 자신만의 경쟁력이 된다는 이야기가 특히 공감됐습니다. 

처음 발표자로 참석한 학회는 단순히 지식을 접하는 자리가 아니었습니다. 논문은 온라인으로도 읽을 수 있지만, 같은 주제를 고민하는 연구자들이 전 세계에 있다는 것과, 그 사람들과 직접 대화할 수 있다는 것이 생각보다 큰 힘이 되었습니다. 다음 번에는 세션 발표자로 참석하고 싶다는 생각을 하며 연구에 대한 동기부여를 많이 얻고 왔습니다. 무엇보다 사람을 위한, 실질적으로 현실에 적용 가능한 연구란 무엇인지에 대해 다양한 시각을 접할 수 있었고, 이를 앞으로의 연구에 녹여내고 싶다는 생각이 들었습니다.

In mid-April, I traveled to Barcelona, Spain, to attend CHI (Conference on Human Factors in Computing Systems), the largest international conference in my research field. My area of study, HCI (Human-Computer Interaction), explores how people and technology interact, and it is a multidisciplinary field that includes researchers from engineering, psychology, design, and more. In recent years, a central theme has been how AI and humans can work and communicate together. At my lab, we mainly develop LLM-based systems ourselves and conduct user studies that research the experiences of real users interacting with these systems.

1. Ideation through Other Research

The CHI program is broadly divided into sessions, workshops/meetups, and posters. Sessions are where authors present their accepted full papers, while workshops and meetups provide smaller, in-depth discussions on specific topics. Listening to presentations by other researchers gave me ideas for my own work and helped me analyze what methodologies similar studies employed.

I mainly focused on two themes during the sessions: the mental health and AI companion fields, which I have been interested in recently, and the interface field, which I’m beginning to explore. One particularly impressive study was Texterial: A Text-as-Material Interaction Paradigm for LLM-Mediated Writing, presented in the GenAI interface session. This research proposed a novel interaction paradigm treating text itself as a material, investigating through focus group studies how users can interact by cutting, pasting, and reshaping text like a physical substance within an LLM-based writing environment. It was clear that LLM interface paradigms are rapidly expanding from simple text input/output to haptics, motion, and physical interactions in real spaces.

2. A First Presentation Experience That Defied Expectations

I participated in this conference as a poster presenter. I presented on the topic of a multi-agent LLM chatbot designed to help early-career professionals manage workplace stress. The idea originated from my undergraduate background in psychology and from hearing about the experiences of friends working full-time.

The poster presentation took place in a large banquet hall-like space, where posters were displayed by topic and interested attendees could approach to discuss the research. Although I prepared and practiced multiple versions of a script for my first presentation, it turned out to be almost pointless once I was there. This was because interactions were conversational—attendees would ask spontaneous questions, and I would respond in real time, continuing the discussion on the spot. Thanks to this, I had the opportunity to engage in deep one-on-one discussions with researchers who shared similar interests.

3. Networking

Beyond academic sessions, CHI offers many informal opportunities for interaction. Among those, KAIST Night and SNU Night left a strong impression. KAIST Night was an event open to invited guests from outside, while SNU Night brought together HCI labs from Seoul National University to mingle and network.

During the two-day networking parties, I connected not only with domestic researchers but also with overseas labs, postdocs, and members from Naver AI research labs. Conversations ranged from research topics and lab cultures to current industry trends and career paths. One memorable discussion was sharing perspectives on how junior researchers and students should utilize AI. We agreed that rather than relying on AI, it is crucial to develop one’s own critical thinking skills, which ultimately become a unique competitive advantage.

Attending the conference as a first-time presenter was more than simply acquiring knowledge. Although papers can be read online, knowing that researchers worldwide are grappling with similar issues and being able to converse with them directly was unexpectedly empowering. I left highly motivated, with aspirations to present in a session next time. Above all, I was exposed to various perspectives on what it means to conduct research genuinely applicable to people and real-world settings, which I hope to integrate into my future work.

• 모델의 규모를 단순히 키우는 것만으로는 산술적 추론(arithmetic reasoning), 상식적 추론(commonsense reasoning), 기호적 추론(symbolic reasoning)과 같은 복잡한 논리적 문제를 해결하는 데 충분하지 않음
• 대형 언어 모델의 추론 능력을 활성화할 수 있는 간단한 방법을 탐구. 이 방법은 두 가지 핵심 아이디어에서 출발
  • 산술적 추론 기술은 최종 정답을 도출하는 과정에서 자연어 기반의 논리적 사고 과정(natural language rationales)을 생성하는 방식에서 이점을 얻을 수 있음
  • cf) 이전 연구에서는 모델이 자연어 기반의 중간 단계를 생성하도록 학습하는 방식을 제안한 바 있음. 예를 들어, 처음부터 모델을 학습하는 방법(Ling et al., 2017), 사전 학습된 모델을 미세 조정(fine-tuning)하는 방법(Cobbe et al., 2021), 자연어가 아닌 형식적 언어(formal language)를 활용하는 신경-기호적(neuro-symbolic) 접근 방식(Roy and Roth, 2015; Chiang and Chen, 2019; Amini et al., 2019; Chen et al., 2019) 등
  • → 논리적 사고 과정을 활용한 학습 및 미세 조정(fine-tuning) 방법은 고품질의 중간 추론 과정(reasoning rationales)을 생성하는 데 높은 비용이 듦. 일반적인 기계 학습에서 사용하는 간단한 입력-출력 데이터보다 훨씬 복잡
  • 대형 언어 모델은 프롬프팅을 통해 few-shot learning이 가능. 즉, 새로운 작업마다 별도의 모델 체크포인트를 미세 조정(fine-tuning)하는 대신, 몇 개의 입력-출력 예제(input-output exemplars)를 제공하는 프롬프팅(prompting) 방식을 사용할 수 있음
  • → 전통적인 Few-shot Prompting 방식(Brown et al., 2020)은 추론 능력이 필요한 작업에서는 효과가 미미하며, 모델 크기가 증가해도 성능 향상이 크지 않음(Rae et al., 2021)
• Chain-of-Thought Prompting(CoT)이라는 기법을 제안
  
  • CoT란 정답을 도출하기까지의 논리적 중간 단계(reasoning steps)를 자연어로 표현한 것을 의미
  • 언어 모델이 추론 작업(reasoning tasks)에서 Few-shot Prompting을 수행할 수 있도록 하는 방법을 연구하며, 입력과 함께 "Chain of Thought(CoT, 연쇄 사고 과정)"을 제공하는 방식을 탐색
  • 우리는 CoT 프롬프팅을 산술적 추론, 상식적 추론, 기호적 추론 벤치마크에서 평가하였으며, 실험 결과 CoT 프롬프팅이 기존의 표준 프롬프팅(Standard Prompting)보다 훨씬 높은 성능을 달성했음을 확인
  • 특히, 그림 2에서 보여주듯이 GSM8K(math word problem 벤치마크)에서 PaLM 540B 모델을 CoT 프롬프팅 방식으로 프롬프팅했을 때, 표준 프롬프팅보다 월등히 높은 성능을 기록하며, sota 성능을 달성
  • 프롬프팅 기반 접근법은 중요한 의미를 가짐
    • 별도의 대규모 학습 데이터셋 없이도 모델 성능을 향상시킬 수 있으며,
    • 단일 모델 체크포인트(single model checkpoint)로 다양한 작업을 수행할 수 있음
      

      

2. CoT

• CoT는 인간이 복잡한 문제를 해결하는 방식과 유사
• 문제를 중간 단계로 분해하고, 최종 답안을 내기 전에 각각을 해결
• 충분히 큰 언어 모델에 few-shot prompting의 예시로 CoT 추론을 적용하면 생각의 연쇄 생성

Chain-of-Thought Prompting의 장점

1. 복잡한 문제를 해결할 수 있음
   • 기존 Few-shot Prompting 방식으로는 해결하기 어려운 다단계 문제(multistep problem)를 해결하는 데 유리
   • 수학 문제, 논리적 추론, 기호적 조작(symbolic manipulation) 등의 문제에서 더 높은 성능을 발휘
2. 추론 과정이 해석 가능함 (Interpretability)
   • CoT 방식에서는 모델이 내놓은 답의 과정이 자연어로 표현되기 때문에 모델이 왜 그런 결론을 내렸는지 해석 가능
3. 작업에 대한 적응성 증가 (Generalizability)
   • CoT는 단순한 질의응답(QA) 문제뿐만 아니라, 다양한 상식적 추론, 수학 문제, 논리적 문제 해결 등 다양한 작업에 적용될 수 있음
4. 별도의 모델 학습 없이 즉시 사용 가능 (Zero-shot Learning 가능)
   • CoT는 별도의 모델 재학습(fine-tuning) 없이 사전 학습된 대형 언어 모델을 그대로 사용할 수 있음이 중요한 특징
   • 즉, 기존 모델을 변형하지 않고도 단순히 Prompting 방식을 바꾸는 것만으로 성능 향상 가능

3. Arithmetic Reasoning

3.1 실험 설계

본 연구에서는 Chain-of-Thought Prompting(CoT)이 산술적 추론(Arithmetic Reasoning) 문제에서 얼마나 효과적인지 평가하기 위해 여러 실험을 수행

사용된 벤치마크 데이터셋 (Math Word Problem Benchmarks):

1. GSM8K (Cobbe et al., 2021) - 초등학교 수준의 복잡한 수학 문제
2. SVAMP (Patel et al., 2021) - 다양한 구조의 수학 문제
3. ASDiv (Miao et al., 2020) - 광범위한 수학 문제
4. AQuA - 다단계 연산을 포함한 객관식 문제
5. MAWPS (Koncel-Kedziorski et al., 2016) - 기초적인 수학 문제

실험 방법:

• Standard Prompting: 기존 Few-shot Prompting 방식으로 질문과 정답만 포함
• Chain-of-Thought Prompting: 문제 해결 과정을 자연어로 설명하는 중간 논리 단계를 포함

사용된 언어 모델:

• GPT-3 (175B)
• LaMDA (137B)
• PaLM (540B)
• UL2 20B
• Codex (code-davinci-002)

모델은 Greedy Decoding 방식으로 답변을 생성하며, LaMDA 실험에서는 5개의 랜덤 샘플을 사용하여 평균 성능을 계산

3.2 실험 결과

핵심 결과:

1. CoT 프롬프팅은 모델 크기가 클수록 효과적으로 작동함
   • 작은 모델에서는 성능 향상이 크지 않음
   • 100B 이상 모델에서 CoT 사용 시 급격한 성능 향상
2. 복잡한 문제일수록 CoT의 성능 향상이 두드러짐
   • GSM8K (가장 어려운 문제) → CoT를 사용하면 기존 성능보다 2배 이상 향상
   • MAWPS (가장 쉬운 문제) → CoT의 영향이 크지 않음
3. CoT 프롬프팅을 적용한 PaLM 540B 모델이 GSM8K, SVAMP, MAWPS에서 새로운 SOTA(State-of-the-Art) 기록을 달성
   • 기존 GPT-3 및 Fine-tuned 모델을 능가하는 성능을 보임
4. 오답 분석:
   • CoT를 사용한 경우에도 일부 오류가 발생했으며, 오답 유형은 계산 실수, 논리적 오류, 기호 해석 오류 등으로 분류됨
     

     

3.3 제거 실험 (Ablation Study)

CoT의 효과가 단순히 더 많은 텍스트를 생성한 결과인지, 혹은 특정 요소가 핵심인지 확인하기 위해 여러 변형 실험을 수행하였다.

1. Equation-only Prompting (수식만 포함하는 프롬프팅)
   • 모델이 자연어 논리 과정 없이 수식만 생성하도록 유도
   • 결과: 큰 성능 향상 없음 → CoT의 핵심은 자연어 기반 논리 과정임을 확인
2. Variable Compute-only Prompting (계산량 증가 실험)
   • 모델이 단순히 더 많은 토큰을 생성하도록 유도
   • 결과: 성능 향상 없음 → CoT의 효과는 단순한 토큰 증가 때문이 아님
3. Reasoning-after-Answer Prompting (정답 후 논리 과정 추가)
   • 모델이 먼저 정답을 생성한 후, 나중에 논리적 사고 과정을 생성하도록 유도
   • 결과: 성능 향상 없음 → 논리적 사고 과정이 정답을 도출하기 전에 필요함을 입증
     

     

3.4 CoT의 견고성 (Robustness of CoT)

cf) robustness의 의미: CoT가 다양한 조건(데이터셋, 모델 크기, 논리적 사고 과정, 프롬프팅 예제 변형)에서도 일관되게 높은 성능을 유지할 수 있는지

CoT의 견고성을 평가하기 위해 다음과 같은 변수를 변경하여 실험을 수행

1. 다른 Annotator가 생성한 CoT 예제 사용
   • 여러 명의 연구자가 각기 다른 스타일로 CoT 예제를 작성
   • 결과: 어떤 Annotator가 작성해도 CoT는 표준 프롬프팅보다 높은 성능을 유지
2. 다양한 문제 예제 적용
   • GSM8K 훈련 세트에서 3개의 예제 세트를 무작위로 샘플링하여 CoT 수행
   • 결과: 예제가 달라져도 CoT의 효과는 일관되게 유지됨
3. Prompt 순서 변경
   • Few-shot 예제의 순서를 랜덤으로 바꾸어 실험
   • 결과: 순서가 달라져도 CoT 효과는 유지됨
4. Few-shot 예제 개수 변경
   • 8개에서 4개로 줄였을 때도 CoT 효과가 유지됨
   • 즉, 소수의 예제만으로도 CoT 효과가 강하게 나타남
     

     

4. Commonsense Reasoning

4.1 개요

• 상식적 추론(commonsense reasoning): Chain-of-Thought Prompting(CoT) 기법이 단순한 수학 문제뿐만 아니라 상식적 추론(Commonsense Reasoning) 문제에서도 효과적인지 평가
• 상식적 추론이란?
  • 인간이 일반적으로 알고 있는 일상적 지식과 논리를 바탕으로 문제를 해결하는 과정
  • 언어 모델이 단순한 패턴 학습이 아닌, 실제 논리적 사고 과정을 수행하는지 평가하기에 적절한 과제
• 연구 목표:
  • CoT를 활용하여 모델이 보다 논리적으로 상식적인 답변을 생성할 수 있는지 확인
  • 기존 Few-shot Prompting 방식과 비교하여 CoT의 성능 향상 여부 분석
  • 다양한 상식적 추론 벤치마크에서 CoT의 적용 가능성을 평가

4.2 실험 설정

1) 사용된 벤치마크 데이터셋

• CSQA (CommonsenseQA): 일반 상식 문제 해결 (Talmor et al., 2019)
• StrategyQA: 다단계 논리 추론 필요 (Geva et al., 2021)
• Date Understanding: 날짜 관련 개념 이해 및 계산
• Sports Understanding: 스포츠 관련 문장의 타당성 평가
• SayCan: 로봇 조작을 위한 명령 해석 (Ahn et al., 2022)

2) 실험 방법

• Standard Prompting (기존 방식): 질문과 정답만 포함
• Chain-of-Thought Prompting: 논리적 사고 과정 포함

3) CoT 예제 구성 방식

• CSQA, StrategyQA: 훈련 데이터에서 무작위 샘플링 후 CoT 생성
• Date Understanding, Sports Understanding: 벤치마크 평가 세트에서 몇 개의 샘플을 골라 CoT 적용
• SayCan: 로봇 제어를 위한 명령 해석을 포함한 CoT 생성

4.3 실험 결과

• 모델 크기가 커질수록 CoT의 효과가 커짐
• 모든 데이터셋에서 Standard Prompting보다 높은 성능을 보임
• CoT 적용 후 주요 성능 개선 사례:
  • StrategyQA: 기존 최고 성능(69.4%)을 75.6%로 개선 → 새로운 SOTA 달성
  • Sports Understanding: 인간 전문가(84%)보다 높은 95.4%의 성능 달성
• CoT가 특히 효과적인 데이터셋:
  • StrategyQA, Date Understanding: 다단계 추론이 필요한 문제에서 CoT의 성능 향상이 두드러짐
  • SayCan: 로봇 조작과 관련된 문제에서도 논리적 사고 과정이 중요한 역할을 함
    

    

4.4 결과 분석

1) CoT가 상식적 추론에서 효과적인 이유

• 단순한 패턴 학습을 넘어 논리적 사고를 유도
  • 기존 Few-shot Prompting 방식은 단순히 질문과 정답의 패턴을 학습하려는 경향이 있음
  • CoT는 모델이 실제 논리적 사고 과정을 수행하도록 유도하여 정답 예측 성능을 향상시킴
• 다단계 논리가 필요한 문제에서 큰 성능 향상
  • StrategyQA, Date Understanding 등 한 번의 추론으로 해결할 수 없는 문제에서 CoT의 성능 향상이 특히 두드러짐
  • 이는 CoT가 단순한 질문-답변 방식이 아닌, 논리적 추론 과정을 내재화하는 방식으로 동작함을 시사
• CoT는 상식적 판단을 강화하는 역할 수행
  • Sports Understanding 문제에서 CoT를 사용했을 때 "어떤 상황이 더 합리적인가?"를 고려하는 방식으로 응답이 개선됨
  • 예를 들어, 특정 선수의 이름이 등장할 때 그가 해당 스포츠에서 실제로 활동하는지 판단하는 데 도움을 줌

2) CoT의 한계점

• 문제의 복잡성이 낮을 경우 CoT의 효과가 미미함
  • CSQA(CommonsenseQA)처럼 단순한 상식 문항에서는 CoT가 성능 향상에 큰 영향을 미치지 않음
  • 이는 모델이 이미 상식적인 개념을 학습한 경우, CoT가 추가적인 이점을 제공하지 않을 수도 있음을 의미
• CoT의 논리적 흐름이 완벽하지 않음
  • 일부 문제에서는 CoT가 논리적 오류를 포함한 추론을 수행하여 오답을 생성하는 경우가 있음
  • 즉, CoT를 사용한다고 해서 항상 논리적으로 완벽한 답변이 생성되는 것은 아님

4.5 결론

1. CoT는 상식적 추론 문제에서도 효과적임
   • 특히 StrategyQA, Date Understanding, SayCan 같은 복잡한 논리적 사고가 필요한 문제에서 성능 향상이 큼
   • 기존 Standard Prompting보다 높은 정확도와 논리적 일관성을 유지
2. CoT는 단순한 패턴 학습이 아니라 실제 논리적 추론 능력을 강화함
   • 다단계 논리가 필요한 경우, 모델이 논리적 사고 과정을 자연스럽게 따르도록 유도
   • 기존 모델이 해결하기 어려웠던 문제에서도 효과적
3. 일부 단순한 문제에서는 CoT의 효과가 제한적일 수 있음
   • CSQA처럼 단순한 상식 문항에서는 큰 성능 차이를 보이지 않음
   • 즉, CoT의 효과는 문제의 복잡성에 따라 달라질 수 있음
4. CoT의 논리적 일관성을 보장하기 위한 추가 연구 필요
   • 일부 문제에서는 여전히 논리적 오류가 발생
   • CoT가 항상 정답을 도출하는 것은 아니며, 논리적 검증 기법과의 결합이 필요할 수 있음

5. Symbolic Reasoning

5.1 개요

• 기호적 추론(Symbolic Reasoning): 문자열 조작, 패턴 인식, 논리적 규칙 적용과 같은 문제를 포함하며, 일반적인 언어 모델이 해결하기 어려운 영역 중 하나
• 연구 목표:
  1. CoT가 기호적 추론 문제에서도 효과적인지 평가
  2. 기존 Few-shot Prompting과 비교하여 CoT의 성능 향상 여부 분석
  3. 기호적 조작(Symbolic Manipulation)이 필요한 다양한 문제에서 CoT의 적용 가능성을 검증

5.2 실험 설정

1) 사용된 기호적 추론 벤치마크 (Symbolic Reasoning Benchmarks)

다음 두 가지 대표적인 기호적 조작 문제를 실험 대상으로 선정

• Last Letter Concatenation: 여러 단어에서 마지막 글자를 추출해 연결하는 문제
• Coin Flip Tracking: 동전이 여러 번 뒤집혔을 때 최종 상태를 예측하는 문제

2) 실험 방법

• Standard Prompting (기존 방식): 질문과 정답만 포함
• Chain-of-Thought Prompting: 문제 해결 과정을 자연어로 설명하는 중간 논리 단계를 포함

5.3 실험 결과

1) CoT를 적용한 모델의 성능 향상

• Standard Prompting은 기호적 조작 문제에서 거의 작동하지 않음
• CoT를 적용하면 모델이 기호적 규칙을 학습하고 정답을 도출하는 데 도움을 줌
• CoT 적용 후 주요 성능 개선 사례:
  • Last Letter Concatenation 문제 → 기존 GPT-3의 10% 정확도가 CoT 사용 후 79%까지 상승
  • Coin Flip Tracking 문제 → 모델이 일련의 동전 뒤집기 과정을 추적하여 90% 이상의 정확도를 달성

2) 데이터셋별 성능 분석

➡ 결론: 기호적 조작이 필요한 문제에서 Standard Prompting은 거의 작동하지 않지만, CoT를 활용하면 모델이 논리적 사고를 통해 정답을 도출할 수 있음.

5.4 분석

CoT가 기호적 추론에서 효과적인 이유

1. CoT는 단계별 논리를 유도함으로써 모델이 패턴을 더 쉽게 인식하게 함
   • Standard Prompting은 단순한 문자 조작 패턴을 학습하려 하지만, CoT는 문제 해결의 논리적 과정을 포함하므로 모델이 더 정확하게 패턴을 학습할 수 있음
2. 단순한 기호적 조작이 아니라 논리적 사고를 강화함
   • CoT는 단순한 규칙 학습이 아니라, 모델이 연속적인 논리적 단계를 따라가도록 유도
   • 예를 들어, 동전 뒤집기 문제에서 CoT는 "처음 상태 → 뒤집기 연산 → 최종 상태"의 사고 과정을 명확하게 정리하여 모델이 올바르게 추론할 수 있도록 도움

5.5 CoT의 한계점

1. 긴 시퀀스의 문제에서는 여전히 한계가 있음
   • 동전이 100번 이상 뒤집히는 경우, CoT를 사용하더라도 모델이 모든 과정을 정확히 따라가지 못함
   • 즉, 연산량이 많아질수록 오류율이 증가
2. 기호적 추론 문제에서 완벽한 성능을 보장하지 않음
   • CoT가 기호적 조작 문제에서 큰 성능 향상을 보이지만, 규칙 기반(Symbolic Rules)을 직접 적용하는 방식보다는 여전히 낮은 성능을 보임
   • 따라서, 기호적 문제를 해결하기 위해서는 CoT만으로 충분하지 않을 수도 있음

참고 문헌

Jason Wei, Xuezhi Wang, Dale Schuurmans, Maarten Bosma, Brian Ichter, Fei Xia, Ed H. Chi, Quoc V. Le, and Denny Zhou. 2022. Chain-of-thought prompting elicits reasoning in large language models. In Proceedings of the 36th International Conference on Neural Information Processing Systems (NIPS '22). Curran Associates Inc., Red Hook, NY, USA, Article 1800, 24824–24837.

Abstract

• 상호작용 중 유저의 감정 상태(emotional state)를 예측하는 것은 감성 컴퓨팅(affective computing)의 주요 과제
• 한계: 전통적인 방식 감각 데이터(sensory data)에 의존하여 사용자의 내재적(latent) 인지 상태와 감정 반응 간의 상호작용(interplay) 때문에 한계
• 연구 방법: 상호작용 에피소드 동안 감정을 정적인 상태가 아닌 연속적인 과정(continuous process)으로 시뮬레이션하는 인지 컴퓨팅 모델 제안
  • 모델은 계산적 합리성(computational rationality)과인지-감정적 평가 메커니즘(cognitive-emotional appraisal mechanisms) 통합, 강화학습의 가치 예측(value predictions) 활용
• 연구 결과: 상호작용 중에 발생하는 행복(happiness), 지루함(boredom), 짜증(irritation)과 같은 감정의 발생을 예측하고 설명
• 연구 의의:
  • 이러한 접근 방식은 사용자 감정 상태에 적응하여 사용자 경험과 몰입도(engagement)를 향상시키는 상호작용 시스템 설계 가능성을 열어줌
  • 보상 처리(reward processing), 강화학습, 목표 지향적 행동(goal-directed behavior), 그리고 평가(appraisal) 간의 관계를 모델링하는 가능성을 심화

1. Introduction

• emotion의 중요성
  • 상호작용에 영향을 미침
  • 컴퓨터는 상대방의 감정을 이해, 예측하기 어려움
• emotion detection의 어려움
  • 심리 생리학적 시그널에 집중
  • 감정(emotion)과 인지(cognition)간 상호작용(interplay) 때문에 어려움
    • 인지 과정은 관찰 불가능
• 이 논문은 강화학습 모델을 이용하여 보상 체계(reward processing)과 평가 이론(appraisal theory) 통합 → 상호작용 중 감정을 동적으로 시뮬레이션하는 방법을 제시
  • cf) 평가 이론: 정서유발자극이 지각되면 → 먼저 그 상황에 대한 평가가 이루어지고 → 정서적 경험이 결정된다는 이론
    • 상황 자체가 아니라, 상황에 대한 개인의 평가에 따라 정서적 경험이 결정됨
    • 정서는 인지의 결과로 나타남, 평가는 개인과 외부환경 간의 관계를 나타냄
    • 

• 보상처리: 컴퓨터를 사용해 목표를 달성 ?
• 상호작용:
  • 컴퓨터를 이용한 문제 해결 과제
  • 의사결정 과정(Decision Process)
• 평가 결과: 가치 예측(Value Prediction) 업데이트
• 전반적인 실험 도식
  • 이 논문은 시간차 강화학습(Temporal Difference Reinforcement Learning)과 평가 이론(Appraisal Theory)에 기반한 감정 계산 모델 개발 및 평가
  • 이 모델은 보상 처리(Reward Processing)와 인지적 평가(Cognitive Appraisal)를 통합하여 사건에 대한 감정적 반응을 예측
  • 연구 방법:
    • 인간 참여자를 대상으로 한 작업 예시에서는 사용자가 컴퓨터를 사용해 목표를 달성하려고 시도
    • 문제를 여러 차례 성공적으로 해결하면 자신이 느끼는 행복감(self-evaluated feeling of happiness)이 증가하며, 이는 제안된 계산 모델에서도 동일하게 나타남
    • 상호작용은 의사결정 과정(Decision Process)으로 모델링되며, 상호작용 사건의 평가 결과가 가치 예측(Value Prediction) 업데이트로 이어짐
    • →감정의 평가 과정은 이러한 평가 중 수행되는 다양한 계산에 기반해 모델링

• 기대효과
  • 기존 연구의 문제: 모델들이 예상되는 결과를 최적화하기 위해 행동을 평가하고 선택할 수 있는 자율 에이전트의 시뮬레이션을 포함(incorporate)하지 않음
  • 감성 컴퓨팅(Affective Computing) 연구자들은 우리의 작업을 기존의 생리신호 모델에 통합함으로써 감정 탐지의 정확성을 향상할 수 있음
  • 사용자 감정에 대한 모델 기반 이해를 갖춘 기계는 시뮬레이션(in silico)을 통해 대안적인 행동 경로(alternative courses of action)를 모의 실행할 수 있으며, 원하는 감정적 결과를 달성할 가능성이 가장 높은 행동을 선택할 수 있음

2. Background

• 감성 컴퓨팅은 인간의 감정을 인식하고, 해석하며, 시뮬레이션하고 이에 반응할 수 있는 시스템을 개발하는 연구 분야
• 이 분야는 감정 및 사회적 신호(social signals)를 탐지하고, 인간-에이전트 상호작용의 다양한 측면을 모델링하며, 심리학적 이론에 기반한 감정 과정을 시뮬레이션하는 데 중점을 둠

• 평가 이론은 감정을 인지적-감정적 통합 과정으로 설명하며, 특정 상황이 감정적 반응을 어떻게 유발하는지 설명
• 이 이론의 핵심은 상황적 자극을 인지적으로 평가하는 과정으로, 감정은 평가의 결과물로 발생한다고 봄
• 대표적인 모델인 구성 요소 과정 모델(Component Process Model, CPM)은 상황적 자극을 평가하는 단계별 체크리스트(예: 새로움, 내재적 쾌적성, 목표 관련성, 대처 가능성)를 제공
• 이러한 평가 결과는 특정 감정(예: 행복, 분노)으로 연결. CPM은 이러한 과정을 정량적으로 공식화하여 계산적으로 구현할 수 있는 기반을 제공

• 감정 컴퓨팅 및 HCI에서 사용자 반응을 추정하고 예측하는 데 사용되어 시스템이 사용자의 행동을 적응시킬 수 있도록 함
• 본질적으로 보상 처리 모델링은 예상 보상에 따라 의사 결정을 이해하고 궁극적으로 시간이 지남에 따라 이러한 보상을 극대화하는 것을 목표로 함
• 작동 원리는 긍정적인 결과가 행동을강화하여 반복을 장려한다는 것
• 한계
  • 종종 에이전트가 보상을 위해 순전히 행동한다고 가정하여 동기를 지나치게 단순화하고 인지 처리 또는 행동 제약과 같은 측면을 간과
  • 게다가 감정의 보상 처리 모델과 인간 감정의 현실적인 모델 사이에는 여전히 상당한 차이가 있음

• 인간을 정보, 계산 리소스 및 예상결과 유틸리티가 부과하는 경계 내에서 의사 결정 및 행동이 최적화된 에이전트로 모델링할 수 있다고 가정
• 감정의 보상 처리 모델과의 관련성:
  • 계산적 합리성 모델링에 서 RL은 제한된 최적 행동 정책을 도출하는 데 사용
  • HCI에서 계산 합리성의 핵심은 시뮬레이션된 사용자의 목표를 보상 함수로 구현하는 것
• 한계 존재

3. Modeling

• S: A가 나타내는 state
• A: agent가 취할 수 있는 action
• T: transition function; a 액션을 취했을 때 상태 s에서 s’로 바뀔 확률
• R: 상태 s에서 s’로 바뀔 때 agent가 받는 즉각적인 reward
• $𝛾$: discount factor: 행동의 가치를 계산할 때 미래 보상을 할인
• MDP로 설명된 순차적 의사결정 작업의 장기 보상을 최대화하기 위
  해 RL 에이전트는 환경과 상호 작용하여 상태 전환 확률과 보상 함수
  인코딩
• RL의 과제는 최적의 정책을 도출하는 것
• 상태를 동작 확률에 매핑하여 그에 따른 동작이 예상 누적 보상을 최대화
  하도록 함
• value function
• 
• form of TD learning called Q-learning
• 

• 급작성(Suddenness): 평가 동안 사건이 얼마나 새로웠는지, 상태 전환이 예상 가능했는지
• 목표 관련성(Goal Relevance): 현재 에이전트와 목표가 얼마나 연관되어있는지
• 유익성(Conduciveness): 특정 사건이 에이전트의 목표 달성을 돕는지를 평가
  • 값이 0이면 해당 사건은 매우 비유익함(highly unconducive)
  • 값이 1이면 매우 유익함(very conducive)
  • 값이 0.5이면 기대에 부합하는 중립적 사건(neutral event)
• 통제력(Power): 얼마나 agent가 사건의 결과에 영향을 미치는지

• SVM(Support Vector Machine)을 사용하여 계산된 평가 값을 감정 레이블로 분류
• 해당 논문의 목표는 classifier에서 인간의 성능을 근사하는 것
• 
• 인간의 감정 식별 정확도를 분석
  • 분류기의 정밀도는 인간의 성능과 거의 일치
  • parameter c는 모델의 예측 오류를 최소화하기 위해 인간의 감정 평가에 대해 조정된 것이 아니라 인간 데이터에서 발견되는 것과 동일한 평가 정밀도 수준으로 조정
  • c 값이너무 크면 가장 강렬한 감정만 예측되며, 값을 낮추면 모델은 다른 덜 강렬한 감정도 예측
• classifier를 사용하면 계산 평가 모델은 다양한 평가에 대한 방정식을 통해 RL 에이전트의 값 계산에서 감정 단어를 예측할 수 있음

• 단일 순간의 감정 상태 대신, 상호작용 중 발생하는 연속적인 감정 변화를 반영하기 위해 이동 평균(Moving Average)을 사용

4. Evaluation

• 실험 초점: 행복(happiness), 지루함(boredom), 짜증(irritation) 세 가지 감정을 유도하는 과제를 설계하고 사용자 감정 데이터를 수집
• ↔ 과거: vignette-based method
• 실험 과제 설계: 평가 이론(Appraisal Theory)의 원칙에서 도출되었으며, 목표 감정에 해당하는 평가 프로파일을 반영(예: Table 1 참고).
  • 행복 과제: 낮은 급작성(low-suddenness)과 높은 목표 유익성(high goal-conduciveness)을 특징으로 함
  • 짜증 과제: 목표에 방해가 되는(goal-obstructive) 사건이 포함되며, 참여자가 일부 통제력을 가질 수 있도록 설계됨
• 실험 구성:
  • 첫 번째 실험: 단일 평가(single-appraisal) 모델을 실제 감정 경험 데이터와 비교하여 테스트
  • 두 번째 실험: 감정을 시간적으로 더 긴 연속(sequence)에서 평균화하는 아이디어를 테스트
• 평가 척도: 자기 보고식 감정 강도 척도를 사용하여 데이터를 표준화하고 분석

• 각 실험에 대해 3개씩, 총 6개의 온라인 과제 구성
• 자료는 위키피디아에서 가져온 영어 텍스트 단락(약 220단어)이었고, 참가자들은 텍스트에 대한 질문에 답해야 함
• 동일한 소스 텍스트에서 여러 질문이 설계 됨
• 과제 내용
  • 행복 과제: 질문은 의미 있었고, 정답은 긍정적인 피드백으로 이어졌으며, 결국참가자는 좋은 성과를 축하하는 메시지를 받음(그림 2a).
  • 지루함 과제: 단조롭고 간단한 질문이 많았고, 개별 과제와 실험의 끝에 의도적으로 중립적인 피드백을 제공(그림 2b).
  • 짜증 과제: 여러 시스템 오류를 통합하여 사용자의 결정과 관계없이 잘못된 선택을 하게 했고, 결국 과제 실패와 부정적인 피드백으로 이어짐(그림 2c)
• 그림2
• 

• 첫 번째 실험: 각 과제당 9명씩, 총 27명의 참가자 모집, 평균 연령 34세, 7명의 남성과 20명의 여성으로 구성
• 두 번째 실험: 각 과제당 15명씩, 총 45명의 참가자 모집, 평균 연령 29세=7.3, 남자 15명, 여자 30명

• 목표: 단일 평가(single-appraisal) 모델의 감정 예측 정확성을 실제 사용자 데이터를 기반으로 테스트
• 평가 방법
  • 각 과제 후 참가자들에게 자신의 감정(행복, 지루함, 짜증 등)을 0에서 10까지의 척도로 보고하도록 요청
  • 모델은 마르코프 결정 과정(Markov Decision Process, MDP)으로 설계된 환경에서 강화학습 에이전트를 사용하여 동일한 과제를 수행
  • 모델이 생성한 감정 예측 값과 인간 참가자의 보고 값을 비교
• 결과
  • 모델은 인간 참가자 데이터와 유사한 감정 프로파일을 생성
  • 각 과제에서 목표 감정(행복, 지루함, 짜증)의 강도가 가장 높게 나타났으며, 예측 정확도는 RMSE = 0.13로 측정됨
  • 이는 단일 평가 모델이 실험에서 유발된 감정을 성공적으로 예측할 수 있음을 보여줌
  • 

• 목표: 감정을 단일 시점에서 측정하는 대신, 상호작용 중 시간에 따라 감정이 어떻게 변화하는지를 모델링
• 실험 설계
  • 첫 번째 실험과 동일한 세 가지 과제를 사용하되, 감정 데이터를 여러 시간 단계에서 수집.
    • 참가자는 실험 초반, 중간 두 번, 그리고 종료 시 총 네 번 감정 강도를 보고.
  • MDP 모델은 각 과제에 대해 세 가지 주요 단계로 확장되어 시간적 변화 요소를 반영
• 평가 방법
  • 모델은 이동 평균(Simple Moving Average, SMA)을 사용하여 감정이 시간이 지남에 따라 누적되거나 감소하는 과정을 반영
  • 모델 초기 상태는 인간 참가자의 초기 감정 보고 데이터를 기반으로 설정
  • 각 시간 단계에서 모델의 예측 값과 인간 데이터 간의 일치를 분석
• 결과: 모델은 감정의 시간적 변화를 잘 예측했으며, 전체적인 데이터 적합도는 R² = 0.86, RMSE = 0.19로 나타남
  • 지루함 과제:
    • 지루함은 시간이 지남에 따라 증가했으나 일부 참가자들이 짜증을 보고하기도 함
    • 이는 단조로운 과제가 예상 외로 짜증을 유발했기 때문으로 분석됨
    • 

5. Discussion and Conclusion

• 기여: 제안된 모델은 사용자 감정을 효과적으로 예측할 뿐만 아니라 상호작용 중 감정 변화를 설명할 수 있음
• 한계: 제한된 감정 범위와 단순한 과제 디자인. 향후 연구에서는 더 다양한 감정과 복잡한 상호작용을 포함해야 함
• 응용 가능성: 사용자 감정을 예측하고 적응하는 지능형 상호작용 시스템 설계에 활용 가능