드디어 라이브러리로 만들었다. 2/4에 첫 배포도 했다.

이거 만들면 세계 70억 앵귤러 개발자가 환영해줄줄? 알았는데 그런건 없더라

HN, GN 등에 홍보글이라도 올려서 그나마 좀 weekly download가 있는듯? 이슈나 피드백이 올라오길 기대했는데 그런 것도 아직 없다..

주변에 앵귤러 개발자가 있다면 추천 및 즐겨찾기, 알림 설정까지~..

https://github.com/Ea-st-ring/ngx-locator

라이브러리로 만들면서 크게 달라진 점은,

Selector 기반 탐색에서 Angular 공식 API를 활용한 탐색으로 전환

기존

컴포넌트 파일의 selector를 읽어 스캔한 파일에서 경로를 찾는 방식

// todo.ts

@Component({
  selector: 'app-todo', // 이걸 읽어서 찾기!
  templateUrl: './todo.html',
  styleUrls: ['./todo.scss'],
})
export class TodoComponent {
...
}

지금

ng.getOwningComponent, ng.getComponent와 같은 앵귤러 공식 API를 활용하여 런타임 단계에 컴포넌트에 붙는 클래스네임을 가져오는 방식

// todo.ts

@Component({
  selector: 'app-todo',
  templateUrl: './todo.html',
  styleUrls: ['./todo.scss'],
})
export class TodoComponent { // 이걸 읽어서 찾기!
...
}

이점

• 런타임 인스턴스 기반 매칭이라는 점, 프레임워크가 보장하는 API를 사용한다는 점에서 더욱 안정적.

한계점

• 중복되는 클래스네임에 대해서는, 현재 URL 경로와 파일 경로를 비교해서 점수를 부여하고 가장 관련성이 높은 파일을 선택하는 애매한 로직이 있다.(=정확도가 100%는 아님)
• SSR 환경에서 제한된다.

근황 그리고 앞으로

출시 5일차..weekly downloads 66인 응애 라이브러리지만~ 점점 더 angular 개발자들이 찾아보고 사용하지 않을까? 라는 기대감을 품고 있다.

개인적으로는 아직 초반 세팅 과정이 매끄럽지 않은 것 같아서, 관련 flow를 보수할 예정이다. Maintain하는 라이브러리가 있다는 건 제법 즐거운 일인 것 같다 아직 아무 피드백도 못 받았지만 ! !

사이트 호스팅을 제공하는 회사(shopify, 카페24, 아임웹 등) 특성상 제공 받은 업체의 사이트를 SSR로 서빙할 때, 적절한 메타 태그와 구조화된 데이터를 삽입하는 것은 중요하다.

SEO 측면은 말할 것도 없고, 제대로 설정해두지 않으면 다음과 같은 문제가 발생할 수 있다. 우리 회사 이름을 딩딩, 호스팅 제공받는 업체 이름을 탐조월드라고 가정, 구글에 탐조월드를 검색했으나, 아래처럼 우리 회사 이름이 뜰 수도 있다..

전개

그래서 구조화 데이터를 추가하여 이를 보강하는 작업을 해주다 문제가 발생했다.

