금붕어의 일기장

입사 뭐시기

금붕어 송인호 — Sun, 8 Dec 2024 20:17:34 +0900

https://imminent-actor-8cf.notion.site/156242a0fce3804cad3dda5656110cd4?pvs=4

EP0. 골디학개론

금붕어 송인호 — Mon, 5 Feb 2024 23:02:25 +0900

참고로 내이름은 골디다.
회사에서 쓰는 닉네임인데, 그 이유가 뭔지 아는가.

금붕어의 일기장이라는 블로그를 운영하기 때문이다.
그렇다 이 블로그의 이름은 금붕어의 일기장이다.

신년을 맞이해서 이런 저런걸 하다가 생각을 했다.
뭐라도 남기자.
내 몇 안되는 인생에서도 깨달은 내용은 뭐라도 남아야 개이득이라는 것이다.

그리고 이때에만 남길수 있는 것이 있다.
나의 생각, 가치관, 지식, 경험 등등.

그래서 적어보려 한다.
나는 어떤 사람이며, 어떤 마음가짐을 가지고 있으며,
어떤 생각을 하며, 어떤 로직을 거쳐 그런 생각을 가지고 있는지.

어차피 이 블로그는
HTML 이스케이프와
Tailwind CSS 설치법이 최고 조회수인
사실상 그냥 일기장이기 때문에 편한 마음으로 적어본다.

그래서 노가리 까듯 말해볼 생각이다.
지나가다 놀라시는 분 없길 바란다.

Vue 배우기 (1) - 속성 바인딩, 디렉티브, 단축어

금붕어 송인호 — Sat, 19 Aug 2023 15:44:49 +0900

Vue 객체로 속성에 바인딩하기

기본적으로 HTML 코드가 브라우저에서 DOM으로 파싱이 되고 나면,
기존에는 값을 바꾸거나 이벤트를 추가하는 등의 동작을 하려면
DOM 객체에 직접 접근해서 변경해줘야 했다.

Vue에서는 엘리먼트에 이벤트, 변수등을 바인딩하여
스크립트에서 더 쉽게접근할 수 있도록 하였다.

// html
<button :disabled="disabled" @click="handleClick"> 버튼 </button>

// js
<script>
export default {
  data() {
    // disabled 바인딩
    return {
      disabled: false,
    }
  },
  methods: {
    // handleClick 바인딩
    handleClick() {
      this.disabled = !this.disabled;
    }
  },
}
</script>

디렉티브 (directive)

엘리먼트에 기본적으로 넘겨줄 수 있는 Prop들 외에도,
Vue에서 제공하는 Prop들이 있다.

앞에 v-가 붙는 prop들이 Vue에서 제공해주는 것들인데,
이 v-를 디렉티브라고 한다

<button
  v-bind:disabled="disabled"
  v-on:click="handleClick"
  v-if="visible"
>
  <p v-for="item in lists">
    {{ item }}
  </p>
</button>

단축어

위에서 사용한 v-bind와 v-on은 간단하게 축약해서 사용할 수 있다.

// v-bind:prop -> :prop
<button v-bind:disabled="disabled" />
<button :disabled="disabled" />

// v-on:click -> @click
<button v-on:click="handleClick" />
<button @click="handleClick" />

익스프레션 사용하기

리액트와 달리 Vue에서는 문자열에 Expression을 쓰는 괴이한 형태다.
나는 리액트를 써와서 그런지 굉장히 당황했다.

<button
  @click="handleClick(disabled)"
/>

리액트는 string과 변수를 명확히 구분하는 편이라
개인적으로는 리액트가 더 취향

Next.js 13 - App Router

금붕어 송인호 — Thu, 10 Aug 2023 23:52:28 +0900

오랜만에 create-next-app으로 프로젝트를 생성했더니
폴더 구조가 달라졌길래 공식 문서를 확인해봤다.

the app Router

13버전에서부터 새로운 App Router라는게 도입되었다고 한다.

이전에 사용하던 pages도 여전히 동작하며,
혼용이 가능하다.

두 라우터 (pages와 app router)가 충돌할 경우,
app router가 더 우선적으로 적용된다고 한다.
경로가 충돌하면 빌드 과정에서 에러가 발생한다.

또한 서버 컴포넌트와 클라이언트 컴포넌트를 사용할 수 있다.

폴더와 파일의 역할

