26 4월 2026

[一日30分 인생승리의 학습법] 소프트웨어 공학의 법칙들 

[一日30分 인생승리의 학습법] 소프트웨어 공학의 법칙들 

소프트웨어 공학의 법칙들

 (lawsofsoftwareengineering.com)

88P by GN⁺ 4일전 | ★ favorite | 댓글 1개
  • 소프트웨어 시스템, 팀, 의사결정에 영향을 미치는 56가지 원칙과 패턴을 한곳에 모은 컬렉션으로, 팀 운영부터 아키텍처, 품질, 설계, 의사결정까지 폭넓은 영역을 포괄
  • Conway의 법칙, Brooks의 법칙, Dunbar의 수 등 팀 관련 법칙들은 조직 구조가 시스템 설계와 생산성에 직접적으로 영향을 미침
  • 아키텍처 영역에서는 Hyrum의 법칙, CAP 정리, Gall의 법칙 등 복잡한 시스템 설계 시 반드시 고려해야 할 제약과 원칙을 정리
  • 품질 관련 법칙들은 기술 부채, 테스팅 피라미드, Kernighan의 법칙 등 코드 품질 유지와 디버깅의 현실적 어려움을 다룸
  • 의사결정 영역에서는 Dunning-Kruger 효과, 매몰 비용 오류, 파레토 원칙 등 개발 과정에서 빠지기 쉬운 인지 편향과 판단 기준을 포괄

팀(Teams)

1. Conway의 법칙 (Conway’s Law)

조직은 자신의 커뮤니케이션 구조를 그대로 반영하는 시스템을 설계한다

  • 소프트웨어 아키텍처는 그것을 만든 조직의 소통 구조를 자연스럽게 따라가는 현상
  • 팀이 3개로 나뉘어 있으면 시스템도 3개의 큰 모듈로 나뉘는 경향이 있음
  • 이를 역으로 활용하는 “역 Conway 전략”(Inverse Conway Maneuver)도 존재: 원하는 아키텍처에 맞춰 팀 구조를 먼저 재편하는 접근
  • 마이크로서비스 도입 시 팀 경계와 서비스 경계를 일치시키는 것이 효과적

2. Brooks의 법칙 (Brooks’s Law)

지연된 소프트웨어 프로젝트에 인력을 추가하면 오히려 더 늦어진다

  • 신규 인력이 합류하면 기존 팀원이 교육과 조율에 시간을 소모하여 전체 생산성이 일시 저하
  • 팀원이 늘어나면 커뮤니케이션 경로가 기하급수적으로 증가 (n명일 때 n(n-1)/2개)
  • Frederick Brooks가 IBM OS/360 프로젝트 경험을 바탕으로 1975년 저서 The Mythical Man-Month에서 정립
  • Little의 법칙(L = λ × W)으로 정량적 설명 가능: 인력 추가 시 WIP(작업 중인 항목)는 증가하지만 처리량(throughput)은 정체되어 리드 타임이 오히려 증가
  • 해결책은 인력 추가가 아닌 범위 조정 또는 일정 변경

3. Dunbar의 수 (Dunbar’s Number)

한 사람이 안정적으로 유지할 수 있는 관계의 인지적 한계는 약 150명

  • Robin Dunbar가 영장류 뇌 크기와 사회 집단 규모의 상관관계에서 도출한 수치
  • Dunbar의 사회적 계층 구조: ~5명(친밀한 관계), ~15명(신뢰할 수 있는 협력자), ~50명(가까운 업무 관계), ~150명(안정적 사회적 연결)
  • 엔지니어링 조직이 150명을 넘으면 비공식적 소통이 한계에 도달하여 공식적 계층과 프로세스 필요
  • Amazon의 “Two-Pizza Team”(5~10명)은 150명 내에서도 실질적 협업은 더 작은 단위에서 일어남을 반영

4. Ringelmann 효과 (The Ringelmann Effect)

그룹 규모가 커질수록 개인의 생산성은 감소한다

  • 그룹 구성원이 많아질수록 각 개인의 기여도가 줄어드는 “사회적 태만”(social loafing) 현상
  • 소프트웨어 팀에서도 팀 크기가 커지면 개별 책임감이 희석되고 조율 비용이 증가
  • 소규모 팀이 1인당 더 높은 산출물을 내는 이유를 설명

5. Price의 법칙 (Price’s Law)

전체 참여자 수의 제곱근에 해당하는 인원이 전체 작업의 50%를 수행한다

  • 100명의 조직에서는 약 10명이 전체 작업의 절반을 담당
  • 조직이 커질수록 소수의 고성과자에 대한 의존도가 심화
  • 팀 확장 시 생산성이 선형으로 증가하지 않는 이유를 설명

6. Putt의 법칙 (Putt’s Law)

기술을 이해하는 사람은 관리하지 않고, 관리하는 사람은 기술을 이해하지 못한다

  • 기술 조직에서 관리 역할과 기술 전문성의 괴리를 풍자적으로 표현
  • 기술 리더십 구조를 설계할 때 이 간극을 인식하고 보완 장치를 마련해야 함

7. Peter 원칙 (Peter Principle)

조직 내에서 모든 직원은 자신의 무능력 수준까지 승진하는 경향이 있다

  • 특정 역할에서 유능한 사람이 승진하여 새로운 역할에서는 무능력해지는 패턴
  • 뛰어난 개발자가 반드시 좋은 매니저가 되지는 않는 현실을 반영
  • IC(Individual Contributor) 트랙과 매니지먼트 트랙을 분리하는 듀얼 래더 체계의 필요성

8. Bus Factor

프로젝트가 심각한 위험에 처할 수 있는 최소 팀원 이탈 수

  • Bus Factor가 1이면 단일 장애점(Single Point of Failure)이 존재하는 상태
  • 지식 공유, 페어 프로그래밍, 문서화를 통해 Bus Factor를 높이는 것이 중요
  • 코드 리뷰와 크로스 트레이닝이 Bus Factor를 개선하는 실질적 방법

9. Dilbert 원칙 (Dilbert Principle)

기업은 무능한 직원을 관리직으로 승진시켜 피해를 제한하는 경향이 있다

  • Scott Adams가 제안한 풍자적 관찰로, Peter 원칙의 변형
  • 관리직이 실무에서 가장 적은 피해를 주는 자리로 여겨지는 역설적 조직 현상

계획(Planning)

10. 조기 최적화 / Knuth의 최적화 원칙 (Premature Optimization)

조기 최적화는 모든 악의 근원이다

  • Donald Knuth가 1974년 논문에서 제시: “약 97%의 경우에서 작은 효율성은 무시해야 한다”
  • 코드의 약 20%가 실행 시간의 80%를 차지하므로, 나머지 80% 코드를 최적화하는 것은 낭비
  • 올바른 순서: 먼저 동작하게 만들고 → 올바르게 만들고 → 필요하면 빠르게 만들 것
  • 최적화된 코드는 복잡성이 높아지므로, 프로파일링을 통해 실제 병목 지점을 확인한 후 수행해야 함

11. Parkinson의 법칙 (Parkinson’s Law)

업무는 주어진 시간을 모두 채울 때까지 확장한다

  • 데드라인이 2주면 2주, 4주면 4주 동안 일이 늘어나는 현상
  • 소프트웨어 프로젝트에서 짧고 명확한 마일스톤 설정이 중요한 이유
  • 스프린트 기반 애자일이 이 법칙에 대한 실질적 대응 방법

12. 90-90 법칙 (The Ninety-Ninety Rule)

코드의 처음 90%가 개발 시간의 90%를 차지하고, 나머지 10%가 또 다른 90%의 시간을 차지한다

  • 소프트웨어 프로젝트의 마지막 10%(엣지 케이스, 폴리싱, 버그 수정)가 예상보다 훨씬 오래 걸림을 경고
  • “거의 완성”이라는 말이 실제로는 전체 일정의 절반 지점일 수 있음

13. Hofstadter의 법칙 (Hofstadter’s Law)

Hofstadter의 법칙을 고려하더라도 항상 예상보다 오래 걸린다

  • 재귀적 자기 참조 구조를 가진 법칙으로, 소프트웨어 일정 추정의 본질적 어려움을 표현
  • 버퍼를 추가해도 여전히 일정이 초과되는 현실
  • Douglas Hofstadter가 1979년 저서 Gödel, Escher, Bach에서 소개

14. Goodhart의 법칙 (Goodhart’s Law)

측정 지표가 목표가 되면 더 이상 좋은 측정 지표가 아니다

  • 코드 커버리지를 KPI로 설정하면 의미 없는 테스트를 양산하는 현상이 대표적 사례
  • 코드 라인 수(LOC)로 생산성을 측정하면 불필요하게 장황한 코드가 생산됨
  • 지표 최적화가 아닌 본질적 가치 달성에 집중해야 함

15. Gilb의 법칙 (Gilb’s Law)

정량화가 필요한 것은 측정하지 않는 것보다 어떤 방식으로든 측정하는 것이 나다

  • 완벽한 측정이 불가능하더라도 대략적 측정이 무측정보다 항상 유익
  • 소프트웨어 품질, 사용자 만족도 등 정량화가 어려운 항목에도 적용

아키텍처(Architecture)

16. Hyrum의 법칙 (Hyrum’s Law)

API 사용자가 충분히 많으면, 시스템의 모든 관찰 가능한 동작에 누군가 의존한다

  • 공식 API 명세뿐 아니라 타이밍, 에러 메시지 형식, 정렬 순서 등 비공식적 동작도 의존 대상이 됨
  • Microsoft Windows가 과거 문서화되지 않은 동작과 버그에 의존하는 서드파티 앱 호환을 위해 구버전 동작을 유지한 사례
  • Google의 Hyrum Wright가 2011-2012년경 Google 내부 라이브러리 변경 경험에서 관찰
  • 동료 Titus Winters가 “Hyrum’s Law”라는 이름을 붙임 (Software Engineering at Google 수록)
  • 실질적 계약은 공식 API가 아니라 실제 관찰되는 동작 전체

17. Gall의 법칙 (Gall’s Law)

작동하는 복잡한 시스템은 반드시 작동하는 단순한 시스템에서 진화한 결과이다

  • 처음부터 복잡한 시스템을 설계하면 검증되지 않은 미지의 변수가 너무 많아 실패 확률이 높음
  • MVP(Minimum Viable Product) 접근의 이론적 근거
  • Facebook이 2004년 Harvard 학생용 단순 프로필 시스템에서 시작하여 점진적으로 확장한 사례
  • 마이크로서비스 전환 시에도 모놀리스에서 시작하여 점진적으로 분리하는 것이 유리
  • John Gall이 1975년 저서 Systemantics에서 제시 (30개 출판사가 거절 후 출간된 컬트 클래식)

18. 누수 추상화의 법칙 (The Law of Leaky Abstractions)

모든 비자명(non-trivial) 추상화는 어느 정도 누수가 발생한다

  • ORM이 SQL을 숨기지만 성능 문제가 발생하면 결국 생성되는 쿼리를 확인해야 하는 상황이 대표 사례
  • Java/Python의 가비지 컬렉션도 추상화이지만 GC 일시정지 같은 내부 동작이 성능에 영향을 미침
  • 추상화 자체가 나쁜 것이 아니라, 추상화가 깨질 때를 대비해야 한다는 교훈
  • Joel Spolsky가 2002년 블로그 포스트에서 TCP, 가상 메모리 등의 사례와 함께 소개
  • George Box의 “모든 모델은 틀렸지만, 일부는 유용하다“와도 맥락 연결

19. Tesler의 법칙 / 복잡성 보존 법칙 (Tesler’s Law)

모든 애플리케이션에는 제거할 수 없는 고유 복잡성이 있으며, 이동만 가능하고 제거는 불가능하다

  • 핵심 질문: 복잡성을 누가 감당할 것인가 (사용자 vs 시스템)
  • Calendly는 일정 조율의 복잡성을 시스템이 흡수하고, 이메일 스레드는 사용자에게 전가하는 차이
  • 좋은 설계는 복잡성을 사용자 경험에서 시스템 내부로 이동시킴
  • Larry Tesler가 Apple Lisa 및 초기 GUI 작업 중 1980년대에 정립

20. CAP 정리 (CAP Theorem)

