팀에서는 레포가 여러개 있습니다. 프론트를 예로 치면 product-desktop, product-mobile 처럼 있는 셈입니다.. 다들 Claude Code나 Codex 같은 AI Agent를 쓰기 때문에 스킬을 커밋하여 공유하고 있는데요. 아무래도 같은 프론트라면 공통적인 스킬들(예: 아키텍처 등)도 있을 겁니다.

여기서 몇가지 문제가 생깁니다.

• 스킬 개선하면 레포마다 같은 스킬 복사해서 넣기...
• 다른 브랜치에 커밋했으면 체리픽 해오기...
• 결론 : 스킬 하나 수정하면 = 복사 × 붙여넣기 × 커밋 × N개 레포 × M개 브랜치
• 다른 팀과 공유하려면 zip으로..?

게다가 public github는 보안상 쓰기 어렵기에... 어디에다 올려서 쓸 수 없었습니다. bitbucket에 올리는거 까지는 괜찮은데 이걸 레포마다 동기화하는건 어떻게 해결하지? 라는 생각이 들었습니다. 심볼릭 링크면 이를 해결할 수 있을 것 같았고, 그래서 만든 CLI도구가 바로 agent-skill-cast 입니다. 마치 마법을 외우는거 처럼 스킬을 agent에게 장착 시키는 CLI도구입니다.

Agent Skill Cast

먼저 설치를 진행합니다.

npm install -g agent-skill-cast

1. 스킬 소스 등록 (GitHub 레포 또는 로컬 폴더) 먼저 스킬을 가져올 소스를 정합니다.

   cast source add https://github.com/your-team/shared-skills
   cast source add ~/projects/my-skills

2. 필요한 스킬 선택 인터렉티브 UI로 스킬을 선택할 수 있습니다.

   cast use
   cast use my-skills/react

   선택한 스킬은.claude/skills/, .gemini/skills/, 또는 .codex/skills/ 하위에 심볼릭 링크됩니다

3. 동기화

   cast source sync

   명령으로 모든 외부 소스를 pull 받습니다. (로컬 폴더는 symbolic link라 pull X)

작동 방식

1. home 디렉터리에 소스를 넣습니다. (외부 레포면 clone, 로컬 폴더면 심볼릭 링크)
2. cast use로 사용할 때마다 해당 skill을 .claude/skills 하위로 심볼릭 링크를 합니다.

스킬 소스 (GitHub/Local)
         ↓
~/.asc_sources/shared-skills/  ← 클론/심볼릭 링크
         ↓
    ┌────┼────┐
    ↓    ↓    ↓
프로젝트 A  B  C
.claude/skills/ → [symlinks]

• 디스크 낭비 제로: 복사본이 아닌 심볼릭 링크
• 즉시 업데이트: 소스 변경이 모든 곳에 반영
• 선택적 설치: 각 프로젝트마다 다른 스킬 조합 가능

스킬 감지

소스의 폴더를 기준으로 각 agent 폴더(.claude/skills 등)와 1~2 depth에서 SKILL.md가 존재하는 폴더를 탐색합니다.

• /.claude/skills/react/SKILL.md
• /mobile/screen/SKILL.md
• /docs-write/SKILL.md

와 같은 케이스를 모두 지원합니다.

따라서 실제 사용하고 있는 프로젝트를 소스로 삼거나, https://github.com/ComposioHQ/awesome-claude-skills와 같은 외부 프로젝트를 모두 소스로 삼을 수 있습니다.

미래

앞서 개발 계기에서 이야기한 것 처럼, 현재 레포의 스킬을 특정 git reop를 통해 publish하는 기능 까지 계획했었는데, 생각보다 사용자 플로우 정의가 어려워서 우선은 use에 초점을 맞췄습니다.

사용 예시

Github : https://github.com/Shin-JaeHeon/agent-skill-cast

wttr.in은 wego의 래핑으로 시작한 프로젝트로 콘솔 지향 기상 예보 서비스다. 이미지 없이 Text만으로도 멋진 날씨 정보를 볼 수 있는 서비스다. 자세한 정보는 https://github.com/chubin/wttr.in 를 참조하면 된다.

