델만 제정신이네 ㅋㅋㅋ AI 칩이 어쩌고해서 사람들이 과연 거기에 관심이 있나 싶었는데
Hong Segi (aka khris)
@khris@hackers.pub · 32 following · 27 followers
Software Engineer
델, 소비자들은 AI PC에 관심 없다는 사실을 인정
------------------------------
- CES 2026에서 *Dell은 AI 중심 마케팅을 배제한 제품 발표* 를 진행하며, 최근 몇 년간의 AI 과열 분위기와 대비되는 접근을 보임
- 발표에서는 *XPS 및 Alienware 노트북, Area-51 데스크톱, 신규 모니터* 등 구체적 하드웨어 중심의 제품군이 소개됨
- Dell 측은 모든 신제품에 *NPU가 탑재되어 있음에도* , 소…
------------------------------
https://news.hada.io/topic?id=25669&utm_source=googlechat&utm_medium=bot&utm_campaign=1834
Bose, 단종 예정인 SoundTouch 스마트 스피커의 API를 공개
------------------------------
- Bose가 *SoundTouch 홈시어터 스피커의 API 문서* 를 공개해, 단종(EoL) 이후에도 개발자들이 기기를 활용할 수 있게 함
- 2025년 10월 발표에 따르면, 2026년 2월 18일부터 SoundTouch 제품은 *AUX·HDMI·Bluetooth 연결만 지원* 하며 클라우드 기능과 앱 연동이 중단될 예정
- Bose는 이후에도 *AirPlay·Spoti…
------------------------------
https://news.hada.io/topic?id=25674&utm_source=googlechat&utm_medium=bot&utm_campaign=1834
LLM에서 마크다운이 널리 쓰이게 되면서 안 보고 싶어도 볼 수 밖에 없게 된 흔한 꼬라지로 그림에서 보는 것처럼 마크다운 강조 표시(**)가 그대로 노출되어 버리는 광경이 있다. 이 문제는 CommonMark의 고질적인 문제로, 한 10년 전쯤에 보고한 적도 있는데 지금까지 어떤 해결책도 제시되지 않은 채로 방치되어 있다.
문제의 상세는 이러하다. CommonMark는 마크다운을 표준화하는 과정에서 파싱의 복잡도를 제한하기 위해 연속된 구분자(delimiter run)라는 개념을 넣었는데, 연속된 구분자는 어느 방향에 있느냐에 따라서 왼편(left-flanking)과 오른편(right-flanking)이라는 속성을 가질 수 있다(왼편이자 오른편일 수도 있고, 둘 다 아닐 수도 있다). 이 규칙에 따르면 **는 왼편의 연속된 구분자로부터 시작해서 오른편의 연속된 구분자로 끝나야만 한다. 여기서 중요한 건 왼편인지 오른편인지를 판단하는 데 외부 맥락이 전혀 안 들어가고 주변의 몇 글자만 보고 바로 결정된다는 것인데, 이를테면 왼편의 연속된 구분자는 **<보통 글자> 꼴이거나 <공백>**<기호> 또는 <기호>**<기호> 꼴이어야 한다. ("보통 글자"란 공백이나 기호가 아닌 글자를 가리킨다.) 첫번째 꼴은 아무래도 **마크다운**은 같이 낱말 안에 끼어 들어가 있는 연속된 구분자를 허용하기 위한 것이고, 두번째/세번째 꼴은 이 **"마크다운"** 형식은 같이 기호 앞에 붙어 있는 연속된 구분자를 제한적으로 허용하기 위한 것이라 해석할 수 있겠다. 오른편도 방향만 다르고 똑같은 규칙을 가지는데, 이 규칙으로 **마크다운(Markdown)**은을 해석해 보면 뒷쪽 **의 앞에는 기호가 들어 있으므로 뒤에는 공백이나 기호가 나와야 하지만 보통 글자가 나왔으므로 오른편이 아니라고 해석되어 강조의 끝으로 처리되지 않는 것이다.
CommonMark 명세에서도 설명되어 있지만, 이 규칙의 원 의도는 **이런 **식으로** 중첩되어** 강조된 문법을 허용하기 위한 것이다. 강조를 한답시고 **이런 ** 식으로 공백을 강조 문법 안쪽에 끼워 넣는 일이 일반적으로는 없으므로, 이런 상황에서 공백에 인접한 강조 문법은 항상 특정 방향에만 올 수 있다고 선언하는 것으로 모호함을 해소하는 것이다. 허나 CJK 환경에서는 공백이 아예 없거나 공백이 있어도 한국어처럼 낱말 안에서 기호를 쓰는 경우가 드물지 않기 때문에, 이런 식으로 어느 연속된 구분자가 왼편인지 오른편인지 추론하는 데 한계가 있다는 것이다. 단순히 <보통 문자>**<기호>도 왼편으로 해석하는 식으로 해서 **마크다운(Markdown)**은 같은 걸 허용한다 하더라도, このような**[状況](...)**は 이런 상황은 어쩔 것인가? 내가 느끼기에는 중첩되어 강조된 문법의 효용은 제한적인 반면 이로 인해 생기는 CJK 환경에서의 불편함은 명확하다. 그리고 LLM은 CommonMark의 설계 의도 따위는 고려하지 않고 실제 사람들이 사용할 법한 식으로 마크다운을 쓰기 때문에, 사람들이 막연하게 가지고만 있던 이런 불편함이 그대로 표면화되어 버린 것이고 말이다.
![* 21. Ba5# - 백이 룩과 퀸을 희생한 후, 퀸 대신 **비숍(Ba5)**이 결정적인 체크메이트를 성공시킵니다. 흑 킹이 탈출할 곳이 없으며, 백의 기물로 막을 수도 없습니다. [강조 처리된 "비숍(Ba5)" 앞뒤에 마크다운의 강조 표시 "**"가 그대로 노출되어 있다.]](https://media.hackers.pub/note-media/17646c5d-3f9d-472b-9d56-dd34006ad291.webp)
@khrisHong Segi (aka khris) 
@hongminhee洪 民憙 (Hong Minhee) (그대로 실천하려면 애로사항이 있겠지만) 커밋을 작은 작업단위로 하고, 모델이 작업을 시작할때 그 사이 추가된 커밋을 프롬프트로 넣어주는 방법은 잘 동작할까요?
@bglbgl gwyng @hongminhee洪 民憙 (Hong Minhee) 개인적으로 느끼기에는 말씀하신대로 하는게 프롬프트로 일일히 설명하는것보단 유의미하게 더 낫기는 했습니다.
고등학생 때부터 Vim을 썼으니까, Vim/Neovim을 합치면 거의 15년 가까이 썼던 것 같다. 그러다가 Deno와 TypeScript를 접하면서 Visual Studio Code로 갈아탔는데, 그러고 한 2–3년? Zed가 나와서 Zed를 또 1년 가까이 썼다. (아, VS Code를 쓸 때도 Zed를 쓸 때도 Vim 키 바인딩을 끄지는 못 했다.)
그런데 요즘에는 Claude Code니 OpenCode니 LLM 기반의 코딩 에이전트들을 꽤 열심히 쓰게 되면서 에디터 자체를 잘 안 쓰게 되었다. 심지어 import 한 줄 추가하는 것도 프롬프트로 해결하게 된다. 그래야 LLM한테 맥락이 주어져서 혼선이 없기 때문이다. (내가 말 없이 코드를 고쳐 두면 LLM이 뭔가의 이상 상황으로 받아들이거나, 무심코 원래 코드로 되돌리기도 한다.) 그러다 보니 커밋 직전에 디테일을 손 보거나 코드를 리뷰할 때 빼고는 에디터를 잘 안 켜게 된다. 켜더라도 즉각적으로 열리는 걸 선호하게 되어서, Vim/Neovim이 가장 먼저 손이 가더라.
결국에는 몇 년 동안의 방황을 거쳐 다시 Vim/Neovim으로 돌아오게 되었다는 이야기. 그래서 조만간 먼지가 쌓인 Vim/Neovim 설정도 새해 맞이를 겸해서 한 번 청소를 해야겠다 싶다.
심지어 import 한 줄 추가하는 것도 프롬프트로 해결하게 된다. 그래야 LLM한테 맥락이 주어져서 혼선이 없기 때문이다.
이 부분 완전 공감합니다. 일일히 설명하는 방법도 써봤는데 완벽하지가 않더라구요...
미지의 영역을 프로토타이핑할때는 Sonnet으로 충분한듯... Opus 깊생하게 해봤자 토큰만 더먹는다
클로드 맥스 5x 월 16만원... 10만원만 됐어도 눈감고 지르는건데
예전에 LLM이 얼마나 복잡한 코드를 이해할 수 있는지 파악하기 위해 Gemini 2.5 모델들로 내 IOCCC 2012 수상작을 던지고 무슨 일을 하는지 실행 없이 알아 맞춰 보라고 했더니 하나도 제대로 파악하지 못했던 적이 있다. 문득 생각이 나서 Gemini 3 Pro는 개선되었을려나 생각했는데, 힌트 하나만 받고 10분동안 생각하더니 완벽하게 응답에 성공했다! 심지어 설명도 실행 없이 분석했다는 걸 감안할 때 매우 정확했다. IOCCC 수상작을 모두 기억하고 있을 가능성을 감안해 이전에 본 적이 있냐고 물어 보니 환각(...)을 내뱉는 것도 그렇고(그보다 외웠다면 처음에 바로 정답을 얘기했겠지), 실제로 생각 과정을 보면 사람이 할 법한 분석을 전부 하고 있는 걸 보니 진짜로 LLM들의 reasoning 능력이 이 정도 수준에 도달했음을 알 수 있다. 세상 참 많이 발전했네.
![> 다음 C 프로그램이 하는 일을 알려 줘. [코드 생략]
이 C 프로그램은 **난독화(obfuscated)**된 코드로, 입력받은 **시간 또는 단위가 포함된 문자열**을 해석하여 총합을 계산한 뒤, 그 결과를 **16진수(Hexadecimal)**로 출력하는 프로그램입니다.
구체적인 작동 방식은 다음과 같습니다:
1. **입력 처리**:
* `getchar()`를 통해 표준 입력(stdin)에서 문자를 하나씩 읽어들입니다.
* `|32`를 통해 대문자를 소문자로 변환하여 처리합니다.
2. **문자 매핑 (해싱)**:
* `"ynwtsflrabg"`라는 문자열은 입력받은 문자가 특정 단위(예: year, week, second 등)인지 확인하기 위한 인덱스 문자열입니다.
* 입력된 문자가 이 문자열에 포함되면 변수 `b`에 특정 해시 값을 누적합니다.
3. **단위 변환 및 계산**:
* `"1+DIY/.K430x9G(kC["`라는 복잡한 문자열은 **룩업 테이블(Lookup Table)** 역할을 합니다.
* 내부 루프에서 이 테이블과 비트 연산(`&255^b`)을 통해 현재 입력된 단위가 무엇인지(예: 'y'가 연도인지, 's'가 초인지) 판별합니다.
* `u=1ll<<6177%n--*4` 부분은 각 단위에 맞는 **가중치(Multiplier)**를 계산합니다. `<<` 비트 시프트 연산을 사용하는 것으로 보아, 특정 단위마다 2의 제곱수 형태의 배수를 적용하거나, 혹은 시간을 초 단위(또는 나노초 단위)로 변환하는 계수를 생성합니다.
4. **결과 누적**:
* 변수 `m`에 파싱된 수치와 단위 가중치를 곱하여 누적합니다.
5. **출력**:
* 최종적으로 계산된 값 `m`을 `printf("%llx\n", m)`을 통해 **16진수(long long hex)** 형태로 출력합니다.
**요약하자면:**
이 코드는 "1y(1년)", "2w(2주)", "30s(30초)"와 같은 형식의 텍스트를 입력받아, 이를 초(second)나 특정 기본 단위로 환산한 총합을 16진수로 보여주는 **단위 변환 계산기**입니다.](https://media.hackers.pub/note-media/53eb3036-9463-495d-bb5c-a04de12a7f21.webp)
pyodide를 사용해서 python으로 된 앱을 정적 웹사이트로 서빙 https://khris.github.io/woodcut/
클로드가 너무 못생기게 만들어서 bootstrap(ㅈㅅ ㅋㅋ)인가? 했는데 자체 CSS였네...
pyodide를 사용해서 python으로 된 앱을 정적 웹사이트로 서빙 https://khris.github.io/woodcut/
LLM(과 그것을 사용한 앱)을 사용한다는 것은 확률을 내가 어느정도는 조작할 수 있는 가챠인것 같다.
클로드 코드 쓰면서 처리가 가장 오래걸리는 프롬프트: /compact
You've hit your limit · resets 9pm (Asia/Seoul)
GUI앱을 못보니까 콘솔로 출력해서 본다는 점이 정말... 나보다 낫군
목공용 절단도면 만들어주는 프로그램 뇌 비우고 Claude Code한테 시켰더니 때깔이 좋네
근데 뇌비우고 했더니 쟤가 짠 코드 못고치겠다
목공용 절단도면 만들어주는 프로그램 뇌 비우고 Claude Code한테 시켰더니 때깔이 좋네
Hong Segi (aka khris) shared the below article:
Claude Code의 거의 모든 것은 Tool Use 입니다. MCP도 subagent도 Skills 역시요.
자손킴 @jasonkim@hackers.pub
이번 글에서는 지난글에 이어서 Claude가 도구를 사용하는 구체적인 방법을 알아본다. Claude가 사용할 수 있는 도구들의 목록은 Tools 섹션에 포함되어 있다. Tools 섹션에 대해서는 이전 글을 참고한다.
Tool Use 란?
Tool Use는 Claude가 외부 도구(함수)를 호출하여 실제 작업을 수행할 수 있게 하는 메커니즘이다. Claude는 텍스트 생성만으로는 수행할 수 없는 작업들, 예를 들어 파일 읽기, 명령어 실행, 웹 검색 등을 도구를 통해 수행한다.
Claude에게 사용 가능한 도구들의 스키마를 알려주면 Claude는 사용자의 요청을 분석하여 적절한 도구를 선택하고 필요한 파라미터와 함께 도구 사용을 요청한다. 에이전트(클라이언트)는 이 요청을 받아 실제로 도구를 실행하고 그 결과를 다시 Claude에게 전달한다.
Tools 섹션: 도구 정의하기
Claude가 도구를 사용하려면 먼저 어떤 도구가 있는지 알아야 한다. 에이전트는 API 요청의 tools 배열에 사용 가능한 도구들을 정의한다. 각 도구는 이름, 설명, 그리고 입력 스키마를 포함한다.
Bash 도구 정의 예시
{
"name": "Bash",
"description": "Executes a given bash command in a persistent shell session with optional timeout, ensuring proper handling and security measures.\n\nIMPORTANT: This tool is for terminal operations like git, npm, docker, etc...",
"input_schema": {
"type": "object",
"properties": {
"command": {
"type": "string",
"description": "The command to execute"
},
"timeout": {
"type": "number",
"description": "Optional timeout in milliseconds (max 600000)"
},
"description": {
"type": "string",
"description": "Clear, concise description of what this command does in 5-10 words, in active voice."
}
},
"required": ["command"],
"additionalProperties": false,
"$schema": "http://json-schema.org/draft-07/schema#"
}
}Glob 도구 정의 예시
{
"name": "Glob",
"description": "- Fast file pattern matching tool that works with any codebase size\n- Supports glob patterns like \"**/*.js\" or \"src/**/*.ts\"\n- Returns matching file paths sorted by modification time\n- Use this tool when you need to find files by name patterns",
"input_schema": {
"type": "object",
"properties": {
"pattern": {
"type": "string",
"description": "The glob pattern to match files against"
},
"path": {
"type": "string",
"description": "The directory to search in. If not specified, the current working directory will be used."
}
},
"required": ["pattern"],
"additionalProperties": false,
"$schema": "http://json-schema.org/draft-07/schema#"
}
}도구 정의에서 description이 중요하다. Claude는 이 설명을 읽고 어떤 상황에서 해당 도구를 사용해야 하는지 판단한다. input_schema는 JSON Schema 형식으로 Claude가 도구를 호출할 때 어떤 파라미터를 어떤 형식으로 전달해야 하는지 정의한다.
Claude가 도구를 선정하는 방법
Claude가 도구를 선택하는 과정은 Messages API의 대화 흐름 속에서 이루어진다. 실제 예시를 통해 살펴보자.
사용자의 요청
사용자가 "이 NestJS 프로젝트에서 entity 구조를 탐색해주세요"라고 요청하면 에이전트는 다음과 같은 메시지를 API에 전송한다:
{
"role": "user",
"content": [
{
"type": "text",
"text": "이 NestJS TypeScript 프로젝트에서 entity 구조를 탐색해주세요..."
}
]
}Claude의 도구 사용 요청
Claude는 사용자의 요청을 분석하고 작업 수행에 필요한 도구들을 선택하여 tool_use 블록으로 응답한다:
{
"role": "assistant",
"content": [
{
"type": "text",
"text": "이 NestJS 프로젝트의 entity 구조를 철저하게 탐색하겠습니다."
},
{
"type": "tool_use",
"id": "toolu_01ABC123XYZ",
"name": "Glob",
"input": {
"pattern": "**/*.entity.ts"
}
},
{
"type": "tool_use",
"id": "toolu_01DEF456UVW",
"name": "Bash",
"input": {
"command": "find /workspace/my-nestjs-project/src -type f -name \"*.ts\" | grep -E \"(entity|entities)\" | head -20",
"description": "Find entity files in src directory"
}
}
]
}여기서 주목할 점이 있다. Claude는 한 번의 응답에서 여러 도구를 동시에 요청할 수 있다. 위 예시에서는 Glob과 Bash 두 도구를 병렬로 요청했다. 각 도구 요청에는 고유한 id가 부여되어 나중에 결과를 매핑할 때 사용된다.
응답의 stop_reason
Claude가 도구 사용을 요청하면 API 응답의 stop_reason이 "tool_use"로 설정된다:
{
"id": "msg_01XYZ789ABC",
"type": "message",
"role": "assistant",
"model": "claude-haiku-4-5-20251001",
"content": [...],
"stop_reason": "tool_use",
"usage": {
"input_tokens": 714,
"output_tokens": 314
}
}이 stop_reason은 에이전트에게 "응답이 끝난 것이 아니라 도구 실행이 필요하다"는 신호를 보낸다.
에이전트는 tool_use 요청을 받으면 무엇을 하는가?
에이전트(클라이언트)가 stop_reason: "tool_use" 응답을 받으면 다음 단계를 수행해야 한다:
-
도구 요청 파싱: 응답의
content배열에서type: "tool_use"블록들을 추출한다. -
도구 실행: 각 도구 요청에 대해 실제 도구를 실행한다. 예를 들어:
Bash도구 → 시스템에서 실제 bash 명령어 실행Glob도구 → 파일 시스템에서 패턴 매칭 수행Read도구 → 파일 내용 읽기
-
결과 수집: 각 도구의 실행 결과를 수집하고
tool_use_id와 함께 결과를 구성한다. -
모델에 결과 전달: 수집한 결과를
tool_result형식으로 모델에 다시 전송한다.
이 과정에서 에이전트는 도구 실행의 성공/실패 여부, 타임아웃 처리, 보안 검증 등을 담당한다. Claude는 도구의 스키마와 용도만 알 뿐 실제 실행은 에이전트의 몫이다.
에이전트가 모델에 도구 실행 결과를 알리는 방법
에이전트가 도구를 실행한 후에는 그 결과를 tool_result 형식으로 모델에 전달한다. 이 결과는 user role의 메시지로 전송된다.
tool_result 구조
{
"role": "user",
"content": [
{
"tool_use_id": "toolu_01DEF456UVW",
"type": "tool_result",
"content": "/workspace/my-nestjs-project/src/modules/chat/entities/dm-unlock.entity.ts\n/workspace/my-nestjs-project/src/modules/agora/entities/call-session.entity.ts\n/workspace/my-nestjs-project/src/modules/user/entities/user.entity.ts\n/workspace/my-nestjs-project/src/modules/user/entities/user-profile.entity.ts\n/workspace/my-nestjs-project/src/modules/item/entities/item.entity.ts\n...",
"is_error": false
},
{
"tool_use_id": "toolu_01ABC123XYZ",
"type": "tool_result",
"content": "/workspace/my-nestjs-project/src/modules/agora/entities/agora-event-log.entity.ts\n/workspace/my-nestjs-project/src/modules/agora/entities/call-participant.entity.ts\n/workspace/my-nestjs-project/src/modules/item/entities/item.entity.ts\n...",
"cache_control": {
"type": "ephemeral"
}
}
]
}각 tool_result의 핵심 필드는 다음과 같다:
| 필드 | 설명 |
|---|---|
tool_use_id |
Claude가 요청한 도구의 고유 ID. 어떤 요청에 대한 결과인지 매핑 |
type |
항상 "tool_result" |
content |
도구 실행의 실제 결과 (문자열) |
is_error |
도구 실행 실패 시 true |
cache_control |
(선택) 프롬프트 캐싱을 위한 제어 옵션 |
전체 대화 흐름
tool_result를 받은 Claude는 결과를 분석하고 추가 도구가 필요하면 다시 tool_use를 요청한다. 충분한 정보가 모이면 최종 응답을 생성한다. 이 과정이 반복되면서 복잡한 작업도 단계별로 수행할 수 있다:
User → Claude: "entity 구조를 탐색해주세요"
Claude → Agent: tool_use (Glob, Bash)
Agent → Claude: tool_result (파일 목록)
Claude → Agent: tool_use (Read - 여러 파일)
Agent → Claude: tool_result (파일 내용들)
Claude → User: 최종 분석 결과실제 예시에서 Claude는 먼저 Glob과 Bash로 entity 파일 목록을 찾고 그 결과를 받은 후 Read 도구로 개별 파일들을 읽어 분석했다:
{
"type": "text",
"text": "좋습니다. 이제 주요 entity 파일들을 읽겠습니다."
},
{
"type": "tool_use",
"id": "toolu_01GHI789RST",
"name": "Read",
"input": {
"file_path": "/workspace/my-nestjs-project/src/modules/user/entities/user.entity.ts"
}
},
{
"type": "tool_use",
"id": "toolu_01JKL012MNO",
"name": "Read",
"input": {
"file_path": "/workspace/my-nestjs-project/src/modules/user/entities/user-profile.entity.ts"
}
}마무리
Claude Code와 같은 에이전트는 모델에 사용할 수 있는 도구를 알려주어 도구를 능동적으로 사용하게 만듦으로써 유저의 실행환경과 상호 협력하여 도구를 실행한다. 유저에게 질문을 하는 AskUserQuestion도 도구이고 심지어 계획 모드를 빠져나가는 ExitPlanMode도 도구다.
MCP(Model Context Protocol) 서버가 제공하는 기능들도 결국 도구로 노출되며 Subagent 호출도 도구를 통해 이루어진다. Skills도 마찬가지다. 결국 Claude Code의 거의 모든 확장 기능은 Tool Use라는 하나의 메커니즘 위에서 동작한다.
이 구조를 이해하면 Claude Code가 어떻게 파일을 읽고, 코드를 실행하고, 웹을 검색하는지 명확해진다. 그리고 새로운 도구를 추가하거나 MCP 서버를 연동할 때도 같은 패턴이 적용된다는 것을 알 수 있다.
'를 기본으로 사용하면 문장 중간중간에 들어가는 '를 항상 이스케이핑 해줘야되기 때문에 " 를 기본으로 하는게 좋다는 주장에... 승복하고 말았음
올해도 Advent of Code는 글렀다
나도 세부 디테일과 맥락을 잃어가면서 헛다리를 계속 짚게된다 이것이 관리직?
Codex 쓸맘이 안드는게 ChatGPT는 틈만나면 친한척 해서 Claude 계속 씀
Black 이거 왜 인기지? 문자열 기본이 홑따옴표가 아니라 쌍따옴표인데? 게다가 끄는 옵션만 있고 홑따옴표로 강제하는건 없네? Black 불매한다
뭐 쓰지 말라는소리가 너무많네 있으면 쓰는거지
타임라인의 엔지니어님들께 여쭙습니다. 제가 CLI에서 동작하는 파이썬 코드를 작성해도 다른 사람들의 로컬에 파이썬이 설치되어있지 않고 이를 가이드하기도 어려워서 웹 주소 하나를 띡 던지면 브라우저 안에서 바로 실행해보도록 하고싶습니다. 적당한 방법, 서비스, 솔루션에는 어떤 것이 있을까요.
참고로 도커를 24시간 돌리는 기계가 있습니다.
@meWoojin Kim Jupyter Notebook 서빙을 하는것도 적당해 보입니다. 이건 제가 직접 써본건 아닌데 다중 사용자를 지원하는 JupyterHub(https://jupyterhub.readthedocs.io/en/latest/)란게 있어서 이걸로 서빙하면 될거같습니다.
사실 제일 간단한건 https://programiz.pro/ide/python/UGB386YP4Z 이런 playground(?)류 사이트 중에서 공유를 지원하는걸 쓰는거지만요.
타임라인의 엔지니어님들께 여쭙습니다. 제가 CLI에서 동작하는 파이썬 코드를 작성해도 다른 사람들의 로컬에 파이썬이 설치되어있지 않고 이를 가이드하기도 어려워서 웹 주소 하나를 띡 던지면 브라우저 안에서 바로 실행해보도록 하고싶습니다. 적당한 방법, 서비스, 솔루션에는 어떤 것이 있을까요.
참고로 도커를 24시간 돌리는 기계가 있습니다.
@hongminhee洪 民憙 (Hong Minhee) 웹뷰써서 안됩니다~~~
환경 보호를 위해 electron등을 사용한 webview기반 애플리케이션을 더 이상 만들지 못하게 해야합니다
어지간해선 적절한 키보드 높이에 맞는 책상을 찾기 어려운데, 키보드 전용 움직이는 책상 같은거라도 찾아봐야 할 듯.
역시 코딩의 재미는 차력쑈에 있다. 코드 골프, Reactive Programming, TypeScript같은 언어에서 타입으로 이상한짓 하기 등...
Reactive Programming(정확히는 그 코드의 형태)를 내가 좋아하는 이유는 뭘까? 생각해봤는데 선언적인거 이전에 일종의 불렛포인트로 작성된 문서라는 느낌을 주기 때문인듯? 아무래도 코루틴이나 Promise나 그런걸 쓰면 줄글같죠...
역시 코딩의 재미는 차력쑈에 있다. 코드 골프, Reactive Programming, TypeScript같은 언어에서 타입으로 이상한짓 하기 등...
안녕하세요, 백엔드 경력직 프로그래머 뽑고 있습니다. 로그를 모니터링하고 저장하는 시스템을 개발하는 포지션입니다. 기존 오픈소스 솔루션을 사용하긴 하지만 단순히 구축하고 운영하는 것은 아닙니다. 운영도 하지만 개발이 주된 업무 입니다. (오픈소스 솔루션 운영 포지션으로 착각하고 지원하시는 분들이 계셔서 사족을 넣었습니다) https://careers.linecorp.com/ko/jobs/2845/
Hong Segi (aka khris) replied to the below article:
Stop writing CLI validation. Parse it right the first time.
洪 民憙 (Hong Minhee) @hongminhee@hackers.pub
This post introduces Optique, a new library created to address the pervasive problem of repetitive and often messy validation code in CLI tools. The author was motivated by the observation that nearly every CLI tool reinvents the wheel with similar validation patterns for dependent options, mutually exclusive options, and environment-specific requirements. Optique leverages parser combinators and TypeScript's type inference to ensure that CLI arguments are parsed directly into valid configurations, eliminating the need for manual validation. By describing the desired CLI configuration with Optique, TypeScript automatically infers the types and constraints, catching potential bugs at compile time. The author shares their experience of deleting large chunks of validation code and simplifying refactoring tasks. Optique aims to provide a more robust and maintainable approach to CLI argument parsing, potentially saving developers from writing the same validation logic repeatedly.
Read more →@hongminhee洪 民憙 (Hong Minhee) 이 소개글을 보고 TypeScript의 타입 시스템을 더 사랑하게 되었습니다.
Github merge queue 이제야 보는데 이걸로 Stacked PR(or Diff) 할수있다고 한 사람 누구야? 관계없잖아...
LLM을 적절하게 팀에 도입하는 방법을 모르겠다. (특히 주니어의) 학습과 단련을 위해 LLM을 의도적으로 배제해야 할 필요도 있을텐데... 하지만 LLM 도구를 사용하는 것도 추구해야 할 학습과 단련의 범주에 포함됨.
그리고 조금 다른 이야기지만 프로젝트에 바이브 코딩을 제대로 도입하는건 비가역적인 변화에 가깝다. 결국 사람이 일일히 다 검수하면 그건 비효율적임. 프로젝트에 들이려면 구현체를 어느 정도 블랙박스로 취급하고 테스트 수트 등에 의존해야 하는데, 생각보다 별로라서 돌아가려면 다시 알지도 못하는 코드베이스에 던져져야함. AI를 믿고 쓴다는 가정이었기 때문에 코드 퀄리티와 컨벤션도 장담할 수 없음.
LLM을 적절하게 팀에 도입하는 방법을 모르겠다. (특히 주니어의) 학습과 단련을 위해 LLM을 의도적으로 배제해야 할 필요도 있을텐데... 하지만 LLM 도구를 사용하는 것도 추구해야 할 학습과 단련의 범주에 포함됨.
영화 <퀴어> 각본가 저스틴 커리츠키스, 이화여대·모모의 한국퀴어영화제 대관 거부에 대해 말하다
저는 루카 과다니노 감독의 영화 <퀴어>의 각본가 저스틴 커리츠키스입니다. 최근 우리의 영화가 서울 이화여자대학교 내 아트하우스 모모에서 상영될 것이라는 것을 알았습니다. 평소라면 이런 뉴스에 무척 기뻤겠으나, 오늘은 위선이 저를 분노케합니다.
전설적인 퀴어 작가 윌리엄 S. 버로우의 책을 원작으로 하는 <퀴어>는, 1950년대 멕시코시티를 배경으로 한 두 미국인 남성의 사랑을 그렸습니다. 이러한 우리 영화를 상영하고 홍보하는 아트하우스모모와 그 공간의 실질적 소유주인 대학은, 얼마전 한국퀴어영화제의 아트하우스모모 대관을 거부했습니다. 그들은 퀴어영화제가 대학의 “기독교 가치”에 반하고, “청년 대학생에게 동성애를 선전할 위협이 있다”는 반LGBTQ 집단의 압력에 굴복해 이런 결정을 내렸습니다.
이런 결정은 당연하게도, 많은 면에서 터무니없습니다. 영화가 누군가를 성소수자로 만들지 않습니다. 좋은 영화는 그저 현실을 반영할 뿐이고, 퀴어는 인류 역사 최초의 순간부터 세계 어디서나 존재했고 또 존재해 왔다는 것이 바로 현실입니다. 게다가 퀴어는 영화라는 예술이 최초로 탄생하던 순간부터 영화의 창작과 관계 맺었습니다. 전면적으로 퀴어 이야기를 담은 작품이 끊임없이 억압당하고 낙인찍히던 때조차도 말이죠. 일생을 영화관에 가거나 집에서 영화를 시청한 영화 애호가라면 누구나 배우, 작가, 감독, 촬영 스태프, 조명 감독, 카메라맨, 프로듀서 등 수많은 퀴어 예술가들의 작업을 즐긴 적이 있을 것입니다. 퀴어가 그저 퀴어이듯, 퀴어 영화도 그저 영화일 뿐입니다. 이 사실을 무시하는 것은 의도적인 무지에 스스로를 내던지는 행위입니다. 그리고 이 무지는 이미 낙인찍힌 사람들을 추가로 위협하고, 스스로의 지성과 인간성을 모욕합니다.
우리의 영화 <퀴어>에 관해 말씀드리자면, 이화여대가 대학의 “가치”에 반한다는 이유로 한국의 퀴어 영화를 거부하는 반면 해외 퀴어 영화인 <퀴어>를 홍보하고자 하는 것은 몹시 황당합니다. 이화가 우리 영화를 상영할 준비가 되었다면, 한국에서 제작된 퀴어 영화들의 터전이 되는 것을 기쁘게 받아들이고 적극적으로 나서야 할 것입니다. 이런 결정은 세계 영화의 지형을 더욱 풍요롭게 하고 대학 스스로를 더 명예롭게 만들 것입니다. 대학의 일차적 “가치”는 결국 진실에 대한 헌신입니다. 그러므로, 나는 이화가 한국퀴어영화제 대관 거부 결정을 재검토하고, 다양한 인간적 경험을 다루는 모든 표현에 대한 국내와 해외 영화를 모두 환영하기를 바랍니다.
감사합니다.
cc. https://x.com/kqcfkqff/status/1935583115671658682
@khrisHong Segi (aka khris) 오… njs라는 게 있었군요? 처음 알았습니다.
@hongminhee洪 民憙 (Hong Minhee) 넵 아무래도 nginx로는 기존에 lua로 스크립팅을 많이해서 좀 덜 알려진거같고, 주력으로 밀지는 않는거같아요. 공식 문서도 deprecated 상태인것도 있을정도고... QuickJS 들어오기 전까지는 ES6도 부분적 지원만 하기도 해서요.
하지만 외부 라이브러리도 적당히 번들링하고 import 하면 되니 어떻게든 문제되는 부분만 간단하게 해치우고 십수년 전통의 다른 부분(리버스 프록시 등등)은 의존하고 싶을때는 이만한게 없는거같아요. 물론 lua나 OpenResty가 있긴 하지만 npm의 존재가 무시하기 힘들더군요… 마침 저는 grafana의 lezer-logql(파서)을 썼어야 했어서요.
한편 새로 도입된 QuickJS라는 경량 JS 엔진은... ffmpeg과 qemu로 유명한 Fabrice Bellard 씨 작품… 진짜 뭐 이런 사람이 다 있지???
Nginx의 njs에 QuickJS 엔진 추가되니 기능이나 문법 제약도 거의 없어서 출근해서 해볼 성능 테스트만 제대로 되면 좀 복잡한 로직 필요한 리버스 프록시는 이걸로만 짤거같음. JS모듈들 대충 번들로 만들고 import해서 다 쓸수 있어서...
@khrisHong Segi (aka khris) 답글 감사합니다! LangDev에 올리신 채팅으로 해당 공고를 미리 알게 되었습니다.
본문에 적었듯이, 제가 올해 하반기에 전공 필수 이수가 하나가 남아 있어서, 재직 증명을 바탕으로 교수진과 유연한 수업 이수 방식에 대한 추후 협의가 필요한 상황인데요.
제가 지원하는 직무와 연관이 있는 조직 내 동료 등 여러 이해관계자에게 이런 상황의 지원자가 지원해도 괜찮은지 사전에 확인을 받고 싶습니다.
안녕하세요, 업으로 프로그래밍을 하고 있는 컴퓨터 학부생 김무훈입니다.
현재 3년차 웹 프론트엔드 개발자로서, 다가오는 7월부터 함께할 정규직 포지션을 적극적으로 찾고 있습니다.
최근 학과 사무실에서 졸업 요건을 확인한 결과, 전공 필수 한 과목과 전공 선택 2학점(총 5학점)이 남아있음을 확인했습니다.
본래는 다음 2학기까지 수료 후 내년 2월에 졸업할 예정이었으나, 교수진과 상의한 결과 취업 및 재직이 확정된다면 수업 이수 방식을 보다 유연하게 결정할 수 있다는 긍정적인 답변을 받아 적극적으로 조기 취업을 추진하게 되었습니다.
이는 전공 필수 과목의 경우에만 해당이 되는 문제이고, 전공 선택 2학점의 경우 앞으로의 여름 학기 현장 실습 또는 다음 학기에 개설되는 하나의 원격 강의로 대체하여 문제가 없는 상태입니다.
지금까지의 업무 경험과 프로젝트는 아래의 포트폴리오에서 확인하실 수 있습니다.
📌 경력기술서 겸 포트폴리오 페이지: https://www.frontend.moe/portfolio/
좋은 인연을 찾을 수 있도록, 많은 관심과 연락 부탁드립니다!
AI에 대한 SW 엔지니어들의 자신감은 "어쨌거나 업계 내에서 만드는거라서-" 인거 같다. 손바닥 위에 있다는 감각(얼추 맞긴 하다).
타 직업군은 AI나 LLM 솔루션 자체를 다루는데도 한계가 있거니와(아무래도 fork떠서 고친다거나 할순 없으니까) 결과물도 자기 의사와 관계 없이 학습당하고 있기 때문에…
아예 거스를 수 없는 것이기 때문에, 타 분야에서는 오히려 공격적으로 자기 분야에 특화된 모델을 만들고, 기존 저작물들을 학습으로 부터 보호해서 우선권을 선점 하는게 그나마 좀 더 낫지 않을까?
근데 후자는… 테크기업이 양아치라서 잘 안될거같다.
아니미친 살다살다 이제 청소기도 소프트웨어 업데이트를 해???????? 자전거 변속기 소프트웨어 업데이트 후 오랜만에 느끼는 기괴함.
@meWoojin Kim 변속기도 이제 그런게 들어가나요???? 세상에
아무래도 Github Copilot 잘 안쓰게 되는게 사람말이 가장 어려워서인거 같다
개인적으로는 k8s쓰는 가장 큰 이유는 개발자 복지라고 생각한다. 적정기술만 쓰면 대부분의 사람들은 뭔가를 실 서비스에서 경험할 기회를 잃어버린다. 아니 이건 됐고…
온프레미스 클러스터 오퍼레이션 부담이나 EKS같은 서비스의 사용료 걱정만 없다면 쓰는게 무조건 낫다고 생각한다.
일단 k8s뿐만 아니라 컨테이너/머신 오케스트레이션의 세계에서 앱과 머신은 좀 더 잘 죽어도되는 존재가 된다. (물론 stateful한 호스트와 앱을 최대한 stateless하게 하거나, 상태를 분리하여 격리시켜야 하긴 한다)
그러면 docker-compose로 충분하지 않느냐 말할 사람도 있겠지만 처음에야 docker-compose 쓰는거나 k8s 쓰는거나 그게 그거지만(오히려 k8s가 성가실것이다) 마이그레이션의 때가 오면 난 그걸 감당할 자신이 없다.
물론 자신만의 가볍고 쏙 맘에드는 솔루션을 고집할 사람도 있을텐데… 난 남들이 다 쓰는거 쓰는게 편하다.
v1의 구현방식이 매력적이었는데 한계로 인해 결국 v2의 방식을 택하게된게 참 아쉬웠다…
RE: https://hl.pkgu.net/@pkgupdt/019627a1-2be1-763a-90e2-1e10ce1df445
Claude code를 잘 써보려고 이렇게 저렇게 해보는 중.
코드는 잘 찍어내는데… 가끔씩 삑사리를 내서 끝도없는 삽질하느라 크레딧만 쳐묵쳐묵해서 쳐다보고 있다가 끊어줘야한다.
내가 없어도 이 정도 할 수 있으면(시간당 $5정도) 쓸만한데… 계속 쳐다보고 있을거면… 그냥 클로드 웹(월 $20)이나 깃헙 코파일럿(월 $10)보다 나을 게 없다.
사실 휴먼 개발자도 비슷하다. 해보고 안되면 “적절한” 시점에 도움을 청해야하는데… “적절한”게 어렵다. 제대로 해보지도 않고 도움을 청해도 안되고, 안되는 걸 끝까지 붙잡고 있어도 안된다.
이 녀석에게 “적절함”을 어떻게 가르쳐야하나…
AI한테 코딩을 왜 시킵니까? 팀원들한테 JIRA 이슈 배분하면 되는데... ㅠㅠ