분산 시스템은 일관성(C), 가용성(A), 분할 내성(P) 중 두 가지만 보장 가능하다

  • 네트워크 파티션은 현실에서 불가피하므로, 실질적 선택은 일관성 vs 가용성
  • CP 시스템 (예: MongoDB): 파티션 발생 시 쓰기를 차단하여 모든 레플리카 동기화 유지
  • AP 시스템 (예: Cassandra, DNS): 파티션 중에도 요청 응답 유지, 레플리카 간 일시적 불일치 허용
  • Eric Brewer가 2000년에 웹 서비스 맥락에서 제안, Gilbert & Lynch가 2002년에 공식 증명

21. Second-System 효과 (Second-System Effect)

작고 성공적인 시스템 다음에는 과도하게 설계된 비대한 후속 시스템이 뒤따르는 경향

  • 첫 번째 시스템의 성공에 자신감을 얻어 두 번째 시스템에 모든 아이디어를 쏟아붓는 패턴
  • 기능 과잉(feature creep)과 과도한 일반화(over-generalization)가 주된 원인
  • Frederick Brooks가 The Mythical Man-Month에서 식별

22. 분산 컴퓨팅의 오류 (Fallacies of Distributed Computing)

분산 시스템을 처음 설계하는 사람들이 흔히 갖는 8가지 잘못된 가정

  • 8가지 오류: (1) 네트워크는 신뢰할 수 있다, (2) 지연 시간은 0이다, (3) 대역폭은 무한하다, (4) 네트워크는 안전하다, (5) 토폴로지는 변하지 않는다, (6) 관리자가 한 명이다, (7) 전송 비용은 0이다, (8) 네트워크는 균일하다
  • 이 가정들을 기반으로 설계하면 프로덕션에서 예기치 않은 장애와 성능 문제가 발생

23. 의도하지 않은 결과의 법칙 (Law of Unintended Consequences)

복잡한 시스템을 변경하면 예기치 않은 결과를 예상해야 한다

  • 시스템 하나의 컴포넌트를 변경하면 예측하지 못한 곳에서 부작용이 발생
  • 카오스 엔지니어링과 포괄적 테스팅의 필요성을 뒷받침하는 원칙

24. Zawinski의 법칙 (Zawinski’s Law)

모든 프로그램은 메일을 읽을 수 있을 때까지 확장을 시도한다

  • 소프트웨어가 성공하면 점점 더 많은 기능을 추가하려는 기능 팽창(feature bloat) 현상을 풍자
  • Jamie Zawinski(Netscape 초기 개발자)가 관찰
  • 단순한 도구가 시간이 지나면 만능 플랫폼이 되려 하는 경향에 대한 경고

품질(Quality)

25. Boy Scout 규칙 (The Boy Scout Rule)

코드를 발견한 것보다 더 나은 상태로 남겨야 한다

  • 대규모 리팩토링이 아닌 지속적이고 점진적인 개선이 핵심
  • 혼란스러운 함수명 수정, 중복 코드 제거, 누락된 테스트 추가 등 매번 작은 개선을 실천
  • Robert C. Martin(Uncle Bob)이 Clean Code(2008)에서 소프트웨어 개발에 적용
  • Google 엔지니어들의 원칙 “If you touch it, you own it” — 코드를 수정하면 그 품질에 대한 책임도 함께 가져감
  • 이 규칙을 실천하면 깨진 유리창 효과(Broken Windows)를 예방하고 기술 부채 축적을 방지

26. Murphy의 법칙 (Murphy’s Law)

잘못될 수 있는 것은 반드시 잘못된다

  • 방어적 프로그래밍, 예외 처리, 장애 대비 설계의 근거
  • 소프트웨어에서는 “일어날 수 있는 에러는 반드시 일어난다”는 자세로 에러 핸들링과 폴백을 설계해야 함

27. Postel의 법칙 / 견고성 원칙 (Postel’s Law)

자신이 하는 일에는 보수적으로, 타인으로부터 받는 것에는 관대하게

  • API 설계 시 출력은 엄격하게 스펙을 준수하되, 입력은 다양한 형식을 유연하게 수용하는 원칙
  • Jon Postel이 TCP/IP 프로토콜 설계 시 수립한 견고성 원칙(Robustness Principle)
  • 시스템 간 상호운용성을 높이는 실질적 가이드라인

28. 깨진 유리창 이론 (Broken Windows Theory)

나쁜 설계, 잘못된 결정, 저품질 코드를 방치하지 말 것

  • 하나의 “깨진 유리창”(나쁜 코드)이 방치되면 추가적인 품질 저하를 유발
  • 코드베이스에 TODO 주석, 죽은 코드, 미해결 경고가 쌓이면 새로운 코드도 낮은 수준으로 작성되는 경향
  • 발견 즉시 작은 문제라도 수정하는 문화가 중요

29. 기술 부채 (Technical Debt)

소프트웨어 개발 속도를 저하시키는 모든 요소

  • Ward Cunningham이 1992년 OOPSLA에서 금융 메타포로 처음 사용: 코드 지름길을 택하면 미래에서 시간을 빌리는 것
  • 원금(수정 비용) + 이자(지저분한 코드로 인한 지속적 생산성 저하)
  • 의도적 기술 부채는 때로 합리적 (시장 출시 타이밍, 프로토타이핑)이지만 상환 계획이 필수
  • 자동화 테스트 생략이 대표적 사례: 릴리스는 성공하지만 이후 변경 시마다 예상치 못한 버그 발생
  • 해결 방법: 리팩토링, 누락 테스트 추가, 설계 개선

30. Linus의 법칙 (Linus’s Law)

충분한 수의 검토자가 있으면 모든 버그는 쉽게 발견된다

  • 오픈소스 개발의 핵심 원리: 다수의 눈이 코드를 검토하면 버그가 사소한 문제가 됨
  • Eric Raymond가 The Cathedral and the Bazaar에서 Linus Torvalds의 이름을 따 명명
  • 코드 리뷰 문화의 중요성을 뒷받침

31. Kernighan의 법칙 (Kernighan’s Law)

디버깅은 코드를 처음 작성하는 것보다 두 배 어렵다

  • 따라서 최대한 영리하게 코드를 작성하면, 디버깅할 때 충분히 영리하지 못하게 됨
  • 가독성 높은 단순한 코드를 작성해야 하는 이유
  • Brian Kernighan이 The Elements of Programming Style에서 제시

32. 테스팅 피라미드 (Testing Pyramid)

프로젝트는 빠른 단위 테스트를 많이, 통합 테스트는 적게, UI 테스트는 소수만 보유해야 한다

  • 단위 테스트(하단): 빠르고 저비용, 가장 많이 작성
  • 통합 테스트(중간): 컴포넌트 간 상호작용 검증
  • UI/E2E 테스트(상단): 느리고 깨지기 쉬우므로 최소화
  • Mike Cohn이 Succeeding with Agile에서 소개한 테스트 전략 모델

33. 살충제 역설 (Pesticide Paradox)

동일한 테스트를 반복 실행하면 시간이 지남에 따라 효과가 감소한다

  • 기존 테스트가 이미 잡을 수 있는 버그는 다 잡았으므로, 새로운 테스트 케이스를 지속적으로 추가해야 함
  • 테스트 세트를 정기적으로 검토하고 업데이트하는 것이 필수

34. Lehman의 소프트웨어 진화 법칙 (Lehman’s Laws of Software Evolution)

현실 세계를 반영하는 소프트웨어는 반드시 진화해야 하며, 그 진화에는 예측 가능한 한계가 존재한다

  • E-type(현실 세계를 반영하는) 소프트웨어는 사용되려면 지속적 변경이 불가피
  • 변경 시마다 복잡성이 증가하며, 이를 적극적으로 관리하지 않으면 품질이 저하

35. Sturgeon의 법칙 (Sturgeon’s Law)

모든 것의 90%는 쓸모없다

  • Theodore Sturgeon이 SF 문학 비평에 대응하여 제시
  • 소프트웨어에도 적용: 대부분의 코드, 도구, 프레임워크 중 진정으로 훌륭한 것은 소수
  • 품질에 대한 높은 기준을 유지하고, 가치 있는 10%에 집중하는 자세 필요

스케일(Scale)

36. Amdahl의 법칙 (Amdahl’s Law)

병렬화로 인한 속도 향상은 병렬화할 수 없는 작업 비율에 의해 제한된다

  • 프로그램의 5%가 순차적이면 아무리 많은 프로세서를 투입해도 이론적 최대 속도 향상은 20배
  • 병렬화의 한계를 인식하고 순차적 병목 구간을 줄이는 것이 더 효과적
  • Gene Amdahl이 1967년에 제시

37. Gustafson의 법칙 (Gustafson’s Law)

문제 크기를 늘림으로써 병렬 처리에서 상당한 속도 향상을 달성할 수 있다

  • Amdahl의 법칙에 대한 보완적 관점: 고정된 문제가 아닌 확장 가능한 문제에서는 프로세서 추가가 효과적
  • 빅데이터 처리, 과학 시뮬레이션 등에서 더 많은 리소스로 더 큰 문제를 풀 수 있음

38. Metcalfe의 법칙 (Metcalfe’s Law)

네트워크의 가치는 사용자 수의 제곱에 비례한다

  • 사용자가 10명이면 가치는 100 단위, 100명이면 10,000 단위로 증가
  • 소셜 네트워크, 메신저, 마켓플레이스 등 네트워크 효과의 이론적 기반
  • Robert Metcalfe가 이더넷 기술의 가치를 설명하기 위해 제시

설계(Design)

39. DRY 원칙 (Don’t Repeat Yourself)

모든 지식은 단일하고 명확하며 권위 있는 하나의 표현만 가져야 한다

  • 코드 중복뿐 아니라 지식, 로직, 데이터의 중복도 포함
  • 중복은 변경 시 여러 곳을 동시에 수정해야 하므로 버그와 불일치의 원인
  • Andy Hunt와 Dave Thomas가 The Pragmatic Programmer에서 정립

40. KISS 원칙 (Keep It Simple, Stupid)

설계와 시스템은 가능한 한 단순해야 한다

  • 복잡성은 이해, 유지보수, 디버깅의 비용을 증가시킴
  • 단순한 해결책이 대부분의 경우 더 효과적이며 결함 가능성도 낮음
  • 미국 해군이 1960년대에 제시한 설계 원칙에서 유래

41. SOLID 원칙 (SOLID Principles)

소프트웨어 설계를 향상시키는 5가지 핵심 가이드라인

  • S — 단일 책임 원칙(Single Responsibility): 클래스는 하나의 이유로만 변경
  • O — 개방-폐쇄 원칙(Open-Closed): 확장에 열려 있고 수정에 닫혀 있어야 함
  • L — Liskov 치환 원칙: 하위 타입은 상위 타입을 대체할 수 있어야 함
  • I — 인터페이스 분리 원칙: 클라이언트는 사용하지 않는 인터페이스에 의존하지 않아야 함
  • D — 의존성 역전 원칙: 상위 모듈이 하위 모듈에 의존하지 않고 추상화에 의존
  • Robert C. Martin이 정립하고 Michael Feathers가 SOLID라는 약어를 명명

42. 디미터 법칙 (Law of Demeter)

객체는 직접적인 친구와만 상호작용해야 하며, 낯선 객체와의 직접 소통은 지양해야 한다

  • a.getB().getC().doSomething() 같은 체인 호출을 피해야 한다는 원칙
  • 결합도를 낮추고 캡슐화를 강화하여 변경 영향 범위를 줄임
  • “최소 지식의 원칙”이라고도 불림

43. 최소 놀라움의 원칙 (Principle of Least Astonishment)

소프트웨어와 인터페이스는 사용자와 다른 개발자를 가장 적게 놀라게 하는 방식으로 동작해야 한다

  • 함수, API, UI가 이름과 컨벤션에서 예측 가능한 동작을 해야 함
  • delete() 함수가 실제로는 아카이브만 한다면 놀라움을 유발 → 설계 결함
  • 직관적이지 않은 동작은 버그와 사용자 실수를 초래

44. YAGNI (You Aren’t Gonna Need It)

필요하기 전까지 기능을 추가하지 말 것

  • Extreme Programming(XP)의 핵심 원칙으로 1990년대 후반 Ron Jeffries가 제시
  • “미래에 필요할지 모른다”는 이유로 코드를 작성하면 과잉 설계와 유지보수 부담 발생
  • 리팩토링에 대한 자신감(좋은 테스트 커버리지, CI)이 있어야 YAGNI를 실천 가능
  • 현재 JSON 내보내기만 필요하면 JSON만 구현, XML/YAML 등은 요구될 때 추가