async start(){
     /************** 새로 추가한 로직 ****************/

     // 사이트 관련 정보를 fetch하고, 구조화 데이터를 삽입한다.
     const {siteName, siteUrl} = await this._retrieveSiteFullUrl();
     this._updateSchemaOrgWebsite({ siteName, siteUrl });

     //--------------------------------------------/

    this.router.events
    .pipe(filter((event) => event instanceof NavigationEnd))
    .subscribe((event) => {
       void 메타태그삽입(e.url);
    }
  }

 /**
  * document body에 마이크로데이터(구조화 데이터) 추가하는 로직, 간소화함
  */
  private _updateSchemaOrgWebsite({ siteName, siteUrl }: { siteName: string; siteUrl: string }): void {
      const schemaDiv = ...
      const body = this.renderer.selectRootElement('body', true);
      this.renderer.appendChild(body, schemaDiv);
  }

위와 같이 코드를 짜니까, 구조화 데이터는 추가가 되는데 메타 태그 삽입이 안됐다. 처음에는 문제가 뭐지? renderer에 문제가 있나? 싶었는데 아니었다. 문제는 간단한 거였는데..사수님이 알려주시기 전까지 정확히 문제가 뭔지도 몰랐다.

• renderer -> Angular에서 SSR document를 조작하도록 돕는 API

절정

문제는 await this._retrieveSiteFullUrl(); 호출 시점에 있었다.

async start(){

      // 여기서 await을 소비하는 동안 NavigationEnd 이벤트가 일어남!
     const {siteName, siteUrl} = await this._retrieveSiteFullUrl();
     this._updateSchemaOrgWebsite({ siteName, siteUrl });

    // NavigationEnd 이벤트가 이미 일어난 이후 구독을 시작해서,
    // 메타 태그 삽입이 이루어지지 않음
    this.router.events
    .pipe(filter((event) => event instanceof NavigationEnd))
    .subscribe((event) => {
       void 메타태그삽입(e.url);
    }
  }

정리하면,

1. 신나게 await this._retrieveSiteFullUrl() 하는 동안 첫번째 NavigationEnd가 일어났다.
2. 구독 발생 시점 이전에 일어났고, 이미 일어난 NavigationEnd 이벤트를 감지하는 방법도 딱히 없었기 때문에 처음에 메타 태그 삽입 로직이 아예 일어나지 않는다.
3. 그래서 다른 페이지로 navigate하면 그제서야 잘 반영된다.

알고나면 되게 기본적이고 간단한 것인데... 문제를 너무 어렵게 본 것 같다. 그럼 해결은 어떻게 할까?

결말

1. router 구독 선언을 항상 start 최상위에 둔다.

async start(){
    // 항상 최상위에
    this.router.events
    .pipe(filter((event) => event instanceof NavigationEnd))
    .subscribe((event) => {
      void 메타태그삽입(e.url);
    }

    await 어쩌구();
  }

문제점 : 혹여혹여혹여혹여혹여나 subscription 이전에 꼭 실행해야 하는 작업이 있으면 어떡할 것인가?

2. rxjs의 startsWith 사용

startsWith는 선언 시점에 무조건 값을 하나 내뱉어준다.

async start(){
    await 어쩌구(); // NavigationEnd 발생!

     this.router.events
      .pipe(
        filter((e): e is NavigationEnd => e instanceof NavigationEnd),
        startWith({ url: this.router.url, urlAfterRedirects: this.router.url } as NavigationEnd),
      // 현재 url로 값을 무조건 뱉으면, 이미 일어난 걸 감지 못하더라도 올바른 url을 획득 가능
      )
      .subscribe((e) => {
        void 메타태그삽입(e.url);
      });
}

문제점: 처음 발생하는 NavigationEnd를 잘 감지하는 케이스의 경우에는 this.router.url이 비어 있기 때문에 메타 태그에 이상한 값이 삽입될 수 있다. 그러나 바로 NavigationEnd가 일어나니 크게 문제는 없다. 그러나 찜찜해. . . .

3. 더 이른 시점에 구독해버리기

  private navigationEndReplaySubject = new ReplaySubject<NavigationEnd>(1);
// 1은 버퍼 사이즈, 저장할 이벤트 수

constructor(...) {
    // constructing 시점부터 NavigationEnd 구독하여 저장
    this.router.events
      .pipe(filter((e): e is NavigationEnd => e instanceof NavigationEnd))
      .subscribe((e) => this.navigationEndReplaySubject.next(e));
 }

 async start(){
     await 어쩌구();

     // 여기서 구독을 이어가면, 이전 이벤트가 일어나더라도 버퍼에 남아있기 때문에 놓치는 값 없이 수행 가능!
     this.navigationEndReplaySubject.subscribe((e) => {
         void 메타태그삽입(e.url);
    });
 }

4. 그냥 구독하는 코드 내부에서 해버리기

async start() {
    this.router.events
    .pipe(filter((event) => event instanceof NavigationEnd))
    .subscribe(async (event) => {
      if (!중복) {
        await 어쩌구();
        중복 = true;
      }

      void 메타태그삽입(e.url);
    }
}

방법은 또 더 많겠지만 이것저것 알아본 건 여기까지..

느낀 점

요즘은 AI 코드 리뷰를 하는 일이 잦다보니, 코드를 읽고 생각하는 집중력이 떨어지는 것 같다. 차근히 코드의 흐름을 잘 살펴보자. 늘 기본에 충실히... 도움 많이 된다

미러링 서비스란?

웹사이트를 편집하면서 편집중인 화면이 모바일에서 어떻게 보이는지 실시간으로 보고 싶을 때 이용 가능한 서비스이다. 예를 들어 피그마 앱에도 해당 기능이 있는데, 디자인하며 실시간으로 스마트폰에서 비춰지는 모습을 확인하는 것이다.

기술 스택 정하기

우선 미러링 서비스를 위해서는 앱과 웹 사이 연결이 이루어져야 한다. Firebase를 이은 차세대 강자 Supabase의 Realtime 서비스를 기존에도 활용하고 있었기 때문에, 이번에도 사용하기로 했다.

필요한 요구사항은,

1. 앱과 웹의 미러링 상태 상호 구독
2. 블록*이 변경될 때 정보를 웹 -> 앱에 전달한다.
3. 블록 변경 정보뿐 아니라, 블록 편집 정보를 웹 -> 앱에 전달한다.

블록: 웹사이트 편집 간 하나하나의 섹션을 블록이라고 부른다. 헤더, 히어로, 헤더, 상품, 공지사항 등등.. 편집 정보: 캐러셀 블록을 편집중이라면 몇 번째 슬라이드를 편집중인지 등

세 가지 방법이 있었다.

1. Realtime DB(블록 변경 상태) + Presence Service(미러링 , 블록 편집 상태)
2. Presence(미러링, 블록 편집 상태) + Broadcast Service(블록 변경 상태)
3. RealtimeDB Only

• Broadcast: 클라이언트 간 임의의 메시지를 실시간으로 주고받는 PUB/SUB 브로드캐스트 채널. • RealtimeDB: Postgres의 테이블 변경사항을 실시간으로 스트리밍 • Presence: 같은 채널에 접속한 사용자들의 온라인 상태·참여 정보(존재 상태)를 추적하는 기능, 피그마에서 접속되어있는 사용자 정보를 보는 것과 동일한 개념이다.

편집 정보를 주고 받는데 갑자기 웬 Postgres changes가 나오는지 의아할 수 있겠는데, 정보를 잃어버리지 않기 위한 목적이었다.

예를 들어 Broadcast나 Presence는 폰이 시간이 지나 잠금 상태가 되거나, 백그라운드 상태가 되면 연결이 끊길 수 있다. 이외에도 와이파이 상태 불량 등 연결이 끊어질 수 있는 많은 케이스가 존재하고, 이는 정보의 불일치를 불러일으키게 된다.

그래서 웹에서 DB에 정보를 넣어두면, 앱에서 정보를 받아오는 식으로 구현하면 이를 해소할 수 있다. Mermaid를 사용하여 그려보면 이런 느낌이다.

그러나 나는 DB를 사용한다는 게 뭔가뭔가였다. 결국 우리가 필요한 것은 블록들의 최종 상태이며, 블록이 변해가는 중간 과정까지 읽어와야 할 필요가 있나? 싶었다. 또한 실시간 미러링 정보 또한 최신 상태가 가장 중요한 것이고, 누가 나갔다 들어왔는지, 미러링을 켜둔 상태인지 아닌지 과거의 기록은 필요하지 않다고 생각했다. DB 사용 -> 불필요한 오버헤드만 늘어난다고 생각했기 때문에 Presence + Broadcast Service를 사용하는 것을 건의드렸고, 회의실에 모여 모든 요구 사항을 만족하는지 1-2시간 정도 얘기를 나누게 되었다.

1. 에디터(뷰어)에서 미러링 버튼을 눌렀을때 뷰어(앱)에 메시지가 전달되어야함. 앱은 이때 꺼진 상태였다가 다시 연결될 가능성 있음

2. 에디터에서 페이지 뷰를 바꾸었을때 이 상태가 뷰어에 전달되어야함. 앱은 이때 꺼진 상태였다가 다시 연결될 가능성 있음

3. 에디터에서 특정 블록에 대해 slide를 바꾸었을때 이 상태가 앱에 전달되어야함. 여러개의 블록의 슬라이드가 각각의 값을 가지고 있을 수 있음. 앱은 이때 꺼진 상태였다가 다시 연결될 가능성 있음

4. 뷰어가 먼저 미러링을 눌렀을때, 에디터가 켜진 상태라면 미러링이 시작되어야함

5. 뷰어에서 의도적으로 미러링을 닫았을때(미러링 나가기 버튼), 에디터에서는 이를 인지할 수 있어야함. 반대도 마찬가지.

6. 유저 액션 없이 확실히 한쪽의 커넥션이 끊겼다고 판단될때(앱 강제 종료 등). 일정시간 후 다른 한쪽에서는 이를 인지할 수 있어야함.

말고도 정말 여러 케이스들이 있는데...(웹에서 다중 탭 켜져있는 경우? 앱이 여러 디바이스로 여러 개 켜져있는 경우?) 이건 너무 길어지니 다음 글에 적겠다..

일단은 여러 논리 검증을 통해 Presence + Broadcast Service로 충분히 가능할 것 같다! 는 결론을 내렸다.

이후 결정해야하는 것은 Presence에 각각 클라이언트(뷰어, 에디터)는 몇 개의 미러링 상태를 지니고 있어야 하는가?이다.

interface EditorPresenceState {
  mirroring_state: 'mirroring' | 'idle' | 'rejected' ...
}

에디터에서 미러링이 켜져있는 상태이고, 이후에 뷰어가 접속한 상태라면 "미러링을 연결하시겠습니까?" 모달을 띄워야 한다. 아니오를 누르면 그 이후에는 뷰어가 다시 미러링 연결을 누를 때까지 모달이 떠서는 안된다.

뭐 이런 여러 UI 플로우와 앞서 나열한 케이스들에 따라 필요한 상태값 개수가 달라질 수 있다. 과연 내가 내린 결론은 무엇이었을까?

다음 글에 계속 . . .

"런타임에 컴포넌트 Tree만 보고 컴포넌트의 파일 위치를 얻어내기"는 사실상 Angular 자체만으로는 불가능했다. 이러니 아무도 안 만들었지..

정확히는 모든 "앵귤러 프로젝트"로 범위를 설정하니 너무 막히는 부분이 많았다.

이를 사내 프로젝트로만 한정한다면? 80억 앵귤러 개발자들의 찬사를 포기한다면? 먼저 사내용으로 개발 후에, 지금 당장이 아닌 나중에라도 부자가 되기로 마음먹는다면?

LocatorJs For Angular, 그리 불가능해보이지만은 않는다

다시 시작

크롬 익스텐션은 때려친다. 어차피 우리만 쓸 것이다. (일단은..) 사내 라이브러리로 만들까도 고민해봤지만 어차피 사내 앱 프로젝트는 여기저기 분리되어있지 않고, 메인 APP들이 모노레포로 구성되어 있기 때문에 레포에 직접 구성하는 것이 낫겠다고 판단했다.

파일 위치 알아내기

이게 가장 힘든 점이었는데, 사내 프로젝트에 코드를 작성하게 되면서 파일을 돌며 component map을 하나 생성하는게 제일 간단했다. 이것저것 다 시도해봐도 이게 가장 정확도가 높았다 (당연히도).

모든 파일을 돌면서 생성하면 너무 오래 걸리지 않을까?

생각보다 얼마 안 걸린다. 추가로 캐싱 최적화를 통해 최초 1회를 제외하고는 빠르게 작업을 수행할 수 있었다. (최초 실행 시. 1-2초, 이후 500ms 내외) 컴포넌트 파일이 천 개가 넘어가도 이 정도니까..적당한 규모의 프로젝트에는 대부분 대응 가능해 보인다.

구조

전체적인 구조는 다음과 같이 잡아준다.

devtools/ ├── cmp.scan.ts # 컴포넌트 트리 스캔 로직 ├── angular-locator.ts # 클라이언트 ├── file-opener.js # 서버 └── README.md # 설명

cmp.scan.ts

LocatorJS의 경우 컴포넌트를 클릭하면 해당 컴포넌트 파일(e.g. LoginComponent.ts)로 이동한다. 반면 앵귤러에서는 크게 두 가지 선택지가 있다.

• html 템플릿 파일
• ts 파일

cmp.scan.ts에는 ts 파일을 스캔하여 해당 파일의 메타데이터를 저장하기 위한 로직이 담겨있으며. 최초 실행 및 변화 감지 시에 실행된다.

앵귤러는 MVW (Model-View-Whatever) 패턴이라고 보통 불리우고, 우리는 대부분 MVVM 패턴으로 구성되어 있다. 쉽게 말하면 컴포넌트 별로 HTML 파일 하나, TS 파일 하나씩 알아내면 된다는 것이다.

코드를 왕창 적어놓으면 별로 읽고 싶어지지 않으니 workflow를 적어보겠따

초기화

• open-in-editor.config.json 설정
• TypeScript 파일들을 AST로 로드 (ts-morph 이용)

open-in-editor.config.json에는 다음과 같은 내용을 적어준다.

• 스캔에 포함 / 미포함시킬 디렉토리
• 파일을 열 IDE (cursor, claude code, webstorm 등)
• 서버 port

// open-in-editor.config.json
{
  "port": 4123,
  "editor": "cursor",
  "fallbackEditor": "webstorm",
  "scan": {
    "includeGlobs": ["projects/**/*.{ts,tsx}"],
    "excludeGlobs": ["**/node_modules/**", "**/dist/**", "**/.angular/**"]
  }
}

ts-morph 라이브러리를 통해 컴포넌트 스캔 시에 구문 트리(Abstract Syntax Tree)를 만들어 클래스, 함수, 인터페이스 같은 걸 코드에서 직접 찾아낼 수 있다. TS 코드 접근 및 조작이 용이해진다는 말.

예시

import { Project } from 'ts-morph';


const project = new Project();

project.addSourceFilesAtPaths(includeGlobs); // 스캔 범위 설정

const sourceFiles = project
  .getSourceFiles()
  .filter(
    (sf) =>
      !excludeGlobs.some((x) =>
        sf.getFilePath().includes(x.replace('**/', '')),
      ), // config 설정에 따라 제외할 파일들은 제외시켜준다
  );

스캔 최적화

컴포넌트 스캔은 최초 프로젝트 실행 시, 그리고 런타임 변경 감지 시에 실행한다.

변경이 감지되었을 때 항상 모두 다시 스캔하면 짜치니까.. node fs에서 제공하는 mtimeMs(마지막 파일 수정 시간)을 가지고 다시 스캔할지 말지를 결정한다. 혹시 파일이 삭제된 경우 에러 케이스도 처리해준다.

• 변경 감지: 파일 수정시간 비교
• 조기 종료: 변경사항 없으면 스캔 건너뛰기

function getFileStats(filePaths: string[]): Record<string, number> {
  const stats: Record<string, number> = {};
  for (const filePath of filePaths) {
    try {
      const stat = fs.statSync(filePath);
      stats[filePath] = stat.mtimeMs;
    } catch {
      // 파일이 삭제된 경우
    }
  }
  return stats;
}

const filePaths = sourceFiles.map((sf) => sf.getFilePath());
const currentStats = getFileStats(filePaths);
const previousCache = loadCache();

// 변경된 파일 확인
const hasChanges = filePaths.some(
  (filePath) =>
    !previousCache[filePath] ||
    previousCache[filePath] !== currentStats[filePath],
);

// 새로운 파일, 삭제된 파일 확인
const cachedPaths = Object.keys(previousCache);
const hasNewOrDeletedFiles =
  filePaths.length !== cachedPaths.length ||
  filePaths.some((path) => !previousCache[path]) ||
  cachedPaths.some((path) => !currentStats[path]);

if (!hasChanges && !hasNewOrDeletedFiles && fs.existsSync(outFile)) {
  process.exit(0);
}

컴포넌트 추출 및 결과 생성

이 뒤로는 별 거 없다. 앵귤러의 @Component 데코레이터를 확인하고, 같이 작성되어 있는 메타데이터(selector, templateUrl, styleUrls) 등을 절대 경로로 변환하여 저장한다.

결과는 component-map.json에 고이 저장해둔다. 이 때 캐시도 같이 업데이트한다.

아래와 같은 메타데이터들이 저장되어, 에디터에서 파일을 열 때 사용하게 된다.

{
  "generatedAt": "2025-01-15T10:30:00.000Z",
  "byClass": {
    "HeaderComponent": "/abs/path/header.component.ts",
    "FooterComponent": "/abs/path/footer.component.ts"
  },
  "bySelector": {
    "app-header": "/abs/path/header.component.ts",
    "app-footer": "/abs/path/footer.component.ts"
  },
  "detail": {
    "HeaderComponent": {
      "className": "HeaderComponent", // 클라이언트에 노출할 정보
      "selector": "app-header", // 이거 가지고 찾을 거다
      "filePath": "/abs/path/header.component.ts",
      "templateUrl": "/abs/path/header.component.html",
      "styleUrls": ["/abs/path/header.component.scss"],
      "isStandalone": false
    }
  }
}

file-opener.js

클라이언트와 에디터를 연결하는 브릿지 역할 express 서버다. 클라이언트에서 http 요청을 날리면, 해당 요청에 맞게 에디터에서 파일을 연다.

에디터 설치 여부 등을 확인하고, 클라이언트에서 요청한 파일을 여는 로직이 작성되어 있다. 파일 열기만 하면 아쉬우니까 html 템플릿 파일을 여는 경우에 해당 요소가 있는 line을 탐색, 해당 라인을 열어주도록 로직을 추가했다.

어차피 regex가 대부분이라 구체적인 로직은 생략.

function findBestLineInFile(filePath, searchTerms) {
  try {
    const content = fs.readFileSync(filePath, "utf8");
    const lines = content.split("\n");
    const scores = new Array(lines.length).fill(0);

    // 각 검색어에 대해 점수 계산
    searchTerms.forEach((term, termIndex) => {
      const weight = Math.max(1, searchTerms.length - termIndex); // 앞쪽 검색어에 더 높은 가중치 부여

      lines.forEach((line, lineIndex) => {
        const lowerLine = line.toLowerCase();
        const lowerTerm = term.toLowerCase();

        if (lowerLine.includes(lowerTerm)) {
          // term에 대해 exact 매칭,단어 경계 매칭, 시작 부분 매칭을 통해 가중치 부여
          // searchTerm이 "header"일때 
          // "header"가 포함된 줄에 가장 높은 점수, 
          // "my-header"와 같은 경우 그 다음으로 높은 점수...
        }
      });
    });

    // 가장 높은 점수의 라인 찾아 반환
    let bestLine = 1;
    let bestScore = 0;
    scores.forEach((score, index) => {
      if (score > bestScore) {
        bestScore = score;
        bestLine = index + 1; // 1-based
      }
    });

    return bestScore > 0 ? bestLine : 1; // 없으면 첫 줄에서 열기
  } catch (e) {
    console.warn(`[file-opener] Failed to search in file: ${e.message}`);
    return 1;
  }
}

angular-locator.ts

컴포넌트를 찾아 file-opener.js에 에디터를 열어달라고 요청을 보낸다. 제공되는 옵션은 아래 세 가지다.

• Alt + hover (컴포넌트 이름 노출)
• Alt + Click (html 파일 열기 요청)
• Alt + Shift + Click (ts 파일 열기 요청)

다음과 같은 로직들이 작성되어 있다.

1. file-opener.js 서버에서 컴포넌트 맵 미리 받아오기
2. EventListner 등록 + 각 로직 작성 (호버 시 효과, 클릭 시 피드백 등)
3. 요소 클릭 시 컴포넌트 selector를 찾아 file-opener.js에 http 요청

Angular 컴포넌트는 main-header 와 같이 "-" 가 포함되어 있는 선택자 패턴을 사용한다. selector가 main-header면 컴포넌트 트리에도 <main-header> 와 같이 노출되어 있다. 이걸 가지고 앵귤러 컴포넌트인지 아닌지를 알아낸다.

• <div>, <h1>, ... -> x
• <main-header>, <my-app> -> o

실행

nodemon 라이브러리를 설치, 아래와 같이 package.json에 script를 추가해준다.

"cmp:scan": "ts-node -P tsconfig.tools.json devtools/cmp.scan.ts",
"cmp:watch": "nodemon --delay 2.5 -e ts,html -w projects --ignore '**/node_modules/**' --ignore '**/dist/**' --ignore '**/*.spec.ts' --ignore '**/*.test.ts' -x \"npm run cmp:scan\"",
"dev:opener": "node devtools/file-opener.js",

cmp:watch + cmp:scan

• 루트 폴더에서 .ts, .html 파일 변경이 일어나는지 추적하고, 변경이 있으면cmp.scan.ts를 실행

dev:opener

• 파일 열기 서버를 실행시킨다. 우리 프로젝트에서는 4123 포트에서 실행되도록 했다.

개발 서버와 포트 번호가 다르기 때문에 CORS 에러가 발생할 수 있다. 개발 서버를 열 때 다음과 같이 proxy 설정도 추가해줬다.

// proxy.config.json
{
  "/__open-in-editor": {
    "target": "http://localhost:4123",
    "secure": false,
    "changeOrigin": true
  },
  "/__open-in-editor-search": {
    "target": "http://localhost:4123",
    "secure": false,
    "changeOrigin": true
  },
  "/__cmp-map": {
    "target": "http://localhost:4123",
    "secure": false,
    "changeOrigin": true
  }
}

전체 workflow는 아무튼 다음과 같다. (고맙다 커서야..)

테스트

• IDE: Cursor

• IDE: WebStorm

가끔 Line matching이 제대로 이루어지지 않아 그냥 컴포넌트의 첫줄로 갈 때도 있지만, 대체로 잘 작동한다.

하면서 느낀 점은 충분히 라이브러리화까지는 가능할 것 같다. 그러나 유저가 수행해야할 작업이 좀 있다는게 조금 불편한 것 같다.(config 파일 작성, 프로젝트 root 지정, script 추가 등등..) 그래도 쓸 사람이 있으려나

다음에는 라이브러리로 만들어서 npm 배포를 한 번 해보자

모델 선정

우선 AI 이미지로 무엇을 할 지에 따라 어떤 모델을 사용할지 달라진다. 무작정 인기 많은 모델만 사용할 게 아니라, 요구사항과 상황에 맞는 모델을 잘 선택해야 한다. 나같은 경우에는 아래와 같은 작업들이 필요했다.

• Text to Text Generation
• Text to Image Generation
• Image background edit

선정 기준

모델을 고를 때는 아래와 같은 사항들이 중요하다.

• 기능 요구사항을 만족하는지
• 비용이 적절한지
• 속도가 너무 느리진 않은지

위 사항들을 쉽게 탐색, 비교해보기 위해 아래와 같은 사이트들을 이용해볼 수 있다.

도움이 되는 사이트

Imarena

익명의 AI 모델 두 개를 가지고 결과물을 만들어보고, 잘 만들어진 쪽에 투표한다. 어떤 모델이 많은 득표를 했는지 확인할 수 있다.

• https://lmarena.ai/

이를 참고하여 테스트해볼 모델들을 결정 / 탐색해볼 수 있다. 많은 득표 수를 받은 모델들도 확인 가능하다.

Replicate

https://replicate.com/

강력 추천한다. 모델 탐색하기에 굉장히 편하고, replicate 자체 토큰을 충전하여 여러 모델을 직접 실행하며 비교할 수 있다. 인기 있는 모델들이 많이 준비되어 있으니 여기서 한 번 찾아보고, 마음에 드는 게 없으면 그 때 다른 모델들을 탐색해보면 된다.

모델 탐색

Playground 제공

HuggingFace

https://huggingface.co/

AI 모델계의 깃허브라고 불리는 허깅페이스다. 모델 탐색하기에도 괜찮은 것 같고(엄청 많다), 모델을 직접 훈련시킬 생각이 있다면 한 번 살펴보면 좋겠다. 물론 Replicate에서도 훈련 기능이 있으니 더 좋아보이는 쪽을 고르면 되겠다.

내가 선택한 모델

여러 모델을 테스트해보면서 모델별 느낀 점들을 정리할까 했는데, 어차피 1달만 지나도 새로운 모델들이 쏟아져 나와서 지금 적어놔도 크게 의미가 없을 확률이 높다고 생각한다. 그냥 어떤 모델을, 왜 골랐는지에 대해서만 적겠다.

Text Model

이미지 생성 프롬프트를 생성(?)하기 위해 Text 모델이 필요했다. User Input을 받아서, 이를 이미지 프롬프트로 확장시키는 개념을 택했는데, 예를 들어 유저가 아래의 값들을 입력했다면

// Input
{
  domain: "커피샵",
  color: "오트밀",
  mood: "모던 & 미니멀",
}

// Output
"테이블 위에 모던 & 미니멀한 커피 머신이 배치되어있고, 
앞에는 컵이 오트밀 색상의 행주 위에 놓여있다. ~~~..."

이에 걸맞는 이미지 프롬프트를 뱉도록 하는 것이다. (물론 다 영어) 요구사항에 걸맞는 프롬프트를 안정적으로 도출하기 위해 아래 Text To Image 모델과 함께 테스트를 하며 few-shot을 확보해두면 좋다.

가장 무난한 gpt-4.1 모델과 gpt-5.0 중 4.1을 골랐다. 비용과 성능은 비슷하지만 5.0은 너무 시간이 오래 걸리는게 문제였다.

더욱 간단한 작업에는 gpt-4.1-nano도 추천한다. nano인만큼 가격이 저렴하고 속도가 빠르다. 나 같은 경우에는 예를 들어 잘못된 input이 들어왔을 때 검증하는 용도 등으로 사용했다.

Text to Image Generation

수많은 후보들을 뚫고 구글의 Imagen4 모델을 선택했다. 유력한 상대는 flux-context-pro 모델이었는데, Imagen4가 더 빨랐고, 퀄리티도 우세했다. (비용은 동일)

사실 요즘 핫한 nano-banana로 다시 테스트해본다면 결과가 어찌될 지 모르겠다

아래는 위 Input을 가지고 생성한 결과이다. Hero 섹션에 쓰일 이미지로 이 정도면 제법 괜찮아 보인다.

Image Background edit

위와 같이 누끼가 따져 있는 특정 Object 이미지를 유저가 갖고 있다고 가정해보자.

이 이미지를 가지고 AI에 부탁하여 단색 혹은 나무 테이블, 부엌 등 다채로운 배경으로 바꾸고 싶다.

이 때 중요한 것은

• 원본 이미지가 깨지지 않을 것 (Object에 텍스트가 있는 경우 더욱 민감)
• 자연스러운 배경과 그림자를 생성할 것

이런 점들이 있다.

이외에도 요구사항에 맞게 여러 가지를 고려했을 때 가장 적합한 모델은 Photoroom에서 제공하는 API였다.

https://www.photoroom.com/api

bria에서 제공하는 api도 쓸만하다. https://bria.ai/ai-product-shot-editing

욕실 세면대를 요청했을 때 만들어준 이미지. 글자도 깨지지 않고, 배경도 적절하다.

프롬프트 작성

1. 부정보다는 묘사를 사용하기

내가 스니커즈를 만들어달라고 했더니 나이키 로고가 떡하니 박힌 이미지를 만들어준다. 이를 방지하기 위해 다음과 같이 추가했다고 하자.

Must not Include visual elements like logo, text on the product.

"코끼리를 생각하지 말라"고 하면 사람은 코끼리를 머릿속에 떠올리게 된다. AI도 똑같은 것 같다. 로고를 대문짝만하게 박아서 이미지를 만들어줬다.

"~~를 하지마라" 와 같은 프롬프트가 먹힐 때도 있지만, 그게 잘 안될 때는 다음과 같이 해보자.

Product with clean and simple surface, ~~

"로고를 만들지마!" 보다는 "깨끗하고 간결한 표면을 만들어줘." 라고 요청하는 것이 더욱 잘 먹힐 때가 많다. 굉장히 중요한 점이니 명심..

2. 단어 대체

이미지의 배경을 천 질감으로 바꾸고 싶다. 간단히 입력해본다.

Background is a plain fabric surface in ivory color...

천이 물론 잘 생성되긴 했는데, 뭔가 좀 아쉽다. 미사여구를 여럿 붙여봐도 보통 결과는 비슷하다. 단어에 따른 이미지 훈련 셋이 정해져 있어 결과가 크게 달라지지 않는다. 이럴 때 "fabric" 이라는 단어를 유사 단어로 대체해보는 시도가 도움이 될 때가 많다. 예를 들어 "천"을 "바삭한 침대 시트"로 바꾸게 되면 결과는 다음과 같이 달라진다.

미묘한 차이로 보일 수도 있지만 이 차이를 조금씩 줄여나가는게 이미지 프롬프팅의 핵심이다. 원하는 느낌이 나지 않을 때는 단어 대체를 통해 새로운 결과를 만들어보자.

3. 좋은 프롬프트를 작성하기 위해 API 제공처의 공식 홈페이지 예시나, Documentation, 파라미터 등을 다 뒤져보자.

Imagen 홈페이지를 들어가보면 예시 이미지와 함께 프롬프트가 나열되어 있다. 프롬프트들이 어떤 체로 작성되어 있는지 확인하고, GPT에게 예시로 주어 이런 식으로 적어 라는 느낌을 학습시키는 것도 퀄리티를 높이는 데 도움이 된다.

Photoroom API 같은 경우에는 좋은 프롬프트를 작성하는 팁 등이 꼭꼭 숨겨져 있다.

https://docs.photoroom.com/image-editing-api-plus-plan/ai-backgrounds#how-to-write-a-high-quality-prompt

4. 일관성 유지하기

이미지 생성에서 중요한 점은 일관성을 유지하는 것인데, 훈련을 시킬 수 있다면 좋겠지만 그렇지 못한 경우 다음과 같은 방법들을 고려해볼 수 있다.

• few-shot 제공
• 템플릿형 프롬프트 구성 (GPT에게 프롬프트를 일정한 템플릿에 맞춰 생성시키도록 하기)
• 모델에 일관성 혹은 가이드를 주는 seed, guidance_image 등의 파라미터 존재 여부 확인

5. 테스팅 환경 구성

Replicate에서 테스트를 하다보면 여러 모델을 한꺼번에 비교하거나 여러 이미지를 넣어 동시에 결과를 보고 싶을 때가 있다. 그럴 때는 그냥 AI에게 부탁해서 나만의 테스트 Playground를 구성해보자. 정말 많은 테스트를 해보면서 최적의 파라미터를 찾아나가는 과정이기 때문에 쾌적한 테스트 환경은 중요하다.

아래는 Cursor로 구성한 테스트 환경이다. 이거 쓰고 DX 800% 향상했다.

프롬프트를 잘 작성했다면 이제 LangGraph를 이용하여 코드를 작성할 차례다. 너무 길어져서 이건 다음 편에. . .

리액트 개발을 하면서 굉장히 편리하게 사용했던 크롬 확장 프로그램 LocatorJS...

아쉽게도 해당 익스텐션은 Angular에서 지원되지 않는다. Angular 개발을 시작한지도 벌써 두 달, LocatorJS가 있으면 DX가 크게 향상될 것 같다는 생각이 들었다.

우선 LocatorJS에서 Angular를 지원할 예정이 있을까?

이슈가 올라온지도 약 3년이 흘렀다.. 지원을 기대하기는 쉽지 않아보였다.

그러면 직접 한 번 만들어보자. 잘 만들기만 하면...

1. DX가 크게 향상된다.
2. 전세계 8억 Angular 개발자에게 찬양 받을 수 있다.
3. 잘하면 억만장자가 되어 개발은 취미로 하게 될지도 모른다...ㄷㄷ

크롬 익스텐션 개발을 해본 적은 없지만, 대부분의 크롬 익스텐션이 JS로 개발되어 있는 것을 보면 나도 도전해볼만하다고 생각했다. (해보니 진짜 별 거 없었다)

우선 필요한 기능부터 정리해보자면

1. Angular 감지 🔍

React, Preact, Vue, Svelte는 이미 LocatorJS에서 지원 중이기 때문에 나는 Angular-Only-Target으로 진행한다. (한국에선 우리 팀말고 아무도 안쓰겟군.)

개발 환경이 Angular로 구성되어 있는지 아닌지 알기 위한 방법은 여러가지가 있다.

• window 객체에 등록된 Angular 관련 요소들(Zone, ng 등) 존재 여부
• HTML Element 중 ng prefix의 존재 여부
• HTML root 요소 확인

위 요소들을 확인하여 Angular Project가 존재하는지 여부를 판단하여 지원 여부를 알려줄 수 있다.

2. Web Inspector 🎯

LocatorJS와 같이 command 키를 누르고 마우스를 올렸을 때 해당 요소를 개발자 도구의 Inspector와 같이 HTML 요소를 콕 집어야한다. 이 기능도 정말 여러가지 구현 방법이 있다.

1. Angular에서 지원하는 Angular DevTools API 사용 - o

   const component = window.ng.getComponent(element);

2. 컴포넌트 선택자 기반 탐지 - x

Angular의 컴포넌트 선택자 생성 방식(ex.app-user-card -> UserCardComponent)으로 알아내는 것인데, 선택자를 바꾸는 예외 케이스가 굉장히 많으므로 해당 방법은 적절치 않다.

3. ng.probe API 사용 - o

   const debugElement = window.ng.probe(element);
   const component = debugElement.componentInstance;
   const componentName = component.constructor?.name

4. 전역 컴포넌트 검색 - △

   const globalComponent = findNearestAngularComponent(element);

말 그대로 다 돌며 찾는 것이다. 이건 최악의 성능을 지니므로 최후의 수단이다..

위 방법들 중 1번과 3번이 그나마 쓸만한 것 같은데, 아직 무엇이 더 적절할 지는 모르겠다. 2편에서 계속 ...

3. File Path 알아내기 ☠️

이게 좀 어려운 부분이다. 컴포넌트 이름 등 Angular의 컴포넌트 정보를 알아냈다 한들 이 컴포넌트가 정확히 어떤 폴더에 어떤 파일명으로 저장되어 있을지 알아내기가 쉽지 않은 것 같다. 현재 여러 방법을 통해 구현해보는 중인데 정확도가 높지 않다. stable한 방법을 찾으면 따로 글로 정리해보려 한다.

4. 에디터 열기 🧑🏿‍💻

해당 기능은 chrome에서 제공하는 API를 다음과 사용하면 된다. 자세한 레퍼런스는 여기를 참고

    chrome.runtime.sendMessage({
        action: 'openFile',
        componentInfo: componentInfo
    }, (response) => {
        if (response && response.success) {
            showNotification('파일이 열렸습니다!', 'success');
        } else {
            showNotification('파일 열기에 실패했습니다', 'error');
        }
    });

5. Chrome Web Extension 개발 환경 구성 📦

크롬 익스텐션에 등록하기 위해 manifest.json 파일을 루트 디렉토리에 작성해주면 된다.

https://developer.chrome.com/docs/extensions/reference/manifest?hl=ko

위 링크에서 필요한 내용을 참고하여 manifest.json 파일을 작성한다.

chrome://extensions/

위 사이트에 접속하여 개발자 모드를 켜고, 프로젝트 디렉토리를 등록하면 직접 내가 만든 익스텐션을 사용해볼 수 있다.

-1. 앞으로...

아직 개발중이어서 잘 동작하지는 않지만... 우선 기반 구축은 완료했다.

배포할 수 있을 정도의 퀄리티로 만들 수 있을지는 모르지만, DX 향상을 위해 자발적으로 무언가를 만들어보는 경험이 처음이라 도키도키하다. 잘 만들고 대박 나서 개발은 취미로 할 수 있기를. . .

[개발 테스트 화면]

☝️이건 첫번째 레슨~ 크롬 익스텐션

PixelParallel

디자이너: "피그마랑 디자인이 미세하게 안 맞아요~" 나: "넹 ㅠ_ㅠ (어느 세월에 디자인 확인하고 값 체크하고 수정하지 귀차나 ㅠ ㅠ)"

이 때 PixelParallel 익스텐션을 써보자 쉽게 설명하면 웹에 PNG 띄워서 비교할 수 있는 익스텐션이다.

사용법

1. 익스텐션을 설치한다.
2. 피그마에서 비교해보고 싶은 화면 혹은 요소를 export한다.
3. 익스텐션을 키고 UPLOAD IMAGE를 눌러 export한 파일을 선택한다.
4. 그럼 반투명한 요소가 떠서 실제 내가 만든 화면과 비교해보며 잘못 스타일링한 값이 있는지 편히 확인할 수 있다.

앗 !!! 폰트 크기가 안맞는다 !!! 🤦‍♂️

LocatorJS

개발하다보면 이 컴포넌트 위치가 어디지?! 할 때가 있다. 이 때 LocatorJS 익스텐션을 써보자

활성화 후 클릭 한 번이면 Cursor Vscode 등 작업 환경에 해당 컴포넌트가 있는 파일로 슝~ 이동시켜준다. 이거 알고나서 개발 속도 800% 향상되었다

✌️이제 두번째 레슨~ 개발자 도구

API Response Override

API 응답 갈아끼우고 싶을 때 가끔 사용했다. 지금은 MSW 사용중이어서 잘 안 쓴다

사용

1. Network 탭 -> 네트워크 요청 중 값을 바꾸고 싶은 응답을 선택, 우클릭하여 Override Content를 누른다.
2. 바꾸고 싶은 값을 바꾸고 저장 -> 새로고침하면 response가 갈아끼워져 있다. UI로 제어하기 힘든 값들을 바꾸고 싶을 때 써먹으면 좋다.

자세한건 아래 링크에서

https://www.youtube.com/watch?v=KxjGYcHZ_uI

HTML 요소 duplicate, delete, force state

이거 은근 모르는 분들이 있다. 간단히 html 요소를 늘리거나 삭제하고 싶을 때 사용한다. 조작하고픈 element를 선택하고 하고 싶은 행동 누른다.

침착맨 영상으로 가득 duplicate했다.

hover 상태 같은거 보고 싶을 땐 force state를 쓰자 Styles 탭에도 동일한게 있다

$0

Web Inspector로 찍은 요소는 $0에 저장되어 console에서 사용할 수 있다. 이걸 가지고 유튜브 동영상이 미리 몇 개나 로드되어 있는지 알아보자

대충 동영상 목록의 부모를 선택해서

콘솔에 찍어보니 25개다. 참고로 $1은 그 이전에 찍은 요소이다.

그렇다면 $2는?...

여러분의 상상에 맡긴다..ㄷㄷ

Chrome Developer Tools AI Assistant

크롬 개발자 도구에 AI Assistance가 있다. 왜 요청이 오래 걸리는지 네트워크 요청 분석 등 물어보면 알려준다.

위 내용들을 다 알고 있었다면? 당신은 멋쟁이 ~

🖖 드디어 세번째 레슨~ 모바일 디버깅

개발 환경마다 다를 수도 있는데, 나는 이렇게 한다.

1. 개발 중인 PC와 폰을 같은 WIFI에 연결

2. 실행 명령어 + --host 0.0.0.0 로 개발 환경 실행

ex. npm run start --host 0.0.0.0

3. WIFI IP 주소를 확인하여 해당 페이지로 접속 ex. IP가 1.1.1.1, 포트번호가 3000이면 http://1.1.1.1:3000

4. 야호~ 접속 완료

사파리의 경우에는 Safari Technology Preview를 쓰는 것도 추천한다. PC에 폰 연결해서 편하게 개발자 도구로 디버깅할 수 있다.

BONUS

마지막으로 내가 사용중인 Cursor Rule도 시원하게 공유한다. 어디선가 긁어와서 디벨롭해서 쓰고 있다. 여러분들은 더욱 디벨롭해서 쓰길 바라며 context7 MCP 연결해서 써야한다.

- Always respond in Korean
- Be casual unless otherwise specified
- Be terse
- Suggest solutions that I didn't think about—anticipate my needs
- Treat me as an expert
- Be accurate and thorough

1. Bug Fixes:
   - Analyze the problem thoroughly before suggesting fixes
   - Provide precise, targeted solutions
   - Explain the root cause of the bug

2. Keep It Simple:
   - Prioritize readability and maintainability
   - Avoid over-engineering solutions
   - Use standard libraries and patterns when possible

3. Code Changes:
   - Propose a clear plan before making changes
   - Apply all modifications to a single file at once
   - Do not alter unrelated files

use context7 for task which needs document (library or framework or something)

이전 회사에서 switch(true) 패턴을 자주 사용했다.

최근 코드를 짜면서 관성적으로 해당 패턴을 사용한 뒤, 셀프 리뷰 도중 문득 그런 생각이 들었다. 이게 정말 괜찮은 코드인가?

회사에서 짠 코드를 보기 쉽게 각색하여 switch(true) 패턴과 if-else 패턴으로 적어보았다.

switch(true) 버전

    switch (true) {
      case isOnlyOneItem:
        // Do Nothing
        return;

      case isFirst:
        const originalFirstItem = _items[1];
        newRank = originalFirstItem.prevRank();
        break;

      case isLast:
        newRank = _items.at(-1).nextRank();
        break;

      case isBetween:
        newRank = beforeRank.between(afterRank);
        break;

      default:
        // case for last index item and has more items to load    
        const newItem = await fetchNextItem();
        newRank = _items.at(-1).between(newItem.rank)
        break;
    }

if-else 버전

    if (isOnlyOneItem) {
      // Do Nothing
      return;
    } else if (isFirst) {
      const originalFirstItem = _items[1];
      newRank = originalFirstItem.prevRank();
    } else if (isLast) {
      newRank = _items.at(-1).nextRank();
    } else if (isBetween) {
      newRank = beforeRank.between(afterRank);
    } else {
      // case for last index item and has more items to load 
      const newItem = await fetchNextItem();
      newRank = _items.at(-1).between(newItem.rank)
    }

코드는 드래그 앤 드랍 이후 정렬을 위해 새로운 rank를 결정하는 코드이다.

정렬 간 rank 개념이 궁금하다면 Jira에서 만들었으며, 라인에서도 사용하는 LexoRank 개념을 찾아보삼!

얼핏 보기에는 switch(true) 구문이 더 깔끔해보인다. 코드를 읽는게 아니라 그냥 그림 보듯이 슥 보면 말이다.

그런데 지금와서 생각해보면, Readability를 향상시키고자 적었던 이 패턴이 실제로는 오히려 해친다는 생각이 들었다.

익숙하지 않고, 직관적이지 않다.

나와 같이 switch(true)를 사용하는 개발자가 있다면 이 구문을 보고 슥 넘어갈지도 모르지만, 아마 처음 보는 사람이라면 switch(true)? 이게 뭐지? 바본가? 라는 생각부터 들 법하다.

이게 첫번째 문제라고 생각한다.

설계 의도에 부합하지 않는다.

MDN에도 친절히 나와있듯, switch 직후 인자인 expression에는 case 구문과 매칭될 것으로 기대되는 값을 넣어주어야 한다. true를 넣는 것은 편법이며, 표현식을 평가해서 그 값과 일치하는 case 절을 찾아 실행한다 라는 switch의 설계 의도에 부합하지 않다. (제일 큰 문제다)

(번외) switch는 Type Narrowing이 제한적이다.

if else에서는 앞에서 평가한 expression의 타입이 다음 expression에 반영된다.

좀 어거지로 만들긴 했지만 아래 예시를 보면, 첫번째 if문에서 value가 undefined가 아닌 것을 알 수 있으므로, 두번째 else if에서 '+' 연산자를 써도 문제가 없다. value의 타입이 number로 좁혀졌기 때문이다.

    interface Value {
      value?: number;
    }


    if(value === undefined) {
        return value;
    } else if(value + 1 === 2) {
        return value;
    } else {
        return 0;
    }

그러나 switch 문에서는 case 블록의 조건을 Type Narrowing의 근거로 사용하지 않는다. 요게 은근 불편할 때가 많았다.

    switch(true) {
        case value === undefined:
            return value;

        case value + 1 === 2:
            return value;

        default:
            return 0;

Type Narrowing에 관한 내용은 타입스크립트 문서에서 확인 가능하다.

(번외) 우선순위가 중요한 if-else 문을 어떻게 사용해야 잘 사용했다고 소문이 날까?

자주하는 고민 중 하나는 if-else 문에서 우선순위가 중요한 경우 어떻게 적는 것이 좋겠냐는 것이다. 순서가 중요한 경우는 조건1이 참이고 조건2도 참일 때 조건1에 해당하는 동작을 먼저 수행해야 할 때이다.

예를 들어, 로그인을 안한 경우 접근 불가능한 페이지가 있다. 그러나 맥북 M4 PRO 오너라면 로그인 없이 접근할 수 있는 사이트가 있다고 가정하자.

그렇다면 코드는 아래와 같이 짤 수 있다.

 if (isMacbookM4ProOwner) { // 로그인 안해도 입장 가능
    return '환영합니다'
 } else if (!isLogin) {
    return '로그인 해주세요'
 }

그런데 만약 평가식의 순서를 바꾸게 된다면

if (!isLogin) {
    return '로그인 해주세요'
} else if (isMacbookM4ProOwner) {
    return '환영합니다'
}

아뿔싸, 맥북 M4 프로 오너임에도 로그인하라는 메시지를 받게된다. 이와 같이 평가식에서 참인 케이스가 여럿인 경우는 개발하다보면 은근 있다. 지금은 평가식이 두 개여서 간단하지만 더 많은 케이스가 추가된다면?

if (isLoading) {
    return '로딩중...'
 } else if (isMacbookM4ProOwner) { // 로그인 안해도 입장 가능
    return '환영합니다'
 } else if (isWindows) {
    return '이 참에 바꿔보시는건 어떨까요?'
 } else if (!isLogin) {
    return '로그인 해주세요'
 } 

그럴때는 그냥 if문을 분리하자.

if (isLoading) {
    return '로딩중...'
}

if (isMacbookM4ProOwner) {
    return '환영합니다'
} else if (isWindows) {
    return '이 참에 바꿔보시는건 어떨까요?'
}

if (!isLogin) {
    return '로그인 해주세요'
}

영역을 잘 분리하는 것이 가독성에 도움이 된다고 생각한다. 물론 위의 예시는 return을 해주기에 유의미하다. 안하면 환영도 하고 로그인도 하고 난리난다.

여러 우선순위가 있고 조건이 복잡하다면 조건을 변수로 분리하는 등 최대한 노력을 기울여보자. 거지같은 비즈니스 로직에서 비롯된 if else문 떡칠 속에서도 깨끗한 코드 한 줄을 적어내려고 노력하자.

결론

switch(true)는 이제 잊자. switch문은 평가 가능한 enum 혹은 value에 대해 사용하도록 하고, if-else는 예쁘게 잘 쓰면 되겠다.

최근에 알게된 건데, useMount useEffectOnce (react-use 라이브러리에서 제공하는 라이프사이클 관련 훅)은 리액트 공식 문서에서 쓰지 말라고 언급되어 있다. 그것도 모르고 그동안 신나게 썼다.

관성적으로 적는 코드를 다시 한 번 잘 들여다보자. 나도 모르게 나쁜 습관이 배어 있을 수 있다.

그래도 결국 앵귤러(회사)를 선택하게 된 이유는 세 가지 정도가 있다.

1. 면접 본 회사 중 지금 회사가 가장 마음에 들었다.(서비스의 완성도도 좋았고, 잘될 것 같다 + 성장할 수 있겠다는 느낌이 강했다)
2. 무릇 개발자라면 일정 수치 이상의 '개발력'만 갖추게 되면 기술 스택은 중요치 않다고 생각한다.
3. 새로운 스택을 배워보고 싶었다. 현 회사는 Angular뿐 아니라 Capacitor + ionic을 이용한 앱 빌드 등도 경험할 수 있는 환경이다. 원하면 Nest까지도..

아무튼 그래서 앵귤러를 미리 일주일 정도 공부하고, 입사 이후 과제 등을 통해 앵귤러를 익혀가고 있다.

2주 따리가 무슨 감상평이냐고 할 수 있지만, 그 말이 맞다. 그래도 느낀 점 몇 개 적어보겠다.

왜 잘 안쓰일까?

• 리액트 / Next - 90%
• 뷰 혹은 .net, jsp 등등... - 9%
• 앵귤러 - 1% (우리 회사 ㅋㅋ)

이미지 출처: https://survey.stackoverflow.co/2024/technology

stackoverflow ranking을 보면, 24년 기준으로 리액트는 39.5%, 앵귤러 17.1%, 뷰 15.4%인데... 국내에서 이는 완전히 다른 듯 하다.

잘 쓰이지 않게 된 데에는 다음과 같은 이유들이 있는 것 같다.

1. 타입스크립트 강제

2. 가파른 러닝 커브

3. 관성적인 선택

Angular 2주 체험 후기

앵귤러 맛보기를 하면서 느낀 점은 다음과 같다.

1. 오히려 좋다

리액트를 개발하면서 가장 재밌으면서도 열받는 점은, 라이브러리 선택 및 학습이다. 번들러는 무엇을 쓰고, 라우팅 전략은 뭘 쓰고, UI는 뭐 상태관리는 뭐 뭐뭐뭐 하다보면 시간 다 간다.

실컷 배워놔도 한 해 지나니 새로운 뭐가 떠오른다. 물론 끊임없이 공부해야하는게 숙명이라지만, 이 분야에서 리액트는 단연 레전드다.

앵귤러 프레임워크에서 가장 좋았던 점은 위의 것들을 신경쓰지 않고, 프레임워크에 내장된 기술을 쓰면 된다는 것.

이렇게 이렇게 해 ! 라고 공식 문서에 나와있으니, 레퍼런스가 부족하더라도 그냥 보고 쓰면 된다. 공식 홈페이지의 권장되는 코딩 스타일 가이드도 참 많이 도움이 되었다.

2. 조금 더 명확한 패턴

리액트는 새로운 회사에 가든, 혹은 회사의 다른 개발자분과 협업을 하든 각자마다 코딩 스타일이 꽤나 다른 경우가 많다. 물론 내부 컨벤션 및 가이드를 통해 어느정도 해소 가능하지만, 감안하더라도 차이가 꽤 크다.

앵귤러는 다 '해줘'서 그럴 일이 적다. 앵귤러는 MVVM (Model-View-ViewModel) 패턴에 가까운데, 이런 것이 개발할 때 좀 더 생각을 안해도 되게 만들어준다. 라우팅이나 상태관리 측면에서도 대부분 그렇다.

EX) Component - 뷰의 로직, 상태관리 HTMl - 뷰모델 Service - 이외 로직 때려박기

3. 환경이 척박하긴 하다

Angular 개발을 위해서는 VSCode보다는 WebStorm이 더 낫다고 한다. vsCode 만년 인생을 살아온 나로써는 적응하기 좀 어려웠다. 지금은 제법 잘 쓰는듯? 현재는 Webstorm + Cursor 사용중이다.

최신 레퍼런스는 제로에 가깝다. 가끔 불친절한 공식 문서를 보고 모르는 것을 구글링하면 대부분 최소 n년전 자료들이 나온다.(though thank you stackoverflow) 그래도 요즘 AI 성능이 참 좋아서 이것도 어느정도 해결되는 문제다.

총평

리액트나 앵귤러나 라이브러리 / 프레임워크의 설계 의도에 부합하게 코드를 잘 작성하려고 노력하면 되는 것 같다. 처음엔 어렵대서 쫄았는데, React, Angular, Vue 아무거나 깊게 잘만 공부해놓으면 다른 스택으로 넘어가는건 금방이라고 느꼈다.

Nest 녀석도 자꾸만 눈길이 간다. 이러다 풀스택 개발자가 되어버릴지도..?

"본 포스팅은 Angular 홍보를 목적으로 Google로부터 제품 대여 및 원고료를 지원 받지 않은 내돈내산이며, 직접 사용한 후기를 바탕으로 작성되었습니다."

회사 다니느라 너무 바빠서 글 1년동안 하나도 못 썼다.(핑계다)

기술적인 부분 외에 배우고 느낀 점들을 정리해보려고 한다. 지금부터 적는 내용들은 바쁘고 정신 없는 스타트업에서는 비슷하게 적용될 것 같다.

1. 실무 개발 = 이데아를 찾는 과정

그간 회사에서 짠 코드의 대부분은 다 짜고 난 후, 혹은 짜다가도 이런 생각이 든다.

"아 훨씬 잘 짤 수 있을 것 같은데..."

평소 작문에 흥미가 있는 나는 처음에 멋있는 글을 쓰고 싶다는 생각을 했었다. 그렇지만 멋있는 글을 쓰는 것보다 더 어려운 것은 쉽게 읽히는 글을 쓰는 것이었다.

👉 기습 책 추천 내가 생각한 인생이 아니야. 저자 류시화

유지보수에 용이한 코드, 확장성 및 Readability가 뛰어난 코드, 구조가 잘 설계된 코드 등등 항상 지키고 행하고 싶은 원칙들은 많다.

코드도 글과 같이 쉽게 읽히는 코드가 위 원칙들을 만족하는 경우가 많은 것 같다. 그렇지만 코드를 짜다보면 이는 생각처럼 잘 되지 않는다.

실무에서 이를 방해하는 요소가 크게 세 가지가 있다고 보았다.

• 복잡한 요구사항
• 레거시 코드 (= 기술 부채)
• 촉박한 마감기한

당연하게도 코딩을 할 때 온전히 코드에만 집중하기는 어려웠다. 결국 회사에서 짜는 대부분의 코드는 복잡한 비즈니스를 프로그래밍 언어로 빠르게 풀어나가는 과정이고, 그 과정에서 나는 수많은 타협을 하게 된다.

위 세 가지에 대해 하나하나 설명하지 않아도 대부분 감이 올 것이라고 생각하여 적지 않겠다..

아무튼 실무에서의 개발은 이런 험난함 속에서도 최적의 코드를 찾아나가는 과정이라는 것을 느꼈다.

특히 기한이 빡빡할 때는... 시작부터 잘못 짰다고 느낄 때가 있어도 뒤엎지 못하고 다시 또 부채로 쌓이는 경우가 많았던 것 같다. 꼭 전체적인 구조부터 잘 잡아나가자.

세 줄 요약
1. 바쁘고 정신 없을 때 코드 짜기 힘들다
2. 그냥 몸에 체화시키고 계속 의식하며 개발해야한다.
2. 초반 구조를 잘 잡자. 기술 부채는... 

2. 도메인

나는 교육 도메인에 관심이 있었다.

한 때 꿈이 선생님이기도 했었고, 코딩 과외를 1년 정도 한 경험도 있었기 때문에 교육 도메인은 재미있을 것이라고 기대했다. 그러나 기업 대상으로 하는 코딩 교육, 디지털 교과서 등 교육 플랫폼을 만드는 일은 내가 생각하던 교육과는 달랐다. 내가 관심 있었던 부분은 실제 교육을 하는 교육자의 입장이었지, 교육자와 학습자를 이어주는 플랫폼이 아니라는 것을 깨달았다.

추가로 나는 유저 혹은 서비스와 좀 더 맞닿아있는 개발을 하고 싶다는 걸 알게되었다. 사실 회사를 다니면서도 내가 직접 유저가 되어 서비스를 사용하는 일이 적었고, 배포 이후에도 유저의 반응을 확인하기가 어려웠다.

결국 개발을 꾸준히 하게 만드는 원동력은 성취감이었는데, 1년 동안 내가 이런 서비스를 만들었다! 라는 데에서 오는 성취감은 적었고 이게 큰 퇴직 사유가 되기도 했다.

이직을 처음 마음 먹은 2월 즈음에는 아무 회사나 적당히 괜찮아 보이면 지원하곤 했는데, 최근에는 정말 관심이 가게되는 곳을 위주로 지원하였다. 다행히 그 중 가장 마음에 들었던 곳에 합격하게 되어 곧 출근 예정이다. 야호~

세 줄 요약
1. 교육 도메인 내 스타일 아니다
2. 내가 만들어낸 것이 효과가 있던 없던 그 정도를 아는 것 자체가 중요하다. 
   임팩트가 있었다면 성취감을 얻고, 없었다면 절치부심하게 된다. (아님 말고)
3. 취업했다. 야호~

3. 효율적인 커뮤니케이션을 못하게 하는건 능력보단 상황

이미 인터넷에 널린 좋은 커뮤니케이션의 예시가 많지만, 나도 한 번 적어보련다.

한 번에 할 수 있는 말을 여러 핑퐁에 나누어 하게되는 경우를 지양하고, 같이 알아야하는 사람이 있다면 잘 전달하기 등만 지켜도 중간은 가지 않을까?

~ 비효율적인 예 ~

000 디자이너님, 이 부분 디자인 스펙 개발 코스트가 커서 수정하여도 괜찮을까요?

"네, 어떤 식으로 수정할까요?"

원형 버튼은 디자인 시스템에 커스텀해야하는 부분이 많아서, 대신 기존의 토글 버튼으로 수정하면 좋을 것 같아요. 

"네, 그러면 그렇게 수정하시죠! 피그마에도 수정해둘게요."

~ 몇 시간 혹은 며칠 후 ~
@기획자 님 여기서 논의되었습니다!
"음 그런데 토글 버튼은 사용성 측면에서 ~~"

...

~ 개선해본 예 ~

000 디자이너님, 이 부분 디자인 스펙 커스텀할 부분이 많아보여서요, 
원형 버튼 대신 디자인 시스템의 토글 버튼으로 수정하여도 문제 없을까요?
cc. @기획자님 @동료 프론트엔드 개발자

...

일부만 보여주는 예시긴 하지만, 내가 생각하는 어느정도의 기본이 담겨있다고 생각한다.

바쁘고 정신없는 상황에서 특히 중요하게 생각하는 요소들을 정리해보자면

1. 멘션 하나에 질문 / 요구사항 / 그로 인한 효과 등을 적어 비효율적인 코스트 없애기 ➡️ 글로 설명하기 힘들면 그냥 찾아가서 여쭤보고 이후 글로 다시 정리해두는 것도 좋은 것 같다.
2. 서로 이해하고 있는 부분이 명확히 일치하는지 확인 ➡️ 가끔 이해한 것 같아도 서로 다른 방향을 바라보고 있을 때가 많다.
3. 작업에 관련된 사람들이 모두 최신의 정보를 알 수 있도록 신경쓰기 ➡️ 최고는 처음에 딱 정하고 안 변하는 것이지만..그러기는 쉽지 않으니

세줄 요약
1. 개발이나 커뮤니케이션이나 한 걸 다시 하는게 최악의 코스트이다.
2. 커뮤니케이션으로 중간을 못 가는 경우가 연차 불구하고 많다. 
능력이 안된다기보다 상황 혹은 태도가 문제인 것 같다.
3. 나도 여전히 잘 못하지만 최소한 고치려고 한다. 이게 제일 중요하다고 생각한다.

적다보니 스타트업 절망편처럼 적은 감이 없잖아 있는데, 결국 나도 사람인지라 좋았던 점보다는 아쉬웠던 점들이 더 남는 것 같다. 그럼에도 불구하고 그 아쉬웠던 점들 덕분에 나는 훨씬 성장할 수 있었다 like 나를 죽이지 못하는 고통은 나를 더욱 강하게 만들뿐. 좋은 점들은 배우고, 아쉬운 점은 스스로 개선해나가면 된다 like Deep Learning.

적고 싶은 것들이 더 많았던 거 같은데 기억이 안나서 일단 줄인다. 생각나면 추가로 적어야지

1년 동안 힘들고 지칠 때도 많았지만, 성장하고 즐거웠던 기억들도 정말 많이 남아있다. 특히 부족한 나에게 많은 것들을 가르쳐준 프로덕트 팀 동료들에게 무한 감사하다.

Thank you

✅ 세션, 토큰 로그인

세션 방식

1. 유저가 로그인을 한다.
2. 서버 DB에 아이디, 로그인 날짜, 유효기간, 세션 ID를 기록한다.
3. 이후 post, get 요청 시 쿠키에 session id가 기록되어 보내진다.
4. session id를 DB의 정보와 비교 후, 요청을 처리한다.

장점 : 매 요청마다 엄격하게 로그인 상태를 체크할 수 있다.

단점 : DB에 부하가 걸린다. 해소 -> Redis를 이용한 입출력 부하 줄이기

토큰 방식(JWT)

1. 유저가 로그인을 한다.
2. 쿠키에 아이디, 로그인 시간, 유효기간 등이 암호화되어 저장된다.
3. 이후 요청 시 쿠키를 보고 처리한다.

장점 : DB 부담이 적다.

단점 : 입장권이 도용당하면 큰일난다. 해소 -> 나쁜 입장권 목록을 DB에 저장한다.

✅ OAuth

로그인 시 다른 곳의 개인정보 권한을 대여한다. ex) 구글에게 유저정보에 대한 접근 권한을 위임받는다.

예시

1. 유저가 구글 로그인을 진행한다.
2. 유저에게 내 사이트에서 정보 권한을 이용해도 되는지 동의를 구한다.
3. 구글에서 권한 증명에 사용되는 코드를 발급한다.
4. 받은 코드로 유저 정보 등 자원을 구글에 요청하여 받아온다. 이 때 받는 정보에는 유저이메일, 이름, AccessToken 등이 포함된다. 이후 이를 가지고 JWT, 혹은 세션 방식으로 이후 과정을 이어나간다.

Next에서의 OAuth

Next에서는 NextAuth.js라는 라이브러리가 존재한다. 이를 이용하면 소셜 로그인, JWT 토큰, Session, DB Adapter 방식 등 모두 이용 가능하다. 단, 아이디, 비밀번호를 이용한 로그인 시에는 세션 방식은 사용 불가능하고, 토큰 방식으로만 이용할 수 있다. 보안 이슈를 막기 위함이라고 한다..

깃허브 소셜 로그인 만들기

1. 깃허브 로그인 진행 후, settings -> Developer Settings -> OAuth Apps에 진입한다.

이후 New OAuth App을 누르고, name, URL을 적어준다. 이 때 개발 환경이라면 Homepage URL과 Authorization callback URL에 모두 http://localhost:3000을, 배포된 환경이 있다면 해당 URL을 적어준다.

이후 생성 시 발급되는 Client ID와, Generate a new client secret를 눌러 암호를 잘 저장해두자.

이후 Next-Auth 세팅을 위해

npm install nextauth 입력, 이후 root/pages/api/auth/[...nextauth].js 위와 같은 위치에 폴더 및 파일을 생성한다.

// [...nextauth].js
import NextAuth from "next-auth";
import GithubProvider from "next-auth/providers/github";

export const authOptions = {
  providers: [
    GithubProvider({
      clientId: 'Github에서 발급받은 ID',
      clientSecret: 'Github에서 발급받은 Secret',
    }),
  ],
  secret : 'jwt생성시 쓸 암호'
};
export default NextAuth(authOptions);

이 때 jwt 생성 시 쓰는 암호에는 복잡한 문자열을 알아서 입력해주면 된다. 나는 1q2w3e4r!로 적었다.

이후 간단한 로그인 버튼을 만들어주자.

// LoginBtn.tsx
"use client";

import { signIn } from "next-auth/react";

export default function LoginBtn() {

  return (
    <button
      onClick={() => {
        signIn();
      }}
    >
      로그인
    </button>
  );
}

로그인 시에는 signIn을, 로그아웃 시에는 signOut을 import하여 사용해주면 된다. 이후 정보가 잘 받아와졌는지 확인하기 위해

let session = await getServerSession(authOptions);
console.log(session);

session은 다음과 같다.

{
  user: {
    name: 'Donghyun Hwang',
    email: '-----@soongsil.ac.kr',
    image: 'https://avatars.githubusercontent.com/u/95581482?v=4'
  }
}

나의 깃허브 정보들이 잘 넘어와진걸 볼 수 있다.

💎 느낀 점

백엔드 팀과 리액트 + 구글 로그인 + JWT토큰 방식으로 OAuth를 구현하다 많이 헤맸던 기억이 난다. 그 과정에서 알게 됐던 것들 덕분에 강의를 들으며 복습하는 기분이었고, 직접 Next + 세션 혹은 토큰 방식으로 로그인을 구현하는 것에 기대를 가지고 있다.

✅ npm run build, 결과

개발 서버가 아닌, 실제 배포를 위해서는 npm run build를 통해 배포에 필요한 파일들을 준비해줘야 한다. 이 때 로그를 살펴보면

위와 같이 페이지 앞에 o, λ와 같은 기호들이 있는 것을 볼 수 있다. 각각 페이지의 렌더링 방식을 나타낸다. o : Static Rendering λ : Dynamic Rendering

✅ Dynamic Rendering VS Static Rendering

Dynamic Rendering의 특징

1. 접속마다 새로 html을 만들어 보낸다
2. fetch('/URL', { cache: 'no-store' }), useSearchParams(), headers, cookies(), [dynamic route] 등을 사용 시에 Dynamic Rendering 된다.

Dynamic Rendering의 장단점

1. 실시간 데이터를 유지 가능하다.
2. 서버 / DB에 부담이 될 수 있다.

Static Rendering의 특징

1. 아무 설정도 하지 않으면 디폴트로 설정된다.
2. npm run build 시 만들어진 페이지를 그대로 유저에게 보낸다.

Static Rendering의 장단점

1. 만들어진 페이지를 보내기 때문에 전송이 빠르다.
2. 실시간 데이터 반영이 되지 않는다.

Static <-> Dynamic Rendering 변환

Static Rendering, Dynamic Rendering 여부는 npm run build 시에 자동으로 결정되지만, 이를 전적으로 신뢰해서는 안된다. 해당 프로젝트의 list 페이지의 경우에도, 글을 수정, 삭제, 작성 시에 페이지에 실시간 적용이 되어야하나, 현재는 Static Rendering으로 설정되어 있는 것을 볼 수 있다. 이를 강제로 Dynamic Rendering으로 바꾸기 위해서는 페이지 상단에 다음과 같이 적어주면 된다.

// list.tsx
export const dynamic = 'force-dynamic';

// Dynamic을 Static으로 바꾸고 싶은 경우
// export const dynamic = 'force-static';

이렇게 적어준 후 npm run build를 다시 해보면, 성공적으로 Dynamic Rendering으로 바뀌어 있는 것을 볼 수 있다

✅ 캐싱

Dynamic Rendering의 단점인 서버 / DB에 부하를 줄이기 위한 방법으로 캐싱이 있다. 불러왔던 데이터를 저장해두고 잠시 가져다 쓰는 것이다.

1. GET 요청 결과 캐싱

get 요청을 캐싱하기 위해

await fetch('/URL', {cache: 'force-cache'})

위와 같이 적는 방법이 있다. 사실 적지 않아도 디폴트로 get 요청 값이 캐싱된다. 실시간 데이터 fetching을 위해 이를 해제하고 싶다면

await fetch('/URL', {cache: 'no-store'})

와 같이 이를 명시해주면 된다.

이 외에도

await fetch('/URL', {next: {revalidate: 60}})
// 60초 단위 캐싱

과 같은 옵션이 있다. 앱의 성격에 맞게 이를 잘 구분해주자.

2. 페이지 단위 캐싱

하나의 요청이 아닌 페이지 단위로도 캐싱할 수 있다. DB 입출력을 위한

export default async function Home() {

  const client = await connectDB;
  const db = client.db('board');
  let result = await db.collection('post').find().toArray();


  return ...;
}

아래와 같은 코드가 있을 때,

import { connectDB } from "@/util/db";

export const revalidate = 60;
// 60초 캐싱

export default async function Home() {

  const client = await connectDB;
  const db = client.db('board');
  let result = await db.collection('post').find().toArray();

  return ...;
}

최상단에 미리 예약되어 있는 변수 revalidate를 설정해주면 페이지 단위 캐싱이 가능하다. 참고로 방문자가 있을 때 60초 단위고, 없으면 페이지 재생성은 이루어지지 않는다.

on-demand Revalidation을 통해 60초가 지나기 전에 강제로 캐시를 새로 생성하는 방법도 있다.

가보자

새로 알게 된 내용은 몇 없었다(MongoDB 업데이트, 수정 등). 알던 지식을 다시 정리해보자.

✅ MongoDB 데이터 수정, 삭제

클라이언트 페이지는 다음과 같이 만들었다.

// edit/[id]/page.tsx
import { connectDB } from '@/util/db';
import { ObjectId } from 'mongodb';
import React from 'react';

const Edit = async (props: any) => {
  const db = (await connectDB).db("board");
  let result = await db.collection("post").findOne({ _id: new ObjectId(props.params.id) });

  if (!result) {
    alert('잘못된 접근입니다.');
    window.location.href = '/list';
    return;
  }
  return (
    <div className>
      <h4>수정 페이지</h4>
      <form action="/api/post/edit" method="POST">
        <label htmlFor="title">제목</label>
        <input type="hidden" name="id" value={props.params.id} />
        // id를 전송하기 위한 input, 유저에게 보여서는 안됨
        <textarea name='title' defaultValue={result.title}></textarea>
        <label htmlFor="content">내용</label>
        <textarea name='content' defaultValue={result.content}></textarea>
        <button type="submit">수정</button>
      </form>

    </div>
  );
};

export default Edit;

여기서 눈여겨 볼 점은 글의 id를 담기 위한 input을 하나 더 만들어준다는 것이다. id 정보를 가지고 있어야 DB에서 올바르게 데이터를 수정할 수 있다. <input type="hidden"> 또는 style={{display:'none'}}을 통해 사용자에게 보이지 않도록 주의하자.

다음은 서버 페이지다.

// pages/api/post/edit.tsx
import { connectDB } from "@/util/db";
import { ObjectId } from "mongodb";
import { NextApiRequest, NextApiResponse } from "next";

const edit = async (request: NextApiRequest, response: NextApiResponse) => {
  if (request.method == "POST"){
  const db = (await connectDB).db("board");

  let result = await db.collection("post").updateOne(
    {
      _id: new ObjectId(request.body.id),
    },
    {
      $set: {
        title: request.body.title,
        content: request.body.content,
      },
    },
    { writeConcern: { w: "majority" } }
  );

  response.status(302).redirect("/list");
  } else {
    response.status(400).json("잘못된 접근입니다.");
  }

};

export default edit;

MongoDB에서 하나의 데이터를 수정할 때는 updateOne() 메소드를 사용한다.

기본 형식은 다음과 같다.

db.collection("테이블 이름").updateOne(
    {
      // 업데이트 시에 데이터를 식별할 값
    },
    {
      $set: {
        // 수정할 값과 내용
      },
    });

$set뿐만 아니라 $inc를 통해 값의 변경이 아닌 증가/감소 처리 또한 가능하다.

삭제 또한 비슷한 형식인데, 클라이언트에서 삭제 버튼을 누를 시, /api/post/delete로 글의 id를 담아 DELETE 요청을 보낸다고 가정해보자.

이 때 서버에서는 다음과 deleteOne 메소드를 통해 처리한다.

// api/post/delete.tsx
const Delete = async (request: NextApiRequest, response: NextApiResponse) => {
  if (request.method == "DELETE"){
  const db = (await connectDB).db("board");

  let result = await db.collection("post").deleteOne(
    {
      _id: new ObjectId(request.body.id),
    }
  );

  response.status(302).redirect("/list");
  } else {
    response.status(400).json("잘못된 접근입니다.");
  }

};

export default Delete;

수정할 값을 담았던 updateOne과 달리, 데이터를 식별할 수 있는 값을 담아 보내면 데이터 삭제가 이루어진다.

✅ Client 컴포넌트에서의 데이터 접근

1. props를 통한 접근

클라이언트 컴포넌트가 서버 컴포넌트의 자식 요소로 존재할 때, 데이터 접근은 서버 컴포넌트에서 처리한 뒤, 클라이언트 컴포넌트에 props로 이를 넘겨주는 방식이다.

// 서버 컴포넌트
import { connectDB } from "@/util/db";
import Link from "next/link";
import ListItem from "./ListItem";

export default async function List() {

  const db = (await connectDB).db('board');
  let result = await db.collection('post').find().toArray();

  return (
    <div className="list-bg">
      <ListItem result={result} />
       // 클라이언트 컴포넌트 ListItem에 result를 넘겨줌
    </div>
  )
}

// ListItem.tsx, 클라이언트 컴포넌트
"use client";

const ListItem = (props: any) => {

  const result = props.result;
  return (
    <div>
      {result.map(
      // ... 
      )}
    </div>
  );
};

2. useEffect를 통한 접근

"use client";

import { useEffect } from "react";

const ListItem = () => {

  useEffect(() => {
    // 서버에 부탁해서 DB 게시물 가져오는 코드 작성
    // result에 저장
  }, []);

  return (
    // ...
  );
};

export default ListItem;

유의할 점은 DB에 직접 접근하는 것이 아닌, 서버에게 DB 데이터를 달라는 요청을 보낸다는 점이다. 클라이언트 컴포넌트는 클라이언트에게 노출되기 때문에, DB 접근과 같은 민감한 행위들은 금지된다. 더 궁금하다면 NextJS 독학 2차시를 참고해보자.

3. 각 방식의 장단점

props를 통한 접근은 SEO에 더욱 유리하다. useEffect가 호출되는 시점은 html이 모두 렌더링된 이후이기 때문에, 검색 엔진 봇에게 제대로 된 결과를 제공할 수 없다.

그러나 컴포넌트 구조가 복잡해질수록, props를 통해 데이터를 주고 받는 것은 Props Drilling과 같은 문제를 낳을 수 있다.

💎느낀 점

NextJS에서는 Redux와 같은 전역 상태 관리 툴이 따로 존재하는지 궁금해졌다. 또한 백엔드 지식이 없다시피 하다보니 더 상세한 서버의 데이터, 예외 처리 등에 대해 알아봐야겠다고 생각했다.

1. 계정 생성

MongoDB에서 회원가입을 진행한다.

무료로 500mb 용량의 DB를 사용할 수 있다.

2. DB 접속용 아이디 / 비밀번호 생성

Database Access에서 아이디, 비밀번호를 만들어준다. 이 때 아이디, 비밀번호는 잘 기억해두자.

생성 후 edit을 눌러 built-in-role을 Atlas admin으로 설정해주자. DB 접속 시 무엇이든 할 수 있게 하기 위함이다.

그 후 Network Access 메뉴를 찾아 IP를 등록한다. 이 때 어디서나 접속해도 상관없다면 Allow access from anywhere을 누르거나 0.0.0.0/0 을 추가한다.

3. 데이터 추가

데이터베이스와 Collection을 만들고, 데이터를 추가해주자.

NextJS에서 사용하기

1. MongoDB 라이브러리 설치

npm install mongodb

2. DB 연결

생성한 DB에서 다음 과정을 따른다. Connect - Drivers - 그 후 url을 복사해주자.

3. 환경 변수 설정

NextJS에서 환경 변수를 사용하기 위해 프로젝트 루트 디렉토리에 .env.local 파일을 만들어준다. 그 안에 복사한 URL을 기입해준다.

MONGODB_URL = mongodb+srv://아이디:비밀번호@cluster0...mongodb.net/?retryWrites=true&w=majority'

4. 전역 타입 및 tsconfig 설정

타입스크립트와 같이 사용하기 위해 몇 가지 설정을 해주어야한다.

_mongo 전역 타입 지정을 위해 다음 위치에 global.d.t.ts파일을 하나 만들어준다.

// 루트 디렉토리/src/type/global.d.t.ts
export {};

declare global {
    var _mongo: Promise<MongoClient> | undefined;
}

tsconfig.json에 다음과 같이 추가해준다.

// tsconfig.json
.. 
"typeRoots": [
      "./src/types",
      "./node_modules/@types"
    ]
...
"include": [
    ".next/types/**/*.ts",
    "src/**/*",
    "global.d.ts"
  ],

5. db.ts 생성

db 연결 코드는 계속해서 사용되므로 util 폴더를 만들고 db.ts 파일을 만든다.

// util/db.ts

import {MongoClient} from 'mongodb'

const url = process.env.MONGODB_URL;

if (!url) {
    throw new Error('The MONGODB_URL environment variable is not defined')
}
let connectDB: Promise<MongoClient>;
if (process.env.NODE_ENV === 'development') {
    if (!global._mongo) {
        global._mongo = new MongoClient(url).connect()
    }
    connectDB = global._mongo
} else {
    connectDB = new MongoClient(url).connect()
}
export {connectDB}

6. 사용 방법

import { connectDB } from "@/util/db";

export default async function Home() {

  const client = await connectDB;
  const db = client.db('db이름');
  let result = await db.collection('collection 이름').find().toArray();
  console.log(result);

  return <div>...</div>;
}

위와 같이 사용하면 되며, 자세한 사용법은 추후 다시 정리하도록 하겠다.

시작하자

서버, 클라이언트 컴포넌트에 대해 간략하게 배웠다. 궁금해져서 더욱 찾아보았다.

✅ Server / Client Component

React18에서 공개된 서버 컴포넌트를 이어받아 NextJS 13에서도 Server / Client 컴포넌트가 탑재되었다. 우선 서버 컴포넌트와 클라이언트 컴포넌트가 무엇인지 알아보자.

Server Component

서버 측에서 컴포넌트를 실행하여 미리 렌더링된 마크업을 생성 후, 클라이언트에게 전달되어 사용자에게 콘텐츠를 보여주는 방식.

❗ 서버 사이드 렌더링과는 엄연히 다른 개념이다! 서버 컴포넌트는 SSR의 단점을 보완하기 위해 등장했다.

특징

• 페이지 초기 로딩이 빠르다. (UX 향상)

• 클라이언트에게 컴포넌트 JS 번들이 전달되지 않는다.
• 백엔드 리소스에 접근이 가능하다 ≒ 서버 인프라를 더욱 잘 활용할 수 있다.

Client Component

기존의 우리가 사용하던 리액트 컴포넌트

❗ 클라이언트측만이 아닌, 클라이언트 / 서버 양측에서 모두 렌더링이 일어난다!

사용법

• 코드 최상단에 'use client'라고 명시한다. 적지 않을 시 기본적으로 서버 컴포넌트로 작동한다.

• 내부에 서버 컴포넌트를 포함시킬 수 없다. 읽어보면 좋은 글

❓ 언제 사용하면 좋을까

공식 문서에서 이를 표로 잘 알려주고 있다.

서버 컴포넌트는 Data Fetching이나, 민감한 정보를 숨기고 싶을 때 사용하면 되는 듯 하다. 대신 우리가 기존에 쓰던 useState(), onClick() 등의 이벤트 리스너, hooks를 사용하려면 클라이언트 컴포넌트를 사용해야 한다.

✅ Request Memoizaition

NextJS에서는 여러 번의 동일한 Data fetching에 대해 캐싱을 지원한다. 강의에서는 deduplication이라고 잠깐 소개해주셨는데, 공식 문서에서는 이를 Request Memoization이라고 표현하는 것 같다. 이는 NextJS만의 기능이 아닌 리액트에서 제공하는 기능이다.

이렇게 그림으로 나와있는데, 와~ 이거 좋다 고 느꼈다. 참고로 메모이제이션은 GET 메소드에 한해서만 작동한다고 한다.

왜지? 라고 잠깐 생각했는데, POST 메소드에 대해서도 캐싱을 해버리면 동작이 비정상적으로 일어날 것 같다고 생각했다. 단순히 받아오는 게 아니라 보내는 데이터가 있기 때문에..

예시 코드는 아래와 같다.

async function getItem() {
  // The `fetch` function is automatically memoized and the result
  // is cached
  const res = await fetch('https://.../item/1')
  return res.json()
}

// This function is called twice, but only executed the first time
const item = await getItem() // 첫 요청에 대한 데이터가 캐시된다. (cache MISS)

// The second call could be anywhere in your route
const item = await getItem() // 같은 요청이기 때문에 캐시된 데이터가 불러와진다. (cache HIT)

💎느낀 점

Next를 어떤 용도로, 어떻게 써먹으면 좋을 지에 대해 다시 한 번 생각했다.

풀스택 웹개발 찍먹 + 자주 다루던 리액트를 사용하기 때문에 시작하긴 했지만, NextJS를 세세히 배워가며 어떤 성격의 프로젝트에 어떻게 활용하면 좋을지 더욱 고찰해봐야겠다.

또한 규모가 큰 프로젝트의 경우 서버 컴포넌트와 클라이언트 컴포넌트의 구조를 적절히 잘 배합하여 시작하는 것이 정말 중요하겠다고 느꼈다.

📚레퍼런스

서버 컴포넌트란 Server Components 리액트 서버 컴포넌트, 간단하게 알아보기

SSR, 유니버셜 렌더링이 중요해지는 요즘 나도 살아남기 위해 NextJS를 배워보기로 결심했다.

NextJS란?

NextJS는 Vercel이 개발한 node.js 기반 리액트 SSR 프레임워크이며, 현재 나이키, 틱톡, 트위치 등의 기업에서 사용되고 있다.

왜 NextJS가 사랑받는지, 어떻게 써먹으면 좋을지는 차차 알아가보자.

✅시작하기

NextJs는 node 18 이상 버젼을 요구한다. 설치되어 있지 않다면 node.js에서 LTS 버젼을 다운받자.

node 설치를 완료하였다면, 작업용 폴더를 하나 만들어준다. 그 후 shift + 우클릭 -> 여기에 Powershell 창 열기를 눌러준다.

이후 터미널에

npx create-next-app@latest

를 입력해준다.

이후 설정은 남자답게 선택해준다. App Router 사용 -> Y만 잘 해주자.

만들어진 폴더를 코드 에디터에서 열어주자.

그러면 위와 같은 폴더 구조가 생성된다.

여기서 짚고 넘어갈 점이 있다.

✅앱 라우터

• layout.tsx : 레이아웃 페이지(메인 페이지를 감싸고 있다)
• page.tsx : 각 페이지의 메인 페이지. 리액트 기반 코드를 작성한다.

1. page는 layout에 항상 감싸져 있다. 따라서 최상위 layout에 헤더를 정의하면, 다른 폴더의 page에는 항상 헤더가 들어가게 된다. 굿
2. NextJS는 폴더 기반으로 알아서 라우팅을 해준다. 위와 같이 'app/cart' 폴더를 만들어두면, http://localhost:3000/cart와 같이 접속했을 때 cart 디렉토리 내에 있는 page.tsx가 보여지게 된다! 이건 정말 편한 것 같다. 당연히 폴더 내 폴더 구조를 통해 중첩 라우팅도 가능하다. http://localhost:3000/cart/payment 접속 시 payment 폴더의 page.tsx가 보이게 된다.

✅이미지 사용

image 태그를 사용할 수도 있지만, NextJS에서는 사이즈 최적화, 레이아웃 시프트, Lazy Loading를 위해 Image 태그를 지원한다.

import Image from "next/image";
import food0 from "/public/images/food0.png";

export default function List() {
  return (
    <div>
      <h4 className="title">상품목록</h4>     
          <Image src={food0} alt="food"/>
        </div>
      ))}
    </div>
  );
}

