UX 법칙은 정답이 아니라 관찰의 언어다

제품을 만들다 보면 이상한 순간을 자주 만난다.설명은 더했는데 이해는 느려지고, 선택지는 늘렸는데 결정은 어려워진다.사용자를 위했다고 생각하지만 결과는 반대다. 이런 순간에 UX 법칙은 정답을 주지 않는다. 단지 우리가 무엇을 놓쳤는지 볼 수 있는 이름을 준다. 왜 사용자는 설명을 읽지 않는 건가.왜 모든 것을 보여주었는데 중요한 것은 보지 못하는 건가.왜 거의 끝난 일은 마무리하고 싶어 지는 건가. 사람의 행동은 제각각이지만, 그 안에는 반복되는 패턴이 존재한다.Laws of UX는 그 패턴을 인터페이스를 만드는 사람이 사용할 수 있는 언어로 정리한다. 하지만 법칙을 안다는 것과 좋은 제품을 만드는 것은 다르다. 선택지를 줄인다고 언제나 좋은 것도 아니고, 버튼을 크게 만든다고 모든 문제가 해결되는 ..

일이 앞으로 나아가고 있다기보다, 앞으로 가는 척하고 있다는 느낌이 들 때가 있다.1년 전쯤만 해도 나는 그 차이를 잘 몰랐다. 기능은 계속 만들어졌고, 겉으로는 아무런 문제가 없어 보였다.팀이 적극적으로 AI를 사용하기 시작한 뒤로는 생산성도 더 높아진 듯했다.처음에는 분명 좋은 변화라고 생각했다. PD는 자신이 구상한 기능을 직접 만들기 시작했고, PO는 제품 정책과 기술적 제약을 더 빠르게 파악할 수 있었다.FE는 간단한 API를 설계했고, BE는 간단한 화면을 구현했다. 흔히 말하는 역할의 경계가 빠르게 흐려지고 있었다. 그 모습은 꽤 멋져 보였고, 동시에 조금 두렵기도 했다. 기획 초안은 금방 나왔다. 스펙은 빠르게 정리됐고, 화면의 문구도 몇 번의 프롬프트만으로 그럴듯해졌다.예전 같으면 여러 ..

최근, AI 활용 방식에 대해 팀 안팎으로 같은 이야기를 반복하고 있다."r"을 세도록 명령하지 말고, "r"을 세는 함수를 만들도록 하라 벌써 몇 년이나 흘렀지만, 이런 질문이 화제가 되었던 적이 있다."Strawberry"에는 "r"이 몇 개 있는가? 사람이 보기에는 분명한 답인데도, 당시의 AI는 엉뚱한 개수(2개)를 내놓았다.지금은 많은 모델이 정답(3개)을 맞히게 되었지만, 이 질문이 남기고 간 인사이트는 여전히 유효하다. AI에게 정답을 말하게 하지 말고, 정답을 계산하는 함수를 만들게하라. 왜 이 문장이 중요한가?1. LLM은 본질적으로 확률적 시스템이다.2. context-window와 출력 토큰의 한계가 존재한다.3. 따라서 “전부 찾아서 보고해”는 그럴듯 해 보이는 답을 줄 수 있어도 ..

AI와 본격적으로 함께한 지 벌써 1년이란 시간이 흘렀다.정확하게는 감독자로서, 지휘자로서, 조율자로서의 1년이 지나갔다. 지난 1년은 변화의 연속이었고, 가장 큰 변화는 업무 방식의 근본적인 전환이었다.80% 손코딩 → 80% 에이전트 코딩으로 이동했다.쌓여 있던 기술 부채는 "몇 번의 대화"만으로도 해소될 가능성을 보여주었다.Write First, Decide Later.일단 만들어보고 결정하는 접근이 가능해졌다. 이제 "작동하는 프로토타입"은 누구나 만들 수 있게 되었다.업무를 넘어 일상 전반에서도 AI를 활용하고 있지만, 솔직히 말하면 여전히 혼란스럽다. 모두가 다른 말을 한다Geek News에는 낙관과 비관이 끊임없이 교차한다.Reddit에는 바이브 코딩으로 만들어진 프로젝트가 쏟아지지만, 상당..

