Vue.js 2 버전과 Quasar 1 버전 기반의 기존 제품 코드를 참고하며 React 마이그레이션을 해야 했다. Node.js LTS 버전이 18이던 그때 당시의 제품 스펙은 Node.js v14와 Vue.js v2 + Quasar Framework v1으로 상당히 오랜 기간 라이브러리/패키지 버전을 신경쓰지 않은 상태였고, Node.js 버전에 호환되지 않던 기존 제품 덕분에 한동안은 nvm으로 버전을 변경해가며 작업하느라 상당히 번거로운 기간이 있었다.

작업하며 이따금 살펴봤던 Quasar v1도 상당히 좋은 프레임워크인 것 같은데, TypeScript를 잘 지원한다는 Vue 3 버전과 Quasar v2으로 업그레이드하고 리팩토링을 잘 해주었다면 굳이 큰 비용을 들여가며 React로의 마이그레이션이 필요했을까? 라는 생각도 했었다. 덕분에 React에 익숙해졌어요

개선 내용​

• 포맷팅이 적용되지 않은 코드

  • Prettier 적용

• 가독성이 중요한 제품에 적절치 못했던 웹 폰트 (ELAND_Choice_M.ttf)

  • Pretendard Variable 👍

• 타입스크립트로 작성했으나 타입스크립트의 장점을 살리지 않은 코드

  • types 디렉토리 추가해서 페이지/기능 단위로 타입 작성하고 네이밍 수정

• 천 줄에 육박하거나 넘어가는 코드들

  • 적절한 단위나 기능으로 컴포넌트화

• 엄청나게 많았던 중복 코드 제거

  • 다른 라이브러리에서 동일한 기능을 제공하면 제거 (useInterval hook, classnames 등)

• 네이밍 수정이나 코드 축소 등으로 가독성 개선

  • onHide, handleHide → handle로 통일
  • handleClickDownload, onDownloadClick 등의 이벤트 핸들러의 네이밍 규칙 → handleClickDownload
  • open (뭘 오픈하고 싶은게냐) → visibleDialog

• inline 스타일을 최대한 제거

  • Tailwind CSS & SCSS로 많이 변경

• create-react-app & Webpack

  • Vite ⭐

• 혼용되던 패키지 매니저 (코드에 npm, yarn 둘 다 있었음…)

  • npm 걷어내고 yarn berry(v4) 도입

  • pnpm 방식의 nodeLinker 설정

    • package.json

      {
        ...
        "packageManager": "yarn@4.3.1"
      }
      

    • .yarnrc.yml

      compressionLevel: mixed
      
      enableGlobalCache: false
      
      nodeLinker: pnpm
      
      packageExtensions:
        '@semantic-release/changelog@*':
          dependencies:
            semantic-release: ^23.0.0
        '@semantic-release/commit-analyzer@*':
          dependencies:
            semantic-release: ^23.0.0
        '@semantic-release/git@*':
          dependencies:
            semantic-release: ^23.0.0
        '@semantic-release/npm@*':
          dependencies:
            semantic-release: ^23.0.0
        '@semantic-release/release-notes-generator@*':
          dependencies:
            semantic-release: ^23.0.0
        '@testing-library/user-event@*':
          dependencies:
            '@testing-library/dom': ^9.3.4
        file-loader@*:
          dependencies:
            webpack: ^5.90.0
        react-loading@*:
          dependencies:
            prop-types: ^15.8.1
        url-loader@*:
          dependencies:
            webpack: ^5.90.0
      
      supportedArchitectures:
        os:
          - linux
          - win32
      
      yarnPath: .yarn/releases/yarn-4.3.1.cjs
      

• PrimeReact UI 라이브러리와 함께 사용하던 PrimeFlex라는 이상한 Tailwind like 라이브러리

  • Tailwind랑 비슷하면서 달라! 네이밍도 미묘하게 다르고, 무엇보다 기능이 많이 모자라! ㅠㅠ
  • 진짜 real Tailwind CSS로 교체 (클래스명 다 변경하며 일일이 확인하느라 고생)

• semantic-release 라이브러리 추가 및 semver 적용

• Git 브랜치 규칙 도입

  • develop 브랜치에서 feature 생성, alpha에서 테스트하고 버전 업 하면 main에 merge

• 자유분방하던 Git commit 규칙 정립 & husky 도입 타입스크립트 에러가 있으면 commit 할 수 없도록 규칙을 넣어주었다.

  • package.json

    {
      ...
      "scripts": {
        "preinstall": "npx only-allow yarn",
        "postinstall": "husky",
        "checkTs": "tsc",
        ...
      }
    }
    
  • .husky/pre-commit

    yarn checkTs
    
  • before 정리되지 않은 메시지들과 너무나 많은 no message
  • after 정리가 되면서 마음도 편-안해졌다.

수많은 노력의 결과, 개발 서버는 빠릿해졌고, 빌드 시간이 획기적으로(?) 줄었다.

그 외에도 몇 가지 더 붙이자면,

• React-Hook-Form
  • 스키마 검증 라이브러리로 Zod resolver 추가
• 애니메이션 라이브러리
  • Framer Motion 추가
• 404 페이지
  • Lottie를 활용해서 제작

최적화​

우리 회사의 제품은 CI/CD로 배포해서 상시 서비스하는 제품은 아니고 장비에 프로그램을 포함해서 제공하는 솔루션 제품이다. 이러한 제품의 특이성이 있어 사실 브라우저의 렌더링 최적화가 덜 중요하다고 생각하고 넘어갈 수도 있겠지만, 그럼에도 브라우저에 좋다는 건(?) 최대한 적용해보고 싶었다.

• lodash → lodash-es
  • 참고 글
• 코드 스플리팅
  • 라우팅 로직에서 React.lazy, Suspense
  • vite.config.ts 에서 build 설정 rollup-plugin-visualizer에서 뽑아주는 report를 참고해서 chunk를 적절하게 나눠주었다. (manualChunks 설정 부분을 더 간결하게 작성하는 법을 배우고 싶다)

배포​

하지만 아직 제대로 해결하지 못한 문제는 배포의 자동화이다. 현재는 빌드 결과물인 dist 디렉토리 내용물을 고객의 서버 또는 포터블 장비의 리눅스 OS 서버 내부에 직접 파일을 넣어주어야 한다. 그리고 노션의 프론트엔드 배포 페이지에 함께 업로드하며 관리하고 있다.

파일 업로드는 SFTP로​

1. 접속

   sftp [원격 계정명]@[원격 IP 주소]
   # sftp im_user@192.168.1.221
   

   포트를 넣고 싶다면 -P 플래그 뒤에 포트 번호를 입력해야 한다.

   ssh랑 달리 -P를 대문자로 입력해야 해서, 처음엔 소문자로 입력하곤 왜 안 되지? 하며 혼란스러워 했었다.

   sftp -P [포트 번호] [원격 계정명]@[원격 IP 주소]
   # sftp -P 12345 im_user@my.url.co.kr
   

2. 접속 후 파일 업로드

   put [업로드할 파일] [업로드할 위치 또는 생략(현재 위치)]
   # put sample.json
   

   디렉토리를 업로드 시, -r 플래그 추가

   put -r [업로드할 디렉토리] [업로드할 위치]
   # put -r dist static
   

SSH 접속해서 root 디렉토리로 옮겨주기​

1. 접속

   ssh [원격 계정명]@[원격 IP 주소]
   # sftp im_user@192.168.1.221
   

   포트 바꿔서 접속하려면 -p 뒤에 포트 번호를 입력한다.

   sftp와 달리 -p 플래그는 소문자로 입력해야 한다.

   ssh -p [포트 번호] [원격 계정명]@[원격 IP 주소]
   # ssh -p 12345 im_user@my.url.co.kr
   

2. 기존 디렉토리 제거 및 업로드된 디렉토리 옮겨주기

   sudo rm -rf [제거할 디렉토리] && sudo mv [업로드한 static 디렉토리] [옮길 경로]
   

3. 브라우저 강력! 새로고침

이렇게 수동으로 배포하고 있는 과정을 스크립트로 만들어 자동화할 수 있으면 좋을 것 같다.

아직 해결하지 못한 문제들​

PrimeReact 대신 Tailwind CSS를 더 잘 활용할 수 있는 UI 컴포넌트 라이브러리​

PrimeReact를 교체하고 싶다. 내가 선택한 것이 아니기도 하고, 사용해보니 불편한 점이 매우 많더라.

버전 넘버링 중 가장 오른쪽에 위치한 패치 넘버링이 업데이트되기만 해도(v10.6.3 → v10.6.5) 버그가 발생하는 경우가 너무 잦았고, 가운데 마이너 넘버링이 올라간다 하면(v10.6.5 → v10.7.0) 앱 전체 UI 코드를 손 봐야 할 정도로 치명적인 버그가 터진 경험이 많아서 패키지 버전 업데이트를 할 때면 항상 제품 구석구석을 테스트하는 습관을 만들어준 좋은(?) 녀석이기도 하다.

처음 사용할 때와 비교하면 지속적으로 버전이 올라가면서 기능이 추가되고 GitHub stars 숫자도 많이 올라갔고 커뮤니티가 활발하게 돌아가는 건 다행이지만, 상대적으로 커뮤니티가 더 큰 라이브러리들과 비교하면 마이너한 라이브러리인 점(입사하기 전에는 존재를 몰랐다)은 부정할 수 없고, GitHub에 올라온 issue의 수가 너무 많다는 건 그만큼 버그가 많고, 안정성이 떨어진다는 점일 것이다.

제보된 수많은 버그들

개인적으로는 가능하면 Headless 계열의 shadcn/ui이나, shadcn의 베이스인 Radix UI로 교체하고 싶다.

daisyUI나 Mantine도 굉장히 잘 만들어진 라이브러리인 듯 하지만, 내부 규칙이 강해서 우리 회사의 제품을 구현할 때 굉장히 다양한 형태의 UI를 구현하기엔 자유로운 커스터마이징이 가능한 headless가 더 적합하다는 생각이 든다.

이런 저런 요런 이유들로 다른 라이브러리로 갈아타는 것이 좋겠다는 심정이지만, 제품에서 PrimeReact 내부의 몇몇 컴포넌트에 의존성이 강해 쉽게 교체할 수 없는 상황이다. (DataTable, Draggable dialog 등)

여담으로 올해 3월에 개편된 Node.js 웹사이트의 재설계 사례를 보면 덩치가 엄청나게 커진 앱을 개선하는 것이 얼마나 어려운 점인지 잘 보여주는 것 같다.

차트 라이브러리​

제품의 주요 라이브러리 중 하나로 Apache ECharts를 사용하고 있다. React용 랩핑 라이브러리로 echarts-for-react도 함께 사용하고 있다.

근데 좀 불편하다. ECharts는 자유도 높은 커스터마이징에 비하면 공식 문서가 친절하게 작성된 편이 아니고, echarts-for-react는 타입스크립트로 작성되었음에도 불구하고 타입이 잘 지원되지 않아서 타입 정의 파일을 열어보면 any 타입으로 돼있는 게 너무 많았다. 애니 스크립트

가장 코어한 EChartsOption & EChartsInstance의 타입이 any라니…? 🤔

