1번째 글: 개발팀이 알아야 할 WBS: 프로젝트 혼돈에서 질서를 찾는 마법

 "우리 프로젝트 언제 끝나요?" 이 질문에 자신 있게 답할 수 있나요?

읽는 시간: 7분
대상 독자: PM, 개발팀 리더, 스크럼 마스터
핵심 가치: WBS로 프로젝트 예측 가능성 90% 향상

---

🎯 30초 요약

WBS(Work Breakdown Structure)는 거대한 프로젝트를 작은 레고 블록으로 나누는 기법입니다. 마치 "코끼리를 냉장고에 넣는 방법"처럼:

1. 냉장고 문을 연다 (프로젝트 시작)
2. 코끼리를 작게 자른다 (WBS의 핵심)
3. 조각을 하나씩 넣는다 (작업 실행)
4. 문을 닫는다 (프로젝트 완료)

---

📖 스토리: 두 개발팀의 운명

팀 A: "대충 하면 되겠지" 팀

PM: "로그인 기능 언제쯤 끝날까요?"
개발자: "음... 한 2주?"
(3주 후)
PM: "아직도요?"
개발자: "거의 다 됐는데... 몇 가지만 더..."
(2주 후)
PM: "..."
개발자: "..."

팀 B: "WBS 있는" 팀

현재 상태: 전체 40h 중 20h 완료 (50%)

예상 완료: 3일 후
신뢰도: 95%

어느 팀에서 일하고 싶으신가요?

---

🧠 WBS의 본질: 불확실성을 확실성으로

인간의 추정 능력은 왜 형편없을까?

심리학 연구에 따르면, 인간은 큰 작업을 추정할 때 평균 2.5배 과소평가합니다.

작은 작업 추정 오차: ±20%

큰 작업 추정 오차: ±150%

WBS의 과학적 원리

파킨슨의 법칙: "작업은 주어진 시간만큼 늘어난다"

• 큰 작업: 버퍼가 숨어있어 늘어남
• 작은 작업: 버퍼가 없어 정확함

밀러의 법칙: "인간은 7±2개만 동시에 처리 가능"

• WBS는 복잡도를 관리 가능한 수준으로 낮춤

---

🏗️ WBS의 구조: 프로젝트를 해부하기

계층 구조의 아름다움

황금 규칙: 100% 규칙

def validate_wbs(project):
    total = sum(task.effort for task in project.tasks)
    assert total == project.total_effort, "누락된 작업 존재!"

# ✅ 좋은 예
project = {
    "개발": 60,
    "테스트": 20,
    "문서화": 10,
    "배포": 10
}  # 합계: 100%

# ❌ 나쁜 예
bad_project = {
    "개발": 80,
    "테스트": 20
    # 문서화는...? 배포는...? 😱
}

---

💡 WBS가 해결하는 5가지 고질병

1. "거의 다 됐어요" 증후군

증상: 매일 "90% 완료"라고 하지만 끝나지 않음

WBS 처방:

• 작업을 8시간 단위로 분해
• 0% 또는 100% 규칙 적용
• 일일 체크포인트 설정

2. 스코프 크립 바이러스

증상: 프로젝트가 진행될수록 요구사항이 계속 추가

WBS 백신:

프로젝트 범위 (고정)

✅ 포함

• 사용자 인증
• 상품 관리
• 주문 처리

❌ 제외 (Phase 2)

• 소셜 로그인
• 추천 시스템
• 실시간 채팅

3. 리소스 블랙홀

증상: 특정 개발자에게 모든 중요 작업이 몰림

WBS 솔루션: 작업 재분배와 페어 프로그래밍

4. 데드라인 공포증

증상: 마감일이 다가올수록 패닉

WBS 치료법:

5. 커뮤니케이션 단절

증상: "그거 누가 하기로 했죠?"

WBS RACI 매트릭스:

작업	개발자A	개발자B	PM	QA
API 개발	R	A	C	I
UI 개발	A	R	C	I
테스트	C	C	I	R

• Responsible: 실행 책임
• Accountable: 최종 책임
• Consulted: 협의 필요
• Informed: 정보 공유

---

🎮 게임화: WBS를 재미있게 만들기

프로젝트 RPG

레벨 시스템:

• 🥉 브론즈: 5 Tasks 완료
• 🥈 실버: 20 Tasks 완료
• 🥇 골드: 50 Tasks 완료
• 💎 다이아몬드: 100 Tasks 완료

일일 퀘스트

const dailyQuests = {
  '버그 슬레이어': '크리티컬 버그 1개 해결',
  '스피드 러너': '예상보다 빨리 완료',
  '팀 플레이어': '동료 PR 리뷰 3개',
  '문서 마스터': 'README 업데이트',
};

// 보상 시스템
const rewards = {
  points: 100,
  badge: '🏅 오늘의 영웅',
  perk: '내일 재택근무',
};

