It's Myself

Google Apps Engine을 보다가, 우연히 Google Apps를 보게 되었습니다. 바로 전 직장이 MS 쪽 계열이 아닌 IBM 쪽이었는데, 협업도구가 생각보다 매력적인 것이 없었습니다. 물론 IBM Notes 란 것이 있지만, 간단히 깔아 단순하게 막 쓸 수 있는 솔루션은 아니었죠. 무언가 전문가의 손이 거쳐 지나가야 물건이 되는 그런 것이었습니다.

그래서 팀 내에서 협업 도구로 쓸 만한 무언가가 필요했고, 마침 이 제품을 보게 되었습니다.
당시에는 유료 버전이 없었는데, 최근 간만에 접속해보니, 유료버전도 생겼더군요.
메일 크기 25G 이상, 막강한 협업 관련 기능이 필요하면, 유료버전을 써도 되지만,
작은 규모의 팀이나, 회사 내에서 별도의 투자 없이 사용할 만한 솔루션인 것 같습니다.
(물론 데이터가 Google Server에 저장되는 게 쪼큼 두렵지만, 보안 비로 회사의 매출 10~20% 소비하는 레벨이 아니라면, 뭐 그냥 써도 무방할 겁니다.

단, 이 작업을 수행하려면, 도메인이 필요합니다.
공인 도메인이 있어야 합니다. 그 이유가 서브 도메인 생성 가능 여부 때문인데, 예를 들면 knoie.net 이라는 도메인이 있으면 mail.knoie.net 같은 서브 도메인을 만들 수 있죠. 그 외에도 메일을 위한 "MX" 레코드 설정도 해야 되는데, 무료 도메인 같은 경우에는 대부분 사용이 불가능합니다.

그러므로 가급적 유료도메인을 확보하세요! ( 싸구려 pe.kr 같은 것도 상관 없습니다. )

단, 실제 사용할 때 도메인을 구매해서 연결을 해도, google에서 정한 google 도메인이 주소 줄에 나옵니다.

뭐 주소줄에 도메인 이름이 어떻게 표시되든 관계 없어야 합니다. 막상 설치하고 난 뒤, URL이 이상 야리꾸리하다는 걸 눈치 챘을 때는 이미 늦은 겁니다. - 도메인을 이미 샀고, 계정은 이미 만들고..

도메인은 준비되었고, 주소창에 URL이 어떻게 표시되어도 상관 없다는게 확실하면,
슬슬 시작을 해보도록 하겠습니다.
여기서는 설명을 편하게 하기 위해 knoie.net 이라는 도메인을 가지고 구축하겠습니다.

최초 계정 만들기

지금부터 할 작업은 자신의 도메인을 Google Apps에 등록하고, 관리자 계정을 만드는데 있습니다.
웹의 설명을 조심스럽게 따르기만 하면 어렵지 않게 생성할 수 있습니다.

1. 제일 먼저 Google Apps 사이트 접속 합니다.
   http://www.google.com/apps/intl/ko/business/index.html
   
2. 예전에는 바로 "시작하기" 같은 버튼이 있었는데, 이번에는 그리 쉽게 찾을 수는 없습니다.
   대신 왼편에 위치한 표준형이라는 부분을 클릭하시면 나옵니다.
   
   
3. 다음 페이지로 전환 되면 "시작하기" 버튼이 보입니다. 그 시작하기 버튼을 클릭하세요.
   
   
4. 이제 시작하기 화면에 들어가면 정보를 입력하는 창이 뜹니다.
   먼저 도메인 소유 여부 선택 부분과 도메인 이름을 넣는 부분이 나옵니다.
   도메인 권한 관련 묻는 항목에서는 “관리자: 이 도메인을 소유 또는 관리합니다”를 선택하세요.
   (그래야 나중에 작업하기가 수월합니다. 사실 구매한 도메인이면 당연히 첫 번째를 고르겠죠.)
   그리고 도메인이름에 구입한 도메인이름을 넣어주시기 바랍니다. 서브 도메인(www.knoie.net 같은)으로 넣지 마시고 대표 이름(knoie.net 같은)으로 넣어주시기 바랍니다.
   (이 도메인 이름으로 mail을 구성하게 됩니다. 지금 예제에서는 knoie.net 이니까, 나중에 admin@knoie.net 같은 이메일 계정으로 로그인도 하고, 메일을 사용하게 됩니다.)
   
   
5. 입력 후 "시작" 버튼을 눌렀다면 이제 이 Google Apps 사이트의 기본 정보를 입력하게 됩니다.
   사이트 관리자에 대한 정보를 넣습니다. 그리고 연락을 위한 간단한 연락처 2가지를 입력받죠.
   그리고 지역적 위치 정보도 받게 됩니다. 중간에 체크 박스가 있는데, 일종의 확인을 위한 체크 박스인데,
   이 Google Apps를 사용하기 위해서는 DNS(도메인 서버)의 정보를 일부 변경해야 된다는 것입니다.
   즉 이 정보를 손댈 수 없다면 이 Google Apps 사이트를 만들 수 없다는 의미입니다. ( 이 부분은 앞 부분에서 언급 드렸죠?)
   그 외에 회사(혹은 팀) 이름 및 규모를 묻습니다. 그 외에 이 Google Apps를 사용하게 된 출발점에 대한 영업 정보를 넣게 되어 있는데, 대충 넣으시면 됩니다.
   다 입력 하셨으면 "계속"을 클릭하세요.
   
   
6. 이제 이 Google Apps 사이트의 관리자이자 최초 계정을 생성을 합니다.
   일반적인 계정 생성 폼과 유사합니다. 자질구레한 부분은 없고, 단지 생성할 아이디와 암호 정도를 넣습니다.
   또, 외부 봇을 이용한 멋대로의 생성을 막기 위한 부분을 통과하시구요.(개인적으로는 이게 제일 힘들더군요 -_-;;;;) 다 입력하신 뒤, "동의 합니다. 설정 계속하기 >>" 버튼을 클릭하세요.
   
   
7. 이제 화면에는 관리도구가 뜹니다. 이러면 최소한 여러분의 도메인으로 Google Apps내 사이트 구축이 완료된 것입니다. 아직은 동작하지는 않지만, 최소한 입력한 도메인에 대한 독립적인 공간이 구성된 것이죠!
   갈 길은 더 있지만, 어찌되었던 축하합니다!
   

도메인 연결하기.

지금까지의 작업은 사이트를 Google Apps 내에 생성하는 일이였다면, 지금 부터 할 작업은 진짜 여러분의 도메인이 실제로 권한이 있는지 없는지를 체크하는 것입니다. 체크 후에 진짜로 Google Apps와 연결하는 것이죠.
여기서는 설정 부분을 전반적으로 다룹니다.
하지만, 도메인 내 정보를 Google Apps를 바라보게 설정을 해도, 미국 내 에있는(정말 있는지는 모르겠습니다. -_-;; ) Google Apps 서버에서 변경된 정보를 수신 하는데 걸리는 시간이 좀 많이 걸립니다. 이 작업의 완료는 설정 후 빠르면 거의 1~2분 내로 적용 되지만, 늦으면 2~3일 정도 걸립니다. 이건 전 세계로 뻗어 연결된 DNS 서버간의 설정 때문이기 때문에, 설정 후 왜 바로 적용이 안되냐고 반문은 자제해주시고 그냥 될 때까지 기다려 주세요.

일단 제일 먼저 해야 하는 것은 Google Apps에게 현재 설정한 도메인이 진짜 자신의 것임을 증명하는 일을 해야 합니다. 있지도 않은 도메인으로 멋대로 Google Apps를 만들어 연결하는 짓을 막기 위한 일종의 장치입니다. Google Apps가 자신의 도메인을 도메인으로 인정할 수 있도록 하는 것입니다.
이제 도메인 연결 관련된 전반적인 작업을 시작하겠습니다.

1. 맨 처음 관리자 창이 뜬 상태 위 쪽에 보면 "도메인 소유권을 확인하십시오" 라는 링크를 볼 수 있습니다. 이 링크에 먼저 들어가시기 바랍니다. ( 이 링크와 설명 부분은 인증을 정상적으로 받으면 사라집니다.)
   
   
2. "도메인 소유권을 확인하십시오"의 링크로 들어가면 아래와 같은 그림같은 페이지가 뜹니다. 여기서 도메인 소유권을 확인 방법을 고릅니다.
   
   여기서 도메인 소유권 확인 방법이 두 가지 가 있습니다. 하나는 그 도메인을 위한 웹 서버가 이미 있고 구입한 도메인이 연결되어 있는 경우입니다. (즉 이미 홈페이지를 확보하고 계신 경우 ). 다른 하나는 완전히 도메인만 있고, 그 안의 설정만 할 수 있는 경우 입니다.
   전자의 경우에는 "HTML 파일 업로드" 라는 방법을 사용하시면 되고, 후자의 경우라면 "CNAME 레코드 변경" 이라는 방법을 사용하시면 됩니다. 각 방법 별로 나누어 설명을 드리겠습니다.
   해당 방법을 선택하는 화면은 아래와 같습니다.
   
   1. HTML 파일 업로드 방법
      1. 먼저 자신의 도메인으로 웹 서버가 정상적으로 연결되어 있는지 확인합니다.
         구입한 도메인에 www 나 w3 나 이런 앞부분의 서브도메인을 없애고, 그냥 도메인이름으로만
         웹 페이지에 접근이 가능한지 보세요( 여기 예제가 knoie.net 인데, http://www.knoie.net 같은 게 아니라, http://knoie.net  으로 접근이 되어야 합니다. )
      2. 확인이 되었으면 "귀하의 도메인 소유권을 확인하십시오" 라는 항목 에 있는 선택 상자에서 "HTML 파일 업로드"를 선택하세요.
      3. 선택하면 아래 그림처럼 적용하는 방법이 나옵니다. 일단 googlehostedservice.html 이라는 파일을 만들고 그 안에 문자열을 복사해주세요. googleXXXXXXXXXXXX 형태의 문자인데, 자신의 도메인 인증 번호에 따라 나오는 값입니다.
         
      4. 그리고 난뒤에 만들어진 html 파일을 해당 웹 서버의 Root 폴더에 업로드 해주세요.
         (업로드는 각 웹 호스팅 혹은 웹 서버 설정에 따라 맞게 하시면 됩니다.)
      5. 2번 항목에 있는 url 처럼 http://knoie.net/googlehostedservice.html 해서 브라우저 상에 자신이 입력한 문자열이 정상적으로 나오면 확인 버튼을 클릭하세요.
         
         
   2. CNAME 레코드 변경.
      1. 이 방법은 위의 웹 서버 방식이 불가능한 경우 사용합니다. 대표적으로 웹 호스팅 같은 서비스가 없고 도메인만 있는 경우입니다. 이 때, 반드시 해당 도메인의 DNS 설정을 할 수 있어야 합니다. 대개 도메인 구입한 곳에서 무료로 DNS 서비스를 합니다. 여기서는 제 도메인인 knoie.net로 전체적인 소개를 하며, 그 도메인을 구입할 때 이용한 whois.co.kr 을 통해 설정하는 방법까지 제시하겠습니다.
      2. 먼저 옵션 창에서 "CNAME 레코드 변경을 선택하면 아래의 그림과 같이 표시 됩니다.
         항목 중 2번 항목에 있는 고유의 문자열을 적당한 위치에 복사해주세요.
         googleXXXXXXXXXX 형식의 이름입니다.
         
      3. DNS 서비스를 변경할 차례입니다. DNS 설정 부분은 각 DNS 서비스 마다 다릅니다. 자체적으로 DNS를 구축하여 하시고 있다면 CNAME 레코드를 위의 이름으로 만들면 됩니다.
         만일 저처럼 별도 DNS 서비스를 구축한게 아니라면, 자신의 도메인을 구입한 곳에서 제공하는 DNS 서비스를 이용하여 변경하면 됩니다. 앞서 설명 드렸듯이 여기서는 제가 이용하는 whois.co.kr 이라는 곳을 기준으로 설명 드립니다.
      4. 먼저 whois.co.kr 에 접속한 뒤, 로그인을 합니다. 그리고 도메인 관리에 들어가도록 합니다.
         
      5. 도메인 관리 화면에서 이번엔 메뉴 중에 "도메인 활용 / 부가서비스" 안에 있는 "네임서버 고급설정"에 들어갑니다.
         
      6. 그러면 도메인 이름을 입력하는 창이 있는데, 자신의 도메인 이름을 넣으시면 됩니다.(선택상자가 아니고 직접 입력합니다.) 여기서는 knoie.net 을 사용하니까, knoie.net을 넣습니다. 그리고 그 옆에 있는 선택 상자 중 "#CNAME 레코드 관리"를 선택합니다. 선택을 했으면 "확인 >" 버튼을 클릭합니다.
         
      7. 이제 앞서 메모했던 CNAME 이름을 호스트 이름에 설정하고, 그에 연결되는 값을 "google.com" 이라고 넣습니다. 완료 되었으면 다음 단계로 넘어갑니다.
         
      8. 그러면 최종적으로 그 추가/변경된 정보들이 요약되서 나오고 확인 후 신청하기 버튼을 클릭합니다.
         
      9. 완료되었으면  앞서 열었던 도메인 확인 페이지에 다시 들어가서 "확인" 버튼을 클릭하세요.
         
         
   3. 웹 방법이든, CNAME 방법이든, googleapps를 관리하는 서버에서 해당 도메인에 정상적으로 접근하는 순간 각 방법대로 체크를 하게 됩니다.
   4. 첫 화면으로 돌아가면 아래의 그림과 같은 표시를 보실 수 있습니다.
      

메일 서비스 연결하기.

위 단계 까지 왔다면 중요한 설정은 다 끝난 것입니다. 도메인 소유권 확인까지 끝나면 사실상 중요한 설정 대부분은 끝난 것입니다. 이제, 이 Google Apps 의 핵심 서비스인 메일 서비스가 남았습니다.
여기서는 메일을 위한 MX ( Mail Exchange ) 설정과 메일 서버와의 연결 작업만 수행하면 됩니다.
단 이 작업은 도메인 소유권 확인이 정상적으로 완료되시면 수행하시기 바랍니다.

1. 기본적으로는 메일 서비스를 사용하기로 되어 있지만, 만일 되어 있지 않다면 서비스를 활성화 시킵니다.
   활성화 하는 방법은 Google Apps 도메인 관리에 있는 대쉬보드에 들어가시면 중앙 정도에 "서비스 추가하기" 링크가 있습니다. 그것을 클릭하시기 바랍니다.
   
2. 현재 비활성화 된 서비스들이 나열되어 있는데 그 중, 이메일에 위치한 "바로 추가" 버튼을 클릭하시기 바랍니다. 그러면 자동적으로 닫히면서 도메인 관리도구로 이동하게 됩니다.
   
3. 다음은 메일을 활성화 하는 작업을 해야 합니다. 이 때 메일을 접근하기 위한 도메인 이름을 만듭니다.
   즉 메일 서버에 접근하기 위한 전체 도메인 이름을 의미합니다.
   여기서는 mail.knoie.net 이라는 이름으로 만들도록 하겠습니다.
4. 다시 도메인 관리도구의 대시보드에 갑니다. 그리고 이메일 항목으로 이동하여 링크를 클릭합니다.
   
5. 이메일 설정 화면으로 이동되면, 웹 주소라는 항목을 보실 수 있습니다.
   그 곳에서 URL 변경을 클릭합니다.
   
6. 그러면 이 메일 서비스에 바로 접속할 때 사용될 URL을 구성할 수 있습니다.
   기본적으로는 http://mail.google.com/a/도메인이름 으로 접근이 되지만, 그래도 자신의 도메인으로 알기 쉽게 만드는게 좋습니다. webmail 이나, mail, mailsvr 등등 쉽게 알 수 있는 이름으로 정해주시면 됩니다.
   여기서는 mail.knoie.net으로 설정하도록 하겠습니다. - 아래 항목을 선택 후 mail 이라는 이름을 넣습니다.
   구성이 되었으면 계속>> 버튼을 클릭합니다.
   
7. 메일 접속을 위한 CNAME 설정 방법을 설명하는 화면이 나옵니다.
   앞서 도메인 확인을 위해 CNAME을 설정했는데, 마찬가지로 자신이 결정한 이름에 대한 CNAME으로 ghs.google.com을 설정합니다. CNAME의 설정을 위한 네임서버 설정은 각기 자신의 네임서버 설정에 따라 진행하시면 됩니다. 네임 서버 상의 설정도 끝났으면 다음 단계를 완료했습니다.를 클릭하시기 바랍니다.
   ( whois.co.kr 인 경우, 앞서 도메인 확인을 위하여 CNAME 설정한 부분을 확인하시기 바랍니다. )
   
   
8. 이제 남은 것은 MX(Mail Exchanger) 설정이 있습니다. 이 작업은 네임 서버의 설정 작업입니다.
   앞서 네임 설정을 했던 것 처럼 네임 서버의 서비스를 접근해야 합니다. 마찬가지로 여기서는 knoie.net에 대한 도메인 서비스를 수행하는 whois.co.kr을 가지고 작업을 하도록 하겠습니다.
   기본적인 로그인 및 서비스 접근 부분은 건너 뛰도록 하겠습니다.
9. 네임 서버 고급 설정에 들어가, 자신의 도메인 이름을 넣고, "#MX 레코드 관리"를 선택합니다. 그리고 확인 버튼을 클릭합니다.
   
10. MX 레코드 값을 입력하는 창을 5개 정도 만듦니다. 그리고 각 MX 값을 아래에 제공하는 표 내용대로 채워주시기 바랍니다. MX 값은 한 개만 있어도 되지만, 원할한 메일 송수인을 위해 gmail에서 제공하는 모든 MX를 설정하는 것이 좋습니다. 이 MX 정보는 http://www.google.com/support/a/bin/answer.py?answer=48242 에 기록되어 있습니다.
    

    우선순위	메일 서버
    1	ASPMX.L.GOOGLE.COM.
    5	ALT1.ASPMX.L.GOOGLE.COM.
    5	ALT2.ASPMX.L.GOOGLE.COM.
    10	ASPMX2.GOOGLEMAIL.COM.
    10	ASPMX3.GOOGLEMAIL.COM.

    채우면 아래의 그림처럼 나열될 것입니다.
    
11. 설정이 완료된 뒤, Outlook 이나, Apple mail 이나, 기타 메일 클라이언트 연결은 Gmail 연결방법과 동일합니다. pop.gmail.com 으로 POP3로 연결할 수 있으며, smtp.gmail.com 으로 메일을 발송할 수 있습니다. 이 설정들은 gmail의 도움말을 참고하시기 바랍니다.
    http://www.google.com/support/a/bin/topic.py?hl=kr&topic=9202

총 3단계를 걸쳐 Google Apps에 대한 구성방법을 소개해 드렸습니다.
실제로 기존에 Google에서 Google 계정만 등록하면 사용할 수 있는 각종 도구들을 한데로 묶어 제공합니다. 기존에 Google에서 제공하는 서비스를 사용한 경험이 있다면 큰 문제없이 활용하실 수 있습니다.
단지, 자신의 도메인을 연결할 수 있다는 점 때문에, 이렇게 긴 글을 쓴 것이구요.

조직 내에서 보다 본격적인 활용을 하신다면 유료로 도전해보는 것도 나쁘지는 않습니다. 메일 저장 사이즈나, 기타 추가적인 기능들을 확장하실 수 있으니까요. 하지만, 무료 버전으로 제공하는 표준형도 상당히 괜찮은 솔루션입니다. 현재 제가 다니는 회사도 이 Google Apps에 연결해서 사용하며, 몇몇 부족한 부분만을 제외하면 만족스럽게 사용하고 있습니다. 모바일로도 지원되기 때문에, 의외의 사용성이 증대되었다고나 할까요?

독자적인 도메인을 갖고 있는 작은 규모의 회사 혹은 팀이 있다면 이런 Google Apps의 활용이 어떨까 조심스럽게 짐작해 봅니다.

이 모든 자료는 apple.com과 AppsNext.com에 그 권한이 있습니다.

(한글) 앱스토어 리뷰가이드 라인

제공: iPhone 개발의 모든 것- AppsNext.com   

우리는 당신이 iOS를 위한 어플리케이션을 개발하려고 하는 것을 매우 기쁘게 생각합니다. iOS 앱 개발은 직업적, 금전적으로 수많은 개발자들에게 도움을 주고 있는 작업이며, 우리는 당신이 이 성공적인 개발자들의 대열에 합류하길 기원합니다. 우리가 앱스토어 리뷰 가이드라인을 작성한 것은 이번이 처음입니다. 우리는 이 리뷰가 당신이 앱을 개발하는데 발생할 수 있는 문제에 대해 명확한 지침을 제공해줄 수 있을거라고 기대하며, 그로 인해 앱 승인 절차를 빠르게 할 수 있을거라고 생각합니다.

우리는 앱을 책이나 노래 따위의 우리가 취급하지 않는 것들과는 다르게 보고 있습니다. 만약 당신이 종교를 비판하고 싶다면 책을 쓰십시오. 만약 당신이 섹스에 대해 묘사하고 싶다면 책을 쓰거나 노래를 만들거나, 혹은 의학적 서류를 만드십시오. 구분하기 다소 복잡할 수 있습니다만, 우리는 그런 류의 컨텐츠들을 앱스토어에 등록하지 못하도록 결정하였습니다. 하기의 지침들을 인지하는 것이 당신들의 앱 개발에 도움이 될 것입니다.
많은 아이들이 앱들을 다운받고 있으며, 부모들이 별도로 아이들을 위한 컨트롤 장치를 세팅하지 않는 한 아이들의 앱 다운로드를 제어할 수 있는 방법은 없습니다. (많은 부모들이 보통 그 장치를 세팅하지 않습니다.) 우리가 아이들에게 나쁜 영향을 주지 않도록 항상 주의하고 있음을 주지하십시오.
앱스토어에는 250,000개가 넘는 앱들이 있습니다. 더 이상의 의미없는 앱들은 필요없습니다. 당신이 만든 앱이 실용적 으로 쓸모있거나 혹은 지속적인 즐거움을 제공할 수 없다면 우리는 그 앱을 승인하지 않을 수 있습니다.
만약 당신이 만든 앱이 고작 며칠 사이에 조잡하게 만들어졌다고 보이거나, 당신의 친구들에게 보여주기 위해 연습용 으로 만든 앱을 스토어에 올릴 경우 해당 앱들은 승인 받지 못할 것입니다. 많은 전문 앱 개발자들은 자신들의 양질의 개발물이 아마추어들이 유희로 만든 것들과 같이 앱스토어에 전시되는 것을 원하지 않습니다.
우리가 판단하기에 선을 넘었다고 보이는 컨텐츠나 행동을 다룬 앱은 승인을 거부당할 수 있습니다. 당신이 그 기준이 무엇이냐고 묻는다면, “보면 알것입니다.” 라고 대답하겠습니다. 우리는 당신들 역시 그 기준을 충분히 인식할 수 있을 거라고 생각합니다.
만약 당신의 앱이 승인을 거부당했을 경우, 당신은 우리가 제공하는 Review Board를 통해서 이를 어필할 수 있습니다. 당신이 이런 프로세스를 따르지 않고 언론사에 우리를 비난한다고해서 그 문제를 해결하지는 못할 것입니다.
이 가이드라인은 지속적으로 업데이트될 수 있습니다. 만약 새로이 개발된 앱이 새로운 문제점을 야기할 경우 우리는 새 룰을 언제든 추가할 수 있습니다.어쩌면 당신이 만든 앱이 그것을 불러올지도 모릅니다.

마지막으로, 우리는 당신이 개발하는 앱을 매우 좋아하며 당신이 하는 일들에 존경심을 가지고 있습니다. 우리는 앱 개발에 있어서 당신의 능력을 최대한 발휘할 수 있는 최고의 플랫폼을 구축할 수 있도록 노력하고 있습니다. 어쩌면 당신이 보기에 우리의 통제가 지나치다고 생각할지도 모르지만, 만약 그렇다면 그건 우리가 고객의 입장에서 생각하고 그들이 우리의 제품을 통해 양질의 경험을 할 수 있도록 신경쓰기 때문 일 겁니다. 그런 생각은 당신들 대부분도 아마 마찬가지일겁니다.

목차

1. 약관
2. 기능성
3. 메타데이터, 등급, 순위
4. 지역
5. 알림서비스 (푸쉬 노티피케이션)
6. 게임센터
7. 전자광고
8. 상표, 상품외장
9. 미디어 컨텐츠
10. 유저 인터페이스
11. 구입, 통화
12. 긁어오기, 종합
13. 기기에 손상
14. 개인적인 공격
15. 폭력성
16. 거부감을 주는 컨텐츠
17. 사생활
18. 포르노그래피
19. 종교, 문화, 인종
20. 컨테스트, 경품, 복권, 추첨
21. 자선, 기부
22. 법적 요구사항

1. 약관

1.1     앱스토어의 어플리케이션을 개발하는 개발자로서 당신은 Program License Agreement (PLA), Human Interface Guidelines (HIG), 그 외에 다른 애플과 맺은 라이센스 혹은 계약들에 종속된다. 하기의 룰과 예시는 당신이 만드는  앱이 승인을 받는데 도움을 주기 위한 것이지 다른 협의문을 수정하거나 그에 종속된 조항을 무효화하기 위함이 아니다.

2. 기능성

2.1     (시스템을) 고장내는 앱은 승인하지 않는다.
2.2     버그가 발견되는 앱은 승인하지 않는다.
2.3     개발자가 명시한대로 작동하지 않는 앱은 승인하지 않는다.
2.4     문서 상의 설명과는 일치하지 않는 숨겨진 요소 혹은 불법적 요소를 포함한 앱은 승인하지 않는다.
2.5     공개되지 않은 API(어플리케이션 프로그래밍 인터페이스)를 사용한 앱은 승인하지 않는다.
2.6     할당된 공간 외의 곳에서 데이터를 읽거나 쓰는 앱은 승인하지 않는다.
2.7     어떤 방식이나 형태로든 코드를 다운받는 앱은 승인하지 않는다.
2.8     다른 실행 가능한 코드를 인스톨 혹은 실행시키는 앱은 승인하지 않는다.
2.9     “베타”, “데모”, “체험판” 혹은 “테스트” 버전인 앱들은 승인하지 않는다.
2.10   아이폰 앱은 별도의 조정없이 아이패드에서도 사용할 수 있어야한다. 해상도는 아이폰과 동일, 아이폰3GS의 2배 이다.
2.11   앱스토어에 이미 있는, 그중에서도 특히 유사한 종류 여럿이 존재하는 앱을 복제한 앱은 승인하지 않는다.
2.12   실용적으로 유용하지 않거나 지속적인 오락적 가치를 제공하지 못하는 앱은 승인하지 않는다.
2.13   마케팅이나 광고가 주목적으로 제작된 앱은 승인하지 않는다.
2.14   명확하게 명시되지 않은 속임 혹은 가짜 기능을 제공하기 위해 만들어진 앱은 승인하지 않는다.
2.15   20메가가 넘는 크기의 앱은 무선 네트워크를 통해서 다운로드할 수 없다. (앱스토어에서 자동적으로 이를 방지함)
2.16   멀티태스킹 앱은 백그라운드 서비스를 그것들의 기본적인 목적에 맞게 사용해야한다.
          (예: 인터넷전화, 오디오 플레이백, 지역, 과제수행, 지역 공지 등)
2.17   웹브라우징하는 앱은 IOS WebKit framework와 WebKit Javascript를 반드시 사용해야한다.
2.18   알코올 혹은 법적으로 금지된 물질의 과도한 소비를 조장하거나, 미성년자의 음주 및 흡연을 조장하는 앱은 승인 하지 않는다.
2.19   잘못된 진단결과 혹은 기타 부정확한 기기 정보를 제공하는 앱은 승인하지 않는다.
2.20   앱스토어에 유사한 앱의 여러가지 버전을 올려서 “스팸질”을 하는 개발자는 iOS 개발자 프로그램에서 퇴출한다.

3. 메타데이터 (이름, 설명, 등급, 순위 등)

3.1     다른 모바일 플랫폼의 이름을 명시한 메타데이터를 포함한 앱은 승인하지 않는다.
3.2     플레이스홀더 텍스트를 포함한 앱은 승인하지 않는다.
3.3     앱 설명에서 앱 컨텐츠, 기능과 상관없는 기술을 한 앱은 승인하지 않는다.
3.4     아이튠스 커넥트 상에 표시되는 앱의 이름과 기기 상에 표시되는 앱의 이름은 서로 비슷해야한다.
          이는 혼란을 피하기 위한 목적이다.
3.5     앱의 큰 아이콘과 작은 아이콘은 혼란을 피하기 위해 서로 비슷해야한다.
3.6     4세 이상 등급을 지키지 않은 앱 아이콘과 스크린샷을 포함한 앱은 승인하지 않는다.
3.7     앱 컨텐츠에 맞지 않는 카테고리, 장르를 표기한 앱은 승인하지 않는다.
3.8     개발자는 자신의 앱에 적합한 등급을 매길 책임이 있다. 부적합한 등급은 애플이 수정할 수 있다.
3.9     개발자는 자신의 앱에 적합한 키워드를 부여할 책임이 있다. 부적합한 키워드는 애플이 수정하거나 삭제할 수
          있다.
3.10   거짓 리뷰, 돈을 주고 작성한 리뷰, 혹은 기타 부적합한 방법으로 유저 리뷰 혹은 앱스토어 상의 차트 순위를 조작 하거나 부풀리려는 시도를 한 개발자는 iOS 개발자 프로그램에서 퇴출한다.

4. 지역

4.1     지역 데이터를 수집, 전송, 혹은 사용하기 전에 해당사항에 관해 사용자의 합의를 공지하지 않거나 득하지 않은 앱은 승인하지 않는다.
4.2     지역 데이터에 근거한 API를 통해 자동차, 비행기 혹은 기타 기기들의 자동, 자주적인 조작을 하고자 하는 앱은 승인하지 않는다.
4.3     지역 데이터에 근거한 API를 통해 발송, 차량관리, 혹은 긴급 서비스를 하고자 하는 앱은 승인하지 않는다.

5. 알림서비스 (푸쉬 노티피케이션)

5.1     APN(애플 푸쉬 노티피케이션) API를 사용하지 않은 알림서비스를 제공하는 앱은 승인하지 않는다.
5.2     애플로부터 푸쉬 어플리케이션 ID를 득하지 않고 APN 서비스를 사용하는 앱은 승인하지 않는다.
5.3     사용자 합의를 먼저 득하지 않고 알림서비스를 보내는 앱은 승인하지 않는다.
5.4     알림서비스를 통해 민감한 개인정보, 혹은 비밀정보를 보내는 앱은 승인하지 않는다.
5.5     알림서비스를 통해 원하지 않는 메시지를 전하거나, 피싱 혹은 스팸의 목적으로 만들어진 앱은 승인하지 않는다.
5.6     앱의 알림서비스를 이용하여 광고, 프로모션, 혹은 어떠한 직접적 마케팅도 해서는 안된다.
5.7     앱의 알림서비스 사용료를 사용자들로 하여금 부담하게 해서는 안된다.
5.8     알림서비스를 통해 네트워크 용량 혹은 APN 서비스의 대역폭을 과도하게 사용하거나 기기에 지나친 부담을 주는 앱은 승인하지 않는다.
5.9     바이러스, 파일, 컴퓨터 코드, 혹은 APN 서비스의 정상적인 기동을 방해하거나 손상을 끼치는 프로그램을 전송하는 앱은 승인하지 않는다.

6. 게임센터

6.1     플레이어 ID를 최종사용자 혹은 제3자에게 보여주는 앱은 승인하지 않는다.
6.2     어떠한 목적으로든 플레이어 ID를 사용하는 앱은 승인하지 않는다. 단, 그것이 게임센터 약관에 근거하였을 경우는 논외로 한다.
6.3     룩업, 트레이스, 릴레이트, 어소시에이트, 마인, 하베스트 등을 역추적하여 플레이어 ID, 가명 혹은 기타 게임센터를 통해 얻을 수 있는 정보를 이용하고자 하는 개발자는 iOS 개발자 프로그램에서 퇴출한다.
6.4     순위권 점수 따위의 게임센터 정보는 게임센터의 승인을 받은 앱에서만 사용할 수 있다.
6.5     게임센터 서비스를 통해 원하지 않는 메시지를 전하거나, 피싱 혹은 스팸의 목적으로 만들어진 앱은 승인하지
          않는다.
6.6     게임센터 서비스를 통해 네트워크 용량 혹은 APN 서비스의 대역폭을 과도하게 사용하는 앱은 승인하지 않는다.
6.7     바이러스, 파일, 컴퓨터 코드, 혹은 게임센터 서비스의 정상적인 기동을 방해하거나 손상을 끼치는 프로그램을
          전송하는 앱은 승인하지 않는다.

7. 전자광고

7.1     인위적으로 광고의 시청수나 조회수를 올리고자 하는 앱은 승인하지 않는다.
7.2     아무 내용이 없는 전자광고 배너를 달고 있는 앱은 승인하지 않는다.
7.3     광고를 보여주는 것이 주목적인 앱은 승인하지 않는다.

8. 상표, 상품외장

8.1     개발자들은 애플 상표 및 저작권 사용에 관한 가이드라인과 애플 상표 리스트에 명시된 모든 약관에 근거하여 앱을 제작해야 한다.
8.2     애플이 앱의 소스나 공급자라고 주장하거나 애플이 앱의 품질이나 기능을 보증한다는 내용을 주장 혹은 암시하는 앱은 승인하지 않는다.
8.3     애플 제품이나 광고 주제와 혼동할 수 있을 정도로 유사한 앱은 승인하지 않는다.
8.4     앱 이름 상에 애플 제품 이름의 철자를 잘못 적었을 경우 (예, GPS for Iphone, iTuz) 해당 앱은 승인하지 않는다.
8.5     법적으로 보장되는 제3자의 권리(상표, 저작권, 기업비밀, 기타 등록된 컨텐츠)를 사용할 경우 요청 시 서류화된 사용권을 제출해야한다.
8.6     오리지널 컨텐츠의 기능에 변화가 없고 해당 브랜드에 관해 모든 것을 명확히 확인할 수 있다는 전제 하에서 구글 맵스 API를 통해 습득한 구글 맵스 및 구글 어스 이미지는 어플리케이션 내에서 사용할 수 있다.

9. 미디어 컨텐츠

9.1     음악 라이브러리에 접속 시 MediaPlayer framework를 사용하지 않는 앱은 승인하지 않는다.
9.2     아이팟 인터페이스를 흉내낸 사용자 인터페이스를 가진 앱은 승인하지 않는다.
9.3     무선 네트워크를 통한 오디오 스트리밍 컨텐츠는 5분 간 5메가 이상 사용하지 않도록 한다.
9.4     무선 네트워크를 통한 비디오 스트리밍 컨텐츠는 10분을 초과하는 경우 HTTP 라이브 스트리밍을 사용해야하며, 기본 64kbps 오디오만 사용한 HTTP 라이브 스트림을 포함해야한다.

10. 사용자 인터페이스

10.1   모든 앱은 애플 아이폰 Human Interface Guidelines과 애플 아이패드 Human Interface Guidelines에 맞춰 제작해야 한다.
10.2   앱스토어, 아이튠스스토어, 아이북스토어를 포함한 아이폰 상에 기본으로 제공되는 번들 앱과 유사한 앱은 승인 하지 않는다.
10.3   애플 아이폰 Human Interface Guidelines과 애플 아이패드 Human Interface Guidelines에 명시된대로 버튼이나  아이콘 등을 제대로 제공하는 시스템이 없는 앱은 승인하지 않는다.
10.4   변경된 데스크탑/홈 스크린 환경을 만들거나 멀티앱 위젯 환경을 시뮬레이션하는 앱은 승인하지 않는다.
10.5   볼륨 업/다운 및 벨소리/진동 스위치 같은 기본적인 스위치 기능을 변경하는 앱은 승인하지 않는다.
10.6   애플과 애플의 고객들은 심플하고 세련되며 창의적이고 좋은 아이디어에서 나온 인터페이스를 높이 평가한다.
          이러한 인터페이스를 만들기 위해서는 더 많은 노력이 필요하지만, 그럴만한 가치가 있는 일이다.
          인터페이스에 관한 애플의 기준치는 높다.
          만약 당신의 사용자 인터페이스가 복잡하거나 좋지 않을 경우 해당 앱을 승인하지 않을 것이다.

11. 구입, 통화

11.1   락을 풀어서 앱스토어 이외의 메커니즘에서 추가적인 기능을 사용할 수 있도록 하는 앱은 승인하지 않는다.
11.2   앱 상의 구매 API (IAP) 이외의 시스템을 통해 앱 상의 컨텐츠, 기능, 혹은 서비스를 구매할 수 있도록 하는 앱은 승인하지 않는다.
11.3   IAP를 통해 어플리케이션 외에서 쓰이는 상품이나 서비스를 구입할 수 있도록 하는 앱은 승인하지 않는다.
11.4   IAP를 통해 신용이나 다른 통화를 구입하는 앱의 경우 해당 신용을 어플리케이션 내에서 소비해야한다.
11.5   IAP를 통해 만료된 신용이나 다른 통화를 구입하는 앱은 승인하지 않는다.
11.6   IAP를 통한 컨텐츠 가입은 최소 30일 동안 유지되어야하며, iOS를 사용하는 기기를 가진 모든 사용자들에게 공개 되어야한다.
11.7   IAP를 통해 물품을 구입하는 앱의 경우 정확한 구입기능이 있어야한다.
11.8   IAP를 통해 카메라나 자이로스코프 따위의 iOS에 내장된 기능에 접속할 수 있는 권한을 구매할 수 있도록 하는 앱은 승인하지 않는다.
11.9   “렌탈” 컨텐츠나 일정 기간이 지나면 만료되는 서비스를 포함한 앱은 승인하지 않는다.
11.10   보험 어플리케이션은 무료여야하며, 배포되는 지역의 법을 준수해야한다. 또한, 해당 앱은 IAP를 사용할 수 없다.
11.11   전반적으로, 당신이 만든 앱이 비쌀수록 우리는 더 철저하게 리뷰를 할 것이다.

12. 긁어오기, 종합

12.1   애플 사이트(예: apple.com, 아이튠스스토어, 앱스토어, 아이튠스커넥트, 애플 개발자 프로그램 등)로부터 정보를 긁어오거나 애플 사이트와 서비스의 컨텐츠를 이용해서 순위를 만드는 앱은 승인하지 않는다.
12.2   어플리케이션은 아이튠스스토어 RSS feed 따위의 승인받은 애플 RSS feeds를 사용해야 한다.
12.3   웹상의 자료를 잘라온 것이나 컨텐츠 모음, 혹은 링크모음 따위의 앱은 승인하지 않는다.

13. 기기에 손상

13.1   사용자들로 하여금 애플 기기를 기기를 손상시키는 방향으로 사용하게 유도하는 앱은 승인하지 않는다.
13.2   기기의 배터리를 급격히 소모시키거나 과도한 열을 발생시키는 앱은 승인하지 않는다.

14. 개인적인 공격

14.1   명예훼손, 공격적, 비열한 내용을 포함하거나 혹은 특정인이나 집단에게 해를 끼칠 수 있는 앱은 승인하지 않는다.
14.2   직업적 정치 풍자가나 유머작가는 공격적, 비열한 코멘트로 인한 금지 항목에서 제외한다.

15. 폭력성

15.1   사람이나 짐승이 살해당하는 모습, 불구가 되는 모습, 총에 맞는 모습, 칼에 찔리는 모습, 고문당하거나 다치는
          모습의 실제 이미지를 표현한 앱은 승인하지 않는다.
15.2   폭력이나 아동학대를 묘사한 앱은 승인하지 않는다.
15.3   게임 상의 “적”은 특정인종, 문화, 실존하는 정부나 회사, 혹은 그 어떤 실제적 존재를 단독으로 지목하여 만들어서는 안된다.
15.4   무기를 통한 폭력을 현실적으로 보여줘서 무기의 불법적, 난폭한 사용을 독려하는 앱은 승인하지 않는다.
15.5   러시안 룰렛을 포함한 앱은 승인하지 않는다.

16. 거부감을 주는 컨텐츠

16.1   과도하게 거부감을 주거나 상스러운 컨텐츠를 보여주는 앱은 승인하지 않는다.
16.2   주로 사용자를 기분나쁘게 하거나 역겹게 하기 위한 목적으로 제작된 앱은 승인하지 않는다.

17. 사생활

17.1   모든 앱은 사용자 정보 사용에 관해 사전에 사용자의 허락없이, 그리고 사용자로 하여금 해당 정보가 어디서 어떻게 사용될 것인지에 관해 알려주지 않은 채 사용자 정보를 전송할 수 없다.
17.2   구동을 위해서 이메일 주소나 생년월일 따위의 사용자 개인정보의 공유를 필요로 하는 앱은 승인하지 않는다.
17.3   미성년자를 대상으로 정보수집을 하는 앱은 승인하지 않는다.

18. 포르노그래피

18.1   웹스터 사전에서 정의한 “생식기관의 노골적 묘사, 그리고 미적이나 감성적인 느낌이 아닌 에로틱한 느낌을 유발하기 위한 목적의 노골적 행위를 표현한 것”에 해당하는 포르노물을 포함한 앱은 승인하지 않는다.
18.2   수시로 포르노물에 해당하는 내용이 등장하는 사용자 제작 컨텐츠를 포함하는 앱(예: “채트 룰렛” 앱)은 승인하지 않는다.

19. 종교, 문화, 인종

19.1   특정 종교, 문화, 혹은 인종에 대해 명예훼손, 공격적, 비열한 태도를 취하고 있거나 해당 그룹에게 피해를 끼칠 수 있는 코멘트 혹은 문헌을 포함한 앱은 승인하지 않는다.
19.2   앱이 종교적인 텍스트를 포함할 경우, 텍스트 상의 멘트나 번역은 정확해야한다. 코멘트는 선동적이라기보다는 교육적이거나 정보전달 차원에서 그쳐야한다.

20. 컨테스트, 경품, 복권, 추첨

20.1   경품 및 컨테스트는 앱의 개발자/회사가 후원하여 제공해야한다.
20.2   경품 및 컨테스트에 관한 공식적인 룰이 앱 상에 표기되어야하며, 해당 행위에 관해 애플이 관련이 없다는 점을 명확히 해야한다.
20.3   복권 앱을 만들기 위해서는 개발자가 법적 허가를 득해야하며, 복권 앱은 해당 3가지 특성을 모두 갖추고 있어야 한다: 배려, 기회, 상금
20.4   사용자로 하여금 직접적으로 복권이나 추첨티켓을 살 수 있도록 하는 앱은 승인하지 않는다.

21. 자선, 기부

21.1   자선단체에 기부할 수 있는 기능을 포함한 앱은 무료여야한다.
21.2   기부금의 모금은 사파리 상의 웹사이트나 SMS를 통해 이뤄져야한다.

22. 법적 요구사항

22.1   앱은 사용자에게 공개되는 지역의 법적 요구사항을 충족시켜야한다. 모든 지역법을 이해하고 따르는 것은 개발자 들의 의무사항이다.
22.2   허위사실, 사기, 호도된 정보를 포함한 앱은 승인하지 않는다.
22.3   범죄 혹은 난폭한 행위를 요청, 촉진, 장려하는 앱은 승인하지 않는다.
22.4   불법적 파일 공유를 가능케하는 앱은 승인하지 않는다.
22.5   카드 카운터를 포함한 불법적 도박을 조장하기 위해 만들어진 앱은 승인하지 않는다.
22.6   익명 혹은 장난스러운 전화나 SMS/MMS 메시지 전송이 가능한 앱은 승인하지 않는다.
22.7   부정한 방법으로 사용자의 패스워드나 기타 개인정보를 알아내고자 하는 목적으로 앱을 만든 개발자는 iOS 개발자 프로그램에서 퇴출한다.

이 문서는 지속적으로 업데이트되는 문서임

이 문서는 개발자들이 앱스토어에 제출하는 앱을 우리가 어떻게 리뷰하는지 알려줍니다. 또한 우리는 이 가이드가 당신이 앱을 개발하고 제출하는데에 있어 도움이 될 수 있기를 바랍니다. 이 가이드는 새로운 앱과 상황이 발생함에 따라 지속적으로 업데이트되는 문서이며, 변경사항이 있을 경우 주기적으로 이를 반영할 계획입니다.
iOS의 앱 개발에 참여해주셔서 감사합니다. 비록 이 문서가 당신이 하지 말아야할 것들로 가득하긴 하지만, 그보다 훨씬 짧더라도 당신이 꼭 해야하는 것들의 리스트를 꼭 기억해두시길 바랍니다. 무엇보다도, 사용자들을 놀라게 하고 기쁘게 하는 것에 동참 해주시길 바랍니다. 그들에게 창조적인 길을 보여주고, 이전에는 볼 수 없었던 방법으로 소통할 수 있도록 해주십시오. 우리의 경험에 의하면 사용자들은 기능적으로나 사용자 인터페이스적으로 세련된 것에 적극적으로 반응합니다. 조금 더 노력하셔서 그들에게 그들이 기대하는 이상을 보여주십시오. 그들이 이전까지 본 적이 없는 세계를 보여주시기 바랍니다. 우리는 당신을 도울 준비가 되어있습니다.

*위 문서는 개인 블로그 ,카페등에 가져가실수 있지만, 반드시 문서의 출처 Appsnext.com 을 명기해주시기 바랍니

응용 프로그램이 TWAIN을 이용하여 데이터를 취득할 때, 응용 프로그램을 사용하는 사람을 기준으로 바라보는 취득하기 위한 절차는 다음과 같은 세가지 측면으로 볼 수 있습니다.

Figure 2-2 Data Acquisition Process

The Application

사용자에게는 원하는 데이터를 취득하기 위해, 적절한 장치를 선택할 수 있어야 합니다. 또한 데이터 전송 준비가 완료되었을 때 그 에 맞는 신호를 받기 원합니다. 이러한 요구 사항들을 충족하기 위해 TWAIN에서는 File 메뉴와 같은 곳에 반드시 두가지 옵션을 넣도록 권고 하고 있습니다.

• Select Source - Source 선택 : 장치를 선택하기 위한 기능
• Acquire - 데이터 획득 : 데이터 전송 처리를 시작.

The Source Manager

사용자가 Select Source의 옵션을 선택 할 때, 응용 프로그램에서는 Source Manager에게 Select Source 대화상자를 띄우도록 요청하게 됩니다. 여기서는 현재 선택가능한 모든 장비들을 나열하고 사용자가 원하는 장비를 선택 표시될 수 있도록 합니다. 필요하면, 응용 프로그램에서 이 사용자 인터페이스를 자신의 버전에 맞게 별도 제작도 가능합니다.

The Source

모든 TWAIN 호환 Source에서는 독자적인 장비 별로 사용자 인터페이스를 제공합니다. 응용 프로그램 사용자는 Acquire 옵션을 선택할 때, Source에서 제공되는 인터페이스를 보여주게 됩니다. 물론 필요하면, 응용 프로그램에서 자신의 버전에 맞게 별도 제작도 가능합니다.

준비물.

VMWare Workstation 7.0 정품.

vmware-darwin-200

해킨토시용 MacOSX ( D:\OSX86.iPC.iDeneb.v1.4.10.5.6.Mac.OS.X.Leopard.Kalyway_10.5.2_DVD_Intel_Amd.iso 같은...파일이름은 각기 배포판 버전이나 캐리어의 규칙에 따라 달라질 수 있음 )

1. VMWare Workstation 준비.

일단, VMWare Workstation 7.0 을 설치한다. (가격이 세긴하지만, 성능은 우수한 가상 머신)
설치방법이야, 일반적인 VMWare Workstation 방법이고, 사이트에서 받은 Key를 넣는다.

그리고 vmware-darwin-200 을 설치한다. 사실 darwin for vmware 인데, 어둠의 경로나 기타 여러 해킨토시 관련 사이트를 통해 받을 수 있다. 일단 필자가 가진 darwin for vmware는 200 이라는 이름으로 적혀서 전달 받았는데, 그건 각기 받는 곳에따라 버전에 따라 조금씩 차이는 있겠지만, 적절한 경로에 맞추어 설치해주도록 한다.
일단 위의 파일의 압축이 되어 있으면 압축을 풀도록 한다.
그리고 setup.cmd 가 있는지 확인한다.
setup.cmd가 있으면 다음과 같이 명령을 넣는다.

setup.cmd install

만일 Windows Vista나 Windows 7 과 같은 버전의 윈도우를 사용 중이라면, cmd 창을 띄울 때 반드시 Administrator 권한을 가진 cmd 창을 열도록 한다.

2. VM 만들기.

가상 머신을 만드는 작업이다.

일반적인 새 가상 머신을 만드는 작업과 동일하지만, 몇가지 부분만 고려해서 만들도록 한다.

1. 반드시 Custom(advanced) - 사용자 정의(고급) 을 선택해서 진행한다.
   
2. 버전은 Workstation 6.5~7.0 에 맞춘다. 기본값이므로 그대로 둔다.
   
3. 설치될 게스트 OS를 선택한다, 여기서는 반드시 Other의 FreeBSD를 선택한다.
   물론 Darwin이 x64 지원 버전이 있을 수 있는데, 그 경우에는 FreeBSD 64-Bit 를 선택한다.
   몇가지 변경이 필요할 수 있겠지만, 여기서는 FreeBSD로 할 예정이다.
   
   
4. VM의 이름 및 저장될 위치등을 결정한다. 이름은 임의대로, 그리고 위치도, 원하는 대로 설정하도록 한다.
   (만일 C 드라이브로 설정되어 있는데, 용량이 부족할 수 있으므로 이 부분을 꼭 확인하도록 하자)
   
5. 프로세스 갯수 및 코어 갯수. 프로세서야 보통 1개니 위쪽에서 1을 선택하고(시피유 2개짜리면 2를 선택하면 될듯). 듀얼 코어면 밑의 칸에서 2, 쿼드코어면 4, 구형 PC면 1을 선택하면 된다. 현재 자신의 PC에서 여유가 될법한 만큼 설정하면 된다.
   
   
6. 메모리 사이즈. 간단하게 돌리는 정도면 512MB도 무난하지만, 개발을 하려면, 현재 가지고 있는 메모리를 고려해서 넉넉하게 잡도록 한다. 현재 필자의 PC는 거의 3G 정도인데, 그래서 2G 2048MB로 잡았다.
   
7. 네트워크 설정. 지금 랜카드와 직접적으로 연결하려면 Bridge를 설정한다.만일 VM의 네트워크가 밖으로 안새게 하려면 NAT로 설정하도록 한다. 여기서는 그냥 NAT로 잡아도 무방하다. ( 즉 인터넷 공유기를 한개 더 끼어 있다고 생각하면 됨 )
   
   
8. 다음은 HDD. HDD 동작 방식인데, 이 부분은 필자도 명확이 모르는 기능. 현재로는 권장사항이라고 적힌 부분을 선택된 채로 두도록 한다.
   
   
9. 다음은 Virtual HDD를 새로 만들 것인지, 기존의 것을 슬것인지, 아니면 직접 물리적인 HDD와 연결할 것인지를 묻는 부분인데, 그냥 새로 만드는 것으로 한다.
   
   
10. 그 다음 IDE 방식으로 할지, SCSI 방식으로 할지인데, 권장 방법으로 선택한다. 만일 64bit인 경우라면, 아마도 SCSI 방식이 권장으로 되어 있는데, 현재는 32Bit 여서 그런지, IDE로 설치하도록 한다.
    
11. 용량은 자유롭게, 하지만, 기본 값이 8G 는 너무 작으니, 넉넉하게 잡도록 한다.
    
    
12. 다음은 HDD 디스크 파일 이름. 그냥 VM 이름과 동일하게 잡히므로 그대로 두면 된다.
    
13. 최종적으로 설치될 VM에 대한 각종 값들을 표시해주는데, 확인하고 Finish를 클릭하면 된다.
    만일 FDD 같은 쓸모없는 장치에 대한 제거는 Customize Hardware 버튼을 눌러 지우면 된다.
    단, 주의할 것은 이 가상장치를 일단 켜지 말고, 다음 작업을 해야 한다. 이를 위해서는 Power on this virtual machine after creation 의 체크를 끄도록 한다..
    
    
14. 자 이젠 VM이 설치되어 있는 폴더로 이동하자.
    그리고 VM 파일들이 있는 위치내에서 vmx 파일을 메모장을 통해 열도록 한다.
    vmx 파일을 Drag & Drop(끌어 놓기)하면 된다.
    
    
15. 열린 파일에서 GuestOS 라고 적힌 부분에 "Darwin10" 이라고 넣는다.
    만일 지금까지 64bit로 설정하신 분은 Darwin10-64 라고 넣도록 한다.

3. Mac OS X 설치하기.

VM도 준비되었고, 이제 준비해 놓은 Mac OS X 시디 이미지를 VM에 연결한다.
연결 방법은 VM의 설정(Edit virtual machine)에 들어가, 이미지를 걸어준다.
앞서 준비물로 언급한 핵킨토시용 Mac OS X면 된다.

그리고 난 뒤 장치를 켠다.그러면 맨 처음 검은 화면에 아래와 같이 표시된다.
지체없이 검은 화면 안으로 들어가 아무키나 누른다.

그럼 아래와 같은 화면으로 넘어간다. 잠시만 기다리자.

그러면 맨처음 언어 설정이 나온다. 한글로 하도록 하자.

계속을 클릭한다.(이 화면은 가지고 있는 해킨토시 이미지에 따라 다를 수 있습니다.)

해킨토시 사용에 대한 주의 사항을 일러줍니다.VM이 아닌 직접 자신의 PC에다 설치하는 경우 간혹 호환성 문제나 H/W 문제를 일으킬 소지가 다분이 있다는 조금 겁나는 경고들입니다. 그냥 동의하시구요.

이제 어디에다 설치할 것인가... 하는 부분인데, 맨처음 보면 아래와 같이 텅텅 비어 있습니다.

상단의 메뉴에서 유틸리티 -> 디스크 유틸리티를 선택합니다.

아래의 이미지 처럼, 볼륨설계에서 1개의 파티션을 선택하고, 이름에 적당한 이름을 넣고 적용을 누릅니다.

디스크 선택화면에 드디어 HDD가 보입니다. 해당 하드를 선택하고 설치를 진행하면 된다.

이제 설치 버튼을 클릭하면 자동으로 쫙 설치합니다.

4. Mac 가상 머신 설정.

이제 대부분의 단계는 완료되었다.
뭐 apple.com 계정이 기존에 있다면 최초 그 계정을 넣어주고, 없다면 계정 생성을 위한 정보들을 제공하게 된다.
뭐 자질구레한 설정 후 최후 darwin.iso를 설치하면 된다.

5. 마무리

사실 1~3 까지의 단계가 문제지, 그 이후는 Mac에 대한 기본 동작이므로 쉽게 쉽게 진행 할 수 있다.
(사용자 계정을 만드는 작업 빼고.)
현재 포스팅 내용은 대부분 직접 캡처하고 기록한 것이지만,
이 모든 내용의 단서는 "다크스타"님의 블로그를 참고(아니 완전 활용) 했다.

1. VMware에 맥 스노우레오파드 설치하기![1]
2. VMware에 맥 스노우레오파드 설치하기![2]

여튼 성공 기원 합니다 ㅋ

원본 문서 : http://www.twain.org/docs/TWAIN_2_1_Spec.pdf
Chapter 2. Technical Overview - TWAIN Architecture

TWAIN에서는 전체적으로 세가지 소프트웨어 구성요소들 통해 만들어진 데이터를 전송합니다. 응용프로그램, Source Manager, Source 이렇게 세가지가 그 중요 구성요소입니다.

이 구성요소들은 TWAIN의 아키텍처를 사용하여 서로 커뮤니케이션을 수행합니다. TWAIN 아키텍처는 ekdmarhk rkxdl 총 4가지 레이어로 되어 있습니다.

• Application
• Protocol
• Acquisition
• Device

TWAIN 소프트웨어 구성요소들이 각 계층에 어떻게 배치되는지를 아래의 그림처럼 나타낼 수 있습니다. 각 레이어는 각 섹션별로 설명을 할 예정입니다.

Application

사용자의 소프트웨어 응용프로그램 자체가 실행되는 부분이 바로 이 계층입니다.

TWAIN 에서는 사용자 인터페이스에 대한 가이드라인을 제공합니다. TWAIN기능들을 사용자들이 어떻게 접근해야 하는지 특정 Source를 어떻게 선택하는지와 같은 방법들을 응용 프로그램 개발자들에게 제시하게 됩니다.

TWAIN에서는 응용 프로그램을 어떻게 구현하는지는 전혀 고려되어있지 않습니다. 단지 응용 프로그램에서 사용하게 될 각종 응용 프로그램 내부 간의 통신 스키마에 대해 쉽게 접근 할 수 있도록 도와주는 것입니다.

Protocol.

Protocol 이란 일종의 "언어"로써 TWAIN에서 사용되는 각종 문법 같은 것으로 생각하면 됩니다. 데이터 송수신에 필요한 정확한 명령들과 통신 규약들을 정해 놓은 것입니다.

Protocol 계층에는 다음과 같은 내용이 포함되어 있습니다.

• 응용 프로그램과 TWAIN 간에 인터페이스를 제공하는 응용 프로그램 소프트웨어의 일부분.
• TWAIN에서 제공하는 TWAIN Source Manager
• Source Manager에서 명령을 받고, 데이터와 결과 코드를 돌려주는 Source 장비에 포함된 소프트웨어

Protocol 계층에 대한 더 자세한 내용들은 "Communication Between the Element of TWAIN" ( Page 2-5 ) 를 참조하세요.

Acquisition

Acquisition(취득) 장치는 물리적(스캐너 혹은 디지털 카메라 같은)일 수도 있고, 논리적(이미지 데이터베이스 같은)일 수도 있습니다. 이 계층에서 가장 중요한 위치에서 Source 라고 불리는 취득 동작을 제어하는 소프트웨어 요소들로 되어 있습니다.

Source에서는 응용 프로그램에게 데이터를 전송합니다. Source와 응용 프로그램 상에서 합의를 본 형식과 전송 방법을 사용하여 전송하게 됩니다.

Source는 항상 Source 장치들을 제어하기 위한 내장된 사용자 인터페이스들을 제공합니다. 물론 필요한 경우에 응용 프로그램에서 이들 기능들을 추가적으로 덧붙여 자신만의 사용자 인터페이스를 제공할 수 있습니다.

Device

이 부분은 전통적인 저 수준의 장지 드라이버 레벨을 의미합니다. 여기서는 장치 별로 제공되는 H/W 레벨의 명령과 지시들을 전달하는 것으로 각 제조사 별로 제공된 드라이버에 특화되어 있습니다. 응용 프로그램에서는 단지 TWAIN을 사용을 하면 되고 , 이 장치 드라이버를 별도로 탑재하지 않아도 됩니다. 이 부분은 모두 Source에서 담당하게 됩니다.

TWAIN에서는 Device 계층에 대한 모든 사항들이 고려되어 있지는 않습니다. 단지 Source에서 응용 프로그램이 직접 Device 계층을 접근하지 않도록 숨겨놓았습니다. Source는 TWAIN 동작과 Source의 사용자 인터페이스 사이에서 조율을 하게 됩니다. 이를 통해 사용자가 직접 장비에 접근하지 않고도 원하는 기능을 수행할 수 있도록 내부적으로 적절한 명령들을 내리게 되는 것입니다.

NOTE : Protocol 계층은 응용 프로그램 과 Source들 사이에서 정확한 통신을 할 수 있도록 사려깊으며 엄격하게 정의되어 있습니다. 이 문서안의 정보들은 Protocol 과 Acquisition 계층에 대해 주안점을 두고 작성되었습니다.

DAMO(Domino Access for Microsoft Outlook) 프로그램을 사용하여,

Outlook에서도 마치 Exchange 쓰듯 Lotus Domino 서버를 활용할 수 있다.

보통 XP의 Outlook 2003에서는 상당히 제정신으로 도는데,

MS에서도 밥벌어먹고 살려면 업그레이드를 해야 되겠고,

결국 덩달아 업그레이드를 하다 보니, 현재 구성은 Windows 7에 Outlook 2007이 되버렸다.

그러나 최적의 환경을 구성하기에는 너무 구닥다리 같은 UI와 기능들에

결국 꿋꿋하게 Windows 7의 Outlook 2007을 활용하려고 한다.

그러나 현재 Outlook 2007을 종료하면 자꾸 프로그램 오류가 발생한다.

에러 내용은 아래와 같다.

Faulting application name: OUTLOOK.EXE, version: 12.0.4518.1014, time stamp: 0x4542840f
Faulting module name: nwnspR32.dll_unloaded, version: 0.0.0.0, time stamp: 0x489c864f
Exception code: 0xc0000005
Fault offset: 0x01e82e74
Faulting process id: 0xcf4
Faulting application start time: 0x01ca9e6097aafc8d
Faulting application path: C:\Program Files\Microsoft Office\Office12\OUTLOOK.EXE
Faulting module path: nwnspR32.dll
Report Id: f39a9d85-0a53-11df-b241-001f3b661b0f

일단 현재까지 파악한 내용은 Windows 7(Vista 때 부터 담겼던) Windows Search가 Outlook 자원까지 찝적거린결과 였었다. 최소한 Windows Search가 찝적되면 Outlook이 제대로 작동하지 않는다.

이 것을 해결하는 방법은 아래의 레지스트리를 수정하면 된다.( 대개는 없으므로 추가해야 한다. )

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Windows Search]
"PreventIndexingOutlook"=dword:00000001

그리고 난 뒤, Windows Search 서비스를 재 시작하거나, 아니면 컴퓨터를 리부팅 한다.

UPDATE: 2010-01-06 18:41

SP1을 적용했으나, 변화 없음 똑 같은 형태로 에러가 발생한다.

현재 설치된 버전의 About 내용은 아래와 같다.

   Outlook 2007

  DAMO 8.0.2

일단 현재 상황은 아직도 오류는 발생 오류 내용은 아래와 같다.

Faulting application name: OUTLOOK.EXE, version: 12.0.6316.5000, time stamp: 0x4833a470
Faulting module name: nwnspR32.dll_unloaded, version: 0.0.0.0, time stamp: 0x489c864f
Exception code: 0xc0000005
Fault offset: 0x02222e74
Faulting process id: 0x5d4
Faulting application start time: 0x01ca9e6b2826f17f
Faulting application path: C:\Program Files\Microsoft Office\Office12\OUTLOOK.EXE
Faulting module path: nwnspR32.dll
Report Id: c4be8a8d-0a5e-11df-9165-005056c00008

짐작이지만, Outlook 종료 때, 이 DAMO의 핵심 DLL인 nwnspR32.dll 이 지연되서 발생되는 문제같다. 아무래도 Notes와의 연결을 정리해야 하는데, 그 시간이 의외 많이 걸리는듯...

Outlook이 조금 천천히 종료되거나, 이 DAMO가 빨리 종료되면 문제가 없을 것 같은데...

역 어셈블해서 까야 되나... 일단 SP2를 한번 받아서 설치해보고 그 뒤를 보도록 하겠다.

구글 크롬을 한창 사용 중인데, IE의 고유 기능을 사용할 때 별 수 없이 IE를 꺼내게 된다.

하지만, 점점 Task bar에 달린 응용 프로그램의 종류가 많아져서

이제는 더 이상 추가하기도 그렇고, 자꾸 IE와 Chrome을 혼재해서 쓰니까,

사용면에 있어 점점 활용도가 엇갈리며 떨어져 갔다.

이에 단행!. IE를 Task Bar에서 없애고, 대신 Chrome을 사용하는 방법을 모색 중에,

Google Chrome 4.0 이상에서는 IE 플러그인을 제공한다는 사실을 알게 되었다.

그러나, 다른 한국어 사이트들에서 제공하는 내용은 대부분,

과거 3.0 시절의 패치 방법이나, 좀 Hack 스럽게 하거나,

아니면 별도의 다른 프로그램의 힘을 빌어 처리하는 방법이였다.

공식인지는 모르겠지만, 일단 크롬 플러그인들을 제공하는 사이트에서 제공하는 방법으로

아래의 링크에서 플러그인을 다운로드 받아 설치하면 된다.

http://www.chromeextensions.org/utilities/ie-tab/

사용방법은 원하는 URL로 이동한 후에, URL 바 옆쪽에 있는 IE 아이콘을 누르기만 하면 된다.

많다고 하면 많고, 조금이라고 생각하면 조금이겠지만,

최소한 나름대로 다양한 사이트를 경험해왔다고 생각은 한다.

다양한 사이트를 다니면서 이런 저런 것들을 만들고 구성하면서 드는 최후의 생각은 바로 이것이였다.

“ 고객은 적이다!!!! “

하지만, 일을 하면서 돈을 주는 건 애석하게도 고객이기 때문에, 언제나 프로그래머들은 “적과의 동침"(?)을 계속 해올 수 밖에 없었다.

이 때, PM혹은 PL 또는 프로그래머들은 일정과 요구사항에 맞추어 고객을 무시하고 진행할 수 있다. 제시간에 프로젝트를 종료하고, 모든 프로그래머들은 행복하고, 편한 사이트라고 평할 수 있는 그런 진행말이다. 그러나, 우리나라에서 그런 짓을 하다가는 십중 팔구 프로젝트 실패나 고객의 불신 포인트 쌓기에 심하면 차기 프로젝트에 있어서 지명 제외 사태까지 벌어진다. 더욱이 고객이 네트워크 까지 넓다면 다른 사이트 들어가기는 물 건너 간셈.

그렇다면 고육지책이지만, 프로그래머를 쥐어 짜면? 무리한 요구사항들이든 뭐든 받아들이고 진행하면? 물론 프로젝트 검수 완료 될 때( 대개 프로젝트의 사이즈에 따라 다르겠지만, 1~2 주일, 혹은 한달, 심하면 1년? 지연이 되는 것은 어쩔 수 없을 듯… ) 고객의 극찬과 맛난 음식이 기다리겠지만, 그 전에 프로그래머들의 건강은 피폐해지고, 직업병에 대한 심각한 우울의 나락을 왔다 갔다 하고 자신의 신세한탄의 홍수에 오락가락 할 것은 뻔하다. 그리고 이직하고 이직하고…

이게 현실이다!!!! 라고 말하기에는 무언가 이상하다고 생각된다.

사실 고객이라고 해봐야, 그들도 결국 다른 이들을 고객으로 삼고있는 또 다른 형태의 서비스 제공자일 뿐이다. 그들도 이 소프트웨어 바닥의 괴로움 정도는 어느정도 알고 있다고 생각한다. (최소한 초창기 시절 보다는.. ). 이심 전심이지 않을까? 그들도 최소한 서로 Win-Win 하는 방법을 찾고 싶어하고, 그렇게 움직이고 싶어한다. 하지만, 결국 일을 시작하면, 자선사업이 아닌 이상, 결국은 비용과 일정 때문에, 결국 프로그래머들을 쪼고 또 쪼게 되는 악순환을  반복하게 된다.

자… 그럼 무엇이 문제일까?

이 부분에 대한 해답까지는 아니지만, 나름 대로 실타래 끝자락을 바로 이 애자일에서 찾을 수 있었다.

맨 처음 접했던 애자일은 사실 신뢰성 0 였다. 도리어 여타 다른 방법론과 같이 취급되었다. 그전에 직접 체험 보다는 간접 체험한 사람들의 결과 내용들을 보기만 했는데, 이게 과연 방법론 맞아? 라는 의구심만 들게 만들었고, 가장 위험한 방법론이구나, 라는 생각이 들었다. 그리고 몇 년이 흘러, 우연히 찾은 김창준씨의 블로그를 보면서 새롭게 바라보았고, 관련 서적을 이것 저것을 보고 난 뒤, 나의 오해는 거의 다 푼 것 같았다.

자,다시! 그렇다면 문제는 무엇일까?

최소한 내가 바라보는 문제는 바로 고객과 프로그래머 사이를 효율적으로 조율할 무언가의 부재였다. 이 이야기하면, “PM이나 PL이 바로 그런 역할을 하는 거야!” 라고 정중히 충고하시는 분들이 있을 것이다. 그러나 그건 다르다. PM이나 PL은 고객과 프로그래머를 조율하는 것이 아니라, 일정 관리나, 기술 관리 등을 수행하는 또 다른 조직일 뿐이다. 혹은 설계 부분을 담당하거나, 요구사항을 정리도 하겠지만, 결국 프로그래머 관리하는 관리 조직일 뿐인 것이다. 그렇다면 그 무언가는 무엇인가?

그건 바로 중간 결과물이다.

다시 오해를 벗기 위해 또 다시 이야기를 하겠다. 내가 말하는 중간 결과물은 단순한 문서나 제작중인 코드를 의미하는 것이 아니다. 게다가 솔직히 문서 같은 것은 중간에 고객에게 보여주기 위해서 만들기 보다는 중간에 품질 관리에서 도장을 받기 위한 숙제 같은 것일 뿐, 중간 결과물이 아니다!!!

내가 말하고 싶은 것은 바로 프로토타입 처럼 고객에게 보여줄 수 있는 그런 중간 결과물이다.

터무니 없다고 생각되는가? 그럴 수 있다. 도리어 성급하게 결과물을 보여주면 그간 모아온 요구사항과 완전 역전되는 진행을 낳을 수도 있다. 그러면 기존에 설계된 사항과 완벽히 위반되어 처음 부터 다시하는것 아닌가? 라는 것이다. 맞다. 정말 맞다.

그런데 다시 생각해보자. 왜? 요구사항과 설계가 역전되어 새로 다시 모으고 만들어야 될까?

부끄러워 숨기고 싶겠지만, 바로 그 놈의 요구사항은 고객의 의도와는 전혀 다르게 수집하고,

고객이 원하는 모습과는 전혀 다른 모습으로 설계하고 있었던 것 아닌가?

여기에 유명한 그림이 있다. (http://onestone.tistory.com/entry/user-requirements)

왜 요구사항의 환상이라고 했을까? 환상? 아니다.

고객의 의도와 개발자의 한계 상의 조율이 전혀 안된 것 뿐이라는 것이다.

일단, 고객에게 가장 중요한 것이 무엇인지 물어봐서, 최대 2주 내로 구현 가능한 모델을 만드는 것이다. 그리고 시연하고 보여준다. 다시 이야기한다. 다시 여기서 살을 붙이고 뼈를 잇는다. 여기서 중요한 것은 무조건 고객에게 모든 것을 다 주는 것은 아니다. 고객도 희생이 필요하다. 당신들이 원하는 것은 이정도 크기의 프로젝트다! 그러면 모든 것을 들어주는데는 10년이 걸리고 10억이 필요하다! 그렇게 하고 싶지 않으면 어떻게 할까? 이제 고객의 욕심을 줄이는 시점이 오는 것이다. 이건 있으면 좋겠지만, 꼭 필요한 것이 아니면 없앨 수 있는 계기를 만들어주는 작업을 하는 것이다. 비용과 기간을 고객의 요구사항과 저울질을 하는 것이다. 그리고 여과 없이 보여준다.

이게 바로 핵심이지 않을까 싶다.

이를 위해서는 라이트한 조직으로 기존과는 전혀 다른 진행, 관리 방식이 요구된다.

이 부분에서 애자일에서는 다양한 방법들을 마치 방법론 처럼 보여줄 뿐이다.

우리나라의 소프트웨어 개발 환경에서는(애석하게도 외국의 다양한 사이트에서는 이미 많은 성공 사례들이 발표되고 있고, 큰 개발 조직 같은 경우에서도 시도하고 있으며 이미 발전 단계에 이르렀다) 마치 환상 같아 보이기만 하지만, 이런 환경을 구성하여 진행하는 곳에 꼭 참여해보고 싶다.

당분간은 이런 환경 접하기는 어려워 보이고, 스스로 만들 용기나, 힘도 부족하니 당분간은 책을 통해서 생각이나 정리하면서 지식 DDR나 하면서 공상이나 해야 겠다.