성능 이슈 때문에 ECharts로 도입을 결정했다고 하는데, 아쉽다. 준수한 성능에 React + TypeScript에 더 적합한 라이브러리가 분명 있을 텐데.

테스트 코드 도입​

Jest를 추가하고 sample 코드를 만드는 것까지 완료해두었지만, 아직 실제 테스트를 작성하지 못한 점이 너무 아쉽다. 테스트 코드를 안 넣는 회사가 있다?

테스트 코드가 익숙하지 않은 점, 그리고 프론트엔드 개발자가 부족하다는 것이 이유(핑계).

일관적인 디자인​

현재 회사는 UX/UI 디자이너가 없고, 두 명 뿐인 프론트엔드 개발자 각개전투로 UI를 만들고 있다.

코드 스타일은 Prettier + Tailwind CSS 플러그인으로 어느 정도 강제할 수 있지만 디자인에서는 많이 사용한다는 Storybook이나 Figma를 다룰 수 있는 인력이 없기 때문에 참 어려운 점이라고 생각한다.

마무리​

프론트엔드라는 분야에 한정짓지 않아도 개발자라면 알아야 할, 또는 배우면 좋은 것들이 너무나도 많다는 걸 새삼 느낀다. 배워서 써먹는 건 항상 즐겁다.

또한 글쓰기의 어려움을 오랜만에 포스팅을 작성하며 느꼈다. 일목요연하게 물 흐르듯 글을 쓰는 게 얼마나 어려운지, 글쓰기도 많이 해봐야겠다.

끝.

Vue.js 2 버전을 사용하고 있는 프로젝트에서 iframe으로 기능을 구현하려고 (iframe은 너무 극혐이지만 회사 프로젝트라서 어쩔 수 없다. 까라면 까야...) vue-friendly-iframe 라이브러리와 NginX 리버스 프록시까지 적용하며 하나씩 퀘스트를 헤쳐 나가던 중이었다.

Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Headers 등등 온갖 액세스를 허용하기에 이르렀으니.

가능한 모든 편법을 동원해 드디어 화면에 렌더링되는 iframe의 내용물. 😭

하지만 기쁨도 잠시, 다시 API의 Post 요청 후 받아든 에러들의 문턱을 넘지 못했다.

아무런 의심없이 내장 Fetch API를 사용하고 있었는데 Response로 내려주는 내용에서

{
  type: 'cors',
  headers: {},
  ...
}

분명 필요한 헤더를 Access-Control-Expose-Headers에 추가해줬음에도 headers의 내용이 비어있다??

며칠을 끙끙대다가, 혹시나 해서 fetch 요청 코드를 Axios로 교체해봤더니 원했던 headers의 응답 내용은 물론이며 fetch로 요청했을 땐 볼 수 없었던 추가적인 응답 내용들이 함께 보였다.

먼저 작성했던 fetch 코드​

async createTicket() {
  try {
    const { status, headers } = await fetch({
      method: 'POST',
      url: `${this.iframeUrl}/######/##/########`,
      headers: {
        'Content-Type': 'application/json',
      },
      body: JSON.stringify(this.userData),
    });

    if (status === 201) {
      const { ticket } = headers;
      if (ticket) {
        return ticket;
      }
    }
  } catch (error) {
    console.warn(error);
  }
},

Axios 코드​

axios.js

// Vue instance property에 정의
import axios from 'axios';

export default ({ Vue }) => {
  Vue.prototype.$axios = axios;
};

async createTicket() {
  try {
    const { status, headers } = await this.$axios({
      method: 'post',
      url: `${this.iframeUrl}/######/##/########`,
      headers: {
        'Content-Type': 'application/json',
      },
      data: this.userData,
    });

    if (status === 201) {
      const { ticket } = headers;
      if (ticket) {
        return ticket;
      }
    }
  } catch (error) {
    console.warn(error);
  }
},

여기서,

const { status, headers } = await this.$axios({
  method: 'post',
  headers: {
    'Content-Type': 'application/json',
  },
  url: `${this.iframeUrl}/######/##/########`,
  data: this.userData,
});

이 부분을 이렇게 작성할 수도 있다.

const { status, headers } = await this.$axios.post(`${this.iframeUrl}/######/##/########`, this.userData);

Fetch와 Axios는 비슷하지만 다르다​

Fetch와 Axios는 문법에서도 비슷하지만 다른 부분이 꽤 있음을 알 수 있다.

Fetch에서 body에 해당하는 부분은 Axios에서는 data로 전달하며, fetch와 달리 JSON stringify가 필요없고 자동으로 문자열로 변환해준다. 또한, Fetch에는 없는 요청 메소드를 Axios에서 제공한다.

참고로, 원래 HTTP request method는 대소문자를 구별하기 때문에 대문자로 작성하는 것이 정확하다고 한다.

GET, POST, PUT, DELETE, ...

HTTP Method Name is Case Sensitive - Developer Note

RFC 7231

Axios는 편리하게 타입스크립트로 대/소문자 모두 작성 가능하도록 정의해두었다.

node_modules
└─ axios
    └─ index.d.ts

export type Method =
  | 'get' | 'GET'
  | 'delete' | 'DELETE'
  | 'head' | 'HEAD'
  | 'options' | 'OPTIONS'
  | 'post' | 'POST'
  | 'put' | 'PUT'
  | 'patch' | 'PATCH'
  | 'purge' | 'PURGE'
  | 'link' | 'LINK'
  | 'unlink' | 'UNLINK'

결론​

Axios에 관한 내용을 구글링해보면 거의 사용 편의성이나 약간의 기능 차이 정도만 설명하고 있어서 평소에는 fetch로도 대부분의 API 요청을 처리하는데 문제가 없기 때문에 당연하게 fetch만 사용하고 있었다.

CORS라는 특수한 환경에서 이렇게 막강한 능력을 발휘할 줄은 몰랐다. 이래서 써드파티 라이브러리를 사용하는구나 싶었다. 같은 역할을 하지만 다양한 도구들이 끊임없이 개발되는 이유 중의 하나가 아닐까 싶다. 코드를 작성할 때 한 가지 방법만 고수하지 않고 여러 가지 도구들을 비교하면 좋을 것 같다. (막상 바쁘면 필요할 때 하겠지 😂)

그 외 Fetch와 Axios의 기능 비교에 관한 글은 아래를 참고하면 좋을 것 같다.

[번역] 입문자를 위한 Axios vs Fetch

프로젝트를 하다가 새로 알게 된 지식을 정리하려고 한다.

배열 길이 변경​

length 속성에 값을 설정하게 되면, 배열의 길이를 변경할 수 있다.

const menu = ['pizza', 'chicken', 'jokbal', 'budaejjigae', 'samgyeopsal', 'gganpunggi'];
console.log(`메뉴 개수 : ${menu.length}개`); // 메뉴 개수 : 6개

menu.length = 0;
console.log(`메뉴 개수 : ${menu.length}개`); // 메뉴 개수 : 0개

배열 단축​

예를 들어 데이터를 5개만 보여주고 싶을 경우, 이것을 활용할 수 있다.

const data = [10, 20, 30, 40, 50, 60, 70, 80, 90, 100, 110, 120, 130, 140, 150];
if (data.length > 5) {
  data.length = 5;
}

console.log(data); // [10, 20, 30, 40, 50]
console.log(data.length); // 5

프로젝트를 진행하다가 일관성을 위해 styles.css라는 파일명을 Styles.css로 변경해 주었다.

그런데, Git이 파일명 변경 사항을 tracking하지 못하는 현상을 발견했다.

원인​

Git의 기본 설정에서 대소문자 구분을 무시(ignorecase = true)하는 것이 기본값이라고 한다.

해결​

ignorecase 설정을 false로 수정한다.

git config --global core.ignorecase false

저장소에 반영하기 위해서 cache를 제거한다.

git rm -r --cached [적용할 파일이나 폴더]
git add [적용할 파일이나 폴더]
git commit -m "update: Git 대소문자 구분 설정"
git push

문제 설명​

머쓱이는 프로그래머스에 로그인하려고 합니다. 머쓱이가 입력한 아이디와 패스워드가 담긴 배열 id_pw와 회원들의 정보가 담긴 2차원 배열 db가 주어질 때, 다음과 같이 로그인 성공, 실패에 따른 메시지를 return하도록 solution 함수를 완성해주세요.

• 아이디와 비밀번호가 모두 일치하는 회원정보가 있으면 “login”을 return합니다.
• 로그인이 실패했을 때 아이디가 일치하는 회원이 없다면 “fail”를, 아이디는 일치하지만 비밀번호가 일치하는 회원이 없다면 “wrong pw”를 return 합니다.

입출력 예​

풀이​

function solution(id_pw, db) {
  const [id, pw] = id_pw;

  if (!db.find(([_id]) => _id === id)) return 'fail';
  return db.find(([_id, _pw]) => _id === id && _pw === pw) ? 'login' : 'wrong pw';
}

문제 설명​

문자열 my_string이 매개변수로 주어질 때, 대문자는 소문자로 소문자는 대문자로 변환한 문자열을 return하도록 solution 함수를 완성해주세요.

입출력 예​

풀이​

function solution(my_string) {
  let answer = '';

  for (let x of my_string) {
    if (x === x.toUpperCase()) {
      answer += x.toLowerCase();
    } else {
      answer += x.toUpperCase();
    }
  }
  return answer;
}

이주한 이유​

Gatsby를 사용하면서 크게 불편한 점은 없었다.

하지만 몇 가지 이유를 나열해보자면

• 최근에 TypeScript를 많이 사용하면서 Gatsby Blog에도 TypeScript를 적용해보고 싶었지만, Gatsby 패키지 버전과 다른 라이브러리들의 종속성 때문에 업그레이드가 쉽지 않았다.

• Gatsby가 4 버전까지 출시되었고, 어느새 5 버전 릴리즈를 앞두고 있다는 점을 감안하면 사용 중인 블로그 템플릿의 버전이 많이 낮다. (Gatsby v2)

• 이왕 변경하기로 마음먹은 김에 새로운 도구를 사용해보고 싶었다. yarn berry도 학습할 겸, 겸사겸사.

Docusaurus를 선택한 이유​

React Native를 학습하면서 공식 문서를 봤는데 깔끔한 UI와 굉장히 빠른 동작이 인상적이었고, Docusaurus를 사용하고 있다는 것을 알게 되었다.

이미 다양한 사이트들과 특히 오픈 소스 공식 문서의 용도로 많이 사용되고 있다.

또한 React를 만든 곳이기도 한 facebook의 오픈 소스 프로젝트라는 점에서 React와의 호환성과 꾸준한 유지보수 를 기대해볼 만하다.

앞으로의 계획​

블로그를 이주하면서 과거에 작성한 포스팅을 쭉 살펴보니, 개발을 주제로 한 글을 많이 작성하지 않은 것을 반성하게 되었다.

여태까지 회사 일을 해오면서 배운 점들이 적지 않은데 제때 글로 옮겨두지 않은 것이 아쉽다.

글을 조금 더 자주 쓰도록 노력해야겠다.

과거에 티스토리에 작성했던 글도 조금씩 옮겨볼 생각이다.

때로는 이미 원격 저장소에 업로드한 파일을 나중에 무시하고 싶은 경우가 있다.

이 경우에는 .gitignore를 수정해서 git push해도 원격 저장소에 업로드된 파일은 사라지지 않는다.