위와 같이 Image를 임포트하여 써먹도록 하자.

💎최종 목표

방학 동안 NextJS를 이용하여 개인 프로젝트를 하나 완성하고 싶다. 생각중인건 개인 블로그인데, 이후 더욱 구체화시켜야겠다.

마무리 단계에 접어들었다. 짧게 구성된 섹션인만큼 배운 점이 많지는 않았던 것 같다.

📚배운 점

1. npm run build

지금까지는 npm run dev를 통해 개발 모드로 진행했다면, 배포를 위해 이제는 npm run build를 사용한다. 이 때 총 프로젝트의 압축 버전인 dist 폴더가 나온다.

위와 같이 dist 폴더가 나오는 것은 알고 있었지만, 이를 webpack-bundle-analyzer 라이브러리 설치 후 npm run build를 실행하게 되면

위와 같이 각 번들이 어느 정도 공간을 차지하고 있는지 볼 수 있다는 점이 신기했다. 이를 잘 분석하여

1. Tree-shaking을 통해 공간을 확보하거나
2. Code-splitting을 통해 Lazy Loading을 구현할 수 있다는 점이 마음에 들었다.

2. 타입 가드

타입가드는 조건문에서 객체의 타입을 좁혀나가며 타입을 구분, 점검하는 역할을 한다.