원문 보기 : jaeheon.kr/277

마진상쇄가 일어나는 것은, 문서에 비유해서 생각하면 왜 발생하는지 이해하기가 쉽다. 또한 margin을 적어도 n픽셀의 빈 공간이 있어야 한다고 생각한다면, 마진상쇄 현상을 이해하기 쉽다.

em과 rem의 차이에 대해 설명한다.

em, rem을 꼭 써야 하는 걸까?

em과 rem을 꼭 써야하는지에 대해 설명하는 문단이다.

em과 rem을 사용하면 좋은 경우

em과 rem을 적절히 활용한 페이지의 예시에 관한 문단.

전체 내용은 https://jaeheon.kr/242 에서 확인할 수 있다.

• Awaited 유형을 통한 Promise 개선
• 사용하지 않는 import 제거를 끄는 플래그 추가
• in 연산자를 통해 private 필드 존재 확인
• realpathSync.native를 통한 로드 성능 개선
• 기타 등등

자세한 글은 https://jaeheon.kr/239에서 확인 가능

원문 보기

목차 소개

메타버스로 가득 찬 메타버스

여기도, 저기도, 온통 메타버스로 가득하다...

원격근무는 메타버스가 아니다

원격근무의 효과를 메타버스로 포장해서는...

솔직히 메타버스가 더 불편해보인다

급해서 계단을 뛰어서...

VR 쇼핑몰이라는 예제

예전에 액티브X 때문에...

자꾸 현실로 넘어온다

위에서 언급된 맥락과 유사한...

모니터 안에서 모니터 보기?

적어도 메타버스 솔루션에서 무언가 다른 작업을...

모니터에서 벗어나면 됐었네

생각해보니, 모니터에서 벗어나면 된다....

스큐어모피즘

지금까지 메타버스는 마치 스큐어모피즘 같다...

미니멀 메타버스?

한 발자국 먼저 앞서서 생각해보면...

그래도 메타버스는 좋은 솔루션이다

현실과 디지털을 통합하는 데 있어서....

미래는 게임 소설이다!

아무리 봐도 메타버스의 최종 종착지는....

아닌가? 메트릭스인가?

빛이 게임 소설이라면 어둠은...

https://jaehoen.kr/225

본문은 https://jaeheon.kr/187 에서 확인

https://jaeheon.kr/186

• 필멸적인 도지코인
• VTI

자세히 보기 : https://jaeheon.kr/185

자세히 보기 : https://jaeheon.kr/184

2월 4일부터 시작한 토이프로젝트 하나를 공개할 수 있게 되었다.

시작은 평단가 계산기지만, 금융과 관련된 기능들을 더 추가할 예정이다. 다크모드는 당연히 지원한다.

접속 주소는 https://findon.kr 이다.

개발 의도

가장 큰 이유는 국내에서, 경제와 관련된 서비스들은 UI가 불친절 하거나 예쁘지 않은 경우가 많았는데, 이러한 부분을 개선하고 싶었다.

UI 소개

간단한 UI로 구성되어있다.

단위 및 테마 변경이 가능하다.

이 글의 원본은 https://jaeheon.kr/161 입니다.

await과 async

자바스크립트에서 async, await을 사용하면 좀 더 깔끔한 코드를 작성할 수 있습니다. 하지만, 적절하게 사용하지 않으면 적지 않은 시간을 사용해야할 수도 있습니다. 특히, 여러개의 await을 사용할 경우에 주의해야합니다.

위와 같은 코드가 있을 때, end를 보려면 얼마나 기다려야할까요?

2700ms를 기다려야합니다. 생각보다 긴 시간입니다.

Promise.all를 사용해서 시간을 단축해보았습니다. 이제는, 1900ms만 기다리면됩니다. 800ms나 줄였습니다.

하지만 아직 개선의 여지가 있어보입니다.