의사결정(Decisions)

45. Dunning-Kruger 효과 (Dunning-Kruger Effect)

어떤 것에 대해 적게 알수록 더 자신감을 갖는 경향이 있다

  • 초보 개발자가 복잡한 시스템의 난이도를 과소평가하거나, 전문가가 오히려 자신의 지식에 겸손한 현상
  • 코드 리뷰, 멘토링, 지속 학습을 통해 자기 인식의 정확성을 높이는 것이 중요

46. Hanlon의 면도날 (Hanlon’s Razor)

어리석음이나 부주의로 충분히 설명되는 것을 악의로 돌리지 말 것

  • 동료의 나쁜 코드나 잘못된 결정을 의도적 방해로 해석하기 전에 무지, 실수, 시간 부족을 먼저 고려
  • 팀 내 신뢰와 건설적 커뮤니케이션의 기반

47. Occam의 면도날 (Occam’s Razor)

가장 단순한 설명이 가장 정확한 경우가 많다

  • 디버깅 시 복잡한 원인보다 가장 단순한 가능성부터 먼저 확인
  • 아키텍처 설계에서도 불필요한 추상화 레이어를 추가하기 전에 단순한 해결책을 우선 탐색

48. 매몰 비용 오류 (Sunk Cost Fallacy)

시간이나 에너지를 투자했다는 이유만으로 손해가 되는 선택을 계속 유지하는 현상

  • 6개월 동안 개발한 기능이 잘못된 방향이었더라도 투자한 시간 때문에 버리지 못하는 심리
  • 올바른 결정은 과거 투자가 아닌 미래 가치를 기준으로 해야 함

49. 지도는 영토가 아니다 (The Map Is Not the Territory)

현실에 대한 표현(모델)은 현실 자체와 동일하지 않다

  • UML 다이어그램, 아키텍처 문서, 데이터 모델 등은 현실의 근사치일 뿐
  • 모델을 맹신하지 말고, 실제 시스템의 동작을 관찰하며 모델을 갱신해야 함

50. 확증 편향 (Confirmation Bias)

기존 믿음이나 아이디어를 지지하는 정보를 선호하는 경향

  • 자신이 선택한 기술 스택이나 설계 결정에 유리한 정보만 선별적으로 수집하는 함정
  • 반대 증거를 적극적으로 탐색하고 다양한 관점을 수용하는 것이 균형 잡힌 의사결정의 핵심

51. Hype Cycle과 Amara의 법칙 (The Hype Cycle & Amara’s Law)

기술의 단기 효과는 과대평가하고, 장기 영향은 과소평가하는 경향이 있다

  • Gartner의 Hype Cycle: 기술 촉발 → 과도한 기대의 정점 → 환멸의 골짜기 → 계몽의 경사 → 생산성 안정기
  • 새 기술(블록체인, AI 등)을 도입할 때 단기 과열에 휩쓸리지 말고 장기적 실용성을 평가해야 함

52. Lindy 효과 (The Lindy Effect)

오래 사용된 것일수록 앞으로도 계속 사용될 가능성이 높다

  • UNIX, SQL, C 언어처럼 수십 년간 사용된 기술은 앞으로도 오래 생존할 가능성이 높음
  • 새로운 프레임워크보다 검증된 기술을 선택할 때의 이론적 근거
  • Nassim Nicholas Taleb이 Antifragile에서 대중화

53. 제1원리 사고 (First Principles Thinking)

복잡한 문제를 가장 기본적인 구성 요소로 분해한 후 그로부터 재구축하는 사고법

  • 기존 관행과 가정을 제거하고 근본적 진실에서 출발하여 해결책을 도출
  • Elon Musk가 SpaceX 로켓 비용 절감에 적용한 사례로 유명
  • 복잡한 시스템 설계 시 “원래 다 그렇게 하니까”라는 사고를 경계

54. 역전 사고 (Inversion)

반대 결과를 상정하고 거꾸로 추론하여 문제를 해결하는 방법

  • “어떻게 성공할까” 대신 “어떻게 하면 실패할까” 를 먼저 생각하여 위험 요소를 식별
  • 장애 모드 분석(Failure Mode Analysis)과 프리모템(Pre-mortem)의 이론적 근거
  • Charlie Munger가 자주 활용하는 멘탈 모델

55. 파레토 원칙 / 80/20 법칙 (Pareto Principle)

문제의 80%는 원인의 20%에서 발생한다

  • 전체 버그의 80%가 코드의 20%에 집중되어 있는 경향
  • 가장 영향력이 큰 20%에 리소스를 집중하는 것이 효율적 자원 배분 전략
  • Vilfredo Pareto가 이탈리아 토지 소유 분포에서 관찰한 원리에서 유래

56. Cunningham의 법칙 (Cunningham’s Law)

인터넷에서 정확한 답을 얻는 가장 좋은 방법은 질문이 아니라 틀린 답을 게시하는 것이다

  • 사람들은 질문에 답하는 것보다 잘못된 정보를 교정하는 데 더 적극적으로 참여
  • Ward Cunningham(Wiki 발명자)의 이름을 딴 법칙이지만, 실제로는 Steven McGeady가 이 이름을 붙임
  • 오픈소스 커뮤니티에서 문서화나 지식 공유에 활용 가능한 통찰

[출처] https://news.hada.io/topic?id=28760

Loading

Category: 경영 및 창업, 기술자료, 업무참고자료, 학습자료 | LEAVE A COMMENT
25 4월 2026

[인공지능 개발자] 프로덕션 환경에서 바이브 코딩을 책임감 있게 하는 법 – Vibe coding in prod 

[인공지능 개발자] 프로덕션 환경에서 바이브 코딩을 책임감 있게 하는 법 – Vibe coding in prod 

프로덕션 환경에서 바이브 코딩을 책임감 있게 하는 법 – Vibe coding in prod | Code w/ Claude

 (youtube.com)

36P by ragingwind 4일전 | ★ favorite | 댓글 2개

Anthropic의 코딩 에이전트 연구자 Eric이 바이브 코딩(AI에게 코드 작성을 전적으로 맡기는 방식)을 실제 서비스 환경에서 어떻게 안전하게 활용할 수 있는지를 다룬 발표입니다. 단순히 AI로 코드를 많이 생성하는 것과 바이브 코딩은 다르며, Andrej Karpathy의 정의처럼 “코드가 존재한다는 사실 자체를 잊는 것”이 핵심이라고 설명합니다. AI가 처리할 수 있는 작업 규모가 7개월마다 두 배로 늘고 있는 상황에서, 이 흐름을 활용하지 못하면 경쟁에서 뒤처질 수밖에 없다는 문제의식에서 출발합니다.

핵심 주장

  • 바이브 코딩의 원칙은 “코드는 잊되, 제품은 잊지 말 것”입니다. 컴파일러가 생성한 어셈블리를 일일이 읽지 않듯, AI가 작성한 코드 자체보다 결과물의 품질과 정확성을 검증하는 데 집중해야 한다고 봅니다.
  • 개발자의 역할이 직접 구현하는 사람에서 Claude의 프로덕트 매니저(PM)로 전환되어야 합니다. 신입 엔지니어에게 업무를 맡길 때처럼, 요구사항과 코드베이스 맥락, 제약조건을 충분히 정리해 AI에 전달하는 과정이 15~20분 이상 소요되더라도 그 투자가 성공률을 크게 높인다고 합니다.
  • 바이브 코딩은 코드베이스의 리프 노드(다른 코드가 의존하지 않는 말단 기능)에 집중해야 합니다. 핵심 아키텍처나 다른 모듈이 의존하는 근간 코드는 여전히 사람이 깊이 이해하고 관리해야 합니다.
  • 검증 가능성 설계가 필수적입니다. Anthropic 내부에서 22,000줄 규모의 강화학습 코드를 Claude로 작성해 프로덕션에 머지한 사례에서, 스트레스 테스트와 입출력 기반 검증 체크포인트를 설계해 코드를 전부 읽지 않고도 안정성과 정확성을 확인했다고 합니다.

현재의 한계

  • 기술 부채(tech debt)는 코드를 직접 읽지 않고는 측정하거나 검증할 좋은 방법이 아직 없습니다. 이 점이 바이브 코딩을 리프 노드에 한정해야 하는 가장 큰 이유입니다.
  • 비개발자가 보안이나 결제 같은 민감한 영역까지 바이브 코딩으로 프로덕션 시스템을 구축하는 것은 위험합니다. 올바른 질문을 던질 수 있는 기술적 판단력이 전제되어야 합니다.

차별점

  • 바이브 코딩을 단순한 유행이 아닌 소프트웨어 산업의 구조적 전환으로 프레이밍하고, CTO가 전문가를 관리하거나 CEO가 회계사의 업무를 검증하는 것처럼 “구현을 모르면서도 결과를 검증하는 문제”는 문명만큼 오래된 과제라는 점을 짚은 것이 인상적입니다.

시사점

  • 소프트웨어 엔지니어에게 요구되는 역량이 코드 한 줄 한 줄을 쓰는 능력에서, 요구사항을 정밀하게 정의하고 결과를 구조적으로 검증하는 능력으로 이동하고 있습니다. AI 도구의 성능 향상 속도를 고려하면, 이 전환에 적응하는 시점이 빠를수록 유리할 것으로 보입니다.

[출처] https://news.hada.io/topic?id=28749

Loading

Category: stechstar.com 운영정보, 경영 및 창업, 업무참고자료, 학습자료 | LEAVE A COMMENT
21 4월 2026

[인공지능 개발자]  AI 코딩 시대, 성장이 멈추는 개발자의 뇌에서 일어나는 일 

[인공지능 개발자]  AI 코딩 시대, 성장이 멈추는 개발자의 뇌에서 일어나는 일 

AI 코딩 시대, 성장이 멈추는 개발자의 뇌에서 일어나는 일

 (evan-moon.github.io)

55P by bboydart91 3일전 | ★ favorite | 댓글 19개

TL;DR;

  • AI를 잘 쓰는 핵심 역량은 출력물의 품질을 판단하고 교정하는 능력이며, 이 능력은 AI에 의존할수록 오히려 약화됨
  • Bjork의 “바람직한 어려움” 이론에 따르면, 쉽게 처리한 정보는 장기 기억에 남지 않음
  • Roediger & Karpicke(2006) 연구에서 인출 연습 그룹의 일주일 후 기억 보존율이 반복 읽기 그룹보다 약 50% 높았음
  • AI가 코드를 대신 작성하면 본질적 인지 부하(germane load) 까지 제거되어 스키마 형성 기회 자체가 사라짐
  • 숙련된 개발자일수록 신경 효율성으로 인해 AI 출력을 읽는 것만으로는 뇌에 걸리는 부하가 거의 없음
  • AI 이전에도 성장이 멈추는 경로는 존재했지만, AI는 그 경로의 마찰을 극적으로 제거함

상세 요약

AI를 잘 쓰려면 코드를 알아야 하는 역설

  • “이걸 만들어줘”라고 말할 수 있는 사람은 많지만, AI 결과물을 보고 “이 구조는 변경에 취약하다”, “이 인터페이스는 두 가지 책임을
    가지고 있다”고 구체적으로 교정할 수 있는 사람은 훨씬 적음
  • 이 능력은 수많은 실패와 디버깅과 리팩토링 경험에서 형성된 직감에 가까움
  • AI 사용법 학습과 코드 패턴 학습은 양자택일 관계가 아니라, 후자가 전자의 토대인 관계임
  • “AI를 가장 잘 활용할 수 있는 개발자는 AI 없이도 코드를 판단할 수 있는 개발자”

뇌는 편하면 기억하지 않는다

  • Bjork의 “바람직한 어려움”: 학습 과정에 적절한 난이도와 저항이 존재할 때 단기 수행은 느려지지만 장기 기억 보존과 전이는 향상됨
  • Roediger & Karpicke(2006): 반복 읽기 vs 인출 연습 실험
    • 5분 후 테스트: 반복 읽기 그룹 성적이 더 높음
    • 일주일 후 재테스트: 인출 연습 그룹의 기억 보존율이 약 50% 더 높음
  • 능동적 인출 그룹은 해마–전두엽 피질 연결성이 강화되고 감각운동 네트워크 활성도 증가
  • 수동 학습 상태의 뇌는 해마–방추상회 연결만 활성화 — “정보를 보고 있을 뿐 처리하지 않는 것”에 가까움
  • 생성 효과 (Slamecka & Graf, 1978): “뜨거운-차___” 처럼 직접 완성한 그룹이 완성된 쌍을 읽은 그룹보다 기억 보존율이 유의미하게 높음
  • 유창성의 착각: 정보를 쉽게 처리할 수 있다는 느낌이 잘 기억할 것이라는 착각으로 이어짐