원격 저장소에서 .gitignore 적용하기​

git rm -r --cached .
git add .
git commit -m "[.gitignore 적용]"
git push

forEach와 다른 점​

• iterable(반복가능한) 객체(Array, String, Map, Set, NodeList 등)에서 사용할 수 있다.

  forEach는 Array 에서만 쓸 수 있다.

• const 대신 let도 사용할 수 있다.

• Loop를 멈출 수 있다.

const foods = ['Pizza', 'Chicken', 'Burger', 'Pasta', 'Bibimbap', 'Sandwich', 'Barbecue'];

for (const food of foods) {
  if (food === 'Bibimbap') {
    break;
  } else {
    console.log(food);
  }
}

// Pizza
// Chicken
// Burger
// Pasta

더 복잡하고 자세한 설명이 필요하다면 해당 페이지를 참고하자.

참고 링크​

• MDN: for ... of
• MDN: forEach

React Native를 개발하다보면 Text가 종종 제대로 줄 바꿈 이 되지 않고 화면 밖으로 넘칠 때가 있다.

나 또한 그랬다.

현상​

프로젝트는 이런 구조이며, Column이 Title을 감싸고 있는 부모 요소이다.

const Column = styled.View`
  flex-direction: row;
  width: 80%;
`;

const Title = styled.Text`
  // ...생략
`;

export default function Detail() {
  return (
    <Container>
      <Header>
        <Background />
        <Column>
          <Poster />
          <Title>{title}</Title>
        </Column>
      </Header>
      <Overview>{overview}</Overview>
    </Container>
  );
}

고민​

처음에는 'width를 70% 로 줄이면 어떻게 될까?'라고 생각해서 수정해봤다.

const Column = styled.View`
  width: 70%; // 80%에서 줄이기
`;

폭이 줄어들면서 해결은 되지만, 다른 형제 요소와 맞물렸을 때 70%이라는 기준이 명확하지 않은 숫자가 마음에 들지 않았다.

해결 방법​

구글링을 하다가 좋은 글을 발견했다.

부모 요소가 아니라 해당 요소에 flex: 1 속성을 주는 것이다.

flex: 1은

flex-grow: 1;
flex-shrink: 1;
flex-basis: 0%;

즉, flex: 1 1 0;과 같다.

해당 현상의 경우 flex-shrink만 영향을 주기 때문에 정확히 flex-shrink: 1만 주어도 충분하다.

그리고 부모 요소인 Column의 width 를 제거해주면 원하는 모습으로 해결된다.

Gatsby로 블로그를 만들고 포스팅하고 있다.

앞서 작성한 포스팅을 commit 후 push하고 한참을 기다려도 브라우저에 나타나지 않았다.

Netlify에 가서 error log를 확인해보니 예상대로 어떤 문제 때문에 빌드가 진행되지 않고 있었다.

...???

원인​

title에 쓴 대괄호([ ], Square brackets) 가 문제를 일으키고 있었다!

---
title: [React Native] Text가 넘칠 때 해결 방법
date: 2022-10-05 19:10:47
category: development
draft: false
---

해결 방법​

간단하다. quote 로 묶어주면 된다. single이든 double이든 상관없다.

backtick 을 써도 된다.

---
title: '[React Native] Text가 넘칠 때 해결 방법'
date: 2022-10-05 19:10:47
category: development
draft: false
---

해결 완료!

최근 급하게 이직을 준비하고 있다. 분당 사무실에서 근무하고 있는데 9월부터 본사인 이천(!!)으로 출근하게 된다는 날벼락같은 소식이 들려왔기 때문이다.

개발자로서 발전하고 싶어서 포항에서 건너왔는데 이천으로 출근하라니? 게다가 개발 회사도 아니기 때문에 너무나도 당연하게 이직을 해야 한다고 생각한다.

요즘 여러 차례 지원을 해보고 부족한 점이 너무 많다는 것에 생각이 많아졌다. 기업들이 어떤 기준으로 서류 전형을 불합격시키는지 확신할 수는 없지만, 운이 좋게 면접을 본 케이스에서 느낀 바로는 적어도 내가 부족한 게 무엇인지 많이 배울 수 있었다.

협업 경험도 부족하지만, 더 중요한 건 본질적으로 프론트엔드 개발자로서 기본 소양이 많이 부족하다는 것이다. 구현이야 강의를 따라하며 얕은 지식으로도 어떻게든 흉내는 낼 수 있고, GitHub 잔디를 채우는 것까지도 가능하다. 이게 통하지 않는 순간은 바로 기술의 기본 내용에 대한 질문을 받았을 때이다. 면접관이 기술 관련 질문을 했을 때, 심지어 내가 직접 타이핑한 코드임에도 불구하고 제대로 대답할 수 없는 현실에 좌절감을 맛보았다.

개발자로서 가장 중요한 것​

기본기가 정말 중요한데 난 그게 부족했다. 그것도 매우 많이. 프로그래머로서의 소양이 부족하다고 해도 틀리지 않은 것 같다.

개발 블로그나 유튜브를 보며 생각을 정리해보았다.

두 번의 면접 탈락, 그리고 현재까지 10건 이상의 서류 탈락을 통해 나의 부족한 점을 비로소 뼛속 깊이 깨닫게 되었으니 이제는 채워넣어야겠다.

앞으로의 계획​

1. 자바스크립트를 깊이 판다.
2. 이미 진행한 사이드 프로젝트 코드를 발전시킨다.
3. 클론 코딩은 그만하고 새로운 아이디어로 나만의 프로젝트를 진행한다.
4. GitHub을 잘 채운다.
   • README를 성실하게 작성한다.
5. 코딩 테스트도 조금씩 풀어본다.
6. 좌절감에 빠지지 않게 멘탈 관리, 체력 관리.

데스크탑 크롬 브라우저에서 잘 되는 것을 보고 한창 개발을 진행하던 중, 아이폰으로 테스트하기 위해 접속해봤더니... 아니 글쎄, SVG 아이콘이 뜨지 않는 게 아닌가! 😱

뭐가 문제일까​

@svgr/webpack 설정을 꼼꼼히 씹고 맛보고 아무튼 수많은 삽질을 했다.

• next.config.js의 webpack 설정도 바꿔보고,
• config.module.rules.push를 unshift로도 바꿔보고,
• .svgrrc 파일을 만들어보기도 했지만

여전히 원인은 미궁...

방금 해결했는데, 정말 어처구니가 없었다.

원인​

나의 경우는 디자이너가 그려준 SVG 이미지를 Adobe Illustrator에서 SVG 코드를 통해 추출했다.

그 코드는 이러한 형태였다.

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 183.15 148.15">
  <g id="fa5306e0-2884-4b0a-9d4c-aa2f9b7ff8fe">
    <g id="afa1c823-8b74-436c-bb59-094354fbe2f7">
      <path
        d="M143.47,75.08a1.69,1.69,0,0,0-2.18,2.58c36.63,31,38.55,60.29,38.45,67.12H106.51V130a2.64,2.64,0,0,0,0-.28c-1.8-10.52-6.17-17.61-13-21.09-11.59-5.93-25.83.91-26.43,1.2a1.67,1.67,0,0,0-.28.18c-5.18,4-10.58,5.44-16,4.42C38.17,112,29,97.12,28.93,97a39.81,39.81,0,0,1-2.48-5.21c.16.22.32.44.49.64a3.34,3.34,0,0,0,2.56,1.29,5.91,5.91,0,0,0,2.48-1c2.47-1.39,5-3.42,5.52-6.38a2.19,2.19,0,0,0-.54-2,2.09,2.09,0,0,0-2.05-.55,24.92,24.92,0,0,1-4.21,1.28l-.09,0a3.05,3.05,0,0,1-.52,0c-.35,0-.69,0-1,0l-.26,0-.42-.07a3.9,3.9,0,0,1-.46-.12c-.1,0-.76-.28-.23,0a2.34,2.34,0,0,0-1.62-.22,2.37,2.37,0,0,0-.78.42,4.92,4.92,0,0,1,.36-1.33,3.46,3.46,0,0,1,2.15-2c12.88-2.21,20.28-5.37,22-9.4a4.21,4.21,0,0,0,0-3.57c-6-22.48,17.5-30.77,18.53-31.12a1.69,1.69,0,0,0-1.07-3.2c-.28.1-27.73,9.68-20.66,35.38a.88.88,0,0,0,.19.45,1.17,1.17,0,0,1-.16.86c-.68,1.31-3.93,4.63-19.54,7.29a6.88,6.88,0,0,0-4.51,3.84C20.89,86.05,22,91.56,26,98.72c.4.66,10,16.31,24.11,19,6.39,1.2,12.63-.46,18.57-4.94,1.44-.66,13.77-6,23.29-1.16,5.78,3,9.53,9.18,11.15,18.51v16.36a1.69,1.69,0,0,0,1.69,1.69h76.52a1.7,1.7,0,0,0,1.68-1.49C183.19,145.25,186.61,111.65,143.47,75.08Z" />
      <path
        d="M87.71,75.1a22,22,0,0,0,12.45,13.18,2.13,2.13,0,0,0,2.6-1.47,2.16,2.16,0,0,0-1.48-2.59A17.5,17.5,0,0,1,91.4,72.74c-1.75-6.63.39-13.53,2.19-19.91,1.86-6.63,3.63-13.66,2-20.53-1.41-5.81-5.44-11.15-11.41-12.73a12.81,12.81,0,0,0-9.63,1.09,11.79,11.79,0,0,0-5.63,8,2.16,2.16,0,0,0,1.47,2.59A2.13,2.13,0,0,0,73,29.8a7.78,7.78,0,0,1,4-5.66,8.87,8.87,0,0,1,7-.22c5,1.75,7.59,7.28,8,12.23C93,49.36,83.2,61.84,87.71,75.1Z" />
      <path
        d="M117.17,80.57a2.16,2.16,0,0,0-2.11-2.11,15.45,15.45,0,0,1-12-8c-2.33-4.53-1.62-10.48.29-15.05,1-2.32,2.44-4.36,3.33-6.74a28.17,28.17,0,0,0,1.55-7,33.42,33.42,0,0,0-1.54-13.9,27.74,27.74,0,0,0-3.19-6.71,15.9,15.9,0,0,0-2.35-2.88,23.85,23.85,0,0,0-3-1.89c-2.26-1.52-4.37,2.13-2.13,3.64a18.4,18.4,0,0,1,2.42,1.44,10.76,10.76,0,0,1,1.75,2.26,23.61,23.61,0,0,1,2.58,5.53,29.49,29.49,0,0,1,1.17,13.45,22.25,22.25,0,0,1-2,6.56,43.13,43.13,0,0,0-3.37,7.3C96.92,61.89,96.82,68,99.62,73c3.15,5.69,9.11,9,15.44,9.68A2.12,2.12,0,0,0,117.17,80.57Z" />
      <path
        d="M125.43,76A2.16,2.16,0,0,0,128,74.48a2.13,2.13,0,0,0-1.47-2.59,20.9,20.9,0,0,1-6.1-2.14A15.11,15.11,0,0,1,115.6,66c-1.21-1.63-1.07-4.06-.74-6a52.09,52.09,0,0,1,1.89-6.7,63.93,63.93,0,0,0,1.74-6.8,42.87,42.87,0,0,0,1.11-7.8,37.57,37.57,0,0,0-.69-6.68,47.55,47.55,0,0,0-1.28-5.89,29.39,29.39,0,0,0-7.4-12.66c-1.92-1.92-4.9,1.06-3,3a25.12,25.12,0,0,1,6.32,10.8,37.45,37.45,0,0,1,1.77,12.46c-.33,5-1.83,9.86-3.34,14.58-1.35,4.23-2.77,9.79,0,13.78A18,18,0,0,0,118,73.21,23.9,23.9,0,0,0,125.43,76Z" />
      <path
        d="M139,71.25a2.19,2.19,0,0,0,2.6-1.48,2.12,2.12,0,0,0-1.48-2.59,19.18,19.18,0,0,1-11-5.17c-1.39-1.45-1.46-3.56-1.34-5.46a31.85,31.85,0,0,1,1.33-6.39,45.93,45.93,0,0,0,1.54-7,32.49,32.49,0,0,0,0-7.31,47.23,47.23,0,0,0-3.07-12.95A40.76,40.76,0,0,0,120,11c-1.81-2-4.79,1-3,3A38.62,38.62,0,0,1,126.45,37a27.35,27.35,0,0,1-.3,7.45c-.44,2.22-1.13,4.38-1.69,6.58-1.13,4.41-1.92,9.83,1.29,13.57a19,19,0,0,0,6,4.36A24.36,24.36,0,0,0,139,71.25Z" />
      <path
        d="M59.25,65.4h-.33l-.28-.07-.46-.15a13.38,13.38,0,0,1-2.28-1.42,2.13,2.13,0,0,0-2.89.75,2.18,2.18,0,0,0,.76,2.89c2,1.45,4.5,2.82,7,2a8.91,8.91,0,0,0,3.1-2c.88-.82,1.74-1.65,2.61-2.48a2.11,2.11,0,1,0-3-3l-2.25,2.14a5.94,5.94,0,0,1-1,.88c.46-.27-.15.1-.24.15l-.27.18a1.49,1.49,0,0,1-.58.16C59.47,65.39,59.49,65.38,59.25,65.4Z" />
      <path
        d="M30.17,51.39A1.66,1.66,0,0,0,31.29,51a1.69,1.69,0,0,0,.14-2.38l-7-7.87.25-.19,2.29-2,7,7.87a1.7,1.7,0,0,0,2.38.14,1.68,1.68,0,0,0,.14-2.38l-7-7.87,2.63-2.34,7,7.87a1.68,1.68,0,0,0,1.26.56,1.68,1.68,0,0,0,1.26-2.8l-7-7.87,2.63-2.34,7,7.87a1.68,1.68,0,0,0,1.26.56A1.68,1.68,0,0,0,46.77,35l-7-7.87,2.63-2.34,7,7.87a1.69,1.69,0,0,0,2.52-2.24l-7-7.87,2.64-2.34,7,7.87a1.7,1.7,0,0,0,2.38.14,1.68,1.68,0,0,0,.14-2.38l-7-7.87,2.83-2.52,7,7.87a1.68,1.68,0,0,0,1.26.56A1.68,1.68,0,0,0,62.43,21L55.26,13a8.33,8.33,0,0,0-.67-10.18,8.33,8.33,0,0,0-11.74-.69l-29.24,26a8.38,8.38,0,0,0-2.59,8L1.37,44.64A4.09,4.09,0,0,0,1,50.4a4,4,0,0,0,3.05,1.37,4.08,4.08,0,0,0,2.71-1l9.65-8.58a8.51,8.51,0,0,0,4.92.13,1.24,1.24,0,0,0,.17.23l7.38,8.3A1.65,1.65,0,0,0,30.17,51.39ZM16.88,38.69a1.7,1.7,0,0,0-1.89.24L4.55,48.22a.72.72,0,0,1-1-.06.7.7,0,0,1,.06-1h0l10.44-9.28A1.68,1.68,0,0,0,14.51,36a5,5,0,0,1,1.34-5.43l29.24-26a4.93,4.93,0,0,1,3.27-1.24h.31a4.94,4.94,0,0,1,3,8.63L22.43,38A5,5,0,0,1,16.88,38.69Z" />
    </g>
  </g>
