2017년 5월 29일 월요일

점핑프로그 게임이 만들어지기까지

나처럼 게임을 취미로 만들고자 하는 사람들에게 조금이나마 도움이 될까 싶어서 점핑프로그의 탄생에 얽힌 이야기를 해보려한다.

나는 현재 소프트웨어 개발 프리랜서다.
지금은 테스트와 관련된 개발을 주로 진행하고 있으며 경력은 18년 정도 되었다!

이런 내가 처음으로 게임을 만들기 시작하게 된 것은 2013년으로 기억된다.
그때 아들에게 숫자를 재미있게 가르쳐보려고 시작한 것이 계기가 되었다.
당시에 만든 게임은 예전 핸드폰과 함께 사라져서 지금은 찾을 수 없다.

그때 사용한 게임 엔진이 libGDX(https://libgdx.badlogicgames.com/) 인데 Opensource 게임엔진으로 Cross-Platform 을 지원하여 선택하게 되었다.
그 당시에는 0.9.3 버젼으로 개발했던 걸로 기억되는데 오늘 확인해보니 1.9.6 까지 release 가 되어있다.

libGDX 를 선택한 가장 큰 이유는 Cross-Platform 을 지원하기 때문에 개발하면서 윈도우환경에서 바로 테스트해볼 수 있다는 점이 좋았다.
안드로이드의 느린 에뮬레이터를 사용할 필요도 없고, 윈도우환경에서 돌아가는 모습이 별다른 작업없이 그대로 안드로이드에서도 동일하게 돌아가는 모습에 많이 감탄했던 것으로 기억된다.


그러다가 2015년 3월 Unity(https://unity3d.com) 를 무료로 제공한다는 기사를 접하고 Unity 라는 게임엔진을 처음으로 알게되었다.


Unity를 2015년 말부터 공부하게 되었고, 2016년 6월 첫번째 게임을 만들게 되었다.



  • 첫번째 게임 : 팔로우미(Follow Me)

장르는 아케이드 횡스크롤 게임이다.
조작방식은 버튼 터치(Touch)를 통해 리더 새(Leader bird)를 조정하여야 한다.
게임의 목표는 최대한 많은 새들을 이끌고 도착지까지 날아가는 것이다.



이 게임은 결국 출시를 하지는 못했다.
이유는 Unity 를 처음 사용하다보니 공부하면서 만든 게임이라서 터치감 조절에 실패하였다.
또 이펙트(Effect)가 화려하지 못하여 게임의 재미요소를 주지 못했다.
그래도 Unity에 대한 이해를 높여줬다는 점과 수묵화의 느낌이 풍기는 게임을 시도해 봤다는 것에 의미를 두고있다.




  • 드디어 점핑 프로그 - 나뭇잎 청소부(Jumping Frog - Leaf Cleaner) 출시

점핑 프로그(https://play.google.com/store/apps/details?id=com.kimssoft.jumpingfrog)는 한 붓그리기를 응용한 퍼즐게임이다.
게임의 목표는 개구리가 모든 나뭇잎을 없애면서 도착지까지 가는 것이다.



게임의 장르가 퍼즐이다 보니 퍼즐을 좋아하는 사용자들이 아니면 쉽게 다운받지 않을 것으로 예상했었다.
그런데도 내가 퍼즐 장르를 선택한 이유는 캐릭터 디자인에 있었다.
내가 개발자이다 보니 그림을 그리는 것이 너무 어렵고 시간도 많이 걸렸다.



그래서 생각한 것이 타일기반의 퍼즐게임이다.
타일기반의 퍼즐 게임은 몇가지 종류의 타일만 그리고 나면 모든 스테이지(Stage)에서 타일을 재사용 할 수 있을 것 같았기 때문이다.
다행히 예상은 맞아 떨어져서 그림에 쏟는 시간은 많이 줄일 수 있었다.
하지만 역시 다운로드에는 한계가 있었다.




현재 다운로드수 250명 중 50명은 지인이고, 나머지 200명은 광고를 통해 유입된 사용자들이다.
결국 첫번째 게임은 기대에 미치지 못하는 성과를 거두었다.

나름대로 의미를 찾는다면 첫번째 출시작이라는 점과 만들고 싶은 기능은 모두 만들었다는 점이다.
아이템 판매를 위해서 Unity 의 IAP 라이브러리를 사용하여 아이템 구매 기능을 추가하였고, Unity Ads 를 사용하여 동영상 광고도 넣었다.
그리고 배너(Banner)나 전면(Full Screen) 광고를 위해 Admob 광고도 부착하였다.
또한 무료와 유료 게임을 모두 출시해 보았다.




  • 두번째 출시작 점핑 프로그-어둠의 강(Jumping Frog - Dark River) 출시

점핑 프로그-어둠의 강(https://play.google.com/store/apps/details?id=com.kimssoft.jumpingfrog.darkriver.free) 은 메모리 게임이다.
게임의 목표는 어둠이 내린 강에서 장애물(Tornado)을 피해서 목표 지점까지 도달하는 것이다.



"점핑 프로그 - 어둠의 강" 부터 게임에 부제(Sub-title)를 붙이기 시작하였다.
원래 첫번째 출시작인 "점핑 프로그 - 나뭇잎 청소부" 의 원 제목은 그냥 "점핑 프로그" 였다.
그런데 두번째 게임도 개구리를 테마로 만들다 보니 부제(Sub-title)를 붙이게 되었고, 그래서 첫번째 게임에도 부제(Sub-title) "나뭇잎 청소부(Leaf Cleaner)" 를 붙이게 되었다.

조금은 예상을 했겠지만 그림을 또 그리는 것이 너무 힘들 것 같아서 첫번째 게임의 디자인을 재활용할 방법을 찾게 되었고, 자연스럽게 점핑 프로그 시리즈로 게임을 만들어 보자는 생각으로 두번째 게임을 만들게 되었다.



"어둠의 강(Dark River)" 은 "나뭇잎 청소부(Leaf Cleaner)" 보다는 성적이 좋았다.
광고를 시작하고 몇 일 지나지 않아서 다운로드 수가 450명에 도달하였다.
다운로드 국가 랭킹은 이라크 -> 몽골 -> 방글라데시 순이었다.



"어둠의 강" 과 "나뭇잎 청소부" 는 구글 플레이(Google Play)에 있는 광고 켐페인을 통해 각각 50,000원씩 광고비를 지출하였다.
그랬을 때 "어둠의 강" 이 "나뭇잎 청소부" 보다 2배 많은 다운로드 수를 기록하였다.
왜 "어둠의 강"이 2배 더 많은 다운로드를 기록했는지 정확한 이유는 알 수 없다.
다만 추측하기로는 게임 아이콘이 좀 더 눈에 확 들어왔을 것으로 생각한다.



현재 점핑 프로그 3탄을 준비중에 있으며 이번에는 퍼즐장르를 벗어난 게임을 만들어 보려하고 있다.

클라우드 컴퓨팅 이해하기

클라우드 컴퓨팅이란 무엇일까?

간단하게 말하면 인터넷을 통해서 파일 저장소, 데이터베이스, 가상 서버, 네트워크, 소프트웨어 등의 컴퓨팅 환경을 제공하는 것을 말한다.
즉 서버 포함하여 개인 컴퓨터가 가지고 있거나 가질 수 있는 모든 기능을 인터넷을 통해서 서비스하는 것을 통칭하는 것이라고 생각하면 될 것 같다.

모든 것을 인터넷으로 서비스(Service)하기 위해서 클라우드 컴퓨팅은 다음과 같은 특성들을 가지고 있어야한다.




  • Broad network access
다양한 사용자의 기기들이 인터넷을 통해서 서비스에 접속할 수 있어야한다.


  • On-demand and Self-service
서버, 네트워크, 스토리지 같은 자원들은 사용자의 요청에 따라 언제라도 공급이 가능해야하고, 이를 사용자가 직접 제어할 수 있어야 한다.


  • Resource pooling
제공되는 전체 자원은 여러 사용자들에 의해 공유 되고 재사용 되어야하고, 대신에 각각의 사용자 영역은 자원을 반납하기 전까지 독립적으로 유지되어야 한다.
이를 위해 가상화(Virtualization)와 멀티테넌트(Multi-tenant)를 구현해야한다.


  • Rapid elasticity
제공되는 자원은 빠르고 탄력적(Rapid elasticity)으로 공급되어야한다.


  • Measured service
사용자의 서비스 사용량은 정량적을 측정되어 사용자에게 전달되어야한다.



위와 같은 특성을 갖는 클라우드 컴퓨팅은 서비스 범위에 따라서 아래와 같이 구분하여 표현할 수 있다.

출처 : https://blogs.msdn.microsoft.com/eva/?p=1383

  • Packaged Software
개인용 컴퓨터가 보급되면서 개인이 하드웨어 부터 소프트웨어에 이르기까지 모든 자원을 스스로 관리하는 모델이 나타나게 되었다.
소프트웨어는 패키징(Packaging)되어 공급되었고, 사용자들은 패키징된 소프트웨어를 자신의 컴퓨터에 설치해야만 사용할 수 있었다.
뿐만 아니라 인터넷을 사용하기 위해서는 통신서비스 업체에게 인터넷 서비스를 신청해야했고, 저장 용량이 부족하면 하드디스크(HDD)의 용량을 늘리는 작업들을 모두 직접해야만 했다.
사용자는 컴퓨터의 전문가 수준이 되어야만 했던 모델이다.


  • IaaS(Infrastructure as a Service)
클라우드 컴퓨팅의 IaaS 모델은 인프라(Infrastructure) 자원은 서비스(Service)로 제공받고 나머지 부분에 대해서만 사용자가 관리하는 모델이다.
그래서 사용자는 인터넷 서비스 업체를 선정하거나 하드디스크(HDD)의 용량을 늘리는 작업을 직접 하는 것이 아니라 서비스로 제공받는다.
사용자가 할 일은 인터넷 속도와 하드디스크의 용량을 결정하여 서비스를 요청(Self-Service)하고 그에 대한 대가를 지불하면 된다.
초기 클라우드 컴퓨팅은 IaaS 모델로 서비스를 시작하였다.
현재 아마존(AWS)의 EC2와 S3 , 마이크로소프트(Microsoft)의 Azure, IBM 등이 모두 IaaS 모델의 서비스를 제공하고 있다.


  • PaaS(Platform as a Service)
PaaS 모델은 IaaS 모델의 범위를 넘어서 O/S 와 미들웨어까지 서비스(Service) 형태로 제공하는 모델이다.
사용자는 하드웨어 리소스(H/W Resource)뿐만 아니라 O/S 와 그 위에서 동작하는 미들웨어까지 모두 서비스 요청으로 제공받을 수 있다.
결국 사용자는 어플리케이션 개발과 데이터 관리만 신경쓰면 되는 모델이다.
현재의 클라우드 컴퓨팅은 IaaS 모델 서비스를 확대하여 PaaS 로 나아가고 있다고 할 수 있다.
클라우드 컴퓨팅을 이끌고 있는 아마존(AWS)과 마이크로소프트의 Azure 가 모두 PaaS 모델의 서비스를 제공하고 있다.


  • SaaS(Software as a Service)
SaaS 모델은 PaaS 모델의 범위를 더욱 확대하여 어플리케이션과 데이터 관리까지 모두 서비스 형태로 제공하는 모델이다.
사용자가 할 일은 비즈니스 모델(Business Model)을 개발하여 그에 맞는 서비스들을 선택하고 요청하는 일만 하게되는 모델이다.
현재의 클라우트 컴퓨팅 제공업체들이 아직까지는 SaaS 모델을 완벽하게 지원하고 있지는 않는다.


로컬(Local) 컴퓨팅 시대에서 클라우드 컴퓨팅 시대로 세상은 빠르게 변하고 있다.
클라우드 컴퓨팅도 IaaS 에서 PaaS 로 빠르게 발전하고 있다.
클라우드 컴퓨팅은 조만간 PaaS 에서 다시 SaaS 발전해 갈 것이다.

2017년 5월 24일 수요일

SW 테스트의 종류 총정리하기

소프트웨어 테스트의 종류에 대해서 알아본다.

테스트의 종류는 여러가지 분류기준에 따라서 다양하게 이름 붙여질 수 있다.
이 글에서는 아래와 같이 테스트 종류를 구분하고 정리할 것이다.

  • 블랙박스 테스트 vs 화이트박스 테스트 
블랙박스(Black Box) 테스트
소프트웨어 내부 구조가 어떻든 간에 외부로 나타나는 현상만을 기준으로 테스트한다.

화이트박스(White Box) 테스트
소프트웨어 내부 구조를 잘 이해하는 사람이 겉으로 들어나지 않는 기능들을 테스트한다.

  • 기능 테스트 vs 비기능 테스트 
기능(Functional) 테스트
소프트웨어의 기능을 확인하는 테스트한다.

비기능(Non-functional) 테스트
소프트웨어 기능외에 비기능적인 것을 테스트한다. 예를 들면 성능(Performance)이나 안정성(Stability) 등을 테스트한다.


이렇게 4개의 영역으로 테스트를 분류하고 각각의 테스트를 배치하면 아래 그림과 같이 분류할 수 있다.






  • 인수 테스트(Acceptance Test)
고객의 요구사항(Requirements) 을 만족하는지 여부를 확인하는 테스이다.
그래서 요구사항(Requirements)을 분석하여 테스트 항목을 추출한다.
인수 테스트는 나중에 프로젝트 종료를 결정짓는 중요한 기준이 되기 때문에 프로젝트 초기부터 관리가 되어야한다.


  • 시스템 테스트(System Test)
전체 시스템 관점에서 테스트를 수행한다.
시스템 테스트는 고객의 요구사항(Requirements)을 만족시키기 위해 필요한 내용은 모두 테스트 범위에 포함시킨다.
다만 통합 테스트(Integration Test)처럼 화이트박스 테스트는 아니고 블랙박스 관점에서 테스트 항목을 추출하여 테스트한다.


  • 통합 테스트(Integration Test)
개발된 각 컴포넌트(Component)를 통합하면서 발생할 수 있는 버그를 확인하기 위한 테스트이다.
개별 컴포넌트만 테스트할 때는 확인할 수 없는 부분을 확인하기 위한 테스트이다.


  • 유닛 테스트(Unit Test)
단위 기능에 대해 확인하는 테스트이다.
개발자가 작성한 함수(Function)의 기능 하나 하나를 테스트한다.
그렇기 때문에 코드를 가장 잘 이해하고 있는 코드 작성자가 테스트를 주로 진행한다.


  • UI 테스트(User Interface Test)
사용자의 인터페이스(Interface) 기능 하나 하나를 확인하는 테스트이다.
대상 UI 컴포넌트가 정상적으로 동작하는지 확인한다.
UI 테스트는 인수 테스트와 시스템 테스트에 모두 포함되어 있다.


  • 시나리오 테스트(Scenario Test)
UI 테스트가 개발 UI 컴포넌트에 대한 테스트라면 시나리오 테스트는 UI 테스트의 조합으로 이루어진 테스트이다.
사용자의 사용 시나리오를 바탕으로 테스트 시나리오를 작성하여 테스트를 수행한다.
시나리오 테스트는 인수 테스트와 시스템 테스트에 모두 포함되어 있다.


  • 성능 테스트(Performance Test)
소프트웨어의 성능이 기준을 만족하는지 확인하는 테스트이다.
그래서 성능에 대한 기준을 정하는 것이 매우 중요한데 요구사항에 성능이 정의되어 있으면 요구사항을 기준으로 삼아야한다.
만약 요구사항에 성능이 정의되어 있지 않다면 고객과 합의를 통해 성능기준을 개발초기에 정의해야 한다.
예를 들면 "웹 페이지(Web Page)의 반응 속도는 5초를 넘지 말아야 한다." 등의 경우가 성능 기준이라고 할 수 있다.


  • 안정성 테스트(Stability Test)
소프트웨어가 안정성 기준을 만족하는지 확인하는 테스트이다.
안정성 기준이 요구사항에 정의되어 있다면 요구사항을 기준으로 삼아야 하지만 그렇지 않다면 일반적인 성능을 토대로 고객과 합의하여 기준을 정해야 한다.
예를들면 "1000명이 동시접속하여 24시간 사용하여도 시스템이 다운되지 않아야 한다." 등의 경우가 안정성의 기준이라고 할 수 있다.


  • 스모그 테스트(Smoke Test)
스모그(Smoke)는 연기를 뜻하는 것으로 하드웨어 보드에서 연기가 나는지 확인하는 것을 비유한 테스트이다.
즉, 아주 기본적인 기능을 확인하는 테스트이다.
그렇기 때문에 스모그 테스트를 통화하지 못하면 그 외의 테스트는 수행할 가치가 없다고 판단하면 된다.
그래서 스모그 테스트는 모든 테스트를 수행하기 전에 선행되어 하는 테스트이다.


  • 몽키 테스트(Monkey Test)
원숭이가 터치스크린을 무작위로 터치하는 것을 비유한 테스트이다.
주로 UI 컴포넌트(Component)에 무작위로 클릭 이벤트(Click Event)를 전송하여 시스템에 오류가 발생하는지 확인하는 테스트이다.
그렇기 때문에 테스트 수행은 일정시간 테스트를 수행하고, 그 동안 시스템에 오류 발생했는지 여부로 통과(Pass)와 실패(Fail) 을 판단한다.


  • 사용성 테스트(Usability Test)
사용성 테스트는 UX(User Experience) 관점에서 테스트를 수행한다.
다시 말해서 기능적인 부분을 확인하는 것이 아니고 사용자가 불편하게 느낄 수 있는 부분들을 찾아내는 테스트이다.
그렇기 때문에 테스트 자동화가 거의 불가능한 부분이고, 전문 UX 엔지니어가 테스트를 수행해야 한다.


  • 스트레스 테스트(Stress Test)
소프트웨어의 한계치를 확인하는 테스트이다.
스트레스 테스트는 요구사항을 만족시키는 목적보다는 제품의 사양(Specification)을 확인하기 위한 테스트라고 할 수 있다.
예를들면 소프트웨어에 동시접속자의 숫자를 늘려가면서 웹 페이지(Web Page)의 반응속도를 테스트하고 기록한다.
이렇게 기록된 웹 페이지 반응속도는 소프트웨어나 하드웨어의 성능을 개선하는 기준자료가 될 수 있다.
따라서 스트레스 테스트는 비 정기적인 이벤트(Event)성으로 수행되는 경우가 많다.


  • 인터페이스 테스트(Interface Test)
각 모듈(Module)간에 데이터가 정상적으로 오고 가는지를 테스트 한다.
개별적으로 개발된 모듈을 통합하여 연결했을 때 발생하는 오류를 확인하는 테스트이다.


  • 회귀 테스트(Regression Test)
이미 해결된 이슈가 또 다시 발생하는지 확인하는 테스트이다.
한번 발생한 오류는 다시 또 발생될 확률이 높다는 아이디어에서 발생한 테스트이다.
그래서 기능 테스트중 가장 큰 범위에 걸쳐 있는 테스트이다.
어떤 버그(Bug)가 발생하고 해결되면 동일한 버그(Bug)가 발생하는지 확인할 수 있는 테스트 항목이 있어야 한다.
그래서 만약 이미 존재하는 테스트이면 회귀 테스트(Regression) 라벨(Label)을 달아놓고, 그렇지 않다면 테스트 항목을 새로 추가하고 라벨(Label)을 달아 놓아야한다.
이렇게 라벨(Label)을 달아 놓고 주기적으로 회기 테스트를 수행해야 한다.


  • 메모리 누수 테스트(Memory Leak Test)
소프트웨어에 메모리 누수 현상이 발생하는지 확인하는 테스트이다.
장시간 소프트웨어를 방치하거나 또는 UI, Scenario, Monkey 테스트와 조합하여 메모리 누수를 확인한다.메모리 누수 현상이 발생하면 소프트웨어에 치명적인 문제를 일으킬 수 있기 때문에 이런 테스트를 통해 미리 탐지하는 것이다.


  • 포지티브 테스트(Positive Test)
정상적인 값을 대입하여 정상적인 결과가 나오는지 확인하는 테스트이다.
단위 테스트에서 테스트 대상 Function 에 정상적인 값들만 대입하여 확인하는 테스트이다.
포지티브 테스트에서 실패(Fail)가 나온다면 그 Function 은 구현이 이루어지지 않았다고 볼 수 있다.


  • 네가티브 테스트(Negative Test)
비정상적인 값을 대입하여 에러처리가 제대로 이루어지는지 확인하는 테스트이다.
단위 테스트에서 테스트 대상 Function 에 비정상적인 값들만 대입하여 확인하는 테스트이다.
네가티브 테스트에서 실패(Fail)가 나온다면 그 Function 은 에러처리가 더 필요한 것이다.


  • 경계값 테스트(Boundary Test)
경계값, 경계값 보다 작은값, 경계값 보다 큰값을 사용하여 테스트한다.
단위 테스트에서 테스트 대상 Function 에 경계값 근처의 값들을 대입하여 Function 이 제대로 대응을 하는지 확인하는 테스트이다.
경계값 근처에서 버그가 발생할 확률이 높다는 아이디어에서 만들어진 테스트이다.


소프트웨어 테스트를 나름대로 정리해보았다.
각각의 테스트에 대해서 그 동안의 경험을 토대로 분류한 것이다.
그래서 다소 자의적으로 해석한 부분이 있을 수 있다.

예를 들면 나는 안정성 테스트(Stability Test)를 인수 테스트(Acceptance Test)의 비기능 테스트(Non-functional)로 분류하였다.
그런데 몽키 테스트(Monkey Test)와 스트레스 테스트(Stress Test)도 안정성 테스트(Acceptance Test)의 한 종류로 해석한다면 안정성 테스트의 범위가 달라질 것이다.

이렇듯 해석하기에 따라서는 다르게 분류될 수도 있는 것이기 때문에 위의 분류는 내 개인적인 생각임을 밝혀둔다.

2017년 5월 22일 월요일

SW 테스트를 정의해보자!

소프트웨어 테스트(이하 테스트라 칭함)가 무엇인지 함께 생각해보자!

위키피디아(www.wikipedia.org)에서는 테스트를 어떻게 정의하고 있는지 알아보자!
소프트웨어 테스트는 주요 이해관계자들에게 시험 대상 제품 또는 서비스의 품질에 관한 정보를 제공하는 조사 과정이다. 소프트웨어 테스트는 또한 소프트웨어에 대한 객관적이고 독립적인 시각을 제공하여 사업주체가 소프트웨어 구현의 위험성을 올바로 이해하도록 한다. 시험 기술에는 프로그램이나 응용 프로그램을 실행하여 소프트웨어 버그를 찾는 절차가 포함되나 이에 국한되지는 않는다.
위키피디아에서는 소프트웨어 테스트를 "서비스 품질에 관한 정보를 제공하는 조사과정" 이라고 정의하고 있다.
그 외에도 테스트는 "사업주체가 소프트웨어 구현의 위험성을 올바로 이해하도록 한다." 라고 테스트의 가치를 말해주고 있다.
끝으로 "소프트웨어 버그를 찾는 절차가 포함되나 이에 국한되지는 않는다." 라고 테스트의 범위를 정의하고 있다.


테스트에 대한 위키피디아의 정의가 틀린 것은 아니지만 너무 포괄적인 면이 있다.
그래서 나는 다음과 같이 정의하고 싶다.

"소프트웨어 테스트는 리스크(risk)를 이슈(issue)로 만드는 과정이다."

여기서 리스크는 잠재적인 위험이고, 이슈는 발생한 위험이다.
둘 다 모두 위험이지만 하나는 아직 발생하지 않은 것이고, 다른 하나는 발생한 것이다.
리스크는 영원히 발생하지 않을 수도 있다는 것이 이슈와 다른 점이다.




테스트를 위와 같이 정의하면 테스트가 어떻게  수행되어야 하는지도 쉽게 정의할 수 있다.

"소프트웨어를 테스트한다는 것은 리스크(risk)를 파악하고, 파악된 리스크(risk)가 이슈(issue)인지 아닌지 확인하는 활동이다."

즉 테스트 활동을 도식화 하면 아래와 같다.


2017년 5월 21일 일요일

블로그를 시작하며...

난 프로그래머로 20년 가까이 생활해 왔다.
20년 동안 인터넷은 내 직장생활에서 가장 많은 도움을 준 도구이다.
이런 인터넷에게 조금이나마 감사함을 표현하고자 이 글을 쓰게 되었다.

처음 프로그래머의 꿈을 꾸고 공부를 하던 시절에는 책을 통해 모든 지식을 얻을 수 있었다.

하지만 지금은 책보다 인터넷 통해 더 많은 지식을 습득하고 있다.
특히 블로그와 질의응답 게시물은 업무를 수행하는데 없어서는 안되는 도구가 되었다.
프로그래머의 실력은 인터넷 검색 실력이라고 할 정도다.

이렇듯 난 인터넷을 통해 불특정 다수로 부터 많을 도움을 받고 있었다.
잘 정리된 블로그의 글이나 성의 있는 답변들을 볼 때면 큰 고마움을 느꼈었다.
이에 나도 항상 도움만 받지 말고 내가 받은 만큼 돌려주어야겠다는 생각이 들어서 이 블로그를 시작하려 한다.

비록 내 글이 어떤 내용의 어떤 값어치를 가질 지는 알 수 없다.
하지만 조금이라도 누군가에게 도움을 줄 수 있다면 그것으로 행복할 것이다.



그래서 이왕에 글을 쓴다면 다음의 원칙에 따라 글을 써보려한다.


1) 글을 쉽게 쓰자!
   문장은 단문 위주로 작성한다.
   표나 목록을 사용하여 핵심 내용을 쉽게 파악할 수 있도록 한다.
   강조가 필요한 부분은 Bold 나 글자색을 입힌다.
   글은 정보전달이 우선이므로 존대말을 생략한다.

2) 그림과 샘플 코드를 적극 활용하자!
   그림으로 표현이 가능한 것은 글보다는 그림을 우선 사용한다.
   프로그램 관련된 것은 Sample 을 적극 활용한다.

3) 영어 번역본을 만들자!
   특별한 이유가 없는 한 블로그 글은 모두 영어 번역본을 만든다.
   번역은 구글 번역기를 사용한다.


나는 위의 원칙을 항상 생각하며 블로그를 작성하겠다.