Posts on Kaisekukun

현대 CSS의 새로운 기능 (서브 그리드 컨테이너 쿼리) 실전 활용

Wed, 14 Oct 2026 00:00:00 +0900

Viewport 기준에서 자립형 구성요소로의 패러다임 이동

기존의 반응형 웹 디자인은 전체 화면 너비(Viewport)에 따라 달라졌습니다. 그러나 컴포넌트 지향 전성의 현대, UI 파트는 배치되는 부모 요소(사이드바인가 메인 컬럼인가)에 의해 이용 가능한 가로폭이 다릅니다.

CSS 그리드의 “서브 그리드 (Subgrid)“와 “컨테이너 쿼리 (Container Queries)“의 출현으로 레이아웃의 유연성과 유지 보수성이 크게 향상되었습니다.

레시피 1 : 카드의 높이를 정렬하면서 버튼 위치를 동기화하는 `subgrid`

복수열의 카드 UI로 타이틀 문자수가 불일치한 경우에서도, 각 카드내의 「이미지・타이틀・본문・버튼」의 높이를 가로 일렬로 완전하게 정렬할 수 있습니다.

Vitest 및 Testing Library로 효율적인 프런트 엔드 테스트

Tue, 06 Oct 2026 00:00:00 +0900

Vite 네이티브 테스트 환경이 제공하는 개발 속도의 상승

프런트엔드 테스트라고 하면 오랜 세월 Jest가 주류였지만, 설정의 복잡성이나 오버헤드가 과제였습니다. Vite 설정을 공유하는 ‘Vitest’와 ‘React Testing Library’를 결합하면 폭속 테스트 환경을 얻을 수 있습니다.

보수성이 높고 깨지기 어려운 테스트 스위트를 구축하기 위한 실전 원칙을 정리했습니다.

원칙: ‘구현 세부사항’ 대신 ‘사용자 동작’ 테스트

컴포넌트의 내부 상태를 직접 테스트하면 리팩토링 할 때마다 부서지는 취약한 테스트가됩니다. 사용자에게 보이는 화면의 동작을 검증하는 것이 기본입니다.

import { render, screen } from '@testing-library/react';
import userEvent from '@testing-library/user-event';
import { LoginForm } from './LoginForm';

test('入力からログイン完了までのフローを検証', async () => {
 const user = userEvent.setup();
 render(<LoginForm />);

 await user.type(screen.getByLabelText('メールアドレス'), 'test@example.com');
 await user.click(screen.getByRole('button', { name: 'ログイン' }));

 expect(await screen.findByText('ようこそ')).toBeInTheDocument();
});

비동기 업데이트의 함정 : 쿼리 함수 사용

getBy*: 요소가 “지금 존재한다"는 것을 동기 검증. 존재하지 않는 경우 즉시 오류.
findBy*: API 취득 등 「비동기로 늦게 표시되는」요소를 대기(Promise를 돌려준다).
queryBy*: 요소가 “화면에 존재하지 않는 것"을 어서트 할 때에 사용 (null 를 돌려준다).

CI 실행 시간을 줄이는 병렬화 포인트

Vitest는 기본적으로 스레드 병렬 실행을 수행합니다. DOM 조작을 포함한 테스트에서는 테스트 케이스마다 독립성을 유지하도록 afterEach 로 적절하게 모의를 리셋트 해, 테스트 병렬수를 극대화해 CI 코스트를 억제합시다.

웹 접근성(a11y)을 의식한 UI 컴포넌트 설계

Tue, 29 Sep 2026 00:00:00 +0900

디자인과 조작성을 양립하는 접근성의 기반

웹 접근성(a11y)은 특정 장애인을 위한 대응에 그치지 않고 키보드 조작 사용자나 일시적인 부상·한손 조작 사용자를 포함한 모든 사람의 체험을 향상시키는 품질 기준입니다.

누구나 직관적으로 조작할 수 있는 컴포넌트 설계의 요점을 정리합니다.

모달 대화 상자 디자인의 필수 3 요구 사항

모달은 접근성 위반이 가장 자주 발생하는 부분입니다. 다음 3가지 요건을 충족해야 합니다.

