최근 Snackbar 컴포넌트를 만들면서 callback ref를 사용하게 되었습니다. callback ref는 함수를 ref로 전달하는 방식입니다. 이 글에서는 callback ref를 사용하게 된 이유와 사용 사례를 컴포넌트 개발 사례를 통해 소개하고자 합니다.

Quest! Snackbar 컴포넌트 제작하기​

Snackbar 컴포넌트는 사용자에게 메시지를 보여주는 컴포넌트입니다. 사용자가 어떤 작업을 했을 때, 성공했는지 실패했는지 등을 알려주는 데 사용합니다.

말줄임표 처리 문제​

제가 맞닥뜨린 문제는 Snackbar 컴포넌트의 내부 텍스트의 말줄임표 처리였습니다. 단순히 Snackbar 컴포넌트의 내부 메세지 텍스트에 max width값을 설정해 주어 ellipsis로 말 줄임 처리하면 해결되는 문제가 아니었기 때문입니다. Snackbar 컴포넌트 내부에 액션버튼이 있을 때, 액션 버튼의 길이에 따라 내부 메세지 텍스트의 max width값이 동적으로 변경되어야 했습니다.

const Snackbar = ({ message, action }) => {
  const classes = useStyles({
    root: {
      width: "fit-content",
      maxWidth: "300px",
    },
    message: {
      width: "fit-content",
      // maxWidth: 'calc(100% - action 버튼의 크기에 따라 동적으로 변경)',
      overflow: "hidden",
      textOverflow: "ellipsis",
      whiteSpace: "nowrap",
    },
    action: {
      maxWidth: "100px",
      overflow: "hidden",
      textOverflow: "ellipsis",
      whiteSpace: "nowrap",
    },
  });

  return (
    <div className={classes.root}>
      <div className={classes.message}>{message}</div>
      <button className={classes.action}>{action}</button>
    </div>
  );
};

릴리즈를 하면 개발자의 일이 끝난 걸까요? 지난 3년 간 10여 번의 크고 작은 릴리즈를 경험하면서 느낀 점은 '끝날 때까지 끝난 게 아니다'였습니다.

어찌 보면 당연한(?) 말인데요. 처음에는 릴리즈 === 끝이라고 생각했습니다. 개발 기간 동안 야근한 나를 위로하기 위해 긴 휴가를 보내거나 하릴없이 월급 루팡을 하기도 했고요. 하지만 정말 프로젝트를 매조지기 위해서 해야 할 일들이 있고, 코드 개발에 비해 개발자들이 놓치기 쉽고 귀찮은 작업들이 많습니다.

우연히 읽게 된 <Stopping at 90%>라는 글에 굉장히 공감하며 읽었고, 이것이 비단 개발자들만의 문제는 아니라는 점도 알게 되어 흥미롭게 읽었습니다. 글을 소개하며 저도 지금까지 프로젝트들을 잘 마무리해왔는지 되돌아보려고 해요. 이 글을 읽는 분들도 하고 계신 일을 완전히 매듭짓는 데 이 글이 도움이 되었으면 좋겠습니다.

어그로성이 짙은 제목입니다. 이 글은 회사에서 2개월 간 서비스 개발을 멈추고, 개발 프로세스를 점검하고 개선하는 TF에 참여하면서 느낀 점을 정리한 글입니다. 저도 프론트엔드 개발 말고 이런 업무는 처음이라 2개월간 많은 삽질을 했는데 이 과정을 글로 정리하면서 배운 점, 개선할 점들을 돌아보고 싶었습니다.

TF의 발단​

TF란 'Task Force'의 약자로, 특정 목적을 달성하기 위해 일시적으로 구성된 팀을 말합니다. 저희 회사에서는 '지속가능한 개발팀'을 위해 2달간 제품 개발을 멈추고, 회사의 개발 프로세스를 점검하고 개선하는 TF를 구성했는데요. 이 TF는 서비스의 메이저 업데이트 회고 이후 제기된 문제점을 해결하기 위해 시작되었습니다.

새벽 5시 퇴근... 그만 하려면 어떻게 해야할까요?​

저희 회사의 제품은 예전 포토샵과 같은 패키지 형태이고, 5~8개월 주기로 서비스를 배포 합니다. 유저에게 배포 메일이 릴리즈 된 이후에는 제품에 버그가 있어도 변경할 수 없기 때문에 마지막의 마지막까지 공들여 QA하고 버그픽스를 진행하는데요. 핫픽스 버전을 내는 것이 비즈니스적으로 비용이 매우 많이 드는 작업이고, 고객과의 신뢰와도 연관되어있기 때문에 모든 개발자가 부담을 가지고 진행합니다. 스프린트 후반에는 종종 주말 출근을 하기도 하고, 최종 빌드 날까지 버그 픽스와 QA를 진행하느라 새벽 퇴근이 당연해지는 문제가 있었어요.

