FF11 서버 제작을 시작하면서 개인적으로 꼭 구현하고 싶었던 기능 중 하나가 있었다.

바로 트리거 팝 NM의 등장 애니메이션이다.

리테일 FF11에서는 ???에 아이템을 트레이드하거나 특정 조건을 만족시켜 NM을 소환하면 몬스터가 그냥 갑자기 나타나는 것이 아니라, 고유의 등장 모션과 함께 모습을 드러낸다.

별것 아닌 것처럼 보일 수도 있지만 개인적으로는 이런 작은 연출들이 FF11 특유의 분위기를 만들어주는 중요한 요소라고 생각한다.

하지만 기존 LSB에서는 트리거 팝 NM을 소환하면 이러한 등장 연출 없이 몬스터가 바로 생성된다.

서버 진행이나 전투 자체에는 문제가 없기 때문에 LSB에서는 상대적으로 우선순위가 낮은 부분이었고, 아직까지 제대로 구현되어 있지 않았다.

하지만 나는 처음 서버를 만들기 시작했을 때부터 이 부분이 계속 아쉬웠다.

언젠가는 꼭 리테일과 같은 방식으로 구현하고 싶다고 생각했는데, 결국 약 8개월 만에 트리거 팝 NM의 등장 애니메이션을 구현하는 데 성공했다.

이번 수정은 특정 NM 하나에만 적용되는 방식이 아니다.

트리거 방식으로 소환되는 NM들이 등장할 때 리테일과 같은 등장 애니메이션이 나오도록 처리했기 때문에, 이제 서버의 모든 트리거 팝 NM에서 등장 연출을 볼 수 있게 되었다.

그리고 이번 작업과 함께 또 하나 오랫동안 아쉬웠던 부분도 수정했다.

바로 몬스터가 사용하는 소환수의 등장 애니메이션이다.

기존 LSB에서는 몬스터가 펜릴 같은 소환수를 불러낼 경우 소환수가 별도의 연출 없이 바로 생성된다.

리테일에서는 소환수가 등장할 때 중앙에 소환 원이 나타나고 그 안에서 소환수가 모습을 드러내지만, 기존 LSB에서는 이 과정이 생략되어 있었다.

이번에는 xi.mob.callPets()를 기반으로 소환되는 몬스터 소환수에 등장 애니메이션이 적용되도록 수정했다.

특히 지난 개발일지에서 소개했던 듀나미스 보스딘의 Hydra NM Dagourmarche(다고르마슈)에서 그 차이를 확실하게 확인할 수 있다.

다고르마슈는 와이번과 펜릴을 동시에 소환하는 NM이다.

지난 작업에서 와이번이 주인을 제대로 추종하지 않던 문제와 펜릴 소환, BST의 2시간 어빌리티인 매료 등 주요 기믹을 리테일과 동일하게 구현하면서 다고르마슈의 전투 기믹은 모두 완성했다.

그리고 이번에는 마지막으로 남아 있던 연출까지 손을 봤다.

다고르마슈가 등장할 때 트리거 팝 NM 특유의 등장 애니메이션이 재생되고, 펜릴 역시 단순히 갑자기 나타나는 것이 아니라 소환 원이 생성된 후 그 안에서 등장한다.

여기에 펜릴이 등장 직후 포효하는 모션까지 리테일과 동일하게 구현했다.

기존 LSB에서는 펜릴이 소환되면 그냥 등장하고 끝이었기 때문에, 직접 비교해 보면 느낌의 차이가 상당히 크다.

전투 기믹만 놓고 보면 없어도 플레이에는 문제가 없는 기능이다.

하지만 개인적으로는 이런 작은 부분까지 제대로 구현되어야 내가 기억하고 있는 75시대 FF11에 조금이라도 가까워질 수 있다고 생각한다.

서버 기능 구현에서는 상대적으로 중요도가 낮아 보이는 부분일 수도 있지만, 그래서 오히려 내가 직접 구현하고 싶었던 부분이기도 했다.