• typeof 연산자

  function doSomething(x: number | string) {
  if (typeof x === 'string') { // TypeScript는 `x`가 무조건 `string`이란 걸 알고 있다.
  console.log(x.subtr(1)); // Error: `subtr`은 `string`에 존재하지 않는 메소드다.
  console.log(x.substr(1)); // 굿
  }
  x.substr(1); // Error: `x`가 `string`이라는 보장이 없다.
  }

• in 연산자 내부에 특정 property가 존재하는지 확인하는 연산자이다.

interface IChat { // 채널의 채팅 id: number; UserId: number; User: IUser; content: string; }

export interface IDM { // DM 채팅 id: number; SenderId: number; Sender: IUser; }

interface Props { data: IDM | IChat; }

const user = 'Sender' in data ? data.Sender : data.User; // data라는 객체 안에 Sender 속성이 있는지 검사함

이 외에도 instanceOf, 리터럴 타입 가드, 사용자 정의 타입 가드 등이 있다. 타입 점검 시에 유용하게 써먹을 듯 하다.

---

## ✅해결한 에러

1. 슬랙 아이콘이 제대로 보이지 않던 오류를 수정했다.
2. 가끔 input이 제대로 작동하지 않던 오류를 해결했다.

## 😡해결할 에러
1. 서버에서 온라인 유저 목록이 제대로 불러와지지 않는다.

한 번쯤 써보고 싶었던 웹소켓에 대해 배웠다.

📚배운 점

1. socket.io

웹소켓을 통해 서버, 클라이언트 간 실시간으로 데이터를 주고 받을 수 있다. 채팅 기능을 구현하기 위해 사용하였다.

소켓 사용 프로세스는 다음과 같다. ㆍ connect을 통해 서버와 연결한다. ㆍ emit을 통해 데이터를 보낸다. ㆍ on을 통해 데이터를 받는다. ㆍ disconnect을 통해 연결을 해제한다.

서버 코드는 이미 준비되어 있기 때문에, 아래와 같이 클라이언트에서 useSocket 훅을 구현하여 필요한 곳에서 사용할 수 있도록 하였다.

useSocket 훅 구현

// 우선 알맞은 workspace에 대해 소켓 연결을 저장할 객체를 선언한다.
const sockets: { [key: string]: SocketIOClient.Socket } = {}; 

/* 
  useSocket에서 workspace 인자를 받고,
  해당 워크 스페이스에 연결된 소켓과 disconnect 함수를 반환한다.
*/
const useSocket = (workspace?: string): [SocketIOClient.Socket | undefined, () => void] => {
  // ...
  return [sockets[workspace], disconnect];
}

... 부분에 소켓 연결 생성, 연결 해제 관련 코드를 적는다.

// 소켓 연결 해제를 위한 cleanup 함수
const disconnect = useCallback(() => {
    if (workspace) {
      sockets[workspace].disconnect();
    }
  }, [workspace]);