</svg>

이것을 SVGOMG라는 서비스를 통해 최적화 해주었다.

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 183.15 148.15">
  <path
    d="M143.47 75.08a1.69 1.69 0 0 0-2.18 2.58c36.63 31 38.55 60.29 38.45 67.12h-73.23V130a2.64 2.64 0 0 0 0-.28c-1.8-10.52-6.17-17.61-13-21.09-11.59-5.93-25.83.91-26.43 1.2a1.67 1.67 0 0 0-.28.18c-5.18 4-10.58 5.44-16 4.42C38.17 112 29 97.12 28.93 97a39.81 39.81 0 0 1-2.48-5.21c.16.22.32.44.49.64a3.34 3.34 0 0 0 2.56 1.29 5.91 5.91 0 0 0 2.48-1c2.47-1.39 5-3.42 5.52-6.38a2.19 2.19 0 0 0-.54-2 2.09 2.09 0 0 0-2.05-.55 24.92 24.92 0 0 1-4.21 1.28h-.09a3.05 3.05 0 0 1-.52 0h-1.26l-.42-.07a3.9 3.9 0 0 1-.46-.12c-.1 0-.76-.28-.23 0a2.34 2.34 0 0 0-1.62-.22 2.37 2.37 0 0 0-.78.42 4.92 4.92 0 0 1 .36-1.33 3.46 3.46 0 0 1 2.15-2c12.88-2.21 20.28-5.37 22-9.4a4.21 4.21 0 0 0 0-3.57c-6-22.48 17.5-30.77 18.53-31.12a1.69 1.69 0 0 0-1.07-3.2c-.28.1-27.73 9.68-20.66 35.38a.88.88 0 0 0 .19.45 1.17 1.17 0 0 1-.16.86c-.68 1.31-3.93 4.63-19.54 7.29a6.88 6.88 0 0 0-4.51 3.84C20.89 86.05 22 91.56 26 98.72c.4.66 10 16.31 24.11 19 6.39 1.2 12.63-.46 18.57-4.94 1.44-.66 13.77-6 23.29-1.16 5.78 3 9.53 9.18 11.15 18.51v16.36a1.69 1.69 0 0 0 1.69 1.69h76.52a1.7 1.7 0 0 0 1.68-1.49c.18-1.44 3.6-35.04-39.54-71.61Z" />
  <path
    d="M87.71 75.1a22 22 0 0 0 12.45 13.18 2.13 2.13 0 0 0 2.6-1.47 2.16 2.16 0 0 0-1.48-2.59 17.5 17.5 0 0 1-9.88-11.48c-1.75-6.63.39-13.53 2.19-19.91 1.86-6.63 3.63-13.66 2-20.53-1.41-5.81-5.44-11.15-11.41-12.73a12.81 12.81 0 0 0-9.63 1.09 11.79 11.79 0 0 0-5.63 8 2.16 2.16 0 0 0 1.47 2.59A2.13 2.13 0 0 0 73 29.8a7.78 7.78 0 0 1 4-5.66 8.87 8.87 0 0 1 7-.22c5 1.75 7.59 7.28 8 12.23 1 13.21-8.8 25.69-4.29 38.95Z" />
  <path
    d="M117.17 80.57a2.16 2.16 0 0 0-2.11-2.11 15.45 15.45 0 0 1-12-8c-2.33-4.53-1.62-10.48.29-15.05 1-2.32 2.44-4.36 3.33-6.74a28.17 28.17 0 0 0 1.55-7 33.42 33.42 0 0 0-1.54-13.9 27.74 27.74 0 0 0-3.19-6.71 15.9 15.9 0 0 0-2.35-2.88 23.85 23.85 0 0 0-3-1.89c-2.26-1.52-4.37 2.13-2.13 3.64a18.4 18.4 0 0 1 2.42 1.44 10.76 10.76 0 0 1 1.75 2.26 23.61 23.61 0 0 1 2.58 5.53 29.49 29.49 0 0 1 1.17 13.45 22.25 22.25 0 0 1-2 6.56 43.13 43.13 0 0 0-3.37 7.3C96.92 61.89 96.82 68 99.62 73c3.15 5.69 9.11 9 15.44 9.68a2.12 2.12 0 0 0 2.11-2.11Z" />
  <path
    d="M125.43 76a2.16 2.16 0 0 0 2.57-1.52 2.13 2.13 0 0 0-1.47-2.59 20.9 20.9 0 0 1-6.1-2.14A15.11 15.11 0 0 1 115.6 66c-1.21-1.63-1.07-4.06-.74-6a52.09 52.09 0 0 1 1.89-6.7 63.93 63.93 0 0 0 1.74-6.8 42.87 42.87 0 0 0 1.11-7.8 37.57 37.57 0 0 0-.69-6.68 47.55 47.55 0 0 0-1.28-5.89 29.39 29.39 0 0 0-7.4-12.66c-1.92-1.92-4.9 1.06-3 3a25.12 25.12 0 0 1 6.32 10.8 37.45 37.45 0 0 1 1.77 12.46c-.33 5-1.83 9.86-3.34 14.58-1.35 4.23-2.77 9.79 0 13.78a18 18 0 0 0 6.02 5.12 23.9 23.9 0 0 0 7.43 2.79Z" />
  <path
    d="M139 71.25a2.19 2.19 0 0 0 2.6-1.48 2.12 2.12 0 0 0-1.48-2.59 19.18 19.18 0 0 1-11-5.17c-1.39-1.45-1.46-3.56-1.34-5.46a31.85 31.85 0 0 1 1.33-6.39 45.93 45.93 0 0 0 1.54-7 32.49 32.49 0 0 0 0-7.31 47.23 47.23 0 0 0-3.07-12.95A40.76 40.76 0 0 0 120 11c-1.81-2-4.79 1-3 3a38.62 38.62 0 0 1 9.45 23 27.35 27.35 0 0 1-.3 7.45c-.44 2.22-1.13 4.38-1.69 6.58-1.13 4.41-1.92 9.83 1.29 13.57a19 19 0 0 0 6 4.36 24.36 24.36 0 0 0 7.25 2.29ZM59.25 65.4h-.33l-.28-.07-.46-.15a13.38 13.38 0 0 1-2.28-1.42 2.13 2.13 0 0 0-2.89.75 2.18 2.18 0 0 0 .76 2.89c2 1.45 4.5 2.82 7 2a8.91 8.91 0 0 0 3.1-2c.88-.82 1.74-1.65 2.61-2.48a2.11 2.11 0 1 0-3-3l-2.25 2.14a5.94 5.94 0 0 1-1 .88c.46-.27-.15.1-.24.15l-.27.18a1.49 1.49 0 0 1-.58.16c.33-.04.35-.05.11-.03ZM30.17 51.39a1.66 1.66 0 0 0 1.12-.39 1.69 1.69 0 0 0 .14-2.38l-7-7.87.25-.19 2.29-2 7 7.87a1.7 1.7 0 0 0 2.38.14 1.68 1.68 0 0 0 .14-2.38l-7-7.87 2.63-2.34 7 7.87a1.68 1.68 0 0 0 1.26.56 1.68 1.68 0 0 0 1.26-2.8l-7-7.87 2.63-2.34 7 7.87a1.68 1.68 0 0 0 1.26.56A1.68 1.68 0 0 0 46.77 35l-7-7.87 2.63-2.34 7 7.87a1.69 1.69 0 0 0 2.52-2.24l-7-7.87 2.64-2.34 7 7.87a1.7 1.7 0 0 0 2.38.14 1.68 1.68 0 0 0 .14-2.38l-7-7.87 2.83-2.52 7 7.87a1.68 1.68 0 0 0 1.26.56A1.68 1.68 0 0 0 62.43 21l-7.17-8a8.33 8.33 0 0 0-.67-10.18 8.33 8.33 0 0 0-11.74-.69l-29.24 26a8.38 8.38 0 0 0-2.59 8l-9.65 8.51A4.09 4.09 0 0 0 1 50.4a4 4 0 0 0 3.05 1.37 4.08 4.08 0 0 0 2.71-1l9.65-8.58a8.51 8.51 0 0 0 4.92.13 1.24 1.24 0 0 0 .17.23l7.38 8.3a1.65 1.65 0 0 0 1.29.54Zm-13.29-12.7a1.7 1.7 0 0 0-1.89.24L4.55 48.22a.72.72 0 0 1-1-.06.7.7 0 0 1 .06-1l10.44-9.28a1.68 1.68 0 0 0 .46-1.88 5 5 0 0 1 1.34-5.43l29.24-26a4.93 4.93 0 0 1 3.27-1.24h.31a4.94 4.94 0 0 1 3 8.63L22.43 38a5 5 0 0 1-5.55.69Z" />
