Dorong Dorong 💻😴

현재 Express.js를 사용하여 REST API를 구축 중입니다.

나중에 팀원이 합류하거나, 바쁜 일정 후에 다시 프로젝트를 봐야 할 때를 대비해 문서화를 하려 합니다.

시간의 제약 때문에 Swagger와 OpenAPI Specification을 사용해 Design First 방식으로 규격을 정의하고,

이를 기반으로 문서화하고 있습니다.

API의 검증 및 라우팅을 자동화하기 위해 express-openapi-validator 미들웨어를 사용하고 있지만, 몇 가지 문제가 발생했어요 🧐

JWT를 http-only cookie로 전달하려는데, Authorization 헤더와 CSRF 토큰 관련 검증에서 문제가 발생한 것입니다!!!

문제 상황

1. CSRF 토큰이 있고 Authorization 헤더가 없을 때
   • Authorization 헤더 필수 에러가 발생하지 않음
   • 이때 JWT 토큰은 쿠키로 전송
2. CSRF 토큰과 Authorization 헤더 모두 없을 때
   • Authorization 헤더 필수라는 에러 발생
   • 이때도 JWT 토큰은 쿠키로 전송
3. CSRF 토큰 없이 Authorization 헤더만 있을 때
   • CSRF 토큰 필수라는 에러 발생

원인 분석

http-only cookie를 사용 중이므로, Authorization 헤더를 보내지 않더라도 쿠키의 JWT 토큰만으로 유효성을 검증하고 싶었습니다.

하지만 validateSecurity 미들웨어 로직에서 CSRF나 JWT 둘 다 누락될 경우 해당 미들웨어의 보안 핸들러가 작동하지 않는다는 사실을 알게 되었습니다.

코드 분석

express-openapi-validator의 내부 코드를 분석하면서 인증 관련 로직이 SecuritySchemes 클래스와 AuthValidator 클래스에서 처리된다는 것을 발견했습니다.

• SecuritySchemes 클래스는 securityHandlers를 통해 보안 검증 핸들러를 실행합니다.
• AuthValidator 클래스는 요청 헤더를 검사하고, Authorization 헤더가 있는지 확인합니다.
• 특히 validateHttp() 메서드는 이 Authorization 헤더를 필수로 요구하고 있었습니다. 이 때문에 type: http로 설정된 스킴에서는 Authorization 헤더가 필수였던 것입니다!!

아래는 관련 코드이니 참고해 주세요!

• SecuritySchemes

class SecuritySchemes {
95    constructor(securitySchemes, securityHandlers, securities) {
96        this.securitySchemes = securitySchemes;
97        this.securityHandlers = securityHandlers;
98        this.securities = securities;
99    }
100    async executeHandlers(req) {
101        // use a fallback handler if security handlers is not specified
102        // This means if security handlers is specified, the user must define
103        // all security handlers
104        const fallbackHandler = !this.securityHandlers
105            ? defaultSecurityHandler
106            : null;
107        const promises = this.securities.map(async (s) => {
108            if (Util.isEmptyObject(s)) {
109                // anonymous security
110                return [{ success: true }];
111            }
112            return Promise.all(Object.keys(s).map(async (securityKey) => {
113                var _a, _b, _c;
114                try {
115                    const scheme = this.securitySchemes[securityKey];
116                    const handler = (_b =
117                        (_a = this.securityHandlers) === null || _a === void 0
118                            ? void 0
119                            : _a[securityKey]) !== null && _b !== void 0
120                        ? _b
121                        : fallbackHandler;
122                    const scopesTmp = s[securityKey];
123                    const scopes = Array.isArray(scopesTmp) ? scopesTmp : [];
124                    if (!scheme) {
125                        const message = `components.securitySchemes.${securityKey} does not exist`;
126                        throw new types_1.InternalServerError({ message });
127                    }
128                    if (!scheme.hasOwnProperty('type')) {
129                        const message = `components.securitySchemes.${securityKey} must have property 'type'`;
130                        throw new types_1.InternalServerError({ message });
131                    }
132                    if (!handler) {
133                        const message = `a security handler for '${securityKey}' does not exist`;
134                        throw new types_1.InternalServerError({ message });
135                    }
136                    new AuthValidator(req, scheme, scopes).validate();
137                    // expected handler results are:
138                    // - throw exception,
139                    // - return true,
140                    // - return Promise<true>,
141                    // - return false,
142                    // - return Promise<false>
143                    // everything else should be treated as false
144                    const securityScheme = scheme;
145                    const success = await handler(req, scopes, securityScheme);
146                    if (success === true) {
147                        return { success };
148                    }
149                    else {
150                        throw Error();
151                    }
152                }
153                catch (e) {
154                    return {
155                        success: false,
156                        status: (_c = e.status) !== null && _c !== void 0 ? _c : 401,
157                        error: e,
158                    };
159                }
160            }));
161        });
162        return Promise.all(promises);
163    }
164}

• AuthValidator