처음부터 꼭 만들어보고 싶었던 기능 하나를 8개월 만에 드디어 완성했다.

그리고 다고르마슈 역시 기믹뿐만 아니라 등장과 소환 연출까지 모두 구현하면서 이제야 정말 완성됐다는 느낌이 든다.

이번 작업은 꽤 만족스럽다. ㅋㅋ

2026.08.08 - [파이날 판타지11/LSB서버 개발일지] - FF11 LSB 개발일지 5 - Dagourmarche 기믹 구현

간만에 FF11 LSB 개발일지를 작성한다.

오늘 소개할 NM은 듀나미스 - 보스딘의 하이드라 NM 중 하나인 Dagourmarche(다고르마슈)다.

듀나미스 - 보스딘의 하이드라 NM들은 여러 직업의 특성을 동시에 가지고 있으며, 각각 3개의 2H 어빌리티를 사용하는 하이브리드형 NM이다.

그래서 일반적인 NM에 비해 기믹을 구현하고 밸런스를 맞추는 과정이 상당히 까다로웠는데, 그중에서도 개인적으로 가장 구현하기 어려웠던 NM이 바로 Dagourmarche였다.

Dagourmarche의 가장 큰 특징은 전투 중 Wyvern(와이번)과 Fenrir(펜릴)를 동시에 소환한다는 점이다. 여기에 BST의 2H 어빌리티인 Charm(매료)까지 사용한다.

하나의 NM에 여러 종류의 기믹이 동시에 들어가 있는 셈이다.

가장 골치 아팠던 Wyvern(와이번)

Dagourmarche를 구현하면서 개인적으로 가장 어려웠던 부분은 의외로 Wyvern의 추종 문제였다.

일반적인 DRG(용기사) 타입 몬스터가 소환하는 Wyvern은 아무런 문제가 없었다.

다른 DRG 타입 몬스터들을 테스트해 보면 주인이 이동할 때 Wyvern도 정상적으로 주인을 따라 이동한다.

그런데 Dagourmarche에서만 문제가 발생했다.

Wyvern 자체는 정상적으로 소환됐다.

문제는 그다음이었다.

Dagourmarche가 이동해도 Wyvern이 주인을 따라오지 않고 소환된 장소에 그대로 남아버렸다.

기존 DRG 타입에서는 정상적으로 작동하는 기능이 Dagourmarche에서는 제대로 동작하지 않았기 때문에 처음에는 원인을 찾는 것부터 쉽지 않았다.

여러 부분을 수정하고 또 수정하면서 계속 테스트했지만 좀처럼 해결되지 않았다.

더보기

단순히 따라오지 않는 것으로 끝나는 문제가 아니었다

Dagourmarche의 Wyvern이 주인을 추종하지 않는 것은 단순히 보기 어색한 정도로 끝나는 문제가 아니었다.

Dagourmarche가 팝하는 장소 주변은 전투하기에 상당히 좁다.

그리고 팝 장소에서 바로 바깥으로 나가면 일반 몬스터들이 있기 때문에 그 자리에서 전투를 진행하기에도 상당히 부담스럽다.

특히 Dagourmarche가 소환하는 Avatar의 Astral Flow는 잘못 맞으면 파티가 전멸할 수도 있을 정도로 강력하다.

때문에 실제 전투에서는 주변 몬스터의 방해를 받지 않으면서 충분한 공간을 확보할 수 있는 몹이 없고 넓은 장소까지 Dagourmarche를 끌고 이동해서 상대하는 것이 안전하다.

그런데 Dagourmarche만 이동하고 Wyvern이 처음 소환된 장소에 그대로 남아버린다면 이러한 전투 방식 자체가 제대로 성립하지 않는다.

결국 리테일과 동일한 전투를 재현하기 위해서는 Wyvern이 Dagourmarche를 정상적으로 따라 이동하도록 만드는 것이 반드시 필요했다.

한 번은 포기했던 기믹

사실 처음에는 이 문제를 결국 해결하지 못했다.