  if (!workspace) { 
    // workspace가 올바르게 제공되지 않은 경우 undefined를 반환한다
    return [undefined, disconnect];
  }

// socket 연결이 존재하지 않을 시 생성하며, transports를 통해 polling 방식이 아닌 웹소켓으로 업그레이드한다.
  if (!sockets[workspace]) {
    sockets[workspace] = io.connect(`${backUrl}/ws-${workspace}`, {
      transports: ['websocket'],
    });
  }

  return [sockets[workspace], disconnect];

최종 코드는 다음과 같다.

// useSocket.ts
import io from 'socket.io-client';
import { useCallback } from 'react';

const backUrl = 'http://localhost:3095';

const sockets: { [key: string]: SocketIOClient.Socket } = {};
const useSocket = (workspace?: string): [SocketIOClient.Socket | undefined, () => void] => {
  const disconnect = useCallback(() => {
    if (workspace) {
      sockets[workspace].disconnect();
    }
  }, [workspace]);

  if (!workspace) {
    return [undefined, disconnect];
  }

  if (!sockets[workspace]) {
    sockets[workspace] = io.connect(`${backUrl}/ws-${workspace}`, {
      transports: ['websocket'],
    });
  }

  return [sockets[workspace], disconnect];
};

export default useSocket;

이제 다른 컴포넌트에서 useSocket 훅을 통해 소켓을 사용할 수 있다.

사용 예시

import useSocket from '@hooks/useSocket';


const [socket] = useSocket(workspace);

