Jaeyeol Lee (a.k.a. kodingwarrior) :vim:'s Avatar

Jaeyeol Lee (a.k.a. kodingwarrior) :vim:

@kodingwarrior.social.silicon.moe.ap.brid.gy

자바가 아닌 백엔드를 하면서 삐딱선을 타는 풀스택개발자 🌉 bridged from https://social.silicon.moe/@kodingwarrior on the fediverse by https://fed.brid.gy/

29 Followers  |  11 Following  |  10 Posts  |  Joined: 18.10.2024  |  3.0305

Latest posts by kodingwarrior.social.silicon.moe.ap.brid.gy on Bluesky

브라우저 스터디 기록 (3) Note 이 글은 Web Browser Engineering 을 독학하면서 시도했던 것들을 의식의 흐름대로 남긴 흔적입니다. TL;DR - Chapter 3 연습문제 풀이를 보고 싶다면 여기서 확인할 수 있다. Chapter 3는 좀 빡세다는 느낌이 들었다. 이 글을 작성하는 시점에는 Chapter 4까지 이미 끝내놓은 상태이긴 하지만, 런타임 환경마다 각자 다르게 동작하는 폰트 렌더링이라던가 후술할 **일부 연습문제** 가 굉장히 골치가 아팠던 것으로 기억한다. 그만큼 텍스트 레이아웃이라는 심연히 굉장히 골때리다는 것이고, "폰트렌더링과 씨름했던 사람들은 어떤 싸움을 해온 것인가..." 라는 생각이 들곤 했다. Chapter 2에서는 글자를 하나씩 하나씩 고정된 간격으로 렌더링했었다. 고정폭 글자 기준으로는 이렇게 해도 문제가 없긴 하지만, 가변폭 글자 기준으로는 가독성이 굉장히 떨어진다. 예를 들자면, a 이라는 글자의 폭이 다르고, l 이라는 글자의 폭이 다르다. 그리고, 단어를 구성하는 각 글자의 폭을 합친 값과 단어 자체의 폭도 값이 다르다. 그래서, 텍스트 자체를 렌더링할때는 단어 단위로 렌더링하는 편이 좀 더 정밀하다고 볼 수 있다. 그리고, 여러가지 폰트가 섞여있는 상황에서 글자가 올바르게 배치되도록 하기 위해서 baseline, ascent, descent라는 개념이 있다. 이 세 가지는 말하자면 **글자가 어디에 ‘앉는지’와 ‘얼마나 위아래로 뻗는지’를 결정하는 기준선들** 이다. * **baseline** 은 모든 글자가 공통으로 맞춰야 하는 “바닥선”이다. 대부분의 글자는 이 선 위에 앉아 있다. * **ascent** 는 글자가 위로 얼마나 뻗는지를 나타내는 값이다. 예를 들어 “h”나 “b” 같은 글자는 베이스라인 위로 높게 올라가므로 ascent 값이 크다. * **descent** 는 반대로 글자가 아래로 얼마나 내려가는지를 나타낸다. “p”나 “g”, “y”처럼 꼬리가 밑으로 내려가는 글자들이 descent를 가진다. 이걸 눈으로 보면 아주 단순해 보이지만, 렌더러 입장에서는 꽤 골치 아픈 개념이다. 왜냐면, 폰트마다 ascent와 descent의 비율이 다르고, 심지어 같은 폰트라도 굵기(weight)나 스타일(italic)에 따라 기준선이 조금씩 달라지기 때문이다. 그래서 브라우저는 단순히 “텍스트를 그린다”기보다는, 각 글자가 가진 메트릭 값을 모두 고려해서 줄 전체가 시각적으로 균형 잡히도록 맞춰야 한다. 우리가 평소에 아무렇지 않게 읽던 한 줄의 텍스트가 사실 꽤 정교한 계산 위에서 표시된다는 걸 알 수 있다. 그냥 “글자가 줄 맞춰진다”는 게 아니라, 각 문자의 메트릭 값이 조합되어 시각적으로 균형을 이루도록 배치되는 것이다. 이렇게 각 글자의 형태와 위치를 조정해 실제 표시될 글자(glyph)로 변환하는 일련의 과정을 **shaping** 이라고 한다. Chapter 3에서는 단어 단위로 렌더링하기 전에 Shaping 하는 과정을 소개한다. ## 폰트 렌더링이라는 심연 이 교재를 Linux/macOS 각각 다른 기기를 번갈아가면서 실습하는 사람은 이미 실감했을 것인데, font 글자의 가로폭을 계산하는 과정이 굉장히 느리다. 사실 이것은 tkinter 자체의 구현이 문제인데, tkinter에서 font.measure 함수를 호출할때 런타임마다 동작하는 방식이 다르다. macOS 구현체는 CoreText(소스코드는 비공개)라는 라이브러리에 내장된 측정 함수를 그대로 가져다 쓰기 때문에, 측정이 거의 네이티브라고 볼 수 있을 정도로 굉장히 빠르다. 하지만, Linux는....? 폰트 정보를 가져오고 측정함수를 호출하기 위해 X 서버를 거쳐야 하기 때문에, 성능이 몇배는 차이가 난다. 여기서 큰 차이를 만들어낸다. 실습이라는게 되고 안되고가 나뉠 정도로. Linux 환경에서는 화면을 매번 렌더링할 때마다 너무 느려서 실습을 포기할 정도가 될 수 밖에 없는데, 이건 정상적인 실습환경이라고 볼 수 없다. 그럼에도 불구하고, 방법은 있다. 바로, 브라우저에서 처음 렌더링하는 시점에, (폰트 패밀리, 폰트 크기, 폰트 스타일) 을 키로 활용하여서 각각에 매칭되는 가변폭 글자 각각의 길이를 미리 측정해서 어딘가에다가 캐싱해두는 것이다. 렌더링 루프에서 실시간으로 `font.measure()`를 호출하기 전에 미리 캐싱해두는 것이다. 그리고 단어의 길이를 측정할때는 단어를 구성하는 각 문자의 가로폭을 합치는 식으로 계산하면 된다. 예시 코드는 아래와 같다. from dataclasses import dataclass, field import tkinter.font @dataclass class FontMeasurer: cache: dict[tuple[float, str, str, str], dict[str, float]] = field(default_factory=dict) fixed_cjk_width: dict[tuple[float, str, str, str], float] = field(default_factory=dict) def _font_key(self, font: tkinter.font.Font): return ( font.cget("size"), font.cget("weight"), font.cget("slant"), font.cget("family"), ) def _is_cjk(self, ch: str) -> bool: code = ord(ch) return ( 0x4E00 <= code <= 0x9FFF or # Kanji 0xAC00 <= code <= 0xD7A3 or # Hangul 0x3040 <= code <= 0x30FF or # hiragana, katakana 0x31F0 <= code <= 0x31FF or # katakana extension 0x3400 <= code <= 0x4DBF or # CJK extension A 0xFF00 <= code <= 0xFF60 # Fullwidth roman characters and halfwidth katakana ) def _prefetch_ascii_widths(self, font: tkinter.font.Font, cache: dict[str, float]): """Prefetch widths for common ASCII characters.""" ascii_chars = ( [chr(i) for i in range(32, 127)] # printable ASCII ) for ch in ascii_chars: if ch not in cache: cache[ch] = font.measure(ch) def measure(self, font: tkinter.font.Font, text: str) -> float: if not text: return 0.0 key = self._font_key(font) cache = self.cache.setdefault(key, {}) # Prefetch widths for common ASCII characters (only once) if " " not in cache: self._prefetch_ascii_widths(font, cache) # Initialize fixed CJK width if not already done if key not in self.fixed_cjk_width: self.fixed_cjk_width[key] = font.measure("가") result = cache.get(text) if result is not None: return result # Single character case if len(text) == 1: if text not in cache: cache[text] = ( self.fixed_cjk_width[key] if self._is_cjk(text) else font.measure(text) ) return cache[text] # Multi-character case width = 0.0 for ch in text: w = cache.get(ch) if w is None: w = ( self.fixed_cjk_width[key] if self._is_cjk(ch) else font.measure(ch) ) cache[ch] = w width += w cache[text] = width return width font_measurer = FontMeasurer() 이는 인메모리에 접근해서 계산하는 것이기 때문에 X 서버를 거치는 것보다 굉장히 빠르다. 그리고, 일부 단어는 빈번하게 등장할 수 있기 때문에 렌더링하는 성능은 더 올라갈 수 밖에 없다. 물론 이것은 근본적인 해결책은 아닐 수 있다. 아까 언급했듯이, 가변폭 글자 각각의 가로폭을 합치는 것과 단어 자체의 엄밀한 가로폭은 다르다. 하지만, 브라우저가 동작하는걸 눈으로 확인하기도 어려운 상황에서 자연스러운 속도로 렌더링되게 한다면 이는 감당이 가능한 비용이다. 이 프로젝트의 목표가 “브라우저의 동작을 눈으로 직접 확인해보는 것”이라는 점을 고려하면, 속도와 정밀도 사이의 이 정도 타협은 충분히 감당 가능한 수준이다. 참고로, macOS는 위와 같이 캐싱을 굳이 하지 않아도 빠르다(.....) 실제 브라우저들은 이 문제를 훨씬 더 정교하게 다룬다. 예를 들어 크로미움(Chromium)은 `HarfBuzz` 라는 오픈소스 라이브러리를 내장해, 플랫폼에 상관없이 동일한 shaping과 측정 알고리즘을 사용한다. 덕분에 Linux에서도 macOS와 거의 같은 속도로 텍스트를 렌더링할 수 있다 ## 연습문제 풀이 3.1(중앙정렬)의 경우, 2.5(ltr 지원)에서 가로 넓이를 계산했었다면 어렵지 않게 풀 수 있다. 3.3(`<abbr>` 태그 지원)는 그냥 문제의 요구사항대로 upper case로 만들어주는 것만 신경써주면 된다. 3.4(soft-hyphen 지원) 의 경우, `current_width + w`가 `screen_width`를 넘어서는 시점에 어느 부분부터 자를지 계산만 잘해주고 다음 행으로 개행시키면 된다. ### 연습문제 3.2 : `<sup>`, `<sub>` 태그 지원 `<sup>`와 `<sub>`는 단순히 글자 크기를 조정하는 태그가 아니라, 줄의 기준선(baseline) 자체를 움직이는 태그다. 같은 줄 안에서도 글자가 서로 다른 높이에 놓일 수 있기 때문에, 단순히 y좌표를 더하거나 빼는 식으로 처리하면 줄 전체가 어긋나 버린다. 이번 구현에서는 이러한 문제를 해결하기 위해 기준선의 변화를 **스택(stack)** 으로 관리했다. `BufferLine`의 `context_stack`은 `<sup>`나 `<sub>`가 열릴 때마다 새로운 기준선 정보를 push하고, 닫힐 때 pop하여 복원하는 방식으로 작동한다. `<sup>`은 현재 폰트의 `ascent`를 기준으로 약 1/4만큼 위로, `<sub>`은 `descent`를 기준으로 약 1/4만큼 아래로 이동하며, 이렇게 쌓이는 컨텍스트 덕분에 첨자가 중첩되더라도 각 글자의 상대적인 높이를 정확히 계산할 수 있다. 이 구조의 장점은 첨자 내부에서도 폰트 관련 태그를 자유롭게 섞어 쓸 수 있다는 점이다. 예를 들어 `<sup>` 안에서 `<big>`, `<small>`, `<b>`(또는 `<strong>`), `<i>` 같은 태그가 들어와도 기준선이 흔들리지 않는다. 폰트 크기나 굵기, 스타일 변경은 `VerticalAlignContext` 안에서만 영향을 주기 때문에, 텍스트의 세로 위치는 여전히 안정적으로 유지된다. 실제로 `<sup><big>Text</big></sup>`처럼 크기를 키우거나 줄이더라도, 글자는 원래의 기준선 위에서 자연스럽게 정렬된다. 이 덕분에 폰트 스타일과 세로 정렬이 서로 간섭하지 않으면서도, 브라우저와 비슷한 안정적인 렌더링 결과를 얻을 수 있다. 줄이 끝날 때(`flush()`)는 스택에 쌓인 글자들의 상대적인 y좌표를 바탕으로 줄 전체의 높이를 계산한다. 흥미로운 점은, 기준선 컨텍스트가 줄 경계에서 바로 사라지지 않는다는 것이다. `<sup>`가 한 줄에서 열리고 다음 줄에서 닫히는 경우에도 이전의 기준선 상태가 그대로 유지되어, 여러 줄에 걸친 첨자 구조가 자연스럽게 이어진다. `BufferLine`은 스택이 완전히 비었을 때만 기준선을 0으로 복원하기 때문에, 각 줄의 높이는 독립적으로 계산되면서도 전체 문맥은 유지된다. 이런 구조 덕분에 깊은 중첩이나 복잡한 폰트 조합이 등장하더라도, 텍스트 레이아웃은 줄과 줄 사이에서 끊기지 않고 매끄럽게 이어진다. 예시 코드는 아래와 같다. class BufferLine: words: list[tuple[float, float, str, tkinter.font.Font]] = field(default_factory=list) baseline: float = 0.0 current_baseline: float = 0.0 context_stack: list[VerticalAlignContext] = field(default_factory=list) def clear(self): self.words.clear() def is_empty(self) -> bool: return len(self.words) == 0 @property def previous_baseline(self) -> float: if not self.context_stack: return 0 return self.context_stack[-1].relative_baseline_y def add_word(self, *, x: float, font: tkinter.font.Font, word: str): ... def calculate_bounds(self) -> tuple[float, float]: ... def add_context(self, context: VerticalAlignContext): self.context_stack.append(context) self.current_baseline = context.relative_baseline_y def pop_context(self) -> VerticalAlignContext: if not self.context_stack: raise RuntimeError("No context to pop") context = self.context_stack.pop() if self.context_stack: self.current_baseline = self.context_stack[-1].relative_baseline_y else: self.current_baseline = 0.0 return context class Layout: def handle_tag(tag: str): ... elif tag == 'sup': current_font = self.get_font(self.size, self.font_weight, self.style) metrics = current_font.metrics() ascent = metrics["ascent"] baseline_y = self.buffer_line.previous_baseline - int(ascent * 0.25) self.buffer_line.add_context( VerticalAlignContext( restore_size=self.size, relative_baseline_y=baseline_y, weight=self.font_weight, style=self.style ) ) previous_size = self.size self.size = int(previous_size * 0.75) elif tag == "sub": current_font = self.get_font(self.size, self.font_weight, self.style) metrics = current_font.metrics() descent = metrics["descent"] baseline_y = self.buffer_line.previous_baseline + int(descent * 0.25) self.buffer_line.add_context( VerticalAlignContext( restore_size=self.size, relative_baseline_y=baseline_y, weight=self.font_weight, style=self.style ) ) previous_size = self.size self.size = int(previous_size * 0.75) elif tag == '/sup': context = self.buffer_line.pop_context() self.size = int(context.restore_size) elif tag == '/sub': context = self.buffer_line.pop_context() self.size = int(context.restore_size) ### 연습문제 3.5 : `<pre>` 태그 지원 요구사항은 오히려 3.2에서 `<sup>` / `<sub>` 지원하는 것보다 훨씬 간결하다. `<pre>` 태그는 공백과 개행을 그대로 유지해야 하는데, 일반 텍스트 렌더링처럼 단어 단위로 쪼개거나 공백을 합치면 이 특성이 깨진다. 그래서 `<pre>`가 열리면 `pre_tag_depth`를 1 증가시켜 “pre 텍스트 모드”임을 표시하고, 이 상태에서는 단어가 아닌 **라인 단위** 로 텍스트를 처리하도록 했다. `splitlines(keepends=True)`로 줄바꿈 문자를 포함해 순회하며 각 줄 끝에서 `flush()`를 호출하면, 원본의 줄 구조와 들여쓰기가 그대로 보존된다. 닫히는 태그를 만나면 `pre_tag_depth`를 1 감소시켜 다시 일반 렌더링 모드로 복귀한다. 크게 보면 이 정도 차이만 있다. if self.pre_tag_depth > 0: # pre 태그 안에 들어갔을 때 처리하는 방식. (단어 단위가 아닌 줄 단위로 처리한다.) lines = tree.text.splitlines(keepends=True) for line in lines: self.process_word(line) if line.endswith('\n'): self.flush() else: # 기존의 처리 방식 for word in tree.text.split(): self.process_word( word if not self.small_caps else word.upper() )
09.11.2025 01:33 — 👍 0    🔁 0    💬 0    📌 0
Composer on iPhanpy, showing a prompt asking user if would like to access the Camera.