계속 붙잡고 있어도 해결되지 않아 한동안 Wyvern을 포기하고 다른 기믹으로 대체해서 Dagourmarche를 구현하기도 했다.

전투 자체는 그것으로도 가능했다.

하지만 아무리 생각해도 마음에 들지 않았다.

기왕 구현하는 것이라면 리테일과 동일하게 만들고 싶었다.

결국 다시 Dagourmarche의 기믹을 붙잡았다.

여러 부분을 다시 확인하고 수정과 테스트를 반복했고, 결국 가장 골치 아팠던 Wyvern이 주인인 Dagourmarche를 정상적으로 추종하도록 만드는 데 성공했다.

이후 Wyvern과 Fenrir의 동시 소환을 비롯해 Charm과 2H 어빌리티 등 Dagourmarche가 가지고 있는 기믹들을 다시 확인하면서 최종적으로 리테일과 동일한 전투 흐름을 구현할 수 있었다.

Astral Flow까지 정상 작동

그리고 Dagourmarche 전투에서 가장 무서운 것 중 하나가 바로 Avatar의 Astral Flow다.

제대로 맞으면 정말 아프다.

경우에 따라서는 한 번의 Astral Flow로 파티가 거의 전멸할 수도 있다. ㅋㅋ

위 스크린샷은 Dagourmarche가 원래 팝하는 장소에서 찍은 것이 아니다.

실제 전투를 위해 주변 몬스터가 없고 공간이 넓은 장소까지 Dagourmarche를 끌고 이동한 상태다.

사진을 보면 Dagourmarche와 함께 Wyvern도 정상적으로 주인을 따라 이동해 있는 것을 확인할 수 있고, 동시에 소환된 Avatar의 Astral Flow 역시 정상적으로 작동하고 있다.

사진 한 장이지만 이번 Dagourmarche 구현에서 확인하고 싶었던 핵심적인 부분들을 대부분 보여주는 장면이기도 하다.

듀나미스 하이드라 NM 기믹 구현 완료

Dagourmarche는 한때 구현을 포기했던 NM이었다.

특히 다른 DRG 타입 몬스터에서는 아무런 문제가 없었던 Wyvern의 추종이 Dagourmarche에서만 제대로 작동하지 않아 해결하는 데 상당한 시간이 필요했다.

그래도 결국 다시 붙잡고 문제를 해결하면서 리테일과 동일한 Dagourmarche의 기믹을 구현하는 데 성공했다.

그리고 Dagourmarche를 마지막으로 듀나미스 - 보스딘 하이드라 NM들의 모든 기믹 구현도 완료했다.

하이드라 NM들은 기본적으로 3개의 2H 어빌리티를 사용하는 만큼 다른 NM보다 구현과 밸런스 조정이 어려웠지만, 그중에서도 Dagourmarche는 가장 까다로운 NM이었다.

구현하는 동안에는 정말 골치 아팠지만, 실제 전투에서 Wyvern과 Avatar가 함께 움직이고 각종 기믹들이 의도했던 대로 하나씩 작동하는 모습을 보니 꽤 뿌듯하다.

결국 이 맛에 기믹을 구현하는 것 같다. ㅋㅋ

나는 2017년 부터 티스토리 블로그에 개인 도메인 siguma.co.kr을 연결해서 사용하고 있다.

카카오 애드핏도 지금처럼 티스토리 관리자에서 계정을 연동하고 광고 위치를 설정하는 기능이 생기기 전부터 사용했다.

당시에는 개인 도메인을 애드핏 매체로 직접 등록하고 광고 코드를 스킨에 삽입하는 방식이었고, siguma.co.kr 역시 정상적으로 심사를 통과해 지금까지 승인 상태로 남아 있다.

그런데 티스토리에 애드핏 수익 관리 기능이 생기면서 문제가 발생했다.

기존 승인 매체가 있는데 또 다른 매체가 만들어졌다

현재 내 애드핏에는 같은 블로그를 대상으로 사실상 두 개의 매체가 등록되어 있다.

• siguma.co.kr : 기존 개인 도메인 매체 / 승인
• siguma.tistory.com : 티스토리 연동 매체 / 심사 반려