class AuthValidator {
166    constructor(req, scheme, scopes = []) {
167        const openapi = req.openapi;
168        this.req = req;
169        this.scheme = scheme;
170        this.path = openapi.openApiRoute;
171        this.scopes = scopes;
172    }
173    validate() {
174        this.validateApiKey();
175        this.validateHttp();
176        this.validateOauth2();
177        this.validateOpenID();
178    }
179    validateOauth2() {
180        const { req, scheme, path } = this;
181        if (['oauth2'].includes(scheme.type.toLowerCase())) {
182            // TODO oauth2 validation
183        }
184    }
185    validateOpenID() {
186        const { req, scheme, path } = this;
187        if (['openIdConnect'].includes(scheme.type.toLowerCase())) {
188            // TODO openidconnect validation
189        }
190    }
191    validateHttp() {
192        const { req, scheme, path } = this;
193        if (['http'].includes(scheme.type.toLowerCase())) {
194            const authHeader = req.headers['authorization'] &&
195                req.headers['authorization'].toLowerCase();
196            if (!authHeader) {
197                throw Error(`Authorization header required`);
198            }
199            const type = scheme.scheme && scheme.scheme.toLowerCase();
200            if (type === 'bearer' && !authHeader.includes('bearer')) {
201                throw Error(`Authorization header with scheme 'Bearer' required`);
202            }
203            if (type === 'basic' && !authHeader.includes('basic')) {
204                throw Error(`Authorization header with scheme 'Basic' required`);
205            }
206        }
207    }
208    validateApiKey() {
209        var _d;
210        const { req, scheme, path } = this;
211        if (scheme.type === 'apiKey') {
212            if (scheme.in === 'header') {
213                if (!req.headers[scheme.name.toLowerCase()]) {
214                    throw Error(`'${scheme.name}' header required`);
215                }
216            }
217            else if (scheme.in === 'query') {
218                if (!req.query[scheme.name]) {
219                    throw Error(`query parameter '${scheme.name}' required`);
220                }
221            }
222            else if (scheme.in === 'cookie') {
223                if (!req.cookies[scheme.name] && !((_d = req.signedCookies) === null || _d === void 0 ? void 0 : _d[scheme.name])) {
224                    throw Error(`cookie '${scheme.name}' required`);
225                }
226            }
227        }
228    }
229}

문제 해결

기존 설정

jwt_auth:
  description: Bearer token authorization with JWT
  type: http
  scheme: bearer
  bearerFormat: JWT

• jwt_auth는 type: http로 설정되어 있었고, 이 때문에 validateHttp() 메서드가 실행되어 Authorization 헤더가 필수라는 에러가 발생했습니다.

새로운 설정

jwt_auth:
  type: apiKey
  in: cookie
  name: token
  description: JWT token authentication using HTTP-Only cookies

• jwt_auth를 type: apiKey로 설정하여, 이제 쿠키에서 JWT를 검증하도록 변경했습니다.

변경 후 validateApiKey() 메서드가 쿠키에서 JWT를 검증하게 됐습니다!

이제야 의도한 대로 잘 동작하네요!

다만, Authorization 헤더를 보내지 않았을 때, 에러의 원인은 파악됐지만 아직도 CSRF 토큰을 보내줬을 땐 왜 통과되는 걸까?라는 의문은 해결이 안 됐습니다.

그리고 그 의문은 제가 작성해둔 아래의 validateSecurity 코드를 다시 돌아보며 풀리게 됐어요..😭

validateSecurity: {
	handlers: {
        jwt_auth: async (req) => {
          const isTokenValid = await authHandler(req);
          return isTokenValid && csrfCheck(req);
        },
        csrf_token: authHandler,
     },
},

csrf_token의 handler는 csrf_token을 보내주지 않았을 땐 동작하지 않았습니다.
그래서 저는 위처럼 jwt_auth에서 jwt_auth가 있을 시 csrf_token의 체크도 함께해 주도록 만들었어요.

하지만 핸들러를 이런 식으로 등록해야 하는 건 부자연스럽다고 생각합니다.
그래서 이 부분은 더 검토해 본 후 공유하려 합니다.
하지만 오늘은 type: http에 대한 validateHttp 로직이 AuthValidator Header를 필수로 요구한다는 게 메인 주제이니 여기서 더 다루진 않겠습니다.

추가 고려 사항

type: apiKey로 변경하면 Bearer 토큰에 대한 검증이 사라진다는 문제가 있습니다.

기존에는 type: http 설정 덕분에 validateHttp 메서드가 실행되었고, 이 메서드는 Authorization 헤더에 Bearer 토큰을 요구하면서 JWT를 검증했습니다. 하지만 type: apiKey로 변경하게 되면 이제 validateApiKey 메서드가 실행되고 validateApiKey는 Bearer 토큰 형식을 전혀 다루지 않습니다.

왜 Bearer 검증이 중요할까요?
JWT 토큰은 기본적으로 Bearer 토큰으로 전송되는 경우가 많습니다.

즉, Authorization: Bearer <JWT> 형태로 전송되기 때문에, 이 방식을 그대로 사용하고 싶다면 type: http와 scheme: bearer 설정을 유지해야 합니다. 이렇게 해야 validateHttp가 적절히 Bearer 토큰을 검증 가능할 테니까요.

