원사이트
수박 겉핥기 사고방식
수박 겉 핥기 사고방식
글을 잘 쓰려면 책을 꽤 읽어야 한다. 우째 쓰는지 읽어 봐야 내 글을 쓸 것 아닌가. 마찬가지로 코드를 잘 짜기 위해서는 내가 해결하고자 하는 문제와 관련된 코드를 많이 읽어야 한다.
~~원민관 감 다 죽었네,,, 당연한 소리 아님요;;~~
아니다, 기다려보셈.
코드를 읽을 때 순차적으로 읽어야 한다. 그런데 최근에 더 확실히 느낀 것은 2차원 평면을 기준으로 위에서 아래로 순차적으로 읽는 것이 아니라, 3차원 도형이라고 가정하고 겉에서부터 속으로 순차적으로 읽어나갈 줄 알아야 한다는 것이다. 최근 작업을 기준으로 이야기를 전개해 보겠다.
초록색 껍데기
수박의 초록색 껍데기 부분을 담당하는 것은, UI이다. Q&A 사이트를 개발하는 원 모 씨가 있다.


잘은 모르겠지만 submit question 버튼을 클릭하면 data가 위 카드 형태로 추가되는 것 같다. 그렇다면 첫 번째 껍데기에서 파악해야 하는 것은 ``내가 무엇을 submit 할 것인가``라는 점이다. 내가 현재 파악한 초록 껍데기는 다음과 같다.
// edit page에서 question을 submit 할 때의 entity
export class Question {
// id: 개별 question에 대한 고유 식별값
id: number;
// title: 개별 question의 제목
title: string;
// tags: 여러 question cards를 필터링하기 위한 요소, 배열로 설정하여 다양한 태그 수용
tags: string[];
// content: 개별 question의 실질적인 내용
content: string;
// askedBy: 질문자 닉네임, 향후 auth와 연동
askedBy: string;
// createdAt/updatedAt: 생성 및 수정 날짜
createdAt: Date;
updatedAt: Date;
// upVote/downVote: 추천순 필터링을 위한 데이터
upVoteCount: number;
downVoteCount: number;
// answerCount/viewCount: 질문에 대한 답변 및 조회수 관리를 위한 데이터
answerCount: number;
viewCount: number;
}
현재는 진행되는 프로젝트 상황을 기준으로 설명해서 미진한 부분이 있지만, 사실 초록 껍데기에서 가장 핵심적으로 다루어야 할 내용은 state management다. 조금 멋있게 표현하면 프론트에서 "무엇을 보낼 것인가"는 사실 '상태(State Data)'에 관한 문제이고, 결국에는 상태 관리를 어떻게 하느냐에 따라 프론트의 퀄리티가 달라진다고 볼 수 있다.
노란색 껍데기

김치의 민족. 별걸 다 김치를 해 먹는다. 수박은 초록색과 빨간색 사이, 노란색 영역이 존재한다. NestJS로 백엔드를 구현하고 있는 나는, module을 노란색 껍데기로 인식했다.

Frontend에서는 최종적으로 App 컴포넌트를 보여주고, App 컴포넌트는 하위의 page들로 구성되어 있다. 이것이 기본 구조이고, 필요에 의해 반복되는 UI적 요소는 components로 분리하고, 반복되는 상태 로직은 hooks로 분리할 뿐이다.
Backend도 크게 다를 바 없다. 최종적인 end point는 App Module이다. modules directory에 필요한 여러 module을 만들고 그 모듈들을 App Module에 연동한다. 과정 중에 필요한 pipes나 interceptor 등이 추가적으로 붙을 뿐이다.
그런데 module은 module이고, 노란 껍데기의 핵심은 controller다.

초록 껍데기에서 내가 무엇을 submit 할 것인가에 대한 내용은 백엔드 src/modules/questions/questions.entity.ts에 정의해두었다. 컨트롤러는 ``요청을 어디로 보낼 것인가``에 대한 고민을 한다.
> **빨간색 알맹이**
겉핥기 사고방식으로 두 가지 문제를 처리했다. ```무엇을 submit 할 것인가```, ```요청을 어디로 보낼 것인가```가 바로 그것이다. 마지막은 ```어떻게 처리할 것인가```이다.
import { Injectable } from '@nestjs/common'; import { Question } from './questions.entity';
@Injectable() export class QuestionsService { private questions: Question[] = [];
create(title: string, content: string, tags: string[]): Question { const newQuestion = new Question(); newQuestion.id = this.questions.length + 1; newQuestion.title = title; newQuestion.content = content; newQuestion.tags = tags; newQuestion.askedBy = 'Anonymous'; newQuestion.createdAt = new Date(); newQuestion.updatedAt = new Date(); newQuestion.upVoteCount = 0; newQuestion.downVoteCount = 0; newQuestion.answerCount = 0; newQuestion.viewCount = 0;
this.questions.push(newQuestion); return newQuestion; } }
More to read
프론트엔드와 백엔드 사이
HTTP 상태 코드는 프론트엔드에서 백엔드로 보냈던 요청의 수행 결과를 의미하는 일종의 약속이며, API를 구성하는 핵심 요소 중 하나입니다. 상태 코드와 관련하여, 백엔드는 잘 모르는 프론트엔드의 슬픈 사정이 있습니다.아래는 요청이 실패했음에도, 백엔드에서 상태 코드
JWT토큰 관리 방식 톺아보기
0. 들어가며 🎯 서비스에 접근하려는 사용자가 누구인지 확인하는 과정을 사용자 인증이라고 합니다. 인증된 사용자에게 주어진 권한을 확인하는 작업은 인가라고 부릅니다. 이번 글에서는 인가는 다루지 않습니다. 사용자 인증에는 많은 방식이 있지만, 오늘은 세션 인증 방
A2AA2A / MCP 멀티 에이전트 오케스트레이션
0. 들어가며 ✍️ Google for Developers에, 레스토랑 공급망 시나리오로 엮은 6대 프로토콜(MCP, A2A, UCP, AP2, A2UI, AG-UI)에 대한 가이드가 게시된 이후, MCP와 A2A부터 구현해 보는 것이 좋을 것 같다는 생각이 들었습니