『데이터 중심 애플리케이션 설계』 🐷 , 사두기만 하고 몇 장 읽다 멈추신 분 계신가요? 좋은 기술서일수록 혼자 끝까지 읽기가 어렵습니다. 그래서 달레 스터디에서 8주 동안 한 권을 함께 끝까지 읽는 독서 스터디 1기를 모집합니다. 이 스터디에는 챕터 요약 발표가 없습니다. 매주 각자 흥미로웠던 부분, 깊이 파본 부분, 실무와 연결되는 부분을 짧은 메모로 남기고, 그중 함께 이야기하고 싶은 주제를 골라 깊게 나눕니다. "여기는 잘 이해가 안 됐다"도 충분히 좋은 이야기입니다. - 도서: 데이터 중심 애플리케이션 설계 (마틴 클레프만) - 기간: 8주 - 모집 인원: 10명 - 모집 기간: 10/7 ~ 10/14 23:59 KST 자세한 내용과 신청은 아래 링크에서 확인해 주세요. https://lnkd.in/gHdg8dXu #독서스터디 #DDIA #데이터중심애플리케이션설계 #백엔드 #분산시스템 #개발자스터디
About us
달레 스터디는 오픈소스 프로젝트를 매개로 한 협업 학습 커뮤니티이며, 주니어/예비 개발자들에게 실전 경험과 성장 기회를 제공하는 것을 사명으로 합니다. 회원들에게는 팀 프로젝트를 통한 실무 체험과 네트워킹의 장을 제공하고, 나아가 지속적인 오픈소스 생태계와 선순환 멘토 문화를 구축하는 것이 우리의 궁극적인 지향점입니다. 혼자서는 별 볼일 없어 보이는 개발자들도 함께 힘을 모으면 의미있고 영항력있는 결과물을 만들어낼 수 있다고 믿습니다. 달레 스터디는 특정 수준 이상의 실력자만 참여하는 엘리트 집단이 아닙니다. 주니어 개발자, 미드 레벨 개발자, 그리고 개발자를 꿈꾸는 예비 개발자까지 누구나 환영하는 포용적인 커뮤니티를 지향합니다. - 깃허브: https://github.com/DaleStudy - 디스코드: https://dales.link/discord - 웹사이트: https://dalestudy.com/
- Website
-
https://www.dalestudy.com/
External link for 달레 스터디
- Industry
- IT System Training and Support
- Company size
- 501-1,000 employees
- Type
- Educational
Updates
-
✍️ 블로그 스터디 2기를 모집합니다! 개발하면서 이런 생각을 해본 적 있으신가요? “이건 분명 내가 알고 있는 내용인데, 막상 다른 사람에게 설명하려니 어렵다.” 코드를 작성하고 기술을 사용하는 것과, 그 기술을 내 언어로 설명하는 것은 전혀 다른 경험입니다. 블로그에 글을 쓰다 보면 자연스럽게 이런 질문을 만나게 됩니다. “왜 이렇게 동작하지?” “이 방법을 선택한 이유는 뭘까?” “다른 방법과 비교하면 어떤 차이가 있을까?” “내가 실제로 겪었던 문제는 어떻게 해결했을까?” 그리고 그 질문에 답을 찾아가는 과정에서 평소에는 지나쳤던 것들을 다시 공부하게 됩니다. 그래서 블로그 스터디 2기를 시작합니다. 거창한 기술 글을 쓰는 스터디가 아닙니다. 이번 주에 새롭게 공부한 내용, 프로젝트를 진행하며 해결한 문제, 업무에서 경험한 시행착오, 관심 있는 기술을 직접 테스트해본 기록까지. 개발하면서 얻은 경험이라면 무엇이든 하나의 글이 될 수 있습니다. 📌 10주 동안 매주 한 편씩, 한 주간 학습/경험한 내용을 자기 블로그에 발행합니다 📌 발행한 글은 링크와 간단한 설명을 붙여 달레 스터디 커뮤니티에 공유합니다 📌 다양한 직군과 배경의 동료 멤버가 쓴 글을 서로 읽고 의견을 나누며 시야를 넓힙니다 블로그를 이제 시작하려는 분부터 꾸준함을 되찾고 싶은 경험자까지 누구나 환영합니다! 🗓 2기 모집 안내 - 모집 인원: 50명 내외 - 기간: 10주 - 운영 공간: 달레 스터디 디스코드 - 신청 방법: 아래 깃허브 디스커션에 댓글로 신청해주세요 👉 신청하러 가기: https://lnkd.in/gWcRkYn6 함께 성장하는 개발자 커뮤니티를 만들기 위해 커피챗과 모각코도 함께 진행하고 있으니 많은 관심 부탁드립니다. #Blog #블로그 #지식나눔 #자기계발
-
[ 블로그 스터디 10주차 베스트 글 ] 잘못되면 얼마가 드는지 아는 문제는 대충 풀 수 없습니다. 블로그 스터디 1기의 마지막 주에 고른 세 편은 모두 그 값을 아는 데서 시작합니다. 🥇 GeoIP DB의 불필요한 메모리 사용을 줄인 방법 Pyroscope로 살아 있는 힙을 보니 39GB 중 11.7GB가 embed.FS.ReadFile 한 곳에 잡혀 있었습니다. 바이너리에 embed한 72MB GeoIP DB를 ReadFile로 읽는 순간 힙에 복사본이 하나 더 생기고 reader가 그걸 계속 붙들고 있던 것인데, []byte에 직접 embed하는 것만으로 배포 구조를 건드리지 않고 live heap을 41% 줄였습니다. mmap과 나란히 재 본 뒤 가정이 아니라 측정 결과로 고른 점이 좋습니다. https://lnkd.in/gixgrCeg 🥈 [프로젝트] 점검 페이지는 장애 난 시스템 밖에 있어야 한다 점검 플래그를 백엔드에 두려다, 점검 화면이 필요한 바로 그 순간 판정 자체가 실패할 수 있다는 걸 깨닫는 데서 출발합니다. 그래서 플래그는 Vercel Edge Config에, 판정은 Next.js Middleware에, 스위치는 별도 프로젝트의 관리자 화면에 두고, Edge Config를 못 읽으면 점검 모드를 끄는 fail-open까지 정했습니다. "가장 중요한 결정은 코드를 어떻게 작성할지가 아니라 스위치를 어디에 둘지였다"는 문장이 글 전체를 요약합니다. https://lnkd.in/guEyNNXX 🥉 멱등성(idempotency) 있는 엔드포인트 설계 회사에서 고객 신용 보고서를 벤더에 요청하는 엔드포인트를 만들게 됐는데, 요청 한 번에 25불이 청구되니 같은 요청이 두 번 나가면 그대로 돈입니다. Idempotency-Key 헤더로 요청을 식별하고 처리 중이면 429, 완료됐으면 저장해 둔 응답을 그대로, 벤더 오류면 재시도 허용으로 갈랐습니다. 키는 같은데 본문이 다른 요청을 해시로 잡아 409로 막은 대목이 이번 주에 실제로 만들며 부딪힌 질문이라 좋습니다. https://lnkd.in/g9NwY55q 세 글을 나란히 놓고 보니 모두 실패의 값을 먼저 적어 둔 이야기였습니다. 메모리 글은 힙 39GB 중 11.7GB라는 숫자에서, 점검 페이지 글은 판정이 실패하는 순간 그 자체가 장애라는 시나리오에서, 멱등성 글은 요청 한 번에 25불이라는 청구서에서 출발합니다. 값을 모르는 문제는 미룰 수 있지만, 값을 아는 문제는 그럴 수 없으니까요. #달레스터디 #기술블로그 #개발자글쓰기 #블로그스터디
-
[ 블로그 스터디 9주차 베스트 글 ] 요즘은 어디서나 바꾸라는 말을 듣습니다. AI가 개발자를 대체할 거라고, 레거시는 걷어내라고, C++는 Rust로 옮기라고 합니다. 이번 주 달레 스터디에서 고른 세 편은 그 말을 그대로 받아쓰지 않았습니다. 🥇 경제학으로 살펴보는 AI 시대 개발자의 미래 GPT-6 소식에 스멀스멀 올라온 불안을 학부 때 배운 탄력성으로 풀어 본 글입니다. 노동 수요는 최종재 수요에서 파생된다는 힉스-마샬 법칙을 가져와, 소프트웨어 수요의 탄력성과 AI 대체 용이성 두 축으로 개발자 시장을 네 칸으로 나눕니다. 은행 계정계나 병원 EMR처럼 틀리면 치명적이고 법적 책임이 따르는 칸은 사람이 남고, 크롬 확장이나 카톡 봇처럼 수요는 늘지만 비개발자도 만들 수 있는 칸은 수요가 늘어도 개발자 몫은 아니라고 봅니다. 맬서스의 인구론이 틀렸어도 틀은 남았듯 예측의 쓸모는 맞히는 데 있지 않다는 마무리가 좋습니다. https://lnkd.in/gu-XFsH9 🥈 레거시 SOAP를 Spring Boot로 옮기며 배운 것들 — Apache CXF, JAX-WS 그리고 '계약'과 '비즈니스'의 분리 레거시 코드의 PaymentService를 열어 보니 익숙한 @Service가 아니라 @WebService였고, 그게 외부 시스템과 XML 구조를 약속한 WSDL 계약(SEI)이라는 데서 출발합니다. SOAP DTO와 결과코드 0000·1001이 비즈니스 로직까지 파고드는 구조를 피하려고 SEI → 변환만 하는 SOAP 어댑터 → JAX-WS import가 하나도 없는 애플리케이션 서비스로 세 겹을 나눴습니다. 테스트도 서비스를 직접 부르는 대신 JaxWsProxyFactoryBean으로 실제 HTTP와 XML 마샬링을 통과시켰습니다. WS-Security 없음, 승인 멱등성 없음, 외부가 WSDL을 먼저 주는 환경이면 Contract First가 낫다는 한계를 목록으로 적어둔 점이 좋습니다. https://lnkd.in/gXXNUNG5 🥉 Rust, Microsoft의 Tier-1 언어가 되다 Microsoft가 Rust를 C++, C#, TypeScript와 같은 줄에 올렸다는 GeekNews 소식을 정리한 글입니다. 핵심은 선언이 아니라 rustc_codegen_utc입니다. Rust 컴파일러를 LLVM 대신 Windows C++가 쓰는 MSVC 백엔드에 붙여, 디버깅·크래시 분석·Hotpatch 같은 기존 투자를 Rust가 그대로 물려받게 했습니다. Rust 1.90부터 자체 빌드에 쓰이고 내부 100개 넘는 저장소가 이 백엔드로 빌드 중이라고 합니다. 1년 전만 해도 "왜 그런 언어로 하냐"는 말을 들었다는 저자는, 그래도 전부 Rust로 바꾸자가 아니라 대체했을 때 성능이 나는 곳부터라는 입장을 붙여 둡니다. https://lnkd.in/gzmKzHsj 세 글을 나란히 놓고 보니 모두 무엇을 남기고 무엇을 바꿀지 가르는 이야기였습니다. 개발자 시장 글은 검증이 필요한 칸은 사람 몫으로 남기고 롱테일 틈새를 새로 파자고 하고, SOAP 글은 WSDL 계약은 함부로 못 건드리는 경계로 두되 그 안쪽은 프로토콜을 모르게 만들어 언제든 갈아끼울 수 있게 하고, Rust 글은 C++를 걷어내는 게 아니라 같은 백엔드 위에 나란히 두고 성능이 나는 곳부터 바꾸자고 합니다. 바꿀 것을 고르는 일은 결국 남길 것을 먼저 정하는 일이니까요. #달레스터디 #기술블로그 #개발자글쓰기
-
[ 블로그 스터디 8주차 베스트 글 ] 이번 주에도 달레 스터디에 다양한 글들이 올라왔습니다. 그중에서 세 편을 골라 소개합니다. 🥇 2026년 제5회 SW테스트 경진대회 참가 및 대상 수상 후기 2024년부터 해마다 나가던 대회에서 대상을 받은 후기입니다. 한 시트에서 셀이 밀리던 문제는 대분류별로 시트를 나눠 작업하고 마지막에 메인 시트로 병합하는 식으로 풀었고, 단순 CRUD가 반복되는 앱은 절차를 템플릿으로 만들어 키워드만 바꿔 넣는 방식으로 730개가량의 케이스를 뽑았습니다. 그런데 글의 무게는 수상보다 KPT 회고의 Problem에 실려 있습니다. 실망할까 봐 미리 기대를 낮춰 잡는 버릇을 스스로 짚어내고, 충분히 했으면 좋은 결과를 기대해도 된다고 적어둔 대목이 오래 남습니다. https://lnkd.in/ge75xxdD 🥈 Go 서버의 할당량을 37% 줄인 두 번의 작은 수정 Pyroscope로 운영 중인 Go 서버를 들여다보니 요청마다 새로 만드는 gzip writer가 전체 누적 할당의 40%를 차지하고 있었습니다. sync.Pool에서 빌려 Reset으로 재사용하고, 반납 직전에 출력 대상을 io.Discard로 바꿔 직전 요청의 버퍼가 pool에 딸려 남지 않게 했습니다. 캐시 hit마다 []byte를 통째로 복사하던 한 줄도 읽기 전용임을 확인한 뒤 원본을 그대로 넘기도록 바꿨습니다. 카나리 기준 요청당 할당량은 37%, CPU는 11% 줄었습니다. alloc_space와 inuse_space를 구분하지 않으면 "메모리를 1TB 썼다"는 잘못된 결론에 이르기 쉽다는 지적, 그리고 더 공격적인 세 번째 최적화는 GC 비용을 키워 롤백했다고 적어둔 부분이 눈여겨볼 만합니다. https://lnkd.in/gc6m6Cgy 🥉 Index를 만들어도 PostgreSQL은 사용하지 않을 수 있다 어제까지 멀쩡하던 조회가 갑자기 수십 초씩 걸리기 시작한 사고를 다룹니다. EXPLAIN ANALYZE로 열어 보니 JOIN 컬럼에 인덱스가 버젓이 있는데도 플래너는 Seq Scan에 Hash Join을 고르고 있었습니다. 데이터가 불어나 조건에 맞는 행이 많아지자 인덱스보다 순차 스캔이 싸다고 계산한 것입니다. Partial Index를 하나 더 만드는 대신 LATERAL JOIN으로 조인 순서를 뒤집어 fov 범위를 먼저 좁히고 defect는 기존 인덱스로만 찍어 오게 했더니 31초가 1.1초로 내려왔습니다. 인덱스가 있는 것과 쿼리가 그 인덱스를 쓰는 것은 별개라는 말을 사례로 보여줍니다. https://lnkd.in/gxYzsU5s 세 글을 나란히 놓고 보니 모두 짐작 대신 직접 들여다본 이야기였습니다. Go 서버는 프로파일러를 켜고서야 writer 하나가 할당의 40%인 걸 알았고, PostgreSQL은 실행 계획을 펼치고서야 인덱스가 놀고 있는 걸 알았고, 경진대회 후기는 대상을 받고서야 낮춰 잡은 기대가 실제 역량과 얼마나 달랐는지 알았습니다. 그렇겠거니 하고 넘긴 것들은 열어 보면 대개 다르게 생겨 있으니까요. #달레스터디 #기술블로그 #개발자글쓰기 #블로그스터디
-
달레 스터디가 OpenAI의 지원을 받게 되었습니다 🎉 OpenAI의 Codex for Open Source 프로그램에 선정되어, Codex를 이용할 수 있는 ChatGPT Pro를 지원 받게 되었습니다. 달레 스터디는 오픈 소스 프로젝트를 중심으로 현업과 유사한 협업 경험을 제공하는 개발자 커뮤니티입니다. 팀을 이루어 설계, 구현, 테스트, 리뷰, 배포까지 직접 경험하고, 완성된 프로젝트는 실제로 동작하는 서비스로 공개합니다. 깃허브와 디스코드에서 소통하고 협업하며, 혼자서는 얻기 힘든 실무 경험을 함께 쌓습니다. 현재 리트코드 스터디와 달레 UI 디자인 시스템을 비롯해 10여 개의 오픈 소스 프로젝트가 진행되고 있습니다. 프로젝트를 꾸준히 이어 가려면 코드 작성뿐 아니라 변경 사항 검토, 릴리스 관리, 품질 유지에도 많은 시간과 노력이 필요합니다. 이 모든 유지보수는 운영진과 기여자들의 100% 자발적인 참여로 이루어지고 있기에, 이들의 소중한 시간과 노력을 조금이라도 덜어줄 방법을 늘 고민해 왔습니다. 이번 지원을 계기로 Codex를 프로젝트 개발과 반복적인 커뮤니티 운영 업무에 적극 활용할 계획입니다. 그렇게 확보한 시간은 새로운 기여자의 질문에 답하고, 동료들과 설계를 고민하고, 서로의 성장을 돕는 데 더 많이 쓰고 싶습니다. 그 과정에서 겪은 시행착오와 배운 점도 꾸준히 나누겠습니다. 함께 코드를 작성하고 리뷰해 주신 기여자 여러분, 달레 스터디를 꾸준히 후원해 주신 분들, 그리고 이번 지원을 제공한 OpenAI에 감사드립니다. 🙏 #달레스터디 #DaleStudy #OpenSource #Codex
-
-
[ 블로그 스터디 7주차 베스트 글 ] 이번 주에도 달레 스터디에 다양한 글들이 올라왔습니다. 그중에서 세 편을 골라 소개합니다. 🥇 다형성 연관관계로 알림 기능과 이벤트 로그 테이블 설계하기 여러 도메인의 레코드를 한 테이블에 쌓아야 하는 요구를 두고 도메인별 분리, Exclusive arc, 다형성 연관관계를 나란히 놓고 비교합니다. 도메인이 계속 늘어나는 상황에서는 object_type 값만 추가하면 되는 쪽을 택했고, 대신 참조 무결성을 DB가 아니라 애플리케이션에서 지키기로 했다고 분명히 밝힙니다. 쓰기 중심인 이벤트 로그와 읽기 중심인 알림에 서로 다른 인덱스와 역정규화 전략을 적용한 부분도 눈여겨볼 만합니다. https://lnkd.in/gWXNMg_E 🥈 트랜잭션 Isolation 이해하기: 동시에 실행되는 트랜잭션을 다루는 방법 DDIA 2판의 트랜잭션 장을 따라가며 격리 수준이 무엇을 보장하고 무엇은 보장하지 않는지를 정리합니다. 계좌 이체 예제로 커밋된 데이터만 읽어도 일관성이 깨질 수 있다는 걸 보여주고, 병원 당직 예제로는 서로 다른 행을 고치는 트랜잭션 사이에서도 Write Skew가 생긴다는 점까지 짚습니다. 격리 수준을 이름으로만 외우고 있었다면 한 번 짚고 넘어갈 만합니다. https://lnkd.in/gQPY4zkK 🥉 [프로젝트] GCP 단일 VM에 블루그린 배포를 올렸다 — 무중단은 성공했지만 재부팅하면 장애가 났다 배포는 무중단으로 잘 끝났는데 VM을 재부팅하니 이틀 전 이미지가 올라와 스키마가 맞지 않아 기동에 실패한 사고를 다룹니다. 성공한 이미지 버전을 데이터 디스크에 남겨 재부팅 때 되찾고, systemd의 RequiresMountsFor로 마운트가 실패하면 아예 부팅을 멈추게 했습니다. 저비용 구조라 VM 장애까지는 못 막는다는 한계를 스스로 적어둔 점에 믿음이 갑니다. https://lnkd.in/gpTEdVr5 세 글을 나란히 놓고 보니 공교롭게도 모두 무엇을 보장하고 무엇은 보장하지 않는지 선을 긋는 이야기였습니다. 다형성 연관관계는 참조 무결성을 DB에 맡기지 않겠다고 정하고, 격리 수준은 커밋된 값만 읽어도 막지 못하는 게 있다고 말하고, 블루그린 배포는 배포 중은 지켜도 재부팅까지는 못 지킨다고 적어둡니다. 정상 경로만 보고 그은 선은 대체로 사고가 나고 나서야 잘못된 걸 알게 되니까요. #달레스터디 #기술블로그 #개발자글쓰기 #블로그스터디
-
[ 블로그 스터디 6주차 베스트 글 ] 이번 주에도 달레 스터디에 다양한 글들이 올라왔습니다. 그중 멤버들의 추천과 댓글을 가장 많이 받은 세 편을 소개합니다. 🥇 왜 책임님은 매달초 dev를 master로 엎어칠까? 5년 전 갈라진 뒤 dev와 release 브랜치에 각각 커밋이 쌓여온 시스템을 인수인계받아, 두 브랜치를 하나씩 정리해 나가는 과정을 기록한 글입니다. 매달 초 dev를 master로 덮어쓰는 관행이 왜 생겼는지 거슬러 올라가고, 3-dot diff를 활용해 두 브랜치의 실제 차이를 가려냅니다. "이제 30% 정도 왔다"는 담담한 후기가 오히려 더 와닿습니다. https://lnkd.in/gmXAJJtb 🥈 [운영] 코드만 옮기면 끝일까? SVN 커밋 이력을 보존하며 GitLab로 마이그레이션한 과정 코드만 복사해 옮기면 과거 커밋 이력이 사라져 장애의 원인을 추적하기 어려워진다는 문제의식에서 출발합니다. git-svn으로 리비전을 커밋으로 변환하고 작성자 매핑을 별도로 관리했으며, SSL 검증을 끄는 우회 대신 CA 인증서를 정상적으로 등록하는 길을 택했습니다. 빠르게 이전하는 것보다 언제든 다시 검증할 수 있는 상태를 만드는 데 우선순위를 둔 판단이 인상적입니다. https://lnkd.in/gfgydcxF 🥉 코드 컨벤션을 만들기 전에 했어야 하는 질문 레거시의 복잡함을 규칙으로 풀어보려다 실패한 경험에서 시작하는 글입니다. "규칙을 어떻게 강제할까"가 아니라 "이 규칙으로 무엇을 해결하려 했나"를 먼저 물었어야 했다고 말합니다. 형식의 문제와 의도의 문제를 구분하고, 현재 상태를 측정한 뒤 조금씩 개선해 나가는 접근이 설득력 있습니다. https://lnkd.in/gUKP5Vv3 세 글을 나란히 놓고 보니 공교롭게도 모두 물려받은 것을 어떻게 다룰 것인가에 대한 이야기였습니다. 5년 동안 벌어진 브랜치, SVN에 쌓인 커밋 이력, 아무도 이유를 모르는 코드 규칙. 세 분 모두 눈앞의 복잡함을 바로 걷어내기보다, 먼저 왜 지금의 모습이 되었는지 이해하는 데서 시작했습니다. 레거시를 다룬다는 건 어쩌면 오래된 것을 지우는 일이 아니라, 그 안에 쌓인 맥락을 이해하면서 더 나은 상태로 조금씩 옮겨가는 일인지도 모르겠습니다. #달레스터디 #기술블로그 #개발자글쓰기 #블로그스터디
-
📣 Dale UI 디자인 시스템을 함께 만들어갈 디자이너를 찾습니다! Dale UI는 한국어 사용자 경험을 최우선으로 고려한 접근성 높은 오픈소스 디자인 시스템입니다. 디자이너와 개발자가 함께 컴포넌트의 사용성과 인터페이스를 고민하고, Figma에서의 디자인이 실제 React 컴포넌트로 구현되고 배포되는 과정까지 함께 만들어가고 있어요. 올해 정식 버전을 릴리즈한 이후에도 꾸준히 새로운 컴포넌트와 기능을 선보이고 있으며, 실제 사용자들의 피드백과 외부 기여가 이어지는 오픈소스 디자인 시스템으로 성장하고 있습니다.✨ 새롭게 합류하실 디자이너분과도 단순히 화면을 디자인하는 것을 넘어, 좋은 디자인 시스템이 무엇인지 함께 고민하고 실제 오픈소스 결과물로 만들어가고 싶습니다. 🎨 이런 일을 함께해요 • UI 컴포넌트를 설계하고 기존 컴포넌트를 개선해요. • 개발자와 함께 UI/UX, 컴포넌트 스펙과 인터랙션을 논의해요. • 디자인 토큰과 디자인 시스템 가이드를 함께 발전시켜요. • Figma에서 설계한 디자인이 실제 구현까지 일관되게 이어질 수 있도록 함께 고민해요. • 한국어 사용자 경험과 접근성을 고려해 디자인 시스템의 기준과 원칙을 함께 만들어가요. 🙌 이런 분과 함께하고 싶어요 • UI/UX와 디자인 시스템에 관심이 있으신 분 • 화면 단위의 디자인을 넘어 컴포넌트와 시스템 단위로 고민하는 것을 좋아하시는 분 • 일관성, 재사용성, 접근성 등을 고려해 디자인하는 과정에 관심이 있으신 분 • 개발자와 적극적으로 의견을 나누며 디자인을 실제 구현까지 발전시키는 과정을 즐기시는 분 • 사용자와 기여자의 피드백을 바탕으로 함께 개선해나가는 과정에 관심이 있으신 분 • 한국 맥락에서 자주 사용되는 컴포넌트의 특징이나 패턴에 대해 고민해보신 분 디자인 시스템이나 오픈소스 경험이 없더라도, 함께 배우고 고민하며 만들어가고 싶은 분이라면 환영합니다! 🌱 이런 경험을 할 수 있어요 • 성장 중인 오픈소스 디자인 시스템의 원칙과 방향을 함께 만들어가는 경험 • Figma의 디자인이 실제로 구현되고 배포되기까지 개발자와 긴밀하게 협업하는 경험 • 실제 사용자와 외부 기여자의 피드백을 바탕으로 디자인을 지속적으로 개선하는 경험 • 디자인 의사결정의 배경과 결과를 공개된 프로젝트에 기록하고 실제 기여로 남기는 경험 • 오픈소스 환경에서 다양한 의견을 조율하며 디자인 시스템을 함께 운영하는 경험 💻 이렇게 활동하고 있어요 Dale UI는 100% 온라인 비대면으로 운영되는 오픈소스 프로젝트입니다. GitHub Projects를 중심으로 작업을 관리하고 Discord에서 소통하며, 각자의 본업과 일정을 고려해 자율적으로 참여하고 있습니다. 매주 토요일 오전 9시 30분(KST)에 온라인 팀 미팅을 진행하며, 미팅 시간은 팀원들의 일정에 따라 유동적으로 조율 가능합니다. 관심 있으시다면 부담 없이 지원해주세요! 함께 이야기 나눠보고 서로 잘 맞는 프로젝트인지 알아가면 좋겠습니다! 👉 지원하기: https://lnkd.in/gXrhae8x Dale UI가 실제로 어떻게 만들어지고 있는지 궁금하다면 아래 링크에서 확인해보세요! • 웹사이트: https://www.daleui.com/ • GitHub: https://lnkd.in/gTtX945g • Figma UI Kit: https://lnkd.in/gkBjSKYE • Storybook: https://lnkd.in/gxvHyCFR • Wiki: https://lnkd.in/gtF8_7dZ
-
[ 블로그 스터디 5주차 베스트 글 ] 이번 주에도 달레 스터디에 다양한 글들이 올라왔습니다. 커뮤니티 내에서 가장 반응이 좋았던 세 편을 소개합니다. 🥇서로 다른 Linux·Windows 로그를 하나의 운영 원칙으로: AWS S3 로그 적재 자동화 설계기 Linux는 Bash와 systemd로, Windows는 PowerShell과 작업 스케줄러로 서로 다르게 구현하면서도 선별, 압축, 검증, 업로드, 정리라는 동일한 흐름을 유지한 과정을 담고 있습니다. 특히 모든 영역이 성공했을 때만 원본을 삭제하도록 조건을 걸어, 중간에 실패하더라도 데이터를 잃지 않게 만든 판단이 인상적입니다. https://lnkd.in/gigBshvi 🥈 PostgreSQL의 idle in transaction이란? 운영 중 종종 마주치지만 그냥 지나치기 쉬운 세션 상태를, active와 idle부터 차근차근 구분하며 정리합니다. 결국 원인은 raw query나 ORM에서 커밋을 놓친 코드였다는 점에서, 자동 커밋에 익숙한 환경에서 벗어났을 때 무엇부터 확인해야 하는지 알려주는 글입니다. https://lnkd.in/gvVPArrp 🥉 Defuddle의 추출 파이프라인 이해하기 웹 페이지에서 본문만 골라내는 라이브러리가 LLM 없이 DOM 분석만으로 어떻게 동작하는지 뜯어봅니다. 후보 영역마다 점수를 매기고, 추출된 본문이 너무 짧으면 셀렉터를 과하게 제거한 것인지 숨겨진 래퍼 때문인지 목록을 잘못 고른 것인지 각각 다른 가설을 세워 재시도하는 구조를 읽어낸 부분이 특히 좋았습니다. 세 글을 나란히 놓고 보니 공교롭게도 모두 실패를 어떻게 다룰 것인가에 대한 이야기였습니다. 실패를 피하는 것보다 실패했을 때 어떻게 대응할지 고민하고, 그 시행착오를 기록으로 남기는 과정이 인상적이었습니다. 이번 주에는 특히 댓글로 피드백을 주고받으며 글이 보완되고 더 좋아지는 과정도 볼 수 있었습니다. 좋은 글을 쓰는 것뿐 아니라 서로의 글을 읽고 더 나은 글을 함께 만들어가는 것, 그것이 우리가 함께 스터디를 하는 이유가 아닐까요? #달레스터디 #기술블로그 #개발자글쓰기 #블로그스터디