하지만 단순히 JWT만 검증하고 싶고 Bearer 형식에 얽매이지 않겠다면, 현재처럼 type: apiKey로 설정한 후 쿠키에서 JWT를 검증하는 로직으로 충분합니다.

현재까진, JWT를 Bearer 형식으로 유지하고 싶다면 validateHttp() 메서드에서 쿠키로 전달된 JWT도 함께 검증하도록 로직을 추가하는 것이 바람직하다고 판단됩니다.

결론

• 쿠키 기반 JWT 인증만 사용한다면, type: apiKey로 설정한 후 쿠키에서 JWT를 검증하는 방식을 사용해야 합니다.
• 하지만 Bearer 토큰 방식의 검증이 필요하다면 type: http 설정을 유지하고, validateHttp()에서 쿠키를 처리하는 로직을 추가해야 합니다.

제가 생각한 방식이 맞는지, 놓친 부분은 없는지 검토하기 위해 validateHttp 메서드를 수정후 PR을 남겨둔 상태입니다.
빠른 적용 후 피드백을 위해 연관된 테스트 코드까진 손을 대지 않았지만,
프로젝트를 진행하며 더 깊게 고민해 볼 예정입니다!

Allini는 Create React App(CRA)을 사용하지 않고, 직접 Webpack과 Babel을 설정해보기로 했습니다.
회사에서 Webpack을 설정해본 경험이 있어, 처음에는 그 기억에 의존해 작업을 시작했어요.

그런데 프로젝트 진행 도중 Pretendard-Black.subset.woff2 및 Pretendard-ExtraBold.subset.woff2 폰트 파일을 찾을 수 없다는 에러가 발생했습니다.

이 에러를 해결하기 위해 파일 위치, font.css의 경로, 파일명, 빌드 캐시 삭제 등 다양한 방법을 시도했지만,

문제는 여전히 해결되지 않았고..😢

제가 작성한 Webpack 설정 자체에 문제가 있는 것이 아닌가 의심하게 됐습니다.

Webpack 설정 점검: file-loader는 잘 등록했는데...

에러가 발생한 이유를 찾기 위해 webpack.config.js 파일에서 파일 로더 설정을 확인했습니다.

file-loader를 아래와 같이 설정해두었기에, 문제가 없을 것이라고 생각했었죠..! 

{
  test: /\.(png|jpe?g|gif|webp)$/i,
  use: [
    {
      loader: "file-loader",
      options: {
        name: "[path][name].[ext]",
      },
    },
  ],
}

그렇기에 이 설정에는 아무런 문제가 없다고 판단했고, 왜 이런 문제가 발생하는지 도저히 이해가 되지 않았습니다.

엉뚱한 고민: MSW가 문제인가?

이쯤 되니 MSW(Mocking Service Worker)가 폰트 파일조차 가로채는 것이 아닌가 하는 엉뚱한 생각까지 하게 되었어요..!

MSW는 백엔드가 구축되기 전에 프론트엔드 UI 개발을 위해 사용 중이었습니다.

하지만 공식 문서를 읽어본 결과, MSW는 정적 리소스(예: 폰트 파일)에는 영향을 주지 않는다는 것을 확인했습니다.

MSW가 폰트 파일 요청을 가로채지 않는 한, 이 문제는 MSW와 관련이 없을 가능성이 높았습니다.

진짜 문제: Webpack 버전 차이

고민을 거듭하던 중, 혹시 내가 알고 있던 Webpack 설정과 현재 사용하는 버전 간에 차이가 있는 것은 아닐까 하는 생각이 들었습니다.

이 생각이 바로 정답이었죠!!!  ᕦ( ᐛ )ᕡ

Webpack 5에서는 파일 로더 설정이 간소화되었고, 더 이상 file-loader를 사용할 필요가 없었습니다.

Webpack 5에서는 다음과 같이 설정합니다:

{
  test: /\.(jpg|jpeg|gif|png|svg|eot|woff|ttf)$/i,
  type: "asset/resource",
}

Webpack 5에서는 file-loader와 url-loader등을 더 이상 사용하지 않고, asset/resource, asset/inline, 그리고 asset을 통해 파일을 처리합니다.

• asset/resource: 별도의 파일을 내보내고 URL을 반환합니다. (file-loader 대체)
• asset/inline: 데이터 URL로 내보내기 (url-loader 대체)
• asset: 자동으로 데이터 URL과 파일 내보내기 중 선택하며, 기존의 크기 제한 설정도 포함됩니다.

더 자세한 내용은 참고했던 Webpack 공식 문서 링크를 남겨둘게요!!

학습 방식에 대한 반성, 그리고 앞으로의 계획

이전에 TOAST Editor가 React 17 버전까지만 지원된다는 이슈를 겪었던 적이 있습니다.

부끄럽지만 그때도 이전 지식에만 의존했던 탓에, 사용된 기술 스택에 대해 충분히 검토하지 않았던 경험이 있었습니다.