</svg>

React 컴포넌트처럼 사용하기 위해 /public/svg 경로에 .svg 파일을 만들어주고, import 해서 사용했다.

대강 이런 식이다.

import Shedding from '@public/svg/problems/Shedding.svg';

...

const Step1: NextPage = () => {
  return (
    <div>
      <Shedding />
    </div>
  )
}

export default Step1;

언급한 대로 데스크톱 크롬 브라우저에서는 정상적으로 나오지만 모바일 브라우저나 심지어 추가로 발견한 현상으로 데스크톱 사파리 브라우저에서도 아이콘이 나타나지 않는 것을 발견했다. 😦

해결 방법​

허무하게 너무 간단했다.

그저 svg 태그에 width, height 속성과 값을 추가하면 되는 거였다.

<svg xmlns="http://www.w3.org/2000/svg" width="100" height="100" viewBox="0 0 183.15 148.15">
  <path
    d="M143.47 75.08a1.69 1.69 0 0 0-2.18 2.58c36.63 31 38.55 60.29 38.45 67.12h-73.23V130a2.64 2.64 0 0 0 0-.28c-1.8-10.52-6.17-17.61-13-21.09-11.59-5.93-25.83.91-26.43 1.2a1.67 1.67 0 0 0-.28.18c-5.18 4-10.58 5.44-16 4.42C38.17 112 29 97.12 28.93 97a39.81 39.81 0 0 1-2.48-5.21c.16.22.32.44.49.64a3.34 3.34 0 0 0 2.56 1.29 5.91 5.91 0 0 0 2.48-1c2.47-1.39 5-3.42 5.52-6.38a2.19 2.19 0 0 0-.54-2 2.09 2.09 0 0 0-2.05-.55 24.92 24.92 0 0 1-4.21 1.28h-.09a3.05 3.05 0 0 1-.52 0h-1.26l-.42-.07a3.9 3.9 0 0 1-.46-.12c-.1 0-.76-.28-.23 0a2.34 2.34 0 0 0-1.62-.22 2.37 2.37 0 0 0-.78.42 4.92 4.92 0 0 1 .36-1.33 3.46 3.46 0 0 1 2.15-2c12.88-2.21 20.28-5.37 22-9.4a4.21 4.21 0 0 0 0-3.57c-6-22.48 17.5-30.77 18.53-31.12a1.69 1.69 0 0 0-1.07-3.2c-.28.1-27.73 9.68-20.66 35.38a.88.88 0 0 0 .19.45 1.17 1.17 0 0 1-.16.86c-.68 1.31-3.93 4.63-19.54 7.29a6.88 6.88 0 0 0-4.51 3.84C20.89 86.05 22 91.56 26 98.72c.4.66 10 16.31 24.11 19 6.39 1.2 12.63-.46 18.57-4.94 1.44-.66 13.77-6 23.29-1.16 5.78 3 9.53 9.18 11.15 18.51v16.36a1.69 1.69 0 0 0 1.69 1.69h76.52a1.7 1.7 0 0 0 1.68-1.49c.18-1.44 3.6-35.04-39.54-71.61Z" />
  <path
    d="M87.71 75.1a22 22 0 0 0 12.45 13.18 2.13 2.13 0 0 0 2.6-1.47 2.16 2.16 0 0 0-1.48-2.59 17.5 17.5 0 0 1-9.88-11.48c-1.75-6.63.39-13.53 2.19-19.91 1.86-6.63 3.63-13.66 2-20.53-1.41-5.81-5.44-11.15-11.41-12.73a12.81 12.81 0 0 0-9.63 1.09 11.79 11.79 0 0 0-5.63 8 2.16 2.16 0 0 0 1.47 2.59A2.13 2.13 0 0 0 73 29.8a7.78 7.78 0 0 1 4-5.66 8.87 8.87 0 0 1 7-.22c5 1.75 7.59 7.28 8 12.23 1 13.21-8.8 25.69-4.29 38.95Z" />
  <path
    d="M117.17 80.57a2.16 2.16 0 0 0-2.11-2.11 15.45 15.45 0 0 1-12-8c-2.33-4.53-1.62-10.48.29-15.05 1-2.32 2.44-4.36 3.33-6.74a28.17 28.17 0 0 0 1.55-7 33.42 33.42 0 0 0-1.54-13.9 27.74 27.74 0 0 0-3.19-6.71 15.9 15.9 0 0 0-2.35-2.88 23.85 23.85 0 0 0-3-1.89c-2.26-1.52-4.37 2.13-2.13 3.64a18.4 18.4 0 0 1 2.42 1.44 10.76 10.76 0 0 1 1.75 2.26 23.61 23.61 0 0 1 2.58 5.53 29.49 29.49 0 0 1 1.17 13.45 22.25 22.25 0 0 1-2 6.56 43.13 43.13 0 0 0-3.37 7.3C96.92 61.89 96.82 68 99.62 73c3.15 5.69 9.11 9 15.44 9.68a2.12 2.12 0 0 0 2.11-2.11Z" />
  <path
    d="M125.43 76a2.16 2.16 0 0 0 2.57-1.52 2.13 2.13 0 0 0-1.47-2.59 20.9 20.9 0 0 1-6.1-2.14A15.11 15.11 0 0 1 115.6 66c-1.21-1.63-1.07-4.06-.74-6a52.09 52.09 0 0 1 1.89-6.7 63.93 63.93 0 0 0 1.74-6.8 42.87 42.87 0 0 0 1.11-7.8 37.57 37.57 0 0 0-.69-6.68 47.55 47.55 0 0 0-1.28-5.89 29.39 29.39 0 0 0-7.4-12.66c-1.92-1.92-4.9 1.06-3 3a25.12 25.12 0 0 1 6.32 10.8 37.45 37.45 0 0 1 1.77 12.46c-.33 5-1.83 9.86-3.34 14.58-1.35 4.23-2.77 9.79 0 13.78a18 18 0 0 0 6.02 5.12 23.9 23.9 0 0 0 7.43 2.79Z" />
  <path
    d="M139 71.25a2.19 2.19 0 0 0 2.6-1.48 2.12 2.12 0 0 0-1.48-2.59 19.18 19.18 0 0 1-11-5.17c-1.39-1.45-1.46-3.56-1.34-5.46a31.85 31.85 0 0 1 1.33-6.39 45.93 45.93 0 0 0 1.54-7 32.49 32.49 0 0 0 0-7.31 47.23 47.23 0 0 0-3.07-12.95A40.76 40.76 0 0 0 120 11c-1.81-2-4.79 1-3 3a38.62 38.62 0 0 1 9.45 23 27.35 27.35 0 0 1-.3 7.45c-.44 2.22-1.13 4.38-1.69 6.58-1.13 4.41-1.92 9.83 1.29 13.57a19 19 0 0 0 6 4.36 24.36 24.36 0 0 0 7.25 2.29ZM59.25 65.4h-.33l-.28-.07-.46-.15a13.38 13.38 0 0 1-2.28-1.42 2.13 2.13 0 0 0-2.89.75 2.18 2.18 0 0 0 .76 2.89c2 1.45 4.5 2.82 7 2a8.91 8.91 0 0 0 3.1-2c.88-.82 1.74-1.65 2.61-2.48a2.11 2.11 0 1 0-3-3l-2.25 2.14a5.94 5.94 0 0 1-1 .88c.46-.27-.15.1-.24.15l-.27.18a1.49 1.49 0 0 1-.58.16c.33-.04.35-.05.11-.03ZM30.17 51.39a1.66 1.66 0 0 0 1.12-.39 1.69 1.69 0 0 0 .14-2.38l-7-7.87.25-.19 2.29-2 7 7.87a1.7 1.7 0 0 0 2.38.14 1.68 1.68 0 0 0 .14-2.38l-7-7.87 2.63-2.34 7 7.87a1.68 1.68 0 0 0 1.26.56 1.68 1.68 0 0 0 1.26-2.8l-7-7.87 2.63-2.34 7 7.87a1.68 1.68 0 0 0 1.26.56A1.68 1.68 0 0 0 46.77 35l-7-7.87 2.63-2.34 7 7.87a1.69 1.69 0 0 0 2.52-2.24l-7-7.87 2.64-2.34 7 7.87a1.7 1.7 0 0 0 2.38.14 1.68 1.68 0 0 0 .14-2.38l-7-7.87 2.83-2.52 7 7.87a1.68 1.68 0 0 0 1.26.56A1.68 1.68 0 0 0 62.43 21l-7.17-8a8.33 8.33 0 0 0-.67-10.18 8.33 8.33 0 0 0-11.74-.69l-29.24 26a8.38 8.38 0 0 0-2.59 8l-9.65 8.51A4.09 4.09 0 0 0 1 50.4a4 4 0 0 0 3.05 1.37 4.08 4.08 0 0 0 2.71-1l9.65-8.58a8.51 8.51 0 0 0 4.92.13 1.24 1.24 0 0 0 .17.23l7.38 8.3a1.65 1.65 0 0 0 1.29.54Zm-13.29-12.7a1.7 1.7 0 0 0-1.89.24L4.55 48.22a.72.72 0 0 1-1-.06.7.7 0 0 1 .06-1l10.44-9.28a1.68 1.68 0 0 0 .46-1.88 5 5 0 0 1 1.34-5.43l29.24-26a4.93 4.93 0 0 1 3.27-1.24h.31a4.94 4.94 0 0 1 3 8.63L22.43 38a5 5 0 0 1-5.55.69Z" />
</svg>

처음에는 SVGOMG에서 최적화를 거칠 때 width, height가 날아간 줄 알았는데, 처음부터 없었다. 아니 없어요 그냥