자, 이제 1200ms면 모든 작업을 끝내고, end를 볼 수 있습니다. API의 응답시간 개선 없이 1700ms를 단축했습니다.

왜 이런 차이가 발생할까요?

async, await을 사용하는 목적은 코드를 동기식으로 작성하기 위함입니다.

1개만 있을 때에는 크게 문제가 되지 않지만, 두 개 이상의 await을 사용할 시에는 의존관계를 면밀히 살펴봐야 할 필요가 있습니다.

예를 들어, read와 readSomething은 '독립적인 관계'를 가진 함수입니다. read를 먼저 호출하나, readSomething을 먼저 호출하나 서로에게 영향을 주지 않습니다.

반대로, readThat과 checkValidKey는 '의존적인 관계'을 가진 함수입니다. 반드시, readThat이 선행되어야, checkValidKey를 호출할 수 있습니다.

또, read와 readSomething은 readThat, checkValidKey 2개의 함수와 '독립적인 관계'를 가진 함수입니다. 세가지 작업을 동시에 비동기적으로 진행하여도 무방합니다.

'의존적인 관계'에서는 await을 사용하여 동기식으로 작성하여도 무방합니다. 동기적으로 동작하여야하는 코드이니깐요.

그러나, '독립적인 관계'에서는 위의 예시처럼 Promise.all을 사용하거나, 아래와 같이 사용할 수도 있습니다. 위의 예시에서, run1, run2, run3은 동시에 시작합니다.

run2 와 run3은 run1 보다 빨리 끝났지만, run1이 아직 끝나지 않아, run1이 끝날 때 까지 기다리게 됩니다. '후속 작업'이 존재하면, 그것을 우선적으로 await 하여, 가능한 빨리 후속 작업을 호출할 수 있도록 하면 됩니다.

일반적인 경우에, await을 사용하는 것이 더 깔끔한 코드를 작성할 수 있도록 해줍니다. 또한 대부분의 경우에 API 호출에 오래 걸리지 않습니다. 그렇기 때문에, 적극적으로 await을 사용하는 것을 추천드립니다.

하지만, API가 느리거나, 최적화를 원하는 경우(라고 쓰지만, 100ms라도 로딩시간을 줄일 수 있으면 줄이는 것은 매우 좋습니다)에는, 대부분의 경우에 Promise.all같은 기법을 사용해야합니다.

두 줄 요약

1. await은 동기식으로 코드를 만들어줌으로, 주의가 필요하다.

2. Promise.all이나, 적절한 await 배치로, 많은 시간을 절약할 수 있다.

[ 수정내용 ]

• 2020.04.30 가독성을 증대하였습니다.

vue-naver-maps는 Naver Maps JavaScript API v3을 Vue.js에서 간편하게 이용하게 할 수 있는 라이브러리입니다.

이 라이브러리는 MIT 라이선스로 배포되고 있습니다.

2019년 10월 14일 기준으로 최신 버전은 v0.11.9입니다. 비록 0.x 버전의 라이브러리지만 충분히 사용이 가능한 수준입니다. 사용시에 오류가 발생하거나 궁금하신 점이 있으시다면 깃허브에 이슈를 남겨주시면, 감사하겠습니다.

문서

한국어 문서

특징

• 자바스크립트의 기본 타입만으로도 사용이 가능합니다.
• Nuxt.js에서도 사용이 가능합니다.
• @click등 Vue.js 스타일로 코딩이 가능합니다.

계획

Vue.js 3.0이 출시가 되면, TypeScript 지원을 위한 개발을 시작할 예정입니다. 아마 TypeScript 지원을 시작하면 버전을 1.0.0으로 바꿀 수 있지 않을까 싶네요.

이 글은 필요 없는 부분이 일부 있습니다. 코드를 원하시면, '함수' 항목으로 이동하세요.

1. 계기