  const onMessage = useCallback(
    () => {
      // 메세지가 왔을 때 필요한 기능 구현
    }
    [],
  );

  useEffect(() => {
    socket?.on('message', onMessage);
    return () => {
      socket?.off('message', onMessage);
    };
  }, [socket, onMessage]);

서버에서 message 이벤트를 수신할 시, onMessage 함수를 호출한다. 이 때 useEffect를 통해 컴포넌트 언마운트 시 리스너를 제거하여 메모리 누수, 원치 않은 동작을 방지한다.

느낀 점

생각보다 클라이언트에서 데이터를 주고 받는 것 자체에 필요한 코드가 많지 않은 것 같다. 오히려 스크롤 처리, 파일 업로드 등 부가적인 요소에 훨씬 할 일이 많은 것 같다.

2. 리버스 무한 스크롤

무한 스크롤은 구현해 본 경험이 있지만, 이를 역으로 구현하는 것은 처음이었다. 채팅의 경우 아래가 아닌 위로 계속 올려 이전 채팅 내역을 보기 때문에, 역방향의 무한 스크롤이 필요했다. 여기서는 swr의 도움을 받아 구현한다.

먼저 대략적인 구조는 다음과 같다.

1. DirectMessage (혹은 Channel)이 ChatList의 부모 컴포넌트이다.
2. ChatList에는 채팅 박스가(스크롤 포함) 구현되어 있다.
3. DirectMessage에 useSWRInfinite를 정의한 뒤, ChatList에서 스크롤바의 ref를 받는다.

// DirectMessage.tsx
const DirectMessage = () => {

  const { data: chatData, mutate: mutateChat, revalidate, setSize } = useSWRInfinite<IDM[]>(
    (index) => `/api/workspaces/${workspace}/dms/${id}/chats?perPage=20&page=${index + 1}`,
    fetcher,
  );
  // index -> page의 수를 의미한다.

  const isReachingEnd = isEmpty || (chatData && chatData[chatData.length - 1]?.length < 20) || false;
  // isReachingEnd를 통해 채팅 데이터를 다 불러왔는지 확인한다.

  const scrollbarRef = useRef<Scrollbars>(null);
  // scrollbar에 접근하기 위해 ref 선언

  return (    
    // ...    
      <ChatList ref={scrollbarRef} setSize={setSize} isReachingEnd={isReachingEnd} />
    // setSize -> page 수를 바꿔주는 함수이다.
    // ...    
  );
};

export default DirectMessage;

4. ChatList에 스크롤, 페이징 관련 함수 onScroll을 정의한다.