Composer on iPhanpy, showing a prompt asking user if would like to access the Camera.

iPhanpy app in the iOS app switcher. Phanpy PWA is behind it.

iPhanpy app in the iOS app switcher. Phanpy PWA is behind it.

Testing uh… iPhanpy.

Built on my machine, running this on my iPhone 13 mini. @fantinel

Repo: https://github.com/matfantinel/iphanpy

27.10.2025 01:23 — 👍 0    🔁 1    💬 1    📌 0
Preview
11年ぶりに「Sleipnir Mobile」が大型アップデート。新たにスクラップブック機能を搭載 スクロールするだけのタブ高速切り替えも フェンリル株式会社は10月15日、モバイルブラウザーアプリ「Sleipnir Mobile」のiPhone/iPad版をアップデートしたと発表した。じつに11年ぶりの大型アップデートになるという。「検索をムダにしない」というキャッチフレーズを掲げており、新機能「スクラップブック」を搭載。「情報の検索とお気に入りコンテンツのスクラップで、ブラウザーに新たな価値を提供する」としている。iOS 18.6以降/iPadOS 18.6以降に対応しており、App Storeより無料でダウンロードできる。

生きていたのか…
https://internet.watch.impress.co.jp/docs/news/2054953.html

15.10.2025 02:42 — 👍 2    🔁 3    💬 0    📌 0
podman 격리 컨테이너 시동 스크립트

