CSS는 HTML 문서의 요소들을 꾸미는 역할을 합니다. 처음 CSS를 배우고 나서는 도전적인 과제가 주어지거나, 인터렉티브한 과제가 주어지지 않는 이상 초반에 배웠던 CSS를 그대로 사용하게 되는데요. 저도 취업 이후에는 따로 CSS를 공부하지 않았던 것 같습니다. 최근 zero-runtime CSS-in-JS 키워드를 접하게 되면서 어떤 스타일링 방식이 있는지 다시 한 번 정리해보고자 합니다.

CSS의 작동방식​

Vim is a highly configurable text editor built to make creating and changing any kind of text very efficient. It is included as "vi" with most UNIX systems and with Apple OS X.[^1]

Vim은 "Vi IMproved"의 준말로, 원래 UNIX 시스템에서 사용되던 Vi 편집기를 개선한 텍스트 편집기 입니다. 1991년에 v1.14가 처음 공개되었습니다.[^2]

vim 실행 화면

터미널에 vi를 입력하면 Vim이 실행됩니다.

vim을 배우고 싶었던 이유​

출처 https://xkcd.com/378/

어디에선가 vim에 익숙해지면 마우스 없이 모든 명령어를 처리할 수 있고, 생산성이 극대화된다는 말을 들었습니다. 저는 리눅스 환경에 익숙하지 않아서 검은 터미널 화면에 빽빽하게 타이핑하며 개발하는 것에 대한 환상이 있었고, 한 번 배워보고 싶었어요. 그리고 뭔가 '진짜' 개발자처럼 보이잖아요...!

어느 날 아침 문득, 정말이지 맹세코 아무런 계시나 암시도 없었는데 불현듯, 잠에서 깨어나는 순간 나는 이렇게 부르짖었다. "그래, 이렇게 살아서는 안 돼! 내 인생에 나의 온 생애를 다 걸어야 해. 꼭 그래야만 해!"

모순, 양귀자

요 근래에 정말 재미있게 읽었던 소설의 첫 문장입니다. 글또 10기 OT가 끝나고 문득, 정말이지 맹세코 아무런 계시나 암시도 없었는데 불현듯, '그래, 이렇게 살아서는 안 돼! 내 인생에 나의 온 생애를 다 걸어야 해. 꼭 그래야만 해!'라고 생각했어요. (부르짖지는 않았음...)

처음 개발자를 꿈꾼지 5년이 지났고, 프런트엔드 개발자로 봉급을 받은지 3년이라는 시간이 지났습니다. 사랑의 유효기간은 900일[^1]이라고 하죠? 요즘은 어쩐지 프로그래머로서의 열정도 사라지고, 커리어 권태기가 온 것 같아요. 그래서 '글또 10기 시작'이라는 핑계로 제 프로그래밍 인생에 저의 온 생애를 다 걸어보자는 비장한 다짐을 해보려고 합니다. 글또는 어쩌면 프로그래머로서 열심히 살아보기 위한 수단일지도 모르겠네요😁

어제 2024 Women tech week에서 세미나를 듣고 왔습니다. '함께 그리는 커리어 성장 곡선'이라는 주제로 개발자로서의 커리어를 어떻게 쌓아나가야할지에 대한 이야기였는데 Q&A 시간에 어김없이 '비전공자도 개발자로 취업할 수 있을까요?'라는 질문이 나왔습니다.

전공자도 비전공자도 아닌 나​

저는 '디지털콘텐츠학'을 전공했습니다. 이름만으로는 정확히 어떤 전공인지 알기 쉽지 않습니다. 사실 입학할 때, 포토샵이나 프리미어로 디지털콘텐츠를 만드는 방법을 배우는 곳이겠거니 싶어서 선택했는데 실제로는 포토샵이나 프리미어 같은 프로그램을 만드는 방법을 배우는 곳이었어요😅