이번 Webpack 설정 문제를 겪으면서, 다시 한 번 저의 학습 방식에 대해 돌아보게 되었습니다..!

Webpack 버전을 올린 후에도 다른 작업에 급급해 중요한 변화를 미처 확인하지 않았던 것이 원인이었으니까요.

Allini 프로젝트는 팀원들의 회사 업무로 인해 잠시 중단되었었지만, 다시 시작하게 되었습니다!

현재는 디자이너님이 요청한 수정된 UI를 빠르게 적용하는 것이 우선순위가 높다고 판단하여, 이 부분부터 작업을 진행하고 있습니다. 

그렇기에 Webpack 5 버전에 맞춘 전체적인 설정 수정은 프로젝트가 완성된 후에 진행하기로 결정했습니다.

우선은 프로젝트의 완성도를 높이는 데 집중하고, 작업 중 발생하는 문제들은 하나씩 해결해 나갈 계획입니다.

프로젝트가 마무리되면, CSS 파일을 개별적으로 추출하기 위한 MiniCssExtractPlugin 등의 리팩토링도 진행할 예정입니다.

이 과정에서 작성된 최종 코드도 나중에 블로그에 공유할 예정이니, 기대해 주세요! 💪

React.js와 Next.js 프로젝트를 진행하던 중, 처음 개발 공부를 시작할 때 고민했던 라이브러리와 프레임워크에 대해 다시 한번 정리해보기로 했습니다.

과거에는 이들을 완성된 로봇과 조립형 로봇에 비유하곤 했지만, 지금은 다르게 접근해보려 합니다.

그렇다면 공식 문서부터 확인해 보겠습니다!

공식 문서의 메인 페이지에서조차 "사용자 인터페이스를 만들기 위한 JavaScript 라이브러리" 라는 문구로 우리를 환영하고 있습니다.

그렇다면 수많은 사람들은 도대체 무엇 때문에 혼동하게 된 걸까요?

라이브러리와 프레임워크에 대해 간략히 설명드린 후 "React.js는 라이브러리일까?"  목차에서 다시 한번 정리해 보겠습니다. 

라이브러리와 프레임워크란?

라이브러리

검색 시 쉽게 아래의 내용들을 확인해 보실 수 있습니다.

"특정한 기능을 쉽게 사용할 수 있도록 미리 작성된 코드의 집합"

"개발자가 필요에 따라 라이브러리를 호출하여 사용하는 방식으로, 도구처럼 필요한 부분만 선택적으로 사용"

정리해 보자면, 무언가를 만들 때 유용한 도구 같은 친구네요.

마치 미용실에서 쓰는 도구나 공사 현장에서 쓰는 도구처럼, 특정한 문제를 해결해 주는 기능을 제공해 줍니다.

드라이기로 머리를 말릴 필요는 없지만, 필요하면 사용할 수 있는 것처럼 이런 도구들은 필요에 맞게 골라 쓸 수 있습니다.

프레임워크

라이브러리보다 더 큰 단위의 솔루션을 제공합니다.

라이브러리에서의 예시를 가져와 보겠습니다.

미용실에서 머리를 말리는 방법을 다 정해주고, 그 안에서 정해진 방법을 이용해 머리를 말리는(필요한 로직을 구현하는) 방식입니다.

그래서 Next.js는 React.js를 베이스로 해 웹을 만드는데 필요한 전체적인 해결책을 제공해 줍니다!

React.js와 Next.js의 관계

• React.js는 UI를 선언적으로 만들기 위한 라이브러리로, 필요한 기능을 선택적으로 사용합니다.
• Next.js는 웹 어플리케이션 개발에 필요한 전체적인 솔루션을 제공하며, React를 기반으로 다양한 기능을 포함한 프레임워크입니다.

지금까지 라이브러리, 프레임워크와 React,js, Next.js에 대해 간략히 설명드렸습니다.

이제 본론으로 들어가 보도록 하겠습니다!

React.js는 라이브러리일까?

저는 프레임워크와 라이브러리에 대한 학습에서 "프레임워크 없는 프론트엔드 개발 | 프란세스코 스트라츨로" 교재의,

"프레임워크는 코드를 호출하고 코드는 라이브러리를 호출한다"라는 문구가 가장 와닿았습니다.

교재를 학습하며 해당 문구가 라이브러리와 프레임워크의 차이에 대해 정말 잘 설명하고 있다는 생각이 들었어요.

발췌한 문장을 기반으로 다시 정리하자면,

• 프레임워크는 코드를 호출하여 실행 흐름을 제어합니다.
• 라이브러리는 개발자가 필요한 기능을 호출하여 사용하는 도구입니다.

발췌한 문장을 기반으로 글을 써 내려갈 예정이에요.

참고하여 읽으신다면 좀 더 도움이 되실 거라 생각합니다!

이는 React가 UI 컴포넌트를 만들고 관리하는 데 중점을 두기 때문입니다.

그러나 저를 포함한 많은 개발자들은 React를 프레임워크처럼 사용하고 있습니다.
이유가 뭘까요?