podman 격리 컨테이너 시동 스크립트

VRChat 세상은 위험하단다! 격리 컨테이너를 가져가렴.

07.10.2025 09:47 — 👍 1    🔁 6    💬 2    📌 0
Preview
fedify/.github/workflows/check-stale-assignees.yaml at main · fedify-dev/fedify ActivityPub server framework in TypeScript. Contribute to fedify-dev/fedify development by creating an account on GitHub.

오늘은 Fedify 이슈 트래커에서 이슈가 할당되었는데 2주 이상 아무 반응이 없는 경우에 댓글이 자동으로 달리게 만들었다. Claude Code한테 부탁하니까 거의 한 방에 완성되었다.

https://github.com/fedify-dev/fedify/blob/main/.github/workflows/check-stale-assignees.yaml

09.10.2025 09:18 — 👍 1    🔁 2    💬 0    📌 0
Email notification from Open Collective showing AltStore has become a new financial contributor to Fedify as a corporate sponsor with a $500.00 monthly contribution. The email includes the Open Collective logo, information about AltStore with a link to their Open Collective page, and details about the sponsorship tier and amount.

Email notification from Open Collective showing AltStore has become a new financial contributor to Fedify as a corporate sponsor with a $500.00 monthly contribution. The email includes the Open Collective logo, information about AltStore with a link to their Open Collective page, and details about the sponsorship tier and amount.

### Announcement: AltStore becomes a financial contributor to Fedify

We're thrilled to announce that AltStore has become a financial contributor to Fedify! This generous support comes as part of AltStore's broader commitment to strengthening the open social web […]

[Original post on hollo.social]

08.10.2025 03:28 — 👍 1    🔁 18    💬 1    📌 0
Post image 26.09.2025 02:30 — 👍 2    🔁 2    💬 0    📌 0
The icons for Hackers' Pub, Elk and Elgg on a white background

The icons for Hackers' Pub, Elk and Elgg on a white background

Its been a while! I just added #HackersPub (https://hackers.pub), #Elk (@elk) and #Elgg (@elgg) icons to https://iconography.fediverse.info