   // ChatList.tsx
   const ChatList = forwardRef<Scrollbars, Props>(({ chatSections, setSize, isReachingEnd }, scrollRef) => {
   const onScroll = useCallback(
    (values) => {
      // 채팅 스크롤이 가장 위에 닿았는지 확인
      if (values.scrollTop === 0 && !isReachingEnd) {
        // size를 변경하여 무한 스크롤이 되도록
        setSize((prevSize) => prevSize + 1).then(() => {
          // 스크롤 위치 유지 코드
          const current = (scrollRef as MutableRefObject<Scrollbars>)?.current;
          if (current) {
            current.scrollTop(current.getScrollHeight() - values.scrollHeight);
          }
        });
      }
    },
    [scrollRef, isReachingEnd, setSize],
   );
   
   

return ( // ... ); });

export default ChatList;

❗ **체크할 부분**

- ``forwardRef``를 통해 하위 컴포넌트(ChatList)의 ``scrollRef``를  상위 컴포넌트(DirectMessage)에서 접근할 수 있다.

- 스크롤 관련 작성 코드, ``Optimistic UI``를 위한 처리 등등이 추가로 필요한데, 이는 따로 정리하는 것이 좋을 것 같다.


## 💎 느낀 점
1. 좋은 라이브러리를 많이 알고 사용할 줄 아는 것.
프론트엔드 개발자의 미덕이다.
2. 우리가 흔히 쓰는 채팅 기능을 구현하기 위해 처리할 부분들이 한 두가지가 아니었다. 실제 프로젝트에 적용시키며 익숙해지자..

❗ 본 글은 IT 연합동아리 코테이토의 프론트엔드 네트워킹 3차시 활동을 목적으로 작성된 글이며, 상당히 주관적인 내용을 담고 있습니다. 기획자, 디자이너, 백엔드 개발자와 처음으로 협업을 진행하는 예비 프론트엔드 개발자분들에게 조금이나마 도움이 되길 바라면서 적는 글이며, 기업에서의 협업 방식은 저도 아직 경험해보지 못한 영역이기 때문에 혹시 기업에서의 협업 방식과 크게 다른 부분이 있다면 지적해주시면 감사하겠습니다.

👨🏻‍🏫공통

1. 프론트엔드 개발자의 숙명 📢

프론트엔드 개발자는 기획자, 디자이너, 백엔드 개발자와 모두 밀접하게 맞닿아 있기 때문에, 각 직군과의 의사소통이 가장 잦습니다.

그렇다면 프론트엔드 개발자는 어떻게 훌륭한 소통을 만들어갈 수 있을까요? -> 제 생각에 이상적인 의사소통에 있어 필수불가결한 두 가지는 올바른 문서 작성 및 사용 + 정형화된 용어 라고 생각합니다.

2. 자주 사용되는 툴에 대한 기초적인 사용법을 숙지해놓자

저 같은 경우에 동아리 단위 프로젝트에서는 팀 단위에서 Notion, 디자이너와는 피그마, 백엔드 개발자와는 API 명세서 (ex. Swagger)를 사용하여 소통하는 일이 잦았습니다. 앞서 나온 툴들은 동아리 단위 프로젝트에서는 스탠다드에 가까우며 혹시 사용법을 잘 모르고 있다면 시간을 내서 조금이라도 숙지하도록 합시다.

저는 디자이너 한 분을 붙잡고 2시간 동안 피그마 특강을 들었습니다...

3. 모르면 물어보자

저는 첫 프로젝트에서 회의를 진행하면서 모르는 단어, 처음 써보는 툴이 정말 많았습니다.

ERD? 포스트맨?(가수 X) LO-FI?(노래 장르 아님) Ideation? 피그마에 메모 남기는 법 등등....

너무 기본적이거나 간단하게 느껴지는 것은 자기가 직접 찾아봅시다. 그래도 잘 모르겠으면, 회의의 흐름을 끊지 않는 선에서(쉬는 시간이나 회의 직후) 꼭 물어봅시다. 다들 처음이고 미숙한건 당연하니까요.

모르는 것은 잘못이 아니나 모르는 것을 알면서도 방치하는 것은 죄입니다..

👨🏻‍🏫직군 별

💻백엔드 개발자와의 협업

백엔드와의 협업 = API 통신 그 중에서도 RESTful API 통신이 대표적인데요. 이게 어떤건지 잘 모르시겠다면 이 글을 한 번 읽어보시면 좋을 것 같습니다. 저는 첫 프로젝트를 할 때 처음 들어봤어요..

통신 과정에서, 프론트나 백이나 한 번에 API 연결 딱딱 진행되서 값을 잘 넘겨주고 받아오면 좋겠지만 현실은 녹록지 않죠...😪 대표적인 예로 처음 프로젝트를 경험하게 되면 자주 겪는 CORS 에러, 상황에 따른 request 파라미터 변경 등 서로 소통하게 될 일이 많은데요. 이 때 2가지 정도만 주의하여 진행하면 적어도 욕먹을 일은 없을거에요!

1. 질문 / 문제 발생 시에는 상세히 알려주기

FE : 로그인이 안돼요! - X 

FE : 로그인 해보니 이러이러한 에러가 떴어요! - △

FE : api/~~/login 으로 login, password 값 담아서 post 요청 보냈는데 ~~~한 에러가 돌아옵니다. 확인 부탁드려요 - O

에러 등 문제상황이 생겼을 땐 최대한 모든 정보를 알려주세요! 그래야 원인을 찾기도 쉽고, 시간 낭비도 피할 수 있습니다. 이건 백엔드뿐 아니라 동료 개발자에게도 물론 적용되는 사항입니다.

2. 요청 사항이 있을 시에는 정중하게, 존중하며

위험한 생각 = 이거 하나 바꾸는게 어렵나?

우리도 잘 알잖아요. 하나 바꾸는게 어렵고 귀찮은 경우가 많다는거.. 넘겨주는 값, 넘겨받는 값 등 수정이 필요해 보일 땐 1에서와 같이 어떤 이유로, 어떻게 바꾸면 좋을 지 상세하게 부탁해보도록 합시다. 또한 개발자 간 의사소통에서는, 명확하고 공식적인 용어를 사용하여 착오가 없도록 합시다. API는 프론트와 백엔드 간의 "약속" 입니다.

🎨디자이너와의 협업

다들 개발을 배우는 요즘이지만, 대부분의 사람들에게 개발은 어렵고, 낯선 영역입니다. 디자이너와 협업 시에는 이 점을 명심하고 들어가면 좋을 것 같습니다!

1. 이해하기 쉬운 용어를 사용하자

백엔드 개발자와의 협업에서 공식적인 개발 용어를 사용했다면, 이젠 비유를 통해 설명할 때입니다. 디자이너가 어떤 요청을 했을 때

개발하기 힘들어서 안돼요
렌더링 이슈도 있고 마땅한 라이브러리가 없어서 구현하기 힘들 것 같아요

이런 식으로 얘기하면 능력이 없다거나, 예의가 없다고 뒷담화를 들을 수도 있겠죠? 객체에 대해 배울 때 붕어빵에 비유했던 것처럼, 우리도 비개발자가 알아듣기 쉽도록 설명해줍시다.

2. 존중, 또 존중

프론트엔드 개발자는 디자이너가 만든 화면을 토씨 하나 빠짐없이 그 대 로 퍼블리싱하도록 합시다. 개인의 의견을 넣어 수정, 추가, 삭제 등의 행위를 하는 것은 디자이너를 무시하는 행동이며, 좋은 프론트엔드 개발자가 아닙니다. 그럼에도 불구하고 정말 이건 아니다 싶거나, 사정상 수정이 필요할 때가 있습니다. 그럴 때는 지겹도록 말했듯, 정중하게 물어보도록 합시다.

너무 프론트엔드 개발자가 상대적 약자(?)인 느낌으로 이것저것 적은 것 같은데요. 그래서 이번에는 프로젝트 경험이 적은 디자이너에게 요청하면 좋을 것 들을 알려드리려고 합니다.

1. 컬러 팔레트, 자주 사용되는 컴포넌트(ex.버튼) 따로 빼놓아 주세요!

페이지에서 자주 사용되는 색, 컴포넌트들을 미리 피그마 한 곳에 빼두면, 프로젝트 초기 설정 단계부터 색상을 변수화시키거나, 컴포넌트를 미리 만들어 두기 편하겠죠? 한 번 요청해보도록 합시다.

2. 여러 플로우에 따른 디자인 모두 만들기

그런 경우가 있었습니다.

// 화면에는 좋아요 버튼이 있는데 빈 좋아요 버튼만 있고 눌러진 좋아요 버튼은 없는 경우 // 로그인, 회원가입 중 누락된 입력 값에 대한 알림 텍스트 디자인이 없음

이와 같이 디자이너도 사람이다 보니, 사소한 것들을 빼먹는 경우가 발생합니다. 이런 경우를 미연에 방지하기 위해 한 번씩 미리 말씀드려 요청해보도록 합시다.

마지막으로 VSCode를 쓰시는 분들께 팁 하나 드리자면, 피그마에는 개발자 모드가 있으며, VSCode에도 피그마 익스텐션이 존재합니다.

저 버튼을 눌러 개발자 모드를 활성화시키면

위와 같이 값들만 따로 보기 편하게 활성화됩니다!

또한 VSCode에서도 피그마 익스텐션을 설치하시면

위와 같이 피그마를 보면서 개발할 수 있습니다. 근데 이건 듀얼 모니터 쓰시는 분들에게 권장드려요

섹션 2~3 메뉴와 모달 만들기, DM 보내기를 수강했다.

📚배운 점

1. Input은 컴포넌트 분리

어찌 생각하면 기본이다. 그렇지만 우리는 기본을 자주 잊곤 한다. 규모가 큰 컴포넌트에서는 input을 분리시켜 글자 입력마다 리렌더링이 일어나지 않도록 조심하자.

2. react-toastify

쉽게 예쁜 알림창을 구현해주는 라이브러리. 상세한 내용은 따로 작성해보도록 하고, 간단한 사용법만 정리해보자면

yarn add react-toastify

import {ToastContainer, toast} from "react-toastify";
import 'react-toastify/dist/ReactToastify.css';

const notify = () => toast('toastify test');

// ...

return(
    <div>
      <button onClick={notify}>
        알림 노출
      </button>
        <ToastContainer />
    </div>
)

이런 식으로 사용해주면 알림이 잘 뜨게 된다. 프로젝트에 적용해봐야지..

3. autosize 라이브러리

textarea의 사이즈를 자동으로 늘려주는 라이브러리. 기존에 textarea에 글을 많이 입력하게 되면 사이즈가 아닌 스크롤로 늘어나게 된다.

사용방법

yarn add autosize

타입스크립트라면

yarn add @types/autosize

까지!

import autosize from "autosize";


const ref = useRef<HTMLTextAreaElement>(null);

useEffect(() => {
  if (ref) {
    autosize(ref.current as HTMLTextAreaElement);
  }
}, []);

// ...

return(
  <textarea
    ref={ref}
    value={text}
    onChange={onChangeTextarea}
    placeholder={"내용을 입력해주세요."}
  />
);

이런 식으로 사용하면 된다! textarea도 나름 자주 쓰는 태그인데, 유용하게 잘 써먹을 듯 하다.

💎느낀 점

강의 중 크게 공감했던 말이 있다. 스타일드 컴포넌트 / 혹은 emotion으로 태그를 만들다보면 이름이 뭐 Section부터 시작해서 Wrapper Container Zone 등등 중구난방으로 다양해진다고... 아직까지 공식적인 분류는 없더라도 나만의 규칙을 어느정도 만들어놔야겠다고 생각하게 되었다. (ex. 한 페이지의 제일 큰 부분은 컨테이너, Contents를 담고 있는 작은 부분에 Section 이런 식으로...)