어딜 가나 AI 에이전트에 대한 이야기를 듣게 된다.사람 하나를 더 고용한 것처럼, 유능한 주니어 개발자를 옆에 앉혀 둔 것처럼 말한다. 그 말이 완전히 틀렸다고 하기도 어렵다. 분명히 빠르고, 생각보다 많은 일을 해내고 있다.AI 에이전트를 본격적으로 사용한 지도 벌써 수개월이 흘렀다. 유튜브 요약기 구조를 따라 만들어보는 것에서 시작해,AI 기반 서비스들이 제공하는 가치를 일부 직접 구현해보기도 했다.최근에는 tauri를 활용해 데스크톱에서 겪는 작은 불편을 해소하는 도구를 직접 만들어 사용하고 있다. 몇 번의 경험이 쌓일수록, 묘한 감정이 든다.누구나 쉽게 원하는 제품을 뚝딱 만들어 낼 수 있는 시대다. 이미 눈앞에 와있다. 그렇다면, 경쟁력은 어디서 오는가. 누구나 AI를 통해 빠르게 만들어낼 수..

크라잉넛의 공연과 함께한 카운트다운 판타지에서 2025년을 맞이했던 기억이 아직도 선명한데, 어느새 그 해가 저물어 간다.샴페인 풍덩 데킬라 원샷생맥주 마셔 인생 즐겨어차피 모든 게 잘 안될 거야다음에 잘하자 데킬라 원샷 좋아하는 밴드였기 때문이었을까, 아니면 노래의 가사 때문이었을까.2025년 한 해만큼은, 이왕이면 후회 없이 잘 보내보자고 마음먹었던 것 같다. 생각한 대로 모든 일이 이루어진다면 얼마나 좋을까.역시나, 세상일을 그렇게 호락호락하지 않다.돌이켜보면 올 한 해는 정말 다사다난했다. 어떤 순간에는 설명할 수 없는 상실이 갑작스럽게 찾아왔고,어떤 순간에는 당연하다고 믿었던 관계들이 조용히 끝나 있었다.말해야 했던 순간에는 침묵했고, 늦게 도착한 진심과 미련은 그 자리를 채우고 남아있다.시간이..

성장이라는 것을 오랜 시간 동안 오해했던 것 같다.더 많이 알고, 더 많이 쌓는 일이 곧 성장이라고 믿었다. 하지만 시간이 지나며 성장은 덜어내고 정리하는 능력에 가깝다는 것을 느낀다.무엇을 더할지가 아니라 무엇을 비워낼지, 무엇을 먼저 둘지, 무엇을 과감히 보내줄지가 성장을 가른다.무상 (無常)모든 것은 계속 변화하며, 고정된 상태로 머물지 않는다는 불교의 근본 교리세상은 끊임없이 바뀐다.관계도, 요구도, 우리가 일하는 환경도 끊임없이 흐른다. 모든 것은 서로 기대어있고, 혼자서는 완성되지 않는다.어느 한쪽으로 기울어진 극단은 쉽게 무너지기 마련이다. 일하는 태도 역시 흐름을 전제로 만들어야 한다.오면 만나고, 가면 헤어지고, 말 걸면 대답하면 된다.제품도 팀도 그렇다.중요한 것은 “붙잡기”보다 “흘려..

애초에 어떻게 설계했어야 했을까?복잡한 정책들이 얽혀있는 제품 관련 논의 중, 동료로부터 이런 질문이 나왔다.아무도 답을 모른다. 정답이 없는 질문이다.이렇게 제품 기능이 발전될 줄 누구도 몰랐고, 설계가 잘못되었다는 사실은 뒤늦게 천천히 찾아온다.현재 상태를 잘못된 설계라 판단하고, 새로운 설계로 바꾼다 하더라도 언젠가 또다시 “애초에 어떻게 설계했어야 했을까?”라며 말하고 있을지 모른다.잘못된 설계는 단순히 실패가 아니다. 과정에서 우리는 어떤 선택이 문제를 일으키는지 몸소 겪었고, 언젠가 비슷한 상황에서 이 방향으로 가게 된 가면 고려해야 할 것들과, 안 된다는 확실한 근거를 얻게 된다.만약 잘못된 설계를 한 번도 경험하지 않았다면,더 나은 구조에 대한 고민조차 할 수 없었을 것이다.실패는 없다...