23.09.2025 19:08 — 👍 0    🔁 1    💬 0    📌 0
2025 Q2/Q3 Review 사실 2분기 결산에도 담고 싶은 내용은 있었는데, 알짜배기 컨텐츠는 3분기에 몰려있어서 이렇게 몰아쓰게 되었다. 1분기 결산 때 다음 분기부터 어떻게 할 것인지 계획을 나열해놓긴 했었는데, 사실 몇가지 더 중요한게 생기는 바람에 따로 챙기진 못했다. 그만큼 여러가지 굵직굵직한 이벤트가 생겼다고 보면 되는데, 어떤 일들이 있었는지 하나하나씩 나열해보고자 한다. 1분기 결산에서 계획했던 일들이 틀어졌던건 나름 이유가 있었다(라고 자기합리화를 해본다) ### Timeline 4월부터 이 글을 쓰고 있는 9월까지, 2주~4주 단위로 여러가지 큼직큼직한 일들이 일어났다. 개인(혹은 업무)적인 일부터 대외적인 활동과 관련된 일까지. 내가 너무 많이 뿌려놓은 씨를 거두느라 개고생한 흔적, 다시 말해서 **업보청산의 히스토리** 라고 볼 수도 있겠다. * **2025-04-10 (수입이 들어오지 않기 시작함)** : 강남에 파견근무를 가던 일이 있었다고 이전 글에서 언급한 적이 있다. 그런데, 어느 날, 임금이 미지급되고 말았다. 임금이 미지급된 건 관련해서 노무적인 협상을 시도하긴 했는데, 새로 작성한 계약서에 몇가지 찝찝한 조항이 있어서 더 이상 진행하지 않기로 하고 수입이 없는 나날이 시작되었다. 바이브코딩이 한참 뜨고 있었던 시기였어서 돈이 안되지만 일단 아이디어 가지고 일단 만들어보는 생활만 거의 3개월 했다. 결과적으론, 딱히 소득은 없었던 것 같다. * 돈이 들어올 구멍이 없으면 외주라도 넣어야겠어서, 프리모아/위시켓 같은 외주플랫폼에서 돈이라도 따오자라는 제안을 했었고, 지원서 넣는 것도 내가 다 했다. 그 외에도 외주 견적서 뽑아주는 사이트도 만들고, 내 돈(법인계좌로 빌려준 돈 400만원 중 일부)으로 페이스북 마케팅비 태우기까지 했는데 딱히 큰 성과는 없었다. 2인 사업장에서 겨우 버틸 수 있으려면 한달에 최소 1,000만원은 벌어야 하는데, 그에 한참 미치지 못하는 건들도 많았다. (물론, 실무적인건 내가 주로 해왔다) * **⭐ 2025-05-11 (파이콘 발표 지원)** : "올해는 파이콘에서 발표 꼭 해봐야겠다"라는 생각을 하고는 있었는데, 마침 Aider로 온갖 실험을 하고 있었던 찰나였어서 "**Aider와 함께하는 바이브코딩** "이라는 주제로 패기롭게 CFP 자료를 제출했다. 물론.... **여기서부터가 심장이 쫄깃쫄깃해지는 나날이 시작** 되었다. * **2025-05-24 (한국 연합우주 개발자 모임, 두번째 스프린트 밋업 주관)** * 한국 연합우주 개발자 모임의 첫번째 스프린트 밋업을 연지가 9개월 정도가 지나서 간만에 열었다. 모임을 여러군데 운영하다보니까 정신이 없기도 했고, '어디에서 모임을 또 열지'하고 고민만 하다가 계속 미뤄졌던 것도 컸다. 가능하면 "1달 단위로 열 수 있도록"은 해봐야겠다는 생각은 든다. 물론 내 여가시간을 희생하는건 불가피하겠지만... * 물론, 이후의 모임은 뒤에서 설명할 **Fedify 기여활동을 시작** 하게 되면서 미뤄지게 되었다...... * **⭐ 2025-06-19 (파이콘 발표자로 선정)** : '에이, 설마 되겠어?'하고 반신반의했었는데, **파이콘 한국 2025 발표자로 선정** 이 되고 말았다. 이 당시까지만 해도 굉장히 자신만만했다. 그리고 어떤 일이 있었는지는..... 아래 사진과 당시 대본으로 설명을 대신하겠다. > 정말…. 그… 발표를 준비하는데도 강산이 계속 변했습니다. > > 저는 터미널에서 Cursor 못지 않게 LLM으로 개발하기 딱 좋은 도구가 있다고 해서 Aider를 도입을 했고, 플러터 개발을 할 수 있을 정도로 기여도 하고 그랬는데요. > > 다른 LLM 에이전트 도구들도 계속 발전을 해왔습니다. > > Claude Code도 5월 1일쯤인가 Todo List라는 기능이 들어가면서 약간은 성능이 괜찮아졌구요. 물론 이때도 Aider만큼 좋지는 않았던 것 같아요. > > 그래서 확신에 찬 마음으로 5월 11일 파이콘 CFP 마감하는 날에 Aider를 주제로 발표자료를 제출했구요. > > 그런데, 어느날 5월 16일 OpenAI에서 LLM 코딩 에이전트를 하나 출시하고, 웹에서 백그라운드로 돌아가는 제품을 또 출시 했더라구요? > > 그리고 5월 23일, 앤스로픽에서 Global Available 버전으로 Claude Code가 출시가 되었고, 많은 각광을 받았습니다. > > 6월 13일, 저도 한번 Claude Code를 본격적으로 사용하기 시작했고, Aider랑 비교할겸해서 병행해서 사용하게 되었던 것 같아요. > > 그리고, Claude Code와 Aider 사이에 갈등하던 중…. 6월 19일 파이콘 한국 2025 발표자로 선정이 되고 말았습니다. > > 네. 그래도, 뭐, Aider가 구글 쪽 좋은 모델을 갖다쓸 수 있는 장점이 있으니까.. 그래도 차별적인 장점은 존재한다고 생각하고 계속 확신은 가지고 있었어요. > > 그런데, 그 일주일 뒤에 Gemini CLI가 공식 발표됩니다. > > 이럴 수가…… 하고 또 넉놓은 사이, 또 일주일 뒤에 Cursor에서 신기능을 발표하고, > > 그리고 또 일주일 뒤에 Kiro 라는 개발도구가 발표되었습니다. > > Spec Driven Development를 녹여낸 제품이다 뭐다하면서요. > > LLM 기반의 개발도구는 따라잡기 버거울 정도로 계속 발전하고 있습니다. * **⭐ 2025-07-04 (Fedify 프로젝트에 기여자로 참여)** : NIPA에서 주관하는 오픈소스에 기여할 수 있는 멘토링 프로그램, 오픈소스 컨트리뷰션 아카데미(줄여서 OSSCA)에서 **Fedify 팀 멘티** 로 선정이 되었다. * Fedify는 홍민희님이 진행하시는 오픈소스 프로젝트인데, 쉽게 말하자면 ActivityPub 프로토콜을 지원하는 웹 서비스 개발의 난이도를 낮춰주는 프레임워크다. Express/Hono/Fresh/NestJS 등 Typescript 기반의 웹프레임워크와 같이 연동해서 사용할 수 있다. * 예를 들자면, 마스토돈 같은 분산형 SNS 서비스를 만들어야 한다고 가정해보자. SNS 기능을 지원하는 서비스를 만드는 것 정도는 MVP를 만드는 것 정도는 어렵지 않게 가능할 수 있다. 하지만, 각자 다른 환경에 서비스가 self hosted되어 있고, 각각의 서비스가 하나의 타임라인을 구성하는 것처럼 연합되려면 일종의 프로토콜이 필요한데, 그것이 바로 ActivityPub이다. * ActivityPub 프로토콜 스펙에 맞게 소프트웨어를 구현하려면 당연히 inbox를 구현하고, outbox를 구현하고, message queue를 구현하고, Activity를 전달하는 매커니즘을 구현해야 하고, 특정 Activity를 받았을때 어떻게 할 지에 대해서 정의하는 인터페이스가 필요한데, 자잘한 인터페이스를 정의해야하는 수고로움을 Fedify에서는 획기적으로 줄여준다. Fedify와 연동이 되어 있다면, 거기서 제공하는 인터페이스를 가져다 쓰기만 하면 된다. * Fedify는 ActivityPub 기반의 소프트웨어를 만들기 위해 어떤 고려사항이 필요한지, 그리고 어떤 구현요소가 필요한지 등등이 어지간하면 정리가 되어있고, 홍민희님이 Hollo, Hackers' Pub 등의 소프트웨어를 직접 개밥먹기하면서 개발해온 노하우가 문서에 녹아 있다. * 그리고 **2025-07-12** OSSCA 발대식에 참여도 했고, 팀별 발대식하면서 자발적으로 부멘토 역할을 하기로 했다. **OSSCA Challenges**(**~08/10**) 기간 동안에는 가능하면 많은 분들이 기여를 하셨으면 좋겠어서, 멘티분들이 어떤 특기를 가지고 있는지 간단하게 설문조사를 했었고, 각자의 특기에 맞게 골고루 일을 분배시키는 역할은 했던 것 같다. 일정 트래킹은 덤. 지금 진행중인 Masters는 여러가지 일정이 겹쳐서 늘어지고 있는데, 벌써 마감(11/01)이 코앞이다 (ㅋㅋ) * 부멘토 역할 외에도 내가 담당하고 있는 파트는 NestJS 지원(fedify/nestjs)인데, 이 PR을 시작으로 NestJS 기반의 연합우주 소프트웨어를 개발하고 있다. 처음에는 내가 개발중인 모노리포 프로젝트의 패키지로서 정의해서 갖다쓰는 방식으로 접근했다가, Fedify의 서브패키지로서 갖다 쓰는 방식. 이 과정에서도 정말 여러가지 우여곡절이 있었다. 내가 개발중인 프로젝트는 연합우주판 SlideShare인데, 추석 연휴 중에 배포까지 끝내고, OSSCA 성과발표회때 MVP 시연하는걸 목표로 하고 있다. 실서비스를 생각하고 도메인(cosmosli.de)이랑 맥미니도 사놨다. * NestJS 자체는 CommonJS 기반의 모듈 시스템 위에서 돌아가고 있다. Fedify는 원래 ESM 기반의 모듈 시스템 위에서 돌아가는 라이브러리인데, CommonJS 지원한다고 홍민희님이 도움을 많이 주셨다... NestJS에서 지겹도록 사용하고 있는 Decorator 문법이 사실은 deno 런타임에서는 지원되지 않는다던가, Decorator 문법을 지원하기 위해서 라이브러리 빌드할때 tsconfig를 별도로 건드려줘야한다던가 등등 여러가지 사정이 있었다. 특히, `js-temporal/polyfill`이 mjs에서 뽑히는거랑 cjs에서 뽑히는게 다를 줄은 누가 알았겠는가..... * **⭐ 2025-07-06 (vimrc 2025 준비 첫 미팅)** : ​누군가가 "Vim 교정 학원 안 열어주나"라고 트윗을 했던 것을 시작으로 2019년/2022년 이렇게 3년 단위로 박현우(lqez)님의 주도로 vim 사용자들의 모임이 연말마다 진행되곤 했었다. 어느 날, "올해도 과연 열릴 것인가?" 라는 의문이 들어서 현우님한테 vimrc 진행 계획을 DM으로 여쭤보았다가, vim.kr 주관으로 여는 걸로 바톤을 이어받게 되었다. 그리고 7월 6일 첫 미팅을 했고, 11월 중순에 진행하는 것으로 결정이 되었다. * vim.kr 주관으로 중간 정도 규모의 컨퍼런스 열어야지 열어야지 했다가 위에서 언급한 맥락들을 비롯한 개인적인 사정으로 계속 미뤄졌는데, 그나마 vimrc 행사라도 이어받았다. 이거라도 반드시 해내야지. * **2025-07-31 (퇴사)** : 사업장의 경영난으로 인해서, 월급도 3개월 이상 밀리기도 했고 더 이상 지속하기 어렵겠다는 판단이 들어서 아예 **독립을 시작했다**. 그 외에도 받아야 할 돈이 제법 있는데, 여러가지 면에서 문제가 많았기 때문에 누가봐도 함께하기 어렵다(그리고 함께해서는 안된다)는 명분은 충분했다. 3년 동안 정말 길면서도 짧은 세월이었다. 그리고, **여기서 하던 외주도 따로 들고 나왔다.** * 마무리는 어쩔 수 없이 내가 해야한다는 강박은 있었고, 사업장(그래봤자 2인이지만)에서 진행하는 것보다 내가 혼자 들고 있는 편이 낫기도 했고, 그냥 튀어버리자니 여러가지 찜찜한 구석이 있었다. * 온전히 포트폴리오 쌓기/취업 준비에만 시간을 쏟아붓고 싶었지만, 하루의 절반은 외주에 시간을 써야 하는게 아쉽기만 하다. 시간을 통으로 확보할 수 있는 사람들이 한편으로는 부럽다는 생각이 든다. * **2025-08-09 (개인 명함 디자인)** : 하제의 도움을 받아서 피그마로 개인 명함 제작하는 레슨을 들었다. 그리고 명함 디자인 만드는건 하제가 거의 다 따줬다. * 생각보다 디자인이 잘 나왔어서 커피챗을 나갈때도, 행사장을 돌아다닐때도 받는 사람들마다 평은 좋았던 것 같다. * **⭐ 2025-08-10 (UbuCon Korea 2025 발표)** : UbuCon Korea 2025에서는 발표를 두탕 뛰었다. * "2025 우분투 환경에서의 에디터, 그리고 미래" * 세션 소개 페이지 : https://events.canonical.com/event/126/contributions/671/ * 사실은 한참 전부터 Ubucon Korea 오거나이저 분들한테도 Vim 관련해서 세션을 열어달라는 제안은 있었다. 정확히는 BoF 세션을 열어보는게 어떠냐는 내용이었다. BoF가 뭔가하고 알아보긴 했는데, 간단하게 요약하자면 사회자가 어떤 주제를 가지고 화두를 던지면 사람들이 자발적으로 프리스타일로 얘기할 수 있는 자리를 가지는 세션이다. 가능하면 Vim 외에도 다른 에디터를 쓰는 사람들도 견해를 나눌 수 있으면 좋겠어서, Emacs를 잘 아시는 rangho님도 공통 진행자로 모시고, 막 전역하신 neovim 플러그인 장인 boltless님을 발표자 지인 찬스로 모셨다. 그리고, 결과는 성공적이었다. * "글로벌 OSS 개발자들은 왜 Fediverse에 모일까?" * 세션 소개 페이지 : https://events.canonical.com/event/126/contributions/700/ * 아마 한국의 규모있는 컨퍼런스 중에서는 처음으로 연합우주(Fediverse)를 소개하는 세션일 수도 있을 것 같다. 해외에는 fosstodon.org/hachyderm.io/floss.social/infosec.exchange 등 연합우주 인스턴스에 터를 잡은 FOSS 개발자들이 많이 있는데, 국내에는 잘 안보이기도 하고 유입이 거의 없다. 국내에는 홍민희님을 중심으로 Hackers' Pub에 개발자들이 유입되고 있는데, 여기에 부스터를 달아주고자 겸사겸사 발표를 지원했다. 한국 연합우주 개발자 모임 모더레이터도 하고 있기 때문에 명분은 충분했다. 이 발표를 통해서, 국내에도 개발자 커뮤니티 전반적으로 연합우주에 대한 저변이 조금이라도 넓혀졌지는 않았을까 싶다. * 발표자료는 여기서 확인이 가능하다. * 사실은 맨 마지막 슬라이드의 Hackers Pub 초대장 QR 코드가 핵심 목적이었다 (ㅋㅋ) * 그리고...... OSSCA Challenges 기간이 끝난 시점이었어서, 행사가 끝나자마자 광화문에서 서초로 칼같이 이동해서 Fedify팀 단체 회식도 따로 가졌다. * **⭐ 2025-08-16 ~ 2025-08-17 (PyCon KR 참여)** : 올해는 파이콘 한국에 커뮤니티 후원사로서도 참여하고, 발표자로서도 참여했다. 정신없는 나날을 보냈던 것 같다. * 후원사로서 참여할때는 Hackers' Pub/한국 연합우주 개발자 모임/vim.kr 이렇게 커뮤니티 세군데에 걸쳐서 부스를 지켰다. * 어쩌다가 커뮤니티 세군데에 걸쳐서 부스를 지키게 되었는지에 대해서 얘기하자면 길다. 올해도 커뮤니티 후원사로 참여할 생각은 있었지만, 파이콘 트위터 계정의 커뮤니티 후원사 모집 공고가 누군가의 팬클럽 디스코드에 좌표로 찍히면서 시작되었다. 요약하자면, 딱히 많지도 않은 금액으로 커뮤니티 후원사로 참여가 가능하다는 뭐 그런 내용이었다. 그렇게.... vim.kr 모더레이터인 다른 친구 한 명 더 껴서, 한 디스코드 서버에서 4개의 커뮤니티가 파이콘 한국에 후원사로 참여하게 되었다. 그냥 할 수 있으니까? 무턱대고 저질러버렸다. * 양일간 한국 연합우주 개발자 모임 부스만 계속 지키고 있었다. 중간중간에 vim.kr 부스도 지키고, Hackers' Pub 부스를 지키긴 했지만 대부분의 시간은 한국 연합우주 개발자 모임 부스에만 있었다. 발표하느라 자리를 비우는 동안, 다른 세션 들으러 가는 동안, 같은 Fedify 팀 멘티인 이찬행님/권지원님 그 외에도 김무훈님, 하제도 부스를 지키는걸 도와줬다. 압도적 감사... * 그리고 vim.kr 부스는 낙관적으로 생각했던 것과는 다르게 신경쓸 겨를이 너무 없었다. sliver님, 이벤트 티켓으로 선정되셨던 성지호님, 그리고 iblea님이 정말 고생을 많이 해주셨다. 다음엔 커뮤니티 부스를 여러개 세우게 된다면, 백업플랜을 많이 세우던가 해야겠다. * 발표자로서 참여할때는..... 떨려왔던 것에 비해서는 생각보다 반응은 괜찮았던 것 같다. AI 도구가 너무 빠르게 발전해온 탓에 내 발표는 실시간으로 망한 컨텐츠가 되어가고 있었음에도 불구하고, 여전히 내가 전달하고 싶었던 핵심적인 메시지는 변하지 않았다. "**사람 자체가 강해져야 하고, 아는 만큼 올바르게 지시내릴 수 있다** " * 컨퍼런스 발표는 뭐랄까... CFP 모집부터 발표자로 확정되고 발표하기까지의 사이클이 길다면 긴 편인데, 빨리 변하는 컨텐츠는 가능하면 다루지 말아야겠다는 교훈을 얻었다. 책을 출간하는 것도 마찬가지겠지... * 발표자료는 여기서 확인이 가능하다. * **⭐ 2025-09-14 (Hackers' Public 주최)** : 한국 연합우주 개발자 모임 주관으로 해커스펍 오프라인 모임 Hackers' Public 첫번째 모임을 성공적으로 끝냈다. * Hackers' Pub에서 오프라인 모임을 열었으면 좋겠다는 수요는 꾸준히 있어왔다. 그렇다면, "어떻게 모일 것인가?"가 문제였다. 가능하면 많은 사람들이 만족할 수 있어야 하고, 너무 가볍지도 않으면서 한편으로는 지적인 호기심을 자극시키고, 네트워킹하면서도 여운이 남을 수 있는 그런 행사를 만드는게 이상적일 것이다. * 사실은, 모임을 어떻게 열까에 대해서 밑바닥부터 고민해보기 보다는 이런 형태의 행사는 열어봐야겠다고 지속적으로 눈여겨보고 있던 행사는 있었다. 바로 NYC Systems Meetup인데, 적당히 소규모이면서 **다양한 분야의 전문가들이 각자의 분야(컴파일러/데이터베이스/브라우저/IDE/...)에서 어떤 챌린징한 과제를 하고 있는지를 소개** 하는 밋업이다. 유튜브 영상도 공개되어 있다. 완전히 이런 형태의 밋업을 따라갈 수는 없겠지만, 큰 틀에서 봤을 때 내가 가장 마음에 들었던 부분은 '**지적호기심을 유발하는 적당히 하드코어한 주제** ' 중심의 밋업이라는 점, 그리고 '**특정 언어/프레임워크에 종속적이지 않다** '라는 점이었다. 연사자 분들을 섭외하는데 있어서 가장 핵심적인 기준이 되었다. * 연사자 모집 구글폼은 여기서 확인이 가능하다 * 그렇게 모임 아이디어는 냈으니까 당연히 추진해야지! 라는 마음가짐으로 바로 실천으로 옮겼다. NYC Systems Meetup처럼, 사람들이 흥미를 가질만한 주제를 중심으로 연사자 두 명 섭외하고, 나머지는 자유로운 주제로 네트워킹하는 식. * 이찬행님이 Hackers' Public 이라고 이름도 지어주셨고, 포스터도 만들어주셨다 * 내가 생각하는 이상적인 모임에 연사자로 적합하다고 생각해둔 후보가 몇명 있었다. 그 중 몇몇 후보가 dalgona님, Jake Seo님이었어서 첫번째 모임 연사자로 모시게 되었다. 그리고, 역시 예상한대로 반응은 좋았다. 다만, 네트워킹 시간이 생각보다 적게 확보되어서 아쉬웠다. 다음에 행사를 열게 된다면 4시간 확보해둘까 생각하고 있다. * 행사 소개 페이지는 여기서 확인이 가능하다. * **⭐ 2025-09-24 ~ 2025-09-29 (PyCon JP 참여)** * 2023년에 RubyKaigi를 참여했던 이후로 2년만에 일본에 들리는 셈인데, 파이썬으로 밥벌이를 하고 있지는 않지만 일본 개발자들과 네트워킹도 하고, 간만에 해외여행도 하고 싶어서 질러버렸다. * 자세한 내용은..... Mastodon 사담계에서 거의 생중계했으니 여기를 참고하면 될 것 같다. 혹시나 아티클을 또 발행할게 될 수도 있을 것 같은데, 그건 확실하지는 않다. #### 요약하자면..... 1. 자유의 몸이 되어서 일단은 취준 모드에 들어가있고, 2. PyCon KR/UbuCon KR에서 두 차례 발표를 했고, 3. Hackers' Pub에서 내가 열고 싶은 이상적인 형태의 밋업 첫 스타트를 끊었고, 4. Fedify라는 오픈소스 프로젝트에 기여자로 참여하면서 Fedify를 중심으로 한 연합우주 생태계를 넓히는 작업을 진행중이고, 5. 그러면서 외주도 진행중이다. 맙소사, 나열해봤더니 정말 많다. 2분기는 모르겠지만, 3분기는 확실히 판은 많이 벌려놨고 하고 싶은건 다 하면서 살았다. 그리고 아직까지도 청산해야하는 것들이 많아서 11월까지는 구직을 미룰 것이다. ### 그래서 현재 상태는? 이것저것 나열하느라 얘기가 좀 길어지긴 했다. 어떤 것을 했고, 어떤 이벤트가 일어났고, 여러가지 사실 관계들을 나열하기만 했다. 그렇다면 지금의 내 상태는 어떤가? #### 일은 벌려놨지만, 딱히 수입은 없다. 그래도 만족한다. 위에서 언급했다시피 4월 이후로 수입은 거의 끊긴 상태다. 사업장 안에서 외주를 진행할때는 100/200 이렇게 중간에 들어오긴 했지만, 진행 중인 외주 마무리하고 잔금을 받으면 300은 받을 수 있다. 그 외에는 그냥 돈이 빠져나간다고 보면 된다. 혹시 몰라서 대출받아놓은게 있었는데, 거기다가 미국주식 투자한 것도 있어서 총알이 없지는 않다. 1월까지는 버틸 수 있는 금액이다. 그렇다고, 외주를 더 하기에는 내가 원하는 일자리 구할 기회도 놓치고, 괜히 잘못 계약맺었다가 발이 묶일 수도 있을 것 같아서 일부러 더 하고 있지는 않다. 지금 내가 벌려놓고 있는 일들도 올해 안에 끝장은 봐야하는데, 여기에 뭔가를 더 추가할 수는 없다. 감당할 수 있는건 지금 상태가 마지노선인 것 같다. 그래도.... 나름 하고 싶은건 다 하면서 지내고 있다. #### 취준은 하고 있는데, 프론트엔드 중심은 아니게 되었다. 분명, 1분기 때는 취업준비를 프론트엔드 중심으로 취업준비를 하리라고 다짐을 하긴 했건만, Fedify에 집중을 하다보니 프론트엔드 중심으로 취업준비하는 건 굉장히 비효율적이라는 판단이 들었다. 위에서 설명했듯, Fedify는 Express/Fastify/NestJS 등 백엔드 프레임워크에서 연합우주 소프트웨어를 개발하는 난이도를 낮추기 위한 라이브러리이다. 그 중에서, 나는 Fedify를 응용해서 NestJS 기반의 연합우주 소프트웨어를 개발하고 있는데, 계속 프로젝트를 진행하다보니 프로젝트는 프론트엔드 보다는 백엔드에 좀 더 전적으로 집중을 해야하는 상황이 되고 있다. 시간이라는 예산이 한정되어있기 때문에, 일자리를 알아보더라도 Node.js 백엔드 엔지니어 중심으로 일자리를 알아보거나 혹은 풀스택 엔지니어로서 일자리를 알아보는게 맞겠다는 판단이 생겼다. FastAPI/Django 쓰는 일자리도 열려있긴 하지만, 선택과 집중을 해야하는 관계로 **당장은 Node.js 중심의 일자리를 알아보는 방향** 으로 노선을 유지하고 있다. 커피챗 갈 때마다, 특정 프레임워크에 숙련된 사람을 원하는지, 혹은 framework agnostic한 관점에서 문제 해결 능력이 뛰어난 인재를 원하는지(사실 이 기준도 어떻게 정의하느냐에 따라 다를 순 있다.) 꼭 물어보곤 하는데, 사실 어느 쪽의 입장이더라도 이해는 된다. 프레임워크에 어느 정도 숙련된 사람을 채용하는 쪽이 아무래도 전반적인 코드 품질이 보장되는 것은 물론이고, 프레임워크를 학습시키느라 드는 학습비용의 우려도 없을 수 있기 때문에 선호될 수도 있을 것이다. Rails 백그라운드이긴 하지만 Rails가 아닌 백엔드 일자리를 알아보고 있는 입장에서, 어떻게 보면 불리한 시작이라고 할 수 있다. 그렇더라도, **" 하나라도 잘해야 한다. 내가 지금 NestJS로 프로젝트를 진행하고 있으니, 이거라도 제대로 해내야겠다."** 라는 생각으로 임하고 있다. 기술면접도 일단 간간히 준비하고는 있다. 이론도 거의 다 까먹어서 OSTEP(Operating Systems : Three Easy Pieces), HPBN(High Performance Browser Networking) 이렇게 두 개의 교재를 위주로 공부하고는 있다. 즉, OS랑 네트워크를 중심으로 공부하고 있다. 데이터메이스는 CMUDB 유튜브 강의로 공부하려고 생각은 하고 있는데, 일단 저것부터 다 끝내고 생각해보는 것으로.... 알고리즘은 감각이 퇴화되긴 했는데, 아예 죽지는 않은 것 같다. ### And...? 그렇다면, 다음 분기에는 무엇을 할까? 하나 확실한 교훈은 얻었다. 다음 분기는 가능하면 내가 현재 하고 있는 것과 관련있는 것을 중심으로 좀 더 스케일업하는 계획을 먼저 세우도록 하고, 곁다리로 계획을 세운다면 충분히 바쁜 상황에서도 소화할 자신이 있는지를 먼저 생각해봐야겠다는 것. 이렇게 4분기를 앞두고 있는 시점에서, 작년에 계획했던 것들 다시 되짚어보자면 * Amazon Kindle 재고 처리하기 <- 아직 청산을 하나도 못했다 * 자기전에 Coursera 강의 듣기 <- 취직해서 자리 잡는게 시급해서 우선순위가 뒤로 미뤄져있다 * **블로그 글 5개 발행하기** <- 이건 다행히 맞출 수 있을 것 같다. 다음 분기때 글 2-3개 이상만 쓰면 된다. * 해외 오프라인 컨퍼런스에서 강연하기 <- 아쉽게도 타이밍을 놓쳤다 * **자기계발 뿐만이 아니라 다른 분야의 책 읽어보기** <- 다음 분기는 최소 책 하나라도 읽긴 해야겠다.... * 일본에서 열리는 VimConf 참여할 파티 구하기 <- OSSCA 성과발표회와 일정이 겹쳐서 못간다. * zig 기반의 오픈소스 프로젝트에 기여하기 <- 한 때 꽂히긴 했었는데, 지금은 엄두가 안나고 있다. * 내가 좋아하는 프레임워크에 기여하기 <- 이것도 자리를 잡고나서 생각해봐야 할 것 같은데, 내년에는 시도해볼 수 있을 듯 싶다. 계획을 세워놓기만 하고 하나도 안하는건 그것도 그거대로 영 찝찝하기 때문에, 하나라도 제대로 해내야겠다는 강박은 있다. 그리고, 벌려놓은 것들은 완전히 마무리 짓는건 당연히 해내야 하고, 가능하면 크리스마스 이전에는 자리를 잡을 수 있으면 좋겠다.
24.09.2025 01:33 — 👍 2    🔁 2    💬 1    📌 0
Original post on burningboard.net

