배운 것을 정리합니다.

주제 선정 AI@Sogang에서 프로젝트 팀빌딩을 위해 여러 주제를 둘러보던 중, 가장 흥미로워 보이는 주제를 골랐다. Vision처리와 action, 그리고 RAG로 에이전트를 개선한다고? 물론 Vision 관련 프로젝트 경험도 없었고, 시뮬레이션 경험도 없었지만 공부한다는 마음으로 시작해보았다. 우리의 초기 가설과 목표는 다음과 같았다. “RAG 를 기억장치로 활용해서 성공-실패 패턴을 저장하면, 파인튜닝 없이도 에이전트를 개선할 수 있지 않을까?” 전체 흐름 1. 초반: 플랫폼과 문제 정의를 정하자 1주차에는 Habitat와 AI2-THOR를 비교한 뒤, 객체 조작 중심 실험에는 AI2-THOR가 더 적합하다는 결론을 내렸다. 동시에 ALFRED benchmark를 핵심 과제로 보고, planner-executor 구조와 long-term memory 가능성을 조사했다. 이 시기에는 Planner, Executor, Verifier, Memory/RAG 모듈이 분리된 형태의 아키텍처를 많이 상상했고, "메타데이터를 최대한 덜 쓰면서도 agent가 과거 관찰을 기억하게 만들 수 있을까"가 중요한 질문이었다. 2주차와 3주차에는 EPO, RoboGPT, SCOUT, RLEF, CAPEAM 같은 선행 연구를 조사하면서, 단순히 논문을 읽는 수준을 넘어서 우리 구조에 무엇을 가져올 수 있을지를 계속 비교했다. 이 과정에서 팀의 관심사는 크게 세 가지로 모였다. subgoal을 계층적으로 나눌 것인가 현재 시점에서 greedy하게 행동할 것인가? 아니면 Plan 후 따를 것인가. RAG를 장기기억으로 둘 것인가, 혹은 episode 내부 메모리처럼 쓸 것인가 특히 EPO의 planner/controller 분리, RoboGPT의 semantic map, SCOUT의 spatial map, RLEF의 reward 관점은 이후 논의의 기준점이 됐다. 2. 중반: 무엇을 학습할지보다 무엇을 기억할지를 정하자 4주차와 5주차쯤부터는 DPO나 reward model 같은 학습 방법론 자체보다, RAG에 어떤 형태의 정보를 저장해야 실제로 agent가 덜 헤매는지가 더 중요한 문제라는 공감대가 생겼다. 성공/실패 trajectory 전체를 넣을지, 부분 성공을 넣을지, 공간 정보만 저장할지, 상호작용 정보까지 저장할지 계속 논의했다.

이번 학기에 서강대학교 안에서 AI 를 깊게 공부하고 프로젝트를 할 수 있는 학회를 만들었다. 설립 멤버로 학회원들의 리크루팅(다른 사람을 평가할 실력은 전혀 아니지만)부터 홍보 행사 기획까지 참여했다. 학회의 첫 공식 활동은 Trocho Study. 네트워킹 자리를 마련해 학회원 들간의 관심 분야를 공유하고, 마음이 맞는 사람들끼리 모여 두달간 스터디를 진행한다. 나는 오디오 AI 분야 스터디에 들어갔다. 선정한 이유는 다음과 같았다. 한 분야의 논문들을 모아보면서 깊게 공부해봐야겠다고 생각했다. 함께하는 멤버들이 학부연구생들이 많아, 논문을 어떻게 읽는지 배울 수 있을 것 같았다. 작년 K-Startup 챌린지에서 수상한 아이템도 오디오 분야였고, 그 당시 학교의 음성분야를 하시는 교수님도 찾아간 적이 있었다. 서비스에 집중하느라 소홀했던 기술을 더 자세히 알아보고 싶었다. 논문 읽는거 생각보다 어려웠고, 이해하지 못하는 내용이 더 많았다. 수식을 하나하나 이해하려고 노력하다보면 시간을 너무 많이 잡아먹었다. 서베이조차 다 못 읽고 스터디 간 날도 있었고 발표자료 준비를 못한 날도 있었다. AI를 사용해서 논문 읽기의 난이도를 조금이나마 낮췄다. NotebookLM 으로 논문들을 컨텍스트로 추가하고 먼저 팟캐스트를 만들어 들으면서 쉬운 수준에서 이해했다. 그 다음엔 AI가 생성한 다이어그램과 정리된 문서를 기반으로 방법론들을 구체적으로 확인하고, 문라이트를 이용하여 논문을 읽었다. 주차별 서기록을 기반으로 7주간 스터디에서 다루었던 내용들을 정리해보았다. 1주차: Audio Representation & Synthesis 오디오 딥러닝의 기초가 되는 데이터 표현 방식과 생성 모델의 원리를 학습했다. Data Representation: 오디오 데이터는 Raw Audio(Waveform), Spectrogram(STFT, CQT), Acoustic Feature(MFCC, Pitch), Embedding(Wav2Vec) 등 다양한 형태로 표현되며, 목적에 따라 적절한 표현형을 선택해야 한다.