1~2학년 때까지는 프로그래밍은 절대 하지 말아야겠다고 생각했었고, 운영체제나 네트워크 같은 전공 필수 수업은 듣지 않았습니다. 교내 방송국에서 일하면서 영상 편집을 배웠고, 대만으로 교환학생을 가서 중국어를 배우며 이리 저리 방황했더랬습니다. 어찌저찌 개발자로 취업했지만 스스로 '전공자'라고 하기에는 부끄러운 마음이 들 때가 많습니다.

이전 글 어느 날, 회사에서 서비스 개발을 멈추기로 했다.에서는 회사에서 2개월 간 서비스 개발을 멈추고, 개발 프로세스 개선하는 TF에 참여하면서 느낀 점을 정리했습니다. TF가 마무리 되고, 회사에서 서비스 개발에 애자일 프로세스를 적용한 지 6개월이 지났습니다 6개월의 시간 동안, 1번의 마이너 업데이트와 2번의 핫픽스를 진행는데요. 이번 글에서는 제가 생각한 애자일한 조직의 모습, 조직에서 애자일 프로세스를 적용한 방법, 겪었던 시행착오 등을 기록 해보려고 합니다.

애자일 하다는 착각​

뉴로클의 개발 문화

회사 채용페이지의 개발 문화에 대한 내용은 제가 작성했는데요. 작성할 때만해도 저는 저희 조직이 애자일하게 개발하고 있다고 생각했습니다.

착각 요소​

1. 스프린트를 진행한다.
2. Jira를 사용한다.
3. 프로젝트가 끝나면 회고한다.

생각해보면 이 두 가지 요소 때문에 애자일하다고 착각하고 있었던 것 같습니다. '워터폴이 아니니까 애자일인거 아니야...?'라고 대충 생각했던 것 같아요.

우리 조직은 애자일하게 하고 있는데 기획을 수정하는 게 왜 이렇게 힘든 걸까요? 왜 개발자들이 릴리즈 날에 밤새면서 버그를 고치는 걸까요? 애자일이란 과연 무엇일까요?

회사에서는 혼자 일할 수 없다. 3~4명으로 이루어진 팀이 하나의 목표를 가지고 일하는 경우가 많다. 내가 어떤 일을 하고 싶어도, 팀원들과 협의하여 업무를 배분해야 한다. 팀은 프로젝트 초기에 업무 담당자를 배분하는데 이 때, 모두가 만족할 업무 배분의 기준을 선택하는 것은 항상 어려운 일이다.

업무 배분 기준​

1. 담당자가 이전에 담당했던 부분을 계속 개발한다.
2. 담당자가 이전에 담당하지 않았던 부분을 개발한다.

3년차 웹 프론트엔드 개발자의 흔한 데스크 셋업

2023년 12월부터 2024년 4월까지 총 5개월간의 글또 활동이 끝났습니다. 글또 9기를 마치며 5개월동안 이룬 것과 느낀 점을 정리해보고자 합니다.

글또에서 생긴 일​

옛날부터 글또의 존재를 알고 있었지만 지원서를 작성할 용기가 생기기까지는 2~3년이 걸렸습니다. 제 삶에 꾸준히 긍정적 영향을 주는 친구가 있는데 그 친구가 꽤 오래전부터 글또 활동을 하고 있었더라구요.(심지어 운영진😮!!!) 덕분에 용기내어 글또 9기 활동을 시작 할 수 있었고, 글또를 통해 많은 것을 얻었습니다. 커뮤니티의 규칙은 단순히 '2주에 한 번 글을 제출'하는 것이지만 그것보다 더 많은 것을 해낸 5개월 이라고 생각합니다.

최근 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%라는 글에 굉장히 공감했고, 이것이 비단 개발자들만의 문제는 아니라는 점도 흥미로웠습니다. 글을 소개하며 저도 지금까지 프로젝트들을 잘 마무리해왔는지 되돌아보려고 하는데요. 이 글을 읽는 분들도 하고 계신 일을 완전히 매듭짓는 데 이 글이 도움이 되었으면 좋겠습니다.