The old web was decentralized:

- Newsgroups
- Personal Websites
- Bulletin board
- Email as a service, not a platform
- Internet relay chat (IRC)
- Early blogs

Then corporations arrived with money and lock-in, turning the internet into centralized ad farms (Meta, X, TikTok). Users became […]

21.09.2025 08:48 — 👍 21    🔁 7    💬 0    📌 2
Original post on hollo.social

Thinking about building “#Fedify Studio” (tentative name)—a web-based #ActivityPub debugging & development toolkit, like a supercharged version of ActivityPub.Academy and `fedify inbox` command. Imagine having a proper UI for testing activities, inspecting actors, debugging federation issues… […]

20.09.2025 07:14 — 👍 2    🔁 13    💬 3    📌 1

이 분의 유명한 강연이.... 요거 https://youtu.be/30YWsGDr8mA?si=yMtG1rulnISpLL0Z 인데

내용을 적당히 추리자면

* * *

복잡하거나 난해하거나 어려운 것들을 단순한 것으로 만들기 위해서

1. 난해한 것들을 단순하게 만들어주는 훌륭한 도구를 사용하거나
2. 찾는데서 삽질하는 빈도를 줄이기위해 좋은 레퍼런스를 확보하거나
3. 시간순으로 설명하거나
4. 가려져있는 것들을 가시화할 것을 권장