코딩 실력은 절차 기억이다

  • 코딩 실력의 상당 부분은 절차 기억 — 자전거 타기처럼 한번 체화되면 의식하지 않아도 자동 실행됨
  • Anderson의 적응적 사고 통제(ACT) 모델: 절차 기억 형성 3단계
    • 인지 단계: 모든 것을 의식적으로 한 단계씩 실행, 작업 기억 대부분 소모
    • 연합 단계: 개별 절차들이 통합되어 하나의 흐름으로 실행 가능
    • 자동화 단계: 작업 기억 거의 차지하지 않고 자동 실행 — 남은 여유를 설계 판단에 활용 가능
  • 단계 전환은 반복적인 직접 수행을 통해서만 진행됨
  • 청킹 (Chase & Simon 체스 연구): 전문가와 초보자의 차이는 작업 기억 슬롯 수가 아니라, 하나의 청크에 담을 수 있는 정보의 양
    • 체스 고수는 말의 개별 위치가 아닌 “시실리안 디펜스의 전형적인 중반 배치” 같은 의미 있는 패턴을 하나의 청크로 인식
    • 무작위 배치 실험에서 고수와 초보자 차이가 사라짐으로써 입증됨

AI는 이 과정을 방해한다

  • AI에게 구현을 맡기면 본질적 인지 부하(germane load) 까지 AI가 대신 처리 — 스키마 구축 기회 자체가 사라짐
  • 절차 기억 관점: 인지 단계에서 끙끙대는 시간이 줄어 연합 단계 전환이 지연되고 자동화 단계 도달이 어려워짐
  • AI 출력 코드를 읽는 것은 생성 효과 실험의 “완성된 단어 쌍을 읽는 것”에 해당 — 이해한 것 같지만 깊이 각인되지 않음
  • 숙련된 개발자일수록 신경 효율성으로 코드를 더 적은 자원으로 처리 → AI 출력 읽기는 생각보다 뇌에 부하를 거의 걸지 않음
  • 직접 코드를 짤 때는 예측–피드백 루프로 시냅스가 수정되지만, 완성된 AI 코드 읽기는 예측 과정이 생략된 사후 해석에 불과함
  • 주니어에게 특히 심각: 인지 단계에 있는 패턴이 많은 상태에서 AI가 그 단계를 건너뛰게 하면 절차 기억 형성 없이 경력만 쌓임

뇌에 부하를 거는 방법

  • AI에게 맡기기 전에 먼저 자신의 설계안 작성: 생성 효과를 의도적으로 활용 — AI 출력과 비교·평가하는 과정에서 뇌의 의미 처리와 실행
    제어 영역이 동시 활성화
  • 진지한 코드 리뷰: “왜 이 구조인가”, “6개월 뒤에 수정한다면 어디가 문제가 될까”를 의식적으로 묻는 것 — 귀찮음 자체가 바람직한
    어려움
  • 직접 코드를 짜보는 시간 확보: 절차 기억 형성에 대체 불가능 — 막혔을 때는 전체 답이 아닌 최소한의 힌트만 AI에게 요청
  • 생산과 학습의 최적 전략은 다름: AI는 생산 도구로는 탁월하지만, 학습 도구로는 한계가 있음
  • 결국 뇌에 남은 것들이 코드 리뷰의 질, 설계 판단의 정확도, 역설적으로 AI 활용 능력을 결정함

[출처] https://news.hada.io/topic?id=28653&utm_source=weekly&utm_medium=email&utm_campaign=202616

Loading

Category: stechstar.com 운영정보, 경영 및 창업, 기술자료, 업무참고자료, 학습자료 | LEAVE A COMMENT
19 4월 2026

gemma4 e2b 파인튜닝

 

gemma4 e2b 파인튜닝

 

 

Fine-tuning the Gemma 4 E2B (Effective 2B) model is highly accessible, allowing for local training on consumer hardware with as little as 8GB VRAM. Gemma 4 E2B is a multimodal model (text, image, and audio) designed for efficiency using Per-Layer Embeddings (PLE).

 

The most recommended approach for fine-tuning Gemma 4 E2B is using Unsloth, which offers ~1.5x faster training with ~60% less VRAM compared to traditional methodologies.

 

Key Information for Gemma 4 E2B Fine-Tuning

  • Model ID: google/gemma-4-E2B-it or unsloth/gemma-4-E2B-it-unsloth-bnb-4bit

  • Requirements: 8GB VRAM (minimum for QLoRA/4-bit).

  • Frameworks: Unsloth, Hugging Face Transformers, TRL (Transformer Reinforcement Learning).

  • Technique: QLoRA (Quantized LoRA) is recommended for efficient local tuning.

  • Context Window: Supports up to 256K tokens.

  •  

Fine-Tuning Steps (using Unsloth)

Unsloth provides optimized notebooks for training.

  1. Environment Setup: Install Unsloth and necessary dependencies.

python

pip install “unsloth[colab-new] @ git+https://github.com”

pip install –no-deps “xformers<0.0.27” “trl<0.9.0” peft accelerate bitsandbytes

  1. Load Model and Tokenizer: Use 4-bit quantization to save memory.

python

from unsloth import FastLanguageModel

import torch

model, tokenizer = FastLanguageModel.from_pretrained(

model_name = “unsloth/gemma-4-E2B-it-unsloth-bnb-4bit”,

max_seq_length = 2048,

dtype = None,

load_in_4bit = True,

)

  1. Apply LoRA Adapters: Apply Parameter-Efficient Fine-Tuning (PEFT) to adapt only a fraction of the parameters.

python

model = FastLanguageModel.get_peft_model(

model,

r = 16, # Rank

target_modules = [“q_proj”, “k_proj”, “v_proj”, “o_proj”,

“gate_proj”, “up_proj”, “down_proj”,],

lora_alpha = 16,

lora_dropout = 0,

bias = “none”,

use_gradient_checkpointing = “unsloth”,

)

  1. Data Preparation: Format your dataset (e.g., chat templates for instruction tuning).

  2. Train the Model: Use the SFTTrainer (Supervised Fine-tuning Trainer) from TRL.

  3. Save the Model: Save the trained LoRA adapters or merge them into a 16-bit model for inference.

 

Best Practices and Considerations

  • Unsloth Bug Fixes: Ensure you use the latest Unsloth version, as they fixed issues with gradient accumulation (preventing losses from exploding) and inference bugs in Gemma 4.

  • Multimodal Inputs: To train with image or audio data, use AutoModelForMultimodalLM rather than AutoModelForCausalLM.

  • Memory Management: If you encounter Out of Memory (OOM) errors, reduce per_device_train_batch_size to 1 and increase gradient_accumulation_steps.

  • Data Quality: Use specialized datasets (e.g., function calling/tool use) for specialized tasks.

 

gemma4 e2b 파인터닝

Gemma 4 E2B(실질적 2B) 모델의 미세 조정은 매우 접근성이 높아, 8GB VRAM만으로도 소비자용 하드웨어에서 로컬 교육을 할 수 있습니다. Gemma 4 E2B는 Per-Layer Embeddings(PLE)를 효율적으로 사용하여 설계된 멀티모달 모델(텍스트, 이미지, 오디오)입니다.

 

Gemma 4 E2B를 미세 조정하는 데 가장 추천되는 방법은 Unsloth를 사용하는 것으로, 전통적인 방법론에 비해 약 1.5배 빠른 학습과 약 60% 적은 VRAM을 제공합니다.

 

Gemma 4 E2B 미세 조정에 대한 주요 정보

1. 모델 ID: google/gemma-4-E2B-it 또는 unsloth/gemma-4-E2B-it-unsloth-bnb-4bit

2. 요구 사양: 8GB VRAM(QLoRA/4비트 최소 사양).

3. 프레임워크: 언슬로스, 포옹 페이스 트랜스포머, TRL(트랜스포머 강화 학습).

4. 기법: 효율적인 로컬 튜닝을 위해 QLoRA(양자화 LoRA)를 권장합니다.

5. 컨텍스트 윈도우: 최대 256K 토큰을 지원합니다.

6.

미세 조정 단계 (Unsloth 사용)

Unsloth는 훈련을 위한 최적화된 노트북을 제공합니다.

1. 환경 설정: Unsloth 및 필요한 의존성 설치.

파이썬

PIP install “unsloth[colab-new] @ git+https://github.com”

PIP 설치 –no-deps “xformers<0.0.27” “trl<0.9.0” peft accelerate bitsandbytes

2. 로드 모델 및 토큰라이저: 메모리를 절약하기 위해 4비트 양자화를 사용하세요.

파이썬

unsloth에서 가져오는 FastLanguageModel에서

수입 토치

model, tokenizer = FastLanguageModel.from_pretrained(

model_name = “unsloth/gemma-4-E2B-it-unsloth-bnb-4bit”,

max_seq_length = 2048,

dtype = 없음,

load_in_4bit = 참,

)

3. LoRA 어댑터 적용: 파라미터 효율적 미세 조정(PEFT)을 적용하여 일부 매개변수만 적응시키세요.

파이썬

모델 = FastLanguageModel.get_peft_model(

모델,

r = 16, # 랭크

target_modules = [“q_proj”, “k_proj”, “v_proj”, “o_proj”,

“gate_proj”, “up_proj”, “down_proj”,],

lora_alpha = 16,

lora_dropout = 0,

편향 = “없음”,

use_gradient_checkpointing = “나태 해제”,

)

4. 데이터 준비: 데이터셋을 포맷하세요(예: 명령어 조정용 채팅 템플릿).

5. 모델 훈련: TRL의 SFTTrainer(감독 미세 조정 트레이너)를 사용하세요.

6. 모델 저장: 학습된 LoRA 어댑터를 저장하거나 16비트 모델로 병합하여 추론을 진행합니다.

 

모범 사례 및 고려사항

1. 언슬로스 버그 수정: 최신 언슬로스 버전을 꼭 사용하세요. 젬마 4에서 그라디언트 누적(손실 폭발 방지)과 추론 버그 문제를 해결했습니다.

2. 멀티모달 입력: 이미지 또는 오디오 데이터로 학습하려면 AutoModelForCausalLM 대신 AutoModelForMultimodalLM을 사용하세요.

3. 메모리 관리: 메모리 외(OOM) 오류가 발생하면 per_device_train_batch_size를 1로 줄이고 gradient_accumulation_steps을 늘려주세요.

4. 데이터 품질: 특수 작업에 특화된 데이터셋(예: 함수 호출/도구 사용)을 활용하세요.

 

Loading

Category: stechstar.com 운영정보, 경영 및 창업, 기술자료, 업무참고자료, 학습자료 | LEAVE A COMMENT
13 4월 2026

[인공지능 기술] 프롬프트에서 하네스까지 – AI 에이전틱 패턴 4년의 기록 

[인공지능 기술] 프롬프트에서 하네스까지 – AI 에이전틱 패턴 4년의 기록 

프롬프트에서 하네스까지 – AI 에이전틱 패턴 4년의 기록

 (bits-bytes-nn.github.io)