폴더는 라우트를 뜻한다.
src/app/page.tsx는 기존의 src/pages/index.tsx와 동일하다.
다른 예로, src/app/foo/bar/page.tsx는 src/pages/foo/bar.tsx와 동일하다.

파일은 해당 라우트에 적용될 UI 요소들이다.
특정 파일명에 대해서 특수한 동작들을 한다.

자신의 세그먼트와 자식에게 적용되는 것들

layout - 레이아웃 적용. children으로 page의 내용을 삽입한다.
loading - 로딩시에 적용되는 UI. (React suspense boundary에 잡힘)
not-found - 404시에 표시되는 UI. (React error boundary에 잡힘)
error - 에러시에 표시되는 UI. (React error boundary에 잡힘)

해당 세그먼트에만 적용되는 것들

page - 해당 경로에 접근할 수 있게 하는 UI

기타

global-error - 글로벌 에러 UI
route - 서버사이드 API 엔드포인트
template - ???
default - Parallel Routes에 사용되는 Fallback UI

마무리

언제 나왔나했더니 작년 10월에 나왔다.
너무 뒷북인거 같기도 하고.

그래도 이제 알면 그만이지~

컴포넌트 기능 관리에 대한 고찰

금붕어 송인호 — Sun, 6 Aug 2023 01:37:48 +0900

제목을 뭘로 지어야 할지 모르겠어서 대충 써봤다.
갑자기 생각났는데, 기존의 고민을 해결할 수 있을 것 같아 급하게 써본다.

다양한 기능을 가지는 최하위 UI 컴포넌트

기능 개발을 하다보면 UI 컴포넌트를 관리하게 된다.
제일 복잡한 데이터테이블 컴포넌트를 가져와보자

이해를 돕기 위해 props의 설명을 써두겠다.

columns: 컬럼 정보. 타이틀, 색상, 정렬가능등의 옵션이 포함됨
rows: 데이터 배열
header: 데이터테이블 상단에 표시되는 제목
cellStyleOption: 셀에 적용되는 스타일관련 옵션들
emptyRender: 조회 전이거나, rows가 빈 값일 때 표시되는 내용 (React Component 타입)
paginationOption: 페이지네이션 관련 옵션들

만약 이 컴포넌트를 호출한다면 아마 이런 모양일 것이다.

너무 추잡하다.

기능이 늘어날수록 외부에서 넣어줘야하는 값들이 늘어날 것이다.
기본값을 활용하면 줄일 수는 있겠지만,
그것만으로 다양한 바리에이션의 요구사항을 만족하기는 역부족이다.

개선 방법 1: 바리에이션 명시하기

아예 명시적으로 다양한 바리에이션에 대한 옵션을 지정하는 방법이 있다.
(나중에 나오지만 추천하지 않는다)

장점
전달해야하는 여러가지 prop을 생략할 수 있다.
종류가 몇가지 안된다면 편할 수 있다.

단점
종류가 많아지면 복잡해진다.
커버 가능한 경우의 수에 한계가 있다.

예를 들어 propA, propB, propC에 각각 5가지 입력의 경우의 수가 있다면,
총 5 x 5 x 5 = 125의 경우의 수가 나오지만,
개발자가 타입을 명시하게 되면 특정 경우만 지정이 가능하고,
새로운 요구조건이 들어올 때마다 컴포넌트에 지정해줘야한다.

눈앞의 요구사항을 쳐내는데에 급급해서 하게되면
나중에 피눈물을 흘리는 케이스다.

왜 피눈물을 흘리는지는 나도 알고 싶지 않았다 ㅠㅠ

개선 방법2: 자주 사용하는 옵션을 상수로 빼기

코드의 직관성과 옵션의 재활용을 고려하기 시작하면,
자주 사용하는 옵션들을 상수로 관리할 수 있다.

장점
특정한 옵션을 재활용할 수 있다.
옵션과 컴포넌트를 파일을 분리하여 관리할 수 있다.

단점
일괄적인 변경요청에 취약할 수 있다.
묶여서 사용하는 옵션들이 있을 때, 변경에 대한 관리가 어렵다.

일괄적인 변경요청의 예시를 들어보자.
A, B, C 페이지 모두 paginationA 옵션을 사용한다.

그런데 A, B는 같은 구성의 페이지이고,
C는 전혀 다른 페이지의 구성이지만 옵션은 paginationA를 쓰고 있다.
(겹칠수는 있으니까)