Adobe Illustrator에서 svg 코드를 추출할 때부터 없었던 것이다. 왜...?

정확한 원인은 모르겠지만 svg 태그에서는 width, height 값이 필수이며, 브라우저마다 해석하는 방식이 달라서 생기는 문제인 것 같았다.

덕분에 3일을 열심히 삽질하며 물론 많이 배웠다.

임시방편보다는 기본적인 것을 살피는 것이 무엇보다 중요하다는 사실을 다시 한번 깨닳았다.

회사에서 프로젝트를 진행하다가 알게 된 내용을 정리해보았다.

프로젝트를 시작할 때마다 느끼는 것이지만, 개발 환경 설정은 쉽지 않은 것 같다. 그 중에서도 프로젝트 폴더를 구조화하는 것은 너무나도 어려운 일이다.

혼자 프론트엔드 개발 업무를 하고 있는 입장에서 함께 고민할 팀원이 없기 때문에 오롯이 혼자 결정해야 할 몫이다.

이번 글에서는 이 중에서 공통 스타일링 파일, 특히 Sass(SCSS)(CSS의 전처리기)를 사용하는 프로젝트에서 파일을 import 할 때 주의해야 하는 내용을 다뤄본다.

Vue에서 Sass(SCSS) 사용​

진행 중인 프로젝트는 Vue CLI 4 버전대를 사용하여 생성했다. SCSS를 추가하고, 컴포넌트마다 아래의 코드처럼 스타일링을 추가하고 있다.

<style lang="scss" scoped>
  ...
</style>

개인적으로 Sass와 같은 전처리기를 사용하는 이유는 여러 가지가 있지만, 핵심은 바로 nesting이다. HTML 태그와 비슷하게 selector의 parent 와 children 관계를 작성할 목적이다.

개발을 하다보면 공통적인 요소들이 늘어나기 시작한다. 그에 따라 단일 페이지 컴포넌트를 컨테이너 컴포넌트와 프레젠테이셔널 컴포넌트로 나누기도 한다.

점점 반복적인 패턴의 마크업과 스타일링 코드들의 중복을 제거하는 방법에 대한 고민이 깊어집니다. Vue에도 너무나 다양한 디자인 패턴 예시가 존재하기 때문에 slot을 사용할지 등 여러 방법을 두고 고민을 거듭하게 된다.

본 포스팅의 주제는 특정 페이지에서만 SCSS 파일을 따로 작성하는 것이다.

.scss 파일을 .css 파일처럼 import하면... 응?​

컴포넌트의 스타일링 코드를 가져와서 새로운 SCSS 파일을 만든 후(~@/assets/scss/pages/detail.scss), 해당 파일을 원래 자리에 import 하기 위해 아래와 같이 작성했다.

<style lang="scss" scoped">
@import url('~@/assets/scss/pages/detail.scss');
</style>

그리고 해당 페이지에서 아래의 코드가 반영되었는지 개발자 도구로 요소 검사를 해봤다.

.showcase--5p {
  .banner-list {
    flex-direction: column;
    justify-content: center;
    align-items: center;
    height: 100%;
    padding: 0 45vh;
  }
  .banner-item {
    width: 100%;
    height: auto;
    justify-content: center;
    padding-left: 0;
    padding-right: 0;

    .banner-content {
      width: 500px;
      z-index: 2;
    }
    .banner-image {
      width: 50%;
      justify-content: space-around;
      z-index: 1;
    }
    ...;
  }
  ...;
}

개발자 도구가 알려준 내용은 놀랍게도 충격적(?)이었다.

Sass의 nesting이 반영되지 않은 채 오류를 일으키고 있었다.

원인은 Webpack...?​

파일을 불러오는 코드를 다시 살펴보자.

<style lang="scss" scoped">
@import url('~@/assets/scss/pages/detail.scss');
</style>

여기서 문제를 일으킨 것은 바로, url() 형태로 작성된 코드였다.

아래와 같이 url()을 쓰지 않고 string 값만 입력하는 형태로 수정했다.

<style lang="scss" scoped">
@import '~@/assets/scss/pages/detail.scss';
</style>

이상한 에러 메세지는 사라지고 제대로 반영된 것을 확인할 수 있었다.

해당 문제는 Webpack의 sass-loader 문서(Problems with url(...))에서 단서를 찾았다.

하지만, css-loader를 읽어봐도 @import url();와 @import '';의 차이를 이해할 수는 없었다. 기본적으로 모두 같은 형태로 변환된다고 설명하고 있기 때문이다.

sass-loader 에서도 내부적으로는 css-loader(Dev Dependencies)를 사용하고 있는 것을 확인할 수 있다.

CSS에도 데이터 타입이 존재하더라​

원인을 정확히 이해하기 위해서 끈질기게 구글링을 하다가 MDN에서 또 다른 단서를 찾았다.

**CSS data types**를 읽어보며, CSS에도 데이터 타입이란 게 있구나... 하고 머리가 지끈해졌다. 험난한 프론트엔드 개발자의 길

CSS에도 다양한 데이터 타입이 존재하는데, 그 중 이번 포스팅 내용에 해당하는 <string> 타입과 <url> 타입을 이해하면 좋을 것 같다.

마무리​

정확한 동작 원리 를 이해하지 못하는 개발은 굉장히 힘들 수 있다는 사실을 또 한번 깨닫게 된 계기가 되었다.

앞으로도 공식 문서를 위주로 꾸준히 읽으며 개발 실력을 키워나가야 할 것 같다.

🧘🏻

상당한 코드에서 혼재되어 있는 jQuery를 걷어내는 작업을 하다가 알게 된 내용을 적어본다.

jQuery를 걷어내보자​

Vue를 사용하고 있으니 jQuery를 사용할 이유가 없을 것 같았다. 따라서 jQuery스러운 코드가 조금이라도 보이면 모조리 걷어내고 싶어졌다.

이미 작성되어있던 플러그인의 내용 중 스크롤 이벤트가 동작하는 코드를 찾았다.

$(window).on('scroll', function () {
  $('.box').css({ top: ($(window).scrollTop() / 2) * -1 });
});

코드 해석: jQuery​

1. window 객체를 scroll(스크롤)할 때 👉 스크롤 이벤트 발생
2. 함수를 실행한다. 👉 어떤 함수를?
3. .box 엘리먼트의 css 값을 바꾼다. 👉 어떻게?
4. top에 window의 스크롤 위치를 구해서 2로 나눈 값에 -1을 곱한다.

jQuery와 동일한 로직을 순수 자바스크립트로 아래와 같이 작성했다.

const boxElem = document.querySelector('.box');

window.addEventListener('scroll', () => {
  boxElem.style.top = (window.scrollY / 2) * -1;
});

코드 해석: JavaScript​

1. boxElem 상수에 .box를 넣어준다.
2. window 객체에 scroll 이벤트를 추가한다.
3. 스크롤 이벤트가 발생하면 함수를 실행한다. 👉 어떤 함수를?
4. boxElem의 style 속성의 top 값을 'window의 스크롤 위치를 구해서 2로 나눈 값에 -1을 곱한다.'로 변경한다.

...? 하지만, 위 코드는 동작하지 않는다.

jQuery의 CSS API​

jQuery API 문서 중 .css()를 찾아봤다.

문서 중간쯤에 이러한 내용이 있다.

When a number is passed as the value, jQuery will convert it to a string and add px to the end of that string. If the property requires units other than px, convert the value to a string and add the appropriate units before calling the method.

내용인 즉, jQuery에서는 숫자값이 들어오면 자동으로 px(픽셀) 단위를 붙여준다는 말이다.

따라서 jQuery는 px이나 rem 따위의 **단위(unit)**를 넣지 않았음에도 기본값인 px를 붙여주기 때문에 작동하는 것이고, 바닐라 자바스크립트로 새로 작성한 코드가 작동하지 않았던 이유는 단위를 누락했기 때문이었다.

Element style에는 단위를 꼭 붙여주자​

다시 위의 코드로 돌아가서,

boxElem.style.top = `${(window.scrollY / 2) * -1}px

마지막에 px 단위를 추가해줬다.

const boxElem = document.querySelector('.box');

window.addEventListener('scroll', () => {
  boxElem.style.top = `${(window.scrollY / 2) * -1}px`;
});

이제 정상적으로 동작하는 것을 확인했다 😊

문자열과 자바스크립트 변수를 결합할 때 대부분 백틱을 사용해서 코드를 작성하고 있는데 일부 코드에서 에러가 발생했고, 해결해가면서 백틱의 특징을 조금 더 알 수 있었다.

백틱은 화면에 입력한 그대로 표현된다?​

백틱의 특성 중 하나는 백틱 내에 입력한 문자열은 공백 과 개행 까지 그대로 표현되는 것이다. 이러한 특징은 마치 HTML의 pre 태그와 비슷하다.

따라서 특정 상황에서는 예상치 못한 결과가 나오기도 했다.

예제 코드​

개인적인 프로젝트에서 Code Formatter인 Prettier를 사용하고 있다.

문의하기 페이지의 Form에서 휴대폰 번호를 처리하는 코드의 일부를 예제로 가져왔다.

예시로 사용할 전화번호는 010-1234-5678 이다.

아래와 같은 String을 Form으로 전송하려고 한다.

{
  "phone": "010-1234-5678"
}

1번 예제 ('+' 연산자를 사용한 문자열 결합)​

let request = phoneNumber.substr(0, 3) + '-' + phoneNumber.substr(3, 3) + '-' + phoneNumber.substr(6);

// 010-1234-5678

2번 예제 (백틱 문법)​

백틱 으로 작성한다면 이러한 코드가 될 것이다.

let request = `${phoneNumber.substr(0, 3)}-${phoneNumber.substr(3, 3)}-${phoneNumber.substr(6)}`;

// 010-1234-5678

Prettier의 printWidth 값에 의해 자동 개행으로 코드를 다듬어주기 때문이다.

3번 예제 (백틱 사용과 개행)​

또는 가독성을 위해 백틱을 열어두고 다음 행부터 작성하기도 한다.

let request = `
  ${phoneNumber.substr(0, 3)}-${phoneNumber.substr(3, 3)}-${phoneNumber.substr(6)}
`;

Code Formatter의 자동 개행 처리에 의한 오류​

2번과 3번의 예제처럼 백틱을 적용한 코드를 formatting 할 경우, Prettier가 printWidth 옵션(기본값 80)에 따라 자동으로 처리하기 때문에 예측하기 어려울 수 있다. 여기에서 백틱의 특징 때문에 문제가 발생할 수 있다.

백틱을 사용한 코드에 Prettier를 적용하면 아래처럼 formatting 된다.

한 줄로 입력한 경우​

// prettier-ignore
let request = `${phoneNumber.substr(0, 3)}-${phoneNumber.substr(
  3,
  3
)}-${phoneNumber.substr(6)}`;

// 010-1234
// -5678

일반적으로 코드를 작성할 때 가독성을 위해 indent(들여쓰기)를 추가하고, String을 작성하는 방법을 많이 사용한다.

이 경우에도 백틱을 사용하여 입력한 String 데이터를 보내야 할 때 문제가 발생할 수 있다.

A. 백틱을 열고 indent를 추가하여 입력한 경우​

// prettier-ignore
let request = `
  ${phoneNumber.substr(0, 3)}-${phoneNumber.substr(3, 3)}-${phoneNumber.substr(
  6
)}
`;

// (공백 2자) 010-1234
// -5678

B. 백틱 사이를 열고 입력한 경우​

가독성을 위해 들여쓰기를 추가하고 String을 작성했다.

// prettier-ignore
let request = `
  ${phoneNumber.substr(0, 3)}
  -
  ${phoneNumber.substr(3, 3)}
  -
  ${phoneNumber.substr(6)}