72P by xguru 5일전 | ★ favorite | 댓글 8개
  • 2022~2026년, AI 개발 패러다임이 세 번 전환됨: Prompt Engineering → Context Engineering → Harness Engineering
  • 각 전환은 이전 패러다임이 약속을 지키지 못한 실패에서 비롯되었으며, 엔지니어링의 엄밀함은 사라진 것이 아니라 프롬프트에서 컨텍스트로, 컨텍스트에서 하네스로 위치를 옮겼을 뿐임
  • [1시대] Prompt Engineering (2022~2024)
    • “영어가 곧 프로그래밍 언어”, “단계별로 생각하라”
    • 아무리 정교한 프롬프트도 컨텍스트 윈도우에 없는 파일은 모름
  • [2시대] Context Engineering (2025)
    • “어떤 말을 해야 하나”에서 “어떤 정보를 넣어야 하나“로
    • 완벽한 컨텍스트를 구성해도, 그것을 소비하는 루프 자체가 잘못 설계되면 여전히 실패
  • [2.5시대] 바이브 코딩과 그 숙취
    • diff도 안 보고 AI 제안을 전부 수락 – 코드가 읽을 수 있는 수준을 넘어서 자라남
    • “LLM이 코드를 썼더라도 당신이 리뷰했다면 그건 vibe coding이 아니다”
  • [3시대] Harness Engineering (2026~)
    • “에이전트가 실수하면 에이전트가 아니라 하네스를 고쳐라“
    • 에이전트 = 모델 + 하네스
    • Anthropic 3-에이전트 아키텍처, Ralph 패턴, Lethal Trifecta, Meta AI의 Rule of Two
  • 2026년 현재 핵심 메트릭은 프롬프트 품질이 아니라 KV-cache hit rate(모델이 이전 계산을 재활용하는 비율)와 하네스 복잡도로 전환됨
  • 바이브 코딩(Vibe Coding)의 숙취, 에이전트의 자기 평가 불능, 보안 취약점 등 실제 프로덕션 장벽들이 각 시대의 한계를 증명했으며, 하네스는 이 모든 문제에 대한 구조적 대응임
  • 각 시대는 이전 시대를 대체하지 않고 포함(subsume) 하며, 프롬프트 엔지니어링은 죽은 것이 아니라 하네스 엔지니어링의 서브모듈이 되었음
  • 하네스는 뜯어낼 수 있어야(rippable) 함 — 모델이 발전하면 기존 에러 복구 로직의 절반이 불필요해짐
  • 엄밀함의 다음 이동 방향: Guardian Agent(실시간 감시 레이어) → 평가 엔지니어링(behavior beats benchmarks) → 지식 엔진(코드 그래프·커밋 히스토리·메모리 결합)

[출처] https://news.hada.io/topic?id=28301&utm_source=weekly&utm_medium=email&utm_campaign=202615

Loading

Category: stechstar.com 운영정보, 경영 및 창업, 기술자료, 업무참고자료, 학습자료 | LEAVE A COMMENT
5 4월 2026

[인공지능 기술] Google, 오픈 모델 Gemma 4 공개 

[인공지능 기술] Google, 오픈 모델 Gemma 4 공개 

Google, 오픈 모델 Gemma 4 공개

 (deepmind.google)

8P by GN⁺ 2일전 | ★ favorite | 댓글 2개
  • Google DeepMind가 Gemini 3 기술을 기반으로 한 차세대 오픈 AI 모델 Gemma 4를 발표, 매개변수당 지능 효율을 극대화한 구조로 설계됨
  • 모델은 E2B, E4B, 26B, 31B 네 가지 크기로 제공되며, 모바일·IoT부터 개인용 GPU 환경까지 폭넓은 실행 범위를 지원
  • 멀티모달 추론, 140개 언어 지원, 에이전트형 워크플로, 세밀한 파인튜닝, 효율적 아키텍처 등 주요 기능을 포함
  • 수학·코딩·멀티모달 이해 영역에서 Gemma 3 대비 성능이 크게 향상되었으며, 보안·신뢰성 기준은 Google 상용 모델과 동일 수준 유지
  • 모델 가중치는 Hugging Face, Ollama, Kaggle, LM Studio, Docker 등에서 다운로드 가능하며, 로컬 및 클라우드 환경 통합 실행을 지원함

Gemma 4 — 차세대 오픈 AI 모델

  • Gemma 4는 Gemini 3의 연구와 기술을 기반으로 개발된 Google DeepMind의 최신 오픈 모델로, 매개변수당 지능 효율(intelligence-per-parameter) 을 극대화한 구조를 가짐
  • 모델은 E2B, E4B, 26B, 31B 네 가지 크기로 제공되며, 모바일·IoT부터 개인용 워크스테이션까지 다양한 환경에서 실행 가능
  • 멀티모달 추론, 140개 언어 지원, 에이전트형 워크플로, 세밀한 파인튜닝, 효율적 아키텍처를 주요 기능으로 포함
  • 성능 벤치마크에서 Gemma 3 대비 전반적인 향상치를 기록하며, 특히 수학·코딩·멀티모달 이해 영역에서 높은 점수를 달성
  • 보안·신뢰성 기준은 Google의 상용 모델과 동일 수준으로 유지되며, Hugging Face, Ollama, Kaggle, LM Studio, Docker 등에서 모델 가중치를 다운로드 가능

모델 구성 및 효율성

  • Gemma 4는 Gemini 3의 기술 기반으로 설계되어 지능 효율을 극대화한 오픈 모델 구조를 채택
  • 모델 크기는 E2B, E4B, 26B, 31B 네 가지 버전으로 구분되며, 각 버전은 컴퓨팅 자원과 메모리 효율성에 따라 최적화됨
    • E2B·E4B: 모바일 및 IoT 기기용으로, 최대 효율성과 오프라인 실행 지원
    • 26B·31B: 개인용 GPU 환경에서 프론티어급 추론 능력 제공

주요 기능

  • Agentic workflows

    • 함수 호출(function calling) 을 네이티브로 지원해, 사용자를 대신해 계획·앱 탐색·작업 수행이 가능한 자율형 에이전트 구축 가능

  • Multimodal reasoning

    • 오디오와 비주얼 이해 능력을 결합해 풍부한 멀티모달 애플리케이션 개발 지원

  • Support for 140 languages

    • 단순 번역을 넘어 문화적 맥락 이해를 포함한 다국어 경험 생성 가능

  • Fine tuning

    • 사용자가 선호하는 프레임워크와 기법으로 특정 작업 성능 향상을 위한 파인튜닝 가능

  • Efficient architecture

    • 자체 하드웨어에서 실행 가능하며, 효율적인 개발 및 배포 환경 제공

성능

  • Gemma 4는 다양한 텍스트 생성 관련 데이터셋과 지표를 기반으로 평가됨
  • 주요 벤치마크 결과 (Gemma 4 31B IT 기준):
    • Arena AI (text): 1452 (Gemma 3 27B 대비 1365)
    • MMMLU (다국어 Q&A): 85.2%
    • MMMU Pro (멀티모달 추론): 76.9%
    • AIME 2026 (수학): 89.2%
    • LiveCodeBench v6 (코딩 문제): 80.0%
    • GPQA Diamond (과학 지식): 84.3%
    • τ2-bench (에이전트 도구 사용): 86.4%
  • 전반적으로 Gemma 3 대비 모든 항목에서 성능 향상을 보이며, 특히 수학·코딩·멀티모달 이해 영역에서 큰 개선

E2B 및 E4B — 모바일 및 IoT용

  • 오디오·비전 지원을 통해 엣지 디바이스에서 실시간 처리 가능
  • 스마트폰, Raspberry Pi, Jetson Nano 등에서 완전 오프라인 실행 및 거의 제로 지연(latency) 성능 제공
  • Google AI Edge Gallery를 통해 체험 가능

26B 및 31B — 고성능 로컬 AI

  • IDE, 코딩 어시스턴트, 에이전트형 워크플로에 적합한 고급 추론 기능 제공
  • 소비자용 GPU에 최적화되어 학생·연구자·개발자가 로컬 AI 서버 환경을 구축 가능
  • Google AI Studio에서 직접 실행 가능

보안 및 신뢰성

  • Gemma 4는 Google의 상용 모델과 동일한 인프라 보안 프로토콜을 적용
  • 기업 및 공공기관이 사용할 수 있는 투명하고 신뢰할 수 있는 기반 제공
  • 최고 수준의 보안·신뢰성 기준을 충족하면서도 최신 AI 기능을 제공

다운로드 및 실행

  • 모델 가중치 다운로드

    • Hugging Face, Ollama, Kaggle, LM Studio, Docker Hub에서 Gemma 4 모델 가중치 제공

  • 학습 및 배포 지원

    • Jax, Vertex AI, Keras, Google AI Edge, Google Kubernetes Engine, Ollama 등 다양한 플랫폼과 통합 지원
    • 공식 문서 및 API를 통해 훈련·배포·추론 환경 구성 가능

Gemmaverse 커뮤니티

  • Gemmaverse를 통해 전 세계 개발자들이 Gemma를 활용해 구축한 프로젝트를 탐색 가능
  • Google DeepMind의 X, Instagram, YouTube, LinkedIn, GitHub 채널을 통해 최신 업데이트 제공
  • 구독을 통해 최신 AI 혁신 소식 수신 가능

[출처] https://news.hada.io/topic?id=28138

Loading

Category: 경영 및 창업, 기술자료, 알아봅시다, 업무참고자료 | LEAVE A COMMENT
3 4월 2026

[인공지능 기술] Harness — Claude Code 에이전트 팀 & 스킬 아키텍트 플러그인 

[인공지능 기술] Harness — Claude Code 에이전트 팀 & 스킬 아키텍트 플러그인 

Harness — Claude Code 에이전트 팀 & 스킬 아키텍트 플러그인

 (github.com/revfactory)

112P by xguru 5일전 | ★ favorite | 댓글 6개
  • “하네스 구성해줘” 한 마디로 도메인에 맞는 전문 에이전트팀을 설계하고, 에이전트가 사용할 스킬까지 자동 생성해주는 메타 스킬
  • 6가지 아키텍처 패턴을 지원하며, 에이전트 간 오케스트레이션과 에러 핸들링 프로토콜을 포함
  • 아키텍처 패턴
    • 파이프라인: 순차 의존 작업
    • 팬아웃/팬인: 병렬 독립 작업
    • 전문가 풀: 상황별 선택 호출
    • 생성-검증: 생성 후 품질 검수
    • 감독자: 중앙 에이전트가 동적 분배
    • 계층적 위임: 상위→하위 재귀적 위임
  • 6단계 워크플로우 : 도메인 분석 → 팀 아키텍처 설계(에이전트 팀 vs 서브 에이전트) → 에이전트 정의 생성 → 스킬 생성 → 통합 및 오케스트레이션 → 검증 및 테스트
  • 실행 모드는 두 가지:
    • 에이전트 팀(기본): TeamCreate + SendMessage + TaskCreate 방식, 2개 이상 에이전트·협업 필요 시 권장
    • 서브 에이전트: Agent 도구 직접 호출, 단발성 작업·통신 불필요 시 적합
  • 하네스 실행 시 .claude/agents/에 에이전트 정의 파일(예: analyst.md, builder.md, qa.md), .claude/skills/에 스킬 파일이 자동 생성됨
  • 생성할 수 있는 팀 구성 예시
    • 딥 리서치 — 리서치 하네스를 구성해줘. 어떤 주제든 여러 각도에서 조사할 수 있는 에이전트 팀이 필요해 — 웹 검색, 학술 자료, 커뮤니티 반응 — 교차 검증 후 종합 보고서를 작성하는 팀.
    • 웹사이트 제작 — 풀스택 웹사이트 개발 하네스를 구성해줘. 디자인, 프론트엔드(React/Next.js), 백엔드(API), QA 테스트를 와이어프레임부터 배포까지 파이프라인으로 조율하는 팀.
    • 웹툰 제작 — 웹툰 에피소드 제작 하네스를 구성해줘. 스토리 작성, 캐릭터 디자인 프롬프트, 패널 레이아웃 기획, 대사 편집 에이전트가 필요하고 서로의 작업물을 스타일 일관성 관점에서 리뷰해야 해.
    • 유튜브 콘텐츠 기획 — 유튜브 콘텐츠 제작 하네스를 구성해줘. 트렌드 조사, 대본 작성, 제목/태그 SEO 최적화, 썸네일 컨셉 기획을 감독자 에이전트가 조율하는 팀.
    • 코드 리뷰 — 종합 코드 리뷰 하네스를 구성해줘. 아키텍처, 보안 취약점, 성능 병목, 코드 스타일을 병렬로 감사하는 에이전트들이 결과를 하나의 리포트로 통합하는 팀.
    • 기술 문서 작성 — 이 코드베이스에서 API 문서를 자동 생성하는 하네스를 구성해줘. 엔드포인트 분석, 설명 작성, 사용 예제 생성, 완성도 리뷰를 파이프라인으로 처리하는 팀.
    • 데이터 파이프라인 설계 — 데이터 파이프라인 설계 하네스를 구성해줘. 스키마 설계, ETL 로직, 데이터 검증 규칙, 모니터링 설정을 계층적으로 위임하는 에이전트 팀.
    • 마케팅 캠페인 — 마케팅 캠페인 제작 하네스를 구성해줘. 타겟 시장 조사, 광고 카피 작성, 비주얼 컨셉 디자인, A/B 테스트 계획을 반복적 품질 리뷰와 함께 진행하는 팀.
  • revfactory/harness-100 — 10개 도메인, 100개의 프로덕션 레디 에이전트 팀 하네스(한영 200패키지) 공개
    • 각 하네스에 4-5명의 전문 에이전트, 오케스트레이터 스킬, 도메인 특화 스킬 포함
    • 콘텐츠 제작·소프트웨어 개발·데이터/AI·비즈니스 전략·교육·법률·헬스케어 등 1,808개 마크다운 파일로 구성
    • 모두 Harness 플러그인으로 생성됨
  • 클로드 코드의 에이전트 팀 기능 활성화 필요: CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1