이는 리액트 생태계와 커뮤니티의 강력한 영향력 때문입니다.
React는 UI를 렌더링하는 라이브러리로 시작했지만, 생태계의 발전과 함께 많은 개발자들이 React를 이용해 프레임워크처럼 프로젝트를 구조화하고 있습니다. 

이제 지금까지의 내용을 토대로 실제 개발과정을 예시로 들어 다시 한번 정리해 보도록 할게요!

어떻게 사용해야 될까?

프로젝트를 진행할 때, 프레임워크와 라이브러리의 사용 방식과 목적을 명확히 이해하는 것이 중요합니다.

React를 프레임워크처럼 사용할 때와 라이브러리처럼 사용할 때의 차이를 이해하면 더 나은 선택을 할 수 있습니다.

React를 프레임워크처럼 사용할 때

커뮤니티와 생태계의 영향력

• 리액트는 초기 설정과 구조가 이미 잡혀있는 상태에서 시작하기 때문에 많은 개발자들은 이를 프레임워크처럼 사용하게 됩니다. 예를 들어, npm create-react-app으로 프로젝트를 시작하면 정해진 구조 안에서 개발을 진행하게 됩니다.

컴포넌트 내의 다양한 기능

• 리액트를 사용할 때 컴포넌트에 이벤트 핸들러, 비즈니스 로직, API 호출 등을 모두 포함시킵니다. 이러한 방식은 리액트가 코드를 호출하는 형태로 동작하게 하여 프레임워크처럼 느껴지게 만듭니다.

즉, React 컴포넌트가 모든 실행 흐름을 제어하며, 강한 결합이 발생할 수 있습니다.

장점:

• 빠른 개발 속도: 비즈니스 로직을 리액트 컴포넌트 내부에 통합하여 빠르게 개발할 수 있습니다.
• 코드 구조가 명확하고 일관성이 있습니다.

단점:

• 의존성 증가: 비즈니스 로직이 리액트 컴포넌트에 강하게 결합되어 있어, 리액트를 다른 라이브러리로 대체하기 어렵습니다.
• 이는 향후 마이그레이션 시 큰 비용을 초래할 수 있습니다.

React를 라이브러리처럼 사용할 때

비즈니스 로직과 UI 렌더링을 분리하고, 이 둘을 연결하는 인터페이스를 두는 방법

상태 관리와 UI 업데이트

• 리액트에서 setState를 호출하면 UI가 리렌더링 됩니다. 이 점을 활용하여, setState를 UI를 업데이트하는 요소로 간주하고, UI 업데이트가 필요한 시점에만 setState를 호출하게 합니다.
• 이런식으로 비즈니스 로직은 리액트와 독립적으로 동작하도록 합니다. 이렇게 하면 리액트는 오로지 UI를 렌더링하는 역할만 하게 되며 상태 관리를 최소화할 수 있습니다.

비즈니스 로직 분리

• 비즈니스 로직은 퓨어한 자바스크립트로 작성하여 리액트와 독립적으로 동작하도록 합니다.
• 이를 통해 비즈니스 로직은 UI와 별개로 작동하게 됩니다.

UI 렌더링에만 집중

• 리액트를 순수 UI 렌더링 라이브러리로 사용하려면 비즈니스 로직을 리액트 외부의 순수 자바스크립트 클래스 등의 코드로 분리합니다. 리액트는 오직 데이터를 화면에 렌더링하는 역할만 수행합니다.
• 비즈니스 로직을 담당하는 클래스 등의 자바스크립트 코드로 작성하여, 데이터 처리와 상태 관리를 독립적으로 수행합니다.

인터페이스를 통한 통신

• 비즈니스 로직과 리액트 컴포넌트 간의 데이터 통신(연결)을 담당하는 인터페이스를 설계하여, 상태 변경을 리액트에 전달합니다.
• 이 인터페이스는 비즈니스 로직의 상태 변경을 감지하고, 필요한 시점에 리액트의 setState를 호출하여 UI를 업데이트합니다.

간단한 구현 예시

/**
* 비즈니스 로직 - 순수 자바스크립트 클래스
*/
class BusinessLogic {
  constructor() {
    this.data = null;
    this.listeners = [];
  }

  setData(newData) {
    this.data = newData;
    this.notifyListeners();
  }

  getData() {
    return this.data;
  }

  addListener(listener) {
    this.listeners.push(listener);
  }

  notifyListeners() {
    this.listeners.forEach(listener => listener(this.data));
  }
}

/**
* 리액트 컴포넌트 - UI 렌더링
*/
import React, { useState, useEffect } from 'react';

const TestComp = ({ businessLogic }) => {
  const [data, setData] = useState(businessLogic.getData());

  useEffect(() => {
    const handleDataChange = (newData) => {
      setData(newData);
    };

    businessLogic.addListener(handleDataChange);

    return () => {
      businessLogic.removeListener(handleDataChange);
    };
  }, [businessLogic]);

  return (
    <div>
      <h1>{data}</h1>
    </div>
  );
};

/**
* 비즈니스 로직과 리액트 컴포넌트 사용
*/
const logic = new BusinessLogic();
logic.setData("커피 마시고싶다..");