---

🤖 보너스: AI 시대의 WBS

AI가 코딩하는데 WBS가 필요해?

역설적이게도, AI 시대야말로 WBS가 더 중요합니다.

핵심: AI는 명확한 작업 단위와 상세 스펙이 있을 때 가장 잘 작동합니다.

AI + WBS 조합의 위력

# 기존: WBS만
traditional_wbs = {
    "planning": "4시간",
    "coding": "40시간",
    "total": "44시간"
}

# 혁신: AI + WBS
ai_powered_wbs = {
    "planning": "30분 (AI가 WBS 초안 생성)",
    "coding": "8시간 (AI가 80% 생성, 인간이 20% 리뷰)",
    "total": "8.5시간"
}

# 결과: 5배 빠름!

다음 글에서 ChatGPT로 30분 만에 WBS 만드는 법을 배워보세요!

---

🚀 WBS 도입 첫 걸음

월요일 아침, 10분 투자하기

스타터 템플릿

이번 주 WBS 예시:

월요일 (8h)

•  API 설계 리뷰 (2h)
•  로그인 모듈 구현 (4h)
•  단위 테스트 작성 (2h)

화요일 (8h)

•  코드 리뷰 반영 (2h)
•  통합 테스트 (3h)
•  문서 업데이트 (1h)
•  스탠드업 & 계획 (2h)

진행률: ⬜⬜⬜⬜⬜⬜⬜⬜ 0%

---

📊 WBS의 ROI: 숫자로 보는 효과

Before & After

투자 대비 수익

• 투자: 주당 2시간 WBS 관리
• 수익:
  • 프로젝트당 2주 단축 = 80시간 절약
  • 재작업 50% 감소 = 40시간 절약
  • 회의 시간 30% 감소 = 12시간 절약
• ROI: 1:16 (1시간 투자로 16시간 절약)

---

🎯 핵심 정리: WBS 3줄 요약

1. WBS = 프로젝트를 레고 블록으로 만들기
2. 작게 나누면 정확해진다 (±40% → ±10%)
3. 모두가 같은 그림을 본다 (혼돈 → 질서)

---

🔥 액션 아이템

오늘 당장 시작하기

1. 지금 진행 중인 작업 하나를 선택
2. 5개 이하 서브태스크로 분해
3. 각각 시간 추정 (1-8시간)
4. 팀 채널에 공유

다음 주 목표

•  팀 전체 작업을 WBS로 정리
•  주간 리뷰 미팅 도입 (30분)
•  진행률 대시보드 만들기

---

💬 마무리: 선택의 순간

"복잡한 것을 단순하게 만드는 것이 진정한 기술이다" - 스티브 잡스

WBS는 단순한 도구가 아닙니다. 프로젝트의 GPS입니다.

지도 없이 등산하시겠습니까?
아니면 WBS와 함께 정상을 향해 가시겠습니까?

---

🚀 다음 단계

무료로 WBS 시작하기: Plexo 14일 체험

다음 글 예고:
[실전편] "5단계로 완성하는 개발 프로젝트 WBS" - 실제 프로젝트에 WBS를 적용하는 구체적 방법

---

이 글이 도움되었다면 팀과 공유해주세요!

#WBS #프로젝트관리 #개발팀 #애자일 #Plexo

0번째 글: 돌아오며 — 왜 Plexo를 만들었나

오랜만에 블로그로 돌아왔습니다. 예전엔 Excel WBS로 일정을 프로젝트 예측하고 지켰고, 이제는 그 경험을 바탕으로 "예측 가능한 일정, 지키는 프로젝트"를 위한 웹서비스 Plexo를 만들었습니다.

나는 누구인가

"소프트웨어 개발의 모든것"이라는 책을 썼던 전규현입니다. 책에서 일정 관리 시 Excel WBS로 정확하게 예측하고 관리하는 방법을 소개했었죠.
참고: 소프트웨어 개발의 모든것 (YES24)

지난 수십년간 실무에서 수십 개 프로젝트를 운영하면서, Excel WBS의 강점과 한계를 몸소 체감했습니다.

1년 반 만의 복귀

솔직히 말하면 지난 1년 반, 블로그는 거의 방치했습니다. 글은 거의 안 쓰고, 개발에만 몰두했어요.
주말과 짬 나는 시간마다 무언가를 만들었고, 그 결과물이 바로 Plexo라는 프로젝트 관리 도구입니다. 이번에 정식으로 공개하게 되었습니다.

Excel WBS, 좋았지만 한계가 있었다

내가 사랑했던 Excel WBS의 핵심은 간단합니다.
"작업을 충분히 잘게 나눠서, 근거 있는 일정 추정을 만들고, 매일 그 오차를 줄여나간다."