[출처] https://news.hada.io/topic?id=27969

Loading

Category: stechstar.com 운영정보, 경영 및 창업, 기술자료, 알아봅시다, 업무참고자료 | LEAVE A COMMENT
26 3월 2026

[인공지능 기술] AI 이야기, 이제 지겹지 않나요? 

[인공지능 기술] AI 이야기, 이제 지겹지 않나요? 

AI 이야기, 이제 지겹지 않나요?

 (blog.jakesaunders.dev)

31P by GN⁺ 1일전 | ★ favorite | 댓글 15개
  • AI가 워크플로를 완전히 바꿔놓았고 생산성도 크게 높여줬지만, 매일 쓰다 보니 이제 더 이상 새로울 게 없는 일상이 됨
  • Hacker News 등 개발자 커뮤니티가 거의 동일한 Claude Code 워크플로 자랑과 AI 도구 설정 이야기로 뒤덮여, 흥미로운 프로젝트와 문제 해결 논의가 밀려남
  • 2023년에는 코드보다 제품 가치(Product Engineer) 에 집중하자는 흐름이 있었는데, 지금은 엔지니어링에서 가장 쉬운 부분을 더 쉽게 만드는 도구에 집착하는 방향으로 퇴보
  • 경영진까지 AI에 올라타면서 개발자당 토큰 사용량 같은 무의미한 지표를 측정하기 시작, 과거 코드 줄 수 측정과 다를 바 없음
  • 도구가 아니라 그 도구로 무엇을 만들고 있는지, 누군가에게 가치를 전달하는 진짜 목적을 이야기해야 함

AI 피로감: 놀랍지만 이제는 일상

  • AI는 놀라운 기술이고 매일 사용하며 워크플로를 완전히 바꿔놓았지만, 일상적으로 쓰다 보니 더 이상 대화할 거리가 남지 않은 느낌
  • 최근 새 역할을 맡아 까다로운 도메인에서 웹 스케일 작업을 시작했는데, AI 덕분에 몇 주 만에 생산성이 0에서 1로 올라감
  • 변화의 속도가 빠른 건 맞지만, 하루하루 체감하는 수준에서는 루틴화된 상태

개발자 커뮤니티의 AI 편중

  • Hacker News는 원래 흥미로운 프로젝트와 문제 해결로 가득했지만, 지금은 세 명이 올리는 거의 동일한 Claude Code 워크플로와 OpenClaw로 고양이 쓰다듬고 비디오 게임 하면서 절약한 시간으로 또 AI 도구를 설정한다는 포스트로 변질
  • 이 현상이 자기 충족적(self-fulfilling) 순환 구조를 만들고 있음
  • Kagi Small Web도 같은 현상의 예시로, ‘next’ 버튼을 20번 누르면 AI 관련 글이 얼마나 되는지 확인해볼 만함

Product Engineer에서 도구 집착으로의 퇴보

  • 2023년, 누구든 Claude Code 터미널을 열 수 있는 사람을 ‘AI 엔지니어’라 부르기 전, ‘Product Engineer’ 가 가장 뜨거운 개념이었음
  • 코드에 대한 집착에서 벗어나 제품이 전달하는 가치에 집중하자는 방향이었고, 매우 합리적이었음
  • 하지만 지금은 코드 대신 과도하게 비대해진 자동완성 도구(overgrown auto-complete) 에 집착하는 상태로 퇴보
    • 엔지니어링에서 가장 쉬운 부분을 더 쉽게 만드는 데 몰두하는 꼴
  • 목공 커뮤니티에 비유하면, 만든 테이블 사진을 올리던 곳에서 모두가 같은 망치를 같은 방식으로 쓰면서 망치 이야기만 소리치는 상황

경영진의 AI 개입과 무의미한 지표

  • 과거 매니저들은 데이터베이스 기술, IDE, JavaScript 프레임워크에 관심이 없었고 기능 완성과 판매만 원했음
  • 이번에는 경영진이 구현 세부사항에 직접 발을 들여놓기 시작
  • 대부분의 개발자가 올해 목표에 ‘AI를 더 사용하라’ 는 회사 이니셔티브를 받았을 것
  • 기존 경영진의 SDLC 개입은 DORA 메트릭스 등 산출물(faster deploys, time to respond) 중심이었지만, 지금은 개발자당 토큰 사용량을 측정하고 있음
    • 이는 과거 코드 줄 수(lines of code) 측정만큼이나 무의미한 지표

결론: 도구가 아니라 만드는 것을 이야기하자

  • 사용하는 도구보다 그 도구로 만드는 멋진 결과물을 더 이야기해달라는 요청
  • 코딩을 포함한 모든 크래프트의 본래 목적은 누군가에게 가치를 전달하는 것, 그 누군가가 자기 자신이더라도
  • AI에 대한 글을 불평하는 글 자체가 AI에 대한 글이라는 아이러니를 인지하고 있음

[출처] https://news.hada.io/topic?id=27827

Loading

Category: stechstar.com 운영정보, 경영 및 창업, 기술자료, 알아봅시다, 학습자료 | LEAVE A COMMENT
24 3월 2026

[인공지능 기술] Claude Code를 만들며 배운 것: 우리가 Skills를 사용하는 방법 

[인공지능 기술] Claude Code를 만들며 배운 것: 우리가 Skills를 사용하는 방법 

Claude Code를 만들며 배운 것: 우리가 Skills를 사용하는 방법

 (x.com/trq212)

92P by GN⁺ 5일전 | ★ favorite | 댓글 1개
  • 클로드 코드에서 Skills는 가장 많이 사용되는 확장 포인트 중 하나로, Anthropic 내부에서 수백 개의 스킬을 실제로 운용하며 축적한 실전 노하우를 공개
  • 스킬은 단순 마크다운 파일이 아니라 스크립트, 에셋, 데이터 등을 포함하는 폴더 구조이며, 에이전트가 탐색하고 활용할 수 있는 형태
  • 라이브러리 레퍼런스, 제품 검증, 데이터 분석, 코드 스캐폴딩, CI/CD 등 9가지 스킬 카테고리로 분류되며, 좋은 스킬은 하나의 카테고리에 깔끔히 맞아야 함
  • 스킬 작성 시 Gotchas 섹션, 파일 시스템 활용, 점진적 공개(Progressive Disclosure), 데이터 저장 등의 실전 팁이 핵심
  • 조직 확장 시에는 내부 플러그인 마켓플레이스를 통해 스킬을 배포하고, 사용량 측정 훅으로 효과를 추적하는 구조 권장

Skills란 무엇인가

  • Skills에 대한 흔한 오해는 “그냥 마크다운 파일”이라는 것이지만, 실제로는 스크립트, 에셋, 데이터 등을 포함하는 폴더 구조
  • 에이전트가 이 폴더를 탐색하고, 내용을 발견하고, 조작할 수 있음
  • Claude Code에서 Skills는 다양한 설정 옵션을 제공하며, 동적 훅(dynamic hooks) 등록도 가능
  • 가장 흥미로운 스킬들은 이러한 설정 옵션과 폴더 구조를 창의적으로 활용하는 것들

스킬의 9가지 카테고리

  • 내부에서 사용 중인 스킬을 모두 분류한 결과, 반복적으로 나타나는 몇 가지 카테고리로 클러스터링됨
  • 좋은 스킬은 하나의 카테고리에 깔끔히 맞고, 혼란스러운 스킬은 여러 카테고리에 걸쳐 있음

  • 1. Library & API Reference

    • 라이브러리, CLI, SDK를 올바르게 사용하는 방법을 설명하는 스킬
    • 내부 라이브러리뿐 아니라 Claude Code가 자주 실수하는 일반 라이브러리도 대상
    • 레퍼런스 코드 스니펫 폴더와 주의사항(gotchas) 목록을 포함하는 경우가 많음
    • 예시: billing-lib(내부 결제 라이브러리의 엣지 케이스), internal-platform-cli(내부 CLI 래퍼의 모든 서브커맨드와 사용 예시), frontend-design(디자인 시스템 적용 개선)

  • 2. Product Verification

    • 코드가 정상 동작하는지 테스트하고 검증하는 방법을 기술하는 스킬
    • Playwright, tmux 등 외부 도구와 결합하여 사용하는 경우가 많음
    • Claude의 출력 정확성 보장에 매우 유용하며, 엔지니어가 일주일을 투자해서라도 검증 스킬을 우수하게 만들 가치가 있음
    • Claude가 출력을 영상으로 녹화하도록 하거나, 각 단계에서 상태에 대한 프로그래매틱 어설션을 강제하는 기법 권장
    • 예시: signup-flow-driver(가입→이메일 인증→온보딩을 헤드리스 브라우저로 수행), checkout-verifier(Stripe 테스트 카드로 결제 UI 구동 후 인보이스 상태 검증), tmux-cli-driver(TTY가 필요한 인터랙티브 CLI 테스트용)

  • 3. Data Fetching & Analysis

    • 데이터 및 모니터링 스택에 연결하는 스킬
    • 크레덴셜이 포함된 데이터 가져오기 라이브러리, 특정 대시보드 ID, 일반적 워크플로우 안내 등을 포함
    • 예시: funnel-query(가입→활성화→결제 퍼널에 필요한 이벤트와 canonical user_id가 있는 테이블), cohort-compare(두 코호트의 리텐션/전환율 비교 및 통계적 유의성 플래깅), grafana(데이터소스 UID, 클러스터명, 문제→대시보드 룩업 테이블)

  • 4. Business Process & Team Automation

    • 반복적인 워크플로우를 하나의 명령으로 자동화하는 스킬
    • 비교적 단순한 지시문이지만 다른 스킬이나 MCP에 대한 복잡한 의존성을 가질 수 있음
    • 이전 실행 결과를 로그 파일에 저장하면 모델이 일관성을 유지하고 이전 실행을 반영하는 데 도움
    • 예시: standup-post(티켓 트래커, GitHub 활동, Slack을 종합한 포맷 스탠드업), create-ticket(스키마 강제 및 생성 후 워크플로우), weekly-recap(머지된 PR+닫힌 티켓+배포를 요약 포스트로 작성)

  • 5. Code Scaffolding & Templates

    • 코드베이스의 특정 기능에 대한 프레임워크 보일러플레이트를 생성하는 스킬
    • 조합 가능한 스크립트와 결합할 수 있으며, 코드만으로는 다 커버할 수 없는 자연어 요구사항이 있을 때 특히 유용
    • 예시: new-framework-workflow(어노테이션 포함 새 서비스/워크플로우/핸들러 스캐폴딩), new-migration(마이그레이션 파일 템플릿과 주의사항), create-app(인증, 로깅, 배포 설정이 미리 연결된 새 내부 앱)

  • 6. Code Quality & Review

    • 조직 내 코드 품질을 강제하고 코드 리뷰를 돕는 스킬
    • 최대한의 견고성을 위해 결정론적 스크립트나 도구를 포함할 수 있음
    • 훅이나 GitHub Action의 일부로 자동 실행할 수도 있음
    • 예시: adversarial-review(새로운 시각의 서브에이전트가 비판→수정→반복하여 지적이 니트픽 수준으로 떨어질 때까지 진행), code-style(Claude가 기본적으로 잘 못하는 코드 스타일 강제), testing-practices(테스트 작성 방법과 테스트 대상 안내)

  • 7. CI/CD & Deployment

    • 코드베이스 내에서 코드를 가져오고, 푸시하고, 배포하는 스킬
    • 다른 스킬을 참조하여 데이터를 수집할 수 있음
    • 예시: babysit-pr(PR 모니터링→flaky CI 재시도→머지 충돌 해결→자동 머지 활성화), deploy-service(빌드→스모크 테스트→점진적 트래픽 롤아웃→에러율 비교→회귀 시 자동 롤백), cherry-pick-prod(격리된 worktree→cherry-pick→충돌 해결→템플릿 PR 생성)

  • 8. Runbooks

    • 증상(Slack 스레드, 알림, 에러 시그니처 등)을 입력받아 멀티 도구 조사를 수행하고 구조화된 리포트를 생성하는 스킬
    • 예시: service-debugging(증상→도구→쿼리 패턴 매핑), oncall-runner(알림 가져오기→일반적 원인 체크→결과 포맷팅), log-correlator(요청 ID로 관련 시스템 전체 로그 수집)

  • 9. Infrastructure Operations

    • 일상적 유지보수와 운영 절차를 수행하며, 파괴적 작업에 대한 가드레일을 포함하는 스킬
    • 엔지니어가 중요 운영에서 베스트 프랙티스를 따르기 쉽게 해줌
    • 예시: resource-orphans(고아 Pod/볼륨 탐색→Slack 알림→대기 기간→사용자 확인→계단식 정리), dependency-management(조직의 의존성 승인 워크플로우), cost-investigation(스토리지/이그레스 비용 급증 원인 조사용 버킷 및 쿼리 패턴)