어떤 것에 대해 질문을 올리면 Read The Fucking Manual […]

18.09.2025 04:06 — 👍 0    🔁 1    💬 0    📌 0

added a cheat sheet to the official Git website https://git-scm.com/cheat-sheet

16.09.2025 18:26 — 👍 8    🔁 3    💬 1    📌 0

연합우주가 뭔가요?

트위터에서는트위터글만볼수있고인스타에서는인스타글만볼수있는데이메일은구글을쓰든네이버를쓰든서로볼수가있잖아요이게이메일이하나의공통프로토콜을지킨덕분인데요이메일처럼SNS에서도공통프로토콜을만들어서로통신이가능하게하자고만든게ActivityPub프로토콜이고요이프로토콜을지켜만든사이트들이하나의거대한연합처럼뭉쳐서서로통신을할수있다보니이연합를가리켜연합우주라고합니다

네?

트위터 같은 거에요

15.09.2025 03:06 — 👍 6    🔁 16    💬 1    📌 3
Hackers' Pub 오프라인 모임 Hackers' Public 1회차 포스터. 어떤 발표주제였는지 확인이 가능하다.

Hackers' Pub 오프라인 모임 Hackers' Public 1회차 포스터. 어떤 발표주제였는지 확인이 가능하다.

많은 관심 덕분에 Hackers' Pub 모임이 성공적으로 마무리되었습니다! 🎉