블로그 3.0을 시작하며 양질의 글을 쓰기로 마음먹은지 벌써 2년이 지났습니다. 하지만 메세지가 있는 글, 내 마음에 드는 글을 쓰기란 생각보다 쉽지 않았고 2년간 9개 밖에 작성하지 못했습니다. 올해 글쓰기를 조금 더 잘하고 싶어서 글또 9기 활동을 시작했고, 글또에서 <실용주의 글쓰기> 세미나를 듣고 제 작문 활동을 되돌아 봅니다.

지덕체를 고루 갖춘 훌륭한 사람이 되고자 했던 2023년이 지나갔습니다. 회고를 쓰고 있는 지금은 감기에 걸려서 조금 골골대고 있지만 종합적으로 보면 지덕체 스탯을 골고루 찍었지 않았나... 하는 생각이 드네요. 구체적으로 1년동안 어떻게 살았는지, 그리고 2024년에는 또 방향으로 나아가야 하는지 생각하는 시간을 가져보려고 합니다.

여러 가지 언어를 지원하는 서비스를 만들 때, 개발적인 어려움 외에도 디자이너, 번역가와 협업하면서 마주치는 어려움도 있습니다. 이 글은 제가 다국어 언어 key 관리 업무를 맡으며 겪었던 비효율과 이를 Locize라는 플랫폼으로 해결한 내용을 다룹니다. 언어 key 관리에 고통받는 분들의 생산성을 높이는 데 도움이 되길 바랍니다.

이전 포스트에서 소개했듯이 저는 현재 회사에서 다국어 서비스를 만들고, 운영하고 있습니다. 이 글에서는 3개 국어를 지원하는 서비스를 개발해 오면서 겪었던 어려움과, 이를 해결하기 위해 시도했던 방법들을 공유하고자 합니다. 글로벌 서비스를 운영하시는 분들께 도움이 되었으면 좋겠습니다.

글또 9기를 지원하며 작성한 글입니다.

내가 거의 매일 사용하는 어플 중 하나는 지도 어플이다. 기술이 발전하면서 지도의 기능이 다양해져 단순히 길을 찾는 데에만 쓰지는 않는다. 이동시간을 최적화 할 때, 맛집을 찾아볼 때, 또가고 싶은 곳을 기록할 때에도 쓴다. 새로운 길을 갈 때에도 도움이 되지만, 익숙한 길을 갈 때에도 도움이 되기도 한다.

만약 삶에도 지도가 있다면, 앞으로 가야할 길에 큰 도움이 되지 않을까? 실제 지도를 볼 때처럼 내가 지금 어디에 있고, 어디로 가야하고, 어떻게 가야할지 지도에 비유해 생각해 보려고 한다.

제가 회사에서 만들고 있는 제품은 한국뿐 아니라 일본, 싱가폴, 대만, 유럽 등 다양한 국가에 고객사가 있습니다. 지금은 영어, 일본어, 한국어를 지원하고 있는데요. 취준생 시절 포트폴리오를 만들기 위한 웹서비스 개발을 할 때에는 다국어 지원 경험이 많지 않아서 처음엔 조금 생소한 주제였습니다. 그래서 이번 기회에 다국어 지원을 위한 구현 방법을 정리해보려고 합니다.

먼저, 생각해 볼까요?​

위와 같이 다양한 언어를 지원하는 서비스를 만들려면 어떻게 해야할까요? 간단히 구현방법을 생각해보면 다음과 같습니다.

1. 컴포넌트 내 모든 문구를 하드코딩하지 않고, 언어에 맞는 문구를 반환하는 메서드를 사용한다.
2. 언어별로 문구를 관리하는 파일을 마련한다.
3. 언어 선택 버튼을 만들어서, 언어를 선택하면 해당 언어로 문구를 반환할 수 있도록 한다.

생각보다 복잡하지는 않습니다. 직접 구현해 보는 것도 좋은 경험이지만 위에 나열한 것들을 쉽게 구현할 수 있도록 도와주는 라이브러리가 이미 존재합니다!

뉴로클에서 일한 지 벌써 2년이 다 되어갑니다. 첫 직장, 스타트업에서의 2년을 돌아보고 앞으로의 각오를 정리해 봤어요.

입사 전​

합격 메일을 받고 약 3주간의 시간이 있었습니다. 사실 그때 당시에는 AI 도메인에 대해 잘 몰랐고, 회사가 만드는 제품에 대해서도 잘 몰랐어요. 그냥 개발자로 커리어를 한시라도 빨리 시작하고 싶어서, 빨리 개발을 잘하게 되어 좋은 회사에 가고 싶다는 단순한 생각으로 입사를 결정했던 것 같습니다. 그만큼 모르는 것이 많았기에 불안함도 컸고요.

첫 사회생활이다 보니 대책 없이 떨기만 했고, 불안감을 줄여보고자 <신입 개발자 생존의 기술> 같은 책을 사서 입사 이후 시뮬레이션을 돌려보기도 했어요. 저런 책들은 사실 실리콘 밸리를 기준으로 하고 있는 것들이 많기도 하고, 실제로 적용 해 볼만한 것들은 많지 않았던 것 같습니다. 그냥 재미있는 책을 읽을껄... 껄껄

돌아보니 입사 전의 저는 정말 아무것도 모르는 상태였던 것 같네요.