const App = () => (
  <TestComp businessLogic={logic} />
);

export default App;

장점

• 만약 리액트를 시장에서 더이상 원하지 않게 되거나 새로운 UI 렌더링 라이브러리(예: 스벨트)를 사용하고 싶을 때, 라이브러리처럼 구현했다면 전환이 매우 쉽습니다.
• 비즈니스 로직이 리액트와 독립적이기 때문입니다.

단점

• 실제 사례 드묾: 많은 회사들이 라이브러리처럼 구현하는 방식을 채택하지 않습니다. 이는 개발 비용과 시간이 많이 들기 때문입니다.
• 높은 개발 비용: 비즈니스 로직과 UI를 분리하여 모든 것을 인터페이스로 관리하면 개발 비용이 많이 듭니다. 이렇게 하면 초기 런칭이 어려워질 수 있습니다.

아래에서 좀 더 상세히 저의 생각을 풀어보려 합니다.

위와 중복되는 내용이 있지만 흐름을 위해 그대로 적어보도록 하겠습니다!

기술 부채와 그 관리

저는 기술 부채에 대해 개발 과정에서 단기적인 이익을 위해 장기적인 유지보수 비용을 증가시키는 선택이라고 생각합니다.

그리고 이 기술 부채의 개념은 "React.js의 라이브러리와 프레임워크 방식의 결정"에 도움을 줄 것이라 생각해요!

그래서 지금부터 React를 프레임워크처럼 사용할 때와 라이브러리처럼 사용할 때의 기술 부채를 비교해 보도록 하겠습니다.

프레임워크처럼 사용할 때의 기술 부채

• 강한 결합으로 인해 다른 라이브러리로 전환이 어려워집니다.
• 비즈니스 로직이 React 컴포넌트에 깊이 결합되어 유지보수가 어렵습니다.

라이브러리처럼 사용할 때의 기술 부채

• 초기 개발 비용이 높을 수 있습니다.
• 각 기능이 분리되어 있어 개발 속도가 느려질 수 있습니다.

기술 부채 관리의 중요성

기술 부채를 효과적으로 관리하는 것은 중요합니다.

프로젝트의 요구사항과 일정에 맞게 기술 부채를 잘 조정하면, 장기적으로 더 나은 유지보수와 확장성을 확보할 수 있습니다.

무엇보다 저는 기술 부채가 생겨도 청산만 잘하면 문제가 없다고 생각합니다.

그래서 기술 부채를 잘 내는 것도 저는 중요한 능력이라고 보고있습니다.

개발자가 이쁜 코드만 작성하는 예술가는 아니니까요.

그러니 무언가를 사용할 때 단순하게 정의된 특정 단어나 문장만을 받아들이는 게 아니라 상대적으로 생각하는 습관을 들일 수 있다면 빠른 성장에 유리하지 않을까 생각합니다.

결론

React는 공식적으로 라이브러리이지만, 많은 개발자들이 프레임워크처럼 사용하고 있습니다.

프로젝트의 특성과 요구사항에 따라 React를 어떻게 사용할지 결정하는 것이 중요합니다.

기술 부채를 관리하면서, 프레임워크와 라이브러리의 차이를 이해하고 적절하게 활용하면 성공적인 개발을 이룰 수 있습니다.

상대적으로 사고하고, 상황에 맞는 최선의 선택을 하는 습관을 기르면 더욱 빠르게 성장할 수 있을 것입니다!

여러분들께서 이 글을 읽고 난 후에도, 계속 학습하며 다양한 의견을 접하게 되시겠죠?!

자신들만의 단어로 설명할 수 있게 되고, 개발 방향에 대한 길잡이 역할에 도움이 될 수 있기를 바라며 이만 마치겠습니다.

로고의 디자인은 프로젝트명인 Allini의 A와 강아지의 코 모양을 섞어 디자인됐어요!

안녕하세요, 오늘은 제가 최근에 시작한 프로젝트에 대해 소개하려고 합니다.

이 프로젝트는 제 반려견의 건강을 관리하고 알레르기 증상을 줄이기 위해 시작됐어요!

우리 강아지들이 먹은 음식들을 기록하고, 그 정보를 기반으로 통계를 내고, 심지어는 간식을 추천해주기도 합니다.

뿐만 아니라, 우리 강아지가 알레르기 반응을 보인 음식들도 기록할 수 있어요.

하지만 왜 Allini 프로젝트를 만들게 됐을까요?!

저희 가족의 소중한 멤버이자 마스코트인 반려견의 이름은 "뽀글이" 입니다. 이름 귀엽죠?!

"화이트 슈나우저"라는 견종이에요.

슈나우저는 유전적으로 피부질환이 있는 편입니다.

뽀글이의 경우엔 알레르기성 피부염이나 식이 알레르기로 인한 피부 두드러기, 간지러움 등 환경과 식이의 문제가 가장 심했어요.