이론적으로는 완벽하죠. 실제로도 잘 작동했습니다. 그런데 실무에서는 다음 제약을 피하기 어려웠어요.

• 실시간 협업의 어려움: 버전 충돌, 메일 첨부, 공용 드라이브에서 "누가 최종본이지?" 싸움
• 여러 프로젝트 동시 운영: A 프로젝트와 B 프로젝트의 리소스 충돌, 가시성 부족
• 이력/통계 축적의 어려움: 일정 편차, 지연 패턴, 반복되는 리스크를 체계적으로 분석하기 힘듦

그래서 만든 Plexo

Plexo는 "엑셀의 편리함은 유지하고, 협업과 자동화를 더한" 프로젝트 관리 도구입니다.

• 리소스 캘린더 기반 일정 예측: 담당자별 가용시간을 반영해 현실적인 마감일 산출
• 지연 위험 자동 감지: 계획 대비 실행 편차를 조기에 경고
• 실시간 동시 편집: Google Docs처럼 WBS를 팀이 함께 편집
• 포트폴리오 관리: 여러 프로젝트의 진행 상황과 리소스를 한눈에
• 가격: FREE 플랜(3 프로젝트/3 사용자/300 작업), Professional $29/월(14일 무료 체험)

어떻게 만들었나 — AI가 코드를 쓰고, 나는 리뷰했다

이번 프로젝트는 "AI-first 개발 프로세스"로 진행했습니다.

사양서(스펙)도 약 99%를 AI가 작성했어요. 나는 방향만 제시하고 리뷰하고 승인했습니다.
구현은 프롬프트 기반 반복 루프로 빠르게 진행했죠. (요구 사항 제시 → 스펙 작성 -> 코드 생성 → 테스트 → 리뷰 → 수정)

앞으로 연재할 글들

이 글을 시작으로, 매주 월요일과 목요일에 프로젝트 관리 이야기를 이어갑니다.
이미 6개 글을 준비해뒀으니, 다음 글들을 기대해주세요.

1. 개발팀이 알아야 할 WBS: 프로젝트 혼돈에서 질서를 찾는 마법
2. 5단계로 완성하는 개발 프로젝트 WBS 실전 가이드
3. Excel WBS의 종말: 현대적 협업 도구로 갈아타기
4. AI + 스펙 + WBS = 프로젝트 성공의 황금 조합
5. WBS 작성할 때 90%가 하는 실수 5가지
6. 프로젝트가 망하는 5가지 신호와 WBS로 막는 법

한번 써보세요

• 홈페이지: https://www.plexo.work
• 데모: https://demo.plexo.work
• 무료 가입(14일 무료 체험): https://app.plexo.work/register

피드백과 질문은 언제든 환영합니다.
다음 글에서 뵙겠습니다.

신제품보다 업그레이드 제품 번역이 더 어려운 이유 (27)

소프트웨어 국제화가 가장 쉬운 것은 신제품이다.

국제화의 여러 분야도 마찬가지이지만, 번역은 특히 신제품 개발 시 쉽게 접근하지만, 유지보수 때 쓴맛을 본다.

번역 아키텍처와 프로세스는 신제품이던지, 업그레이드 제품이던지 항상 쉽고, 빠르고, 비용을 최소화 해야 한다.

소프트웨어 개발 시 흔히 벌어지는 사례를 보자.

메시지가 1,000개쯤 되는 소프트웨어를 신규로 개발하고 있다. 번역해야 하는 언어는 10개이다.

개발자는 번역이 필요한 메시지를 소스코드에 적으면서, 별도의 번역 파일에 메시지를 적어 줘야 하는 방식으로 개발을 하고 있다. 

개발을 완료하고 1,000개의 메시지를 10개의 언어로 번역을 하여 개발이 완료되었다. 쫑파티도 했다.

이제 소프트웨어를 업그레이드 할 차례다.

메시지를 300개쯤 추가하게 되었다. 이것은 번역 파일에 300개를 추가하면 된다.

이 때 개발자는 새로 추가할 메시지가 기존의 번역 파일에 있는지 검색을 해야 한다. 원래 있던 메시지가 아니라도 오늘 아침에 다른 개발자가 추가했을 수도 있다.

만약에 내가 메시지를 삭제하게 되었다. 그러면 번역 파일에서 그냥 삭제를 하면 되는가? 그 메시지는 나만 쓰는 것이 아니고 다른 개발자가 다른 소스코드에서 쓰고 있다면?

그럼 소스코드 전체를 뒤져서 해당 메시지가 다른 곳에서 쓰이고 있는지 찾아봐야 하는가? 

이것도 완벽하지 않다.

때마침 다른 개발자가 해당 메시지가 번역파일에 있는 것을 알고 그 메시지를 이용해서 개발하고 있고, 아직 소스코드를 등록하지 않았다면?