스킬 작성 팁

  • 당연한 것은 쓰지 말 것

    • Claude Code는 코드베이스에 대해 이미 많이 알고 있고, 코딩에 대한 기본 의견도 가지고 있음
    • 지식 중심 스킬을 만든다면 Claude의 일반적 사고방식에서 벗어나게 하는 정보에 집중해야 함
    • frontend-design 스킬이 좋은 예시로, Anthropic 엔지니어가 고객과 반복하며 Claude의 디자인 감각을 개선하기 위해 만든 것이며, Inter 폰트와 보라색 그라디언트 같은 전형적 패턴을 피하도록 구성

  • Gotchas 섹션 구축

    • 모든 스킬에서 가장 높은 신호 가치를 가지는 콘텐츠가 Gotchas 섹션
    • Claude가 스킬 사용 시 흔히 만나는 실패 지점에서 축적해야 함
    • 시간이 지나면서 이러한 gotchas를 계속 업데이트하는 것이 이상적

  • 파일 시스템과 점진적 공개 활용

    • 스킬은 폴더이므로 전체 파일 시스템을 컨텍스트 엔지니어링과 점진적 공개의 수단으로 활용해야 함
    • Claude에게 스킬에 어떤 파일이 있는지 알려주면, 적절한 시점에 읽음
    • 가장 단순한 형태: 상세 함수 시그니처와 사용 예시를 references/api.md 같은 별도 마크다운으로 분리
    • 최종 출력이 마크다운인 경우 assets/ 폴더에 템플릿 파일 포함 가능
    • 레퍼런스, 스크립트, 예시 등의 폴더가 Claude의 작업 효율을 높임

  • Claude를 과도하게 제약하지 말 것

    • Claude는 지시사항을 따르려 하지만, 스킬은 재사용성이 높으므로 지나치게 구체적인 지시는 주의해야 함
    • 필요한 정보는 주되, 상황에 유연하게 적응할 수 있는 여지를 줘야 함

  • 설정(Setup) 과정 설계

    • 일부 스킬은 사용자로부터 컨텍스트를 수집하는 설정 단계가 필요
    • 예: 스탠드업을 Slack에 올리는 스킬이라면 어느 채널에 올릴지 물어야 함
    • 좋은 패턴: 설정 정보를 스킬 디렉토리의 config.json 파일에 저장, 설정이 안 되어 있으면 에이전트가 사용자에게 질문
    • 구조화된 다중 선택 질문을 제시하려면 AskUserQuestion 도구 사용을 지시 가능

  • Description 필드는 모델을 위한 것

    • Claude Code가 세션을 시작하면 모든 가용 스킬의 description 목록을 빌드함
    • 이 목록을 Claude가 스캔하여 “이 요청에 맞는 스킬이 있는가?”를 판단
    • 따라서 description 필드는 요약이 아니라 이 스킬을 언제 트리거해야 하는지의 설명

  • 메모리 및 데이터 저장

    • 스킬에 데이터를 저장하는 형태의 메모리를 포함할 수 있음
    • 단순한 텍스트 로그 파일이나 JSON 파일부터 SQLite 데이터베이스까지 다양한 형태 가능
    • 예: standup-post 스킬이 standups.log에 모든 작성 이력을 저장하면, 다음 실행 시 Claude가 자신의 이력을 읽고 어제 이후 변경사항을 파악
    • 스킬 디렉토리에 저장한 데이터는 스킬 업그레이드 시 삭제될 수 있으므로 ${CLAUDE_PLUGIN_DATA}라는 안정적 폴더에 저장해야 함

  • 스크립트 저장 및 코드 생성

    • Claude에게 줄 수 있는 가장 강력한 도구 중 하나가 코드 자체
    • 스크립트와 라이브러리를 제공하면 Claude가 보일러플레이트 재구성 대신 구성(composition)에 집중 가능
    • 예: 데이터 과학 스킬에 이벤트 소스에서 데이터를 가져오는 헬퍼 함수 라이브러리 포함
    • Claude가 이 기능들을 조합하여 즉석에서 스크립트를 생성, “화요일에 무슨 일이 있었나?” 같은 복잡한 분석에 활용

  • On Demand Hooks

    • 스킬이 호출될 때만 활성화되고 세션 동안만 지속되는 훅을 포함할 수 있음
    • 항상 실행하기에는 부담스럽지만 특정 상황에서 매우 유용한 강한 의견의 훅에 적합
    • 예시:
      • /careful — rm -rf, DROP TABLE, force-push, kubectl delete를 PreToolUse 매처로 차단, 프로덕션 작업 시에만 활성화
      • /freeze — 특정 디렉토리 외의 모든 Edit/Write를 차단, 디버깅 시 의도치 않은 수정 방지에 유용

스킬 배포

  • 스킬의 큰 장점 중 하나는 팀 전체와 공유 가능하다는 점
  • 두 가지 공유 방식 존재:
    • 스킬을 리포에 체크인 (./.claude/skills 아래)
    • 플러그인으로 만들어 Claude Code Plugin 마켓플레이스에 업로드, 사용자가 설치

  • 마켓플레이스 관리

    • 소규모 팀이 소수 리포에서 작업할 때는 리포에 체크인하는 방식이 적합
    • 체크인된 스킬은 모델의 컨텍스트에 조금씩 추가되므로, 규모가 커지면 내부 플러그인 마켓플레이스가 유리
    • 마켓플레이스에 들어갈 스킬을 결정하는 중앙 팀은 없으며, 가장 유용한 스킬이 자연스럽게 발견되는 방식
    • 시도해볼 스킬이 있으면 GitHub의 sandbox 폴더에 업로드하고 Slack 등에서 안내
    • 충분한 견인력(traction)을 얻으면 스킬 소유자가 마켓플레이스로 이동하는 PR을 올림
    • 나쁘거나 중복된 스킬이 쉽게 만들어질 수 있으므로 릴리스 전 큐레이션 메커니즘이 중요

  • 스킬 조합(Composing Skills)

    • 스킬 간 의존성이 필요할 수 있음 (예: 파일 업로드 스킬 + CSV 생성 및 업로드 스킬)
    • 마켓플레이스나 스킬에 의존성 관리가 네이티브로 내장되어 있지는 않지만, 다른 스킬을 이름으로 참조하면 설치되어 있는 경우 모델이 호출

  • 스킬 측정

    • 스킬의 성과를 파악하기 위해 PreToolUse 훅으로 회사 내 스킬 사용량을 로깅
    • 인기 있는 스킬이나 기대 대비 트리거가 부족한 스킬을 찾는 데 활용

결론

  • Skills는 에이전트를 위한 매우 강력하고 유연한 도구이지만, 아직 초기 단계이며 모두가 최선의 활용법을 찾아가는 과정
  • 이 글은 확정적 가이드가 아니라 실전에서 효과가 있었던 팁 모음
  • 대부분의 스킬은 몇 줄과 하나의 gotcha에서 시작했으며, Claude가 새로운 엣지 케이스를 만날 때마다 사람들이 계속 추가하면서 개선

[출처] https://news.hada.io/topic?id=27640

Loading

Category: 경영 및 창업, 기술자료, 업무참고자료, 학습자료 | LEAVE A COMMENT
22 3월 2026

[자유게시판] 힘이나는 명언 100가지 준비했습니다 오늘 하루 마무리 잘하시길 바랍니다

[자유게시판] 힘이나는 명언 100가지 준비했습니다 오늘 하루 마무리 잘하시길 바랍니다

힘이나는 명언 100가지 준비했습니다 오늘 하루 마무리 잘하시길 바랍니다

박** 2022.01.04 조회수 : 1419753
힘이나는 명언 100가지 준비했습니다 오늘 하루 마무리 잘하시길 바랍니다

세상사는데 도움이되는 명언들 힘이되는 명언 용기를 주는 명언 위로가되는 명언 좋은명언 글귀 모음 100가지 자주 보면 좋을듯 하여 선별 했습니다.