1회차 발표 주제들은 아래 이미지에서 확인하실 수 있구요, 다음 밋업을 더욱 흥미롭게 만들 연사자도 모집 중입니다! 전문지식·시행착오·독특한 경험까지 환영합니다!

https://forms.gle/1qM2fQmZciZu3erAA

많은 관심 부탁드립니다!

14.09.2025 15:12 — 👍 2    🔁 4    💬 0    📌 0

오늘은 Hackers' Public 첫 번째 모임! 다들 튜링의 사과(@TuringAppleDev)에서 오후 3시에 모여요!

14.09.2025 04:35 — 👍 1    🔁 2    💬 0    📌 0
I'm stoked to share my next role: **Design Engineer** at Shopify; alongside Jason Miller to hack on next-gen admin UI/UX and a new Polaris. I'm also workin to rejoin the CSSWG via Shopify too 🙂 Thanks for all y'all's support! 💀🤘🏻

Me 🤝 Shopify

https://nerdy.dev/joining-shopify

12.09.2025 23:28 — 👍 7    🔁 2    💬 2    📌 0
Recent open source development updates

I wrote a post on my blog after a long time: _Recent open source development updates_.

12.09.2025 11:17 — 👍 1    🔁 2    💬 1    📌 0
Recent open source development updates

오랜만에 블로그에 글을 썼습니다: 〈오픈 소스 開發(개발) 近況(근황)〉.

12.09.2025 11:17 — 👍 1    🔁 5    💬 1    📌 0

블루스카이 CEO 가 찰리 커크 추모글을 올리며 폭력은 절대 용인할 수 없으며 관련 폭력 미화는 위반 사항이라는 글을 알티함

아 물론
- 가자, 팔레스타인 얘기는? 안함
- 민주당 주의원이 총격 피살 당했을 때는? 역시 안 함
- 찰리 커크 총격과 동일한 날에 발생한 콜로라도 학교 총기 난사 사건은? 당연히 안 함

12.09.2025 04:54 — 👍 66    🔁 264    💬 3    📌 6
Preview
Threads • Log in Join Threads to share ideas, ask questions, post random thoughts, find your people and more. Log in with your Instagram.

I keep forgetting Barack Obama is on the Fediverse.

https://www.threads.com/@barackobama/post/DOdyIyWDZZo

11.09.2025 15:22 — 👍 0    🔁 4    💬 1    📌 0
Original post on hackers.pub

〈타입 검사는 해결책이 아니라 증상이다〉(Type Checking is a Symptom, Not a Solution).

난 이 글에 동의하지 않는데, 여러 측면에서 그렇지만, 한 측면에만 집중해서 얘기해 보자면: 좋은 아키텍처는 훌륭한 프로그래머를 요구하지만 타입 시스템은 훌륭한 프로그래머를 요구하지 않기 때문이다.

누구나 훌륭한 프로그래머가 되어야만 하는가? 혹은 될 수 있는가? 좋은 아키텍처를 그릴 수 있는 훌륭한 프로그래머가 아니라면 소프트웨어 개발을 해서는 안 될까? 좋은 아키텍처에만 의존하는 것은 잠재적으로 […]

10.09.2025 10:54 — 👍 2    🔁 4    💬 0    📌 0

10월 연휴에는 어떻게든 출시를 하는걸로....

07.09.2025 07:11 — 👍 1    🔁 1    💬 0    📌 0
What looks like a Facebook marketplace listing: Epson TV with built-in printer. Listed 7 hours ago for $100. The TV is very large and dated

What looks like a Facebook marketplace listing: Epson TV with built-in printer. Listed 7 hours ago for $100. The TV is very large and dated

If you use Linux, this is your final boss.