식이 알레르기 같은 경우는 사료와 간식을 제한하고 동물 병원에서 처방받은 처방 사료를 급여하고 간식을 제한하고 어떤 재료에 알레르기가 있는지 검사를 해서 그 재료를 피하면 식이 알레르기는 해결할 수 있습니다.

물론 피부 질환이 거의 없는 개체도 있어요! 

하지만 사람도 강아지도, 살아가며 본인에게 있는 알레르기가 계속 바뀐다는 사실 알고 계셨나요?!

자주 먹는 음식이 알레르기가 생길 수 있어 당장은 괜찮아도 언제든지 다른 음식에 알레르기가 생길 수 있다는 거예요!

저는 새우 알레르기가 심했지만 이제는 다 사라졌고, 뽀글이는 당근 알레르기가 심했지만 지금은 전혀 다른 음식에 알레르기가 생겼습니다.

그래서 피부문제로 병원에 방문 시, 항상 아래와같은 질문들을 받았어요.

오늘은 뭘 먹였나요? 어제는? 이번 주는 무엇을 가장 많이 먹였죠? 이번 달에는 어떤 음식을 가장 많이 먹였죠? 뭐를 먹였을때 어떤 증상이 심해졌죠? 이전에 알레르기가 있던 음식들은 요즘 괜찮나요? (영양을 위해 소량 급여하는 경우가 있어요!)

이런 식으로 저에게 질문이 올때마다 헷갈리더라고요..!

딱 정해진 게 아니라 계속 바뀌는 거니까요! 그래서 이 모든 걸 최대한 편하게 기록하고 관리할 수 있는 프로젝트를 만들고자 결심했습니다!

프로젝트의 1차 목표!!

이 프로젝트는 우리 반려견뿐만 아니라, 다른 반려견 주인들에게도 도움이 될 수 있도록 만들고자 해요.
디자이너님과 협업하여 간편하고 효과적인 방법으로 반려견의 음식 섭취를 기록하고 관리할 수 있는 UI / UX를 제공합니다.
이를 통해 음식 알레르기의 원인을 파악하고, 반려견의 건강을 지속적으로 관리할 수 있어요.

개발 블로그인만큼 저의 코드와 경험을 공유할 예정이에요! 

프로젝트 자체의 취지도 잊지 않고 다른 반려견 주인들과 소통하며, 함께 건강한 반려견 생활을 지향할 생각입니다! 

그러니 이 프로젝트에 많은 관심과 참여를 부탁드립니다!

애정이 담긴 코드로 꾸준히 프로젝트를 발전시켜, 함께 반려견들의 건강을 지키고 행복한 시간을 보내는 것이 목표입니다.

함께해요! 🐾

멘토링을 시작하게 된 계기

회사에 입사 후 사수 없는 환경에서 혼자 개발에 임하며 큰 문제가 있진 않았습니다.
하지만 문제가 생기지 않았던 건 제가 잘해서가 아니라 개발 환경이 심플해서 그랬던 거라 생각됐고,

조금 더 다양한 스택이나 환경에서 여러 사람들의 피드백을 받고 싶었습니다. 

그렇게 재직 중 F-Lab 멘토링을 신청하게 되었어요!

멘토링을 진행하기 전과 비교했을 때 나는 어떻게 변했는가?

어떤 회사를 지원하고 싶은가?

자유롭게 의견을 주고받을 수 있는 회사면 좋을 것 같아요! 멘토님께 당근 마켓에서 겪으신 여러 경험을 들으며 커뮤니케이션이 성장에 정말 중요하다는 생각이 들었습니다!

프로젝트 퀄리티에 대한 만족도는 어땠는가? 어떤 것이 좋았었는가? 새로운 것들은 무엇을 경험했는가?

멘토링전 경험해온 개발과 비교했을 때, 프로젝트의 퀄리티는 꽤 만족스럽습니다!
디자인 시안이 변경될 수 있는 점이나 개발자 경험을 고려하여 Headless UI를 적용한다던가, 사용자들이 사이트의 마지막 경험을 더 중요하게 생각한다는 것을 알게 돼 다양한 오류 페이지를 처리하는 방법을 생각해 봤어요. 이렇게 생각해 본 적이 없는 많은 것들에 대해 고민해 보았다는 것 자체가 정말 만족스러웠습니다!

멘토링의 장점과 단점

주로 혼자서 개발에 참여하다보니 소통과 협업에 대한 갈증이 있었습니다.
이를 해소할 수 있었던 게 가장 큰 장점이었어요!
멘토링을 잘못 이용한다면 더 숙력된 멘토님에게 과도하게 의존하게 될 수도 있겠지만, 적절한 순간에 커트를 해주셔서 오히려 가져본 적 없는 사수에게 지켜야 할 선 같은 걸 분별하는 법을 배웠습니다!
이러한 경험들은 사소하게 면접에서조차도 저의 경험이나 배경지식의 전달을 위해 커뮤니케이션 스킬이 정말 중요하단 걸 다시 한번 느끼게 해주었습니다.
빠르게 개발하는 것만을 고민하던 지금까지의 습관들 탓에 멘토님의 코드 리뷰에 대한 피드백 고민 시간이 길어졌고 그렇기에 프로젝트 진행도에 대한 만족도는 좋지 않습니다. 그래서 멘토링은 끝났지만, 새로운 프로젝트를 진행한다고 해도 뽀글이(우리 강아지..!)를 위해 만들기 시작한 이 프로젝트만큼은 끝까지 완성시키고 싶어졌어요!