포커스 스트랩(Focus Trap): 열려 있는 동안 Tab 키로 이동을 모달 내부에만 갇혀 후면 요소에 포커스가 새는 것을 방지합니다.
Escape 키 조작: ESC 키를 눌러 즉시 닫고 닫은 후에는 “모달을 연 원래 버튼"으로 포커스를 복귀시킨다.
적절한 WAI-ARIA 속성:
- role="dialog" 및 aria-modal="true" 부여
- 제목을 가리키는 aria-labelledby의 명시

간과되기 쉬운 3 대 안티 패턴

** 안티 패턴 1 :<div> 또는 ‘
`에 클릭 이벤트를 추가 **
- 문제: 키보드(Enter/Space)로 조작할 수 없고, 스크린 리더에게도 버튼으로서 전해지지 않는다.
- 해결: 네이티브의 <button> 태그를 사용해, 스타일은 CSS로 정돈한다.
**안티패턴 2: 자리 표시자를 라벨 대신 **
- 문제: 입력을 시작하면 사라져 버려 시인성과 인지부하를 손상시킨다.
- 해결: 상시 표시되는 <label> 를 준비해, htmlFor 로 input 의 id 와 묶는다.
안티패턴 3: 콘트라스트비 부족
- 문제: 얇은 회색 문자 등 대비비가 4.5:1 미만으로 시인 곤란.
- 해결: WCAG 2.1 AA 기준을 클리어하는 컬러 팔레트를 고정한다.

Headless UI 라이브러리를 통한 공수 감소

액세서빌러티를 처음부터 직접 구현하는 것은 매우 공수가 걸립니다. Radix UI나 React Aria등의 「스타일을 가지지 않는 고액세시빌리티인 UI 프리미티브」를 채용해, 스타일링만을 Tailwind CSS등으로 맞추는 수법이 현대의 스탠다드입니다.

Next.js와 Hono로 만드는 풀 스택 WebAPI 시작

Tue, 22 Sep 2026 00:00:00 +0900

Next.js App Router × Hono의 개발 혁명

Next.js의 Route Handlers는 강력하지만, 엔드포인트 증가에 따른 보일러 플레이트와 형 공유의 번잡함이 과제가 되기 쉽다.

웹 표준을 준수하는 초경량 프레임워크 “Hono"를 API 레이어에 통합하여 정교한 엔드 투 엔드 유형 안전 RPC(Remote Procedure Call) 환경을 손쉽게 완성합니다.

Step 1: Catch-all Route에서 Hono 초기화

App Router 내에 와일드카드 루트를 배치하고 /api/* 를 모두 Hono 에 위양합니다.

// app/api/[[...route]]/route.ts
import { Hono } from 'hono';
import { handle } from 'hono/vercel';
import { zValidator } from '@hono/zod-validator';
import { z } from 'zod';

export const runtime = 'edge';
const app = new Hono().basePath('/api');

const routes = app.get('/users/:id',
 zValidator('param', z.object({ id: z.string() })),
 (c) => c.json({ id: c.req.valid('param').id, name: 'Alice' })
);

export type AppType = typeof routes;
export const GET = handle(app);

Step 2: `hc`에 의한 타입 안전 데이터 페치

서버 측의 루트 정의 (AppType)를 클라이언트로 그대로 형태로서 임포트 할 수있는 것이 Hono의 큰 강점입니다.

TypeScript 5계에서 실천하는 형태 안전한 코딩 테크닉

Tue, 15 Sep 2026 00:00:00 +0900

TypeScript 5.x 시대에 요구되는 타입 디자인의 사상

TypeScript 5계에서는, 개발자 체험을 해치지 않고 형태 추론의 정밀도를 극한까지 높이는 신기능이 다수 도입되었습니다. 과도한 유형 어설션(as)에 의존하는 코드는 런타임 오류의 온상이 됩니다. 형 시스템을 아군에게 붙여, 자연과 형이 좁혀지는 실천 테크닉을 해설합니다.

1. `const` 형 파라미터 : 리터럴 형 추론의 스마트화

함수의 인수로 리터럴형을 보관 유지하고 싶은 경우, 종래는 호출측에서 as const 의 부여가 필요했습니다. TypeScript 5.0의 const 형 파라미터를 사용하면(자), 함수 정의측에서 리터럴 추론을 강제할 수 있습니다.

Next.js 15에서 구축하는 폭속 웹 애플리케이션

Tue, 08 Sep 2026 00:00:00 +0900

요전날의 업데이트로 마침내 베타판이 공개되어 프런트 엔드 경계를 크게 끓이고 있는 「Next.js 15」. 저자도 즉시 개인 프로젝트를 Next.js 14에서 15로 업그레이드하고 몇 가지 새로운 기능을 시도해 보았습니다. 본고에서는, 실제로 만져 보아 느낀 「진화의 굉장함」을 리뷰 형식으로 전달합니다.

만지고 놀란, Next.js 15 진화

우선 한마디로 표현한다면, 「개발자 체험(DX)과 퍼포먼스의 궁극의 저조」입니다. App Router가 도입된 이후, Next.js는 큰 패러다임 시프트 중에 있었지만, 버전 15는 그 완성형에 가까운 인상을 받았다.

1. React Compiler를 사용한 수동 메모화에서 해제

개인적으로 가장 인상적인 것은 React Compiler의 공식 지원입니다. 지금까지는 쓸데없는 재 렌더링을 막기 위해useMemo,useCallback,React.memo를 어디서나 작성해야했습니다. 그러나 Next.js 15에서는 컴파일러가 잘 최적화합니다.

백엔드 개발의 성능 튜닝 시작

Thu, 03 Sep 2026 00:00:00 +0900

웹 서비스의 이용자가 늘어나면 반드시 직면하는 것이 「응답이 느린」「서버가 떨어진다」라고 하는 퍼포먼스 문제입니다. 프런트 엔드 최적화도 중요하지만 근본적인 데이터 처리를 담당하는 백엔드가 병목 현상이되는 경우는 적지 않습니다.

이 기사에서는 백엔드 성능 향상을 위해 처음으로 노력하는 엔지니어를 위해 실용적인 체크 포인트를 목록 형식으로 설명합니다.

🚨 검토해야 할 5가지 체크포인트

퍼포먼스 튜닝은 암구름에 가도 효과가 나오지 않습니다. 우선은 다음 항목이 원인이 되어 있는지 확인합시다.

**N+1 문제가 발생하지 않았습니까? **
- O/R매퍼(ORM)를 사용하면 무의식적으로 발생하기 쉬운 것이 N+1 문제입니다. 리스트 데이터를 취득할 때, 관련하는 데이터를 1건씩 반복해 SQL을 발행하고 있지 않은지, 쿼리의 로그를 확인합시다.
** 색인이 제대로 붙여져 있습니까? **
- 데이터베이스 검색 속도에 가장 직결하는 것이 인덱스입니다. 검색 조건이나 정렬 조건에 자주 사용되는 열에는 적절한 인덱스(단일·복합)를 설정해 주세요.
** 캐시를 효과적으로 활용할 수 있습니까? **
- 자주 액세스되지만 드물게 업데이트되지 않는 데이터(마스터 데이터 등)는 Redis, Memcached 등을 사용하여 인메모리에 캐시함으로써 DB에 대한 부하를 극적으로 낮출 수 있습니다.
**외부 API에 대한 호출을 너무 기다리지 않았습니까? **
- 타사 API 또는 다른 마이크로서비스로의 통신이 동기화 처리가 되면 거기에서 처리가 차단됩니다. 가능하면 비동기 처리나 백그라운드 작업자에게 놓치는 설계를 고려해 봅시다.
** 메모리 누수가 발생하지 않았습니까? **
- 장기 실행 응용 프로그램에서 점차 성능이 저하되면 메모리 누수가 의심됩니다. 불필요한 객체에 대한 참조가 남아 있지 않거나 프로파일러를 사용하여 조사합니다.

🛠️ 측정하지 않고 개선 없음

튜닝에 있어서 제일 해서는 안 되는 것이 「추측으로 고치는 것」입니다. “여기가 느린 생각이 든다"라는 감은 종종 벗어납니다.

가을의 야장에 배우기 : 최신 프론트 엔드 기술 동향

Sun, 30 Aug 2026 00:00:00 +0900

창 밖에서 희미하게 벌레 소리가 들리는 계절이되었습니다. 에어컨이 효과가 있는 방에서 차가운 음료를 한 손에 코드를 쓰는 여름도 좋아합니다만, 시원한 야풍을 느끼면서, 새로운 기술의 문서를 한가로이 바라보는 가을의 야장이라고 하는 것도, 엔지니어에게 있어서는 꽤 풍치가 있는 것입니다.

이번에는 조금 어깨의 힘을 빼고, 올해의 프런트 엔드 경계를 활기찬 기술 동향을 에세이풍으로 되돌아보고 싶습니다.

서버 측으로 되돌아 가기

올해를 상징하는 키워드를 하나 든다면 확실히 ‘React Server Components (RSC)‘일 것입니다. 지난 몇 년 동안 우리는 “어떻게 브라우저 측 (클라이언트)에서 풍부한 경험을 만드는 방법"에 심혈을 기울였습니다. 하지만 자바스크립트의 번들 크기가 커지고 초기 로딩 속도가 한계에 도달했습니다.

보안 인증 기능 구현: NextAuth.js 시작

Fri, 28 Aug 2026 00:00:00 +0900

웹 어플리케이션을 개발할 때, 피해서는 통과할 수 없는 것이 「인증 기능」의 구현입니다. 하지만 비밀번호 해시화, 세션 관리, CSRF 대책, OAuth 연계 등을 0부터 자체적으로 구현하는 것은 보안 리스크가 높고 개발 비용도 엄청납니다.

그래서 이번에는 Next.js 환경에서 인증의 사실상 표준이 되고 있는 “NextAuth.js(현재는 Auth.js)“를 사용한 보안 인증 구현의 모범 사례를 몇 가지 소개합니다.

모범 사례 1: 기본은 OAuth(소셜 로그인)를 우선한다

자체적으로 암호를 관리한다는 것은 정보 유출의 위험이 있음을 의미합니다. NextAuth.js를 사용하는 경우 먼저 Google, GitHub 등의 소셜 로그인(OAuth 공급자)을 도입해 봅시다. 공급자 설정은 놀라울 정도로 간단하며 구성 파일에 Client ID와 Secret을 작성하고 몇 줄의 코드를 추가하면 강력한 인증 시스템이 완성됩니다. 사용자에게도 비밀번호를 기억하는 수고를 줄일 수 있으므로 등록률 향상에도 연결됩니다.

React Server Components의 작동 방식과 활용 사례

Sat, 22 Aug 2026 00:00:00 +0900

프런트 엔드 아키텍처에 큰 변화를 가져온 React Server Components (RSC). 이름은 듣지만 SSR(서버사이드 렌더링)과 무엇이 다른지, 뒷면에서 어떤 처리가 움직이고 있는지를 정확하게 파악하고 있습니까? 본 기사에서는, 그 기술적인 구조를 깊이 파고, 실무에서의 활용 사례를 고찰합니다.

SSR과의 결정적인 차이

기존 SSR은 초기 로드 시 서버 측에서 HTML을 생성하여 브라우저로 반환하는 기술이었습니다. 그러나 그 후 브라우저 측에서 JavaScript를 읽고 구성 요소를 다시 실행 (하이드레이션)하여 대화 형 상태로 만들 필요가있었습니다. 즉, 컴퍼넌트의 코드 자체는 결국 브라우저에 다운로드되고 있었던 것입니다.

Vercel에서 자동 배포 및 미리보기 환경 활용

Sun, 16 Aug 2026 00:00:00 +0900

「〇〇씨, 지금 구현이 끝났으므로 로컬 환경에서 브런치를 풀어 동작 확인해 주실 수 있습니까?」 팀 개발에서 이러한 상호 작용에 쓸데없는 시간을 빼앗기지 않았습니까? 환경 구축의 번거로움과 로컬 빌드 대기 시간은 전체 팀의 생산성을 크게 저하시킵니다.

이 과제를 우아하게 해결하고 프런트 엔드 개발의 워크플로에 패러다임 시프트를 일으킨 것이 「Vercel」의 자동 배치와 프리뷰 환경입니다.

리뷰의 병목 현상을 파괴하는 미리보기 URL

Vercel을 GitHub 등의 리포지토리와 연동시키면 마법 같은 경험이 기다리고 있습니다. 개발자가 새로운 기능을 구현하고 Pull Request(PR)를 작성하는 순간 Vercel은 자동으로 브랜치의 코드를 빌드하고 프로덕션 환경과 정확히 동일한 구성의 임시 ‘미리보기 URL’을 발행합니다.

GraphQL의 기본과 REST API의 차이점

Tue, 11 Aug 2026 00:00:00 +0900

API의 설계 수법으로서 오랫동안 업계의 표준이었던 「REST API」. 그러나 최근 프론트엔드의 고도화에 따라 「GraphQL」을 채용하는 기업이 늘고 있습니다. 기술적인 이야기에 들어가기 전에, 우선은 양자의 차이를 「레스토랑의 주문」에 비유해 생각해 봅시다.

레스토랑의 REST API 한계

REST API는 말하자면 “메뉴마다 창구가 다른 푸드 코트"입니다. 예를 들어, 햄버거 세트를 요청하고 싶습니다. 먼저 햄버거 창구(/api/burgers/1)로 가서 감자 창구(/api/sides/potato)로 가서 마지막으로 음료 창구(/api/drinks/coke)로 가야 합니다.

이것은 여러 번 창구를 오가는 수고 (여러 번의 요청)가 걸립니다. 게다가, 「햄버거의 피클은 빼고 싶다」라고 생각해도, 창구에서는 반드시 피클스들이의 완성품이 건네져 버립니다. 이것은 불필요한 데이터까지 얻어 버리는 “오버 페치"라는 문제입니다.

웹 성능 최적화 모범 사례

Wed, 05 Aug 2026 00:00:00 +0900

웹사이트의 표시 속도는 사용자의 이탈률과 SEO에 직접 연결하는 매우 중요한 요소입니다. 그러나 퍼포먼스 최적화에 관해서는 「일단 이렇게 해 두면 좋다」라고 하는 과거의 상식이, 현대의 브라우저 환경에서는 오히려 역효과가 되는 경우도 있습니다.

여기에서는, 흔히 있는 「퍼포먼스 개선의 오해」를 풀어주면서, 진정한 베스트 프랙티스를 찾아 갑니다.

오해 1: “이미지는 모두 지연 로드(Lazy Load)해야 한다”

“이미지가 무거우면, 모두 loading="lazy"를 붙이면 빨라진다"라고 착각되기 쉽습니다. 확실히 화면 밖의 화상에는 유효합니다만, 퍼스트 뷰(페이지를 열어 최초로 눈에 들어오는 영역)의 화상에까지 Lazy Load를 적용해 버리는 것은 큰 실수입니다. 브라우저는 이것을 후회로 해 버리기 때문에, LCP(Largest Contentful Paint：최대 컨텐츠의 묘화 시간)가 현저하게 악화됩니다. 퍼스트 뷰의 이미지는 오히려 우선적으로 읽어들인다(fetchpriority="high"를 검토한다) 것이 정답입니다.

Supabase를 이용한 백엔드 구축 입문

Fri, 31 Jul 2026 00:00:00 +0900

프런트 엔드 엔지니어의 구세주?

“백엔드 구축이 번거롭고 좀처럼 앱 프로토 타입이 진행되지 않는다” 그런 고민을 가진 개발자들 사이에서 최근 급속히 지지를 모으고 있는 것이 「Supabase」입니다. Firebase의 대체로 언급되는 경우가 많습니다만, 도대체 무엇이 다른 것일까요?

자주 묻는 의문을 Q&A 형식으로 정리해 보았습니다.

Q1 : Supabase는 한마디로 무엇입니까?

A: 오픈 소스 “BaaS(Backend as a Service)“입니다. PostgreSQL을 기반으로 하여 데이터베이스, 인증 기능, 스토리지, 실시간 리스너 등의 백엔드에 필요한 기능 세트를 놀라울 정도로 간편하게 프로젝트에 통합할 수 있습니다.

헤드리스 CMS 비교 및 선택 방법

Sat, 25 Jul 2026 00:00:00 +0900

프런트 엔드와 백엔드 (관리 화면)를 분리하는 “헤드리스 CMS"의 아키텍처는 현대적인 웹 제작에 완전히 정착했습니다. 그러나, 막상 도입하려고 하면 「Contentful」「microCMS」「Strapi」등 선택사항이 많아, 어느 것을 선택하면 좋은가 헤매어 버리는 분도 많을 것입니다.

이 기사에서는 프로젝트의 특성과 상황에 따라 최적의 헤드리스 CMS를 선택하는 방법을 제안합니다.

시츄에이션 1：국산의 안심감과 사용의 용이함을 중시한다면

추천: microCMS

“영어 관리 화면이라면 클라이언트 담당자가 업데이트할 수 없다” 수탁 제작 등에서 자주 있는 이 과제를 순식간에 해결하는 것이 국산 헤드리스 CMS의 필두인 microCMS입니다. 관리 화면의 UI가 매우 세련되고 IT 리터러시가 높지 않은 사용자도 직관적으로 기사 트래피킹이 가능합니다. 또, 일본어의 공식 문서가 충실하고 있어 서포트 체제도 만전. 기업 사이트나 소~중 규모의 미디어 사이트라면, 망설이지 않고 이것을 선택해 두면 틀림없습니다.

Tailwind CSS를 이용한 효율적인 UI 개발

Mon, 20 Jul 2026 00:00:00 +0900

몇 년 전까지, 프런트 엔드의 스타일링이라고 하면 BEM등의 명명 규칙에 따라 독자적인 클래스명을 생각해, CSS 파일에 가거나 오면서 디자인을 짜는 것이 주류였습니다. 그러나 현재, 그 풍경은 “Tailwind CSS"에 의해 일변했다. 유틸리티 퍼스트라는 개념은 왜 여기까지 많은 개발자를 매료시켰습니까?

이번은 Tailwind CSS의 도입을 검토하고 있는 분을 향해, 그 메리트와 굳이 말하는 단점을 감싸 숨기지 않고 분석합니다.

장점 1 : 클래스 이름에 대한 깊은 고민으로부터 해방

“이 버튼의 래퍼 요소, 뭐라고 명명하자… button-container? action-wrapper?” 이런 무익한 생각에 시간을 빼앗긴 경험은 없을까요? Tailwind는 미리 준비된 짧은 유틸리티 클래스(flex, p-4, text-center 등)를 HTML에 직접 부여해 나가기 때문에, 클래스명의 명명이라는 정신적 부담이 완전히 소멸합니다.

TypeScript로 강력한 웹 애플리케이션 만들기

Tue, 14 Jul 2026 00:00:00 +0900

자바스크립트는 매우 유연하고 쓰기 쉬운 언어이지만, 그 “유연성” 때문에 대규모 개발이 발생하면 예기치 않은 버그를 일으킬 수 있습니다. “문자열을 기대하고 있던 함수에 수치를 건네주었다” “API의 응답으로부터 존재하지 않는 프로퍼티에 액세스 해 버렸다”——이러한 에러는, 모두가 한 번은 경험이 있을 것입니다.

이 기사에서는 과제와 해결책이라는 접근법으로 왜 TypeScript가 현대의 웹 애플리케이션 개발에 필수적이라고 말할 수 있는지를 풀어 나갈 것입니다.

과제 : 실행할 때까지 버그를 모르는 공포

순수한 JavaScript로 작성된 응용 프로그램의 가장 큰 약점은 코드 오류가 “런타임 (런타임)“으로 처음 발생하는 것입니다. 브라우저에서 실제로 버튼을 클릭하거나 특정 화면으로 전환하지 않으면 오류를 알 수 없습니다. 이로 인해 QA 팀의 테스트 누출과 사용자의 결함보고를 통해 처음으로 버그를 알 수있는 매우 위험한 개발 프로세스가됩니다.

Next.js App Router의 기본 및 도입 이점

Thu, 09 Jul 2026 00:00:00 +0900

Next.js 13에서 도입되어 이제 표준이 된 “App Router”. 기존의 Pages Router에서 크게 개념이 바뀌었기 때문에, 아직 이행에 발을 디디고 있는 분도 있을지도 모릅니다. 이 기사에서는 App Router를 이해하기위한 기초를 단계별로 설명합니다.

1단계: 디렉토리 구조의 차이점 이해

기존의 Pages Router에서는 pages 디렉토리의 파일 이름이 그대로 URL 라우팅이 되었습니다(예: pages/about.tsx → /about).

App Router에서는 app 디렉토리를 사용합니다. URL 라우팅은 폴더 이름으로 결정되었으며 폴더에 항상 page.tsx라는 파일을 넣는 규칙으로 변경되었습니다 (예 : app/about/page.tsx → /about). 겉보기에는 귀찮아 보이지만, 이것에 의해 「라우팅에 관계가 없는 컴퍼넌트나 테스트 파일을, 같은 폴더내에 공존시킬 수 있다」라고 하는 큰 이점이 탄생했습니다.