07.09.2025 04:08 — 👍 34    🔁 75    💬 4    📌 1
정치적인 컨텐츠에 대한 생각 > 해커스펍이 소프트웨어 개발자 및 IT 업계에 몸을 담근 사람들을 위한 공간이라지만 그렇다고 기술적인 것만 얘기해야한다는 강제적인 룰이 없기도 하고, 반사회/반인륜적이지도 않은 관점에서 실험적인 글을 남기고자 한다. 명목상으로는 사회생활에서 정치를 얘기하는 것이 금기의 영역이고, 정치혐오가 도처에 만연하다지만 우리의 삶은 절대로 정치에서 자유로울 수가 없다. 당장에 정책이 실행되는 것도 정치에서 파생된 결과물이고, 우리가 이익을 받거나 불이익을 당하는 것도 정치에서 파생되는 결과물이다. ## 정치적인 것이란 무엇인가? 주변 사람들과 얘기하다보면 정치 사안에 대해서는 굳이 언급도 안할때도 있고, 내가 활동하는 영역에서는 어떤 정치적인 스탠스랑은 가능하면 엮지 않으려고 하는 편이지만.. (기계가 들어가도 마찬가지겠지만) 사람이 개입한다면 결과적으로 어떻든 정치적이라고 볼 수 있다고 본다. 여성인권/소수자인권/노동자인권 등 당연한 것을 챙기자고 하는 것 조차 정치적이라고 주장하는 사회인데, "정치적이라고 보여지는 것"을 숨기는 것 조차도 정치적이라고 볼 수 있다. 호모소셜하고 배타적인 집단이라는 프레임에서 탈피하기 위해 다양성이 존중되는 문화로 빌드업하는 것도 어떻게 보면 정치적이고, 문제점이 있는지도 모르거나 현상을 인지하다라도 문제라고 보지 않으려고 애쓰는 것도 정치적이다. 정치적이라고 바라보는 것도 어찌보면 정치적일 수 있다. 정치혐오가 도처에 만연한데, 그것조차 정치적이라는 것을 인지해야 한다. 내 삶이 정치와는 무관하다고 할 지라도, 누군가는 장난으로든 정치적인 것으로 프레임을 씌우려고 하고, 의도하지 않아도 정치색이 "묻는다" ## 정말 정치에서 자유로울 수 있는가? 우리의 삶이 영향을 받을 수 있기 때문에 정신 차리고 정치에 관심을 가져야 하는 것이기도 하지만, 누군가에게는 생존권이고 누군가에게는 삶이 걸려있다. 특정 정치진영에서 다른 약자를 조롱하고 폄하하기 위해 만든 표현도 실수로라도 무의식적으로라도 주워먹지 않게 주의해야 한다. 이미 지금도 계속해서 가시화가 되고 있지만, 몇몇 유머계정 내지는 바이럴계정들도 사실은 도파민을 부추기는 목적 이면에는 정치적인 선전을 끼워넣는 경우가 굉장히 많다. 그것 조차도 교묘한 수작이라는걸 인지하기 위해서라도 정치에 관심을 가져야 할 수 밖에 없다. "정치적이라고 생각되는 것"을 혐오하고 가려낸다고 해서 정치에서 절대로 자유로울 수 없다. 디X인사이드 등등에서부터 우경화 가짜컨텐츠가 유구하게 만들어져왔지만, 이젠 AI로도 가짜컨텐츠를 찍어내는게 너무 쉬운 세상이 왔다. 컨텐츠를 있는 그대로 받아내기엔 컨텐츠를 만드는 주체의 정치적인 의도, 컨텐츠의 사실 여부, 컨텐츠가 가지는 함의, 컨텐츠 출처의 신뢰성까지 의심을 하지 않을 수 없다. 정치적인 것을 멀리한다 치더라도, 그것이 암묵적인 약속이라 하더라도, 결국에는 정치에 관심을 가져야 할 수 밖에 없다. ## 결론 겉으로는 정치적으로는 이런 입장이라고 생색을 내지 않고, 커뮤니티를 운영했던 입장으로서는 어떤 정치색도 강요하지 않으려고 하는 편이지만, 나 또한 정치적인 사람이기 때문에 "과연 내가 운영해왔던 커뮤니티가 정치적이지 않았던건가?" 하면 모르겠다. 정치적인 입장을 가진 사람으로서 나름대로의 판단으로 **분위기가 나락가지 않는 수준으로는** 운영했던 것 같다. 커뮤니티에 참여하는 사람들의 다양성을 늘리는 것도 어떻게 보면 정치적이라고 볼 수 있지만, 정치적이라고 볼 수 있는 행위가 오히려 배타적인 분위기가 아닌 건강한 커뮤니티를 만들 수 있는 밑거름이 될 수 있다. 경험해온 바로는 그렇다. 위에서 언급했다시피, 이미 많은 것들이 정치적인 것에서 그렇게 자유롭지는 않다. 의도치 않은 언행으로도 정치적인 프레이밍이 씌워질 수 있고, 정치적인 부산물을 잘못 주워먹어서 의도하지 않은 오해를 불러올 수 있다. 그리고, 잘 인지하고 있다면 오히려 더 좋은 판단을 내리게 될 수 있다. 그렇기 때문에, 더더욱 정신차리고 사회/정치에 관심을 가질 수 밖에 없다.
04.09.2025 04:19 — 👍 0    🔁 0    💬 0    📌 0

우부콘 코리아 2025에서 **"연합우주(Fediverse)란 무엇인가"**를 주제로 소개하는 세션을 가졌었는데, 그 때 쓰던 발표자료 한번 만들어놓으니까 "연합우주는 이런겁니다" 하고 던져주기 좋은 듯.....

발표자료는 여깄다네요... https://slides.kodingwarrior.dev/fediverse-onboarding-ubucon2025.pdf

01.09.2025 10:56 — 👍 1    🔁 3    💬 0    📌 0
Preview
Add Django South Korea community · Issue #2175 · django/djangoproject.com Name Django South Korea Description Django South Korea is a local community in South Korea for Django developers and users. The group shares knowledge, provides support, and hosts both online and o...

https://github.com/django/djangoproject.com/issues/2175

한국에도 Django 커뮤니티 디스코드가 생긴듯. 모더레이터분이 Django에 기여한 이력이 있으신 분!

25.08.2025 10:54 — 👍 2    🔁 3    💬 0    📌 0
Original post on hackers.pub

Vim에 관심있는, 혹은 Vim을 사랑하는 여러분, 안녕하세요.

한국어권 Vim 사용자 모임 vim.kr입니다. 오늘은 vim.kr에서 공식적으로 주최하는 모임 소식을 전해드리려 합니다.

혹시 *빔교정학원 모임(vimrc)*을 들어보신 적 있으신가요? vimrc 밋업은 2019년과 2022년에 3년 간격으로 개최된 바 있는데, 2025년부터는 저희 vim.kr이 그 바통을 이어받아 공식적으로 진행하게 되었습니다.

지난 7월 2일, 기존 vimrc 밋업을 주최하셨던 박현우(lqez)님께 연락을 드렸고, 이어 7월 6일 첫 […]

23.08.2025 11:16 — 👍 3    🔁 7    💬 1    📌 0
Preview
웹은 왜 복잡해졌나?: 모던 웹의 복잡성과 하이퍼미디어 시스템 분명 2000년대에 "이제는 초등학생도 홈페이지를 만들 수 있는 시대"를 한 번 거쳤는데, 이 낡아버린 캐치프레이즈가 무색할 정도로 오늘날 웹 개발은 정말 어려워졌다.팀 버너스 리(Tim Berners-Lee)가 첫 웹 사이트를 공개한 이후로 웹은 짧은 시간 동안 엄청난 변화와 성장을 겪었...

1년 반 만에 글을 썼다. 웹이 복잡해진 과정을 간략히 되돌아보고, 웹을 지탱해온 하이퍼미디어라는 개념이 얼마나 강력한 힘을 가졌는지 짚어보았다. https://parksb.github.io/article/43.html

17.07.2025 10:35 — 👍 7    🔁 9    💬 0    📌 0

@kodingwarrior.social.silicon.moe.ap.brid.gy is following 11 prominent accounts