이처럼 메시지를 새로 추가할 때, 삭제할 때 모두 문제가 된다.

이제 필요 없는 메시지라고 삭제를 하는 것도 문제가 된다.

메시지를 삭제했는데, 다음 버전에서 해당 메시지가 다시 쓰일 수도 있다. 그래서 메시지를 다시 추가하면 옛날에 번역했던 메시지를 다시 번역해야 한다. 비용과 시간의 낭비가 아닐 수 없다.

그래서 이런 문제가 전혀 없는 방식의 번역 아키텍처와 프로세를 사용해야 한다. 전 과정은 자동화 되어야 한다.

구체적인 방법들은 추후에 자세히 다루겠다.

소프트웨어 번역 전략 (26)

소프트웨어 국제화에서 가장 중요하며 많은 비용이 드는 것이 번역이다.

번역도 전략이 필요하다. 소프트웨어 번역을 어떻게 해야 하는지 알아보자.

영어 버전을 먼저

우리는 흔히 한국어 버전의 소프트웨어를 먼저 만들어 놓고, 나중에 영어 버전을 만들곤 한다.

이렇게 되면 메시지의 key가 한국어가 된다.

영어와 한국어 2개의 언어만 지원을 할 때는 문제가 안된다.

하지만, 여기에 프랑스어 하나를 추가하면 문제가 된다.

번역가에게 한국어를 프랑스어로 번역하도록 시켜야 하기 때문이다.

물론 번역한 영어를 주고 프랑스어로 번역하게 할 수도 있다.

이렇게 하면 항상 한국어를 영어로 번역한 후에 다른 언어로 번역을 해야 하는 2단계 과정을 거쳐야 한다.

그리고 영어 번역을 수정하면 다른 모든 언어의 번역을 다시 수정해야 한다.

그래서 전세계 거의 모든 번역가 표준의 삼는 영어를 기준으로 해야 한다.

소프트웨어의 첫번째 버전은 영어를 기준으로 만들어야 하며, 한국어버전만 필요한 경우에도 미래에 국제화가 필요하다면 영어, 한국어를 지원하는 소프트웨어를 만들어야 한다.

만약에 영어를 잘 못하는 개발자라면 영어 메시지를 만들어내기 어려울 수 있다.

요즘은 Google번역기와 같은 자동 번역기의 품질이 상당히 좋아서 한국어를 바로 영어로 번역할 수 있다. 검토 후에 문제가 없으면 바로 사용할 수 있다.

영어 검수는 추후 일괄적으로 한번 하면 되기 때문에 개발자들이 메시지 입력 시 자동번역기를 이용하는 것도 좋은 방법이다. 

번역 프로세스

주변에서 흔히 벌어지는 소프트웨어 번역 프로세스는 다음과 같다.

• 1년에 걸쳐서 소프트웨어 개발을 완료한다.
• 2개월에 걸쳐서 소프트웨어를 번역한다.
• 1개월에 걸쳐서 테스트를 한다. 번역이 잘못된 것을 발견한다.
• 번역을 수정하고, 다시 테스트를 하고 출시한다.

이렇게 하면 계획된 일정에 소프트웨어를 출시하기 어렵다.

번역을 마지막에 한꺼번에 하게 되면 화면 배치가 많이 깨져서 대대적인 수정을 해야 한다. 똑같은 문장이라도 한국어는 대체로 짧다. 한국어를 영어, 특히 독일어로 번역을 하면 2배 또는 3배까지 길어진다. 그래서 번역을 고려하여 UI 배치를 해야 한다.

소프트웨어가 70% 정도 개발이 되었을 때 먼저 1차로 번역을 하고, 90% 정도 개발이 되었을 때 2차 번역을 한다. 마지막으로 구현이 완료 되었을 때 최종 번역을 한다.

이렇게 70%, 90%, 100% 단계별로 번역을 하면, 소프트웨어 구현과 거의 동시에 번역도 완료가 되어 있어서 번역 때문에 소프트웨어 출시가 늦어지는 일은 없다.

소프트웨어 개발 계획을 세울 때 번역 일정도 같이 수립하고 번역 업체도 미리 섭외하여 일정에 지장이 없도록 해야 한다.

번역 방법

번역을 하는 방법은 몇가지가 있다. 각각 장단점이 있으니 비교하여 선택하자.

전문 번역자(회사) 이용

전문 번역회사를 이용하거나 번역자를 채용할 수도 있다. 

소프트웨어 개발 프로세스 상 번역은 항상 벌어지는 일이 아니기 때문에 아주 큰 회사가 아니면 번역가를 보유하기가 어렵다. 그리고 언어별로 모든 번역가를 채용하는 것이 어렵기 때문에 대부분의 회사는 전문 번역 회사를 이용하거나 병행한다.