그런데 A, B와 같은 레이아웃에 일괄적으로 다른 페이지네이션을 적용하게 되었다.
그렇다면 개발자 입장에서의 해결방법은
paginationA를 전체검색을 해서 변경된 페이지만 paginationB로 변경하거나,
각 페이지 코드에 찾아 들어가서 수정을 해줘야 한다.

예시라서 2개만 바꾸면 되지만,
프로젝트의 규모가 있다면 수십개 변경을 각오해야 한다.

묶여서 사용하는 옵션의 예시를 들어보자.

예를 들어 위의 경우와 같이 A, B, C가 있다고 생각해보자.
A와 B는 페이지 맥락상 비슷한 구성이다.
예를 들면 메일함의 받은 메일함과 즐겨찾기같이.

그런데 이 둘이 같은 구성이라는 것을 코드만 보고서는 파악이 어렵다.
또한 같은 구성의 일괄 변경이 있을 때,
특정 구성만 검색하기가 어렵다.
단순히 paginationA로만 검색하면 C도 검색이 될 테니까.

개선 방안 3: 옵션 그룹의 관리

이게 생각한 방식이다.
기존에 이미 있는 방식인지는 모르겠다. 있다면 댓글로 용어를 알려주셨으면.

옵션을 그룹으로 묶어서 관리하는 방식이다.
백문이 불여일견. 코드로 보자.

주요한 값들 (rows, columns, header)을 제외하고는
대부분을 세트로 묶어서 관리했다.

일괄적인 변경 요청에도 세트를 수정하면 된다.

한계

자 일단 생각은 해봤는데...
한계가 일단 여럿있다.

1. 일을 위한 일이 생긴다.
(호출부는 가벼워지지만, constants가 verbose해진다)

2. 일괄적인 변경을 예측하기 어렵다.
예를들어 A, B, C 페이지 모두에 변경이 있다고 한다면...
또는 C와 같은 구성의 D도 DATA_TABLE_TYPE_B를 공유하고 있었는데,
C만 바뀌고 D는 그대로라면...

마무리

오 나 개천재인데 생각해보고 써보니
역시 안 쓰는데에는 이유가 있다.

한층 겸손해진 하루였다.

그래도 딱 맞는 상황에 쓰면 괜찮을듯?

주관적인 소프트웨어 엔지니어의 역량

금붕어 송인호 — Sun, 30 Jul 2023 14:13:55 +0900

스로틀링 (Throttling)

금붕어 송인호 — Sun, 30 Jul 2023 13:55:24 +0900

스로틀링이란 사용자의 디바이스의 부담을 줄이기 위해
성능을 저하시키는 것을 말합니다.

성능을 저하시킨다고하니 뭔가 쓰레기 같은 느낌이지만
모든 것은 하기 나름이다.

예를 들어 인간은 60fps보다 빠른 영상은 크게 체감을 못 한다

근데 300fps짜리 영상을 재생한다면?
인간의 인지로 따라가지도 못하는 속도로 재생하느라 CPU를 혹사하고 있다.
(CPU와 GPU의 인권을 보장하라)

웹에서는 다음과 같은 케이스가 있을 수 있겠다.

스크롤 이벤트나 mouse in / out 이벤트의 경우 굉장히 빈번히 발생한다.
하지만 부드럽게 표현이 되지 않아도 되는 경우에는
딜레이나 호출 횟수로 실행 횟수를 제한하는 경우가 있겠다

API 해체 응답기 개발 내용

금붕어 송인호 — Sun, 9 Apr 2023 17:58:00 +0900

프로젝트 소개

API 해체분석기 소개

소개 API 해체분석기는 API 응답을 기록하고 분석하는 도구입니다. 인기 게임 리그 오브 레전드 (LOL)의 미니언 해체 분석기에서 따왔습니다. TODO: 링크 연결 제작 배경 회사 팀원분과 얘기를 하다

goldfishdiary.tistory.com

개발 스택

Typescript: 정적 타입 언어 사용 (JS 답답해서 못 씀)
React: 컴포넌트 기반 구현 (JQuery 답답해서 못 씀)
Webpack: TS 트랜스파일 및 React 컴파일
Chrome API: Chrome 내부 기능 사용
Jotai: Atomic 컨셉의 상태 관리 라이브러리

Eslint: 문법 및 오타 체크
Prettier: 컨벤션 자동 수정
Watch: 파일 변화 감지하여 자동 빌드에 사용

구조

Service Worker