1장 객체 설계 5장 책임할당하기 5.3 구현을 통한 검증. 코드로 적어보니 다음과 같은 개선 사항이 존재한다. DiscountCondition은 3가지 이유로 변경될수 있다. 새로운 할인조건 추가로 인한 isSatisfiedBy 메소드의 조건 추가 isSatisfiedBySequence의 로직 변경 isSatistfiedByPeriod의 로직 변경 하나의 클래스가 여러가지 변경이유를 가진다는 것은 단일 책임의 원칙(SRP)의 위배되며 높은응집도를 달성하지 못했다고 볼수 있다. 그러므로 변경의 이유에 따라 클래스를 분리하자. 변경의 이유를 쉽게 파악하기 꿀팁! 인스턴스 변수의 초기화 시점이 다른 부분을 분리의 후보로 잡아보자. 인스턴스 변수 사용의 방식을 살펴보자. 모든 속성을 다 사용하면 응집도가 높은거다! 이렇게 나눈다면 PeriodCondition과 SequenceCondition두개의 클래스가 나뉘지만, Movie는 두가지 클래스와 협력해야한다. 이건 전체적인 결합도도 높아지고(Movie가 Condition 1개에서 각각의 2개로 결합이 늘어남),변경이 더 어려워져서(새로운 할인조건 추가시 List 인스턴스 추가해야하고 판별 메서드도 추가해야함) 설계 품질이 나빠진거다. Movie 입장에서는 두 클래스 모두 같은 책임을 수행한다. 구현방식의 차이일 뿐이므로 ‘역할’이 등장한다. 자바에서는 이를 구현하기위해 추상클래스(구현을 공유)와 인터페이스(책임만 정의)를 사용한다. POLYMORPHISM 패턴 객체에 타입에 따라 변하는 로직이 있다면 조건문보다는 다형성을 이용하자. PROTECTED VARIATIONS 패턴 변경될 가능성이 높다면 캡슐화해서 예측가능한 안정적인 인터페이스 뒤로 숨기자.

문제발생 데이터 정규화를 너무 잘지켜서 엔티티를 만들다보면 join이 많이 필요해지는건 당연하다. 그만큼 필요한 정보의 분리가 잘 일어났다는 뜻이고, 데이터의 중복과 정합성이 보장된다는 뜻이니까. 그런데 JPA에서는 지연로딩 때문에 연관관계에 부담을 느끼게 된다. 같은 작업 프로세스 내에서 조회가 확정된 연관관계가 지연로딩 상태라면 추가적인 쿼리가 발생할 것이 뻔하기 때문이다. 보통의 경우에는 여러가지 해결법이 있지만 이번에 만들게 된 유사 설문조사 도메인에서는 1:N이 연쇄적으로 그리고 동시에 여러개를 한번에 조회해야하는 문제를 경험했다. 엔티티 연관관계 가정으로 최상단이 1 이 하나에 N개가 붙어있고 각각 M개가 붙어있고, 또 각각 K개가 붙어있다고 가정해보자. sol1: 추가쿼리? 상관없어 최상단 엔티티 조회후 그냥 원하는 엔티티 마음껏 조회. 이러면 모든 연관관계마다 추가쿼리가 나가게 된다. 가장 최악인것 같다. 이러면 NxMxK개 쿼리다. sol2: 상남자는 LAZY 보다는 EAGER지. 이런 방법도 있다. 지연로딩 대신 즉시로딩을 사용하게 된다면 프록시를 사용하지 않고 바로 연관된 모든 데이터를 가져오기 때문에 추가쿼리가 발생할 염려가 없다. fetch - FetchType (defaults to EAGER) Defines whether this attribute should be fetched eagerly or lazily. EAGER indicates that the value will be fetched as part of loading the owner. LAZY values are fetched only when the value is accessed. Jakarta Persistence requires providers to support EAGER, while support for LAZY is optional meaning that a provider is free to not support it. Hibernate supports lazy loading of basic values as long as you are using its bytecode enhancementsupport.