번역 회사를 고를 때는 해당 언어에 대해서 능숙한 것 외에도 해당 분야에 경험이 많은 회사를 고르는 것이 좋다. 금융, 의료 등 전문 용어를 많이 사용하는 소프트웨어는 아무나 번역을 할 수는 없다. 전문 번역가의 경우 비용이 더 들어가지만 그만큼 번역 품질이 높다.

소셜 번역

전문 번역가는 아니지만 Flitto와 같은 앱을 통해서 전세계 일반인들에게 작은 비용을 주고 번역을 시키는 방법이 있다. 

대규모 번역을 시키는 것은 어렵지만, 작은 소프트웨어에서 작은 번역을 싸게 맡길 수 있는 장점이 있다.

자동 번역기

AI의 발달과 함께 자동 번역기는 엄청나게 발전했다.

구글 번역기, DeepL 등은 번역 품질이 매우 좋다. 

POEDIT의 유료 버전은 자동 번역을 매우 빠르게 한다.

무료이거나 저렴한 것이 장점이지만, 품질을 보장하기 어려운 것이 단점이다.

정확한 번역

동일한 단어라도 상황에 따라서 다른 뜻으로 사용되는 경우는 매우 흔하다.

Ruler라는 단어만 하더라도 '자'가 될 수도 있고, '지배자'가 될 수도 있다.

Ruler를 그냥 번역해달라고 요청을 하면, 원하지 않는 방향으로 번역될 가능성이 높다.

이럴 때는 '번역 가이드'를 같이 전달하는 것이 좋다.

'번역 가이드'는 영어로 전달해야 한다. 그래야 전세계 번역가가 잘 이해할 수 있다.

Ruler의 번역 가이드는 'a stick to measure the length'와 같이 적으면 된다.

'번역 가이드'는 소스코드에 해당 message를 사용하는 곳에 같이 작성하면 된다.

그럼, 개발자들은 해당 용어를 사용할 때, 이 용어가 잘못 번역될 가능성이 있는 단어인지 잘 생각해야 한다. 여러 뜻을 가진 단어라면 '번역 가이드'를 추가하거나 오해가 없는 확실한 단어로 교체하는 것도 좋다.

물론 소스코드에서 message를 추출하고 '번역 가이드'도 같이 추출하는 것은 완전 자동화 되어야 한다.

번역 검수

프랑스어로 번역을 할 때 외주를 맡기는 것은 우리가 프랑스어를 잘 모르기 때문이다. 그래서 번역을 해와도 프랑스어가 제대로 번역된 것인지 알기가 어렵다.

그래서 번역이 제대로 되었는지 확인을 하려면 번역 검수 절차를 거쳐야 한다.

소프트웨어를 해외 총판을 통해서 판매를 할 경우 해외 총판의 원어민에게 검수를 시키면 좋다. 따는 우리의 해외 우수 고객에게 미리 써보게 하는 필드 테스트를 진행할 수도 있다. 이 때 번역이 잘못되었거나 좀 이상한 것은 꼼꼼히 봐달라고 부탁을 하면 된다.

이렇게 검수 과정을 거쳐야 품질 좋은 소프트웨어를 만들 수 있다.

지금까지의 모든 과정을 소프트웨어 개발 계획을 수립할 때 미리 감안해서 계획을 수립해야 한다. 

   

소프트웨어 국제화 전략 (25)

소프트웨어를 이미 개발해 놓고 비즈니스가 잘되면 나중에 국제화를 적용하려고 하면 늦다는 것을 이전 글에서 살펴 보았다.

소프트웨어를 기획할 때부터 향후 1%라도 국제화 가능성이 있다면 계획에 따라서 적절한 국제화 기술을 미리 적용하는 것이 좋다. 

그럼 어떠한 경우 국제화가 필요한가?

• 국내 외에 해외에 소프트웨어를 판매하거나 서비스할 수 있다.
• 국내에서만 판매할 계획이지만, 국내의 외국인 고객이 사용할 수 있다.

그럼 소프트웨어 국제화가 필요한 경우 어떠한 국제화 전략을 어떻게 수립해야 하는지 알아보자.

국제화 적용 수준을 결정한다.

당장은 아니고 미래에 해외에 팔 계획이 있는 소프트웨어라면 초기부터 국제화 기능을 모두 적용하면 기간, 비용이 많이 든다. 이러다가 해외 판매 계획을 취소하면 국제화 투자 비용은 매몰 비용이 된다. 

따라서 판매 계획에 따라서 국제화 적용 정도를 달리하는 것이 좋다.

소프트웨어에 국제화 기능을 구현하기 위해서는 크게 2가지 모듈이 필요하다.

• 국제화 모듈 (i18n module or library)
• 지역화 모듈 (L10n module or library)