처음에는 왜 티스토리 기본 도메인이 별도의 매체로 등록되어 있는지 이해하기 어려웠다.

나는 이미 siguma.co.kr로 애드핏 승인을 받아 사용하고 있었기 때문이다.

하지만 티스토리 고객센터에 문의한 결과 현재 티스토리 수익센터의 애드핏 연동은 기존에 애드핏에서 승인받은 개인 도메인 매체를 사용하는 방식이 아니었다.

티스토리 수익센터에서는 티스토리 블로그 주소를 기준으로 애드핏 연동 매체가 생성되며, 개인 도메인으로 별도 승인받은 기존 매체를 연동 매체로 지정할 수 없다고 한다.

즉, 기존에 siguma.co.kr이 정상 승인되어 있어도 티스토리 관리자에서는 이 매체를 사용할 수 없다.

티스토리 기본 도메인은 왜 심사 반려됐을까?

그렇다면 티스토리에서 자동으로 연결된 siguma.tistory.com을 사용하면 되는 것 아닌가 싶지만 여기서 또 문제가 발생한다.

카카오 애드핏 고객센터에 확인한 결과 siguma.tistory.com은 동일 매체고유값 등록을 이유로 심사 반려된 상태였다.

이미 승인되어 있는 siguma.co.kr과 동일한 블로그로 확인되기 때문에 티스토리 연동으로 만들어진 siguma.tistory.com이 중복 매체로 판정된 것이다.

결국 같은 블로그를 두고 siguma.co.kr은 이미 승인되어 있는데 티스토리에서는 사용할 수 없고,

티스토리가 사용하는 siguma.tistory.com은 기존 매체와 동일하다는 이유로 반려된 상태가 되어버렸다.

그래서 애드핏 광고 설정도 저장되지 않는다

현재 티스토리 관리자에서

수익 → 애드핏 관리 → 광고 설정

으로 들어가면 광고 위치와 크기를 선택하는 화면 자체는 정상적으로 나온다.

하지만 광고를 설정한 뒤 변경사항 저장을 누르면 저장 실패가 발생한다.

이전다음

01

처음에는 티스토리의 단순한 저장 오류라고 생각했다.

하지만 고객센터 답변을 통해 현재 티스토리 수익센터에 연결된 애드핏 매체가 심사 반려 상태이기 때문에 광고 위치를 설정하거나 광고를 노출할 수 없다는 사실을 확인했다.

그러니까 저장 실패 자체의 원인은 확인된 셈이다.

문제는 왜 정상 승인된 기존 매체를 사용할 수 없어서 이런 상태가 만들어졌느냐는 것이다.

광고는 안 나오는데 kakaoAdFit 빈 영역은 남아 있다

또 하나 이상했던 부분은 실제 광고가 나오지 않는데도 블로그 본문에 kakaoAdFit이라는 글자만 표시된 빈 광고 영역이 계속 남아 있었다는 것이다.

이 부분 역시 티스토리 고객센터에 확인했다.

답변에 따르면 예전에 저장되어 있던 광고 위치 정보가 남아 있기 때문에 광고 영역만 표시되고 있는 것이라고 한다.

현재 매체가 반려 상태라 실제 광고는 나오지 않는다.

결국 현재 상태는 이렇다.

애드핏 매체 심사 반려 → 광고 설정 저장 불가 → 실제 광고 노출 불가 → 과거 설정 정보 때문에 빈 kakaoAdFit 영역만 출력

정말 깔끔하지 못한 상태다.

다음 티스토리 고객센터의 답변

티스토리 고객센터 답변을 통해 가장 중요한 사실 하나는 명확해졌다.

개인 도메인으로 별도 승인받은 애드핏 매체를 티스토리 수익센터의 연동 매체로 지정할 수 없다.

이게 현재 문제의 핵심이라고 생각한다.

나는 애드핏 수익센터 연동 기능이 만들어진 이후에 처음 애드핏을 사용한 것이 아니다.