Share Links는 반응형 바둑판 레이아웃(항목의 가로길이는 고정, 세로길이는 유동적)를 사용합니다. 한마디로 말해서 핀터레스트(Pinterest)의 레이아웃입니다. flex나 grid로 하려했으나 실패해 결국에는 자바스크립트의 힘을 빌렸습니다. 처음에 핀터레스트는 어떻게 구현한건지 살펴보니 일일이 top과 left를 때려박아서(...) 만들어져있었습니다.

여하튼 한번 만들어놓고 잘 썼었습니다만, 태그 목록이 길어지면 overflow:auto 시켜서 가로스크롤로 표현하는 대신, 세로를 height:auto로 설정해 스크롤 없이 표현하는 것으로 레이아웃을 변경하려고 했습니다. 또한 제목이 길어지면 역시 태그처럼 스크롤을 생성하지 않게 레이아웃을 변경하려했습니다. 이제 auto로 늘어난 만큼을 계산해서 전체 카드의 height를 구하는 것이 관건이었습니다.

2. 문제점

자바스크립트에서 .length는 한글이나 영어나 한글자로 취급해 반환합니다. 하지만 렌더링상으로는 전각과 반각문자이기 때문에, 차지하는 넓이는 다릅니다. 저는 "와 문자열이다!".getLength()의 길이가 14로 취급되는 것을 원했기 때문에, 바이트값으로 문자열의 길이를 측정할 방법이 필요하다고 생겼습니다.

물론 모노(Mono)글꼴을 사용하지 않으면 글자들이 각기 다른 넓이를 갖고 있지만 한글/한자 = 2, 반각문자 = 1, 정도로 계산해도 충분하기 때문에 넘어 갈 수 있습니다.

3. 함수

원본 코드는 https://programmingsummaries.tistory.com/239 에 소개되어있는 코드 중 '개선된 FOR문'의 코드입니다.

아래의 코드는 해당 코드를 map과 reduce를 대신하여 사용한 것입니다. 또한 바이트 수를 구하는 부분은 해당 글에 달려 있는 댓글 중 '노예'라는 분이 써주신 EUC-KR용(2바이트) 코드를 사용했습니다. 만약에 한글을 3바이트로 계산하는 코드가 필요하다면 아래에서 일부 코드를 '개선된 FOR문' 코드에서 따와서 고치면 됩니다.

원리

원리는 아래와 같습니다. 먼저, map과 reduce를 쓰기 위해 문자열을 배열로 쪼갭니다. 그 다음으로, map으로 각 문자의 문자 코드 배열을 만듭니다. 이 과정을 생략하려면 charCodeAt(0)을 reduce 부분에 2번 해주어야합니다. 이제 계산식을 사용해서 reduce로 값을 구해주면 됩니다.

코드

function getByte(str) {
  return str
    .split('') 
    .map(s => s.charCodeAt(0))
    .reduce((prev, c) => (prev + ((c === 10) ? 2 : ((c >> 7) ? 2 : 1))), 0); // 계산식에 관한 설명은 위 블로그에 있습니다.
}

4. 여담

여담으로, 이 글은 https://jaeheon.kr/123 에도 올라와있습니다. 하지만, 분명이 블로그 글이 원본임에도 불구하고 velog에 작성하면서 싹 고친것 + velog의 깔끔한 UI덕분에 velog가 훨씬 더 좋습니다. 물론 여기에 쓰면서 개선된 부분을 블로그에 다시 옮겨 붙이긴 했습니다.

• const a = 1;
  const b = 2;
  console.log('코드블럭은 잘 된다!');

• 코드는 폰트만 바뀐다.

그리고 에디터에서도 무언가 이상하게 동작한다.

• 먼저 해당 EC2 인스턴스의 디스크를 복사해서 다른 ec2 인스턴스로 엽니다. 여기서 다른 ec2 인스턴스를 여는것은, 다른 추가 디스크로 열어야 합니다.
• 해당 인스턴스로 ssh 접속을 한다.
• /etc/ufw/ufw.conf를 편집기로 열고 ENABLED=no로 바꾼다. //방화벽 종료
• 그 다음 해당 디스크로 원래 쓰던 서버의 디스크 이미지를 교체한다.