국제화 모듈은 국제화 아키텍처 전체를 다루는 모듈이고, 지역화 모듈은 하나의 국가 또는 언어 기능을 지원하는 모듈이다. (아래 그림 참조)

당장 해외 판매 계획이 있다면 위 그림 처럼 여러 지역화 모듈을 모두 만들어야 하지만, 당장은 국내에서만 판매를 하고 추후에 해외에 판매를 하려면 아래와 같이 필요한 국제화 기능만 개발을 하면 된다.

이렇게 개발을 하면 한국어 전용으로 개발하는 것보다 1~2%의 개발 비용이 더 들지만, 나중에 국제화 기능을 새로 추가하는 것보다는 10배 이상 비용을 절약할 수 있다.

국제화를 적용할 범위 결정

국제화는 매우 광범위하다.

아래는 국제화 시 고려해야할 49가지라는 지난 글이다.

https://www.allofsoftware.net/2012/09/49.html

물론 이 모두를 적용할 필요는 없다. 내용을 읽어보고 현실적으로 우리 소프트웨어에 적용해야 할 범위를 결정한다. 국제화에 대한 지식, 경험이 없다면 무엇이 필요한지 결정이 어려울 수가 있으므로 국제화 전문가나 경험자의 도움을 받는 것이 좋다.

보통 필수적으로는 아래와 같은 것들을 적용한다.

• 문자열 (번역)
• 날짜/시간
• 숫자
• 쓰기 방향 (좌우, 우좌)
• 대소문자
• 문자 정렬

시스템적으로 필수적으로 결정해야 할 기술적인 요소는 다음과 같다.

• 문자 인코딩 방법 및 변환
• Database, File, Network communication 시 사용할 문자 Encoding
• 지금은 UTF-8이 대세지만 아닌 경우도 있어서 주의해야 한다.
• 국제화에 유리한 UI 배치
• 타임존 처리

선택적으로는 소프트웨어의 종류나 특성에 따라서 추가 결정을 한다. 

• 폰트의 종류와 크기
• 화폐 단위
• 주소
• 전화번호
• 이름 표기
• 아이콘

처음에는 어려운 일이지만, 국제화 모듈을 한번 잘 만들어 놓으면 회사의 여러 소프트웨어에 재사용이 가능하다. 

국제화 조직 구성

큰 소프트웨어 조직은 국제화 팀이 별도로 있지만, 작은 조직은 별도의 팀을 갖추기가 어렵다. 그렇다면 일반 SW팀에 국제화 담당자를 별도로 지정하여 국제화 아키텍처를 설계하고, 국제화, 지역화 모듈을 개발하게 하면 된다.

모든 개발자가 국제화 기술을 다 알 필요는 없다. 국제화 담당자가 잘 만들어 놓은 기능을 그냥 써서 개발을 하면 된다.

시간을 표시하는 함수 하나도 그냥 쓰지말고 또는 본인이 직접 국제화를 적용하지 말고 국제화 담당자가 잘 만들어 놓은 국제화 시간 함수를 사용하면 되는 것이다.

국제화 담당자도 개발 초기 부터 국제화 모듈을 모두 완성해 놓을 필요는 없다. 그렇게 한다면 국제화 담당자가 국제화 모듈을 완성할 때까지 일반 개발자들은 개발을 시작할 필요가 없다.

국제화 담당자는 국제화 범위를 정하고 Interface만 정해 놓으면 된다. 즉 국제화 모듈의 Interface만 정하고 지역화 모듈은 제대로 개발할 필요가 없다.

시간 함수를 예로 들면 시간 함수의 Interface를 잘 정하고 나면 그 내용은 그냥 시간을 출력하는 함수를 최대한 간단히 구현해 놓으면 되고, 국가별 언어별로 다른 표시법은 적용할 필요가 없다.

이렇게 인터페이스를 만드는 데는 며칠 걸리지 않는다.

나중에 개발을 진행하면서 지역화 모듈의 내용을 하나씩 채워가면 지연 없이 개발이 진행된다.

국제화 마인드

국제화가 잘 된 소프트웨어를 개발하는 것은 매우 어렵다. 경험이 적으면 국제화가 누락된 소프트웨어를 개발하기 쉽다.

예를 들어보자.

사용자가 입력한 문자열을 단어별로 쪼개서 처리하려고 한다. 그래서 띄어쓰기로 token을 구분하여 처리를 했다고 하자. 하지만 띄어쓰기를 사용하지 않는 언어는 의외로 많다. 이런 곳에서는 이 기능은 제대로 동작하지 않을 것이다. 이처럼 예상치 못하게 국가별 언어별로 다른 것들이 꽤 많다.  다음과 같은 것들이 있다.

• 띄어쓰기
• 단수, 복수 처리
• 좌우 쓰기 방향
• 문장 순서
• 달력