attr가 뭐야 By default, everything in $attrs will be automatically inherited on the component's root element if there is only a single root element. This behavior is disabled if the component has multiple root nodes, and can be explicitly disabled with the inheritAttrs option. attr는 props나 emit으로 미쳐 받지 못한 속성들을 모두 잡아준다. 명시적으로 모두 정의하기 어려운 속성들을 가져오거나, 다시 자신의 자식에게 드릴링 할때 유용하다. 커스텀 inut을 만들었는데, input태그에 여러 속성들을 추가하고 싶은데 모두 props로 명시적으로 정의하기는 귀찮다. 그럴때 attrs로 남은 속성 다 받아와서 input에 v-bind로 동적으로 HTML속성을 추가해주면 된다. falltrhough attributes Fallthrough Attributes에 대해 조금더 알아보자. 부모에서 컴포넌트를 선언하며 추가한 속성들 중 props,emits로 잡지 않은 모든게 들어있다. style, class도 들어온다. inheritAttrs 를 따로 설정하지 않는다면, Fallthrough Attributes는 해당컴포넌트의 루트노드로 자동으로 바인딩 된다. class와 style의 경우, 이미 존재한다면 자동으로 merge된다. 이벤트가 이미 있는 경우, 기존이벤트, Fallthrough Attributes로 자동 바인딩 된 이벤트 모두 실행된다. 중첩된 컴포넌트에서도 잘 전달된다. 만약 루트 엘리먼트가 여러개인 경우, 오류가 발생한다. 이 경우 $attrs 로 바인딩 할 엘리먼트를 정해주거나, inheritAttrs 를 false로 설정 후 useAttrs() 로 받아오고 사용하면 된다. 웬만해서는 반응형이 유지된다. 참고 : https://vuejs.org/guide/components/attrs.html

목표 자식스코프에서 slot에 많은 사항을 접근하기. <slot>에 가변적으로 엘리먼트를 추가. 자식컴포넌트에서는 각각의 엘리먼트의 validation함수를 수행 후 경고 또는 safe 표현 <slot>에 있는 각각의 데이터를 수집가능해야함. vue slot vue slot 자식 스코프 접근 다행히도 vue에서는 자식 스코프의 변수에 접근할 수 있는 기능이 있다. 찾아보니 반응성도 유지되고 수정도 가능한 값이라고 한다. 1차목표 : 데이터 모으기 custom form을 만드려는 첫번째 이유인 데이터 모으기는 성공했다. form 컴포넌트에 반응형 배열을 하나 만들고, v-slot으로 부모로 넘긴다음, 각각의 input에 v-model로 매핑해준다. 그러면 input에서 변한 값은 부모 스코프의 변수가 아니라 form 스코프에서 관리할 수 있다. 2차목표 : validation도 한군데서 사실 데이터를 한곳에 모은 이유가 validation을 한곳에서 하기위해서였다. 가장 먼저 생각이 난 방법은 form 컴포넌트에 props로 validation함수배열을 넘겨주고, 순서대로 하나씩 하는거였다. 장점 : 구현이 간단하다. (데이터가 form에 모여있어서 validation함수에서 사용하기 편하다.) 단점 : validation함수가 부모컴포넌트에 있어야한다. 순서를 실수하면 안된다. 각각의 input을 분리 아니면 각각의 input태그들을 내용과 validation로직이 함께 있는 컴포넌트를 만들고, 그걸 모아놓은 form태그에서 일괄적으로 validation을 실행시킬 수 있으면 어떨까? 이게 가능하려면 부모컴포넌트에서 자식 컴포넌트의 메서드를 실행시킬 수 있어야한다. script setup방식에서는 expose를 이용해서 외부에 노출시킬 변수와 메서드를 선언하고, 해당 컴포넌트ref.value로 그 값에 접근 할 수 있다. 이상 부모에서 customForm을 사용하는 방법을 조금 더 간소화 시켜보면 어떨까. 직접 ref연결하고 data 매핑하는 과정이 너무 귀찮다. 그냥 customForm 컴포넌트에서 자신에게 들어온 slot들의 정보를 불러와서, 각각의 customInput에 대해 script setup부에 정의된 ref랑 validation 메소드를 가져와서 실행시키면 정말 좋을 것 같다.