이 기능이 생기기 전부터 당시 제공되던 방식에 따라 개인 도메인을 애드핏에 등록하고 정상적인 심사 절차까지 거쳐 사용하고 있었다.

그런데 새로운 시스템에서는 기존 승인 매체를 가져와서 사용할 방법이 없다.

애드핏의 해결책은 기존 승인 매체를 삭제하라는 것

그렇다면 기존 사용자는 어떻게 해야 할까?

카카오 애드핏 고객센터에서 받은 답변은 기존에 승인된 siguma.co.kr 매체를 삭제한 뒤 siguma.tistory.com의 재심사를 요청하라는 것이었다.

여기서 가장 이해가 되지 않았다.

기존 시스템에서 정상적으로 승인받아 사용하고 있던 매체를 새로운 티스토리 연동 시스템에서 사용할 수 없다는 이유로 사용자가 직접 삭제하고 다시 심사를 받아야 한다는 것이다.

현재 구조를 순서대로 보면 이렇다.

기존 개인 도메인 siguma.co.kr로 애드핏 정상 사용

↓

티스토리에 새로운 애드핏 연동 시스템 추가

↓

기존 개인 도메인 승인 매체는 티스토리 수익센터에서 사용 불가

↓

티스토리 기본 주소 siguma.tistory.com으로 별도 매체 생성

↓

기존 매체와 동일한 블로그라 동일 매체고유값으로 심사 반려

↓

티스토리에서 광고 설정 불가

↓

기존에 정상 승인된 매체를 삭제하고 다시 심사받으라는 안내

이게 과연 기존 이용자를 위한 정상적인 이전 방식인지 모르겠다.

기존 사용자를 위한 이전 방법은 왜 없는 걸까?

새로운 시스템을 만드는 것 자체가 문제라는 이야기는 아니다.

예전처럼 스킨에 광고 소스를 직접 삽입하는 방식보다 관리자 화면에서 광고 위치를 선택해서 관리할 수 있는 방식이 훨씬 편하다.

문제는 새로운 시스템이 만들어지기 전부터 서비스를 이용하던 사람들을 어떻게 새 시스템으로 옮길 것인지에 대한 방법이 보이지 않는다는 것이다.

특히 개인 도메인으로 애드핏을 사용했던 기존 티스토리 이용자라면 나와 같은 문제가 발생할 수 있다.

더 이해하기 어려운 것은 카카오 애드핏에서도 siguma.co.kr과 siguma.tistory.com이 같은 블로그라는 것을 동일 매체고유값을 통해 이미 확인하고 있다는 점이다.

같은 매체라는 것을 확인할 수 있다면 기존 siguma.co.kr의 승인 상태를 siguma.tistory.com으로 이관하거나, 기존 승인 매체를 티스토리 수익센터와 연결할 수 있도록 해주는 방식이 더 자연스럽지 않을까?

이 부분에 대해서도 카카오 애드핏 고객센터에 다시 문의했다.

기존 siguma.co.kr의 승인 상태를 siguma.tistory.com으로 이관하거나 두 매체를 통합하는 방식으로 처리할 수 없는지 확인했지만, 승인 상태 이관과 매체 통합 모두 지원하지 않는다는 답변을 받았다.

결국 카카오 애드핏에서 제시한 방법은 하나뿐이다.

기존에 정상 승인되어 있는 siguma.co.kr 매체를 삭제하고, 동일 매체 등록 문제가 해소된 이후 siguma.tistory.com을 신규 매체로 등록해 다시 심사를 받는 것이다.

같은 블로그라는 사실까지 시스템에서 확인하고 있으면서 기존 승인 상태를 승계하거나 매체를 통합하는 방법은 없고, 기존 이용자가 정상적으로 사용하던 매체를 직접 삭제한 뒤 처음부터 다시 심사를 받아야 한다.

새로운 시스템을 만들면서 그 이전부터 서비스를 사용하던 이용자를 위한 이전 절차가 사실상 마련되어 있지 않았다는 점은 여전히 이해하기 어렵다.