이외에 매우 많다. 어떤 것은 해당 국가에서 이상하게 보여도 나름 용인이 되는 것도 있고, 용인이 되지 않는 것도 있고, 명백히 버그가 되는 것도 많다.

예를 들어 숫자의 소숫점은 국가별로 다르다. 숫자의 소숫점을 잘못 처리하면 명백한 버그가 되고 큰 사고가 될 수도 있다.

그래서 우리가 이러니 전세계 모든 국가에서도 이럴 것이라면 생각을 버려야 한다. 어려운 일이다. 그래서 국제화 전문가가 회사에 적어도 한명은 있으면 좋다. 그렇지 않으면 국제화 전문가의 컨설팅을 받으면 적은 비용으로 큰 문제를 해결할 수 있다.

국제화 프로세스

국제화 조직 또는 담당자는 국제화 모듈만 개발하는 것이 아니고 국제화 프로세스를 잘 정해야 한다. 국제화 초보자에게는 매우 어려운 일이지만 필요한 것이 프로세스다.

예를 들어 문자열을 번역하기 위해서는 여러 단계가 필요하다.

• 소스코드에 국제화 문자열 함수를 작성한다.
• 문자열을 추출한다.
• 추출한 문자열을 각 언어로 번역한다.
• 소프트웨어에 번역된 문자열을 적용한다.
• 검수를 한다.

국제화 프로세스는 최대한 자동화가 되어야 한다.

국제화가 누락되는 부분을 찾기 위해서는 코드 리뷰 절차에 국제화 관련 부분이 추가 되어야 한다.

그리고 테스트 프로세스에서도 국제화 부분이 추가되어야 한다.

결론

우리나라에는 수많은 회사가 소프트웨어 국제화에 실패한 역사가 있다. 초기에 소프트웨어 인코딩 결정의 실수로 대규모 서비스가 글로벌 서비스에 실패하기도 한다. 

소프트웨어 국제화의 실패로 좌초된 경우조차 그 원인을 국제화에서 찾지 못하는 경우가 대부분이다. 그래서 매우 중요하지만 아주 소홀히 하는 분야이기도 하다.

국제화는 결코 소홀히 하면 안되고, 소프트웨어 개발 초기부터 심각하게 고민하지 않으면 안된다.

소프트웨어 국제화는 나중에 적용하면 늦는다 (24)

 잠시 중단했던 소프트웨어 국제화 칼럼을 재개한다.

당장의 소프트웨어 출시가 급하다고 국제화를 고려하지 않고 일단 개발하고 출시를 했다가 나중에 필요 시에 국제화를 적용하려고 하면 안된다. 비용이 너무 많이 들거나 너무 복잡해져서 제품 자체가 망가지기도 한다.

실제로 많은 회사들이 소프트웨어 국제화에 실패해서 비지니스에서도 실패하는 경우가 많다.

처음에는 국내에서만 팔다가 나중에 해외 진출을 하면서 뒤늦게 국제화를 적용하다가 낭패를 본다.

국제화를 적용하려고 했더니 데이터 베이스의 인코딩 등 설정을 바꿀 수 없기도 하고, 기능이나 UI를 대거 바꾸지 않으면 안되기도 한다. 초기부터 국제화를 적용했을 때의 국제화 비용보다 수십배 또는 수백배가 들기도 한다. 또한 수많은 버그를 만들어내곤 한다.

국제화를 적용하기에는 너무 늦어져 국제화 버전을 따로 개발해서 똑같은 소프트웨어가 여러벌이 되기도 하는데, 이는 더 큰 문제가 된다. 돌아올 수 없는 강을 건넌 것과 같다.

우리가 개발할 소프트웨어가 영원히 한국에서만 팔릴 소프트웨어라면 국제화를 적용할 필요가 없다.

한국에서만 팔리는 소프트웨어라도 한국내의 외국인을 위해서 여러 언어를 지원해야 한다면 국제화가 필요하다.

당장은 한국에서만 판매를 하지만 추후 해외에서도 판매할 계획을 1%라도 가지고 있다면 초기부터 국제화를 적용해야 한다.

당장 국제화 기능이 필요한 것은 아니고 추후 필요한 경우라면 국제화 아키텍처만 적용하여 나중에 국제화가 필요할 때 언제든지 적은 비용으로 빠르게 국제화를 적용할 수 있도록 할 수 있다.

간단한 예를 들어보자.

소프트웨어 내에는 날짜, 시간을 처리하는 수많은 모듈들이 있다. 이것을 국제화를 고려하지 않고 개발자들이 알아서 한국어에만 알맞게 개발을 한다면 어떻게 될까?

한국에서는 잘 동작할 것이다. 하지만 영어, 프랑스어 등 외국어를 지원해야 하는 국제화가 필요할 때는 큰 문제가 된다. 날짜를 처리하는 수많은 코드를 찾아다니면서 모두다 고쳐야 한다.