사용자가 등록한 API에 따라 API 호출을 감지하여
Inbox에 데이터를 삽입하거나,

사용자 페이지에서 API 설정 변경이 있을 때
이벤트를 받아 처리하는 로직이 포함되어있다.

Chrome Extension Storage

크롬 익스텐션에서 제공하는 storage 서비스이며,
localStorage와 달리 모든 페이지에서 접근 가능하다.

inbox: 응답 목록
apis: 저장할 API에 대한 설정 목록
apiIndex: api에 고유 index를 부여하기 위한 카운터

Jotai Store

Atomic 컨셉의 상태관리 라이브러리 Jotai의 관리 단위.

inbox: 응답 목록. Chrome Storage의 내용과 싱크
apis: API 설정 목록. Chrome Storage의 내용과 싱크
apiIndex: API id 부여를 위한 카운터. Chrome Storage의 내용과 싱크

bodyMode: body의 모드. 현재 모드를 파악하여 Body를 렌더
bodyContent: Body에서 표시할 내용을 관리
currentTab: 현재 탭. API 목록 / Inbox 목록

Hooks

React Hook을 모아놓은 폴더

useStorage: 프로젝트 구조 상, chorme Extension과 사용자 페이지, Service worker 간의 싱크가 맞아야 함.
관련 로직을 처리하는 훅.

useBody: bodyMode와 bodyContent를 관리.

useTab: currentTab을 관리

Components

컴포넌트 단위로 페이지를 구현

Sidebar: 사이드바
Body: 본문 영역. bodyMode에 따라 다른 컴포넌트를 render

회고

Jotai를 적극적으로 사용해본 프로젝트.
하지만 너무 Atomic하게 사용한건지 사용이 복잡했다.

특히 value를 관리하는 것이지, 로직이 관리되는 것이 아니기 때문에
useContext의 부재가 뼈져리게 느껴졌다.

결국 Hook을 이용해서 로직을 정리하였으나,
이럴거면 그냥 Context를 쓰는게 낫지 않나 생각이 들었다.

프로젝트를 설정하면서 Chrome Extension을 매번 설정하는게 복잡해서,
템플릿을 만들어버렸다. 껄껄.

GitHub - ImInnocent/chrome-extension-template: 크롬 익스텐션 + Typescript + React + Webpack 템플릿

크롬 익스텐션 + Typescript + React + Webpack 템플릿. Contribute to ImInnocent/chrome-extension-template development by creating an account on GitHub.

github.com

추가로 eslint나 prettier, watch 설정도 해야하는데
이건 브랜치로 따서 분리하는게 나을 것 같다.

개발 과정에서 chat GPT를 적극 활용했다.
특히 자료가 많지 않은 Chrome Extension을 개발할 때 도움이 되었다.

하지만 한계도 명확했다.
chat GPT가 항상 정확한 답변을 내는 것은 아니므로,
내가 로직을 보고 문제점을 스스로 파악할 수 있어야 했다.

결국 로직을 이해하고 파라미터를 파악하는 용도로 주로 이용한 것 같다.

API 해체분석기 소개

금붕어 송인호 — Sun, 9 Apr 2023 17:05:34 +0900

소개

API 해체분석기는 API 응답을 기록하고 분석하는 도구입니다.

인기 게임 리그 오브 레전드 (LOL)의 미니언 해체 분석기에서 따왔습니다.

TODO: 링크 연결

제작 배경

회사 팀원분과 얘기를 하다가 개발자 도구를 보면서 뭔가를 하고 있었는데,
굉장히 많은 양의 데이터 중에서 특정한 key의 값을 모아서 봐야했습니다.
그리고 다시 잘못된 값을 수정해서 다시 API를 쏴야하는 상황이었죠.

하지만 할 수 있는거라고는 개발자도구에서 복사해서 IDE로 옮긴 다음,
검색기능으로 하나하나 살펴보는 것 뿐이었습니다.

그러고보니 저도 개발자도구를 사용하면서 불편한 점이 있었습니다.
조건에 맞는 API를 찾아서, 열어서, 뜯어서, 값을 찾아서 확인을 해야 했죠.

이러한 문제점을 해결하기위해 API 해체 분석기를 만들었습니다.

주요 기능 및 사용 방법

응답을 기록할 API 등록하기

새 API 추가 버튼을 누르면 추가 화면으로 넘어가며,
화면에 표시될 이름과 URL 패턴을 입력합니다.

새 API 추가 화면