computed란 무엇인가 어떤 데이터에 반응하는가 [의존성] 어떤 데이터를 반응시키는가 [다시 렌더링 되는 범위] 그냥 ref와의 차이점 computed 사용시 주의점 setter를 이용한 computed란 computed 속성은 템플릿의 데이터 표현을 더 직관적이고 간결하게 도와주는 속성이다. 사용법 인자는 계산결과를 리턴해주고 매개변수가 없는 콜백함수 한개이다. 리턴된 값은 vue 반응형으로 감싸졌기 때문에 x.value()처럼 value() 메소드를 이용해서 값에 접근할 수 있다. 특징 반응형 계산: computed 속성은 의존하는 반응형 데이터가 변경될 때 자동으로 다시 계산된다. 캐싱: computed 속성은 그 결과값을 캐싱한다. 의존하는 데이터가 변경되지 않으면, computed 속성은 이전에 계산된 값을 재사용하여 성능을 향상시킨다. 선언적 접근: computed 속성을 사용하면 복잡한 로직을 간결하고 선언적인 방식으로 표현할 수 있습니다. 이는 코드의 가독성과 유지보수성을 높인다. 반환값: computed 속성은 항상 값을 반환해야 합니다. 이 반환값은 템플릿이나 다른 반응형 속성에서 사용될 수 있다. 함수 형태: computed 속성은 함수로 정의된다. 이 함수는 반응형 데이터를 기반으로 계산을 수행하고 결과를 반환한다. 의존하는 반응형 데이터의 범위 여기서 "의존하는 반응형 데이터" 가 어디까지를 포함하는지 알아보자. Reactive References (ref): ref 함수로 생성된 반응형 참조 변수들입니다. 이들은 .value 속성을 통해 접근되며, 이 속성의 값이 변경될 때 자동으로 업데이트를 트리거합니다. Reactive Objects (reactive): reactive 함수를 통해 생성된 반응형 객체들입니다. 이 객체들의 속성이 변경되면 자동으로 업데이트가 일어납니다.

문제상황 유지보수 중 새로 수정한 코드에서 다음과 같은 문제가 생겼다. <select>태그에서 연도를 고르고, 검색을 누르면 검색은 되는데 매 요청마다 <select>태그의 선택된 값은 기본값을 보고 있다. 요약하자면 <select>태그의 selected 옵션을 정확히 지정하지 못하는 문제이다. 내가 원하는 로직의 진행 순서는 다음과 같았다. (창 새로고침 시)백엔드로 연도리스트를 요청 (응답 시) <select> 태그 밑에 appendChild로 <option> 추가. (위 작업 종료 시) <select> 태그의 value 값을 현재 param값으로 설정. 이를 위해서 다음과 같이 코드를 추가했다.(xhr방식을 사용하고 있어서 그대로 유지하기 위해서 조금만 수정했다.) async await 은 Promise 확장판 다음과 같은 두가지 기본 전제를 잊고 있었다. async 함수는 Promsie를 반환해야한다. await은 Promise 를 반환하는 함수에 대해서만 사용할 수 있다. 초기코드에서 문제점은 다음과 같다. loadYear함수는 async를 붙였는데 Promise를 반환하지 않는다. 보통 fetch를 사용하면 자동으로 Promise를 반환해준다. 하지만 xhr은 그런거 없다. 직접 Promise를 만들어야한다. 그러니까 당연히 xhr.send도 await되지 않고 loadYear도 await이 될 리가 없다. 뒤에 오는 함수가 Promise를 반환하지 않으니까! async await 복습하기. Promise의 기본 **Promise**는 JavaScript에서 비동기 연산을 나타내는 객체입니다. 비동기 연산의 결과(성공 또는 실패)를 추후에 처리할 수 있도록 해줍니다. **Promise**는 세 가지 상태를 가집니다: Pending (대기 중): 초기 상태, 연산이 완료되지 않음. Fulfilled (이행됨): 연산이 성공적으로 완료됨. Rejected (거부됨): 연산이 실패함. async 함수

