Your Site's RSS Feed

<에이전트 시대의 AI 시스템 설계> AI 실습 문제 생성은 프롬프트만 잘 쓰면 충분할까?

Sun, 24 May 2026 00:00:00 GMT

“한빛미디어 <나는 리뷰어다> 활동을 위해 도서를 제공받아 작성된 서평입니다.”

제품을 만들 때 AI로 실습 문제를 생성하는 기능을 붙인 적이 있다. 사용자의 직무, 개선하고 싶은 업무, 지금 하고 있는 일을 입력으로 받아서 그 사람의 상황에 맞는 실습 문제를 만들어주는 흐름이었다. 처음에는 프롬프트에 규칙을 잘 적어두면 어느 정도 안정적인 결과가 나올 거라고 생각했다.

그런데 실제로 만들어보니 생각보다 쉽지 않았다. 결과물이 겉으로는 문제 형식을 갖추고 있었지만, 실제 업무 상황처럼 느껴지지 않는 경우가 많았다. 실습 데이터도 부실해서 사용자가 “이걸 내 업무에서 어떻게 쓰지?”라고 느낄 만한 결과가 나왔다. 직무와 상황을 입력으로 넣었는데도, 결과물은 그 맥락을 깊게 반영하지 못했다.

그래서 계속 규칙을 고쳤다. “이런 상황을 더 구체적으로 반영해라”처럼 규칙을 자세히 쓰기도 했고, 반복해서 안 좋은 결과가 나오는 경우에는 “이런 식으로 만들면 안 된다”는 금지 규칙을 추가하기도 했다. 이 과정을 반복하면서 AI 기능은 프롬프트 한 번으로 완성되는 게 아니라, 실패 사례를 보고 규칙과 검증 기준을 계속 보강하는 운영 루프에 가깝다는 생각을 하게 됐다.

이 책 <에이전트 시대의 AI 시스템 설계>는 생성형 AI를 실제 서비스로 운영할 때 마주치는 환각, 비결정적 응답, 지식 공백, 도구 호출 실패, 비용과 지연시간, 안전장치 문제를 32가지 설계 패턴으로 다루는 책이다. 내가 겪었던 “AI가 문제는 만들지만 좋은 실습 문제는 못 만든다”는 문제도 결국 프롬프트 문장력보다 시스템 설계에 가까웠다.

인사이트 1: 좋은 문제를 만들려면 좋은 맥락이 먼저 필요하다

AI에게 직무와 상황을 넣었다고 해서 곧바로 실제 업무 같은 문제가 나오지는 않았다. “프론트엔드 개발자”, “업무 자동화를 개선하고 싶다”, “현재 이런 일을 하고 있다” 같은 정보를 줘도 결과물은 종종 일반적인 예시 문제에 머물렀다. 입력값은 구체적인데 출력은 뭉뚱그려지는 느낌이었다.

이때 아쉬웠던 건 실습 데이터였다. 실제 업무에서 다룰 법한 데이터, 제약 조건, 예외 상황, 의사결정 맥락이 있어야 문제가 살아나는데, AI가 만든 데이터는 너무 얇았다. 테이블이나 예시 값은 있지만 현업에서 마주치는 복잡함이 없었다. 그래서 학습자는 문제를 풀 수는 있어도, 그 문제가 자기 업무와 연결된다는 느낌을 받기 어려웠다.

책을 읽으면서 가장 먼저 연결된 부분도 RAG와 지식 추가였다. 기본 RAG, 의미 기반 색인화, 대규모 색인화, 신뢰할 수 있는 생성 같은 주제를 따로 다루는데, 여기서 좋았던 건 RAG를 단순히 “문서 검색 붙이기”로 설명하지 않는다는 점이었다. 내가 만들던 기능에 대입해보면, 사용자 입력 몇 개를 프롬프트에 넣는 것만으로는 부족하고, 직무별 업무 사례나 좋은 실습 데이터의 기준을 어떻게 공급할지까지 설계해야 한다는 이야기로 읽혔다.

결국 맥락은 “문장으로 설명하는 것”만으로 충분하지 않다. 좋은 실습 문제를 만들려면 사용자의 직무와 상황을 해석할 수 있는 참고 데이터, 예시, 제약 조건이 같이 들어가야 한다. 책을 읽고 나서는 내가 부족하다고 느꼈던 “실습 데이터의 부실함”도 단순 데이터 양의 문제가 아니라, 어떤 지식을 어떻게 가져오고 생성 과정에 연결할지의 문제였다는 생각이 들었다.

인사이트 2: 금지 규칙도 시스템의 일부다

실습 문제 생성에서 규칙을 추가하다 보면 자연스럽게 금지 규칙이 늘어난다. 처음에는 “직무와 레벨을 반영해라”처럼 원하는 방향을 적는다. 그런데 결과를 보다 보면 “이런 식으로 만들면 안 된다”는 조건이 더 중요해지는 순간이 생긴다. 실제 업무 상황 같지 않은 문제, 데이터가 너무 단순한 문제, 정답이 뻔한 문제, 맥락 없이 용어만 바꾼 문제 같은 것들이다.

이런 금지 규칙을 넣으면 당장은 나아진다. 하지만 금지 규칙만 계속 늘어나는 방식은 한계가 있다. 프롬프트가 길어지고, 규칙 사이의 우선순위가 애매해지고, 새로운 실패 유형이 나오면 또 규칙을 추가해야 한다. 결국 “규칙을 얼마나 많이 쓰느냐”보다 “어떤 실패를 막아야 하고, 그 실패를 어떻게 감지할 것인가”가 더 중요한 문제가 된다.

책의 후반부에는 템플릿 생성, 조립 후 재구성, 자체점검, 가드레일 같은 안전장치 패턴이 나온다. 이 부분을 읽으면서 내가 프롬프트에 계속 추가하던 금지 규칙을 조금 다르게 보게 됐다. AI가 부실한 실습 문제를 만들지 않게 하려면 단순히 “잘 만들어줘”라고 하는 게 아니라, 나쁜 결과의 유형을 정의하고 막는 장치가 필요하다.

내가 추가했던 금지 규칙은 일종의 작은 가드레일이었다. 다만 그때는 그것을 시스템 설계라고까지 생각하지 못했다. 책을 읽고 나니 금지 규칙을 프롬프트 안에 계속 쌓아두는 것보다, 템플릿, 자체점검, 평가 기준으로 분리하는 편이 더 운영 가능한 방식이라는 생각이 들었다.

인사이트 3: 퀄리티 컨트롤은 생성 이후에 더 중요해진다

실습 문제 생성에서 가장 어려웠던 건 퀄리티 컨트롤이었다. 문제를 하나 생성하는 것 자체는 어렵지 않았다. 어려운 건 그 문제가 정말 사용자의 직무와 상황에 맞는지, 실습 데이터가 충분한지, 실제 업무 상황처럼 느껴지는지 판단하는 일이었다.

처음에는 결과가 마음에 들지 않으면 프롬프트를 고쳤다. 규칙을 더 구체화하거나 금지 규칙을 추가했다. 하지만 시간이 지날수록 프롬프트를 수정하는 것만으로는 충분하지 않다는 생각이 들었다. 어떤 결과가 좋은 문제인지, 어떤 결과가 나쁜 문제인지 판단하는 기준이 더 중요했다. 기준이 없으면 매번 사람이 감으로 보고 고쳐야 한다.

이 책은 신뢰성 개선 파트에서 심판형 LLM, 성찰, 의존성 주입, 프롬프트 최적화 같은 패턴을 다룬다. 제약 조건 해결 파트에는 성능 저하 테스트도 있다. 이 부분을 읽으면서 이 책이 “생성”만이 아니라 “생성된 결과를 어떻게 믿을 것인가”를 꽤 중요하게 다룬다는 느낌을 받았다.

내 경험에 대입하면, AI가 만든 실습 문제를 다시 평가하는 단계가 필요했다. 예를 들어 “실제 업무 상황이 드러나는가”, “사용자의 입력이 문제에 반영됐는가”, “실습 데이터가 충분한가”, “금지한 유형의 문제가 나오지 않았는가” 같은 기준이다. 이 기준을 사람이 매번 감으로 보는 게 아니라, 시스템 안에 넣을 수 있어야 제품으로 안정화될 수 있다. 책에서 말하는 신뢰성 개선 패턴은 이 지점을 정리하는 데 도움이 됐다.

마무리

책을 다 읽고 나니, 이 책은 단순한 AI 입문서나 프롬프트 작성법 책과는 거리가 있었다. 생성형 AI를 실제 서비스로 운영할 때 생기는 문제를 패턴 단위로 다루는 책에 가깝다. 그래서 처음부터 끝까지 순서대로 읽는 것도 가능하지만, 지금 만들고 있는 AI 기능에서 막히는 지점을 기준으로 필요한 패턴을 찾아 읽는 방식도 잘 맞아 보였다.

내가 AI 실습 문제 생성 기능을 만들면서 겪었던 문제도 결국 같은 방향이었다. 좋은 결과가 나오지 않을 때마다 프롬프트를 고치고 규칙을 추가했지만, 더 근본적으로는 맥락 공급, 금지 규칙, 품질 평가, 검증 루프가 필요했다. 이 책을 읽으면서 그 경험을 RAG, 신뢰성 개선, 가드레일, 성능 저하 테스트 같은 패턴으로 다시 정리할 수 있었다.

AI 기능을 빠르게 만드는 단계에서는 프롬프트와 데모가 중요하다. 하지만 오래 버티는 AI 시스템을 만들려면 그 뒤의 설계가 필요하다. 특히 AI로 무언가를 생성하는 제품을 만들고 있고, “결과는 나오는데 품질이 안정적이지 않다”는 고민을 해본 사람이라면 이 책에서 연결해볼 지점이 많을 것 같다.

#한빛미디어 #나는리뷰어다 #에이전트시대의AI시스템설계 #AI시스템설계 #RAG #가드레일 #AI에이전트

더 줄일 수 있는건 없을까? <미니멀리즘 프로그래머>

Sun, 05 Apr 2026 09:04:21 GMT

“한빛미디어 <나는 리뷰어다> 활동을 위해 도서를 제공받아 작성된 서평입니다.”

인사이트 1: 비동기적인 삶

많은 팀이 이벤트 주도 시스템처럼 일한다는데 공감한다. 요즘에 B2B로 제품이 나가면서 이슈 해결을 빠르게 하려다 보니까 새로운 일이 터지면 온 신경이 거기다 쏠린다. 하지만 그 중에는 우선순위, 긴급도가 낮은 경우도 분명 있었을 것이다. 하지만 셀에서 비동기로 처리할 수 있는 일을 남겨놓는 프로세스가 부족하다는 생각이 들었다.

인사이트 2: 회의도 “복잡함”을 줄일 수 있다

코드 바깥에서 가장 인상 깊었던 부분이 여기였다. 책은 회의를 단순히 “시간 낭비”로 뭉뚱그리지 않는다. 회의는 여러 사람의 시간을 동시에 소모하는, 비용이 굉장히 큰 행위라는 시각으로 접근한다. 실제로 드는 비용을 계산해봤을 때 꽤나 컸다.

실무에서 회의 시간이 길어지는 경우가 많았다. 하지만 길어진다고 해서 회의를 마쳤을 때 상쾌한 기분이 들지도 않았다. 아무래도 셀에서 챙겨야 할 것들이 많았어서 이런저런 이야기를 하다가 흩어지는 회의들이 대부분이었다. 책을 읽고 나서는 회의 전에 “이 회의가 끝났을 때 무엇이 결정되어야 하는가”를 먼저 정의하고, 끝난 후에 실제로 그게 이뤄졌는지 확인해봐야겠다는 다짐을 하게 됐다. 코드를 단순하게 만드는 것처럼, 회의도 목적이 뚜렷할수록 비용 대비 가치가 올라간다.

또 한 가지 와닿은 포인트는, 회의는 강의 시간이 아니라는 것이다. 정보 전달을 회의 시간 안에 하려고 하면 그만큼 의사결정에 쓸 시간이 줄어든다. 읽어야 할 자료를 미리 공유하고, 회의 자리에서는 이미 자료를 읽은 사람들이 논의하고 결정하는 구조가 훨씬 효율적이다. 회의를 하기 전에 필요한 자료를 읽어보자는 요청을 해야겠다. 정보는 회의 밖에서도 자유롭게 흐를 수 있어야 한다.

인사이트 3: 주석도 관리 대상이다

요즘 코드 이해도를 높이겠다고 주석을 꽤 열심히 달고 있었다. 그런데 이 책을 읽으면서 불편한 진실 하나를 마주했다. 주석이 길어지는 순간, 그것도 코드처럼 관리해야 할 대상이 된다는 것이다. 아직까지는 기존 코드를 자주 건드리면서 주석도 함께 수정하는 경우가 많지 않았어서 이 부분은 크게 체감하지 못했다. 하지만 코드가 바뀌면 주석도 바꿔야 한다. 안 바꾸면 거짓말하는 주석이 된다. 코드는 최신인데 주석은 옛날 로직을 설명하고 있는 상황, 한 번쯤은 다들 겪어봤을 것이다. 결국 주석이 길수록 유지 비용도 그만큼 올라간다. 테스트 코드도 마찬가지라고 생각한다. 코드가 바뀌면 테스트 코드, 주석이 함께 바뀌어야 한다. 어떻게 효율적으로 관리할 수 있는지 고민이 필요하다.

책에서 강조하는 방향은 코드 자체가 의도를 드러내도록 짜는 것이다. 변수명, 함수명, 구조로 설명이 되어야 한다. 주석이 필요하다면 “왜(Why)“를 적는 것이지, “무엇을(What)“을 풀어 쓰는 게 아니다. 앞으로는 주석을 달기 전에 “이게 코드로 표현될 수 없는 내용인가”를 먼저 물어봐야겠다.

마무리

AI로 코드를 짜다보면 생각보다 복잡하고, 많은 양의 코드가 생성되는 일이 많다. 이 책을 읽고 나서 그런 복잡함을 경계하는 태도를 연습해야겠다는 생각이 들었다. 책의 분량이 많지도 않았지만 얻을 수 있는건 명확했다.

#한빛미디어 #나는리뷰어다 #미니멀리즘프로그래머

컨텍스트 엔지니어링으로 구축하는 AI 에이전트 리뷰 - 한빛미디어

Mon, 02 Mar 2026 15:30:00 GMT

출처: 한빛미디어

“한빛미디어 서평단 <나는리뷰어다> 활동을 위해 도서를 제공받아 작성된 서평입니다.”

최근 회사에서 학습 컨텐츠를 만드는 일을 하면서, 생각보다 많은 시간을 프롬프트에 쓰고 있었다. 예시 문제(원본)가 있고, 사용자의 상황(직무/레벨/목표)에 맞게 문제를 re-writing한 뒤, 정해진 JSON 스키마에 맞춰 컨텐츠를 생성해 반환하는 작업이다.

겉으로 보면 단순하다. “규칙만 잘 지키면 자동으로 안정적인 결과가 나오겠지”라고 생각했다. 근데 운영으로 들어가니 제일 곤란한 문제가 생겼다. 결과가 항상 일정하지 않다. 어떤 날은 규칙이 잘 적용되는데, 어떤 날은 규칙이 누락되는 느낌이 들었고 컨텐츠 퀄리티도 들쭉날쭉했다.

특히 제일 치명적인 건 “형식”보다 “내용”이었다. 형식은 대부분 잘 맞춰주는데 정작 사용자 맥락을 제대로 반영하지 못하는 결과가 종종 나왔다. 사용자 입장에서는 “그럴듯한 문제”가 아니라 “내 상황에 맞는 문제”가 필요한데, 그걸 놓친 결과물은 결국 내가 다시 손으로 고쳐야 했다. 그리고 특정 한두가지 property값만 기대치에 못 미치면 스트레스를 받았다.

이 책을 읽고 나서 내가 바꾼 건 프롬프트 문장력이 아니라, 컨텍스트를 다루는 방식이었다. 특히 두 가지가 결정적이었다.

강화형 컨텍스트 학습으로 “생성 후 보완” 루프를 만들기

2. re-writing 컨텍스트와 컨텐츠 생성 컨텍스트를 분리하기

문제는 ‘규칙이 부족해서’가 아니라 ‘규칙이 강화되지 않아서’였다. 규칙을 전부 적어놓긴 했지만 그럼에도 고려하지 못한 부분, 엣지 케이스들이 훨씬 많았다. 그래서 필요한 건 “처음부터 완벽한 규칙”이 아니라, 구멍을 발견하면 강화하는 게 맞아 보였다.

1. 강화형 컨텍스트 학습으로 ‘생성 후 보완’ 루프 만들기

강화형 컨텍스트 학습 플로우를 만들기 위해서 결과물을 만든 다음,그 결과물에서 “규칙을 보완할 지점”을 찾아 다음 생성에 반영해 강화했다. 그러다보니 계속 진행할수록 퀄리티가 올라갔다. 생성하고 피드백한만큼 강화되는 것이다.

2. re-writing과 컨텐츠 생성 컨텍스트를 분리하기

또 하나 크게 바꾼 건 “한 번에 다 하게 만들지 말자”였다.

이전에는 한 프롬프트 안에서 원본 예시 문제를 해석하고 사용자 맥락을 반영해 re-writing하고 JSON 스키마에 맞춰 컨텐츠를 생성하고 이 모든 걸 동시에 시켰다. 내용은 빠진 게 없었지만 AI가 한번에 하려니까 퀄리티가 잘 안 나왔다.

그래서 나는 컨텍스트를 의도적으로 두 덩어리로 분리했다.

re-writing 컨텍스트

사용자 맥락을 “어떻게” 반영할지에 집중
직무/레벨/목표를 반영하는 기준을 명시
원본 문제의 핵심을 유지하는 규칙 포함

→ 여기서 결과물은 “텍스트”다. (아직 JSON 아님)

컨텐츠 생성 컨텍스트

re-writing 결과를 입력으로 받아
JSON 스키마 준수에 집중
금지어/길이/톤 등 출력 제약을 강하게 적용

→ 여기서 결과물은 “JSON”이다.

이렇게 하니까 퀄리티가 훨씬 올라갔고 디버깅하기도 쉬워졌다. 중간단계인 re-writing 결과를 로그로 찍어보면 re-writing 단계의 문제인지, 뒷단의 문제인지 쉽게 판단할 수 있었다. 무엇보다 “사용자 맥락 반영”이 컨텐츠 생성 과정에서 묻히지 않았다. 맥락을 반영하는 일과, 형식을 맞추는 일을 분리하니 서로의 품질을 갉아먹지 않게 됐다.

마무리

이 책을 읽고 나서 내가 얻은 건 “프롬프트를 잘 쓰는 법”이 아니었다. 운영 가능한 컨텍스트 설계 방법이었다.

규칙은 한 번에 완성되지 않는다 → 강화 루프가 필요하다
한 프롬프트에 모든 걸 넣으면 흔들린다 → 컨텍스트를 분리해야 한다

기존에는 너무 사람처럼 생각했는데 이제는 AI의 입장에서 조금이나마 프롬프트를 작성할 수 있게 되지 않았나 싶다.

#한빛미디어 #나는리뷰어다 #컨텍스트엔지니어링으로구축하는AI에이전트

소프트웨어 아키텍처 The Basics(2판) 리뷰 - 한빛미디어

Sat, 31 Jan 2026 15:30:00 GMT

출처: 한빛미디어

“한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다.”

시작하며

연차가 쌓이면서 코드 외적인 것들을 자연스레 신경쓰게 된다. 슬슬 인프라쪽도 더 공부해서 팀원들 도움받지 않고 구축하고 싶었는데 “이 책이 답을 줄 수 있을까?” 기대하며 펼쳤다. 이 책의 내용은 오히려 더 베이스를 이루는 아키텍처들을 다뤘다. 그래서 책을 쭉 봤을 때 내용이 많이 어려웠다. 하지만 여러번 읽다보면 이해가 될 것이라 기대했다.

책에서 소개하는 여러 아키텍처 패턴들은 익숙한 프론트엔드 디자인 패턴과는 사뭇 다른 느낌이었다. 근데 끝까지 읽고 나니 아키텍트들이 어떤 고민을 하고, 어떤 기준으로 결정을 내리는지 조금은 이해할 수 있었다.

하지만 돌이켜 생각해봤을 때 나도 자잘하게 이런 결정들을 했었다.

개발자와 아키텍트는 뭐가 다를까

“이 함수를 어떻게 짤까?”
“어떤 라이브러리를 쓸까?”
“이 버그는 어떻게 고치지?”

책에서는 이런 고민들을 전술적(tactical) 결정이라고 불렀다.

반면 아키텍트는 전략적(strategic) 결정을 한다:

“우리 시스템에 정말 중요한 건 뭘까?”
“어떤 구조가 우리 비즈니스에 맞을까?”
“이 선택을 하면 뭘 포기해야 할까?”

아키텍트는 시스템 전체로 넓게 보는 느낌이다.

예를 들어, 내가 버튼 컴포넌트를 만들 때는 “어떻게 예쁘게 만들지”를 고민한다. 하지만 아키텍트는 “100개 넘는 버튼의 일관성을 어떻게 유지할지”, “각 팀이 독립적으로 개발하려면 어떤 구조가 필요할지”를 고민하더라.

나는 코드 한 줄에 집중하는데, 아키텍트는 시스템 전체를 본다. 줌 아웃의 정도가 다르달까. 그 간격이 생각보다 크다는 걸 이 책을 통해 체감했다.

아키텍트는 번역가다: 기술과 비즈니스 사이

책에서 가장 인상 깊었던 부분 중 하나는 아키텍트의 번역자 역할이구나 싶었다.

개발자는 “React 18로 마이그레이션해야 합니다”, “Redis 캐시를 도입하면 됩니다”처럼 기술 언어로 말한다. 하지만 경영진은 “그래서 매출이 늘어나나요?”, “비용은 얼마나 드나요?”, “언제 끝나나요?”를 궁금해한다.

아키텍트는 이 둘 사이를 연결한다.

“Redis 캐시를 도입하면 페이지 로딩 속도가 2초 빨라집니다. 이는 사용자 이탈률을 15% 줄이고, 월 매출을 약 500만원 증가시킬 수 있습니다. 초기 구축 비용은 2주, 200만원 정도 예상됩니다.”

기술적 결정을 비즈니스 가치로 변환하는 것. “좋은 코드”가 아니라 “좋은 코드가 만드는 비즈니스 임팩트”를 설명해야 한다.

나는 지금까지 “좋은 코드를 짜면 인정받는다”고 생각했다. 근데 실제로는 그 코드가 비즈니스에 어떤 영향을 주는지 설명할 수 있어야 인정받는다는 걸 깨달았다.

“컴포넌트 재사용성을 높였습니다”보다 “개발 시간을 30% 단축해서 기능 출시를 2주 앞당길 수 있습니다”가 더 설득력 있다.

책에서는 이런 소통 능력을 기술만큼이나 중요하게 다룬다. 아무리 좋은 아키텍처를 설계해도, 이해관계자를 설득하지 못하면 실행할 수 없기 때문이다.

실제 회사에서도 기술스택 변경 마이그레이션을 하려고 C레벨을 설득해야 했을 때가 있었는데, 이런 경험을 바탕으로 이해가 됐고 이것은 단순 아키텍트만이 아니라 개발자들도 갈고 닦아야 하는 능력이었다.

모든 결정은 트레이드오프다

책을 읽으면서 계속 “응, 그렇지” 하게 되더라. 책에서 가장 많이 나온 단어가 트레이드오프. 모든 걸 다 잘할 수는 없다.

성능을 올리려면? 코드가 복잡해진다. 보안을 강화하면? 개발 속도가 느려진다. 처음부터 확장 가능하게 만들려면? 초기 비용이 크다. 유연한 구조를 만들려면? 단순함을 포기해야 한다.

항상 뭔가를 포기해야 한다는 걸 머리로는 알았는데, 이렇게 명시적으로 정리해주니까 속이 시원했다.

프론트엔드로 예를 들면, SSR을 도입하면 초기 로딩은 빨라지지만 서버 비용이 증가하고 배포가 복잡해진다. 타입스크립트를 쓰면 안정성은 높아지지만 초기 러닝커브와 설정 비용이 든다.

아키텍트는 “무엇이 우리에게 가장 중요한가?”를 먼저 정한다. 그리고 나머지는 어느 정도 포기한다.

이커머스 사이트라면 성능이 최우선일 수 있다. 0.1초 지연이 매출에 직접 영향을 주니까. 반면 내부 관리 도구라면 빠른 개발과 유지보수성이 더 중요할 수 있다.

완벽은 없다. 그때그때 최선이 있을 뿐이다. 이 문장이 책 전체를 관통하는 메시지라고 생각한다.

기술보다 중요한 것: 소프트 스킬

이 책에서도 소프트 스킬을 강조한다. 아무리 좋은 아키텍처를 설계해도, PM을 설득하지 못하면 실행할 수 없다. CEO에게 비즈니스 가치를 설명하지 못하면 예산을 못 받는다. 팀원들의 협조를 얻지 못하면 혼자 고군분투하다 끝난다.

특히 기억에 남는 건 트레이드오프를 설명하는 법이다. “모든 기능 다 넣어야 해요!”라고 할 때, “안 됩니다”가 아니라 “A를 선택하면 B를 포기해야 하는데, 어떻게 할까요?”처럼 현실적인 대안을 제시하는 것이다. 무조건 받아들이는 것도, 무조건 거절하는 것도 아니고, 함께 최선을 찾아가는 거다.

이런 능력은 지금도, 시니어가 되어서도 계속 필요할 것 같다.

실용적인 조언들

이 책에서 설명하는 20분 규칙은 하루에 딱 20분만 투자해서 새로운 기술들을 훑어보고 판단하는 것이다.

프론트엔드는 트렌드가 빠르게 바뀌니까, 모든 걸 다 깊게 공부할 수는 없다. 하지만 완전히 무시하기도 찝찝하다. 20분 규칙은 그 중간 지점을 찾는 현실적인 방법이다.

또 하나는 생성형 AI 시대의 개발자 역할에 대한 내용이다. AI가 코드를 짜주는 시대지만, “어디에 어떤 코드를 둘지”, “어떤 구조가 맞는지”, “무엇을 포기하고 무엇을 선택할지”는 여전히 사람이 결정해야 한다.

마무리

지금은 컴포넌트나 함수 레벨에서 고민하지만, 점점 더 시스템 전체를 설계하는 쪽으로 생각하려고 한다.

그때 이 책에서 배운 것들이 도움이 될 것 같다. 특히 **“정답은 없다. 항상 트레이드오프다. 그때그때 최선을 찾는 거다”**라는 생각. 완벽을 추구하다가 아무것도 못 하는 것보다, 그때의 최선을 선택하고 나중에 개선하는 게 낫다. 이게 아키텍처의 본질인 것 같다.

어려운 책이었지만, 읽길 잘했다고 생각한다. 읽다보면 더 디테일한 내용들도 이해될 것 같다.

다음 단계로 성장하기 위한 준비를 조금은 한 것 같다.

GitKraken에서 AI로 merge conflict 쉽게 해결하기

Fri, 05 Dec 2025 23:13:29 GMT

브랜치를 머지하려는데 conflict가 발생하면 막막한 경우가 많습니다. 보통 팀원들의 작업과 충돌하는 경우가 많아서 해결하기 어려운 경우가 많습니다. 많이 조심스럽기도 하구요. 심지어 비슷한 라인을 건드리면 더 막막해집니다. 보통의 경우 동료를 소환해서 같이 보면서 해결하는 경우가 많았습니다. 그렇게 하는 편이 정확도가 높았습니다. 언제나 빠르게 같이 보고 해결할 수 있다면 좋겠지만, 동료가 부재중이거나 바쁜 경우에는 작업을 이어나가기가 힘들었습니다. 그래서 요즘에는 제가 자주 사용하는 Git GUI 툴인 GitKraken Desktop에서 AI가 merge conflict를 분석해서 해결 방법을 제안해주는 기능을 애용하고 있습니다. 써보니까 이 과정이 정말 많이 편해져서 경험을 공유해보려고 합니다.

GitKraken AI가 제안하는 해결책

GitKraken을 사용하고 있다면 별다른 설정없이 해당 기능을 사용할 수 있습니다. 이해를 돕기 위해 GitKraken youtube에서 해당 기능을 설명하는 영상을 캡쳐해봤습니다.

충돌이 발생하면 GitKraken AI가 양쪽 변경 내역을 분석해서 어떻게 해결하면 좋을지 제안해줍니다. 단순히 “이쪽 선택하세요”가 아니라, 각 선택지가 정답일 확률(Confidence)를 수치로 함께 제시합니다. 그래서 단순히 AI의 선택에 맡기는 것이 아니라 개발자가 납득할 수 있고, 최종적으로 결정할 수 있도록 도와줍니다.

정확도가 올라갔습니다

혼자서 merge conflict를 해결할 때 한번에 완벽하게 해결되는 경우는 드물었습니다. 해결하고 나서 개발 환경에서 다시 살펴보면서 빠진 부분은 없는지, 잘못 들어간 부분은 없는지를 다시 체크하는 경우가 많았습니다. 하지만 AI의 도움을 받았을 때는 시행착오가 적었고 병합 과정에서 의사 결정에 도움을 많이 받기 때문에 더 정확하게 해결할 수 있었습니다.

동료를 덜 부르게 됐습니다

이 기능을 쓰면서 제일 좋았던 건, 혼자 해결할 수 있는 충돌의 범위가 확실히 넓어졌다는 것입니다. 동료가 부재중일 때도 혼자서 conflict를 해결할 수 있게 됐습니다. 맥락 파악 시간을 줄임과 동시에 AI의 코멘트를 읽으면서 공부하는 기회가 되기도 했습니다.

결론

저번에는 AI의 도움을 받아 커밋 메시지를 작성하는 GitKraken의 기능을 사용해봤는데, 이번에는 AI의 도움을 받아 merge conflict를 해결하는 기능을 사용해봤습니다. 이렇게 GitKraken이 유저들에게 필요한 기능이 뭔지 고민하고 빠르게 도입해보는 모습이 보기 좋았습니다. 이런 도구들이 개발자들의 일상적인 고민을 해결해주는 모습을 보면서, 정말 개발 환경이 많이 좋아졌다는 생각이 듭니다. 혹시 GitKraken을 아직 사용해보지 않으셨다면, 한 번 체험해보시는 것도 좋을 것 같아요.

아래 링크를 사용하시면 GitKraken Pro를 50% 할인된 가격에 구독하실 수 있습니다.
프로모션 링크

바이브코딩 너머 개발자 생존법(한빛미디어) 도서 리뷰

Sat, 29 Nov 2025 20:11:52 GMT

“한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다.”

왜 이 책을 집었는가 – “AI를 잘 쓰고 있는 게 맞을까?”

저는 6년차 웹 프론트엔드 개발자이자 한 제품개발 셀의 리드입니다. 이미 팀에서 AI를 꽤 쓰고 있고, 저도 업무 중에 자연스럽게 AI를 켜놓고 개발하는 편입니다. 덕분에 생산성이 많이 올라갔습니다. 코드 생성 속도가 빨라져서 AI없이는 지키기 힘든 일정으로 제품을 개발할 수 있게 됐고 문서화에 도움을 받기도 합니다. 또한 테스트 코드를 작성하기도 수월해져서 코드 안정성도 많이 올라가고 있습니다. 이렇게 AI를 활용하고 있지만 더 잘 활용할 수 있을까 하는 기대감에 이 책을 읽어보기로 했습니다.

책을 읽어봤을 때 이 책은 “AI 입문자”에게는 좋은 네비게이션이 되고, “이미 쓰고 있는 사람”에게는 브레이크와 안전벨트를 다시 달아주는 느낌에 가깝습니다.

이 책이 던진 핵심 메시지: “AI가 짠 코드는 끝이 아니라 시작이다.”

책을 읽으면서 가장 많이 반복해서 느낀 키워드는 두 가지였습니다.

검증
소화

AI가 코드를 만들어주는 건 이제 너무 자연스러운 일이 됐는데, 이 책은 그다음 단계를 집요하게 묻습니다.

그 코드가 정말 문제를 해결하고 있는지
기존 시스템/아키텍처와 정합성이 맞는지
보안/성능/장기 유지보수 관점에서 괜찮은 선택인지

즉, AI가 만들어 준 코드는 결과물이 아니라 일종의 초안이고, 그걸 검증하고, 맥락 안에 끌어와서 소화하는 과정이 바로 개발자의 역할이라는 메시지를 강하게 던집니다. 그리고 AI를 활용하는 것은 사람을 대체하는게 아니라 AI의 도움을 받아 생산성을 증폭시킨다는 AI와 함께 코딩한다는 메시지에 깊이 공감했습니다.

부트스트래퍼 마인드셋 – “가설 검증을 위해 빠르게 만들어보자”

이 책에서 특히 재미있게 읽었던 부분이 ‘부트스트래퍼’ 방식의 개발을 강조하는 대목입니다. 최근에 회사의 대표님께서 강조하셔서 셀에서도 실험적으로 도입해본 방식이었는데 상당히 효과가 좋았습니다. 셀 구성원들이 직군 상관없이 가설을 세우고 검증하기 위해 각자의 프로토타입을 AI로 제작해서 빠르게 피드백을 받는 방식이었고 사내 구성원들에게 공유할 때도 반응이 좋았습니다.

여기서 말하는 부트스트래퍼는:

완벽한 제품을 만드는 사람이 아니라
가설을 검증하기 위해 빠르게 프로토타입을 만드는 사람

에 가깝습니다.

AI와 이 마인드셋이 만나면 워크플로가 이렇게 바뀝니다.

비즈니스/제품 가설을 명확히 적습니다.
그 가설을 검증하기 위한 최소한의 기능을 정합니다.
AI를 활용해 프로토타입 코드를 빠르게 만듭니다.
직접 코드 검증/리팩터링을 해서 “대충 굴러가지만 이해는 되는 상태”까지 끌어올립니다.
실제 사용자나 이해관계자에게 보여주고, 다음 가설/다음 실험으로 넘어갑니다.

실무에 적용해볼만한 점들

먼저 문서를 항상 남겨야겠다는 생각을 하고 있었는데 책을 읽고 나서 확실히 도움이 될 것이라는 생각이 들었습니다. 보통의 경우 작은 기능 단위로 AI를 활용해서 개발했고 리팩토링도 했기 때문에 그 내역을 문서화하진 않았습니다. 하지만 나중에 작업을 이어서하고 싶을 때 컨텍스트를 다시 주입해줘야 하는 문제가 생겼습니다. 문서로 작업 내역과 의사 결정 과정, 결과를 문서화하면 다음에 이어서 작업하는데 도움이 되고 코드를 이해하는데에도 많은 도움이 되었습니다.

“AI가 개발자를 대체할까?”에서 “AI와 함께 어떻게 일할까?”로

“AI와 함께 일하는 개발자는 무엇을 책임져야 할까?”라는 질문이 이 책을 관통하는 것 같습니다. AI가 짠 코드는 결과물이 아니라 일종의 초안이고, 그걸 검증하고, 맥락 안에 끌어와서 소화하는 과정이 바로 개발자의 역할이라는 메시지를 강하게 던집니다. AI를 활용하는데 있어 좋은 가이드라인이 되었습니다.

밑바닥부터 시작하는 웹 브라우저(한빛미디어) 도서 리뷰

Sun, 26 Oct 2025 19:10:35 GMT

“한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다.”

시작에 앞서

웹 개발자라면 한 번쯤 “브라우저는 내부에서 어떤 과정을 거쳐 페이지를 띄우는 걸까?”라는 궁금증을 가져보셨을 겁니다. 저도 브라우저를 언젠가 더 공부해봐야지 생각하고 있었는데 마침 그럴 기회가 생겼습니다. 밑바닥부터 시작하는 웹 브라우저는 단순히 원리를 설명하는 데 그치지 않고, 브라우저의 핵심 기능을 직접 구현해보며 동작 원리를 체득하는 과정에 초점을 맞춥니다. 무언가를 배우는 가장 좋은 방법은 직접 해보는 것이라는 말이 있는 것처럼 이 책을 통해 브라우저의 동작 원리를 직접 구현해보며 이해할 수 있었습니다.

챕터별 내용 요약

PROLOGUE 브라우저와 나

브라우저의 기본 개념과 이 책에서 구현할 브라우저의 전체적인 구조를 소개합니다.

PART 1 페이지 로딩

CHAPTER 1 웹페이지 다운로드

HTTP 프로토콜을 통한 서버 연결과 데이터 다운로드 과정을 구현합니다. TCP 소켓 연결, HTTP 요청/응답 처리, HTTPS 암호화 연결까지 다룹니다.

CHAPTER 2 화면에 그리기

tkinter를 이용해 브라우저 창을 만들고 기본적인 그래픽 렌더링을 구현합니다. 텍스트 배치, 스크롤 기능, 렌더링 최적화 기법을 학습합니다.

CHAPTER 3 텍스트 포맷팅하기

폰트의 기본 개념부터 시작해 텍스트 측정, 스타일링, 레이아웃 객체 설계까지 텍스트 렌더링의 모든 과정을 구현합니다.

PART 2 문서 표시

CHAPTER 4 문서 트리 구축하기

HTML 파싱을 통해 DOM 트리를 구축하는 과정을 구현합니다. 파서 디버깅, 셀프 클로징 태그 처리, 오류 처리까지 다룹니다.

CHAPTER 5 페이지 레이아웃

렌더 트리와 레이아웃 계산 과정을 구현합니다. 블록 레이아웃, 크기/위치 계산, 재귀 페인팅, 배경 그리기까지 다룹니다.

CHAPTER 6 개발자 스타일 적용하기

CSS 파싱과 스타일 적용 과정을 구현합니다. 셀렉터 매칭, 캐스케이딩, 스타일 상속, 폰트 프로퍼티 처리까지 다룹니다.

CHAPTER 7 버튼과 링크 처리하기

인터랙티브 요소들의 처리 방법을 구현합니다. 링크 처리, 클릭 이벤트, 탭 브라우징, 히스토리 탐색, URL 입력까지 다룹니다.

PART 3 애플리케이션 실행

CHAPTER 8 서버로 정보 보내기

HTML 폼의 동작 원리와 서버로 데이터를 전송하는 과정을 구현합니다. 폼 요소 렌더링, 상호작용, POST 요청 처리까지 다룹니다.

CHAPTER 9 대화형 스크립트 실행하기

DukPy 자바스크립트 엔진을 이용해 JS 코드 실행 환경을 구현합니다. 브라우저 API 노출, 이벤트 처리, DOM 조작까지 다룹니다.

CHAPTER 10 사용자 데이터 보호하기

웹 보안의 핵심 개념들을 구현합니다. 쿠키, 인증 시스템, CORS, Same-Origin Policy, CSRF/XSS 방어, CSP까지 다룹니다.

PART 4 모던 브라우저 기능

CHAPTER 11 시각적 효과

Skia와 SDL을 이용한 하드웨어 가속 그래픽 렌더링을 구현합니다. 컴포지팅, 투명도, 블렌딩, 마스킹까지 다룹니다.

CHAPTER 12 태스크와 스레드 스케줄링

비동기 작업 관리와 멀티스레딩을 구현합니다. 태스크 큐, 타이머, 렌더링 주기, 성능 최적화까지 다룹니다.

CHAPTER 13 애니메이션과 컴포지팅

GPU 가속 애니메이션과 컴포지팅을 구현합니다. JS 애니메이션, CSS 트랜지션, 컴포지팅 최적화까지 다룹니다.

CHAPTER 14 콘텐츠 접근성 향상

웹 접근성 기능들을 구현합니다. 줌, 다크 모드, 키보드 내비게이션, 스크린 리더 지원까지 다룹니다.

CHAPTER 15 삽입된 콘텐츠 지원

이미지와 iframe 등 복잡한 콘텐츠를 처리합니다. 이미지 렌더링, iframe 통신, 보안 고려사항까지 다룹니다.

CHAPTER 16 이전 결과 재사용

렌더링 성능 최적화를 위한 캐싱과 무효화 전략을 구현합니다. 의존성 관리, 캐시 무효화, 불필요한 재계산 방지까지 다룹니다.

CHAPTER 17 이 책에서 다루지 않은 내용

현대 브라우저의 고급 기능들과 향후 학습 방향을 제시합니다.

EPILOGUE 변화하는 환경

웹 기술의 발전과 브라우저의 미래에 대한 전망을 다룹니다.

입력에서 렌더링까지, 브라우저의 모든 여정

이 책은 사용자가 주소창에 URL을 입력한 순간부터 화면에 결과가 그려지기까지의 전체 과정을 코드와 함께 따라갑니다.

Part 1에서는 DNS, HTTP, TLS 등 네트워크 단계에서 실제 요청과 응답이 어떻게 이루어지는지를 다룹니다.
Part 2에서는 HTML 파싱, DOM 트리 생성, CSS 스타일 적용, 레이아웃 계산과 같은 렌더링 파이프라인을 구현합니다.
Part 3~4에서는 자바스크립트 실행, 이벤트 처리, 폼 제출, 스레드 및 GPU 가속 등 현대 브라우저의 복잡한 동작까지 확장합니다.

직접 만드는 브라우저 – 실습 중심 학습

이 책의 가장 큰 매력은 파이썬으로 브라우저를 한 줄씩 구현해 나가는 구성입니다. 단순히 설명을 읽는 것이 아니라, 직접 코드를 작성해 실행하면서 “내가 만든 프로그램이 웹페이지를 띄운다”는 감각을 얻을 수 있습니다.

특히 프론트엔드 개발자에게는 “렌더링 과정의 원리”를 실감나게 이해할 수 있는 실습 경험이 될 것입니다. 렌더링 속도나 레이아웃 변화 같은 현상을 단순히 ‘느낌’으로 접근하는 대신, 그 근거를 브라우저 내부 구조에서 찾아볼 수 있게 됩니다.

처음엔 간단한 글자들을 렌더링하는 것부터 렌더 트리를 구축하고 레이아웃, 스타일을 적용하는 등 점진적으로 브라우저의 기능들을 하나씩 구현해 나가는 구성이 좋았습니다. 이 과정을 직접 구현해보며, “웹 브라우저가 화면을 만드는 과정이 얼마나 세밀한 설계 위에 있는지”를 몸소 경험할 수 있습니다.

그리고 연습 문제를 통해서 책에서 구현한 부분에서 더 나아가 도전적인 기능들을 구현해 볼 수 있는 기회를 제공합니다.

커밋 메시지가 고민일 때 GitKraken이 대신 써줍니다

Sun, 21 Sep 2025 11:10:10 GMT

코드를 다 짜놓고 git commit을 치려는데… 커서 앞에서 멍하니 멈춘 적, 다들 있지 않나요?

컨벤션에 맞게 prefix를 정하려고 하는데 이것도 맞는 것 같고 저것도 맞는 것 같고 애매한 경우도 있었고 커밋 제목을 깔끔하게 정리하고 싶은데 주저리 적는 것 같고 그랬던 적이 있어요. 요즘에 AI가 있어서 편해졌다지만 AI에게 물어보려면 제 작업 내역을 전달해야 하는데 방법도 마땅치가 않았구요. 제가 주로 사용하고 있는 Git GUI 툴인 GitKraken에서 AI가 커밋 메시지를 자동으로 생성해 주는 기능이 생겨서 써 본 경험을 공유해요.

GitKraken AI가 제시한 새로운 해법

GitKraken Desktop을 애용하고 있었는데 언제부턴가 Commit summary 옆에 마법이 일어날 것 같은 버튼이 생겼어요.

GitKraken이 제가 바꾼 코드를 분석해서 자동으로 메시지를 제안해 줬어요. “오, 이거 괜찮은데?” 싶은 순간이었어요. 고민 없이 메시지가 툭 나오니까 확실히 편했어요.

커스텀 지침 설정

하지만 한 가지 문제가 있었어요. 일단 영어로 나왔고 AI는 저희 회사의 커밋 컨벤션을 모르니까 feat:, fix: 같은 prefix를 붙여주지 않았어요. 하지만 분명히 커스텀 지침을 설정할 수 있을 거라고 생각해서 설정 화면을 찾아보다가 관련 기능을 발견했어요.

회사의 커밋 컨벤션과 함께

한글로 작성하기
prefix의 맨 앞글자는 소문자로 작성하기

를 instruction에 추가했더니 이젠 마치 제가 작성한 것처럼 잘 뽑아줬어요.

핵심은 “작성”이 아닌 “검토”

AI 커밋 메시지 생성 기능을 사용하면서 깨달은 점이 있습니다. 이 기능은 개발자를 대신하는 게 아니라, 개발자가 뇌정지하지 않게 도와주는 도구라는 것입니다. 어떻게 써야 할지 모르겠을 때도 물론 사용하겠지만 나는 이렇게 메시지를 작성했는데 AI라면 어떻게 작성했을까? 궁금할 때도 비교하는 용도로 사용하고 있어요. 실제로 비교해보면서 사고가 확장되는 경험도 많이 했어요.

유저 친화적인 GitKraken의 빠른 변화

GitKraken을 오랫동안 사용했던 유저로서, 계속해서 업데이트하고 AI 기능을 실험적으로 시도하고 있는 부분들이 굉장히 긍정적이었어요. 이런 도구들이 개발자들의 일상적인 고민을 해결해주는 모습을 보면서, 정말 개발 환경이 많이 좋아졌다는 생각이 들어요. 혹시 GitKraken을 아직 사용해보지 않으셨다면, 한 번 체험해보시는 것도 좋을 것 같아요.

아래 링크를 사용하시면 GitKraken Pro를 50% 할인된 가격에 구독하실 수 있어요.
프로모션 링크

타입스크립트(TypeScript)로 에러 핸들링하기

Thu, 07 Aug 2025 22:08:50 GMT

기존에 try catch 문으로 에러를 처리하던 방식을 벗어나 타입스크립트로 에러를 처리해봤습니다. 에러 타입이 명확해지니 코드가 훨씬 명확해졌습니다.

1. 에러의 종류: 예상된 비즈니스 에러 vs. 예상치 못한 에러

에러 핸들링 전략을 수립하기 전에, 에러를 두 가지 주요 유형으로 구분하는 것이 매우 유용했습니다.

예상된 비즈니스 에러 (Expected Business Errors): 시스템의 정상적인 운영 과정에서 발생할 수 있는 에러입니다. 예를 들어, 사용자 등록 시 이미 존재하는 사용자 이름을 입력하거나, 유효하지 않은 입력 값을 제출하는 경우 등이 있습니다. 이러한 에러는 사용자에게 명확한 피드백을 제공하고, 경우에 따라 사용자가 직접 문제를 해결할 수 있도록 안내해야 합니다.
예상치 못한 에러 (Unexpected Errors): 시스템의 정상적인 작동 중에는 발생하지 않을 것으로 예상되는 에러입니다. 데이터베이스 연결 실패, 서버 내부 로직 오류, 외부 API 호출 실패 등이 여기에 해당합니다. 이러한 에러는 일반적으로 복구하기 어렵고, 개발자에게 알림을 보내고 로그를 기록하는 것이 주된 처리 방법이 됩니다.

어떤 에러가 예상된 에러이고 예상치 못한 에러인지는 애플리케이션의 도메인과 비즈니스 로직에 따라 달라질 수 있습니다.

2. 전통적인 `try...catch`와 `throw`의 기본과 한계

JavaScript에서 에러를 발생시키고 처리하는 가장 기본적인 방법은 throw와 try...catch 문입니다.

// 에러 발생시키기 (throw)
function getUser(id: string) {
  const user = findUserById(id)
  if (!user) {
    throw new Error(`User with id ${id} not found`) // 수동으로 에러 발생
  }
  return user
}

// 에러 잡기 (try...catch)
try {
  const user = getUser('123')
  console.log(user.name)
} catch (error) {
  console.error('An error occurred:', error)
}

`unknown` 타입 에러와 타입 좁히기

TypeScript에서 catch 블록의 error 변수는 기본적으로 unknown 타입입니다. 이는 JavaScript에서 문자열, 숫자, 객체 등 어떤 것이든 throw될 수 있기 때문입니다. unknown 타입의 에러를 다루기 위해서는 해당 에러의 타입을 명확히 좁혀야 합니다. instanceof 연산자를 사용하여 에러의 타입을 좁힐 수 있습니다.

try {
  // ...
} catch (error) {
  if (error instanceof Error) {
    // Error 인스턴스인지 확인하여 타입 좁히기
    console.error('Error message:', error.message)
  } else {
    console.error('An unknown error occurred:', error)
  }
}

`throw`의 한계

throw와 try...catch는 간단하지만 몇 가지 한계가 있습니다.

모든 가능한 에러에 대한 지식 요구: 함수가 어떤 에러를 던질 수 있는지 파악하려면 해당 함수와 그 함수가 호출하는 모든 함수를 검사해야 합니다. 이는 문서화가 최신 상태로 유지되지 않으면 파악하기 어렵습니다.
제어 흐름의 불연속성: throw가 발생하면 코드의 제어 흐름이 예측하기 어렵게 “점프”합니다. 코드를 읽는 사람이 throw 문을 만났을 때 해당 에러가 어디서 처리될지 (또는 처리될지 여부) 파악하기 어렵습니다.

3. 객체 지향적 접근: 커스텀 에러 클래스 활용

unknown 타입 에러 문제를 해결하고 에러를 더 구조적으로 관리하기 위해 커스텀 에러 클래스를 정의하는 디자인 패턴이 유용합니다.

커스텀 에러 타입 생성: Error 객체를 확장하는 클래스를 정의합니다. 이 클래스는 스택 트레이스를 포함할 수 있게 해줍니다. 에러 이름에 대한 유니온 타입을 유지하여 타입 안전성과 자동 완성을 제공할 수 있습니다.

// errors.ts
type ProjectErrorName = 'PROJECT_LIMIT_REACHED' | 'PROJECT_NOT_FOUND'

export class ProjectError extends Error {
  constructor(public name: ProjectErrorName, message?: string) {
    super(message)
    Object.setPrototypeOf(this, ProjectError.prototype) // 상속 체인 유지
  }
}

커스텀 에러 던지기: 새로운 커스텀 에러를 인스턴스화할 때, 정의된 유니온 타입 내에서 name 값을 선택할 수 있습니다.

function createProject(userId: string, projectName: string) {
  if (getUserProjectCount(userId) >= MAX_PROJECT_LIMIT) {
    throw new ProjectError(
      'PROJECT_LIMIT_REACHED',
      '프로젝트 생성 한도에 도달했습니다.'
    )
  }
  // ... 프로젝트 생성 로직
}

커스텀 에러 잡기: catch 블록에서 instanceof를 사용하여 커스텀 에러 타입을 좁힐 수 있습니다. 에러가 좁혀지면 error.name을 통해 특정 에러에 대한 로직을 수행할 수 있습니다.

try {
  createProject('user123', 'My New Project')
} catch (error) {
  if (error instanceof ProjectError) {
    if (error.name === 'PROJECT_LIMIT_REACHED') {
      console.error('사용자에게 메시지 표시:', error.message)
    } else if (error.name === 'PROJECT_NOT_FOUND') {
      console.error('프로젝트를 찾을 수 없습니다.')
    }
  } else if (error instanceof Error) {
    console.error('일반 에러:', error.message)
  } else {
    console.error('알 수 없는 에러:', error)
  }
}

재사용 가능한 에러 베이스 만들기: 여러 도메인에서 커스텀 에러 클래스를 사용해야 할 경우, DRY(Don’t Repeat Yourself) 원칙을 위해 제네릭을 사용하는 ErrorBase 클래스를 만들 수 있습니다.

// base-error.ts
export class ErrorBase<T extends string> extends Error {
  constructor(public name: T, message?: string) {
    super(message)
    Object.setPrototypeOf(this, new.target.prototype)
  }
}

// project-errors.ts
type ProjectErrorName = 'PROJECT_LIMIT_REACHED' | 'PROJECT_NOT_FOUND'
export class ProjectError extends ErrorBase<ProjectErrorName> {}

4. 함수형 접근: `Result` 타입 패턴

throw 방식의 한계를 극복하기 위해 함수형 프로그래밍에서 영감을 받은 Result 타입을 사용하는 방법이 있습니다. 이 접근 방식은 함수가 에러를 발생시킬 수 있다는 사실을 반환 타입에 명시적으로 인코딩합니다.

`Result<T, E>` 타입의 개념

Result 타입은 성공적인 값(T) 또는 에러 값(E) 중 하나를 포함할 수 있는 공용체(discriminated union)입니다.

type Result<T, E> =
  | { result: 'success'; value: T }
  | { result: 'error'; error: E }

function createUser(newUser: NewUser): Result<User, Error> {
  if (Math.random() > 0.5) {
    return { result: 'success', value: newUser }
  } else {
    return { result: 'error', error: new Error('Username already taken') }
  }
}

// 호출 코드
const userResult = createUser({ username: 'hunter2' })

if (userResult.result === 'error') {
  console.error(`Failed to create user: ${userResult.error.message}`)
} else {
  console.log(`User created: ${userResult.value.username}`)
}

이 방식은 함수가 반환할 수 있는 모든 에러를 명시적으로 선언하므로, 호출하는 쪽에서 어떤 에러를 처리해야 하는지 쉽게 알 수 있습니다. 또한, 제어 흐름이 순차적으로 진행되어 코드 가독성이 향상됩니다.

함수형 접근을 하니 예상된 비즈니스 에러를 핸들링하기 수월해졌고 catch 절에서는 여전히 예상치 못한 에러를 처리할 수 있어서 컨텍스트를 분리해서 생각할 수 있었습니다.

엔지니어링 리더십 – 실력 있는 개발자에서 조직적 영향력자로 성장하기까지

Fri, 30 May 2025 21:06:25 GMT

“한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다.”

시니어 개발자라면 누구나 한번쯤 고민한다. “다음 단계는 무엇인가?”

윌 라슨의 『엔지니어링 리더십』은 그 질문에 조직적 영향력과 기술적 전략을 통해 답한다. 스태프 엔지니어의 역할을 다루는 이 책은, 특히 다음 세 가지 주제를 깊이 있고 현실감 있게 다룬다:

엔지니어링 전략 세우기
리더십 스타일 개발하기
우선순위와 에너지 관리하기

이 리뷰는 이 세 가지 관점에 집중해, 실제 실무에 어떤 통찰을 줄 수 있는지 살펴본다.

엔지니어링 전략 수립: 실행 가능한 기술 방향을 설계하라

『엔지니어링 리더십』은 전략을 ‘문서화된 방향성’이 아니라, 조직이 실제로 따라가고 싶은 기술적 경로로 정의한다.

단순히 기술 스택을 정하는 것이 아니라, **“우리가 왜 이 방향으로 가야 하는가”**를 팀 전체가 이해하고 납득하도록 만드는 것이 핵심이다.

“전략 없는 엔지니어링은, 구현만 있고 목적이 없다.”

전략은 기술적 선택뿐 아니라, 리소스 분배, 기술 부채 관리, 아키텍처 결정까지 관통한다. 나는 이 부분을 읽고 나서 팀에 ‘기술 투자 우선순위 문서’를 만들어서, 리팩터링과 신기능 사이의 판단 기준을 명확히 하기 시작했다.

실제로 이 문서 덕분에 팀 내에서 “이번 스프린트에 리팩터링을 할까, 신기능을 만들까?”라는 논의가 훨씬 구체적이고 생산적으로 바뀌었다. 단순히 개발자의 취향이나 그때그때 상황에 따라 결정하는 게 아니라, 명확한 기준에 따라 판단할 수 있게 된 것이다.

리더십 스타일 개발: 복제 가능한 리더가 되지 마라

책에서 특히 인상적인 점은, **‘리더십은 따라 하는 게 아니라 구축하는 것’**이라는 메시지다.

각자의 리더십은 자신이 만든 성공 경험, 성격, 신념에서 나온다. 그래서 책은 이렇게 묻는다:

당신은 결정을 빠르게 내리는 타입인가?
조율과 설득에 강점을 두는가?
문제 해결에 열정을 가지는가?

“당신의 리더십 스타일은, 당신이 꾸준히 반복한 선택들의 결과다.”

이 말은 마치 코딩 스타일을 정립하는 것처럼, 리더십도 자기화해야 지속 가능하다는 통찰을 준다.

나는 이걸 계기로, 의견 충돌 시 나의 접근 방식, 회고 작성 방식, PR 리뷰 피드백 스타일 등을 분석해서 **‘내가 지향하는 리더십 톤’**을 정리해봤다.

예를 들어, 나는 직접적인 피드백보다는 질문을 통해 상대방이 스스로 답을 찾도록 유도하는 편이라는 걸 깨달았다. “이 코드가 문제야”라고 말하기보다는 “이 부분에서 예상되는 시나리오는 뭐가 있을까?”라고 묻는 식으로 말이다. 이런 패턴을 의식적으로 정리하니, 팀 커뮤니케이션이 훨씬 일관되고 예측 가능해졌다.

우선순위와 에너지 관리: 임팩트 있는 것에 집중하라

성장할수록 일이 많아지는 게 아니라, 집중해야 할 일이 명확해진다.

이 책은 단순한 할 일 관리보다 훨씬 높은 수준의 메타인지 전략을 다룬다.

“모든 기술 과제를 처리할 수는 없다. 처리할 가치가 있는 일을 선택하는 것이 리더십이다.”

책은 우선순위를 ‘비용 대비 가치’로 판단하라고 말하지 않는다. 오히려 조직이 가장 아파하는 지점을 식별하고, 거기에 기술적 해법을 던질 수 있는 역량을 강조한다. 이를 위해선 자기 에너지를 어디에 쓸지 먼저 정해야 한다는 것이다.

나 역시 업무량이 과중했던 시기에, ‘조직 전체가 겪는 병목을 해결하면 내 시간도 줄어든다’는 인식 전환으로 릴리즈 자동화 파이프라인을 먼저 개선했다.

당시에는 매번 배포할 때마다 개발자들이 수동으로 체크리스트를 확인하고, 슬랙에서 “배포 시작합니다”, “배포 완료했습니다” 메시지를 주고받았다. 하루에 3-4번씩 이런 과정을 반복하다 보니 정작 개발에 집중할 시간이 부족했다.

자동화 파이프라인을 구축한 후에는 팀 전체의 생산성이 눈에 띄게 올라갔고, 결과적으로 내 업무 부담도 크게 줄었다. 이 책은 그런 시야의 전환을 도와준다.

총평: 직급이 아닌 전략으로 리드하라

『엔지니어링 리더십』은 단순한 직책이 아니라, 기술적 영향력의 디자인 방법을 알려주는 책이다.

스태프 엔지니어라는 포지션을 빌려, 어떻게 전략적으로 사고하고, 자기 리더십을 정의하고, 에너지를 임팩트 있게 배분할 수 있는지를 정제된 언어로 전달한다.

특히 이 책이 좋은 점은, 추상적인 리더십 이론이 아니라 실제 엔지니어링 조직에서 마주하는 구체적인 상황들을 다룬다는 것이다. 기술 부채를 어떻게 관리할지, 팀 간 의견 충돌을 어떻게 조율할지, 한정된 리소스로 어떤 프로젝트를 우선할지 같은 현실적인 고민들 말이다.

한줄 평

“혼자 잘하는 개발자에서, 조직을 설계하는 기술 리더로 가는 가장 명료한 로드맵.”

FormData 전송 시 Content-Type 헤더를 설정하면 안 되는 이유

Sat, 24 May 2025 09:05:10 GMT

“왜 파일 업로드가 계속 실패하지?” - 많은 개발자들이 겪는 흔한 실수

🤔 문제 상황

파일 업로드 기능을 구현했는데 이유없이 실패하는 문제를 맞닥뜨렸다.

// 이렇게 했는데 왜 안 될까? 🤷‍♂️
const formData = new FormData()
formData.append('file', file)

axios.post('/upload', formData, {
  headers: {
    'Content-Type': 'multipart/form-data', // 이게 문제!
  },
})

서버에서는 400 Bad Request나 파일 파싱 오류가 발생하고, 몇 시간을 디버깅해도 원인을 찾기 어려웠다.

💡 해결책: 헤더를 아예 생략하세요

이것저것 찾아본 결과 내가 찾은 해결책은 정말 파격적이었다. formData를 보낼 때마다 당연히 헤더를 설정했는데 말이다.

// ✅ 올바른 방법
const formData = new FormData()
formData.append('file', file)
formData.append('description', 'My awesome file')

axios.post('/upload', formData)
// 끝! 이게 전부입니다.

🔍 왜 이런 일이 생길까?

Boundary의 비밀

multipart/form-data로 데이터를 전송할 때, 각 필드를 구분하기 위해 boundary라는 특별한 구분자가 필요하다.

아래와 같이 boundary가 없는 경우 서버는 어떤 문자열로 필드를 구분해야 하는지 모르게 된다.

const formData = new FormData()
formData.append('username', 'john_doe')
formData.append('email', 'john@example.com')
formData.append('bio', 'I love coding!')

Content-Disposition: form-data; name="username"
john_doe
Content-Disposition: form-data; name="email"
john@example.com
Content-Disposition: form-data; name="bio"
I love coding!

아래와 같이 boundary가 있는 경우 서버는 어떤 문자열로 필드를 구분해야 하는지 알 수 있다.

------WebKitFormBoundary7MA4YWxkTrZu0gW
Content-Disposition: form-data; name="file"; filename="photo.jpg"
Content-Type: image/jpeg

[파일 바이너리 데이터]
------WebKitFormBoundary7MA4YWxkTrZu0gW
Content-Disposition: form-data; name="description"

My awesome file
------WebKitFormBoundary7MA4YWxkTrZu0gW--

여기서 ------WebKitFormBoundary7MA4YWxkTrZu0gW가 바로 boundary다.

// ❌ 이렇게 하면...
headers: {
  'Content-Type': 'multipart/form-data'  // boundary가 없음!
}

하지만 내가 헤더를 수동으로 설정하면 boundary가 포함되지 않는다. 그래서 서버는 “어떤 문자열로 필드를 구분해야 하는지” 모르게 된다. 마치 책에서 페이지 번호가 없는 것과 같다.

🛠 올바른 동작 원리

자동 설정 과정

FormData 감지: axios가 요청 본문이 FormData 객체임을 인식
Boundary 생성: 고유한 랜덤 문자열 생성 (예: ----formdata-axios-0.27.2-1234567890)
헤더 설정: Content-Type: multipart/form-data; boundary=----formdata-axios-0.27.2-1234567890
데이터 구성: 생성된 boundary로 각 필드를 구분하여 전송

개발자 도구에서 확인해보기

const formData = new FormData()
formData.append('file', file)

axios.post('/upload', formData)

Network 탭에서 Request Headers를 보면:

Content-Type: multipart/form-data; boundary=----formdata-axios-0.27.2-16789012345

🌐 다른 HTTP 클라이언트들도 마찬가지

이는 axios만의 특별한 기능이 아니다. 모든 HTTP 클라이언트에서 동일하다.

Fetch API

// ✅ 올바른 방법
fetch('/upload', {
  method: 'POST',
  body: formData, // Content-Type 자동 설정
})

cURL

# ✅ 자동으로 boundary 설정
curl -X POST -F "file=@photo.jpg" http://example.com/upload

Node.js

// Node.js에서 form-data 라이브러리 사용 시
const FormData = require('form-data')
const form = new FormData()
form.append('file', fs.createReadStream('file.txt'))

axios.post('/upload', form, {
  headers: {
    ...form.getHeaders(), // 올바른 헤더 자동 생성
  },
})

왜 모든 클라이언트가 이렇게 동작하는가?

HTTP 표준 (RFC 7578)에서 정의:

multipart/form-data는 반드시 boundary 파라미터가 필요
Boundary는 고유하고 예측 불가능한 문자열이어야 함
각 구현체(브라우저, 라이브러리)가 자동으로 생성하도록 설계

🎯 핵심 정리

FormData 사용 시 Content-Type 헤더를 생략하기
HTTP 클라이언트가 자동으로 올바른 boundary와 함께 설정한다
이는 웹 표준(RFC 7578)을 따르는 모든 구현체의 공통 동작이다

패턴으로 익히고 설계로 완성하는 리액트 리뷰(한빛미디어)

Thu, 27 Mar 2025 21:04:16 GMT

“한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다.”

출처: 한빛미디어

책 소개

최근에 어떻게 하면 코드를 더 잘 짤 수 있을지 고민하다가 『패턴으로 익히고 설계로 완성하는 리액트』라는 책을 접했다. 표지의 “패턴”과 “설계”라는 글자가 와닿았고 TDD와 리팩터링으로 계속 코드를 개선하는 가이드를 제시해줄 것이라고 기대했다.

책의 구성 및 내용

이 책은 리액트 애플리케이션 개발 시 자주 발생하는 안티패턴을 정의하고, 이를 해결하기 위한 설계 원칙과 패턴을 제시한다. 특히 TDD(테스트 주도 개발)와 리팩터링을 통해 코드 품질을 높이는 방법을 실용적인 예제를 통해 보여준다.

책은 크게 리액트 기본 개념, 안티패턴 이해하기, 효과적인 패턴과 테스트 방법, 그리고 실제 프로젝트 구현 등의 섹션으로 나누어져 있다.

Part2 테스팅 기법

Part2에서 테스트 방법론 같은 부분은 다른 책과 내용이 비슷했다. 하지만 7장에서 테스트 주도 개발을 제대로 보여줬다. 예시로 ‘코드 오븐’ 애플리케이션을 만들었는데 요구사항 분석과 세분화를 통해 테스트를 먼저 짜놓고 컴포넌트 개발에 들어갔다.

Part3 비즈니스 로직과 디자인 패턴 알아보기

가장 관심있던 부분은 Part3 비즈니스 로직과 디자인 패턴 알아보기였다. 요즘에 비즈니스 로직을 어떻게 잘 분리해서 작성할 수 있을지 고민이 많았기 때문이다. Part3의 내용을 요약해보면 다음과 같다.

ACL(오류 방지 계층)(Anti-Corruption Layer)

ACL은 각각 다른 언어를 사용하는 다른 서브시스템 간의 중재자 역할을 한다. 프론트엔드 ACL은 서버에서 받아 온 데이터를 프론트엔드에서 이해할 수 있는 형태로 변환한다. 그리고 캐시 처리, 오류 변환과 같은 여러 문제를 처리하는 전략 계층으로도 활용할 수 있다.

변환 함수를 사용하면 백엔드에서 주는 데이터 형식이 바뀌더라도 변경의 범위를 변환 함수로 제한할 수 있기 때문에 컴포넌트를 보존할 수 있다.

Context API를 통한 Prop Drilling 문제 해결

보통의 Prop Drilling은 상태값을 넘길 때 일어났지만 예시에서는 함수를 넘길 때의 상황을 다뤘다. 겹겹이 쌓인 컴포넌트에서 자식 컴포넌트의 onClick 함수를 그대로 전달하기 위해 부모 컴포넌트를 무의미하게 거치는 상황을 Context API를 통해 해결했다. 그러면 자식 컴포넌트에서 바로 onClick 함수에 접근이 가능해진다.

단일 책임 원칙

가장 많이 사용되는 기술

render prop

리액트 컴포넌트 간 코드 공유를 위해 함수 prop을 사용

const Title = ({ title, render }) => {
  return <div>{render(title)}</div>
}

부모 컴포넌트가 자식 컴포넌트의 렌더링 로직을 제어할 수 있어 컴포넌트를 더욱 유연하게 하고 재사용할 수 있게 한다.

핵심 로직을 변경하지 않고 컴포넌트 동작을 확장하거나 사용자에 맞게 지정할 수 있다.

합성(composition)

const MyAvatar = () => (
  <Tooltip name="My Avatar">
    <Avatar />
  </Tooltip>
)

예제와 같이 Tooltip 컴포넌트와 Avatar 컴포넌트를 분리함으로써 각자의 역할을 하면서 서로 합성할 수 있다.

Part4 실무에서의 구현

Part4에서는 앞에서 배운 개념들을 가지고 ‘코드 오븐’이라는 피자 가게 애플리케이션을 개발한다. 여기서는 타입을 클래스 기반의 모델로 변환하면서 데이터의 모든 변환 로직을 이곳에 모은다. 그리고 전략 패턴을 통해 할인을 제공하는 등의 요구사항을 개발했다. 이렇게 개발한 코드들을 마지막 계층 구조 챕터에서 봤을 때 유지 보수하기 쉬운 코드가 되었다는걸 알 수 있었다.

정리

책의 난이도는 어렵지 않은 편이라서 프론트엔드 개발자라면 누구나 읽을 수 있을 것이다. 그리고 이론과 실제 예제의 조화가 적절하고 예제가 이론을 이해하는데 큰 도움이 됐다. 어떻게 하면 더 나은 코드를 작성할 수 있을지 고민하고 있다면 큰 도움이 될 거라고 생각한다.

최근에 내가 구현했던 흔하지 않았던 UI들 모음

Sun, 16 Mar 2025 16:03:15 GMT

프론트엔드 개발자로 일하다 보면 디자이너가 제안한 UI를 구현하는 과정에서 표준 패턴만으로는 해결하기 어려운 상황을 종종 마주치게 된다. 이런 사례들을 해결하다 보면 역시 css 세계는 드넓구나 하는 생각이 들고 css의 가능성에 대해서 더 시야가 트이는 것 같다. 그리고 거기서 찾아오는 성취감은 덤이다. 사례가 아직 많진 않지만 마주할 때마다 이것도 모아두면 유용한 참고자료가 되지 않을까 싶어서 적어보고 계속해서 업데이트 해보려고 한다.

1. 중간에 있는 텍스트 truncate(ellipsis)하기

보통 truncate는 이렇게 텍스트 전체에 적용하거나 끝 부분에 적용한다. 그리고 이런 효과를 주기 위해서 다음 속성들을 활용한다.

overflow: hidden으로 컨테이너를 벗어나는 텍스트를 숨긴다.
text-overflow: ellipsis로 숨겨진 텍스트 대신 말줄임표를 표시한다.

하지만 중간 텍스트에 truncate를 적용해야 하는 경우가 생겼다. 처음엔 어떻게 구현하지 싶었는데 같은 원리를 적용하니까 수월하게 풀렸다. 적용할 텍스트를 inline-block으로 만들었고 텍스트 정렬이 틀어지기 때문에 vertical-align을 bottom으로 바꿨다.(이렇게 처리하는 이유) 그 다음엔 똑같이 width 제한을 주고 text-overflow 등을 조절했다.

이 방식의 핵심은 텍스트를 블록 요소처럼 다루면서도 인라인 흐름을 유지하는 것이다. inline-block은 요소가 인라인 요소처럼 텍스트 흐름 내에 배치되면서도 블록 요소처럼 너비와 높이를 가질 수 있게 해준다. 이를 통해 텍스트의 특정 부분만 제한된 너비를 갖도록 만들 수 있다.

실제 사용 사례와 고려사항

이 패턴은 사용자 프로필이나 댓글 시스템에서 특히 유용하다. 예를 들어, “홍길동님이 댓글을 남겼습니다”와 같은 알림에서 사용자 이름이 너무 길 경우 중간 부분을 생략하면서도 문장의 흐름을 유지할 수 있다. 또한 이메일 주소를 표시할 때 도메인 부분은 항상 보여주면서 사용자 이름 부분만 truncate하는 경우에도 활용할 수 있다.

.nickname {
  max-width: 100px;
  display: inline-block;
  white-space: nowrap;
  overflow: hidden;
  text-overflow: ellipsis;
  vertical-align: bottom;
}

2. Grid 열의 높이를 자식 중 가장 높은 요소에 맞추기

보통의 경우에는 grid를 사용할 때 자식 요소들 크기가 일정해서 높이에 대해 신경 쓸 일이 별로 없었는데 특정 케이스에서 높이가 더 긴 자식 요소가 있었고 그 행의 높이를 가장 높은 자식의 높이에 맞춰야했다. 이럴 때 grid-auto-rows의 minmax를 활용했다.

minmax 함수는 CSS Grid의 강력한 기능 중 하나로, 첫 번째 인자는 최소값, 두 번째 인자는 최대값을 의미한다. 최소 높이를 요구사항에 맞게 정하고 auto 값을 최대값으로 사용하면 콘텐츠에 따라 자동으로 크기가 조정된다. 이를 통해 콘텐츠의 양이 적을 때는 최소 높이를 유지하고, 콘텐츠가 많을 때는 자동으로 확장되는 유연한 레이아웃을 만들 수 있다. 아래 예시에서는 grid-auto-rows: minmax(200px, auto);로 스타일을 설정했다.

브라우저 호환성

grid-auto-rows 속성은 2017년 업데이트 버전 이후 버전에서는 대부분 작동한다. Firefox for Android 브라우저의 경우에는 79버전(Released 2020-07-28) 이후 버전에서 정상 작동한다.

mdn 링크

전문가를 위한 리액트 도서 리뷰(한빛미디어)

Fri, 28 Feb 2025 19:02:44 GMT

“한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다.”

출처: 한빛미디어

책 소개

“전문가를 위한 리액트”는 단순히 리액트의 기본 사용법을 넘어 고급 패턴과 성능 최적화, 확장 가능한 아키텍처를 구축하는 방법을 다루는 책이다. 이 책은 리액트를 이미 사용해 본 개발자가 더 깊이 있는 이해와 실무적인 기술을 습득하는 데 초점을 맞추고 있다.

인상 깊었던 내용

리액트를 오래전에 다뤄봤던 터라 버전이 올라가면서 내부 동작 원리도 많이 바뀌었다는 것을 느꼈다.

파이버 데이터 구조

리액트는 16 미만 버전 ‘스택 재조정자’를 사용했었다고 한다. 작업을 일시 중지하거나 연기하지 않고 쌓여 있는대로 렌더링하기 때문에 업데이트의 우선순위를 설정할 수 없었다. 그래서 덜 중요한 업데이트가 더 중요한 업데이트를 방해하는 문제가 생겼다. 그래서 파이버라는 데이터 구조를 사용해 이 문제를 해결했다고 한다. 파이버 재조정자를 활용한 재조정 과정을 깊이있게 학습할 수 있었다.

메모화

컴포넌트에 메모화를 적용하면 내부적으로 어떤 일이 일어나는지 학습할 수 있었다.

고차 컴포넌트 패턴

고차 컴포넌트는 컴포넌트를 입력으로 받아 새로운 컴포넌트를 반환하는 함수다. 이 책에서는 고차 컴포넌트를 활용한 다양한 패턴을 소개한다. 특히 컴포넌트 합성, 고차 컴포넌트, 렌더 프롭스, 커스텀 훅 등을 활용한 다양한 패턴과 각각의 장단점이 비교되어 있어 상황에 맞는 패턴을 선택하는 데 도움이 되었다.

리액트 동시성

동시성 렌더링을 사용해 렌더링 과정에서 어떻게 우선순위를 설정하고 구성하는지 학습할 수 있었다. 처음 보는 훅도 있었는데 useDeferredValue 훅은 특정 UI 업데이트를 나중으로 미룰 수 있어서 실무에서 사용해 볼 수 있겠다는 생각이 들었다.

프레임워크

Next.js는 계속 써보고 있지만 Remix는 따로 사용해 볼 일이 없었다. Remix에 대한 글도 점점 많이 보이고 기업에서 채택하는 경우도 있었는데 뭐가 좋길래 그렇게 채택을 하는지 궁금했는데 대략적으로나마 Remix가 추구하는 방향을 알 수 있었다. Remix는 코드가 프레임워크 안에 숨겨져 있지 않고 외부로 드러나 있기 때문에 사용자가 입맛대로 수정할 수 있는게 인상적이었다. 그리고 웹의 기본적인 기능들을 적극적으로 활용하려고 한다. 폼을 사용할 때도 따로 input값을 상태값으로 저장하지 않고 native input 자체로 활용한다.

마무리

“전문가를 위한 리액트”는 단순한 리액트 입문서를 넘어서, 실제 복잡한 애플리케이션 개발에 필요한 고급 기술과 패턴을 체계적으로 정리한 책이다. 요즘에 내부 구현 및 원리에 관심이 많아서 입문서 이상의 책을 찾고 있었는데 마침 좋은 기회로 이 책을 만나서 좋았고 한번에 내용들을 완전히 이해하긴 어려웠기 때문에 여러번 반복숙달하면서 내 것으로 만들어 보려고 한다. 리액트를 사용하는 개발자라면 한 번쯤 읽어볼 가치가 있는 책이라고 생각한다.

CSS white-space 속성 적재적소에 활용하기!

Wed, 05 Feb 2025 22:03:02 GMT

웹 개발하면서 white-space 속성은 신경쓰지 않으면 놓치기 쉬운 부분인 것 같다. 계속 필요할 때마다 찾아 봤었는데 머리 속에서 제대로 정리되지 않아서 계속 찾아보게 되는 거 같아 이번에 좀 정리해보려고 한다. 결국엔 각 속성이 어떤 역할을 하고 어떤 상황에서 써야 할지 정리해두는 게 좋을 것 같다.

white-space 속성이란?

white-space 속성은 텍스트의 공백 처리 방법을 지정하는 CSS 속성이다. 이 속성은 요소 안에 있는 공백 문자와 줄바꿈 문자를 어떻게 처리할지를 정한다. 브라우저는 이 설정에 따라 텍스트의 줄바꿈, 공백 축소, 자동 줄바꿈 여부 등을 결정한다. 기본 값은 normal이다.

.element {
  white-space: normal;
}

white-space의 다양한 값

pre

소스 코드에 쓴 그대로 모든 공백과 줄바꿈을 그대로 보여준다. 자동 줄바꿈은 발생하지 않아서 너비를 넘으면 스크롤이 생길 수 있다.
사용 예: 코드 스니펫이나 시, 혹은 서식이 중요한 텍스트에 좋다.

nowrap

연속된 공백은 축소되지만 텍스트는 한 줄로 유지된다. 줄바꿈이 없어서 긴 텍스트가 한 줄로 쭉 이어진다.
사용 예: 메뉴, 버튼처럼 텍스트가 한 줄에 유지되어야 하는 경우에 적합하다.

pre-wrap

사용자가 입력한 모든 줄바꿈과 연속 공백을 그대로 유지하면서, 요소 너비를 넘어가는 경우 자동 줄바꿈도 적용된다.
사용 예: 포럼 게시글이나 채팅 메시지처럼 사용자가 입력한 텍스트 포맷(줄바꿈, 들여쓰기 등)을 그대로 보여줘야 할 때 좋다. 코드나 시처럼 정밀한 포맷이 필요한 경우에 유용하다.

pre-line

사용자가 입력한 줄바꿈은 유지하면서 연속된 공백은 하나로 축소하고, 자동 줄바꿈도 적용된다.
사용 예: 댓글이나 사용자 리뷰처럼, 사용자가 의도한 줄바꿈은 살리면서 불필요한 공백을 줄여 깔끔한 레이아웃을 유지하고 싶을 때 좋다.

white-space 속성 요약

normal
- 공백 처리: 연속 공백 축소
- 줄바꿈 처리: HTML 태그 및 기본 규칙에 따름
- 자동 줄바꿈: 요소 너비에 따라 wrap
- 사용 예: 일반 텍스트 콘텐츠 (기본 설정)
pre
- 공백 처리: 입력한 공백 그대로 유지
- 줄바꿈 처리: 소스 코드상의 줄바꿈 그대로 적용
- 자동 줄바꿈: 지원하지 않음 (오버플로우 시 스크롤 발생)
- 사용 예: 코드 스니펫, 시 또는 포맷이 중요한 텍스트
nowrap
- 공백 처리: 연속 공백 축소
- 줄바꿈 처리: 모든 줄바꿈 무시
- 자동 줄바꿈: 지원하지 않음 (한 줄로 표시)
- 사용 예: 메뉴, 버튼 등 한 줄로 유지해야 하는 경우
pre-wrap
- 공백 처리: 입력한 공백 그대로 유지
- 줄바꿈 처리: 소스 상의 줄바꿈 그대로 적용
- 자동 줄바꿈: 지원 (요소 범위 내 자동 wrap)
- 사용 예: 사용자가 입력한 텍스트의 형식을 유지할 때
pre-line
- 공백 처리: 연속 공백 축소
- 줄바꿈 처리: 입력한 줄바꿈은 유지하지만 불필요한 공백은 축소
- 자동 줄바꿈: 지원
- 사용 예: 불필요한 공백은 제거하면서 필수 줄바꿈만 유지할 때

다양한 상황에서 테스트 해보기

See the Pen Untitled by Donghoon Song (@donghoon759) on CodePen.

CSS white-space를 완벽히 내 것으로 만들었나요?

이제 배운 내용을 실전에서 확인할 시간이에요!

Ducklog 🐥에서 각 white-space 옵션의 특성과 사용하면 좋을 상황들을 쭉 적어보고 확인해보세요!

Zustand의 shallow comparison으로 최적화하기

Sun, 02 Feb 2025 18:02:18 GMT

Zustand store에서 객체 상태를 구독할 때 shallow 비교를 사용하면 불필요한 리렌더링을 방지할 수 있다는 것을 알게 되었다.

Zustand의 기본 동작

Zustand는 기본적으로 상태를 비교할 때 Object.is를 사용한다.

shallow 비교란?

shallow는 간단한 데이터에 대해서 빠르게 비교할 수 있는 방식이다. 중첩된 객체의 경우에는 내부 속성까지 비교하지 않고 참조값을 기준으로 판단한다. 이를 통해 선택자에서 반환하는 객체가 새로 생성되더라도 실제로 필요한 값이 변경되지 않았다면 리렌더링을 피할 수 있다.

아래 처럼 shallow를 전달해서 사용할 수 있다.

import { shallow } from 'zustand/shallow'

export function useUser() {
  return useUserStore(
    store => ({
      id: store.user?.id,
      name: store.user?.name,
    }),
    shallow // 👈 명시적 설정 필요
  )
}

Primitive 타입 비교

숫자, 문자열, 불리언 등 primitive 타입은 Object.is와 shallow 모두 값 자체를 비교한다. 따라서, primitive 값을 선택자로 사용할 경우 별도의 shallow 비교 없이도 값이 같으면 리렌더링이 발생하지 않는다.

객체 비교

객체를 비교할 때 shallow는 각 객체의 최상위 속성 값만을 비교한다.

import { shallow } from 'zustand/shallow'

const obj1 = { a: 1, b: 2, c: 3 }
const obj2 = { a: 1, b: 2, c: 3 }

console.log(Object.is(obj1, obj2)) // false
console.log(shallow(obj1, obj2)) // true

위의 예제에서 두 객체의 참조값은 다르지만 top-level 속성(a, b, c)의 값이 모두 같기 때문에 shallow 함수는 true를 반환한다.

import { shallow } from 'zustand/shallow'

const obj1 = { a: 1, b: 2, c: { d: 4 } }
const obj2 = { a: 1, b: 2, c: { d: 4 } }

console.log(Object.is(obj1, obj2)) // false
console.log(shallow(obj1, obj2)) // false

하지만 객체 내부에 중첩된 객체가 포함되어 있을 경우, shallow 비교는 해당 속성의 참조만을 비교하기 때문에 false를 반환한다.

shallow 비교의 동작 원리

Zustand의 shallow 함수는 다음과 같은 방식으로 두 객체를 비교한다.

두 객체가 같은 참조(메모리 주소)를 가지면 true를 반환한다.
두 객체의 키 개수가 다르면 false를 반환한다.
각 속성 값을 비교하며, 값이 다르면 false를 반환한다. 단, 객체나 배열인 경우 참조가 같으면 true를 반환한다.
속성 값이 객체나 배열이면 참조(메모리 주소)를 비교하지만, 최상위 속성의 값이 동일하면 같다고 판단한다.

github에 있는 shallow 함수의 코드는 아래와 같다.

export function shallow<T>(objA: T, objB: T) {
  if (Object.is(objA, objB)) {
    return true
  }
  if (
    typeof objA !== 'object' ||
    objA === null ||
    typeof objB !== 'object' ||
    objB === null
  ) {
    return false
  }

  if (objA instanceof Map && objB instanceof Map) {
    if (objA.size !== objB.size) return false

    for (const [key, value] of objA) {
      if (!Object.is(value, objB.get(key))) {
        return false
      }
    }
    return true
  }

  if (objA instanceof Set && objB instanceof Set) {
    if (objA.size !== objB.size) return false

    for (const value of objA) {
      if (!objB.has(value)) {
        return false
      }
    }
    return true
  }

  const keysA = Object.keys(objA)
  if (keysA.length !== Object.keys(objB).length) {
    return false
  }
  for (const keyA of keysA) {
    if (
      !Object.prototype.hasOwnProperty.call(objB, keyA as string) ||
      !Object.is(objA[keyA as keyof T], objB[keyA as keyof T])
    ) {
      return false
    }
  }
  return true
}

불필요한 리렌더링을 방지

이제 본론으로 넘어 와 보자. Zustand의 useStore 훅에서 shallow를 활용하면 불필요한 리렌더링을 방지할 수 있다.

import { create } from 'zustand'

const useUserStore = create(set => ({
  user: { id: 123, name: 'John' },
  // 전체 user를 변경하는 함수
  setUser: user => set({ user }),
  // user 객체의 일부 속성을 업데이트하는 함수
  updateUser: updates =>
    set(state => ({ user: { ...state.user, ...updates } })),
}))

export function useUser() {
  return useUserStore(
    store => ({
      id: store.user?.id,
      name: store.user?.name,
    }),
    shallow // 👈 명시적 설정 필요
  )
}

// 초기 상태: { user: { id: 123, name: 'John' } }
const { id: id1 } = useUser() // 123 반환

// 1. id가 변경되지 않은 업데이트
setStore({ user: { id: 123, name: 'Jane' } })
const { id: id2 } = useUser() // 123 → 리렌더링 발생 ❌

// 2. id가 변경된 업데이트
setStore({ user: { id: 456, name: 'Jane' } })
const { id: id3 } = useUser() // 123 → 리렌더링 발생 ✅

// 3. email이 추가된 업데이트
setStore({ user: { id: 123, name: 'Jane', email: 'test@test.com' } })
const { id: id4 } = useUser() // 123 → 리렌더링 발생 ❌

shallow를 사용하면 1번의 경우 id2를 사용하는 컴포넌트는 리렌더링이 발생하지 않는다. 왜냐하면 name은 바뀌었지만 구독하고 있는 id의 값은 123 그대로 유지되었기 때문이다.

2번의 경우는 구독하고 있는 id값이 달라졌으므로 id3을 사용하는 컴포넌트는 리렌더링이 발생한다.

3번처럼 새로운 속성이 추가되어도 id값은 바뀌지 않았기 때문에 id4를 사용하는 컴포넌트는 리렌더링이 발생하지 않는다. 만약에 shallow를 사용하지 않으면 1번, 2번, 3번 모두 리렌더링이 발생할 것이다.

이렇게 중첩되지 않는 객체나 배열을 구독하는 경우 shallow를 사용하면 불필요한 리렌더링을 방지할 수 있다.

필요한 값만 구독하기

shallow를 사용하지 않고 이렇게 필요한 값만 구독하면 primitive 타입을 반환하기 때문에 Object.is에서 같다고 판단해 리렌더링이 발생하지 않는다. 그래서 보통의 경우에는 이렇게 필요한 값만 구독하는 것이 좋다.

export function useUserNo() {
  return useUserStore(store => store.user?.id)
}

불가피하게 객체를 구독하는 경우

하지만 객체에서 사용하는 값이 많고 업데이트가 자주 일어난다면 이렇게 객체를 한번에 구독하고 shallow 함수를 사용하는 것을 고려해볼 수 있다.

import React from 'react'
import create from 'zustand'
import { shallow } from 'zustand/shallow'

// Zustand 스토어 정의: 여러 user 관련 속성을 포함합니다.
const useUserStore = create(set => ({
  user: {
    id: 123,
    name: 'John',
    email: 'john@example.com',
    phone: '010-1234-5678',
    address: 'Seoul, Korea',
    role: 'user',
  },
  // user 객체의 일부 또는 전체를 업데이트하는 함수
  updateUser: updates =>
    set(state => ({
      user: { ...state.user, ...updates },
    })),
}))

// 전체 user 객체를 shallow 비교와 함께 구독하는 훅
export function useUser() {
  return useUserStore(state => state.user, shallow)
}

// 예시 컴포넌트: 여러 user 관련 속성을 렌더링합니다.
function UserComponent() {
  const user = useUser() // 전체 user 객체를 구독
  console.log('UserComponent rendered')

  return (
    <div>
      <p>ID: {user.id}</p>
      <p>Name: {user.name}</p>
      <p>Email: {user.email}</p>
      <p>Phone: {user.phone}</p>
      <p>Address: {user.address}</p>
      <p>Role: {user.role}</p>
    </div>
  )
}

// 예시 업데이트 코드 (실제 환경에서는 이벤트 핸들러 등에서 호출)
// 예를 들어, 1초 후 name과 email을 업데이트하는 경우:
setTimeout(() => {
  useUserStore
    .getState()
    .updateUser({ name: 'Jane', email: 'jane@example.com' })
}, 1000)

export default UserComponent

결론

정리해보면 불필요한 리렌더링을 방지하기 위해서는

객체의 특정 속성만 선택하는 것이 좋다.
중첩되지 않은 객체나 배열을 구독하는 경우 shallow를 사용하면 불필요한 리렌더링을 방지할 수 있다.

가운데 정렬된 네비게이션 혹은 헤더 grid로 구현하기

Sat, 01 Feb 2025 14:02:56 GMT

UI를 구현하다보면 이런 식으로 가운데 정렬된 네비게이션 혹은 헤더를 구현해야 할 때가 있다. absolute를 이용해서 가운데 요소를 가운데 정렬하거나 flex의 justfify-content: space-between 사용해서 레이아웃을 구현하기도 한다. 하지만 후자의 경우에는 왼쪽이나 오른쪽 요소가 사라질 경우 레이아웃이 깨질 위험이 있다. 이번 포스트에서는 grid를 사용해서 구현하는 방법을 알아보려고 한다.

HTML 구조

<div class="page-navigation-controls">
  <div class="left-button-wrapper">
    <button class="icon-button" id="prevButton" disabled>⬅️</button>
  </div>
  <div id="progressText">1 / 5</div>
  <div class="right-button-wrapper">
    <button class="icon-button" id="nextButton">➡️</button>
  </div>
</div>

CSS 스타일링

네비게이션 컨트롤을 그리드 레이아웃을 사용하여 배치하고, 버튼 스타일을 설정한다.

.page-navigation-controls {
  display: grid;
  grid-template-columns: 1fr auto 1fr;
  align-items: center;
  margin-top: 1.5rem;
  width: 100%;
  max-width: 400px;
  position: relative;
  gap: 1rem;
}

.left-button-wrapper {
  justify-self: flex-start;
}

.right-button-wrapper {
  justify-self: flex-end;
}

.icon-button {
  background: none;
  border: none;
  cursor: pointer;
}

.icon {
  width: 24px;
  height: 24px;
}

여기서 중요한 부분은 grid-template-columns: 1fr auto 1fr;이다.

1fr : 첫 번째, 세번째 열(왼쪽 버튼, 오른쪽 버튼)이 가변 크기를 가지며, 공간이 있으면 확장된다.
auto : 가운데 열(페이지 진행률 표시)은 내용 크기만큼 유지된다.

이렇게 하면 왼쪽 버튼과 오른쪽 버튼이 화면 크기에 따라 확장되면서 가운데 열은 고정된 크기를 유지한다. 이 방법은 레이아웃이 유연하면서도 왼쪽이나 오른쪽 요소가 사라지는 경우에도 레이아웃이 깨지지 않는다.

테오의 스프린트 18기 참가 후기

Thu, 26 Dec 2024 17:13:07 GMT

들어가며

좋은 사람들과 함께 잘 만들어진 협업 프로세스를 배우고 경험한다.라는 슬로건으로 운영중인 테오의 스프린트에 드디어 참여했다. 후기 글들과 스프린트 결과물을 보면서 꼭 한번 참여해 보고 싶었는데 항상 시간이 안 맞아서 참여하지 못해서 항상 아쉬웠다. 컨퍼런스 발표를 마치고 숨을 돌리고 있던 와중에 모집 글이 올라와서 다행히 이번엔 참여할 수 있겠다 싶어서 부리나케 지원 폼을 작성했다.

테오의 스프린트란

구글 스프린트는 짧은 시간 내에 아이디어 검증을 하기 위한 그럴싸한 MVP를 효율적으로 만들어내는 방법론입니다. **[6일간 좋은 사람들과 잘 만들어진 협업 프로세스를 함께 경험한다]**라는 슬로건 아래 스프린트를 직접 경험해 본 9명의 퍼실리테이터가 모여, 스프린트에서의 경험을 잘 이어가기 위해 1개월간 열심히 준비했습니다. 다양한 생각과 경험이 모여 더욱 풍성한 스프린트가 되길 기대합니다.

https://teo-sprint.oopy.io/

테오의 스프린트는 위에서 소개한 내용처럼 아이디어 검증을 위한 협업 프로세스를 타이트하게 경험할 수 있는 스프린트이다.

스프린트에서 어떤 걸 경험하고 배웠는지 날짜별로 정리해 봤다.

Day1. 팀 캔버스 작성하기

우리는 아이디어를 중심으로 팀을 구성했다. 나도 아이디어를 냈는데 놀랄 만큼 아무런 관심도 받지 못했다. 하지만 그런 아이디어들이 꽤 여럿있었고 다른 좋은 아이디어들이 많아서 딱히 신경쓰진 않았다. 😅

아이디어: 즉석 대화 소재 생성기

내가 선택한 아이디어는 즉석 대화 소재 생성기이다. 낯선 사람과 대화할 때 할 말이 없으면 대화 소재를 추천해주는 서비스인 것이다. 정말 나같은 사람에게 필요하겠다 싶어서 냅다 선택했다. 하지만 나같은 사람들이 많아서 우리 팀의 아이디어는 반응이 뜨거웠고 많은 사람들이 모였다.

팀 빌딩

우리는 1조가 되었고 서로에 대해 알아가는 시간을 가졌다. 다양한 사람들이 모였는데 우리는 공통적으로 모두 MBTI I였고 아이디어에 대해 많이 공감하는 사람들이었다.

그리고 나서 우리는 여러가지 이야기를 나눴다.

팀의 성공을 어떻게 정의할 것인가?

공통적인 의견으로는 서비스의 완성, 그리고 사용자가 있을 것이었다. 생각이 잘 맞아서 좋았다.

우리 서비스는 어떤 가치를 줄 것인가?

우리는 좋은 대화 소재를 추천하고 누구나 빠르게사용할 수 있게 하고 싶었다.

그 외에 우리는 가진 능력과 기술스택, 약점과 리스크, 꼭 지켜줬으면 하는 규칙에 대한 얘기를 나누면서 팀 캔버스를 완성했다. 이런 내용들도 미리 얘기를 하니까 협업하면서 생길 수 있는 이슈에 대해 미리 생각해볼 수 있었고 서로 어떤 부분을 걱정하는지 알 수 있었다.

숙제로 비슷한 앱의 레퍼런스를 찾아 왔었는데 우리 아이디어를 실현한 앱들이 꽤 보여서 놀랐다. 이 앱들에서 찾은 아쉬운 점들을 개선해서 우리 서비스에 넣으면 좋지 않을까 하는 생각을 했다.

Day2. 지도 그리기

Day2는 생각의 주파수를 맞추는 날이었다. 그라운드 룰이 있었는데 아래와 같았고 굉장히 인상깊었다.

결정하지 않기
- 새로운 가능성을 차단하지 않는다.
- A vs B 가 아니라 A + B = C가 되도록
기록하기
리액션하기

이 룰들을 가지고 또 여러가지 이야기를 나눴다.

서비스의 목적

우리는 서비스의 목적을 대화의 어려움 해소, 즐거운 대화라고 생각했고 말을 잘 못하는 I들을 타겟이라고 생각했다. 한 팀원분은 서비스 타겟이 우리 팀이라고 적었는데 맞는 말이었다. 😅

Pain/Wow Point

기존 사람들이 목적을 달성하기 위해 어떤 행동을 하고 있는지를 생각해 봤을 때 이런 것들이 있었다.

그냥 침묵하기
관심사를 명찰이나 옷에 붙이기
어떻게든 머리 짜내기

그리고 우리가 찾았던 비슷한 서비스들엔 어떤 아쉬운 부분들이 있었을까 생각해봤는데 아무도 그런 앱이 있다는 것을 알지 못했고 찾아보려는 생각조차 못했었다는 것이 공통된 의견이었다. 그래서 일단 이런 부분들이 기회가 될 수 있겠다는 생각이 들었다. 그리고 우리 앱을 사용해서 대화를 쉽게 할 수 있다는 것을 깨달으면 그게 WOW point가 되지 않을까 하는 생각이 들었다.

워드 클라우드 만들기

우리가 얘기할 때 나왔던 단어들을 가지고 워드 클라우드를 만들었다. 빈도수가 높았던 단어일수록 크게 작성했다. 불편, 부담, 다양한 주제, 침묵 등이 눈에 띈다.

어떻게 하면~ 질문 만들기

이 활동이 상당히 인상적이었다. 우리가 갖고 있는 고민 포인트들을 구체화할 수 있었고 해소하는 방법에 대해 생각해 볼 수 있었다.

어떻게 하면 이 앱을 꺼낼 때 부담스럽지 않을 수 있을까?

이 앱을 어떻게 자연스럽게 꺼낼 수 있을지에 대한 고민에서부터 나온 질문이다. 낯선 사람과 앉아 있는데 갑자기 이 앱을 꺼내면서 대화를 시작하면 상대방도 당황하지 않을까 하는 생각이 들었다. 그래서 “빌드업을 하면 괜찮을 거 같다.”, “상대방이 이 앱을 인지하고 거부감을 줄일 수 있는 시간이 필요하다. ex) 앱에 게임을 같이 제공”는 의견들이 나왔다.

어떻게 하면 다양한 주제의 토픽을 효과적으로 분류할 수 있을까?

우리 주제들을 어떻게 분류해야 사용자가 쉽게 사용할 수 있을지에 대한 고민도 했다.

다른 서비스와 차별화된 주제

어떻게 하면 우리 서비스의 주제들을 차별화할 수 있을지에 대한 고민도 했다.

이런 질문들을 통해서 핵심적인 고민거리에 대한 서로의 생각을 들어볼 수 있었다.

기능 및 페이지 정리

다음으로는 필요한 기능들을 쭉 나열하고 페이지별로 나누고 정리하는 시간을 가졌다.

화면 스케치

숙제로는 각자가 생각하는 화면을 스케치했다.

Day3. 스케치

Day3에서는 각자의 스케치를 화면 별로 정리하고 좋았던 요소에 투표를 하는 시간을 가졌다. 여기서 좋았던 요소에 투표를 하는 게 인상적이었다. 이것도 A + B = C가 되도록 하는 장치였다.

서로의 스케치를 보면서 스케치도 각자가 생각하는 게 달라서 정말 신기했다. 다양한 스케치들이 나왔다.

요소에 투표했던 예시를 들어보면 아래 처럼 토픽 추천받아 대화 시작해보기 버튼에 많이 투표를 했다. 밸런스 게임을 통해서 어느정도 어색함이 사라지면 바로 대화를 시작할 수 있게 하는 장치여서 좋다고 생각했다.

이렇게 투표를 하고 UX/UI 최고 권위자를 뽑았다. 우리 팀은 디자이너가 있기 때문에 자연스레 디자이너가 최고 권위자가 되었다.

또 PL(Project Leader)를 뽑았는데 내가 맡았다. 아무래도 회사에서 하는 역할이랑 비슷한 거 같기도 하고 데모 퀄리티를 꼭 지켜보고 싶었다. 잘 해낼 수 있을 거라는 근거 없는 자신감도 뿜뿜했다.

우선순위 결정

그럴싸함 챙기는 법을 읽었는데 대부분 하고 있던 생각이랑 비슷했다. 하지만 미구현 기능에 대해 '준비중입니다' 알림 띄우기 항목이 인상적이었다.

다음으로는 임팩트와 Effort(걸리는 시간)을 기준으로 기능들의 우선순위를 나눴다.

Day4. 결정하기

드디어 결정하는 시간이 왔다. 이제까지의 활동에는 결정하는 시간이 없어서 몸이 근질거렸다.

BDD로 태스크 분배

사용자의 행위를 중심으로 태스크를 나눴다. BDD를 처음 해봐서 이게 맞나 걱정이 됐지만 그래도 얼추 잘 해낸 거 같다.

태스크를 분배하고 컨벤션, 기술스택, 배포에 대한 결정을 했는데 프론트엔드 팀원들은 대부분 스택이 비슷했기 때문에 정하는데 크게 어려움은 없었다.

Day5~6. 개발

주말에 드디어 개발을 했다. 개발을 이틀만 하니까 시간이 많이 부족하긴 했는데 초반부에서 생각을 맞추는 활동들을 하다 보니까 확실히 많은 시간이 들고 꼭 필요한 시간들이라는 생각이 들었다. 이렇게 하는 게 맞다는 생각이 들었다. 이렇게 많은 시간을 투자했는데도 아직도 생각이 다른 부분들이 남아 있을 수 있기 때문이다.

개발할 때는 PL로서 아래 항목들을 챙기려고 노력했다.

스케쥴 투명하게 관리
- 작업 가능한 시간, 불가능한 시간 공유
- 온라인이면 zep에 항상 들어 와 있기
  - 소통하기 편하고
  - 궁금한 거 봐주고
- 자리 비울 때 디스코드에 올리기
작업 상황 투명하게 관리
- 노션에 todo로 관리
  - 실패(?)
  - 모두가 해당 항목에 동의했고 멤버들을 초대하려고 메일을 남겨달라고 했지만 전부가 남기진 않았음. 그래서 활용하지 못했음.
  - 하지만 노션 없이도 빠트린 내용없이 잘 완수했음. -> 우리 팀엔 필요없는 거 같음!
도와주기
- 모르는 거 봐주기
서로의 작업물 연결하기
- 밸런스 게임 2명, 토픽 추천 2명 이렇게 맡았기 때문에 서로의 작업물을 연결하는 작업을 해야했다.
적절히 위임하기
- 챙기려고 했으나 신경써야 할 게 너무 많아서 밸런스 게임 주제, 대화 소재 등 데이터 부분을 백엔드에 챙겨달라고 위임.
- README → 써 본 경험 있는 팀원에게 위임. 대신 그 팀원의 개발 태스크를 도와줌.
먼저 배포하기
- 배포하면 문제가 생기는 경우가 많아서 미리 미리 배포해보기
  - 실제로 배포했는데 api가 안 불러와져서 보니까 vercel에 환경변수 등록하는걸 빼먹었었음
덜어내기
- 카드 UI, interaction가 굉장히 어려웠다. 이 부분을 조금 덜어냈어야 했는데 그거라도 없으면 너무 심심할 거 같아서 미련을 좀 가지고 시간을 투자했다. 역시나 빠르게 덜어내는 게 더 나았을 것이라는 생각을 했다.

Day7. 데모

개발을 무사히 마치고 데모날이 왔다. 그리고 이렇게 메시지를 남겼다. 기능을 마무리하고 서비스에 크게 지장이 없는 선에서 챙길 수 있는 디테일을 계속 챙겨 나가다 보니 직전까지 정신이 없었다.

페어 데모

데모는 아래의 방식으로 진행했는데 데모를 하는 방식도 인상깊었다. 데모를 위한 데모가 아니라 정말 유저의 찐 반응을 볼 수 있도록 설계된 거 같아서 마음에 들었다.

사람 사는 거 다 똑같구나

테오의 스프린트에서는 모두가 매끄러운 경험을 할 줄 알았는데 데모 때 보니까 사람 사는 거 다 똑같구나 하는 생각이 들었다. 디자이너가 도중에 이탈한 팀도 있고 배포했는데 문제가 생겨서 데모를 못한 팀도 있었다. 참 안쓰러우면서도 내가 정말 운이 좋아서 좋은 사람들을 만난 거였구나 하는 감사한 마음이 들었다.

회사에서 이 경험을 공유했을 때 한 분이 “물론 운이 좋았다고 하실 거 같지만 그것 외에 데모를 성공적으로 마칠 수 있었던 비결이 뭐라고 생각하시나요?”라는 질문을 하셨다. 그 분이 원하는 대답을 하고 싶었지만 아무리 생각해봐도 이건 “운이 좋았다.” 라고밖에 설명할 길이 없었다. 좋은 사람들이 모여서 맡은 바 역할을 다 한 게 성공의 요인이었다는 게 내 결론이다.

팀 회고

데모 후에 팀 회고를 하면서 스프린트를 마쳤다.

모두 소통도 잘 되고 책임감 있게 서로의 역할을 다 했던 부분들이 좋았다고 작성했고 완성할 수 있어 좋았다고 했다. 의견을 나눌 때도 서로 잘 들어주고 존중하면서 진행했던 부분이 좋았다.

아쉬웠던 부분은

데이터 부분이 조금 아쉬웠는데 대화 소재는 아이디에이션을 하고 투표를 해서 높은 투표 수를 받은 소재들을 위주로 쓰고 싶었는데 마음이 급해서 아이디에이션까지밖에 하지 못했다.
밸런스 게임도 선택지 별로 질문을 다 다르게 하고 싶었는데 시간상 질문을 통일해야 했다. 하지만 질문을 통일하다 보니까 질문과 답변 사이 관계가 어색한 부분이 있었다.
데모 때 카드가 스와이프 되는 걸 몰랐다는 피드백을 받았는데 이 부분이 많이 아쉬웠다. 시간 관계상 디자인을 바꿨는데 우리 팀원들이야 스와이프 되게 만들었다는 걸 알지만 모르는 사람이 봤을 때 스와이프 된다는 걸 충분히 인지하지 못 할 수 있었기 때문이다.

길게 썼지만 아쉬웠던 부분들은 다 나에 대한 내용이다. 내 욕심 그리고 셀프 회고 느낌. 다른 부분에 대해선 아쉬운 게 없을만큼 좋았다. 👍🏻

다음 번 스프린트를 한다면

다음 번 스프린트를 상상하면서 어떤 것을 하면 좋을지 얘기를 하고 회고를 마무리했다. 이 부분도 의견들이 비슷해서 좋았다.

롤링 페이퍼

롤링 페이퍼도 썼는데 개인 것들은 이렇게 남겨두려고 한다. 대놓고 칭찬 받을 기회는 잘 없기 때문에 🤣 읽으면서 서툴지만 그래도 역할은 다 해낸 거 같다는 뿌듯한 마음이 들었다.

대화가 어려운 당신을 위한 말해머해

서비스 링크

좋았다

일주일동안 정말 값진 경험을 할 수 있었다. 많이 배웠고 업무에서 써 먹으면 좋을 것 같은 부분들도 많았다. 그리고 부족했던 부분들은 채워 나가려고 한다. 누군가 테오의 스프린트에 참여하는 것을 고민하고 있다면 적극 추천하고 싶다.

소플의 처음 만난 AWS 리뷰(한빛미디어)

Thu, 26 Dec 2024 15:13:30 GMT

AWS는 처음 접할 때부터 어렵게 느껴졌다. 서비스가 워낙 많기도 하고 공식 문서나 자료를 읽는 것도 쉽지 않아서 공부 과정에서 많은 어려움을 겪었는데, 이 책은 그런 저에게 새로운 길을 열어주었다.

쉽고 친근한 설명

이 책의 가장 큰 장점은 쉽게 풀어 쓴 설명이다. AWS의 기본 개념과 서비스 사용법을 마치 친근한 선생님이 알려주는 듯한 방식으로 전달해 주어 부담 없이 내용을 이해할 수 있었다. 이러한 접근 방식 덕분에 내용들이 친근하게 다가왔다. 또한, 깔끔하고 직관적인 책 디자인도 학습 효율을 높이는 데 큰 역할을 했다. 책의 구성이 체계적이어서 초보자들도 큰 부담 없이 차근차근 학습할 수 있었다.

구체적이고 직관적인 실습 내용

책에 담긴 실습 내용은 AWS 서비스를 이해하는 데 큰 도움이 되었다. 실습이 상당히 구체적이고 따라 하기 쉬워서 저자가 실습을 구성하는 데 많은 고민을 했겠다는 생각이 들었다. 예를 들어, 사진 공유 웹사이트를 만드는 과정을 통해 S3와 EC2 같은 서비스의 실제 사용법을 체득할 수 있었다. 이러한 실습은 단순히 개념적인 이해를 넘어 실질적으로 클라우드 기반 애플리케이션을 구현하고 운영하는 데 필요한 자신감을 주었다. 실습 과정에서 마주친 문제들도 저자가 제공한 가이드라인 덕분에 쉽게 해결할 수 있었다는 점이 인상 깊었다.

풍부한 그림 자료

이 책은 각 장에서 AWS 서비스의 동작 방식과 설정 과정을 이해하기 쉽게 그림과 다이어그램을 풍부하게 제공한다. 덕분에 독자가 복잡한 개념을 시각적으로 이해할 수 있었고, 책의 전반적인 접근성이 높아졌다. 예를 들어, IAM에서 사용자와 그룹을 설정하는 과정을 다이어그램으로 상세히 설명해 주어, 시각적인 자료 덕분에 이해도가 크게 높아졌다. 그림 자료가 부족하면 내용을 이해하기 어려웠을 부분도 쉽게 파악할 수 있었다.

간결하고 핵심적인 내용

이 책의 구성은 아래와 같다. 간결하고 핵심적인 내용만 다루면서도 다양한 서비스를 다뤘다.

클라우드 컴퓨팅과 AWS 기초(0~2장)

클라우드 컴퓨팅의 기본 개념과 AWS의 핵심 개념을 소개한다. 이를 통해 AWS를 처음 접하는 독자들도 쉽게 따라올 수 있도록 기초적인 배경지식을 제공한다. AWS의 탄생 배경, 주요 서비스의 역할, 클라우드 컴퓨팅의 장점 등을 다루며, 클라우드를 사용해야 하는 이유를 명확히 설명한다.

AWS 핵심 서비스 이해 및 실습(3장~8장)

AWS의 주요 서비스를 다룬다. EC2, S3, RDS와 같은 핵심 서비스부터 Auto Scaling, ELB, IAM 같은 인프라 및 보안 관리 서비스까지 폭넓게 설명한다. 각 장은 개념 학습 파트와 실습 파트로 구성되어 있어 독자가 주요 서비스의 개념과 필요성을 이해한 뒤 실제 AWS 환경에서 직접 실습하며 해당 서비스의 작동 원리와 사용법을 익힐 수 있도록 돕는다.

심화 서비스와 운영 관리(9장~15장)

AWS의 심화 서비스를 다룬다. CloudFront를 활용한 콘텐츠 전송 네트워크(CDN) 설정, Route 53을 통한 도메인 관리, DynamoDB와 같은 비관계형 데이터베이스 활용, Lambda를 사용한 서버리스 컴퓨팅 등의 고급 개념을 설명하며, AWS의 다양한 서비스가 어떻게 연동되고 운영되는지를 살펴본다.

프로젝트 실습(16장)

AWS를 활용하여 실제 웹 애플리케이션을 구축하는 프로젝트를 진행한다. 앞서 배운 모든 내용을 바탕으로 사진 공유 웹사이트를 만들면서 AWS의 다양한 서비스를 어떻게 통합적으로 사용할 수 있는지를 직접 경험해본다. 이를 통해 실무에 바로 적용할 수 있는 클라우드 애플리케이션 구축 능력을 키울 수 있다.실무에 바로 적용 가능한 내용

회사에서 자주 사용하는 IAM, S3, EC2, CloudWatch 같은 핵심 서비스에 대한 이해도를 높이는 데 큰 도움이 되었다. 이러한 서비스들이 실제 업무에서 어떻게 활용될 수 있는지 구체적인 사례와 함께 설명되어 있어서 실질적으로 바로 적용할 수 있었다.

테오콘(TEOConf 2024) 참가 후기

Wed, 27 Nov 2024 20:11:09 GMT

테오콘

작년 테오콘은 참석하지 못했는데 이번 테오콘은 스피커라서 100% 확률로 참석할 수 있었다. 😎 발표 준비를 하면서 테오님이 이 컨퍼런스를 열게 된 계기를 말씀해 주셨었는데 컨퍼런스가 끝나면 뭔가 열심히 들은 거 같은데 남은 게 없는듯한 기분으로 집에 돌아간 적이 많으시다고. 나도 실제로 컨퍼런스가 끝나고 공허한 상태에서 집에 간 적이 많았다. 머릿속은 발표 내용들로 꽉 찼는데 딱 거기까지였었다. 그래서 이번 테오콘이 기대됐다. 과연 이 문제를 어떻게 해결하실까 궁금했다.

네트워킹 중심의 컨퍼런스

테오콘은 철저히 네트워킹 중심의 새로운 포맷의 컨퍼런스였다. 우리는 정면을 바라보고 앉지 않고 원형 테이블을 중심으로 둥글게 앉았다.

우리는 모두 닉네임을 가지고 편하게 소통했다. 그리고 닉네임과 관심사가 적힌 멋진 명함도 받았다. 서로가 닉네임을 말하고 닉네임의 유래를 말하는데 정말 재밌었다. “주사위”를 좋아하시는 분도 계셨고 “이 세상의 중심은 나다”라는 의미의 닉네임을 가지신 분도 계셨다. 난 딱히 닉네임이 없어서 본명을 썼지만, 이 글을 쓰고 있는 시점에선 하나 만들었다. (드디어)

자리에 앉자마자 발표를 듣지 않았고 서로 친해질 수 있는 충분한 시간을 가졌다. 처음에는 “개발을 시작한 계기”, “삶의 목표”, “이성을 볼 때 중요한 것”을 서로 적어보고 얘기하면서 말문을 틀 수 있었다. 여기서 팀원들의 다양한 배경과 가치관을 알 수 있었다. 이런 스몰토크를 진행할 수 있는 MC도 팀에서 뽑았는데 유치원 교사를 하시다가 개발자가 되신 분이 계셔서 ‘아 이분이다’ 싶었다. 기대에 부응해서 진행을 너무 잘 해주셨다. 유치원생이 된 기분이었다. 👶🏻

서로 얼굴 그려주기 게임도 했는데 방식이 독특했다. 자신이 자주 쓰지 않는 손(난 오른손잡이니까 왼손)으로 그려야 했고 5초인가 동안 그리고 시계 방향으로 종이를 넘겨야 했다. 그렇게 모든 구성원이 짧은 시간 동안 불편한 손으로 그린 그림을 받을 수 있었는데 난 푸근한 군밤 같은 느낌으로 그려졌다.

같이 게임을 하면서 서로의 무시무시한 승부욕도 볼 수 있었다. 초성 게임도 하고 노래 맞히기도 했다. 꽤 많이 맞춘 것 같았는데 순위권에 들기엔 조금 부족했다. 😅

루키라는 분이 MC를 보셨는데 진짜 정말 재밌었다. 너무 잘하신다. 말이 안 된다고 생각했다. 그분도 분명 개발자실텐데.. 너무 멋졌다. 그래서 앞에 서로 친해질 수 있는 시간이 너무 빠르고 재밌게 흘러갔다.

네트워킹 세션

각 발표가 끝나고 네트워킹 세션을 통해 발표에 대해 팀원들과 의견을 나눌 수 있었다. 그게 정말 좋았다. 내가 듣고 느낀 것을 서로 나누는 그런 시간이 이전의 컨퍼런스에서는 빠져 있었던 것 같다. 이게 테오콘의 킥이었다고 생각한다. 나도 발표 준비를 하면서 네트워킹 질문들을 준비했는데 종이에 적혀 있는 내 질문을 보니까 기분이 신기했고 팀원들이 술술 얘기하는 걸 들으니, 질문도 잘 뽑았다는 생각이 들었다.

선물 교환식

선물 교환식도 너무 재밌었다. 만 원 이하의 선물을 준비해야 했는데 의미를 왕창 부여해도 되고 쓸데없는 걸 준비해도 됐다. 나는 앞날 창창 감성 LED 모던 수정구슬 침실 무드등을 준비했는데 굳이 의미 부여를 해보자면 우주의 중심 어쩌구 저쩌구..라고 할 수 있다!

나는 핸드워시를 받았는데 향도 좋았고 아주 유용하기도 했다. 마침 집에 있는 비누가 거품이 잘 안 나서 고민하고 있었는데 잘된 일이다.

테오님의 마무리

테오님이 좋은 말씀 해주시면서 마무리할 수 있었다. 말씀을 들으면서 다른 분들이 사전에 제출했던 고민들도 들을 수 있었고 그에 대한 테오님의 조언도 들을 수 있었다. 계속하는 고민이지만 내가 성장했다는 것을 어떻게 측정할 수 있는지, 나는 성장하고 있는지, 더 잘하려면 어떻게 해야 할지 등에 대해서 곰곰이 생각해 볼 수 있었다. 아직 많이 멀었다. 주말에 귀중한 시간을 내서 테오콘에 참여했던 많은 분과 좋은 에너지를 나눌 수 있어서 좋았다. 내년에도 가고 싶다.

소프트웨어 엔지니어 가이드북(The Software Engineers Guidebook) 리뷰 - 한빛미디어

Tue, 26 Nov 2024 00:12:23 GMT

“소프트웨어 엔지니어 가이드북”. 이 책이 나온다고 했을 때 꼭 읽어보고 싶었는데 운좋게 한빛미디어에서 제공받을 수 있었다. 이 책의 저자는 Pragmatic Programmers의 창시자인 게르겔리 오로스이다. 커리어를 시작한 단계부터 수석 엔지니어까지 커리어 전반에 걸친 포괄적인 가이드를 제공한다.

📑 책의 구성

이 책은 크게 6부로 구성되어 있다:

개발자 커리어의 기본 사항
유능한 소프트웨어 개발자
다재다능한 시니어 엔지니어
실용주의 테크리드
롤모델로서의 스태프 및 수석 엔지니어
결론

💡 주요 내용

1. 커리어 관리

엔지니어로서의 커리어 패스 이해
성과 평가 및 승진 전략
자신의 성과를 효과적으로 공유하는 방법

2. 기술적 역량 강화

효율적인 코딩 방법
문제 해결과 디버깅 기술
코드 품질 향상과 리팩토링

3. 협업과 리더십

코드 리뷰와 페어 프로그래밍
효과적인 멘토링
다양한 직군과의 협업 방법

4. 아키텍처와 시스템 설계

대규모 애플리케이션 구조 설계
신뢰성 있는 시스템 구축
성능 최적화 전략

🤔 개인적인 소감

이번에 셀리드를 맡으면서 어떻게 하면 더 잘 할 수 있을까 고민하고 있는데 업무에 적용해 볼 만한 포인트들이 많았다. 요즘에 서비스의 안정성을 높이기 위해 로깅 작업도 많이 해서 관심이 갔는데 좋은 내용들이 있었다. 로그에 어떤 내용을 담아야 좋은 로그가 되는지를 알려줬고 지금 내가 쌓고 있는 로그는 한참 부족하다는 것을 깨달았다. 개발자로서 설정할 수 있는 OKR에 대한 예시가 있는 것도 좋았다. 개발자는 평가를 어떻게 할지, OKR을 어떤 것으로 잡을지 사내 구성원들이 고민이 많았는데 예시를 보니 아이디어가 떠올랐다. 소프트 스킬에 대한 내용도 많이 강조됐다. 최근에 커뮤니케이션과 관련해서 발표했었는데 비슷한 내용이 책에 나와서 기뻤다. 목차 순서대로 주니어부터 시니어를 넘어서까지 포괄하고 있기 때문에 따라가며 읽기가 수월했다. 기나긴 커리어가 아직 한참 펼쳐질 것이라는 기대도 됐다.

📌 결론

이 책은 단순한 기술 서적을 넘어서는 포괄적인 가이드북이다. 특히 다음과 같은 독자에게 추천한다:

커리어 방향성을 고민하는 주니어 개발자
리더십 역할을 준비하는 시니어 개발자
체계적인 성장을 원하는 모든 소프트웨어 엔지니어

이 책은 계속 끼고 살아야 할 책이다. 이 책의 내용들을 체화한다면 정말 멋진 개발자가 되어 있지 않을까 싶기도 하다. 하나씩 체화해 볼 생각에 설렌다.

한빛미디어 <나는리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다.

[I in We x AWS] Mentoring Program 2024 후기

Sun, 24 Nov 2024 08:11:53 GMT

[I in We x AWS] Mentoring Program 2024 후기

이번달은 유난히 바빴다. 항상 일을 벌여 놓으면 한번에 몰려 오더라. 컨퍼런스 발표 준비와 멘토링이 겹치니 한달동안 퇴근 후에도, 주말에도 카페에 가면서 달렸다. 멘토링 시작할 때 쯤에 자취생의 야매요리도 시작했는데 그것도 이젠 잠시 쉬고 있다.

💡 드디어 고민 해소

정신없이 하루하루를 보내다가 멘토링 초중반 쯤에 글또(개발자 글쓰기 모임) 9기가 끝났을 때가 생각났다. 2주에 글 하나씩 쓰는 것도 벅차서 커피챗도 많이 못하고 모임도 못 나갔던 게 아쉬웠는데, 이번 멘토링도 그렇게 흘려 보내고 싶지 않았다. 그런 생각을 하던 찰나에 멘토님께서 중요한 말씀을 해주셨는데 그 말씀 덕분에 멘토링에 임하는 태도를 크게 바꿀 수 있었다. 더 적극적으로, 더 치열하게 고민할 수 있었고 멘토링을 시작하기 전에 했던 묵혀뒀던 많은 고민들을 해소할 수 있었다.

가장 큰 고민은 ‘내가 지금 잘 하고 있는가’ 였다. 누구나 할 수 있는 고민일거 같은데 해소하기가 참 어려웠다. 그래서 컨퍼런스 네트워킹 세션에 가서도 비슷한 연차의 개발자들과 얘기해보고 싶었는데 그런 사람을 만나기가 쉽지 않았다. 다행히 이번 멘토링을 통해서 나를 객관화해 볼 수 있는 방법을 배웠다.

🙋‍♂️ 멋진 멘토님

SungHyun Lim 멘토님은 정말 멋진 분이시다. 정말 도움이 되는 말씀들을 많이 해주셔서 좋았고 멘티들의 목소리 하나하나에 귀기울여 주셔서 좋았다. 보통의 멘토링의 경우 멘티 한명 한명의 뾰족한 고민들을 해소하기가 쉽지 않았는데 그걸 해주셨다. 최근에 발표 준비를 하면서 어떤 분이 다른 분에게 피드백해주신 내용을 간접적으로 들을 수 있었는데 “자신이 하고 싶은 말과 청자가 듣고 싶은 말을 균형있게 하는 게 중요하다” 였다. 딱 그걸 멘토님께서 해주신 것 같다. 온라인 멘토링을 할 때마다 하나하나 주옥 같은 말씀에 머리가 띵했고 시간이 너무나도 짧게 느껴졌다. 난 왜 이렇게 모르는 게 많을까 싶기도 했고. 이제서야 알았다는 사실에 다행이기도 싶었다. 커뮤니케이션도 너무 잘하시고 경험도 풍부하셔서 닮고 싶다는 생각이 자연스럽게 들었다. 그리고 나중에 멘토님처럼 다른 사람들을 돕고 싶다는 생각도 들었다.

👥 멋진 멘티님들

다양한 배경의 멋진 멘티님들과도 함께 할 수 있어서 좋았다. 한분 한분 다 멋지셔서 배울점이 있다는 생각이 들었다. 온라인 멘토링 때는 얘기를 많이 못 해봤지만 이번 목요일에는 얘기를 해 볼 수 있을 거 같아서 기대된다 :)

📚 스페셜 세션

좋은 내용의 스페셜 세션들도 많이 준비되어 있어서 좋았다. 나는 그중에 Amazon의 10가지 개발문화 세션이 도움이 많이 됐는데, 문서에 집중하고 문서로 소통한다는 내용이 특히나 인상깊었다. 문서를 잘 작성하지 못하는 나도 한번 따라해 봐야겠다는 생각이 들었다.

✅ 멘티 미션들

다른 팀의 멘토, 멘티님들도 간접적으로 노션 페이지에서 만날 수 있었고 알아가는 게 즐거웠다. 준비된 미션을 하나하나 따라가다 보니 어느새 멘토링이 끝났다.

나는 이 멘토링이 터닝 포인트가 되지 않을까 생각하고 있는데, 몇년 후에 다시 돌이켜봐도 이 멘토링이 터닝 포인트였다고 생각하지 않을까 싶다. 좋은 프로그램 준비해주신 유성실님, Olivia Son님과 다른 운영진 분들께도 너무 감사드린다. ☺️

TEOConf 2024 발표 후기

Sun, 24 Nov 2024 08:11:13 GMT

출처: TEOConf 2024

테오의 컨퍼런스(TEOConf) 3회차에 드디어 발표했다! 발표했던 소감과 발표 준비 과정을 적어보려고 한다. 이 글에서 발표 준비는 어떤 식으로 이루어졌고 이런 부분에선 도움을 좀 받을 수 있겠구나 하는 점들을 전달하고 싶다.

발표

"출근해서 바로 써 먹을 수 있는 커뮤니케이션 팁"이라는 주제로 발표했다. 생산성에 관심이 많은 나는 커뮤니케이션을 잘해서 나의 시간, 팀원들과 시간을 아끼고 싶었는데 커뮤니케이션을 잘해보려는 시행착오를 겪으며 좋았던 점들을 8가지 팁으로 정리했다. 거창한 주제는 아니지만 내 경험이 조금이나마 도움이 됐으면 하는 마음에서 발표했다.

발표하고 자리로 돌아와서 조원들과 얘기하는데 공감이 가는 부분이 많다고 해주셔서 뿌듯했다.

한 분은 비슷한 사례를 겪은 적이 있다고 자기 경험을 공유해주셨고
다른 분은 팁을 하나씩 들을 때마다 모두 공감 가는 얘기여서 지난 경험을 떠올리며 들었다고 해주셨다.
같은 조였던 내 친구는 실제 사례가 있으니 이해하기가 훨씬 쉽고 재밌었다고 했다. 마음 같아선 회사 벽에 팁을 인쇄해서 붙여놓고 싶다고 했다. 😅

모든 분의 의견을 들을 수는 없었지만 그래도 최소한 우리 조에서 이렇게 도움이 됐다고 해주셨으니, 전반적으로 도움이 됐을 거라는 생각이 들었다.

어떻게 이 발표를 준비했나

도전하기

테오의 컨퍼런스 3회차 스피커 모집을 보고 신청했다. 많은 사람들 앞에서 오프라인으로 발표하는건 너무나 긴장되는 일이지만 도전하고 싶었다. 처음에 생각했던 제목은 “비개발직군과의 소통, 한 걸음 더 나아가기”였다. 회사에서 FE 개발자로 일하는 나는 비개발직군 팀원들과 소통을 많이 해야 했고 잘하고 싶은 마음에 이것저것 시도해 본 것을 공유하고 싶었다.

피드백

그렇게 준비했고 테오님과 온라인 미팅을 하면서 피드백을 받았다. 그때 나는 말을 제대로 못했다. 무슨 의미냐면, 이런 주제로 발표해야겠다는 생각은 했지만, 내용을 제대로 구체화하지 않아서 머릿속에 떠다니는 생각을 그 자리에서 설명하려고 하니까 테오님에게 제대로 내용이 전달되지 않았다. 테오님이 그 생각을 구체화할 수 있게 많이 도와주셨지만 나도 내가 하고 싶은 말을 정확히 전달할 수 없어서 답답했었다. 그래서 미팅이 끝나고 발표를 준비할 때 최대한 실제 사례를 가져오려고 노력했다. 그리고 주제도 바꿨다. 내가 전하고 싶은 내용이 꼭 비개발직군 팀원들과 소통할 때만 적용되는 내용은 아닌 것 같아서 더 보편적인 제목으로 바꿨다.

리허설

발표 한 달 전에 오프라인 리허설을 했다.

출처: 테오의 프론트엔드 디스코드

테오님과 솔싹님(스태프), 병스커님(스피커)를 만날 수 있었다! 3명 앞에서 발표하는데도 많이 긴장됐다. 하지만 엄청나게 몰입해서 들어주셔서 어느새 긴장감은 사라졌다. 이때 ppt의 내용을 채우는 것조차 힘들어서 정말 러프하게 내용만 있는 ppt를 가지고 발표했다. 이번에는 아무래도 실제 사례를 많이 들고 왔다 보니까 전달하고자 하는 바가 명확했고, 주제가 유니크하기도 하고 많이 공감할 수 있는 주제이기 때문에 더 재밌다고 해주셨다. 세 분이 너무나 좋은 피드백을 많이 해주셨는데 꼭 반영해야겠다 생각했던 것들을 꼽아봤다.

핵심 키워드인데 장표에 담겨 있지 않은 경우 -> 장표에 넣어주기
강조할 점 볼드처리하거나 색상 바꾸기
팁이 여러 개여서 상단에 진행 상황을 보여주는 게 있으면 좋겠다.
발표 톤이 기술 세미나 하는 톤이어서(말끝을 “습니다."" 라고만 끝냈음 😅) 아쉽다. 팁을 주고 있는 입장이기 때문에 자신 있는 강사 톤이었으면 좋겠다.
팁을 먼저 제시하기보다는 사례 탐구 식으로 사례 -> 팁 순서로 하면 좋겠다.
HOW가 부족하다. 실제로 어떻게 적용해 볼 수 있는지 구체적인 문장이 팁이 됐으면 좋겠다.

장표는 거의 새로 만드는 수준으로 많이 바꿨고 시간도 엄청나게 오래 걸렸다. 발표 전주에 오늘은 끝내야지 오늘은 끝내야지 하다가 안 끝나서 주말에 겨우겨우 끝낼 수 있었다.

이렇게 피드백해 주시는 내용들이 너무 좋았다. 아마 이 피드백들이 없었다면 발표나 장표 퀄리티가 엄청 안 좋았을 것이라고 확신한다. 많이 도와주셔서 너무 감사했다.

연습 또 연습

나는 발표할 때 사람 눈을 마주치면 그렇게 머리가 하얘지더라. 그리고 발표자 노트를 안 보고도 잘 해내고 싶어서 연습 또 연습했다.

다음에 발표를 또 한다면

발표 준비 과정도 그때그때 글로 남기면 좋겠다 싶다. 지금 이 글을 쓰고 있는 시점에서 회상하려고 하니까 역시나 잘 생각이 나지 않는다. 🫨

리허설을 한 달 전에 빠르게 해보는 건 너무나 좋았다. 다음에도 그렇게 하고 싶다. 리허설을 빠르게 하지 않았다면 나는 아마 발표 전날까지도 ppt를 만들고 있었을지도..

같은 내용으로 다른 데서 발표해 보는 것도 좋겠다는 생각이 들었다.

발표하고 싶지만 머뭇거리고 있는 당신! 바로 신청하시죠

발표자료 링크

textarea를 감싸는 div에 여백이 생겨버리는 이유

Sun, 10 Nov 2024 10:11:03 GMT

개발을 하다가 단순히 textarea 하나만을 감싸는 div의 높이가 textarea보다 더 큰 문제가 있었는데 개발자도구로 요리보고 저리봐도 원인을 찾지 못했다. 마치 투명한 뭔가가 사이에 끼어 있는 것 같았는데 이 답답함을 말로 형용할 수 없었다. 이걸 뭐라고 검색해야 할지조차 몰라서 영원한 친구 ChatGPT에게 물어보고 실마리를 찾을 수 있었다.

코드는 다음과 같다. 정말 간단하다.

<div>
  <textarea></textarea>
</div>

생기는 여백을 더 쉽게 보기 위해 아래 codepen을 추가했다.

See the Pen Untitled by Donghoon Song (@donghoon759) on CodePen.

분명히 두 태그 사이에는 아무런 여백이 없는데 textarea를 감싸는 div의 높이가 textarea보다 더 크게 나타나는 문제가 있었다.

원인

이런 현상은 textarea의 기본 display 속성이 inline-block이기 때문에 발생한다. inline 또는 inline-block 요소 사이에 생기는 여백 또한 예상치 못했던 문제 상황이었는데 이 이슈는 inline-block 요소의 수직 정렬 방식 때문에 발생한다.

수직 정렬 문제와 descender 공간

inline 또는 inline-block 요소는 텍스트와 같은 방식으로 수직 정렬이 이루어진다. 기본적으로 vertical-align 속성이 명시되지 않으면, 요소는 부모 요소의 기준선(baseline)에 맞춰진다.

기준선(baseline): 텍스트에서 소문자 ‘x’의 하단에 해당하는 가상의 선으로, 대부분의 문자들이 이 선 위에 위치한다.
descender: ‘g’, ‘p’, ‘q’와 같이 기준선 아래로 내려오는 문자 부분을 말한다. 이러한 문자들을 고려하여 텍스트의 하단에는 약간의 여백이 필요하다.

textarea 내부에 텍스트가 없어도 브라우저는 descender가 입력될 때를 대비해서 미리 공간을 확보해 놓는다. 이로 인해 textarea의 높이가 예상보다 크게 나타나는 것이다.

descender라는 개념은 font metrics와 관련이 있다.

해결 방법

가장 간단하고 직관적으로 해결하는 방법은 textarea의 display 속성을 block으로 변경하는 것이다. 이렇게 하면 textarea는 블록 요소로 취급되어 수직 정렬 이슈가 사라진다. 블록 요소는 자동으로 새로운 줄에서 시작하고, 전체 가로 너비를 차지하므로 추가적인 여백이 제거된다.

textarea의 vertical-align값을 top이나 middle로 수정하는 방법도 있다. 이렇게 하면 textarea의 display속성을 바꾸지 않고 해결할 수 있다.

textarea {
  vertical-align: top;
}

비슷한 문제

이미지 태그를 사용할 때도 비슷한 문제가 발생한다. 이미지 아래에 불필요한 여백이 생기는데, 이것도 이미지가 inline 요소이기 때문에 발생하는 문제이다. 이런 경우에도 이미지의 display 속성을 block으로 변경하거나 vertical-align 속성을 수정하면 해결할 수 있다.

img {
  display: block;
  /* 또는 */
  vertical-align: bottom;
}

정리

정리하자면 textarea를 감싸는 div의 높이가 예상보다 크게 나타나는 문제는 inline-block 요소의 수직 정렬 방식과 descender 공간 때문에 발생한다. css의 세계는 무궁무진하고 공부해야 할 것들이 정말 많은 것 같다.

참고

vertical align: MDN

이미지 출처

w3.org

마무리가 약한 나의 마무리

Sun, 13 Oct 2024 16:10:54 GMT

서울국제도서전에 다녀왔던 적이 있다. 많은 부스가 있었지만 커다란 벽에 자기만 알고 있는 동네 서점을 소개하는 공간이 있었다. 지금은 사라진 곳도 있고 엄청 큰 서점도 있고 아주 다양한 서점을 담고 있는 포스트잇들이 붙어 있었다. 지금은 사라졌지만 어릴적 아버지가 운영했다는 서점도 있었고 친구들과의 추억이 담긴 서점도 있었다.

서울국제도서전에 다녀왔던 적이 있다. 많은 부스가 있었지만, 특히 내 눈길을 끈 건 커다란 벽에 사람들이 자기만 알고 있는 동네 서점을 소개하는 공간이었다. 벽에는 각기 다른 사람들의 이야기가 담긴 포스트잇들이 빼곡히 붙어 있었다. 지금은 사라진 서점도 있었고 한 참가자는 어릴 적 아버지가 운영했던 서점이라고 적어 놓았다. 또 다른 사람들은 친구들과의 추억이 깃든 서점을 공유하며 그 순간의 특별함을 나누었다. 지금은 볼 수 없는 작은 서점도 있었고, 이미 유명해진 대형 서점도 있었다. 이 다양한 서점들을 보면서 문득 이런 서점들을 모아볼 수 있는 공간이 있으면 얼마나 재미있을까 하는 생각이 들었다. 게다가 이런 서점들은 기존 지도 앱에서는 찾아보기 힘들 것이다. 그렇게 나는 작은 아이디어에서 출발해 지도 앱을 만들기 시작했다.

이렇게 나는 충동적으로 프로젝트를 시작하는 데 능숙하다. 나에게 작업했던 다른 사이드 프로젝트들도 많다. 그러나 문제는 마무리를 잘 짓지 못한다는 점이다. 프로젝트의 초반에는 열정적이지만, 시간이 지나면서 동기가 약해지거나 더 재미있어 보이는 새로운 아이디어가 생겨서 기존 프로젝트를 끝내지 못하고 중단하게 된다. 특히 이번에도 어김없이 여러 가지 생각들이 머리를 스쳐 지나갔다. 그중 가장 큰 고민은 역시나 ‘내가 이걸 만든다고 해서 사람들이 정말 사용할까?‘라는 의문이었다. 나는 내가 만든 서비스가 사람들에게 유용하게 사용되길 바라는 마음이 크다. 하지만 이러한 기대감이 오히려 나를 주저하게 만들었다는 것을 깨닫게 되었다.

이번에는 이러한 마음을 이겨내기로 했다. 이런 마음 때문에 마무리하지 못한 프로젝트들이 얼마나 많은지 알기 때문이다. 처음부터 사람들이 사용해 줄 거라는 욕심과 기대는 버리기로 했다. 대신 이 프로젝트들을 끝까지 완성하면서 배우려는 자세로 임하기로 했다. 생각해 보면, 애초에 내가 홍보하지 않는 한 내가 만든 서비스를 사람들이 알지 못할 것이다. 그렇다면, 사용자에 대한 기대보다 내가 무엇을 배울 수 있을지에 집중하는 것이 더 의미 있을 것이다. 회사에서는 다루지 않는 기능을 구현하고, 마주치지 않는 문제들을 해결해 나가면서 경험을 하나씩 쌓아가는 것이 훨씬 더 중요한 자산이 될 것이라고 생각했다. 그렇게 하나의 프로젝트를 완성하고 경험을 쌓아가는 과정이 나중에는 진정으로 사람들이 원하는 서비스를 만드는 데 큰 도움이 될 것이라는 생각이 들었다.

나는 또한 배포 과정에서 생기는 문제들을 빨리 마주하는 것을 선호한다. 보통은 프로젝트가 완전히 끝난 후에 배포하는 경우가 많지만, 나는 되도록 빨리 배포하는 편이다. 왜냐하면 배포 과정에서 항상 예상치 못한 문제가 발생하기 때문이다. 빌드 에러가 그중 하나다. 개발 중에는 전혀 보이지 않던 타입 에러들이 빌드할 때 한꺼번에 드러나는 경우가 많다. 그래서 나는 이런 에러들을 빨리 발견하고 수정하는 것이 마음이 편하다. 무엇보다도 배포를 완료했을 때 비로소 내가 이 프로젝트를 만들었다는 실감이 난다. 로컬에서 혼자 개발하는 것과 실제로 다른 사람들도 볼 수 있게 배포하는 것은 큰 차이가 있다. 그래서 배포를 완료하는 것이 나에게는 프로젝트의 하나의 마무리이자 동시에 진정한 시작이라고 느껴진다.

이번 지도 앱 프로젝트에서도 지도 API를 처음 사용해 보면서 여러 문제에 부딪혔다. 처음 접하는 기술을 사용하다 보니 막히는 부분도 많았지만, 그 과정을 통해 정말 많은 것을 배울 수 있었다. 결국 나는 광활한 인터넷에 또 하나의 작은 씨앗을 심었다. 그렇게 나만의 독립 서점 지도 웹앱이 탄생했다. 이 프로젝트는 단순히 한낱 사이드 프로젝트로 끝나는 것이 아니라, 나에게 있어서 의미 있는 배움의 과정이었다.

https://indie-bookstore.vercel.app/

이번 프로젝트가 나의 터닝 포인트가 됐으면 좋겠다. 이전에 같은 이유로 관뒀던 프로젝트들도 다시 들여다보고 세상에 내보이고 싶다.

그림으로 이해하는 서버 구조와 기술 리뷰 - 길벗

Mon, 30 Sep 2024 21:09:33 GMT

정말 쉬운 네트워크 책

이 책은 정말 쉽습니다. 복잡한 개념을 시각적으로 쉽게 이해할 수 있도록 돕는 213개의 그림과 17개의 표를 활용합니다. 어려운 용어나 전문적인 설명을 최소화하고, 대신 일상적인 비유와 실용적인 예시를 통해 서버의 역할, 운영체제, 네트워크 장비의 기능을 설명합니다. 예를 들어, TCP/IP 모델을 설명할 때, 각 계층의 기능을 마치 우편 배달 시스템처럼 단순화해 설명하는 방식은 큰 도움이 됩니다. 여러번 읽어도 기억에 잘 남지 않았던 TCP/IP의 각 계층별 역할도 택배에 비유해서 설명해주는데 이해가 잘 됐습니다.

작고 가벼운 책

보통 네트워크 책이라고 하면 500쪽 정도 되는 들고 다니기도 힘든 무거운 책이 대부분인데 이 책은 정말 가볍습니다. 가방에 넣고 다니면서 자투리 시간에 읽기에도 딱 좋습니다. 이 책이 제가 대학생 때 나왔다면 네트워크 개념을 더 쉽게 이해할 수 있었을 것 같은데 아쉽습니다. 책을 읽으면서 알고 있던 개념은 쉽게 리마인드하고 새로운 개념들은 빠르게 이해할 수 있었습니다.

다양한 주제

책이 가볍지만 정말 다양한 주제를 다룹니다. 처음에는 서버와 클라이언트 등 기본 개념을 설명하고 서버의 종류, 요구사항, 다양한 구성, 보안, 장애 대응 기술 등 실무에서 사용되는 개념들도 설명합니다. 그래서 단순한 입무서를 넘어 서버와 네트워크의 전체적인 흐름을 이해하는데 아주 유용합니다. 1장에서는 서버, 클라이언트 등 기초 지식을 배웁니다. 2장에서는 네트워크를 배우며 OSI 참조 모델, TCP/IP 등 데이터 전송을 이해하는데 중요한 개념들을 배웁니다. 3장에서는 서버 형태를 배우며 우리가 흔히 사용하는 클라우드형 서버에 대해서도 배웁니다. 온프레미스, 클라우드, 하이브리드 등의 형태를 배우고 각 형태의 장단점을 배웁니다. 4장에서는 웹 서버, DNS 서버 등 외부용 서버를 배웁니다. 5장에서는 파일 서버, 프린터 서버 등 내부용 서버를 배우고 6장에서는 서버 보안에 대해서 배웁니다. 방화벽과 SSL, VPN의 개념이 등장합니다. 후반부인 7장에서는 서버 장애에 대비하는 기술들을 배우며 8장에서는 서버 운용에 대해서 배웁니다.

결론

이미 네트워크 개념을 알고 있지만 빠르게 정리하고 싶은 분들에게도 좋고 두껍고 어려운 네트워크 책은 소화하기 힘든 입문자분들에게도 좋겠다는 생각이 들었습니다.

두부의 캐릭터 드로잉 리뷰 with 프로크리에이트 - 한빛미디어

Sun, 29 Sep 2024 20:09:33 GMT

“두부의 캐릭터 드로잉 with 프로크리에이트”는 프로크리에이트를 활용한 캐릭터 드로잉 기법을 다룬 책입니다. 이 책은 디지털 드로잉을 처음 시작하는 사람들을 위해 프로크리에이트의 기초부터 나만의 캐릭터와 굿즈를 만드는 방법까지 단계별로 설명하고 있습니다. 취미로 귀엽고 아기자기한 캐릭터를 그려보고 싶으신 분들에게 추천하는 책입니다. 책의 후반부에는 만든 작품을 굿즈로 발주하는 과정도 담겨 있어서 굿즈에 관심이 많으신 분들에게도 추천할 수 있습니다.

1장에서는 프로크리에이트의 기본적인 기능을 익히고 간단한 드로잉을 합니다. 2장에서는 동물 캐릭터를 그리기 위한 이론들(얼굴형, 특징 파악하기 등)을 배웁니다. 작가님이 준비해주신 프리셋 파일이 있어서 편하게 참고할 수 있습니다. 3장에서는 그렸던 캐릭터들에 표정, 동작을 추가합니다. 그 외에 음료를 잡고 있거나 돗자리 위에 앉아 있거나 하는 등 다양한 상황에서의 드로잉 방법을 배웁니다. 4장에서는 채색 개념부터 시작해서 개념을 토대로 채색하는 팁을 배웁니다.

저는 그림을 정말 못 그리는데 책을 읽고 천천히 따라가다보니 너무 재밌고 아기자기한 캐릭터들을 그릴 수 있어서 좋았습니다. 저같은 경우에는 사이드 프로젝트에서 사용할만한 캐릭터를 그려보고 싶어서 읽었는데, 책을 읽고 나니 굿즈로 만들어서 나만의 캐릭터를 만들어보고 싶은 생각이 들었습니다. 그리고 프로크리에이트가 엄청 사용하기 편하다는 생각이 많이 들었습니다. 손가락 두개로 터치하면 실행취소, 세개로 터치하면 다시 실행인데 그 외에도 사용자를 고려한 기능들이 많아서 사용하기 편했습니다.

“한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다.”

실무로 통하는 클린 코드(한빛미디어) 리뷰

Tue, 27 Aug 2024 21:08:20 GMT

25장, 200가지 이상의 예시로 이루어진 이 책은 백과사전 같은 느낌을 줍니다. 내용이 방대해 읽을 엄두는 안 나지만 컴퓨터 옆에 놓고 필요할 때마다 참고할 수 있는 든든한 동반자 같은 느낌을 줬습니다. 큰 업무를 작게 나누듯 패턴들을 한번에 이해하기 부담없는 작은 단위들로 나눠놨습니다. 그리고 대부분의 클린 코드 책이 Java코드를 예제로 사용했는데 이 책은 python, javascript, c++ 등 다양한 언어를 사용해서 읽을 때마다 환기되는 느낌이었습니다. 그 외에 특히 도움이 됐던 내용들을 나열하면 다음과 같습니다.

기본형 데이터 구체화하기

이 챕터를 읽고 나니 기본형 타입을 많이 썼던 것 같습니다. 아래와 같은 식으로 작성하면 ‘무엇’과 ‘어떻게’를 명확하게 분리할 수 있습니다.

Port server = Port.parse(this, "www.example.org:8080");

Port in = server.open(this);
URI uri = server.asUri(this);
InetSocketAddress address = server.asInetSocketAddress();
Path path = server.path(this, "/index.html");

삼항식 제거

중첩된 삼항식을 피하는 부분도 좋았습니다. 한 줄에 쓰기 간결해서 삼항식도 자주 작성했지만 시간이 지날수록 코드를 이해하는데 시간이 더 드는 느낌이 강했습니다.

주석을 테스트로 대체하기

새로운 함수를 작성하면 주석을 작성하는 일이 많아졌습니다. 하지만 이를 테스트 케이스로 남기면, 함수의 동작을 더 정확하게 보장할 수 있고 읽는 사람도 이해하기 더 쉬울 것 같습니다.

전제 조건 적용하기

성능에 심각한 문제가 있지 않는 한, 어서션을 제대로 구성합니다. 데이터가 정상적인 범위 내에 있을 거라는 확신을 버리고 예외 케이스에 대해서 예외 처리를 항상 해서 빠르게 실패하는 편이 오히려 데이터 손상을 찾는 빠른 길이라는 것을 배웠습니다.

총평

디자인 시스템 책은 내용이 방대하기 때문에 읽고 지나치는 등 적용하지 못했던 경우가 많았습니다. 이 책을 읽고 나니 알고 있던 내용들은 환기가 되고 새로운 내용 또한 도움이 많이 됐습니다. 앞으로는 각 항목에 대해 활용 사례를 같이 적으면서 천천히 적용해보려고 합니다.

자바스크립트 리액트 디자인패턴(한빛미디어) 도서 리뷰

Mon, 26 Aug 2024 19:08:34 GMT

자바스크립트+리액트 디자인 패턴

자바스크립트+리액트 디자인 패턴은 최신 자바스크립트 디자인 패턴과 함께 리액트에서 적용할 수 있는 패턴까지 광범위하게 다룹니다.

디자인 패턴은 왜 디자인 패턴인가

이 책은 보통의 디자인 패턴 책들과 다르게 앞장에서 스스로 생각해 볼 거리들을 많이 던져줍니다.

1장에서는 디자인 패턴을 개념적으로 어떻게 정의하는지 설명합니다. 디자인 패턴을 그냥 받아들이던 저에게 패턴에 대해 생각해 볼 수 있는 질문을 던질 수 있었습니다. 그리고 2장과 3장에서는 좋은 패턴은 어떤 특성을 가지는지 설명합니다. 수없이 탄생하는 패턴들로부터 어떤 패턴이 살아남아 우리가 공부하고 있는지, 그리고 왜 그 패턴이 살아남았는지에 대해 생각해 볼 수 있었습니다. 4장에서는 우리가 피해야 할 안티 패턴을 제공해 좋은 패턴과 비교해볼 수 있었습니다.

리액트 디자인 패턴

12장부터는 리액트 디자인 패턴을 배웁니다. 고차 컴포넌트 패턴으로 시작해서 Hooks 패턴으로 진행하면서 기존 패턴의 문제점은 이후에 나오는 패턴이 어떻게 해결하는지를 배울 수 있었습니다. 또한, 로더블 컴포넌트, PRPL 패턴 등 리액트 애플리케이션의 성능도 챙길 수 있는 방법들을 배웠습니다.

성능 최적화

실용적인 팁들이 많이 나와서 좋았습니다. 예를 들어, preload를 사용하는 것까진 알고 있었는데 FCP 또는 LCP에 필요한 리소스의 로딩이 지연되는 것과 트레이드 오프라는 것을 생각해야 한다는 것을 배웠습니다.

구성상 좋았던 점

내용을 정리할 때 표를 함께 첨부해서 배웠던 개념들을 한눈에 비교할 수 있는 게 좋았습니다.

한 개념에 대해 내용이 길지가 않아 짧게 나눠서 부담없이 나눠서 공략하기가 쉬웠습니다.

“한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다.”

혼자 해도 프로처럼 잘 만드는 굿즈 제작 비법 리뷰

Sun, 28 Jul 2024 15:08:27 GMT

출처: 한빛

굿즈를 제작하려고 할 때 드는 막막함들이 있습니다. 스마트폰으로 업로드한 이미지를 PC로 봤을 때 색상이 왜 달라 보이는지 그 이유도 모르겠고, 마음먹고 제작하려는데 굿즈를 제작할 수 있다는 사이트들(인쇄소들)에 들어가보니 모르는 용어들의 나열이라 포기한 적이 있습니다.

굿즈제작비법 책에서는 굿즈를 만들려고 마음을 먹어봤지만 어려워서 힘들어하고 있는 사람들에게 필요한 내용들이 들어있는데요. 특히, 이런 책들은 단순한 정보의 나열인 경우가 많은데 이 책은 굿즈를 처음 제작하는 사람들에게 필요한 정보를 순서대로 제공하는 점이 좋았어요. 의식의 흐름을 읽고 있는 것처럼 “이건 뭐지?”라는 의문이 드는 순간 정보가 나와서 놀랐습니다.

책의 초반부에서는 굿즈 제작에 필요한 순서를 상세히 설명하고, 만들고 싶은 굿즈별 추천 제작 업체 리스트도 포함되어 있어요! 많은 업체들 중 빨간고래님의 경험으로 선정한 업체들이라 믿음도 갑니다. 또 반드시 일러스트와 포토샵을 사용해서 제작하라고 나와있는데, 프로크리에이트만을 사용하지 않는 이유에 대한 설명도 잘나와있어요.

특히나 중간중간 적혀있는 실무 꿀팁에 도움되는 내용들이 많았습니다! 예를 들어, 종이에 작품을 인쇄하는 경우 포토샵을 사용하는 것이 좋고, 패브릭이나 화지에 인쇄하는 경우에는 프로크리에이트도 품질 차이가 나지 않기에 사용해도 좋다는 실무적인 팁들이 있습니다. 책의 중반부에는 각 굿즈별 포토샵과 일러스트를 활용해 만드는 상세 과정, 프로그램 기능 설명들에 대한 내용이 나와있습니다. 책에 담기 어려운 내용들 (실제 인쇄소에서 만들어져 나온 굿즈 검수하는 과정들)은 QR로 바로 동영상 시청이 가능한 점도 좋았습니다.

후반부에는 일러스트페어에 대한 내용도 있어요! 일러스트페어가 유명하지만 그들만의 세계같고 어려운데 정말 자세히 나와있어요. 어디서 신청을 받고, 얼마나 걸리고, 어떤걸 준비해야하는지에 대한 내용이 전부 나와있습니다. 심지어 빨간고래님이 일러스트 페어에서 평균 어느정도 벌었는지에 대한 현실적인 정보도 제공해주십니다.

마지막엔 인쇄에 대한 자세한 정보들이 나열되어있는데 종이에 대한 궁금증을 해결해주는 다양한 지류 설명도 포함되어 있습니다. 저는 종이에 관심이 많아 이 부분을 관심있게 보았는데, 띤또레또와 같은 고급 종이에 대한 설명이나 리소그래프 인쇄 등 다양한 인쇄 방법도 다루고 있습니다. 몰랐던 인쇄 용어들도 많았습는데요. ‘오시’는 인쇄물을 접어야 하는 경우 누름자국을 넣어주는 것, ‘미싱’은 티켓처럼 점선으로 쉽게 뜯을 수 있게 해주는 것, ‘형압’은 올록볼록한 느낌을 주는 인쇄 기법 등 다양한 인쇄 용어에 대해 상세히 설명하고 있습니다.

이미 경험이 있는 사람이 읽어도 좋지만, 처음 굿즈 제작을 시도하는 사람에게 너무 추천하는 책이에요! 독자를 고려한 책의 흐름과 현실적인 팁들이 중간중간에 포함되어 있어 당장 굿즈를 만들고 싶을 때 바로 실행이 가능할만큼 많은 도움이 됩니다. 굿즈 제작에 관심이 있다면 꼭 한 번 읽어보길 추천합니다!

컨텐츠에 따라 높이가 자동으로 조절되는 textarea 구현하기

Sat, 13 Jul 2024 16:08:37 GMT

높이가 컨텐츠에 따라 조절되는 textarea는 다음과 같이 구현합니다. 원리는 다음과 같습니다.

사용자가 값을 입력할 때마다 height를 ‘auto’로 설정하여 scrollHeight가 컨텐츠 높이만큼 만듭니다.
그 scrollHeight값을 height에 반영합니다.
높이가 늘어나더라도 스크롤바가 생기지 않도록 overflow를 hidden으로 설정합니다.
사용자가 수동으로 크기를 조절하지 못하게 하기 위해 resize를 none으로 설정합니다.

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Auto-resizing Textarea</title>
    <style>
      textarea {
        width: 100%;
        box-sizing: border-box;
        overflow: hidden; /* 스크롤바 숨김 */
        resize: none; /* 사용자가 수동으로 크기 조절하지 못하게 함 */
      }
    </style>
  </head>
  <body>
    <textarea
      id="autoResizeTextarea"
      rows="1"
      oninput="autoResize(this)"
    ></textarea>
    <script>
      function autoResize(textarea) {
        textarea.style.height = 'auto' // 높이를 자동으로 초기화
        textarea.style.height = textarea.scrollHeight + 'px' // 스크롤 높이에 맞게 높이 설정
      }
    </script>
  </body>
</html>

ChatGPT랑 비슷한 File Input 컴포넌트 구현하고 react-hook-form에 연동하기(파일 누적 관리하기)

Thu, 11 Jul 2024 21:08:00 GMT

오늘은 ChatGPT에서 사용하는 파일 인풋을 유사하게 구현했습니다. ChatGPT에서는 파일을 입력할때마다 업로드를 하기 때문에 실제 처리 방식은 다르지만 파일들을 모아서 한번에 업로드 해야 한다고 가정했습니다. 즉, 여러 파일을 선택하고 폼에 누적해서 관리하는 기능을 구현했습니다. 아래에 ChatGPT의 인풋 컴포넌트를 가져왔습니다.

구현사항

파일을 입력하면 미리보기로 보여줬습니다.
기존 file input과 다르게 파일을 여러번에 걸쳐 추가로 입력해도 누적이 되도록 했습니다.
react-hook-form을 연동하여 form을 관리했습니다.

import React, { useState } from 'react'
import { useForm, Controller } from 'react-hook-form'

const FileInputForm = () => {
  const { handleSubmit, control, setValue, getValues } = useForm()
  const [filesArray, setFilesArray] = useState([])

  const onSubmit = data => {
    console.log('Submitted files:', getValues('files'))
  }

  const handleFileChange = event => {
    const selectedFiles = Array.from(event.target.files)

    if (selectedFiles) {
      // Array.from에 넣는 이유는 selectedFiles가 array가 아닌 FileList이기 때문입니다.
      const selectedFilesArray = Array.from(selectedFiles)

      // 보여주는 파일 리스트 정보 처리
      const newFileInfoList = selectedFilesArray.map(file => ({
        name: file.name,
        size: `${(file.size / 1024).toFixed(2)} KB`,
        url: URL.createObjectURL(file),
      }))
      setFileInfoList(prevFileInfoList => [
        ...prevFileInfoList,
        ...newFileInfoList,
      ])

      // files form value 처리
      // 기존 파일 목록과 새로 선택한 파일 목록을 합칩니다.
      // 이렇게 처리하지 않으면 새로 선택한 파일이 기존 파일을 대체합니다.
      const currentFiles = Array.from(getValues('files') || [])
      const updatedFiles = [...currentFiles, ...selectedFilesArray]

      // array에 담긴 정보를 가지고 FileList를 만듭니다.
      const fileList = new DataTransfer()
      updatedFiles.forEach(file => fileList.items.add(file))
      setValue('files', fileList.files)
    }
  }

  return (
    <form onSubmit={handleSubmit(onSubmit)}>
      <Controller
        name="files"
        control={control}
        defaultValue={[]}
        render={() => (
          <input type="file" onChange={handleFileChange} multiple />
        )}
      />
      <ul>
        {filesArray.map((file, index) => (
          <div key={index}>
            <img src={file.url} alt={file.name} />
            <li>{file.name}</li>
            <li>{file.size}</li>
          </div>
        ))}
      </ul>
      <button type="submit">Upload</button>
    </form>
  )
}

export default FileInputForm

ChatGPT를 사용할 때는 저런걸 어떻게 보여주지 생각했었는데 실제로 구현해보니까 신기했습니다. 보통 이렇게 누적식으로 관리해본 적은 처음이었고, n번째 파일을 제거할 때 DataTransfer api를 사용해서 FileList를 다시 만드는 게 인상적이었습니다.

실전 예제로 알아보는 react hook form 사용법

Wed, 19 Jun 2024 23:07:20 GMT

안녕하세요. 요즘 실무에서 form을 다룰 때 react-hook-form library를 사용하고 있습니다.

form의 input을 상태로 관리하면 상태가 바뀔 때마다 리렌더링이 발생해 불필요한 리렌더링이 많아집니다. react-hook-form을 사용하면 각 form을 독립적으로 관리할 수 있어서 다른 form의 리렌더링을 방지할 수 있습니다. 또한 성능 최적화도 잘 되어 있고 쉽게 사용가능한 유용한 api들도 제공해줘서 form 관리가 편해졌습니다.

실무에서 다양한 요구사항을 구현하면서 많이 검색해봤지만, 검색해도 안 나오는 부분들이 많아서 api의 type을 보면서 스스로 터득한 것들을 sandbox와 함께 공유하려고 합니다. 코드의 각 줄에 주석을 달아 설명을 추가했습니다. 코드 아래에 sandbox 링크를 첨부할테니 활용해보시면 좋을 것 같습니다.

import React, { useEffect, useState } from 'react'
import ReactDOM from 'react-dom'
import { useController, useForm } from 'react-hook-form'

import './styles.css'

const formatPhoneInput = (value: string) => {
  return (
    value
      // 숫자를 제외한 입력값 제거
      .replace(/[^0-9]/g, '')
      // 휴대폰 번호 형식으로 하이픈 추가
      .replace(
        /(^02|^0505|^1[0-9]{3}|^0[0-9]{2})([0-9]+)?([0-9]{4})/,
        '$1-$2-$3'
      )
      // 하이픈이 여러개면 제거
      .replace('--', '-')
  )
}

function App() {
  const [includePhone, setIncludePhone] = useState(false)
  const {
    register,
    handleSubmit,
    watch,
    formState: { errors },
    control,
  } = useForm({
    mode: 'onChange',
    // form value 초기값을 설정할 수 있습니다.
    // 해당 객체의 key값은 항목의 'name'입니다.
    defaultValues: {
      example: '',
      exampleRequired: '',
      exampleRequiredWithMessage: '',
      mobile: '',
      email: 'abc@abc.com',
    },
  })

  // errors는 각 항목 name들을 key로 가지는 map입니다.

  // 예를 들어 type은 다음과 같으며 등록된 항목에 따라 바뀝니다.
  // DeepMap<{example: string; exampleRequired: string; exampleRequiredWithMessage: string;}, FieldError>

  // error가 없을 땐 빈 map입니다.
  // {}

  // error가 발생하면 해당 항목에 에러 정보가 담깁니다. error가 없으면 해당 항목 error 정보는 없습니다.
  // message는 사용자가 지정한 메시지이고, type에는 어떤 validation rule인지가 담깁니다.
  // {
  //   phone: {
  //     message: '올바른 휴대폰 번호를 입력해주세요.",
  //     ref: HTMLInputElement,
  //     type: 'pattern'
  //   },
  //   exampleRequiredWithMessage: {
  //     message: 'example required',
  //     ref: HTMLInputElement,
  //     type: 'required'
  //   }
  // }

  // 유저가 입력할 때 하이푼이 자동으로 들어가도록 설정하고 싶음.
  // 커스텀하기 위해 controller를 사용합니다.
  const { field: mobileField } = useController({
    name: 'mobile',
    control,
    rules: {
      required: '휴대폰 번호를 입력해주세요.',
      pattern: {
        value: /^01(0|1|[6-9])-(?:\d{3}|\d{4})-\d{4}$/,
        message: '올바른 휴대폰 번호를 입력해주세요.',
      },
      maxLength: 13,
    },
  })

  useEffect(() => {
    console.info('errors : ', errors)
  }, [{ ...errors }])

  // watch에 항목의 'name'을 넘겨서 값이 바뀔 때마다 체크할 수 있습니다.
  console.log(watch('example'))

  return (
    <form
      // form 제출을 할 때 유효성 검사에 성공하면 handleSubmit callback의 parameter로 form data가 넘어옵니다.
      // 유효성 검사에 실패하면 실패한 input에 focus가 됩니다.
      onSubmit={handleSubmit(data => {
        alert(JSON.stringify(data))
      })}
    >
      <label>Example</label>
      {/* 항목을 등록할 때 register 함수를 사용합니다.
      'example' 항목을 등록합니다. */}
      <input {...register('example')} />

      <label>ExampleRequired</label>
      <input
        /* register의 두번째 인자로 ValidationRule option을 넘길 수 있습니다.
        require rule과 maxLength rule을 추가합니다. */
        {...register('exampleRequired', { required: true, maxLength: 10 })}
      />
      {/* validation을 통과하지 못하면 errors 객체에 정보가 넘어옵니다.
      message를 등록할 때 지정하지 않고 이렇게 임의로 보여줄 수 있습니다. */}
      {errors.exampleRequired && <p>This field is required</p>}

      <label>ExampleRequiredWithMessage</label>
      <input
        // required rule validation을 통과하지 못했을 때 메시지를 에러 정보에 담고 싶다면 메시지를 바로 넘기면 됩니다.
        {...register('exampleRequiredWithMessage', {
          required: 'example required',
        })}
        // validation rule에 조건을 주고 싶을 때가 있습니다. 그러면 ValidationRule의 형태로 넘기면 됩니다.
        {...register('exampleRequiredWithMessage', {
          required: {
            value: true, // 원하는 조건식
            message: 'example required',
          },
        })}
      />
      {/* errors에 담긴 message를 사용합니다. */}
      {errors.exampleRequiredWithMessage && (
        <p>{errors.exampleRequiredWithMessage?.message}</p>
      )}

      <label>ExampleRequiredWithMessage</label>
      <input
        // validation을 통과하지 못했을 때 메시지를 보여주고 싶다면 required rule에 string을 넘기면 됩니다.
        {...register('exampleRequiredWithMessage', {
          required: 'example required',
        })}
      />
      {errors.exampleRequiredWithMessage && (
        <p>{errors.exampleRequiredWithMessage?.message}</p>
      )}

      <label>Email</label>
      <input
        {...register('email', {
          required: '이메일을 입력해 주세요.',
          pattern: {
            value: /\S+@\S+\.\S+/,
            message: '올바른 이메일 주소를 입력해주세요',
          },
        })}
      />
      {errors.email && <p>{errors.email?.message}</p>}

      <div>
        <label htmlFor="includePhone">Include Phone</label>
        <input
          id="includePhone"
          type="checkbox"
          onChange={({ target: { checked } }) => setIncludePhone(checked)}
          style={{ width: 'auto' }}
        ></input>
      </div>
      {includePhone && (
        <>
          <label>Mobile</label>
          <input
            // 하이픈이 들어간 휴대폰 번호를 받고 싶다면
            {...mobileField}
            onChange={e => {
              const formattedValue = formatPhoneInput(e.target.value)
              mobileField.onChange(formattedValue)
            }}
          />
          {errors.mobile && <p>{errors.mobile?.message}</p>}
        </>
      )}
      <input type="submit" />
    </form>
  )
}

const rootElement = document.getElementById('root')
ReactDOM.render(<App />, rootElement)

sandbox link

Javascript Nullish Coalescing Operator (??) 자바스크립트 연산자

Wed, 12 Jun 2024 22:06:45 GMT

개발을 하다보면 변수가 null 또는 undefined일 때 기본값을 설정하는 경우가 많습니다. 이를 효과적으로 처리하기 위해 ECMAScript 2020(ES11)에서는 Nullish Coalescing Operator (??)가 도입되었습니다. 이 글에서는 Nullish Coalescing Operator의 개념, 사용법, 그리고 활용 예시를 살펴보겠습니다.

Nullish Coalescing Operator란?

Nullish Coalescing Operator (??)는 JavaScript에서 변수가 null 또는 undefined인 경우에만 오른쪽 피연산자를 할당합니다. 아래 예시를 보면 변수가 0이나 '' 같은 값일 땐 오른쪽 피연산자를 할당하지 않는 것을 확인할 수 있습니다.

let foo = null
let bar = foo ?? 'default value'
console.log(bar) // 출력: 'default value'

let foo2 = undefined
let bar2 = foo2 ?? 'default value'
console.log(bar2) // 출력: 'default value'

let foo3 = 0
let bar3 = foo3 ?? 'default value'
console.log(bar3) // 출력: 0

let foo4 = ''
let bar4 = foo4 ?? 'default value'
console.log(bar4) // 출력: ''

|| 연산자와의 차이점

|| 연산자와 비슷해 보이지만 다릅니다. ||연산자는 falsy 값인 0, '', false, null, undefined, NaN 등을 false로 처리합니다. 따라서 || 연산자는 0이나 '' 같은 값이 들어왔을 때도 오른쪽 피연산자를 할당합니다.

let foo = null
let bar = foo || 'default value'
console.log(bar) // 출력: 'default value'

let foo2 = undefined
let bar2 = foo2 || 'default value'
console.log(bar2) // 출력: 'default value'

let foo3 = 0
let bar3 = foo3 || 'default value'
console.log(bar3) // 출력: 'default value'

let foo4 = ''
let bar4 = foo4 || 'default value'
console.log(bar4) // 출력: 'default value'

https://ko.javascript.info/nullish-coalescing-operator 문서에서 좋은 표현을 찾았는데요. || 연산자는 첫 번째 truthy 값을 반환하는 반면, ?? 연산자는 첫 번째 defined 값을 반환한다고 생각하면 이해하기 쉽습니다.

활용 예시

로컬 저장소 값 처리

로컬 저장소에서 값이 없을 때 null이기 때문에 기본값을 쉽게 처리할 수 있습니다.

const storedValue = localStorage.getItem('key')
const value = storedValue ?? 'Default Value'

console.log(value) // 출력: 'Default Value' (로컬 저장소에 값이 없을 때)

환경 설정 값 처리

환경 설정에서 설정되지 않은 값이 있을 때 기본값으로 처리하기 쉽습니다.

const config = {
  apiEndpoint: process.env.API_ENDPOINT ?? 'https://default.api.com',
  timeout: process.env.TIMEOUT ?? 5000,
}

console.log(config.apiEndpoint) // 환경 변수에 따라 다름, 기본 값은 'https://default.api.com'
console.log(config.timeout) // 환경 변수에 따라 다름, 기본 값은 5000

0이 할당될 수 있는 변수 처리

예를 들어, 사용자의 만족도 조사 점수로 0부터 5까지의 값을 받는데, 사용자가 응답하지 않았을 때 0이 할당될 수 있습니다. 이때 ?? 연산자를 사용하면 기본값을 설정할 수 있습니다.

function displayScore(score) {
  let finalScore = score ?? '조사에 참여하지 않았습니다.'
  console.log(`만족도 점수: ${finalScore}`)
}

displayScore(5) // 출력: 만족도 점수: 5
displayScore(0) // 출력: 만족도 점수: 0
displayScore(null) // 출력: 만족도 점수: 조사에 참여하지 않았습니다.
displayScore(undefined) // 출력: 만족도 점수: 조사에 참여하지 않았습니다.

참고 글

https://ko.javascript.info/nullish-coalescing-operator

Tidy First 리뷰

Sun, 26 May 2024 23:05:53 GMT

켄트 벡의 “Tidy First?”는 코드 정리를 언제, 왜, 어떻게 해야 하는지에 대한 가이드라인을 제시합니다. 굉장히 얇아서 내용을 컴팩트하게 다루고 그만큼 빠르게 적용해 볼 수 있는 장점이 있습니다.

Part1에서는 코드 정리법을 다룹니다. 여러가지 방법을 제시하지만 저자가 강조하는 것은 “코드를 읽고 이해하는 데 드는 비용”이 높다는 것입니다. 그래서 코드를 읽기 쉽게 만들어야 한다는 것이 중요하다고 합니다.

Part2에서는 코드 정리를 언제 해야 하는지에 대해 다룹니다. 정리할 부분이 보인다고 무작정 하는 것이 아니라 코드 정리하는데 들어가는 비용까지 고려해서 합니다. 예를 들어, 다시는 코드를 변경할 일이 없는 컴포넌트의 경우에는 정리를 하지 않습니다. 코드 정리를 했을 때, 이해가 쉬워지거나 동작 변경이 쉬워지는 즉각적인 효과를 얻을 수 있으면 정리를 하는 것이 좋다고 합니다.

Part3에서는 코드 정리를 왜 해야 하는지에 대해 다룹니다. 개발에 들어가는 비용을 돈에 빗대어 설명하면서, 스스로 코드 정리를 해야 하는 이유에 대해서 찾을 수 있도록 합니다.

저자는 이 책이 코드 정리에 대해서 다룬다고 해서 코드 정리를 무조건 해야 한다고 말하지 않습니다. 대신에 스스로 생각할 수 있는 능력을 길러줍니다. 이제까지는 코드 정리를 뭐라도 하면 좋지 라고 생각했지만 이 책을 읽고 나서 돌이켜보면 굳이 안 해도 됐을 경우도 있었고 더 신경써서 해야 했을 경우도 있었던 것 같습니다. 앞으로 개발을 하면서 이 책의 내용을 체화한다면 변화에 유연하면서도 읽기 쉬운 코드를 작성해 장기적으로 많은 비용을 줄일 수 있을 것이라고 기대하고 있습니다.

NavigationDuplicated Avoided navigation to current location - vue router 에러

Thu, 23 May 2024 21:06:09 GMT

이슈

NavigationDuplicated: Avoided navigation to current location: “abc”

Tabs 컴포넌트로 페이지 이동을 하는데 이런 에러를 만났습니다. 탭을 빠르게 왔다갔다 하면 생겼는데요. vue router에서 현재 페이지와 같은 path로 this.$router.push(path)를 하면 발생합니다. 현재 페이지에서 같은 경로의 페이지로 이동할 수 없기 때문입니다.

해결방법

해결방법은 여러가지가 있습니다.

1. 에러 메시지를 무시하기

catch문으로 에러를 잡아버리는 방법입니다. 근본적인 해결책이라고는 볼 수 없습니다. 다른 에러도 같이 무시되기 때문입니다. 단순히 에러메시지를 보기 싫다면 적용할 수 있는 방법입니다.

this.$router.push.catch(() => {})

2. 경로 비교하기

$router.push하기 전에 경로를 비교합니다. 근본적인 원인을 없앨 수 있습니다.

const currentPath = this.$route.path
const targetPath = 'path'
if (currentPath !== targetPath) this.$router.push(targetPath)

3. this.$router.replace 사용

push 방식과 동작 방식이 다르긴 하지만 옵션이 될 수 있습니다.

this.$router.replace(path)

this.$router.push

히스토리에 새 항목이 추가됩니다.
브라우저의 뒤로 가기 버튼을 사용할 수 있습니다.
일반적인 네비게이션 용도로 사용됩니다.

this.$router.replace

히스토리의 현재 항목이 새로운 경로로 대체됩니다.
브라우저의 뒤로가기 버튼을 사용할 수 없습니다.
로그인 후 리디렉션, 오류 페이지로 리디렉션 등의 상황에서 사용됩니다.

참고

읽기 쉬운 코드 도서 리뷰

Mon, 13 May 2024 23:06:35 GMT

읽기 쉬운 코드

읽기 쉬운 코드(로버트 C.마틴 / 길벗)는 “레스토랑 예약 시스템”을 통째로 구현하는 과정을 예시로 들어 시작부터 개선과정까지를 담았습니다. 그 과정에서 어떻게 하면 좋은 코드를 짤 수 있는지를 녹여냈습니다. 프론트엔드 개발자인 제가 이 책에서 인상깊었던 내용들을 몇 자 적어보려고 합니다.

처음부터 순서대로

저는 책을 읽을 때 관심이 가는 부분을 먼저 읽는 편입니다. 하지만 이 책은 시스템을 통째로 구현하는 순서로 구성되어 있기 때문에 이미 설명했던 부분이나 이전 챕터의 코드를 참고해야 할 때가 많습니다. 그래서 처음부터 순서대로 읽으면 더 이해하기 쉬울 것입니다.

프로젝트라고 생각해서 발생하는 문제

이 책은 소프트웨어 개발을 프로젝트라고 생각하는 것이 좋지 않다고 서술합니다. 프로젝트는 시작과 끝이 있어 마지막에 도달하면 작업이 끝납니다. 하지만 성공한 소프트웨어는 지속되고 계속 유지보수해야 합니다. 그래서 오히려 정원 가꾸기에 비유합니다. 소프트웨어를 살아 있는 유기체로 보고 계속 살아가게 하기 위해서 리팩토링을 하거나 죽은 코드를 삭제하는 것에 비유할 수 있기 때문입니다.

주기적으로 의존성 갱신하기

의존성을 갱신하는 작업은 상당히 번거롭습니다. 이 책에서는 의존성 업데이트를 위한 일정을 따로 잡으라고 합니다. 그렇지 않으면 다른 업무에 우선순위가 밀려 하기 힘들 것이기 때문입니다. 이 내용에 많이 공감이 갔습니다. 의존성을 관리하지 않으면 나중에 업데이트하기가 무섭기도 하고, 업데이트 했을 때 엮여 있는 의존성들 때문에 쉽지가 않았기 때문입니다. 더군다나 프론트엔드 생태계는 라이브러리 업데이트 주기가 빠르기 때문에 더더욱 신경써야겠다는 생각을 했습니다. 회사에서 업데이트 일정을 따로 잡고 실천해보려고 합니다.

문제 해결법 - 이분법

코드에 문제가 생겼을 때 이분법을 활용할 수 있습니다.

문제를 감지하거나 재현할 방법을 찾습니다.
코드의 절반을 제거합니다.
문제가 계속되면 2단계부터 반복합니다. 문제가 해결되면 제거한 코드를 복원하고 나머지 절반을 제거한 후 다시 2단계부터 반복합니다.
문제가 재현되는 코드에서 어떤 일이 일어나는지 이해할 수 있을 정도로 충분히 코드가 작아질 때까지 반복합니다. 실제로 저도 사용하고 있던 방법인데 책에서 이렇게 이론으로 정리하니까 무척 반가웠습니다. 또한 git bisect 명령을 사용하면 보다 쉽게 결함이 있는 커밋을 찾을 수 있다는 것도 배웠습니다.

관심사의 분리

중요한 동작을 숨기는 형태로 작성하면, 코드를 이해하기 어려워진다고 합니다. 대신에 순수 함수의 반환값이 다른 순수 함수의 입력으로 들어가는 형태를 가지는 순차적 조합이 더 읽기 쉽다고 합니다. 이것도 업무에서 적용해볼만한 부분이었습니다. 또한, 비결정적 쿼리와 부수 효과를 가진 동작들을 시스템의 바깥 부분에 가깝게 유지하고, 핵심이 되는 복잡한 논리는 순수 함수로 작성하라고 합니다. 그렇게 해서 개선한 코드를 봤을 때 뇌가 더 받아들이기 편하고 읽기 쉬웠습니다.

정리하며

책의 예상 독자가 ‘숙련도를 높이고 싶은 개발자’인만큼 한번 읽어서 소화하기에는 어려운 내용이었습니다. 하지만 여러번 읽어서 내용을 이해할 때 오는 쾌감은 더 컸습니다. 조금 느리지만 한 챕터씩 계속해서 정복해보겠습니다.

개발자 기술 면접 노트(한빛미디어) 도서 리뷰

Sun, 28 Apr 2024 18:05:35 GMT

개발자 기술 면접 노트

한빛미디어의 “개발자 기술 면접 노트”를 소개합니다. 18년 차 카카오 면접관을 맡고 계시는 저자가 취업 및 이직에 도움이 되는 가이드를 작성해주셨습니다. 내용은 크게 서류 준비와 면접과 코딩 테스트 두 파트로 나뉩니다.

책을 읽다가 특히나 좋았던 부분 몇가지 소개해 드리겠습니다.

면접관의 입장에서

이 책을 추천한다면 면접관의 입장에서 서술한 부분이 많은 것이 그 이유입니다. 보통의 면접 관련 책들을 보면 지원자의 입장에서 서술한 경우가 많았습니다. 그런 내용들도 물론 도움이 되지만 저는 이 책이 면접관의 시선에서 쓰여 있어서 더 도움이 됐습니다.

가장 적절한 이직 시즌

이 책을 읽기 전에는 수시 채용은 수시 채용. 공채는 공채였습니다. 하지만 아래와 같은 관점을 제시해줘서 언제 어떻게 지원해야 합격률을 높일 수 있을지 생각해 볼 수 있었습니다.

대규모 공채 때에는 실력 있는 직원들을 많이 뽑았기 때문에 이후에는 채용 난이도가 올라갈 수 있다.

공채는 마감 날짜가 가까울수록 서류가 몰리기 때문에 몰리기 전에 미리 서류를 제출해야 채용 담당자가 서류를 읽을 시간이 충분하고 경합을 벌일 대상이 적다.

면접관의 의식의 흐름

이런식으로 면접관은 면접 보는 동안 어떤 의식의 흐름을 겪는지 적어주신 것도 면접관의 심리를 생각해보는데 많은 도움이 됐습니다. 면접관이 물어보는 질문의 난이도도 낮아지는지, 높아지는지도 지원자 입장에서 생각해 볼만한 점이라고 생각했습니다.

스터디를 해야 하는 이유

이런저런 스터디를 해봤는데 완주한 스터디도 있었고 흐지부지된 스터디도 있었습니다. 보통은 친구들과 하거나 회사 동료들과 했는데 모르는 사람들과 하는 스터디는 부담감이 많이 컸습니다. 그럼에도 저자는 스터디가 스펙을 올리기 가장 비효율적이고 번거로운 길이라고 소개합니다. 하지만 공부한 지식을 정리하는 방법과 끝까지 완주하는 방법을 배울 수 있습니다.

사람들 만나기

내부 추천의 기회도 많이 중요하다고 합니다. 아무래도 같이 일하는 사람을 뽑는 입장에서 이미 잘 알고 합을 맞춰 본 사람들이 눈에 더 들어오기 때문입니다. 그래서 대외활동, 스터디를 통해 사람들을 많이 만나라고 조언합니다. 이 부분은 제가 많이 약한데 어떻게 하면 좋을지 고민해보려고 합니다.

대화 잘 하기

결국에는 면접에서 ‘대화’를 잘 해야 한다고 합니다. 면접에 들어가보면 역량은 뛰어나신데 질문을 잘 이해하지 못하시거나 엉뚱한 대답을 하시는 등 의사소통에서 아쉬운 분들을 만난 적이 있습니다. 같이 일할 때 의사소통이 어려우면 많이 삐걱거리기 때문에 이 관점에서도 자신을 많이 돌아봐야겠다고 생각했습니다.

회고와 성장

연차가 쌓이면서 어떤 모습의 개발자가 되어야 할까 많은 고민을 했었는데 제가 생각하고 있는 것과 같은 내용이 나와서 반가웠고 확신이 조금 들었습니다. 짧게 추상화해보면 결국에는 주변 사람들에게까지 영향력을 미치는 개발자가 되어야겠고 그런 방향으로 나아가야겠다는 생각이 들었습니다.

마치며

신입, 경력 개발자 두 관점에서 내용들이 모두 서술되어 있어서 취업과 이직을 잘 하고 싶거나 성장하고 싶은 개발자분들은 누구나 읽기 좋은 책이지 않나 생각했습니다. 18년의 경력에서 우러나오는 경험을 다 정리해주신 것 같아 너무 좋았고 서평단을 통해 감사하게도 읽을 수 있어서 좋았습니다.

“한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다.”

Clerk를 사용해서 유저 정보 관리하기

Sun, 28 Apr 2024 16:04:04 GMT

Clerk라고 하는 유저 관리 플랫폼이 있습니다. 몇달 전에 뉴스레터에서 봤을 때는 이게 뭐지 싶었는데 요즘 듣고 있는 사이드 프로젝트 강의에서 사용했는데 번거로운 부분들을 많이 줄여줘서 재밌었습니다. 굉장히 직관적이고 편해서 제가 사용했던 컴포넌트들을 예시와 함께 소개합니다.

SignInButton

props

fallbackRedirectUrl - user가 sign in한 후에 redirect되는 url
signUpFallbackRedirectUrl - user가 sign up한 후에 redirect되는 url
mode
- redirect - sign in page로 redirect합니다.
- modal - modal을 띄웁니다.

SignUpButton

props

fallbackRedirectUrl - user가 sign up한 후에 redirect되는 url
signInFallbackRedirectUrl - user가 sign in한 후에 redirect되는 url
mode
- redirect - sign up page로 redirect합니다.
- modal - modal을 띄웁니다.

사용법

import { SignInButton } from '@clerk/nextjs'

export default function Home() {
  return (
    <div>
      <SignInButton />
    </div>
  )
}

각 컴포넌트는 아래와 같이 기본적인 UI를 제공해주는데

커스텀이 필요하면 wrapper 형식으로 사용하면 됩니다.

import { SignInButton } from '@clerk/nextjs'

export default function Home() {
  return (
    <div>
      <SignInButton>
        <button>Sign in with Clerk</button>
      </SignInButton>
    </div>
  )
}

SignedIn

유저 세션이 있을 때 렌더링되는 컴포넌트입니다. docs

SignedOut

유저 세션이 없을 때 렌더링되는 컴포넌트입니다. docs

ClerkLoaded

Clerk object가 로드된 상태를 보장하는 컴포넌트입니다. docs

ClerkLoading

Clerk object가 로딩중 일 때 렌더링되는 컴포넌트입니다. docs

UserButton

계정을 관리하거나 Sign out할 수 있는 버튼입니다. Clerk는 구글처럼 multi-session을 지원하기 때문에 계정간 전환도 가능합니다. docs

이 컴포넌트들을 종합적으로 아래와 같이 사용할 수 있습니다.

...
// 로딩 시에
<ClerkLoading>
 <div>loading</div>
</ClerkLoading>
// 로딩이 끝나면
<ClerkLoaded>
 // 유저 세션이 있다면
 <SignedIn>
  <UserButton afterSignOutUrl="/" />
 </SignedIn>
 //유저 세션이 없다면
 <SignedOut>
  <SignInButton
   mode="modal"
   fallbackRedirectUrl="/learn"
   signUpFallbackRedirectUrl="/learn"
   >
   <Button size="lg" variant="ghost">
    Login
   </Button>
  </SignInButton>
 </SignedOut>
</ClerkLoaded>
...

기존에는 예를 들어서, firebase를 쓴다고 하면 auth change를 watch해서 상태를 바꾸는 로직 등이 필요했는데 Clerk를 사용하면 그런 번거로운 작업들을 많이 줄일 수 있었습니다. 아직 초반부라 사용한 코드가 적었는데 나중에 user 정보를 어떻게 가져오고 어떻게 활용할 수 있을지 배울 수 있을 거 같아서 기대가 됩니다. 배우면 또 업데이트 해보겠습니다.

AI 프로필을 팔기 시작한 개발자 이야기

Fri, 19 Apr 2024 20:05:38 GMT

Carat

출처: carat.im

인스타그램을 보다가 우연히 발견했던 Carat은 사진 필터앱이었습니다. 사람들이 색감이나 특수효과를 입혀 놓은 필터를 유저들이 구매할 수 있는 서비스였는데요. 취미로 인물사진을 찍던 저는 ‘나도 필터를 만들어볼까’하고 잠시 생각했었지만 색감에 자신이 없어 도전하지 않았었습니다. 그러다가 최근에 Carat 측에서 AI필터를 출시해보자고 연락이 왔습니다. 출처: carat.im

보니까 비슷한 인물사진들을 여러장 학습시켜서 AI 사진을 만들 수 있는 기능이었습니다. 저는 AI 프로필을 구매한 적도 없고 솔직히 사람들이 많이 쓸까 싶었습니다. 스노우에서 AI 프로필 기능을 출시했을 때 ‘이걸 진짜 프사로 쓸까?’ 생각했었는데 재미로 해보고 인스타 스토리나 게시물로 올리는 정도였던 거 같아서 더욱 그랬었습니다. Carat 앱을 둘러보니 필터의 공유수나 저장수를 봤을 때 사람들이 꽤나 쓰는 것 같았습니다. 그래서 한두개 정도 만들어보고 조금이라도 팔리면 더 만들어봐야겠다 생각했습니다.

작업했던 모델분께 허락을 받고 두개 정도 만들었는데 이틀동안 3번 정도 구매가 일어났습니다. 재밌어서 무료필터를 한개 더 만들었는데 확실히 무료필터는 사용량이 많아서 금새 10회에 도달했습니다. 수수료를 떼면 커피값도 안 나왔지만 passive income을 만들 수 있는 가능성에 기분이 좋았고 기존 작업물들을 활용하면 리소스는 충분하기 때문에 필터만 열심히 만들면 될 것 같았습니다. 그리고 꾸준히 올리다보면 트래픽은 지금보다는 오를거라고 생각했습니다. 그래서 기존에 작업했던 모델분들에게 전부 연락을 돌려서 허락을 받았습니다. 아쉽게도 협업이 어려운 분들도 계셨지만 대부분 결과물이 궁금하기도 하고 신기하다며 허락해주셔서 다행이었습니다.(TMI인데 연락을 돌리면서 Carat 앱을 아는 모델님은 한 두분 정도밖에 없었습니다.)

글을 쓰면서 앱의 다른 부분들을 들여다 봤습니다. 이제까지는 시간이 조금씩 날 때 필터만 만들러 들어와서 몰랐던 부분이었습니다.

앱의 피드탭을 쭉 봤는데 유저들은 사진을 올릴 수 있고 좋아요랑 댓글로 소통할 수 있는 구조였습니다. 필터를 엄청 많이 쓰시는 헤비유저들도 계셨습니다. 하지만 피드에 헤비유저분들 몇 분만 보여서 여전히 노출 알고리즘은 모르겠습니다. 이젠 자주 들여다 봐야겠다는 생각이 들었습니다.

기존에는 200P짜리 필터만 만들었었는데 포인트 충전 가격 정책을 보니 150P짜리 필터도 몇개 만들어야겠다는 생각이 들었습니다. 최소 충전금액이 3,300원이고 300P를 받을 수 있는데 시험삼아 최소금액으로 충전하는 유저 입장에서 150P짜리 필터는 두개 살 수 있는데 200P짜리는 하나밖에 구매할 수 없기 때문입니다.

그렇게 지금은 총 6개의 필터를 업로드했습니다. 팔로워도 조금씩 생기고 있고 사용량이 오를 때마다 뿌듯합니다. 정산을 받으면 얼마가 될진 모르겠는데 지금 커피 몇잔 값은 벌었습니다. 필터들이 어떤 식으로 노출되는지도 아직은 모르고 수익이 얼마나 더 날지는 모르겠는데 잘 되서 허락해준 모델님들에게도 감사함을 표현하는 날이 왔으면 좋겠습니다.

생산성 향상을 위한 실무에서의 비동기 커뮤니케이션

Sun, 31 Mar 2024 15:04:19 GMT

작은 조직에서 일하면 갑작스러운 대면 커뮤니케이션이 잦다. 궁금한 점이 생기거나 논의할 게 생기면 자리로 찾아가 바로 말을 거는 케이스가 많다. 그렇게 빠르게 움직이는 것이 작은 조직의 장점이기도 하다. 하지만 너무 잦다 보면 작업 흐름이 깨지기도 한다. 몰입 상태에 있다가 동료가 불러서 얘기를 하다가 다시 돌아오면 몰입 상태로 다시 들어가는데 또 시간이 걸린다. 또한 능률도 떨어진다.

컨텍스트 스위칭 비용

능률이 떨어지는 것은 컨텍스트 스위칭 비용이 있기 때문이다. 컨텍스트 스위칭을 하면 이전에 하던 작업이 머릿속에 조금씩 남는다고 한다. 그래서 다른 작업을 시작해도 이전 작업을 깔끔하게 멈추는 것이 아니게 된다.

비동기 커뮤니케이션 지향

회사에서 일을 하면서 생산성이나 커뮤니케이션 방식에 대해 많이 고민한다. 그렇게 이것저것 시도해 보면서 정착한 것 중 하나는 비동기 커뮤니케이션을 지향하는 것이다. 여기서 비동기 커뮤니케이션이란 메일이나 글의 댓글처럼 커뮤니케이션 대상이 동시에 실시간으로 커뮤니케이션하지 않는 방식을 뜻하는 개념으로 썼다. 비동기 커뮤니케이션을 하면 나뿐만 아니라 동료의 작업 흐름을 끊지 않고 집중력을 보장할 수 있다.

비동기 커뮤니케이션의 적용

내가 상대방에게 먼저 요청하는 경우와 상대방이 나에게 먼저 요청하는 경우 두 가지로 나누어 얘기해 보겠다.

먼저, 내가 상대에게 무언가를 요청하는 경우에는 우선순위에 따라서 전달 방식을 결정한다.

지금 당장 얘기해야 하는 건 어쩔 수 없이 자리로 찾아가지만 가기 전에 채팅으로 “급하게 논의해야 할 게 있어서 그런데 잠깐 시간 내 주실 수 있나요?”라고 조금이라도 미리 요청드린다.
지금 당장은 아니지만 근시일 내에 얘기해야 하는 것은 채팅으로 “이런 부분에 대해서 논의가 필요한데 가능할까요? 가능하신 시간을 알려주시면 감사하겠습니다.”하고 채팅을 먼저 보낸다.
그 외에는 요청 글이나 댓글을 작성한다.
1. 이때 “급한 건 아니라서 시간 되실 때 봐주세요.”라든지 “급한 건 아닌데 언제까진 봐주시면 좋겠어요.”같이 상대방이 작업할 때 참고할 수 있도록 나의 우선순위를 같이 전달한다.

이제 반대의 경우이다. 나는 작업 사이클을 25분 정도로 잡아두고(포모도로) 그 시간에는 온전히 작업에 집중하려고 한다. 채팅이나 알림은 사이클이 끝나고 한 번에 확인한다. 바로 답장할 수 있는 건 바로 답장하지만 뭔가 확인해야 하거나 작업이 필요해 그렇지 않은 경우들이 있다. 그런 경우에는 “확인해 보고 몇 시까지 답변드릴게요”라고 미리 알려 드린다. 채팅 또는 글만 읽고 작업하러 가면 상대는 내가 확인은 했는지, 뭘 하고 있는지 모르기 때문이다. 또한 작업흐름을 유지하고 싶고 급하지 않다고 생각하는 경우 “지금 이런 작업을 하고 있어서 끝나고 볼게요.”라고 보낸다. 가끔 얼마나 빨리 피드백을 드려야 하는지 모르겠는 경우가 있는데 우선순위 파악이 잘 안되는 경우에는 얼마나 급하고 중요한 건지 먼저 물어보고 참고한다. 이렇게 하면 상대방 입장에서는 작업을 언제 할지, 답장은 언제 정도에 올지 예측 가능하고 기다리는 동안 다른 일을 계획할 수 있다.

예를 들어보자면, 백엔드 개발자분이 API를 개발하시는 동안 테이블에 데이터를 출력하는 작업을 하고 있었다. 커스텀이 필요하다 보니까 로직을 짜는 데 오래 걸렸고 꽤 집중해서 하고 있었다. 백엔드 개발자분이 API 개발이 다 됐다고 확인하고 알려달라고 하셨다. 그래서 “테이블에 데이터 출력하는 작업을 하고 있는데 생각보다 어려워서 작업 다 하고 확인해 볼게요.”라고 보냈다. 백엔드 개발자분은 다음 API를 작업하시면 되고 바로 확인해야 할 사항은 아니라고 생각해서 그렇게 답했다.

더 빠른 커뮤니케이션을 위한 팁

비동기 커뮤니케이션을 하다 보면 메시지를 주고받는 게 느리다고 느낄 수 있다. 그럴 때 더 빠르게 커뮤니케이션하기 위해서는 한번 메시지를 보낼 때 다음에 필요한 걸 미리미리 요청하는 것이다. 예를 들어서, 상대방에게 미팅을 요청하고 싶을 때, “이러이러한 것에 대해서 오늘 얘기를 나누고 싶은데 시간 괜찮으실까요?”라고만 보내면 상대방은 긍정 혹은 부정의 답변을 보낼 것이다. 긍정의 답변을 받았다면 오늘 몇 시에 시간이 되는지, 부정의 답변을 받았다면 되는 날은 언제인지 다시 물어봐야 할 것이다. 하지만 처음에 요청할 때 “이러이러한 것에 대해서 오늘 얘기를 나누고 싶은데 시간 괜찮으실까요? 가능하시다면 되는 시간을 알려주시면 감사하겠습니다. 혹시 오늘 안 된다면 다른 되는 날과 시간을 알려주시면 감사하겠습니다.”라고 필요한 정보를 미리 요청하면 커뮤니케이션 과정이 훨씬 단축된다.

정리

비동기 커뮤니케이션을 지향하다 보니 작업에 집중할 수 있는 시간이 많이 늘어났다. 이렇게 쭉 적고 보니까 아래 두 가지로 요약할 수 있을 거 같다.

서로가 커뮤니케이션 과정을 예측 가능하게 하기
서로의 작업 흐름을 존중해주기

조코딩의 챗GPT API를 활용한 수익형 웹 서비스 만들기 책 리뷰

Tue, 20 Feb 2024 21:02:48 GMT

출처: 한빛미디어

한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다.

서비스 구현부터 수익화까지: 챗GPT API의 실전 활용 가이드

이 책은 챗GPT API를 활용해 서비스를 구현하고 수익화하는 과정을 전반적으로 다루며, 개발자와 비개발자 모두에게 접근 가능한 가이드를 제공한다. 저자가 실제로 만들었던 "운세 보는 챗도지" 서비스 구현을 목표로 필요한 것들을 위주로 군더더기없이 배울 수 있었다. 빠르게 서비스를 만들고 고도화하며 배포하는 방법과 수익화 전략까지 상세히 다루고 있다. 실제 서비스를 구현할 때 적용해보면 좋을 순서로 구성되어 있어, 사이드 프로젝트를 생각하고 있다면 적용해보면 좋을 것 같다.

인상 깊은 프롬프트 실전 팁

책에서 가장 유용했던 부분은 프롬프트 실전 팁이다. 저자는 챗GPT와의 상호작용에서 어떤 단어를 사용해야 효과적으로 의도를 전달할 수 있는지, 역할을 어떻게 잘 부여할 수 있는지에 대해 공유했는데 이렇게까지 구체적이고 유용한 팁은 처음 봤다. 그래서 저자가 얼마나 연구를 많이 했는지 보여주는 부분이라고 생각했다. 예를 들어서, 프롬프트에는 보편적인 단어를 사용해야 한다. GPT에 사전 학습 데이터에 포함된 단어여야 결과가 더 정확하다. 가장 보편적인 단어를 찾는 방법은 구글에 여러가지 표현을 검색해보고 결과가 가장 많은 단어를 찾는 것이다. 또 다른 예로는 “무조건 답을 할 수 있다”라고 주입시키는 것이다. 가끔 가다가 사과를 하면서 원하는 대답을 하지 않을 때가 있는데 이 팁은 그것을 방지해준다.

접근성과 이해도

책은 개발 지식이 부족한 사람도 충분히 따라할 수 있도록 최대한 범용적인 기술스택을 사용했다. 프론트엔드 프레임워크를 사용하지 않고 순수하게 HTML에 Javascript를 넣는 형태로 작성했다. api 서버도 가장 범용적인 expressjs를 사용했다. 챗GPT를 api에만 사용하는 것이 아니라 실제 개발과정에서 모르는 지식이 있을 때 챗GPT에게 어떤 식으로 질문하면서 정보를 얻을 수 있는지도 보여준다. 이런 특징으로 책의 접근성을 높였고 다양한 배경의 독자들을 고려했다.

수익화 전략

애드센스와 토스 후원 링크를 삽입해 수익화를 노린 것도 이 책의 특징이다. 애드센스는 워낙 많이 쓰이는 방식이라 알고 있었는데 토스 후원 링크를 넣는건 처음 봤다. 물론 링크를 본 사람이 진짜 후원해주고 싶은 마음이 생겨야 돈을 보내겠지만 그래도 재미있는 방식이었다. 이런 수익화 전략을 적용해보고 싶은 사람에게는 유용한 정보가 될 것 같다.

해결할 프로덕트 도서 리뷰 - 고객과 가까워지기

Sun, 18 Feb 2024 22:02:05 GMT

출처: 길벗

책 소개

임팩트 하나만 만들어라라는 문장이 나의 프로덕트에 대한 고민을 해결할 열쇠처럼 다가왔다. 길벗 출판사에서 리뷰어를 모집한다는 소식을 듣고 홀리듯이 신청했다. 솔직히 신청할 때는 이 책이 572 페이지나 되는 줄 몰랐다. 그래서 책을 받고 나서 ‘언제 다 읽지’라는 생각을 했다. 하지만 책을 훑어보니 그렇지 않아도 되겠다는 생각이 들었다. 책의 서론에서도 얘기하지만 백과사전식으로 필요한 부분부터 읽으면 되기 때문이다.

요약하자면

이 책은 제품 회사의 수명 주기를 1. 아이디어, 2. 스타트업, 3. 성장, 4. 확장, 5. 성숙, 6. 회고로 세세히 나누어 접근한다. 각 단계별로 유저와 어떻게 가까워질 수 있는지에 대해 얘기한다. 설명이 잘 되어 있고 구체적인 액션 플랜도 제시해줘서 쉽게 행동으로 옮길 수 있을 것 같다. 자사 서비스가 있는 회사에서 일하고 있는 사람이 읽는다면 유용할 것이라는 생각이 들었다.

리뷰하자면

나의 상황

우리 조직은 제품 중심의 스쿼드에서 목적 중심의 셀로 조직 개편을 해서 일하는 실험을 하고 있다. 그래서 셀로 일하는 방식에 적응해야 하는데 이 책을 읽다보니 적용해 볼만한 지점들이 많았다. 필요한 부분들부터 몰입해서 빠르게 읽을 수 있었다.

가치 제공 평가하기

가장 먼저 읽었던 부분은 “가치 제공 평가하기” 챕터였다. 우리 셀이 1년 목표를 잡고 나아갈 때 얼마나 고객에게 가치를 제공하는지 제대로 측정하고 싶었다.

책에서 고객 연구를 아무리 열심히 하더라도 그들이 원하는 100% 완벽한 제품을 한번에 만들 수는 없다고 한다.

대신에

고객 요구를 찾아 몇번의 이터레이션을 거쳐야 하고
제품을 유연하게 만들어 실험하기 좋게 만들어야 하며
단순하게 유지해서 제품이 복잡해지기 전 핵심 기능의 가치를 평가할 수 있어야

한다고 한다. 대표님이 우리 셀은 목표를 달성하기 위한 모든 방법을 나열하고 우선순위에 따라 실행하면서 고객을 학습하는 식으로 그로스 해보라고 하셨다. 책에 관련한 내용이 있어서 왜 이런 방식으로 접근하면 좋은지 더 깊게 이해할 수 있어서 도움이 많이 됐다.

실험과 학습

“복리식 승리” 챕터에서 우리가 승리하는 유일한 방법은 훨씬 더 많이 실험하고, 그 과정에서 어떤 것이 통하는지 운 좋게 발견하는 것이라고 한다. 트위터는 2011년부터 주당 실험 횟수를 0.5에서 10으로 증가시켜 가파르게 성장했고, 더 많은 실험이 더 이상 빠른 성장으로 이어지지 않을때까지 했다고 한다.

빠른 실험 과정의 성과는

통찰력과 고객 연구의 질. → 좋은 가설
실험 속도
실험 결과로부터 학습할 수 있는 능력

에 달려 있다고 한다. 지난 달을 돌이켜보면 실험 속도는 충분히 빠르다고 생각하는데 좋은 가설을 세우는 능력, 학습하는 능력은 많이 부족하다는 생각이 들었다.

고객과 가까워지기

그리고 다른 챕터에서 고객에게 가까이 다가가는 방법을 많이 배웠다.

예를 들어, “후속 이메일을 통한 학습” 챕터에서는 이탈한 고객은 붙잡기 어렵지만 그들로부터 배울 수 있는 것이 많다고 한다. 그래서 스크럼 때 이탈 고객들에게 이메일을 보내보자고 제안했다.

그리고 “단일 용이성 질문” 챕터에서는 사용 용이성을 평가하는 툴로 태스크 수행 후 태스크 완료가 얼마나 어려웠는지 혹은 쉬웠는지 물어보는 방법을 소개했다. 이 방식도 셀에 제안해서 서비스 대학 제휴 후에 제휴 과정이 얼마나 매끄러웠는지 물어보는 설문을 추가했다.

마무리하자면

리뷰를 작성하면서 좋은 책이라는 걸 다시 한번 느꼈다. 이 정도만 읽어도 배울 게 이렇게나 많은데 내가 아직 읽지 않은 챕터들까지 포함해서 액션 아이템을 뽑아서 적용해본다면 어떤 모습일지 너무 기대된다. 어떤 제품을 만들어야 할지 고민하고 있다면 꼭 읽어보길 추천한다.

openai api code 429, You exceeded your current quota, please check your plan and billing details 에러 해결하기

Thu, 08 Feb 2024 15:02:57 GMT

openai api를 사용하다가 status code 429, You exceeded your current quota, please check your plan and billing details. 라는 에러를 만났다. 이 에러의 해결 과정을 정리했다.

openai에서 제공하는 api error 문서를 찾아보니 다음과 같은 내용이 있었다.

openai api를 사용해 본 적이 없는 계정은 account page에 들어가보면 Usage limits이 free로 되어 있다. 나는 문제를 해결하고 이 글을 쓰는 것이기 때문에 지금은 Usage tier1로 되어 있다. 이건 내가 설정하는 것이 아니라 내가 api를 사용하면 자동으로 업데이트되는 거라 확인만 하면 된다.

내 크레딧이 0이었기 때문에 아래 Add to credit balance 버튼을 눌러서 작고 소중한 5달러를 충전했다.

이 에러를 만났다면 API key를 이미 발급받은 상태일텐데, 이 상태에서 다시 시도해도 똑같은 에러가 떴다. 그래서 당황했다가 API key를 새로 발급받으니 에러가 사라졌다.

요약

openai 크레딧이 없거나 api 사용량을 넘으면 status code 429, You exceeded your current quota, please check your plan and billing details.
크레딧을 충전하거나 api key를 새로 발급받아 해결할 수 있다.

글쓰기 세미나 및 글쓰기 프로세스 회고

Wed, 07 Feb 2024 19:03:13 GMT

글또의 글쓰기 세미나를 듣고 머릿속에만 있던 나의 글쓰기 프로세스를 끄집어 내 정리해보고자 한다. 나는 이제껏 어떤 플로우로 글을 썼는지, 개선할 부분은 없는지 보고 싶었다.

나의 글쓰기 프로세스

나의 글쓰기 프로세스를 도식화하면 다음과 같다.

글감 모으기

나는 글 소재나 아이디어가 생각날 때마다 아이폰 메모에 모아 놓는 편이다. 아이폰 기기라면 동기화가 돼서 어디에서나 쉽게 접근할 수 있어서 그렇다. 소재만 남길 때도 있고, 간단하게 몇 문장 덧붙여서 남길 때도 있다. 그 뒤에도 소재에 대해 생각 나는 것이 있으면 바로 적는다. 그것들이 모여서 초안의 재료가 된다.

글 작성

글또 글을 써야 할 때는 메모에서 주제를 찾아보고, 마땅한 게 없으면 다시 생각해본다. 아직까지 뭔가 새로 공부하면서 쓴 적은 없고, 내가 했던 경험들을 글로 남겼었다. 자리에 앉아서 소재를 초안으로 만들 때는 글또 노션 템플릿을 활용한다. 템플릿에 있는 질문들을 답하다보면 어떤 식으로 쓰면 좋을지 도움이 많이 된다. 질문에 답하고 나서 글을 쓰기 시작하는데 나는 구조를 먼저 생각하기보다는 의식의 흐름대로 생각나는걸 쭉 써놓는다. 처음부터 구조대로 쓰려고 하면 잘 생각이 나지 않는데, 생각나는 대로 막 쓰면 그나마 잘 써진다. 그리고 글을 오래 쓰고 있으면 몸이 근질거려서 시동이 걸릴 때 확 쓰고 다음 사이클 때 또 쓰는 편이다. 생각나는대로 적어놓았던 것들을 서론, 본론, 결론으로 구조에 맞게 다듬으면서 정리한다.

개선

글감 폴더

아이폰 메모에 글감 폴더를 만들었다. 메모 앱에는 글감이 다른 것들(사이드 프로젝트 아이디어, 주저리 주저리 생각 등)이 섞여 있으니까 글감을 얼마나 모았는지, 어떤 글감들이 있는지 모아보기 힘들었다. 글감폴더에 있는 글감들. 확실히 구분하니까 보기 쉽다.

일상 소재

아무래도 주로 글을 쓰게 되면 글또에 제출할 글을 쓴다. 그래서 소재를 떠올릴 때도 글또 글 소재로 쓸 수 있는걸 떠올리는 편인데, 꽤나 잘 생각이 나지 않았다.

밀리의 서재의 쓸 게 없다뇨, 이렇게 많은데 라는 책을 읽었는데 글 쓸 게 없다는건 핑계다. 흘러가는 일분 일초를 자세히 들여다보면 충분히 글로 적어낼 부분이 많다. 라는 문장이 나온다.

그래서 이제는 일상 소재도 많이 메모해 두려고 한다. 글또에 제출할 수 없는 경우가 많겠지만 그럼에도 따로 적어보려고 한다. 많이 써봐야 글을 더 잘 쓸 거 같아서.

실행

마감기한이 닥쳐 와서 쫓기듯 글을 쓰면 잘 되지 않는다. 그리고 쓰다보면 고칠 것이나 떠오르는 것이 있기 때문에 글이 애매해질 때가 많다. 이 글도 더 일찍 사이클을 돌리면서 썼어야 했는데 너무 미뤘던 거 같다. 그래서 이제는 글을 더 빨리 쓰고, 더 빨리 다듬어야겠다.

작은 조직에서 개발문화를 제안했던 경험과 알아두면 좋을 느낀점

Fri, 02 Feb 2024 23:02:22 GMT

최근에 슬랙에 올라 온 고민글 중에 개발 문화가 없는 조직에서 개발 문화를 어떻게 도입할 수 있을지 고민이라는 글이 있었다. 그 글을 보니 내가 프론트엔드 팀에 제안했던 경험들이 떠올라서 열심히 댓글을 남겼다. 그 경험들을 정리해서 남겨보고자 한다.

테스트 코드를 작성하는 문화

내가 프론트엔드 팀에 제안했던 문화는 테스트 코드를 작성하는 문화였다.

우리 서비스는 유저가 어떤 행동을 하면 gtm(google tag manager) event를 trigger해서 수집한다. 입사 초반에 내가 코드를 수정했다가 이 event가 발동하지 않으면 어쩌지? 하는 걱정에 이 로직들을 테스트 자동화 해놓으면 미리 알아차릴 수 있지 않을까 하는 생각을 했다. 빨리 알아차릴수록 고치는 비용이 작기 때문이다. 그 순간이 테스트 코드에 관심을 가지기 시작한 순간이었고 e2e test tool인 cypress를 설치해서 열심히 뚝딱거렸다. 하지만 내가 생각했던 대로 테스트 환경을 구축하지는 못했다. 시나리오대로 app을 mocking하는 게 쉬운 일은 아니었고, 프론트 앱 뿐만 아니라 이것저것 얽혀 있었기 때문이었다. 그래서 혼자서 만져보기만 하고 팀에 도입하지는 못했다.

시간이 지나고 jest를 이용해 컴포넌트 단위 테스트를 짜보면 어떨까 하는 생각이 들었다. 대상 컴포넌트만 mocking하면 되기 때문에 단위가 작아서 구현이 쉽고 더 효용이 있을 것이라는 생각이 들었다. 하지만 개발하면서 약속한 일정을 맞추다보면 테스트 코드를 항상 같이 짜진 못했다. 대신에 생각보다 빨리 개발하면 개발 후에라도 테스트 코드를 붙이는 경우가 있었다. 또한 사이즈가 작은 업무인 경우 테스트 코드를 먼저 작성해보고 컴포넌트를 개발해 본 경우도 있었다. 이렇게 테스트 코드를 놓지 않고 계속 붙들고 있으니까 아래와 같은 효용을 느낄 수 있었다.

테스트 코드 자체가 컴포넌트의 기능 명세가 된다.
변경으로 인한 예상치 못한 버그를 예방할 수 있다.
테스트 코드를 먼저 작성했을 때는 UI를 뺀 기능구현에 먼저 집중을 하니 오히려 더 빨리 개발하는 경우도 있었다.

그리고 팀원들을 설득했다. 팀 미팅 때마다 테스트 코드가 좋다고 노래를 부르고, 위의 효용을 느꼈다고 했다. 물론 팀원들도 이게 좋은지는 안다. 하지만 내가 얘기를 꺼낸다고 해서 100% 설득되지는 않는다. 좋은지는 알지만 직접 효용을 느끼지 못한다면 설득되지 않는다.

그래서 github action을 통해 PR을 올리면 자동으로 테스트가 돌아가도록 해놓았는데 이거라도 붙여보자고 했다. 이걸 붙인다고 지금부터 당장 테스트 코드를 써야 하는건 아니기 때문에 넣어만 보자는 것이다. 나중에 정말 필요없다고 생각하면 그 때 지워도 되니까. 결국 그렇게 붙인 github action이 빛을 발했다. 팀원이 테스트 코드가 달린 컴포넌트를 수정할 일이 있었는데 수정하고 보니 테스트 코드 통과를 못 한 것이다. 그래서 테스트 코드를 보니 미처 생각하지 못한 부분이 있었음을 깨달으시고 다시 수정했다고 하셨다. 그리고 PR을 올릴때마다 계속 돌아가니, 팀원들도 시간이 날 때 하나씩 테스트 코드를 작성해보기도 했다.

적용해볼만한 느낀점

그 후에도 유용한 툴을 같이 쓰자고 제안하거나 스터디를 같이 하거나 팀에서 여러가지 시도를 했었다. 그러면서 느꼈던 점을 요약해보면 다음과 같다.

팀원들이 쉽게 설득될 것이라는 기대는 버린다.
팀원들이 직접 효용을 느끼게 해야 한다. 좋다고 느끼면 설득하지 않아도 자발적으로 참여할 것이다.
모든 문화가 팀에 맞는 것은 아니다. 해보고 맞지 않는 문화는 과감히 버리는 게 좋을 수도 있다.

shadcn, react-hook-form useFieldArray, zod로 동적 form 관리하기

Fri, 02 Feb 2024 22:02:50 GMT

이 글에서는 shadcn + react-hook-form useFieldArray + zod로 동적 form을 만드는 과정을 소개한다.

shadcn: UI library
react-hook-form: 폼을 만드는 라이브러리
zod: 스키마 타입 검증을 해주는 라이브러리

책에서 액션 아이템을 뽑는 앱을 사이드 프로젝트로 만들고 있다. 그러다 form을 만들 일이 생겼다. 회사에서는 Vue를 주로 쓰고 있어서 React를 사이드 프로젝트로 공부하고 있다. 안 그래도 React는 form을 만들기가 어렵다는 얘기를 많이 들어서 살짝 겁났다.

먼저 내가 쓰고 있는 shadcn의 Form component를 살펴봤다. shadcn은 form을 만들 때 React Hook Form과 Zod를 사용한다. 공식문서를 따라가 보면 다음과 같다.

먼저 form의 스키마를 만든다. 이 예제에서 username은 최소 2, 최대 50의 길이를 가지는 문자열이다.

'use client'

import { z } from 'zod'

const formSchema = z.object({
  username: z
    .string()
    .min(2)
    .max(50),
})

useForm hook으로 form을 만든다.

"use client"

import { zodResolver } from "@hookform/resolvers/zod"
import { useForm } from "react-hook-form

// 1. Define your form.
const form = useForm<z.infer<typeof formSchema>>({
  resolver: zodResolver(formSchema),
  defaultValues: {
    username: "",
  },
})

// 2. Define a submit handler.
// values로 데이터를 확인할 수 있다.
function onSubmit(values: z.infer<typeof formSchema>) {
  // Do something with the form values.
  // ✅ This will be type-safe and validated.
  console.log(values)
}

컴포넌트는 아래와 같이 구성하면 form이 연동된다.

return (
  <Form {...form}>
    <form onSubmit={form.handleSubmit(onSubmit)} className="space-y-8">
      <FormField
        control={form.control}
        name="username"
        render={({ field }) => (
          <FormItem>
            <FormLabel>Username</FormLabel>
            <FormControl>
              <Input placeholder="shadcn" {...field} />
            </FormControl>
            <FormDescription>This is your public display name.</FormDescription>
            <FormMessage />
          </FormItem>
        )}
      />
      <Button type="submit">Submit</Button>
    </form>
  </Form>
)

이 가이드를 기반으로 내가 작성한 코드는 다음과 같다.

'use client'

import {
  Drawer,
  DrawerClose,
  DrawerContent,
  DrawerHeader,
  DrawerTitle,
  DrawerTrigger,
} from '@/components/ui/drawer'
import {
  Form,
  FormControl,
  FormField,
  FormItem,
  FormLabel,
  FormMessage,
} from '@/components/ui/form'
import { Button } from '@/components/ui/button'
import { Input } from '@/components/ui/input'
import { toast } from '@/components/ui/use-toast'

import { z } from 'zod'
import { zodResolver } from '@hookform/resolvers/zod'
import { useForm } from 'react-hook-form'
import { X } from 'lucide-react'

type Props = {
  children: React.ReactNode,
}

const FormSchema = z.object({
  from: z.string().min(2, {
    message: '출처는 반드시 필요합니다.',
  }),
  title: z.string().min(2, {
    message: '제목은 반드시 필요합니다.',
  }),
})

export default function ActionItemCreateDrawer({ children }: Props) {
  const form =
    useForm <
    z.infer <
    typeof FormSchema >>
      {
        resolver: zodResolver(FormSchema),
        defaultValues: {
          from: '',
          title: '',
        },
      }

  function onSubmit(data: z.infer<typeof FormSchema>) {
    toast({
      title: 'You submitted the following values:',
      description: (
        <pre className="mt-2 w-[340px] rounded-md bg-slate-950 p-4">
          <code className="text-white">{JSON.stringify(data, null, 2)}</code>
        </pre>
      ),
    })
  }
  return (
    <Drawer>
      <DrawerTrigger>{children}</DrawerTrigger>
      <DrawerContent className="h-screen mt-0 max-w-sm mx-auto">
        <DrawerHeader>
          <DrawerClose>
            <X className="mb-10" />
          </DrawerClose>
          <DrawerTitle>액션 아이템 만들기</DrawerTitle>
        </DrawerHeader>
        <div className="px-4">
          <Form {...form}>
            <form
              onSubmit={form.handleSubmit(onSubmit)}
              className="w-full space-y-6"
            >
              <FormField
                control={form.control}
                name="from"
                render={({ field }) => (
                  <FormItem>
                    <FormLabel>출처</FormLabel>
                    <FormControl>
                      <Input placeholder="부자아빠 가난한아빠" {...field} />
                    </FormControl>
                    <FormMessage />
                  </FormItem>
                )}
              />
              <FormField
                control={form.control}
                name="title"
                render={({ field }) => (
                  <FormItem>
                    <FormLabel>제목</FormLabel>
                    <FormControl>
                      <Input placeholder="힘든 일 먼저 하기" {...field} />
                    </FormControl>
                    <FormMessage />
                  </FormItem>
                )}
              />
              <Button type="submit" className="w-full">
                액션아이템 만들기
              </Button>
            </form>
          </Form>
        </div>
      </DrawerContent>
    </Drawer>
  )
}

내 form은 string type인 from과 title field를 가지고 있다. 여기까진 좋았다.

생각해보니 액션 아이템이 여러개일 수 있다는 사실을 간과했다. 그래서 다급하게 react-hook-form dynamic이라는 키워드를 검색했다. 찾아보니 useFieldArray라는 hook이 있었는데 이걸 쓰면 될 것 같았다. 참고해서 코드를 수정했다.

// actionItem -> actionItems 배열로 바뀌었다.
const FormSchema = z.object({
  from: z.string().min(2, {
    message: '출처는 반드시 필요합니다.',
  }),
  actionItems: z.array(
    z.object({
      actionItem: z.string().min(2, {
        message: '액션 아이템은 반드시 필요합니다.',
      }),
    })
  ),
})

// initValue도 그에 맞게 수정해줬다.
const initValue = {
  from: '',
  actionItems: [{ actionItem: '' }],
}

const form =
  useForm <
  z.infer <
  typeof FormSchema >>
    {
      resolver: zodResolver(FormSchema),
      defaultValues: initValue,
    }

// useFieldArray의 control에는 기존의 form.control을 넘긴다.
// name은 이 hook으로 관리하는 field array의 이름을 넘겨주면 된다.
// fields는 관리하는 field들, append는 field를 추가할 때, remove는 제거할 때 사용할 수 있다.
const { fields, append, remove } = useFieldArray({
  control: form.control,
  name: 'actionItems',
})

UI 부분은 다음과 같이 수정했다. name에는 아래와 같이 형식에 맞춰서 적어줘야 한다. 형식이 다르면 Input component에서 type error가 났다. append를 할 수 있는 Button도 추가해봤다.

{
  fields.map((field, index) => {
    return (
      <FormField
        key={`form-field-${field.id}-${index}`}
        control={form.control}
        name={`actionItems.${index}.actionItem`}
        render={({ field }) => (
          <FormItem>
            <FormLabel>액션 아이템</FormLabel>
            <FormControl>
              <Input placeholder="힘든 일 먼저 하기" {...field} />
            </FormControl>
            <FormMessage />
          </FormItem>
        )}
      />
    )
  })
}
;<div className="flex justify-end">
  <Button onClick={() => append({ actionItem: '' })}>추가하기</Button>
</div>

최종 코드는 다음과 같다.

'use client'

import {
  Drawer,
  DrawerClose,
  DrawerContent,
  DrawerHeader,
  DrawerTitle,
  DrawerTrigger,
} from '@/components/ui/drawer'
import { Button } from '@/components/ui/button'
import {
  Form,
  FormControl,
  FormField,
  FormItem,
  FormLabel,
  FormMessage,
} from '@/components/ui/form'
import { toast } from '@/components/ui/use-toast'
import { Input } from '@/components/ui/input'

import { z } from 'zod'

import { zodResolver } from '@hookform/resolvers/zod'
import { useForm, useFieldArray } from 'react-hook-form'

import { X } from 'lucide-react'

type Props = {
  children: React.ReactNode,
  open: boolean,
  setOpen: (open: boolean) => void,
}

const FormSchema = z.object({
  from: z.string().min(2, {
    message: '출처는 반드시 필요합니다.',
  }),
  actionItems: z.array(
    z.object({
      actionItem: z.string().min(2, {
        message: '액션 아이템은 반드시 필요합니다.',
      }),
    })
  ),
})

const initValue = {
  from: '',
  actionItems: [{ actionItem: '' }],
}

export default function ActionItemCreateDrawer({
  children,
  open,
  setOpen,
}: Props) {
  const form =
    useForm <
    z.infer <
    typeof FormSchema >>
      {
        resolver: zodResolver(FormSchema),
        defaultValues: initValue,
      }

  const { fields, append, remove } = useFieldArray({
    control: form.control,
    name: 'actionItems',
  })

  function onSubmit(data: z.infer<typeof FormSchema>) {
    setOpen(false)
    toast({
      title: 'You submitted the following values:',
      description: (
        <pre className="mt-2 w-[340px] rounded-md bg-slate-950 p-4">
          <code className="text-white">{JSON.stringify(data, null, 2)}</code>
        </pre>
      ),
    })
  }
  return (
    <Drawer open={open} onOpenChange={setOpen}>
      <DrawerTrigger>{children}</DrawerTrigger>
      <DrawerContent className="h-screen mt-0 max-w-sm mx-auto">
        <DrawerHeader>
          <DrawerClose>
            <X className="mb-10" />
          </DrawerClose>
          <DrawerTitle>액션 아이템 만들기</DrawerTitle>
        </DrawerHeader>
        <div className="px-4">
          <Form {...form}>
            <form
              onSubmit={form.handleSubmit(onSubmit)}
              className="w-full space-y-6"
            >
              <FormField
                control={form.control}
                name="from"
                render={({ field }) => (
                  <FormItem>
                    <FormLabel>출처</FormLabel>
                    <FormControl>
                      <Input placeholder="부자아빠 가난한아빠" {...field} />
                    </FormControl>
                    <FormMessage />
                  </FormItem>
                )}
              />
              {fields.map((field, index) => {
                return (
                  <FormField
                    key={`form-field-${field.id}`}
                    control={form.control}
                    name={`actionItems.${index}.actionItem`}
                    render={({ field }) => (
                      <FormItem>
                        <FormLabel>액션 아이템</FormLabel>
                        <FormControl>
                          <Input placeholder="힘든 일 먼저 하기" {...field} />
                        </FormControl>
                        <FormMessage />
                      </FormItem>
                    )}
                  />
                )
              })}
              <div className="flex justify-end">
                <Button onClick={() => append({ actionItem: '' })}>
                  추가하기
                </Button>
              </div>
              <Button type="submit" className="w-full">
                액션아이템 만들기
              </Button>
            </form>
          </Form>
        </div>
      </DrawerContent>
    </Drawer>
  )
}

결론

멋진 라이브러리들의 도움으로 동적 form을 손쉽게 만들어봤다. actionItems를 string 배열로 만들어보고 싶었는데 하다보니 타입 에러가 나서 이건 아직 구현 방법을 모르겠다. 손에 익도록 다양한 형태의 form도 만들어봐야겠다.

슬랙 커뮤니티를 처음 운영해보고 배운 점

Sun, 21 Jan 2024 00:02:37 GMT

이 글에서는 제가 겪는 문제에서 비롯해 슬랙 커뮤니티를 처음 만들고 운영해 본 경험을 나누고자 합니다. 채널을 만들고 나서 날짜별로 현황을 조금씩 정리했었는데 그 형식대로 적어볼까 합니다.

1월 5일

계기

링크드인에서 어떤 분이 프론트엔드 슬랙을 만드신다는 글을 봤는데 참여하고 싶다는 댓글이 엄청나게 달렸습니다. 그 글을 보고는 수요가 엄청 많구나 싶었는데 문득 소규모 스타트업 프론트엔드 개발자들을 모아보면 어떨까 하는 생각이 들었습니다. 보통의 아티클들을 보면 내용이 좋고 너무 훌륭하지만 팀 규모가 다르다 보니 실제로 적용해 보기 힘든 부분들이 많았습니다. 그래서 작은 조직에서 겪는 문제와 그 해결책을 서로 나눈다면 그 경험들이 더 현실적이고 와닿지 않을까 하는 생각이 들었습니다.

두려움

만드는 과정에서 어려움이 많았습니다. 제가 사내에서 슬랙을 주로 사용하지도 않고 커뮤니티 운영도 처음이었기 때문입니다. 그래서 시작하기 전에 사람들이 괜히 들어왔다가 실망하고 나가지는 않을지 많이 걱정했습니다.

실행

하지만 일단 만들어보고 싶었습니다. 필요한 건 그때마다 배우면 되고 모르면 물어보고 싶었습니다. 설령 실패하더라도 많이 배울 것 같았습니다. 그래서 글에도, 초대 메시지에도 서툴 수도 있으니 같이 만들어 갔으면 좋겠다는 메시지를 추가했습니다. 처음으로 슬랙 워크스페이스를 생성해 보고 채널을 생성해 봤습니다. 취지에 맞게 비슷한 환경의 멤버분들끼리 묶어 드리는 걸 1순위로 생각해서 채널을 나눠보고 싶었습니다. 하지만 기준을 어떻게 잡아야 할지 고민이었습니다. 조직규모에 따라 나눌지, 프론트팀 또는 개발팀 규모에 따라 나눌지 고민했습니다. 처음엔 후자로 기준을 잡았는데 조직규모가 크면 개인이 활용할 수 있는 리소스가 더 많을 거 같아서 전자가 더 적합할 거 같아서 기준을 바꿨습니다. 어떤 게 더 적합할진 모르겠습니다. 하다가 안 맞으면 바꾸면 될 거 같아서 이렇게 진행했습니다.

덤으로 chatGPT로 멋진 로고도 만들어 봤는데 꽤 만족스러웠습니다.

모집글 게시

그렇게 링크드인에 글을 올렸습니다.

(별개로 초대 링크를 메시지로 보내는데 일촌이 아니면 보낼 수 없다는 걸 글을 올리고 나서 알아서 일촌이 아니신 분들에게는 열심히 신청하고 있습니다. 오히려 좋아 😅)

1월 6일

자기소개를 아무도 쓰지 않아서 자기소개 템플릿을 만들고 첫 글을 올렸습니다. 아래와 같은 형식이었는데 생각해 보니 너무 딱딱한 거 같았습니다.

어떤 규모의 조직에서 일하시는지
어떤 문제를 풀고 있는지
어떤 문제를 풀어봤는지

자기소개는 조금 더 편하게 작성하도록 하는 것이 좋은 거 같다는 생각이 들었습니다. 그래서 아래와 같이 템플릿을 바꿨습니다.

어떤 규모의 조직에서 일하시는지
속해 있는 개발팀 규모는 어떤지
연차
참여한 이유
기대하는 점

제 첫 자기소개를 올리고 3일 후에 멤버분들께서 하나둘씩 글을 올리셔서 제일 활성화된 채널이 됐습니다. 글들의 4번과 5번 문항을 읽다 보니까 멤버분들의 니즈를 파악할 수 있어서 좋았습니다.

1월 7일

그래도 14명 정도 모였습니다. 링크드인에 참여 신청 댓글 알람이 오면 기분이 좋은데 아무도 글을 쓰지 않아 신경이 쓰였습니다. 채널을 만들면 엄청 활발하게 이야기하실 줄 알았는데 그건 제 고정관념이었던 거 같습니다. 80%의 결과가 20%의 원인에 의해 발생한다는 파레토의 법칙이 있습니다. 이걸 여기 적용해 보면 80퍼센트의 글은 20퍼센트의 멤버들이 작성한다는 가설이 나오는데, 생각해 보니 제가 속해 있는 다른 채널도 항상 글이 엄청 활발하진 않다는 걸 깨달았습니다. 예외로 글또 채널이 있긴 한데(글또 사랑해요) 여기는 멤버분들이 엄청 활발하십니다 👍🏻. 아무래도 글또 채널에 주로 접속해 있다 보니까 제 채널도 그랬으면 좋겠다는 마음에 조바심이 컸던 거 같습니다. 그래서 20퍼센트의 멤버들만이라도 글을 쓰게 해보자는 방향으로 생각을 바꿨고 마음이 한결 편해졌습니다.

1월 8일

아티클-공유해요 채널을 생성했습니다. 처음에는 조직규모에 따른 채널만 만들었는데 사람도 없는데 이런 채널에 처음 들어와서 말을 시작하기 어려울 거 같아서 장벽이 낮은 채널을 만들었습니다. 글을 하나 공유했는데 멤버분도 글을 공유해주셔서 신이 나서 댓글을 달았습니다. 자유로운-이야기 채널에도 생각나는 대로 글을 작성했습니다. 화목순대국을 먹은 얘기를 할까 하다가 너무 갑분싸가 될 거 같아서 참았습니다.

1월 9일

회사에서 유저 인터뷰를 하다가 “커뮤니티는 글 리젠률이 중요한 거 같다. 글이 어느 정도 올라와야 커뮤니티의 성격을 파악하고 그것에 맞게 글을 작성할 수 있다.”라는 말을 들었습니다. 이 말을 곰곰이 생각해 보니 제가 먼저 글을 많이 써봐야겠다는 생각이 들었습니다. 멤버분들은 제 글을 읽고 초대받긴 했지만 텅 빈 채널들을 보며 커뮤니티의 무드를 파악하긴 힘드리라 생각했습니다.

1월 11일

자기소개 채널에 글이 엄청 많이 올라왔습니다! 그래서 굉장히 반가웠습니다. 다양한 조직, 다양한 환경에 멤버분들이 속해 있다는 생각이 들었습니다.

이 이후로는 멤버분들이 이런저런 글을 올려주셔서 커뮤니티 운영에 대한 걱정이 거의 사라져서 따로 기록하지 않았습니다. 그리고 자유게시판에 커피챗을 하거나 모임을 해도 좋겠다는 멤버분들이 있으셔서 커피챗 채널을 만들었습니다 ☕️.

채널 데이터

슬랙의 분석 기능을 사용해 채널 데이터를 살펴봤습니다. 그래서 활성 멤버와 포스트한 멤버가 같이 우상향을 그리고 있어 기분이 좋습니다 ☺️

결론

이렇게 슬랙으로 처음 커뮤니티를 개설해 운영해 본 초기 경험을 적어봤습니다. 채널 운영은 순항 중이라고 생각합니다. 멤버분들이 필요한 게 뭔지, 필요하지 않은 게 뭔지 귀 기울여서 적재적소에 제공해 좋은 커뮤니티를 한번 만들어보고 싶습니다. 현재는 45명의 멤버분들이 함께 하고 계십니다. 그리고 아직 초대하지 못한 분들도 계시는데요. 이 글을 마치며 마저 초대하러 가보겠습니다 🫡

2023년의 나는 어땠나

Sat, 06 Jan 2024 00:01:56 GMT

순식간에 지나가 버린 2023년에는 어떤 일들이 있었고 어떤 나였는지 회고하려고 한다. 방향성과 성과에 대한 고민을 많이 했던 한해였다.

업무

어떻게 제품에 더 임팩트 있게 기여할 수 있을까?

대표님이 11월부터 OKR을 달성하기 위해 스쿼드가 그로스 모드로 일하는 것을 제안해 주셨다. 기존에 진행했던 실험들은 정합성을 높이는 방향으로 설계하다 보니 시간이 많이 들었다. 대신 그로스 모드에서는 정합성을 높이는 대신 야구 방망이를 많이 휘두르라고 하셨다. 측정하는 방식을 잘 설계하고 많은 실험 아이디어를 내서 그 내용을 토대로 조건도 바꿔보고 메시지, 채널도 바꿔보면서 최대한 많이 실험해 보는 것이다. 우리는 가설만 가지고 있을 뿐이고 판단은 고객에게 맡기면 된다.라는 말씀이 가장 인상적이었고 핵심을 찌르는 조언이었다. 그래서 나는 실험을 하나라도 더 하려면 무엇을 해야 할까?라는 질문에 리소스를 집중했다.

내가 작업할 실험들은 UI/UX를 변경하는 방식이 대부분이었고 그러면 기획, 디자인 리소스가 들어간다. 그래서 디자이너 리소스가 가득 차면 자연스레 개발자는 그걸 기다릴 수밖에 없었다. 기존에는 시간이 좀 남으면 기술 공부를 하거나 백로그에 있는 작업을 조금씩 했는데 그로스 모드에서는 내가 먼저 작업할 수 있는 실험들을 찾았다. 이 실험들은

새로운 디자인 작업이 필요 없거나(간단한 문구 변경, 기존 컴포넌트를 재활용하는데 UX도 동일한 경우)
디자인이 최소한으로 들어가는 실험들

이 있다.

1의 경우 문구가 필요하면 팀 아이디에이션을 통해 해결했다. 기존 컴포넌트를 재활용하는 경우는 기존 실험에서 성공했던 UI/UX를 다른 퍼널에 맞게 변형해 적용해 보는 것이었다. 예를 들어, A->B 퍼널에서 native card 광고를 통한 실험의 전환율이 높았었다면 다른 퍼널에도 똑같이 적용해 보는 것이다. 2의 경우 세부 디자인을 뺀 대략적인 설계를 해놓고 디자이너님에게 도움을 받았다.

11월 한 달은 실험 38개를 돌렸다. 그럼 업무일 동안 하루에 넉넉잡아 최소 1.7개는 돌렸다는 뜻이 된다. 엄청났다. 12월에는 실험 사이즈를 조금 크게 해서 주당 5개를 돌렸다. 그렇게 유저를 학습하고 학습점을 다음 실험에 반영하기를 반복했다.

계속 비슷한 퍼널의 실험 아이디어를 떠올리다 보니 스쿼드 구성원들 전부 아이디어가 고갈되어서 고생했던 부분도 있었지만 너무 재미있던 두 달이었다.

팀이 일을 더 잘할 수 있도록

많이 고민했다. 노션으로 프로젝트들을 관리하고 있었는데, 노션의 sprint 템플릿을 사용해 sprint 식으로 움직이려고 노력했다. 그래서 한 스프린트에 할당한 task 달성률을 통해 현재 스쿼드가 어떤 텐션으로 일하고 있는지 가늠해 보려고 했다. 또한 회고에 많이 신경 썼다. 작은 프로젝트라도 끝난 후에 회고를 통해 개선점을 서로 얘기한 부분이 도움이 많이 됐다. 실험이 끝나고 나서는 학습점을 한문장으로 정리하려고 노력했다. 한문장으로 만들려고 고민하는 부분에서 생각이 많이 정리됐다.

글쓰기

나는 글을 지지리도 쓰지 않는 사람이다. 글쓰기가 중요하다는 소리는 많이 들었지만 정말 실천하기 힘들었다. 자기 생각을 글로 잘 표현하는 것은 엄청난 역량이라는 생각이 들었고 열심히 훈련해야겠다는 생각이 들었다. 실무에서도 너무나 중요한 부분을 차지한다고 생각한다. 지금의 나는 글또 9기에서 활동하고 있고 이렇게 노력하고 있다.

글을 한 번에 술술 써내려 가는 것은 너무나 어렵기 때문에 여러 가지 주제를 펼쳐놓고 생각날 때마다 내용을 채우고 있다.
사내 블로그에 글을 작성할 때는 팀원들의 피드백을 많이 받았는데 글을 잘 쓰시는 분들이 많아서 많이 고치면서 배웠다.
많은 부분을 의도적으로 글로 남기려고 하고 있다. 무언가를 할 때 애초에 글을 쓸 생각으로 시작하면 도움이 많이 된다.

계획, 메모

MBTI 대문자 P인 나는 계획, 습관이랑은 먼 사람 같았다. 계획을 세워놔도 며칠 지나면 잘 안 보게 되고, 눈앞의 반짝이는 것에 매달렸다. 몇장 쓰다 만 다이어리도 엄청 많다. Todo app도 이것저것 써봤는데 이것도 몇일 후엔 잘 보지 않았다. 그런 내가 계획, 메모의 필요성을 느낀 부분은 다음과 같다.

내가 기억력이 별로 좋지 않다.
- 기억에 의존하는데 기억력이 좋지 않으니 다시 떠올릴 때 노력이 배로 든다.
- 할 일 또는 하고 싶은 일이 많은데 “나중에 해야지” 하고 기억하려고 하니 뇌에 부하가 왔다.
시간은 유한하다.
- 내가 하고 싶은 걸 전부 다 하면서 살 순 없다.
- 그중에 중요한 것부터 해야 한다.
- 그러기 위해선 미리 기준을 세우고 라벨을 붙여놔야 한다.
- 그렇지 않으면 어떤 일을 시작할 때마다 우선순위를 다시 고민해야 한다.

Todo app에 기억을 위임하고 있다. 할 일이 생각하면 바로 Todo app에 마감 기한까지 찍어서 추가하고 있다. 그러면 그 일에 대한 생각을 그만하고 더 중요한 것에 집중할 수 있다.

시간 블록

캘린더에 시간 블록을 추가한다. 꼭 이 시간에 이걸 해야 하는 건 아니지만 이렇게 가이드라인을 추가해 놓는 것만으로도 내가 정신없을 때 뭘 해야 할지 고민하지 않고 바로 실행할 수 있다.

리추얼

생산성 관련 강의를 참고해 리추얼을 만들고 계속 수정해 나가고 있다. 반복되는 작업을 습관으로 만들면 뇌가 그 일을 하는데 쓰는 에너지가 줄어든다고 해서 해보고 있다.

성취

헬스

몇 달 동안 헬스를 했다. 식단도 같이 했다. 하는 동안 몸의 변화도 조금 느껴졌다. 더 건강해졌을까? 잘 모르겠다. 소화를 잘 못하는 내가 단백질 양을 채우려고 쉴 틈 없이 닭가슴살을 먹었는데 평소에 활동량이 부족하다 보니 버겁긴 했다. 운 좋게 공용으로 쓸 수 있는 인바디 측정기가 있어서 주기적으로 측정했는데 체지방량과 근육량의 변화에 일희일비하며 살았던 시기가 있었다. 😅 웃기게도 헬스장이 내부 보수공사에 들어가면서 쉬게 됐는데 공사가 끝났는데도 아직도 쉬고 있다. 겨울은 게을러지는 계절..

밴드 공연

일렉기타를 배웠다. 한달동안 레슨받고 한달동안 합주해서 공연까지 하느라고 짧은 기간동안 엄청나게 연습했고 실력이 단기간에 늘었다. 이 시기에는 퇴근하고 정말 기타만 쳤다. 처음에는 C코드도 잡지 못했던 내가 세컨 기타로 4곡이나 공연하기까지의 레벨이 오른 경험이 정말 뜻깊었다. 공연이 끝나고 연습이 부족해서 아쉬워하고 싶지 않아서 악보도 다 외우고, 손에 익을 때까지 열심히 연습한 후에 무대에 올라 만족스러웠다.

2024년의 나

기술 공부

올해는 기술 공부에 많은 시간을 투자하려고 한다. 작년에 시간을 많이 투자하지 못한 게 아쉽다. 기술 서적도 많이 읽고 블로그에도 많이 남겨보려고 한다.

사이드 프로젝트

요즘에 사이드 프로젝트 관련 글을 많이 읽어서 더 노력해야겠다는 생각이 들었다. 내가 생각하는 아이디어를 빠르게 구현할 수 있는 모습이 내 목표다. 나만의 보일러 플레이트, 손에 익은 기술스택을 갖고 싶다.

글쓰기

계속 글을 써서 습관으로 만들고 싶다. 내 생각을 조리있게 표현하는 것이 목표다. 블로그 글, 문서를 더 잘 쓰고싶다.

회고

올해는 달마다 회고글을 작성하고 싶다. 그러면 저절로 한 해 회고가 되지 않을까. 한번에 회고하고 작성하려니까 너무 어렵다.

초보 개발자도 오픈소스에 기여할 수 있다 - Notion Avatar Maker 한국어 버전 개발기

Sun, 10 Dec 2023 15:13:06 GMT

오픈소스는 어렵다

개발자의 성장에 대한 글을 보면 자주 강조되는 부분이 오픈소스 기여다. 성장하고 싶었던 나도 오픈소스에 기여하고 싶었다. 하지만 우리가 사용하는 오픈소스 React, Vue.js등의 이슈를 찾아 해결해보려고 해도 이해하기도 어렵고 어떻게 고칠 수 있는지 감도 잘 안 오지 않았다. 그래도 굴하지 않고 코드를 보고 이해해 보려고 해도 역시나 어려웠다.

그런 나도 엄청나진 않지만 작게나마 오픈소스에 기여하면서 살고 있는데 기여 기회를 찾는 나만의 꿀팁과 실제로 기여했던 프로세스를 공유하고자 한다.

기회 잡기

나는 기여하려고 기회를 찾기 보다는 오는 기회를 잡는 편이다. 예를 들어, 공식문서를 보는데 스타일이 깨져서 보인 경우, 좋은 자료가 담긴 repository가 있는데 한국어 버전이 없는 경우, 공식 문서에 잘못된 명령어가 적혀 있는 걸 찾은 경우, 흥미로운 사이트를 찾았는데 한국어 버전이 없는 경우 등이다. 이번에 소개할 예는 흥미로운 사이트를 찾았는데 한국어 버전이 없는 경우이다.

Notion Avatar Maker라는 사이트를 구독중인 뉴스레터에서 발견했다. 노션 스타일의 아바타를 직접 만들 수 있는 사이트이다. 요소들을 클릭해서 나만의 아바타를 만들 수 있고 노션 스타일로 만들 수 있다는 게 매력적이었다. 가지고 놀다가 이 사이트의 한국어 버전이 없다는 것을 깨닫고 기여해보고 싶다는 생각이 들었다. 그리고 내가 기여할 수 있는지 체크했다. 일단 이슈나 PR에 한국어 지원 관련 내용은 없어서 다른 사람이 작업 중이진 않은 것 같았다. 그 다음으로는 어떻게 작업하면 될지 살펴봤다.

일단 README 파일에 I18n로 영어와 중국어를 지원한다고 적혀 있었다. 그래서 파일을 찾아보니 public/locales 디렉토리 내부에 관련 파일들이 있었다.

다음으로는 repository를 clone해서 public/locales/zh/common.json 파일의 변경내역을 살폈다.

커밋 전체 내역을 보니까 아래와 같은 작업 내역들이 있었는데, 초기 작업이다 보니까 i18n 라이브러리를 설치하고 세팅하는 부분들이 있다. 여기서 나는 next-i18next.config.js에 locales/ko/common.json을 추가하면 될 것 같았다.

이제 내가 작업할 내용이 어느정도 보였기 때문에 로컬 서버를 실행했다. public/locales/ko/common.json을 생성하고, next-i18next.config.js의 locale에 ko를 추가했다. 작업 후 실행해보니 아주 잘 적용되는 것을 볼 수 있었다.

빠진 부분이 없는지 이것저것 기능을 테스트해보는 데 걸리는 부분이 있었다. 영어와 한국어가 어순이 다르기 때문에 “눈 선택”이라고 나와야 자연스러운 부분이 “선택 눈”이라고 나오고 있었다. 그래서 이 부분을 코드에서 찾아봤다.

이 컴포넌트는 AvatarPicker였고 어순을 바꾸기 위해 한국어일 때 분기하는 방법을 찾아봤다.

useTranslation hook에서 i18n.language에 현재 언어가 무엇인지 담겨 있었다. 그래서 아래와 같이 작성해보려고 했는데 한국어 한정 코드인 거 같아서 마음에 걸렸다. 그래서 이 작업은 커밋하지 않고 메인테이너에게 설명을 하고 조언을 구하고자 했다.

const {
  t,
  i18n: { language },
} = useTranslation('common')

;<h1 className="py-4 w-full">
  {language === 'ko'
    ? `${t(`${avatarPart.part}`)} ${t('Choose')}`
    : `${t('Choose')} ${t(`${avatarPart.part}`)}`}
</h1>

그렇게 아래 PR을 작성하고 어순을 바꾸는 부분은 코멘트로 달았다.

그러자 메인테이너가 i18n의 interpolation 기능을 사용하면 해결할 수 있을 거 같고 일단 머지하고 싶다고 했다.

그렇게 내 작업은 머지가 됐고 노션 아바타 메이커의 한국어 버전이 탄생했다. 🐥 뿌-듯

조만간 interpolation 기능도 공부해서 작업을 마무리하려고 한다.

작은 관심

이렇게 초보 컨트리뷰터가 기여할 수 있는 가장 현실적인 방법은 작은 관심이라고 생각한다. 막상 뭘 기여할까 찾다 보면 잘 안 보이지만 이렇게 관심을 가지다보면 기회가 생겼었다. 내 프로젝트는 아니지만 기여해보면 애착도 생기고 엄청나게 뿌듯하다. 그리고 새로운 배움의 기회가 온다.

나는 이런 경험들이 좋아서 기회를 찾자마자 신나서 회사의 팀원들과 나누려고 했는데 작업해야 할 부분이 너무 작아서 혼자 하기로 했다. 아래는 검토를 안하고 공유한 결과다 😅

공유 직후

작업량 검토 후

테크 커리어 리뷰

Wed, 30 Aug 2023 22:08:31 GMT

같은 시리즈로 나온 다른 책들도 읽어 봤고 내용이 좋아서 이 책도 기대를 많이 했다. 개발자로서 어떻게 경력을 관리하고 쌓아갈지, 그리고 회사에서 성과를 내기 위한 태도와 마음가짐 등 인사이트를 주는 책이었다. 그래서 어느 정도 일을 해 보신 분들이 예상 독자가 아닐까 싶다.

특히 이 책은 각 장이 끝날 때마다 실천해 볼 수 있는 실천 과제를 줘서 액션 아이템을 세우는데 도움을 받을 수 있었다. 한 장을 읽고 실천 과제를 수행해보면 내용 정리하기 수월했다.

이런 내용을 구체적으로 다루는 블로그 글이나 영상은 찾아보기 힘들다. 그래서 가뭄에 단비 같은 책이었다. 내가 일을 어떻게 바라보면 좋을지 그리고 나 자신을 어떻게 바라볼지에 대해 배우고 그 관점을 기반으로 경력 및 브랜드 관리, 네트워킹, 학습과 태도, 시간관리, 커뮤니케이션, 의사 결정 방법 등에 대해 배웠다.

실제로 적용해 볼 수 있는 내용들이고 양이 많아 한번에 모든 내용을 소화하기 보다는 두고두고 꺼내 볼 수 있게 백과사전식으로 활용해보면 좋을 거 같다.

출처 : yes24

길벗 출판사에서 책을 제공받아 읽고 작성한 서평이다.

인프콘 2023 후기

Tue, 15 Aug 2023 21:08:59 GMT

이 웅장한 인파가 얼마나 열기가 뜨거웠는지를 보여주는 것 같다.

작년엔 못 갔는데 이번엔 운이 너무너무 좋아서 인프콘 2023을 갈 수 있었다. 😆

큰 오프라인 행사에 가는 게 너무나도 오랜만이다.

등록

등록하러 갔을 때부터 사람이 엄청 많았다. 😱

이벤트들

전체적인 지도는 이랬다. 101~105호는 발표 듣는 곳. 외에 인프런 및 참가 회사들의 부스가 있었다. 2층은 핸즈온이나 프로그램이 따로 열렸다.

스탬프 받는 곳으로 가서 이벤트에 참여하면 스탬프를 모을 수 있고 4개당 한번! 뽑기 기회가 주어졌다.

오프닝

자리에 앉아서 어둠 속에서 오프닝을 기다리는 순간은 정말 가슴이 웅장해졌다.

멋진 성장을 이뤄낸 지표를 바탕으로 행사를 여시는 CEO님!

유튜브로만 뵀던 CTO 향로님! 연예인 보는 기분이었다.

듣고 싶었던 세션과 그 이유, 발표 내용 요약

구글 Apps Script와 ChatGPT로 많은 동료들 생산성 향상 시킨 썰

구성원들의 생산성을 향상하는 데 관심이 많아 다른 회사 사례도 들어보고 싶었다. 어떤 계기로 어떤 작업을 어떻게 줄였는지 궁금했다.

메일을 대량 발송하는 업무를 하고 계신 동료분의 메시지를 받고 몇백 개의 메일을 한 번에 보내다 보면 시간이 꽤 걸린다고 계산하셨다. 그래서 이를 자동화할 수 있다면 소중한 시간을 꽤 단축할 수 있을 거로 생각하시고 방법을 찾아가셨다. Apps Script에 익숙지 않아 ChatGPT에게 물어보고 원하는 결과를 얻을 때까지 피드백을 주면서 기능을 구현하셨다.

문제는 이걸 개발자가 아닌 동료분이 사용하셔야 했던 건데, 한 줄 한 줄 친절하게 주석을 달아주셨다. 더 사용하기 쉽도록 동영상 강의를 직접 찍어서 공유하셨다고 한다. 그러고 나서 사용하던 동료분들의 새로운 요구사항이 등장했다. 그것은 바로 특정 이메일은 첨부파일을 다르게 보내는 기능이었는데, 이것도 구현을 해내셨다. 그리고 이 문제를 겪고 있는 다른 동료분들도 계실 거로 생각해서 전사에 공유하셨다고 한다. 👍

많은 동료의 시간을 아껴준 엄청 임팩트 있는 일을 해내셨다는 게 인상 깊었고, 사용법을 알려주는 동영상 강의를 직접 찍어서 공유하신 점, 더 나아가 전사에 공유하신 점이 좋았다.

나도 회사에서 그렇게 어렵지 않은 작업으로 동료들의 생산성을 향상한 사례가 있다. 어드민에서 테이블 텍스트를 클릭하면 자동으로 복사가 되는 기능이었다. 테이블 텍스트를 클릭하면 테이블에 따라 그 데이터의 편집 페이지로 이동하는 등 기존의 액션이 있어서 텍스트만 복사하기가 어렵다고 하셨었는데 불편해하시는 줄 몰랐었다가 그 목소리를 늦게나마 들어서 작업했었다. 반응이 너무 좋아서 뿌듯하기도 했지만 😎 그런 목소리를 들을 수 있는 환경을 구축해야 더 쉽게 불편함을 캐치할 수 있을 거라는 생각이 들었다. 🦻🏻

출시 3일만에 앱스토어 2위를 달성한 사이드 프로젝트

disquiet이라는 커뮤니티에 글이 올라와서 시간 가는 줄 모르고 읽었던 흥미로운 경험이었다. gas라는 앱을 카피해서 한국에서 디지털미디어 고등학교(이하 디미고) 학생들이 가설을 세우고 검증하면서 그로스해 나갔던 이야기가 담겨 있는데 개발 담당이었던 김아인 님도 발표에 참여해서 더 풍부한 내용을 들을 수 있을거라 생각했다.

미국의 gas라는 앱이 성공하면서 한국에도 똑같은 앱이 먹힐지 가설을 세우고 검증해본 이야기이다. 미국의 15~19세 인구와 한국의 인구를 비교해 미국에서 기간별로 이만큼 매출이 일어났으니 한국에서 이정도 매출이 나야 성공으로 정의할 수 있다.라고 지표를 세웠다. 아이디어 불패의 법칙이라는 책에 나온 XYZ 가설8을 활용해 가설을 세웠다고 한다. => skrr 미디어에 3번 이상 노출된 유저들의 n%는 앱을 설치할 것이다, 과금을 할 것이다 등.

디미고 특성 상 전국 각지에서 학생들이 모이기 때문에 전국적으로 바이럴이 일어나기 좋은 환경이라고 생각했다고 한다. 처음에 인스타그램 마케팅(계정을 만들어 디미고 학생들 팔로우하기), 쪽지 GTM(오프라인에서 그럴듯한 쪽지를 적어서 건네주는) 등의 활동을 하면서 유저를 모았다고 한다.

몇일이 지나 1일 7천명이 설치하며 앱스토어 소셜 2위에 올랐다고 한다. 하지만 여기에 안주해 결국 경쟁사가 더 치고 올라갔다고 한다.

실패의 원인으로는 먼저 팀원들을 지속적으로 동기부여하지 못했으며 제어 불가능한 변수를 만나기도 했다고 한다. 그래서 mvp단계에 머무르다 보니 다음 단계로 나아가지 못했다고 한다.

개발 프로세스에서 Feature Develop Cycle(1FDC)를 잘개 기능별로 쪼개서 빠르게 피드백 받으며 나아갔다고 한다. 쪼갠 기능으로는 “마이페이지에서 친구초대하기”, “친구 검색 기능” 등이 있다.

초기에 데이터를 json file로 관리했다고 한다. 서버 개발 지식과 경험이 많지 않아 익숙한 방법을 사용했다고 하는데 트래픽이 올라가면서 파일 읽기 쓰기가 많이 발생, 동시성 제어가 안됨, 파일이 길어질수록 속도가 느려지는 등의 이슈가 발생했다고 한다.

서비스 로그를 중요한 부분만 남기고, json 구조 개선 등을 통해 성능 개선을 하다가 json 형식을 거의 그대로 쓸 수 있는 mongodb로 넘어갔다고 한다.

XYZ 가설의 경우 프로젝트 근래에 읽은 책에서 배운 내용인데 바로 적용해봤다는 점이 참 좋았다. 나도 책에서 배운 내용을 적용하는데에는 아직 서툰데, 실행력이 굉장히 멋지다. 미국의 사례를 바탕으로 한국과 비교해 목표를 세운 점도 배울 점이었고 실패했던 원인은 내가 비슷한 상황을 만났을 때 어떻게 개선할 수 있을지 고민해보면 좋을 거 같다.

왜 내가 만든 서비스는 아무도 안 쓰지?: 개발자가 알아두면 좋은 사이드 프로젝트 제작 팁

내 이야기이다 😂. 사실 나는 작은 사이드 프로젝트를 개발하고 출시해서 사용자 피드백을 받고 다시 개선하고 있다. 사이드 프로젝트에 관심이 많지만 아직 경험이 부족한 내가 정말 관심이 갔던 이야기였다.

사이드 프로젝트를 29개나 하셨다는 점이 인상깊었다. 그 중 코로나맵이 일주일 1000만 조회, 1400만 사용자를 이끌어 내셨다.

좋은 문제를 찾고 이해하고 해결하기라는 부분을 강조하셨는데 우리가 간과하는 점이 상품은 시장의 니즈로부터 나와야 하지만 우리는 솔루션을 먼저 정의하고 고객을 끼워 맞춘다는 것이다. 그러니까 사람들이 쓰지 않는다. 즉, 내가 만들고 싶은 서비스를 만들고 있었다고 볼 수 있다.

좋은 문제를 찾으려면

주변에 당연하다고 생각하는 것에 반문하고
관찰하며
펼쳐봐야

한다고 하셨다.

코로나 맵을 만들 때 패턴화된 페이스북 댓글을 감지했다고 하셨다.

오늘 오후 3시에 서울역에서 확진자 나왔다는데 진짜인가라는 댓글인데 여기서

불안감을 남들과 공유
위치, 시간 정보 알고 싶음
정확한 정보를 찾을 수 없음

을 파악하셨다. 코로나 정보를 얻기 위해 가독성 떨어지는 보도 자료를 읽어야 한다는 점을 개선하려고 하신 것에서 출발했다.

가능한 짧은 시간 안에 완성하는 것을 강조하셨다. 프로젝트를 계속 하다보면 동기가 점점 떨어지기 때문이다.

어떤 문제를 어떻게 해결하려고 했는지
어떤 기술스택을 왜 사용했는지
어떤 결과가 나왔고 얻은점은 무엇인지

를 기반으로 경험을 잘 기록하라고 하셨다.

성공한 프로젝트가 나오기 까지 수많은 실패와 도전이 있었다는 게 인상깊었고 동기부여가 됐다. 또한 주변을 관찰하다가 불편함을 찾아내고, 개선방향을 생각해낸 인사이트도 좋았고 짧은 시간안에 완성해야 한다는 것에 공감을 많이 했다. 또 이제까진 기록을 별로 하지 않았지만 앞으로라도 경험을 기록해야겠다는 생각이 들었다.

어느 날 고민 많은 주니어 개발자가 찾아왔다 2탄: 주니어 시절 성장과 고민들

요즘 성장에 대한 고민을 많이 하고 있어서 비슷한 사례가 있을지, 그에 대한 조언이 있을지 궁금해서 듣고 싶었다.

듣지 못했다. 😭 인기가 너무 많아서 자리가 없었다. 대신 사람이 없는 이 시간을 활용해 스탬프 투어를 완료하고 밥을 먹었다. 👍

팀플레이어 101: 팀의 성공을 위해 달리는 메이커 되기

팀원으로서 어떻게 움직여야 팀에 도움이 되고 서비스에 도움이 될지 고민이 많아서 관심이 갔다.

이 발표는 사례 중심이었고 내가 빠르게 못 적어서 정리를 많이 못했다. 영상으로 다시 볼 예정이다.

더 나은 팀플레이어가 되기 위해

멋지다 싶으면 적는다.
실천하기 위해 액션 아이템으로 적는다.
반면교사도 적는다.

를 실천하셨다. 노션에 81개의 best practice를 정리해서 모아놓으셨다. 성공보다는 시도가 중요하다고 하셨다. 적은 내용을 자기만의 방식으로 시도하는 것이다.

예를 들면, 이 맥북으로 교체하면 로컬 빌드 속도가 n% 빨라지고, 개발이 이정도 빨라지니 같은 기간 내에 배포를 m번 더 할 수 있다. 라고 맥북 구매 이유를 적은 사례가 있었다.

다른 사례로는, 구현하기 굉장히 어려운 디자인 시안을 받았을 때, 기간 내에 하기 위해 야근을 하는 게 아니라, 이 부분은 이런 이유로 이 기간 내에 완성하기가 어렵다. 기능이 같지만 공수가 적게 드는 대안으로 기간 내에 배포를 하고 추후 데이터를 보면서 개선하는 건 어떨까요? 라고 커뮤니케이션 하는 것이다.

이런 사례들이 몇 개 더 있다.

맥북 사례는 비슷하게 경험을 했었는데, 빌드 속도가 n% 빨라진다는 것까진 생각을 했는데 이로 인해 배포를 m번 더 할 수 있다는 생각까진 도달하지 못했었다. 😂 그래서 사고가 확장된 느낌을 받았고 두번째 예 같은 경우에는 나도 해봤던 커뮤니케이션 방식이어서 신기했다. 그 외 다른 예들을 들어보면 내가 커뮤니케이션 하는 방식보다 조금 더 본질적이고 깊게 들어가는 거 같아서, 나중에 영상이 올라오면 다시 정리해보고 적용해보려고 한다.

주니어 프론트엔드 엔지니어의 성과 및 역량 향상을 위한 실전 가이드

어떻게 하면 내 역량을 더 향상시킬 수 있을지 실제로 적용해 볼 수 있을법한 내용을 기대했다.

저번에 공유해주신 너무 좋은 자료였던 프론트엔드 엔지니어 커리어 로드맵: 주니어를 위한 3가지 전문성 트랙에서 더 나아간 실질적인 실행방법들, 이론들이 주된 내용이었다. 이 발표도 정리를 잘 하지 못했다. 장표에 글이 많고 새로운 용어가 많아서 한번에 이해하기는 쉽지 않았다. 발표 속도도 빨라서 다른 분들도 필기 대신 장표를 폰으로 찍는 방법을 택하셨다. 이 발표도 영상으로 나오면 천천히 다시 볼 예정이다. 소화하고 체득하면 분명히 성장하는데 도움이 될만한 좋은 내용들이었다.

테크 챗

발표도 너무 좋았지만 테크 챗도 너무 좋았다. 내가 고민하고 있는 부분들을 직접 물어보고 조언을 구할 수 있기 때문이다. 카카오페이는 사전접수, 인프랩은 현장접수로 진행할 수 있었다. 😆

기획부터 배포까지의 사이클이 어떻게 진행되는지, 테스트 코드 작성, 팀 규모, api 명세, 팀 분위기 등에 대한 이야기를 나눴다. 카카오페이 개발자분은 같은 연차셔서 경험적인 부분에서는 공감하는 부분이 많았다. 인프랩 개발자분은 연차가 더 높으셔서 너무나 좋은 인사이트를 공유해주셨다.

테크 챗을 진행하면서 고민하고 있던 부분들 중 많은 게 해소됐고 시간 가는 줄 모르고 너무 재미있게 얘기를 나눌 수 있어 좋았다.

네트워킹

MBTI ISTP인 나에게 네트워킹 시간은 아직도 어렵다. 남들이 먼저 얘기하고 있으면 그 자리에 끼는 게 나는 너무나 어렵다. 이번에는 인프랩 직원분들이 도와주신다고 해서 그래도 괜찮지 않을까 기대하고 들어갔는데 다행히 인싸 직원분께서 프론트엔드 써클에 넣어주셔서 한 8분 정도의 개발자분들과 얘기를 나눌 수 있었다. 먼저 내가 개발하는 서비스 코멘토를 사용해보셨던 유저분이 계셔서 뿌듯했다. 😎

보통의 경우 다른 분들의 얘기를 들었었는데 이번에는 반대였다. 내가 연차가 가장 많았어서 😱 다른 개발자분들이 막 질문을 하셔서 긴장됐다. 😂 얘기를 많이 해서 오히려 좋았고 다른 저연차 개발자분들은 이런게 궁금하시구나 싶었다. 도움이 됐으면 좋겠다.

혹시라도 이 글을 보고 계신분들 중에도 저랑 커피챗 하시고 싶으신 분들은 언제나 환영입니다 :) 아래 메일로 남겨주세요!

thdehdgns@gmail.com

특히 좋았던 점

발표주제

발표 주제들이 대부분 발표자분들의 경험에서 우러나온 것들이어서 특히 좋았다. 그래서 발표자분들만의 고유한 이야기가 된 거 같다.

시간배분

전체적인 발표 세션을 40분으로 잡아놓고, 실제 발표 20분, QnA시간 20분을 배정한 게 좋았다. 쉬는 시간도 20분으로 넉넉해서 숨을 좀 돌리거나(연속으로 발표를 듣는건 은근 힘들다) 화장실에 가기 충분한 시간이었다.

QnA

보통 발표가 끝나면 다음 발표가 이어지기도 하고, 발표자분께 가서 따로 물을 환경이 안되면 연락하기가 힘든데, 발표가 끝나고 깃발을 든 직원분을 따라가면 QnA 장소에서 더 궁금했던 것을 편하게 물어볼 수 있어서 너무 좋았다.

네트워킹 경험

네트워킹에서 스티커로 명찰을 꾸밀 수 있었는데 말 걸어주세요 스티커가 보여서 취향저격 당했었다. 😂 네트워킹이 어려운 사람들을 많이 배려해주신 모습이라고 생각했고, 직원분들께서 네트워킹을 도와주셔서 너무 편했다. 테크챗을 하고 나서 가서 시간이 많지 않았는데 재밌어서 시간가는 줄 모르고 대화하니까 정말 빨리 지나갔다.

아쉬웠던 점

점심시간이 조금 아쉬웠다. 특이 케이스긴 하지만 나의 경우는 점심 시간 전 세션에서 QnA까지 진행했는데 끝나니까 1시 40분으로 점심시간을 20분만 쓸 수 있었다. 그렇다고 QnA를 포기할 수는 없었다. 너무 좋은 말씀을 많이 해주셔서 엄청나게 도움이 됐다. 😱

시간보다도 광활한 코엑스에서 밥집을 찾아서 식사를 해결하는 게 시간이 조금 걸렸다. 다른 분들 얘기를 들어보니까 인파가 한번에 몰려서 줄을 서기도 했다고 하셨다. 그리고 그쪽 물가가 비싸기도 하다. 🥲

도시락을 한번에 주문해서 제공하면 불편함도 줄이고, 식사하면서 자연스럽게 네트워킹 하시는 분들이 계실 수도 있고, 비용도 덜 수 있지 않을까 하는 아이디어가 생각났다.

행사 풍경

리코gr3 똑딱이 카메라를 오랜만에 들고 갔다. 그냥 잠깐잠깐 허리춤에서 꺼내서 찍느라고 구도가 이쁘거나 하지 않다. 날것의 시선이었다. 사람이 너무 많아 많이 찍지도 않았다.

현장을 가니까 전문 작가분들이 사진부터 동영상까지 전담하고 계셔서 멋있다고 생각이 들었다. 저번 엑셀콘에서는 내가 사진을 찍고 있었는데 역시 인프콘이다 싶었다 👍 발표 중간에 사진 찍으려고 포지션 잡는 작가님들을 보면서 이런 위치에서 이런 각으로 찍으시는구나 슬쩍슬쩍 보기도 했다.

얼굴이 나오는 사진은 블러처리를 했는데 혹시라도 문제가 있다면 알려주시면 감사하겠습니다.

굿즈 모음

굿즈가 너무 푸짐해서 어깨가 아팠다. 😂

스탬프 찍으러 부스에 가면 받을 수 있었는데 귀염뽀짝한 스티커부터 티셔츠, 수건, 키보드 덮개, 안경닦이, 칫솔세트, 키캡, 썬스틱, 부채 등 실용적인 굿즈까지 너무 좋았다. ☺️

쉽게 시작하는 타입스크립트 책 리뷰

Sat, 12 Aug 2023 09:09:32 GMT

캡틴판교님이 쓰신 쉽게 시작하는 타입스크립트 책을 리뷰하려고 합니다. 🥰

독자(나)의 수준

실무에서 메인 프로젝트에는 도입하려다가 에러가 너무 많이 나서 보류했고(nuxt는 웁니다), 서브 프로젝트, 사이드 프로젝트에서는 조금 써봤던 정도의 수준이기에 입문자 정도라고 생각합니다.

좋았던 점

글과 함께 실려있는 많은 이미지들이 도움이 많이 됐습니다.
- 책이나 블로그에서 타입스크립트를 마주하면 텍스트만 있는 경우가 대부분이었는데, 이 책은 코드를 IDE나 플레이그라운드에 직접 작성하고 보여지는 에러 밑줄, 툴팁 등을 같이 첨부해줘서 내용을 이해하기 수월했습니다.
이미지 외에도 새로운 개념이 나타났을 때 부연설명이 자세해서 따로 검색해보지 않아도 책을 읽는데 문제가 없었습니다.
예시들이 실무에 가깝습니다.
- 책을 읽다가 이런 부분은 프로젝트에 이렇게 적용해보면 되겠다. 하는 부분들이 많았습니다.
- 특히 Partial 유틸리티 타입은 처음 알았는데 너무 편해보였습니다.
개념 설명에 끝나지 않고, 이 개념의 장단점은 이런데 이런 상황에서 쓰면 더 좋다, 이 개념이 꼭 필요한 이유 등 사용해야 하는 이유, 활용방법에 대해서 같이 고민해볼 수 있어서 좋았습니다.
앞에서 배운 내용을 바로 써 볼 수 있는 실습이 제공되어서 도움이 많이 됐습니다.
타입스크립트 설정 부분에서 속성 하나하나 자세한 설명이 있어서 좋았고, 실무에선 어떤 식으로 활용하는지도 나와있어 좋았습니다. 설정 속성이 궁금해서 찾아봐도 내용이 너무 간결하거나, 읽어도 이해 안됐던 적이 많았는데 이 책을 통해서 확실히 이해할 수 있었습니다.
뒷 부분에 있는 외부 라이브러리 타입 정의 방법 등 저자분의 경험이 녹아 있는 꿀팁들도 정말 도움이 많이 됐습니다. “와 이런게 있구나”하면서 재미있게 읽었습니다 😂.

구매 링크

교보문고

yes24

알라딘

supabase + typescript DB schema 연동하기

Sun, 23 Jul 2023 21:07:45 GMT

이슈

supabase로 사이드 프로젝트를 하고 있다. Talk table에서 데이터를 가져오기 위해 interface를 선언했고 ref에 generic으로 넘겼다.

예시 코드는 vue3 + typescript 환경이다.

export interface Talk {
  id: number
  speaker_id: string
  topic: string
  created_at: string
  duration: number
}

const talkList = ref<Talk[]>([])

supabase를 이용한 select 결과에서 data를 검사하면 string key와 any value를 가지는 일반적인 타입으로 추론되는 것을 확인할 수 있다.

그래서 Talk interface와 맞지 않기 때문에 타입 에러가 난다.

설령 data type을 단언한다 해도, DB schema가 변하면 다시 작성해야 한다.

해결

supabase-cli를 활용하면 DB schema를 추출해 supabase sdk와 연동할 수 있다. 아래 링크를 보면 쉽게 따라갈 수 있다. https://supabase.com/docs/guides/api/rest/generating-types

PROJECT_REF를 찾는 게 처음에 어려웠는데, supabase dashboard를 들어간 후에 url에서 project 뒤에 오는 부분을 PROJECT_REF 칸에 넣어주면 된다.

https://supabase.com/dashboard/project/$PROJECT_REF

npx supabase gen types typescript --project-id "$PROJECT_REF" --schema public > src/types/supabase.ts

생성된 Database interface를 generic으로 넘긴다.

이렇게 적용하고 기존 코드를 다시 보면 data 타입이 바뀐 것을 볼 수 있다!

기존에 선언했던 Talk interface는 다음과 같이 Database interface에서 꺼내온 것으로 대체할 수 있다.

// /types/talk.ts
import type { Database } from './supabase'

export type Talk = Database['public']['Tables']['talk']['Row']

회의실 예약 시스템을 내렸습니다.

Tue, 18 Jul 2023 23:08:21 GMT

이전 포스트에서 회의실 예약 시스템을 만들어서 팀 내 시스템 문제를 해결하려고 했다.

그리고 이 글을 여러군데에 올렸는데, 생활코딩에서 내 글을 본 동료 개발자분에게 카톡이 왔다.

내가 아는 구글 캘린더에서 위치, 메모, URL은 추가해봤는데 회의실 기능은 처음 들어봤다. 그래서 관련 문서를 열심히 찾아봤다.

먼저 건물을 추가해야 회의실을 추가할 수 있는데 구글 관리 콘솔에 관리자 계정으로 로그인하고 캘린더 건물, 기능, 캘린더 리소스 만들기를 따라 추가하면 금방 한다.

그렇게 작고 소중한 회의실 2개를 추가할 수 있었고

팀원들에게 빠르게 이 사실을 알려주었다. 회의실 예약 시스템을 공개한지 단 이틀만이다 😅

기존 문제는 그대로 해결할 수 있고, 구글 캘린더 연동 기능은 생각도 하지 않아도 되니 너무 좋은 발견이었다.

소중한 사이드 프로젝트를 내려야 해서 조금 아쉬웠지만 나는 다른 문제를 해결하는데 시간을 쓸 수 있다는 생각이 더 앞섰다. 풀어야 할 문제는 많으니까.

글을 쓰는건 부끄럽지만 도움이 된다

사실 내가 뭐 대단한 걸 해서 글을 쓰고 여기저기 올리는 것은 아니다. 잘 쓰는 것도 아니도 그렇게 깊지도 길지도 않다. 작은 경험이라도 누군가에겐 재미있고 도움이 되지 않을까 해서 올리는건데 이 글을 올리지 않았다면 나는 예약 시스템을 머리 싸매고 열심히 개발하고 있었을 것이다.

저번에도 트리거 관련 글을 썼다가 어떤 개발자님께서 댓글을 달아주신 적도 있다. 내 친구 개발자도, 아는 개발자분도 현업에서 trigger가 어떻게 쓰이는지 내 글을 보고 알려주셨다. 프론트 개발자인 나는 아마 평생 몰랐을 지식이었을 것이다.

카톡을 보내준 갓개발자님께 감사드리며 이 글을 마친다.

주니어 프론트엔드 개발자의 6월 회고

Sun, 09 Jul 2023 22:08:29 GMT

회사에서의 나

🧑🏻‍💻 업무

커뮤니티 광고 구좌를 만들기 위해서 여러 곳에 광고를 넣어보고 클릭 전환율을 측정하는 실험을 디자이너님과 진행했다. 아직 측정 중인 실험도 있고 가드레일 지표가 무너져서 실패한 실험들도 있다.

무작정 광고를 추가하기보다는 먼저 실험해 본 경험이 좋았다. 생각 외로 가드레일 지표가 무너져 버렸던 점도 인상 깊었다.

데이터 분석을 더 정교하게 하기 위한 gtm 수정 작업을 했고 데이터 이관 작업 때문에 스쿼드가 정신없었다.

📝 스터디

프론트팀 javascript 스터디를 완주했다. 👏 알다가도 모를 javascript를 조금 덜 헷갈리게 해 준 스터디였다. 7월에 전체적으로 한 번 더 봐야겠다는 생각이 들었다.

진행하다가 흐지부지된 스터디들도 있었기에 뿌듯했다. 스터디를 이어 나가는 게 참 어렵다. 학습자료의 분량, 난이도, 스터디 방식 등 생각해야 할 것들이 많다. 이것저것 하다 보면 그래도 성공률이 높은 데이터들이 남아 있을 것이다.

👨🏻‍🔧 메이커로서의 나

메이커로서의 역량을 키우고 싶다. 내가 생각하는 걸 빠르게 구현하는 능력을 갖추는 게 목표다. 그래야 문제를 맞닥뜨렸을 때 잘 해결할 수 있기 때문이라고 생각한다. 또한 여러 가지 문제 상황에 노출되면서 내가 성장할 수 있다고 믿고 있다.

그렇게 혼자 처음 만든 고무 오리 앱이 아래 있다.

궁금하시다면 ☺️

혼자서 기획, 디자인하는 게 정말 어렵다. “이게 최선인가?” 계속 되묻지만, 아직 “예”라는 답이 나오려면 멀었다. 아무래도 피그마를 다뤄야 할 거 같아서 유튜브에서 열심히 공부했는데 간단한 걸 만드는 데 큰 도움이 되었다.

사람들에게 공개했을 때 반응은

무슨 앱인지 모르겠다.
왜 써야 하는지 모르겠다. (from INTP 동료)

1은 내가 예상했던 것과 다른 반응이었다. 고무 오리 앱에 대한 개념이 사람들에게 생소한 것일 줄은 몰랐는데 나의 착각이었다.

2는 친한 동료분께서 말해주신 피드백이다. 차갑게 들릴 수 있는데 나는 괜찮다 😂. 나는 입에 발린 말보다 쓴소리를 좋아하는 사람이기 때문. 맞는 말이다. 아직 "굳이 브라우저를 켜서 여기 왜 들어와야 하는가?"하고 물어봤을 때 대답하지 못한다. 그 경험을 찾는 여정이 될 거 같다.

배운 점을 요약하면 다음과 같다.

회사 밖 환경에서 혼자 만드는 스킬은 숙련되지 않았다.
배포하고 사람들의 반응을 봐야 한다. 그래야 내 착각들이 깨진다.

🐥 대외활동

여름엔 무지하게 더우니까, 사진 찍는 건 엄두가 안 나고 에어컨 바람 맞으면서 코딩을 열심히 하려고 생각했다. 좋은 동료들과 함께 프로덕트를 만들어 보고 싶은 마음에 IT 동아리를 지원했는데 아쉽게도 함께 하지 못했다. 면접을 못 본 게 아니어서 더욱 아쉬웠는데 어쩌겠나. 다음 기수에 다시 지원해야겠다는 생각이 들었다. 그 엄청난 경쟁률을 뚫으려면 더 열심히 해야겠다는 생각이 들었다. 그리고 오랜만에 면접을 본 경험도 좋았다. 내가 알고 있는 걸 잘 말할 수 있도록 더 연습해야겠다.

📖 모임

필독! 개발자 온보딩 가이드라는 책을 읽고 있었는데 마침 이 책을 가지고 열린 독서 모임이 있어서 참여해 봤다. 친구들이랑 개발 서적 스터디를 했을 때 서로의 생각과 경험을 공유했던 점이 좋았었기 때문이다. 다양한 직군과 연차의 개발자분들과 책에서 좋았던 점, 얘기해 보고 싶었던 점 등에 관해서 얘기를 나눌 수 있어서 좋았다. 그룹을 지어서 20분 정도 얘기하고 그룹을 섞는 식으로 진행했는데 얘기하다 보니까 시간이 너무 금방 가서 다음에는 좀 더 길게 했으면 하는 바람이 있었다.

취미생활을 하는 나

📚 독서

미치지 않고서야라는 책을 읽고 디스콰이엇이라는 메이커 커뮤니티에 기록을 남겼다. 기록을 어딘가에 남기고 싶었는데 마침 북클럽이 있어서 하나씩 작성해 보고 있다.

이번 달에 다 읽은 책은 미치지 않고서야, 딸아, 돈 공부 절대 미루지 마라, 나는 4시간만 일한다가 있다.

디스콰이엇은 메이커분들이 양질의 글을 올려주셔서 읽고 배우는 재미가 있다.

📸 사진

엑셀콘이라는 개발자 컨퍼런스에서 행사 사진을 찍었다. 인물 스냅만 주로 찍고 있어서 행사 사진을 찍을 기회가 없었는데 좋은 경험이었다.

주로 낮에 야외에서 찍는 것과는 다르게 장소가 넓지 않고, 조명에 의존해야 했기 때문에 사진 찍기에 어려운 조건이었다. 또한, 여러 인물에 초점을 맞춰야 했기에 어느정도의 노이즈를 감수하고 조리개를 조여야 했다. 그 순간순간 최선의 판단을 하느라 정신이 없었다.

스태프로 이렇게 참가해 보니 정말 컨퍼런스를 준비하는데 많은 사람의 시간과 노력이 들어간다는 걸 깨달을 수 있었고, 정성껏 준비한 행사를 잘 즐겨주신 참가자분들이 고마웠다. 개개인의 순간을 담는 인물 스냅도 좋지만, 행사의 분위기를 담을 수 있는 행사 사진을 찍으면서 재밌어서 지치지 않았고 즐거웠다.

여담인데 데이먼스이어 사인회와 엑셀콘 시간이 겹쳐서 가지 못한 사연이 있다. 데이먼스이어를 가까이서 볼 수 있는 다시 올지 모르는 소중한 기회였는데 아쉬웠다. 언젠가 기회가 또 생기겠지. 가끔은 원하는 걸 포기해야 하는 상황도 있겠구나 싶었다. 이 글도 데이먼스이어 노래를 들으면서 작성하고 있다.

🎵 음악

너드커넥션 공연을 두 번이나 봤다. 운이 좋았다. 돈이 많아서 그런건 아니고 운이 좋게 지역문화센터에서 저렴하게 열린 공연 예매에 성공했다. ✌🏻 최유리님 공연도 들을 수 있었는데 정말 너무 좋았다… 최고야…

사이드 프로젝트로 업무 불편함 해결하기

Mon, 03 Jul 2023 22:08:07 GMT

배경

사무실에는 회의실로 사용하는 임의의 두 공간이 있다. 예약하려면 공용 캘린더에 등록을 하는데, 임의의 공간이기 때문에 예약 시스템이 있는 것이 아니라 “저 여기 사용해요”라고 글을 적어놓는 것이랑 같다.

문제

별 불편함없이 쓰고 있었지만 거슬리는 문제가 터진다. 바로 중복 예약이다. 이미 예약된 시간에 예약글을 적어도 글이 써지기 때문에 생기는 문제이다. 회의실에 갔는데 이미 사용하는 팀원이 있고, 예약내역을 다시 살펴보지만 중복예약이 되어 있다는 것을 발견하는 경험을 하면 굉장히 당황스럽다.

해결

그래서 사이드 프로젝트로 이 문제를 풀어보려고 했다.

예약시스템? 만들면 되지. 하고 살짝 가볍게 생각하긴 했다. 😅

일단 예약하는 기능만 있더라도 중복 예약 문제를 해결할 수 있을 거라고 생각했다.

또한 회의실은 팀원들이 많이 사용하므로 개발하면

팀원들의 불편함을 많이 덜어줄 것이고
트래픽이 꾸준하게 있어, 주기적으로 피드백도 받을 수 있었다.

팀원들에게도, 나에게도 좋은 프로젝트라고 생각해서 퇴근 후 짬을 내서 개발했다.

개발 과정을 온전히 기록하진 못했으나(아직 기록하는 게 서툴다) 우여곡절 끝에 예약 기능이 담긴 MVP 제품이 나왔다. 기획하면서 생각해낸 여러 편의기능들은 다 빼고 제일 중요한 예약 기능, 예약 현황 확인 기능만 먼저 개발했다. 수정? 삭제? 안 넣었다.

그것보다 예약 기능에 집중하고 싶었다

예약 시스템을 처음 만들다보니 이것저것 생각해볼 게 많았고(예를 들어, 근무 시간 외의 시간 제외하기, 예약 모달을 열었을 때 예약 시간 기본값 등) 아직까지 엣지 케이스들이 다 잡히지 않은 거 같았다. 그래서 먼저 팀원들에게 열어놓고, 피드백을 받으면서 살을 붙이고 싶었다. 기존 시스템과 병행하면서 쓰다가 문제가 없다 싶은 타이밍에 기존 시스템을 대체하고 싶었다.

그리고 짜잔! 오늘 공지글을 올리면서 세상에 내놓았다

공지글을 요약해보자면 다음과 같다.

현재의 시스템 -> 중복 예약 문제가 있습니다. 그래서 문제를 해결하고자 만들었습니다. 작은 단위로 개발했기 때문에 이런 기능들만 있습니다. 지금 시스템과 병행해서 써보시면서 버그나 개선점을 마구마구 남겨주시면 감사하겠습니다!

예약하기 기능
예약현황 보기(피드백을 대놓고 받기 위해 Alert로 넣은게 회심의 포인트다)
예약 상세 내역 확인

피드백 남기기 버튼을 클릭하면 구글폼으로 이동한다. 팍팍한 일상 속에서 한번 웃으시라고 귀여운 고양이 사진도 넣었다 😻

솔직히 이렇게까지 반응이 뜨거울 줄 몰랐는데 많이 뜨거웠다. 🔥🔥

만들어 둔 구글폼으로, 댓글로 많은 의견을 남겨주셨다. 그 중에는 내가 생각해놓았던 기능들도 있었는데 의견들을 보면서 우선순위를 매기는데 참고하려고 한다.

Do not use "new" for side effects eslint rule

Wed, 14 Jun 2023 23:07:29 GMT

주어진 url이 유효한지 검사하는 기능이 필요해서 관련 함수를 작성했다. 아래와 같이 isValidUrl 함수를 작성했는데 ESLint: Do not use 'new' for side effects.(no-new)라는 eslint rule를 위반했다고 경고가 떴다.

export const isValidUrl = url => {
  try {
    new URL(url)
    return true
  } catch (error) {
    console.error('isValidUrl error : ', error)
    return false
  }
}

eslint 문서를 참고하면, 보통의 경우 new를 통해 인스턴스를 생성하고 변수에 할당해 사용하는데, 저장하지 않으면 reference가 어디에도 남지 않기 때문에 이를 방지하기 위함이라고 한다. 그렇다고 인스턴스를 변수에 할당하면 그 변수는 사용하지 않아 no-unused-vars rule을 위반하기 때문에 즉시실행함수로 감싸주었다.

export const isValidUrl = url => {
  try {
    (() => {
      return new URL(url)
    })()
    return true
  } catch (error) {
    console.error('isValidUrl error : ', error)
    return false
  }
}

테스트 코드는 아래와 같이 작성했다. chatGPT를 통해서 테스트 케이스를 얻는데 도움을 받았다. 케이스가 많은 거 같긴 하지만 어떤 인풋값들이 들어올 수 있을지 예상할 수 있어서 도움이 많이 됐다.

describe('isValidUrl function', () => {
  it('유효한 URL에 대해서 true를 반환한다.', () => {
    expect(isValidUrl('https://www.example.com')).toBe(true)
  })

  it('유효하지 않은 URL에 대해서 false를 반환한다.', () => {
    expect(isValidUrl('not a valid url')).toBe(false)
  })

  it('프로토콜이 없는 URL에 대해서 false를 반환한다.', () => {
    expect(isValidUrl('www.example.com')).toBe(false)
  })

  it('query parameter가 있는 유효한 URL에 대해서 true를 반환한다.', () => {
    expect(isValidUrl('https://www.example.com/?id=123')).toBe(true)
  })

  it('hash fragment가 있는 유효한 URL에 대해서 true를 반환한다.', () => {
    expect(isValidUrl('https://www.example.com/#about')).toBe(true)
  })

  it('빈 문자열에 대해서 false를 반환한다.', () => {
    expect(isValidUrl('')).toBe(false)
  })

  it('null에 대해서 false를 반환한다.', () => {
    expect(isValidUrl(null)).toBe(false)
  })

  it('undefined에 대해서 false를 반환한다.', () => {
    expect(isValidUrl(undefined)).toBe(false)
  })

  it('문자열이 아닌 값에 대해서 false를 반환한다.', () => {
    expect(isValidUrl(1)).toBe(false)
  })
})

db trigger를 활용해 supabase signUp 후에 users table에 데이터 추가하기

Fri, 09 Jun 2023 16:06:59 GMT

배경

supabase를 활용해 사이드 프로젝트를 하다가 겪었던 문제를 해결한 경험이다. supabase auth를 활용해 google signUp을 했는데, data는 auth schema의 users table에 저장되는데, 보안상의 목적으로 외부에서 접근할 수 없도록 설정되어 있다.

내용

그래서 user data로 다른 table의 data와 상호작용하기 위해 public schema에 table을 만들어야 했다.

이와 관련한 supabase docs가 아래 있었고 나는 이렇게 학부생 때 배웠던 db trigger를 사이드 프로젝트 하면서 처음 쓰게 되었다.

supabase-auth/managing-user-data

-- inserts a row into public.profiles
create function public.handle_new_user()
returns trigger
language plpgsql
security definer set search_path = public
as $$
begin
  insert into public.profiles (id)
  values (new.id);
  return new;
end;
$$;

-- trigger the function every time a user is created
create trigger on_auth_user_created
  after insert on auth.users
  for each row execute procedure public.handle_new_user();

$$;

예제를 보면, auth.users table에 insert가 일어나면 handle_new_user function이 실행되고, public.profiles table에 id를 넣는다.

나는 사용자가 회원가입을 하면 public.users table에 id, email, name(email에서 @앞)을 넣고 싶었다.

email에서 name을 추출하기 위해서 postgre split_part function을 활용할 수 있었다.

create or replace function public.handle_new_user()
    returns trigger
    language plpgsql
security definer set search_path = public
as $$
begin
    insert into public.users (id, name, email)
    values (new.id, split_part(new.email, '@', 1), new.email);
return new;
end;
$$;

피드백

생활코딩에 글을 공유하니까 지나가던 개발자님께서 왜 트리거를 썼는지 물어봐주셨다. 글을 본 내 친구와 지인분도 현업에서 트리거는 거의 쓰지 않는다고 알려줬다. 가장 큰 이유는 유지보수가 힘들다는 것이다. 데이터베이스에 달려 있다 보니 파악하기가 어렵고, 예상치 못한 오류가 발생할 수도 있다. 그래서 로직은 모두 코드단에서 구현하고 관리한다고 한다. 그리고 또 다른 이유는 성능인데, 아무래도 디비 CPU를 사용하다 보니까 성능이 저하될 수 있다.

아무래도 프론트엔드 개발자이다보니까, trigger는 현업에서도 쓸 일이 없어서 이런 실무지식은 아예 모르고 있었는데 이번 일을 계기로 알 수 있어서 좋았다. 지식이 늘었다.

supabase로 구글로그인(소셜로그인) 구현하기

Tue, 06 Jun 2023 17:06:25 GMT

supabase로 구글로그인을 구현하기 위해서는 어떤 세팅을 해야 하고 코드로는 어떻게 구현하는지 적어보았다.

supabase, google cloud console 세팅하기

먼저 supabase의 Authentication - Providers에서 Google을 enable 시키면 Client ID와 Client Secret을 입력하는 창이 나온다.

Google cloud console에서 새 프로젝트를 만든다.

그리고 OAuth 동의 화면에서 User Type 외부를 선택하고 생성한다. 검색창에 OAuth라고 치면 쉽게 찾을 수 있다.

그리고 나서 사용자 인증 정보에서 OAuth 클라이언트 ID를 만든다. 검색창에 credential이라고 치면 쉽게 찾을 수 있다.

유형은 각자의 환경에 맞게 골라주면 된다.

그리고 아까 열어둔 supabase 화면에서 Redirect URL을 복사해서 승인 목록에 추가해준다.

그리고 만들기를 하면 아래 처럼 클라이언트 ID와 비밀번호를 확인할 수 있다.

이걸 supabase 화면에 붙여넣고 저장하면 준비는 끝이다.

클라이언트단

sdk를 설치하고

yarn add @supabase/supabase-js

아래처럼 supabase client를 만든다. 나는 next.js에서 만들었다.

// supabase.ts
import { createClient } from '@supabase/supabase-js'

const supabaseUrl = process.env.NEXT_PUBLIC_SUPABASE_URL || ''
const supabaseAnonKey = process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY || ''

if (!supabaseUrl) throw new Error('Supabase URL not found.')
if (!supabaseAnonKey) throw new Error('Supabase Anon key not found.')

export const supabase = createClient(supabaseUrl, supabaseAnonKey)

함수는 아래와 같이 작성하고, redirectTo options을 통해서 원하는 곳으로 redirect시킬 수 있다.

const handleSignInWithGoogle = async () => {
    try {
        const { error } = await supabase.auth.signInWithOAuth({
            provider: 'google',
            options: {
                redirectTo: 'http://localhost:3000/auth/callback',
            },
        }
        if (error) throw error;
    } catch(error) {
        console.error(error);
    }
}

큰 틀은 이렇고, 아래 onAuthStateChange method로 세션을 가져올 수 있다.

supabase.auth.onAuthStateChange((event, session) => {
  if (event == 'SIGNED_OUT') {
    store.state.user = null
  } else {
    store.state.user = session.user
  }
})

보통 SPA의 경우 App.js 같은데서 store에 값을 넣어주는 거 같고

next.js의 경우 아래 문서를 참고해서 추가적인 로직을 구현하면 된다.

next.js pages directory를 사용하는 경우

next.js app router를 사용하는 경우

alwayz를 만드는 레브잇팀은 어떻게 성장했는가

Wed, 17 May 2023 23:05:49 GMT

배운 점 요약

가장 인상 깊었던 것은 모두가 problem solver로 문제를 해결하는데 필요한 모든 것을 배우면서 실행한다는 것이었다. 이 부분은 회사에서 실험 DRI를 맡게 된 큰 동기가 되었다. 실험 DRI를 맡으면서 실험 횟수가 늘어나고 있어 뿌듯하고 더 빨리, 더 많이 실험하고 싶다.

그리고 높은 목표를 세우고 많은 부분을 이뤄낸 것도 인상적이었다. 높은 목표를 세우면 확실히 그 목표에 가까워지도록 사고방식이 좀 트이는 거 같다. 하지만 아직까지는 폭발적이고 과감한 성장을 이뤄내보지 못했다. 올해 큰 거 하나 터트려보고 싶다.

본질 지표도 중요하다는 것에 공감한다. 실험만 하다보면 퍼널별 전환율에 집중하게 되고, 숲을 보는 것을 놓치고 있을 수 있다. 오늘 실제로 실험설계를 하면서 PM님과 리텐션 지표에 대해 잠깐 얘기 나눴는데 리텐션을 어떻게 잘 측정할지도 고민 포인트인 거 같다.

영상

1. 어떻게 성장했는가?

모두가 매일 사용하는 소프트웨어를 만드는 것이 꿈. 나이브하게 접근하면 꿈을 이루지 못할 것이라 생각.
갈망론 → 모든 것은 사람들의 갈망에서 출발
1. 구매
2. 소셜(소통, 관계)
3. 엔터
중국의 핀둬둬를 벤치마킹. 3가지 갈망을 다 담고 싶었음.
1. 좋은 제품을 싸게 살 수 있음
2. 팀구매를 통한 소통, 관계
3. 나중에 개발할 엔터쪽 요소

MVP

2달정도 걸림

만들어낼 수 있는 부분에 집중

- 만들어낼 수 있는 부분 → `바이럴`, `성장`
- 만들어낼 수 없는 부분 → 가격에 `WOW`를 느끼고 계속 구매할지?

MVP에 8천개의 상품을 올림(어떻게?)

- 셀러를 모집하는건 불가능.
- `오픈마켓에 있는 상품들을 대신 올리고, 주문이 들어오면 주문대행을 하는 식.`
- 20% 낮은 가격으로 세팅하고 손해본건 시드투자금으로 메움.
- week1 재구매율이 `30%` 정도면 확신을 얻을 것이라 생각. 실데이터 `48~50%` 나옴.

빠른 실행과 피드백 루프(A/B Test)
- 가설을 세우고 A/B test를 많이 함
- 낮은 가격에 대한 갈망을 기반으로 한 ‘팀 구매’ 바이럴
  - 바이럴 종류
    - 카카오톡 바이럴
      ![image](https://github.com/vuejs/core/assets/32301380/fa47dc1a-63db-4319-8899-3b67065d2c76)
    - 네이버 카페 바이럴
      ![image](https://github.com/vuejs/core/assets/32301380/45ed5238-e975-4855-82b0-c5884472bcf4)
      - 카카오 오픈 채팅방 바이럴
  - 100원짜리 양파
    - 가격이 낮은건 좋지만 친구 초대는 부담스러울 수 있음(민폐처럼 느낄 수 있다고 생각)
    - 허들을 낮추는 방향으로 가봤지만 작동하지 않음
    - 가격이 더 낮으면(갈망이 극대화되면) 허들을 뛰어넘지 않을까?
    - CAC(Customer acquisition cost) 15000~20000원대(큰 회사는 50000원대)인데 월 3배 성장하면서 CAC 3000원으로 가고 싶음
      - 2900원짜리 양파를 100원에 팔아보자.
      - 100원 짜리 양파(CAC를 담보하는 핵심상품)으로 유입 → 다른 상품도 사지 않을까?
        
        셀러분이 감당할 수 없다고 품절처리 하셔서 3억원을 들여 양파 80톤을 매입.
        
        초기 1만명까지의 그로스를 담당.
  - 10000원짜리 → 100원
    - 99인 100원 팀구매
    - 실패시 → 비용이 들지 않으므로 CAC 조절 가능
    - 추첨도 마찬가지. 상품 수량을 조절해 CAC 조절 가능
    - 100팀(1만명)이 성사시킴. → 1억원 지출
실패담
- 리텐션을 유지하기 위해 본질을 잊고 트라이함
- 점점 객단가가 더 비싼(테팔 → 아이패드 → 샤넬백 → 벤츠) 것으로 추첨을 돌림
- DAU는 10만으로 정체

전사 지표 재설정

6월 이전 → 거래액
거래액이 갖는 허점 → 리텐션이 없으면 유지가 힘듦

RGMV → 건전하고 유지 가능한 GMV

![image](https://github.com/vuejs/core/assets/32301380/aca1598e-65b4-446b-b8b0-dc43aed65e14)

![image](https://github.com/vuejs/core/assets/32301380/d5a3049f-0bd8-416f-840a-2e1d44f3074c)

![image](https://github.com/vuejs/core/assets/32301380/1ec70b6b-9315-4489-a84d-f2e468c1b952)

2. Key lessons

MVP는 만들어낼 수 없는 것 중심
빠른 실험, 피드백
장기적이고 본질적인 가치 추구
본질 중심의 전사지표 설정 및 Align
레브잇의 조직문화(TBC)
- 중요한 것은 도구가 아닌 문제 해결.
7 Standards
1. Madly Motivated
2. Fastest
3. Focused
4. Humble
5. Resilient
6. Smart
7. Impact Oriented

프론트엔드 테스트에서의 정규식의 활용

Wed, 17 May 2023 22:06:23 GMT

이슈

component test를 하다보면 렌더링된 결과물을 비교하는데, 텍스트가 길어져서 line break가 발생하거나, 의도치 않은 공백이 생기는 등의 상황에서 텍스트 단언문에서 애를 먹는다. 이럴 때 정규식을 사용해 공백을 제거하면 수월하게 테스트할 수 있다!

const str = '   This  is     a    test.   '
const result = str.replace(/\\s\\s+/g, ' ')
console.log(result) // Output: "This is a test."

// mount한 결과물의 text가 아래와 같이 나올 때
// '   This  is     a    test.   ';
const wrapper = mount(component, ...);
expect(wrapper.element.textContent.replace(/\\s\\s+/g, ' ')).toContain('This is a test.');

정규식 해석

.replace(/\\s\\s+/g, ' ')

스페이스, 탭, 라인브레이크 등을 하나의 스페이스로 치환해준다.
/\\s\\s+/ 는 여러개의 white space character를 뜻한다
맨 뒤의 ‘g’는 글로벌 적용을 의미한다.(한번 패턴을 마주하면 적용하고 끝이 아니라 문자열 끝까지 검사함)

vscode error lens extension(야무진 익스텐션 추천)

Sat, 06 May 2023 22:06:22 GMT

세미나에 참여하다가 정말 편해보이는 vscode 익스텐션을 발견했다.

Error Lens라는 익스텐션인데, 마우스 호버하지 않아도 에러 메시지를 읽을 수 있어 정말 편리하다.

nuxt3 server api 만들기 & env 접근

Sat, 06 May 2023 19:06:33 GMT

nuxt3 서버에서 api를 만들려면 server/api 디렉토리 안에 파일을 만들면 된다. nuxt는 ~/server/api directory를 자동으로 스캔해 api를 등록한다.

예를 들어, server/api/ai.ts -> /api/ai endpoint가 생긴다.

앱 내에서 $fetch("/api/ai")를 통해 API를 호출할 수 있다.

// ~/server/api/ai.ts
export default defineEventHandler(() => {
  return { message: 'success' }
})

예제로 잘 작동하는 것을 확인한 후에 구현하고자 하는 로직을 추가했다. 간단하게 message를 받아 openai api에 보낸 응답값을 return하는 api이다.

// ~/server/api/ai.ts
import { Configuration, OpenAIApi } from 'openai'

export default defineEventHandler(async event => {
  const body: { message: string } = await readBody(event)
  const { OPENAI_API_KEY } = useRuntimeConfig()
  const configuration = new Configuration({
    apiKey: OPENAI_API_KEY,
  })
  const openai = new OpenAIApi(configuration)
  const completion = await openai.createCompletion({
    model: 'text-davinci-003',
    prompt: body.message,
  })
  return completion.data.choices[0].text
})

파일은 보는바와 같이 defineEventHandler로 감싸서 export하면 된다.

여기서 문서를 참고해야 했던 부분은

env값에 접근하는 방식
request body를 읽는 방식 이었다.

먼저 env는 process.env를 통해 접근할 수 없고, nuxt runtime config를 이용해야 했다. nuxt.config.ts에서 runtimeConfig에 등록하면 앱에서 useRuntimeConfig를 통해 접근할 수 있다.

사용하기에 번거로워진 거 같은데, 공식문서에서 이는 .env 내용이 변경되었을 때 변화를 감지해 HMR을 지원하기 위함이라고 한다.

// nuxt.config.ts
// https://nuxt.com/docs/api/configuration/nuxt-config
export default defineNuxtConfig({
  runtimeConfig: {
    OPENAI_API_KEY: process.env.OPENAI_API_KEY,
  },
})

전달받는 event가 H3Event 타입이어서 생소했는데, body를 읽는 방식은 공식 문서에 나와 있듯이 readBody api를 활용하면 됐다.

추가적으로, 파일명으로 allow method를 지정할 수 있다. ai.ts -> ai.post.ts로 변경하면 post method만 허용한다.

vue composition api

Sat, 06 May 2023 10:06:14 GMT

options api

정의

data, method 등을 options object에 담아서 정의하는 방식.

문제

관련 로직이 분산되어 있음
믹스인으로 로직을 재사용하는데에 한계가 있음
- 컴포넌트 데이터의 출처가 모호해짐
개발할 때, IDE에서도 로직을 파악하기 어려움
이름이 중복될 수 있음
타입스크립트 지원이 제한적

이미지 출처: https://vueschool.io/articles/vuejs-tutorials/options-api-vs-composition-api/

composition api

특징

반응형 api
라이프사이클 훅을 지원
의존성 주입
관심사를 한데 모을 수 있어 읽고 이해하기 쉬움
문맥에 따라 사용하는 부분들의 이름을 다시 지을 수 있음
로직을 재사용하기 쉬움
타입스크립트 지원이 잘됨
- ref의 초기값으로 타입 추론 가능
- computed가 반환하는 값으로 타입 추론 가능
- interface로 reactive data의 타입을 정의할 수 있음
(vue2.7 버전부터 빌트인 되어 있다.)

setup

setup 은 Vue가 컴포넌트 생성전에 props가 전달되면 자동으로 실행됨.
인자로 props, context를 받는다.
setup이 불릴 때 컴포넌트가 생성되지 않았으므로 this로 접근 불가

<script>
export default {
  props: {
    name: String,
    price: Number,
  },
  setup(props) {
    console.info('name', props.name)
    console.info('price', props.price)
  }
}
</script>

context

attrs
slots
emit

reactive data가 아니므로 context는 destructure 가능. props는 불가능.

<script>
export default {
  props: {
    name: String,
    price: Number,
  },
  setup(props, { attrs, slots, emit}) {
    console.info('name', props.name)
    console.info('price', props.price)
  }
}
</script>

ref로 값을 전달하면 Vue는 value property를 가지는 object로 감싼다.

그래서 접근하거나 변형할 때 .value를 통한다. wrapper로 감싸면 반응성을 잃지 않고 안전하게 사용할 수 있다. script 외부에서는 unwrap한다.

아래 예제에서, name을 let으로 선언하고, .value를 통해 값을 바꿔도 반응성은 유지된다.

setup() {
  let name = ref("The Snazzy Burger");
  name.value = "Nice Burger"
  function placeOrder() {
    alert("Your order has been placed!");
  }
  const addItemToCart = (item) => {
    alert(`You added ${item} to your cart!`);
  };
  return { name, placeOrder, addItemToCart } ;
},

하지만 .value를 빼먹으면 값이 교체되서 반응성을 잃는다.

<template>
  <h1>{{name}}</h1>
  <input type="text" v-model="name">
</template>

<script>
import { ref } from "vue";

export default {
  setup() {
    let name = ref("The Snazzy Burger");
    name = "Nice Burger"
    return { name } ;
  },
}
</script>

ref

장점

primitive, non-primitive 둘 다 쓸 수 있음
destructuring하기 좋음

import { ref } from 'vue'
export default () => {
  return {
    name: ref('Pizza'),
    price: ref(1000),
  }
}

단점

.value를 쓰는 게 성가실 수 있다.
context에 따라 쓰는 방법이 달라서 헷갈린다.
- template에선 name
- setup에선 name.value
- options api에선 this.name

reactive

장점

.value를 안 써도 됨
context가 달라도 문법이 똑같음
toRefs를 사용하면 destructuring이 가능하긴 함
- toRefs => reactive object property를 돌면서 하나씩 ref로 변경해줌

import { reactive, toRefs } from 'vue'
export default () => {
  return toRefs(
    reactive({
      name: ref('Pizza'),
      price: ref(1000),
      time: ref(2000),
    })
  )
}

단점

primitive에 사용하지 못함
reassign을 하면 반응성을 잃음
전체 object를 교체하지 못함.

let posts = reactive(['post 1', 'post 2'])
posts = ['post 3', 'post 4']

computed

getter, setter 선언이 가능
.value를 사용해야 함

const pricePretty = computed(() => `$${props.price.toFixed(2)}`)
const pricePrettySentence = computed(() => `Price: ${pricePretty.value}`)

watch

options api처럼, immediate, deep option이 가능

watch(
  name,
  (newName, oldName) => {
    console.log(`Name changed from ${oldName} to ${newName}`)
  },
  {
    immediate: true,
    deep: true,
  }
)

의견

이상 vue school 강의를 듣고 요약한 내용이다. 아무래도 vue core member들이 강의한 내용이다 보니 이해도 잘 되고, 일반 블로그 글들에선 볼 수 없었던 관점 등을 배울 수 있었다.

경험이 쌓여서 ref와 reactive 중 어느 것을 선호할 수 있는 정도가 되고 싶다. options api의 코드 재사용성은 정말 안 좋았는데, composition api로 많이 개선됐으면 한다. 이것도 많이 써보면서 사례들을 경험해나가고 싶다.

supabase edge function 빠르게 시작하기

Sat, 06 May 2023 09:05:56 GMT

notion database에서 값을 가져오고 싶었는데 생각해보니, client단에서 notion api call을 하면 CORS 에러가 났다. 그래서 Proxy server가 필요했고, lambda로 만들까 하다가 생각해보니 supabase에 edge function이라는 기능이 있었다. 그래서 이것을 사용해 봤다!

처음에 무척 애를 먹었다. supabase cli 설치가 마음대로 안됐다. 결국 유튜브 동영상을 보고 명령어를 찾았다.

brew install supabase/tap/supabase

설치를 하고 함수 생성한 뒤 바로 배포했다.

supabase functions new notion-api-proxy
supabase functions deploy notion-api-proxy --project-ref ${PROJECT_REF}

Edge functions 대시보드에 들어가면 배포한 함수가 짜잔!

새로 생성한 함수는 functions directory 안에 들어 있다.

서버는 deno로 되어 있다. 와우. 한번도 안 써봤는데 잘 됐다.

로컬로 돌려보기 위한 과정을 쭉 적어보면, docker가 필요했다.

 supabase functions serve notion-api-proxy
Error: cannot read config in /Users/songdonghoon/study: open supabase/config.toml: no such file or directory
Have you set up the project with supabase init?

 supabase init
Finished supabase init.

 supabase functions serve notion-api-proxy
Error: supabase start is not running.
Try rerunning the command with --debug to troubleshoot the error.

 supabase start
Error: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
  in github.com/supabase/cli/internal/utils.AssertDockerIsRunning:48
  in github.com/supabase/cli/internal/start.Run:36
Try rerunning the command with --debug to troubleshoot the error.
Status: Downloaded newer image for public.ecr.aws/supabase/deno-relay:v1.6.0
Seeding data supabase/seed.sql...
Started supabase local development setup.

         API URL: http://localhost:54321
         ...

 supabase functions serve notion-api-proxy
Starting supabase/functions/notion-api-proxy
Serving supabase/functions/notion-api-proxy
Watcher Process started.
Check file:///home/deno/functions/notion-api-proxy/index.ts
Hello from Functions!
Listening on http://localhost:8000/

그리고 코드 아래에 있는 invoke 명령어를 사용하면 테스트 해볼 수 있었다.

curl --request POST 'https://<project_ref>.functions.supabase.co/hello-world' \ --header 'Authorization: Bearer ANON_KEY' \ --header 'Content-Type: application/json' \ --data '{ "name":"Functions" }'

참고

https://supabase.com/docs/guides/functions/quickstart

셀프 브랜딩에서 가장 중요한 것

Sat, 06 May 2023 00:06:27 GMT

개발이나, 사진이나 셀프 브랜딩에 관심이 많다. 그러다가 유튜브에서 아래 영상을 마주했는데 정말 주옥같은 내용들이 많고 내 자신을 돌아볼 수 있는 기회를 얻어서 공유해본다.

가장 와닿아서 메모했던 내용은 다음과 같다.

내 브랜드는 고객의 삶에서 어떤 부분을 해결해주는가?
그게 해결되면 어떤 모습이 되는가?
내가 하는 일을 단 한 문장으로 말 할 수 있는가?
이 문장이 고객의 변화를 약속하고 있는가?

이걸 내 경험에 비추어서 답해보면 다음과 같다. 여기서 내 고객은 지금 다니고 있는 회사가 될 것이다.

회사가 해결하려는 문제를 해결한다.
회사는 성장할 수 있고, 유저들에게 가치를 전달할 수 있다.
문제 해결.
회사는 더 나아진 기능, 새로운 기능 등을 가질 수 있고 유저들에게 더 좋은 UX, UI, 서비스를 제공할 수 있다.

Amplify pwa Manifest: Line: 1, column: 1, Syntax error 해결법

Sat, 06 May 2023 00:05:20 GMT

이슈

aws amplify에 pwa앱을 배포했는데 manifest파일을 읽지 못하는 이슈가 있었다.

error message를 클릭하면 index.html이 보인다. 오잉?

원인

다시 쓰기 및 리디렉션을 처음 설정한 것 때문에 요청이 index.html로 가고 있었다.

해결

/manifest.webmanifest는 그대로 다시 쓰게하고 우선순위를 높여서 해결했다.

AWS WAF 정리

Sat, 06 May 2023 00:05:18 GMT

WAF(Web Application Firewall)

http(s) 요청을 모니터링하고 관리하는 방화벽 규칙을 정하고 어떤 액션을 취할지 정의할 수 있음

액션 종류

허용(Allow)
차단(Block)
카운팅(Count)
CAPTCHAR를 실행시키거나 사람인지, 브라우저인지 체크

WAF Rules

요청을 검사할 때 사용할 기준을 정하고 action을 적용할지 정함
ex) Bot이면 요청을 차단 IP 주소 기준, 지역 기준 등

Actions

Allow and Block actions
- terminating action
- terminate되면 그 후 다른 rule을 거치지 않는다.
Count action
- non-terminating action
- WAS는 request를 count하고 다음 룰로 넘어간다.
CAPTCHA and Challenge
- terminating or non-terminating action
- …

Rule action overriding

Allow
- 보호받는 자원으로 forward하기 전에 request에 custom header를 넣을 수 있다.
Block
- status code 403
- rule을 통해 response도 커스터마이즈할 수 있다.
- block 당하면 block action setting이 설정한 response를 client에게 전송한다.
Count
- 남은 rule을 거친다.
- custom header를 request에 넣거나 label을 붙인다.
CAPTCHA and Challenge
- CAPTCHA plzzle을 쓰거나
- silent challenge를 사용해 request가 bot인지 아닌지 체크한다.

Overriding the rule action to Count

룰의 action을 Count로 overriding할 수 있다. 프로덕션에 룰을 적용하기전에 로그를 보면서 테스트, 모니터링하는데 주로 쓰임.

Temporary inconsistencies during updates

web ACL 생성 혹은 편집 시에 전 영역으로 퍼지는데 시간이 조금 걸리기 때문에 싱크 이슈가 있을 수 있다.

How browser automation works behind the scenes - JSWORLD 2023

Wed, 22 Mar 2023 16:03:22 GMT

https://www.youtube.com/watch?v=6vwWBKfwTWk

을 시청하고 정리한 글입니다.

Debugging & Testing

DevTools
Browser Automation
ChromeDriver
WebDriver BiDi

WebDriver “Classic” Protocol - Conventional

전통적인 프로토콜
모든 브라우저에서 동작
pull-based - 클라이언트는 서버에 HTTP 통신을 해서 응답을 받아야 함 - 서버가 클라이언트에 직접적으로 메시지를 보내지 못함
command 마다 HTTP handshake가 필요

ChromeDevTools Protocol(CDP) - Non-standard

크로미움 기반 브라우저에서만 동작
Puppeteer, Playwright, Selenium, Nightwatch, WebdriverIO, Cypress, Testcafe
Browser drivers를 사용하지 않음
웹소켓 기반으로 빠른 커뮤니케이션 가능
chatty - 프로토콜단에서 많은 command를 생성 - 원래 디버깅을 목적으로 디자인되었음
low-level control 지원 - device mode 시뮬레이션 - geolocation 시뮬레이션 - 네트워크 요청 intercept - console log message

// 아래 명령어를 사용해 프로토콜단에서 벌어지는 일들의 로그를 볼 수 있음
DEBUG=puppeteer:protocol:SEND*

Web APIs + JavaScript - Non-standard

크로미움 기반 브라우저에서 동작
개발자 -> 자동화 툴 -> 테스트 스크립트
자동화 툴 -> 프로토콜로 브라우저에서 스크립트 실행

Cypress

브라우저에서 실행
Nodejs 서버 프로세스로 실행

TestCafe

Node server side test code -> client-side javascript
브라우저에 삽입

크로스 브라우저 자동화를 어떻게 더 잘할 수 있을까?

WebDriver BiDi

WebDriver BiDi protocol을 통해 명령을 수행
웹소켓 사용
크로스브라우저 지원
빠르고, 양방향 메시징 가능
low level control도 지원
Ergonomic API build for testing - Ergonomic : 인체공학적이라는 뜻인데, 의역하기 어려움.

New protocol을 도입하기 위해 체크해야 되는 부분

Specification(RFC)
Verification
Implementation

발표자님의 말씀

DX 발전과 ecosystem에 기여 중
테스팅 툴들이 사람들에게 도움이 되길 바라며
WebDriver BiDi를 사용하는 프레임워크가 출시되면 빨리 써보고 예제를 많이 올려주시길!

느낀점

구글 크롬 new features 탭에 나오시는데 너무 반가웠다. 이런 툴들은 어떻게 돌아가나 신기했는데 원리를 알고 나니 더 재밌어졌다. cypress를 사용해봤는데 너무 무거워서 로컬로 돌리면 pc가 감당하지 못했다. WebDriver BiDi가 나오면 써보고 싶다. 가볍고 빠르길 바라며.

https://github.com/GoogleChromeLabs/chromium-bidi/milestones

vue3 typescript props interface issue

Thu, 16 Mar 2023 23:03:49 GMT

문제 상황

vue3 + typescript로 개발을 하던 중, props에 type을 추가하고 싶었는데 예상치 못한 이슈를 마주했다. interface로 선언했는데 처음 보는 에러가 떴다.

원인

https://github.com/vuejs/language-tools/discussions/2421

위의 글을 참고하면 모든 프로젝트에서 발생하는 것은 아닌데 tsconfig에서 아래 옵션이 켜져 있으면 발생한다고 한다.

// tsconfig
"compilerOptions": {
    "composite": true
}

"declaration": true도 같은 에러를 발생시킨다.

본문에 따르면 props는 component에서 export된 type중 하나이고, interface가 defineProps에 전달되면 setup 함수 내부에 들어가기 때문에 이 에러를 피하려면 hoisting이 필요하다.

+ interface Props {
+   msg: string
+ }

export default defineComponent({
  setup() {
-   interface Props {
-     msg: string
-   }

    defineProps<Props>()
  }
})

해결책

현재로서는, Volar에서 hoisting을 하려면 export를 사용할 수 밖에 없는데, 이걸 사용자에게 강제하는건 별로 직관적이지 않다.

우회하는 다른 방법으로는 interface 대신 type을 사용할 수 있다.

읽으면서

나는 일단 interface를 export해서 우회하고자 한다. type으로 바꾸면 나중에 확장하지 못할 거 같아서. 개발자들이 이 문제를 어떻게 해결할지 궁금하다. 살포시 watch를 눌러본다.

window is undefined, vue-test-utils needs to be run in a browser environment 이슈 해결법

Sun, 05 Mar 2023 15:04:29 GMT

이슈

기존 프로젝트에 vue-test-utils v1, jest로 테스트 환경을 구축하는데 다음과 같은 에러를 만났다.

원인

이슈에 대해서 검색해보다가 아래 글을 찾았다.

https://github.com/vuejs/vue-test-utils/issues/999

jest27부터 성능 이슈 때문에 기본 테스트 환경값을 "jsdom"에서 "node"로 바꿨다고 한다. jest-environment-jsdom 또한 기본 종속성 트리에서 제거했다고 한다.

해결책

이를 해결하려면 jest-environment-jsdom 패키지를 설치하고 testEnvironment값을 지정해주면 된다.

npm i --save-dev jest-environment-jsdom

// jest.config.js
module.exports = {
 ...
 testEnvironment: 'jsdom'
}

구글 스프레드시트에서 javascript 코드 실행하기(Apps Script, custom function)

Sun, 19 Feb 2023 18:03:01 GMT

사이드 프로젝트로 database의 data를 migration하다가 스프레드시트 상에서 데이터를 쉽게 변환할 수 있는 방법으로 Apps Script 기능을 찾을 수 있었습니다.

저에겐 unix timestamp 데이터가 있었고, 이것을 ISO String으로 변환해서 새로운 데이터베이스에 bulk로 insert하고 싶었습니다.

확장 프로그램의 Apps Script 메뉴를 활용합니다.

그러면 코드를 작성하는 화면이 나오는데, 함수를 작성만 한다고 추가되지는 않고 스크린샷에서 보시는 것처럼 customfunction이라는 주석을 달아야 등록이 됩니다. jsDoc 형식으로 부가적인 주석도 달 수 있습니다.

주석을 작성하고 저장후에 스프레드시트로 돌아오면 저희가 작성했던 커스텀 함수가 보이고, 주석도 잘 보이는 것을 확인할 수 있습니다.

데이터를 변환할 때 자바스크립트가 필요하거나, 편한 경우에 데이터를 복사해서 변환 후에 다시 붙여넣는 작업을 했었는데 이 기능을 사용하면 너무 편하게 변환할 수 있고, 자주 사용하는 스크립트는 저장해 놓을 수 있어서 더 좋은 거 같습니다.

특정 셀로 바로 가는 엑셀 링크 만드는 방법

Fri, 17 Feb 2023 09:02:14 GMT

스프레드시트로 작업하면서 데이터가 많아지면 동료에게 공유하는 것도 일입니다. 특정 데이터를 찾을 때 문서링크로 이동 후에 직접 검색을 하시는 동료들의 모습을 보고 특정 셀로 바로 이동할 수는 없을까 생각해보다가 찾은 방법입니다.

예시의 데이터는 A열 19행에 있습니다.

바로 이동하고자 하는 셀에서 이 셀의 링크 얻기로 링크를 얻으시고 접속해보시면

아래와 같이 해당 셀로 바로 갈 수 있는 링크를 얻게 됩니다.

이 시트의 몇열 몇행에 데이터가 있다고 전달하기보다는 이 링크를 바로 공유해보면 어떨까요 :)

supabase bucket new row violates row-level security policy for table "objects" 이슈 해결법(policy 설정법)

Fri, 10 Feb 2023 00:03:29 GMT

이슈

supabase storage bucket에서 권한이 없는 경로로 operation을 수행하면 다음과 같은 권한 이슈가 발생합니다.

아래 이슈는 제가 권한이 없는 경로로 image를 upload할 때 발생했습니다.

new row violates row-level security policy for table \"objects\"

해결

권한이 없으면 권한을 설정해주면 됩니다! bucket policy 메뉴로 접속합니다.

해당 bucket의 New policy 메뉴를 클릭해서 새로운 정책을 추가합니다.

저는 간단하게 기존의 템플릿에서 가져오도록 했습니다.

커스터마이징이 필요하시면 아래 버튼을 클릭하시면 됩니다.

맨 첫번째 정책인 “public folder에 있는 JPG image에 대해 유저에게 권한 부여하기”를 선택합니다.

여기서 Allowed operation에 체크해주시고, 저는 Policy definition에서 JPG image인 조건을 제거했습니다.

그렇게 정책을 생성한 후에 다시 이미지를 업로드해보면 정상적으로 작동하는 것을 확인할 수 있습니다.

vue3 composition api로 재사용가능한 코드 만들기 & toRefs 기능

Tue, 07 Feb 2023 23:03:23 GMT

vue3의 composition api를 사용하면 로직을 재사용할 수 있습니다.

직접 짜보니 react hook과 흡사하다는 생각이 많이 들었습니다.

supabase에서 id에 해당하는 data의 한글이름을 가져오는 코드를 재사용하기 위해 짜보았습니다.

// @/modules/useKoreanName.js
import { supabase } from '@/utils/supabase'
import { reactive, toRefs } from 'vue'

export default function useUserKoreanName() {
  const state = reactive({
    userKoreanName: '이름',
  })
  const loadUserKoreanName = async id => {
    const koreanName = await fetchUserKoreanName(id)
    if (koreanName) state.userKoreanName = koreanName
  }
  const fetchUserKoreanName = async id => {
    try {
      const { data: users } = await supabase
        .from('users')
        .select('korean_name')
        .eq('id', id)
      if (users) {
        return users[0].korean_name
      }
    } catch (error) {
      console.error(error)
    }
  }
  return { ...toRefs(state), fetchUserKoreanName, loadUserKoreanName }
}

여기서 눈여겨볼 점은 state를 ...toRefs(state)의 형태로 반환하는 점입니다. 이렇게 해야 반응성이 유지된다고 하는데요. 이 모듈을 컴포넌트에서 불러와서 사용해봤습니다.

const { userKoreanName, loadUserKoreanName } = useKoreanName();

onMounted(() => {
  fetchNotes();
  loadUserKoreanName(id);
});

...
    <div class="text-4xl mr-4">{{ userKoreanName }} 님 담벼락</div>

template에서 userKoreanName을 출력하는데 아래와 같이 잘 동작하는 것을 볼 수 있습니다.

만약에 toRefs를 빼보면 어떨까요?

// @/modules/useKoreanName.js
import { supabase } from '@/utils/supabase'
import { reactive } from 'vue'

export default function useUserKoreanName() {
  const state = reactive({
    userKoreanName: '이름',
  })
  const loadUserKoreanName = async id => {
    const koreanName = await fetchUserKoreanName(id)
    if (koreanName) state.userKoreanName = koreanName
    console.info('koreanName after load : ', state.userKoreanName)
  }
  const fetchUserKoreanName = async id => {
    try {
      const { data: users } = await supabase
        .from('users')
        .select('korean_name')
        .eq('id', id)
      if (users) {
        return users[0].korean_name
      }
    } catch (error) {
      console.error(error)
    }
  }
  return { ...state, fetchUserKoreanName, loadUserKoreanName }
}

이 경우에는 로그를 찍어보면 useUserKoreanName 함수 내부에서는 state가 반응성을 띕니다.

하지만 컴포넌트에서 userKoreanName을 출력해보면 기본값이 들어가 있는 것을 확인할 수 있습니다.

toRefs에 관한 공식문서 공식문서를 살펴보면 toRefs는 composable function에서 반응형의 객체를 반환할 때, 사용하는 컴포넌트에서는 객체를 destructure나 spread를 하더라도 반응성을 잃지 않도록 한다고 합니다.

vite lib production build에서 css 파일명 변경하기

Sat, 04 Feb 2023 20:03:38 GMT

해결법

vite를 사용해 library mode로 빌드할 때 나오는 css파일의 이름을 변경하는 방법은 다음과 같습니다.

vite.config.js의 build/rollupOptions에 output, assetFileNames를 설정합니다.

build: {
   rollupOptions: {
    ...
      output: {
         assetFileNames: `${LIBRARY_NAME}.[ext]`,
      },
   },
},

결과

vite에서 전역 scss 파일 추가하기

Sat, 04 Feb 2023 20:02:02 GMT

vite에서 전역 scss를 추가하는 방법을 다음과 같습니다.

해결법

vite.config.js에 css, preprocessorOptions, scss, additionalData 속성을 추가해주시면 됩니다.

// https://vitejs.dev/config/
import { defineConfig } from 'vite'
const path = require('path')

export default defineConfig({
  plugins: [vue()],
  resolve: {
    alias: {
      '@': path.resolve(__dirname, './src'),
    },
  },
  // 이 부분 추가
  css: {
    preprocessorOptions: {
      scss: {
        additionalData: `@import "@/assets/style/base/main";`,
      },
    },
  },
})

vue3 vite 프로젝트에 tailwind 설치하는 법

Sat, 28 Jan 2023 09:02:23 GMT

패키지 설치

Tailwind와 peer-dependencies를 설치합니다.

npm install -D tailwindcss@latest postcss@latest autoprefixer@latest

설정 파일 생성

tailwind.config.js, postcss.config.js를 아래 명령어로 생성합니다.

npx tailwindcss init -p

perge 옵션을 주면 Tailwind가 tree-shaking을 하면서 사용하지 않는 스타일을 production build에서 제거합니다.

// tailwind.config.js
module.exports = {
  purge: ['./index.html', './src/**/*.{vue,js,ts,jsx,tsx}'],
  darkMode: false, // or 'media' or 'class'
  theme: {
    extend: {},
  },
  variants: {
    extend: {},
  },
  plugins: [],
}

index.css 추가

@tailwind directive를 사용해 Tailwind style들을 추가합니다. Tailwind가 build time에 해당 directive들을 스타일로 변환합니다.

/* ./src/index.css */
@tailwind base;
@tailwind components;
@tailwind utilities;

index.css import

마지막으로 main.js에 css 파일을 추가해주면 끝입니다.

// src/main.js
import { createApp } from 'vue'
import App from './App.vue'
import './index.css'

createApp(App).mount('#app')

설정 변화

tailwind v3이상을 쓰신다면! purge -> content로 rename되었으니 바꿔주세요.

// tailwind.config.js
module.exports = {
  content: ['./index.html', './src/**/*.{vue,js,ts,jsx,tsx}'],
  darkMode: false, // or 'media' or 'class'
  theme: {
    extend: {},
  },
  variants: {
    extend: {},
  },
  plugins: [],
}

그리고 darkMode 기본값이 media로 변경되었다고 합니다. 그래서 따로 지정해주시려는 게 아니면 darkMode를 지워주셔도 되겠습니다 :)

더 자세한 내용은 아래 가이드를 참고해주시면 됩니다. 감사합니다.

tailwindcss upgrade guide

Failed to load plugin import declared in .eslintrc.js eslint 이슈 해결법

Thu, 26 Jan 2023 23:02:22 GMT

eslint를 upgrade한 lint 명령어를 실행시켰는데 아래와 같은 에러를 만났습니다.

$ eslint --ext .js,.vue --ignore-path .gitignore --fix src

Oops! Something went wrong! :(

ESLint: 8.32.0

Error [ERR_PACKAGE_PATH_NOT_EXPORTED]: Failed to load plugin 'import' declared in '.eslintrc.js': Package subpath './lib/util/glob-util' is not defined by "exports" in /Users/donghoonsong/project/comento-ui/node_modules/eslint/package.json
Referenced from: /Users/donghoonsong/project/comento-ui/.eslintrc.js
    at new NodeError (node:internal/errors:371:5)
    at throwExportsNotFound (node:internal/modules/esm/resolve:440:9)
    at packageExportsResolve (node:internal/modules/esm/resolve:692:3)
    at resolveExports (node:internal/modules/cjs/loader:482:36)
    at Function.Module._findPath (node:internal/modules/cjs/loader:522:31)
    at Function.Module._resolveFilename (node:internal/modules/cjs/loader:919:27)
    at Function.Module._load (node:internal/modules/cjs/loader:778:27)
    at Module.require (node:internal/modules/cjs/loader:1005:19)
    at require (node:internal/modules/cjs/helpers:102:18)
    at Object.<anonymous> (/Users/donghoonsong/project/comento-ui/node_modules/eslint-plugin-import/lib/rules/no-unused-modules.js:43:34)
error Command failed with exit code 2.

아래 명령어를 실행해서 plugin을 upgrade했더니 해결됐습니다.

yarn upgrade eslint-plugin-import

https://github.com/import-js/eslint-plugin-import/issues/2252

vscode prettier format on save 적용

Thu, 26 Jan 2023 23:02:20 GMT

format on save는 파일을 저장할 때 포맷을 적용하는 기능입니다.

vscode에서 prettier를 설치한 후에 format on save를 적용하고 싶으시다면 (mac 기준) command + ,로 설정창을 열고 default formatter를 검색합니다.

해당 값을 prettier로 설정해줍니다.

그리고 다시 format on save를 검색해서 활성화시켜주시면 끝입니다!

[Vue] Component name should always be multi-word eslint error

Thu, 26 Jan 2023 23:01:55 GMT

이슈

eslint를 8로 업데이트 하니 새로운 eslint error가 발생했습니다.

 27:8  error  Component name "Loader" should always be multi-word  vue/multi-word-component-names

해결

아래 줄을 eslint rules에 삽입했습니다.

'vue/multi-word-component-names': 'off',

공부

https://eslint.vuejs.org/rules/multi-word-component-names.html

문서를 살펴보면 root App component나 <transition>, <component> 같은 vue의 built-in 컴포넌트가 아니면 component name은 multi-word가 되어야 한다는 규칙이 있습니다. 이 규칙이 생겨난 이유는 HTML element(single-word)와의 혼동을 막기 위함입니다.

eslint-plugin-vue v7.20.0 부터 추가되었다고 하는데, 매번 component name을 multi-word로 짓는 것도 일일 거 같고, 이름이 겹칠 확률이 얼마나 될까 싶습니다.

Vue3 + Vite에서 환경변수(env) 사용하는 방법

Tue, 24 Jan 2023 18:02:35 GMT

create-vue를 사용해 생성한 Vue3 프로젝트는 Vite를 기반으로 합니다. 이 환경에서는 env에 어떻게 접근할까요?

먼저, VITE_을 prefix로 사용해야 합니다. 그러면 import.meta.env로 접근할 수 있습니다.

VITE_ENV_VARIABLE = EXAMPLE

<script setup>
  const variable = import.meta.env.VITE_ENV_VARIABLE
</script>

php version upgrade 이슈 해결

Tue, 10 Jan 2023 14:01:31 GMT

저희는 백엔드가 php로 되어 있는데요. php version을 8.0 -> 8.1로 올리셔서 그에 대응해야 하는 상황이었습니다.

기존에는 아래와 같은 방식으로 설치하고, 링크를 다시 해주면 반영됐었는데, 이번에는 link를 해도 version이 바뀌지 않는 이슈가 생겼습니다.

brew install php@8.1
brew unlink php@8.0
brew link php@8.1
// php version check
php -v

그래서 원인을 찾다보니까 ~/.zshrc에 아래와 같이 php version을 명시하는 코드가 들어 있었고 이 부분을 제거했습니다.

export PATH="/opt/homebrew/opt/php@8.0/bin:$PATH"

하지만 버전을 다시 확인해봤는데 이번에는 엉뚱하게 아래와 같은 메시지가 떴습니다.

WARNING: PHP is not recommended

PHP is included in macOS for compatibility with legacy software. Future versions of macOS will not include PHP. PHP 7.3.29-to-be-removed-in-future-macOS (cli) (built: Sep 6 2021 05:14:39) ( NTS ) Copyright (c) 1997-2018 The PHP Group Zend Engine v3.3.29, Copyright (c) 1998-2018 Zend Technologies

메시지로 구글링을 해봤는데 보통은 php를 다시 설치하고, 다시 링크 과정을 거쳐서 해결했다고 나와 있었습니다. 하지만 저는 그런 방법들만으로는 해결하지 못했고, 이것저것 해보다가 ~/.zshrc에 다시 버전을 명시해주는 코드를 넣어서 해결했습니다.

export PATH="/opt/homebrew/opt/php@8.1/bin:$PATH"

[intellij] 인텔리제이 단어 찾아바꾸기 단축키

Tue, 10 Jan 2023 11:02:02 GMT

웹스톰에서 단축키 ctrl + shift + f로 코드 검색을 주로 했었는데요

ctrl + shift + r을 사용하면 찾아바꾸기가 가능합니다.

저는 라이브러리 업데이트 후에 변경사항을 일괄 적용해야 했는데요. Typography의 기존 headline6 type을 headline7로 바꿔야 했습니다.

메뉴 하단에 있는 replace All 버튼으로 쉽게 변경할 수 있었습니다.

실용주의 프로그래머 리뷰 (2장)

Sun, 08 Jan 2023 20:14:25 GMT

동료들과 실용주의 프로그래머라는 책을 같이 읽고 있습니다. 공부하면서 정리한 내용을 블로그에도 남겨볼까 합니다. 아직 못 읽은 부분은 계속 업데이트하려고 합니다.

2장. 실용주의 접근법

새로운 아이디어에 전력투구하기 전에 먼저 아이디어를 검증하고 피드백을 받아 보는 것이 매우 중요하다.

Topic8 좋은 설계의 핵심

좋은 설계는 나쁜 설계보다 바꾸기 쉽다.

ETC(Easier to Change)

‘내가 방금 한 일이 전체 시스템을 바꾸기 쉽게 만들었을까, 어렵게 만들었을까?’ → 파일 저장, 테스트 작성, 버그 수정시에 물어보기

코드의 결합도를 낮추고 응집도를 높인다.

컴포넌트 개발할 때 신경쓰고 있지만 정말 어렵다. 버튼 등 간단한 컴포넌트는 원칙을 지키기 비교적 쉬우나, 여러 개의 컴포넌트를 같이 쓰는 등의 컴포넌트는 결합도가 높으면 사용하기는 쉬워지나, 유지보수가 안 좋음. 디자인 시스템을 개발할 때 처음에는 바뀔일이 없던 컴포넌트도 나중에는 바뀌기 시작하고, 그래서 컴포넌트를 미리 넣어놓기 보다는 위치 정도만 잡아두고, 사용할 때 그 위치에 컴포넌트를 넣는 식으로 구현

도전해 볼 것

일상적으로 사용하는 설계 원칙
- DRY…
ETC를 따르는 코드를 작성할 때 큰 도움을 주거나 걸림돌이 되는 부분?
에디터에 “ETC?” 기능을 설정해 볼 것
- webstorm file watcher → 되나?

FileWatcher는 컴파일러 같은건 할 수 있는데 메시지 띄우는건 못할 듯.

Topic9 DRY: 중복의 해악

모든 지식은 시스템 내에서 단 한 번만, 애매하지 않고, 권위 있게 표현되어야 한다.

주석을 달기 전에 먼저 코드에 의도를 드러낼 것.

모듈이 자료 구조를 노출하면 언제나 모듈의 구현과 그 자료 구조를 사용하는 코드 사이에 결합이 생긴다. 가능하다면 언제나 객체의 속성을 읽고 쓸 때 접근자 함수를 사용할 것.

개발자 간의 중복 → 적극적이고 빈번한 소통

개발자 간의 중복은 엄청 공감됨. 이번에 만든 기능이 다른 분이 먼저 개발했었던 경우가 많음. 이런걸 찾기가 굉장히 힘듦. 그래서 요즘에는 다른 분들에게 먼저 물어보고 시작함.

Topic10 직교성

하나가 바뀌어도 나머지에 어떤 영향도 주지 않으면 서로 직교한다.

우리가 설계하고 싶은 것은 자족적인(단일하고 잘 정의된 목적을 가진) 독립적인 컴포넌트

직교적인 컴포넌트들을 결합함으로써 단위 노력당 더 많은 기능을 얻을 수 있다.(M x N)

‘특정 기능에 대한 요구 사항을 대폭 변경하는 경우 몇 개의 모듈이 영향을 받는가?’ → 한개여야 한다.

불필요한 것은 다른 모듈에 보여 주지 않으며, 다른 모듈의 구현에 의존하지 않는 코드를 작성할 것.(shy)

직교적으로 설계하고 구현한 시스템 → 테스트하기 더 쉽다

모듈 수준의 테스트나 단위 테스트가 통합 테스트보다 테스트 케이스를 만들고 수행하기 훨씬 쉽다.

단위 테스트를 작성하는 행위는 직교성을 테스트해 볼 수 있는 기회

도전해 볼 것

GUI가 있는 경우 여러 기능을 묶어서 사용하거나 할 때에는 수동으로 해야 함. 셸 프롬프트에서는 그걸 묶은 새로운 명령어를 만들어서 사용 가능.

연습 문제 1

Split2가 직교적이라고 생각. Split1에는 다음 줄로 이동하는 역할이 포함. 하지만 바로 다음 줄이 아니라 한 줄씩 건너뛰는 등 요구사항이 변경되면 readNextLine을 변경해야 함.

Topic11 가역성

되돌릴 수 없는 결정을 최대한 줄인다. → 우리의 선택은 최선이 아닐 수 있다.

새로운 프로젝트의 백엔드 서버(파일 업로드가 있는)를 람다로 올렸다가 request size 제한이 있다는 걸 알아서 옮겼던 기억이…

컴포넌트 설계할 때도 어렵다. 어느 정도의 미래까지 대비해야 할지

Topic12 예광탄

요구 사항으로부터 최종 시스템의 일부 측면까지 빨리, 눈에 보이게, 반복적으로 도달하게 해 줄 무언가가 있어야 한다.

요구 사항에서 의문이 드는 부분이나 가장 위험이 커 보이는 곳의 코드를 가장 먼저 작성

시스템을 구성하는 요소를 모두 연결해 놓은 후라면 목표물에 얼마나 근접했는지 확인할 수 있고, 조정이 가능하다.

목표물에 맞을 때까지 조준을 옮겨야 한다.

예광탄 코드
- 기능은 별로 없지만 완결된 코드
- 최종 시스템 골격 중 일부가 된다.
프로토타입
- 예광탄을 발사하기 전에 수행하는 정찰 단계

한 사이클을 한 기능에서 쭉 돌아보는 방식. 배포 환경에서 발견되는 문제점을 미리 발견할 수 있음. 가장 큰 위험 요소를 빨리 파악할수록 고치는데 필요한 비용은 줄어든다고 생각.

Topic13 프로토타입과 포스트잇

프로토타입은 위험 요소를 분석하고 노출 시킨 후, 매우 저렴한 비용으로 바로잡을 기회를 얻는 것

당장 중요하지 않은 세부 사항이라면 일단 무시하면서 코딩할 수 있다.

프로토타이핑의 대상은 위험을 수반하는 모든 것 → 이를 통해 배우는 교훈이 가치가 있다.

아키텍처
추가 기능
외부 데이터 구조 혹은 내용
외부 도구나 컴포넌트
성능
사용자 인터페이스

무시해도 좋을 것들

정확성
- 더미 데이터 사용
완전성
- 입력 데이터 하나와 한 가지 메뉴 항목만 작동해도 됨
안정성
- 오류 검사는 빼먹거나 무시
스타일
- 주석이나 문서가 많지 않아야 한다.
- 프로토타입 결과를 문서로 많이 작성할 것

규명할 만한 사항

주요 영역의 책임이 잘 정의되었고 적절한지
주요 컴포넌트 간의 협력 관계가 잘 정의됐는지
결합도는 최소화했는지
중복이 발생할 만한 곳이 있는지
정의된 인터페이스와 제약 사항을 수용할만 한지
각 모듈이 실행 중에 필요한 데이터에 접근할 수 있는 경로를 갖고 있는지
모듈에 데이터가 필요한 시점에 데이터 접근이 가능한지

프론트 단에는 데이터 별로 필요한 시점이 있는데 개발하다 보면 필요한데 아직 못 불러오거나 하는 경우가 있음.

이번에 게시판에 대댓글을 추가하는데 (댓글까지 있었음) 저와 백엔드 개발자님은 현재 디비로 충분히 대댓글까지 커버할 수 있을거라고 생각했었는데, 만들고보니 현재 구조에서는 따로 분리하는 편이 더 나을 거 같다는 판단을 함.

이것도 UI를 만들어놓고 api 연동을 했었는데, UI는 텍스트만 나와도 되니까 api 연동을 맨 먼저 해보는 것이 어땠을까 하는 생각이 듦.

프로토타입을 코드로 만들 때는 시작하기 전에 항상 모든 사람에게 폐기 처분할 코드임을 밝혀야 한다.

연습 문제 3

디자인 팀에게 피그마로 만들어줄 것을 요청
react, vue

Topic17. 셸 가지고 놀기

GUI 환경의 기능은 설계자가 의도한 범위를 넘어설 수 없다.

도커로 서버를 켜는 명령어는 만들어놓고 유용하게 쓰고 있다. 하지만 그 이상의 활용은 못 해봄.

도전해보기

가르쳐 줘 본 적 없음. 알아서 잘함. 자동화 할만한건 아직 없음

셸을 사용할 일이 많이 없어서 와닿지는 않지만 저자의 의도는 알겠음.

Topic18. 파워 에디팅

유창해지는 것의 가장 큰 이점은 사용법을 생각하지 않아도 된다는 것. 속도가 빨라지면 이점이 있음

텍스트 편집 시 문자, 단어, 줄, 문단 단위로 커서를 이동하거나 내용 선택
반대쪽 괄호로 이동 → control + M
control + option + [] ⇒ navigate between code blocks
option + command + L ⇒ reformat code
command + shift + / ⇒ 여러줄 주석
shift + command + z ⇒ redo
shift + command + [] ⇒ move between tabs
command + L ⇒ go to line number
search “sort lines” on command panel

트랙패드없이 작업을 해봐야겠다. 분명히 생산성 향상에 큰 도움이 될 거 같다.

Topic19. 버전 관리

롤백하기 → revert commit
신입이 들어왔을 때 초기 세팅을 하나의 셸 스크립트로 퉁칠 수 있을까? 있다면 편하긴 하겠다.
다른데는 깃허브에서 어떤 기능까지 쓰는지 궁금. discussion도 쓰나? 이슈는?

Topic20. 디버깅

비난 대신 문제를 해결할 것. 어쨌든 해결해야 한다.
“그건 불가능해”라는 반응하지 말 것. 실제로 일어난 일이니까.
표면에 보이는 증상만 해결하려고 하지 말고 문제의 근본 원인을 고민할 것
코드를 고치기 전에 실패하는 테스트부터 한다. → ‘명령 하나’로 버그를 재현하기 위해
“select”는 망가지지 않았다. 컴퓨터는 거짓말하지 않는다. 시스템 탓을 하지 말 것
가정하지 말고 증명하라.
버그를 미리 잡을 순 없는지 계속 고민해볼 것

프론트는 사용자의 환경이 매우 다양하다. 값을 참조하는 것도 그 구문을 실제로 호출하는 시점에 따라 에러가 날 수 있음.

Topic21. 텍스트 처리

기본적인 도구만으로는 해내기 힘든 종류의 변환 작업이 있을 수 있고, 이를 위해 텍스트 처리 도구가 필요하다. ex) json -> yaml 변환기

Topic22. 엔지니어링 일지

파일이나 위키말고 종이를 사용해볼 것

기억보다 믿을 만하다.
진행 중인 작업과 관련없는 발상을 일단 쌓아놓을 수 있다.
고무 오리와 같은 역할

개발자는 노트북에 적는게 편하겠지만 항상 들고 다닐 수 있는가? 라고 물어본다면 No인 거 같다.

실용주의 프로그래머 리뷰 (1장)

Sat, 12 Nov 2022 10:11:04 GMT

1장. 실용주의 철학

Topic1 당신의 인생이다

우리에게는 스스로의 행동을 직접 결정할 수 있는 힘이 있다. 이 업계는 우리에게 다양한 기회를 주고, 주도권은 우리에게 있으니 행동하라.

Topic2 고양이가 내 소스 코드를 삼켰어요

개인적으로 최선을 다하는 것이 전부가 아니다. 불가능하거나 위험 요소가 크면 책임을 맡지 않을 권리가 있고 실수를 저지르거나 잘못된 판단을 내렸다면 잘못을 인정하고 대안을 제시해야 한다. 책임을 맡은 업무에서 외부 요인이 문제가 있더라도 그것까지 커버해야 한다.

“잘 모르겠어요. 하지만 알아볼게요” → 모른다는 것을 인정하고 전문가답게 책임을 지는 방법

현재 회사를 다니면서 스스로 결정을 많이 합니다. 그 결정이 합리적이라면 전적으로 믿어주는 팀원들이 있습니다.

Topic3 소프트웨어 엔트로피

나쁜 설계, 잘못된 결정, 형편없는 코드 등은 모두 깨진 창문이며 발견하자마자 고칠 것. 엔트로피가 우리를 지배하도록 내버려두지 말 것

그러기 위해서는 먼저 망가트리지 말아야 한다.

프로젝트에 깨진 창문은 얼마나 많은지? 어떻게 고칠 것인지?

Topic4 돌멩이 수프와 삶은 개구리

변화의 촉매가 될 것. 사람들은 각자 자신의 자원을 지키려고 한다. (시작 피로) 계속되는 성공에는 합류하기 쉽다.

비슷한 경험을 했습니다. 같이 일하는 디자이너분들과 사이드 프로젝트를 하는데, 첫 미팅 후에 다음 미팅 때 간단하게라도 데모 버전을 보여드렸던 적이 있습니다. 굉장히 반응은 뜨거웠고 크게 동기부여가 되서, 아이디어도 많이 나왔고 디자이너 분들의 의욕이 넘쳐나는 것이 보였습니다. 다음 미팅때도 기능을 조금 더 추가한 데모 버전을 보여드렸고 그 결과 업무에 지쳐있던 분들의 컨디션을 끌어올릴 수 있었고 계속해서 동기를 부여할 수 있었습니다.

큰 그림을 기억하라. 당장 하고 있는 일에만 정신을 쏟지 말고, 주변에서 무슨 일이 벌어지는지 살펴봐야 한다.

Topic5 적당히 괜찮은 소프트웨어

완벽한 소프트웨어를 만들 순 없지만 적당히 괜찮은 소프트웨어를 만들 순 있다.

우리가 생산해 낸 것이 적당히 괜찮게 사용자의 요구를 충족하는지 결정하는 과정에 사용자가 참여할 기회를 가져야 한다.

완벽하게 훌륭한 프로그램을 과도하게 장식하거나 지나칠 정도로 다듬느라 망치지 말 것.

Topic6 지식 포트폴리오

지식에 대한 투자가 언제나 최고의 이윤을 낸다.

매우 인상깊은 말

우리 지식은 기한이 있는 지식이다. 새로운 것을 배우는 능력이 가장 중요한 능력 자산

알고 있지만 참 어려운… react, vue도 나중에 보면 한물 간 기술이겠지

주기적으로 공부하자
더 많은 기술에 익숙해지자 → 변화에 더 잘 적응
리스크 관리 → 위험도가 높지만 보상이 큰 것, 낮지만 보상이 작은 것을 잘 섞자
싸게 사서 비싸게 팔기(얼리어답터)
검토 및 재조정 → 트렌드를 다시 파악해서 올바른 방향으로 가고 있나 체크!

많이 하지 않더라도 조금씩 공부하자. -> 새로운 것을 접하는 것만으로도 리프레쉬되고 나를 객관적으로 돌아보는데 도움이 많이 됨. 중심을 잡을 기술(react 등)과 새롭지만 높은 보상이 있는 기술을 섞어볼 것.(deno, next13 등) 포트폴리오에 비유를 하니까 되게 재밌고 유사한 점이 많은 거 같음.

목표

매년 새로운 언어를 최소 하나는 배우기
- 언어는 동일한 문제를 다르게 푼다
- 사고방식의 확장에 도움을 줌
기술 서적을 한 달에 한 권씩 읽기
- 제일 실천하고 싶은 것
- 깊이 있는 지식 → 긴 글 형식의 책
모임에 참여할 것
- 고립은 경력에 치명적일 수 있다.
다른 환경에서 실험
- 새로운 환경은 자극을 준다

책은 읽기 시작했는데 기술 서적을 읽을 생각은 못했음. 주기적으로 읽어야겠다 라는 생각이 듦. 모임에 참여하자. 겨울엔 사진을 좀 줄이고 모임을!

비판적 사고

왜냐고 다섯 번 묻기
누구에게 이익이 되나?
- 사용자?
- 개발자?
- 조직원?
어떤 맥락인가?
- 전제 조건이 뭔지
- 그 결과의 장,단기적 여파는 무엇인지?
언제 혹은 어디서 효과가 있을까?
- 다음에 어떤 일이 일어날까 → 그 다음엔 어떤 일이 일어날까? 멀리 생각해볼 것
왜 이것이 문제인가?

일을 할 때, 왜 하는지, 공수대비 얼마나 임팩트, 컨피던스가 있는지를 항상 생각하는데 더 다각화해서 생각해볼만 하다.

Topic7 소통하라!

청중을 알고 내용을 그에 맞게 각색해서 전달.

멋지게 보이게 할 것. (개발자라는 핑계로 디자인을 소홀히 하지말자.)

타이밍도 중요(청중이 내 전달 내용을 필요로 하는 타이밍을 찾아보자)

청중을 참여시켜라

결국 듣는 사람이 듣고 싶은 얘기를 해야 한다.

문서화 → 코드의 용도와 목적을 논해야 한다. 동작 방식은 코드가 보여주므로 불필요.

청중 참여, 타이밍 등 청중을 계속 생각하는 걸 연습해야겠음.

Jest로 next component test하기

Wed, 02 Nov 2022 22:11:06 GMT

Next.js 환경의 실무 프로젝트에서 Report라는 페이지 컴포넌트를 처음 테스트하면서 겪었던 이슈들을 정리했습니다.

먼저 테스트 코드의 많은 예제에서 다루는 것처럼 테스트의 기본은 컴포넌트가 제대로 render되는지 확인하는 것이라 생각하여 render시키고 난 후에 다음 것들을 생각해보고자 하였습니다. 분명히 마음처럼 쉽게 되지 않을 거라는 것을 알았기 때문입니다.

import Report from '../components/TabContent/Report';
import { render } from '@testing-library/react';

describe('Report', () => {
	it('should render', () => {
		render(<Report />);
	});
});

바로 첫번째 이슈를 겪었습니다.

Jest useNavigate() may be used only in the context of a Router component

컴포넌트 내부에서 useNavigate()를 사용하고 있었는데 Router component로 감싸지 않아서 에러가 났습니다. Router component로 감싸서 해결했습니다.

import Report from '../components/TabContent/Report';
import { render } from '@testing-library/react';
import { BrowserRouter as Router } from 'react-router-dom';

describe('Report', () => {
	it('should render', () => {
		render(
			<Router>
				<Report />
			</Router>,
		);
	});
});

이제는 react-redux 관련 에러가 났습니다.

could not find react-redux context value; please ensure the component is wrapped in a <Provider>

Writing Tests | Redux

관련 이슈를 검색해보니 redux를 test에서 사용할 때 가이드라인이 있어 해당 코드를 추가했습니다.

// src/utils/test-utils.tsx

import React, { PropsWithChildren } from 'react';
import { render } from '@testing-library/react';
import type { RenderOptions } from '@testing-library/react';
import { configureStore } from '@reduxjs/toolkit';
import type { PreloadedState } from '@reduxjs/toolkit';
import { Provider } from 'react-redux';
import type { AppStore, RootState } from '@/store';
import { reducers } from '@/store';

interface ExtendedRenderOptions extends Omit<RenderOptions, 'queries'> {
	preloadedState?: PreloadedState<RootState>;
	store?: AppStore;
}

export function renderWithProviders(
	ui: React.ReactElement,
	{
		preloadedState = {},
		store = configureStore({ reducer: reducers, preloadedState }),
		...renderOptions
	}: ExtendedRenderOptions = {},
) {
	function Wrapper({ children }: PropsWithChildren<{}>): JSX.Element {
		return <Provider store={store}>{children}</Provider>;
	}
	return { store, ...render(ui, { wrapper: Wrapper, ...renderOptions }) };
}

import Report from '../components/TabContent/Report';
import { BrowserRouter as Router } from 'react-router-dom';
import { renderWithProviders } from '@/utils/test-utils'

describe('Report', () => {
	it('should render', () => {
		renderWithProviders(
			<Router>
				<Report />
			</Router>
		);
	});
});

다시 돌려보니까 새로운 에러를 발견했습니다. 검색해보니 아래와 같은 솔루션을 발견할 수 있었습니다.

window.matchMedia is not a function

Jest test fails : TypeError: window.matchMedia is not a function Manual Mocks · Jest

import Report from '../components/TabContent/Report';
import { BrowserRouter as Router } from 'react-router-dom';
import { renderWithProviders } from '@/utils/test-utils'

Object.defineProperty(window, 'matchMedia', {
	writable: true,
	value: jest.fn().mockImplementation(query => ({
		matches: false,
		media: query,
		onchange: null,
		addListener: jest.fn(), // Deprecated
		removeListener: jest.fn(), // Deprecated
		addEventListener: jest.fn(),
		removeEventListener: jest.fn(),
		dispatchEvent: jest.fn(),
	})),
});

describe('Report', () => {
	it('should render', () => {
		renderWithProviders(
			<Router>
				<Report />
			</Router>
		);
	});
});

다시 돌려봤는데 다른 에러가 발생했습니다. 하지만 비슷한 원인의 에러인거 같아서 더 찾아봤고, window가 아닌 global 객체의 matchMedia를 mocking해야 하는 상황이었습니다.

import Report from '../components/TabContent/Report';
import { BrowserRouter as Router } from 'react-router-dom';
import { renderWithProviders } from '@/utils/test-utils';

global.matchMedia =
	global.matchMedia ||
	function () {
		return {
			addListener: jest.fn(),
			removeListener: jest.fn(),
		};
	};

describe('Report', () => {
	it('should render', () => {
		renderWithProviders(
			<Router>
				<Report />
			</Router>,
		);
	});
});

드디어 정상적으로 작동했습니다 🙂

global.matchMedia를 mocking하는 부분은 공통적으로 실행될 수 있는 영역에다가 넣어야겠다는 생각이 들었습니다.

20220829 TIL

Mon, 29 Aug 2022 22:09:10 GMT

yarn berry는 어떤 문제를 해결해주는가?

비효율적인 의존성 검색
- 기존 : node_modules 선회
- yarn berry : .pnp.cjs 사용
재현 가능성
- 기존 : npm은 패키지를 찾지 못하면 상위 디렉토리의 node_modules를 찾으므로, 상위 디렉토리 환경에 따라 달라짐.
- yarn berry : 의존성이 외부 환경에 영향을 받지 않음
의존성 설치
- node_modules 필요없음. 같은 버전의 패키지 여러 번 설치되는거 방지
- Zero-install을 사용하면 라이브러리를 설치 없이 사용 가능
의존성 관리
- 의존성을 끌어올리지 않으므로 유령 의존성 현상 방지

msw로 server api mocking 성공

현재 cypress로 e2e test를 해보려고 함. api mocking에 cy.intercept()를 사용하거나 msw를 사용할 수 있지만 문제는 nuxt의 server side에서 부르는 api를 intercept하지 못함. 이에 대해 검색해보면

next.js 서버를 하나 더 만든다. -> 실패
- 동시에 돌리니까 nuxt page가 렌더링되지 않음. (정확한 이유는 잘 모르겠음.)
- api mocking하자고 next.js, react 등을 설치해야 하는 문제.
cypress-mock-ssr
- 아직 사용해보지 않음.
msw
- 브라우저 환경에서만 동작하는 줄 알았는데 확장하여 node 환경에서 동작하는 모듈도 있음.
- 이 방법으로 성공했고, 글 작성 예정.

참고

https://toss.tech/article/node-modules-and-yarn-berry

github action으로 gatsby 블로그 github.io에 배포하기

Sun, 14 Aug 2022 21:08:26 GMT

blog template을 바꾸면서 main branch에 merge하면 자동으로 배포될 수 있도록 설정하고 싶었습니다. 이를 지원하는 액션이 있을거라고 생각하고 검색해보았더니 아래의 액션을 발견했습니다.

Gatsby Publish

기존 배포 명령어는 다음과 같았습니다.

"deploy": "gatsby build && gh-pages -d public -b master -r 'git@github.com:donghoon-song/donghoon-song.github.io.git'"

.github > workflows directory에 auto-deploy.yml 파일을 생성했습니다.

name: Gatsby Publish

// main branch에 push할 때 실행
on:
  push:
    branches:
      - main

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v1
      - uses: enriikke/gatsby-gh-pages-action@v2
        with:
          access-token: ${{ secrets.ACCESS_TOKEN }}
          // 배포될 repository의 이름을 적습니다.
          // 따로 명시하지 않으면 이 action이 실행되는 repository에 배포됩니다.
          deploy-repo: 'donghoon-song.github.io'
          // 배포될 branch를 적습니다.
          // 따로 명시하지 않으면 'master' branch가 기본값입니다.
          deploy-branch: 'main'

ACCESS_TOKEN은 secrets에서 읽어오는데 아래 공식문서를 참고해 발급받으시고 repository -> settings -> secrets에 추가해주시면 됩니다.

Creating a token

lodash collection flatMapDeep 활용

Sun, 14 Aug 2022 20:09:36 GMT

개발을 하다가 여러가지 input값들을 한번에 관리하는 경우가 생겼고, 각 input이 모두 비어있는지를 체크하고 싶었습니다. 활용할만한 라이브러리를 찾아보다가 lodash collection의 flatMapDeep을 활용하면 쉽게 해결할 수 있었습니다.

코드 확인하기

콘솔창을 보시면 모든 input value값들을 펼쳐서 배열에 저장할 수 있었고 문제를 해결할 수 있었습니다 :)

flatMapDepth의 내부구현은 어떻게 되어 있을지 궁금해서 찾아봤습니다.

import baseFlatten from './.internal/baseFlatten.js'
import map from './map.js'

/**
 * This method is like `flatMap` except that it recursively flattens the
 * mapped results up to `depth` times.
 *
 * @since 4.7.0
 * @category Collection
 * @param {Array|Object} collection The collection to iterate over.
 * @param {Function} iteratee The function invoked per iteration.
 * @param {number} [depth=1] The maximum recursion depth.
 * @returns {Array} Returns the new flattened array.
 * @see flatMap, flatMapDeep, flatten, flattenDeep, flattenDepth, map, mapKeys, mapValues
 * @example
 *
 * function duplicate(n) {
 *   return [[[n, n]]]
 * }
 *
 * flatMapDepth([1, 2], duplicate, 2)
 * // => [[1, 1], [2, 2]]
 */
function flatMapDepth(collection, iteratee, depth) {
  depth = depth === undefined ? 1 : +depth
  return baseFlatten(map(collection, iteratee), depth)
}

export default flatMapDepth

import isFlattenable from './isFlattenable.js'

/**
 * The base implementation of `flatten` with support for restricting flattening.
 *
 * @private
 * @param {Array} array The array to flatten.
 * @param {number} depth The maximum recursion depth.
 * @param {boolean} [predicate=isFlattenable] The function invoked per iteration.
 * @param {boolean} [isStrict] Restrict to values that pass `predicate` checks.
 * @param {Array} [result=[]] The initial result value.
 * @returns {Array} Returns the new flattened array.
 */
function baseFlatten(array, depth, predicate, isStrict, result) {
  predicate || (predicate = isFlattenable)
  result || (result = [])

  if (array == null) {
    return result
  }

  for (const value of array) {
    if (depth > 0 && predicate(value)) {
      if (depth > 1) {
        // Recursively flatten arrays (susceptible to call stack limits).
        baseFlatten(value, depth - 1, predicate, isStrict, result)
      } else {
        result.push(...value)
      }
    } else if (!isStrict) {
      result[result.length] = value
    }
  }
  return result
}

export default baseFlatten

collection의 요소들을 iteratee에 넣고 돌린 결과들을 가지고 baseFlatten 함수에 전달하네요. 그러면 depth만큼 재귀적으로 함수를 반복한 결과를 반환합니다. 생각보다 단순합니다.

여기에서 나머지 인자 predicate, isStrict는 사용하지 않는데, 설명만 읽고서는 어떤 역할인지 이해가 잘 안되네요.

한 권으로 배우는 Vue.js3 서평

Wed, 22 Sep 2021 18:47:00 GMT

구성

크게 보면 Vue.js에 대한 소개 -> Vue3 기초(Vue2와 비교) -> Vue3로 애플리케이션 개발 순입니다.

난이도

제 생각에는 Vue2를 이미 어느정도 알고 계신 분이라면 수월하게 읽을 수 있을 것이라는 생각이 들었습니다. Vue2를 아예 모른다면 이해하는데 시간이 좀 걸릴수도 있습니다.

좋았던 점

Vue3 기초개념 챕터에서 “Vue2에서 이렇게 표현되는 것들이 Vue3에는 이렇게 표현된다.”라는 비교 형식의 서술방식이 주였고, 다음 챕터부터는 Vue3 내용이 주입니다. 내용이 자세하기 때문에 Vue2를 이미 알고 있어도 Vue2에 대한 이해가 깊어지는 느낌이 들었고 Vue3에 대한 내용도 쉽게 이해됐습니다. 그리고 뒤에 Vue3를 이용해 애플리케이션을 만들어보면서 Vue3를 충분히 익힐 수 있었습니다.
아직 Vue3로 완전히 마이그레이션을 할수는 없지만 미래에 마이그레이션을 대비해 읽으면 도움이 될 책이라는 생각이 들었습니다.

[출판사로부터 도서를 제공받아 주관적으로 작성한 리뷰입니다]

Vue.js 화살표 함수(arrow function) 주의점

Wed, 31 Mar 2021 22:47:00 GMT

Vue.js의 data 및 lifcecycle hook(created, mounted…)에서 화살표 함수를 사용하면 어떻게 될까요?

this가 undefined라고 합니다. 왜 이런 일이 발생할까요?

공식문서에 설명이 나와 있습니다.

Vue instance는 몇가지의 초기화 과정을 거칩니다. created, mounted 등의 생명주기 훅들은 this context가 Vue instance를 가리키도록 설정되고 나서 실행됩니다. 화살표 함수를 option property나 callback (created, watch … ) 에서 실행하지 말아야 합니다. 화살표 함수는 this를 가지고 있지 않기 때문에 this는 다른 변수들처럼 부모 스코프까지 렉시컬하게 조회되어 Uncaught TypeError: Cannot read property of undefined 나 Uncaught TypeError: this.myMethod is not a function 같은 에러를 발생시킬 수 있습니다.

저는 여기서 Vue가 this context를 어떻게 Vue instance에 바인딩하는지 궁금해졌습니다. Vue core 코드를 뜯어보았습니다.

initMixin을 따라가봅니다.

initState가 data를 초기화하는 부분같습니다. initState를 따라갑니다.

data가 있으면 initData를 호출합니다. 따라들어갑니다.

data가 함수타입이면 getData를 실행합니다. 따라들어갑니다.

드디어 찾고있던 마지막 종착지입니다. data.call(vm,vm)을 return합니다.

lifecycle hook의 경우에는 어떨까요? init.js에서 callHook(vm, 'created')를 따라갑니다.

invokeWithErrorHandling에 vm을 넘겨주고 있습니다.

똑같이 handler에게 context를 바인딩하면서 실행합니다.

예제를 만들어서 일반 함수와 화살표 함수의 동작원리를 비교해봤습니다. (Node.js 환경)

첫번째 예제에서는 this가 전부 전역 객체를 가리킵니다. ({})

두번째 예제에서는 생성자 함수로 객체를 만들어 바인딩해봤습니다. 화살표 함수의 경우 this context가 vm을 가리키지 못합니다.

call method의 첫번째 인자는 this, 두번째 인자부터는 함수의 매개변수로 값들이 전달됩니다. 화살표 함수도 vm을 잘 전달받습니다.

결론적으로, data에서 this를 사용하는 경우 화살표 함수를 쓰고 싶다면 vm을 인수로 넘겨줘야 하는데 굳이 이렇게까지 해서 화살표 함수를 쓰는 이점이 있을까? 라는 생각이 듭니다.

긴 글 읽어주셔서 감사합니다. 피드백은 언제나 환영입니다!

Django framework로 간단한 api 만들기

Sun, 07 Mar 2021 22:31:00 GMT

본 포스트는 인프런의 플러터와 장고로 1시간만에 퀴즈 앱/서버 만들기 [무작정 풀스택] 강의를 듣고 내용을 정리한 것입니다. 퀴즈 모델에 관한 api를 만들어봅니다.

먼저 가상환경을 설정합니다.

가상환경을 설정하는 명령어는 다음과 같습니다.

// 가상환경 설정
python3 -m venv venv(본인의 가상환경 이름)
// 가상환경 활성화
source venv/bin/activate

그리고 Django project를 cli로 생성합니다.

// 프로젝트 생성 (.을 꼭 적어야함)
django-admin startproject myapi .
python manage.py startapp quiz

settings.py 파일을 수정합니다.

// 모든 호스트 허용
ALLOWED_HOSTS ['*']
// 타임존 변경
TIME_ZONE = 'Asia/Seoul'
// 스태틱 파일 경로 추가
STATIC_ROOT = os.path.join(BASE_DIR, 'staticfiles')
// INSTALLED_APPS에 'quiz', 'rest_framework' 추가

INSTALLED_APP

migration을 합니다.

// migration 파일 생성
python manage.py makemigrations
// migration 진행
python manage.py migrate
// 서버 구동
python manage.py runserver

여기까지 하면 기본적인 서버를 만들었습니다.

다음으로 Model을 생성하겠습니다.

// quiz/models.py
from django.db import models

# Create your models here.
class Quiz(models.Model):
    title = models.CharField(max_length=200)
    body = models.TextField()
    answer = models.IntegerField()

Serializer 생성

// serializers.py
from rest_framework import serializers
from .models import Quiz

class QuizSerializer(serializers.ModelSerializer):
    class Meta:
        model = Quiz
        fields = ('title', 'body', 'answer')

Model과 Serializer를 만들었으니, 이제는 실제로 api를 만들어봅니다.

api 생성

view

// quiz/views.py
from rest_framework.response import Response
from rest_framework.decorators import api_view
from .models import Quiz
from .serializers import QuizSerializer
import random
# Create your views here.
@api_view(['GET'])
def randomQuiz(request, id):
    totalQuizs = Quiz.objects.all()
    // sample의 두번째 인자는 length
    randomQuizs = random.sample(list(totalQuizs), id)
    // serializer에 many=True를 주면, 다수의 데이터도 직렬화해줍니다.
    serializer = QuizSerializer(randomQuizs, many=True)
    return Response(serializer.data)

이제 api를 url에 연결하면 됩니다.

myapi내의 urls.py는 전체 app에 대한 url을 관리하고, quiz/urls.py는 quiz app에 대한 url만 관리합니다.

// quiz/urls.py
from django.urls import path, include
from .views import randomQuiz

urlpatterns = [
    path("<int:id>/", randomQuiz)
]

// myapi/urls.py
from django.contrib import admin
from django.urls import path, include

urlpatterns = [
    path('admin/', admin.site.urls),
    path('quiz/', include('quiz.urls')),
]

django에서 동적 url 작성법

api 개발을 완료했습니다. 이제 model data를 생성하기 위해 admin을 등록해봅니다.

// quiz/admin.py
from django.contrib import admin
from .models import Quiz

# Register your models here.
admin.site.register(Quiz)

model이 변경되었기 떄문에 migration을 한번 더 진행합니다.

이제 admin에 접속할 수 있는 슈퍼계정을 만듭니다.

python manage.py createsuperuser

서버를 구동해봅니다.

python manage.py runserver

어드민에 접속해서 Model을 만들어봅니다.

Model data를 4개 이상 만들고 “/quiz/3”을 호출해봅니다.

api가 잘 작동하는 것을 확인할 수 있습니다!

이렇게 django framework로 model 생성 및 api를 만들어보았습니다. 코드를 따라치다가 원리가 궁금해서 내용을 정리해보았습니다. 다음에는 flutter app부분도 내용을 정리할까 합니다.

내용 정리

돌아가기

가상환경이란

가상환경은 해당 프로젝트의 Python 개발환경을 구축하기 위해 모듈을 독립적으로 관리하는 환경입니다. 가상환경을 설정하는 이유는 각 모듈이 다른 모듈에 의존성을 가지고 있기 때문에 이것저것 설치하다가 충돌이 날 수 있기 때문입니다.

돌아가기

INSTALLED_APPS란

참고
INSTALLED_APPS는 Django와 함께 딸려오는 다음의 앱들 등을 포함합니다.

django.contrib.admin - 관리용 사이트
django.contrib.auth - 인증 시스템

그외 앱들 …

Django 인스턴스에서 활성화된 모든 Django application들의 이름을 담고 있습니다.

돌아가기

migration이란

참고
Django framework는 기본적으로 SQLite를 사용하도록 구성되어 있습니다. migrate 명령어를 실행하면 INSTALLED_APPS를 참고해 필요한 데이터베이스 테이블을 생성합니다.

돌아가기

Model field reference

참고

CharField
- class CharField(max_length=None, **options)
- small to large string field
- 대량의 텍스트는 TextField를 사용할 것
- max_length는 required argument
TextField
- class TextField(**options)
- large textfield
InterField
- class IntegerField(**options)
- An integer

돌아가기

Serializer란

참고
쿼리셋, 모델 인스턴스 등의 복잡한 데이터를 JSON, XML 등의 컨텐츠 타입으로 쉽게 변환시켜주는 역할. 여기서는 Django의 모델 데이터를 JSON 타입으로 바꿔주는(직렬화) 코드(클래스)

ModelSerializer

이 class는 Serializer class와 같지만 다음 차이점이 있습니다.

model을 기반으로 field를 자동생성합니다.
validator를 자동생성합니다.
간단한 .create(), .update() 메서드를 기본적으로 가지고 있습니다.

따라서, 간단하게 Serializer를 만들 때 사용됩니다.

돌아가기

view란

참고
프론트엔드 개발자로서 view란 view template을 의미하는 줄 알았지만, Django에서의 view function은 Web request를 받고 Web response를 return하는 역할을 합니다. express framework의 route와 유사하다는 생각이 들었습니다.

돌아가기

django에서 동적 url 작성법

str - ’/‘를 제외한 비어있지 않은 문자열
int - 0이상의 정수
slug - 아스키 문자나 숫자, 하이픈, 언더스코어 등으로 이루어진 slug string
- ex. building-your-1st-django-site
uuid - UUID
path - ’/‘를 포함한 비어있지 않은 문자열
- str은 부분 URL path
- path는 완전한 URL path

오픈소스를 번역할 때 유용한 Git Localize 사용법

Sat, 02 Jan 2021 00:48:00 GMT

등록하기

Git Localize는 Git Repository의 내용 번역을 쉽게 도와주는 사이트입니다. Git Localize

로그인을 해서 Add Repository를 누르면 번역할 대상을 등록할 수 있습니다.

다음으로 번역할 Repository를 고르는데, 접근 권한 설정이 되어 있어야 보이겠죠? Repository를 고른 뒤에는, 대상 Branch를 작성합니다. 저는 번역용 Branch를 따로 생성해서 PR을 생성할 것이기 때문에 제가 새로 만든 Branch이름을 적었습니다.

default branch는 master인데, master를 main으로 바꾸신 분들은 main을 적어주세요!

Project Paths 항목에서는 Repository 안에서 번역할 대상을 지정할 수 있습니다. Directory로 설정하면 해당 Directory에 있는 모든 파일이 대상이 되며, File을 선택하면 특정 File만 선택할 수 있습니다.

%lang%이라는 placeholder는 번역 세팅에 따라 target language로 자동 변환됩니다. 예를 들어서, target language를 ko로 설정한다면 Microsoft-Web-Dev-For-Beginners에 있는 파일들을 번역하면 Microsoft-Web-Dev-For-Beginners/ko에 저장됩니다.

저는 모든 파일들을 번역할 것이 아니라 특정 파일들만 번역할 예정이라 File로 Path들을 추가해나갔습니다. %lang% 부분이 target language로 자동 변환된다고 했죠? 제가 설정한걸 예로 들어보면 assignment.md 파일을 번역하면 ./translations/assignment.ko.md파일로 저장된다고 볼 수 있습니다!

그 다음엔 Project languages 설정입니다. 제가 이 글을 쓰게 된 이유이기도 합니다. ko라고 검색하면 두개가 나오는데 [ko-KR]을 선택하고 제출하면, 계속 로딩만 되고 아무것도 안됩니다. 위에 있는 [ko]를 선택하셔야 합니다. 그리고 나서 Submit 버튼을 누르시면 정상적으로 등록됩니다. 😎 파일이 많을수록 로딩이 오래 걸리니 조금만 기다려주시면 됩니다. 준비가 되면 이메일로 알려줍니다.

등록이 되면 리스트에 등록한 결과가 나오며, 여러가지 메뉴가 나옵니다. Overview 메뉴에서는 번역 상태를 볼수 있고 번역 언어도 관리할 수 있습니다.

Team 메뉴에서는 함께 작업할 유저들을 초대하고 관리할 수 있습니다.

Settings 메뉴에서는 Project Paths를 수정할 수 있으며 Sync Repository, Repository 제거 등을 할 수 있습니다.

Badge 메뉴에서는 프로젝트의 README.md에 추가할 수 있는 귀여운 배지를 제공해주네요!

번역하기

번역하려는 파일을 클릭하면 다음과 같은 화면이 나옵니다.

여기서 각각의 블럭들을 segment라고 부릅니다. 원본 segment랑 번역본 segment랑 일대일로 link되어 있습니다.

ex) Reading the Docs - 문서 읽기

Git Localize는 Machine Translate과 Pretranslate from TM 기능을 제공합니다.

Machine Translate은 말그대로 번역을 자동으로 한번 해주는 기능입니다. 버튼을 클릭하면, 기계가 번역할 수 있는 부분만큼 번역해줍니다. 번역이 막막할 때 큰 도움이 되는 기능입니다.

Pretranslate from TM은 suggestion을 바탕으로 번역을 해주는 기능입니다. 여기서 suggestion은 이전에 다른 파일들을 번역했던 기록을 가지고 제안해주는 기능입니다. 밑에 Suggestions에서 그 기록들을 확인할 수 있습니다. 이 기능을 사용하면 협업할 때, 다른 작업자들이 해당 단어를 어떻게 번역했는지 찾아보지 않아도 파악할 수 있어서 굉장히 좋습니다. 최초에 빨갛게 나오는 부분은 눌러보면 왼쪽의 원본이랑 링크되지 않는 segment라고 나오는데 왜 두개씩 나오는지는 아직 파악하지 못했습니다. 같은 것이 두개씩 나온거라서 저는 빨간색 부분은 삭제했습니다.

segment를 클릭하면 내용을 수정할 수 있습니다.

리뷰하기

번역을 완료하면 Create Review Request 버튼을 눌러서 리뷰를 요청할 수 있습니다.

코멘트를 남기고 제출하면 리뷰 요청 목록에서 확인할 수 있습니다.

파일 이름을 눌러서 들어가보면 Approve할 수 있도록 체크박스가 나옵니다. 현재 Approve all 체크박스를 눌러서 Approve한 경우 승인 상황이 저장되지 않는 버그가 있습니다. report를 넣어야겠네요!😎 체크박스를 하나하나씩 일일이 눌러야 저장이 되네요. 확인해보려면 approve후에 다른 페이지에 갔다가 다시 이 페이지로 돌아와보시면 됩니다.

이렇게 나와야 잘 저장된 거겠죠?

해당 요청에 코멘트도 남길 수 있고, 리뷰를 마치고 Send Pull Request 기능을 활용해서 기존 저장소에 merge를 하면 번역이 끝나겠네요.

Translated Texts 메뉴를 이용하면 그 자리에서 번역 요약정보를 확인할 수 있습니다.

이렇게 Git Localize에 등록하는 부분부터 번역, 리뷰하는 방법까지 알아봤습니다. 이번에 처음 써보면서 몇몇 버그도 발견했는데 잘 정리해서 Git Localize측에 알려주고 싶고, 좋은 도구를 찾은 거 같아 기분이 굉장히 좋습니다 :) 영어가 어려워서 번역을 망설이시는 분들도 Git Localize와 함께 다시 시작해보셨으면 하는 바램입니다.

스타트업 주니어 개발자의 2020년 연말회고

Thu, 31 Dec 2020 16:13:00 GMT

연말회고 두둥등장! (요즘에 머쉬베놈에 빠져있음)

스타트업에서 개발자로 일한다는 것

올해초에 서울로 올라와서 취준을 하다가 운이 좋게 3월말이라는 빠른 타이밍에 지금의 회사에 합류해서 지금까지 개발자로 일하고 있다. 나와 내 대학동기들이 지겹게 겪었던 정보격차 문제, 관심 분야의 실제 직무를 체험하기 힘든 문제를 해결하는 회사이다. 수평적인 환경에서 독자적인 개인으로서 성장할 수 있는 환경도 마음에 들었다.

우리 회사는 데이터에 기반하여 의사결정을 한다. 그리고 끊임없이 실험한다. 처음에는 이 말이 잘 와닿지 않았는데 계속 일을 하다보니 피부로 와닿았다. 제품을 개선하거나 수정할 때 “이게 더 이쁘다.”, “이게 더 나아보인다.” 라는 추상적인 생각은 근거가 되지 않는다. “이 부분을 이렇게 바꾸면 제품의 어떤 면이 더 좋아져서 어떤 퍼널로의 전환율이 증가할 것이다.” 라는 가설을 세우고 A/B 테스트를 진행한다. 해당 url로 들어오는 유저들에게 A안 또는 B안을 보여주고 유저들의 행동을 분석한다. 실험이 끝나면 실험 결과를 분석하고 문서화해서 의사결정에 사용한다. 이렇게 유저들을 학습한다.

수평적인 문화를 바탕으로 구성원 누구나 눈치를 보지않고 목소리를 낼 수 있다. 그 목소리들이 누군가가 놓치고 있는 것을 캐치해줄 수 있었고, 누군가에게 발상의 전환점이 될 수 있었다.

대표님(사내에선 대표님이라고 안부름)이 중요하게 생각하시는 결정하는 연습을 계속하고 있다. 업무의 우선순위, 예상마감일 등을 스스로 결정하면서 자신의 업무를 관리한다. 그 과정속에서 독자적인 개인으로 성장하고 있다고 느낀다.

프론트엔드 팀내에서 나의 역할

기술적으로 괴롭히기

나의 팀내 주 역할은 기술적으로 괴롭히기라고 생각한다. 코드를 보다가 개선할만한 지점이 있거나 새로 적용해볼만한 기술들이 있으면 정리해서 프론트엔드 스크럼 때 공유했다. 다른 분들도 많이 공유를 해주셨다. 공유를 하면 잘 귀기울여주시고, 각자 생각하는 의견을 말씀해주셔서 피드백도 자유롭게 이루어졌다. 그런 팀원들이 정말 고맙고 같이 일을 할 수 있어서 고맙게 생각하고 있다.

프론트엔드팀 Datadog 관리자(?)

어쩌다보니 프론트엔드팀에서 Datadog 매니저님과 커뮤니케이션 하는 사람이 내가 되었다. 프론트엔드 팀에서 사용하고 있는 서비스의 요금도 내가 모니터링하고 관리하고 있다. 내가 Datadog에 가장 관심이 많아서였는지 Datadog이라는 미지의 세계를 가장 먼저 개척하고, 사용법을 요약해 팀내에 공유한적이 있다.

기억에 남는 활동들

Junction X Seoul 2020 해커톤

작년에 같이했던 팀원 한명이랑 회사 동료들 3명과 함께 참여했다. 포지션은 기획1, 디자인1, 프론트엔드3(?)이었다. serverless framework + lambda로 해커톤 규모의 백엔드 정도는 구현할 수 있을 거 같아서 내가 백엔드를 자처했다. 그렇게 나는 프론트엔드 + 가성비 백엔드(팀원피셜) 역할을 맡았다. 가성비 백엔드라는 별명이 매우 마음에 들었다. 🤣 작년에는 내 구현능력이 많이 부족했고, 핵심을 파악하지 못했어서 많이 아쉬운 부분이 있었다. 그래서 이번에는 코어 기능의 완전한 구현을 목표로 삼았다.

기획단계부터 개발단계까지 순조롭게 진행됐다. 작년에 참여했던 경험도 도움이 됐고 많이 비교가 됐다. 사이드 프로젝트가 아닌 해커톤이라는 걸 명심하고 주제와 서비스 타겟을 기준으로 아이디어들을 필터링했으며, 코어 기능을 중심으로 세부기능들을 가지치기 해나갔다. 그 결과 코어 기능을 만족스럽게 구현했고 발표자료도 잘 만들었다. 그리고 운이 좋게 해당 트랙에서 2등상을 수상할 수 있었다. 🎉

내 친구가 연말회고 때 인용했던 말이 있다. "최고의 복지는 동료다." 이 때 나는 해커톤에 나가자고 하면 기쁜 마음으로 승낙해주는 동료들이 있다는 것이 참 고마웠다.

오픈소스 컨트리뷰톤

작년에는 여유가 없어서 참여하지 못했던 컨트리뷰톤이었다. 올해 컨트리뷰톤 신청 당시에는 회사 업무가 널널해서 충분히 소화할 수 있을 것이라고 생각했는데 거짓말처럼 컨트리뷰톤 활동 시작시점부터 회사 업무가 많아져서 컨트리뷰톤에 시간을 많이 쓰지 못했다. 처음 2주간은 회의에 참여하는 것이 활동의 전부였다. 회의에 참여해도 무슨 내용인지 이해하기 힘들었고 잘 따라가는 다른 멘티분들이 대단해보이고 부러웠다. 스트레스를 많이 받아서 포기할까 하는 생각도 들었다. 내 목표는 PR 최소 1개 작성 이었는데, 뭐라도 해보자는 생각으로 프로젝트 코드를 쭉 읽어보면서 오타를 찾아냈다. 이렇게 많은 사람들이 유지보수하는 프로젝트에는 오타가 별로 없을 줄 알았는데 5개나 찾았다. 생각보다 많아서 놀랐다.

Fixing typos by donghoon-song · Pull Request #4404 · mochajs/mocha

원래 오픈소스 입문은 오타찾기나 번역이라고 했다 😎 이렇게 PR을 올리고 merge가 되니까 뭐라도 했다는 뿌듯함과 자신감이 생겼다. 최소한의 목표를 이뤘던 나는 그 후로 오기가 생겨서 뭐라도 한개만 더 해보자라는 마음가짐으로 task를 찾게 되었다.

Fix: Broken wallaby logo on mochajs.org #4430 by donghoon-song · Pull Request #4431 · mochajs/mocha

위의 PR을 올리면서 디버깅하는 실력이 많이 늘었다. 패키지들을 타고 타고 들어가다보니까 이슈를 해결할 수 있었다.

Add support for node v8 option ‘prof’ parameter (#4433) by donghoon-song · Pull Request #4439 · mochajs/mocha

Update eslint version by donghoon-song · Pull Request #4443 · mochajs/mocha

이슈 해결과정을 정리해서 블로그 글로 남겨보기도 했다.

초보 컨트리뷰터의 Mocha issue 해결 도전기

중도 포기하는 분들도 계셨지만 열심히 참여하다보니 어느새 활동을 마무리할 수 있었고 상도 받을 수 있었다. 컨트리뷰톤을 통해 오픈소스를 바라보는 관점이 달라졌다. 활동전에는 미지의 영역이고, 어렵게만 보이던 것들이 어느정도 눈에 들어오기 시작했으며 다른 기여활동으로 이어지기도 했다. 조금이나마 성장했다는 확신을 할 수 있는 계기가 되었다. 그리고 추후에 사내 컴포넌트 패키지를 관리하는데도 큰 도움이 되었다.

[OpenSource] 초보 컨트리뷰터의 Nuxt docs PR 도전기

Figma - agit webhook 연동

디자이너 분들과 협업을 하다가 개발했다. 개발자는 아무래도 피그마(디자인툴)를 자주 보지는 않기 때문에 디자인 변경사항을 실시간으로 체크할 수 없다. 또한 디자이너분들이 어떤 것을 요청했을 때, 작업이 됐는지, 확인은 했는지 여부가 불투명하여 커뮤니케이션 비용이 발생한다.

그래서 디자이너님들이 특정 조건으로 메시지를 남기면 아지트(협업툴)에 프론트 개발자를 담당자로 해서 글이 남겨지도록 만들었다. 나는 메시지에 [개발팀] 이라는 텍스트가 포함되면 발동하도록 조건을 걸어놨다.(아주 간단) 그러면 개발자는 피그마를 계속 확인하지 않아도 꼭 필요한 메시지를 비동기적으로 받을 수 있다. 피그마에서는 디자이너분들끼리의 코멘트와, 개발자에게 보내는 메시지가 분리된다. 또한, 아지트에서 각 코멘트에 대한 업무 진행 상황을 투명하게 체크할 수 있다.

정말 간단한 로직과 기능임에도 불구하고 팀원들은 아주 잘써주고 있고, 생산성도 많이 향상되었다. 이렇게 팀원들의 생산성 향상에 기여했다.

프론트엔드와 백엔드의 코드 분리

기존 레거시 시스템은 laravel framework 위에서 blade template engine으로 vue파일을 렌더링하는 구조이다. 이렇게 laravel에 의존적인 구조여서 프론트엔드의 자유도가 낮았다. routing을 백엔드에서 주로 담당해서 vue store를 제대로 활용할 수 없었고 뭔가를 수정할 때 백엔드 개발자의 도움이 필요한 경우도 많았다. 또한 사용하려고 하는 패키지 중에 잘 호환되지 않는 패키지들도 있었다.

그래서 오랜시간 PS(Problem Solving)세션과 회의를 거쳐 점진적으로 코드를 분리하기로 결정했다. 새로운 프로젝트에서는 Nuxt framework를 사용하기로 했다. SEO가 필요한 페이지에서 SSR을 부분적으로 적용할 수 있다는 점이 가장 큰 장점이었다.

Design System 개발

Component package 개발 link

코멘토에서 쓰이는 Component들을 디자이너들과 함께 Design System화하는 중이다.
양도 많고 복병들이 있어 난이도도 높았지만 하고 싶었던 업무이고, 완성하고 난 뒤 얻을 수 있는 생산성, 재사용성을 생각하며 즐겁게 만들고 있다.
모든 작업은 개별 branch에서 이루어지며 develop branch로의 모든 merge는 PR을 통해 이루어지며 최소한 한명의 리뷰어가 리뷰를 남겨야하고, CI test를 모두 통과해야 merge할 수 있다.

프론트팀은 디자이너팀의 동의를 받아 패키지를 공개하기로 결정했다. 이 결정을 하기까지는 많은 고민이 있었다. 공개 하는 것도 버전1이 만들어지면 공개할지, 미완성상태에서 공개할지도 고민을 많이 했다. 아무래도 주니어들끼리 작업하다보니 서투른 부분도 있고 비효율적인 로직도 있어 공개하기 부끄러운 마음도 있었다.

하지만 그걸 무릅쓰고 공개를 하는 이유는 그 반대의 사고과정을 거쳐 찾았다. 지나가다 볼 누군가가 피드백을 주면 그걸 자양분삼아 더 발전시킬 수 있을 것이라는 생각을 했고, 아직 완성되지는 않았지만 완성해 가는 과정, 개선해나가는 과정을 공개적으로 진행하는 것도 누군가에게는 자극, 누군가에게는 도움이 될 수 있을 것이라고 생각했다.

CI

chromatic 도입
- visual test tool
- chromatic을 이용하면 storybook을 빌드할 때마다 해당 버전과 비교할 base 버전과의 UI상의, code상의 차이를 보여준다. 구성원들이 차이를 비교하면서 변경 사항을 approve해야 리뷰가 통과된다.
  
  [Storybook] Storybook visual test with Chromatic
- PR을 올리거나 올린 상태에서 변경사항이 생기면 chromatic github action이 동작한다.
- slack에 연동하여 빌드될때마다 메시지가 오고, 결과물을 바로 확인 및 리뷰할 수 있게 했다. 리뷰가 완료되면 완료 메시지도 보내준다. 팀원들이 PR을 확인하기까지의 시간이 대폭 감소하였으며, 자신의 PR이 리뷰됐는지도 빠르게 확인할 수 있어 좋았다.
build test 도입
- 정말 간단하게 github action을 통해 build를 해보는 test이다.
- 처음에는 이런게 필요할지 몰랐지만 작업을 하다보니 필요성을 느껴서 만들었다.
- 당연히 되어야 할 것도 테스트 해야한다. 는 마음가짐이 이때 생겼다.
- 코드 상에서 실수를 해서 빌드가 안되거나, merge를 했는데 lint에서 통과를 못해서 빌드가 안되는 경우를 방지할 수 있었다.

CD

shipjs 도입
- 오픈소스 라이브러리를 배포하는 것은 간단하지 않았다.
- 버저닝, npm에 배포, 태그 생성, changelog 작성 등의 일련의 과정들로 이루어졌다.
- 이 과정들을 항상 수동으로 하기에는 실수도 많이 나고, 리소스가 많이 들겠다고 생각했다.
- 마침 JSConf Korea 2020에서 이은재님께서 shipjs라는 라이브러리를 소개해주셔서 사용중이다.
  
  JSConf Korea 2020 - 발표자 | 이은재
- 사용하다가 변수명 오타를 발견해서 기여를 한건 덤이다!
  
  fix: typo in GitHubAction config by donghoon-song · Pull Request #928 · algolia/shipjs
- 나의 작은 발자취를 남길 수 있었다. 😎
storybook deployer 도입
- storybook deployer라는 툴을 이용해 공식 버전의 스토리북을 배포한다.
- 이것도 배포할 때 자동으로 실행될 수 있도록 github-action에 등록해두었다.
- 현재는 github pages에서 호스팅하고 있다. link

TODOS

번들러 변경
- Rollup을 통해 Single File Component 형식으로 필요한 컴포넌트만 import해서 사용하는 구조로 패키지화하려고 하였으나 밑바닥부터 새로 세팅하는 과정에서 에러들을 발견했고, 시간이 오래 걸려서 잠시 보류해두었다. 내년에 해결해보려고 한다.
- 현재는 vue-cli-service의 build 명령어를 사용해서 패키지화하고 있다.
패키지 경량화
- 현재 패키지 파일이 굉장히 크다. 아직은 세팅에 미숙해서 최적화 및 경량화 하는 방법을 적용하지 못했고, 차차 공부하면서 적용해볼 생각이다. (웹팩 주니어이다. 🐣)
단위 테스트 코드 작성
- jest를 이용해 단위 테스크 코드를 모두 작성하고 개발과정에 넣고 싶었다.
- 하지만 구현해야 할 컴포넌트의 양이 너무 많아서 보류 중이다.
- 내년에는 열심히 테스트를 작성해서 CI과정에 넣고 싶다.

Datadog

개발팀에서 Datadog을 도입했다. 프론트엔드의 경우 모니터링할 툴이 없었는데 Datadog의 도입으로 여러가지 지표 확인, 로깅, 테스팅, 유저 분석, 알람 등이 가능해졌다. 서비스가 커져감에 따라 이 기능들의 필요성은 더욱 증가할 것이라고 생각했고 정말 중요하게 생각했다.

처음 체험기간을 거치고 나서, 팀장님이 꼭 필요한 기능이 아니면 구독을 해지하는 가지치기를 하려고 하셨다. 처음 그말을 듣고 겸사겸사 쓰면 안될까? 하는 생각이 들었는데 시간이 지나고보니 팀장님의 뜻을 이해할 수 있었다. 모든 것은 비용이다. 굳이 필요로 하지 않는 서비스를 이용하는데 돈을 낼 필요는 전혀 없으며 우리가 꼭 사용해야 할 서비스는 누가 들어도 설득될만한 이유를 바탕으로 하고 있어야 함을 말이다.

솔직히 그 이유를 작성하기가 꽤 어려웠다. 아직 Datadog의 기능들에 익숙해지지 않아 기본적인 사용법 정도밖에 숙지를 못했다. 하지만 최대한 설득해보려고 노력했다. 설득하는 과정도 성장의 과정이라고 생각했다. 또한, 지금뿐만이 아니라 장기적인 관점에서 꼭 필요하다고 생각했다.

연말회고를 하는 지금 시점에서 돌이켜보면 굉장히 잘한 선택이라고 생각한다. 현재는 데이터독을 그때보다 더 잘 활용하고 있다. Front End단에서 기본 로그말고도 custom logger를 개발해 특정 이벤트 모니터링에 활용하며, 이슈 해결용에도 쓰고 있다. 모니터링을 하지 않을 땐 발견하기 쉽지 않았던 이슈들도 발견해서 고칠 수 있었고 로그를 활용하는 것도 점점 익숙해졌다. 핵심 활용 사례들을 노션에 정리해서 계속 쌓아가고 있다.

마법이 마법이 아니게 되는 순간

어떤 유명한 개발자분이 기초가 부족하면 그 기술이 마법처럼 보인다. 라고 말씀하셨다. 내가 초반에 겪었던 현상이었다. 하지만 시간이 지날수록 어떤 패키지나 프레임워크의 코드를 뜯어보는 경우가 생기면서 신기했던 마법들이 마법이 아니게 되는 순간들이 찾아왔다. 결국엔 모두 기초를 기반으로 한 코드 덩어리들이라는 생각이 들었다. 아직은 많이 부족하지만 조금씩 성장해감을 느낄 수 있었다. 물론 그 코드들을 보고 한번에 이해할 수는 없어 여러번 읽어야 겨우 이해할 수 있는 상태지만 이해할 수 있는 근육을 키우고 싶다.

2021년에는

2021년에는 업무에 더 능숙해지고 싶고, 그만큼의 여유를 만들고 싶다. 그 여유를 가지고 생각만 하고 못해봤던 것들을 해보고 싶다. 2020년에 기술도입이 많았다. 많은만큼 아직 깊이가 쌓이지 않았다. 그 기술들과 기초지식들의 깊이를 쌓고 싶다. 그래서 남들에게 설명할 수 있을 때까지, 질문을 해도 답해줄 수 있을 때까지 익히고 싶다.

[serverless] serverless로 AWS Lambda 배포 시 memory, timeout 설정하기

Wed, 02 Dec 2020 22:23:00 GMT

이미지에서 dominant color를 추출하는 AWS Lambda 함수를 Serverless Framework로 배포하여 사용하고 있습니다. 이미지가 클 때 에러가 나는 경우가 있었는데, 너무 오래 걸려서 나는 timeout 이슈였습니다. 동료 개발자분이 Lambda함수의 memory와 timeout설정을 바꿔야겠다고 얘기해주셨습니다.

Lambda함수를 serverless로 배포하면 memorySize의 기본값은 1024, timeout은 6초라고 합니다. 이 설정은 aws console에서 확인할 수 있는데, Lambda -> 함수 -> 함수 상세 화면 -> 기본 설정에서 아래와 같이 볼 수 있고 편집도 할 수 있습니다.

aws console에서 설정을 편집할 수 있지만, 새롭게 배포할 때는 serverless.yml에 명시된 설정값으로 배포가 되기 때문에 편집값이 초기화됩니다. 그래서 serverless.yml에 사용할 값을 명시해 주는 것이 좋습니다.

provider 항목의 memorySize, timeout을 변경해주시면 쉽게 적용할 수 있습니다.

참고

serverless.yml aws guide

[Node.js] Node.js 15 변경점 번역

Sun, 15 Nov 2020 16:25:00 GMT

주요 변경점

AbortController
N-API Version 7
npm 7
Throw on unhandled rejections
QUIC (experimental)
V8 8.6

AbortController

AbortController의 구현체를 실험적으로 포함합니다. AbortController는 하나 이상의 웹 요청을 필요할 때 중단시키는 인터페이스입니다. 자세한 설명은 아래의 링크를 참고하시면 됩니다.

AbortController

const ac = new AbortController();
ac.signal.addEventListener('abort', () => console.log('Aborted!'),{ once: true });
ac.abort();
console.log(ac.signal.aborted);  // Prints True

위의 예제에서, ac.abort()가 호출될 때, AbortController가 abort event를 trigger합니다.

AbortSignal에 달린 Eventlistener는 반드시 { once: true } 옵션을 주거나 EventEmitter의 once() 메서드를 호출해 abort 이벤트를 한번만 핸들링하고 사라지도록 해야합니다.

N-API 7

우리는 새로운 N-API 버전을 다른 LTS Node.js 버전에도 백포트하여 사용합니다. N-API 7은 가장 최신 메이저 릴리즈 이후 새 버전이고, ArrayBuffers를 다루는 추가 메서드들을 포함합니다.

백포트(backport) : 최신 버전의 소프트웨어 시스템 또는 소프트웨어 구성 요소에서 부품을 가져 와서 동일한 소프트웨어의 이전 버전으로 포팅하는 작업

npm 7

Node.js 15는 npm 7을 사용합니다. Npm 7에는 다양한 새로운 기능들이 추가되었습니다.

npm workspace
새로운 package-lock.json 포맷
yarn.lock 지원
Peer dependency들이 기본적으로 설치됩니다!

Presenting v7.0.0 of the npm CLI - The GitHub Blog

Throw on unhandled rejections

Node.js 15에서는 unhandledRejection에 대한 기본 mode가 warn에서 throw로 바뀝니다. throw mode에서는, unhandledRejection hook이 설정되어 있지 않으면, unhandledRejection는 uncaught exception으로 잡힙니다. unhandledRejection hook을 설정한 사용자들은 그대로 사용하면 됩니다. -unhandled-rejections=mode 라는 process flag를 사용하여 mode를 변경하는 것이 여전히 가능합니다.

Node.js는 UnhandledPromiseRejectionWarning는 많은 버전에서 emit해왔는데, Node.js User Insights: Unhandled Promise Rejections 설문조사와, Node.js Technical Steering Committee vote 의 결과를 바탕으로 mode를 throw로 변경하는 결정을 내렸습니다.

QUIC(experimental)

QUIC는 새로운 UDP 기반 transport protocol이며, HTTP/3의 기반이 됩니다. QUIC는 TLS 3.1, 흐름 제어, 오류 수정, 연결 마이그레이션 및 멀티플렉싱을 통한 내장된 보안 기능을 제공합니다.

Node.js 15는 QUIC을 실험적으로 제공하고 있으며, --experimental-quic 라는 configuration flag를 통해 Node.js를 컴파일하면 사용할 수 있습니다. Node.js QUIC 구현체는 core net 모듈에서 expose 됩니다.

const { createQuicSocket } = require(‘net’);

QUIC에 대한 더 자세한 설명은 Node.js 문서를 참고하시면 됩니다.

V8 8.6

V8 자바스크립트 엔진이 V8 8.6으로 업데이트되었습니다. (V8 8.4가 Node.js 14에서 사용가능한 가장 최신버전이었습니다.) 성능 개선과 함께 V8 업데이트는 아래의 language feature를 포함합니다.

Promise.any() — MDN (from V8 8.5)
AggregateError — MDN (from V8 8.5)
String.prototype.replaceAll()MDN (from V8 8.5)
Logical assignment operators &&=, ||=, and ??= — MDN (from V8 8.5)

출처

[Storybook] Vue Storybook addon-docs 사용해서 docs 만들기

Thu, 01 Oct 2020 23:00:00 GMT

storybookjs/design-system repository

Storybook example

위의 멋진 Storybook example을 보고, 멋진 docs page를 제 프로젝트에도 추가하고 싶었습니다.

@storybook/addon-docs

addon-docs는 스토리북에서 docs를 만드는 것을 도와줍니다. docs를 만드는데에는 크게 두가지 방식이 있습니다.

DocsPage
- 스토리의 정보를 기반으로 자동으로 docs를 만듭니다.
- stories, text descriptions, docgen comments, props tables, code examples 등을 참고하여 페이지로 만들어줍니다.
MDX
- markdown 문법으로 docs를 작성합니다.
- 자동은 아니지만, 작성자 마음대로 커스터마이징이 가능합니다.

@storybook/addon-docs installation

yarn add -D @storybook/addon-docs

다음의 peer dependency를 가집니다. vue를 쓰지만 react를 설치해야 하는…

yarn add -D react react-is babel-loader

설치를 다 하고 난 후에 main.js에 다음을 추가해줍니다.

// .storybook/main.js
module.exports = {
  stories: ['../src/**/*.stories.@(js|mdx)'],
  addons: ['@storybook/addon-docs'],
};

그리고 나서 preview.js에 다음 코드를 추가하면, 모든 story에 대해 자동으로 DocsPage가 생성됩니다. 아래 코드를 지워도 기본적으로 Docs가 자동으로 생성됩니다.

// .storybook/preview.js
import { addParameters } from '@storybook/vue';
import { DocsPage, DocsContainer } from '@storybook/addon-docs/blocks';
 
addParameters({
  docs: {
    container: DocsContainer,
    page: DocsPage,
  },
});

스토리를 기반으로, Docs 페이지가 생성되었습니다. 스토리에 정보가 별로 없어서, Docs에 들어가는 내용도 별로 없습니다. 저는 MDX를 이용해 저만의 docs를 작성하고 싶었습니다.

MDX Docs

MDX로 Docs를 만든 것을 적용하려면, 아래와 같이 코드를 작성하여, Docs 자동생성 기능을 꺼줘야 합니다.

// .storybook/preview.js
import { addParameters } from '@storybook/vue';

addParameters({ docs: { page: null } });

// Button.stories.mdx
import { Meta, Story, Props } from '@storybook/addon-docs/blocks';
import Button from '@/src/Components/Button/Button';

<Meta title='Button' component={Button}/>

# Button

**Button** 컴포넌트의 문서입니다.

<Story name='docs' height='100px'>
  {{
    components:{ Button },
    template: '<Button>Button</Button>',
  }}
</Story>

우리가 새로 만든 docs로 대체되었습니다!

@storybook/addon-controls

addon-controls는 사용자가 스토리북에서 직접 컴포넌트의 arguments를 바꿔볼 수 있도록 도와줍니다. 저는 단순 props table이 아니라 이 기능을 원했기 때문에 추가해주었습니다.

yarn add -D @storybook/addon-controls

// ./storybook/main.js
module.exports = {
  addons: ['@storybook/addon-controls'],
};

Doc Blocks

Storybook의 document page를 작성할 때 쓰입니다. 여기서 ArgsTable을 사용해볼 것입니다.

Doc Blocks

ArgsTable

Storybook docs는 컴포넌트의 args table을 자동으로 만듭니다. controls와 연동하여 사용자가 컴포넌트의 args를 직접 수정해볼 수 있습니다.

Button Component의 ArgsTable을 만들어봅시다. addon-controls 없이 만들면 아래와 같이 나옵니다.

// Button.stories.mdx
import { ArgsTable } from '@storybook/addon-docs/blocks';
import Button from '@/src/Components/Button/Button';

<Meta title='Button' component={Button}/>

<ArgsTable of={Button} />

addon-controls 를 설치하고 만들면 아래와 같이 나옵니다. Control 열이 더 생겨서, 사용자가 직접 수정할 수 있게끔 도와줍니다. 이것은 Button 컴포넌트의 props를 읽어서 자동생성되었습니다.

// Button.vue
props: {
	size: {
		type: String,
		default: 'medium',
		validator(value) {
			return ['small', 'medium', 'large', 'xlarge'].indexOf(value) !== -1;
		},
	},
	color: {
		type: String,
		default: 'primary',
		validator(value) {
			return ['primary', 'success', 'gray'].indexOf(value) !== -1;
		},
	},
	type: {
		type: String,
		default: 'fill',
		validator(value) {
			return ['fill', 'outlined', 'text'].indexOf(value) !== -1;
		},
	},
	full: {
		type: Boolean,
		default: false,
	},
	// disabled
	disabled: {
		type: Boolean,
		default: false,
	},
},

size, color, type의 경우, String type이긴 하지만 사용할 수 있는 값들의 종류가 미리 정해져 있습니다. 그러면 굳이 text로 안바꾸고, select로 바꿀 수 있다면 스토리북을 사용할 때 편할 것입니다. 이걸 override하려면 따로 설정을 해줘야 합니다.

Meta에 argTypes를 작성하여, Template에 넘겨줍니다. 아래 ArgTypes 문서를 보면 어떻게 작성해야 할지 감이 오고, 이것저것 해보다보면 원하는 형태의 문서를 작성할 수 있습니다.

ArgTypes

controls 작성법

두 문서를 바탕으로 작성한 문서입니다.

// Button.stories.mdx
import { ArgsTable, Meta, Story, Props } from '@storybook/addon-docs/blocks';
import Button from '@/src/Components/Button/Button';

<Meta title='Button' component={Button} argTypes={{
  label: {
    description: '버튼에 들어갈 텍스트',
    defaultValue: '답변 추가하기',
    control: {type: 'text'},
     table: {
      type: { 
          summary: null,
      },
    },
  },
  size: {
    description: '버튼의 크기<br/>`String`',
     table: {
      type: { 
          summary: '목록', 
          detail: '"small" "medium" "large" "xlarge"' 
      },
    },
    control: {
      type: 'select',
      options: ['small', 'medium', 'large', 'xlarge']
    }
  },
  color: {
    description: '버튼의 색상 타입<br/>`String`',
    table: {
      type: { 
        summary: '목록',  
        detail: '"primary" "success" "gray"'
      },
    },
    control: {
      type: 'select',
      options: ['primary', 'success', 'gray']
    }
  },
  type: {
    description: '버튼의 타입<br/>`String`',
    table: {
      type: { 
        summary: '목록',  
        detail: '"fill" "outlined" "text"'
      },
    },
    control: {
      type: 'select',
      options: ['fill', 'outlined', 'text']
    }
  },
  full: {
    description: '버튼의 너비가 부모컴포넌트의 100%를 차지할지<br/>`Boolean`',
    table: {
      type: { 
        summary: null,  
      },
    },
  },
  disabled: {
    description: '버튼의 disabled 상태<br/>`Boolean`',
    table: {
      type: { 
        summary: null,  
      },
    },
  },
  }}
/>

export const Template = (args, { argTypes }) => ({
  props: Object.keys(argTypes),
  components: { Button },
  template: '<Button :size="size" :color="color" :type="type" :full="full" :disabled="disabled">{{label}}</Button>',
});

# Button

**Button** 컴포넌트의 문서입니다.

<Story name='docs' height='100px'>
	{Template.bind({})}
</Story>

<ArgsTable story="docs" />

해당 작업까지 완료되었다면 제가 원했던 원하는 docs를 만드실 수 있습니다. 아래 ArgsTable에서 arguments를 마음대로 수정하여 컴포넌트의 상태를 변경할 수 있습니다.

[Storybook] Storybook visual test with Chromatic

Sat, 12 Sep 2020 00:11:00 GMT

하라는 컴포넌트화는 안하고 테스팅만 찾아보는 당신은 대체…

Storybook Tutorial에서 제시하는 테스트는 크게 세가지가 있다.

Visual tests : 직접 보고 의도대로 모양이 나왔는지 체크하는 방법
Snapshot tests : Storybook이 렌더된 markup의 snapshot을 찍어서 비교한다.
Unit tests : Jest를 사용해 같은 인풋에 대해 같은 아웃풋이 나오는지 체크한다.

하지만 앞서 언급했던 방법들은 UI bug를 감지하기 힘들다. UI bug는 경우에 따라 굉장히 미미한 차이일 수도 있기 때문에, Visual tests는 너무 수동이고, Snapshot tests는 UI에 적용했을 때 너무 많은 false positive(실제론 false인데 positive라고 나오는)를 발생시키며, pixel-level unit tests는 의미가 없다. 그래서 Storybook은 visual regression tests를 제안한다.

Visual regression testing for Storybook

Visual regression tests는 렌더링된 모양의 차이를 잡아내도록 디자인되었다. 모든 스토리의 스크린샷을 찍어서, 커밋별 변화점을 잡아낸다. 많은 visual regression testing 도구가 있지만, Storybook에선 클라우드에서 테스트를 할 수 있는 Chromatic을 제안한다!

Setup visual regression testing

Bring git up to date

먼저 storybook project의 git 저장소가 있어야 합니다! 기존에 만들었으면 상관없겠죠?

Get Chromatic

chromatic을 설치해줍니다.

yarn add -D chromatic

chromatic에서 git으로 로그인을 하고, repository를 추가합니다.

Chromatic

그러면 project-token을 받을 수 있고, 해당 명령어를 실행해 deploy합니다.

npx chromatic --project-token=<project-token>

package.json에 build-storybook이 없다고 한다면?

"scripts": {
	"build-storybook": "build-storybook"
},

그러고 나서 chromatic에 들어가면 정상적으로 배포된 것을 볼 수 있습니다.

진짜 chromatic의 기능은 여기부터 시작입니다. 아무 변화나 주고 다시 배포를 해봅시다. 저는 버튼의 background-color를 파랑에서 빨강으로 바꿔봤습니다. 그럼 다음처럼 변경점이 감지되었음을 보여줍니다. Review changes 버튼을 클릭해서 들어가봅시다.

다음 처럼 UI 변경점을 보여줍니다. 바뀐 지점이 연두색으로 덮혀있습니다. DOM에서도 바뀐게 감지되었죠.

이렇게 배포할 때마다 UI의 변경점을 감지하고, 둘 중에 하나를 선택해서 적용할 수 있습니다. 내가 작업한 결과물이 기존것과 잘 매치되는지, 잘 변경되는지 등을 손쉽게 테스트할 수 있어 정말 유용한 서비스 같습니다.

Manage

PR을 보냈을 때에도 똑같이 테스트를 해 볼 수 있네요! 정말 유용합니다.

브라우저별 테스트를 제공합니다. 제일 말썽인 IE가 포함되어 있네요. IE를 누르면 다음 가격 정책이 뜹니다.

그렇다면 가격 정책에 대해서 알아봅시다! 그만 알아봅시다 ㅠㅠ 너무 비싸네요. 그런데 Free인 5000 snapshots도 다 못 채울 것 같습니다.

[OpenSource] 초보 컨트리뷰터의 Nuxt docs PR 도전기

Wed, 09 Sep 2020 22:26:00 GMT

Nuxt docs가 크롬에서 깨지는 현상

chrome에서 https://nuxtjs.org/ 를 열면 다음 이미지처럼 보이는 현상이 있었습니다.

개발자 도구로 살펴보니, svg라는 클래스에 width: 20px style이 전역으로 적용되고 있었습니다.

오픈소스 컨트리뷰톤에서 활동중이던 차에 직접 PR을 올려볼까? 하는 생각이 스쳤습니다. 그래서 다짜고짜 nuxtjs.org repo를 fork했습니다. dev 모드에선 해당 이슈가 없었는데 prod 모드에서 이슈가 재현되었고, svg class가 어디에서 오는건지 찾아봤습니다. 찾아보니, AppModal.vue이라는 컴포넌트에 있었습니다. 여기서 주목할만한 점은 style이 전역으로 적용되고 있었다는 점입니다. 정확한 빌드과정은 모르겠지만, 스타일이 전역으로 적용되면서 html 태그안에 class로 들어간 것 같았습니다. 그래서 svg class가 다른데에서도 쓰이나 전체검색을 해봤는데, AppModal.vue에서 밖에 쓰이지 않았습니다. (여기서 저는 마음속으로 소리를 질렀습니다.) style에 scoped 속성을 주고 빌드를 해보니 html 태그에서 svg class가 빠지는 것을 확인할 수 있었습니다.

./components/global/bases/AppModal.vue

...
<style>
.svg {
  width: 20px;
  color: black;
}
...

그렇게 PR을 올릴까 하다가 혹시 몰라서 디렉토리 안의 다른 파일들도 살펴보았는데, BaseAlert.vue 컴포넌트도 똑같이 scoped 적용이 되어있지 않았습니다. 이것을 바탕으로 다음 PR을 작성했습니다.

https://github.com/nuxt/nuxtjs.org/pull/639

PR template이 따로 없어서, 어떤 현상인지, 어떻게 고쳤는지, 제 생각을 작성했습니다.
maintainer가 이슈를 재현할 순 없지만, 위의 스타일들이 scoped되어야 하는 것은 동의한다고 merge 해주셨습니다.

Vue에서 style에 scoped속성을 적절히 사용하는 것은 Vue의 기본 중 기본입니다. 이런 기본 개념으로 이슈를 해결할 수 있어서 뜻깊었고 기여가 항상 거창해야 하는 것은 아니라는 것을 느꼈습니다. 또한 제가 자주 사용하는 프로젝트에 기여할 수 있어서 좋았습니다.

[OpenSource] 초보 컨트리뷰터의 Mocha issue 해결 도전기

Sun, 06 Sep 2020 18:19:00 GMT

저는 현재 오픈소스 컨트리뷰톤 Mocha팀에서 멘티로 활동하고 있습니다. Mocha의 #4433 이슈를 해결하면서 배운 점들을 적어봤습니다. 최대한 raw하게, 혼잣말 하듯이 의식의 흐름대로 작성해보았습니다. 양해부탁드립니다 :) 저처럼 오픈소스에 대한 경험이 많이 없고, 두려운 초보자들에게 큰 도움이 되었으면 합니다.

Mocha does not pass “—prof” parameter to Node and thus does not allow for profiling (#4433)

Mocha does not pass “—prof” parameter to Node and thus does not allow for profiling · Issue #4433 · mochajs/mocha

mocha에서 Node의 —prof argument를 넘겨줬는데 Node가 처리하지 못하는 이슈이다.

멘토님께서 lib/cli/node-flags.js를 참고하라고 해주셨다. 링크를 열어보면, node에서 기본적으로 제공하는 flag의 목록이 보인다.

Node.js v14.9.0 Documentation

./lib/cli/node-flags.js

'use strict';

/**
 * Some settings and code related to Mocha's handling of Node.js/V8 flags.
 * @private
 * @module
 */

const nodeFlags = process.allowedNodeEnvironmentFlags;
const {isMochaFlag} = require('./run-option-metadata');

코드를 보면 process.allowedNodeEnvironmentFlags안에 node의 flag들이 들어있다. 그리고 ./lib/cli/run-option-metadata안에 mocha flag들이 들어있다. —-prof는 이 두 곳에 속해있지 않았다.

밑으로 내려가보면 다음 코드를 볼 수 있다. node와 v8 플래그를 여기서 따로 처리하는가보다. 이 목록에 —-prof가 빠져 있으니 추가하면 되지 않을까? 라는 생각이 먼저 들었다. 내가 해야하는 일은 --prof 플래그를 Node가 처리하도록 잘 넘겨주는 일이기 때문이다.

—-prof는 node --v8-options을 실행하면 나오는 옵션이기 때문이다. —es-staging도 여기서 찾을 수 있었다. command 창에서 보기 힘들면, 다음 글에서 찾아보면 쉽다.

The Node.js Runtime v8 options list

먼저, isNodeFlag가 어디서 쓰이는지 찾아보았다.

./lib/cli/node-flags.js

/**
 * Mocha has historical support for various `node` and V8 flags which might not
 * appear in `process.allowedNodeEnvironmentFlags`.
 * These include:
 *   - `--preserve-symlinks`
 *   - `--harmony-*`
 *   - `--gc-global`
 *   - `--trace-*`
 *   - `--es-staging`
 *   - `--use-strict`
 *   - `--v8-*` (but *not* `--v8-options`)
 * @summary Whether or not to pass a flag along to the `node` executable.
 * @param {string} flag - Flag to test
 * @param {boolean} [bareword=true] - If `false`, we expect `flag` to have one or two leading dashes.
 * @returns {boolean} If the flag is considered a "Node" flag.
 * @private
 */
exports.isNodeFlag = (flag, bareword = true) => {
  if (!bareword) {
    // check if the flag begins with dashes; if not, not a node flag.
    if (!/^--?/.test(flag)) {
      return false;
    }
    // strip the leading dashes to match against subsequent checks
    flag = flag.replace(/^--?/, '');
  }
  return (
    // check actual node flags from `process.allowedNodeEnvironmentFlags`,
    // then historical support for various V8 and non-`NODE_OPTIONS` flags
    // and also any V8 flags with `--v8-` prefix
    (!isMochaFlag(flag) && nodeFlags && nodeFlags.has(flag)) ||
    debugFlags.has(flag) ||
    /(?:preserve-symlinks(?:-main)?|harmony(?:[_-]|$)|(?:trace[_-].+$)|gc(?:[_-]global)?$|es[_-]staging$|use[_-]strict$|prof$|v8[_-](?!options).+?$)/.test(
      flag
    )
  );
};

다음 파일에서 isNodeFlag를 찾을 수 있었고, isNodeFlag가 true이면 nodeArgs에 붙여주는 형식이었다.

./lib/cli/options.js

/**
 * Wrapper around `yargs-parser` which applies our settings
 * @param {string|string[]} args - Arguments to parse
 * @param {Object} defaultValues - Default values of mocharc.json
 * @param  {...Object} configObjects - `configObjects` for yargs-parser
 * @private
 * @ignore
 */
const parse = (args = [], defaultValues = {}, ...configObjects) => {
  // save node-specific args for special handling.
  // 1. when these args have a "=" they should be considered to have values
  // 2. if they don't, they just boolean flags
  // 3. to avoid explicitly defining the set of them, we tell yargs-parser they
  //    are ALL boolean flags.
  // 4. we can then reapply the values after yargs-parser is done.
  const nodeArgs = (Array.isArray(args) ? args : args.split(' ')).reduce(
    (acc, arg) => {
      const pair = arg.split('=');
      let flag = pair[0];
			console.log('isNodeFlag : ', isNodeFlag(flag, false));
      if (isNodeFlag(flag, false)) {
        flag = flag.replace(/^--?/, '');
        return arg.includes('=')
          ? acc.concat([[flag, pair[1]]])
          : acc.concat([[flag, true]]);
      }
      return acc;
    },
    []
  );

  const result = yargsParser.detailed(args, {
    configuration,
    configObjects,
    default: defaultValues,
    coerce: coerceOpts,
    narg: nargOpts,
    alias: aliases,
    string: types.string,
    array: types.array,
    number: types.number,
    boolean: types.boolean.concat(nodeArgs.map(pair => pair[0]))
  });
  if (result.error) {
    console.error(ansi.red(`Error: ${result.error.message}`));
    process.exit(1);
  }

  // reapply "=" arg values from above
  nodeArgs.forEach(([key, value]) => {
    result.argv[key] = value;
  });

  return result.argv;
};

아무 테스트 파일이나 실행시켜서, —-es-staging 옵션을 줄 때와 —-prof 옵션을 줄 때 결과가 똑같으면 될 것이라고 생각했다.

./bin/mocha ./test/only/bdd.spec.js --es-staging

console.log('isNodeFlag : ', isNodeFlag(flag, false));
[ [ 'es-staging', true ] ]

이 목록에 —-prof가 빠져있으니 추가해준다. —-prof는 mochaFlag, nodeFlag, debugFlag가 아니므로 네번째 or문에서 처리된다.

./lib/cli/node-flags.js

/**
 * Mocha has historical support for various `node` and V8 flags which might not
 * appear in `process.allowedNodeEnvironmentFlags`.
 * These include:
 *   - `--preserve-symlinks`
 *   - `--harmony-*`
 *   - `--gc-global`
 *   - `--trace-*`
 *   - `--es-staging`
 *   - `--use-strict`
 *   - '--prof'
 *   - `--v8-*` (but *not* `--v8-options`)
 * @summary Whether or not to pass a flag along to the `node` executable.
 * @param {string} flag - Flag to test
 * @param {boolean} [bareword=true] - If `false`, we expect `flag` to have one or two leading dashes.
 * @returns {boolean} If the flag is considered a "Node" flag.
 * @private
 */
exports.isNodeFlag = (flag, bareword = true) => {
  if (!bareword) {
    // check if the flag begins with dashes; if not, not a node flag.
    if (!/^--?/.test(flag)) {
      return false;
    }
    // strip the leading dashes to match against subsequent checks
    flag = flag.replace(/^--?/, '');
  }
  return (
    // check actual node flags from `process.allowedNodeEnvironmentFlags`,
    // then historical support for various V8 and non-`NODE_OPTIONS` flags
    // and also any V8 flags with `--v8-` prefix
    (!isMochaFlag(flag) && nodeFlags && nodeFlags.has(flag)) ||
    debugFlags.has(flag) ||
    /(?:preserve-symlinks(?:-main)?|harmony(?:[_-]|$)|(?:trace[_-].+$)|gc(?:[_-]global)?$|es[_-]staging$|use[_-]strict$|prof$|v8[_-](?!options).+?$)/.test(
      flag
    )
  );
};

실행결과 똑같은 결과가 나왔다.

./bin/mocha ./test/only/bdd.spec.js --prof

console.log('isNodeFlag : ', isNodeFlag(flag, false));
[ [ 'prof', true ] ]

동작을 잘하는지 더 확실히 하고자 찾아봤는데, profiling을 하면 log file이 아웃풋 결과로 나온다고 한다. 잘 나오고 있었다!

Easy profiling for Node.js Applications | Node.js

Since we ran our application using the —prof option, a tick file was generated in the same directory as your local run of the application. It should have the form isolate-0xnnnnnnnnnnnn-v8.log (where n is a digit).

profiling 아웃풋 파일들

추가적으로, 멘토님께서 ./test/node-unit/cli/node-flags-spec.js 파일에서 테스트도 작성하면 좋을 거 같다고 하셨다. 그래서 아래 테스트 구문까지 추가해서 pr을 작성했다 🙂

it('should return true for "prof" itself', function() {
  expect(isNodeFlag('prof'), 'to be true');
});

Add support for node v8 option ‘prof’ parameter (#4433) by Donghoon759 · Pull Request #4439 · mochajs/mocha

처음에는 되게 막막했는데, 코드를 따라가다보니 어디를 수정해야 될지 알 수 있었고, node flag를 주면 node가 처리하도록 넘기는구나, node에 profiling하는 옵션도 있구나 하는 새로운 내용도 배울 수 있어 좋았다. 정말 하면 할수록 알아가는 게 많았고, mocha 코드를 수정하는 pr은 처음이라 자신감도 붙었다!

[Husky] Git hook library Husky 사용

Sat, 22 Aug 2020 23:59:00 GMT

설치

npm install husky --save-dev

// package.json
{
  "husky": {
    "hooks": {
      "pre-commit": "npm test",
      "pre-push": "npm test",
      "...": "..."
    }
  }
}

vue-cli로 프로젝트를 만든 후에 lint를 설치하고 commit 전에 lint를 실행하도록 설정해보았습니다.

// package.json
{
 "scripts": {
   "serve": "vue-cli-service serve",
   "build": "vue-cli-service build",
   "lint": "vue-cli-service lint"
 },
  "husky": {
    "hooks": {
      "pre-commit": "npm run lint"
    }
  }
}

lint를 고치지 않은 채로 commit을 했더니, 예상대로 commit이 막혔습니다.

lint를 고치고 commit을 하니, 정상적으로 통과되었습니다!

Githook list Githook list안에 있는 hook들을 지원한다고 합니다. 저는 pre-commit과 pre-merge-commit hook에 lint를 적용시키고자 합니다. 실제로 작업할 때 merge하는 단계에서 코드가 꼬여버리는 걸 제때 찾지 못해서 이슈가 생기는 경우가 많았기 때문입니다.

참고문서

Husky repository

[Nuxt.js] Nuxt.js에서 global scss 설정

Tue, 28 Jul 2020 00:40:00 GMT

Nuxt.js에서 global scss 설정

Nuxt.js 프레임워크를 사용해 개발하려고 세팅중에 global scss 변수를 사용하고 싶었습니다. 자주 사용하는 변수들을 한데 모아놓고, 꺼내서 사용하려는데 잘 불러와지지 않아서 그 해결과정을 공유합니다.

// @/assets/style/base/color.scss
$primary : #00C850;

// Color.vue
<template>
	<div class="color">컬러</div>
</template>

<script>
export default {
	name: 'Color',
};
</script>

<style scoped lang="scss">
.color {
	background-color: $primary;
}
</style>

Nuxt를 실행하면, 에러가 뜹니다. 이를 해결하기 위해 module을 설치해야 합니다.

npm i --save-dev @nuxtjs/style-resources
yarn add -dev @nuxtjs/style-resources

그리고 나서 nuxt.config.js에서 세팅해줍니다. module.exports 안에 다음 속성을 추가해줍니다.

styleResources: {
		scss: ['@/assets/style/base/color.scss'],
  },
modules: [@nuxtjs/style-resources'],

그러면, styleResources안에 들어있는 scss 파일들이 전역으로 적용됩니다!

[Storybook] Storybook + 전역 scss 설정

Tue, 28 Jul 2020 00:08:00 GMT

Storybook에서 전역 scss파일 불러오기

Storybook을 이용해 디자인 시스템을 만들기 위해 세팅하고 있었습니다.
주로 쓰일 색상 변수들을 color.scss에 모아두고, @assets/style/base 폴더에 넣어두고 쓰려고 했는데 그냥 불러와지진 않더라구요.

// @assets/style/base/color.scss
$primary: #00C850;

// Color.vue
<template>
	<div class="color">컬러</div>
</template>

<script>
export default {
	name: 'Color',
};
</script>

<style scoped lang="scss">
.color {
	background-color: $primary;
}
</style>

main.js는 다음과 같이 기본 scss 설정만 되어있었습니다.

// ./storybook/main.js
const path = require('path');

// Export a function. Accept the base config as the only param.
module.exports = {
    webpackFinal: async (config, { configType }) => {
        // `configType` has a value of 'DEVELOPMENT' or 'PRODUCTION'
        // You can change the configuration based on that.
        // 'PRODUCTION' is used when building the static version of storybook.

        // Make whatever fine-grained changes you need
        config.module.rules.push({
            test: /\.scss$/,
            use: ['style-loader', 'css-loader', 'sass-loader'],
            include: path.resolve(__dirname, '../'),
        });

        // Return the altered config
        return config;
    },
};

yarn run storybook

storybook을 실행하면 다음과 같은 에러가 뜹니다.

변수를 찾을 수 없답니다! 그래서 이 친구를 찾게 도와주는 세팅을 해야됩니다. 아까 봤던 ./storybook/main.js을 다음과 같이 수정합니다.

const path = require('path');

// Export a function. Accept the base config as the only param.
module.exports = {
    webpackFinal: async (config, { configType }) => {
        // `configType` has a value of 'DEVELOPMENT' or 'PRODUCTION'
        // You can change the configuration based on that.
        // 'PRODUCTION' is used when building the static version of storybook.

        // Make whatever fine-grained changes you need
        config.module.rules.push({
            test: /\.scss$/,
            use: ['style-loader', 'css-loader', {
                loader: 'sass-loader',
                options: {
                    additionalData: `
						@import "assets/style/base/color.scss";
					`
                }
            }],
            include: path.resolve(__dirname, '../'),
        });

        // Return the altered config
        return config;
    },
};

그러고나서 다시 Storybook을 실행하면, 정상적으로 작동합니다! vue파일이 scoped임에도 불구하고, 전역 scss 변수를 사용할 수 있으니, 정말 큰 메리트가 있다고 생각합니다! 이 설정을 적용하지 않는다면, vue파일마다 사용할 변수를 style태그안에 매번 작성해줘야 합니다.

https://webpack.js.org/loaders/sass-loader/#additionaldata
참고로 우리가 사용한 sass-loader의 options의 additionalData 속성은, sass/scss 파일을 entry file앞에 붙여준다고 합니다.

Github Notification (깃허브 알림)

Mon, 27 Apr 2020 21:32:13 GMT

Github Notification

깃허브에서 알림 기능을 활용하는 방법입니다!

Managing notifications from your inbox

기존에 알림 기능으로 사용하던 종모양 버튼을 누르면 알림을 관리할 수 있는 페이지로 이동합니다.

오른쪽 리스트에는 전체적인 알림들이 보입니다. 왼쪽 파란부분은 필터 기능으로, 속성값에 따라서 모아볼 수 있습니다. 필터의 설정버튼을 클릭하면 필터를 커스터마이징할 수 있습니다.

그림에서 제 KNUCafeMap이라는 repository에서 review-request를 필터링하는 커스텀 필터를 만들어보았습니다.

Name : KNUCafeMap review-requested
Filter inbox by... : repo:Donghoon759/KNUCafeMap reason:review-requested

커스텀 필터는 15개까지 등록할 수 있다고 합니다. 커스텀 필터는 필터 쿼리를 사용해 커스터마이징할 수 있으며, 쿼리의 종류는 다음과 페이지에서 확인할 수 있습니다. Supported queries for custom filters

repo:아이디/저장소이름 형식으로 작성하시면 됩니다 :)

필터 만드는게 익숙하지 않으시다면 검색창에서 마우스로 클릭하여 쿼리를 만들수도 있으니 너무 겁먹지 마세요.

깃허브에서 받고 싶은 알림들만 받을 수 있어서 좋은 거 같습니다! 다양한 활용 케이스들이 공유되었으면 하네요

[Vue.js] 데이터 바인딩

Fri, 06 Mar 2020 21:34:00 GMT

데이터 바인딩

데이터 바인딩은 HTML 화면 요소를 뷰 인스턴스의 데이터와 연결하는 것

{{}} - 콧수염 괄호

뷰 인스턴스의 데이터를 HTML 태그에 연결하는 가장 기본적인 텍스트 삽입 방식, 템플릿 문법

data의 text 속성이 바뀌면 뷰 반응성에 의해 화면이 자동으로 갱신된다.

<div id="app">
  {{text}}
</div>

<script>
  new Vue({
    el: '#app',
    data: {
      text: 'Hello World!',
    },
  })
</script>

뷰 데이터가 변경되어도 값을 유지하고 싶다면 v-once 속성을 사용한다.

<div id="app" v-once>
  {{ text }}
</div>

v-bind

참고문서

Do it! Vue.js 입문
Vue.js 공식문서

[Vue.js] 컴포넌트 간 통신

Fri, 06 Mar 2020 20:51:00 GMT

뷰 컴포넌트 통신

컴포넌트로 화면을 구성하므로 같은 웹페이지라도 데이터를 공유할 수 없다.
컴포넌트마다 자체적으로 고유한 유효 범위를 가지기 때문

상하위 컴포넌트 관계

상위(부모) - 하위(자식) 컴포넌트 간의 데이터 전달
props로 데이터를 전달한다.
하위에서 상위로는 기본적으로 이벤트만 전달가능

상위에서 하위로 데이터 전달

Vue.component('child-component', {
    props: ['propsName],
});

child-component 컴포넌트 태그에 v-bind 속성을 추가한다.

<child-component v-bind:propsName="value"></child-component>

하위에서 상위로 이벤트 전달

이벤트 발생과 수신

이벤트를 발생시켜 (event emit) 상위 컴포넌트에 신호를 보낸다.

// 이벤트 발생
this.$emit('eventName')

// 이벤트 수신
<child-component v-on:eventName="상위 컴포넌트의 메서드명"></child-component>

관계 없는 컴포넌트간 통신 - 이벤트 버스

이벤트 버스는 개발자가 지정한 2개의 컴포넌트 간에 데이터를 주고받을 수 있는 방법

<div id="app">
  <child-component></child-component>
</div>

<script>
  var eventBus = new Vue()
  Vue.component('child-component', {
    template:
      '<div>하위 컴포넌트 영역.<button v-on:click="showLog">show</button></div>',
    methods: {
      showLog: function() {
        eventBus.$emit('triggerEventBus', 100)
      },
    },
  })

  var app = new Vue({
    el: '#app',
    created: function() {
      eventBus.$on('triggerEventBus', function(value) {
        console.log('이벤트를 전달받음. 값: ', value)
      })
    },
  })
</script>

보내는 컴포넌트에서는 . $emit()을, 받는 컴포넌트에서는 .$ on()을 구현한다.
애플리케이션 로직을 담는 인스턴스와 별개로 새 인스턴스 1개 더 생성한 후, 그것을 이용해 이벤트를 보내고 받는다.
컴포넌트가 많아지면 데이터의 from과 to를 관리하기 어렵다 => Vuex(상태 관리 도구) 사용

참고문서

Do it! Vue.js 입문
Vue.js 공식문서

[Vue.js] 라이프사이클

Fri, 06 Mar 2020 10:51:00 GMT

beforeCreate

인스턴스가 생성되고 나서 가장 처음으로 실행되는 라이프 사이클

data 속성과 methods 속성 접근 불가
돔에도 접근 불가

React.js의 constructor과 유사한 거 같습니다.

created

beforeCreate 단계 다음에 실행

data 속성과 methods 속성이 접근 가능
this.data 또는 this.fetchData()와 같은 로직들을 이용해 data 속성과 methods 속성에 정의된 값에 접근하여 로직 실행가능
돔 요소 접근 불가
Why? 인스턴스가 생성되었지만, 화면요소에 부착되기 전이므로
서버에 데이터를 요청해 받아오는 로직을 수행하기 좋다. (vuex에서 actions)
Why? data 속성과 methods 속성에 접근 가능한 가장 첫 라이프 사이클

options 속성이나 콜백에 화살표 함수 사용을 지양한다. 화살표 함수들은 부모 컨텍스트에 바인딩되기 때문에 this 컨텍스트가 Vue 인스턴스를 호출하지 못한다.

beforeMount

template 속성에 지정한 마크업 속성을 render() 함수로 변환한 후 el 속성에 지정한 화면 요소에 인스턴스를 부착하기 전 단계

render() 함수가 호출되기 직전의 로직을 추가하기 좋다.

React.js의 componentWillMount()와 유사한 거 같다.

mounted

el 속성에서 지정한 화면 요소에 인스턴스가 부착되고 나면 호출되는 단계

template 속성의 돔 요소에 접근 가능
돔에 인스턴스가 부착되자마자 바로 호출되므로 하위 컴포넌트나 외부 라이브러리에 의해 추가된 화면 요소들이 최종 HTML 코드로 변환되는 시점과 다를 수 있다.

beforeUpdate

인스턴스가 부착되고 나면 인스턴스에 정의한 속성들이 화면에 치환된다.

치환된 값은 뷰의 반응성(Reactivity)을 제공하기 위해 $watch 속성으로 감시한다.

관찰하고 있는 데이터가 변경되면 가상 돔으로 화면을 다시 그리기 전에 호출되는 단계
변경 예정인 새 데이터에 접근할 수 있어 변경 예정 데이터의 값과 관련된 로직을 넣을 수 있다.

React.js의 componentWillUpdate(nextProps, nextState)와 유사한 거 같다.

updated

데이터가 변경되고 나서 가상 돔으로 다시 화면을 그리고 나면 실행되는 단계

데이터 변경으로 인한 화면 요소 변경까지 완료된 시점
데이터 변경 후 화면 요소 제어와 관련된 로직을 추가하기 위해 좋음
데이터 값을 갱신하는 로직은 가급적 beforeUpdate에 추가하고, updated에서는 변경 데이터의 화면 요소와 관련되 로직을 추가하는 것이 좋다.

beforeDestroy

뷰 인스턴스가 파기되기 직전에 호출되는 단계

아직 인스턴스에 접근할 수 있다.
뷰 인스턴스의 데이터를 삭제하기 좋은 단계
ex) removeEventListener 호출

var app = new Vue({
  el: '#app',
  created() {
    document.body.addEventListener('click', funcion)
  },
  beforeDestroy() {
    document.body.removeEventListener('click', funcion)
  },
})

beforeDestoy 단계에서 이벤트를 해제시켜주지 않으면, document.body에는 계속해서 해당 event가 바인딩되어 실행된다.

destroyed

뷰 인스턴스가 파괴되고 나서 호출되는 단계

뷰 인스턴스에 정의한 모든 속성이 제거되고 하위에 선언한 인스턴스들 또한 모두 파괴

참고문서

Do it! Vue.js 입문
Vue의 Lifecycle
Vue.js 공식문서

about

Sun, 27 Jan 2019 16:21:13 GMT

Your name

Thank you for reading my resume. If you want to contact me, Please send me an email.

Your Site's RSS Feed

<에이전트 시대의 AI 시스템 설계> AI 실습 문제 생성은 프롬프트만 잘 쓰면 충분할까?

인사이트 1: 좋은 문제를 만들려면 좋은 맥락이 먼저 필요하다

인사이트 2: 금지 규칙도 시스템의 일부다

인사이트 3: 퀄리티 컨트롤은 생성 이후에 더 중요해진다

마무리

더 줄일 수 있는건 없을까? <미니멀리즘 프로그래머>

인사이트 1: 비동기적인 삶

인사이트 2: 회의도 “복잡함”을 줄일 수 있다

인사이트 3: 주석도 관리 대상이다

마무리

컨텍스트 엔지니어링으로 구축하는 AI 에이전트 리뷰 - 한빛미디어

“한빛미디어 서평단 <나는리뷰어다> 활동을 위해 도서를 제공받아 작성된 서평입니다.”

1. 강화형 컨텍스트 학습으로 ‘생성 후 보완’ 루프 만들기

2. re-writing과 컨텐츠 생성 컨텍스트를 분리하기

마무리

소프트웨어 아키텍처 The Basics(2판) 리뷰 - 한빛미디어

“한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다.”

시작하며

개발자와 아키텍트는 뭐가 다를까

아키텍트는 번역가다: 기술과 비즈니스 사이

모든 결정은 트레이드오프다

기술보다 중요한 것: 소프트 스킬

실용적인 조언들

마무리

GitKraken에서 AI로 merge conflict 쉽게 해결하기

GitKraken AI가 제안하는 해결책

정확도가 올라갔습니다

동료를 덜 부르게 됐습니다

결론

바이브코딩 너머 개발자 생존법(한빛미디어) 도서 리뷰

왜 이 책을 집었는가 – “AI를 잘 쓰고 있는 게 맞을까?”

이 책이 던진 핵심 메시지: “AI가 짠 코드는 끝이 아니라 시작이다.”

부트스트래퍼 마인드셋 – “가설 검증을 위해 빠르게 만들어보자”

실무에 적용해볼만한 점들

“AI가 개발자를 대체할까?”에서 “AI와 함께 어떻게 일할까?”로

밑바닥부터 시작하는 웹 브라우저(한빛미디어) 도서 리뷰

시작에 앞서

챕터별 내용 요약

PROLOGUE 브라우저와 나

PART 1 페이지 로딩

CHAPTER 1 웹페이지 다운로드

CHAPTER 2 화면에 그리기

CHAPTER 3 텍스트 포맷팅하기

PART 2 문서 표시

CHAPTER 4 문서 트리 구축하기

CHAPTER 5 페이지 레이아웃

CHAPTER 6 개발자 스타일 적용하기

CHAPTER 7 버튼과 링크 처리하기

PART 3 애플리케이션 실행

CHAPTER 8 서버로 정보 보내기

CHAPTER 9 대화형 스크립트 실행하기

CHAPTER 10 사용자 데이터 보호하기

PART 4 모던 브라우저 기능

CHAPTER 11 시각적 효과

CHAPTER 12 태스크와 스레드 스케줄링

CHAPTER 13 애니메이션과 컴포지팅

CHAPTER 14 콘텐츠 접근성 향상

CHAPTER 15 삽입된 콘텐츠 지원

CHAPTER 16 이전 결과 재사용

CHAPTER 17 이 책에서 다루지 않은 내용

EPILOGUE 변화하는 환경

입력에서 렌더링까지, 브라우저의 모든 여정

직접 만드는 브라우저 – 실습 중심 학습

커밋 메시지가 고민일 때 GitKraken이 대신 써줍니다

GitKraken AI가 제시한 새로운 해법

커스텀 지침 설정

핵심은 “작성”이 아닌 “검토”

유저 친화적인 GitKraken의 빠른 변화

타입스크립트(TypeScript)로 에러 핸들링하기

1. 에러의 종류: 예상된 비즈니스 에러 vs. 예상치 못한 에러

2. 전통적인 try...catch와 throw의 기본과 한계

unknown 타입 에러와 타입 좁히기

throw의 한계

3. 객체 지향적 접근: 커스텀 에러 클래스 활용

4. 함수형 접근: Result 타입 패턴

Result<T, E> 타입의 개념

엔지니어링 리더십 – 실력 있는 개발자에서 조직적 영향력자로 성장하기까지

엔지니어링 전략 수립: 실행 가능한 기술 방향을 설계하라

리더십 스타일 개발: 복제 가능한 리더가 되지 마라

2. 전통적인 `try...catch`와 `throw`의 기본과 한계

`unknown` 타입 에러와 타입 좁히기

`throw`의 한계

4. 함수형 접근: `Result` 타입 패턴

`Result<T, E>` 타입의 개념