`;

// (공백 2자) 010
// (공백 2자) -
// (공백 2자) 1234
// (공백 2자) -
// (공백 2자) 5678

개행(또는 공백)의 위치에 따라 Prettier를 사용하면 다양한 형태로 formatting 될 수 있다.

이러한 결과 때문에 form 내의 input 또는 textarea의 String 값을 보낼 때는 주의가 필요하다.

필요에 따라 정규표현식이나 JavaScript의 trim(), concat() 등의 String 메소드 또는 join() 같은 Array 메소드 등을 적절히 사용해서 해결하면 된다.

그동안 있었던 일들을 글로 정리해보려고 한다.

이직 과정​

3개월 전, 열심히 이력서를 내고 포항에서 수도권 지역까지 면접을 보러 다녔다.

로켓펀치, 원티드 채용 공고들을 살펴보며 조금이라도 가능성이 있으면 닥치는 대로 이력서를 찔러넣었다.

코딩테스트 준비와 자바스크립트, 리액트 공부를 하며 끊임없이 도전했지만 수많은 서류 탈락, 면접 탈락의 아픔을 맛보며 좌절하던 시간을 보내고 있던 도중 로켓펀치에 이력서를 공개해둔 덕분에 현재 다니고 있는 회사와 연락이 닿았다.

연봉과 복지가 만족스러운 수준이었고, 또한 개발 회사는 아니지만 시대의 흐름을 따라가기 위해 과감한 투자들을 연이어 진행하고 있는, 마인드가 훌륭한 곳이라고 판단했다.

프론트엔드 개발자로서 새로운 커리어를 시작하는데 있어서 같은 포지션의 선배 개발자가 없다는 것은 아쉬웠지만, 나 자신이 하기 나름이라고 생각해서 이직을 결정하게 되었다.

포항에서 분당으로​

나에게 대구, 경북을 제외한 다른 곳들, 또한 수도권은 미지의 세계였다. 당연히 경기도 지역은 너무나도 생소한 곳이었다.

이미 회사에 면접을 다녀왔지만 내가 가는 곳이 성남인 줄만 알았지, 거기가 얘기로나 듣던 '분당'인지 몰랐다. 수도권 사람들이 보면 무식하다고 웃을지도 모르겠다.

대구 촌놈이 멀리도 나왔다고, 한편으로는 너무 늦지 않은 나이에 잘 왔다고 생각했다.

이직을 확정짓고 한 달간 이사할 집을 구해야 했다. 감사하게도 부모님께서 포항 집을 정리하고, 집을 알아보러 다니는 일을 도와주셨다.

특히 아버지께서 이삿날 너무 고생하셨다. 트럭으로 일요일 아침부터 포항에서 짐을 싣고, 구미에서 지인 결혼식에 참석했다가 다시 대구로 가서 어머니를 차에 태우고 분당으로 이동해 짐을 내려야 하는 대장정이었다. 짐을 모두 내리고 나니 자정이 가까운 시간이었고, 다음날 아버지는 출근하시기 위해 바로 내려가시기 바빴다.

몇 주 뒤 할머니를 뵐 일이 있어서 이사할 때 있었던 이야기를 해 드리며 아버지가 너무 고생하셨다고 말씀드렸더니, 너가 나중에 아들 낳아도 똑같이 해 줄 거라고, 그게 부모의 마음이라고 하신다.

또다시, 열심히 살아야겠다는 각오를 다졌다.

분당 생활의 시작​

그동안 프론트엔드 개발자로 이직하기 위해 React를 중심에 두고 공부했던 나는 회사의 기존 프로젝트 소스가 Vue로 구축된 덕분에(?) 유지보수 업무를 수행하기 위해 Vue를 공부하기 시작했다.

우리나라에서 Vue.js 알리미로 유명하신 캡틴판교 님의 대부분의 Vue.js 온라인 강의를 3개월 동안 열심히 들으며, 기존 소스에 조금씩 적용해가고 있다.

캡틴판교 님이 활동하시는 판교와도 정말 가까운 곳으로 왔다는 생각을 하니 개발자 행사같은 것들에 대 기대감이 가득했다.

하지만 코로나19라는 지긋지긋한 역병은 끝날 줄을 몰랐고, 대한민국 인구의 반이 살고 있는 수도권에서는 훨씬 체감이 심하게 왔다. 확진자 수는 지방과는 비교도 할 수 없을 만큼 하루마다 쏟아져나왔다.

4월 한 달을 다니고, 5월부터 골프를 시작했다. 평생 골프라는 것에 관심이 없었는데 분당 치고는 굉장히 저렴한(?) 연습장 이용료와 레슨비로 운영하는 연습장 덕분에 시작할 수 있었다.

자기개발, 몸 관리를 게을리 하지 않고 골프도 하면서 열심히 살아야겠다.

4월​

끔찍했던 프로젝트가 드디어 종료되었다.

5월​

그토록 원하던 사무실 내근을 시작했다. 개발 일정 쥐어짜내기는 본사 사무실에서도 여전하다. 6월 말까지 코로나를 핑계로 어떻게든 빨리 빨리 만들어내라고 닦달이다.

7월​

갑자기 또 파견을 가야 한단다. 어떤 프로젝트인지 내용은 대충 듣고 바쁘게 투입되었다.

2020년 하반기​

7월에 시작해서 12월 말에 끝나기로 예정되었던 프로젝트가 아직도 개발이 끝나지 않았다. 하지만 계약된 일정에 따라 12월 31일을 기점으로 나의 업무는 공식적으로는 종료되었고, 회사의 요청에 따라 일주일 추가 근무만 더 하면 투입이 완전 종료될 예정이다.

마지막까지도 나를 괴롭히고 있는 이 프로젝트 때문에 2020년은 정말 힘들었다. 오죽했으면 그 전까지 이직 준비를 손놓고 있었다가 투입된 지 2주 뒤부터 홀린 듯이 이직을 위한 공부와 운동을 시작했을까.

탈출을 위한 준비 시작​

'여기서는 개발자로서 미래가 없다. 최대한 빨리 이런 환경에서 탈출해야 한다...'는 두려움을 안고 퇴근 후에는 어김없이 최소 하루 한 개의 강의를 보며 커밋을 하고, 옆에 엎드려서 푸시업을 100개씩 했다.

비록 잔디의 개수가 많지는 않아도 꾸준하게 실천한 것에 의미를 두고 싶은 한편, 2020년 마지막 주에 완전히 녹초가 돼서 꾸준함을 끝까지 끌고 가지 못한 점이 아쉽다.

최악의 프로젝트, 자괴감​

프로젝트에 관해 이야기하자면 할 말이 정말 많지만, 인생에서 다시는 이런 프로젝트를 하고 싶지 않다.

내가 속한 이 회사는 자신들이 개발자에게 어떤 규모의 프로젝트를 맡기는지 제대로 파악하지 않았고, PM은 마찬가지로 고객이 어떤 제품을 원하는지 제대로 측정하지 않았다. 가장 문제인 것은 고객 측에서 설계 전체를 비틀어버리는 추가, 변경 사항을 요구한 게 한두 번이 아니었다. 그 요구는 연말 마지막 날까지도 계속되었다.

PM은 맨먼스(M/M, Man Month)라는 단위로 개발 프로젝트를 산정할 뿐, 개발 방법을 논의하려고 하면 "그래서 돼요? 안 돼요?" 라며 개발에는 전혀 관심이 없었다. 본인이 맡은 업무는 행정적인 것을 처리해서 도장만 찍으면 끝일 뿐인 사람이었다. 골 때리는 건 개발이 아직도 끝나지 않았는데 프로젝트는 행정적으로는 완료 처리가 되었다는 사실.

회사 역시 그 일이 마무리되고 있는지 아닌지가 중요할 뿐 직원을 소모품으로 생각하는 게 너무 눈에 보였고, 추가 수당 따위는 없었다. 7월부터 12월까지 근무 시간을 기록해두었다. 7월은 186시간 57분, 8월은 172시간, 9월은 187시간 18분, 10월은 166시간 24분, 11월은 222시간 26분, 12월은 241시간 41분을 근무했다.

마지막 두 달은 정말 무지막지한 야근의 연속이었다. 개발 기간을 맞추기 위해 다른 프로젝트에 파견되어있는 동료 개발자들이 와서 1~2주 정도 도와주는 식으로 일을 했는데, 처음부터 개발했던 나조차도 이해하며 개발하기 어려운 업무 프로세스를 잠깐씩 와서 어떻게 돕는단 말인지. 자괴감의 연속이었다.

12월 마지막 주에는 정말 아무것도 하기 싫었다. 하루도 거르지 않은 잔디 심기를 중단했고, 공부도 손에 안 잡혔다. 운동은 그나마 쉬지 않았다. 완전한 번아웃을 느꼈다. 버그가 두려워서 심장이 빨리 뛰고 숨을 제대로 쉴 수 없었을 지경에까지 이르렀던 어느 이름 모를 개발자의 사연이 나도 공감되기 시작하면서 몸과 마음이 피폐해져감을 느끼고 있다.

내일부터 일주일만 더 출근하면 정말 투입이 종료된다. 그러면 이 번아웃 상태에서 회복될 수 있을까?

이 자괴감이 굉장히 오래 지속되고 있다는 것을 8월에 끄적여두었던 글로 대신한다.

올해는 탈출할 수 있을까?​

어느 정도 마음을 추스린 뒤에 다시 개발 공부와 알고리즘 공부를 재개하려고 한다. 맑은 정신은 강한 신체에서 나온다고 믿기 때문에 앞으로도 규칙적인 운동은 항상 병행할 계획이다.

계속해서 '탈출'이라는 말을 쓰게 되는데, 정말이지 너무나도 간절한 일이다. 올해는 꼭 제대로 이직 준비를 해서 탈출을 이루고 싶다.

오랜만에 프로그래머스 Dev-Matching 프로그램에 도전했다.

프론트엔드 개발자로 지원하기 위한 좋은 방법이라고 생각해서, 이력서를 꾸준히 업데이트 해 뒀고 몇 주전에 일찌감치 접수해서 오늘! 조금 전에 드디어 과제를 마쳤다.

알고리즘을 구현하는 코딩 테스트는 항상 손도 못 대고 좌절만 하다가 끝나는(제출도 못 해본) 경우가 대부분이었다. 하지만 오늘처럼 과제 테스트를 하면 어렵기는 마찬가지지만, 그래도 오늘 과제에서는 어느 정도 요구하는 필수 기능을 구현하는 데까지만 성공했다.

라이브러리, 프레임워크 없이 오로지 순수(바닐라) 자바스크립트(ES6)로만 코딩하는 과제였는데, 한동안 리액트 공부만 하다 보니 오히려 바닐라 자바스크립트의 기본이 많이 부족하다는 것을 깨달은 시간이었다.

요구사항 중 한 가지가 컴포넌트 단위로 작게 나눠서 느슨하게 구현하라는 거였는데, 난 바닐라 자바스크립트로는 리액트처럼 파일 단위의 컴포넌트를 만들어 본 경험이 없었다. 게다가 리액트가 아닌 ES6의 class, import, export를 이해하지 못한 상황에서 구현하려다가 시간을 많이 소비하기도 했다.

이번 과제를 통해 어떤 것을 더 공부해야 할지, 기업에서 어떤 구현 방식을 요구하는지, 그것으로 어떤 개발자를 원하는지 간접적으로 알 수 있었고 많은 생각을 하게 된다.

이번에도 역시 면접까지 이어지는 건 아무래도 가능성이 낮지 않을까 싶지만, 과제를 하며 직접 많은 것을 느꼈기 때문에 더 노력해야겠다고 결심하게 된 계기가 된 점은 만족스럽다.

2. 일일 커밋​

프론트엔드 공부하기​

한동안 이런저런 핑계로 방치해뒀던 잔디 심기를 꾸준히 하고 있다.

다시 시작한 건 7월 12일부터, 본격적으로 빵꾸내지 말자 꾸준히 해 보자고 다짐한지는 1개월이 다 돼 간다.

돌이켜보니 이 기간동안 그래도 제법 많은 것을 배웠다.

• React (Router, Hooks...)
• React Native
• Styled-Components
• fetch API, Axios
• gh-pages, Netlify, Expo
• ES6+
• CSS Flex, Grid
• CSS 애니메이션으로 인터랙티브한 웹 만들기
• React-Redux 등

한 달의 과정을 되돌아보니, 본격적인 프론트엔드 실력을 만들기 위한 기초 공사를 시작한 기간이 되었다고 생각한다.

노마드 코더의 니콜라스 선생님, 감사합니다.

체력 만들기​

시작한지 2주 정도까지는 퇴근하고 내가 하고 싶은 공부를 할 수 있다는 사실만으로도 굉장히 즐거웠다.

하지만 역시 나태함은 금방 고쳐지지 않았다.

어느 순간부터 회사 프로젝트 설계 과정에 지쳤는지, 마치고 지친 몸과 마음을 이끌고 카페로 다시 '출근'한다는 생각이 들었다. 그런 날은 한 시간 정도 집에서 쉬다가 다시 나와 악착같이 카페로 향했다.

체력이 많이 약해진 것 같아서 2주 전부터는 일일 푸쉬업도 하고 있다. 집에서 할 수 있는 아주 좋은 운동이라고 생각해서 열심히 하고 있다.

코딩 테스트 준비도 해야 하는데​

생각만 하고 실천을 못 하고 있다. 나에게는 알고리즘이라는 산이 너무 큰 부담으로 자리잡고 있는 것 같다.

서둘러서 프론트엔드 지식을 쌓고, 알고리즘 공부도 조만간 본격적으로 시작해야 할 것 같다.

원래 본사 사무실에서 솔루션을 개발하고 있었는데, 갑자기 급하게 진행할 프로젝트가 있다고 했다. 투입된지 이틀째, 킥 오프 회식을 하고 대략적인 프로젝트 설명을 들은 게 전부다.

하지만 이미 잡힌 계획 상으로는 다음 달 중순까지 화면 설계 및 DB 설계와 더불어, 딸려나오는 산출물(설계서, 테스트 결과서 등)까지 작성해야 한단다. 그것도 나 혼자서 한 파트를 총 담당해서. 그렇게 해서 10월 중순~말 경에 가 오픈(베타 서비스)을 해야 한다고?

높으신 분들께서 상상의 나래를 펼치며 세웠을 계획을 듣고 나니 힘이 쭉 빠진다. 두 달 만에 설계부터 개발까지 해서 가오픈? 솔직히 자신이 없다. 아니, 무슨 작성해야 하는 문서가 그렇게 많은지. 프로젝트 기간은 왜 이렇게 짧은지. 월급은 쥐꼬리만한데 뭘 위해 이렇게까지 일해야 하는지. 한 사람에게 일을 가중시키면서까지 비용을 아끼는 것이 그렇게 중요할까?

원래 SI라는 게 항상 이런 식인가?​

이틀만에 벌써 지치기 시작했다.

경력 2년차인 개발자 한 명이 그 많은 설계서와 문서를 작성하고, 개발도 프론트엔드, 백엔드, DB까지 해내야 하다니. 혹자는 말도 안 된다고 생각하지만, 실제로 진행되고 있고 내가 겪고 있는 과정이다(불과 이틀만에).

내가 개발에 입문하고 배워온 비교적 최근 지식에 의하면 항상 프론트엔드, 백엔드라는 용어로 구분이 되었다. 그에 따른 개발 스택이 따로 존재했다.

지금 속해있는 지방 SI 세상에는 개발 스택이라는 용어도 쓰지 않는 듯하다. 서버는 무엇을 쓰고, 언어는 Java(거의 대부분), DB는 뭘 쓰고. 개요서나 설계서 어디에도 프론트엔드 혹은 자바스크립트라는 용어는 존재하지도 않는다. 그들에게 난 백엔드 개발자 혹은 풀스택 개발자가 아니라 '자바 개발자' 혹은 그냥 '개발자'로 칭한다.

퍼블리싱이라는 개념도 모호하고, 크게 '개발자' 또는 '디자이너'로 나눈다. 그렇기 때문에 '개발자'는 설계하고 개발하는 사람, '디자이너'는 포토샵으로 시안을 만들거나 버튼, 혹은 삽화를 제작하는 역할을 한다. 요즘은 그나마 퍼블리싱까지 커버하기는 한다.

내가 속한 회사에서는 주로 해당 지역의 대기업 프로젝트를 수주해서 진행하는 경우가 많다. 그곳에 투입되면 많은 보안 관련 절차들을 진행한다. 보안 프로그램을 깔아야 한다는 얘기다. 수많은 보안 프로그램이 설치된 노트북은 하루에도 몇 번씩 사용하던 응용 프로그램을 껐다 켜야 하기 일쑤다.

구글링은 가능하지만, 많은 IT 회사들이 사용하는 협업 프로그램은 사이트에 접속조차 되지 않는다. 보안에 위배되기 때문에 그렇단다.

아직도 형상 관리 도구로 Git을 사용하지 않는 곳도 많다. 이번 프로젝트도 SVN으로 소스를 관리해야 할 것 같다.

경험해 본 SI 개발자의 유형​

앞서 두 번의 프로젝트를 경험해본 바에 의하면, 겪어본 개발자의 유형은 이렇다. 일반화하고 싶진 않다.

1. 주어진 개발 환경에 잘 적응하며(레거시가 레거시인 지도 모르는) 개발하는 대다수의 개발자
2. 레거시를 알고, 바꾸고 싶지만 어쩔 수 없이 개발하는 개발자
3. 개발 환경을 바꾸고 싶어하는 소수의 나같은 개발자

내가 잘 났다는 말은 '절대' 아니다. 열악한 개발 환경을 바꾸려는 시도라도 해보려면 같은 생각을 가진 개발자들이 많이 필요하다. 함께 고민하고, 적극적으로 의견을 주장해야 한다고 생각한다. 그러나 현실은 그렇지 못하다.

최신 기술은 나 말곤 아무도 관심 없나?​

솔직히 여기서 그냥 쭉 개발한다면 스프링 부트니, JPA니, 리액트니 하는 최신 기술을 배울 필요가 없다. 써먹을 기회가 없기 때문이다. 심지어 Node.js나 ES6는 이제 최신 기술이라고 얘기하기도 민망한 수준이라고 생각하지만.

웃긴 건 최근에 다녀온 프로젝트의 개발 스택 중 DB는 비교적 굉장히 최신이다. Hadoop이나 PPAS 많이 쓴다. 나머지는 레거시 투성이다. 거의 무조건 jQuery를 사용하고, UI 라이브러리는 없는 경우가 많고, 하드 코딩으로 때운다. CSS는 아직도 float이 난무한다. flex? grid? 꿈같은 얘기다. SCSS의 존재를 아는 사람은 없다고 여겨진다.

온라인 강의 코스만 봐도 React, Vue, Graphql이라는 용어가 익숙하지만, 이 곳에 있는 동안 동료 개발자들과 몇 마디 나눠보고, 개발 스택을 주제로 대화를 시도하는 것을 포기했다.

사용하는 IDE는 (거의) 무조건 Eclipse이다. 이클립스에서만 원활하게 작성이 가능한 어느 특정 프레임워크를 사용하는 덕분이다. 대세가 된지 몇 년이 된 Visual Studio Code는 나만 아는 프로그램인 것 같았다. 나는 사용법을 까먹을까봐서라도 백엔드 단을 제외하고, View(JSP, JavaScript)단이나 CSS, Query를 작성할 때 일부러 꾸준히 사용했다. 모 동료 개발자는 사용법을 몰라서 안 쓴다고.

최신 기술들을 적재적소에 적용한다면 개발이 상당히 편해질 것이고, 그에 따라 SI 특성상 촉박한 개발 일정을 조금이나마 당길 수 있을 것 같은데 자꾸만 '유지보수의 어려움'을 이유로 도입하지 않는다. 내가 생각하는 개발자는 끊임없이 지식을 추구해야 하는 직업인데, 배운 지식들을 써먹지 못하니 개발이 즐거울 수가 없다. 적성에 맞아 시작한 개발자 커리어는 일을 할 수록 점점 열정이 식어간다.

여기서 하루 빨리 도망가야 한다는 생각이 자꾸 드는 이유다. 토이 프로젝트를 다시 적극적으로 실행에 옮겨야겠다.

그래도 나에게 주어진 소중한 기회​

이러한 환경 속에서 무언가를 바꿀 수 있을까를 고민하기 시작했다. 함께 투입된 부장님께서 생각이 상당히 젊으신 분이라서 첫 날부터 뭔가 좋거나 쓰고 싶은 게 있으면 제안을 부탁하신 것이 계기였다. 그 말을 들은 순간 머릿속에는,

최소한 Babel은 무조건 써야 한다.

여기서 JSP 대신 React를 사용할 수 있을까?' 처음부터 시도하고 적용해 보자.

불가하다면 제발 Bootstrap이라도 사용하자!

라는 생각에 도달했다. 문서 작성이 끝나고 코딩에 들어가면 적극적으로 시도해 보자.

일단 이틀간 프로젝트 진행 과정은 여기까지.

어제 놓친 우아한 테크세미나​

오늘 퇴근하고 메일을 확인하다가 어제 진행된 우아한 테크세미나를 놓친 것을 확인했는데, 다행히 유튜브 링크가 걸려있었다.

링크 타고 들어갔는데 너무나도 공감이 되는 영상을 발견했다.

박재성 강사님께서 독하게 말씀해 주셔서(더 독하게 하셨어도 좋았을 것 같다) 나를 비롯한 수많은 주니어 SI 개발자에게 사이다같은 기분을 느끼게 해 주셨다고 생각하는 영상이다.

사장님에게는 죄송하지만, 나도 공감하고 염원하는 바다. 이 업계 중에서 특히 개발 교육 인프라가 부족한 지방 SI는 바닥을 치고 올라올 필요가 있다고 생각한다.