멘토링에 대한 자유로운 후기

개발에 대한 관점에 많은 변화를 겪었습니다.
이전에는 개발에 있어 기술과 배경지식이 가장 중요하다고 믿었습니다.
하지만 이제는 '기술은 기술일 뿐, 필요에 따라 배우고 적용하면 된다. 모든 것을 선제적으로 마스터하려고 하면 중요한 부분을 간과할 수도 있다'는 것을 깨달았습니다. 이전에도 생각은 했던 문장이지만 이를 실천하는 건 상당히 어려운 일이었어요.

멘토링을 겪으며 많은 문제상황과 타임 어택.. 을 겪었고 이때 진정으로 도움이 됐던 건 얕은 지식들이 아닌 깊게 고민하고 파고들었던 습관들이었습니다. 이런 경험들을 겪으며 서서히 공부습관들과 관점이 바뀌게 되었습니다!
이런 경험들을 하게 해주신 멘토님께 정말 감사합니다!

현재까지 무엇을 배웠는가

TypeScript, React.js, AWS, Bundler, CI/CD, TDD 등을 학습했습니다.

유틸리티 타입을 구현한다던가..

"Suspense 기능을 스테이블로 출시했는데 이런 건 왜 만들었을까?" 또는 "서버 컴포넌트는 왜 만들었을까?",

"JSX는 왜 만들었을까?",

"선언적 프로그래밍이란 무엇일까?",

"왜 setState를 비동기로 동작하게 만들었을까?",

"왜 훅이라는 개념은 생겼지?",

"key는 왜 넣어주게 했을까?" 처럼 사용법 뿐만이 아니라 리액트 팀의 철학 측면으로도 고민을 해볼 수 있는 시간이었습니다.

프로젝트 진행은 어떻게 되고 있는가

친한 디자이너님과 협업을 하게 됐습니다!
현재 회사를 다니는 분이고, F-Lab 멘토링을 하고 계신 분은 아니셔서 프로젝트 기한을 정하기가 힘들었어요!

기획이 없던 적은 있어도 완성된 디자인 없이 개발을 진행해 보는 게 처음이라 많은 고민을 했습니다!

고민의 결과 기본적인 프로젝트 세팅(CRA 없이), 배포 프로세스 구축, 반드시 들어가게 될 검색 컴포넌트의 기능 등 디자인과 상관없이 진행할 수 있는 것들부터 진행하게 됐어요!

이전에 경험했던 프로젝트와 무엇들이 다른가?

위에 적은 것처럼 디자인 시안 없이 프로젝트를 진행해 본 건 처음이었어요!

사소한 차이라고 생각했지만 이것만으로도 프로젝트 구조를 잡기 정말 힘들었습니다.
디자인에 따라 페이지가 바뀔 수도 있는 상황이라 판단했었어요..!

그래서 최대한 유연한 변경을 위해 그리고 디자이너님과의 소통을 위해 Headless UI,
Compound Component, Storybook 등 처음 접하는 여러 개념을 학습하고 적용해 보게 됐었네요!

내가 잘못 알고있었던 것을 바로 잡은 것이 있는가

잘못 알고 있던 개념이라기보다는, 컴포넌트를 만드는 방식이 복잡해지는 것이 수익 모델 검증 단계에서는 좋지 않다는 선입견을 깨는 계기가 됐습니다.

초기 비용이 크지만, 추후 유지 보수 기간을 단축시켜주는 TDD와 유사하게, 헤드리스 컴포넌트와 합성 컴포넌트를 통해 컴포넌트가 특정 UI를 규정하지 않고, 로직과 상태 관리만을 전적으로 책임지게 만들려 노력하는 과정에서 이러한 방식은 확장성이 뛰어나고 이를 통해 시각적 표현을 추후 구현하는 개발자에게 맡길 수 있다는 게(여기선 미래의 저겠죠?!) 빠른 개발을 하기에 정말 든든하단 걸 느꼈어요.

멘토님의 실력에 대한 만족도는 어떠한가

최고입니다! 정말 만족스러워요!
위에는 덤덤하게 적었지만 작업순서에 대해 많은 고민이 있었습니다.
그때마다 방향성을 잃지 않도록 잡아주셨어요.

적절한 타이밍에 적절한 코드 리뷰 또한 회사를 다니며 멘토링을 받는 제가 지치지 않고 달릴 수 있었던 원동력이었습니다!

최근 1개월 동안 멘토링에서 어떤 것들이 좋았는가

새로운 상황, 새로운 관점에서 작업을 진행하는 게 굉장히 재밌었어요!

멘토님께서 종종 들려주시는 경험 이야기나 교양 같은 이야기들 또한 멘탈을 환기시켜 집중력을 높이는데 정말 큰 도움이 됐습니다!