드라이기를 하나 사는 데도 우리는 생각보다 많은 과정을 거친다.“드라이기가 필요해”라는 단순한 목적에서 시작해, “온라인에서 살까? 오프라인에서 살까?”, “쿠팡에서 찾아볼까?”, “어떤 브랜드가 좋지?”, “이 제품은 평이 괜찮네?”, “근데 가격은 좀…” 수많은 선택지를 탐색하고, 비교하고, 고민하다 결국 하나를 선택한다.이런 사고의 흐름은 단순히 소비에서 끝나지 않는다.우리의 사고는 대부분 이런 구조를 따른다.요구사항(목적): 어떤 필요나 문제 인식사고: 다양한 가능성 탐색과 브레인스토밍고려: 조건에 따라 비교와 판단결정: 최종 선택과거에는 이 모든 과정을 스스로 처리했지만, 이제는 AI가 그 일부를 도와준다. 예를 들어 “드라이기 추천해 줘”라고 말하면, AI는 브랜드, 성능, 가격 등 다양한 정..

사용자 중심 설계는 제품의 성공을 위해 반드시 필요하다. 하지만 때로는 사용자를 위한다는 마음이 오히려 제품을 망치는 결과를 초래하기도 한다.디자이너의 지나친 우려는 오히려 사용성을 떨어뜨리기도 하고, 개발과정에 복잡성을 추가하기도 한다.한마디로 "과잉친절"이다. 보다 효과적인 접근방법은 없을까?테슬러의 법칙과 복잡성의 본질사용자 경험(UX) 분야에는 유명한 법칙이 하나 있다. 바로 테슬러의 법칙(Tesler’s Law)이다.모든 시스템은 일정 수준 이상의 복잡성을 줄일 수 없으며, 줄인 복잡성은 어딘가로 이동될 뿐이다.제품 설계 과정에서 피할 수 없는 복잡성은 반드시 존재하며, 디자이너가 간소화하지 않은 복잡성은 고스란히 사용자의 몫이 된다는 것을 의미한다. 과잉친절은 복잡성을 제품에서 사용자에게로 떠..

AI를 실제 업무에서 활용하며 왠지모를 불안함을 느끼신 적이 있나요. AI에 기대는 것 같아서 불안해요.AI가 너무 잘하니까.., 내가 설 자리가 없어지는 느낌이에요.AI 자주 활용하다보니, 내 사고력이 퇴화되는 느낌이에요.좋은 질문을 하며, 적절히 활용하고 “나”의 판단으로 완성하는 것AI를 함께 일하는 동료라고 생각하면 조금 달라집니다.이것이 진짜 “AI 활용 능력”입니다. 지난 주말, 많은 시간을 Cursor와 Copilot이 지원하는 여러 모델들을 활용해 코드를 작성해보고, ChatGPT의 모델들과 대화하고 흐름을 분석하는 실험에 투자했습니다.이 과정을 통해, 프롬프트의 구조, 설계에 따라 AI의 반응이 완전하게 달라진다는 걸 체감합니다.'AI 아직 멀었네' 라고 생각했던 것이 파일럿의 문제였다는..

무언가를 만들어 나간다는 것은 단순한 창조 행위가 아니다.오히려 기존의 것들을 깊이 이해하고, 필요에 따라 조합하며, 점진적으로 발전시키는 과정에 가깝다. 메이커에게는 두 가지 상반된 사고방식이 필요하다.하나는 '해석'하는 능력이다. 이미 존재하는 것을 분석하고 의미를 파악하는 것.다른 하나는 '추론'하는 능력이다. 보이지 않는 것까지 예측하고 새로운 가능성을 탐색하는 것. 이 두 가지 사고방식이 어떻게 작용하는지, 영화 식스 센스(The Sixth Sense, 1999)를 통해 살펴보자.결말을 알고 사건을 해석하는 것 - 해석의 관점식스 센스를 처음 본 사람이라면, 영화의 결말에서 큰 충격을 받았을 것이다."말콤 박사는 처음부터 유령이었다!" 처음에는 눈치채지 못했던 사실이 밝혀지는 순간, 우리는 영화..