궁금한 것 VUE의 Single File Component는 정확히 뭘까. 왜 다른 컴포넌트에서 import를 한다면 HTML태그마냥 사용가능한가 변수나 스타일의 scope는 어떻게 되는가 성능저하는 없는가 1. SFC란 A Vue SFC, as the name suggests, encapsulates the component's logic (JavaScript), template (HTML), and styles (CSS) in a single file. .vue파일 안에서 html css js를 모두 작성할 수 있는 vue3의 파일 포맷이다. 공식 홈페이지에서도 이 형식을 권장하고 있고, 사용시 얻는 장점 또한 다양하다. 2. VUE SFC 사용시 장점 익숙한 HTML, CSS, JavaScript 문법을 사용하여 모듈화된 컴포넌트를 작성할 수 있습니다. SFC를 사용하지 않는다면, 복잡한 export data setup 과 같은 구조를 가져야한다. 밀접하게 연관된 관심사를 한 곳에 모을 수 있습니다. 당연한 말인 것 같다. 같은 도메인의 역할을 가진 로직과 변수 화면이 한곳에 모여 있는 것은 가독성을 높여줄 수 있다. 런타임 컴파일 비용 없이 사전 컴파일된 템플릿을 사용할 수 있습니다. 어떤 말인지 찾아보니 vite와 같은 빌드 도구들이 로딩과정에서 .vue의 내용을 js로 컴파일하기 때문에 브라우저에 로드 된 이후 렌더링되지 않기 때문에 더 빠른 속도를 가진다고 한다. 컴포넌트 스코프의 CSS를 사용할 수 있습니다. 이것도 은근 편리한 것 같다. 클래스명의 중복과 같은 문제로부터도 조금은 자유롭다. Composition API 사용시 더 편리한 문법을 사용할 수 있습니다. - data대신 ref, props 대신 defineProps 이런 식으로 중괄호 들어간거 안써도 되고 깔끔해서 좋다. 템플릿과 스크립트를 교차 분석함으로써 더 많은 컴파일 시간 최적화를 할 수 있습니다. - 번들링 과정에서 템플릿과 연결되는 메소드는 연결하고 필요없는 건 제거해준다.

반응형 reactive 다음과 같이 반응형 변수를 사용할 수 있음 업데이트타이밍 반응형이 작동하기 위해서는 DOM 자동 업데이트 시간을 기다려야함. 이때 동기적으로 적용되지 않기 때문에 만약 어떤 상태변경이 완료 된후 특정작업을 하고 싶다면 nextTick()을 사용하면 됨 깊은 반응형 기본적으로 reactive는 깊은 반응형으로 중첩된 객체나 배열의 요소를 변경할 때도 변경이 감지됨 . 언제끊어지나 반응형 객체의 속성을 로컬변수에 할당하거나 분해하면 반응형 연결이 끊어짐 ref .value에 값을 넣어 ref객체에 래핑 후에 반환한다. 값으로 객체를 가지는 경우 객체 전체를 반응형으로 대체할 수 있다. state는 새로운 프록시를 반환하지만 ref는 value의 값을 수정함. 이때 value는 반응형으로 추적되고 있기 때문에 반응형으로 작동함. ref의 언래핑 최상위 속성의 ref를 템플릿에서 접근시 자동으로 언래핑됨 ref가 다른 반응형객체의 속성으로 들어가면 접근이나 변경시 자동 언래핑됨 단, 배열이나 기본 컬렉션 유형의 속성으로 들어간다면 .value가 필요함 computed computed()함수의 매개변수 : getter로 사용될 함수 / return값 : computed ref 이때 의존하고 있는 변수들의 변경을 감지하고 있다가 변경이 감지되면 computed값을 다시 계산한다. 클래스 & 스타일 바인딩

강의 자료 정리

ListTile의 Leading이 가운데 정렬되지 않는 문제 이거로 해결되는줄 알았으나… 결론 In Flutter's ListTile, the leading and trailing doesn't span accross the full height of the ListTile when subtitle is used. Hence create your own Widget using row. CustomListTile 위젯을 만들거나 Row로 해결하는 것이 바람직함. flutter StatefulWidget의 LifeCycle createState State를 생성하고 StatefulWidget에서 state를 실행합니다. initState State를 초기화합니다. 단, initState는 StatefulWidget이 실행되면 단 한번 동작합니다. initState 내부를 수정하고 싶다면 rebuild, hot-reload를 해도 변화가 없으므로 반드시 종료 후 실행시켜야 합니다.