https://aion2.plaync.com/ko-kr/board/notice/view?articleId=6926ceb0ea4d6621c8192da3

요약하면 이 공지는
“신규 서버를 미리 켜놓고 QA 하다가, 설정·보안 구멍 때문에 외부에서 패킷 변조로 접속 → 캐릭터가 만들어졌다.
해킹은 아니고, 지금은 막았고, 나중에 초기화하겠다”
라고 말하는 공지예요.

여기서 문제 삼을 수 있는 지점들을 나눠볼게.

1. “해킹이 아니다” vs “패킷 변조 취약점”

“우려하시는 것과 달리 해킹에 의한 문제는 아니라는 점”
“패킷을 변조해 해당 서버에 로그인할 수 있는 취약점이 있었고…”

• 일반 유저 입장에서는 ‘패킷 변조로 비정상 로그인’ = 전형적인 해킹/불법 접속으로 받아들여요.
• 그런데 문장 구성은
  • “해킹은 아님” → “근데 패킷 변조 취약점이 있었고 그걸로 비정상 접속함”
    이런 구조라, 실질적인 내용과 용어 선택이 충돌합니다.
• 결과적으로 “우리 잘못이라기보단, 일부 유저가 꼼수 쓴 것”처럼 책임을 희석하려는 인상을 줄 수 있어요.

2. “한정된 QA 인원만 접근 가능했다”는 말의 설득력 부족

“한정된 QA인원만 접근할 수 있는 상태로 서버를 점검하던 중”
“외부로부터의 네트워크 접속이 차단되지 않은 이유로…”

• 정말로 “한정된 QA 인원만 접근” 가능한 상태였다면:
  • 내부망만 허용하거나,
  • VPN·IP 화이트리스트·계정 접근 제어가 깔끔하게 되어 있어야 합니다.
• 그런데 바로 뒤에 “외부 네트워크 차단이 안 되어 있었다”고 하니까,
  • 실제로는 그냥 일반 인터넷에서 접속 가능한 상태였던 것처럼 읽혀요.
• 즉, 접근 제어가 제대로 된 적이 없는 상태인데 ‘한정된 QA 인원만 접근할 수 있는 상태’라고 표현해서,
  현실을 미화한 느낌이 강합니다.

3. 구조적인 보안 문제를 “설정 오류” 수준으로 축소

“접근 권한의 설정 오류… 외부로부터의 네트워크 접속이 차단되지 않은 이유로…”

• 이 정도면 단순한 ‘설정 실수’가 아니라,
  • 테스트 서버와 외부망 분리 실패
  • 권한 관리·네트워크 정책 부재
    같은 보안 설계 레벨의 문제에 가깝습니다.
• 그런데 공지에서는 이를 “설정 오류”와 “네트워크 차단 미비” 정도로 완곡하게 표현하고 있어서,
  • 회사 차원에서 이 사안을 얼마나 심각하게 보고 있는지 의문이 생깁니다.
• 특히, 실 서비스 MMO에서 “테스트용 서버를 외부에 노출한 상태로 띄워 둔 것” 자체가 상당히 기초적인 실수인데,
  그 심각도에 비해 표현이 너무 가볍습니다.

4. 유저 입장에서 제일 중요한 “공정성 / 영향 범위” 설명이 부족

유저가 궁금한 건 대략 이런 것들일 텐데요:

1. 얼마나 많은 캐릭터가 만들어졌는가?
2. 닉네임 선점, 자원/정보 선점 등 실제 이득이 있었는가?
3. 해당 계정들은 어떻게 처리되는가? (영구정지·제재 여부)
4. 내가 접속한 기존 서버/계정 보안은 안전했는가?

그런데 공지는:

• “거래소 등 관련 시스템 영향 확인 중”
• “캐릭터 생성 제한 또는 대기열에는 영향 없음”

정도만 이야기해요.

문제점:

• 닉네임/초기 자리 선점 같은 공정성 이슈에 대해 직접적으로 다루지 않음.
• “데이터 초기화 예정”이라지만,
  • ‘언제’
  • ‘어디까지(어떤 범위의 데이터)’
  • ‘예외 없이 전부 삭제되는지’
    명확히 못 박지 않고, **“초기화 및 삭제 조치가 확정되는 즉시”**라는 모호한 표현만 써요.
• 악용한 계정에 대한 제재 방침 언급도 없음 → “해킹은 아니고 취약점이었고… 어쨌든 막았다” 정도로 끝나는 느낌.

결국, **“유저 입장에서 가장 민감한 ‘불공정’ 우려를 정면에서 다루지 않았다”**는 게 큰 비판 포인트입니다.

5. 사건의 범위·타임라인이 불투명

• 언제부터 서버가 열려 있었는지
• 언제 첫 비정상 접속이 발생했고
• 언제 이를 인지해 조치했는지
  이런 타임라인이 전혀 나오지 않습니다.

이게 빠지면:

• “생각보다 훨씬 오랫동안 방치된 거 아닌가?”
• “발생 후에도 인지·대응이 느린 거 아닌가?”

라는 불신을 만들기 쉽죠.

또, 영향 범위도:

• “신규 서버만 문제였는지”
• “기존 서버 계정/데이터는 완전히 분리·안전했는지”

를 분명하게 못 박지 않아서, 전체 서비스 안정성에 대한 불안이 남습니다.

6. “내부 검증 및 보안 절차 강화”의 구체성이 없음

“접근 제어 체계를 전면 재점검”
“내부 검증 및 보안 절차를 더욱 강화하겠습니다”

• 사건 후 공지에서 항상 나오는 전형적인 문구인데,
  • 무엇을 / 어떻게 / 어느 수준까지 바꾸는지에 대한 구체적 내용은 전혀 없습니다.
• 예를 들면 이런 식의 내용이 있으면 조금 더 신뢰를 줄 수 있었어요:
  • 테스트 서버는 원칙적으로 내부망/VPN에서만 접근
  • 외부 노출 서버는 WAF·방화벽 규칙 재정비
  • 계정/세션/패킷 검증 로직 개선 계획
• 지금 문구만 보면, “형식적인 사과 + 추후에 잘할게요” 수준으로 느껴지기 쉽습니다.

7. 유저와의 신뢰 회복을 위한 “실질적 조치” 언급 부재

사과문에는 보통 이런 요소들이 있으면 좋습니다:

• 피해/불안에 대한 보상 또는 보상 계획
  (예: 정식 오픈 시 전 서버 공통 보상, 사전예약자 추가 혜택 등)
• 재발 방지를 위한 제3자 보안 점검/컨설팅 등 외부 검증 계획
• 악용 계정에 대한 명확한 제재 정책

하지만 이 공지는:

• 사과 + 기술적 설명 + “초기화 예정” 정도에 그쳐 있어요.
• 특히, 기다리던 신규 서버에 생긴 이슈라 유저 감정은 더 예민한데,
  • 그에 비해 “진정시키려는 실질적인 제스처”가 부족합니다.

정리

이 해명문에서 비판할 수 있는 핵심 포인트를 한 줄씩 정리하면:

1. “해킹은 아니다”라고 선 긋는 표현이, 실제 내용(패킷 변조 취약점 악용)과 어긋난다.
2. “한정된 QA 인원만 접근 가능했다”는 표현에 비해, 네트워크 설정 상태는 그에 미치지 못한 것으로 보인다.
3. 보안 구조 문제를 단순 “설정 오류” 수준으로 축소해서 설명하고 있다.
4. 유저가 가장 신경 쓰는 공정성(닉네임·자원 선점, 제재 여부)에 대한 답변이 부족하다.
5. 사건 발생 시점·기간·영향 범위에 대한 타임라인이 없어 신뢰감이 떨어진다.
6. 재발 방지 대책이 구체적이지 않고, 형식적인 사과문에 그친다.
7. 신뢰 회복을 위한 실질적인 보상/대응(제재, 보상, 외부 검증 등) 계획이 빠져 있다.

김키티