동료와의 1:1 미팅에서 예상치 못한 인정을 받았다.원래도 그랬지만, 최근 정책을 꼼꼼히 확인하고 리포트하시는 모습이 인상적이었습니다. 세심한 일처리로 내가 인정하고 있던 동료에게 같은 인정을 받으니 감회가 새로웠다.내가 어떻게 행동했는지, 그리고 어떤 사건이 나에게 변화를 가져왔는지 대화를 나누었다. 미팅이 끝난 후에도 여운이 오래 남았던 터라, 글을 작성하는 이 시점은 몇 개월의 시간이 지난 후임에도, 그때의 기억이 생생하다.1년, 2년 그리고 3년차에 접어들며 흐려졌던 나의 사고회로가 다시금 정리되는 느낌이었다. 입사한 지 얼마 되지 않았던 때가 떠오른다.제품을 바라보는 데 있어 다소 이상한 사고방식이 필요하다는 것을 깨달은 지 얼마 되지 않은 시점이었다. 이 글을 남기는 이유는 하나다.미래의 내가..

useRef는 언제 사용하나요?DOM 조작 및 접근: 특정 DOM 요소에 접근하거나 조작할 때 사용값의 변경 추적: 값이 변경되더라도 리렌더링되지 않는다는 특징을 활용, 값이 유지할 때 사용const ref = React.useRef(null);{children}; useRef를 통해 렌더링 이후 해당 DOM 노드를 참조하고, 컴포넌트가 언마운트될 때 다시 null로 설정됩니다.렌더링 이후 특정 DOM 요소에 접근하기: useEffect와 callback refuseEffect를 사용한 경우useEffect를 통해 렌더링 이후 특정 DOM 요소에 접근할 수 있습니다.const ref = React.useRef(null);React.useEffect(() => { if (ref.current) { ..

우리는 모두가 설계자이자 이해당사자입니다. 업무와 일상에서 끊임없이 문제를 해결하고 결정을 내리는 과정 속에서 우리는 설계자의 역할을 맡기도 하고, 때로는 다른 사람의 결정에 영향을 받는 이해당사자가 되기도 합니다. 설계자는 복잡한 문제를 풀어내며 더 나은 솔루션을 찾기 위해 노력하고, 이해당사자는 그 솔루션이 자신의 상황에 어떻게 영향을 미칠지 고민합니다. 하지만 이 둘의 경계는 생각보다 명확하지 않습니다. 설계자의 결정은 이해당사자에게 직간접적으로 영향을 미치고, 이해당사자의 피드백은 설계자의 다음 결정을 좌우합니다. 결국, 설계자와 이해당사자는 서로의 역할을 넘나들며 상호작용하고, 이러한 과정 속에서 갈등과 협력, 그리고 새로운 기회를 만들어 갑니다. 따라서 설계자와 이해당사자가 서로의 입장에서 공..

TypeScript의 꽃🌷이라 할 수 있는 타입추론(Type Inference)과 Generic Type의 부분 타입추론 문제에 대해 알아봅니다. 이 주제에 대해 관심이 생긴다면 꼭 끝까지 파헤쳐 개념을 이해하시길 바랍니다. 이 글은 타입스크립트를 활용해 보았으며, Generic Type에 대한 기본적인 이해가 있음을 바탕으로 합니다. TL;DR TypeScript Generic은 완벽하지 않습니다. 조금 더 자세히 말해보자면 Generic의 부분적인 추론은 완벽하지 않습니다. TypeScript는 모든 Generic에 대해서 추론해 낼 수 있지만, 부분적인 추론에 대해서는 지원하지 않습니다. (적어도 현재까지는) 부분 추론 타입이 제한되는 상황에서 Generic Function에 대해 정상적인 추론을 ..

개발과 비개발의 충돌: 논리와 현실의 간극우리가 해결해야 할 문제는 종종 논리적 가능성과 현실적 가능성의 중간지대에 놓여 있습니다. 특히 개발직군과 비개발직군 사이에서 더 극명하게 드러나곤 합니다. 개발직군은 제품의 안정성과 신뢰성을 유지하기 위해 엣지 케이스까지 고려하며 논리적 결함을 허용하지 않으려는 경향이 있습니다. 모든 가능한 상황을 예측하고 대비해야 한다는 압박 속에서, 개발자들은 논리적 완결성에 집중합니다. 반면, 비개발 직군은 현실적인 가능성, 즉 시장의 요구와 고객의 실제 사용 패턴과 상황에 더 큰 무게를 둡니다. 그들에게는 제품이 사용될 현실적인 환경과 고객의 경험이 더 중요한 요소로 작용합니다. 이런 관점 차이로 종종 개발직군이 중요시하는 논리적 접근을 비개발직군에게는 지나치게 복잡하거..

기존 코드가 복잡하고 이해하기 어려울수록(코드를 만드는 데 더 많은 투자가 이루어질수록) 코드를 유지해야 하는 압박감을 더 많이 느낀다. 여기서 매몰비용의 오류가 발생한다. 매몰비용의 오류? 미래에 발생할 한계 편익과 한계 비용을 비교하여 의사결정을 해야 함에도 불구하고 사람들이 과거에 지출된 매몰 비용을 고려함으로써 비합리적으로 선택하는 현상 성급한 추상화를 피하라 공유하는 코드를 통해 매개변수를 전달하고 조건부 경로를 추가하고 있다면 이미 추상화가 잘못된 것이다. 추상화가 잘못된 것으로 판단된다면 가장 좋은 전략은 다시 중복코드를 생산해 무엇이 옳은지 보는 것. 즉, 잘못된 추상화에 대처할 때 가장 빠른 방법은 되돌아가는 것이다. 이것은 후퇴가 아니라 더 나은 방향으로 나아가는 길이다. 중복된 부분을..

shadcn이 얼마전 vercel팀에 Design Engineer로 합류했다는 소식이 들려왔습니다. 앞으로도 오픈 소스 커뮤니티를 위한 커스터마이징 가능한 UI 컴포넌트를 계속 만들어낼 것이라고 하며, 근시일 내 놀라운 무언가를 출시할 것만 같습니다. 현재 회사에서 활용중인 antd의 커스터마이징 어려움을 느낀 직후 이 프로젝트를 보고(당시 이 프로젝트는 완전 초기) Design System을 구축하는데 있어서 괜찮은 선택이지 않을까 생각했었는데, 발전되는 모습을 지켜보고 있자니 그때보다는 조금 더 기울어진 것 같습니다. 역사와 함께 알아보는 흐름 shadcn/ui는 눈에 띄지 않는 이름에도 지난 몇 달 동안 인기를 끌었습니다. 주요 이유로는 스스로를 라이브러리라고 부르기를 거부하기 때문인데요, 모든 C..

interface를 써야한다. type을 써도 괜찮다. 이에 관한 의견 차이가 약간 있었고, 이에 타입 선언 규칙을 정리했다. 그래서 무엇을 쓰는게 좋은건가? 나는 사실 Declaration Merging이 필요한 경우를 제외하곤 Type alias만을 사용하는 쪽이긴 한데 깊게 들어가서 차이를 비교해보니, interface를 적절히 사용함으로써 개념적인 정리와 이해에 대한 장점이 있었고 (프로젝트마다 다르겠지만)성능적인 이점도 있는 것을 알게 되었다. 결론은.. "객체" 에 대해서 interface를 선호하고, Inheritance 관련한 부분 이외엔 type을 사용하는 쪽으로 정리했다. 😄 이 글은 그 정리에 대한 결과이다. Primitive types 💡 Primitive types을 사용할 때 t..

TypeScript의 Type은 어떻게 나누어지는가? 1. Static 정적 유형은 "컴파일 타임" 또는 "프로그램을 실행하지 않고" 이미 알고있는 유형을 의미 user-defined type(function, tuple, array, object ...), primitive type(string, number, boolean ...) 으로 세부 분류. 2. Generic Generic은 단일 데이터 형식이 아닌 다양한 데이터 형식으로 작업할 수 있는 구성 요소를 만드는 데 사용 3. Decorators 클래스 선언, 메서드, 속성, 접근자 및 매개변수에 첨부할 수 있는 특수한 데이터 유형 let any: any let number: number = 5 let never: never = any // ❌ ..

프로그램 언어의 다형성(多形性, polymorphism; 폴리모피즘)은 그 프로그래밍 언어의 자료형 체계의 성질을 나타내는 것으로, 프로그램 언어의 각 요소들(상수, 변수, 식, 오브젝트, 함수, 메서드 등)이 다양한 자료형(type)에 속하는 것이 허가되는 성질을 가리킨다. 출처 - 위키백과 다형성(컴퓨터 과학) 다형성(Polymorphism)은 프로그래밍 언어 이론에 깊이 뿌리를 둔 개념이며 다양한 종류가 있습니다. 이 글에서는 타입스크립트의 함수를 두 종류의 다형성으로 바라보고 생각합니다. 즉, 인수 타입에 따라 다르게 동작하는 함수(i.e. ad-hoc polymorphisms)와 다양한 수의 인수를 취하는 함수(i.e. parametric polymorphisms)입니다. Union type 만..

올해 서른, 내년도 서른이겠지만 지금까지의 신년 계획은 실패로 끝날게 뻔할 금연뿐이었지만 올해의 시작은 새로운 다짐과 마음가짐으로 시작하고 싶었다.하지만 많은 시간을 고민해보아도 미래의 모습이 잘 상상이 되지 않았고, 그렇게 제대로 그려지지 않은 미래에 대한 실현 의지도 생기지 생기지 않을 것 같았고, 한편으로는 나이를 들어감에 어떤 책임감과 압박감에 염려가 되기도 했다."풀을 베는 사람은 들판의 끝을 보지 않는다"프랑스 속담에 있는 말으로, 농부가 풀을 벨 때 들판의 끝을 보면 '이 넓은 들의 풀을 언제 다 베지?'라는 푸념과 함께 의욕을 잃는다는 것이다.이번 계획을 통해 의욕을 잃지 않고 즐거운 마음으로 풀을 베는데 집중하며,앞으로 다가올 낯선 시간을 보다 현명하게 이용할 수 있는 밑바탕이 되길 바라..

올해 6월 중순 새로이 시작한 사이드 프로젝트 팀원들과 서비스 오픈을 앞두고 1박 2일간의 나들이를 다녀왔다. (처음 계획을 전달받았을 때 서비스 오픈을 앞두고 1박 2일간의 해커톤인 줄 알고 굉장한 기대를 했다...) 결론부터 말하자면 오랜만에 MT와 같은 느낌으로 바람도 쐬고, 맛있는것도 먹으며, 좋은 시간을 보내며 리프레시할 수 있었다. 그리고 같은 프론트엔드 개발자 분과의 대화를 통해 다시 무언가를 깨닫게 된 의미 있는 시간이었다. 팀원분은 나와 마찬가지로 디자이너에서 전직한 1년차 프론트엔드 개발자이며, 현시점에서 각 분야의 일한 기간이 나와는 정확히 반대인 케이스다. 지난밤, 프로젝트 진행 간 어려운 부분이 있으시다며 다음날 카페에서 라이브 코딩으로 알려주실 수 있는지 물어보셨다. 거절할 이유..

Next.js의 개발 서버는 기본적으로 3000 포트에서 실행되도록 설정되어 있습니다. 개발 환경에 따라 다른 포트에서 개발 서버를 실행해야 경우가 종종 생기는데 이를 변경할 수 있는 방법을 알아봅시다. 1. 직접 변경하기 // package.json { ... "scripts": { "dev": "next dev -p 3005", "build": "next build", "start": "next start" } ... } -p 옵션을 통해 뒤에 입력된 포트로 개발 서버가 실행됩니다. 2. 환경변수 사용하기 // package.json { ... "scripts": { "dev": "next dev -p ${PORT-3000}", "build": "next build", "start": "next st..

* 이 프로젝트는 기본적으로 TypeScript를 써 보았고, 내장된 유틸리티 타입들과 Generic 등을 알고 있는 상태에서 진행하는 것을 추천합니다. 그렇지 않다면, 공식 사이트 등을 참고해가며 학습과 병행하는 것을 추천합니다. 지난 글(TypeGuards와 Narrowing)에서 언급했던 Opaque 타입에 대해 알아보겠습니다. 소개 우선 타입스크립트의 타입은 기본적으로 유형의 구조가 동일하다면 호환 가능합니다. 코드와 함께 살펴보겠습니다. type Username = string; type Password = string; Username 타입과 Password 타입은 모두 string이기 때문에 타입스크립트에서는 호환 가능합니다. 개발자는 다른 개념으로 각각의 타입을 생성했지만 타입스크립트는 그..

* 이 프로젝트는 기본적으로 TypeScript를 써 보았고, 내장된 유틸리티 타입들과 Generic 등을 알고 있는 상태에서 진행하는 것을 추천합니다. 그렇지 않다면, 공식 사이트 등을 참고해가며 학습과 병행하는 것을 추천합니다. Narrowing과 type guards Narrowing은 type guards를 사용해 type을 좁혀 더 정확하게 만드는 과정입니다. type guards는 type의 범위를 좁히는 데 도움을 주는 특별한 검사 방식을 말합니다. 이해가 쉽도록 예제로 풀어보겠습니다. 여기, 천 단위 구분 기호를 추가해주는 함수가 있습니다. export function withCommas(value: number) { const formatter = new Intl.NumberFormat(..

개발자로서 Git은 매우 중요한 부분입니다. Git과 상호작용 하지 않고 하루를 보낼 수는 없습니다. 일반적으로 터미널에서 Git을 실행하거나 Sourcetree와 같은 GUI도구를 사용합니다. 우리는 Git의 명령어를 기억하고, 작성하는 것이 어렵고 소모적인 것을 알고 있습니다. GUI툴을 사용한다면 Git 명령어를 외울 필요가 없어 정말 쉽게 사용할 수 있습니다. 직관적으로 보이고 또 강력한 부가기능들도 포함되어 있습니다. 하지만 터미널에서만 Git을 실행하는 것을 좋아하는 fan이 분명 존재합니다. 터미널 fan을 위한 효율적인 어떤 방법이 없을까요? 우리는 Git Alias를 설정해 Git 명령어를 별칭으로 저장해 Git을 좀 더 쉽고 빠르게 사용할 수 있습니다. 그럼 Git Alias는 어떻게 ..

개발자로서 업무를 진행하다 보면 자연스럽게 markdown을 접하고 사용하게 됩니다. 마크다운은 텍스트 기반의 경량 마크업 언어로 쉽고 간단하게 서식이 있는 문서들을 작성하는데 용이합니다. README.md는 물론 issue template, pull request template를 만들어 사용하기도 하고 어떤 분들은 TIL과 스터디 자료를 정리해 개인 리포지토리에 저장하기도 합니다. 저 또한 마찬가지로 클린코드 스터디를 진행하며 md파일로 정리했던 섹션이 있었습니다. 저는 마크다운으로 작성하며 내용이 많아지니 미리 보기에 대한 니즈가 있었습니다. VS Code 내에서 관련 Extension이 있는지 찾아보고 사용해보니 그 외의 기능들도 경험이 좋아 추천하고자 글을 작성합니다. Markdown All i..

github의 pull request는 draft 상태로 올릴 수 있는 기능이 존재합니다. * private 리포지토리는 유료 플랜이 필요 Draft 상태의 PR은 작업중인 상태로 Merge를 막을 수 있습니다. 언제, 어떻게 사용할 수 있을까요? 현재 회사에서는 Draft PR을 다음과 같은 규칙을 만들어 활용하고 있습니다. 1. topic으로 다른 개발자와의 의견 조율 및 소통이 필요할 때 2. 변경사항이 많아 리뷰가 힘들어짐을 방지하기 위해 PR을 나누어 올릴 때 순차적으로 Merge하기 위해 즉, PR을 올리는 행위는 테스크가 완료되어 코드리뷰를 하고 Merge하기 위한 것으로 정리할 수 있었기에 git-action은 그 시점에서 필요한 것이고, Draft PR에서도 git-action이 동작하는..