GPT를 통해  온라인 카지노의 흑역사와 , 관련 법규를 문의해보았습니다.

GPT

홀덤과 오마하 세븐카드의 차이점에 대해 간략하게 알려죠

홀덤 (Texas Hold'em)과 오마하 (Omaha) 그리고 세븐카드 스터드 (Seven-Card Stud)는 모두 인기 있는 포커 게임의 변형이지만 규칙과 게임 방식에서 몇 가지 핵심 차이점이 있습니다. 아래에 각 게임의 주요 차이점을 간략하게 요약합니다:

1. 홀덤 (Texas Hold'em):

   • 카드 분배: 각 플레이어에게 2장의 개인 카드 (포켓 카드)가 숨겨서 분배됩니다.
   • 공용 카드: 게임의 진행 과정에서 총 5장의 공용 카드가 테이블 중앙에 공개됩니다 (플롭 3장, 턴 1장, 리버 1장).
   • 최종 손: 플레이어는 자신의 2장의 포켓 카드와 5장의 공용 카드 중 5장의 최적의 조합을 사용하여 최종 손을 만듭니다.

2. 오마하 (Omaha):

   • 카드 분배: 각 플레이어에게 4장의 개인 카드가 숨겨서 분배됩니다.
   • 공용 카드: 홀덤과 마찬가지로 5장의 공용 카드가 테이블 중앙에 공개됩니다.
   • 최종 손: 플레이어는 자신의 4장의 포켓 카드 중 정확히 2장과 공용 카드 중 3장을 사용하여 최종 손을 만들어야 합니다.

3. 세븐카드 스터드 (Seven-Card Stud):

   • 카드 분배: 게임 시작시 각 플레이어에게 3장의 카드가 분배됩니다. 이 중 2장은 숨겨진 상태이고 1장은 공개됩니다.
   • 공용 카드: 세븐카드 스터드에는 홀덤이나 오마하와 같은 중앙의 공용 카드가 없습니다. 대신 각 플레이어에게 추가 카드가 순차적으로 분배됩니다. 총 7장의 카드 중 4장은 공개되고, 3장은 숨겨진 상태입니다.
   • 최종 손: 각 플레이어는 7장의 카드 중 최적의 5장의 조합을 사용하여 최종 손을 만듭니다.

이 세 게임은 모두 전략, 기술, 그리고 운이 중요한 역할을 합니다. 각 게임마다 고유한 전략과 접근 방식이 필요하기 때문에 플레이어는 그 차이점을 잘 이해하고 있어야 합니다.

온라인 포커 시장의 규모를 리얼머니 소셜머니로 구분하여 요약해죠

1. 리얼 머니 포커 (Real Money Poker):

   • 규모: 전 세계적으로 수십억 달러의 시장 가치를 가지고 있습니다. 일부 주요 국가들에서는 온라인 도박이 합법화되어 있기 때문에 큰 규모의 시장을 차지하고 있습니다.
   • 운영: 리얼 머니 포커 사이트는 플레이어들이 실제 돈으로 게임을 하는 곳입니다. 이런 사이트들은 주로 라이선스를 받아 규제를 받는 국가에서 운영됩니다.
   • 모델: 이 사이트들은 대게 '레이크'라는 시스템을 사용하여 수익을 창출합니다. 레이크는 포커 핸드에서 집게임으로 가져가는 작은 비율의 금액을 의미합니다.

2. 소셜 머니 포커 (Social Money Poker):

   • 규모: 리얼 머니 포커보다는 작지만, 여전히 큰 규모의 시장을 차지하고 있습니다. 소셜 미디어 플랫폼과 모바일 게임 시장의 성장에 따라 이 시장도 계속해서 성장하고 있습니다.
   • 운영: 플레이어들은 실제 돈을 사용하지 않고 가상의 통화나 칩을 사용하여 게임을 합니다. 이러한 게임은 대개 학습, 오락, 혹은 사교적 목적으로 플레이됩니다.
   • 모델: 이런 게임들은 다양한 방법으로 수익을 창출합니다. 일부는 광고를 통해 수익을 얻으며, 다른 일부는 플레이어가 더 많은 칩이나 아이템을 사기 위해 실제 돈을 지출하도록 유도합니다.

두 시장 모두 지속적으로 성장하고 있으나, 각각 다른 정책, 규제, 경제 모델로 운영됩니다. 따라서 투자나 사업 전략을 수립할 때 이러한 차이점을 고려해야 합니다.

라스베가스 도박법과 온라인포커

세계 최초 온라인 포커게임이 합법화된 서비스를 정리해서 요약해죠

세계 최초의 온라인 포커게임이 합법화된 서비스에 대한 정확한 정보를 제공하기 위해선 특정 국가나 시기, 그리고 법률적 상황에 대한 자세한 내용이 필요합니다. 그러나 제가 알고 있는 지식을 기반으로 일반적인 정보를 제공하겠습니다.

온라인 포커 및 다른 도박 서비스는 1990년대 말에서 2000년대 초반에 인터넷이 대중화되면서 등장하기 시작했습니다. 1998년, "플래닛 포커"는 세계 최초의 리얼 머니를 이용한 온라인 포커 사이트로 선보였습니다.

2000년대 초반, 온라인 포커는 크게 인기를 얻기 시작했고, 여러 국가에서는 이를 규제하거나 금지하기 시작했습니다. 일부 국가에서는 온라인 도박의 합법화를 위한 노력이 계속되었고, 국가별로 다양한 법률과 규제가 적용되었습니다.

예를 들면, 영국에서는 2005년 도박법이 시행되면서 온라인 포커 및 다른 도박 서비스가 합법화되었습니다. 이 법은 온라인 도박 사업자들에게 국가에서 허가를 받아 운영할 수 있게 했습니다.

하지만, 미국 같은 경우 2006년 '불법 인터넷 도박 집행법'(UIGEA)이 시행되면서, 대부분의 온라인 포커 사이트가 미국 시장에서 제외되었습니다. 그 이후에도 몇몇 주에서는 온라인 포커를 합법화하는 움직임이 있었습니다.

요약하면, 온라인 포커게임의 합법화는 국가별, 지역별로 다르며, 그 과정과 결과 역시 다양합니다. 특정 서비스나 국가에 관한 더 구체적인 정보를 원하신다면 추가로 알려주시면 도움드리겠습니다.

미국 라스베가스를 기준으로 알려죠

미국의 라스베가스는 전 세계에서 가장 유명한 도박 도시 중 하나로, 네바다 주에 위치하고 있습니다. 온라인 포커 및 도박 관련 법률은 주별로 다르게 적용되기 때문에, 라스베가스에 해당하는 네바다 주의 법률 및 상황에 대해 설명하겠습니다.

1. 네바다의 온라인 포커 합법화: 네바다 주는 2013년에 온라인 포커를 합법화하였습니다. 이로써, 주 내에서 온라인 포커를 합법적으로 운영하고자 하는 기업들은 주 정부로부터 허가를 받아 운영하게 되었습니다.

2. 라이센스 및 규제: 온라인 포커 운영을 희망하는 기업은 네바다 주 도박위원회와 네바다 주 게임 관리위원회로부터 라이센스를 받아야 합니다. 이 두 기관은 라스베가스의 랜드 베이스 카지노들도 감독하는 주요 기관입니다.

3. 다른 주와의 계약: 2013년 합법화 이후, 네바다 주는 다른 주와 "주간 포커 플레이"를 위한 협약을 맺을 수 있게 되었습니다. 예를 들어, 2014년에 네바다와 델라웨어 주는 온라인 포커를 위한 파트너십 계약을 체결했습니다.

4. 현재 상황: 합법화 초기에는 여러 기업들이 온라인 포커 시장에 진입하려 했으나, 시장의 크기와 경쟁력, 그리고 규제 등 여러 이유로 현재는 몇몇 주요 기업들만이 네바다 주에서 온라인 포커 서비스를 제공하고 있습니다.

요약하자면, 라스베가스가 속한 네바다 주에서는 2013년에 온라인 포커를 합법화했고, 주 정부의 감독 아래 몇몇 기업들이 온라인 포커 서비스를 제공하고 있습니다.

2013년 네바다주로 부터 라이센스를 받은 온라인 포커를 순서대로 알려죠

2013년 네바다 주에서 온라인 포커 라이센스를 받은 몇몇 주요 기업들이 있습니다. 이 중에서 가장 눈에 띄는 몇몇 기업들을 아래에 나열하겠습니다:

1. WSOP.com (World Series of Poker): WSOP는 전 세계에서 가장 큰 포커 토너먼트 브랜드 중 하나로, Caesars Interactive Entertainment의 소유입니다. 2013년에 네바다에서 온라인 포커 서비스를 시작했으며, 이후 델라웨어와 뉴저지 주에서도 서비스를 확장했습니다.

2. Ultimate Poker: Ultimate Poker는 2013년에 온라인 포커를 제공하기 시작한 첫 번째 회사였습니다. 그러나 경쟁력 부족 및 기타 이유로 2014년에 운영을 중단했습니다.

3. Real Gaming: 이 회사는 South Point Hotel, Casino & Spa에 소속된 온라인 포커 사이트로 2014년 초에 출시되었지만, 2013년에 라이센스를 받았습니다. 그러나 마찬가지로 시장에서의 경쟁력을 유지하지 못해 활동이 줄어들었습니다.

이 외에도 몇몇 기업들이 온라인 포커 라이센스를 받았으나, 시장의 경쟁력, 규제, 기타 여러 이유로 서비스 제공을 지속하지 않았거나 그 영향력이 크게 줄어들었습니다.

온라인 포커 시장은 지속적으로 변화하고 있기 때문에, 최신 정보나 구체적인 라이센스 상황에 대해서는 네바다 주 도박위원회나 게임 관리위원회의 공식 웹사이트 등에서 확인하는 것이 좋습니다.

Ultimate Poker 운영중단이 아닌 Absolute Poker와 통합된것으로 알고 있는데 통합이슈에 대해 알려죠

죄송합니다, 제가 이전 응답에서 헷갈린 부분이 있습니다. 감사합니다, 지적해 주셔서.

Absolute Poker와 Ultimate Poker는 전혀 다른 기업입니다. 둘 사이에는 직접적인 관계나 통합 이슈가 없습니다.

1. Absolute Poker:

   • 2000년대 중반에 설립된 온라인 포커 사이트 중 하나입니다.
   • Absolute Poker는 2011년 "블랙 프라이데이"라 불리는 사건에서 미국 정부에 의해 기소되었습니다. 이 사건은 미국에서 크게 활동하던 여러 온라인 포커 사이트들이 불법 온라인 도박 및 금융 사기 혐의로 기소되었던 사건입니다.
   • Absolute Poker는 이후 운영을 중단하게 되었고, 플레이어들의 자금도 약간의 문제가 발생했었습니다.

2. Ultimate Poker:

   • Ultimate Poker는 미국의 네바다 주에서 합법적으로 운영된 첫 온라인 포커 사이트로, 2013년에 서비스를 시작했습니다.
   • 그러나 2014년에 운영을 중단했고, 이는 시장 점유율, 경쟁, 기술적 문제 등 여러 가지 이유로 인한 것으로 알려져 있습니다.

즉, 두 회사 사이에는 직접적인 통합이나 연계가 없으며, 각각 별도의 역사와 배경을 가지고 있습니다.

그러면 Cereus Poker Network 에 대해 알려죠

• 이 프롬프트를 할수 있었던것은 AP←UB 로 인수되었고 통합후 Cereus Poker Network가 된점을 알고 있었기에 다시 문의를 하였습니다.

1. 기업 구성: Cereus Poker Network는 주로 두 대표적인 온라인 포커 사이트, Absolute Poker와 Ultimate Bet (또는 UB)를 포함하고 있었습니다.

2. 블랙 프라이데이: 2011년 4월 15일, 미국 법무부는 Absolute Poker, Ultimate Bet, PokerStars, 그리고 Full Tilt Poker에 대한 기소를 시작하였습니다. 이날을 "블랙 프라이데이"라 부르며, 이 사건은 미국의 온라인 포커 산업에 큰 타격을 주었습니다. Cereus Network에 속한 Absolute Poker와 Ultimate Bet도 이 사건의 영향을 크게 받았습니다.

3. 금융적 문제: 블랙 프라이데이 이후, Cereus Network의 사이트들은 금융적 어려움을 겪게 되었습니다. 많은 플레이어들의 자금이 사이트에 얼어버렸고, 이로 인해 큰 논란이 발생하였습니다.

4. 통합과 종료: 2008년경, Absolute Poker와 Ultimate Bet는 Cereus Poker Network의 일부로 통합되었습니다. 하지만 2011년의 블랙 프라이데이 이후, 그들의 사업은 기본적으로 종료되었습니다.

5. 스캔들: Cereus Network와 관련된 사이트들은 블랙 프라이데이 이전에도 여러 스캔들에 연루되었습니다. 특히, 2008년에 Ultimate Bet에서는 몇몇 플레이어가 부정한 방법으로 게임을 조작했다는 주장이 제기되었고, 이로 인해 큰 논란이 발생하였습니다.

결론적으로, Cereus Poker Network는 온라인 포커 역사에서 높은 인기와 큰 논란 모두를 경험한 네트워크였습니다.

블랙프라이데이로 인해 사용자가 찾지 못한 돈을 청구하기 위해 미정부가 했던 노력에대해 알려죠

"Cereus Poker Network"은 "Absolute Poker"과 "UltimateBet" 두 주요 포커 사이트를 운영하던 네트워크였습니다. 이 네트워크는 "Black Friday"라고 불리는 2011년 4월 15일의 미국 법무부의 큰 규모의 기소와 함께 여러 온라인 포커 사이트와 같은 운명을 맞이하게 되었습니다.

Black Friday 이후, 미국 법무부는 Full Tilt Poker, PokerStars, 그리고 Cereus Network와 관련된 자금을 환수하고 미국의 플레이어들에게 반환하기 위한 여러 노력을 했습니다.

1. PokerStars 합의: PokerStars는 미국 법무부와의 합의의 일환으로 Full Tilt Poker의 플레이어들에게 반환되어야 할 자금을 환불하는 데 도움을 주었습니다. 이 합의는 PokerStars가 Full Tilt Poker의 자산을 인수하는 데 중요한 역할을 했습니다.

2. Cereus Network의 문제: 비록 PokerStars와 Full Tilt Poker의 플레이어들에게 돌려줄 자금이 확보되었지만, Cereus Network의 플레이어들은 그러한 행운을 누리지 못했습니다. 이 네트워크는 광고와 운영에 대한 과거의 문제로 인해 많은 금액의 부채를 가지고 있었습니다.

3. 환불 프로세스: 여러 해에 걸쳐 미국 법무부는 Garden City Group라는 회사와 함께 Absolute Poker와 UltimateBet의 플레이어들에게 환불 프로세스를 진행하였습니다. 이는 2017년에 시작되었으며, 미국 내에서 게임을 했던 플레이어들이 자신의 잔고에 대한 청구를 제출할 수 있게 되었습니다.

4. 환불된 금액: 비록 모든 플레이어가 그들의 자금 전액을 되돌려받지는 못했지만, 수백만 달러가 환불되었으며, 이는 Cereus Network의 플레이어들에게 어느 정도의 구제를 제공하였습니다.

Black Friday 이후 미국 법무부의 노력 덕분에 많은 포커 플레이어들이 그들의 자금을 환수할 수 있었습니다. 그러나 이 과정은 많은 시간이 걸렸으며, 일부 플레이어들은 자금의 일부만 되돌려 받았습니다.

Bodog Poker에 대해서도 요약해죠

Bodog Poker는 온라인 도박 및 엔터테인먼트 산업에서 오랜 역사를 가진 브랜드입니다. 다음은 Bodog Poker에 대한 주요 정보를 요약한 내용입니다:

1. 설립: Bodog는 1994년에 엔트리프리놀러 칼빈 아이어 (Calvin Ayre)에 의해 설립되었습니다.

2. 다양한 서비스: Bodog는 원래 스포츠 베팅 사이트로 시작되었지만, 시간이 지남에 따라 온라인 카지노, 포커, 그리고 말 경주 베팅과 같은 다양한 도박 서비스를 추가하게 되었습니다.

3. 온라인 포커: Bodog Poker는 온라인 포커 플레이어들 사이에서 널리 알려져 있으며, 그들의 소프트웨어는 사용자 친화적이며 플레이어 대 플레이어 경쟁을 중점으로 하고 있습니다.

4. 브랜드 확장: Bodog 브랜드는 시간이 지남에 따라 여러 지역에 라이선스를 부여하며 확장되었습니다. Bovada라는 이름으로 미국 시장에 재진입하기도 했고, 여러 다른 국가에서도 Bodog와 관련된 서비스를 제공하기도 했습니다.

5. 규제 문제: Bodog는 미국과의 법적 문제를 겪기도 했습니다. 2012년, 칼빈 아이어는 미국 정부에 의해 불법 온라인 도박 혐의로 기소되었습니다. 그러나 이후에도 Bodog는 다른 지역에서의 활동을 지속하였습니다.

6. 업계 영향: Bodog는 온라인 도박 산업에서 많은 혁신과 마케팅 전략으로 이름을 알렸습니다. 특히, 칼빈 아이어의 개성적인 리더십과 브랜드의 독특한 이미지는 Bodog를 독특하게 만들었습니다.

요약하면, Bodog는 온라인 도박 산업에서 주요한 역할을 한 브랜드 중 하나로, 스포츠 베팅부터 포커까지 다양한 게임을 제공하는 글로벌 브랜드로 자리잡았습니다.

Calvin Ayre란 인물에 대해 요약해죠

Calvin Ayre는 온라인 게임과 스포츠 베팅 산업의 대표적인 인물 중 하나로, 특히 Bodog 브랜드의 창립자로 잘 알려져 있습니다. 아래는 Calvin Ayre에 대한 요약입니다:

1. 기업가: Calvin Ayre는 1961년에 캐나다에서 태어났으며, 1990년대 중반에 온라인 게임 산업을 선도하는 Bodog 브랜드를 창립했습니다.

2. Bodog: 이 회사는 온라인 카지노, 포커, 스포츠 베팅 등 다양한 게임 제품을 제공하며, 그의 리더십 하에 급속히 성장하여 세계적으로 인정받는 브랜드가 되었습니다.

3. 방대한 재산: Bodog의 성공으로 인해 Calvin Ayre는 억만장자가 되었으며, 그의 재산과 성과는 여러 경제 매체에서도 자주 언급되었습니다.

4. 이슈와 논란: 그는 미국 정부와의 법적 분쟁, 특히 불법 온라인 도박에 관련된 기소와 같은 여러 논란에 연루되었습니다. 그러나 2017년, 미국 정부와 합의를 이루어 기소가 철회되었습니다.

5. 비트코인: Ayre는 비트코인 캐시 (BCH, 현재 Bitcoin Cash라고 불리는 분기체)의 주요 지지자 중 하나로 알려져 있습니다. 그는 비트코인의 발전에 큰 관심을 보이며, 특히 Bitcoin Cash 캠프에서 중요한 역할을 하고 있습니다.

6. 은퇴: Calvin Ayre는 2000년대 후반에 Bodog를 떠나긴 했지만, 그 후에도 다양한 사업과 투자 활동을 계속하고 있습니다.

Ayre는 그의 성공적인 경력, 과감한 사업 전략, 그리고 때때로 논란의 중심에 서기도 한 그의 인생 스토리로 인해 게임 산업 내에서 높은 인지도를 갖고 있습니다.

Bodog Poker 가 후원한 스포츠 리그에대해서도 알려죠

Bodog는 그들의 브랜딩과 마케팅 전략의 일환으로 다양한 스포츠 리그와 팀을 후원하였습니다. Bodog의 창립자인 칼빈 아이어는 특히 마케팅과 브랜딩에 큰 중점을 두었기 때문에, 다양한 스포츠와 엔터테인먼트 이벤트를 통해 그들의 브랜드 인지도를 높이는 데 큰 투자를 하였습니다.

Bodog가 후원하였거나 연계되었던 주요 스포츠 리그 및 이벤트는 다음과 같습니다:

1. MMA (혼합 격투기): Bodog는 MMA와 밀접한 연관을 가지고 있었으며, 그들 자체의 MMA 프로모션인 'Bodog Fight'를 운영하기도 했습니다. 여러 격투기 선수들이 이 리그에서 경기를 펼쳤습니다.

2. 축구: Bodog는 영국의 몇몇 축구 클럽을 후원하기도 했습니다. 예를 들어, 아일랜드의 프리미어 리그 축구 클럽인 West Bromwich Albion FC를 2011-2012 시즌 동안 주요 후원사로서 지원했습니다.

3. 캐나다 하키 리그: Bodog는 과거 캐나다의 주요 하키 리그인 WHL, OHL, 그리고 QMJHL을 후원하기도 했습니다.

이 외에도 Bodog는 다양한 스포츠 팀 및 이벤트에 후원을 하거나 연계되었을 수 있습니다. 그러나 위에 언급한 것들은 Bodog의 후원 활동 중 주요한 것들로 기억됩니다.

PokerStars에 대해서도 요약해죠

물론이죠! PokerStars는 세계에서 가장 큰 온라인 포커 사이트 중 하나로 알려져 있습니다. 아래는 PokerStars에 관한 요약입니다:

1. 창립: PokerStars는 2001년에 아일 오브 맨에 기반을 둔 Rational Group에 의해 설립되었습니다.

2. 크게 성장: PokerStars는 2000년대 초반의 포커 붐 기간 중 온라인 포커의 선두 주자로 급부상했습니다. 특히 2003년 WSOP (World Series of Poker) 메인 이벤트에서 PokerStars 플레이어인 Chris Moneymaker가 우승하면서 그 인기는 더욱 상승했습니다.

3. 대회와 이벤트: PokerStars는 다양한 온라인 포커 대회와 프로모션을 제공하며, 많은 프로 포커 플레이어들이 이 사이트의 후원자로 활동합니다.

4. Black Friday: 2011년, 미국 법무부는 PokerStars와 여러 다른 온라인 포커 사이트를 대상으로 큰 규모의 기소를 발표했습니다. 이 사건을 "Black Friday"라고 불리며, 이후 PokerStars는 미국 시장에서 일시적으로 철수하게 되었습니다.

5. 인수: 2014년, Amaya Gaming (나중에 The Stars Group으로 이름이 변경됨)는 PokerStars와 Full Tilt Poker를 인수하였습니다. 2019년에는 Flutter Entertainment가 The Stars Group을 인수하였습니다.

6. 글로벌 리더: 지금까지도, PokerStars는 세계에서 가장 인기 있는 온라인 포커 사이트 중 하나로 남아 있으며, 수백만 사용자들에게 포커 게임을 제공하고 있습니다.

7. 확장: PokerStars는 오직 포커만 제공하는 것이 아닙니다. 시간이 흘러가며, 카지노 게임과 스포츠 베팅 제품 라인도 추가하게 되었습니다.

PokerStars는 온라인 포커 산업의 대표적인 브랜드로, 그 역사와 성장, 그리고 시장에서의 지속적인 성공으로 인해 전세계에서 많은 인기를 누리고 있습니다.

'Virtual Gaming Worlds' 라는 기업이 제공하는 포커게임에 대해서도 알려죠

Virtual Gaming Worlds (VGW)는 온라인 게임 산업에서 큰 주목을 받는 회사 중 하나로, 소셜 카지노 게임과 스윕스테이크 기반의 온라인 도박 플랫폼을 운영합니다. VGW는 Laurence Escalante에 의해 2010년에 호주에서 창립되었습니다.

Chumba Casino와 Global Poker는 VGW의 두 가지 주요 브랜드 중 일부입니다.

1. Chumba Casino: 이는 소셜 카지노 플랫폼으로, 사용자들이 다양한 슬롯 게임과 테이블 게임을 즐길 수 있습니다. VGW는 스윕스테이크 모델을 사용하여, 일부 지역에서는 실제 돈으로 게임을 할 수 없는 문제를 해결합니다. 즉, 사용자들은 "골드 코인"으로 게임을 할 수 있고, 이를 통해 "스윕스 캐시"를 얻을 수 있는데, 이 "스윕스 캐시"는 실제 돈으로 교환될 수 있습니다.

2. Global Poker: 이는 VGW의 온라인 포커 플랫폼입니다. 이 역시 스윕스테이크 모델을 기반으로 하며, 사용자들은 가상 화폐인 "골드 코인"을 구매하고, 이를 사용하여 포커 게임을 즐길 수 있습니다. 구매 시, 사용자들은 "스윕스 캐시"도 함께 받게 되며, 이것은 실제 현금으로 교환될 수 있습니다.

VGW의 플랫폼은 특히 미국에서 인기를 얻었습니다. 이는 미국 내에서의 온라인 도박 법률이 제한적인 데 반해, VGW의 스윕스테이크 모델이 이러한 법적 장벽을 우회할 수 있기 때문입니다.

이 외에도 VGW는 다양한 온라인 게임과 플랫폼을 지속적으로 개발하고 있습니다. 그들의 서비스는 그들의 웹사이트나 연관된 플랫폼에서 확인할 수 있습니다.

VGW의 스윕스테이크 모델이 미국 온라인 도박 법률에 불법이 아닌것에 대해 조금더 구체적으로 설명해죠

1. 구매 기반의 게임과 보너스: VGW의 플랫폼에서, 사용자들은 "골드 코인"과 같은 가상 화폐를 구매할 수 있습니다. 이 가상 화폐는 실제 돈으로 교환될 수 없으며, 오로지 엔터테인먼트 목적으로만 사용됩니다. 그러나 이러한 구매를 할 때, 사용자들은 "스윕스 캐시"와 같은 보너스를 받게 되는데, 이 보너스는 실제 돈으로 교환될 수 있습니다.

2. 무료 참여 방법: 스윕스테이크 법률에 따르면, 참여자들에게 무료로 참여할 방법이 제공되어야 합니다. VGW는 이러한 요구사항을 충족하기 위해 사용자들이 무료로 스윕스테이크에 참여할 수 있는 방법을 제공합니다.

3. 돈의 가치: 사용자들이 "골드 코인"을 구매할 때, 그들은 실제로 엔터테인먼트 상품을 구매하는 것이며, 도박을 하는 것이 아닙니다. 이는 법적으로 중요한 구분이며, 이러한 구분을 통해 VGW는 미국의 도박 법률을 우회할 수 있습니다.

미국에서 스윕스테이크는 특정 기준을 충족하는 한 합법적입니다. VGW는 이러한 스윕스테이크 모델을 사용하여, 사용자들에게 실제 돈으로 게임을 할 수 있는 경험을 제공하면서도 미국의 복잡한 온라인 도박 법률을 준수하고 있습니다.

온라인 포커에서 주요 치팅사건을 알려죠

온라인 포커는 인기와 함께 여러 부정 행위 및 치팅 사건도 발생했습니다. 몇몇 주요 사건들을 아래에 요약하겠습니다:

1. UltimateBet "Superuser" 스캔들:

   • 2008년에 발생한 이 스캔들에서는 특정 계정들이 다른 플레이어의 카드를 볼 수 있는 "Superuser" 권한을 부정하게 획득한 것으로 밝혀졌습니다.
   • Russ Hamilton이 주요 용의자로 지목되었으며, 수백만 달러를 부정하게 획득했다고 알려졌습니다.
   • UltimateBet는 이 스캔들 이후 피해를 입은 플레이어들에게 상당한 금액을 환불하였습니다.

2. Absolute Poker 스캔들:

   • 이 사건도 "Superuser" 관련 스캔들로, 특정 플레이어가 다른 사람들의 홀 카드를 볼 수 있었다는 의혹이 제기되었습니다.
   • 사건이 폭로된 후 Absolute Poker는 내부 조사를 진행하였으며, 특정 내부 직원이 부정 행위를 저질렀다고 밝혔습니다.

3. PokerSpot 결제 문제:

   • PokerSpot은 2000년에 결제 처리 문제로 인해 플레이어들의 출금 요청에 응하지 못했습니다.
   • 이 사건은 온라인 포커 사이트의 초기 규제 및 운영 문제를 반영하였습니다.

4. Full Tilt Poker 자금 부족:

   • "Black Friday" 이후, Full Tilt Poker는 플레이어의 자금을 운영 비용으로 사용했다는 의혹이 제기되었습니다.
   • 이로 인해 사이트는 라이선스를 잃었으며, PokerStars가 이를 인수하게 되면서 대부분의 플레이어들에게 자금이 환불되었습니다.

이러한 사건들은 온라인 포커 산업에 큰 영향을 미쳤으며, 더 엄격한 규제와 투명성이 요구되었습니다. 많은 온라인 포커 사이트들은 이러한 스캔들로 인해 그들의 운영 방식과 보안 조치를 개선하였습니다.

국내 도박법

대한민국의 도박법에 대해 설명해죠

1. 도박과 복표에 관한 처벌에 관한 법률: 대한민국에서는 도박 행위를 금지하고 있습니다. 이 법률에 따라 국내에서의 대부분의 도박 행위는 불법으로 간주됩니다. 법을 위반할 경우 벌금 또는 징역에 처해질 수 있습니다.

2. 예외: 그러나 일부 예외가 있습니다.

   • 복권: 정부에서 발행하는 복권은 합법적입니다. 예를 들어, 로또, TOTO, 경품복권 등이 있습니다.
   • 경마, 경륜, 경정: 이러한 경기에 대한 베팅은 특정 조건 하에 합법적입니다. 각각의 활동은 정부에 의해 통제 및 감독 받는 특정 장소에서만 합법적으로 진행됩니다.
   • 강원랜드: 대한민국에는 하나의 합법적인 카지노, 강원랜드가 있습니다. 이곳은 외국인 뿐만 아니라 한국인도 입장할 수 있습니다.

3. 온라인 도박: 대한민국 내에서 운영되는 온라인 도박 사이트는 불법입니다. 그러나 많은 한국인이 해외의 온라인 도박 사이트를 이용하는 경우가 있습니다. 정부는 이러한 해외 사이트 접속을 차단하려는 노력을 하고 있으며, 해외 도박 사이트 이용 시 처벌 받을 수 있습니다.

4. 도박 문제 개입: 대한민국에서는 도박 문제에 대한 인식이 높아지고 있습니다. 도박으로 인한 사회적 문제나 중독 문제를 예방하고 대응하기 위한 다양한 프로그램과 시설이 마련되어 있습니다.

위 내용은 대한민국의 도박법의 주요 사항에 대한 간략한 설명입니다. 법률은 시간이 지남에 따라 변경될 수 있으므로, 특정 사항에 대한 자세한 정보나 최신 도박법에 관한 정보가 필요하시면 전문가의 조언을 구하거나 관련 공식 사이트 등을 참조하시는 것이 좋습니다.

외국에서 합법적인 국가에서 도박장을 설치하고 운영하는경우 대한민국 도박법에 위배가 될까요?

외국에서 합법적으로 도박장을 설치하고 운영하는 행위 자체는 대한민국의 도박법에 위반되지 않습니다. 각 국가는 자신의 영토 내에서 도박에 관한 법률과 규정을 가지고 있으므로, 해당 국가의 법률을 준수하면서 운영한다면 대한민국의 법률에는 직접적인 영향을 받지 않습니다.

그러나 몇 가지 주의해야 할 사항이 있습니다:

1. 해외 도박 사이트의 이용: 대한민국 국민이 외국의 온라인 도박 사이트를 이용할 경우, 이는 대한민국의 도박법에 위반될 수 있습니다. 즉, 외국에서 합법적으로 운영되는 도박 사이트라도 대한민국 국민이 그 사이트를 이용하는 것은 불법으로 간주될 수 있습니다.

2. 광고 및 홍보: 대한민국 내에서 외국 도박장 또는 도박 사이트에 대한 광고나 홍보를 진행할 경우, 이 역시 법적 제재의 대상이 될 수 있습니다.

3. 자금 송금: 대한민국에서 외국 도박 사이트나 도박장에 자금을 송금하거나, 그곳에서 수익을 얻어 국내로 돈을 송금하는 행위는 금융당국의 감시를 받을 수 있습니다.

이러한 사항들을 고려하여, 외국에서 도박장을 설치하고 운영할 경우에도 대한민국과의 관계에서 주의가 필요합니다.

대한민국 도박개장죄 에 의하면 도박에 장소를 개설 제공하는것 역시 불법으로 규정하고 있는데 해외에 도박장을 개설하고 운영하면 해당국가에서 합법이라 할지라도 불법이 아닌가요?

동일 프롬프트에 해석이 A/B 로 나뉘어 두개를 언급하였습니다.

답변 A 

죄송합니다. 맞습니다. 대한민국의 도박개장죄에 따르면 해외에 도박장을 개설하고 운영하는 대한민국 국민도 처벌의 대상이 될 수 있습니다.

대한민국의 도박법은 그 범위가 국내뿐만 아니라 해외에까지 확장됩니다. 이는 국내에서의 도박 행위뿐만 아니라 해외에서의 도박 행위까지도 처벌의 대상으로 포함하고 있습니다. 따라서 대한민국 국민이 해외에서 도박장을 개설하고 운영할 경우, 해당 국가에서 합법적으로 운영되더라도 대한민국의 법에 따라 처벌받을 위험이 있습니다.

결론적으로, 대한민국 국민이 해외에서 도박장을 개설하고 운영하려 할 때에는 대한민국의 도박법에 대한 깊은 이해와 함께 법적 조언을 구하는 것이 매우 중요합니다.

답변 B

정확하게 말하자면, 대한민국의 형법에 따르면 "도박개장죄"는 국내에서의 도박장 개설을 규정하는 것이 주된 내용입니다. 그러나, 해외에서의 도박 사업과 관련하여 복잡한 법적 문제가 발생할 수 있습니다.

대한민국의 형법 제246조는 도박개장죄를 규정하며, 도박에 장소를 제공하거나 도박에 필요한 물건을 제공하는 행위를 처벌합니다. 이는 주로 국내에서의 불법 도박 행위를 억제하기 위한 조항입니다.

해외에서의 도박 사업 운영과 관련해서는, 대한민국 국민이나 기업이 해당 해외 국가에서 합법적으로 도박 사업을 운영하는 것 자체는 현재까지의 법률 해석 상 "도박개장죄"에 직접적으로 위배되는 것은 아닙니다. 그러나, 이는 법적 해석의 여지가 있으며, 특히 해당 도박 사업이 대한민국 국민을 대상으로 한다면 더욱 복잡한 문제가 될 수 있습니다.

실제로, 대한민국 국민이나 기업이 해외에서 도박 사업을 운영하는 경우에 대한 명확한 법률 해석이나 판례는 제한적입니다. 그렇기 때문에, 이와 관련하여 사업 활동을 계획하거나 진행하는 경우, 전문가의 조언을 구하는 것이 중요합니다.

결론적으로, 해외에서 합법적으로 도박 사업을 운영하는 것이 대한민국의 "도박개장죄"에 위배되는지 여부는 복잡한 법률 문제이므로, 전문가와 상의하는 것이 바람직합니다.

도박장개장죄의 적용 범위에대해 답변이 상이해 프롬프트를 한번더 시도하였습니다.

대한민국 의 '도박개장죄' 가 국내에만 적용된다는 근거는 어디서 찾을수 있습니까?

대한민국의 '도박개장죄'는 형법 제246조에 규정되어 있습니다. 해당 조항은 다음과 같이 규정하고 있습니다:

제246조 (도박개장죄)

1. 도박 또는 복표에 장소를 개설하거나 이를 대여하거나 제공한 자는 3년 이하의 징역 또는 금고에 처한다.
2. 도박 또는 복표에 관한 물건을 제공한 자도 제1항과 같다.

이 조항은 도박장의 개설이나 도박에 필요한 물건 제공에 대한 처벌을 규정하고 있습니다. 그러나, 이 조항 자체에서는 그 적용 지역을 명시적으로 규정하고 있지 않습니다.

그러나 형법의 적용 범위는 대한민국 형법 제3조에 따라 규정됩니다:

제3조 (법률의 활용범위)

1. 대한민국의 영토 내에서 행한 행위에 대하여는 이 법률을 적용한다.
2. 대한민국의 영토 외에서 우리나라의 국민이 행한 행위에 대하여는 그 행위가 우리나라에서 행한 것인 것으로 보아 이 법률을 적용한다.

제3조의 규정에 따라, 대한민국 영토 내에서 행해진 행위는 대한민국 형법을 적용받습니다. 따라서, '도박개장죄'는 기본적으로 대한민국 내에서 도박장을 개설하거나 도박에 필요한 물건을 제공한 경우에 적용됩니다.

제3조 제2항은 대한민국 국민이 국외에서 행한 행위에 대한 형법 적용을 규정하고 있지만, 이는 특정한 범죄(예: 국가반역죄, 외국인에 대한 살인죄 등)에 한하여 적용되는 내용입니다. '도박개장죄'에 해당하는 행위는 제2항에 의해 해외에서 이루어진 경우에 형법 적용을 받지 않습니다.

대한민국 온라인 도박에 대한 규제에 대해서도 요약해죠

대한민국에서는 온라인 도박에 대해 매우 엄격한 규제와 제제를 통해 관리하고 있습니다. 여기는 대한민국의 온라인 도박 규제에 관한 주요 사항을 요약한 내용입니다:

1. 불법 온라인 도박: 대한민국에서는 온라인 도박 사이트의 개설 및 운영이 금지되어 있습니다. 이로 인해 많은 온라인 도박 사이트가 해외 서버를 이용해 운영되며, 국내에서 이러한 해외 사이트에 접속하는 것 또한 불법으로 간주됩니다.

2. ISP 차단: 대한민국 정부는 불법 온라인 도박 사이트에 대한 접근을 차단하기 위해 ISP (인터넷 서비스 제공자) 차단을 실시하고 있습니다. 이를 통해 국민들이 해외의 불법 도박 사이트에 접속하는 것을 어렵게 만듭니다.

3. 처벌: 불법 온라인 도박 사이트의 운영자나 중개자는 심각한 처벌을 받게 됩니다. 또한, 국민이 불법 도박 사이트를 이용하는 경우에도 벌금 또는 징역 처벌을 받을 수 있습니다.

4. 예외 사항: 대한민국에서는 몇몇 합법적인 온라인 도박 서비스가 운영되고 있습니다. 이러한 서비스는 국가가 주관하거나 승인한 것으로, 스포츠토토나 복권 등의 서비스가 포함됩니다. 이러한 서비스 외의 온라인 도박은 모두 불법으로 간주됩니다.

5. 해외 도박 사이트 광고: 해외의 불법 도박 사이트를 광고하거나 홍보하는 행위 또한 불법으로 간주되며, 이에 대한 제재가 있습니다.

대한민국의 온라인 도박 규제는 다른 국가에 비해 매우 엄격하며, 국민과 기업 모두 이러한 법률과 규제를 준수해야 합니다. 온라인 도박과 관련된 활동을 계획하거나 참여하려는 경우, 대한민국의 법률을 철저히 숙지하고 이를 준수하는 것이 중요합니다.

도박개장죄와 온라인 도박법을 참고하여 라스베가스에 카지노 기기를 제작하여 납품하면 이것은 불법입니까?

1. 도박개장죄: 대한민국의 형법 제246조에 따르면, 도박에 장소를 제공하거나 도박에 필요한 물건을 제공하는 행위가 처벌의 대상이 됩니다. 하지만 이는 주로 국내에서의 도박과 관련된 행위에 대한 조항입니다.

2. 온라인 도박법: 대한민국에서는 온라인 도박에 대해 매우 엄격한 규제가 있습니다. 하지만 라스베가스에 카지노 기기를 제작하여 납품하는 것은 온라인 도박과 직접적인 연관이 없습니다.

라스베가스는 미국의 네바다 주에 위치하며, 네바다 주는 합법적으로 카지노 사업을 운영할 수 있는 주 중 하나입니다. 따라서 라스베가스의 카지노나 기타 도박 관련 기관에 카지노 기기를 제작하여 합법적으로 납품하는 것은 그 자체로 불법이 아닙니다.

하지만 대한민국 기업이나 개인이 해외로 카지노 기기를 수출할 때, 대한민국 내에서의 제조, 수출 허가, 관련 세금, 수출입 규정 등 다양한 법률과 규제를 준수해야 합니다.

결론적으로, 라스베가스의 합법적인 카지노에 카지노 기기를 제작하여 납품하는 것은 대한민국의 "도박개장죄"나 "온라인 도박법"에 위반되는 것은 아니나, 수출 과정에서의 다른 규제와 법률을 준수해야 합니다. 해당 사업 활동을 진행하기 전에 전문가나 관련 기관의 상담을 받는 것이 좋습니다.

카지노 기기를 제작하여, 기기만 국내 오락실에 납품하면 이것은 불법입니까?

대한민국에서 카지노 기기를 제작하여 국내 오락실에 납품하는 것이 불법인지 여부는 해당 기기의 특성과 용도에 따라 결정됩니다.

1. 도박성 기기: 만약 해당 기기가 도박성을 띄는 기기로, 플레이어가 돈을 걸고 결과에 따라 추가적인 돈이나 보상을 받을 수 있는 기능을 갖추고 있다면, 그 기기는 불법으로 간주될 수 있습니다. 이는 대한민국에서 도박을 규제하는 법률에 위반될 수 있습니다.

2. 일반 오락 기기: 반면 해당 기기가 순수하게 오락 목적으로만 사용되며, 도박성이나 금전적 보상이 없는 경우에는 법적으로 문제가 되지 않을 수 있습니다. 예를 들어, 전통적인 아케이드 게임 기기나 댄스 게임 기기와 같은 것들이 여기에 해당합니다.

3. 기기 인증: 일부 기기는 국내에서 판매나 납품하기 전에 관련 정부 기관에서의 인증 절차가 필요할 수 있습니다. 이는 해당 기기가 법적 기준에 부합하는지를 확인하기 위한 것입니다.

결론적으로, 카지노 기기를 제작하여 국내 오락실에 납품하려는 경우, 해당 기기의 특성과 기능, 그리고 관련 법률과 규제를 철저히 확인해야 합니다. 특히 도박성이나 금전적 보상과 관련된 기능이 포함된 기기의 경우 불법 여부를 확인하는 것이 중요합니다.

미국과 호주는 원주민 정복이라는 역사를 가지고 있으며 도박과 관련한 원주민 보호법에 대해 요약을 해주세요

미국과 호주는 원주민 정복의 역사를 가지고 있습니다. 이 두 나라는 이러한 역사를 통해 원주민들에게 다양한 사회, 경제적 문제가 발생했음을 인식하고 있습니다. 특히 도박 문제는 원주민 커뮤니티에서 주요한 걱정거리 중 하나로 여겨지며, 그 결과로 미국과 호주에서는 원주민들을 보호하기 위한 법률과 정책을 도입했습니다.

1. 미국의 원주민 보호법:

   • Indian Gaming Regulatory Act (IGRA): 1988년에 채택된 이 법은 원주민 부족의 주권을 인정하면서 도박사업을 규제합니다. 이 법은 원주민 부족의 경제적 자립을 지원하면서 도박의 부정적 영향을 제한하기 위해 설계되었습니다.
   • IGRA 하에 원주민 부족은 자신들의 땅에서 도박 사업을 운영할 수 있으나, 주와 협상을 거쳐 이루어져야 합니다. 이러한 규제는 원주민 커뮤니티 내에서 도박 관련 문제를 최소화하면서 도박 수입을 통해 부족의 경제적 발전을 도모하게 됩니다.

2. 호주의 원주민 보호법:

   • 호주에서는 원주민 커뮤니티 내에서 도박 문제의 심각성을 인식하고, 다양한 프로그램과 정책을 도입하여 문제를 해결하려고 노력하고 있습니다.
   • 주정부와 연방정부는 원주민들의 도박 문제를 해결하기 위한 다양한 지원 프로그램과 교육을 제공합니다.
   • 또한, 도박관련 조직 및 기관들은 원주민 커뮤니티를 대상으로 한 도박 문제에 대한 교육 및 치료 프로그램을 진행하고 있습니다.

미국과 호주는 원주민 커뮤니티의 도박 문제를 인식하고 이를 해결하기 위해 다양한 법률적, 정책적 노력을 기울이고 있습니다.

클로버X 

최근출시한 국내 GPT인 네이버 클로바X 를 통해 동일한 프롬프트를 시도해 보았습니다. 국내법에 대한 이해도도 GPT가 높은것으로 보여지며 클로버X의 경우 해당 주제로 대화를 이어나가지 못했습니다. 

국산 AI도 발전하기를 기원하면서 유사한 프롬프트로 시도된 응답내용도 함께 정리합니다.

세계 최초 온라인 포커게임이 합법화된 서비스를 정리해서 요약해죠

세계 최초로 온라인 포커게임이 합법화된 서비스에 대한 정확한 정보를 제공하기 어려운 상황입니다. 더 많은 조사를 진행하여 정확한 정보를 찾아드릴 수 있도록 최선을 다하겠습니다.이해해 주시기 바랍니다.

미국 라스베가스를 지역 기준으로 최초 온라인 포커게임이 합법화된 서비스를 정리해서 요약해죠

미국 라스베가스를 지역 기준으로 최초 온라인 포커게임이 합법화된 서비스에 대한 정보를 찾지 못했습니다.

포커 게임은 마인드 관리를 통해 실력을 겨루는 두뇌 스포츠로 알려져 있으며, 온라인 포커를 둘러싼 인기는 도박 업계에서 최근 급증한 현상 중 하나입니다. 포커 게임을 즐길 때는 게임의 규칙을 잘 숙지하고, 적절한 금액을 베팅하는 것이 중요합니다.

네바다주의 온라인 포커 라이센스에 대해 설명해죠

네바다주는 1931년 도박을 합법화하였으며, 포커를 포함한 모든 카지노 게임이 성층권으로 변모하려고 한 것으로 알려져 있습니다. 포커 게임을 즐길 때는 게임의 규칙을 잘 숙지하고, 적절한 금액을 베팅하는 것이 중요합니다.

Bodog Poker에 대해서도 요약해죠

Bodog Poker는 온라인 포커 게임 중 하나로, 캐나다의 온라인 도박 사이트인 Bodog에서 제공하는 서비스입니다.

Bodog Poker는 다양한 게임 모드와 높은 상금을 제공하며, 많은 포커 플레이어들에게 인기가 있습니다. 2008년부터 2010년까지 Justin Bonomo는 David Williams, Evelyn Ng 및 Jean-Robert Bellande와 함께 Bodog Poker 온라인 프로 팀의 일원으로 활동한 것으로 알려져 있습니다.

대한민국의 도박법에 대해 설명해죠

대한민국의 도박법은 형법 제246조에 따라 도박을 한 사람은 1,000만원 이하의 벌금 또는 과료에 처하며, 복표를 발매하거나 중개한 사람은 3년 이하의 징역 또는 3천만원 이하의 벌금에 처합니다.

도박은 2인 이상의 자 사이에 행하여지는 것이며, 당사자 전원이 재물득상의 위험을 부담하는 점에서 복표의 경우와 구별됩니다. 승패의 우연성은 당사자에 있어 주관적으로 불확실하면 족하고 객관적으로 불확실할 필요는 없으며 승패는 당사자 상호간에 전부 우연임을 요합니다.

브라질 사법당국은 확률형 아이템에 대해 본격적인 조사를 시작한 것으로 알려져 있으며, 현지 매체 '디 에너미'에 따르면 당국에 의해 확률형 아이템이 불법으로 인정될 경우 이러한 아이템을 판매하는 기업들에 최대 400만 헤알(약 7억 9,000만 원)의 벌금이 ‘매일’ 부과될 가능성도 있는 것으로 알려져 있습니다.

대한민국 도박개장죄 에 대한것도 알려죠

도박개장죄는 대한민국 형법상 범죄로, 재물로 도박을 하여 범해지는 죄입니다. 도박을 한 사람은 1,000만원 이하의 벌금 또는 과료에 처하며(형법 246조 1항), 도박장을 운영하거나 도박장에서 직업적으로 도박하는 사람은 도박사라고 불립니다.

도박개장죄는 5년 이하의 징역 또는 3천만원 이하의 벌금형이 기다리고 있으며, 불법 사행성 게임을 하면 업주는 도박개장죄, 손님은 도박죄로 처벌됩니다. 게임을 빙자한 도박행위는 형법 제246조(도박, 상습도박), 제247조(도박개장)에 의해 업주는 도박개장죄, 이용자는 도박죄로 처벌되어 왔고 지금도 계속해서 처벌을 하고 있습니다.

외국에서 합법적인 국가에서 도박장을 설치하고 운영하는경우 대한민국 도박법에 위배가 될까요?

외국에서 합법적인 국가에서 도박장을 설치하고 운영하는 경우 대한민국 도박법에 위배될 수 있습니다.

도박개장죄는 대한민국 형법상 범죄로, 재물로 도박을 하여 범해지는 죄입니다. 도박을 한 사람은 1,000만원 이하의 벌금 또는 과료에 처하며(형법 246조 1항), 도박장을 운영하거나 도박장에서 직업적으로 도박하는 사람은 도박사라고 불립니다. 도박개장죄는 5년 이하의 징역 또는 3천만원 이하의 벌금형이 기다리고 있으며, 불법 사행성 게임을 하면 업주는 도박개장죄, 손님은 도박죄로 처벌됩니다.

외국에서 도박장을 설치하고 운영하는 경우에도 대한민국 법에 따라 처벌될 수 있으므로, 이에 대한 자세한 법률적인 사항은 변호사나 법률 전문가에게 문의하시는 것이 좋습니다.

대한민국 온라인 도박 규제에 대해서도 알려죠

대한민국에서는 온라인 도박을 포함한 모든 도박 행위가 법적으로 금지되어 있으며, 이를 위반할 경우 형사 처벌을 받을 수 있습니다.

도박 행위를 범죄로 규정하고 있지 않은 타국의 합법적인 카지노에서 도박을 하는 경우에도 속인주의에 의해 처벌의 대상이 될 수 있으므로 주의가 필요합니다.

AI 성능요약 : GPT는 도박을 한사람과 도박을 개설한 것(도박개장죄)에 대한 국내형법을 이해하고 구분해서 응답하지만

클로버X는 이 둘을 구분을 하지 못하고 있으며 대한민국 형법에 기반한 문맥 전개가 안되며 또한 GPT의경우 질문을 통한 답변을 통해 새로운 인사이트를 계속 얻어가면서

새로운 질문으로 이어지는 반면 클로버X경우 2회이상 맥락연결이 안되는점이 아쉬웠습니다.

연관된 국내산업군의 역사

대한민국은 도박을 불법으로 규정하고 있으며 예외로 경마장/정선카지노/외국인전용 호텔카지노등 국가의 승인하에서만 운영될수 있습니다.

대한민국의 형법 제246조는 도박개장죄를 규정하며, 도박에 장소를 제공하거나 도박에 필요한 물건을 제공하는 행위를 처벌합니다. 

이것은 온라인및 해외에도 적용될수 있는것으로 다음 4가지 모두가 불법에 해당할수 있습니다.

• A - 해외 도박 사설사이트를 개발하고 불법인 국가에 운영됨
• B - 라스베가스 네바다주의 온라인도박 라이센스를 취득해 합법적 국가에 운영되는 온라인사이트를 개발함
• C - 라스베가스에 납품할 도박기기를 개발함
• D - 국내오락실에 납품할 바다이야기를 개발함

국내개발사가 네바다주의 온라인 도박 라이센스를 획득하였다고 해도 그것을 개발및 운영하는것이 합법인가 여부는 국내법으로 해석하기에는 한계가 있습니다.

네바다주가 오프라인/온라인이 모두 규정하는 법과 라이센스가 각각 있지만  국내법은 온라인과 오프라인을 구분하지 못해 법적 해석에 있어 모호함이 있습니다

네바다주 온라인 라이센스를 최초로 획득하고 운영한 기업이 Cereus_Poker_Network 이며  블랙프라이데이 이후 CereusPoker는 세금문제를 해결하지 못해 FBI에 의해 사이트가 닫혔지만

라이센스를 획득한 기술을 제공하는 회사가 국내개발사였다란 점은 잘 알려지지 않았으며 이 이야기를 국내사건 중심으로 다뤄보겠습니다.

CereusPokerNetwork 종료후~ 운영기업은 파산신청을 하였고 개발사 자체를 인수하려고 3개의 유명한 기업이 유사한시점  움직였습니다.

이해를 돕기위해 동시로 표현하지만 순서는 약간 차이가 있을수 있습니다.

• 시저스 팰리스(Caesars Palace) - 시저스 팰리스는 라스베가스에서 인기있는 호텔카지노로 , 온라인으로 확장하기위해 이 기업의 CEO가 전세기를 타고 긴급방문하였습니다.
• Bodog - 온라인 카지노를 엔터테이너먼트 영역으로 확장을 시킨 성공사례로 유명하며 기업의 브랜드보다 Calvin_Ayre 인물의  인지도가 더 높습니다.
• 넥슨 - 해외진출을 위해 이 분야의 글로벌 트래픽 TOP3까지 이미 경험했고 라이센스를 취득을 경험한 ,  개발사를 빠르게 인수하여 넥슨-Rushmo 로 출범했습니다.
  • 시저스 팰리스의 경우 납품형태가 아닌 내재화를 희망해 인수하기를 원했으나 넥슨 인수확정이 되었기때문에 철수 하였습니다.
  • Bodog도 개발사 인수를 원했으나~  빠르게 개발하여 납품하는 형태로 진행되었으며 짧은기간(약3개월) BodogPoker 개발및 런칭까지 진행되었습니다.
  • 넥슨을 통해 해당 산업군을 양지영역으로 끌어올리려는 노력을 하였으나 성공하지는 못했습니다.

넥슨 Rushmo의 행보

• Rushomo Poker -  세계최초 html5 플랫폼으로 페이스북에 소셜게임 런칭 ( 징가가 대세였던 시절)
• 페이스북의 게임영역 한국 철수
  • 여성부가 게임을 승인했던 암흑기 시절이였으며 셧다운제를 포함 페이스북 소셜게임 플랫폼영역 한국철수등 현재까지 중지된 상태로 한국 페북쇼셜게임의 몰락기를 맞이함

• 블록체인엔터테인먼트랩 - 원래 러시모(Rushmo)라는 이름의 게임회사였다.

  • Rushmo America, Inc

  • BodogPoker팀을 Bodog으로 매각하면서 낵슨이 최초 인수한 금액 이상의 수익을 냈을것으로 추정하며 그이후 소셜게임의 수익화에 실패하면서 블록체인으로 전환

Bodog행보

한국팀으로부터 BodogPoker가 성공을 이루자 Bodog은 해당 개발팀을 자사팀으로 인수하기를 원했습니다.

정확한 인수금액은 알려지지 않았으나 해당팀만 넥슨으로부터 독립하였으며 Poker를 포함  추가적인 사이트까지 개발해주기를 희망했습니다.

Bodog은  사업계열사와 개발계열사를 분리하여  TheworkShop 을 출범하였으며 한국개발사는 서울리전으로 합류하여 출범하였습니다.

대한민국 불법사이트 단속

2016년 검참은 불법 도박 사이트를 대대 단속하고 검거하던 해이자~ 최순실 게이트가 발생한 해이기도 합니다.

서울에 있는 개발사 글로벌 개발그룹으로 출범한지 한달채 안된상태에서 대한민국 검찰이 사설 불법도박 사이트로 규정을 하고 압수수색/운영중지 사태가 발생했습니다. 

재판은 5개월 동안 지속되었고 본사의 한국 법적대응 노력으로 최종 협의없음으로 마무리가 되었으나~ 이 사태로 보독은 서울리전으로부터 철수를 결정합니다.

다음은 보독이 온라인 카지노를 운행하기위해 받은 인증의 일부이며 사용자의 돈을 금융권수준으로 안전하게 보관관리 할수 있고 공정성있는 룰을 적용하였는가? 사업영역을 늘리기위해 다양한 허가와 인증을 받게됩니다.

미국의 온라인 카지노 철퇴인 블랙프라이데이 이후~ 온라인 카지노는 이러한 인증과 허가및 제약을 기본으로 채택하게 되었으며

불법도박 사이트와 아닌 사이트의 구분은 대한민국 법으로는 분류할수 없으며~ 가장 큰 차이는 서비스 리전으로부터 다양한 허가와 인증을 받고 제약리전에서 서비스접근을 막기위한 노력을 하는지 여부입니다.

Bodog은 카리브해에 위치한 안티가 국가에 등록되어 있으며, 안티가 바부다 금융 서비스 규제위원회(Interactive Gaming License #2392 및 Interactive Wagering License #2393)의 규제를 받고 있습니다. 이들 라이선스는 Bodog가 게임 및 베팅 서비스를 제공하는 데 필요한 규정과 기준을 준수한다는 것을 의미합니다​​.

Bodog는 iTech Labs에서 완전히 인증 받았으며, 이는 그들의 카지노 게임이 공정하고 신뢰할 수 있음을 입증합니다. 이 인증은 Bodog가 제공하는 게임이 테스트되어 공정하게 운영된다는 것을 보여줍니다​​.

게임의 다양성과 접근성 면에서, Bodog는 420개 이상의 다양한 카지노 게임을 제공하며, 다운로드 및 인스턴트 플레이 모드를 지원합니다. 이는 다양한 장치에서, 포함한 모바일 폰과 태블릿에서 iOS, 안드로이드, 윈도우 폰, 블랙베리 운영 체제를 통해 접근할 수 있음을 의미합니다​​.

보안 및 안전 측면에서, Bodog는 게임의 불규칙성과 공정성을 보장하기 위해 최첨단 무작위 셔플링 기술과 난수 생성기를 사용합니다. 또한, 플레이어 간의 부정 행위를 방지하기 위한 정책을 가지고 있으며, 플레이어의 개인 및 재정 정보를 보호하기 위해 온라인 뱅킹 시스템과 동일한 보호 조치를 사용합니다​​.

책임감 있는 게임을 장려하기 위해, Bodog는 플레이어들이 자신의 도박 습관을 관리할 수 있는 도구와 자원을 제공합니다. 이에는 입금 한도, 타임아웃, 자가 배제 옵션 등이 포함되어 있지만, 구체적인 도구의 세부 사항은 제공된 소스에서 자세히 언급되지 않았습니다​​.

이와 같은 Bodog의 라이선스, 인증 및 운영 관행은 안전하고 공정하며 다양한 게임 경험을 제공하기 위한 그들의 전반적인 약속을 증명합니다.

본사는 개발및 운영이 중지되어 프로덕트가 중지되는 사태에대한 리스크가 훨씬 크다라고 판단했으며  말라가 위성 개발팀으로 지식이전이 진행되었으며

수십억 이상의  비용을 다시 한국개발팀에 지불을 했고 지식이전이 결국에는 완료가 되었습니다.

여전히  외화벌이를 하기위해 해외대상 소셜게임/온라인카지노등 개발문화및 개발능력이 준수한 개발사가 해외 진출에 성공했거나 도전을 하고 있으며

이 분야를 떠난지 오래되었지만 게임산업군으로서가 아닌  비즈니스모델 자체는 응원할수 있습니다.

마무리

국내에서 도박행위및 개발하는것 자체로 불법으로 규정될수 있으며,   이 컨텐츠는 도박을 권장하는 내용은 아니며 글로벌기준 온라인 카지노의 흑역사와 함께 관련 법규등 조명해 보았습니다.

관련 주요 사이트

• https://en.wikipedia.org/wiki/Cereus_Poker_Network
• https://en.wikipedia.org/wiki/Calvin_Ayre

특정 물리장치에 VM을 여러개 뛰우고, Docker 머신을 여러개 뛰우는 방법을 소개하고자한다.

하나의 도커에 여러개의 컨테이너를 관리하는것도 어려운데, 이렇게 하는 이유는 이 단계를 뛰어넘어

여러개의 N개의 도커 N개의 컨테이너를 어떻게 잘 관리할것인가? 도커 오케스트라 툴을 시도해보기 위해서이다.  

준비물:

• Virtual Box 설치
• Vagrant 설치

OS는 도커전용 OS인 가벼운 CoreOS를 선택하였다.

vagrant plugin install vagrant-vbguest

우선, 물리장치인 1PC의 호스트 전용 네트워크를 설정한다. 이 네트워크 기반으로 여러개의

VM을 뛰우기위함이다.

호스트 전용 네트워크 설정

Vagrantfile

# -*- mode: ruby -*-
# vi: set ft=ruby :

# All Vagrant configuration is done below. The "2" in Vagrant.configure
# configures the configuration version (we support older styles for
# backwards compatibility). Please don't change it unless you know what
# you're doing.
Vagrant.configure("2") do |config|
  # The most common configuration options are documented and commented below.
  # For a complete reference, please see the online documentation at
  # https://docs.vagrantup.com.

  # Every Vagrant development environment requires a box. You can search for
  # boxes at https://vagrantcloud.com/search.
  config.vbguest.auto_update = false
  config.vm.box = "kleesc/coreos"
  config.vm.hostname = "docker2"
  config.vm.network "private_network", ip: "192.168.56.202"
  config.vm.synced_folder "/media/psmon/DataB/docker_data2", "/vagrant_data",
    type: "nfs",
    linux__nfs_options: ['rw','no_subtree_check','all_squash','async']


  config.vm.provider "virtualbox" do |vb|
  #   # Display the VirtualBox GUI when booting the machine
  #   vb.gui = true
     vb.memory = "2048"
  end
  #
  # View the documentation for the provider you are using for more
  # information on available options.

  # Enable provisioning with a shell script. Additional provisioners such as
  # Puppet, Chef, Ansible, Salt, and Docker are also available. Please see the
  # documentation for more information about their specific syntax and use.
  # config.vm.provision "shell", inline: <<-SHELL
  #   apt-get update
  #   apt-get install -y apache2
  # SHELL
end

VM을 생성하는 스크립트이며, 파일형태로 VM의 생성 정보를 유지하면 된다.

현시점에서 비교적 최신 도커버젼과 공유디렉토리 쉐어까지 가능하다. ( 공유 디레토리를 컨테이너의 data디렉토리로 사용은 금지)

각각의 디렉토리에 Vagrantfile을 생성하여 3대의 VM을 목록을 작성한예이다.

• docker1/Vagrantfile
• docker2/Vagrantfile
• docker3/Vagrantfile

vagrant 명령들

• vagrant up : vm을 구동시킨다.
• vagrant ssh : ssh접속
• vagrant halt : vm 중지
• vagrant reload : vm 재시작
• vagrant destroy : vm 삭제

3대의 vm을 가진 docker 가 순식간에 각각의 프라이빗 네트워크를 가진채 생성이 되었다.

최종골은 여러개의 또는 복합적인 네트워크로 구성된 소규모 인프라를 도커베이스로 빠르게 구축하기 위해서이다. -샘플은 Rancher를 연동한 모습

오래된 고전 게임서비스 로직을 분석하기 시작하였다. 오랫동안 상위 랭크되어 운영된 값어치 있는 소스이며

지속적인 유지보수 과정속에서 OOP의 철학또한 담겨있다. 한동안 OOP와 거리를 두고 있어서

다시 객체지향적인 설계의 감각을 찾기위함도 있지만 관련 도메인지식으로 다시 돈을벌어야하는 상황이 왔기때문이다.

. 

VS의 도움을 받아 불필요한것을 모두 제거하여, 필요 분석대상을 UML로 먼저 압축을 하였으며

다음 과정을 거칠것이다.

Persitence와 사용자와 통신 프로토콜은 다음 기술로 대체할것이며 충분히 강력하고 보편화된 기술을 선택하였다.

• https://developer.lightbend.com/start/?group=play&project=play-java-jpa-example
• https://developer.lightbend.com/start/?group=play&project=play-java-chatroom-example
• https://developer.lightbend.com/start/?group=play&project=play-java-streaming-example

C++→JAVA로 리팩토링을 복잡도및 추상화정도를 조금더 직관적이게 하기위해  최근 언어 스펙을 부분적으로 사용할 예정이며

유행에 이끌려 함수형언어 방식을 전면 채택하지는 않을것이다. 

스칼라선택이 한가지 예이다.  -좋은 경험이며 환영할수있지만. 리스크가 분명있다. 

OOP는 아직도 대중성이 있고 충분히 강력하며(스칼라가 OOP가 아니다란 의미는 아님)

스트리밍/람다 등과 연합할수 있는 방법이 등장하였고 이것은 스칼라의 장점을 JAVA 8이후에서 느리지만 안정적으로 흡수 했기때문이다.

JAVA를 선택한 이유는 Spring/Play Framework/Netty/JPA등을 활용하여 웹서비스영역에서 쉽게사용가능한

표준화되고 범용적인 혜택의 선택지가 다양하기 때문이다.

여기서 어려운점은 언어와 별개로 상속레벨이 3이상인것을 자유자재로  추상화하고 다뤄야하는 OOP 설계능력이 필요한데

서비스 제공을 위해 SQL문 만을 호출하고 그것을 그대로 전달하는 개발 경험만 있는 개발자들과 이것을 어떻게 이해시키며 함께 협업을 할수 있는가란  것이다.

이것을 해결하기위해 아주 특수하게 사용되는 추상적인 서비스 로직을 표준적인 방법으로 심플하게 엔진화할수 있고 문서로만 설명될수 있는 고오급 개발이 필요하다. 

성공할 자신은 없지만... 그것이 왜 필요하고 어떻게 해야할지 구상이 되었기때문에 시작을 해보려고 한다. 

과거 이러한 아키텍으로 작동되는 서비스를 설계하고 작동을 시키고 현재도 운영중에 있는것으로 알고 있지만

표준+문서+심플함과는 거리가 먼 개발코드를 작성을 하였다.

이활동은 아래 링크로 이어집니다.

Spring Cloud MicroService

IDE툴에 UML 기능이 제공되지 않을때 ( 대부분 커뮤니티툴에는 빼버림)

StarUML-Reverse Code 기능을 사용하여 CODE → UML 로 변환가능

여러언어를 플러그인으로 지원하며... 개인 사용제한은 안걸리기때문에 임시로 사용....

SpringBoot VS Playframework  대결구도도 상당히 흥미롭지만

Akka및 Spark와같은 분석처리를 위해 Scala 사용이 웹요소에서 더 중요하다고 하면

애시당초 탑재되어 같이 작동하는 Playframework를 추천을 합니다.

반대로 SpringBoot의 구성 사용요소가 훨씬많으며...,  Spring에서 액터모델을 대체할만한

요소를 찾지못했을시 Akka의 Actor및 Stream을 부분적으로 활용할때 권장되는 방식입니다.

package com.psmon.cachedb.extension;

import akka.actor.Actor;
import akka.actor.IndirectActorProducer;
import org.springframework.context.ApplicationContext;

/**
 * An actor producer that lets Spring create the Actor instances.
 */
public class SpringActorProducer implements IndirectActorProducer {

    private final ApplicationContext applicationContext;
    private final String actorBeanName;
    private final Object[] args;

    public SpringActorProducer(ApplicationContext applicationContext,
        String actorBeanName) {
        this.applicationContext = applicationContext;
        this.actorBeanName = actorBeanName;
        this.args = null;
    }
    
    public SpringActorProducer(ApplicationContext applicationContext, String actorBeanName, Object... args) {
        this.applicationContext = applicationContext;
        this.actorBeanName = actorBeanName;
        this.args = args;
    }

    @Override
    public Actor produce() {
        return args == null ? 
              (Actor) applicationContext.getBean(actorBeanName):
              (Actor) applicationContext.getBean(actorBeanName, args);
    }

    @Override
    public Class<? extends Actor> actorClass() {
        return (Class<? extends Actor>) applicationContext.getType(actorBeanName);
    }
}

package com.psmon.cachedb.extension;

import akka.actor.Extension;
import akka.actor.Props;
import org.springframework.context.ApplicationContext;
import org.springframework.stereotype.Component;

/**
 * Extension to tell Akka how to create beans via Spring.
 */
@Component
public class SpringExtension implements Extension {

    private ApplicationContext applicationContext;

    /**
     * Used to initialize the Spring application context for the extension.
     */
    public void initialize(ApplicationContext applicationContext) {
        this.applicationContext = applicationContext;
    }

    /**
     * Create a Props for the specified actorBeanName using the
     * SpringActorProducer class.
     */
    public Props props(String actorBeanName, Object... args) {
        return (args != null && args.length > 0) ?
             Props.create(SpringActorProducer.class,
                     applicationContext,
                     actorBeanName, args) :
             Props.create(SpringActorProducer.class,
                     applicationContext,
                     actorBeanName);
     }   
}

package com.psmon.cachedb.config;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.context.event.ApplicationReadyEvent;
import org.springframework.context.ApplicationContext;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.ComponentScan;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.Lazy;
import org.springframework.context.event.EventListener;

import com.typesafe.config.Config;
import com.typesafe.config.ConfigFactory;

import com.psmon.cachedb.extension.SpringExtension;

import akka.actor.ActorSystem;

@Configuration
@Lazy
@ComponentScan(basePackages = { "com.psmon.cachedb.services",
    "com.psmon.cachedb.actors", "com.psmon.cachedb.extension" })
public class ApplicationConfiguration {

    @Autowired
    private ApplicationContext applicationContext;

    @Autowired
    private SpringExtension springExtension;


	@Autowired
	private Environment env;

    @Bean
    public ActorSystem actorSystem() {

        ActorSystem system = ActorSystem
            .create("AkkaTestApp", akkaConfiguration());
        springExtension.initialize(applicationContext);        
        return system;
    }

	@Bean
	public Config akkaConfiguration() {

		String akkaip = env.getProperty("akka.remote.netty.tcp.ip");
		String port = env.getProperty("akka.remote.netty.tcp.port");

        // 기존 Akka설정과(application.conf) + 최종계산된 Spring의 설정(appplication.properties)를 머징시키는방법
        // AKKA에서 필요한 기능들 설정은 충분히한후, 변경요소를 Spring설정을 노출하여 변경하는 방식
		return ConfigFactory.load().withValue("akka.remote.netty.tcp.ip", ConfigValueFactory.fromAnyRef(akkaip))
				.withValue("akka.remote.netty.tcp.port", ConfigValueFactory.fromAnyRef(port));

	}

	@EventListener(ApplicationReadyEvent.class)
	public void doSomethingAfterStartup() {
	}
	
}

#application.propertis
logging.config=classpath:logback-spring.xml


#application.conf
akka {

  loggers = ["akka.event.Logging$DefaultLogger"]

  loglevel = "INFO"

  stdout-loglevel = "ERROR"

}


#logback-spring.xml
<configuration>

  <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
    <encoder>
      <pattern>%date{ISO8601} %-5level %X{akkaSource} - %msg%n</pattern>
    </encoder>
  </appender>

  <root level="INFO">
    <appender-ref ref="STDOUT" />
  </root>

</configuration>

# application.conf
akka {
  loggers = ["akka.event.slf4j.Slf4jLogger"]
  loglevel = "DEBUG"
  log-config-on-start = on
}


# pom.xml
<dependency>
	<groupId>com.typesafe.akka</groupId>
	<artifactId>akka-slf4j_2.12</artifactId>
	<version>${akka.version}</version>
</dependency>	


# logback-spring.xml
<logger name="org.springframework.data" level="error" />
<logger name="akka" level="error" />

package com.psmon.cachedb.actors;

import org.springframework.context.annotation.Scope;
import org.springframework.stereotype.Component;

import akka.actor.UntypedActor;
import akka.event.Logging;
import akka.event.LoggingAdapter;

@Component
@Scope("prototype")  //액터객체는 수십만개를 생성해도 가볍습니다. 힙영역에 원하는 만큼 생성해야함으로 싱글톤으로 작동되는것을 방지합니다.(스프링특성)
public class TestActor extends UntypedActor {
    private final LoggingAdapter log = Logging
            .getLogger(getContext().system(), "TestActor");

    @Override
    public void onReceive(Object message) throws Exception {
    	
    	if(message instanceof String) {
    		log.info("Incommessage {}", message);  
    		
    	}else {
    		log.info("Unhandle Message {}", message);    		
    	}    	
    }
}

package com.psmon.cachedb;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.context.ApplicationContext;

import com.psmon.cachedb.extension.SpringExtension;

import akka.actor.ActorRef;
import akka.actor.ActorSystem;
import akka.event.Logging;
import akka.event.LoggingAdapter;

@SpringBootApplication
public class CachedbApplication {

	public static void main(String[] args) {
		ApplicationContext context = SpringApplication.run(CachedbApplication.class, args);
		
        ActorSystem system = context.getBean(ActorSystem.class);

        final LoggingAdapter log = Logging.getLogger(system, "Application");

        log.info("Starting up");

        SpringExtension ext = context.getBean(SpringExtension.class);
                
        ActorRef testActor = system.actorOf(ext.props("testActor"));
        
        testActor.tell("ready spring boot",null);        
	}
}

  final Materializer materializer = ActorMaterializer.create(system);
  
  final ActorRef throttler =
    Source.actorRef(1000, OverflowStrategy.dropNew())
      .throttle(1,  FiniteDuration.create(1, TimeUnit.SECONDS), 10, ThrottleMode.shaping())
      .to(Sink.actorRef(testActor, NotUsed.getInstance() ))
      .run(materializer);
  	        
  for(int i=0;i<100;i++) {
  	throttler.tell(String.format("fasmsg to slow %d", i), ActorRef.noSender());       	
  }

ActorSystem system = context.getBean(ActorSystem.class);

ActorRef testActor = system.actorOf(ext.props("testActor"));


//ActorRef(액터참조)는 로컬 어디든 

   //액터 생성... 
  ActorRef testActor = system.actorOf(ext.props("testActor"),"service1");
  
  //로컬 주소를 통한 액터 선택
  ActorSelection testActor2 = system.actorSelection("user/service1");
  
  //원격 주소를 통한 액터 선택
  ActorSelection testActorRemote = system.actorSelection("akka.tcp://app@localhost:2552/user/service1");
  
  //참조를 통한 전송 ( 로컬 객체관리에 유리 -메모리 전송 )
  testActor.tell("ready spring boot",null);
  
  //액터 셀렉션을 통한 전송
  testActor2.tell("ready spring boot -again", null);
  
  //리모트를 통한 전송 ( 네트워크 전송 )
  testActorRemote.tell("ready spring boot -again too", null);

testActor.tell("ready spring boot",null);

[INFO] [03/25/2018 20:24:00.055] [main] [Application] Starting up
[INFO] [03/25/2018 20:24:00.068] [AkkaTestApp-akka.actor.default-dispatcher-2] [TestActor] Incommessage ready spring boot

웹으로 이용하기: http://play.webnori.com/wstest

웹소켓인터페이스로 이용하기: ws://play.webnori.com/wsapi

웹소켓 메시지 설계

Socket.io 대응 자바용 웹소켓

• https://github.com/Atmosphere/atmosphere

액터+토픽기반

• https://github.com/psmon/TopicEventBus
• https://github.com/psmon/psmonSearch/commit/8a885c1de1820192cb56c32cc34b41e18f03eefc#diff-911a0f2c3e264e6dd7b2e110349983d5

웹소켓을 로드밸런싱 :

• https://www.haproxy.com/blog/websockets-load-balancing-with-haproxy/
• https://x-team.com/blog/socket-io-haproxy-aws/

Full소스위치 :  

• https://github.com/psmon/psmonSearch/tree/master/playWordParser
• 한글형태소 분석 액터

도메인 목표는없고, 설계상의 기능목표만 있음

기능 목표:

• 다양한 잡(배치/실시간/크롤)에의한 데이터 수집및 집계처리
• 분산 데이터 동일성유지
• 실시간 반영 가능구조
• 저장소의 저렴한 분산화를 통한 대량 서비스

단점:

• 복잡도에비해 성능보장안될수도 있음
• 분산된 저장소의 일관성 유지가 어려움
  
  

연동예정 Spec

• Spring Batch
• JPA Curd Repository
• H2 Local DB
• Akka Cluster Actor
• Kafka/Spark/Hadoob 등

개발 예정 Link:

BigData with RealTime

Spring을 사용해야하는 일도생기고..기존 알고 있는 웹프레임워크도 정리겸

겸사겸사 Spring을  먼저 정리하기시작하였습니다.

FullStack 웹 프레임웍이라 불르는 많은 웹개발툴들이, 배포및 자동방식은 제외하고

몇가지 요소의 사용방법및 언어가달라도 공통적인 요소가 있습니다.

• 라우터 처리
• Rest 메서드 정의
• Json 처리방식
• MVC및 View템플릿선택
• DB 객체 핸들링
• 경량화(마이크로서비스)할수 있는지여부?

SPRING의 DB 제어요소를 살펴보니, 큰 분류로 마이바티스/JPA  두가지가

있었으며 국내의 압도적인 사용률과 협업이슈와는 무관하게,

JPA가 JAVA진영의 ORM 표준으로 자리잡고 있고

테이블 관계구조를 객체지향적으로 설계하고,제어할수있는

진보되고 객체지향의 장점을 살린 방식으로 보여집니다.

ORM: 오브젝트를 모델링과 일치(연관)시키는것 이라고 해두겠습니다.

 우리가 설계한 오브젝트가 실제 데이터베이스화 되어 

DB에서 발생하는 일을 신경쓸 필요가 없어 보이거나 성능에 관여할수 없는것처럼 보입니다.

하지만, 데이터를 객체지향적으로 다루는방법과  관계형 데이터베이스를 잘다루는방법을

함께 익혀야한다는것을 의미하는것으로 , 연구대상으로 지정하였습니다.

참고링크

• 02-DBHANDLE with JPA

설계

작동

웹소켓 실시간 분산 대용량 사용자 처리 시스템을 개발해봄

웹소켓 서비스가 1노드당 2천명이 안정적이라고 가정하면

만명 동접시, MessageCenterWS 를 병렬로 5개 확장하는 시스템

비지니스 메시지는 한개의 서비스만이 ,메시지 변경 체크 (DB폴링 / 메시지 큐검사)를

하고 웹소켓 서비스에 브로드캐스트로 전달하는 방식

게임룰

턴제 게임을 예시로 들겠습니다.

게임의 프로세스를 도식화하고 , 과정을 정리해둡니다.

이것은 코딩과 상관없는 단계입니다.

포커 게임중 홀뎀이 위와 같은 프로세스를 가지게 됩니다. 이것을 멀티플레이어가 되는 게임을 만들기위해서 
각 언어에 맞는 구조체를 주고 받기위해 패킷화하여, 약속된 방식으로 주고받게 되지만! 모든 플래폼에 대응하기에 약간의 제약 사항이 있습니다.

그래서!! 웹이던 어플이던 모바일앱이던 어느곳에서나 해석이 가능한 순수 문자열을 통해 홀뎀이라는 네트워크 메시지를 구현해 보겠습니다.

통신을 위한 엔드포인트는 웹서비스이던,TCP이던 편한 방법을 사용하면 되며! 서버를 작성하는 구체적인 방법은 논외이니 제외하겠습니다.

로긴처리

일단, 클라이언트가 서버로 접속을 성공하면.., 서버는 “hello” 라는 문자열을 보내 줍니다. 
그러면 클라이언트는 서버와 통신할 준비가 된것이며!! 로긴을 시도할수 있을것입니다.

sendPacket("loginres$myID$myPW"); 
이렇게 한줄의 문자열로 로긴요청을 합니다. 각 필드는 특수문자로 구분하며! 제일 앞에 문자는 어떠한것을 요청/응답을 받았냐? 에 해당하는 약속된 메시지 입니다.

이 구분문자는 대부분의 언어에 있는 문자열 함수중 
split 함수를 사용하며 분리해낼수가 있습니다.

그리고 로그인이 정상적으로 되었다면!! 서버로 부터 “loginreq$1”, 실패했다면 “loginreq$0” 을 받게 될것이며 
로그인이 정상적으로 되었다면!! 테이블에 앉을수 있는 메시지를 보낼수가 있습니다.

게임입장

sendPacket("Sit$"); 
이렇게요!!!!

그러면 서버는 모든 클라이언트에게.., 특정유져가 테이블에 착석을 했다라고 알려주겠죠!! 
”Sitting$1$John$500”    ==> John이라는 유져가 1번째 테이블에, 500달러를 가지고 착석을 했다는 의미

이러한 프로세스로 한명의 유져가 더 착석을 합니다.

게임진행

”Sitting$2$Smith$300”  
스미스가 300돈을 가지고 2번 자리에 착석을 했네요!!! 게임의 위한 최소 플레이 2명이 충족했기때문에 이제 게임이 시작하게 됩니다.

"StageStart" 
서버로 부터 새로운 스테이지가 시작됨을 받게됩니다.  서버는 역으로 모든 클라이언트에게 보내게 되겠죠

“Dealer$1” 
딜러는 1번째 자리인 존이군요!!! 딜러마크를 이동해줍니다.

”SmallBlind$1$5” 
1번째 자리인 존이 먼저 SB에 해당하는 5달러의 판돈을 냅니다.

”BigBlind$2$10” 
2번째 자리인 스미스가 BB에 해당하는 10$를 내게 됩니다.

그리고 클라이언트는 자신이 무슨 카드(포켓카드 2장)을 받았는지 서버가 각 개별로 보내줍니다. 
다른 사람것을 보내주면 안되겠죠!! 
“Pocket$0$4$1”     //자신의 첫번째 카드가 스페이드 4임   (pos/카드숫자/카드모양) 
“Pocket$1$5$2”     //자신의 두번째 카드가 다이아 5임

그리고 각 유져는 순서대로 벳팅을 하게 되겠죠!!!

”Call$”  “Fold$”  “Raise$400$”  상황에 따라 3가지 상황을 서버에게 보내줍니다.

그리고 서버는 다시 클라이언트에게 상대가 어떠한 행동을 했는지 보내 줍니다. 
”Call$1”     존이 콜을 했네요 
”Call$2”     스미스도 콜을 했습니다.

여기까지가 홀뎀에서 프리플롭이며!!! 이제 커뮤니티 카드인 바닥카드 3장이 깔리게 됩니다.

”Community$0$3$1” 
”Community$1$4$1” 
”Community$2$5$1” 
스페이드 3,4,5 세장의 카드가 깔리고 다시 순서대로 베팅단계가 됩니다.

승패처리

”Fold$1”   존이 패가 안좋아서 폴드를 외칩니다.

누군가 한명이 폴드를 하게되면  한핸드가 끝나게 되고 승패를 알려주게 되죠!!!

”Win$2$300”  존이 300달러를 땄네요!!

게임진행되는 조건이 성립되는동안

계속 반복하여!! 게임을 진행합니다.!! 

채팅수준으로 멀티플레이어 게임을 구현할수가 있습니다.

구현체는 없으나~ 대부분의 턴제게임 프로토타잎은

위와같은 패킷설계(문자열)로 게임 진행이 가능합니다.

게임정보 실시간 갱신

로그인을 반영한 사용자 실시간처리

더 똑똑한 언어

초창기의 컴퓨터 언어는 컴퓨터를 사용해 어떤 일을 쉽게 하기 위한 목적으로 고안됐다. 최신 언어의 초점은 정상적인 작업 이외의 다른 일은 하기 어렵거나 거의 불가능하도록 하는 데 있다. 프로그래밍 커뮤니티는 오랜 시간에 걸쳐 사람들이 어떻게 실수를 해서 프로그램을 망치는지를 학습했다. 그렇게 해서 나쁜 습관 목록을 작성했고, 이제 몇몇 언어 설계자들은 아예 가드레일을 치고 구속복을 입혀가며 프로그래머들이 널 포인터 역참조 또는 경합 조건과 같은 과거 세대의 실수를 반복하지 않도록 하기 위해 애쓰고 있다.

예를 들어 러스트(Rust)에는 변하지 않는 변수 클래스가 있다. 변할 수 없는 변수라니 이상하게 들리겠지만, 경합 조건을 차단하고 코드 실행 속도를 더 빠르게 하기 위한 유일한 방법이다. 이와 같은 수백 가지의 혁신 덕분에 프로그래머들은 더 좋은 코드를 작성할 수 있다.

물론 이러한 제약은 완벽하지 않으며, 나쁜 습관을 반사적으로 피해가는 유능한 프로그래머에게는 오히려 성가신 요소가 되기도 한다. 그러나 많은 프로그래머들이 새로운 언어들의 엄격한 규율과 부가적인 구조를 반갑게 받아들이는 중이다.

원본 :http://www.itworld.co.kr/news/105902?page=0,0

과거(개인적 경험기준)

• 어셈블리를 알아야하며 필요하면 이것으로 성능해결해야한다.
• 메모리를 직접 할당하고 해제해야만 고효율 서버를 작성할수가 있다.
• TCP모델 정확하게는 IOCPSOCK을 제어해야지 대규모 처리를 할수가 있다.
• 성능해결위해 다양한 멀티스레드 모델을 알아야하고,동시성 대규모 처리역시 이것을 통해 이루어낼수있다.

현재

• 디자인패턴을 통해 문제를 해결 해야하며 실제로 더 많은것을 공부하고 어렵습니다.
• 가비지 컬렉트 이해는 어려우며, 플래폼(JVM/CLR)마다 많은 차이가 있습니다.
• 하나의 서버에서 고효율을 내는것보다, 분산처리개념이 더 중요해졌으며 이것역시 목표달성하기 어렵습니다.
• 스레딩을 처리를 직접안하지만 동시성 프로그래밍모델도 과거를 이해 해야하며 어렵습니다.

IT용어 정리

 IT에  한해서 어떠한 단어에대한 정의를 내리는것은 아주 어려운일인듯합니다. 10년동안 어떠한 기술을 사용을 해도

그것의 본질을 정확하게 파악하고 정의 내리기란 어렵습니다.

대부분 추상적이며 다른 경험에의해 새로운 속성을 붙이기 때문입니다.

과학은 모든 사람이 그 뜻에 동의하는 전문용어를 제공한다. 비록 그 전문용어가 어디에 쓰이는지에 대해서 반드시

모두 합의된건 아니지만 , 예를 들자면 '빅뱅'이론은, 그 이론이 우주의 탄생을 설명하기에 적합한 내용인지

모든 천문학자가 동의하는 건 아니지만, 천문학자라면 이해는 한다. 하지만 소프트웨어 공학 분야에서는

모든 사람이 동의한는 전문용어가 없다. 비지니스 환경에서 우리 분야를 원래 '데이터 처리' 라고

불렀지만 지금은 '정보처리'라고 부른다. 공학 환경에서는 '컴퓨팅'이라고 부른다. 우리가운데 일부는

이제 우리 분야의 이름을 '지식처리'라고 바꿔 부르기를 원하기도 한다

..... 고약한문제 합당할 해결 p.29

소프트웨어에 있어서 '서버','비동기','분산처리' ,'객체지향 프로그래밍'등  모두가 동의하는 정의를 어떻게 내려야할까요?  

개인의 용어정리활동 : Terminology

1단계: 제어 흐름

디자인패키지의 제어 흐름에서 다음 태스크를 정의해야 합니다.

검색하려는 원본 데이터에 대한 변경 간격의 시작 및 종료 datetime 값을 계산합니다.이러한 값을 계산하려면 SQL 실행 태스크를 사용하거나 Integration Services 식에 datetime 함수를 사용합니다. 그런 다음 패키지에서 나중에 사용하기 위해 이러한 끝점을 패키지 변수에 저장합니다.참조 항목: 변경 데이터의 간격 지정선택한 간격에 대한 변경 데이터가 준비되었는지 여부를 확인합니다. 비동기 캡처 프로세스에서 선택한 끝점에 아직 도달하지 않았을 수 있기 때문에 이 단계가 필요합니다.데이터가 준비되었는지 여부를 확인하려면 필요한 경우 선택한 간격에 대한 변경 데이터가 준비될 때까지 실행을 지연하는 For 루프 컨테이너로 시작합니다. 해당 루프 컨테이너 내에서 SQL 실행 태스크를 사용하여 변경 데이터 캡처에 의해 유지되는 시간 매핑 테이블을 쿼리합니다. 그런 다음 필요한 경우 Thread.Sleep 메서드를 호출하는 스크립트 태스크 또는 WAITFOR 문이 있는 다른 SQL 실행 태스크를 사용하여 패키지 실행을 일시적으로 지연합니다. 다른 스크립트 태스크를 사용하여 오류 상태나 시간 초과를 기록할 수도 있습니다.참조 항목: 변경 데이터의 준비 여부 확인변경 데이터를 쿼리하는 데 사용할 쿼리 문자열을 준비합니다.스크립트 태스크나 SQL 실행 태스크를 사용하여 변경 내용을 쿼리하는 데 사용할 SQL 문을 조합합니다.참조 항목: 변경 데이터에 대한 쿼리

준비2단계:

변경 데이터에 대한 쿼리 설정데이터를 쿼리할 테이블 반환 함수를 만듭니다.SQL Server Management Studio를 사용하여 쿼리를 개발하고 저장합니다.참조 항목: 변경 데이터 검색 및 이해

3단계:

데이터 흐름 디자인패키지의 데이터 흐름에서 다음 태스크를 정의해야 합니다.변경 테이블에서 변경 데이터를 검색합니다.데이터를 검색하려면 원본 구성 요소를 사용하여 선택한 간격 범위에 포함되는 변경 테이블의 변경 내용을 쿼리합니다. 원본에서는 앞에서 만든 Transact-SQL 테이블 반환 함수를 호출합니다.참조 항목: 변경 데이터 검색 및 이해처리를 위해 변경 내용을 삽입, 업데이트 및 삭제로 분할합니다.변경 내용을 분할하려면 조건부 분할 변환을 사용하여 적절한 처리를 위해 삽입, 업데이트 및 삭제를 다른 출력으로 전송합니다.참조 항목: 삽입, 업데이트 및 삭제 처리대상에 삽입, 삭제 및 업데이트를 적용합니다.대상에 변경 내용을 적용하려면 대상 구성 요소를 사용하여 대상에 삽입을 적용합니다. 또한 OLE DB 명령 변환에 매개 변수가 있는 UPDATE 및 DELETE 문을 사용하여 대상에 업데이트 및 삭제를 적용합니다. 대상 구성 요소를 통해 임시 테이블에 해당 행을 저장하여 업데이트 및 삭제를 적용할 수도 있습니다. 그런 다음 SQL 실행 태스크를 사용하여 임시 테이블의 대상에 대해 대량 업데이트 및 대량 삭제 작업을 수행합니다.참조 항목: 대상에 변경 내용 적용

여러 테이블의 변경 데이터 작업

위 다이어그램에 설명된 프로세스 및 단계는 단일 테이블에서 증분 로드를 수행합니다. 여러 테이블에서 증분 로드를 수행하는 경우 전반적인 프로세스는 같습니다. 그러나 여러 테이블 처리에 맞게 패키지의 디자인을 변경해야 합니다. 여러 테이블에서 증분 로드를 수행하는 패키지를 만드는 방법은 여러 테이블의 증분 로드 수행을 참조하십시오.

출처 :https://technet.microsoft.com/ko-kr/library/bb895315(v=sql.105).aspx

  하루에도 여러차례 서비스코드를 개선하기위해 커밋을하고, 그 커밋은 어떠한 결정에 의해 이루어지며

그 어떠한 결정과정은 , 메일함 어딘가에 있습니다. 메신져 어딘가에 있습니다. 친절한 담당자가 

잘 대응을 해주었으니까요.  그렇게 매직 코드는 쌓여만 갑니다.

장애처리와 관련해서는 해결을위한 처리도 원인 파악을 통해 이루어졌지만

지식및 운영에 관련하여 그어떠한 노하우도 쌓이지않고 추적이 되지 않으니 또 생깁니다.

연말에 과거1년을 돌아보면, 이상하게 비슷한 날짜에 같은 장애처리를 합니다. SSL인증서 만료처럼

한번한 실수는 보통 한사람이 다시 잘안합니다.  과거에했던 누군가의 실수를 팀내 다른사람이 되풀이할뿐이죠

하지만 우리들만의 방식으로 잘 운영이되고있습니다. 운영팀을 도입했지만, 그들은 서버를 켜고끌뿐입니다.

개발과 운영이 분리되지 않습니다. 왜? 개발자가 직접 배포하고 운영도 해야 하니까요

우리는  남들이 컨트롤 못하게 곳곳에  수동조작 버튼을 곳곳에 심어놓았습니다. 그리고 그것은 문서화도 안되어있습니다.

새로 영입된 아키텍트는 한참 분석하더니 결론을 내렸습니다. 이것은 블랙 박스다라고 

원래는 팀장이 아키텍트역활을 했었습니다.  팀장은 결코 자신이 팀장인  기간내에 작성된 팀코드를 블랙박스다란 결론을 내릴수없습니다.

그리고 그것은 좀더 좋은 단어로 바꿔 불렀습니다. 레거시 코드이며, 이것을 개발하는 팀은 레거시팀이다라고 그리고 신규개발팀을 만들었습니다.

저는 이의미에 반대하였습니다. 제가 레거시팀의 메인개발자였으며 

오래된 기술을 사용한다고 해도 현재 서비스를 잘하고 있는데 어떻게 유산이냐고?  새로운 서비스로 바꾸고 나서 그렇게 불러달라고

하지만 늦게 수긍을 하였습니다. 레거시인 이유는 사용된 기술이 오래되서가 아니라

기존코드가 비지니스 흐름 분석이 안되고 개선 지점을 찾을수없으며 문서화도 안되고 배포도 어려운

예전 고전적인 개발방법을 통해 개발이되었기때문이다라고~ 

어쨋든 이것을 지켜보는 상위 관리팀에서 극단의 지침을 내립니다. 이것은 플래폼의 문제를 뛰어넘는것입니다.

그냥 놀아라, 너희가 노는것을 보장해주겠다.

하지만 활동을 하고 싶은면 너가 하는일이무엇인지?  사소한 일도 티켓을 만들고 그 과정을 문서화해라~

티켓:특정한 것을 할 수 있는 자격. (네이버사전)

처음에는 , 뭔가 답답했습니다. 우리는 우리만의 아날로그적인 감성과 , 아날로그적으로 일하는것을 더 선호했습니다.

내가 하는일의 제목을 무엇으로 하고? 요청해야할 제목은 무엇으로 할것이며? 문서로 어떻게 설득을 시킬것이며 할당은 누구에게 하지?

이전에는 그냥 담당팀 아무개한테 해달라고 하면 해줬는데~~

이런 고민을 하는게 처음에는 소모적 으로 느껴졌습니다.

그리고 내가 하는 일을 스스로 보고하여 트래킹 당하는것도 싫었습니다.

그러면서 잘못된 세가지를 알게되었습니다.

• 상대팀의 리소스를 , 내가 함부로 사용할수 없다란것. 
• 또한 그 리소스에 대한 역활및 사용권한에대해  애시당초 정의한적 없었다란것
• 미리 계획하고 요청했을 기회를 무시하고 , 나중에 언제든 요청하면 바로 해주겠지하고 미룬것

기존에는 이러한게  미덕이였습니다.

• 퇴근시간 갑자기 생긴일에 응대를 해주면 착한 개발자 
• 문의받은 그내용이 무엇인지 어렵풋이알지만 신속하게 유추한 정보로 응대를 해줘도 착한 개발자

기존의 그결과는 이렇습니다.

• 유추한 정보가 전달되더니 서비스에 반영됩니다. 실제 그러했습니다.
• 팀의 리소스가 분배되지않고, 팀장을 건너뛰어 팀내 외부 담당전문 개발자가 생깁니다. 팀장도 진행사항을 놓치게됩니다.
• 퇴근시간이되면 문의하는 습관이 생깁니다. 상대가 칼퇴하면 문제 삼습니다.
• 런칭 1주일도 안남아서, 이거 담주 올라가야하니 빨리해주세요 라고 요청합니다. 계획되지 않은걸 문제삼지 않고, 1주일이내에 못끝낸 담당자가 잘못되게 됩니다.

그렇습니다. 기존에는 자신의 팀업무를 위해서 특정누구한테 문의가 집중되었으며 관리도 안되었습니다.

할당수로 측정이되니, 이제 팀내에서 분업을 어떻게 시킬까 고민을 하게 만들었습니다. 대부분의 팀의 일은

이제 팀장에게 직접 할당이 되니까요. 그리고 팀장끼리 협업을 해야합니다. 자신의 팀 문제가 아니면 다른팀에게

넘겨야하니까요

 어쨋건 우리가하는일을 트래킹 시스템을 도입하고 ,아주 세세한 일까지

기록하기로 합의를 하였으며, 프로세스의 잘잘못은 이후에 바로잡아가기로 합니다.

모든 문제의 파악은, 직관적인 티켓을 통해서만 하기로 하였으니까요....,

신규기능 추가

 신규기능은 어떻게 추가하나? 사업부에서 어떠한 아이디어를 떠올려 초안을 세웁니다.

티켓이름  "PRD-001:다중기기 사용자를 대비한 멀티로그인 기능 추가"  

내용: 다중기기 사용자가 늘고있으니, 멀티로그인을 허용해라~~ 이하 생략,아니 없음

하지만 어딘가 이러한 티켓이 발견이 됩니다. "BI-001 다중기기를 로그인을 허용했을때 수익증가율 분석"

그리고 사업부에서 BA(비지니스분석,기획)에게 이 티켓을 좀더 분석해 구체안(기획서)을 만들라고 할당합니다.

기획초안 작성

 이제 BA는 발빠르게 움직입니다. 도대체 이게 무슨 내용이지?  기존 작동법부터 배우기시작합니다.

유니크한 로그인이 뭔지 그떄 파악하고 , 멀티로그인이 가능함으로 할수 있는 여러가지 아이디어를 넣기시작합니다.

기존 기능과 충돌나는 사항에 에대해 고려하지 못할수도 있습니다.

그리고 기획문서 초안이 완성되는 시점, 관련 개발팀을 소집합니다.

"기획-001:멀티 로그인을 통한 플래폼 기능개선"  내용: prd에서 내용약간 추가됨

BA와 개발자는 의사소통이 어렵기 때문에, 아케텍트에게 개발가능하게 구체화 해달라고 할당 합니다.

분석

 각 개발팀이 모여 어떻게 누가? 어떻게 개발해야할지 분석에 들어갑니다.  

PM은 이때 냄새를 맡고 , 개발관련 스케쥴을 컨트롤 하려고 합니다. 런칭일을 준수하지 못하면

프로덕트 메니져에게 혼나기 떄문입니다.

"PKIV-001-다중기기 사용자를 대비한 멀티 로그인  대장정(EPIC)"  우선 가장 거대한 티켓을 만들고 봅니다.  

(여기서 PKIV는 프로덕트기준 약속된 개발관련 접두어이며 자동으로 붙습니다.)

이때 대부분의 사업요구서와 기획티켓이 연관이되기때문에 여기에 직간접 참여한 모든 개발자및 QA 데브옵스 디자이너등등

자신이 무엇때문에 일을 하고 있는지 그 이유와 사명감에 대해서 알게됩니다. 

 아키텍트의 참관하에 BA가 설명을하고 어떤 개발팀이 필요한지 물어봅니다.  

개발팀의 거짓말을 방지하기위해 감독역활로 아키텍트는 그냥 참관합니다. 가끔 이건 안되요 하면 아키텍트가 열심히 리서치해서

해법을 찾아주기도 합니다. 아주 가끔입니다.

QA는 QA범위 산정을 위해 미리 참관을하지만, 새롭게 작동되는 방식에대해 의문을 제기하기도 합니다. 기존작동은 아시냐구요?  

서버팀도 한마디 합니다. "이거  다중기기 허용하면 부하증가 어떻게 하실겁니까?" 하지만  아차합니다. 자기팀에서 해야되는 일이기때문에

괞히 부하이야기 꺼냈다가 아키텍트가 로드 테스트팀을 붙여서 로드테스트 티켓도 만들어버립니다.

갑자기 PM은 그래 서버가 필요해? 잘 쉬고 있는 데브 옵스를 데리고 오고, 데브옵스는 "ITO-001-개발서버두대추가" 티켓을  즉석으로 만들고

PKIV- 멀티로긴 개발대장정(EPIC) 티켓에 연결시킵니다. 물론 이 서브티켓에는 BIGIP설정및 SSL인증서 라우터룰셋팅등 잡다한 티켓이 생성됩니다.

알고싶지는 않지만, 서버두대 추가로 해야되는 고급 일들이 많아 보입니다. 그리고 데브옵스는 임무를 마치고 자기일 하러 갑니다. 아직 프로젝트가

완료 되려면 한참 남았으니까요 

결국 DB / 서버 / 클라이언트/모바일팀  4팀에서 개발을 하기로 결정하고 기획서의 숨겨지고 함축된 의미에 대해

두리뭉실하게 재해석을 하고 파이팅을 외치며 회의는 끝나게 됩니다. 금요일은  빨리 퇴근 해야하기떄문에 이야기가 길어지면

안되기때문입니다.

설계

 아키텍트는 이떄부터 개발팀과함께 다이어그램을그리기 시작하며

어떠한 기능에대해  비지니스 로직이 어디에 있어야 하는가에 대해 물어보기 시작됩니다.

DB냐? 서버냐?  게으른 서버개발자는 이것을 클라이언트에게 넘기기도 하고

똑똑한 클라이언트 개발자는 아키텍트를 설득시켜 다시 넘기기도합니다. 그리고 그것은 다시 DB로 넘어가기도합니다.

아키텍트는 아름다운 중재를 합니다. 반반씩 해라~~~  DB반 서버반....  이 단계가 길어집니다. PM이 개입합니다.

뭣이 중한디? 아무나 빨리하고 일정을 맞추시오. DB에서 영업을뛰어 이 비지니스로직이 DB로 가게되면 공수가생겨 업데이트가 연기가 됩니다

PM이 BA및 아키텍트의 조건부 승인을 받아냅니다. 런칭 날짜가 더 중요하니 이 로직은 그냥 서버가 하게하고 다음에 개선하자

어느정도 아키텍쳐가 그려지는듯 하더니   이러는 동안 PRD(프로덕요구사항)에 수정이 일어나고,

기획서가 변경됩니다.   기획-001 티켓을 은근슬쩍 수정하여 공지합니다

멀티 로그인 허용이지만 모바일은  허용하고,PC는 비허용

이때까지한 설계가 수포로 돌아가거나, 수정이 필요합니다. 원래부터 탄탄한 구조가 아니였기에 옵션화를 통해 할수 있는게 아닙니다.

여러가지 사이드 이펙트 문제로 아키텍/개발자/기획 의 논쟁이 끝나지 않습니다. 

이런문제는 모든 충돌사항을 수용을 시켜야 해결이되며, 그것이 끝날때까지는 개발이 시작될수없습니다.

이때 항상 해결자가 등장하여, 어떠한 중립적인 아키텍쳐를 제시하여 그 문제를 해결을 합니다.  

이러한 설계 티켓번호는 분쟁이 심하면 내용으로 기억되지 않습니다.

숫자로 기억됩니다.  7782번 티켓이라고  ..... 개발시간을 다 까먹었지만 릴리즈 날자는 변경없이 다음 단계로 돌입하게되며

QA는 조용하게 이때까지 준비한 테스트 케이스를  모두 폐기하고, 최종 결론본에 맞춰 처음부터 다시작성합니다.

개발

개발 이전에 수많은 분석및 설계 티켓이 먼저 생성되었습니다. 그렇습니다. 그것은 티켓번호 7782입니다.

PKIV-001 대서사시(EPIC) 에대한 서브 티켓으로

• PKIV02-DB팀의 다중 로그인 추가에 대한 이야기(STORY)
• PKIV03-서버팀의 다중 로그인 추가에 대한 이야기(STORY) 
• PKIV04-클라이트팀의 다중 로그인 추가에 대한 이야기(STORY)
• PKIV05-다중로그인 테스트에대한 아름다운 QA의 이야기(STORY)

각팀에서 해야할 스토리들이 만들어집니다.  

그 이야기에 대한 하부를 어떻게 그룹핑하고 풀어야 할지는 각 개발팀이 만들어야 하며 이때부터

진행사항을 PM이 개입하기 시작합니다. PM은 작업 과정에는 관심이 없고 스토리가 모두 완료되는것에만 관심이 있습니다.

실질적인 하위 일(TASK)이 모두 끝나야 각팀의 이야기가 끝나기 때문입니다. 

개발팀은 소스변경범위를 어느정도 예측하여 QA에게 테스트 범위를 대략 알려주지만, 쓸모없습니다.

대부분 버그는 개발자가 안 알려준곳에서만 생깁니다. 체크리스트는 개발자가 알려준곳 제외하고 나머지를 정리하는것입니다.

소스및 소스에따른 구동환경은 다음과 같이 진행됩니다.

최신 master로부터  featured-기능 브랜치를 각각 만들고,  로컬 개발테스트가 완료되면   release 브랜치로 통합하여 QA를 준비합니다.

이와 동시에  데브옵스는 릴리즈 브랜치를 확인하고 DEV 배포 환경을 준비합니다. (완전 자동화는 아님)

DEV 배포환경이라고 각 기능서버가 한대씩만 존재 하지 않습니다.

실전과같이  스위칭 환경 테스팅도 포함되기때문에 스위칭이되는 장비는 최소  이중화가되어 쌍을 이룹니다.

또한  실제 개발 서브 도메인을 사용합니다.  host를 변경하여 테스트하는 순간 변질된 테스트이기때문입니다.

한가지 팁을 알려드리면, 이런것이 가능한것은 내부/외부 모든 url은 설정화이며 백오피스에 런타임으로도 바꾸면

모든 서버및, 모슨 수만명의 브라우져 사용자에게 실시간 변경사항 적용되기 때문에 가능합니다.

host를 변경하는 테스트를 DEV테스트라고 하지 않습니다. 이것은 QA에 내보낼수 없는 로컬 테스트입니다.

사용자에게  system 폴더에 있는 host파일을 관리자 권한으로 열어서 따따따.com을 111 로 바꾸면 우리의 솔류션은

완벽하게 작동됩니다. 라고 이야기하는것입니다.

DEV-QA

개발이 완료되고, release 브랜치를 통해 QA가 시작됩니다. 여기서 여러가지 수정사항이 생깁니다.

기획서의 내용이 추가되고 개발이 추가됩니다. 동시에 기능 TEST를 하고 A를 FIX하고 문제가 없던 B가 문제가 생깁니다. 

QA는 불평을 합니다. A를  개선하고 FIX 하였는데, B가 왜 문제 생기냐고?

개발자는 쏘리하고 B도 수정해줍니다. 험난한 고비를 넘어 QA의 SING-OFF가 나기직전입니다.

개발내용에따라, 이중화된 서버중 한대를 내리거나, 인터넷 연결선을 단절하거나 극단의 테스트를  마지막에 수행하기도 합니다.

이것에 대한 복구도 개발서버가 커버를 해야하는 부분입니다.  이러한 극단 테스트는 

10번 시도하고 8번정도 복구가됩니다.  인터넷 제공업체의 인터넷 품질에 대해 커버를 모두할수는 없기에 테스트 OK하고 넘어갑니다. 

 이제 대서사시(EPIC) 종료를 위해

통합 테스트 환경인  INT 단계로 넘어가게 됩니다. INT로 넘어가기전의 소스는 가급적 수정이 일어나면 안됩니다.

대서사시의 마무리단계에서, 중간 이야기를 변경하면 그 이후의 이야기도 다시 작성해야 하기때문에 독자들이 화를 낼것입니다.

(QA를 또해야하고, QASingOFF 날짜도 PM과 약속한 QA가 완료해야할 날짜가 있기때문입니다. )

DEV-릴리즈 프리징이되었으며 이것은 서비스에바로올려도 문제가 없을것이다란 희망입니다. 그리고 통합환경인 INT로 넘어갑니다.

INT-QA

INT환경은 소스통합 테스트를 위한 개발환경이 아닙니다. 소스통합에 따른 문제는 DEV단계 Release 프리징을 통해 이미 완료 되었으며

희망사항이 이어진다고 하면, 여기서 넘어온 릴리즈 환경이 리얼서비스환경에 반영이되어도 문제가 없어야합니다. 

 QA완료된 릴리즈 프리징 된 배포버젼이 리얼에 올라가도 문제가 없는게 우리의 희망사항이나

이상은 그렇지 않습니다. 그래서 DEV에 했던 단편적인 테스트를 모두 집합시켜 INT에 한방에 반영하여 풀테스트를 진행합니다. 

가끔 이런 문제제기를 합니다.  INT에서 10%를 빼겠다고, 왜 이런것이 깔끔하게 안되냐고?

답은 간단합니다  INT를 포기하고 DEV단계로 다시 가야하는 이슈입니다. 소스머지가 완벽한다고 해도 안될일입니다.

애시당초 INT에서는 머지를하거나 뺄려고 만든 환경이 아니기 때문입니다. 이것은 SVN,GIT과 상관없이 형상관리를 초월하는 문제입니다.

애시당초  기능활성 미지수인것은 실시간 옵션화로 미리 계획되어야 되는일이며 실제로 수많은 예상기능들이

그렇게하여 소스와 머지된상태로 비활성화되어 올라갔습니다. 또한 옵션 활성/미활성에따른 이중 테스트도 포함이 되었구요

INT환경은  또한 실제 서비스환경과 비슷한 테스트 환경으로,  DB 역시 서비스수준으로 노이즈가 없어야합니다.

 코드프리징이 일어난 Release라 할지라도,DEV에 가지않고  중요한 작은범위의 변경정도는 할수가 있습니다.

추가 변경 테스트를  INT에서 해야하고 소스차가 생겼기때문에 이상황에서는 DEV의 가치는 없어졌습니다. 

그리고 일정상 어떠한 문제에대해서 안올리는게 좋다란 QA판단을 합니다.

A를 고치니...더 중요한 B문제를 놓치는 케이스가 분명 있기때문에 코드변경시 일정내에 QA에서 검증을 할수 없다라고 합니다.  

이것은 이미 보고된 문제임으로 프로덕트 조건 승인이 까지 이루어지면 다음에 개선하기로하고 넘어가는 경우도 있으며

분명 무리하게 고친것보다 , 더 안정적이게 됩니다.

이제 힘든 QA활동을 마쳤습니다. 이것이 바로 프로덕에 갈꺼같지만 몇가지 단계가 더 남았습니다.

INT SignOff는 Release → Master로 통합될수 있다란 의미이자  실반영을 해도 된다란 약속이며 실제로 머지가 됩니다.

하지만 여기서 끝이아니고 실제 운영반영을 위한 민방위 훈련이 하루종일 시행이됩니다.

데브옵스는 INT의 모든 배포 변경사항을  현재 운영 서비스와 동일하게 롤백하고

그동안 INT가 Release대상으로 디플로이 된것을 , Master로 변경합니다.   

Master를 통해 실서비스 반영과 똑같은 스텝으로 , 실제 반영  가상 테스트 시나리오 에 돌입하게 됩니다.

이상적으로 운영 순서에따른,혹은 설정사항 순서 적용에따른 문제를 미리 찾을수 있습니다.

QA는 모든 업데이트 타임을 보고받고, 그 타이밍에 맞는 스모크 테스트를 합니다. 

한가지 예로 로그인서버가 순차 교체가 된다고하면,  그 타이밍에 로그인을 계속 시도하는것입니다.

이쯔음 데브옵스는  동시에 Master를 통한 운영 빌드및 디플로이를 준비합니다.

(빌드와 배포는  분리되어야하는것으로 빌드를 미리해둡니다. )

-만약 이때, 운영버그를 발견한다면,그것은 지금것 방치되었다란 의미이며  무리하게 Fix하지 않고 다음으로 미룹니다

이경우 stable 브랜치를 통해 fix는 가능하나, 굳이 그러지 않습니다.

운영

 INT-QA/LOAD TEST 가 완료되었다고 운영에 반영할수 있는것은 아닙니다.

배포단계에 보안에 문제가 있는부분은 없는지? 이상하게 배포하고 있지 않는지?

"DA001-멀티로그인 추가에따른 운영반영"  티켓이 만들어집니다.  이곳에는 각종 적용스텝,롤백플랜등이 들어있습니다.

만약 하나라도 이상한점이 있거나 수동조작으로 악성코드를 심을수 있는 상황을 개발자에게 제공할 기회를 준다고 하면,

최고 빌드관리자의  승인거부하에 프로덕에  올라갈수 없습니다.

이경우 런칭일정준수상  프로덕트 관리자의 조건부 승인이 추가로 필요합니다. 

운영 수동배포는 다음에 빅이슈 되어 처리해야할 개발과제가 됩니다. 대부분 고질적 문제로 자동배포는 빠르게 해결이안됩니다.

빌드관리자의 승인은 릴리즈 날짜를 방해하는 요소가아니며,  배포서비스를 안정화하겠다란 의지입니다.

결국 추후 자동배포처리가 모두 되었습니다. 이 이후부터 빌드관리자의 승인거부는 절대적인게 됩니다.

-길거리에서 긴급처리한 실제 카톡내용입니다. 다행히 노트북과 버려진 테이블이 있었습니다.

이것은 운영장애 발생이 아닌,  하루전 갑자기 자동빌드가 깨져서 빌드를 정상화하는것입니다.

물론 수동으로 Deploy로 처리할수 있는 부분이지만, 자동배포이후 그것은 허용되질 않았습니다. 등장인물은 PM,데브옵스,개발자,QA ( INT에서 검증후 내보냄)

이제 험난한 과정을 거치고 드디어 런칭하였습니다.  이제부터느 운영이기때문에 집중 테스트가 진행됩니다.

QA에선 테스트기간 1주일동안 못찾은 문제를, 1분만에 찾는 초능력을 발휘하기도 합니다.

 서비스 운영에 반영후, hotfix가 생기면 아직 master가 최신 개발반영소스라 master를 통해 hotfix 진행이 가능합니다. 

운영에 발생한 버그는 , QA와 분리하여 진행됩니다.  "OP-001 로그인안됨  심각단계 : L2"

 아주 큰 결정력이 따르지만 , 만약 긴급 롤백이 생긴다면, 개발소스를 통해 하는게 아니라... 이미 운영에 빌드완료되고 디플로이 셋트가 있기때문에

디플로이 스냅샷을 통해 롤백이 가능합니다. ( 여기서 디플로이 스냅샷은 자동으로 생성되는것 or 수동으로라도 운영빌드된 패키지가 백업이 됨을 의미)

이러한 문제는 보통 모든 운영 반영 테스트를 마치고 새벽에 잠이들때 발생합니다.

이때 일반적으로 회사는 퇴근후 개인 사생활을 보장했기때문에 개인 휴대폰을 통해 연락할수 없으며

개인 전화번도또한 리스트업을 하지 않았습니다. 참 좋은 회사죠......

 그래서 회사가 준비했습니다. 운영대응 개발자에게 폰을 하나씩 지급했습니다. 무제한 데이터로 아주 잘사용했습니다.

하지만 이 전화는 새벽에 울립니다. L2일때 말이죠 

여기서 L3정도의 우선순위 Fix이면 바로 반영 하기보다, 반영과정에 문제가 없는지 체크가 필요하기 때문에

약소한 INT단계를 한번더 거친후 문제가 없음을 확인하고, 서비스에서 HOTFIX 반영이 이루어집니다.

어쨋건 이 모든 과정이 끝나면  PKIV-001 멀티로그인 대서사시(EPIC) 티켓이 막을 됩니다.

정리

이 긴내용에 언급된 티켓을  생성순으로 리스트업하면

• PRD-001:다중기기 사용자를 대비한 멀티로그인 기능 추가
  • 기획-001:멀티 로그인을 통한 플래폼 기능개선
  • 7782
  • PKIV-001-다중기기 사용자를 대비한 멀티 로그인 추가
    • PKIV02-DB 다중로그인 추가
    • SP A 수정
    • SP B 추가
    • PKIV03-서버 다중로그인추가
    • LS변경
    • GS변경
    • DC변경
    • TMS변경
    • PKIV04-클라이언트 다중로그인추가
    • 관련 메시지추가
  • ITO-001-멀티로긴 운영서버 두대추가
    • ITO-002-잡다한 설정하기
  • PKIV-005 다중로그인 QA
    • 여러가지 아주 많은 이슈
  • DA001-멀티로그인운영반영
    • 업데이트 절차
    • 롤백방안
    • 서버적용범위
    • 관련 PRD
  • OP-001 로그인안됨 심각단계 : L2
    • PKIV-새벽에 잠깨는 ,로그인해결개발티켓

 위와같이 한가지 개발 프로세스가 PRD를 통하여 연관 작업을 모두 파악할수 있으며

반대로, 장애 이슈를 통해서도 이 이슈의 태초의 이슈인 프로덕 요구사항을 파악할수가 있습니다.

새벽에 나의 잠을 깨운 티켓및 담당자 추적도 가능합니다. 

이야기가 정리없이 길었지만

이것의 중요한 의미는 서사시(epic)가  축적이되어 우리의 자산(백과사전)이 된다라는 것입니다.

현재 개발 프로세스를 다시 공부하면서 다음 4가지를 통합 구축중에 있습니다.

JIRA : http://jira.webnori.com/secure/BrowseProjects.jspa?selectedCategory=all&selectedProjectType=all

빌드/배포 CI툴 : http://bam.webnori.com/allPlans.action

GIT툴 : http://git.webnori.com/dashboard

개발 프로세스와 연동되는 문서화 기능  : http://wiki.webnori.com/