최근 작성한 글
thumbnail
브릿지 패턴디자인 패턴

[디자인 패턴] 브릿지 패턴

브릿지 패턴(Bridge Pattern) 브릿지 패턴은 추상화 계층(Abstraction)과 구현 계층(Implementor)를 분리해서 독립적으로 확장할 수 있게 만드는 구조 패턴이에요. 추상화 계층을 기능 클래스 계층이라고 보기도 해요. 그래서 기능을 추가하고 싶으면 추상화 계층을, 구현을 추가하고 싶으면 구현 계층을 활용하면 되니 독립적으로 확장이 가능하게 되는 거에요. 브릿지 패턴 구조 Abstraction(추상화 계층, 기능 계층)과 Implementor(구현 계층)을 분리하여 이어주는 구조가 되기 때문에 브릿지 패턴이에요. 두 계층을 직접 묶지 않고, 중간에 다리를 놓아 서로 독립적으로 발전할 수 있도록 이은 거에요. 그림의 각 요소에 대해 설명해 볼게요. Abstraction (추상화 계층의 상위 역할, 기능 계층의 상위 역할) 역할: Client가 사용하는 추상 인터페이스로 내부에 Implementor를 참조하여 구현 일부를 위임해요. 특징: 어떤 Implementor를 사용할 지 모르지만, 단지 호출하여 기능을 만드는데 사용해요. 예시: 리모컨 -> TV가 삼성인지 LG인지 모르지만 "전원 키기", "전원 끄기"가 가능해요. RefinedAbstraction (추상화 계층의 구현 클래스) 역할: Abstraction에 정의된 operation()을 실제로 구현 및 확장해요. 여전히 Implementor를 사용해여 구현해요. 특징: Abstraction을 상속받기 때문에 기능 계층과 약한 결합을 가져요. 예시: LG 리모콘, 종합 리모콘 등.. Implementor (구현 계층의 인터페이스...
2025-11-14
0
0
4
thumbnail
클린 코드

[클린 코드] 4-5장 주석-형식 맞추기

클린 코드 이번 글에서는 좋은 주석 쓰는 방법과, 형식 맞추기 방법 들에 대해서 소개할게요. 4장. 주석 잘 달진 주석은 그 어떤 정보보다 유용해요. 하지만 근거 없는 주석은 코드를 이해하기 어렵게 만들어요. 그리고 오래 관리가 안된 주석은 잘못된 정보를 전달하기도 해요. 저자는 주석은 필요악이라 표현해요. 코드 자체에 표현력과 전달력이 있다면 주석은 거의 필요하지 않기 때문이에요. 즉, 나쁜 코드에 주석을 달은 경우라고 볼 수 있어요. 그래서 주석을 달기전에 먼저 코드로 의도를 표현할 방법이 없을지 생각해보는 것이 좋아요. 주석을 달면 본인이 표현력이 부족함을 인정하는 것과 마찬가지에요. 그러면 왜이렇게 주석을 미워할까요? 바로 주석이 거짓말하는 경우가 많아서에요. 고의적으로 거짓말하는 것은 아니지만, 주석이 오래될수록 코드에서 멀어지기 때문이에요. 또한 개발자가 주석을 유지 및 보수하는 것도 현실적으로 불가능하다고 여겨져요. 아마도 주석을 달아봤으면 알거에요. 언제 썼는지 기억이 안나요. 코드는 변화하고 진화해요. 여기 저기 옮겨다니기도 해요. 그리고 분열했다가 합쳐지기도 합니다. 그래서 주석이 코드를 따라가기 힘들어요. 주석은 나쁜 코드를 보완하지 못한다. 코드에 주석을 추가하는 가장 일반적인 이유는 코드 품질이 나쁘기 때문이에요. 모듈을 짜고 보니 짜임새가 엉망이고 알아먹기가 힘들어 주석을 달아야겠다는 결심을 하죠. 이럴 땐 "주석을 달아야겠다!"가 아니라 "코드를 정리해야겠다!"라고 말할 수 있어야해요. 표현력이 풍부하고 깔끔하며 주석이 거의 없는 코드가 복잡하고 어수선하며 주석이 많이 달린 코드보다...
2025-11-11
0
0
10
thumbnail
디자인 패턴컴파운드 패턴

[디자인 패턴] 컴파운드 패턴

컴파운드 패턴 오늘은 여러 패턴의 조합으로 문제를 해결하는 컴파운드 패턴에 대해서 알아봐요. 컴파운드 패턴은 딱 정해진 형식이 없어요. 단순히 여러 패턴을 조합하여 문제를 해결하는 것이에요. 대표적인 예로 MVC, MVP, VIPER과 같은 많은 아키텍처들이 있어요. 그런데 Head Frist 디자인 패턴 책처럼 한 단계씩 설명하기는 글 내용이 너무 길어질 것 같아요. 그래서 통째로 설명할 수 있게 예시 코드를 통해 설명하고자 해요. 컴파운드 패턴 예시 우선 컴파운터 패턴 예시 코드를 만들기 위해 배경이 필요해요. 피그마 기능을 컴파운드 패턴으로 구현해보자 저가 만들고 싶은 기능은 피그마처럼 화면에 요소를 추가하여 꾸밀수 있는 기능이에요. 생각한 기능들은 다음과 같아요. 기능 정의 화면에 삼각형, 사각형 같은 요소 추가가 가능하다. 추가된 요소는 이동 가능하다. 이동 했던 동작들은 다시 뒤로 되돌릴 수 있다. 여러 사람이 작업하기 때문에 요소에 대한 소유권이 필요하다. 그러면 각 기능을 위해 무엇이 필요할까요? 정리해봐요 필요한 코드들 Viewer에 삼각형, 사각형 등을 렌더링 해야한다. Viewer와 상호 작용 가능한 요소가 필요하다. 상호 작용을 통해 데이터의 수정(위치 이동)할 수 있는 기능이 필요하다. 데이터가 수정되면 수정된 데이터를 Viewer에 전달하여 렌더링할 수 있어야 한다. Viewer에서 요소를 이동시키려할 때 소유권을 가져 다른 사람이 함께 이동시키지 못하게 해야한다. 이동 했던 이력을 저장하여 되돌릴 수 있어야한다. 그러면 위 코드들을 보고 어떠한 패턴들을 사용해야할까요? 사람마다 다를...
2025-10-31
0
0
14
사이트 이용 통계
차트 로딩 중...
사이트 아키텍처
banner
banner
많이 본 글
thumbnail
ProseMirrorShikiNextJs

[블로그 소개] 프론트엔드 - 에디터

블로그 소개 – 에디터 안녕하세요. 첫 번째 블로그 글입니다. 저는 프로그래밍하면서 고민하고 해결한 과정을 기록하고 공유하기 위해 블로그를 만들었습니다. 글을 잘 쓰는 편은 아니지만, 수정·보완하면서 효율적으로 지식을 나눌 수 있도록 하겠습니다. 이번 글에서는 제가 직접 만든 블로그 에디터를 소개하려 합니다. 1달 가까이 다양한 에디터를 테스트했고, 결국 ProseMirror 기반 Tiptap을 선택했습니다. 팁탭은 확장성이 뛰어나고 Viewer를 JSON/Text 형식 모두 SSR 가능 Next.js & 백엔드와 궁합이 좋음 에디터 SSR 확장성 엔진 WYSIWYG Markdown RIch Text 기타 editor.js 🟡 ↗️ 자체 ✅ 🟡 ✅ 문서 좋음. Json 구조. react-md-editor ❌ ➡️ 자체 ❌ ✅ ❌ 이지윅 사용성 안좋음. toast UI ❌ ⬇️ ProseMirror ✅ ✅ ✅ 문서화 나쁨. 플러그인 적음. quill 🟡 ↗️ Delta ✅ 🟡 ✅ 문서 좋음. JSON 구조. TipTap ✅ ↗️ ProseMirror ✅ 🟡 ✅ 문서 보통. 기능 잘 나뉨. ProseMirror ✅ ⬆️ 자체 ✅ ❌ 🟡 문서 최고. 높은 러닝 커브. 👉 결론: 간단 기능 위주라면 Quill/Editor.js 추천. 하지만 커스텀 기능 많이 필요하다면 Tiptap/ProseMirror가 최적일 것입니다. 저의 에디터에 필요한 기능들의 기능들을 정리해 봤습니다. 기본 텍스트 편집 기능 글씨체 변경 (굵게, 밑줄, 기울임, 색깔, 배경색) 글머리 기호, 번호 기호, 체크 리스트 문단 좌, ...
2025-03-16
0
2
277
thumbnail
SentryNextJsCritical CSS

[블로그 소개] 프론트 엔드 - 성능 최적화

[블로그 소개] 프론트엔드 방문해주셔서 감사합니다. 1번째 글 이후 블로그의 마음에 안드는 부분 수정을 하느라 2번째 글 쓰기까지 많은 시간이 걸린 것 같습니다. 이번 글에서는 저가 어떤 방식들로 블로그를 최적화를 했는지 소개하려고 합니다. 우선 글을 읽기 앞서 함께(?) 축하할 일은 최적화 결과 Lighthouse 4가지 카테고리에서 모두 100점을 달성했다는 것입니다. 하하 이번 글에서 소개할 것은 성능에 영향을 끼치는 원인을 어떻게 찾았는지, 그리고 어떻게 최적화 했는지 소개드릴려고 합니다. 여기에 더해 Lighthouse로 점수로 측정되지는 않지만, [네트워크가 오류날 정도로 느린 상황]이나 [새로고침 상황에서 하얀색 깜박임으로 인한 불편한 상황]을 개선한 과정도 소개드리겠습니다. 우선 아래 사진은 최적화를 완전히 마치고 홈화면을 Lighthouse로 성능, 접근성, 권장사항, 검색엔진 4가지 카테고리의 점수를 측정한 결과들입니다. Lighthouse는 크롬 개발자도구의 Lighthouse탭에서 누구나 성능측정을 쉽게 할 수 있도록 만든 툴입니다. Lighthouse 점수 측정시 주의할 점은 사용자 네트워크, 컴퓨터, 브라우저 환경에 따라 다른 결과를 보여줄 수 있다는 점입니다. 대표적인 예로 ThirdParty Cookie를 브라우저에서 차단하지 않았거나, 네트워크가 느리면 성능 측정 결과가 달라집니다. 성능 측정할 때 뿐만 아니라 평소에도 브라우저 설정으로 써드파티 Cookie는 차단하시길 추천드립니다. Home 화면(어드민 로그인) Home 화면(일반유저 로그인) Home 화면(비 로그인) 어드...
2025-03-27
1
2
112
thumbnail
tsconfigmonorepoturborepo

[블로그 소개] 프론트엔드 - 구조 및 설정

[블로그 소개] 프론트엔드 블로그를 만들기 위해 여러 번 세팅을 시도했고, 그 과정에서 포기도 여러 번 했습니다. 다양한 시도 끝에 monorepo 구조로 구성하는 방식이 가장 깔끔하게 프로젝트를 나누고 사용하기에도 편하다는 결론에 도달했습니다. 단순히 폴더 구조만으로 기능을 구분하려 했을 때는 폴더가 지나치게 세분화되었고, 그렇다고 패키지들을 repo를 나누려 하면 관리하고 다른 앱에 적용하기 짜증납니다. 특히 에디터 기능을 포함하려다 보니 코드 양이 많아지면서 도메인과 코드가 섞이기 쉬웠습니다. 반면, 하나의 레포에서 모듈별로 분리하는 방식은 자연스럽게 도메인과 코드가 분리되며, 재사용성 및 사용성(개발자 경험)까지 확보할 수 있다는 점에서 확실히 장점이 있다고 느꼈습니다. 아래는 블로그 만들 때 사용한 Monorepo 구조입니다. 과거 폴더 구조 (tsconfig Reference 기능 사용) 현재 폴더 구조 (Just in Time packages 적용) 1.1 App과 Package 블로그 프로젝트에서 App은 스토리북, React Web, React Native 3개 입니다. 그리고 패키지는 Design System, Editor, Domain, Utils 4개와 ts와 esLint 설정을 위한 tsConfig, eslintConfig 2개로 구성했습니다. App React Web React Native Storybook Package DesignSystem Editor Domain Utils tsConfig esLintConfig 여기서 Domain을 별도로 분리한 목적은 좀더 API를 체계적으...
2025-04-13
0
0
65
좋아요 많은 글
thumbnail
Command Pattern

[디자인 패턴] 커맨드 패턴

[디자인 패턴] 커맨드 패턴 이번 글에서는 커맨드 패턴에 대해 설명하겠습니다. 커맨드 패턴은 요청(행위, 행동)을 객체로 캡슐화해서 요청을 매개변수화하는 패턴이다. (행동 패턴) 주로 요청을 보낸 객체와 요청을 수행하는 객체를 분리하고 싶을 때 사용한다. 에디터의 실행 기록을 저장하며 [redo/undo]를 구현하거나, 작업 큐를 구현하는데 많이 사용된다. 커맨드 패턴은 다음과 같은 요소들로 이루어져 있다고 보면 된다. 커맨드 객체 : 실제 실행될 동작을 구현한 클래스로 "리시버"의 메서드를 실행하는 객체이다. 리시버 객체 : 실제로 작업을 수행하는 객체이다. 인보커 객체 : 커맨드를 실행하는 주체이다. 클라이언트 : 커맨드 객체를 생성하여 인보커에 할당한다. 그리고 그 상관관계를 그림으로 나타내 아래와 같다. 커맨드 패턴을 설명만 들어서는 감이 안올 것 같다. 그래서 아래 간단한 요구사항을 커맨드 패턴으로 구현해보자. 요구사항 스위치 전원을 on/off하여 전등을 끄고 킬 수 있다. // Receiver: 실제 동작을 수행하는 객체 class Light { on() { console.log("💡 불이 켜졌습니다."); } off() { console.log(" 불이 꺼졌습니다."); } } // Command 인터페이스 (Invoker는 인터페이스에 의존하여 Command 객체 구현은 모름) interface Command { execute(): void; } // Concrete Command: 불 켜기 class LightOnCommand implements Comm...
2025-08-29
0
3
25
thumbnail
kernelOS

[운영체제] 운영체제와 커널

운영체제와 커널 컴퓨터의 응용 프로그램은 하드웨어에 접근할 수 있어야 한다. 그래야 하드디스크에 데이터를 저장하고 메모리에 프로세스를 올리고, CPU에서 그 메모리 정보를 가지고 데이터를 처리할 수 있다. 그리고 사용자는 GUI를 통해서 응용 프로그램을 실행할 수 있어야 한다. 그래야만 사용자와의 상호작용을 통해서 원하는 프로세스를 메모리에 올릴 수 있기 때문이다. 이러한 역할을 하는 것이 운영체제(OS)이다. 사용자 자원과 실행 단계를 계층적으로 커널 공간, 사용자 공간, 시스템 콜, 하드웨어로 나눌 수 있다. 사용자 공간은 시스템 콜 인터페이스를 통해 커널 영역에 접근할 수 있고, 커널 영역은 사용자 공간에서 사용한 시스템 콜 API에 따라 하드웨어를 조작하게 된다. 그런데 사용자 공간과 커널 공간이 나뉘어 있듯이, CPU도 사용자 모드와 커널 모드 2가지의 모드가 존재한다. 왜냐하면 사용자 모드에서 통제없이 하드웨어에 접근할 수 있으면 보안과 안정성에 문제가 생기며, 동일 자원에 여러 CPU가 접근할 때도 문제가 생길 수 있기 때문에 이를 특별히 관리할 필요가 있기 때문이다.아래 그림은 CPU가 이중 모드로 모드를 구분하여 명령어를 실행하는 그림이다. 응용 프로그램이 프리턴기를 쓰거나, 하드디스크에 입력하는 등의 커널 영역이 필요한 명령어를 사용하기 위해서 커널 모드에 진입하고, 다시 사용자 모드로 돌아온다. 1.1 운영체제 운영 체제는 컴퓨터 하드웨어와 응용 프로그램 사이에서 상호작용을 지원하고 관리하는 시스템 소프트웨어다. 운영체제는 하드웨어 자원(CPU, 메모리, 저장 장치 등)을 효율적으로 관리하...
2025-06-27
1
3
49
thumbnail
SentryNextJsCritical CSS

[블로그 소개] 프론트 엔드 - 성능 최적화

[블로그 소개] 프론트엔드 방문해주셔서 감사합니다. 1번째 글 이후 블로그의 마음에 안드는 부분 수정을 하느라 2번째 글 쓰기까지 많은 시간이 걸린 것 같습니다. 이번 글에서는 저가 어떤 방식들로 블로그를 최적화를 했는지 소개하려고 합니다. 우선 글을 읽기 앞서 함께(?) 축하할 일은 최적화 결과 Lighthouse 4가지 카테고리에서 모두 100점을 달성했다는 것입니다. 하하 이번 글에서 소개할 것은 성능에 영향을 끼치는 원인을 어떻게 찾았는지, 그리고 어떻게 최적화 했는지 소개드릴려고 합니다. 여기에 더해 Lighthouse로 점수로 측정되지는 않지만, [네트워크가 오류날 정도로 느린 상황]이나 [새로고침 상황에서 하얀색 깜박임으로 인한 불편한 상황]을 개선한 과정도 소개드리겠습니다. 우선 아래 사진은 최적화를 완전히 마치고 홈화면을 Lighthouse로 성능, 접근성, 권장사항, 검색엔진 4가지 카테고리의 점수를 측정한 결과들입니다. Lighthouse는 크롬 개발자도구의 Lighthouse탭에서 누구나 성능측정을 쉽게 할 수 있도록 만든 툴입니다. Lighthouse 점수 측정시 주의할 점은 사용자 네트워크, 컴퓨터, 브라우저 환경에 따라 다른 결과를 보여줄 수 있다는 점입니다. 대표적인 예로 ThirdParty Cookie를 브라우저에서 차단하지 않았거나, 네트워크가 느리면 성능 측정 결과가 달라집니다. 성능 측정할 때 뿐만 아니라 평소에도 브라우저 설정으로 써드파티 Cookie는 차단하시길 추천드립니다. Home 화면(어드민 로그인) Home 화면(일반유저 로그인) Home 화면(비 로그인) 어드...
2025-03-27
1
2
112