URL 패턴은 Regex가 아닌 문자열이며,
전체 경로가 아닌 일부만 충족해도 API를 잡아냅니다.

예시:

목표 API: https://www.naver.com/search?keyword=abcd
URL 패턴1: naver.com (O)
URL 패턴3: r.com/search (O)
URL 패턴3: *naver.com/search* (X)

응답 Inbox 열어보기

등록해둔 API 패턴에 일치하는 API가 호출되면
API Response가 Inbox에 등록됩니다.

사이드바의 Inbox 목록들

우측 상단에서 Inbox 탭을 눌러 목록을 조회하세요.

응답 내용 살펴보기

Inbox 목록에서 내용을 보고 싶은 항목을 클릭하면
API의 응답값을 볼 수 있습니다.

JSON 에디터에서 수정 버튼으로 값을 수정할 수 있습니다.
단, 다른 API 응답 화면으로 이동하거나, 새 API 추가 화면 등
다른 화면으로 이동하면 변경사항을 초기화됩니다.

모아보기

API 응답을 보는 화면에서 검색창에 키워드를 입력하고 검색하면
모아보기 화면으로 이동하며, 접혀있는 검색 결과를 클릭하여 상세 내용을 볼 수 있습니다.

API 응답 화면과 마찬가지로 값을 수정할 수 있습니다.
뒤로가기 아이콘을 눌러 이전 화면으로 돌아가도,
수정한 JSON 변경사항은 여전히 적용됩니다.

클립보드로 복사

API 응답 화면에서 모아보기 버튼 옆의 클립보드 아이콘을 누르면
API 응답이 클립보드로 복사됩니다.

API 응답 화면이나 모아보기 화면에서 수정한 값도
적용되어 클립보드로 복사됩니다.

개발 내용

API 해체 응답기 개발 내용

프로젝트 소개 API 해체분석기 소개 소개 API 해체분석기는 API 응답을 기록하고 분석하는 도구입니다. 인기 게임 리그 오브 레전드 (LOL)의 미니언 해체 분석기에서 따왔습니다. TODO: 링크 연결 제

goldfishdiary.tistory.com

2023 오사카 여행기 2일차

금붕어 송인호 — Tue, 7 Mar 2023 00:43:15 +0900

교토 여행기

둘째날에는 교토로 갔다.
이 날은 진짜 ㅋㅋㅋㅋㅋ

아침에 간단히 스키야에서 덮밥을 먹었다.
20살때 누나랑 오사카 왔을 때 그냥 먹었는데 너무 맛있었다.
근데 다시 와서 먹어보니 메뉴가 달라서그런지 평범하더라.
이래서 추억 미화가 무섭다.
경험이 한번이면 데이터가 1/1이니까.

교토로 가는 길

지하철로 가니까 인명사고로 인해(다른 역)
지하철이 연착되었다.
출근 시간이었는데 다들 발을 동동 구르더라.

전에 나고야 여행중 교토 당일치기할 때에는
신칸센을 타고 다녀와서 걱정이 없었는데,
이번에는 전철을 타게 되어 다소 헤맸다.
일본 전철은 아직도 난 와카라나이

가면서 느낀건데 거리에 사람이 너무 없었다.
아무리 시내가 아니라고해도 그냥 길에 사람이 없었다.
동화같이 예쁜 그림이었지만 묘한 기분도 들었다.

또 느낀 다른 점은 페인트칠을 진짜 오지게 했다는 거다.
어떻게 그렇게 다들 페인트칠을 자주 하지?
그림으로 그린듯 깔끔하게 칠해놨다.

또 건물들이 좁은 땅 위에 높게 짓는다는 점이 있었다.
이게 일본의 협소주택?
근데 뭔가 하나의 집을 케이크 자르듯
여러개로 나눠놓은 듯한 이미지가 인상적이었다.

아라시야마

아라시야마는 교토 동쪽에 있는 지역인데,
죽림과 텐류지가 유명하다.

역에서 내리는데 한국인은 거의 안 보이고
서양계 외국인과 기모노를 입은 일본인들이 많았다.
뭐랄까 경주에 외국인들이 많이 온 느낌?
(경주에서도 옷 입고 다니니까)

말차 라떼와 아이스크림을 챱챱하면서 걷는데,
죽림까지는 들어가서 대충 열심히 돌았는데
갑자기 이상한 길로 들어서버렸다.

계획밖의 보물같은 거리