1. 삶이 있는 한 희망은 있다 -키케로
2. 산다는것 그것은 치열한 전투이다. -로망로랑
3. 하루에 3시간을 걸으면 7년 후에 지구를 한바퀴 돌 수 있다. -사무엘존슨
4. 언제나 현재에 집중할수 있다면 행복할것이다. -파울로 코엘료
5. 진정으로 웃으려면 고통을 참아야하며 , 나아가 고통을 즐길 줄 알아야 해 -찰리 채플린
6. 직업에서 행복을 찾아라. 아니면 행복이 무엇인지 절대 모를 것이다 -엘버트 허버드
7. 신은 용기있는자를 결코 버리지 않는다 -켄러
8. 행복의 문이 하나 닫히면 다른 문이 열린다 그러나 우리는 종종 닫힌 문을 멍하니 바라보다가
9.우리를 향해 열린 문을 보지 못하게 된다 – 헬렌켈러
10. 피할수 없으면 즐겨라 – 로버트 엘리엇
11. 단순하게 살아라. 현대인은 쓸데없는 절차와 일 때문에 얼마나 복잡한 삶을 살아가는가?-이드리스 샤흐
12. 먼저 자신을 비웃어라. 다른 사람이 당신을 비웃기 전에 – 엘사 맥스웰
13. 먼저핀꽃은 먼저진다 남보다 먼저 공을 세우려고 조급히 서둘것이 아니다 – 채근담
14. 행복한 삶을 살기위해 필요한 것은 거의 없다. -마르쿠스 아우렐리우스 안토니우스
15. 절대 어제를 후회하지 마라 . 인생은 오늘의 나 안에 있고 내일은 스스로 만드는 것이다 L.론허바드
16. 어리석은 자는 멀리서 행복을 찾고, 현명한 자는 자신의 발치에서 행복을 키워간다 -제임스 오펜하임
17. 너무 소심하고 까다롭게 자신의 행동을 고민하지 말라 . 모든 인생은 실험이다 . 더많이 실험할수록 더나아진다 – 랄프 왈도 에머슨
18. 한번의 실패와 영원한 실패를 혼동하지 마라 -F.스콧 핏제랄드
19. 내일은 내일의 태양이 뜬다
20. 피할수 없으면 즐겨라 -로버트 엘리엇
21.절대 어제를 후회하지 마라. 인생은 오늘의 내 안에 있고 내일은 스스로 만드는것이다. -L론허바드
22. 계단을 밟아야 계단 위에 올라설수 있다, -터키속담
23. 오랫동안 꿈을 그리는 사람은 마침내 그 꿈을 닮아 간다, -앙드레 말로
24. 좋은 성과를 얻으려면 한 걸음 한 걸음이 힘차고 충실하지 않으면 안 된다, -단테
25. 행복은 습관이다,그것을 몸에 지니라 -허버드
26. 성공의 비결은 단 한 가지, 잘할 수 있는 일에 광적으로 집중하는 것이다.- 톰 모나건
27. 자신감 있는 표정을 지으면 자신감이 생긴다 -찰스다윈
28. 평생 살 것처럼 꿈을 꾸어라.그리고 내일 죽을 것처럼 오늘을 살아라. – 제임스 딘
29. 네 믿음은 네 생각이 된다 . 네 생각은 네 말이 된다. 네말은 네 행동이 된다 네행동은 네 습관이된다 . 네 습관은 네 가치가 된다 . 네 가치는 네 운명이 된다 – 간디
30. 일하는 시간과 노는 시간을 뚜렷이 구분하라 . 시간의 중요성을 이해하고 매순간을 즐겁게 보내고 유용하게 활용하라. 그러면 젋은 날은 유쾌함으로 가득찰것이고 늙어서도 후회할 일이 적어질것이며 비록 가난할 때라도 인생을 아름답게 살아갈수있다 – 루이사 메이올콧
31. 절대 포기하지 말라. 당신이 되고 싶은 무언가가 있다면, 그에 대해 자부심을 가져라. 당신 자신에게 기회를 주어라. 스스로가 형편없다고 생각하지 말라. 그래봐야 아무 것도 얻을 것이 없다. 목표를 높이 세워라.인생은 그렇게 살아야 한다. – 마이크 맥라렌
32. 1퍼센트의 가능성, 그것이 나의 길이다. -나폴레옹
33. 그대 자신의 영혼을 탐구하라.다른 누구에게도 의지하지 말고 오직 그대 혼자의 힘으로 하라. 그대의 여정에 다른 이들이 끼어들지 못하게 하라. 이 길은 그대만의 길이요, 그대 혼자 가야할 길임을 명심하라. 비록 다른 이들과 함께 걸을 수는 있으나 다른 그 어느 누구도 그대가 선택한 길을 대신 가줄 수 없음을 알라.
-인디언 속담
33. 고통이 남기고 간 뒤를 보라! 고난이 지나면 반드시 기쁨이 스며든다. -괴테
34. 삶은 소유물이 아니라 순간 순간의 있음이다 영원한 것이 어디 있는가 모두가 한때일뿐 그러나 그 한때를 최선을 다해 최대한으로 살수 있어야 한다 삶은 놀라운 신비요 아름다움이다. 법정스님 -버리고 떠나기
35. 꿈을 계속 간직하고 있으면 반드시 실현할 때가 온다. -괴테
36. 화려한 일을 추구하지 말라. 중요한 것은 스스로의 재능이며, 자신의 행동에 쏟아 붓는 사랑의 정도이다. -머더 테레사
37. 마음만을 가지고 있어서는 안된다. 반드시 실천하여야 한다. -이소룡
38. 흔히 사람들은 기회를 기다리고 있지만 기회는 기다리는 사람에게 잡히지 않는 법이다. 우리는 기회를 기다리는 사람이 되기 전에 기회를 얻을 수 있는 실력을 갖춰야 한다. 일에 더 열중하는 사람이 되어야한다. -안창호
39. 나이가 60이다 70이다 하는 것으로 그 사람이 늙었다 젊었다 할 수 없다. 늙고 젊은 것은 그 사람의 신념이 늙었느냐 젊었느냐 하는데 있다. -맥아더
40. 만약 우리가 할 수 있는 일을 모두 한다면 우리들은 우리자신에 깜짝 놀랄 것이다. -에디슨
42. 나는 누구인가 스스로 물으라 자신의 속얼굴이 드러나 보일 때까지 묻고 묻고 물어야 한다건성으로 묻지말고 목소리 속의 목소리로 귀 속의 귀에 대고 간절하게 물어야 한다해답은 그 물음 속에 있다. 법정스님- 산에는 꽃이 피네
43. 행복은 결코 많고 큰데만 있는 것이 아니다 작은 것을 가지고도 고마워 하고 만족할 줄 안다면 그는 행복한 사람이다. 여백과 공간의 아름다움은 단순함과 간소함에 있다. 법정스님 – 홀로사는 즐거움 에서
44. 물러나서 조용하게 구하면 배울 수 있는 스승은 많다. 사람은 가는 곳마다 보는 것마다 모두 스승으로서
배울 것이 많은 법이다. -맹자
45. 눈물과 더불어 빵을 먹어 보지 않은 자는 인생의 참다운 맛을 모른다. -괴테
46. 진짜 문제는 사람들의 마음이다. 그것은 절대로 물리학이나 윤리학의 문제가 아니다. -아인슈타인
47. 해야 할 것을 하라. 모든 것은 타인의 행복을 위해서, 동시에 특히 나의 행복을 위해서이다. -톨스토이
48. 사람이 여행을 하는 것은 도착하기 위해서가 아니라 여행하기 위해서이다. -괴테
49. 화가 날 때는 100까지 세라. 최악일 때는 욕설을 퍼부어라. -마크 트웨인
50. 재산을 잃은 사람은 많이 잃은 것이고, 친구를 잃은 사람은 더많이 잃은 것이며, 용기를 잃은 사람은 모든것을 잃은 것이다. -세르반테스
51. 돈이란 바닷물과도 같다. 그것은 마시면 마실수록 목이 말라진다. -쇼펜하우어
52. 이룰수 없는 꿈을 꾸고 이길수 없는 적과 싸우며, 이룰수 없는 사랑을 하고 견딜 수 없는 고통을 견디고,
잡을수 없는 저 하늘의 별도 잡자. -세르반테스
53. 고개 숙이지 마십시오. 세상을 똑바로 정면으로 바라보십시오. -헬렌 켈러
54. 고난의 시기에 동요하지 않는 것, 이것은 진정 칭찬받을 만한 뛰어난 인물의 증거다. -베토벤
55. 사막이 아름다운 것은 어딘가에 샘이 숨겨져 있기 때문이다 – 생떽쥐베리
56. 행복의 한 쪽 문이 닫히면 다른 쪽 문이 열린다. 그러나 흔히 우리는 닫혀진 문을 오랫동안 보기 때문에 우리를 위해 열려 있는 문을 보지 못한다. -헬렌 켈러
57. 만족할 줄 아는 사람은진정한 부자이고, 탐욕스러운 사람은진실로 가난한 사람이다. -솔론
58. 성공해서 만족하는 것은 아니다. 만족하고 있었기 때문에 성공한 것이다.-알랭
59. 곧 위에 비교하면 족하지 못하나,아래에 비교하면 남음이 있다. -명심보감
60. 그대의 하루 하루를 그대의 마지막 날이라고 생각하라 – 호라티우스
61. 자신을 내보여라. 그러면 재능이 드러날 것이다. – 발타사르 그라시안
62. 자신의 본성이 어떤것이든 그에 충실하라 . 자신이 가진 재능의 끈을 놓아 버리지 마라. 본성이 이끄는 대로 따르면 성공할것이다 -시드니 스미스
63. 당신이 할수 있다고 믿든 할수 없다고 믿든 믿는 대로 될것이다.- 헨리 포드
64. 단순하게 살라. 쓸데없는 절차와 일 때문에 얼마나 복잡한 삶을 살아가는가? -이드리스 샤흐
65. 당신이 인생의 주인공이기 때문이다 . 그사실을 잊지마라 . 지금까지 당신이 만들어온 의식적 그리고 무의식적 선택으로 인해 지금의 당신이 있는것이다 . – 바바라 홀
66. 지금이야 말로 일할때다. 지금이야말로 싸울때다. 지금이야말로 나를 더 훌륭한 사람으로 만들때다 오늘 그것을 못하면 내일 그것을 할수있는가- 토마스 아켐피스
67. 모든것들에는 나름의 경이로움과 심지어 어둠과 침묵이 있고 , 내가 어떤 상태에 있더라도 나는 그속에서 만족하는 법을 배운다 -헬렌켈러
68. 작은 기회로 부터 종종 위대한 업적이 시작된다 -데모스테네스
69. 인생이란 학교에는 불행 이란 훌륭한 스승이 있다. 그 스승 때문에 우리는 더욱 단련되는 것이다. -프리체
70. 세상은 고통으로 가득하지만 그것을 극복하는 사람들로도 가득하다 – 헨렌켈러
71. 도저히 손댈 수가 없는 곤란에 부딪혔다면 과감하게 그 속으로 뛰어들라 . 그리하면 불가능하다고 생각했던 일이 가능해진다.
72. 용기있는 자로 살아라. 운이 따라주지 않는다면 용기 있는 가슴으로 불행에 맞서라. -키케로
73. 최고에 도달하려면 최저에서 시작하라. -P.시루스
74. 내 비장의 무기는 아직 손안에 있다 .그것은 희망이다 – 나폴레옹
75. 문제는 목적지에 얼마나 빨리 가느내가 아니라 그 목적지가 어디냐는 것이다. -메이벨 뉴컴버
76. 한 번 실패와 영원한 실패를 혼동하지 마라. -F.스콧 핏제랄드
77. 인간의 삶 전체는 단지 한 순간에 불과하다 . 인생을 즐기자 – 플루타르코스
78. 겨울이 오면 봄이 멀지 않으리 -셸리
79. 일하여 얻으라 . 그러면 운명의 바퀴를 붙들어 잡은것이다 -랄프 왈도 에머슨
80. 당신의 행복은 무엇이 당신의 영혼을 노래하게 하는가에 따라 결정된다. – 낸시 설리번
81. 자신이 해야 할 일을 결정하는 사람은 세상에서 단 한 사람, 오직 나 자신뿐이다. -오손 웰스-
82. 먹고 싶은것을 다 먹는 것은 그렇게 재미있지 않다 . 인생을 경계선 없이 살면 기쁨이 덜하다 . 먹고싶은대로 다 먹을 수있다면 먹고싶은 것을 먹는데 무슨 재미가 있겠나 – 톰행크스
83. 인생을 다시 산다면 다음번에는 더 많은 실수를 저지르리라 – 나딘 스테어
84. 절대 어제를 후회하지 마라 . 인생은 오늘의 나 안에 있고 내일은 스스로 만드는 것이다 -L.론허바드
85. 인생에서 원하는 것을 엇기 위한 첫번째 단계는 내가 무엇을 원하는지 결정하는 것이다 -벤스타인
86. 가난은 가난하다고 느끼는 곳에 존재한다 .- 에머슨
87. 삶이 그대를 속일지라도 슬퍼하거나 노하지 말아라 슬픈 날에 참고 견디라 . 즐거운 날은 오고야 말리니 마음은 미래를 바라느니 현재는 한없이 우울한것 모든건 하염없이 사라지나가 버리고 그리움이 되리니 – 푸쉬킨
88. 문제점을 찾지 말고 해결책을 찾으라 – 헨리포드
89. 우선 무엇이 되고자 하는가를 자신에게 말하라 그리고 해야 할일을 하라 -에픽토테스
90. 되찾을 수 없는게 세월이니 시시한 일에 시간을 낭비하지 말고 순간순간을 후회 없이 잘 살아야 한다. -루소
91.인생에 뜻을 세우는데 있어 늦은 때라곤 없다 – 볼드윈
92. 도중에 포기하지 말라. 망설이지 말라. 최후의 성공을 거둘 때까지 밀고 나가자. – 헨리포드
93. 네 자신의 불행을 생각하지 않게 되는 가장 좋은 방법은 일에 몰두하는 것이다. -베토벤
94. 우리는 두려움의 홍수에 버티기 위해서 끊임없이 용기의 둑을 쌓아야 한다. -마틴 루터 킹
95. 직접 눈으로 본 일도 오히려 참인지 아닌지 염려스러운데 더구나 등뒤에서 남이 말하는 것이야 어찌 이것을 깊이 믿을 수 있으랴? -명심보감-
96. 이미끝나버린 일을 후회하기 보다는 하고 싶었던 일들을 하지못한 것을 후회하라. – 탈무드
97. 실패는 잊어라 그러나 그것이 준 교훈은 절대 잊으면 안된다. -하버트 개서
98. 내가 헛되이 보낸 오늘은 어제 죽어간 이들이 그토록 바라던 하루이다 단 하루면 인간적인 모든 것을 멸망시킬수도 다시 소생시킬수도 있다. -소포클레스
99. 성공으로 가는 엘리베이터는 고장입니다. 당신은 계단을 이용해야만 합니다. 한계단 한계단씩 – 조 지라드
100. 길을 잃는 다는 것은 곧 길을 알게 된다는 것이다. – 동아프리카속담
101. 삶을 사는 데는 단 두가지 방법이 있다. 하나는 기적이 전혀 없다고 여기는 것이고 또 다른 하나는 모든 것이 기적이라고 여기는방식이다. – 알베르트 아인슈타인



[출처] https://council.busan.go.kr/council/freeboard/52658

Loading

Category: 경영 및 창업, 사회포인트, 알아봅시다 | LEAVE A COMMENT