오픈비 : 삽질은없다

Claude Code 활용 가이드 2026

chaeya — Sat, 7 Feb 2026 17:51:36 +0900

Claude Code를 효과적으로 사용하는 방법을 정리한 가이드입니다.

1. 초기화 및 설정

CLAUDE.md 작성 (핵심)

CLAUDE.md는 모든 세션 시작 시 Claude가 읽는 특별 파일입니다.

파일 위치:

전역: ~/.claude/CLAUDE.md (모든 프로젝트)
프로젝트: ./CLAUDE.md (git 커밋 권장)
프로젝트 로컬: ./CLAUDE.local.md (git 무시)

포함 가이드라인:

✅ 포함	❌ 제외
Bash 명령어 (추측 불가능한 것)	코드에서 알 수 있는 것
코드 스타일 (기본값과 다른)	표준 언어 규칙
테스트 지침 및 선호 러너	긴 API 문서
저장소 에티켓 (브랜치 명명, PR 규칙)	자주 변경되는 정보
아키텍처 결정	파일별 코드베이스 설명
개발 환경 특이사항 (필수 env vars)	자명한 것들

좋은 예시:

# Code style
- Use ES modules (import/export) syntax
- Destructure imports when possible

# Workflow
- Typecheck after code changes
- Prefer running single tests for performance

/init 명령어

/init

/init 명령어로 코드베이스를 자동 분석하여 빌드 시스템, 테스트 프레임워크, 코드 패턴을 감지할 수 있습니다.

2. SKILL 시스템

Skill이란?

Skills는 Claude의 기능을 확장하는 재사용 가능한 지시사항 모음입니다. 사용자가 직접 호출하거나 Claude가 자동으로 로드할 수 있습니다.

Skill 생성 방법

# 디렉토리 생성
mkdir -p ~/.claude/skills/explain-code

# SKILL.md 작성
cat > ~/.claude/skills/explain-code/SKILL.md << 'EOF'
---
name: explain-code
description: 코드를 시각 다이어그램과 비유로 설명합니다
---

코드 설명 시 포함:
1. **비유로 시작**: 일상생활과 비교
2. **다이어그램**: ASCII art로 흐름 표시
3. **코드 설명**: 단계별 설명
4. **gotcha 강조**: 일반적인 실수
EOF

Skill 실행 방법

자동 호출: description과 일치하는 질문
직접 호출: /explain-code src/auth/login.ts

Skill Frontmatter 필드

필드	설명
`name`	슬래시 명령어 이름
`description`	Claude가 언제 사용할지 결정
`disable-model-invocation`	`true`면 사용자만 호출 가능
`user-invocable`	`false`면 Claude만 사용 가능
`allowed-tools`	스킬 활성화 시 승인 없이 사용할 도구
`context`	`fork`면 하위 에이전트에서 실행
`agent`	`context: fork` 시 사용할 에이전트 타입

3. Subagents (전문 에이전트)

Subagent란?

독립된 컨텍스트에서 실행되는 전문화된 에이전트입니다. 메인 컨텍스트를 망치지 않고 방대한 코드베이스를 조사하거나 특정 작업에 집중할 때 유용합니다.

Subagent 생성

mkdir -p ~/.claude/agents

cat > ~/.claude/agents/security-reviewer.md << 'EOF'
---
name: security-reviewer
description: 코드의 보안 취약점을 검토합니다
tools: Read, Grep, Glob, Bash
model: opus
---

보안 엔지니어로서 코드를 검토하세요:
- 인젝션 취약점 (SQL, XSS, 명령어 인젝션)
- 인증 및 인가 결함
- 코드 내 비밀키 또는 자격증명
- 안전하지 않은 데이터 처리
EOF

내장 Subagent 유형

에이전트	용도	도구
`Explore`	코드베이스 탐색	읽기 전용
`Plan`	구현 계획 수립	모든 도구 (Edit/Write 제외)
`general-purpose`	일반 작업	모든 도구

4. SKILL vs Subagent 차이점

둘 다 병렬 작업이 가능하지만, 목적과 사용 방식에 명확한 차이가 있습니다.

핵심 차이 비교

특징	SKILL	Subagent
목적	재사용 가능한 작업 패턴 정의	독립된 컨텍스트에서 특정 작업 수행
컨텍스트	메인 컨텍스트에서 실행	완전히 분리된 독립 컨텍스트
상태 공유	메인 대화 상태 유지	메인과 상태 분리
실행 방식	description으로 자동 로드 또는 /명령어	Task tool로 명시적 호출
사용 시점	반복적인 작업 패턴이 있을 때	방대한 코드베이스 조사 또는 특정 작업 집중
예시	코드 설명, 리뷰, 테스트 작성 패턴	보안 검토, 코드베이스 탐색, 구현 계획

언제 무엇을 사용해야 할까?

SKILL 사용이 적합한 경우:

프로젝트 특정의 반복 작업 (예: "우리 프로젝트의 API 라우트 작성 방법")
자주 사용하는 작업의 표준화 (예: 코드 리뷰 체크리스트)
사용자가 직접 호출하는 커맨드로 만들 때
메인 컨텍스트의 정보가 필요할 때

Subagent 사용이 적합한 경우:

방대한 코드베이스를 조사해야 할 때 (메인 컨텍스트 보호)
특정 전문 분야 작업 (예: 보안 전문가, 성능 최적화)
실험적 작업 (메인 대화에 영향 주지 않음)
병렬로 여러 독립 작업 실행

실제 예시:

# SKILL 예시 - 프로젝트 특정 패턴
# ~/.claude/skills/api-route.md
name: api-route
description: Next.js API 라우트 작성

# Subagent 예시 - 보안 검토
# ~/.claude/agents/security-audit.md
name: security-audit
tools: Read, Grep, Glob, Bash

5. MCP 서버 통합

MCP란?

Model Context Protocol (MCP)는 Claude가 외부 도구와 데이터 소스에 연결할 수 있는 오픈 소스 표준입니다.

MCP 서버 설정

~/.claude/settings.json 또는 .claude/settings.json:

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/allowed/path"]
    },
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"]
    }
  }
}

서버	설명
`@modelcontextprotocol/server-filesystem`	파일 시스템 접근
`@modelcontextprotocol/server-github`	GitHub 통합
`@modelcontextprotocol/server-postgres`	PostgreSQL 쿼리
`@modelcontextprotocol/server-brave-search`	웹 검색

6. Hooks 자동화

Hook이란?

Hook은 Claude Code 라이프사이클의 특정 지점에서 자동으로 실행되는 셸 명령어입니다.

주요 Hook 이벤트

이벤트	발생 시점
`SessionStart`	세션 시작 또는 재개
`PreToolUse`	도구 호출 전 (차단 가능)
`PostToolUse`	도구 호출 성공 후
`Notification`	알림 전송 시
`Stop`	Claude 응답 완료 시

Hook 설정 예시

알림 훅 (Linux):

{
  "hooks": {
    "Notification": [
      {
        "hooks": [{
          "type": "command",
          "command": "notify-send 'Claude Code' '입력 필요'"
        }]
      }
    ]
  }
}

자동 포맷팅:

{
  "hooks": {
    "PostToolUse": [{
      "matcher": "Edit|Write",
      "hooks": [{
        "type": "command",
        "command": "jq -r '.tool_input.file_path' | xargs npx prettier --write"
      }]
    }]
  }
}

7. 핵심 모범 사례

검증 가능한 작업 지시

❌ Before	✅ After
이메일 검증 함수 구현	validateEmail 함수 작성. 테스트 케이스: test@example.com은 true, invalid는 false. 구현 후 테스트 실행
대시버드 개선	[스크린샷] 이 디자인 구현. 결과 스크린샷 찍고 원본과 비교

구체적인 프롬프트

❌ Before	✅ After
foo.py에 테스트 추가	foo.py에 사용자 로그아웃 엣지 케이스 covering 테스트 작성. mock 사용 금지
ExecutionFactory API가 이상한 이유	ExecutionFactory의 git 히스토리를 살펴보고 API가 어떻게 되었는지 요약

컨텍스트 관리

작업 간 /clear 사용
Esc + Esc 또는 /rewind로 특정 지점부터 요약
SessionStart hook으로 컴팩션 후 컨텍스트 재주입

8. Claude Code 작업 가이드라인 (실전 예시)

1. 접근 방식 (Before Writing Code)

❌ 나쁜 예:

"사용자 인증 기능 구현해줘"

✅ 좋은 예:

사용자 인증 기능을 구현하고 싶습니다. 제 생각에는 다음과 같이 하면 될 것 같은데 확인 부탁드립니다:

JWT 토큰 방식 사용 (access token + refresh token)

로그인 시 토큰 발급, 헤더에 실어 보내기

src/api/auth.ts에 인증 관련 함수 작성

src/middleware/auth.ts에 미들웨어 작성

이 접근방식이 괜찮을까요?

2. 작업 분할 (3 Files+ Rule)

❌ 나쁜 예:

"전자상거래 시스템 만들어줘" (수십 개 파일 필요)

✅ 좋은 예:

전자상거래 시스템은 크네요. 먼저 다음과 같이 나누어 진행하면 어떨까요?

Task 1: 상품 목록 조회 API (src/api/products.ts)
Task 2: 장바구니 기능 (src/api/cart.ts)
Task 3: 결제 기능 (src/api/payment.ts)

Task 1부터 시작할까요?

3. 테스트 중심 개발

❌ 나쁜 예:

코드만 작성하고 끝

✅ 좋은 예:

코드를 작성했습니다. 이 코드에서 발생할 수 있는 문제점:

네트워크 실패: API 호출 실패 시 처리

잘못된 입력: null, undefined, 빈 문자열

경합 조건: 동시 요청 시 데이터 충돌

이를 covering하는 테스트 작성을 제안합니다:

src/auth/__tests__/login.test.ts

mocking 사용하여 네트워크 실패 시나리오 테스트

4. 버그 수정 TDD

❌ 나쁜 예:

버그 리포트를 보고 코드를 수정하기 시작

✅ 좋은 예:

버그 재현 테스트부터 작성하겠습니다:

// src/auth/__tests__/bug-reproduce.test.ts
test('로그인 후 바로 로그아웃하면 토큰이 남아있는 버그', async () => {
  const user = await login('test@example.com', 'password');
  await logout();
  const token = localStorage.getItem('token');
  expect(token).toBeNull(); // 이 테스트가 현재 실패함
});

이 테스트를 통과할 때까지 수정하겠습니다.

5. 지속적 개선 (CLAUDE.md 업데이트)

실제 예시:

# CLAUDE.md - 프로젝트 가이드

## 테스트 작성 규칙
- 모든 API 함수는 `__tests__` 디렉토리에 테스트 작성
- mocking은 msw 라이브러리 사용
- 네트워크 실패 케이스 항상 포함