어떤 동네에 들어섰는데, 거리가 너무 예뻐서 30분동안 사진찍고 난리였다.
나무도 없어서 가로거치는게 없고 날씨도 너무 좋아서 그대로 누워있고 싶었다.
실제로 좀 누워있었다.

평소에는 도심, 예쁜 제품에 관심이 많았는데
어제 호수도 그렇고 너무 마음이 편안했다.
심지어 사람한명 지나가지 않는 조용한 거리였다.

이렇게 P들과 여행을 가면 이런 일이 생기는구나 싶었다.
아무도 알려주지 않는 신기하고도 소중한 경험이었다.

그래놓고 ㅋㅋㅋㅋㅋ

정작 아라시야마의 히트 텐류지는
입장료가 있다는 이유로 안 갔다 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ
이미 사진을 많이 찍어서 만족했었다는...

교토 시내로

전철을 타고 교토 시내로 가서 점심을 먹으러 갔다.

전에는 새벽에 와서 밤에 가서 교토역을 볼 일이 없었는데,
낮에 본 교토역도 나름 멋있었다.
물론 밤에 불 들어온 교토역이 더 멋있긴했지만

그렇게 규카츠를 먹으러 갔는데
하필이면 온천라멘이 AI (조류독감)때문에
공급이 중단이랜다 아이고

이상하게 억까를 당하는 날이었다.

교토 탐방

절과 니죠 성을 돌고,
교토 번화가로 갔다.

번화가에서는 중간부터 친구들과 따로 다녔다.
나는 기념품 사러 여행가는 거기 때문에
돌아다니는거 좋아하는 친구들과 달리 가게들을 보면서 지나갈 생각이었다.

그렇게 기모노 가게에 들어갔는데
점원이 말을 걸어오길래 어버버했더니
"일본어 할 줄 모르시나요?"라고 말하는 듯한 내용이길래
"저는 한국인입니다 (와타시와 한고쿠진 데스)"라고 했더니
"아 한국인이세요?" 이랬다 ㅋㅋㅋㅋㅋㅋㅋㅋ

다국어 능력자라는 그 분...
참고로 니죠성 앞 카페에서도 한국어를 할 줄 아시는 분이 계셨다

아무튼 기모노도 사고 가챠도 돌리고
일본도 모양의 우산과 칼 모형도 샀다.
소개팅 해주신 분들께 드릴 선물도 샀다.

먼저 보낸 친구들보고 가서 커피 먹으라고 위치를 알려줬는데,
이상한데에서 돌고 있다가 정작 카페는 못 갔다고 한다 (ㅋㅋㅋㅋ)

결국 카페거리 앞에서 예쁜 사진 많이 찍고
장어 덮밥 먹고 집으로 갔다.

장어 덮밥

장어덮밥은 진짜 맛있었다.
나고야식처럼 4가지 방법으로 먹는건 아니었지만,
장어의 간이 정말 딱 좋아서 밥이 쑥쑥 들어갔다.

진짜 뭐라고 설명을 해야할지는 모르겠는데
느끼하게 부담스럽지 않은데 깊고 풍부한 맛이었다.
3일차에 먹은 라면도 그렇지만 깊은 맛이라고해서 무거운 맛인건 아닌 것 같다.
한국에서는 느끼기 힘든 맛이었다.

나는 흰밥을 잘 못 먹어서
비벼먹거나 말아먹거나하는데,
이 장어 덮밥은 밥을 다 먹었다. 최고다.

주변 가게가 모두 문을 닫아서 찾다찾다 간 곳인데,
너무 맛있어서 안 갔으면 후회했을 것 같다.

집으로 가는 길

집으로 가는 길에 편의점에 들러서 술과 안주,
다음날 아침에 먹을 간단한 식사를 샀다.

근데 편의점 가보니까 다 한국인이더라 ㅋㅋㅋ
(도톤보리 근처라 그런듯)

기타 주저리

일본 MZ 세대는 왜이리 예쁜걸까
나는 한국보다는 일본상이나 화장법이 더 좋은 것 같다.
특히 리본 머리띠는 히트다 증말...

난방이 안되는 문제는 호스트한테 연락해서
에어콘으로 난방하라는 설명을 들었다.

이리저리 조작해서 난방을 켜는데 성공했으나,
바람이 너무 쎄서 찬바람도 같이 나왔다.
결국 아침이 되니까 약간 추웠다
(첫날보단 낫지만)