혼자서 또는 극소수의 팀원들과 프로덕트를 만들고 있는 개발자 분들을 위한 클럽입니다.
가이드라인
["현재 프로덕트를 만들고 있는 인디 개발자 분이라면 누구든 환영입니다. 목적이 창업 준비든, 사이드프로젝트이든 관계 없어요.","혼자 개발하면서 생기는 질문, 고민거리, 푸념, 삽질기, 배운 점, 개발 로그 등을 자유롭게 공유해주세요."]
rsptursf
로비콘(Lovicon)은 로고와 파비콘을 손쉽게 만드는 웹 기반 디자인 도구입니다.
저는 여러 사이드 프로젝트를 시도하며, 주로 MVP 수준의 프로덕트를 빠르게 만드는 편입니다. 그 과정에서 로고 디자인에 많은 시간을 쓰지 않게 되더군요. 대신 lucide-react 아이콘 라이브러리에서 적당한 아이콘을 골라 로고와 파비콘을 직접 구성하는 루틴이 자연스럽게 생겼습니다.
하지만 이 작업조차 반복적으로 느껴졌습니다. 피그마를 능숙하게 다루는 편도 아니었기에, 아이콘을 고르고 바로 로고와 파비콘 세트를 내보낼 수 있는 간단한 웹 도구를 직접 만들었습니다.
로비콘은 이 루틴을 줄이기 위해 만들어졌습니다.
추석 연휴 동안 짧게 ‘바이브 코딩’으로 완성했지만, 개인적으로는 꽤 만족스러운 결과물이 나왔습니다. 누구나 무료로 사용하며 자신만의 로고 세트를 빠르게 만들어볼 수 있으면 좋겠습니다.
로비콘
로고와 파비콘 생성을 한번에
공존
수익화 목적의 서비스 성장을 주도할 운영 PO를 모집합니다 (사이드프로젝트)
블링크 아카이빙 소개
2024년 9월 앱 출시 이후 MAU 850명, 평균 MAU 500명 규모로 성장 중이며, 가입자 수가 꾸준히 증가하고 있습니다.
작지만 광고를 통한 수익이 발생하고 있습니다.
팀원 전원이 현직자로 구성되어 있으며, 사이드프로젝트로 직장과 병행하고 있습니다.
주요 업무
인앱결제 기반 비즈니스 모델 기획 및 PMF 검증을 통한 수익화
영미권 대상 마케팅 전략 수립 및 실행을 통한 글로벌 시장 진출
유저 데이터 분석을 통한 운영 전략 수립 및 서비스 개선 (현재 진행중)
이런 분을 기다립니다
열정적이며 스프린트를 책임감 있게 완수할 수 있는 분
빅테크 기업 입사를 희망하시는 분 (실제 포트폴리오로 활용 가능)
팀 구성 및 협업 방식
PM 1명 / 디자이너 2명 / 개발자(앱, 웹, 서버) 5명 / 마케터 2명 (총 10명)으로 구성되어 있으며, 합류 시 PM과 함께 스프린트 업무를 담당합니다.
회의 방식: 주 1회 디스코드 온라인 미팅
지원 방법
간단한 자기소개와 연락처를 보내주시고, 사이드프로젝트를 통해 얻고자 하는 목표도 함께 기재해 주세요.
관련 경험/포트폴리오와 이력서(선택)를 아래 메일로 보내주시면 3일 이내 연락드리겠습니다.
문의사항은 블링크 카카오톡 채널로 연락해 주세요. 커피챗도 환영합니다.
직함이 거창해 보일 수 있으나, 실제로는 주 3-4시간 정도의 업무량입니다. 현직자가 아니어도 괜찮으며 취준생도 환영합니다! 함께 비즈니스 임팩트를 만들어갈 열정 있는 분의 지원을 기다립니다. 감사합니다 :)
블링크 서비스 알아보기 -> https://litt.ly/blink.archive
AI 링크 아카이빙 블링크
매일 밤 탭창 100개 켜놓는 당신을 위한 아카이빙 서비스
Gibeom Lee
웹에서 많은 사람들이 작성해주는 블로그나 뉴스레터들 속에서 인사이트를 얻고 너무 좋은 정보나 인상적이라면 저장해두죠.
또 정보성 글들은 항상 제가 하는 일에서나 일상에서 저의 지식을 한 층 높여주기도 합니다. 그만큼 우리 인터넷에는 정말 많은 정보들이 존재합니다. 하지만 이 정보들을 어떻게 나의 것으로 만들지 항상 고민입니다. 쉽게 접근하고 얻을 수 있는 만큼 흘리기 쉽기 마련입니다.
하지만 이제 우리가 AI 시대에 살고 있지 않습니까?! 누구보다 똑똑하게 정보를 얻고 쉽게 꺼내쓸 수 있어야 합니다.
그래서 제가 만들게 된 서비스는 도비(Doby).
맞습니다. 해리포터의 그 도비. 사실 해리포터를 엄청 좋아하는 편은 아니지만 이 서비스의 이름을 지을 때 그 누구보다 착실한 이름이었으면 했거든요.😂
이제 보고 계신 아티클은 도비한테 던지면 됩니다. 그럼 정리 요약하고 분류해서 알아서 아카이빙 해줄겁니다!!
그런 도비가 잘 성장할 수 있도록 베타 테스터를 모집하고 있습니다! 초기 클로즈드 베타로 10명만을 받아 진행하고자 합니다!!
도비의 성장 그리고 여러분의 새로운 두뇌와 지식을 얻고 싶다면 아래 링크를 통해서 베타 테스터가 되어주세요!!
브라키
스케일 다운 없고, 서버 전송없이 배경제거 하는 툴입니다.
nextjs, typescript
tailwind css
onnxruntime-web
WebGPU -> 모바일 또는 저사양에서는 CPU 사용
BG Remover Pro
이미지 배경 제거, Serverless
공존
[설문조사] 사용 후기 남기고 네이버페이 1만원권 받으세요! 💌
안녕하세요! 링크 아카이빙 서비스 '블링크'를 만들고 있는 Blink팀 공존입니다. 🙂
올해 1월 디스콰이엇에 블링크 서비스를 소개드린 이후로 많은 분들이 관심을 가져주시고 꾸준히 사용해 주셔서 정말 감사드립니다!
저희는 작년 10월 출시 이후 사용자분들의 소중한 피드백을 바탕으로 서비스를 지속적으로 발전시켜 나가고 있는데요, 더 나은 서비스로 거듭나기 위해 여러분의 의견을 듣고자 합니다. 📝
현재 블링크를 사용 중이 아니시더라도, 한 번이라도 사용해보신 경험이 있다면 편하게 의견 나눠주세요!
📌 설문조사 안내
대상: 블링크 링크 저장을 한 번이라도 경험해보신 분
기간: ~ 4월 한 달간 (기한 연장되었어요!)
소요 시간: 5분 이내
참여 혜택: 네이버페이 포인트 1만원권 (추첨 10명)
📌 참여방법
👉 블링크 다운로드: https://litt.ly/blink.archive
블링크앱 다운로드 후 링크 저장하기
팝업 설문 링크 클릭하기
블링크 사용 경험을 솔직하게 작성하기
여러분의 소중한 의견 하나하나가 블링크의 성장에 큰 힘이 됩니다. 많은 참여 부탁드립니다! 🙏
이한글
안녕하세요? 😊
스타트업에서 성능 개선과 코드 품질 향상에 집중하며 성장해온, 운동하는 프론트엔드 개발자입니다! 💪💻
대학 졸업 후, 1년 동안 부트캠프를 다니며 개발자의 길을 시작했어요.
처음에는 “뭘 해야 하지?” 싶어 당황했지만, 어느새 4년차...🤣
혼자서 문제를 해결하고 프로젝트를 주도하는 개발자가 되어 있네요. 시간이 참 빠르죠? 😆
지금 저는 대학병원 및 종합병원에서 사용하는 실시간 환자 모니터링 시스템과 심전도 판독 프로그램을 만들고 있어요.
처음엔 Angular로 된 프로젝트를 인수인계받아 개발했는데, CPU 사용률이 70 ~ 94%나 나와서 좋은 컴퓨터 아니면 실행조차 어려운 상황이었어요.
하지만 포기하지 않고, 계속해서 개선점을 찾고, 고치고, 다양한 방법을 시도한 끝에
지금은 CPU 사용률을 4 ~ 12%로 낮추는 큰 성과를 냈습니다! 🎉
그렇게 문제를 해결하며 성과를 인정받았고, 두 개의 핵심 프로젝트를 주도할 기회도 얻었어요.
앞으로도 기술적 완성도와 사용자 경험을 끊임없이 고민하며 성장하는 개발자가 되려고 합니다.
2025년에는 다들 행복한 일만 가득하길 바라요! 💖🎊
Happy Coding! 🚀
morethanmin
안녕하세요. 몰댄민입니다!
여러분은 글을 작성 하실때 어떤 에디터를 가장 많이 사용하시나요?
저같은 경우 노션을 가장 익숙하고 편하게 사용하곤 하는데요.
정작 블로그를 운영할 때에는 노션처럼 편하게 글을 작성할 수 있는 서비스 없다는게 아쉬웠습니다.
그래서 처음에는 오픈소스 블로그 템플릿을 만들었고, 지금은 더 많은 사람들이 이용하실 수 있도록 블로그 서비스를 만들고있습니다.
언틸의 주옥같은 에디터를 소개해드릴테니.. 혹시라도... 저와 같은 니즈가 있으다면 한번 사용해보세요!
노션처럼 도구상자를 통해서 글을 수정할 수도 있고, 단축키를 통해서 수정할 수도 있어요.
그리고 Slash를 통해서 블록의 타입을 지정할 수도 있어요.
링크를 북마크의 형태로 붙여넣을 수도 있어요.
언어도 자동으로 인식해 하이라이팅해줘요.
에디터에 업로드한 이미지는 썸네일로 지정할 수도 있고, 사이즈도 쉽게 조절이 가능해요.
.... 그 외 세부적인 기능들은 생략하겠습니다. 그렇게 작성한 글들은 아래처럼 보여져요!
글을쓰면 잔디가 심어져요. 잔디를 빼곡히 심으면서 성장해보세요.
본인 블로그에 뿐만아니라 검색 엔진, 언틸 피드에서도 아티클이 공유돼요.
언틸은 유저 피드백을 바탕으로 개발하고 있습니다. 댓글 커뮤니티, 어떤 창구든 필요한 기능을 말씀해주시면 성심성의껏 개발해드립니다. 🧑💻
until
노션처럼 쉽고 강력한 블로그 플랫폼
윤민석
PMC S24를 위해 Variants 기능을 릴리즈 하였습니다.
Vanilla Extract에서는 Recipe라고 알려진 기능으로,
저희 릴리즈 버전에서는 몇가지 기능이 추가되었는데요
원래는 base 키에서만 기본 스타일을 지정할 사용할 수 있었지만,
const button = rules({
base: {
color: "black",
backgroundColor: "white",
borderRadius: 6
}
});Stitches처럼 바로 스타일을 작성가능하도록 했습니다.
const button = rules({
color: "black",
backgroundColor: "white",
borderRadius: 6,
});기존에는 toggle 해야하는 스타일은 `true`라는 variants로 설정하도록 되어있었는데요,
const button = rules({
variants: {
rounded: {
true: { borderRadius: 999 }
}
}
});저희는 toggles라는 필드를 넣어 간편히 토글 variants를 설정할 수 있도록 하였습니다.
const button = rules({
toggles: {
rounded: { borderRadius: 999 }
}
});기존에는 toggle 때와 마찬가지로 true를 사용했어야 했지만,
const button = rules({
variants: {
rounded: {
true: { borderRadius: 999 }
}
outlined: {
true: { border: "1px solid black" }
},
size: {
small: { padding: 12 },
medium: { padding: 16 },
large: { padding: 24 }
}
},
defaultVariants: {
rounded: true,
outlined: true
}
compoundVariants: [
{
variants: {
outlined: true,
size: "small",
},
style: {
fontSize: "16px"
}
}
]
});배열을 사용할 경우 자동적으로 true로 사용하도록 만들고 타입추론까지 되도록 하였습니다.
const button = rules({
variants: {
rounded: {
true: { borderRadius: 999 }
}
outlined: {
true: { border: "1px solid black" }
},
size: {
small: { padding: 12 },
medium: { padding: 16 },
large: { padding: 24 }
}
},
defaultVariants: ["rounded", "outlined"],
compoundVariants: [
{
variants: ["outlined", { size: "small" }],
style: {
fontSize: "16px"
}
}
]
});button을 사용할때도 마찬가지로 배열을 허용하고 자동변환됩니다.
const myButton = button(["outlined", "rounded"]);CSS()와의 연동일반 스타일링을 담당하는 css()에 그대로 넣으면, 기본 Variants를 사용하도록하여 편의성을 높혔습니다.
const base = css({ color: red });
const myRule = rules({
background: blue,
props: ["padding"],
toggles: {
rounded: { borderRadius: 999 }
}
});
const myCss = css([base, myRules]); // Same as [base, myRules()]아직 목표했던 모든 기능을 릴리즈하지는 못했지만, 다양한 편의기능이 들어갔어요.
그럼 11월 공개SW 대회를 목표로 계속 열심히 해보도록 하겠습니다!!
Mincho
디자인시스템을 위한 CSS in JS 프레임워크
윤민석
이전글에서 글을 쓰고 있었다고 했었는데요,
dev.to에 공개했습니다!!
절반의 성공은 예상외로 트위터에서 흥했다는 점이에요.
dev.to 블로그에서도 흥해서 매니저들이 뽑은 Top7 글이자,
금주 최고의 CSS 글로 표시되는 명예를 얻었어요.
제가 원래 트위터나 dev.to는 사용하지 않고, GitHub와 HackerNews위주로 홍보했던 방침을 바꾼 결과에요.
깃허브 스타도 35개가 되었죠.
새로운 마케팅 방법을 시도한 것은 좋았지만,
기존 방법은 실패해버리고 말았어요.
앞서 말씀드린 HackerNews는 디자인이 투박하지만, OpenAI의 샘 알트먼이 사장으로 있었을 만큼 VC 투자로서도 유명한 사이트입니다.
순위권 안에 들면 자동으로 레딧, 페이스북, 트위터등으로 퍼지는등 강력한 영향력을 가지고 있죠.
그런데 제 글이 DEAD표시가 되어 알아보니, Dev.to의 글들은 전반적인 품질이 낮아 광역 스팸 필터..가 걸려있다고 하더라고요.
트위터, 디스코드등에 홍보하여 모든 트래픽이 HN에 집중적으로 모이도록 해서, 다시 퍼지게 하려는 계획이었는데 플랫폼을 잘못 고르는 바람에 실패해버리고 말았네요. ㅠㅠ
그래서 다음에는 Medium을 활용해볼까 생각중입니다.
다음에는 더 잘 할 수 있을거라 믿으며..
이 글이 재미있었거나, 도움이 조금이라도 되었다면 스타를..!!ㅠㅠ
Mincho
디자인시스템을 위한 CSS in JS 프레임워크
헐크코디어
[1인 개발] PlayStore 4번의 리젝과 5번의 시도
안녕하세요!
을 개발한 1인 개발자 박현진 입니다.
PlayStore와의 배포 전쟁 이야기를 들려드리면서 저와 같은 실수를 하지 않길 바라는 마음에 이 글을 공유드립니다.
참고로 아래 진행 과정은 개인 개발자 계정에만 해당하는 정책들입니다.
TodoZIP 앱이 Flutter로 개발 되어 있어 AppleStore, PlayStore 배포를 전부 진행 했습니다.
역시나 iOS개발자 출신답게 AppleStore는 한방에 통과!
하지만 PlayStore는 예전 좋았던 기억과는 다르게 많이 달라져 있었습니다.
개발자 계정 결제 후 본인 인증까지 쉬운게 하나도 없더군요...
그래도 어찌저찌 여기만 지나면 배포 할 수 있겠지!! 라는 너무나 큰 기대감과 함께 앱을 배포 하려고 하니 프로덕션 출시 버튼이 비활성화가 되어 있었습니다...
검색 해보니 이제는 PlayStore에 출시하기 전에 비공개 테스터 20명을 모집하고, 그 후로 14일이 지나야 프로덕션 검수 신청이 가능하다고 바뀐 정책이 있었음을 확인했습니다.
저는 여기서 조금 좌절 했습니다...분명 예전에 구글은 이렇지 않았는데!!
그렇지만 TodoZIP은 좋은 서비스이니깐 양대 스토어에 다 올라가 있어야지!! 하면서 20명을 어떻게 구하나 검색 했더니 아래 두가지 방법으로 좁혀지더군요.
크몽 전문 업체 활용 VS 비공개 테스트 품앗이 카톡방
5만원 정도의 가격을 주고, 아무 신경안쓰고 전문업체에 맡기면 되겠지라는 안일한 마음 가짐과 함께
저는 첫번째 시련을 받았습니다....
PlayStore님이 너는 테스터를 제대로 모으지 않았고, 테스트 모범사례를 따르지도 않았다!!
???????????????????????????????????
저는 크몽 전문업체 분에게 물어봤습니다.
나: 왜 리젝일까요??
크몽: 다시 해보시죠!
네 그렇게 두번째 시련을 받았습니다.
나: 왜 리젝일까요??
크몽: 다시 해보시죠!
네 그렇게 세번째 시련을 받았습니다.
나: 왜 리젝일까요??
크몽: 다시 해보시죠!
네 그렇게 네번째 시련을 받았습니다.
네 저는 그렇게 14일을 자그마치 4번의 리젝과 함께 56일이란 시간과 함께 다 날려버렸습니다!
저는 이때 깨달았습니다...(너무 늦게)
아 이건 크몽에 맡기면 다음번엔 또 리젝이겠구나!
카카오톡 품앗이방에 가서 저는 하소연을 하게 되었습니다.
저 4번 리젝 당했습니다 여러분!!!
어랏?! 이 단톡방에 2 ~ 4번 리젝 당하시는 분이 엄청 많았습니다!!
심지어 다들 크몽을 쓰고 계시더군요..
큰일이다 싶어 저는 네이버 카페에 비공개 테스트 품앗이 방에 글을 올려 테스터를 구하고 14일이란 시간이 지난 후........
드디어 4번의 리젝과 5번의 시도 끝에 배포까지 성공하게 되었습니다...ㅠㅠ
앱 배포가 이렇게 기분좋은 일인걸....신입때 느꼈던 기분을 다시 느끼게 되었습니다.
결론:
크몽 업체에 맡기면 잘 될수도 있고, 안 될 수도 있다
비공개 테스트 품앗이 카페에 올릴 경우 조금 귀찮을 수 있지만 99%의 확률로 통과가 된다
해외랑 카톡방의 정보를 모아보니,
현재 구글은 정책이 더 까다로워져서 비공개테스트때 앱을 업데이트 했는지 여부
업데이트를 몇명이 설치했는지 여부
처음 리젝 후 다시 테스트시 같은 계정으로 테스트 하는지 여부를 다 체크하고 있는것 같습니다.
부디 1인 개발 하실때 저처럼 미련하게 하지 마시고 똑똑하게 하시길 바라면서
좋은 서비스 만드시길 기원합니다.
Todo.ZIP
같이 사는 누군가와 오늘의 집안일을 공유해요!
김은찬
[명절 잔소리 마스터] 명절 날 AI에게 잔소리하는 서비스
추석 연휴가 끝나가네요~ 다들 이번 명절 잘 보내셨나요?? 혹시,, 잔소리만 왕창 들으신 분들도 계실까요??? 🥹
제가 이번에 '명절', '잔소리'라는 주제로 토이 프로젝트를 만들어보았습니다~😉
(추석 연휴에도 계속 개발을 했어서 이제서야 공유하네요...)
서비스 이름은 [명절 잔소리 마스터]인데요. 가상의 상황 속에서 사용자가 AI에게 잔소리를 하는 대화형 시뮬레이션 서비스에요.
대화가 끝나면 대화 내용을 분석해서 잔소리가 서로에게 어떤 결과를 가져오는지, 어떻게 하면 둘의 관계를 개선할 수 있는지 보여줘요.
이 서비스를 통해 자신이 하는 말이 상대에게는 어떻게 들리는지, 상대는 어떤 심경인지 경험해보셨으면 좋겠습니다. 분명 자신이 생각한 것과는 다를거에요. 어떻게 아냐고요? 제가 개발하면서 직접 경험했거든요!
물론! 잔소리가 아니더라도 AI와 함께 대화하며 시간보내기도 좋으니까요~ 귀경길 심심하실 때 한 번씩 해보셔요. 🤗
윤민석
저희가 만들고 있는 프로젝트, Mincho가 공개SW 개발자대회 1차를 패스했습니다.
접수번호상 약 700명 가까이 지원하는 대규모 대회라 좋은 소식이 아닐 수가 없습니다.
(그 와중에 발견하기 쉬운 우리팀..ㅋㅋ) Designed by Freepik
저희는 현재 CSS-in-JS 라이브러리인 'mincho'를 개발 중에 있습니다. 이 라이브러리는 기존 CSS-in-JS 솔루션들의 장점을 취하면서도, 더 나은 개발자 경험과 성능을 제공해 디자인 시스템에 통합하는 것을 목표로 하고 있습니다.
소개글 바로가기: Rethinking CSS in JS
HN:
읽어보시면 아시겠지만 전반적으로 프로젝트 볼륨이 크다보니 개발자가 1~2분 더 계시면 좋지 않을까 싶더라고요.
이 와중에 PMC 2024에서 팀매칭을 지원해주신다!! 하길래 지원을 하게되었습니다.
저희의 주된 목적은 오픈 소스 커뮤니티에 기여하고, 개발자들에게 유용한 도구를 제공하는 것입니다. 물론 이 과정에서 우리의 기술적 역량을 키우고, 새로운 도전을 즐기는 것도 중요한 동기가 되고 있습니다.
공모전도 일종의 동기부여 중 일부입니다.
저희가 찾는 분은:
TypeScript랑 친한 사이인 분 (아주 깊은 사이까지는 아니어도 돼요 😉)
CSS를 보면 "아, 이거 알아!"하는 정도
Git으로 협업해본 경험이 있는 분
관심 있으신 분들은 커피챗 기능으로 부담 없이 연락주세요.
커피 한 잔 하면서 이야기 나눠봐요! (부담스러우시면 메일/디코도 괜찮습니다)
PS: CSS 때문에 머리 아프셨던 분들, 우리랑 함께 그 고통을 없애봐요!
Mincho
디자인시스템을 위한 CSS in JS 프레임워크
정해준
안녕하세요 😊
오늘은 제가 최근에 시작한 오픈 소스 프로젝트 ts-typekit에 대해 가볍게 이야기해보려 해요.
TypeScript를 사용하는 많은 개발자들이 공감할 수 있는 부분이지만, 내장 유틸리티 타입인 'Omit'은 때로는 예상치 못한 문제를 일으키곤 해요. 예를 들어, 존재하지 않는 키를 제거해도 오류를 발생시키지 않아 나중에 문제를 발견하고 수정하는 경우가 있죠.
또한, 기존 유틸리티 타입만으로는 원하는 타입을 만들기 어려워 커스텀 타입을 제작하는 일이 빈번한데요. 그런데, 커스텀 타입은 또 다른 컨벤션을 만들어내며, 문서화가 제대로 되어 있지 않으면 이해하는데 시간이 오래 걸리기도 해요. 이런 이유로, 아예 유틸리티 타입을 제공하는 라이브러리를 만들면 어떨까? 라는 생각에서 ts-typekit를 시작하게 되었어요.
ts-typekit는 TypeScript 개발자들이 더 안전하고 유연한 코드를 작성할 수 있도록 돕는 것이 목표예요. 앞으로도 지속적으로 기능을 추가하고 개선해나갈 예정이에요. 더 다양한 유틸리티 타입을 제공하고, 피드백을 적극 반영해 기능을 개선해 나가면서 개발자들이 서로 의견을 나눌 수 있는 커뮤니티의 장으로 만들어 보려고 해요. 또한, 읽기 편안한 문서를 제공해서 사용자들이 쉽게 이해하고 활용할 수 있도록 할 계획이에요.
ts-typekit와 함께 더 나은 개발 환경을 만들어보는 것은 어떨까요?
개발을 하면서 필요하다고 생각했던 타입이 있다면, 주저하지 말고 이슈로 남겨주세요!
많은 분들의 이슈와 별을 기다리고 있으니, 한 번씩 둘러보시면 좋겠습니다!
Github
Reference
윤민석
Mincho 프로젝트의 이번주 #6 - 작가님..9800자 쪽지보냈습니다!!
이전 글에서 문서화 작업을 하고 있다고 말씀드리고 소식이 잠시 끊겼었습니다.
이제 배포를 하기위해 문서화 작업들을 주로 하고 있어요.
그도 그럴만한게 저는 다른 프로젝트를 보아도 문서화에 공을 엄청나게 들이는 편입니다.
이번 프로젝트도 마찬가지입니다.
근데 제가 봐도 양과 들어간 지식의 양이 엄청나게 넓고 디테일해요...
아무래도 디자인, CSS, 각종 웹환경과 방법론, 구현체등등 글에서 다루어야 하는 내용 자체가 많다보니 제가 봐도 어색하고 퇴고가 반드시 필요하다 느꼈습니다.
그래서 다양한 곳을 통해 베타리딩을 실행하고, 피드백을 받았는데요.
EasyLogic Studio나 Flitter의 개발자님들처럼 프론트에 대한 많은 고민을 하시던 분들이 많으셔서 유용했습니다.
그리고 그 중에는 정말 감동적인 리뷰(9800자 쪽지)도 있었습니다.
제가 부족하다 느끼는 부분들을 하나하나 다 훑어주시는 엄청난 글 구성 능력자..!
사실 양이 너무 많아서 저도 대부분의 리뷰가 옳다고 느끼면서도 반영을 하지는 못했는데요.
발표자료에 쓸때도 유용한 피드백이라 레퍼런스로 계속 써도 좋겠다는 생각이 들었습니다.
이렇게 적극적인 독자분을 만날 수 있는건 행운인 것 같네요.
흠흠.. 저도 디콰 여러분에게 사소한팁을 하나 풀어보겠습니다!!
LLM을 이용해 글을 평가하고 싶을때 이렇게 해보세요.
다음 글을 읽고, 박평식처럼 평론을 해줘.
![Screenshot 2024-09-01 at 01-59-09 Phind - ## 1. What is CSS in JS CSS in JS is a technique that allows you to write CSS styles directly within your JavaScript(or TypeScript) code. Instead of creating separate CSS files you can define styles along[...].png](https://disquiet-public.s3.ap-northeast-2.amazonaws.com/images/makerlog/cd6fab591d7d9f47477040090b4cbe374361b075e132fd9db154504ab6a80d91 "Screenshot 2024-09-01 at 01-59-09 Phind - ## 1. What is CSS in JS CSS in JS is a technique that allows you to write CSS styles directly within your JavaScript(or TypeScript) code. Instead of creating separate CSS files you can define styles along[...].png")
박평식님이 별 7개라면..나름 괜찮죠??
혹시 뼈가 뿌러지고 싶을정도로 솔직한 답변을 받고 싶다면?
"신랄하게"를 넣어보십시오.
다음 글을 읽고, 박평식 스타일로 신랄하게 평론을 해줘.
저는 괜히 해봤다가 가루가 되버려서 올리지 않겠습니다 =3=3
그럼 다음주는 디콰 줌 미팅을 주제로 만나요.
- 끝 -
Mincho
디자인시스템을 위한 CSS in JS 프레임워크
윤민석
Mincho 프로젝트의 이번주 #5 - 기본 기능 완성!!
소개글
주간레터
저번주의 주간레터는 한번 건너 뛰었는데요,
제가 여행갔다 오느라 작업을 거의 못해서 입니다.
그래도 이번주에는 다행히 배포를 위한 모든 기능을 구현했습니다.
마지막으로 구현한 기능이 생각보다 어려웠네요.
Variant Reference 라는 기능인데요, %Variant이름 을 자리표시자로 두고 참조할 수 있게 만들어 줍니다.
export const myCss = cssVariant({
primary: {
color: "red",
":has(%secondary)": {
color: "blue",
}
},
secondary: {
color: "black",
"%primary &":{
color: "white"
}
}
});확실히 전처리기에서 있을범직한 기능이죠.
export const myCss = styleVariant({
primary: {
color: "red",
},
secondary: {
color: "black",
}
});
globalCSS(`${myCss["primary"]}:has(${myCss["secondary"]})`, {
color: "blue"
});
globalCSS(`${myCss["primary"]} ${myCss["secondary"]}`, {
color: "white"
});이제 배포를 하기위해 문서화 작업들을 주로 하고 있어요.
이외에 개발은 changesets를 이용한 Monorepo 자동 버저닝/CHANGLOG 생성과 CommonJS, ESM에서 테스트 검증이 있겠네요.
아 참, 새로운 RFC도 병렬적으로 이루지고 있어요.
새로운 RFC는 흔히 Variants(혹은 recipe)라고 불리는 것으로서 다이나믹한 Props을 다루거나 BEM을 쉽게 구현할 수 있도록 도와주는 역할이에요.
자세한건 다음에 쓸 소개글에 더 적어보도록 하겠습니다.
생각보다 일정잡는게 빡세네요.
Mincho
디자인시스템을 위한 CSS in JS 프레임워크
윤민석
Mincho 프로젝트의 이번주 #4 - JSON 콘솔 디버깅 라이브러리 배포
소개글
주간레터
이번주는 개발 팁이라기보다는 배포 경험입니다.
드디어 팀원분의 시간이 생겼기 때문에 함께 작업을 할 수 있었어요.
먼저 라이브러리에 대해 간략하게 소개하면, 디버깅에 최적화된 출력을 해주는 패키지에요.
설치 방법은 다음과 같습니다.
npm install -D @mincho-js/debug-log
# 또는
yarn add -D @mincho-js/debug-log2번째주 뉴스레터에서 소개했듯, 이미 debugger를 구축하여 사용하고 있지만,
저희는 복잡한 CSS 관련 변환 객체들을 다루고, 재귀적인 호출등이 있다보니 어려움이 있었습니다.
디버거의 브레이킹 포인트는 포착하고 싶은 컨텍스트 근처에서 변화를 살펴볼때 도움이 되었지만,
화면 자체가 이동하기 때문에 단순히 로그만 찍어보고 싶을때도 많았습니다.
단순히 로그를 찍을때는 보통 다음과 같은 방식으로 출력해 보았지만, 불편했어요.
console.log(JSON.stringify(객체, null, 2));타이핑이 너무 많음
총 몇번이나 호출되는지를 즉각 알 수 없음
어디에서 호출되었는지를 즉각 알 수 없음
코드 하이라이팅이 되지 않아 불편
객체끼리 얼마나 달라졌는지 알 수 없음
그래서 5가지를 매우 간단하게 해결하는 라이브러리를 구축했지요.
간단한 함수명
몇 번 호출되는지 횟수 기록
제목 넣기 가능
JSON 객체 하이라이팅
객체 비교 기능
주요 API는 3가지 입니다.
호출할 때마다 count가 증가하고, 제목을 넣을 수 있습니다.
debugLog();
console.log("test");
debugLog("with title debugLog");
console.log("test2");debugLog에 더불어 JSON을 아름답게 출력해줍니다.
혹시 JSON만 출력하고 싶으시다면 jsonPrint를 써보세요.
jsonLog({ key1: true, key2: 1, key3: null, key4: "string" });
jsonLog("with title jsonLog", { others: undefined });여기서부터는 함수 모양이 조금 복잡해 보이기도 하는데요,
제목여부는 function overload를 활용해 자동으로 추론해주고 있습니다.
jsonExpect는 JSON 객체끼리 비교할 수 있는 기능을 탑재하고 있어요.
jsonExpect({ a: 1 }, { a: 2 });
jsonExpect("with title jsonExpect", { b: 1 }, { c: "1" });무엇이 추가되고, 무엇이 삭제되었는지, 무엇이 편집되었는지를 한눈에 볼 수 있고
만약 객체가 동일한 모양이라면 same 이라는 박스에서 한번만 출력됩니다.
심지어 저희는 Vite Plugin화를 시켜놨기 때문에 상단에 import하는 것이 아니라,
함수 내부, 테스트 코드 내부 등 원하는 곳 어디서든 호출하도록 구성하여 사용하고 있답니다.
const { debugLog, jsonLog } = import.meta.debugLog;물론 test 모드일때만 들어가므로, 프로덕션에 포함될 걱정을 하지 않아도 되요.
아직 vite plugin은 내부용도로만 쓰고 있어요.
첫번째 주에서 팀원과 목적/목표등을 정렬(Align)하는 시간도 가졌었는데요.
팀원 분께서는 서비스 배포와 달리 NPM 패키지는 올려본 적이 없었기 때문에 한번 꼭 경험해보고 싶다고 말씀하셨습니다.
사실 저도 개인 계정이 아닌 조직 계정으로 배포는 처음이었는데요.
덕분에 몇가지 삽질을 했지만, 관련 이슈들을 잘 정리해주신 덕분에 매우 편하게 작업할 수 있었습니다.
프로젝트 이름: 조직 계정 이름과 scope 가 일치시키는걸 까먹고 있었습니다.
패치된 패키지: 번들링되는 서비스용 프로젝트면 몰라도, 라이브러리에서 패치된 버전을 배포하기란 생각보다 어렵더라고요. 그래서 저희는 포크를 뜨고, 배포하기로 결정했습니다.
CommonJS: 의존하는 라이브러리 문제인데요, 몇가지 해결 방법을 찾기는 했으나
비동기 함수로의 전환, 동기식이여도 ESM과의 호환성 문제 등 때문에 어차피 내부용 툴링이니 우선 ESM 전용으로만 배포하기로 했습니다.
의존하는 패키지에서 JSON을 import하기 위해 import obj from "mod" with { "type": "json" }를 사용하고 있어 경고가 뜨는 모양이더군요.
역시 저희 환경에는 문제가 전혀 없기 때문에 해결없이 배포를 진행했습니다.
이번주에는 Monorepo에서의 버전 관리를 위한 changesets를 적용하고, 깃허브 액션으로 완전히 자동화된 체계를 갖추어보려고 합니다.
제가 여행을 잠시 다녀올 예정이라 팀원분께서 열심히..!! 작업을 해주시지 않을까 기대해봅니다. ㅎㅎ
혹시 개발에 관심이 있으시다면 댓글을 달아주시거나 alstjr7375@daum.net에 연락을 주셔도 좋습니다.
하단의 업보트와 깃허브 스타를 찍어주셔도 매우 큰 도움이 됩니다!!
- 네번째 뉴스레터 끝 -
Mincho
디자인시스템을 위한 CSS in JS 프레임워크
윤민석
Mincho 프로젝트의 이번주 #3 - 깃허브 봇들과 함께해요
소개글
주간레터
이번 주 개발 팁은 적은 사람들이 오픈소스 개발을 할 때 커다란 도움이 될 거에요.
사람이 많아도 사전 필터링이 한번은 될테니, 도움이 될테구요.
여러분의 프로젝트에서는 어느정도로 자동화를 하고 있나요?
회사라면 상당히 많은 자동화 파이프라인이 가동될 수도 있겠지만, 개인 프로젝트들에서는 생각보다 쉽지 않습니다.
이 글에서는 몇가지 유용한 자동화를 소개하려 합니다.
저희 레포에서 풀리퀘스트를 발생시키면 봇들이 돌아가는데요, 같이 확인해봅시다.
저희의 CI는 pre_job과 build라는 2개의 과정으로 이루어져 있어요
pre_job은 git의 커밋 해시를 인식해 한번 돌아간적이 있다고 인식되면 build 과정을 pass 시켜버려요.
커밋을 다시하는 상황이라면 모를까, 다음의 상황에서 또 CI를 돌릴 필요는 없잖아요?
push되어 CI가 돌아간 이후에 PR을 열기
fast-forward merge가 된 상황
그렇다면 build 과정에서는 어떤 일이 일어날까요?
먼저 레포와 캐시를 다운받고요
워크플로우 및 액션등에 대한 lint를 돌립니다. .yml 파일 작성을 잘못해서, PR에서는 통과했지만 릴리즈를 해야할 때 안돌아간다던가, 이슈폼이 제대로 나타나지 않는다던가 하는 일들이 있으면 억울하잖아요?? 그래서 저희는 체크를 따로 하고 있어요.
이후 yarn test:all이라는 명령어로 각종 테스트를 진행해요.
어떤 테스트를 돌릴까요?
린트: 린트로 정적 분석을 하고, 포매팅도 함께 검사해요
타입 체크: 저희는 타입스크립트 프로젝트이니 타입을 만족하는지 체크해야지요.
빌드: 당연하지만 빌드는 항상 되어야 합니다.
테스트 코드: 유닛 테스트들을 모두 만족해야 합니다.
이 테스트 과정은 turborepo를 이용해 의존성을 파악하고, 병렬로 실행합니다.
캐시와 병렬화 덕분에 1분 정도면 CI 과정은 마무리되요.
아니.. 코드리뷰를 자동으로 해주는 봇이 있다고요??
저희는 Coderabbit이라는 봇을 도입 후 매우 잘 사용하고 있습니다. (오픈소스는 공짜!!)
PR을 올리면 먼저 기다려달라는 귀여운 메세지가 뜨고요.
제 PR을 요약해줍니다.
상세한 코멘트는 별도죠.
리뷰가 필요하다 생각하면 댓글도 달아주고, 주고받고 할 수 있습니다.
특히 문서화 PR에서 폭풍 코멘트를 날려주셨어요..제..슬픈 영어 실력...ㅠㅠ
코드 리뷰는 상대적으로 덜 빡센 편인데요, 그래도 가끔씩 유용한 리뷰들을 남겨주어 좋습니다.
저희는 fast-forward라는 git merge 방식을 주로 사용해요. (자세한건 다음에 설명하겠습니다)
깃허브에서는 지원하지 않는데요.
merge 커밋이 생성되 추적이 어려운 점을 방지하고, rebase나 squash와 달리 커밋기록과 해시가 보존하고 싶었어요.
Fast forward merge봇이 fast-forward가 가능한지 체크해주고, 가능하다면 다음과 같이 댓글을 달아서 merge하도록 구성해놨어요.
깃허브 레포의 settings/security_analysis에 가면 다양한 설정이 있습니다.
먼저 Dependa bot.
뭔가 싶겠지만 한번쯤 본적이 있을거에요.
저희는 여러개가 한꺼번에 열리는 귀찮은 점을 방지하기 위해 그룹으로 한꺼번에 업데이트하도록 설정해두었어요.
그리고 Code scanning을 통해 자동적으로 보안감사를 하도록 구성해두었습니다.
아직 저희는 패키지를 배포하고 있지는 않아서 배포하는 액션은 없는데요,
8월 중에는 아마 생길 것 같습니다.
이번주에도 많은 일을 했어요.
먼저 제 프로젝트들의 특징 중 하나라고 하면, 문서양이 규모에 비해 많은 편 입니다.
보는 사람이 편하고, 관리하기도 편하더라고요.
이번에는 README, Code of Conduct, Contributing 등의 문서를 모두 완전히 다시 썼어요.
특히 Contributing 문서에는 명문화된 개발 프로세스들이 많은데요,
나중에 주간레터에서 하나씩 소개드리도록 하겠습니다.
팀원이 아마 이번주까지는 할 일 때문에 참여를 많이 못할 것 같아요.
그래도 정기 미팅으로 일요일에 만나고 있습니다.
이번주 일요일에는 Stacked Diff PR을 위한 선형 커밋 로그를 만드는 방법에 대해 알려주고,
패키지 배포에 대해 함께 논의하였답니다.
디버깅을 하다가 너무 힘들어서 만든 패키지에요.
호출 될때마다 카운트가 증가하고요,
JSON을 이쁘게 보여주고
비교도 할 수 있어요.
이제 슬슬 배포가 다가오기 때문에 번들링 관련 설정을 했어야 합니다.
의존성: 원래 설정은 Node.js에서 모든 의존 패키지가 번들링되어 하나의 JS 파일로 나왔는데요, 어플리케이션이 아니기 때문에 외부 패키지는 설치하도록 변경했습니다.
ESM & CJS: ESM(index.js, index.d.ts)과 CJS(index.cjs, index.d.cts)를 export 할 수 있도록 했어요.
플러그인: 위에 나온 debug-log를 vite plugin으로까지 만들었어요. 자세한건 다음에. ㅎㅎ
property를 참조할 수 있는 기능이랍니다.
export const myCss = css({
width: "50px",
height: "@width",
margin: "calc(@height / 2)"
});다음과 같이 컴파일 되겠죠?
export const myCss = style({
width: "50px",
height: "50px",
margin: "calc(50px / 2)"
});이번주에는 생각보다 다른 할 일이 많았습니다.
이제 기능은 1개만 더 만들면 되네요!!
다음주에는 debug-log부터 배포를 시작해볼거에요!!
혹시 개발에 관심이 있으시다면 댓글을 달아주시거나 alstjr7375@daum.net에 연락을 주셔도 좋습니다.
하단의 업보트와 깃허브 스타를 찍어주셔도 매우 큰 도움이 됩니다!!
- 세번째 뉴스레터 끝 -
Mincho
디자인시스템을 위한 CSS in JS 프레임워크
윤민석
Mincho 프로젝트의 이번주 #2 - RFC-TDD 프로세스로 개발하기
안녕하세요?
벌써 두번째 뉴스레터를 적어야 할 때가 돌아왔습니다!!
뉴스레터에서는 개발 현황 뿐만 아니라, 각종 개발 팁들을 조금씩 풀어보려고 해요.
이번에 소개해드릴 것은 RFC-TDD 프로세스로 개발하기입니다.
소개글
주간레터
Mincho 프로젝트의 이번주 #1 - 팀 빌딩하는 방법에서 설명한 것처럼 RFC 문서를 작성하면 장점이 많습니다.
스펙 구성, 컨텍스트 공유, 테스트 짜기 등등에서요.
제가 하는 방법을 설명하자면, 다음과 같습니다.
RFC 문서 작성
RFC를 보면서 in source 테스트 케이스 추가
it.only()로 해당 테스트만 실행되게 해놓고, debugger 모드로 실행
의심가는 부분을 break 걸어놓고, 필요하면 log 추가
코드가 헷갈리면 IDE 옆에 켜진 AI에게 물어보기
혹시 구현부분에 추가적인 설계가 필요할 경우 RFC에 적어서 PR 및 커밋
다시 RFC 보면서 코드 구현
only 옵션 풀어보고, 돌아가면 전체 테스트 한번 돌리기
PR 및 Merge
반복
뭔가 복잡해보이죠?
그렇다면 우선 많이들 하는 TDD로 개발하기만 생각해봅시다.
이번에 한 작업은 중첩된 CSS 변환이었는데요,
다음과 같이 범위를 줄여봤어요. 훨씬 쉽죠?
in source 테스트 케이스 추가
it.only()로 해당 테스트만 실행되게 해놓고, debugger 모드로 실행
의심가는 부분을 break 걸어놓고, 필요하면 log 추가
구현
only 옵션 풀어보고, 돌아가면 전체 테스트 한번 돌리기
저희 프로젝트는 탄탄하게 만들기 위해서 in source 테스트를 많이 만듭니다.
in source 테스트가 뭐냐고요?
말 그대로 소스코드와 테스트코드를 함께두는 방식을 말합니다.
Rust에서 자주 쓰는 방법이고, 저희는 Vitest를 통해 달성하고 있어요.
// == Interface ================================================================
export function isCSSVarKey(keyStr: string) {
return keyStr.startsWith("$");
}
export function isPureCSSVarKey(keyStr: string) {
return keyStr.startsWith("--");
}
export function isVarsKey(keyStr: string) {
return keyStr === "vars";
}
export function replaceCSSVarKey(keyStr: string) {
return convertToCSSVar(keyStr);
}
// == Tests ====================================================================
if (import.meta.vitest) {
const { describe, it, expect } = import.meta.vitest;
describe.concurrent("Replace CSS Var value", () => {
it("Is css var key", () => {
expect(isCSSVarKey("$myCssVariable")).toBeTruthy();
expect(isPureCSSVarKey("--my-css-variable")).toBeTruthy();
expect(isCSSVarKey("-my-css-variable")).toBeFalsy();
expect(isPureCSSVarKey("-my-css-variable")).toBeFalsy();
expect(isCSSVarKey("_hover")).toBeFalsy();
expect(isPureCSSVarKey("_hover")).toBeFalsy();
});
it("Convert to css var", () => {
expect(replaceCSSVarKey("$myCssVariable")).toBe("--my-css-variable");
expect(replaceCSSVarKey("$my-css-variable")).toBe("--my-css-variable");
});
});
}이렇게 하면 몇가지 장점이 있어요.
한가지 파일에서 관련된 소스코드와 테스트 코드가 함께 있으므로 작성, 분석, 추적이 쉽습니다.
작성: 화면 스플릿만 하여 바로 작성할 수 있어요.
분석: 한 파일에 있으므로, 타입만 보고 인터페이스를 추정하기 힘든 경우 아래로 내려서 예제를 바로 볼 수 있습니다.
추적: git에서 변경 사항이 여러 파일과 디렉토리에 걸쳐있지 않아 변경사항 추적이 간편합니다. 혹시 test파일을 추가하지 않았다던가 하는 일도 없겠죠.
유닛 테스트와 통합 테스트를 분리할 수 있습니다. (in-source에 있는게 유닛테스트)
테스트를 작성하는 방법 자체는 다음을 참고해보세요.
새로운 기능이나 버그를 고치기 위한 목적으로, 테스트를 작성했다면 분명 실패할거에요.
아직 기능이 구현되거나 버그가 고쳐지지 않았으니까요.
두번째는 작성한 한가지 테스트만 실행되게 해야합니다.
다른 테스트까지 실행하면 분석하기가 어려워지니까요.
이를 위해 먼저 only 옵션을 주도록 합니다.
it.only("Nested selector & AtRules", () => {
// 작성한 테스트...
});다음은 Debugger 모드로 현재 파일만 watch로 실행되도록 .vscode/launch.json 파일을 구성합니다.
이렇게 하면 디버그 모드로 현재파일 테스트를 바로 실행하고, 저장될 때마다 테스트가 통과하는지 확인할 수 있어요.
{
// From https://vitest.dev/guide/debugging#vs-code
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"type": "node",
"request": "launch",
"name": "Debug Current Test File",
"autoAttachChildProcesses": true,
"skipFiles": ["<node_internals>/**", "**/node_modules/**"],
"program": "${input:GIT_ROOT}/node_modules/vitest/vitest.mjs",
"args": [
"watch", "${relativeFile}"
],
"smartStep": true,
"outFiles": ["${workspaceRoot}/dist/**/*.js"],
"console": "integratedTerminal",
"cwd": "${workspaceRoot}",
}
],
// Need to install `augustocdias.tasks-shell-input` extension
"inputs": [
{
"id": "GIT_ROOT",
"type": "command",
"command": "shellCommand.execute",
"args": {
"command": "git rev-parse --show-toplevel",
"useSingleResult": true,
"useFirstResult": true
}
}
]
}한번 실행해 볼까요?
파일을 저장하니 다시 실행되는 모습을 볼 수 있습니다.
이제 브레이크 포인트를 두고, 값들을 확인하면서 코딩이 가능해요.
물론 필요하다면 console.log도 찍어도 좋습니다.
보다 이쁘게 보려면 JSON.stringify(object, null, 2) 를 함께 쓰면 되요.
이제 테스트가 통과할 때까지 구현만 하고, only 옵션을 푼다음 테스트하고 커밋하면 끝나겠죠?
이렇게 디버거와 함께 반복적으로 테스트가 통과하는지 체크하면 개발은 편하면서 일정 품질은 보장이 되요.
그렇다면 RFC는 Test와 함께 어떻게 시너지가 있을까요?
RFC란 "비평을 기다리는 문서"라는 의미로, 새로운 아이디어에 대한 전문가 비평을 받거나 정보를 공유가 목적입니다.
한 번 발행된 RFC는 폐기되지 않으며, 수정이 필요한 경우 새로운 RFC로 발행됩니다.
저희는 각종 기능의 스펙과 배경, 구현 방법등을 담아 발행하고 있습니다.
그리고 테스트를 작성할 때는 RFC에 기반하여 작성하는데요,
설계가 잘못되었거나 보충되어야 할 때를 빠르게 판단할 수 있습니다.
예를들어 CSS 중첩기능을 구현했어야 했는데 다음은 어떻게 변환이 되어야 할까요?
그리고 각종 at-rule들과 복잡한 selector가 중첩이 되면 어떻게 할까요?
const myCss = css({
"nav li > &": {
"@media (prefers-color-scheme: dark)": {
_hover: {
background: "red"
}
}
}
});그래서 저는 중첩된 순서가 미리 정해져 있도록 RFC문서를 보충한 후에 기능을 구현했어요.
이제 위 코드는 명시적으로 다음과 같이 변환이 되어야 하고요,
export const myCss = style({
"@media": {
"(prefers-color-scheme: dark)": {
selectors: {
"nav li > &:hover": {
background: "red"
}
}
}
}
});훨씬 복잡한 상황도 중첩된 순서가 항상 같으므로 안정적인 출력이 가능해져요.
export const myCss = style({
// Level1: @layer
"@layer": {
"framework.layout": {
// Level2: @supports
"@supports": {
"gap: 1rem": {
// Level3: @media
"@media": {
"(prefers-color-scheme: dark) and (prefers-reduced-motion)": {
// Level4: @container
"@container": {
"(min-width: 500px)": {
// Level5: selectors
"selectors": {
"nav li > &:hover": {
background: "red"
}
}
}
}
}
}
}
}
}
}
});모아놓음 RFC문서만 보면 각종 기능과 설계를 한눈에 볼 수 있으므로 개발하기가 매우 편해진답니다.
정리하자면
RFC 문서: 기능 리스트와 설계, 각종 배경정보
In-source 테스트 코드: 실제 구현인 코드와 테스트가 함께
형태이고요,
이를 공정으로 생각하면
RFC: 기획-설계
TDD: 구현-테스트
로 깔끔하게 분할이 됩니다.
이게 정답이다!!라고 할 수는 없겠지만 몇달 쉬었다가 개발을 시작함에도 적응이 무척 쉽네요.
여러분도 RFC - TDD 프로세스로 작업해보시는 것은 어떨까요?
CSS Nesting RFC에서 중첩된 at-rules와 selector 기능이 모두 구현됐어요.
또한 방치되어 있던 의존성을 모두 업데이트 했습니다.
ESLint 설정도 flat config로 바꾸었어요.
CSS Nesting RFC가 끝나면 첫번째 목표인 "Natural CSS in the Typescript "가 이루어지는 셈이니 릴리즈까지는 단 2개의 기능만 남은 셈입니다.
그럼 다음주 출시를 목표로..!! 열심히 해보겠습니다.
담주에 만나요~~
혹시 개발에 관심이 있으시다면 댓글을 달아주시거나 alstjr7375@daum.net에 연락을 주셔도 좋습니다.
하단의 업보트와 깃허브 스타를 찍어주셔도 매우 큰 도움이 됩니다!!
Mincho
디자인시스템을 위한 CSS in JS 프레임워크
문지웅
ReadMagic: README 작성의 마법, 그리고 그 뒤의 이야기
안녕하세요, 프론트엔드 개발자 문지웅입니다.
오늘은 제가 최근에 런칭한 'ReadMagic'에 대해 이야기하려 합니다.
README 작성을 도와주는 이 도구의 탄생 과정과 그 과정에서 얻은 교훈들을 나누고 싶습니다.
모든 개발자가 공감하시겠지만, 프로젝트를 시작할 때마다 README 작성은 항상 필요한 일이었습니다. "이번에야말로 체계적으로 작성해야지"라고 다짐하지만, 매번 비슷한 내용을 반복해서 쓰는 자신을 발견하곤 했죠.
이런 고민 끝에 탄생한 것이 바로 ReadMagic입니다.
프로젝트의 기본 정보만 입력하면 구조화된 README 초안을 자동으로 생성해주는 웹 서비스입니다.
완벽주의 극복하기: 완벽한 README 템플릿을 만들려다 출시가 계속 미뤄졌습니다. 결국 "완벽함보다는 유용함"을 목표로 삼고 MVP(Minimum Viable Product)를 출시하기로 결정했어요.
AI 활용의 양면성: 초기에는 AI를 활용해 더 "똑똑한" README 생성을 구현하려 했습니다. 하지만, 과도한 AI 의존은 오히려 사용자의 창의성을 제한할 수 있다는 점을 깨달았습니다.
1. 프로젝트 정보 입력: 프로젝트 이름, 설명, 필요한 Node.js 버전, 주요 기능 등을 입력합니다.
2. 자동 생성: 입력된 정보를 바탕으로 README 초안을 작성합니다.
현재 ReadMagic은 기본적인 README 생성 기능을 제공하고 있습니다.
하지만 여기서 멈추지 않을 계획입니다.
향후 계획
생성 결과에 대한 커스터마이징 제공
다양한 프로젝트 유형별 템플릿 제공
사용자 커스텀 템플릿 저장 기능
ReadMagic을 개발하면서 가장 크게 느낀 점은 "문제 해결"이 개발의 핵심이라는 것입니다. 단순히 코드를 작성하는 것이 아니라, 실제 사용자의 고민을 해결하는 과정에서 진정한 가치가 생긴다는 것을 배웠습니다.
여러분도 ReadMagic을 사용해보시고, 여러분만의 문제 해결 도구를 만들어보는 건 어떨까요? 때로는 작은 아이디어가 큰 변화를 만들어낼 수 있습니다.
ReadMagic과 함께 더 나은 개발 문화를 만들어가길 희망합니다. 여러분의 의견과 제안을 언제나 환영합니다. 함께 성장해 나가요!
ReadMagic
ReadMe 초안을 빠르게 작성해주는 서비스
Doeon Kwon 권도언
대부분의 창업을 꿈꾸는 사람들은 처음부터 큰 비전과 이상적인 세상을 생각하고 실행에 옮기려고 한다. 비전있는 사람들이 보통 창업에 도전하는 경향도 있고, 실제로 많은 분들이 창업을 하려면 원대한 비전과 목표가 있어야만 할 수 있다는 생각을 하기도 한다. 하지만 이런 직관과 반대로, 작게 생각하고 작게 실행하는 것이 오히려 큰 목표를 달성하게 만든다.
Elad Gil이 2010년에 이 내용에 대한 글을 썼는데, 최근 다시 읽어보니 예전보다 더 많이 공감되었다. 왜냐면, 디스콰이엇을 하면서 자기만의 높은 비전, 이상적인 세상을 만들기 위해 창업에 도전한 분들을 많이 봤는데, 이들 대부분이 뜻대로 잘 안되어 포기하거나 힘들어하고 계시기 때문이다.
Elad Gil이 예시로 든 사례는 페이스북, 트위터, 구글이다.
페이스북
과거: 대학생들만 참여할 수 있는 invite-only 커뮤니티
현재: 전세계인들이 연결되는 SNS (페이스북, 인스타, 스레드)
트위터
과거: 그룹 문자 메시지 서비스
현재: 최신 정보들이 빠르게 전달되는 SNS
구글
과거: 웹 검색 엔진
현재: 전 세계의 청보를 체계화하고 접근을 유용하게 만드는 모든 분야 (검색, 지도, 책, 유튜브, 이메일, 드라이브, 안드로이드 등)
글에는 만약 페이스북이 처음부터 전세계인을 연결하려는 목표로 출발했다면? 이라는 가정을 세우고 이에 대한 결과를 얘기한다.
처음부터 누구나 가입할 수 있는 형태의 제품, GTM 전략을 실행했을 것. 하지만 대학교만 타겟했던 것과 달리 아마 아무도 가입하지 않았을 것이다.
처음부터 사람들이 연결되는 기능을 만들었을 것. 하지만 페이스북엔 내가 아는 사람이 없거나 연결되고 싶은 사람이 없어서 기능 개발에 시간과 돈을 낭비했을 것이다.
스케일업을 고려해 큰 기업의 VP, 리더급을 큰 비용을 들여 채용했을 것. 하지만 이들은 기업의 문화나 제품 로드맵, 방향성 들을 망치고 스케일은 시작도 못했을 것이다.
위 내용들 모두 공감된다. 여기에 내 생각을 더해보자면..
팀이 아무것에도 집중하지 못한다. 만들고자 하는 기능들, BM이 너무 많아서, 이것저것 하다가 결국 아무것도 만들어내지 못한다.
고객이 우리가 만들려는 것이 뭔지 이해하지 못한다. 추상적이거나 뜬구름잡는 소리라고 느끼고 지금 당장 나에게 어떤 가치를 줄지 알기 어렵다. 결국 다 이탈한다.
급변하는 상황들에 대처하기 어렵다. 창업이라는 것은 불확실성에 내던져지는 것이고, 어제 진실이라 생각한 것이 내일은 아니게 될 수도 있다. 근데 처음부터 장기적인 플랜을 세우면 쉽게 무너지고 방향을 다시 잡는데 시간이 오래 걸린다.
그렇다고 크게 생각하면 안되냐, 그것은 아니다. 크게 생각하되, 실행을 작게 하면 된다. 만약 내가 세계에서 가장 맛있는 디저트 브랜드를 만들고 싶다? 그러면 일단 사람들이 어떤 초콜릿 좋아하는지 물어보고, 초콜릿 만드는 법 배우면 된다. 전 세계 유튜브 크리에이터들을 연결하는 SNS를 만들고 싶다면? 일단 유튜버들 만나서 요즘 고민이 뭔지 듣고, 그걸 해소하는 컨텐츠를 만들어 올리면서 사람들을 모으는게 첫 번째다. 처음부터 기능 엄청 많은 앱 개발하고 디저트 브랜딩이나 제품 라인업부터 고민하는 게 아니라, 작은 것부터 하나씩 제대로 실행하는게 더 중요하다.