## API 라우트 작성 패턴
```typescript
// 항상 이 패턴 따르기
export async function POST(req: Request) {
  try {
    // 1. 입력 검증
    // 2. 비즈니스 로직
    // 3. 응답 반환
  } catch (error) {
    // 4. 에러 처리
  }
}

참고 자료

공식 문서

커뮤니티 리소스

50+ Best MCP Servers for Claude Code in 2026

Claude Fast | 50+ curated MCP servers for Claude Code in 2026. The definitive list of best extensions and addons with direct links and install commands.

claudefa.st

Claude Code 워크플로우 가이드

chaeya — Sun, 4 Jan 2026 23:54:02 +0900

최근 AI 코딩 어시스턴트가 개발자들의 필수 도구가 되었습니다. 그중 Claude Code는 독특한 기능과 강력한 워크플로우 자동화 능력으로 주목받고 있습니다. 실제 프로젝트에서 검증한 Claude Code의 효과적인 사용법을 정리해 드립니다.

Claude Code란?

Claude Code는 Anthropic의 Claude 모델을 기반으로 한 CLI 기반 AI 코딩 어시스턴트입니다. 단순한 코드 생성을 넘어, 프로젝트 전체를 이해하고 컨텍스트를 유지하며 복잡한 작업을 수행할 수 있습니다.

핵심 특징

CLI 기반: 터미널에서 직접 사용, 개발 흐름에 자연스럽게 통합
프로젝트 인식: CLAUDE.md 파일을 통한 프로젝트별 맞춤 설정
Plan Mode: 복잡한 작업을 계획-실행으로 체계적 진행
Slash Commands: 반복 작업을 자동화하는 커맨드 시스템

실전 워크플로우

1. Plan Mode로 체계적 개발

가장 강력한 기능 중 하나는 Plan Mode입니다. Claude Code에서 Shift + Tab을 두 번 누르면 활성화됩니다.

# 복잡한 기능 개발 시
[Shift + Tab twice] → Plan Mode 진입

Plan Mode의 장점:

2-3배 더 높은 작업 성공률
코드베이스 전체를 탐색 후 설계
실행 전에 계획을 검토할 수 있음
단계별 구현 계획 자동 생성

2. tmux를 활용한 병렬 작업

장기 실행 작업과 병렬 작업을 위한 tmux 세션 관리 스크립트를 제공합니다.

# 세션 1: 메인 개발
tmux attach -t claude-1

# 세션 2: 테스트 (/test --watch)
tmux attach -t claude-2

# 세션 3: 문서 작업
tmux attach -t claude-3

원격에서도 계속 작업하기

tmux의 가장 큰 장점은 어디서든 동일한 세션에 접속할 수 있다는 것입니다:

# 집에서 SSH 접속 후 동일 세션에 연결
ssh user@office-pc
tmux attach -t claude-1  # 작업하던 그대로!

3. Slash Commands로 자동화

반복적인 작업을 슬래시 명령어로 자동화할 수 있습니다:

`/test` - 테스트 실행

/test           # Jest 테스트 실행
/test --watch   # 와치 모드

`/review` - 코드 리뷰

/review

정적 분석 (linting)
보안 검토 (OWASP Top 10)
성능 검토
코드 품질 점검

`/commit` - 커밋 생성

/commit

한국어 커밋 메시지 자동 생성 (접두사 없음, 최대 50자)
사전 커밋 검사 (lint, build, test)
Co-Authored-By 자동 추가

`/build` - 프로젝트 빌드

/build           # 스마트 빌드 (변경된 파일만)
/build --full    # 전체 빌드

`/deploy` - 서비스 관리

/deploy                       # 서비스 상태 확인
/deploy --restart airun-api   # 특정 서비스 재시작

일상적인 개발 워크플로우

표준 개발 사이클

# 1. Plan Mode로 계획 수립
[Shift + Tab twice]

# 2. Claude Code와 함께 개발

# 3. 검증
/test

# 4. 리뷰
/review

# 5. 커밋
/commit

복잡한 작업에는 전문가 Agent 호출

/backend-architect      # API, 데이터베이스, 확장성
/frontend-developer     # React, 컴포넌트, UI
/ui-designer            # 디자인 시스템, 시각 디자인
/code-simplifier        # 리팩토링, 복잡도 감소
/test-validator         # 테스트, 커버리지
/security-auditor       # 보안 스캔, 취약점
/performance-profiler   # 성능 최적화

핵심 Benefit

⏱️ 시간 단축

반복 작업 자동화 (커밋 메시지, 테스트, 빌드)
tmux 병렬 작업으로 동시에 여러 작업 수행
장소에 구애받지 않는 연속 작업

버그 감소

자동 검증 (후킹 자동 실행)
코드 리뷰 자동화
보안 취약점 스캔

품질 향상

일관된 커밋 메시지
보안 및 성능 검토
Plan Mode로 체계적 개발

생산성

병렬 작업 가능
전문가 agent 호출
어디서든 동일한 개발 환경 유지

참조 자료

공식 문서

워크플로우 관련

CLAUDE.md 가이드라인 - 프로젝트 설정 및 커스터마이징
GitHub Issue #349 - 실제 워크플로우 검증 결과

도구 및 기술

tmux 공식 홈페이지 - 터미널 멀티플렉서
Jest Testing Framework - JavaScript 테스트 프레임워크
Playwright - 브라우저 자동화

마무리하며

Claude Code는 단순한 AI 코딩 도구를 넘어, 개발 워크플로우 전체를 혁신할 수 있는 강력한 도구입니다. 특히 Plan Mode와 tmux를 결합한 병렬 작업, 그리고 Slash Commands를 통한 자동화는 개발 생산성을 크게 향상시킵니다.

실제 프로젝트에서 검증한 이 워크플로우를 적용해 보시면, 개발 속도와 코드 품질 모두에서 큰 차이를 느끼실 수 있을 것입니다.

추가 학습 자료

VRAM 16GB로 30B 모델 구동하기: LM Studio MoE 오프로딩 테스트

chaeya — Tue, 30 Dec 2025 18:42:49 +0900

VRAM 16GB로 30B 모델 구동하기: LM Studio MoE 오프로딩 테스트

핵심 성과: 30.5B 파라미터 MoE 모델을 단 7.8GB VRAM으로 성공적으로 구동! KV 캐시 RAM 오프로딩으로 더 적은 VRAM으로 더 큰 모델 실행 가능.

들어가며

로컬 LLM을 구동할 때 가장 큰 제약은 GPU 메모리(VRAM) 용량입니다. 일반적으로 7B 모델은 8-10GB VRAM, 13B 모델은 16-20GB VRAM이 필요합니다. 하지만 LM Studio의 MoE(Mixture of Experts) 오프로딩 기능을 활용하면 30B+ 모델도 16GB VRAM으로 구동할 수 있습니다!

이 글에서는 실제 테스트를 통해 MoE 오프로딩의 성능과 효율성을 검증하고, 상용 서비스 관점에서의 실용성을 분석합니다.

MoE 오프로딩이란?

MoE (Mixture of Experts) 아키텍처

MoE는 모델의 파라미터를 여러 "전문가(Expert)"로 분리하고, 각 요청에 대해 가장 관련 있는 Expert만 활성화하는 방식입니다.

┌─────────────────────────────────────────────────────────┐
│  기존 모델 vs MoE 모델                                 │
├─────────────────────────────────────────────────────────┤
│  기존 모델: 모든 파라미터가 항상 활성화                │
│  MoE 모델: 관련 Expert만 활성화, 나머지는 대기         │
└─────────────────────────────────────────────────────────┘

MoE 오프로딩의 핵심

LM Studio의 MoE 오프로딩은 다음과 같은 최적화를 제공합니다:

Expert 가중치를 CPU RAM으로 이동 (전체의 약 60-70%)
활성화된 Expert만 VRAM에 로드
KV 캐시도 RAM으로 오프로딩

일반 30B 모델: 전체 VRAM 필요 → 약 20GB+ VRAM
MoE 오프로딩: 66%를 CPU RAM → 약 7-8GB VRAM

이론적 배경

모델 파라미터 구성:

Transformer 레이어: 약 30-40%
FFN(Feed-Forward Network) 레이어: 약 60-70%

MoE 오프로딩은 이 FFN 레이어(Expert)를 CPU RAM으로 이동하여 VRAM 사용량을 획기적으로 줄입니다.

테스트 환경

하드웨어 사양

구분	사양
CPU	AMD Ryzen 5 7500F (6-Core)
RAM	62.46GB
GPU	NVIDIA RTX 4090 16GB
OS	Linux

소프트웨어

구분	버전
LM Studio	0.3.36
테스트 모델	qwen3-coder-30b (30.5B 파라미터, MoE)
비교 모델	hamonize:latest (20.9B 파라미터)

모델 정보

qwen3-coder-30b:

파라미터: 30.5B
아키텍처: MoE (Mixture of Experts)
Quantization: Q4_K_M
파일 크기: 약 18.5GB

LM Studio 설정 방법

1. 모델 로드 전 설정

LM Studio GUI에서 다음 설정을 적용하세요:

  모델 설정
├─ GPU Layers (n_gpu_layers): 20-30
├─ Context Size: 4096
├─ Batch Size: 512
├─ Thread Count: 8
└─ ✅ Offload MoE Experts to CPU/RAM (체크!)
└─ ✅ Offload KV Cache to RAM (체크!)

2. 설정별 설명

설정	권장값	설명
GPU Layers	20-30	VRAM에 로드할 레이어 수. 너무 높으면 OOM
Context Size	4096	문맥 길이. 길수록 VRAM 증가
Batch Size	512	배치 처리 크기. 메모리 사용량 영향
Thread Count	8	CPU 스레드 수. 코어 수에 맞춰 설정
MoE Offloading	✅ 체크	핵심 설정! Expert를 CPU RAM으로
KV Cache Offloading	✅ 체크	KV 캐시를 CPU RAM으로

3. 팁

VRAM이 부족하다면: GPU Layers를 15-20으로 낮추세요
속도가 느리다면: GPU Layers를 30-35로 높이세요 (OOM 주의)
문맥이 길 필요가 없다면: Context Size를 2048로 줄이세요

테스트 결과

✅ 1단계: VRAM 사용량 확인

모델	VRAM 사용량	사용률	상태
gpt-oss-20b (MoE 미적용)	15.2GB	95.5%	⚠️ 거만
qwen3-coder-30b (MoE 적용)	7.8GB	48.3%	✅ 여유 있음

핵심 발견: 30B 모델이 20B 모델보다 더 적은 VRAM을 사용!

✅ 2단계: 추론 테스트

  모델: qwen3-coder-30b
  VRAM 초기: 7874MB (48.3%)
  추론 테스트: "안녕하세요?"

⏱️  소요 시간: 4.21초
  VRAM (추론 후): 7890MB
  VRAM 변화: +16MB (거의 없음!)

중요한 관찰:

추론 시 VRAM 변화가 거의 없음 (+16MB)
활성화된 Expert만 VRAM에 로드되어 추가 할당 불필요
이는 MoE 오프로딩이 정상 작동하고 있다는 강력한 증거

✅ 3단계: 단일 요청 성능

테스트	응답 시간	토큰 수	처리 속도
간단 질문	8.82초	92토큰	10.43 토큰/초
긴 질문	17.71초	311토큰	17.56 토큰/초
평균	13.27초	-	13.99 토큰/초

✅ 4단계: 동시 요청 테스트 (10개)

  LM Studio (qwen3-coder-30b)
├─ 성공: 10/10 (100%)
├─ 총 소요 시간: 32.55초
├─ 평균 응답 시간: 18.64초
└─ 처리량: 29.93 토큰/초

성능 비교

LM Studio vs 원격 Ollama

항목	LM Studio (30B 로컬)	Ollama (20B 원격)	비교
단일 요청 속도	13.99 토큰/초	134.54 토큰/초	Ollama 10x 빠름
동시 요청 처리량	29.93 토큰/초	321.89 토큰/초	Ollama 11x 빠름
응답 시간	8.82-17.71초	1.91-2.82초	Ollama 5-8x 빠름
성공률	100% (10/10)	100% (10/10)	동일
모델 크기	30.5B (더 큼)	20.9B	LM Studio 우수
VRAM 효율	7.8GB	N/A (원격)	LM Studio 탁월
데이터 프라이버시	✅ 완전 로컬	❌ 원격 전송	LM Studio 우수
네트워크 의존	❌ 없음	✅ 필수	LM Studio 우수
확장성	❌ 단일 머신	✅ 수평 확장	Ollama 우수
관리 부담	❌ 직접 관리	✅ 관리 불필요	Ollama 우수

속도 저하 원인 분석

LM Studio가 느린 이유:

CPU/GPU 혼합 연산: Expert가 CPU RAM에 있어 GPU ↔ CPU 데이터 전송 지연
단일 머신 제한: 병렬 처리에 한계
MoE 오버헤드: 활성 Expert를 VRAM으로 로드하는 시간 소요

상용 서비스 관점에서의 평가

❌ LM Studio의 상용 서비스 한계

문제점	현홱	영향
처리 속도	14 토큰/초	사용자 경험 저하 (느린 응답)
동시 처리	30 토큰/초 (10개 요청)	대규모 트래픽 처리 불가
확장성	단일 머신 제한	수평 확장 어려움
관리 부담	서버 유지보수 필요	운영 비용 증가
가용성	단일 장애점(SPOF)	장애 발생 시 서비스 중단
GPU 리소스	전용 GPU 필요	인프라 비용 높음

✅ LM Studio가 적합한 케이스

| 사용 사례 | 예시 | 이유 |
|:---------||:-----|:-----|
| 개발/테스트 | 로컬 개발, 기능 테스트 | 무료, 빠른 세팅 |
| 민감 데이터 | 의료, 금융, 개인정보 | 데이터 유출 방지 |
| 오프라인 환경 | 인터넷 없는 곳 | 네트워크 불필요 |
| 소규모 내부용 | 1-5명 내부 툴 | 비용 절감 |
| PoC/프로토타입 | 초기 검증 | 빠른 시도 |

✅ 원격 Ollama의 상용 서비스 장점

장점	현홱	영향
처리 속도	135 토큰/초	빠른 응답, 좋은 UX
확장성	로드 밸런서 + 다중 서버	수평 확장 용이
관리 부담	서버 관리 불필요	운영 비용 절감
가용성	이미 고가용성 구축됨	안정적인 서비스

결론 및 권장사항

✅ MoE 오프로딩 검증 결과

100% 성공! 30.5B 파라미터 MoE 모델을 7.8GB VRAM으로 구동 가능했습니다.

✅ 입증된 것:
- 30B+ 모델을 16GB 미만 VRAM으로 구동 가능
- KV 캐시 RAM 오프로딩으로 추가 VRAM 절감
- 더 큰 모델도 적은 VRAM으로 구동 가능함이 검증됨

사용 시나리오별 권장사항

상용 서비스 → Ollama 원격 서버

사용자: 100명 이상
일일 요청: 1,000건 이상
응답 시간: 5초 이내
→ Ollama 원격 서버 사용

이유:

10배 빠른 처리 속도
이미 최적화된 인프라
확장성 용이
관리 부담 없음

개발/내부용 → LM Studio 로컬

사용자: 1-10명
일일 요청: 100건 미만
데이터: 민감한 정보 포함
→ LM Studio 로컬 사용

이유:

데이터 프라이버시 보호
오프라인 사용 가능
무료로 대형 모델 구동
빠른 개발/테스트

추천 아키텍처: 하이브리드 접근

┌─────────────────────────────────────────────────────────┐
│                    상용 서비스                          │
│  Ollama 원격 (빠름, 확장성, 관리 불필요)               │
│  - 사용자 facing 기능                                   │
│  - 대규모 트�픽 처리                                   │
│  - 24/7 안정성 요구                                    │
└─────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────┐
│                내부/개발 환경                           │
│  LM Studio 로컬 (프라이버시, 오프라인, 무료)           │
│  - 개발/테스트                                         │
│  - 민감 데이터 처리                                    │
│  - 비상시 백업                                        │
└─────────────────────────────────────────────────────────┘

참고 자료

테스트 스크립트

테스트에 사용한 스크립트는 다음 링크에서 확인 가능합니다:

마무리

LM Studio의 MoE 오프로딩 기능을 통해 VRAM 제약을 극복하고 더 큰 모델을 로컬에서 구동할 수 있음을 확인했습니다. 상용 서비스에는 속도와 확장성 문제로 적합하지 않지만, 개발, 테스트, 민감 데이터 처리 등의 용도로는 훌륭한 선택입니다.

여러분의 환경과 요구사항에 맞게 LM Studio와 Ollama를 적절히 활용하시길 권장합니다!

작성일: 2025년 12월 30일
테스터: AIRUN 팀
환경: RTX 4090 16GB, 62GB RAM, LM Studio 0.3.36

AI로 일관된 웹 UI 디자인 만들기: 디자인 토큰 시스템 구축 가이드

chaeya — Sun, 28 Dec 2025 17:16:46 +0900

AI로 일관된 웹 UI 디자인 만들기: 디자인 토큰 시스템 구축 가이드

AI가 만든 UI, 왜 망가질까?

지난주 AI에게 채팅 페이지 UI를 만들어달라고 했습니다. 처음엔 훌륭했지만, 3일 후엔 5가지 다른 파란색이 코드 여기저기 흩어져 있었습니다. #3b82f6, #2563eb, #1d4ed8... 각각은 예쁘지만, 함께라면 재앙입니다.

이 글에서는 AI가 만든 UI를 일관되게 유지하는 디자인 토큰 시스템을 소개합니다. "예쁘게 만들어줘" 대신 "var(--primary-600)을 써줘"라고 말하는 법을 배워보세요.

문제: AI가 만든 UI의 일관성 재앙

Claude, ChatGPT 같은 AI에게 웹페이지 UI를 만들어달라고 요청하면, 처음에는 멋진 결과물을 얻을 수 있습니다. 하지만 다음과 같은 문제에 부딪히게 됩니다:

흔히 발생하는 문제들

색상 inconsistency
- 페이지마다 다른 파란색 사용 (#3b82f6, #2563eb, #1d4ed8...)
- 하드코딩된 hex 값이 코드 여기저기에 흩어짐
간격 불일치
- padding: 13px, padding: 17px 같은 임의의 값
- 4px 기반 스페이스 시스템 미준수
폰트 혼란
- 같은 제목인데 다른 font-size 사용
- line-height, letter-spacing 불일치
다크모드 깨짐
- 라이트모드에서만 작동하는 색상
- .dark 클래스 미지원

결과: AI가 만든 각 컴포넌트는 개별로는 예쁘지만, 전체적으로는 마치 다른 사람이 만든 것처럼 조잡합니다.

✅ 해결책: "느낌"이 아닌 "키"로 강제하기

해결책은 간단합니다: "예쁜 느낌"으로 설명하지 말고, "정확한 토큰 키"로 강제하세요.

디자인 토큰이란?

디자인 시스템의 모든 값을 이름으로 정의한 것입니다:

/* ❌ 하드코딩 (BAD) */
color: #3b82f6;
padding: 16px;
border-radius: 8px;

/* ✅ 토큰 사용 (GOOD) */
color: var(--primary-600);
padding: var(--space-4);
border-radius: var(--radius-default);

왜 토큰이 효과적인가?

재현성: 동일한 토큰 = 동일한 결과
유지보수: 한 곳에서 변경 = 전체 적용
일관성: 모든 컴포넌트가 같은 언어 사용
다크모드: .dark 클래스에서 자동 변경

1단계: CSS 변수로 디자인 토큰 정의

먼저 globals.css에 모든 디자인 값을 CSS 변수로 정의합니다.

1.1 색상 토큰

:root {
  /* Primary (Blue) */
  --primary-50: #eff6ff;
  --primary-500: #3b82f6;
  --primary-600: #2563eb;
  --primary-700: #1d4ed8;

  /* Semantic Colors */
  --success: var(--success-600);
  --warning: var(--warning-600);
  --error: var(--error-600);
  --info: var(--info-600);

  /* Semantic Mapping */
  --card-bg: #ffffff;
  --card-border: var(--neutral-200);
  --text-primary: var(--neutral-900);
  --text-secondary: var(--neutral-600);
}

1.2 간격 토큰 (4px 기반)

:root {
  --space-1: 4px;
  --space-2: 8px;
  --space-3: 12px;
  --space-4: 16px;
  --space-6: 24px;
  --space-8: 32px;
}

1.3 타이포그래피 토큰 (2025 트렌드)

참고: 2025년 최신 타이포그래피 트렌드에 기반

:root {
  /* Font Family */
  --font-sans: 'Inter', 'Pretendard', sans-serif;
  --font-heading: 'Plus Jakarta Sans', 'Pretendard', sans-serif;
  --font-mono: 'D2Coding', monospace;

  /* Font Size (2025 권장: 16px 기본) */
  --text-xs: 12px;
  --text-sm: 14px;
  --text-base: 16px;  /* 기본 본문 */
  --text-lg: 18px;
  --text-xl: 20px;
  --text-2xl: 24px;

  /* Line Height */
  --leading-normal: 1.5;   /* 영문 */
  --leading-relaxed: 1.6;  /* 한글 */
}

2단계: UI_DESIGN_GUIDE.md 작성

AI가 참고할 수 있는 상세한 디자인 가이드를 작성합니다.

가이드라인에 포함할 내용

Design Tokens - 모든 토큰 키와 용도 설명
Layout Rules - 헤더(56px), 사이드바(280px), 채팅 영역의 고정 크기
Component Specs - 각 컴포넌트의 정확한 스펙
i18n Rules - 한국어/영문 폰트 페어링 (Inter + Pretendard)

핵심 원칙

## AI Implementation Guide

1. **절대 하드코딩된 색상 사용 금지**
   ❌ color: #3b82f6
   ✅ color: var(--primary-500)

2. **모든 간격은 4px 기반**
   ❌ padding: 13px
   ✅ padding: var(--space-3)

3. **Tailwind와 CSS 변수 혼합 주의**
   ❌ className="bg-blue-500" style={{ color: 'var(--primary-500)' }}
   ✅ 둘 중 하나만 사용

3단계: Claude Skills 생성

Claude Code에 재사용 가능한 스킬을 등록합니다.

3.1 UI Theming 스킬

10가지 프리셋 테마를 제공하는 스킬입니다:

# UI Theming

## Available Themes
1. Ocean Depths - Professional maritime blues
2. Sunset Boulevard - Warm sunset gradients
3. Forest Canopy - Natural earth tones
... (10가지 테마)

## Usage
1. Show theme showcase
2. Get user selection
3. Apply theme tokens to components

3.2 Design Philosophy 스킬

디자인 철학 기반 UI 생성 스킬입니다:

# Design Philosophy

## Philosophy Examples
- "Digital Zen": Clean whitespace, minimal color
- "Data Poetry": Information as visual art
- "Organic Tech": Natural forms meet digital precision

️ 4단계: AI 프롬프트 작성 베스트 프랙티스

❌ 나쁜 프롬프트

예쁜 채팅 페이지 만들어줘

✅ 좋은 프롬프트

UI_DESIGN_GUIDE.md의 디자인 토큰을 준수하여 채팅 페이지를 만들어줘.
- 색상: var(--primary-600) 사용
- 간격: var(--space-4) 기반
- 폰트: var(--font-sans) 사용
- 다크모드 지원 필수

5단계: Before & After

Before (하드코딩 시대)

<button style={{
  backgroundColor: '#3b82f6',
  color: '#ffffff',
  padding: '16px',
  borderRadius: '8px'
}}>

문제점:

다른 컴포넌트에서 #2563eb, #1d4ed8 사용
padding: 17px, padding: 13px 혼용
다크모드 미지원

After (디자인 토큰 시스템)

<button style={{
  backgroundColor: 'var(--btn-primary-bg)',
  color: 'var(--btn-primary-fg)',
  padding: 'var(--space-4)',
  borderRadius: 'var(--radius-default)'
}}>

개선점:

✅ 모든 버튼이 동일한 토큰 사용
✅ 다크모드 자동 지원 (.dark 클래스)
✅ 일관된 간격 시스템

6단계: 2025년 타이포그래피 트렌드 적용

용도	폰트	특징
본문 (영문)	Inter	2025년 가장 인기 있는 UI 폰트
본문 (한글)	Pretendard	한글 전용 최적화
제목 (영문)	Plus Jakarta Sans	현대적이고 친근함
코드	D2Coding	개발자 친화적 모노스페이스

2025 베스트 프랙티스

기본 폰트 크기: 16px (2025 표준, 기존 14px에서 상향)
폰트 개수: 최대 2-3개 (제목용, 본문용, 코드용)
줄 간격: 1.5-1.6 (본문), 1.25 (제목)
가독성 최우선: 모든 디바이스에서 명확하게 표시

결론: AI와 협력하는 디자인 시스템

핵심 takeaways

디자인 토큰 = AI의 언어
- AI에게 "예쁜 느낌"이 아니라 "정확한 키"를 제공하세요
구조화된 가이드라인 = 일관성 보장
- UI_DESIGN_GUIDE.md가 AI의 참고 문서가 됩니다
Claude Skills = 재사용 가능한 전문성
- 자주 사용하는 패턴을 스킬로 만들어두세요
2025 트렌드 = 최신 표준 준수
- Inter + Pretendard 폰트 조합
- 16px 기본 폰트 크기
- 가독성 최우선

결과

AI가 만든 UI가 이제:

✅ 일관된 색상과 간격
✅ 다크모드 완벽 지원
✅ 반응형 디자인
✅ 접근성 준수
✅ 유지보수 용이

AI와 함께 일관되고 아름다운 웹을 만들어보세요!

참고 자료

프로젝트 리소스

UI_DESIGN_GUIDE.md - 전체 디자인 가이드
CLAUDE.md - 프로젝트 아키텍처 가이드
globals.css - 디자인 토큰 정의

외부 참고 (2025 트렌드)

Best Fonts for Web Design in 2025 - Shakuro
Typography Trends 2025 - Sunbpo Solutions
Inter Font Pairings - MaxiBestOf
Web Typography Best Practices - Marker.io

지속 가능한 오픈소스 프로젝트를 위한 가장 큰 기여는 후원

chaeya — Thu, 26 Sep 2024 17:55:29 +0900

오픈소스 프로젝트는 우리가 일상적으로 사용하는 소프트웨어의 중요한 기반이지만, 많은 경우 그 프로젝트를 유지하는 관리자들은 무급으로 일하고 있습니다. 그 결과, 여러 오픈소스 프로젝트가 유지되지 않거나 보안 취약점이 발생하기도 합니다. 오픈소스의 지속 가능성을 보장하기 위한 가장 중요한 기여는 바로 "후원"입니다.

오픈소스 프로젝트와 유지 관리자의 현실

오픈소스 프로젝트는 대규모 커뮤니티가 자발적으로 기여하고, 모두가 혜택을 누릴 수 있는 공공재의 성격을 띠고 있습니다. 하지만 많은 유지 관리자는 자금 지원을 받지 못한 채 프로젝트를 운영하고 있습니다. Tidelift 보고서에 따르면, 60% 이상의 오픈소스 유지 관리자들이 무급으로 일하고 있으며, 그로 인해 프로젝트 관리에 필요한 시간과 자원에 제약이 발생합니다(Open Source & More - Blog | Tidelift).

이들은 자발적으로 오픈소스 프로젝트를 운영하고 있지만, 지속 가능성을 보장하기 위해서는 기부와 후원이 필수적입니다. 특히 보안 문제를 해결하거나 소프트웨어의 품질을 높이는 데 있어 자금은 매우 중요한 요소입니다.

후원이 왜 중요한가?

재정적 안정성 제공
유지 관리자들이 무급으로 일하는 한, 프로젝트는 유지 관리자의 여유 시간과 재정 상황에 따라 운영됩니다. 후원은 관리자가 안정적인 환경에서 프로젝트에 더 많은 시간을 투자할 수 있게 하며, 장기적으로 프로젝트가 중단되지 않도록 돕습니다
보안과 품질 개선
오픈소스 프로젝트에서 보안 취약점을 해결하고 새로운 기능을 추가하려면 시간이 많이 소요됩니다. 유급 유지 관리자들은 더 많은 시간을 보안 및 유지 관리 작업에 할애할 수 있으며, 이는 소프트웨어의 안정성을 크게 높입니다. Tidelift 조사에 따르면, 유급 유지 관리자는 보안 문제 해결에 더 많은 시간을 할애하고 프로젝트 품질을 개선하는 경향이 있습니다
커뮤니티의 지원과 동기 부여
기부는 재정적 지원뿐만 아니라 커뮤니티가 프로젝트를 지지하고 있다는 것을 유지 관리자에게 전달하는 중요한 방식입니다. 이는 유지 관리자가 번아웃 없이 장기적으로 프로젝트를 운영하는 데 큰 동기부여가 됩니다.

해결책: 자금 지원과 인식 제고

이 문제를 해결하기 위해서는 몇 가지 실질적인 해결책이 제시될 수 있습니다.

기업의 더 많은 기여 장려: 많은 기업들이 오픈소스 프로젝트를 사용하고 있지만, 실제로 그 프로젝트에 기여하는 비율은 낮습니다. 기업들은 프로젝트에 금전적인 기여나 기술적 지원을 제공함으로써 유지 관리자의 부담을 줄일 수 있습니다. Google, Microsoft와 같은 대기업은 이미 오픈소스 프로젝트에 자금을 지원하거나 기여하는 직원들을 격려하는 정책을 운영하고 있습니다.
개인 및 커뮤니티의 후원: Open Collective와 같은 플랫폼을 통해 프로젝트 유지 관리자는 직접적인 기부를 받을 수 있습니다. 또한, GitHub Sponsors 프로그램을 활용하면, 오픈소스 기여자들이 직접적으로 후원을 받을 수 있습니다. 이와 같은 모델은 프로젝트 유지 관리자들이 금전적인 문제로부터 벗어나 더 나은 품질의 소프트웨어를 제공하는 데 집중할 수 있게 합니다.
- Open Collective
- GitHub Sponsors
프로젝트에 대한 인식 제고: 오픈소스 프로젝트의 가치를 인식하고 그 중요성을 알리는 것도 중요한 해결책입니다. 사용자는 자신이 의존하는 소프트웨어에 대해 더욱 관심을 가지고, 작은 금액이라도 프로젝트를 후원하는 문화가 형성될 필요가 있습니다. 더 많은 사람들이 오픈소스 프로젝트에 참여하고 기여함으로써, 프로젝트 유지 관리자는 정당한 대가를 받을 수 있습니다.

오픈소스 프로젝트에 후원하는 방법

후원은 매우 간단하며, 소액의 후원이라도 프로젝트 유지에 큰 도움이 됩니다. 대부분의 오래된 오픈소스 프로젝트는 사용자들이 쉽게 후원할 수 있도록 안내를 포함하고 있습니다.

예를 들어, LinuxMint 프로젝트의 경우 다음과 같이 쉽게 후원할 수 있습니다.
https://linuxmint.com/sponsors_info.php

하모니카 OS 프로젝트의 경우, 업스트림이 되는 리눅스 민트 프로젝트에 소스코드의 기여 뿐만 아니라, 몇년째 후원을 지속하고 있습니다.

일반적인 오픈소스 프로젝트의 후원 절차는 다음과 같습니다:

후원 페이지 방문.
후원 금액 선택.
결제 정보를 입력하고 완료.

이처럼 간단한 기부 과정을 통해 오픈소스 프로젝트가 지속 가능하게 유지될 수 있습니다.

결론: 지속 가능한 오픈소스를 위한 가장 큰 기여는 후원

오픈소스 프로젝트는 모두가 혜택을 누릴 수 있는 공공재입니다. 하지만 그 뒤에는 무급으로 일하는 유지 관리자들의 노력이 숨어 있습니다. 오픈소스는 단순히 무료로 제공되는 소프트웨어가 아닙니다. 그것은 기술의 미래를 이끌어가는 중요한 요소이며, 이를 유지하는 관리자들의 역할은 필수적입니다.

이들의 노력을 인정하고, 지속 가능한 프로젝트 운영을 위해 후원하는 것은 오픈소스의 미래를 보장하는 가장 큰 기여입니다. 여러분의 소중한 기부가 더 나은 소프트웨어와 보안성을 만들어 나가는데 중요한 역할을 할 수 있습니다. 오픈소스 프로젝트가 계속해서 발전하기 위해서는 더 많은 금전적 지원과 기여가 필요하며 기업과 개인, 커뮤니티 모두가 이 문제에 대한 인식을 높이고, 지속 가능한 생태계를 구축하는 데 동참할 필요가 있습니다.

2024년 오픈소스 현황 보고서

chaeya — Wed, 28 Aug 2024 09:54:12 +0900

최근 발표된 이 보고서는 OpenLogic과 Open Source Initiative(OSI) 간의 협력으로 작성되었으며, 다양한 산업에서 오픈소스 소프트웨어의 사용 및 도입에 대한 통찰을 제공합니다.

https://www.openlogic.com/success/resources/state-of-open-source-report

2024 State of Open Source Report Success Page | OpenLogic by Perforce

Want More Insights and Analysis? In this on-demand webinar, experts from Perforce Software, the Open Source Initiative, and the Eclipse Foundation discuss key findings from the 2024 State of Open Source report, highlighting the most actionable findings for

www.openlogic.com

오픈소스 소프트웨어(OSS)를 채택하는 주요 이유

2024년 오픈소스 현황 보고서의 "오픈소스를 왜 사용하는가" 페이지에서는 오픈소스 소프트웨어(OSS)를 채택하는 주요 이유로 비용 절감이 가장 큰 요인으로 나타났습니다. 응답자의 37%가 라이선스 비용이 없고 전반적인 비용 절감이 주요 동기라고 답했으며, 특히 정부 및 공공 서비스 분야에서 이 비율이 51%로 가장 높았습니다. 이는 전 세계적인 경제 상황이 악화됨에 따라 비용 절감이 더욱 중요한 요인으로 작용한 결과로 보입니다.

그 외에도 응답자들은 개발 속도 향상, 안정적인 기술 및 커뮤니티의 장기 지원, 최신 기술에 대한 접근성, 벤더 종속성 감소, 오픈 표준 및 상호 운용성 등을 오픈소스를 사용하는 주요 이유로 꼽았습니다. 각 지역별로도 이러한 이유들의 중요도가 다르게 나타나고 있습니다. 예를 들어, 북미, 유럽, 영국에서는 비용 절감이 더 큰 요인으로 작용하는 반면, 다른 지역에서는 최신 기술 접근성과 같은 요소가 더 중요한 동기로 나타났습니다.

가장 많이 사용하는 배포판

2023년에 발생한 리눅스 생태계의 변화, 특히 Red Hat의 RHEL 코드 접근 제한과 CentOS 7의 지원 종료가 다가오면서 Ubuntu의 사용이 증가했습니다. 조사에 따르면 응답자의 46%가 Ubuntu를 사용하고 있으며, 이는 작년의 26%에서 크게 증가한 수치입니다. CentOS를 사용하는 응답자는 22%로, 이는 Debian보다 1% 낮아 세 번째로 많이 사용되는 배포판입니다. 특히 기술 업계에서는 28%가 여전히 CentOS를 사용하고 있으며, 이들은 많은 수의 CentOS 배포를 관리하는 기업들일 가능성이 큽니다. 2024년 6월 30일 이후로 CentOS 7에 대한 커뮤니티 지원이 종료되기 때문에, CentOS 사용자들은 빠른 전환이 필요할 것입니다.

CentOS의 공백을 메울 배포판으로는 Rocky Linux와 AlmaLinux가 소폭 성장했으며, Amazon Linux의 사용도 6% 증가했습니다. CentOS Stream의 사용률은 10% 이하로 떨어졌으며, AlmaLinux는 차량 및 물류 업계에서, Rocky Linux는 헬스케어 및 제약 산업에서 인기를 끌고 있습니다. 아직 "리눅스 전쟁"에서 승자를 결정하기에는 이르지만, 각 배포판의 향후 성장이 주목됩니다.

오픈소스 보안 도구

오픈소스 보안 도구에 대한 페이지에서는 이러한 도구들이 취약점 스캔, 방화벽 보안, SBOM(소프트웨어 빌딩 자료) 생성 등 다양한 기능을 수행하며, 소프트웨어 개발 단계뿐만 아니라 네트워킹과 운영에서도 점점 더 중요해지고 있음을 강조합니다.

이번 설문조사에서 처음으로 이러한 기술에 대해 질문했을 때, 27%의 응답자가 자사에서 어떤 오픈소스 보안 도구를 사용하는지 "모른다"고 답한 것이 주목할 만합니다. 이는 일부 조직이 오픈소스 대안에 대한 인식 부족으로 인해 상용 소프트웨어를 사용하고 있거나, 오픈소스 보안 도구 사용에 주저하고 있을 가능성을 시사합니다. 이러한 질문이 응답자들의 호기심을 자극하여 더 많은 오픈소스 보안 도구를 탐색하게 되기를 기대하고 있습니다.

오픈소스 성숙도 및 관리

"오픈소스 성숙도 및 관리" 페이지에서는 조직의 오픈소스 참여와 투자 성숙도를 평가하고 있습니다. 이 섹션에서는 오픈소스 소프트웨어의 소비자이자 사용자로서 조직이 어떤 방식으로 오픈소스에 참여하고 있는지를 분석합니다.  주요 내용은 다음과 같습니다:

1. **보안 스캔과 정책**: 가장 일반적인 활동으로, 조직들은 오픈소스 패키지에서 취약점을 식별하기 위해 보안 스캔을 수행하며, 보안 정책 또는 컴플라이언스를 유지하는데 중점을 두고 있습니다. 이는 모든 조직 규모에서 중요한 요소로 강조되었습니다.

2. **오픈소스 프로젝트 기여**: 많은 조직이 오픈소스 프로젝트에 기여하거나 오픈소스 조직을 후원하고 있지만, 특히 중소기업이나 스타트업에서 이 활동이 활발한 것으로 나타났습니다.

3. **오픈소스 법적 지원**: 대기업의 28%가 오픈소스 라이선스에 익숙한 법률팀을 보유하고 있지만, 이는 필수적인 성숙도 요소로는 볼 수 없습니다.

4. **내부 오픈소스 프로젝트(Innersource)와 OSPO**: 스타트업들이 중대형 기업들보다 더 많은 내부 오픈소스 프로젝트(Innersource)와 오픈소스 프로그램 사무소(OSPO)를 운영하고 있다는 점이 흥미롭게 나타났습니다.

결론적으로, 오픈소스 성숙도는 조직의 규모보다는 오픈소스 사용과 투자에 대한 전략과 우선순위에 따라 더 많이 결정된다는 점이 강조됩니다.

또한, 오픈소스 비영리 단체 후원 측면에서는 Linux Foundation, Apache Software Foundation, Open Source Initiative(OSI), Eclipse Foundation이 가장 많이 지원받는 단체들로 나타났습니다.

보고서 전체 내용

출처 : https://view.flipdocs.com/state-of-open-source

2024 State of Open Source Report

view.flipdocs.com

이 보고서의 전체 내용에 대한 요약은 다음과 같습니다.

1. **오픈소스 소프트웨어 사용 증가**: 보고서에 따르면 응답자의 95%가 지난 1년 동안 오픈소스 소프트웨어(OSS) 사용을 유지하거나 증가시켰으며, 특히 대기업과 아프리카, 아시아, 라틴 아메리카 지역에서 사용 증가가 두드러졌습니다.

2. **오픈소스 채택 이유**: 비용 절감(특히 라이선스 비용 없음)이 오픈소스 소프트웨어 채택의 주요 이유로 나타났습니다. 이는 특히 정부나 공공 서비스 분야에서 강하게 나타났으며, 경제적 압박이 증가하면서 비용 절감이 더 중요해졌습니다.

3. **투자 분야**: 데이터베이스와 데이터 기술이 가장 많이 투자된 분야로 나타났으며, 클라우드와 컨테이너 기술이 그 뒤를 이었습니다. 데이터가 디지털 경제에서 중요한 역할을 하기 때문에 이와 관련된 기술에 대한 투자가 증가하고 있습니다.

4. **지원 도전 과제**: 보안 정책 유지 및 컴플라이언스, 오픈소스 소프트웨어의 수명 종료 버전 관리, 고급 기술 지원 부족 등이 주요 도전 과제로 지적되었습니다.

5. **오픈소스 리눅스 배포판**: Ubuntu가 가장 많이 사용되는 배포판으로 나타났으며, CentOS는 여전히 많은 조직에서 사용되고 있지만, CentOS 7의 지원 종료로 인해 향후 전환이 필요할 것으로 보입니다.

6. **클라우드 네이티브 오픈소스 기술**: Docker와 Kubernetes의 사용이 크게 증가했으며, 특히 유럽과 북미에서 클라우드 네이티브 기술로의 전환이 활발히 이루어지고 있습니다.

7. **프로그래밍 언어 및 런타임**: Python이 JavaScript를 제치고 가장 많이 사용되는 프로그래밍 언어로 부상했습니다.

8. **오픈소스 성숙도 및 관리**: 많은 조직이 오픈소스 보안을 강화하고 있으며, 보안 스캔 및 컴플라이언스 정책을 도입하고 있습니다. 하지만, 오픈소스 프로젝트에 대한 기여나 전문 인력 보유는 상대적으로 부족한 것으로 나타났습니다.

오픈소스 소프트웨어는 전 세계적으로 계속해서 중요성이 증가하고 있으며, 다양한 산업과 지역에서 그 활용도가 확산되고 있습니다.

리눅스 커널 패키지는 어떤 용도일까요?

chaeya — Wed, 21 Aug 2024 16:26:33 +0900

오늘 커뮤니티에 올라온 질문입니다.

안녕하세요

커널 설치를 하다가 궁금한게 있어 질문드립니다

새로 설치한 커널은 6.8.0-40-generic 인데요.

리눅스 민트 업데이트 매니저의 커널설치 기능으로 하니까 별탈없이 잘 되긴 하는데..

설치한 커널의 동일버전 바이너리 파일들을 검색해보니 아래와 같은것들도 있습니다.

linux-buildinfo-6.8.0-40-generic

linux-cloud-tools-6.8.0-40-generic

linux-image-uc-6.8.0-40-generic

linux-image-unsigned-6.8.0-40-generic

linux-modules-nvidia-470-6.8.0-40-generic

파일 이름에 cloud, unsigned, nvidia.. 하는 식으로 뭔가 다르다는 느낌을 주고, 위 파일 말고도 상당히 많이 있던데, 어떤 용도로 설치하는 커널인가요?

리눅스 커널 패키지의 종류

리눅스 커널을 설치하다보면 이런 궁금증이 생길 수 있는데, 이 커널 패키지들은 다음과 같은 용도로 제공되고 있습니다.

- Generic 커널: 범용적이고 광범위한 하드웨어 호환성을 제공하는 기본 커널.

- Lowlatency 커널: 실시간 응답이 중요한 환경에 최적화.

- RT 커널: 실시간 처리 보장이 필요한 임베디드 및 산업 환경에 사용.

- HWE 커널: 최신 하드웨어 지원이 필요한 경우 사용하는 커널.

- Xen 커널: Xen 하이퍼바이저 가상화 환경에 최적화.

- Edge 커널: 최신 기술을 실험적으로 도입한 커널.

- Virtual 커널: 가상화 환경에 최적화된 경량 커널.

- AWS/Azure 커널: 특정 클라우드 플랫폼에서 최적화된 커널.

- Cloud 커널: 클라우드 환경에 최적화된 경량 커널

- Unsigned 커널: 서명되지 않은 커널로 Secure Boot 없이 사용.

- Nvidia 커널: Nvidia GPU와의 호환성을 강화한 커널.

그 외 게임을 하는데 더 최적화된 커널이라던지, 특정한 성능을 더 최적화 한 다음과 같은 커널들도 있습니다.

1. Liquorix 커널

용도: Liquorix는 특히 데스크탑 성능, 게임, 오디오/비디오 작업을 위한 최적화된 커널로, 고성능 사용자와 개발자를 위한 것입니다.
특징: 더 낮은 레이턴시(지연시간)와 향상된 스케줄링을 제공하며, 일반적인 작업에서 더 부드러운 성능을 보여줍니다. 주로 BFS(Brain Fuck Scheduler)와 같은 대체 스케줄러를 사용하여 CPU의 성능을 향상시키는 방향으로 최적화되어 있습니다.

https://liquorix.net/

2. Zen 커널

용도: Zen 커널은 성능을 최대화하고 사용자 경험을 개선하는 데 중점을 둔 커널입니다. 주로 데스크탑 환경에서의 반응성을 높이는 데 집중합니다.
특징: Zen 커널은 주로 더 높은 인터랙티브 성능을 위해 스케줄링 및 메모리 관리 기능을 개선했습니다. Liquorix 커널과 유사하게 데스크탑 환경에서 더 낮은 레이턴시와 빠른 응답성을 제공합니다.

https://github.com/zen-kernel/zen-kernel

3. TuxOnIce 커널

용도: TuxOnIce는 리눅스 커널에 하이버네이션 기능을 개선하는 패치를 추가한 커널입니다. 특히 랩톱과 같은 휴대용 장치에서 하이버네이션 기능을 더 빠르고 안정적으로 사용하기 위한 용도로 만들어졌습니다.
특징: 일반 커널의 하이버네이션 기능을 개선하여, 더 큰 메모리 이미지 처리와 더 빠른 복원 시간을 제공합니다. 이는 랩톱 사용자가 시스템을 하이버네이트 및 복원할 때 성능을 크게 개선시킵니다.

https://tuxonice.net/

4. Clear Linux 커널

용도: Intel에서 제공하는 Clear Linux OS는 성능 최적화에 중점을 두고 있으며, 이와 함께 Clear Linux 커널은 최신 Intel 하드웨어에서 최상의 성능을 제공하도록 특별히 최적화되어 있습니다.
특징: Intel의 CPU 아키텍처에 맞춘 최적화가 이루어져 있으며, 빠른 부팅 시간과 효율적인 에너지 관리 등을 제공합니다.

https://clearlinux.org/

ubuntu 24.04 autoinstall.yml

chaeya — Wed, 21 Aug 2024 16:07:08 +0900

Ubuntu 24.04에서는 서버나 데스크탑 배포 시, 수작업을 최소화하고, 반복적인 설치 작업을 자동화할 수 있는 Autoinstall 기능을 제공합니다. 이 글에서는 autoinstall.yml 파일을 활용하여 Ubuntu 24.04를 자동 설치하는 방법을 소개하겠습니다.

Autoinstall ?

Ubuntu의 Autoinstall는 Ubuntu 서버나 클라우드 이미지를 설정할 때 사용하는 무인 설치(자동 설치) 방법입니다. 사용자가 정의한 설정 파일(autoinstall.yml)에 따라 설치 과정이 자동으로 이루어집니다. 이 방법을 사용하면 여러 대의 시스템을 손쉽게 동일한 설정으로 설치할 수 있습니다.

Autoinstall 파일 (autoinstall.yml) 준비

# autoinstall.yml example based on the preseed content

version: 1

# Locale and keyboard configuration
locale: ko_KR.UTF-8
keyboard:
  layout: kr
  variant: kr104

# Timezone configuration
timezone: Asia/Seoul

# Identity configuration
identity:
  hostname: ubuntu
  username: user
  password: # "openssl passwd -6 비밀번호" 명령으로 비밀번호 생성해서 입력

# Storage layout
storage:
  layout:
    name: direct  # Use direct layout, change this if needed

# Packages to be installed
packages:
  - htop
  - openssh-server
  - gparted

# Updates and upgrades
updates:
  policy: unattended-upgrades

# SSH configuration
ssh:
  install-server: true
  allow-pw: true

# Early command to unmount
early-commands:
  - umount -l -r -f /isodevice

# User-data or any additional scripts can be added here

웹서버로 파일 접근 가능하게 설정

이제 설정한 파일을 사용중인 홈 경로에 저장하고, 터미널을 이용해서 파일이 있는 경로로 이동 후 다음과 같이 8000 번 포트로 파일을 가져갈 수 있게 준비합니다.

cd ~/
python3 -m http.server 8000

sudo ufw allow 8000/tcp

이제 이 파일은 http://자신의 IP:8000/autoinstall.yml 주소로 가져갈 수 있습니다.

Ubuntu 설치

설치를 진행하고 아래 화면에서 다음과 같이 자동설치를 선택후 http://자신의 IP:8000/autoinstall.yml 를 입력합니다.

automatic.yml

이 방법을 사용하면 autoinstall.yml 파일을 로컬 네트워크에서 웹 서버로 제공하여 Ubuntu 24.04를 자동으로 설치할 수 있습니다. 이 방식은 여러 대의 서버를 효율적으로 관리하고 설치하는 데 매우 유용하며, Python의 간단한 웹 서버 기능을 활용하므로 설정이 매우 쉽습니다.

오픈소스 세계의 짠한 현실

chaeya — Tue, 19 Dec 2023 22:21:53 +0900

오늘 proxmox 구축을 하다가 헤놀로지 부트로더 개발자의 깃허브 저장소가 없어진것을 확인했습니다.

개발자가 저장소를 더 이상 제공하지 않기로 결정했다는데 자세한 내용은 아래 링크에 참고하실 수 있습니다.

https://www.2cpu.co.kr/nas/44055

이 글을 읽으면서 저도 오픈소스를 개발하고 배포하는 입장에서 여러가지 생각이 들어서 생각을 정리해봅니다.

Heartbleed 보안 취약점 사건에 대해서 들어보셨나요?

이 사태는 2014년에 발생한 중요한 보안 취약점 사건입니다. OpenSSL 소프트웨어에서 발견된 이 취약점은 암호화된 통신 중에 사용자 데이터를 노출시킬 수 있는 위험이 있었습니다. 카드결제, SSL인증서 등에 사용되는 필수 라이브러리이기 때문에 이 사건은 많은 웹 사이트와 서버에 영향을 미쳤으며, 사용자 정보가 유출될 수 있는 위험을 야기했습니다.

이 개발팀의 내부를 들여다보면 얼마나 오픈소스 개발자들이 힘들게 희생하는지 알 수 있습니다.

이 사고 이전까지 OpenSSL은 일년에 2,000달러(약 260만원)으로 유지되고 있다가, 문제가 생긴후 지금은 9,000달러(약 1100만원)의 기부금으로 운영되고 있습니다. OpenSSL 개발팀은 프로젝트 유지에 상시 개발자 6명 정도가 필요하지만, 프로젝트 지속할 비용을 충당하기 위해 다른 개발 계약을 계속하고 있다고 합니다.

아래 글에서는 오픈소스 개발자들이 자신의 소프트웨어가 수익성 있는 상업 제품에 사용되는 동안에도 아무런 보상없이 무료로 일하는 어려움을 다루고 있으니 한번 읽어보세요.

https://techcrunch.com/2022/01/18/open-source-developers-who-work-for-free-are-discovering-they-have-power/

또 다른 예로 curl 명령을 자주 사용하실텐데, 이 명령어가 25년 동안 다니엘 스타인버그라는 개발자 한명에 의해 무료로 유지되고 있는것을 아시나요? 만약 cURL처럼 수백만 대의 기기에 라이브러리로 사용되는 프로젝트들이, 만약 개발자가 지원하는 것에 스트레스를 받아서 배포를 중단하기로 결정한다면 어떻게 될까요?

많은 사용자들과 기업들은 오픈소스를 자신의 제품이나 서비스에 많이 사용하지만, 오픈소스 소프트웨어가 무료로 제공되는 노력과 그 뒤에 있는 개발자들의 기여를 간과합니다.

또한, 오픈소스 프로젝트는 종종 소수의 개발자들에 의해 유지되지만, 이들의 노력은 상업적인 가치와 비교할 때 충분히 인정받지 못합니다.

오픈소스 공동체의 지속 가능성을 위해서는 오픈소스 사용자들이 이러한 개발자들에 대한 적절한 인정과 지원이 필요합니다.

오픈소스 사용자는 공동체를 지속가능하게 하기 위해서 오픈소스 프로젝트에 대한 책임감 있는 태도를 가져야 합니다.

책임감 있는 태도란 특정 프로젝트를 사용하고 있다면 프로젝트에 대한 적극적인 참여, 버그 리포트 및 피드백 제공, 커뮤니티 활동 참여, 후원 등을 포함합니다.

개발자들의 노력을 존중하고, 그들의 작업에 대한 가치를 인식함으로써, 오픈소스 생태계의 건강과 지속 가능성을 지원하는 것이 중요합니다.

이러한 상호 존중과 협력은 오픈소스 커뮤니티의 성장과 발전에 필수적이라고 생각합니다.

결국 오픈소스 세계에서는 서로 돕고 존중하며 모두가 '함께' 즐길때 오픈소스 커뮤니티가 진정으로 번창할 수 있으니까요!

Subsai 동영상 자막 자동 생성

chaeya — Fri, 18 Aug 2023 13:40:30 +0900

Subsai

유튜브 동영상에 자막을 입히는 일은 많은 노력을 필요로 하는 일입니다. 하지만 자막은 다양한 언어의 관객을 대상으로 콘텐츠를 보다 친근하게 만들 수 있기 때문에 가능하다면 추가하는 것이 좋죠. Subsai는 동영상 자막을 자동으로 생성하는 혁신적인 오픈 소스 프로젝트로 인공지능을 이용한 자막 생성 프로그램입니다.

https://github.com/abdeladim-s/subsai

기능 및 이점

자동 자막 생성: Subsai는 오디오에서 텍스트로의 변환을 통해 자동으로 자막을 생성합니다.
다양한 언어 지원: 여러 언어의 자막 생성이 가능하여 글로벌 시장을 대상으로 활용할 수 있습니다.
사용자 친화적: 간편한 설치 및 사용법으로 사용자가 쉽게 접근할 수 있습니다.

사용 방법

자신의 PC에 직접 설치해서 사용하거나 Docker 를 이용하여 쉽게 구동할 수 있습니다.

1. 도커가 설치되어 있는지 확인합니다.
2. 리포지토리에 복제하고 CD로 복사합니다.
3. docker compose build
4. docker compose run -p 8501:8501 -v /path/to/your/media_files/folder:/media_files subsai-webui
5. 마운트된 media_files 폴더를 통해 미디어 파일에 액세스할 수 있습니다.

Subsai는 동영상 자막 생성의 새로운 방향을 제시하며, 콘텐츠 제작자들에게 유용한 도구로 자리 잡을 것으로 보입니다.
오픈 소스로 제공되기 때문에 개발자 커뮤니티와 함께 성장할 가능성이 크며, 계속해서 주목해 볼 만한 프로젝트입니다.

오픈AI의 wisper 를 이용하는 방식으로 리눅스, 윈도우, 맥에서 동작하고 모든 소스코드를 제공하기 때문에 CLI 또는 파이썬 패키지를 이용하여 자신만의 어플리케이션을 개발할 때 사용할 수 도 있고, 테스트 한 결과 한국어 자막 자동생성도 지원됩니다.

디스코드에서 Midjourney Bot 사용하기

chaeya — Wed, 2 Aug 2023 12:54:58 +0900

오늘은 디스코드에서 Midjourney Bot을 사용하는 방법을 알아보겠습니다.

Midjourney 란 무엇인가요?

Midjourney는 텍스트 기반의 프롬프트를 기반으로 복잡하고 상세한 이미지를 생성하는 AI 기반의 서비스입니다. 이 서비스는 기계 학습 모델을 사용하여 사용자가 입력한 텍스트의 시각적 표현을 만들어냅니다.

Midjourney와 다른 Text-to-Image 엔진의 차이점

Midjourney는 다른 텍스트-이미지 생성 엔진들과 비교하여 몇 가지 주요한 차이점을 가지고 있습니다:

Midjourney는 매우 상세한 이미지를 생성할 수 있는 능력이 탁월합니다. 복잡한 씬이나 특정 객체를 설명하는 텍스트를 입력하면, Midjourney는 그에 맞는 정교한 이미지를 만들어냅니다.
Midjourney는 텍스트의 뉘앙스를 잡아내는 데 탁월합니다. 같은 텍스트 프롬프트를 사용하더라도, 프롬프트 내의 작은 변경사항에 따라 다른 결과를 만들어냅니다.
Midjourney는 디스코드와 같은 플랫폼에 통합되어 있어, 사용자들이 쉽게 사용하고 공유할 수 있게 해줍니다.

디스코드에서 Midjourney Bot 사용하기: 단계별 가이드

다음은 디스코드에서 Midjourney Bot를 사용하는 방법에 대한 단계별 가이드입니다.

Step 1: 먼저, 디스코드에 로그인합니다. 디스코드 계정이 없다면 먼저 계정을 생성해야 합니다.

Step 2: Midjourney Bot의 공식 웹사이트를 방문하여 '디스코드에 추가하기' 버튼을 클릭합니다.

Step 3: 디스코드 서버를 선택하고, Midjourney Bot이 필요로 하는 권한을 확인한 후에 '권한 부여'를 클릭하여 Bot을 서버에 추가합니다.

Step 3: 디스코드 서버에서 Midjourney Bot을 활성화합니다. 이를 위해 서버에서 '/midjourney start'라고 입력하면 됩니다.

Step 4: Midjourney 서비스를 사용하려면 구독을 해야 합니다. '/midjourney subscribe'를 입력하면 구독 페이지로 연결됩니다. 해당 페이지에서 결제 정보를 입력하고 구독을 완료하세요.

Step 5: 이제 텍스트 프롬프트를 입력하면 됩니다. '/imagine prompt: [프롬프트]'를 입력하면 이미지를 생성하게 됩니다.

예를 들어, "/imagine prompt: 노을 지는 바다 위에 떠 있는 작은 섬" 이라고 입력하면, 이 설명에 기반한 이미지가 생성됩니다.

Step 6: 생성된 이미지를 저장하고 싶다면, 디스코드에서 이미지를 우클릭하고 '이미지 저장' 옵션을 선택하면 됩니다.

이렇게, Midjourney를 사용하여 디스코드에서 텍스트 프롬프트를 통해 고도로 복잡하고 상세한 이미지를 생성하고, 그 결과를 저장하는 방법에 대한 가이드를 마무리합니다. 이제, '/imagine prompt:' 명령어를 사용하여 자신만의 독특한 시각적 표현을 만들어 보세요!

프롬프트 예시:

"/imagine prompt: 화산이 폭발하는 모습"

"/imagine prompt: 사막에 있는 외딴 오아시스"

"/imagine prompt: 어린 왕자가 달에서 바라보는 지구"

"/imagine prompt: 야생에서 놀고 있는 아프리카 사자 가족"

"/imagine prompt: 도시 위로 떠오르는 풀 달 아래의 풍경"

참고 링크들:

Midjourney 공식 웹사이트
Midjourney를 이용한 예시 작업들
Midjourney에 대한 자주 묻는 질문
Midjourney 디스코드 서버 가이드
미드저니 사용법 총정리 : https://edmblackbox.tistory.com/901
미드저니 개인서버 만들기 : https://www.nanumpress.com/ai%EC%A0%95%EB%B3%B4/midjourney/%EB%AF%B8%EB%93%9C%EC%A0%80%EB%8B%88-%EA%B0%9C%EC%9D%B8-%EC%84%9C%EB%B2%84-%EB%A7%8C%EB%93%A4%EA%B8%B0/#:~:text=%EB%B2%84%ED%8A%BC%EC%9D%84,%EB%B4%87%20%EC%B4%88%EB%8C%80%EA%B0%80%20%EC%99%84%EB%A3%8C%EB%90%A9%EB%8B%88%EB%8B%A4.
Prompt 생성기 : https://prompt.noonshot.com/

GPT for Sheets로 구글 문서도구 활용하기

chaeya — Wed, 2 Aug 2023 12:16:47 +0900

오늘은 엑셀을 넘어서, 구글 문서도구의 Google Sheets를 더욱 효율적으로 활용하는 방법을 소개하려고 합니다. 이를 위해 사용할 도구는 바로 https://gptforwork.com/에서 제공하는 GPT for Sheets입니다.

전통적으로 엑셀이나 구글 시트에서 복잡한 데이터를 처리하려면 복잡한 수식이나 코드를 작성해야 했습니다. 하지만 이제 GPT for Sheets를 이용하면, 직관적인 자연어 질문을 통해 데이터를 처리하고 분석할 수 있습니다. 예를 들어, '이 달의 매출 합계는 얼마인가요?'라는 질문을 시트에 입력하면 GPT for Sheets가 이를 처리하고 답변을 제공합니다. 이처럼 자연어 질문을 이용하면 복잡한 수식을 사용하지 않고도 원하는 데이터 분석을 쉽게 수행할 수 있습니다.

이제 GPT for Sheets를 통해 구글 문서도구를 어떻게 활용하는지 알아보겠습니다.

1단계: GPT for Sheets 설치

먼저, Google Sheets에 GPT for Sheets를 추가해야 합니다. 이를 위해, Google Sheets를 열고 상단 메뉴에서 "확장 프로그램" > "확장 프로그램 추가"로 이동합니다. 검색창에 "GPT for Sheets"를 입력하고 "설치"를 클릭하면 확장 프로그램이 설치됩니다.

2단계: OpenAI API 키 설정

다음으로, OpenAI 웹사이트 (https://openai.com)에서 개인 API 키를 받아야 합니다. "API Keys" 섹션에서 새 키를 생성할 수 있습니다. API 키를 받은 후, Google Sheets에서 "확장 프로그램" > "GPT for Sheets" > "설정"으로 이동하여 OpenAI API 키를 입력합니다. API 키를 입력한 후에는 "저장"을 클릭하여 설정을 완료합니다.

3단계: 확장 프로그램 활성화

이제 설치된 GPT for Sheets 확장 프로그램을 활성화해야 합니다. Google Sheets에서 열려진 문서에서 상단 메뉴의 "확장 프로그램" > "GPT for Sheets" > "시작하기"를 선택하면 활성화가 됩니다.

4단계: GPT for Sheets 사용

GPT for Sheets를 활성화하면, 셀에 데이터를 입력하거나 셀에 질문을 통해 대답을 받을 수 있게 됩니다.

데이터 분석: 예를 들어, A1부터 A10까지 셀에 판매 데이터가 있고, B1 셀에 "A1:A10의 평균은 무엇인가요?"라는 질문을 작성하면, GPT for Sheets가 자동으로 계산하여 답변을 제공합니다.

자연어 질문: 또한, "A1:A10의 가장 큰 값은 무엇인가요?" 또는 "A1:A10에서 가장 작은 값은 무엇인가요?"와 같은 질문에 대해서도 GPT for Sheets는 대답을 제공합니다.

5단계: 고급 기능 사용

GPT for Sheets는 데이터 분석과 자연어 처리뿐만 아니라, 각 셀의 데이터를 기반으로 한 예측도 제공합니다. 예를 들어, 과거의 판매 데이터를 바탕으로 미래의 판매 예측을 요청할 수 있습니다. 이는 "A1:A10의 판매 트렌드를 바탕으로 다음 주의 판매량을 예측해주세요."와 같은 질문을 작성함으로써 가능합니다.

추가로, 실제 사용 예제와 더 자세한 설명을 원하신다면 아래의 링크를 확인해주세요.

GPT for Sheets 데모 영상: https://gptforwork.com/help/gpt-for-sheets/about
GPT for Sheets 사용 예제: https://docs.google.com/spreadsheets/d/1iXJk3KDBIbHu-VAb0E5PN7684KEa3pxk_r9DuM-pgcU/template/preview

GPT for Sheets는 구글 문서도구에서 데이터를 분석하고, 이해하며, 예측하는데 강력한 도구로 업무 생산성을 향상시키기 위해 활용할 수 있는 좋은 방법입니다.

ChatGPT를 이용하여 Mermaid로 시퀀스 다이어그램 만들기

chaeya — Wed, 2 Aug 2023 11:53:31 +0900

오늘은 OpenAI의 ChatGPT와 Mermaid를 사용하여 간단하고 명확한 시퀀스 다이어그램을 만드는 방법을 다룰 것입니다. 이것은 복잡한 시스템이나 프로세스를 설명하는 데 매우 유용하며, 서로 간의 통신을 효과적으로 시각화하는 데 도움이 됩니다.

다이어그램 예시

1단계: 시나리오 설계

첫 번째 단계는 시나리오를 설계하는 것입니다. 예를 들어, 온라인 쇼핑 웹사이트에서 상품을 구매하는 시나리오를 가정해 보겠습니다. 시나리오는 다음과 같습니다:

사용자가 상품을 선택합니다.
사용자가 장바구니에 상품을 추가합니다.
사용자가 체크아웃을 합니다.
결제 시스템이 사용자의 결제를 처리합니다.
결제가 완료되면, 시스템은 사용자에게 결제 완료 메시지를 보냅니다.

2단계: ChatGPT를 사용하여 시퀀스 다이어그램 작성

이제 시나리오가 준비되었으므로, ChatGPT에 다음과 같은 지시를 내립니다: "위에 설명된 시나리오를 기반으로 한 시퀀스 다이어그램을 만들어주세요."

ChatGPT의 응답:

sequenceDiagram
    participant User
    participant System
    participant Payment

    User->>System: Selects product
    System->>User: Confirms product selection
    User->>System: Adds product to cart
    System->>User: Confirms product added to cart
    User->>System: Checkout
    System->>Payment: Process payment
    Payment-->>System: Payment confirmation
    System->>User: Sends payment confirmation message

3단계: Mermaid에 시퀀스 다이어그램 입력

이제 Mermaid를 사용하여 다이어그램을 그릴 준비가 되었습니다. Mermaid Live Editor에 위에서 얻은 코드를 붙여넣습니다. 그러면 시퀀스 다이어그램이 실시간으로 그려집니다.

저는 구글 문서도구에 확장기능을 설치해서 아래와 같은 다이어그램을 작성했습니다.

4단계: 다이어그램 확인 및 저장

마지막으로, 다이어그램이 정확하게 표현되었는지 확인하고, 필요한 경우 수정합니다. 만족하면, 다이어그램을 이미지나 PDF 형식으로 내보낼 수 있습니다.

그러면 완성된 다이어그램은 시나리오의 각 단계를 명확하게 보여주며, 사용자, 시스템, 결제 처리 시스템 간의 상호작용을 시각화합니다.

이 방법은 복잡한 프로세스를 이해하고 문서화하는 데 매우 유용합니다. ChatGPT는 효과적인 시퀀스 다이어그램을 작성하는 데 필요한 논리와 순서를 제공하며, Mermaid는 이러한 정보를 빠르게 시각화합니다. 이 두 가지 도구를 함께 사용하면, 시스템의 행동을 빠르고 쉽게 표현할 수 있습니다.

결론

이렇게, ChatGPT와 Mermaid를 이용해 빠르고 효과적인 시퀀스 다이어그램을 만들 수 있습니다. 이는 소프트웨어 개발, 시스템 설계 및 문서화 작업에 많은 도움이 될 것입니다. 이 두 가지 도구의 강력한 조합을 활용하여 여러분의 작업을 쉽게 만들어보세요!

참고 : https://mermaid.js.org/intro/

Could not get lock /var/lib/dpkg/lock Error

chaeya — Wed, 12 Jul 2023 13:28:03 +0900

E: Could not get lock /var/lib/dpkg/lock - 잠금 파일을 얻을 수 없습니다 - open (11: Resource temporarily unavailable)
E: Unable to lock the administration directory (/var/lib/dpkg/), is another process using it?

apt update 또는 apt install 을 할 때 나타나는 오류 메세지로 이전의 작업 내용으로 잠금 파일이 있는 경우 패키지의 인덱스를 갱신하지 못해서 생기는 오류입니다. 클라우드 가상머신에 접속했을때 인스턴스 이미지의 템플릿에서 종종 나타납니다.

해결 방법

1) 어떤 프로세스가 잠금파일을 생성하고 있는지 확인합니다.

lsof /var/lib/dpkg/lock

lsof 명령어는 프로세스가 사용중인 파일을 표시하는 명령어로 특정 네트워크 포트를 사용하는 프로세스도 확인할 수 있습니다.

lsof [ 옵션 [ : 포트번호 | 서비스 ]] [ 파일 | 프로세스 ]

lsof 로 특정 네트워크 포트를 사용하는 프로세스 확인

2) 잠금파일을 생성하고 있는 프로세스 제거

kill PID
#wait
kill -9 PID

3) 잠금파일 제거

sudo rm /var/lib/dpkg/lock
sudo rm /var/cache/apt/archives/lock
sudo rm /var/lib/dpkg/lock

4) dpkg 명령으로 문제 수정

sudo dpkg --configure -a

제로트러스트

chaeya — Wed, 12 Jul 2023 09:59:28 +0900

몇일 전 제로트러스트 가이드라인 1.0이 발표되어 한국인터넷진흥원 홈페이지에서 배포되고 있습니다.

가이드라인 다운로드 : https://www.kisa.or.kr/2060205/form?postSeq=20&page=1#fnPostAttachDownload

KISA 한국인터넷진흥원

www.kisa.or.kr

이 가이드라인을 토대로 제로트러스트라는 용어에 대해서 이해를 높일 수 있도록 한번 정리해 보았습니다.

사이버 공격 침투방법 단계

① 최초 침투 단계 해커는 공격대상 기업의 사용자 계정 등을 다크웹 등에서 구입하거나 업무 관련으로 위장한 악성 메일를 보내 계정을 수집하는 등 다양한 방식을 활용하였으며, 일회용 비밀번호 등의 추가 계정 인증 요구도 우회하는 형태를 보임

② 내부망 침투 단계 내부 시스템에 침투한 이후, 다수 계정·단말을 관리하는 중앙서버 또는 기업 내 프로그램 관리 서 등에 접속하여 추가 정보 습득을 위한 악성코드를 배포하는 방식 등으로 접근하기도 함

③ 내부자료 유출 단계 내부망 침투 이후에는 제품 및 영업 관련 정보 또는 내부 직원 정보 등이 저장된 데이터 수집소에 접근한 뒤 관련 파일을 확보하여 외부 반출로 이어짐

사이버 보안 기술 이슈 및 동향

최근 발생한 수많은 해킹 및 랜섬웨어 공격 사례는 경계 기반 보안모델의 한계점을 드러내고 있으며, 최근 등장하는 보안 솔루션만으로는 완벽한 해결책을 제공하지 못함

기존의 경계기반 보안모델은 내부자에 대한 암묵적 신뢰와 함께 높은 권한을 부여함에 따라 고도화·지능화되는 보안 위협에 한계 노출
- 내부 접속 사용자·기기 또는 내부 트래픽에 대해 외부에서 요구하는 접속과 비교하여 높은 수준의 신뢰성을 부여
- 공격자는 악성코드, 크리덴셜 스터핑* 등을 통한 내부 시스템 침투 후 횡적이동**을 통한 DB 관리자 권한 획득 및 데이터 유출

전통적인 경계 기반 보안(Perimeter Security)으로는 업무 환경의 변화와 진화하는 사이버 위협에 효과적으로 대응하기 어려워 ‘제로트러스트(Zero Trust)’ 개념 등장

제로트러스트

제로트러스트(Zero Trust)란 보안위협이 언제 어디서든 발생 가능하다는 전제하에 요건*을 갖추지 않은 사용자·기기는 자원(데이터, 컴퓨팅 서비스 등) 접근을 제한하고, 신뢰도 평가, 지속적 인증, 세밀한 권한 부여 등 각종 접근제어 기관·기업의 ‘경계’ 기반 보안체계 구축보다 ‘내부 데이터 보호’에 집중하는 새로운 보안 패러다임을 의미.

기 존 경계 기반 보안모델은 네트워크 내부 접속 요구(사용자, 기기 등)는 어느 정도 신뢰할 수 있다는 가정에서 시작
- 반면, 제로트러스트 모델은 해커가 네트워크 내·외부 어디든 존재할 수 있으며, 모든 접속 요구는 신뢰할 수 없다는 가정에서 시작

경계 기반 보안모델은 신뢰하는 자원(내부 네트워크)과 신뢰하지 않은 자원(인터넷) 사이에 보안 경계의 벽을 세움
* 내부자 공모 또는 권한탈취 후 침투, 권한 상승 및 횡적이동을 통한 데이터 유출
- 반면, 제로트러스트 모델은 보호해야할 모든 데이터와 컴퓨팅 서비스를 각각의 자원(Resource)으로 분리·보호
* 모든 자원의 경계를 구분하여 분리·보호, 하나의 자원에 접속한 후에는 정해진 권한만큼만 활동이 가능하고, 인근 자원에 대한 추가 접속 요구 시 지속적 인증으로 침투 제한

제로트러스트는 ①SW Defined Perimeter, ②Micro-Segmentation, ③Enhanced Identity Governance에 기반을 두며, 각각의 자원에 대한 접속요구에 동적인증을 통한 선인증 후 접속, 이후에도 가시성 확보를 통한 지속적 모니터링으로 보안 수준을 높임

제로트러스트 기본철학

① 모든 종류의 접근에 대해 신뢰하지 않을 것(명시적인 신뢰 확인 후 리소스 접근 허용)
② 일관되고 중앙집중적인 정책 관리 및 접근제어 결정·실행 필요
③ 사용자, 기기에 대한 관리 및 강력한 인증
④ 자원 분류 및 관리를 통한 세밀한 접근제어(최소 권한 부여)
⑤ 논리 경계 생성 및 세션 단위 접근 허용, 통신 보호 기술 적용
⑥ 모든 상태에 대한 모니터링, 로그 기록 등을 통한 신뢰성 지속 검증·제어

기존 경계 기반 VS 제로트러스트 보안모델 비교

미국의 제로트러스트 도입 동향

美 민간의 제로트러스트 논의 및 도입, NIST의 문서 발표(’20.8월 SP 800-207) 후 미 연방 정부 행정명령(EO 14028)을 통해 연방정부 차원의 제로트러스트 본격 도입 중

출처 : 제로트러스트 가이드라인 1.0(KISA,2023)

오픈소스SW 연구개발 역량성숙도 모델

chaeya — Thu, 27 Apr 2023 14:55:45 +0900

전통적으로 기술 혁신은 내부 연구개발(R&D) 투입, 규모의 경제, 자체 내부의 우수 인적자원의 확보 및 효율적 활용 등으로 이루어져 왔습니다. 이말은 아이디어의 발굴에서 기초 연구, 제품 개발, 사업화에 이르는 모든 기술 혁신 과정을 기업 내부에서 독자적으로 수행하는 것을 의미하는 것입니다.

하지만 기술의 복잡성 증대, 경제의 글로벌화, 제품 수요의 다양화 등 국내·외 경제 환경의 급격한 변화는 기업의 기술 혁신 활동에 상당한 변화를 요구하고 있으며 이러한 기술 혁신의 패러다임 변화와 맞물려, 기술 혁신 과정에서 외부의 혁신 주체들과 협력하는 방식이 확대됨에 따라, 전 세계적으로 개방형 혁신 활동이 급속히 확산되고 있습니다.

이처럼 개방형 혁신 활동의 필요성이 증가하고 국내에서도 정부지원금을 제공받는 다양한 연구개발 사업에서 오픈소스SW 개발방식의 과제 수행을 요구하는 경우가 많아지고 있지만, 개방형 혁신 연구개발(이하 오픈 R&D)을 수행하려는 수행 기관들은 자신에게 필요한 오픈 R&D 평가 지표와 체계적인 관리 모델들의 부재로 인한 혼란이 가중되고 있습니다.

한국정보통신기술협회의 공개소프트웨어 프로젝트 그룹에서는 조직이 오픈 R&D를 수행하는 수행 기관이 외부의 참여자와 함께 개방형 혁신 활동의 관리를 할 수 있는 연구개발 능력 부문에서 현재의 역량 상태를 평가하고, 목표 수준을 설정하여 개선의 우선순위를 설정하기 위한 기준을 제시하고 있으므로 이 모델을 활용하면 오픈 R&D를 수행하는 조직이 다른 조직과의 오픈 R&D 수행 역량 성숙도 수준을 비교할 수 있습니다.

개방형 혁신 연구개발 역량 성숙도 모델

PDF 다운로드 : ::: TTA표준화 위원회 :::

오픈소스 연구개발 역량 성숙도 모델

이 표준은 오픈 R&D를 수행하는 수행 기관이 외부의 참여자와 개방형 혁신 활동의 관리를 할 수 있는 연구개발 능력 수준을 개선하기 위해 필요한 성숙도 모델을 위해 7개의 도메인(비즈니스 전략, 정책 및 조직, 프로젝트 평가, 공급망 관리, 커뮤니티, 개발 환경, 성과 관리) 관점에서 5 등급의 역량 성숙도 등급으로 측정할 수 있는 기준을 제공합니다.

오픈 R&D를 수행하는 수행 기관이 외부의 참여자와 개방형 혁신 활동의 관리를 할 수 있는 연구개발 능력 수준을 개선하기 위해 필요한 성숙도 모델을 정의하고, 역량 성숙도 등급(Capability Maturity Level), 성숙도 모델 프로세스가 적용되는 도메인(Domain), 도메인별 세부 등급 기준으로 구성되어 있습니다.

평가 수준은 획일적으로 적용하는 것이 아니라 조직의 정책에 의해 적합하게 결정될 수 있으며, 이 표준에서는 5 등급의 성숙도 등급을 제시합니다.

평가 모델은 다음과 같이 7개의 평가 도메인으로 구성되며 각 도메인은 개방형 혁신 연구개발 활동들로 구성된 논리적 그룹, 조직의 성숙도를 평가하기 위해 서로 독립적인 활동 등 관행의 집합이며 각 관행은 조직이 오픈 R&D를 수행하기 위한 활동을 의미합니다.

도메인	설명
비즈니스 전략	오픈소스SW 기반의 비즈니스 전략
정책 및 조직	오픈 R&D 거버넌스 정책과 조직의 구성
프로젝트 평가	오픈소스SW 프로젝트의 성숙도 평가
공급망 관리	오픈소스SW가 포함되는 소프트웨어 공급망 관리
커뮤니티	오픈소스SW 커뮤니티 거버넌스
개발 환경	오픈소스SW 개발을 위한 개발 환경
성과 관리	오픈 R&D에 적합한 성과 지표

조직은 평가를 위한 도메인을 결정하고 선정한 도메인에 대하여 다음과 같은 5 등급의 성숙도 수준을 평가하게 되는데, 개방형 혁신 연구개발 역량 성숙도 평가를 위하여 단일 도메인을 평가하는 공식은 평가 도메인 내 오픈 R&D를 수행하기 위한 활동들에 대하여 조직이 설정한 중요도(가중치)를 할당하여 가중 산술 평균값을 합산하여 등급 기준에 따라 평가합니다.

평가를 위하여 다수의 도메인을 평가하는 공식은 다음과 같이 평가 도메인들에 대하여 조직이 설정한 중요도(가중치)를 할당하여 가중 산술 평균값을 합산하여 최종 등급 기준을 평가할 수 있습니다.

기본적으로 평가대상 도메인들에 대한 가중 산술 평균값을 5 단계 척도로 구분하여 식별하여 적용할 수 있습니다.

(1단계) 초기	(2단계) 정의	(3단계) 관리	(4단계) 확산	(5단계) 최적화
20 이하	21~40	41~60	61~80	81 이상

각 도메인의 세부 평가 기준은 별도 문서를 참고하시기 바랍니다.

SBOM(SOFTWARE BILL OF MATERIALS) 이란 무엇인가

chaeya — Wed, 25 May 2022 16:48:27 +0900

개요

작년 미국의 국가 사이버 보안 강화 지침(2021년 5월)이 배포된 이후, 소프트웨어 산업의 다양한 채널에서 SBOM과 관련한 자문이나 회의가 생기고 있는 상황입니다.

최근의 보안 위협은 공급망, 구축도구, 구축환경, 레파지토리등을 공격하는 추세가 많아지고 있는데 이 지침에서는 미국 연방정부가 사용하는 소프트웨어 공급망의 보안과 무결성을 개선하기 위한 조치를 지시하고 있습니다.

지침이 배포된 이후 미국 정부의 요청으로 미국의 90여개 소프트웨어 기업, 오픈소스 커뮤니티가 자문에 참여하여 의견을 제시히고, CISA, NTIA 에서는 이를 정리하여 SBOM 과 관련한 가이드라인 및 FAQ를 공개하였습니다.

https://www.ntia.gov/SBOM

SOFTWARE BILL OF MATERIALS | National Telecommunications and Information Administration

A “Software Bill of Materials” (SBOM) is a nested inventory for software, a list of ingredients that make up software components. The following documents were drafted by stakeholders in an open and transparent process to address transparency around sof

www.ntia.gov

SBOM 이란?

SBOM 은 SOFTWARE BILL OF MATERIALS 의 약자로 소프트웨어의 구성 요소를 나타내는 메타데이터를 의미하는데 이를 보다 쉽게 설명하자면 우리가 흔히 볼 수 있는 다음과 같은 제품의 성분표기를 떠올리면 됩니다.

성분표기를 통해서 알러지가 있는 사람은 해당 식품을 피하기도 하고, 공급자는 제품의 우수성을 홍보하기도 하고, 크게 성분에 신경쓰지 않고 그냥 사용하는 사용자도 있을 수 있죠.

이와 유사하게, SBOM은 공급되는 소프트웨어의 구성 목록을 잘 표시해서 공급자와 사용자가 이를 기반으로 의사결정에 활용할 수 있는 환경을 조성하는 것을 목표로 하고 있습니다.

NTIA 에서 발표한 SBOM의 필수 구성요소는 다음과 같이 구성되어 있습니다.

Supplier name
Component name
Version of the component
Cryptograph hash of the component
Any other unique identifier
Dependency relationship
Author of the SBOM data

이를 기반으로 작성한다면 다음과 같은 개념도로 표시할 수 있습니다.

National Telecommunications and Information Administration (NTIA) 에서는 오픈소스 소프트웨어나 상용 소프트웨어로 구분하지 않고 모든 공급되는 소프트웨어를 대상으로 광범위하게 적용할 수 있는 SBOM 적용을 위해 산업계의 여러 기업과 커뮤니티에 의견을 청취하고 이를 토대로 SBOM의 이해를 돕는 자료와 적용방법에 대하여 다양한 문서를 배포하고 있으니 아래 문서들을 참고하시기 바랍니다.

SPDX, OpenChain

이러한 소프트웨어 구성 목록을 기반으로 공급망의 투명성을 확보해야 한다는 필요성은 오픈소스 커뮤니티에서 10여년 전부터 논의되어 왔으며, 이를 해결하기 위해 실제 산업에서 SPDX와 OpenChain 이 많이 사용되고 있습니다.

SPDX는 라이선스 컴플라이언스, 보안 등과 같은 문제를 다루면서 진화해서 현재는 시장에서 가장 성숙한 SBOM으로 자리잡고 있습니다. (https://www.linuxfoundation.org/blog/what-is-an-sbom/)
또한 오픈소스 라이선스 준수를 위한 ISO 국제표준(https://www.iso.org/standard/81039.html) 으로 오픈체인이 있으며, 이는 소프트웨어 공급망의 투명성을 강화하기 위하여 오픈소스 커뮤니티에서 고민하던 결과물입니다.

SBOM이 소프트웨어 보안의 모든 문제를 해결할 수는 없지만 보다 안전한 소프트웨어 사용에 필요한 기본을 제공하는 것은 분명히 필요한 일이며, 다양한 산업계의 의견을 토대로 만들어진 SBOM을 기반으로 소프트웨어 공급망의 투명성을 강화할 수 있는 미국의 이번 정책은 향후 IT 산업과 디지털 인프라의 소프트웨어 관리에 있어서 매우 중요하다고 생각됩니다.

개방형 OS 생태계에 대한 이해

chaeya — Wed, 9 Dec 2020 15:05:32 +0900

최근 개방형OS 키워드로 여러가지 보고서 작성이나 교육 또는 컨설팅을 하는 일이 종종 생기면서 국내의 개방형OS 생태계에 대한 생각을 여러번 하게 되었습니다. 이런 과정에서 국내의 경우 해외의 개방형OS 생태계와 차이점이 있는 상황이기 때문에 이 부분을 이해하고 적합한 행동을 해야 한다는 생각이 들었고 국내의 개방형OS 생태계를 도식화 하면서 작성한 내용을 공유합니다.

개방형OS 소프트웨어 아키텍처

개방형OS는 어떤 소프트웨어 아키텍처로 구성되는지 생각해보면, 기존의 비공개OS(Windows, MacOS)들은 특정 기업이 독자적으로 모든 소프트웨어 구성요소를 개발하여 배포하는 방식이지만, 개방형OS는 개별 오픈소스 프로젝트들을 컴포넌트로 사용하는 아키텍처로 구성됩니다.

개방형OS의 거버넌스 구조

이처럼 다양한 오픈소스 프로젝트들의 집합인 개방형 OS 생태계의 이해를 위해서는 우선 오픈소스 커뮤니티의 개발 방식과 오픈소스 커뮤니티의 참여자들이 어떻게 구성되는지 식별할 필요가 있습니다.

오픈소스 커뮤니티 개발 방식

개방형 OS와 같이 커뮤니티를 기반으로 형성되는 소프트웨어 개발에는 소프트웨어 릴리즈를 위한 활동을 중심으로 형성되는 개발자(오픈소스 프로젝트) 커뮤니티와 공개된 소프트웨어에 대한 테스트, 버그에 대한 피드백, 신규요구사항, 의견제시 등을 중심으로 형성되는 사용자 커뮤니티가 존재하며, 이 두 커뮤니티의 상호 작용으로 지속적인 발전을 도모할 수 있는 구조입니다.

오픈소스 커뮤니티 개발 방식

오픈소스 커뮤니티의 구성원

일반적으로 오픈소스 프로젝트의 커뮤니티 내 역할 카테고리를 설명하는 데 사용하는 모델은 월트 스카치(Walt Scacchi)와 예·K, 키시다의 양파 모델이 사용 되는데 이 모델은 커뮤니티에 투자를 많이 하고 가장 적극적인 역할은 가운데 있고, 양파 껍질 바깥쪽에서 일할수록 활동과 투자 수준이 줄어드는 특징이 있습니다.

오픈소스 커뮤니티 구성원의 역할

가장 중심에 있는 핵심 개발자는 프로젝트의 창시자 또는 핵심 개발자로 프로젝트의 최종 결정권을 보유합니다. 이 사람들은 대개 프로젝트에서 가장 경험이 많은 실력자이며 수는 많지 않지만, 이들은 모든 커뮤니티 멤버를 지도하거나 멘토링을 하는 사람들이며 이 사람들은 커뮤니티의 소스코드 주 저장소에 외부 참여자의 기여 결과물을 병합하도록 승인하는 커밋 비트 권한을 가지고 있으며 가장 큰 책임을 맡고 있습니다.
커뮤니티 관리자는 커뮤니티가 외부 커뮤니티 또는 기업과 협력이 필요한 경우 핵심 개발자와 협의를 거쳐 필요한 의사결정과 실행을 담당합니다. 이 사람들은 프로젝트의 지속성을 담보하는 파트너들을 발굴하고 프로젝트가 다양한 분야에서 활용될 수 있도록 프로모션을 하는 등 비즈니스 관점에서 매우 중요한 역할을 합니다.
프로젝트 관리자는 커뮤니티 내부에 다수의 프로젝트가 있는 경우 각각의 프로젝트를 집중적으로 관리하는 사람들입니다. 리눅스 재단, 오픈스택재단, 아파치 재단 등 단일 프로젝트가 아닌 다수의 프로젝트가 활성화된 대규모의 오픈소스 커뮤니티는 개별 프로젝트의 관리를 집중할 수 있는 프로젝트 관리자를 통해 커뮤니티 참여자들과 소통하고 있습니다.
개발자는 일반적인 기여자로써 이 사람들은 프로젝트에 어느 정도 정기적인 기여를 제공하고 대부분의 토론에 꽤 활발하게 참여합니다. 다른 사람들이 한 기여를 검토하는 데 협력하기도 하며 신입 기여자들에게 멘토링을 제공하기도 합니다.
능동적 사용자는 프로젝트의 적극적 사용자들로 신입 기여자의 후보가 되는 그룹을 의미합니다. 프로젝트의 결과물을 주변에 적극적으로 홍보하며 자신도 항상 프로젝트 결과물을 사용하면서 발견한 버그를 공유하고, 이 중 일부는 일정한 시간과 연습을 거친 후 프로젝트의 신입 기여자가 됩니다. 일반 사용자의 질문에 대한 답변을 적극적으로 하며 사람들이 커뮤니티에 잘 정착할 수 있도록 지원하는 중요한 역할을 하게되며 이 사람들은 프로젝트에 도움이 되는 귀중한 피드백, 버그 보고, 기능에 대한 아이디어를 계속 제공하며 프로젝트를 지탱하는 가장 중요한 원동력입니다.
가장 바깥쪽의 계층은 수동적 사용자들로써 개발자나 사용자의 입장으로 적극적 참여는 하지 않지만, 프로젝트를 관심 있게 지켜보고 응원하는 사람들로 비정기적인 피드백을 제공하는 역할을 합니다.

개방형OS 생태계의 이해관계자

’글로벌 상용 소프트웨어 백서‘(과학기술정보통신부, 2017)에서는 국내 소프트웨어 산업 중 PC 운영체제의 생태계를 하드웨어 업체, PC운영체제, 애플리케이션, 클라우드 사업자, 소비자, 공개소프트웨어 커뮤니티의 구성요소로 제시한 바 있으며 공개소프트웨어 커뮤니티는 하드웨어 업체를 포함하여 모든 구성요소와 공헌 및 협업 관계를 유지하는 것으로 표현하고 있습니다. 이 구성을 최근 국내 개방형 OS 생태계에서 실제 참여하고 있는 구성원들을 중심으로 재구성하면 다음과 같이 구성할 수 있습니다.

국내 개방형OS 생태계

이 구성을 오픈소스 커뮤니티를 중심으로 개방형 OS 산업의 이해관계자 그룹으로 재구성하면 생산자 그룹, 공급자 그룹, 소비자 그룹으로 다음과 같이 간략하게 도식화할 수 있습니다.

개방형OS 생태계 이해관계자

생산자 그룹은 오픈소스 활동을 적극적으로 하는 오픈소스 기여자와 기여자가 속한 커뮤니티 또는 재단으로 자발적 기여자들과 해당 커뮤니티에 속한 기업의 재정적 지원을 통해 유지됩니다.
공급자 그룹은 해당 프로젝트를 중심으로 비즈니스 생태계를 조성하고 프로젝트 관련 제품개발, 교육이나 컨설팅 서비스, 기술지원 서비스 등을 공급하여 매출을 달성하고, 해당 커뮤니티와 협력관계를 유지하며 기술인력의 수급, 재정적 지원 등을 통해 참여합니다.
소비자 그룹은 무료로 배포되는 개방형 OS를 사용하는 일반 사용자와 커뮤니티 기반의 지식 채널을 이용하는 방식보다 향상된 지원을 받기 위해 유로 지원 서비스를 구독하는 개방형 OS 활용 조직으로 구성됩니다.

개방형OS 생태계의 시사점

(해외) 개방형 OS 부문에서 대표적인 우분투, 수세, 페도라 등 사용자들의 인지도가 높은 글로벌 개방형 OS의 생태계는 오픈소스 커뮤니티를 중심으로 다음과 같이 오픈소스 프로젝트의 커뮤니티가 구심점이 되어서 다양한 분야의 기업들이 참여하여 생태계를 이루고 있습니다.

해외 오픈소스 생태계의 구성

해외의 개방형 OS의 경우 가장 핵심이 되는 오픈소스 프로젝트의 커뮤니티를 중심으로 프로젝트를 이용하여 제품을 공급하는 공급사와 공급사의 하드웨어, 소프트웨어, 공급망, 기술지원 파트너사들이 참여하는 구조의 생태계를 구성하고 있습니다.
개방형OS 프로젝트의 활성화를 지원하는 프로젝트 파트너사와 다수의 개방형 OS 공급기업, 개방형 OS 기술지원기업이 참여하는 생태계를 구성하여 최종 사용자에게 커뮤니티 기반의 기술지원과 기업의 서브스크립션 기반의 기술지원이 제공되는 구조

(국내) 국내의 개방형OS 생태계는 오픈소스 커뮤니티가 중심이 된 구조가 아니라 개방형OS 공급사가 중심이 되어 사용자 커뮤니티가 최종 사용자의 기술지원 요구사항을 지원하는 구조로 지속성을 담보하는 주체가 커뮤니티가 아니라 개방형OS 공급사에 의존적인 구조입니다.

국내 개방형OS 생태계의 구성

물론 국내에도 개방형 OS 공급사의 파트너사와 프로젝트 파트너사도 존재하지만, 하드웨어, 교육, 기술지원 등의 파트너사의 수가 매우 적어서 해외 개방형 OS 프로젝트의 파트너사를 통한 지원의 수준과는 큰 차이가 있는 상황이며, 이처럼 개방형 OS 사용자가 증가할수록 특정 기업이 기술지원을 모두 해소해야 하는 전통적인 방식으로는 개방형 OS 산업에 적합하지 않은 생태계의 구조입니다.
이처럼 국내의 개방형 OS 생태계는 개방형 OS 프로젝트의 커뮤니티 중심이 아닌 개방형 OS 공급 기업을 중심으로 형성된 생태계이기 때문에 공급 기업의 오픈소스 커뮤니티 활성화 노력이 해외의 개방형 OS 공급사보다 더 많이 요구되는 상황입니다. 하지만 그럼에도 불구하고 실제 개방형 OS 커뮤니티를 활성화하기 위한 개방형 OS 관련 기업들의 인적, 물적 지원이 미비한 상황으로 안타까운 현실입니다.
또한 국내 개방형 OS 산업이 양질의 품질을 지속하기 위해서는, 현재 개방형 OS 소비자로서 강한 권리를 가진 공공 정보화 사업에서 발주자의 역할이 매우 중요한 영향을 미치게 됩니다.
따라서 정보화 사업 담당자는 개방형 OS 도입 사업의 사업자 평가 기준에 사업자의 개방형 OS 커뮤니티 참여 현황과 개방형 OS 프로젝트의 성숙도를 포함하여 평가하는 제도가 필요하며, 이러한 접근을 통해서 개방형 OS 생태계의 관련 기업들이 사업 수주를 위해서는 개방형 OS 커뮤니티의 참여를 유도하게 될 것이며, 그 결과 개방형 OS 프로젝트의 커뮤니티를 중심으로 개방형 OS 생태계를 조성하는 초석이 될 수 있을것입니다.

오픈소스 OS 가 윈도우보다 보안에 취약하다? 진짜?

chaeya — Sat, 14 Mar 2020 11:53:08 +0900

이번주에 지인분이 카카오톡으로 기사를 하나 보내왔습니다.
안드로이드와 데비안 리눅스가 윈도우 보다 보안에 더 취약하다는 기사였죠.
결론부터 말씀드리면 이 기사는 잘못된 내용입니다.

http://www.ddaily.co.kr/news/article/?no=192840

보안성 높다는 오픈소스 OS, 취약점 1·2위··· 개방형 OS 괜찮나?

[디지털데일리 이종현기자] 지난 1월14일 마이크로소프트(OS)의 운영체제(OS) 윈도7의 기술지원서비스가 종료(EOS)됐다. 추후 정기적인 보안패치나 업데이트 등의 지원을 받지 못하게 됨에 따라 보안 공백이 우려됐다. 이에 정부는

www.ddaily.co.kr

오픈소스를 생업으로 하는 입장에서 작성된 이 기사를 보고 궁금해서 원문을 한번 찾아봤습니다.

이 기사에서 사용된 이미지의 원문은 아래 링크입니다.

https://thebestvpn.com/vulnerability-alerts/

Vulnerability Alerts | TheBestVPN.com

As we begin the new decade, you should be mindful that your online activity is being monitored. While federal agencies may claim to do it to protect Americans, big-name companies like Google, Apple, and Facebook financially benefit from putting consumer da

thebestvpn.com

이 인포그래픽의 문제는 제품군의 분류에 있습니다.

만약 안드로이드, 데비안, 우분투, 페도라 등을 하나의 제품으로 봤다면 비교의 대상은 전체 MS윈도우 군이어야 합니다.

Windows 3.1, Windows XP, Windows Vista, Windows 7, Windows 8.1, Windows RT 8.1, Windosw 10, Windows Server 2008, Windows Server 2011, Windows Server 2016, Windows Server 2019 등으로 구분한 이 제품들은 리눅스에서 보면 지난 20년간 릴리즈를 지속해 온 데비안 리눅스 전체와 비교되는 것이 맞습니다.

따라서 지난 20년간 데비안 리눅스가 3,067개의 취약점이 발견되었고, MS윈도우는 4,865개의 취약점이 발견된 것이죠.
(그리고 MS윈도우의 4,865개 취약점이라는 숫자는 윈도우 3.1, XP 등의 보고서에 표기되지 않은 다른 버전을 제외한 수치입니다)

2019년 한 해동안의 취약점을 보면 안드로이드 414 건, 데비안 리눅스 360 건, MS윈도우 2286건, 우분투 190건, 페도라 184 건이 되겠네요.

Linux는 오픈 소스이지만 침입하기가 매우 어렵 기 때문에 다른 운영 체제와 비교할 때 매우 안전한 OS입니다.

Linux는 오픈 소스이며 강력한 사용자 커뮤니티를 가지고 있습니다. 전체 사용자 기반이 소스 코드에 액세스 할 수 있으므로 문제를 모니터링 할 수 있으며 해커가 대상보다 먼저 취약성을 발견 할 가능성이 높습니다. 하지만 Linux 사용자는 공개 소스이므로 문제를 조사하고 수정합니다. 이런 식으로 Linux는 개발자 커뮤니티로부터 상당한 수준의 유지 보수를받습니다.

이와 반대로 Windows 사용자는 소스 코드를 수정할 권한이 없으므로 스스로 문제를 해결할 수 없습니다. 시스템에서 취약점을 발견하면 Microsoft에보고 한 후 수정 될 때까지 기다려야합니다.

Windows에서 사용자는 계정에 대한 모든 관리자 액세스 권한을 갖습니다. 따라서 바이러스가 시스템을 공격하면 전체 시스템이 빠르게 손상됩니다. 따라서 Windows의 경우 모든 것이 위험합니다.

반면에 Linux는 사용자에게 제한된 액세스 권한이 부여되는 계정을 제공하므로 바이러스 공격의 경우 시스템의 일부만 손상됩니다. Linux는 기본적으로 루트로 실행되지 않으므로 바이러스가 전체 시스템에 영향을 미치지 않습니다.

Windows에는 액세스 권한을 제어하기위한 UAC (사용자 계정 컨트롤) 메커니즘이 있지만 Linux만큼 강력하지는 않습니다.

Linux는 IP 테이블을 사용하여 시스템의 보안을 강화합니다. IPtable은 Linux 커널 방화벽을 통해 시행되는 특정 규칙을 구성하여 네트워크 트래픽을 제어하는 데 도움이됩니다. 이를 통해 명령을 실행하거나 네트워크에 액세스 할 수있는보다 안전한 환경을 만들 수 있습니다.

리눅스는 바이러스 공격으로부터 시스템을 보호하는 작업 환경을 세분화했습니다. 그러나 Windows OS는 세그먼트가 많지 않으므로 위협에 더 취약합니다.

아래의 관련 글들을 참고하세요.

https://www.softwaretestinghelp.com/linux-vs-windows/

Linux vs Windows Difference: Which Is The Best Operating System?

Difference Between Linux and Windows Operating Systems In Terms of Architecture, Performance, And Security: Both Linux and Windows are the well known operating systems. When we talk about comparing these two, we should first understand what an operating sy

www.softwaretestinghelp.com

https://hackr.io/blog/windows-vs-linux

Windows vs Linux: Which Operating System is The Best For You?

Windows vs Linux: While we discuss the pros and cons of both systems, we hope to deliver a fair review on specific criteria.

hackr.io

https://www.computerworld.com/article/3252823/why-linux-is-better-than-windows-or-macos-for-security.html

Why Linux is better than Windows or macOS for security

Decisions made years ago about which operating system to roll out can affect corporate security today. Of the big three in widespread use, one can credibly be called the most secure.

www.computerworld.com

미래교육을 위한 에듀테크 플랫폼

chaeya — Wed, 30 Oct 2019 16:16:56 +0900

4차 산업혁명 시대의 주도권 확보를 위한 교두보는 에듀테크 산업

- 에듀테크 분야는 전 세계 시장의 45%를 차지하는 세계 1위 산업 시장
- 미국 시장조사 업체 글로벌인더스트리애널리스츠(GIA)도 전 세계 에듀테크 시장 규모를 2017년 2200억달러(약 246조원)에서 2020년에는 4300억달러(약 481조원)까지 성장할 것으로 전망.
- 글로벌 선두 IT 기업은 에듀테크 산업의 주도권 확보 노력 중

이러한 추세를 입증하듯 글로벌 경쟁 국가들의 과감한 교육 혁신 도전이 이루어 지고 있습니다.

과거 1차, 2차 산업혁명을 통해 국가의 번영 경험이 있는 영국, 프랑스 미국 등의 국가들은 창의적 인재 육성을 위해 과감하고 다양한 교수학습 혁신 실험을 오래전부터 시도하고 있고, 작지만 우수한 성적을 보이고 있는 싱가포르, 에스토니아, 핀란드 등의 국가들 역시 미래 역량에 대한 사회적 공감대와 리더십을 기반으로 숨가쁘게 교육 혁신의 성공사례를 만들어내고 있습니다.

- 1987년 설립된 교육자치 실천 사례인 영국 샌즈스쿨, IT 기술 기반의 몬테소리 교육 형식을 도입한 네덜란드 스티브잡스 스쿨, 칸아카데미 플랫폼 기반 하에 운영 중인 실험 학교 칸랩스쿨, 기업가 정신 중심으로 교육과정을 운영하는 몬드라곤 대학, 토론 중심의 온라인 학습과 글로벌 7개국을 기반으로 실세계 프로젝트를 경험하는 미네르바 대학 등 혁신교육 등 다양한 사례가 있고 학교 밖에서도 학교 혁신을 지원하기 위해 프로젝트 학습 사례를 모으고 학교의 혁신을 지원하는 비아이이(BIE), 사회정서 학습 기반의 학교혁신을 지원하는 카셀(CASEL), 킥보드(Kickboard), 꺼꾸로 학습 모형을 확산하는 에프엘글로벌(Flglobal) 등의 비영리 조직들이 운영되고 있습니다.

빠르게 달라지는 교육 환경

한국의 미래교육에 대해 고민하는 여러분들과 의견을 나눌 기회가 있었습니다. 그 때 논의한 여러가지 에듀테크 시장과 관련한 변화를 알 수 있는 키워드를 한번 정리해보았습니다.

세대 교체 - Generation Z

- 시각적 커뮤니케이션, 능동적 문제해결, 공유와 협업이 생활, 자기주도 학습, 글로벌 친화, e포트폴리오

IT기술을 융합하는 교수학습 설계모형 - Flipped Learning, Adaptive Learning

- 지식을 일방적으로 전달하는 방식이 아니라 자기 주도적 문제해결 능력을 강화할 수 있도록 교육

수업이 게임이 되다 – Gamification

- 게임속에 있는 스토리, 다양한 미션, 재미 요소 등을 교육에 접목, 플레이어들 간에 자유로운 소통을 돕는 다양한 장치를 이용하여 학생과 교수 간 학습과정에서 서로의 생각을 나누며 성장시키는 과정이 있는 교육 가능

궁금하면 직접 하버드, MIT, 스탠퍼드 강의로 공부한다 – MOOC

- 온라인 공개 수업 수강생 간의 피드백, 상호 채점, 협동과제 - 온라인 퀴즈와 시험의 자동화된 채점 방식

에듀테크 산업의 플랫폼 전쟁

기술이 교육을 돕는 여러 분야 중 가장 두드러지는 현상은 학습자의 데이터를 기반으로 인공지능 기술을 적용하는 서비스가 급증하고 있으며 글로벌 Top3 공룡기업들은 모두 에듀테크 산업을 주도하기 위해 노력하고 있습니다.

우리나라의 경우 과거 이러닝 산업을 선도했으나 현재는 에듀테크 세계시장의 5% 미만 수준에 그치고 있는 현실이기에 향후 에듀테크 산업의 발전을 위해 다양한 노력이 중요하다고 생각됩니다. 우리나라가 에듀테크 산업을 선도하기 위해서는 기술을 활용하는 사람에 대한 부분도 필요하겠지만 기술을 사용할 수 있는 환경을 준비하는 것도 필수적이며 이를 위해서는 네트워크, 디바이스, 애플리케이션, 교육서비스플랫폼이 각각 준비되어야 합니다.

부문별 필요한 내용을 생각나는 대로 정리해보면 다음과 같습니다.

교육용 디바이스 부문

- 갤럭시탭, 아이패드, 노트북, 크롬북 등 다양한 디바이스가 존재하지만 점차 사용과 관리가 편한 기기로 시장이 집중되는 경향
- 가상 키보드 보다는 물리적 키보드가 있는 것이 다양한 활용 가능
- 클라우드 기반의 계정관리를 통한 사용자 데이터 복원
- 모든 데이터는 삭제하지 않는 한 보관이 영구적이며, 데이터 제한이 없는 저장소
- 화면잠금장치(Lock in mode)를 통해 현장 온라인 시험을 볼 수 있는 기능
- 개별 학생의 앱(Applications)을 통제할 수 있는 교사의 통제권
- 프로그램들은 더 이상 오프라인 기반 하드드라이브에 저장되는 것이 아닌 클라우드 링크로 바로 돌아가는 시스템.

애플리케이션 및 소프트웨어 부문

- 클라우드 기반의 소프트웨어 제공이 쉬운 환경 조성
- 교육서비스를 제공하는 애플리케이션들이 디지털 교수도구들과 상호호환성을 보장해야 함
- 누구나 교육에 필요한 콘텐츠를 제작하고 관리할 수 있는 콘텐츠 관리도구의 공급
- 블록체인 기술을 활용한 과정과 결과를 보존하는 e포트폴리오의 신뢰성 강화
- 인공지능 기술을 쉽게 활용할 수 있는 클라우드 기반의 SDK 또는 OPEN API
- 교사의 업무를 자동화 기술로 지원하는 소프트웨어 또는 서비스
- Edge AI 기술적용이 가능한 애플리케이션

교육 서비스 플랫폼 부문

- 누구나 참여할 수 있는 개방형 교육 플랫폼 생태계 필요
- 애플, 마이크로소프트 등 메이저 회사부터 중소 에듀테크 앱까지 자체 생태계로 영역을 확장·지속하려 해 왔으며 지나치게 폐쇄적인 생태계와 디지털 독과점을 자행
- 클라우드 시대에서 더 이상의 시장 확장과 지속성 유지를 힘들게 하고 있음
- 종국에는 사용자들 스스로 기존의 오프라인 툴과 연계성이 너무나 불편하다는 것을 자연스레 알게 되어 기기 뿐만 아니라 플랫폼까지도 갈아타는 중.
- UI(사용자환경) 측면에서 동시성과 연계성을 지녀야 그 범용성은 인정되고 편리한 사용 가능
- 인공지능이 활약하기 위해서는 더욱 편리하고 쉽게 빅데이터를 가용할 수 있는 플랫폼의 주도가 필요

모임에서 사용한 발표자료에 보다 상세한 내용이 있으니 아래 링크를 참고하세요

https://www.slideshare.net/chaeya/os-187603296

건강한 오픈소스 커뮤니티 관리

chaeya — Wed, 23 Oct 2019 10:16:40 +0900

오픈소스 프로젝트는 이제 더 이상 취미생활로 하던 수준이 아니고 기업에서 목적을 가지고 운영하는 것이 대세입니다.

하지만 기업의 입장에서 보면 오픈소스 커뮤니티의 관리가 생소하고 이 때문에 프로젝트 수행 조직은 오픈소스 커뮤니티의 구축 및 성장을 어떻게 관리해야 하는지 경험이 부족해서 어려움이 많은 현실입니다.

얼마전 공개소프트웨어 연구개발 프로젝트의 관리에 대한 강의를 할 일이 있어서 강의 자료를 작성했는데 그 내용중 오픈소스 커뮤니티의 운영에서 생각해볼 만한 점을 공유합니다.

프로젝트의 메인테이너의 필요한 활동

• 프로세스 문서화 - 사용자, 기여자, 개발자를 위한 최신의 문서를 제공

• 공평하게 작성되고 집행되는 규칙 준비 – 프로젝트의 유지관리 상태를 투명하게 공유

• 커뮤니케이션 공개 – 가능한 모든 커뮤니케이션을 공개

• 멘토링 수용 – 품질이 낮은 기여를 제출하는 경우 인내심을 가지고 기여할 수 있도록 지원

• 커뮤니티의 기여자 활용 – 공개적으로 필요한 요청을 제시하고 반복적인 기여자에게 더 많은 책임을 부여

• 다른 사람이 필요한 솔루션 구축을 지원 (API)

• 자동화 도구를 적극 활용 – 모든 제출에 대해 최소 품질 표준을 설정하고 코드 품질 향상을 위한 테스트를 자동화

오픈소스 커뮤니티 매니저의 필요한 활동

• 커뮤니케이션이 공개되고 접근 가능한 경우 누구나 과거의 게시물을 읽고 참여 가능한 장소 제공 (커뮤니티 사이트, 포럼, 메일링리스트)

• 개인적인 대화를 공개 채널로 안내해서 전환하도록 유도

• 커뮤니티의 이슈에 대한 빠른 대응 - 48시간 내에 코드 검토를 받은 기여자들은 매우 높은 충성도(모질라 재단 연구)

• 인터넷 상의 다른 곳(Stack Overflow, Twitter, Reddit, Google)에서 프로젝트가 언급될 수 있기 때문에 알림을 받을 수 있도록 설정

• 공개 커뮤니케이션에 대한 보안 문제, 민감한 행동 규범 위반 등의 예외적 상황을 커뮤니티 구성원이 개인적으로 보고할 수 있는 방법 제공

• 행동 규범을 준비하여 나쁜 영향을 미치는 커뮤니티 구성원을 최소화 – 문제가 지속되면 떠나도록 요청해야 할 수 도 있음.

• 커뮤니티 내부에서 기여자를 발굴하기

• CONTRIBUTING.md 파일에서 새 기여자에게 시작하는 방법을 제시

• 기여자를 환경하는 특별한 페이지 준비

• 이슈에 다양한 유형의 제공자에서 적합한 레이블 사용 – good first issue, help wanted

• 친절한 문서를 사용해서 사람들이 모든 단계에서 환영 받는 느낌을 받도록 제공

• 커뮤니티와 최대한 소유권을 공유할 수 있는 방법을 준비 - 사람들은 소유권을 느낄 때 기쁘게 기여합니다.

• 갈등 해결 – 커뮤니케이션에 대한 기준을 설정해서 구성원간 강한 의견이 있는 경우 참여하기 보다는 중재자의 입장을 취할 것

• 투표를 통한 주요 결정을 내리기 보다는 대화를 듣고 토론을 먼저 하기 - 답변 보다는 과정에 집중하는 것이 커뮤니티를 건강하게 만듭니다.

• 커뮤니티 구성원들이 충분히 들을 수 있을 때까지 주요 관심사에 대해 논의합니다.

• 조용한 커뮤니티 사용자를 고려하는 것을 잊지 않아야 합니다.

• 커뮤니티에서 행동의 우선 순위를 식별 – 순위 결정은 최후의 수단으로 사용해야 함, 이 때는 GOVERNANCE 파일에서 순위 결정 및 관련 프로세스를 식별 한 후에 사용

• 커뮤니티 거버넌스 모델은 프로젝트 참여자가 수행할 수 있는 역할과 프로젝트 내 의사결정 프로세스를 설명하고 프로젝트 참여 및 프로젝트 팀 및 커뮤니티 내 의사소통 및 공유 프로세스에 대한 기본규칙을 설명.

오픈소스 프로젝트 관리자의 커뮤니티 관리에 필요한 활동

• 사용자들이 우리 프로젝트를 잘 찾을 수 있는가?

• 총 페이지 조회수 : 프로젝트를 조회 한 횟수를 알려 줍니다

• 총 순 방문자수 : 얼마나 많은 사람들이 프로젝트를 보았는지 알려줍니다

• 추천 사이트 : 방문자가 어디에서 왔는지 알려줍니 다. 이 측정 항목은 잠재 고객에게 도달 할 수 있는 위치와 프로모션 노력이 효과가 있는지 파악하는 데 도움이 됩니다.

• 인기있는 콘텐츠 : 방문자가 프로젝트에서 방문한 위치를 페이지 뷰와 순 방문자수로 나눕니다.

• 기여자 당 총 기여 수 및 커밋 수 - 기여자 수와 활동중인 사람 수를 알려줍니다.

• 처음 기여자, 일시적이거나 반복적인 기여자 - 새로운 기여자를 받고 있는지 여부와 그들이 다시 왔는지 여부를 추적 할 수 있습니다. 새로운 기여자가 없으면 프로젝트 커뮤니티가 정체 될 수 있습니다.

• 이슈 및 요청 수 - 이 수치가 너무 높으면 문제 심사 및 코드 검토에 도움이 필요할 수 있습니다.

• 컨트리뷰션 유형 : 예를 들어 커밋, 오타 또는 버그 수정 또는 문제에 대한 의견

• 미해결 이슈 및 풀리퀘스트 요청 수 - 누군가 프로젝트를 이슈를 관리해야 한다는 것을 의미합니다. 시간이 지남에 따라 그 수가 증가하면 사람들이 프로젝트에 관심이 있음을 나타냅니다.

• 이슈 또는 풀 요청이든 관계없이 기여자 (또는 다른 관리자)가 기여에 응답하는 데 걸리는 시간을 추적

아래 화면은 오픈소스 프로젝트 하모니카의 모니터링 시스템입니다.

강의자료

https://www.slideshare.net/chaeya/ss-183109697

linux desktop 화면 해상도 변경

chaeya — Wed, 23 Oct 2019 09:39:50 +0900

듀얼 모니터를 사용하는데 각각의 화면 해상도가 적절하게 나타나지 않는 경우가 있는데

이 경우는 아래의 방법으로 수동으로 설정이 가능합니다. (시나몬을 사용하는 하모니카, 우분투, 리눅스민트에서 동일하게 적용됩니다.)

사용중인 해상도를 확인

먼저 자신의 컴퓨터에서 사용중인 해상도를 확인하기 위해서는 xrandr -q 명령을 터미널에서 입력해서 알 수 있습니다.

여러개의 모니터를 사용 중이라면 다음과 같이 명령해서 사용하는 모니터가 모두 표시할 수 있습니다.

xrandr -q | grep -i connected

현재 사용중인 모니터의 이름이 제일 앞에 있는 필드이며, 1920x1080 이라고 표기된 부분이 해상도를 나타내는 부분입니다.

만약 정상적인 해상도로 나타나지 않는다면 이 정보를 수동으로 설정하여 제대로된 해상도를 표시할 수 있습니다.

모니터 해상도 변경

모니터의 해상도를 변경하기 위해서 다음과 같이 먼저 수동으로 해상도의 변경 가능을 테스트 합니다.

$ xrandr --output HDMI-1 --mode 1920x1080 --primary

정상적으로 변경이 되는 것을 확인하면 이 명령을 윈도우 시작시 구동될 수 있도록 등록해줍니다.

시작프로그램으로 등록하기 위해서 프로그램> 시작 애플리케이션을 실행합니다.

시작프로그램을 다음과 같이 설정해 줍니다.

명령 : xrandr --output <모니터명> --mode <해상도> --primary

이제 시스템을 재 시작하면 해당 명령어가 구동되어 설정한 해상도로 변경됩니다.

무료 데스크톱 OS들

chaeya — Thu, 18 Apr 2019 16:05:56 +0900

Windows 7 지원 종료 알림

윈도우 7을 사용하는 많은 분들은 오늘 PC에서 이런 화면을 보셨을겁니다. 윈도우 XP 기술지원이 종료되던 2014년에도 IT업계 뿐만 아니라 타산업에 미치는 영향이 심각해서 이슈가 되었던 기억이 납니다.

2014년 MBC 방송자료

이번에도 기술지원 종료에 대한 대처법들이 나오고 이슈가 당분간 되겠죠.

소비자가 PC를 구매하면 사용할 수 있는 환경이 다양하게 제공되지 않는 이유때문에 일반적으로 PC에 사용가능한 운영체제는 윈도우를 떠올리고 있지만 전 세계에는 다양한 PC 운영체제가 있습니다. 오늘은 무료로 사용할 수 있는 데스크톱 OS는 어떤것들이 있는지 소개해보도록 하겠습니다.

더 많은 이런 PC 운영체제를 검색할 수 있을까요?

-> DistroWatch는 수백개의 데스크톱 OS를 무료로 다운로드 받아 사용할 수 있게 소개하고 있습니다.

국내 개방형 데스크톱 OS 사용자를 위한 커뮤니티 하모니카에서 많은 사람들이 이런 이야기를 나누고 있으니 윈도우가 아닌 다른 운영체제를 사용하고 싶은 분들은 참고하세요.

https://hamonikr.org/

개방형 데스크톱 OS 동향

chaeya — Fri, 5 Apr 2019 10:37:53 +0900

개방형 OS의 정의

윈도우 XP의 기술지원 종료 시점에 IT 업계에서 대체 가능한 OS를 찾아야 한다고 한참 시끄러웠는데 내년 1월 윈도우 7의 기술지원이 종료되는 시점이 다가오면서 또 한번 이슈가 되고 있습니다.

윈도우, MacOS, 티맥스OS 처럼 개발업체에서 OS를 완전히 소유하고 있는 형태를 폐쇄형 OS라고 할 수 있는데 이 경우는 제조사의 기술지원이 종료되는 시점에 매번 윈도우 기술지원 종료와 같은 사태가 벌어지게 될 수 밖에 없습니다. 이 때문에 각 국가들은 특정 기업에 종속되지 않는 독자적인 운영체제를 개발하고자 많은 노력을 기울이고 있지만 운영체제 개발은 많은 예산을 투입하고 오랫동안 지속해야 하는 기술이므로 쉽지 않은 분야입니다.

개방형 OS란 누구든지 소스를 받아 자유롭게 수정 및 배포가 가능한 운영체제를 의미합니다. 때문에 많은 나라들이 독자적인 기술개발 보다는 개방형 OS를 개발하는 방식을 선택하고 있는데 OS의 모든 부분을 독자적으로 개발하는 것이 아니라 오픈소스로 공개된 영역들은 재사용하고 자신의 환경에 적합한 기술들은 개발하여 각 국가에 적합한 개방형 OS를 제작하고 있습니다.

국가별 개방형 OS 배포 현황

개방형 OS는 국가가 주도하고 있는 배포판들 이외에도 글로벌 커뮤니티에서 주도하는 다양한 종류의 배포판이 존재하는데 http://distrowatch.com 에 방문하면 현재 인기있는 다양한 개방형 OS 관련 정보를 확인할 수 있습니다. 또한 distrowatch 는 수백개의 리눅스 배포판에 대한 최신정보를 제공하고 있으며 다양한 조건으로 검색을 제공하므로 원하는 개방형 OS를 검색하기에 용이합니다.

distrowatch.com 검색화면

개방형 OS는 단일 기업에서 제조되는 OS와 다르게 운영체제를 구성하는 기술 레이어별로 각각 다른 지배구조를 가지고 있기 때문에 응용프로그램 자체의 기술 개발보다는 각기 다른 지배구조를 가진 커뮤니티의 배포 요구사항을 식별하고 관리하는 활동이 중요합니다.

개방형 데스크톱 OS 의 지배구조

윈도우나 맥의 경우에는 데스크톱을 사용하는 환경이 제조사에서 결정한 그대로 고정되어 배포되지만, 개방형 OS는 사용자가 원하는 데스크톱 환경(Gnome, KDE, Cinamon, MATe, Unity 등)을 다양하게 선택할 수 있습니다. 개방형 OS는 사용자에게 원하는 방식을 선택할 수 있는 자유로움을 제공하는것을 기본으로 하고 있기에 윈도우나 맥을 계속 사용해온 처음 사용자들은 기존의 환경과 다른 데스크톱 환경에 혼란스러움을 느낄수도 있습니다.

하지만 개방형 OS는 보안 위협이 발생하면 장시간 걸리는 제조사의 업데이트를 기다리지 않아도 전 세계 개발자들에 의해서 패치가 신속하게 이루어지고 있으며, 최신 기술을 선도하며 사용자에게 좋은 프로그램을 꾸준히 제공하여 현재 전 세계의 많은 사람들이 개방형 OS를 사용하고 있는 상황입니다.

https://en.wikipedia.org/wiki/Comparison_of_Linux_distributions

다양한 개방형 OS 의 비교

현재 국내에서 사용가능한 개방형 OS는 글로벌 커뮤니티에서 제공되는 배포판과 하모니카 OS가 있습니다. 우분투, 페도라 같은 배포판을 직접 다운로드 받아서 커뮤니티에 지원을 받으면서 사용하는 방법도 있지만 국내 기업이 기술지원을 하고 있는 하모니카 OS의 경우 2016년부터 국내 공공기관 및 학교, 병무청, 경찰청 등에서 사용하고 있으며 하모니카 사용자를 위한 한국어 커뮤니티 하모니카(https://hamonikr.org/)에서 사용시 궁금한 점을 함께 이야기 하고 있습니다.

하모니카 OS 프로젝트의 구성

정부 주도로 시작한 프로젝트가 종료되어 장시간 정체되어 있던 하모니카는 인베슘이 주도하여 2018년 하모니카 ME 버전을 출시하였으며, 현재 인베슘(https://www.invesume.com/)에서 하모니카 OS의 기술지원을 제공하고, 개방형 OS의 이용환경을 개선하기 위해서 지속적으로 노력하고 있습니다.

참고. 개방형 데스크톱 OS 동향 : https://www.slideshare.net/chaeya/os-139524487

오픈소스 커뮤니티 구축

chaeya — Sat, 12 May 2018 10:13:50 +0900

오픈소스 소프트웨어는 인공지능(AI), 사물인터넷(IoT), 클라우드 빅데이터 등 다양한 분야에서 4차 산업혁명과 지능정보사회의 핵심 기술로 부상하고 있습니다. 글로벌 시장에서는 구글, 페이스북 같은 글로벌 대기업도 개방형 혁신활동을 중요하게 여기며 이를 위하여 자사의 기술을 외부에 공개하고 오픈소스 커뮤니티를 중심으로 핵심기술을 주도하려는 노력을 하고 있습니다.

전통적으로 기술혁신은 자체적인 우수 인적자원의 확보 및 효율적 내부자원의 활용을 중심으로 조직 내부의 연구개발을 통해 이루어져 왔습니다. 이러한 방식은 아이디어의 발굴에서 기초연구, 제품개발, 사업화에 이르는 모든 기술혁신의 과정을 기업 내부에서 독자적으로 수행하는 것을 의미합니다.

그러나 기술의 복잡성이 증대하고 제품 수요가 다양해지고 시장경제의 글로벌화가 가속되며 기술혁신의 비용은 급증하는 상황을 맞이하여 조직의 연구개발 생산성을 제고하기 위해 기술혁신 과정에서 외부와 협력하는 현상이 확대되고 있는데 UC버클리 대학의 Chesbrough 교수가 주창한 개방형 혁신(open innovation) 이론에 따르면 개방형 혁신의 개념을 다음과 같이 요약하고 있습니다.

“개방형 혁신은 기업이 안으로의 지식 흐름(inflow)과 밖으로의 지식 흐름(outflow)을 적절히 활용하여 내부의 혁신을 가속화하고 혁신의 외부 활용 시장을 확대하는 것이다. 개방형 혁신은 기업들이 내부 아이디어뿐 아니라 외부 아이디어도 활용할 수 있고, 또 활용해야 하며, 자사의 기술을 상업화하여 시장에 진출할 때 내부뿐 아니라 외부 경로도 사용할 수 있고, 또 사용해야 함을 전제하는 혁신 패러다임이다. 개방형 혁신과정은 내부와 외부 아이디어를 결합하여 아키텍처와 시스템을 구현한다. 이 아키텍처와 시스템에 대한 요구 사항은 비즈니스 모델을 통해 정의된다. 비즈니스 모델은 내부와 외부 아이디어를 활용하여 가치를 창출하고 그 창출된 가치의 일부를 자사의 몫으로 전유하기 위한 내부 메커니즘을 정의한다. 개방형 혁신은 부가가치를 창출하기 위해 내부 아이디어가 외부 경로, 즉 기업의 기존 비즈니스 모델 밖에 있는 채널을 통해 시장으로 나갈 수 있음을 전제한다 (Chesbrough 2006b: 1)”

이론에 따르면 개방형 혁신은 연구, 개발, 상업화에 이르는 일련의 기술혁신 과정에서 조직 내부와 외부 사이에 일어나는 모든 형태의 지식 교류 활동을 의미하며, 집단 지성을 활용한 지속적인 개선과 사용자 피드백을 반영한 기술혁신이 이루어지는 오픈소스 커뮤니티는 개방형 혁신 활동의 대표적인 예로 볼 수 있습니다.

우리나라도 최근 이런 흐름을 반영해서 전통적인 연구개발을 오픈소스 개발방식으로 진행하려는 오픈R&D에 대한 학교와 기업의 흐름이 증가하고 있죠.

저는 리눅스 커뮤니티 하모니카(http://hamonikr.org)를 운영하고 있는데 최근에 활발하게 커뮤니티가 성장하고 있으며 현재 하모니카 커뮤니티는 월평균 만명정도의 방문자가 있습니다. [참고] 웹로그 분석 : http://hamonikr.org/board_aMBI05/49687

때문에 저 자신도 오픈소스 커뮤니티 운영에 고민이 있고 그러다 보니 오픈소스 커뮤니티의 구축과 운영을 어떻게 하면 좋을지에 대한 현장의 고민을 자주 듣습니다.

오늘은 오픈소스 커뮤니티를 구축하고 운영하는데 무엇이 필요할지 정리해 보겠습니다.

오픈소스 커뮤니티 현황

오픈소스 커뮤니티[5]란 누구에게나 프로그램의 소스코드에 대한 동등한 접근을 보장하고 책임과 권한을 공유하며 지속적인 개발자와 사용자의 기여에 의해서 프로젝트가 변하는 커뮤니티를 의미하며, 오픈소스 커뮤니티를 기반으로 형성되는 소프트웨어 개발 모델은 소프트웨어 릴리스를 위한 활동을 중심으로 형성되는 개발자 커뮤니티와 공개된 소프트웨어에 대한 테스트, 버그 제출, 의견 제시 등을 중심으로 형성되는 사용자 커뮤니티가 존재합니다.

그림 1 Open Source Development Model

정보통신산업진흥원의 최근 조사 자료에 의하면 전 세계 대표적인 오픈소스 소프트웨어의 소스코드 저장소인 깃허브(Github)에서는 약 38만 건의 프로젝트 개발이 활발히 진행 중이며, 약 2,000만 명이 약 16만 개의 오픈소스 커뮤니티에서 소프트웨어 개발 및 프로젝트 기여를 위해 사용자․개발자로 참여하고 있다고 합니다. 이에 비해 국내의 경우 총 248개의 오픈소스 커뮤니티가 운영중인 것으로 파악되어 글로벌 대비 0.1% 수준의 규모이며 그 중에서도 사용자 커뮤니티 214개(86%), 개발자 커뮤니티 34 개(14%)로 국내 오픈소스 커뮤니티의 다수는 오픈소스의 사용자 커뮤니티로 조사되었습니다.

조사 결과에 따르면 해외에서는 여러 재단을 중심으로 커뮤니티에서 오픈소스 프로젝트의 개발 참여와 기여가 활발하지만 국내에서는 개발에 참여보다는 오픈소스 커뮤니티가 제공하는 결과물을 활용하거나 사용법을 묻는 것이 대부분으로 나타났으며 또한 국내 오픈소스 커뮤니티 중 해외 오픈소스 커뮤니티와 프로젝트를 공유하거나 국제 행사 참가를 통해 교류중인 커뮤니티는 14개로 파악되었습니다. 국내의 오픈소스 생태계는 생산자 관점의 오픈소스 커뮤니티 활용이 매우 저조한 실정임을 알 수 있습니다. 따라서 향후 국내 기업의 오픈소스 커뮤니티 기반 개방형 혁신을 확산하기 위해서는 현재의 사용자 커뮤니티 중심의 국내 오픈소스 커뮤니티를 글로벌 개발자 커뮤니티와 상호 협력할 수 있도록 지원하는 노력이 필요하다고 생각합니다.

오픈소스 커뮤니티의 구축

직접 오픈소스 커뮤니티를 구축하기 전에 먼저 원하는 공개하려는 소프트웨어와 유사한 관심사에 대한 커뮤니티가 국내·외에 이미 존재하는지 검색하는 것이 중요합니다.

만약 동일한 관심사의 커뮤니티가 이미 존재하는데 새로운 커뮤니티를 형성하려고 하면 참여자들의 커뮤니티의 신규 생성에 대한 당위성을 설득하기 어려우며 기존의 다른 오픈소스 커뮤니티의 지지를 얻기 힘들기 때문입니다. 따라서 만약 유사한 관심사를 다루는 오픈소스 커뮤니티가 이미 존재한다면 별도의 커뮤니티를 생성하여 새로운 기반을 형성하는 것 보다는 해당 커뮤니티에 참여하여 협업하는 것이 가장 좋습니다.

이 경우에는 이미 오픈소스 커뮤니티 활성화의 기반이 존재하기 때문에 공개하려는 소프트웨어를 해당 커뮤니티의 사용자들이 사용할 수 있도록 해당 기능을 추가로 제안하여 기존 공개된 소프트웨어의 기능을 강화하는 방식의 접근이 필요합니다.

기존의 커뮤니티 중 공개하려는 소프트웨어와 유사한 관심사를 가진 커뮤니티가 없는 경우 새로운 오픈소스 커뮤니티는 생성하게 되는데, 이렇게 생성되는 오픈소스 커뮤니티의 성장 단계는 Tech-nical Stage, Open Source Stage, Ecosystem Stage의 세 가지 단계로 구분할 수 있습니다.

그림 2 오픈소스 커뮤니티 성장단계

Technical Stage

Technical Stage는 오픈소스 커뮤니티의 참여자들 중 개발자들 보다는 사용자들을 대상으로 공개한 소프트웨어의 바른 사용 방법과 권한을 제공하는 것에 중점을 두는 단계이며 이 단계에서는 공개한 소프트웨어의 라이선스를 컴포넌트 별로 식별한 소프트웨어 라이선스 프레임워크를 통해 프로젝트의 라이선스 정책을 사용자들에게 배포하고 공개한 소프트웨어의 기능을 확인할 수 있는 프로그램 데모를 제공하는 것이 필요합니다. 프로젝트를 소개할 수 있는 웹사이트, 제공하는 소스코드를 다운로드 할 수 있는 공개된 저장소, 의사 소통을 위한 메일링 리스트와 커뮤니케이션 채널, 프로그램의 버그를 추적관리 할 수 있는 버그 트래킹 도구, 각종 문서를 쉽게 작성해 공유할 수 있는 문서화 도구 등이 필요하게 되며 사용자들이 공개된 소프트웨어를 활용할 수 있는 범위와 사용에 따르는 책임을 명확하게 인지할 수 있도록 준비해야 합니다.

Open Source Stage

Open Source Stage는 오픈소스 커뮤니티에 참여하는 사용자와 개발자를 대상으로 잘 구성된 오픈소스 커뮤니티 거버넌스 모델을 구축하는 데 중점을 두는 단계이며 이 단계에서는 커뮤니티 참여자들에게 프로젝트의 구조를 쉽게 설명하는 문서를 준비하고, 프로젝트의 로드맵을 제시하게 됩니다. 또한 커뮤니티 참여자가 어떻게 참여할 수 있는지를 개발자와 사용자로 구분하여 자세히 알려주고, 커뮤니티 내 분쟁이 일어나거나 의사결정이 필요할 때 어떤 방식의 의사결정과정을 따르게 되는지를 투명하게 공개해야 합니다.

오픈소스 커뮤니티의 전략적 방향에 따라 수많은 유형의 거버넌스 문서가 필요할 수 있으나 일반적인 오픈소스 커뮤니티 거버넌스 문서에 포함되어야 하는 공통적인 요소는 다음과 같습니다.

개요 (overview)
역할과 책임 (roles and responsibili-ties)
지원 (support)
기여 과정 (contribution process)
의사결정 과정 (decision making pro-cess)

Open Source Stage 단계에서는 커뮤니티 참여자들의 역할과 책임에 따른 운영 조직이 구성되고 커뮤니티 운영 조직과 커뮤니티 참여자 간 투명한 합의를 기반으로 커뮤니티 운영이 이루어져야 합니다. 이를 위해서 프로젝트 마일스톤과 릴리스를 관리할 수 있는 프로젝트 관리도구, 개발자 및 사용자를 위한 포럼, 이슈관리, 자동화 빌드, 소프트웨어 품질 가시화, 문서 협업 도구 등이 필요하며 외부의 참여자들이 프로젝트에 어떻게 기여할 수 있는지 자세히 안내하는 문서를 준비하고, 커뮤니티의 참여자들과 지속적으로 소통을 유지하는 것이 중요합니다

Ecosystem Stage

공개한 소프트웨어의 사용자의 수가 늘어나고 오픈소스 커뮤니티가 성장하면서 커뮤니티 참여자들에 의한 사용자 지원으로는 기업 사용자들이 요구하는 서비스 수준을 제공하지 못하는 문제가 발생하게 되는데 Ecosystem Stage는 오픈소스 커뮤니티의 확산과 지속가능성을 보장하기 위하여 공개한 소프트웨어를 이용하여 비즈니스에 활용하는 기업 멤버들과 다른 오픈소스 커뮤니티와 함께 상생협력을 중점으로 운영하는 단계입니다. 따라서 이 단계에서는 프로젝트를 지원할 수 있는 기업들로 구성된 비즈니스 협의체가 조직되고 공식 기술지원 파트너 기업이 커뮤니티에서 홍보되어 기업에서 공개된 소프트웨어를 사용하기 위한 신뢰성을 제공할 수 있도록 커뮤니티에 참여하는 기업들을 중심으로 긴밀한 관리가 필요합니다.

이클립스 재단의 경우 다음과 같이 사용하는 프로젝트의 파트너 기업들이 제공하는 제품을 소개하는 마켓플레이스를 직접 운영하며, 활용 사례를 소개하고, 공식적인 기술지원이 가능함을 홍보하여 프로젝트의 신뢰성을 확보하고 있습니다.

그림 3 Eclipse Foundation Marketplace

이처럼 오픈소스 커뮤니티가 원활한 지속적 운영을 보장하기 위해서는 공개한 소프트웨어를 기반으로 기술지원을 제공하는 파트너 기업을 발굴하고 기업 멤버를 커뮤니티에 흡수하여 커뮤니티의 발전방향이 커뮤니티 참여 기업의 비즈니스 전략에 영향을 미치는 관계가 형성되어야 자연스럽게 커뮤니티 지속을 위한 재원 확보가 이루어지고 향후 공개한 오픈소스 프로젝트를 중심으로 성공한 재단의 형태로 성장하는 것을 기대할 수 있습니다.

오픈소스 커뮤니티의 운영

오픈소스 소프트웨어 프로젝트 및 커뮤니티 운영이 성공하기 위하여 가장 중요한 요소는 투명성과 문서화를 꼽을 수 있습니다.

투명성은 프로젝트 관련하여 참여하는 사람들과 외부 참여자들에 대한 프로젝트 관련 도메인 및 기능을 어떻게 유지할 것 인가에 대한 명시를 의미하는데 오픈소스 소프트웨어의 특성상 투명성의 유지는 대단히 중요할 뿐 만 아니라, 기업에 의해서 주도되는 오픈소스 소프트웨어라면 투명성의 확보는 해당 오픈소스 소프트웨어 커뮤니티의 운명을 쥐고 있는 열쇠라고 해도 과언이 아닙니다.

어떤 오픈소스 소프트웨어 개발자들도 보이지 않는 장막 뒤에서 펼쳐지는 오픈소스 소프트웨어에 참여하고 싶은 사람은 없으며 특히 기업이 오픈소스 소프트웨어 전환을 시도할 경우, 그 동안 기업 내부의 습관에 의해 투명성을 소홀히 하고 내부 프로세스를 공개하지 않는 경우가 있는데, 그런 경우 커뮤니티를 활성화하기란 매우 어려우며 오픈소스 소프트웨어 커뮤니티로의 전환의 실패로 이어질 확률 또한 매우 높습니다.

오픈소스 커뮤니티에 투명성이 필요한 요소는 공개한 소프트웨어의 비전, 로드맵, 릴리스 계획, 형상관리 계획, 커미터 자격 조건, 새 기능 추가 또는 소프트웨어 패치의 제출 과정 등이 대상입니다.

오픈소스 커뮤니티 운영의 다른 한가지 중요한 요소는 문서화입니다. 실제로 오픈소스 소프트웨어는 자발적으로 참여하는 사람들이고 개발자 위주로 돌아가는 생태계이기 때문에, 문서화에 소홀하게 되는 경우가 많습니다.

커뮤니티의 운영을 위해서 공개한 소프트웨어 자체에 대한 문서화와 오픈소스 커뮤니티의 구조 및 프로세스에 대한 문서화도 포함하여 작성해야 합니다. 문서를 통해서 커뮤니티 거버넌스 모델 명시, 커뮤니티 구조 및 프로세스 명시뿐만 아니라, 해당 소스코드에 대한 문서화도 명확하게 해두어야 많은 사람들이 참여하여 오픈소스 소프트웨어 커뮤니티를 활성화 시키게 되기 때문에 커뮤니티에 참여하는 개발자 및 사용자들이 쉽게 이해하고 도움을 받을 수 있으며, 참여자들이 쉽게 편집할 수 있는 수준의 문서화를 제공하는 노력이 중요합니다.

마치며

해외의 경우 Apache, Eclipse, Openstack, Linux 등 다양한 오픈소스 재단이 설립되어 클라우드, 빅데이터, 인공지능 등 분야에서 핵심 기술을 주도하고 있는데 비해 국내에서는 공개된 소프트웨어를 가져다 쓰는 사용자 커뮤니티를 중심으로 오픈소스 커뮤니티가 형성되어 있으며 글로벌에 영향력이 있는 개발자 커뮤니티는 찾아보기 힘든 실정입니다.

최근 우리 정부는 국가의 ICT R&D 경쟁력 강화를 위한 지속적인 정책적 노력과 집중 투자에도 불구하고, 창의적․선도적 혁신역량 제고와 성과확산에 한계를 인식하고 개방형 혁신의 장점을 반영한 핵심 원천기술의 오픈R&D를 추진하여 미래 유망기술을 글로벌 시장에서 선도하고 연구개발 결과물의 활용도를 제고하기 위하여 노력하고 있으나 외부의 참여자들과 협력하는 오픈소스 커뮤니티 기반의 개방형 혁신에 익숙하지 않은 연구기관들은 체계적인 관리모델의 부재로 인한 혼란이 가중되고 있습니다.

오픈소스 커뮤니티를 중심으로 세계시장 기술 경쟁력 기반확보를 위해서 정부에서는 오픈소스 생태계를 이해하고 소프트웨어 기술 연구개발을 오픈소스 프로젝트를 방식으로 전환하고 오픈소스 커뮤니티를 통한 사용자 저변이 확산될 수 있도록 지속적인 노력을 기울여야 하며 기업의 경우 오픈소스 커뮤니티에 참여하는 내부 개발자에 대하여 비판적인 시각에서 벗어나 글로벌 오픈소스 프로젝트의 참여와 기여는 기업의 우수한 기술력을 홍보하는 효과적 수단임을 인식하고 내부 개발자의 오픈소스 커뮤니티 참여 활동을 적극 권장하고 기업의 비즈니스 전략에 오픈소스 커뮤니티와 연계한 개방형 혁신을 위한 노력이 필요합니다.

참고문헌

김석관 : Chesbrough의 개방형 혁신 이론. 과학기술정책, 2008
OW2 : open source software the governance makes the difference. https://www.slideshare.net/OW2/open-source-software-the-governance-makes-the-difference, 2015
조재홍 : 공개SW 소비국을 넘어 기여국으로 성장을 위한 제언. NIPA, 2018

Postfix with Gmail SMTP on Ubuntu

chaeya — Sun, 1 Apr 2018 11:19:01 +0900

서비스를 운영하다보면 서버에서 이메일을 발송할 일이 있을때 여러가지 이유로(보안상 계정 관리, 발송한 메일을 확인 등) 지메일 계정으로 쓰고 싶은 경우가 종종 있습니다. 지메일은 메일사본을 보관해주고 웹인터페이스를 제공하기 때문에 저는 중요한 고객서비스를 제공할때 자주 사용하고 있습니다.

이번에 신규서버에 설정할 일이 생겨서 설정 과정을 공유합니다.

이번에 제가 테스트한 환경은 Linux Mint 18.3 입니다.

하모니카 커뮤니티 에디션, Linux Mint 18.3, Ubuntu 16.04 등은 모두 동일한 방법을 사용해서 적용하시면 됩니다.

패키지 설치

필요한 모든 패키지 설치는 다음과 같이 실행합니다.

sudo apt-get install postfix mailutils libsasl2-2 ca-certificates libsasl2-modules

처음 설치하시는 경우 postfix 설정 도우미가 어떤 용도로 사용할지 물어보게 됩니다. 이때 Internet Site 를 선택하세요.

postfix 환경설정

postfix 설정파일 편집

sudo vi /etc/postfix/main.cf 명령으로 설정파일을 편집합니다.

항상 편집을 시도하기 전에 원본을 복사해서 보관해두는 것을 잊지마세요.

파일의 내용은 아래내용을 그대로 사용합니다.

# gmail smtp setting

relayhost = [smtp.gmail.com]:587

smtp_sasl_auth_enable = yes

smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd

smtp_sasl_security_options = noanonymous

smtp_tls_CAfile = /etc/postfix/cacert.pem

smtp_use_tls = yes

계정정보 파일 생성

sudo vi /etc/postfix/sasl_passwd 명령으로 계정정보 파일을 생성하고 아래의 붉은색부분을 자신의 지메일 계정 정보로 적습니다.

[smtp.gmail.com]:587 USERNAME@gmail.com:PASSWORD

postfix 에서 사용할 수 있는 db파일로 변환

다음의 명령으로 계정정보 파일을 루트만 접근하도록 변경하고 postfix에서 사용하는 파일형태로 변환해 줍니다.

sudo chmod 400 /etc/postfix/sasl_passwd

sudo postmap /etc/postfix/sasl_passwd

CAfile 생성

환경설정에서 정의해준 CA파일을 다음과 같이 생성해 줍니다.

cat /etc/ssl/certs/thawte_Premium_Server_CA.pem | sudo tee -a /etc/postfix/cacert.pem

postfix 서비스 재시작

sudo /etc/init.d/postfix reload

테스트

만일 mailutils 가 설치되지 않은 경우에는 이 명령어가 동작하지 않습니다. 설치가 되지 않은 경우에는 다음과 같이 설치해줍니다.

sudo apt install mailutils

메일발송을 다음과 같이 테스트 해 봅니다. 붉은색 부분을 자신이 확인할 수 있는 이메일계정으로 변경해주세요.

echo "postfix로 발송한 메일입니다" | mail -s "Postfix 메일 테스트" 수신이메일주소

디버깅

문제가 발생하여 로그를 확인하고 싶은 경우는

tail -f 10 /var/log/mail.log 명령어로 postfix의 작업과정 확인합니다.

지메일 환경설정

2단계 보안인증

게정 로그인 정보가 정상임에도 불구하고 다음과 같은 오류가 로그파일에 남는 경우에는 지메일에서 추가적인 환경설정이 필요합니다.

postfix/smtp[21326]: CF7CE24225C: SASL authentication failed; server smtp.gmail.com[108.177.125.109] said: 535-5.7.8 Username and Password not accepted. Learn more at?535 5.7.8 https://support.google.com/mail/?p=BadCredentials k24sm23509527pfj.32 - gsmtp

이 이유는 지메일의 보안설정때문에 발생합니다.

먼저 아래 링크에서 2단계 인증을 사용하도록 변경합니다. 이때 보안코드를 받을 수 있는 휴대폰이 있어야 합니다.

https://myaccount.google.com/u/2/security

앱 비밀번호 생성

인증을 마쳤으면 다음과 같이 앱 비밀번호를 생성해줍니다. 새로운 앱을 원하는 이름으로 만들고 이때 발급되는 비밀번호를 복사해둡니다.

다음과 같이 이전에 설정한 파일의 비밀번호 대신 복사한 비밀번호를를 사용하도록 변경합니다.

sudo vi /etc/postfix/sasl_passwd

[smtp.gmail.com]:587 USERNAME@gmail.com:발급받은앱비밀번호

저장해주고 다시 변경된 내용을 postfix에서 사용하는 파일형태로 변환해 줍니다. 저장이 안되는경우는 파일의 쓰기 권한 때문입니다. vi 에서는 저장할때 :wq! 하시면 강제 저장이 됩니다.

sudo postmap /etc/postfix/sasl_passwd

테스트 및 확인

다음과 같이 테스트 해봅니다.

echo "postfix로 발송한 메일입니다" | mail -s "Postfix 메일 테스트" 수신이메일주소

Agile Scrum Kanban Waterfall

chaeya — Sat, 24 Mar 2018 08:59:31 +0900

오랜만에 포스팅입니다.

얼마전 소프트웨어 기업을 대상으로 강의요청이 있어서 교육을 진행했습니다. 5시간 정도 교육을 마치고 교육 수강하신 분들을 대상으로 회고를 해보니 의미있었던 내용이었다는 이야기를 듣고 한번 정리해야 겠다는 마음이 들었습니다.

오늘 주제는 Waterfall, Agile, Scrum, Kanban 이라는 용어에 대해서 알아보고, 어떤 경우에 어떤 방법을 사용하는 것이 좋은지 이야기 하려고 합니다. 상세한 내용은 별도로 공유하는 자료를 참고하시기 바랍니다.

저는 소프트웨어 개발방법론 맹신자는 아니지만 개발방법론의 효용가치에 대해 인정하는 편입니다. 중요한 것은 방법론이 아니라 적절한 방법론을 적절한 곳에 사용하지 않는 사람이 문제 아닐까요.

학교에서 배우는 소프트웨어 공학에 요즘 스크럼, 칸반이 들어있는지 모르겠지만 최근의 소프트웨어 개발방법론은 애자일 방식을 채택하는 경우가 많습니다.

주변에서 요즘은 애자일 개발방법론을 사용하고 있다는 회사들을 종종 접하게 됩니다. 아래의 애자일 개발방식을 사용하고 있다는 사람들에게 물어본 조사결과를 보면 58%는 Scrum을 사용하고 10%는 Scrum과 XP의 하이브리드 형태를 사용하고 있습니다. 그리고 8%는 multiple methodologies를 사용하고 있죠. 7%는 Scrumban 5%는 Kanban을 사용하고 있습니다.

이 이야기는 애자일 개발방식을 사용하는 사람들이 저마다의 환경에서 적합한 방법을 채택하고 있다는 의미입니다. 하지만 아직 국내에서는 실제 현업에서 다양한 적용사례를 만나기 어려운 현실입니다. 현업에서 이야기를 하다보면 애자일과 스크럼을 동일시 하는 경우도 자주 보게 되는데 스크럼은 애자일의 서브셋 입니다.

애자일이란?

소프트웨어 개발의 기초 원칙과 정신을 선언한 철학입니다. 소프트웨어를 개발하는 더 나은 방법들에 대한 이야기를 담은 문서가 2001년 Agile Alliance 라는 그룹에서 만들어지는데 12가지의 원칙을 담고 있습니다.

애자일 철학을 반영하는 개발방법론들

Scrum?

Scrum은 Agile을 구현하는 가장 보편적 인 방법 중 하나입니다. 스크럼은 변하지 않는 일련의 역할, 책임 및 회의를 따르는 반복적인 소프트웨어 모델입니다.

Kanban?

일본에서 '시각적 기호'또는 '카드'를 의미하는 Kanban은 Agile을 구현하는 시각적 프레임 워크입니다. 현재 시스템에 대한 작고 지속적인 변경을 촉진합니다. 그 원칙은 다음과 같습니다 : 워크 플로우를 시각화하고, 진행중인 작업을 제한하고, 플로우를 관리 및 강화하고, 정책을 명시적으로 만들고 지속적으로 향상시킵니다.

XP(Extreme Programming)?

익스트림 프로그래밍 (Extreme Programming)은 진화하는 고객 요구 사항에 대한 품질과 응답성을 개선하기 위한 소프트웨어 개발 유형입니다. XP의 원칙은 피드백을 포함하고, 단순성을 가정하고, 변화를 수용합니다.

기타 Feature-driven development (FDD), Adaptive system development (ASD), Dynamic Systems Development Method (DSDM), Crystal Clear 등의 방법론도 애자일 개발 방법으로 사용됩니다.

그럼 모든 소프트웨어 프로젝트에 지금까지 우리가 잘 알고 있는 Waterfall을 버리고 애자일 철학을 반영한 방법론을 사용하는 것이 필요할까요? 언제 이런 애자일 개발 방법을 선택하면 좋을까요?

Waterfall 이 필요한 경우

- 범위의 변경은 기대하지 않고 고정된 가격 계약으로 작업하고 있는 경우

- 프로젝트는 매우 간단하거나 여러 번 해본 적이 있는 경우

- 요구 사항은 잘 알려져 있고 고정되어 있을 때

- 고객이 원하는 것을 정확하게 미리 알고 있는 경우

- 질서 정연하고 예측 가능한 프로젝트로 작업하고 있는 경우

Scrume 이 필요한 경우

- 프로젝트 요구사항이 바뀌고 진화하는 경우

- 지속적인 피드백이 필요한 경우

- 프로젝트 팀이 자율성을 원하는 경우

- 정기적으로 소프트웨어를 제공해야 하는 경우

Kanban 이 필요한 경우

- 반복을 요구하지 않는 프로젝트

- 언제든지 배포 할 수 있는 것을 원하는 경우

- 팀이 변화를 선호할 때

- 팀의 배포 흐름을 개선하고 싶을 때

- 이해하기 쉬운 시스템을 찾고 있을 때

No silver bullet.

모든 프로젝트를 해결할 수 있는 유일한 소프트웨어 개발방법론은 없습니다. Waterfall, Scrum, Kanban, XP 등 다양한 소프트웨어 개발방법을 알고 우리팀에 좋은 방법을 찾아보고 서로 피드백하며 실행해가는 과정을 통해 조금씩 나아지는 것이 좋은 소프트웨어를 만들기 위해 필요한 것이며 저는 이것을 애자일이라고 부릅니다.

20180318_언제 애자일을 써야 좋을까.pdf

오픈소스와 특허

chaeya — Mon, 10 Jul 2017 11:34:51 +0900

최근 국가연구개발사업이 오픈R&D 형식으로 전환되는 움직임이 많아지면서 기존의 연구개발방식을 수행하던 사람들이 여러가지 질문을 하는데 그 중 자주 묻는 질문이 "오픈R&D를 하면 특허는 어떻게 하나요"라는 질문이다.

이 질문에 대한 결론부터 말하자면 "오픈소스로 배포하는 기술이라도 특허는 등록할 수 있다"이다.

이에 관련하여 공개SW역량프라자에서 얼마전 배포한 오픈소스 라이선스 해설서를 보면 다음과 같이 설명하고 있다.

우선 오픈소스 소프트웨어 진영에서는 모든 프로그램을 자유롭게 사용할 수 있도록 한다는 철학이기 때문에 특허를 반기지 않는다. 많은 오픈소스 커뮤니티는 소프트웨어의 일부 아이디어를 해당 특허로 등록한 후 특허 소송에 관여 시켜 소프트웨어 사용을 막아 수익을 올리려 하거나, 오픈소스 소프트웨어 개발을 법적으로 금하게 하는 특허, 오픈소스 개발자의 오픈소스 원칙을 약화 시키는 특허 등록에 대해서 걱정한다.

그러나 소프트웨어 특허에 대항하려는 오픈소스 소프트웨어 커뮤니티의 시도와 관계없이 소프트웨어 특허법은 존재하는 것이 현실이며 법을 준수하려면 특허 제약사항을 알고 대응해야 한다. 오픈소스 라이선스들은 이 필요성을 인식하고 존중하는 입장이며 오픈소스 라이선스들의 전문에는 특허조항이 권한부여 또는 권한취소에 대하여 여러 문장으로 표현되어 있다.

• 권한부여 라이선스(granting license)의 문맥에는 소프트웨어 일부분에 기여하고 배포하는 행위는 기여자, 배포자의 모든 특허가 전체 소프트웨어(다소 깊게 내포된 라이브러리를 포함) 사용에 필요한 “주어진 자유”라는 상황을 불명확하게 유발한다는 점을 고려해야 한다는 내용이 있다. 따라서 특허 포트폴리오의 핵심 특허 일부가 특허조항에 의해 피해를 받는지, 그리고 이에 따라 해당 오픈소스 소프트웨어 일부를 사용 또는 배포하지 말아야 하는지를 점검하고 싶다면 삽입된 라이브러리 역시 반드시 점검해야 한다.

• 권한부여 라이선스의 문맥에는 특허조항에 근거하여 ‘배포된 소프트웨어를 사용 가능하게 하기 위한 사용을 허용한다.’는 취지로 특허 사용만 허가되는지를 고려해야 한다. 특허조항은 일반적으로 특허를 양도하지 않는다. 이 때문에 오픈소스 소프트웨어에 의해 (고의적이지 않은) 특허 양도의 위협이 크지 않을 때(특허의 사용이 단지 소프트웨어의 결합에서만 부여되는 경우)도 있다. 특허 사용은 소프트웨어와 결합될 때만 권한이 주어진다. 한편 오픈소스 소프트웨어가 대규모의 프로세스에 내포 여부에 상관없이 오픈소스 소프트웨어를 사용하기 위해서는 특허 사용이 필요하기 때문에, 특허 사용 권한을 얻지 못하고는 오픈소스 소프트웨어를 사용하지 못할 수 있다. 반면 오픈소스 라이선스에 근거하여 허가된 오픈소스 소프트웨어가 없이 오픈소스 라이선스의 특허조항에 의해 양도된 특허를 사용할 수는 없다. 그 이유는 특허조항만이 오픈소스 소프트웨어 사용가능 여부를 나타내기 때문이다.

• 권한취소 라이선스에 의한 취소 형태는 어떤 경우에는 소프트웨어 사용 취소를, 또 어떤 경우에는 특허 사용 취소를 나타내는 것인지를 언급해야 한다. 그러나 자비로운 오픈소스 소프트웨어 사용자의 실용적 관점에서 볼 때 두 번째 경우의 특허 취소는 암묵적으로 소프트웨어 사용 권한을 해지한다고 판단할 수 있다. 특허 사용이 소프트웨어의 일부분을 법적으로 사용하기 위해 필요하다면 역시 특허 사용 권한을 갖지 않고 소프트웨어 사용이 허용될 수는 없다(그리고 특허 사용이 소프트웨어를 사용하는데 필요하지 않다면 이 특허는 특허조항이 적용되지 않는다). 따라서 이 유형의 특허조항은 소프트웨어 사용/배포 또는 수정하는 권한을 해지하는 것으로 보인다. 이런 이유로, 기업 또는 조직뿐만 아니라 단일 사용자들은 오픈소스 소프트웨어를 확실히 법률을 준수하면서 사용하고자 한다면 그런 특허조항을 중시해야 한다.

• 따라서 오픈소스 기여자와 배포자는 오픈소스 라이선스를 허가하는 것이 법적으로 소프트웨어를 사용하는데 필요한 모든 권한을 명시하지 않으면서도 저절로 허가하고 있는지, 권한취소 라이선스의 경우, 특허조항에 금지로 이해될 수 있는 부정적 조건이 있는지 고려해야 한다.

공개SW R&D 추진전략

chaeya — Wed, 22 Mar 2017 21:08:24 +0900

4차산업혁명이라는 단어가 정치, 마케팅, 기술 등 분야를 가리지 않고 확산되면서 국가 전체의 화두가 되어있습니다. 그러다보니 여러부처의 지원사업들이 4차산업혁명을 동반하고 쏟아지고 있죠.

4차산업혁명에서 활용가눙한 공개SW 기술이 다양하게 존재하는 덕분에, 여러 지원사업에서 공개SW라는 단어를 종종 만나게 되고, 요몇일동안은 공개SW R&D 추진전략에 대한 의견을 전달하게 되었습니다.

다들 연구개발 지원사업을 오랫동안 해 온 전문가들 이지만, 공개SW R&D의 유형은 일반적인 연구개발의 유형과는 다른 특징을 가지게 되고 준비해야하는 내용도 다를 수 밖에 없습니다. 이번에 의견을 전달하면서 달라진 연구개발의 요구사항에도 불구하고 사업계획을 준비할 수 있는 기초 정보가 부족해서 많은 분들이 어려움을 겪는 것을 알게 되었고 그 과정에서 자료를 좀 정리해야할 필요성을 느끼게 되어서 새 글을 작성합니다.

https://www.slideshare.net/AhmadRb/iem2014-foss

일단 정부의 지원사업에서 공개SW R&D를 한다는 취지를 생각해보면, 1) 사업을 수행하는 동안 기존의 인하우스 개발방식이 아닌 참여와 공유를 통한 공개SW 개발방식을 경험하면서 공개SW 기술의 역량이 축적되고 2) 열심히 노력한 사업의 결과물을 공개SW로 누구나 사용할 수 있게 배포함으로서 산업 활성화에 기여하는 것을 기대하는 것이라 생각합니다.

먼저 지원사업을 발주하는 입장에서는 사업의 선정지표에 공개SW R&D에 대한 준비가 가능한 평가항목을 좀 더 구체화해야 할 것 같습니다. 단순히 '공개SW R&D에 대한 추진방안' 정도로 표현하면 공개SW R&D 사업의 경험이 없이 사업을 준비하는 입장에서는 의도를 파악하기가 어렵습니다. 따라서 어떤 지원자가 참여하면 좋을지 생각하고 있는 의도를 표현할 수 있도록 보다 구체적인 서술을 포함하는 것이 좋겠습니다. (공개SW에 대한 이해, 공개SW R&D 환경, 결과물의 공개SW 라이선스와 배포 방안, 공개SW R&D 관련 경험 등)

뿐만 아니라, 사업의 결과 평가 시점에서도 공개SW로 배포될 결과물에 대하여 평가할 항목을 선정하여 공개SW로 배포되는 사업결과물의 활용을 극대화 하려는 노력이 필요해 보입니다. 공개SW는 특성상 공개SW 커뮤니티를 통하여 배포되고 성장하기 때문에 다운로드수, 홈페이지 방문자수 같은 수치가 아닌 여러가지 공개SW 고유의 지표들을 이용할 수 있고, 공개SW 자체에 대한 성숙도 평가를 하고자 하는 시도 역시 Qualipso OMM, OpenBRR, QSOS, 공개SW 성숙도 및 적용성 평가지침 등이 존재합니다. 따라서 사업의 평가 시점에도 이를 반영하기 위한 노력이 필요하다고 생각됩니다.

또한 사업을 지원하는 입장에서는 어떠한 공개SW R&D 방식을 사용할지, 개발환경은 어떻게 준비할지, 개발과정에서 외부의 참여를 받아들일 준비는 어떠한지, 커뮤니티화 운영을 할때 필요한 거버넌스는 준비되어 있는지, 배포할 결과물에 대한 라이선스 관리전략은 무엇인지 등의 고민을 사전에 해보고, 특허나 기술이전으로 실적을 이야기하던 방식에서 벗어나 공개SW의 특성을 반영한 활용방안과 비즈니스 가능성을 고민하여 제시하는 노력이 필요합니다.

공개SW산업에서 일을 하는 입장에서 보면, 기존의 정부지원사업에서 혁신을 가져온 공개SW R&D 방식 시행되는 것을 대단하게 생각하고 있습니다. 여러가지 부정적인 결과들을 예상할 수 도 있지만, 그 또한 변화의 긍정적인 신호라고 생각합니다. 어찌되었던 이런 좋은 의도의 지원사업을 통해 많은 사람들이 쉽게 기술에 접근해서 아이디어를 구현해보기 좋은 세상이 되었으면 좋겠네요.

4차산업혁명과 오픈소스거버넌스

chaeya — Sat, 18 Mar 2017 16:41:17 +0900

티스토리에 정착하여 글을 쓰기 시작한지 10년째 되었네요.

계속해서 매월 한 개 이상의 글을 적어왔는데, 최근 몇 년 동안은 포스팅을 거의 못했습니다.

시간이 지나고 업무경험이 쌓일수록 생각은 많은데 글을 쓰는 건 더 조심스러워 지네요.

오늘은 4차산업혁명에 대한 이해와 오픈소스는 어떤 역할을 하는지 생각해 보겠습니다.

마이클 포터 교수는 IT가 3번에 걸쳐 큰 변혁의 물결을 가져오고 있다고 이야기 합니다.

- 제 1 물결은 1960년대부터 70년대까지 주문처리나 경비지급, CAD, 생산관리 등 가치사슬의 개별활동을 자동화하면서 기존 수작업에 비해 비즈니스 생산성이 크게 향상.

- 제 2 물결은 1980년대 상용 인터넷이 탄생하고 90년대등러 고속 대용량화와 저가화가 진행되면서 인터넷을 통해 컴퓨터간 쉬운 연결이 가능.

- 제 3 물결은 최근에 나타나는 현상으로 제품에 센서와 프로세서, 소프트웨어, 연결 기능등이 내장되어 제품이 만들어 내는 데이터가 클라우드에서 수집, 분석되어 제품의 기능과 성능을 크게 향상.

이러한 제 3의 물결의 제품을 포터는 스마트 커넥티드 제품이라고 부르며 모니터링, 제어, 최적화, 자율성의 4단계로 구분되는 역량모델을 이야기합니다.

마이클 포터의 이러한 전망에 대해 PTC의 헤플만은 스마트 커넥티드 제품을 실현하기 위해서는 제품, 연결기능, 제품 클라우드, 보안기능, 외부 게이트웨이, 업무 시스템과 통합 등으로 구성된 새로운 기술 스택이 필요하다고 이야기 합니다.

제가 이해하고 있는 4차산업혁명은 온라인과 오프라인이 연결되는 온디멘드 서비스 유형에서 나아가, 모든것이 연결된 세상(IoT), IoT 로 수집되는 데이터의 CPS(Cyber-Physical System)에서 분석, 분석에서 나아가 기술과 사람의 의사결정력이 결합된 의사결정체계가 각 산업에서 분산을 통한 의사결정의 위임을 담당할때 성공적인 모습이라고 생각합니다. 따라서 많은 기업들이 자사의 제품 가치에 대한 높은 이해와 수집되는 데이터 분석기술에 대한 융합이 가능한 전문가를 요구하고 있으며 CDO(최고데이터책임자)를 둔 기업도 출현하고 있습니다.

IT 기업의 입장에서 보면 향후 4차산업혁명의 물결에 대응하기 위해서는 다양한 디바이스간의 연결이 가능한 기술(IoT framework, gateway, network protocol), 데이터를 수집하고 분석하는 기술(Bigdata analysis architecture, 분산파일시스템 응용기술), 데이터 기반 실시간 의사결정기술(AI, context decision making) 등이 중요하게 대두 될 것이라 생각됩니다.

현재 이러한 중요 기술들은 국내에서 원천기술을 확보하고 있는 경우가 거의 없으며, 대부분의 핵심기술은 오픈소스 프로젝트에서 제공됩니다. 따라서 앞으로는 시장에서 오픈소스를 활용한 기술개발이 더욱 심화될 것이고 기업에서 오픈소스 활용 거버넌스를 제대로 준비하고 않아서 발생되는 문제점도 커질 것입니다.

때문에 향후 4차산업혁명의 성공을 위해서 조직은 오픈소스 기술에 대한 경험 축적과 함께 오픈소스 거버넌스의 조직 내 구축이 함께 되어야 할 것입니다.

해외 기업들의 오픈소스 활용 비즈니스 전략

chaeya — Thu, 27 Oct 2016 20:20:44 +0900

최근 해외 기업들의 오픈소스 활용을 어떻게 하는지 살펴보면 모든 기업이 오픈소스 모델의 다양한 가치를 인식하고, 오픈소스 커뮤니티에 적극적으로 참여하고, 오픈소스 기반의 비즈니스 모델을 발견하려는 노력이 점차 강화되는 추세입니다. 이번에 자료를 정리하면서 여러 기업의 비즈니스 전략을 구분해 보았습니다.

기업들의 오픈소스 활용 전략들을 살펴보면 크게 4가지 유형으로 구분할 수 있습니다

1) 자사의 기술이나 서비스를 오픈소스 모델로 전환하여 타사와 경쟁할 수 있는 파괴적 전략으로 채택

2) 고객의 제품이나 서비스의 완성을 위한 전문성을 오픈소스 모델로 지원하는 전략

3) 오픈소스 개발, 배포모델을 기업 비즈니스 목표 달성을 위해 활용하는 전략

4) 오픈소스의 부가적인 가치를 기업 경영에 활용하는 전략

1) 전통적 SW개발 기업이 자사의 기술이나 서비스를 오픈소스 모델로 전환하여 타사와 경쟁.

- 듀얼 라이센싱 모델이나 코어 오픈모델을 사용하는 등 지적산출물에 대한 접근 통제를 가치로 파는 전략

- MySQL과 sleepycat(버클리 DB)가 듀얼 라이센싱으로 유명. 즉, GPL 버전은 무료로 쓰지만, non-GPL버전을 쓰려면 돈을 내야 한다. 소프트웨어를 Embed 해서 재판매 하려는 회사에 해당된다.

- Xen, SugarCRM 과 같은 회사에서는 코어 오픈모델을 사용. 즉, 코어는 공짜로 풀고 부가기능은 돈을 받고 파는 모델이다. 여기서 “판매가치”는 “특화 기능 (Differentiated Features)”들이 만들어 낸다.

- 보통 듀얼라이센싱을 하기 위해서는 오픈소스에 대한 판권을 가져야만 한다. 즉, 코어 개발자를 직접 고용해야 한다는 것을 의미한다. 즉, 개발력이 내재화되어 있으면, 코어를 오픈소스로 풀기도 하고 GPL버전을 만들어서 뿌리는 것도 자유롭다.

2) 전통적인 SW개발 모델이 아닌, 고객을 위한 분산된 컴포넌트의 통합을 교육훈련과 지술지원으로 돕는 오픈소스 전문 비즈니스 전략

- 소프트웨어 회사들은 자사의 개발과 산출물들이 조직 밖으로 나와도, 여전히 회사가치가 남아 있는가에 대한 불안이 존재한다. 하지만 Dixon, Pentaho, RedHat, OpenGeo 등의 회사들은 오픈소스 커뮤니티가 만들어내는 소프트웨어를 팔릴만한 물건으로 만들기 위해 가치를 더해줌으로써 선순환 구조를 완성시킨다. 그리고 그 이익으로 다시 개발자와 스태프를 고용하고 오픈소스 커뮤니티가 새로운 가치를 계속 만들어내도록 지원한다.

- 이런 기업들은 실질적인 코어 개발자들을 물리적으로 보유함으로써 지적 자산을 보호해준다.

3) 오픈소스 개발, 배포모델을 기업 비즈니스 목표달성을 위해 활용

- 기업의 이익을 위해 선별적으로 오픈소스 소프트웨어를 선택하는 이른바 체리 피킹(cherry-picking:선별적 경쟁) 전략을 의미.

- 근간 기능(Commodity Features)은 소프트웨어의 프레임워크으로 뼈대를 형성하는 것이므로 전체 소프트웨어의 중요 부분을 차지하는 경우가 많다. 일반적으로 근간 기능(Commodity Features)은 비용과 시간 절감 및 OSS 사용층 유입의 장점이 있기 때문에 OSS로 구현되는 경우가 많다. (예) 빅데이터 플랫폼 Apache Hadoop)

4) 오픈소스의 부가적인 가치를 기업 경영에 활용

4-1) 오픈소스에 대한 공유와 협업으로 기업 이미지 마케팅 가시성 확보

- 최대 규모의 사유 소프트웨어 기업인 MS조차도 다양한 오픈소스 기여 활발하게 진행 중

아직 관련 매출을 발표한 적이 없음에도 불구하고 오픈소스 계획을 발표한 후로는 1억 달러로 우리가 얻을 수 있었던 것보다 더 많은 마케팅 가시성을 확보하게 됐다. - 아이오나 CEO 피터 조토(Peter Zotto)

4-2) 기업 내 조직운용의 실용성을 오픈소스를 통해 확보.

- 중소 벤처기업 아라스(Aras)는 MS기술로만 작성된 자사의 PLM(Product Lifecycle Management)기술을 오픈소스화 한 이후 영업직을 없애고 그 자리에 고객의 중요한 요구사항에 대한 서비스를 제공할 애플리케이션 엔지니어들을 추가했다.

4-3) 오픈소스를 활용한 소프트웨어 개발의 변화

- 오픈소스는 소프트웨어 산업에서 오랜 시간 논의 되었던 재사용, 재공학 등의 문제를 신뢰도 높은 소프트웨어의 재활용, 개발자의 전문성 강화, 오픈소스 개발프로세스의 활용 등 상당 부분 해결해주고 있다.

- 기업들은 공유와 협업이라는 오픈소스 문화의 적극적 도입으로 소프트웨어 개발 문화도 애자일, 린 개발법 등 다양하게 변화되고 있다.

최근의 기업 동향을 살펴보다 느끼는 점인데 예전과는 참 많이 달라진 모습이더군요. 저는 오픈소스가 시장에서 점점 더 많은 역할을 할 것을 기대하는 쪽이라 이런저런 재미있는 생각을 많이 하고 있습니다. 개발자에서 출발해서 지금은 개발보다는 다른 일을 더 많이 하는 자리가 되었지만 초심을 잃지 말고 제 나름대로의 방식으로 보다 좋은 세상을 위해서 기여하며 살고 싶다고 생각해봅니다.

오픈소스 거버넌스

chaeya — Thu, 29 Sep 2016 21:32:16 +0900

지난 몇년간 오픈소스 거버넌스 이야기를 많은 분들과 나누면서 가장 많이 들은 이야기는 '그건 진정한 거버넌스가 아니죠, 제가 아는 거버넌스랑 다른데요' 였습니다. 그외에도 '그게 뭐예요' 또는 '괜히 그런 거 하지 마시지' 등의 이야기도 여러 번 있었습니다. ㅎㅎ

사무실에 혼자 앉아서 이런저런 자료를 만들다가 한번 정리해보고 넘어가야지 하는 생각에 또 글을 적네요.

위키피디아를 보면 거버넌스라는 단어는 1980년대부터 대두된 통치 시스템의 개념으로 아직 정의에 대한 학문적 합의는 이루어 지지 않았다고 합니다.

그래서인지 다양한 목적으로 다양한 분야에서 거버넌스라는 단어가 사용되고 있습니다.

예를 들면, 뉴 거버넌스, 기업 거버넌스, IT 거버넌스, 정보보안 거버넌스 등이죠.

때문에 거버넌스에 대한 해석이 혹자는 정치 철학으로 혹자는 조직 관리 방법으로 해석하는 것도 당연한 일이겠죠.

저는 몇년동안 여러 전문가 분들과 오픈소스를 기업과 공공이 어떻게 써야 좋을지에 대해서 고민해왔는데 그 결과물이 예전에는 도입가이드, 적용가이드 등에서 현재는 공개SW거버넌스가 되었습니다. 목적은 변하지 않았는데 좀 더 세련된 이름으로 불리게 되었죠.

지금의 저는 공개SW거버넌스를 이렇게 정의하고 있습니다.

공개소프트웨어를 안전하게 사용·적용 및 배포하기 위해 필요한 사항을 다양한 관점에서 활용할 수 있도록 소프트웨어 라이프 사이클 단계별로 제시한 틀

거버넌스라는 단어가 아직 대중적이지 못한 단어이기에 정리해서 자료를 만들었습니다만, 그 이름이 무엇이라고 불리던 간에, 오픈소스를 사용하는 사람들에게 필요한 자료가 되기를 바랍니다.

공개SW거버넌스(개요) from Kevin Kim

애자일 이야기

chaeya — Sun, 25 Sep 2016 21:40:58 +0900

일요일이라 밀린 일을 하러 사무실에 나왔다가 불현듯 셀프회고를 하게 되어서, 생각난 참에 예전 자료를 정리해봤습니다. 일하러 왔다가 딴길로 샌 하루네요 ㅎㅎ

예전에는 기술에 대한 관리업무가 저의 주 업무였는데 최근 몇년동안에 경영 전반에 대한 시야가 필요한 업무를 더 많이 하게 되었습니다. 지금 책상위의 내용을 보니 예전에 다루던 주제들이 많이 바뀌었다는걸 알 수 있네요.

사실 갑자기 애자일에 대한 기록을 돌아보게 된 것은 얼마전 링크드인을 통해서 모회사의 스크럼마스터 자리에 대한 제안이 있었습니다. 덕분에 정신없이 달려오던 지난 몇년을 돌아보게 되었죠.

오늘은 애자일에서 제가 배운것과 여전히 남은 것에 대한 이야기입니다.

저의 애자일에 대한 시작을 더듬어보니 2006년 즈음에 켄트벡의 글을 만나면서 시작되었던 것 같습니다.

이 책을 통해 비슷한 고민에 대한 좋은 이야기를 접한 다음, 켄트벡, 김창준 이라는 키워드에서 TDD, 디자인패턴, 사용자스토리, 회고, xper 등으로 확산되었습니다.

애자일 프랙티스들을 여러 방식으로 적용해 보면서 익히고, 저의 주 업무가 변경되면서 그 과정에서 이런저런 현실적인 문제들을 만나서 현재 저에게 남은 것을 살펴보면 회고와 스크럼 보드 그리고 철학이네요.

우리는비슷한문제를풀고싶어하는다른이들과협업을즐기고, 개발하는내용을오픈소스화하고커뮤니티와정보를공유하며, 애자일한고객접근을통해고객의만족도를높이려고노력합니다

위의 글은 현재 회사의 웹사이트에 적어 둔 소개 내용입니다.

애자일이 저에게는 큰 영향을 주었던 것이 분명하고, 많은 것을 배웠습니다. 예전처럼 기술에 대한 고민은 자주 하지 못하지만 기업의 경영에서도 그 정신을 항상 잊지 않으려고 합니다.

애자일이야기 from Kevin Kim

공개SW 개발자대회 멘토링 이야기

chaeya — Sun, 3 Aug 2014 21:55:05 +0900

주말에 공개SW 개발자대회 참가자를 위한 멘토링이 토즈에서 있었습니다.

다른 참가자 분들에게도 도움이 될지 모르니, 제가 멘토링한 부분에 대해서 정리해서 공유해 두려고 합니다.

제가 준비해간 멘토링의 진행순서는 다음과 같습니다.

1) 참가자 현황분석

2) 대회를 위해서 준비할것 협의

3) 멘토링에서 얻고 싶은 목표 합의

4) 멘토링

5) 향후 멘토링 계획안 협의

제가 담당한 멘티들의 현황을 분석한 결과는 다음과 같습니다.

A팀)

- 보안기술동향을 분석하지 않은 낮은 기술성

- SW의 가시성 확보 필요

- 불확실한 개발 일정 계획

- 개발문서의 미흡

B팀)

- 공개SW를 이용한 비즈니스시 위험관리

- 공개SW 커뮤니티를 활용한 비즈니스 방법

- 비즈니스를 위한 공개SW 라이선스 컴플라이언스 방안

C팀)

- SW의 가시성 확보 필요

- 개발문서의 미흡

- SW품질에 대한 이해 부족

각각의 이슈에 대하여 제가 취한 조치는 아래와 같습니다.

기술동향 : 최근의 보안기술동향 및 관련사이트 소개

SW의 가시성 : 정적분석도구에 대한 소개 및 활용법, 테스트 커버리지에 대한 가이드, 유닛테스트 및 테스트자동화 안내

개발문서 : 개발방법론 소개 및 개발 산출물 관리방안 가이드

공개SW 비즈니스 위험관리 : 공개SW를 기반으로 외부서비스를 하는 기업의 경우에 필요한 거버넌스 체계소개

공개SW 커뮤니티 운영 : 공개SW 커뮤니티 운영유형 및 필수요소 가이드

라이선스 컴플라이언스 : SW 라이선스 유형 소개 및 활용방안 제시.

짧은 시간에 전달하기에는 내용이 많이 부족했기 때문에 각 팀별로 멘토링 내용을 메일로 전달해주고, 향후 멘토링 가능한 일정계획을 제시해주고 마무리했습니다.

부족한 시간때문에 멘토링에 대한 회고를 하지 못해서 아쉬움이 남네요.

IT 기획 전문가 학습로드맵

chaeya — Sat, 16 Nov 2013 03:22:29 +0900

얼마전부터 IT 기획을 배우고 싶은 주변 사람들끼리 모여서 매주 스터디를 하고 있습니다. 스터디 첫날에 각자가 생각하는 기획이란 무엇인가에 대해서 이야기 하는 시간이 있었는데, 기획이라는 단어는 다양한 계층에서 다양한 관점으로 해석이 되고 있더군요.

다음 중 누가 기획자로 적절한지 한번 골라보세요.

1) 계획을 세우는 사람이라는 의미의 플래너(Planner)

2) 팀원을 조직화하고 조율한다는 의미의 코디네이터(Coordinator)

3) 제품의 원형이 되는 아이디어를 내놓고 이를 구체적으로 설계한다고해서 디자이너(Designer)

4) 제품의 질적 기준을 제시하고 이를 감독한다고 해서 디렉터(Director)

5) 전체 프로젝트를 성공으로 이끌수 있도록 관리하고 총괄한다는 의미에서 프로듀서(Producer)

6) 제품을 총괄 관리한다는 의미의 프로덕트 매니저(Product Manager)

제품 기획 또는 서비스 기획을 IT 기획자라고 이야기 할 수도 있지만, 제가 생각하는 IT 기획은 그것보다는 좀 더 광의의 의미이며 그 내용을 정리해 보고 학습 로드맵을 정리해 보려고 합니다.

1. IT 기획의 정의

기획(企劃)이란 단어의 뜻을 네이버에서 확인하니 아래처럼 나오네요.

국어사전 : 일을 꾀하여 계획함.

행정학사전 : 어떤 대상에 대해 그 대상의 변화를 가져올 목적을 확인하고, 그 목적을 성취하는 데에 가장 적합한 행동을 설계하는 것을 의미

기획이란 보다 효과적이고, 효율적으로 목표달성을 하기위해 가장 적합한 행동을 설계하는 것을 의미한다고 할 수 있고, IT 기획이란 IT의 목표를 달성하기 위한 적합한 행동을 설계하는 것이라고 할 수 있겠죠.

그럼 IT의 목표는 무엇일까요?

IT의 목표는 비즈니스를 돕는 IT와 IT 제품/서비스를 제공하는 IT 본연의 비즈니스 관점으로 생각해 볼 수 있습니다.

첫번째, 비즈니스를 돕는 관점에서 보면 기업은 업무를 지원하는 역할을 IT에 기대하고 MIS, EIS, SCM, CRM 등의 분야에 IT 기술을 활용합니다. IT 기술을 업무 지원에 사용하거나, 원가절감과 시간단축을 기대하고 IT를 사용하는 유형입니다.

두번째, IT 본연의 관점에서 보는 경우는 IT 기술을 이용하여 제품이나 서비스를 판매하거나, IT 서비스 또는 프로젝트 중심의 비즈니스를 통하여 수익을 발생시키는 유형입니다.

이 두가지 유형의 기업들은 IT를 통하여 새로운 비즈니스 창출을 통해 신규수익을 발생 시키거나, 경쟁우위 무기로 활용 기존의 매출을 증대시키거나, 내부혁신 촉매로 활용하여 업무 생산성을 증대하는 것이 주요 목적이 됩니다.

따라서 IT 기획이란 IT를 통한 신규 비즈니스의 창출, 경쟁우위로 활용, 내부혁신의 촉매로 활용하기 위한 적합한 행동을 설계하는 것을 의미합니다.

2. IT 기획의 대상

IT의 목표를 달성하기 위한 IT 기획업무의 대상은 아래의 3가지로 구분할 수 있습니다.

1) 전략

2) 사업

3) 제품/서비스

전략을 수립하기 위해서는 전체 경영진이 경영 목표를 명확하게 이해해야 하고, 그 전략을 토대로 각각의 사업이 기획되며, 제품/서비스도 사업에 적합하게 기획되어야 합니다. 각 영역에 필요한 기술과 지식이 별도로 필요하며 각 계층은 상호 긴밀하게 연관성이 있습니다.

3. IT 기획 전문가 학습 로드맵

각 부문별 학습 로드맵은 다음과 같이 구성될 수 있습니다.

1) 전략 부문

- 어떻게 효과적으로 정보기술을 연계하고 적용할 것인가에 대하여 전략 및 해결책을 찾고 실행계획을 수립하는 과정 : 정보화 전략 계획 수립(ISP: Information Strategy Planning)

- IT 체계에 대한 효과적인 분석 및 활용 기법 : EA(Enterprise Architecture)

- 비즈니스 프로세스에 대한 효과적인 개선안 수립 기법 : BPR (Business Process Re-engineering), PI (Process Innovation)

2) 사업 부문

- 환경분석

- 업무분석

- 문제해결/이슈분석 기법

- 조사방법 활용

- 변화관리방법론

- 전략개발방법론

- 리스크 관리방법론

3) 제품/서비스 부문

- 제품/서비스 및 산업에 대한 이해

- 제품/서비스 기획 프로세스 지식

- 제품/서비스 기획 점검

- 제품/서비스 기획 리뷰

- 제품/서비스 기획 평가방법

Vagrant 이용한 LAMP+Tomcat 개발환경구축

chaeya — Mon, 4 Nov 2013 18:50:21 +0900

Vagrant는 쉬운 개발환경의 구성을 도와주는 오픈소스로서 팀내의 개발환경을 동일하게 유지해야 할 경우 유용하게 사용할 수 있습니다.

오늘 새 노트북에 개발환경을 구축하기 위해서 Vagrant를 이용하여 설치할 일이 있었기에 진행 과정을 남겨두려고 합니다.

개발환경은 CentOS 6.4 + Apache 2.2.15 + MySQL 14.14 + PHP 5.3.3 + Tomcat 6-6.0.36 로 구성되었습니다.

1) 필수 환경 구성

먼저 자신의 환경에 맞는 아래의 프로그램을 각각 설치합니다.

- VirtualBox : https://www.virtualbox.org/

- Vagrant : http://downloads.vagrantup.com/

2) 가상이미지(box) 설치

- 저는 손에 익숙한 centos 64bit 를 설치하기로 했습니다.

- 다른 이미지를 사용하고 싶은 경우 http://www.vagrantbox.es/ 참고하세요

우선 box 설치

// 형식 : vagrant box add [title] [download-url]

$ vagrant box add centos64 http://developer.nrel.gov/downloads/vagrant-boxes/CentOS-6.4-x86_64-v20130427.box

box 초기화

$ vagrant init centos64

초기화 하고 나면 Vagrantfile 이라는 환경설정 파일이 생깁니다.(제 경우는 C:\Users\Administrator 안에 있네요.)

어디있는지 모를때는 링크를 참고하세요. http://docs.vagrantup.com/v2/vagrantfile/index.html

box 구동하기

$ vagrant up

box 재구동

$ vagrant reload

box 종료

$ vagrant halt

그리고 예상하시는 것처럼 vagrant help 명령으로 더 많은 내용을 확인할 수 있습니다.

vagrant up 명령으로 구동을 마치면 ssh 클라이언트로 접속해서 사용할 수 있습니다.

ssh 호스트는 localhost 포트는 2222

id : vagrant/ pw : vagrant

3) apache, tomcat, mysql, php 환경구성

- httpd 설치

$ yum install httpd httpd-devel

- php 설치

$ yum install php

- mysql 설치

$ yum install mysql-server mysql

- php mysql 연동

$ yum install php-mysql

- java 설치

$ yum install java-1.6.0-openjdk.x86_64

- tomcat6 설치

wget http://jpackage.org/jpackage50.repo -O /etc/yum.repos.d/jpackage50.repo

$ yum install tomcat6 tomcat6-admin-webapps tomcat6-webapps

설치후 JAVA_HOME 설정

vi /usr/share/tomcat6/conf/tomcat6.conf

JAVA_HOME="/usr/java/jdk1.6.0_45" (각자의 환경에 맞는 JAVA_HOME을 설정해야 합니다.)

4) Vagrantfile 환경설정

- Vagrantfile 에서 apache, tomcat, mysql 포트 포워딩 설정을 아래처럼 변경해 줍니다.

# guest : vm 머신의 포트 / host : local 포트

# 아래와 같이 설정하면 localhost 33306 으로 접속할때 vm 머신 3306으로 접속된다.

config.vm.network :forwarded_port, guest: 3306, host: 33306

# httpd

config.vm.network :forwarded_port, guest: 80, host: 8000

# tomcat6

config.vm.network :forwarded_port, guest: 8080, host: 9999

설정을 마쳤으면 재 구동합니다.

5) 설치확인

- 테스트 파일을 만들어서 확인해 줍니다.

vi /var/www/html/info.php

<?php phpinfo(); ?>

http://localhost:8000/info.php

http://localhost:9999/

기타) box와 운영OS의 파일공유

- 설치 후 가상이미지 상의 /vagrant 디렉토리는 윈도우(내 경우)의 C:\Users\Administrator 폴더와 연결되어 있으니 개발 PC와 이미지의 파일공유가 필요하신 경우 사용하시면 됩니다.

- 폴더 공유 관련 설정은 다음 링크 참고. http://docs.vagrantup.com/v2/synced-folders/basic_usage.html

* 접속 문제가 있는경우 iptables 를 변경하거나 중지해 보세요.

도메인 SRV 레코드

chaeya — Mon, 28 Oct 2013 21:28:14 +0900

Microsoft Office 365 서비스를 사용하기 위해서 DNS 설정을 변경하는 일이 있었습니다.

DNS 필드 중 SRV 레코드에 대해서 값을 추가해달라는 요청이 있었는데 SRV 레코드가 어디에 사용되는지 모르겠더군요.

제가 찾아본 내용을 정리합니다.

영문에 익숙하다면 http://en.wikipedia.org/wiki/SRV_record 를 참고하시기 바랍니다.

SRV 레코드는 SRV(서비스 로케이터) 리소스 레코드입니다. 유사한 TCP/IP 기반 서비스를 제공하는 여러 서버를 단일 DNS 쿼리 동작을 사용하여 찾을 수 있게 합니다. 이 레코드를 사용하여 잘 알려진 서버 포트 및 전송 프로토콜 종류에 대한 서버 목록을 DNS 도메인 이름의 우선 순위로 정렬하여 관리할 수 있습니다.

zone 파일의 설정구문) service.protocol.name ttl class SRV preference weight port target

설정 예) ldap._tcp.contoso.msft 600 in srv 0 100 389 london.contoso.msft

s p n t c p w p t

설명)

service : 서비스를 위한 이름 정의

protocol : 프로토콜 정의

name : 레코드에 의해서 참조되는 도메인 이름 정의

ttl : 표준 DNS 레코드의 time to live의 정의

class : 표준 DNS의 레코드 클레스의 값 정의

priority : 호스트 우선 순위 정의

weight : 로드밸런싱 메카니즘을 위한 정의

port : 호스트에서 서비스 하기 위한 포트정의

target : 서비스를 제공하는 호스트의 FQDN 정의

SRV 리소스 레코드의 상세한 설명은 아래를 참고하세요.

service

원하는 서비스의 심볼 이름입니다. 잘 알려진 서비스의 경우 RFC 1700에 "_telnet" 또는 "_smtp"와 같은 예약된 유니버설 심볼 이름이 정의되어 있습니다. 잘 알려진 서비스 이름이 RFC 1700에 정의되어 있지 않으면 대신 로컬 또는 사용자 기본 설정 이름을 사용할 수 있습니다. 널리 사용되는 일부 TCP/IP 서비스, 특히 POP(Post Office Protocol)에는 단일 유니버설 심볼 이름이 없습니다. RFC 1700에서 이 필드에 표시된 서비스의 이름을 할당하면 RFC 정의 이름만을 사용할 수 있습니다. 로컬로 정의된 서비스만 로컬로 이름을 지정할 수 있습니다.

protocol

전송 프로토콜 종류를 나타냅니다. RFC 1700에서 이름을 지정한 모든 전송 프로토콜을 사용할 수 있지만 주로 TCP나 UDP가 됩니다.

name

이 리소스 레코드에서 참조하는 DNS 도메인 이름입니다. SRV 리소스 레코드는 검색이나 쿼리를 수행하는 데 사용되지 않는다는 점에서 다른 DNS 레코드 종류와 다릅니다.

priority

target 필드에 지정된 호스트의 우선 순위를 지정합니다. SRV 리소스 레코드를 쿼리하는 DNS 클라이언트는 여기에 나열된 가장 낮은 번호로 우선 순위가 지정된 호스트 중 연결 가능한 첫째 호스트에 접속을 시도합니다. target 호스트의 우선 순위 값이 같은 수준인 경우에도 임의 순서로 접속을 시도할 수 있습니다. 우선 순위 값 범위는 0에서 65535입니다.

weight

target 필드에 여러 서버가 지정되어 있고 모두 같은 우선 순위 수준으로 지정되어 있는 경우 로드 균형 조정 메커니즘을 제공하기 위해 기본 설정 이외에도 이 필드가 사용됩니다. 동일한 우선 순위 수준 중에서 대상 서버 호스트를 선택하는 경우 이 값을 사용하여 응답을 받은 SRV 쿼리에 사용되는 대상 호스트의 정확한 순서와 선택 균형 조정을 결정하는 데 사용할 수 있는 추가된 우선 순위 수준을 설정할 수 있습니다. 0이 아닌 값이 사용되면 이 값의 크기에 비례하여 이 값과 우선 순위가 같은 서버가 시도됩니다. 값 범위는 1에서 65535입니다. 로드 균형 조정이 필요하지 않으면 이 필드에 0을 사용하여 레코드를 읽기 쉽게 합니다.

port

service 필드에 표시된 서비스를 제공하는 target 호스트의 서버 포트입니다. 서버 포트 번호에는 흔히 잘 알려진 할당된 서비스 포트 번호가 사용되지만 포트 번호의 범위는 RFC 1700에서 지정한 대로 0에서 65535입니다. 필요에 따라 할당되지 않은 포트를 사용할 수 있습니다.

target

요청된 서비스 종류를 제공하는 호스트의 DNS 도메인 이름을 지정합니다. 사용된 호스트 이름 각각에 해당하는 호스트 주소(A) 리소스 레코드가 DNS 네임스페이스에 있어야 합니다. 이 필드에 마침표(.) 하나를 사용하여 이 DNS 도메인 이름에서 이 SRV 리소스 레코드에서 지정한 요청된 서비스가 가능하지 않음을 명백하게 나타낼 수 있습니다.

오픈소스SW 라이선스 LGPL 바로알기

chaeya — Thu, 24 Oct 2013 20:25:33 +0900

오늘 페이스북 타임라인을 읽다보니 '리눅스 HWP 공개 라이브러리 개발' 건에 대한 라이선스 이야기를 하는 글들이 보이네요. 저도 예전에 FCKEditor를 적용한 제품때문에 LGPL의 정체가 뭔지 몰라서 어려웠던 기억이 납니다. 글타래를 읽다보니 LGPL에 대해서 애매한 이야기들이 좀 있는것 같아서 정리해봅니다.

1. 공통적으로 지킬 것

일단 OSI(Open Source Initiative)에 등록되어 있는 오픈소스SW 라이선스는 GPL이건 LGPL 이건 상관없이 공통적으로 지켜야 하는 내용이 두가지 있습니다.

나. 제품명 중복 방지

- 아파치, 리눅스 같은 프로젝트명을 선택하면 안된다는 의미입니다.

두 가지 모두 무엇인가를 직접 만들어본 사람이라면 상식적인 수준에서 지켜야 하는 것이죠.

2. LGPL 라이선스를 가져다 쓰는데 소스코드를 공개해야만 하나요?

LGPL은 GPL의 조건이 너무 엄격해서 사람들이 쓰는 것을 꺼려할까봐 이를 감안해서 만든 라이선스 입니다. 따라서 GPL과는 다르게 LGPL 라이브러리에 응용프로그램을 정적 혹은 동적으로 링크시킨다고 해도 응용프로그램의 소스코드를 공개할 필요가 없습니다. LGPL 전문에 있는 ”라이브러리의 복제본을 무상이나 유상으로 배포할 경우에, 당신은 우리가 당신에게 부여한 모든 권리를 수취인에게도 그대로 부여해야 한다.“라는 내용으로 요구 조건만 준수한다면 상업적인 유상 배포도 허용하고 있습니다. 따라서 자기가 만든 소스코드의 공개없이 가격을 받는 상용제품으로 판매하셔도 됩니다.

다만, LGPL 라이브러리의 소스코드를 수정하였을 때에는 2차적 파생 저작물에 해당하므로 라이브러리의 소스코드를 제공해야 합니다.

3. LGPL을 가져와서 개발하고 GPL 라이선스로 변경해도 될까요?

대답은 변경해도 됩니다. 아래 내용을 보시면 "양도받은 라이브러리의 복제물에 본 라이선스 대신 GNU 일반 공중 라이선스의 규정들을 적용시킬 수 있다"라고 표기되어 있습니다. 하지만 GPL 소스코드를 가져와서 임의로 LGPL로 변경하는 것은 안됩니다.

http://olis.or.kr/ossw/license/license/detail.do?lid=1005&mapcode=&currentPage=

제3조.
당신은 양도받은 라이브러리의 복제물에 본 라이선스 대신 GNU 일반 공중 라이선스의 규정들을 적용시킬 수 있다. 이를 가능케 하기 위해서는 본 라이선스를 언급하는 모든 사항들을 GNU 일반 공중 라이선스 버전2의 사항들로 대체시켜야 한다. (만약 GNU 일반 공중 라이선스 버전 2 이후에 신규 버전이 공표되었을 경우에는 원한다면 신규 버전을 사용할 수 있다.) 그 외에 다른 사항들은 변경할 수 없다.
복제물에 대해 이러한 수정이 이루어졌을 경우에는 라이선스를 다시 변경하는 것은 불가능하며, 따라서 해당 복제물을 기반으로 만들어진 모든 저작물과 복제물에는 GNU 일반 공중 라이선스가 적용되어야 한다.
이러한 선택 사항은 라이브러리의 코드 일부분을 라이브러리가 아닌 프로그램에 포함시키고자 할 경우에 유용하다.

하지만 LGPL을 제외한 나머지 라이선스는 원 저작자가 아닌 사람이 임의로 라이선스를 변경할 수 없습니다. LGPL은 명확하게 전문에 표기하였기 때문에 문제가 없지만 다른 오픈소스SW 라이선스는 이를 허용하지 않습니다.

4. 더 궁금하시면

다른 오픈소스SW 라이선스에 대하여 궁금하시다면 아래의 링크를 이용하시면 됩니다.

- 공개SW역량플라자 라이선스 설명 : http://www.oss.kr/45607

- 공개SW 라이선스 가이드 다운로드 http://www.oss.kr/?mid=oss_license&page=3&document_srl=70139

- 오픈소스 라이선스 해설 http://www.oss.kr/oss_license/92922

그림출처 : http://terokarvinen.com/freehelia_licenses_and_the_definition_of_free_software.html

화면설계에 유용한 PowerPoint Add-on PowerMockup

chaeya — Mon, 23 Sep 2013 17:22:21 +0900

사용자 인터페이스 설계를 위해서 어떤 방법을 사용하나요? 저는 그때그때 상황에 따라서 보고 바로 작업에 들어갈 수 있는 문서를 원하는지 아니면 빠른 의사소통을 위해서 프로토타입이 필요한 것인지에 따라 다양한 도구(PowerPoint, Balsamiq Mockup, Axure RP, 네이버 Design Studio 2 등)를 사용해서 작업합니다. 화면설계를 지원하는 다양한 도구가 있지만 문서공유 및 수정을 위하여 모든 팀원이 학습없이 쉽게 사용 가능한 파워포인트가 가장 많이 사용되는 것이 현실인데 이때 소개하는 PowerMockup을 사용하면 빠른 작업이 가능합니다.

설치

PowerMockup은 독립적인 소프트웨어가 아니라 PowerPoint 와 함께 Add-on 형태로 동작합니다. 따라서 PowerPoint가 없으면 사용이 불가능하죠.

http://www.powermockup.com/

Download Free Trial 를 클릭하면 설치 파일을 다운 받을 수 있고 다운받은 파일을 실행하고 파워포인트를 실행하면 파워포인트 메뉴 상단에 "PowerMockup" 나타나며 왼쪽에 Library가 노출 됩니다.

기능

기본적인 사용법은 아래 화면과 같이 우측에 자리하고 있는 스텐실 라이브러리에서 원하는 모양을 드래그해서 사용합니다.

PowerMockup은 파워포인트의 Add-on 형태로 설치되는데, 설치된 이 후에 파워포인트 화면 우측에 스텐실 박스가 나타납니다. 좌측에 보이는 것과 같은 스텐실 박스에서 원하는 웹 컨트롤들을 끌어와 놓는 형태로 작업이 진행되기 때문에 스토리보드 레이아웃을 만들어 놓은 상태라면 간단하게 페이지 작성이 가능하고, 개인이 만든 커스텀 스텐실의 추가도 가능하기 때문에 라이브러리에 포함되지 않은 스텐실은 직접 만들어 작업할 수도 있습니다.

Trial 버전에서는 제공되는 스텐실이 몇가지 되지 않지만 정품으로 구매하면 다음과 같이 자유로운 화면설계가 가능합니다. 아래 화면은 PowerMockup 홈페이지의 스크린샷입니다.

구매

http://www.powermockup.com/order

오픈소스 개발자나 블로거인 경우에는 메일을 보내면 무료로 라이센스를 받을 수 있다고 하니 아래 링크를 참고하세요.

http://www.powermockup.com/order/free-license

리더십은 어떻게 결정되는가?

chaeya — Tue, 28 May 2013 02:02:19 +0900

최근 회사의 업무 아키텍처를 개선하는 작업이 진행되어 조직도, 업무프로세스, R&R, 복지정책 등 다양한 관점에서 변화가 많았습니다. 그러다 보니 이번에 새로 팀장이 된 사람도 있고, 팀의 R&R이 변경되어 팀 비전을 새로 수립하는데 고민하는 팀장도 있는 상태입니다. 팀의 리더들이 고민이 많은 시점이죠.

조직의 성패에서 리더의 중요성은 다들 인식을 하고 있지만, 정작 리더가 되어야 하는 순간에는 별도의 지식체계를 따르는 것이 아니라 타고난 기질과 성장배경 그리고 현장에서 부딪치면서 자연스럽게 리더십을 배우게 됩니다. 과연 모든 사람에게 통하는 보편적인 리더십은 어디에 있을까요?

리더십은 다음의 두 단계를 거치면서 결정됩니다.

1) 조직에 의해서 리더의 지위를 획득하는 단계

2) 팀원들에게 리더십을 얻는 단계

간혹 팀장이라는 지위를 얻으면서 의욕이 앞서서 무리수를 두는 경우를 보게 되는데, 아무리 지위를 얻었다고 해도 진심으로 따르는 사람이 없다면 진정한 리더가 아니라는 것을 명심해야 합니다.

리더십을 결정하는 것이 조직과 팀원이라는 것을 이해한다면 아래 그림과 같은 질문을 해보게 되죠.

"나는 어떤 리더일까?"

조직은 성과를 원하고 팀원은 인정과 칭찬을 원합니다.

결국 리더십을 배운다는 것은 조직과 팀원에게 모두 인정받는 아래의 방법을 배우는 것을 의미하는 것이죠.

1) 팀원들을 섬기는 서번트 리더십

2) 팀원들의 부족한 능력을 향상시켜서 성과를 만드는 방법

따라서 좋은 팀장이 되기 위해서는 가장 먼저 리더 자신이 전문 분야에 능력 있는 사람이 되고, 자신의 능력을 팀원들에게 잘 전수하는 커뮤니케이션 능력을 키워서 진심으로 따르는 팀원이 많아지도록 계속 노력해야 합니다.

물론 쉽지 않습니다 :-)

이번 달 사내 북데이에 발표한 책이 '내 인생의 작전타임' 이라는 도서인데 이 책은 21억의 팔로워를 가진 예수님의 내용을 토대로 리더십에 대한 이야기를 하고 있습니다. 전 세계에서 가장 많은 팔로워를 가진 분의 리더십이야기는 흥미로운 내용이었고, 팀장이 되어 고민을 하는 분에게는 일독을 권합니다.

웃겨야 산다.

chaeya — Sat, 20 Apr 2013 02:30:42 +0900

지속가능한 기업이 되기 위해서 가장 중요한 것이 무엇이냐고 묻는다면 단연코 사람이 일순위라고 생각합니다. 사람 없이는 기업을 운영할 수 없으니까요.

그런데 팀을 구성해서 프로젝트를 하다보면 아무리 잘하려고 해도 인간관계에 대한 문제가 꼭 생기고 맙니다.

문제를 찾으려고 해도 이런 저런 다른 핑계에 묻혀서 이유을 찾기가 어렵고, 갈등이 계속되어 서로 간의 소통이 잘 되지 않은채로 불만이 가득한 채 버티면서 일하기도 하죠.

이 때 인적 자원의 여유가 좀 있는 대기업 이라면 팀원의 배치를 좀 조정해보거나, 문제가 있는 사람을 해고하고 다른 인력을 투입하거나 하는 대응을 할 수 있겠지만 규모가 적은 중소기업은 대응이 참 어렵습니다.

인간관계 개선을 위해 책에 있는 여러가지 방법을 해 보기도 쉽지 않고, 돈을 많이 팍팍 주면서 달래보기도 어렵죠. 뿐만 아니라 한명 한명이 회사의 생사를 좌우하는 실정이기에 인력을 변경하는 시도는 하기 더 힘듭니다.

이처럼 조직의 유연성을 확보하기 어려울 때, 사람들의 관계를 말랑말랑하게 만드는 가장 효과적인 방법은 바로 유머입니다.

유머는 상호간의 마찰로 인해 극도의 스트레스를 받는 상황을 극복할 수 있을 뿐만 아니라 웃음이 주는 심리적, 신체적 효과도 탁월합니다. 자신의 정신건강과 사람들과의 관계를 위해서는 많이 웃는것이 좋습니다.

예전에 저는 팀의 관리를 위해서 권위가 어느정도 필요한거 아닌가 하고 생각했지만 지금은 생각이 바뀌었습니다. 좋은 리더가 되려면 권위에 의존하고 공포를 주며 단점을 지적하는 것보다는 스스로를 망가뜨리면서 권위를 내던져야 팀을 잘 관리할 수 있습니다.

유머는 쉽고, 간편하고, 돈이 들지 않는 최고의 기술이죠.
"어떤 상황에서도 유머를 찾아낼 수 있다면, 당신은 어디서든 살아남을 수 있다."

NHN NEXT

chaeya — Fri, 8 Mar 2013 16:20:05 +0900

IT업계에서는 화제의 중심이 되었던 NHN NEXT

오늘 NEXT의 교수님과 미팅이 있어서 처음으로 방문했습니다.

업무 이야기를 나눈 후, 평소에 궁금하던 질문들을 이것저것 물어보게 되었죠

많은 이야기를 나누었는데 그 중 제가 기억에 남는 부분은 아래와 같은 내용이었습니다.

Q. 아직 교수님이 부족한걸로 아는데 NEXT 교수가 되는 과정에서 가장 높은 관문은 무었인가요?

A. 1~2차 평가에서 기술적인 부분이 충족되는 분이 있어도, 3차를 넘기가 어려운것 같습니다. 3차에서 진심으로 학생을 사랑하는지를 묻는데 여기에서 NEXT가 바라는 교수상이 까다롭습니다.

돌아와서 검색해보니 NEXT 학장님이 교수상에 대해서 말한 내용이 있네요.

"학생들을 성장시키기에 엄청난 열의가 있어 예를 들어 수업을 같이 따라가지 못하는 학생이 있고 진로문제를 겪을 경우 같이 밤잠을 못 이룰 정도가 필요하다"

Q. 커리큘럼의 구성은 기업의 현실을 많이 반영하고 있나요?

A. 초기 NHN이 필요한 커리큘럼구성을 했었고, 이후 보다 많은 기업이 필요한 구성으로 조정되었습니다. 대학원을 뛰어넘는 수준의 내용들도 많고, 학생이 자기주도적 학습을 하기를 원하기 때문에 진심으로 원하지 않는다면 감당하기 힘들정도의 수준이죠.

Q. 학생을 선정하는 과정은 어떤가요?

A. NEXT는 SW개발에 필요한 여러가지 관점에서 보려는 노력을 합니다. 학생 선정과정에서 2명의 학생을 대상으로 2시간씩 인터뷰를 했습니다. 이 과정에서 수능이라는 측정기준이 SW개발분야에 적용하기에는 적합하지 않다는 것을 확신하게 되었습니다. 보다 다양한 관점에서 학생들을 바라보려는 노력이 필요합니다.

미팅을 마치고 돌아와서 몇가지 생각이 들어서 회고록을 남겨두려고 합니다.

Feeling
- 학위를 줄수없는 NEXT를 선택한 학생들은 여기까지 온 사실만으로도 충분히 자기주도적이다. 너무 멋진걸~
- 현장경험이 있는 교수진의 구성으로 인해, 진짜 필요한 지식을 교육하게 되고 자연히 취업은 잘 될수 밖에 없다. 하지만 배우는 과정이 빡세다.

- 여기서 가르치는 일이 행복하신가요? 라는 질문에 망설임없이 네 행복합니다. 라고 대답해서.. 움찔했다.

Finding
- 자기주도적인 학습열의도 중요하지만 자질이 있는 것도 중요하다. 나도 좋은 팀원을 확보하기 위해서 강도높은 기술적 수준평가를 해야 한다.
- 누군가를 가르칠 때 나는 어떤 마음인지 다시 돌아보게 되었다.

Future work
- 회사에서 SW개발자에게 맞는 평가기준을 마련하는 노력을 더 해야겠다

길을 모르면 물으면 될 것이고, 길을 잃으면 헤매면 그만이다.
중요한 것은 나의 목적지가 어디인지 늘 잊지 않는 마음이다.
절대로 포기하지 마라 - 윈스톤 처칠

NEXT 다녀와서 또 한수 배웁니다.

트렌드코리아 2013

chaeya — Mon, 25 Feb 2013 18:04:55 +0900

자꾸 회사에서 전략수립이니 동향이니 하는 내용을 자주 이야기해서 그런지 이번에 사내 독서발표회의 책은 "트렌드코리아 2013"이라는 책이었네요.(저희는 팀원들이 돌아가면서 매월 읽을 도서를 선정합니다)

이 책은 서울대 소비트렌드 분석센터에서 매년 소비자의 트렌드를 분석해서 키워드로 만들어 내고 있는데 2012년은 DRAGON BALL 이라는 키워드로 소비트렌드를 풀었고, 2013년의 소비트렌드를 대표하는 단어는 "COBRA TWIST" 라고 합니다.

미래에 대한 이야기를 써보신 분들은 아시겠지만 어떤것을 전망한다는 일은 참 많은 용기를 필요로 합니다. 맞으면 좋지만 안맞으면 그것 참.. 곤란하죠. 저는 읽으면서 내내 이 책을 쓴 사람들의 용기가 생각났습니다. 이 전망이 맞고 안맞고는 제쳐두고도 소비트렌드를 예측하기 위해 많은 고심을 했을 연구진에게 격려를 해주고 싶네요.

COBRA TWIST의 내용은 다음과 같습니다. (자세한 내용은 책을 참고하세요~)

City of hysterie - 날 선 사람들의 도시
OTL... Nonsense! - 난센스의 시대
Bravo, Scandimom - 스칸디맘이 몰려온다
Redefined ownership - 소유냐 향유냐
Alone with lounging - 나홀로 라운징
Taste your life out - 미각의 제국
Whenever U want - 시즌의 상실
It's detox time - 디톡스가 필요한 시간
Surviving burn-out society - 소진사회
Trouble is welcomed - 적절한 불편

트렌드코리아 2013 from Hyeongchae Kim

책을 다 읽고 나니 얼마전 혼잡한 전철에서 제가 히스테릭했던 일이 생각났습니다. 만원 전철안에서 통로를 빠져나갈때의 불쾌한 스트레스는 다들 많이 경험해보셨을 겁니다. 이상하게 화가나서 씩씩대던 날이 있었는데 그게 사람들의 현재 상태라고 하네요.(City of hysterie - 날 선 사람들의 도시)

고객을 상대하는 일을 하려면 사람들의 트렌드를 읽으려는 노력을 하는것은 당연한 일이겠죠.

역시나 쉬운일이 없네요~ㅋ

애자일 회고 - 책 안의 회고와 현실에서의 회고

chaeya — Sat, 2 Feb 2013 16:33:13 +0900

저희 회사는 애자일에 대해서 2009년 부터 단계적인 적용을 해왔고, 책을 통해서 애자일에 대한 이해는 어느정도 하고 있는 상황입니다. 제가 애자일에 관심이 높았던 지난 몇년을 돌아보면 그 중 사내에 도입해서 가장 효과가 좋았던 실천법은 뭐니뭐니 해도 회고가 아닐까 하는 생각이 듭니다.

저희 사내에서 회고는 SW개발 팀원뿐만 아니라, 전사적인 전략 수립, 직무평가 워크샵, 고객관리 등에서도 다양하게 사용되었고, 참여하는 팀원들도 모두 좋아하고 만족도가 높은 멋진 방법임이 분명합니다.

하지만, 회고를 책으로 배워서 그런지 몇가지 답답한 부분이 있었죠.

(창준님이 하시는 AC 코스에 가고 싶은 마음도 몇번이나 있었는데, 의지 부족으로 아직 참여는 못했네요)

언제나 처럼 xper 메일링을 눈팅만 하던 중, 이번에 주제가 애자일 회고이기도 하고 물어볼 수 있는 트랙도 준비되었다는 소식을 접하고, 제가 회고를 하면서 어려웠던 점을 몇가지 정리해서 회사의 팀원 두명과 함께 xper 정모에 참석했습니다.

저도 너무 오랜만에 참석하는 자리였고 같이 간 팀원들도 처음 참석하는 거라 은근히 어색함을 걱정했지만, 새로운 참석자에 배려가 좋은 xper의 문화와 준비를 꼼꼼하게 해주신 퍼실리테이터 분들 덕분에 금방 친해질 수 있어서 좋았습니다.

맛있는 김밥과 음료수를 먹고 테이블에 계신 분과 인사를 나누고 웃고 떠드는 시간이 지나고

회고에 대한 컨설팅을 받을 수 있는 트랙이 시작되었습니다.

제가 김창준님에게 던진 질문은 아래의 두 가지입니다.

질문1. 저희 회사는 매주 주간보고의 말미에 PMI 회고를 수행하는데 그 목적과 다르게 참여도가 낮고 의견을 말하지 않습니다. 어떻게 하면 좋을까요?

질문2. 저희 회사는 6개월의 내용을 모아서 정기회고를 전사적으로 하는데 책 속의 애자일 회고 순서로 진행합니다. 하지만 인사이트 발굴과정에서 어려움을 느낍니다. 어디를 고치면 좋을까요?

한시간 반 정도의 시간동안 3명이서 돌아가며 자신이 회고에서 느낀 어려움을 묻고 답하는 형식으로 진행되었습니다. 김창준님과 박준표님이 좋은 의견을 많이 이야기 해주셨고, 아래 사진처럼 앞 뒤로 빼곡하게 말해주신 내용을 받아 적었습니다.

저의 경우는 상담시간이 끝날 즈음에 저희 회사에서 진행하는 회고의 개선점을 몇가지 찾게 되었고 그 내용을 요약하자면 다음과 같습니다.

보고와 회고를 섞어서 하는 것 보다는 분리하는 것이 좋고, 회고는 형식에 얽매이지 말고 짧게 할 것

회고 자체보다는 평상시 상호작용을 통한 심리적 안정감을 강화하는 노력이 더 중요함

회고에 즐거움을 디자인해서 동물적으로 그 회고가 좋아지도록 할 것

좋은 회고는 결국 꾸준한 연습이 필요하므로. 매일 2명씩 짝지어 10분간 회고해볼 것

회사뿐만 아니라 집에서도 부인과 함께 매일 회고를 연습해보는 것이 좋다.

xper 모임을 마치고 돌아오는 길에 이런 생각을 했습니다.

우선 전체 팀원에게 회고란 무엇이라고 생각하는 질문해보자.
만일 회고를 반성하는것이라고 느낀다면 오늘 들었던 인지적, 정서적, 신체적 관점에서 해결책을 찾아내서,
새롭게 사내 회고를 디자인 해야겠다! 재미있겠는걸~ㅋ

후기를 쓰면서 정리하다 보니, 애자일의 꽃이 회고라던 퍼실리테이터 분의 말이 생각납니다. 저 역시 애자일 실천법을 여러가지 적용하면서 회고가 가장 멋진 거라고 생각하고 있습니다. 회고를 잘 하려면 눈치도 빨라야하고 리더십도 필요하며 좋은 기법도 있어야 합니다. 하지만 여러가지 기법보도 더 중요한 것은 서로를 비난하기 보다는 참여한 모든 사람이 스스로 점검하고 되돌아보는 것에 초점을 맞추는 자세라고 생각됩니다.

사내에 개선된 회고를 디자인해보고 적용한 결과를 나중에 공유할 수 있었으면 좋겠네요 :-)

xper 여러분 덕분에 즐거운 시간이 되었습니다. 자주 자주 만나요~

다른 분의 후기

왜 세계의 절반은 굶주리는가

chaeya — Wed, 16 Jan 2013 20:50:23 +0900

이 책은 최근 한달동안 읽은 십여권의 도서 중 유일한 비 기술도서인데, 책 두께가 얇기도 하지만 내용도 흥미있는 이야기로 전개되어서 한번에 쭈욱 읽게 되었습니다. 책의 내용을 요약하면 제목에서 직관적으로 유추가 되는 것처럼 세계 기아에 대한 문제인식을 재조명 하는 내용입니다.

유엔 인권위원회 식량특별조사관으로서 활동해본 저자(장 지글러)는 우리가 외면하고 있던 사실을 묻습니다.

오늘 날 지구는 현재보다 두 배나 많은 인구도 먹여 살릴 수 있는 식량을 보유하고 있습니다.
즉, 식량 자체는 풍부하게 있는데도, 가난한 사람들에게는 그것을 확보할 경제적 수단이 없고, 그런 식으로 식량이 불공평하게 분배되는 바람에 매년 수백만의 인구가 굶어 죽는 현실이 반복된다는 것이죠. 왜 그런지 아시나요?

왜 세계의 절반은 굶주리는가 라는 질문에 대한 대답으로 막연하게 식량부족을 원인으로 생각하고 있었던 저에게 이 책은 다른 사실을 알려주었습니다. 시카고 곡물거래소의 투기, 사람은 굶고 소는 배를 채우는 현실에 대하여 관심을 가지게 하였다는 점에서 집필의 의미를 잘 전달하고 있는 책이라고 할 수 있겠네요.

왜 세계의 절반은 굶주리는가 from Hyeongchae Kim

다 읽고 책장을 덮으며 가장 먼저 든 생각은 제가 한국에서 태어난 것에 대한 안도감이었습니다.

911테러에 묻혀서 사람들이 잘 모르는 아옌데의 칠레 911 , 서아프리카 사하라 남단 부르키나파소의 상카라와 친구들의 이야기가 우리나라의 이야기가 아닌것이 다행이었습니다.

그리고 세계 사회의 기아에 대한 의식을 다시 한번 일깨우게 되었습니다.

바로 보면 아프지만 피해서는 안되는 사실인 기아.

해결의 희망은 공동이 관심을 모은 전 지구적인 민간단체에 있다고 저자는 말하고 있습니다.

이슈관리 - 이메일로 레드마인 이슈 등록하기

chaeya — Fri, 28 Dec 2012 20:03:33 +0900

업무의 대부분이 이메일로 소통되고 있는데, 이슈를 따로 레드마인에 가서 등록하는 비효율적인 영역의 업무를 줄이기 위해서는 이메일을 통한 이슈등록이 필요합니다. 이번에는 레드마인의 이슈를 이메일로 등록하는 방법을 진행해볼까 합니다.

운영 환경

OS : CentOS 6.x

Version : Redmine 2.2.0

이 글은 레드마인이 설치된 상태에서 시작하기 때문에, 레드마인이 설치되지 않은 경우는 이전글을 참고해서 설치하시기 바랍니다. http://yes.imhappyo.com/403

레드마인 2.x 버전에서는 설정에 필요한 기본적인 내용이 모두 포함되어 있으므로 실제 우리가 설정해야 하는 것은 자동으로 pop3 또는 imap 이메일 서버에 접근해서 이슈를 가져오게 만드는 과정뿐입니다.

저는 redmine@abydos.co.kr 이라는 이메일 계정으로 보내는 내용을 자동으로 레드마인에 등록하는 시나리오를 구상하고 다음과 같이 설정했습니다.

1) 이메일로 받는 것이 가능하도록 레드마인 관리자로 로그인하여 설정을 변경.

관리-> 설정-> 수신메일-> 수신메일에 WS를 허용 하고 키생성을 눌러서 API키를 생성해 둡니다.

2) cron을 이용하여 주기적으로 이슈를 가져오도록 설정.

5분마다 레드마인이 redmine@abydos.co.kr 계정의 imap 서버를 접근하여 이슈를 가져오는 cron 설정은 다음과 같습니다. (pop3를 사용하신다면 아래의 예를 참고하세요)

Gmail imap 서비스 사용하는 경우 crontab -e

0,5,10,15,20,25,30,35,40,45,50,55 * * * * rake -f /opt/webRoot/redmine/Rakefile redmine:email:receive_imap RAILS_ENV="production" host=imap.gmail.com username=redmine@abydos.co.kr password=PASSWORD port=993 ssl=1 project=issue_repo tracker=Issue allow_override=project,tracker,priority

Gmail pop 서비스 사용하는 경우 crontab -e

0,5,10,15,20,25,30,35,40,45,50,55 * * * * rake -f /opt/webRoot/redmine/Rakefile redmine:email:receive_pop3 RAILS_ENV="production" host=pop.gmail.com username=redmine@abydos.co.kr password=PASSWORD port=465 ssl=1 project=issue_repo tracker=Issue allow_override=project,tracker,priority

설정이 끝났습니다. 이제 여러분이 redmine@abydos.co.kr 에게 쓰는 메일은 기본적으로 issue_repo 라는 프로젝트로 Issue 라는 tracker로 자동으로 등록됩니다. 너무 간단하죠 :-)

뒤의 옵션 중 allow_override 는 메일의 본문에서 적는 내용을 우선해서 등록하라는 의미입니다.

2) 이메일을 보내서 등록된 이슈 확인

지금부터 이메일 본문에 아래의 내용이 있으면 이슈가 등록됩니다.

Project: 프로젝트아이디
Tracker: Issue(결함, 새기능, 지원, Issue)
Priority: 보통(낮음, 보통, 높음, 긴급, 즉시)
Status: 신규(신규, 진행, 해결, 의견, 완료, 거절)
Category: 설정한 카테고리
Assigned To: 홍길동(또는 id)

문제가 생겨서 진행과정을 디버깅하는 경우에는 맨뒤에 --trace 를 붙여서 실행하시면 됩니다.

참고) 레드마인 공식사이트에서 제공하는 관련 링크
http://www.redmine.org/projects/redmine/wiki/RedmineReceivingEmails

이슈관리 - Redmine 2.x 과 Eclipse 연동(CentOS 6.x)

chaeya — Fri, 28 Dec 2012 16:06:32 +0900

이번 글은 설치된 레드마인을 Eclipse와 연동하는 방법에 대해서 작성하려고 합니다.
기본적으로 레드마인 공식사이트에서 제공하는 아래의 링크에서 읽으면 되지만, 오픈소스 프로젝트들은 환경이 각각 다르기 때문에 한번에 쉽게 되는 법이 없죠 :-)
http://www.redmine.org/projects/redmine/wiki/HowTo_Mylyn

설치 환경

OS : CentOS 6.x

Version : Redmine 2.2.0

Eclipse : STS

이 글은 레드마인이 설치된 상태에서 시작하기 때문에

레드마인이 설치되지 않은 경우는 이전글을 참고하세요 - http://yes.imhappyo.com/403

저는 CentOS 6.x 를 사용중이고 Redmine 2.2.0 버전을 설치한 상태입니다.
레드마인 사이트의 공식 가이드나, 구글링에서 나오는 Eclipse 연동을 위한 예전의 글은
낮은 버전의 레드마인을 위한 설명이 대부분이라 적당한 문서를 찾지 못해서 기록해둡니다.

설치는 크게 2단계로 나누어집니다.
1단계 - 서버에 설치된 레드마인에 mylyn 플러그인을 추가하는 단계입니다.
2단계 - 이클립스가 설치된 개발용 PC에서 이클립스 플러그인을 깔고 설정하는 단계입니다.

1단계) Redmine 서버에 Mylyn Plugin 설치

Redmine 2.2.0 설치된 서버에 redmine_mylyn_connector plugin을 설치합니다
http://danmunn.github.com/redmine_mylyn_connector/

redmine_mylyn_connector를 설치하는 과정에서 libxml-ruby 의존성 문제 발생하네요
- 의존성문제는 다음과 같이 해결 (http://michael.f1337.us/2009/08/26/172339834/)

yum install gcc make libxml2-devel
Install the libxml-ruby gem:
gem install libxml-ruby --no-rdoc --no-ri

의존성을 해결했으니 이제 플러그인을 설치합니다.

- 저는 postgresql sqlite을 사용하지 않기에 --without 옵션에 추가되었습니다

cd [redmine-install-dir]/plugins
git clone git://github.com/danmunn/redmine_mylyn_connector.git
cd ..
rake db:migrate_plugins RAILS_ENV=production
bundle install --without development test postgresql sqlite

설치를 완료했으면, 설치한 레드마인의 관리자> 환경설정> 플러그인 에서 아래의 화면이 있는지 확인합니다.

2단계) PC에 eclipse plugin 설치

Eclipse PC에 Mylyn Connector for Redmine 설치(저는 STS로 설치확인)
Window > Install New software > Update Site 에 아래주소를 추가합니다.

http://redmin-mylyncon.sourceforge.net/update-site/N/

주소를 추가하면 아래와 같은 화면이 나옵니다. 체크박스를 모두 체크한 후 설치를 진행합니다.

이클립스 플러그인설치를 마쳤이니 이제 이슈를 가져오는 설정을 합니다.

New > Task 를 생성합니다.

화면처럼 설정이 다 되었으면 Validate Settings 를 눌러서 접속을 확인해 봅니다.

정상적으로 접속이 되었다면 이제 이슈를 가져오는 Query 생성 과정을 진행합니다.

Task List 윈도우에서 마우스 오른쪽 버튼을 누르고 새 쿼리를 생성합니다.

기타 유용한 도구
Third Party Tools - http://www.redmine.org/projects/redmine/wiki/ThirdPartyTools
윈도우용 Tortoise SVN 클라이언트에 플러그인으로 동작하는 프로그램인데, 컨텍스트 메뉴로 Redmine에 입력하는 설정을 할 수 있게 해줍니다.

* turtlemine(Tortoise Redmine Plugin) - http://code.google.com/p/turtlemine/wiki/BugTraqConfiguration

Apache, Tomcat IP 접근제한

chaeya — Mon, 10 Dec 2012 14:46:46 +0900

아시는 분이 많으시겠지만, IP 접근제한에 대해서 물어보는 팀원이 있어서 정리했습니다. 최근에는 보안인식이 고취되어서 많은 사람들이 관심이 있네요. 많이 사용되는 Apache, Tomcat 환경에서 IP 기반 접근제어 방법은 다음과 같습니다.

Apache IP 접근제한

Apache 환경설정파일 httpd.conf 파일에 아래의 내용을 추가하고 재시작

AllowOverride all

Order allow,deny

Allow from 192.168.10.11

Deny from all

</Directory>

Order Deny,Allow 의 경우

Allow 를 평가하기 전에 먼저 Deny 를 평가하고, 그 다음 Allow 에 override 함. 그리고 여기에 매치되지 않는 나머지 호스트 모두 Allow 됨. 따라서 이 Order 의 기본정책은 첫번째 Deny 지시자에서 결정함

Order Allow,Deny 의 경우

Deny 를 평가하기 전에 먼저 Allow 를 평가하고, 그 다음 Deny 에 override 함. 그리고 여기에 매치되지 않은 나머지 호스트는 모두 Deny 됨. 이 Order 의 기본정책은 첫번째 Allow 지사자에서 결정함.

참고 : http://httpd.apache.org/docs/2.2/howto/access.html

Tomcat IP 접근제한

Tomcat 환경설정파일 server.xml 의 <Host> ... </Host> 안에 아래의 내용을 추가하고 재시작

또는

참고 : http://tomcat.apache.org/tomcat-7.0-doc/config/filter.html

IPTABLES IP 접근제한

iptables -I INPUT -s 65.24.7.10 -j DROP

iptables -A INPUT -s 192.168.100.0/24 -j DROP

iptables -I INPUT -m iprange --src-range 65.24.7.10-6524.7.13 -j DROP

hosts.deny, hosts.allow IP 허용/차단

/etc/hosts.deny

#모든서비스 접근제한

ALL:ALL

# ssh 접근 제한

SSHD : 65.0.12.4

/etc/hosts.allow

#모든서비스 접근허용

ALL:ALL

# ssh 접근 허용

SSHD : 65.0.12.4, .mycompany.com

좋은 팀이란? - Agile Self-Organizing Team

chaeya — Fri, 30 Nov 2012 02:47:29 +0900

오늘은 팀원과 서로가 원하는 이상적인 팀의 운영이란 어떤것인지 팀 운영방식에 대한 이야기를 할 기회가 있었습니다.

좋은 팀이란 무엇보다도 상대에 대한 이해를 기반으로 해야 하는데, 대화를 해보니 팀 리딩에 있어서 팀원들과 함께 팀의 미래에 대한 비젼을 공유하지 못하고 있는 것 같아서 좋은 팀에 대한 제 생각을 한번 정리해 보려고 합니다.

지난 몇년간 애자일하게 일하는 SW기업이 되고자 이런저런 고민을 많이 하고 있습니다.

그 중 'Self-Organizing Team' 이라는 키워드는 매력적이었고 제가 원하던 모델이었죠.

저는 전통적인 조직운영 방식에서 보이는 강력한 중앙집중형 리더십이 조직을 이끌어가는 형태가 아니라

통제가 적고 구성원의 자유도가 높은 리더십으로 운영이 되는 애자일한 조직운영을 하고 싶었습니다.

Source : http://blogs.seapine.com

제가 이해한 'Self-Organizing'은 멋진 용어이지만, 실제 현업에서 몇년간 해보니

자율적인 업무결정권을 자유로운 업무방식으로 오해하는 팀원이 생기고 그로인해 갈등이 심해지는 경우들이 발생되었습니다.

프로젝트에서 너무 적은 리더십을 가진 스크럼마스터는 팀원이 상호작용하여 협업이 되도록 하기에는 부족하였고

팀원에게 많은 결정사항을 위임하는 자율적 결정방식은 수동적이 지시에 의존해온 팀원들에게 괴로움만 가중시키게 되었습니다.

'서툰 목수가 연장을 탓한다'고 하더니 이게 그런 모습이네요. ㅎㅎ

사실 이것은 리딩을 제대로 못한 저의 무능력 때문이지, 자기조직적팀(Self-Organizing Team)이 잘못된 것은 아니라고 생각합니다.

제가 생각하는 자기조직적인 좋은 팀이란?

프로젝트의 핵심가치를 위반하지 않고 유연하게 해당 업무를 수행할 수 있는 능력이 충분한 사람들의 모임.
- 상호간 업무수행에 있어서 친화력(affinity)이 있을 것.
- 핵심가치를 달성하기 위하여 충분한 자격(competent)을 가질 것
- 팀의 공동문화에 대한 이해와 지지
- 리뷰는 각각의 일정에서 가장 높은 우선순위로 처리하는 태도
- 핵심가치의 달성이라는 목표의 업무안에서는 자체적인 활동
- 중앙집중형 의사결정이 아니라 팀에 의사결정 권한을 분산하고 결과에 대한 책임도 공유
- 개개인은 문제해결을 위하여 능동적인 대응

최근에는 운영방식을 좀 변경했는데 최종결정을 내리는 의사결정프로세스를 명확하게 하여 팀원의 책임을 덜어주면서

팀원들이 능력을 최대한 발휘할 수 있도록 독려하는 형태를 유지하려고 하고 있습니다.

모든 일을 잘하는 슈퍼개발자를 원하는 것은 아니지만 분석, 설계, 코딩, 테스트, 배포를 할수 있는 스크럼 팀원이 다수 있어야 하는데 자원의 확보(항상 팀원이 부족합니다 ㅎㅎ)부터 교육이나 인적자원 관리 등의 이슈가 많아서 팀 리딩이 어려운것은 여전합니다. 하지만, 팀원들이 모두 잘 따라주어서 예전 보다는 훨씬 나아졌으니 앞으로 점점 좋아질거라고 믿습니다.

누워서 읽는 퍼즐북

chaeya — Mon, 26 Nov 2012 18:13:36 +0900

이 책은 제작년쯤 개발자 세미나에서 경품으로 받은 책입니다.

그때 분명히 재미있게 읽었는데

기억력이 쇠퇴해서 그런지 지금 책을 다시 보니 기억나는게 몇가지 안되네요.

책 제목은 누워서 읽는 퍼즐북이지만

문제의 해답을 찾느라 잠을 잘 수 없는 경우도 예상이 되기 때문에

자기전에 읽는 건 비추천입니다. ㅋ

저는 이 책에서 흥미를 느낀 부분이 Edward Adelson의 그림입니다.

이 그림에서 우리가 인지하는 감각과 판단의 오류에 대해서 다시한번 생각하게 되었죠.

그림의 A와 B는 같은색입니다.

믿기시나요?

누워서 읽는 퍼즐북 from Hyeongchae Kim

오픈비 : 삽질은없다

Claude Code 활용 가이드 2026

목차

1. 초기화 및 설정

CLAUDE.md 작성 (핵심)

/init 명령어

2. SKILL 시스템

Skill이란?

Skill 생성 방법

Skill 실행 방법

Skill Frontmatter 필드

3. Subagents (전문 에이전트)

Subagent란?

Subagent 생성

내장 Subagent 유형

4. SKILL vs Subagent 차이점

핵심 차이 비교

언제 무엇을 사용해야 할까?

5. MCP 서버 통합

MCP란?

MCP 서버 설정

인기 있는 MCP 서버

6. Hooks 자동화

Hook이란?

주요 Hook 이벤트

Hook 설정 예시

7. 핵심 모범 사례

검증 가능한 작업 지시

구체적인 프롬프트

컨텍스트 관리

8. Claude Code 작업 가이드라인 (실전 예시)

1. 접근 방식 (Before Writing Code)

2. 작업 분할 (3 Files+ Rule)

3. 테스트 중심 개발

4. 버그 수정 TDD

5. 지속적 개선 (CLAUDE.md 업데이트)

참고 자료

공식 문서

커뮤니티 리소스

Claude Code 워크플로우 가이드

Claude Code란?

핵심 특징

실전 워크플로우

1. Plan Mode로 체계적 개발

2. tmux를 활용한 병렬 작업

3. Slash Commands로 자동화

/test - 테스트 실행

/review - 코드 리뷰

/commit - 커밋 생성

/build - 프로젝트 빌드

/deploy - 서비스 관리

일상적인 개발 워크플로우

표준 개발 사이클

복잡한 작업에는 전문가 Agent 호출

핵심 Benefit

⏱️ 시간 단축

버그 감소

품질 향상

생산성

참조 자료

공식 문서

워크플로우 관련

도구 및 기술

마무리하며

추가 학습 자료

VRAM 16GB로 30B 모델 구동하기: LM Studio MoE 오프로딩 테스트

VRAM 16GB로 30B 모델 구동하기: LM Studio MoE 오프로딩 테스트

목차

들어가며

MoE 오프로딩이란?

MoE (Mixture of Experts) 아키텍처

MoE 오프로딩의 핵심

이론적 배경

테스트 환경

하드웨어 사양

소프트웨어

모델 정보

LM Studio 설정 방법

1. 모델 로드 전 설정

2. 설정별 설명

`/test` - 테스트 실행

`/review` - 코드 리뷰

`/commit` - 커밋 생성

`/build` - 프로젝트 빌드

`/deploy` - 서비스 관리