개발자들이 적절히 날짜 함수에 국제화 코드를 적용했다고 하더라도 문제가 된다. 각각 따로 적용한 국제화 코드는 일관성이 떨어져서 날짜를 표시하는 위치마다 다른 형태의 날짜가 표시될 수 있다.

그럼 당장 국제화가 필요하지 않지만 미래를 위해서 국제화 코드를 미리 적용해 놓으려면 어떻게 해야 할까?

날짜, 시간를 처리(입력, 출력)하는 모든 기능을 별도의 국제화 함수(클래스)로 분리를 하는 것이다. 그리고 모든 개발자는 날짜, 시간을 다룰 때는 꼭 이 국제화 함수를 사용하도록 하는 것이다. 이 국제화 날짜, 시간 함수는 현재는 한국어만 지원하지만 추후 필요할 때 언제든지 다양한 언어를 쉽게 지원할 수 있다.

날짜, 시간 처리 함수는 필요한만큼 다양하게 준비해야 한다. 소프트웨어 UI상 필요한 모든 조합을 함수로 만들어 놓아야 한다.

년월일시분초

년월일

시분초

날짜, 시간 함수 관련 추가 내용은 아래 글을 참조한다.

https://www.allofsoftware.net/2015/06/010203-12.html

제공된 국제화 함수 외에 다른 형식의 날짜 출력 함수가 필요하면 개별 개발자는 스스로 함수를 만들어서 사용하면 안된다. 국제화 담당 개발자에게 필요한 날짜 출력 함수를 만들어 달라고 요청한 한 후에 그 함수를 써야 한다. 1인 개발이라면 한명의 개발자가 양쪽 역할을 다하면 된다.

국제화 외부 라이브러리가 모든 것을 해결해주지는 않는다. 외부 라이브러리를 이용하더라도, 현재 프로젝트에 맞게 다 커스트마이징해서 일관된 국제화 함수들을 만들어 줘야 한다. 개발자들에게 각자 알아서 국제화 함수를 사용하라고 하면 일관성이 없고 중구난방이 된다.

국제화 함수 인터페이스는 나중에 바뀌지 않도록 잘 정해야 하므로 경험이 많은 고참 개발자가 정하는 것이 좋다.

날짜 외에도 고려해야 할 것은 많다. 아래 그 예를 보자.

번역이 필요한 메시지, 문자 인코딩(Database, File, 통신), 키보드 글자 배치, 폰트 종류, 글자 크기, 숫자 표기, 띄어쓰기, 쉼표, 마침표, 날짜/시간 표기, 썸머타임, 대소문자, 정렬 방법, 화폐, 무게, 부피, 길이, 종이크기, 온도, 주소, 이름, 제도 관련, 문화 관련 색깔/아이콘 등, 소리, 텍스트를 포함한 아이콘, O/X 기호, 문자 입력 방향

국제화 이슈가 있는 것은 개별 개발자가 마음대로 개발하면 안되고, 국제화 라이브러리에 추가한 후에 사용해야 한다. 모든 소프트웨어가 이 모든 항목을 고려해야 하는 것이 아니므로 국제화 이슈가 있을 것 같은 항목을 만나면, 또는 이미 구현을 했어도 나중에 발견하면 국제화 라이브러리로 옮겨야 한다.

소프트웨어의 어떤 부분이 국제화의 영향을 받을지 찾아내는 것도 중요하다. 그래서 국제화 경험이 많은 개발자가 필요하다. 

개발 초기에 소프트웨어 국제화 전문가에게 컨설팅을 받는 것도 좋다. 대충 개발하고 나중에 국제화가 문제 되어서 큰 비용을 지불하는 것보다 훨씬 경제적이다.

국제화 아키텍처를 어떻게 구성해야 하는지는 아래 글을 참조한다. 실제는 이보다 훨씬 복잡하지만 간단한 참조는 될 것이다.

https://www.allofsoftware.net/2015/06/5.html

소프트웨어 국제화는 쉽게 생각했다가는 큰코다칠 수 있지만, 초기부터 제대로 적용하면 큰 무기가 될 것이다.

"소프트웨어 스펙의 모든 것" 책을 출판했습니다.

 그동안 블로그를 통해서 연재를 시작했던 "소프트웨어 스펙" 시리즈를 책으로 출판했습니다.

블로그를 통해서 얘기를 시작했지만, 서두 부분만 진행을 했는데, 책을 출판하는 것이 많은 개발자에게 도움이 될 것 같아서 한빛미디어를 통해서 책을 출간하게 되었습니다.

책을 통해서 소프트웨어 프로젝트에서 가장 중요한 스펙에 대해서 익히는데 많은 도움이 될 것입니다.

Link : 한빛미디어, Yes24, 알라딘, 교보문고