[카테고리:] 삽질의 추억

최근 유니티를 활용해 간단한 탱크 게임 사이드 프로젝트를 진행하고 있습니다. 백엔드 개발이 주력이지만, 풀스택을 지향하며 클라이언트 엔진인 유니티도 조금씩 다뤄보는 중입니다.

그런데 프리팹(Prefab)을 정리하고 계층 구조(Hierarchy)를 수정하던 중, 멀쩡하게 잘 나오던 주인공 탱크(PlayerTank) 오브젝트가 갑자기 이상하게 변해버렸습니다.

1. 문제 상황: 갑자기 형광 주황색으로 변해버린 탱크

아래 이미지처럼, 탱크의 형태는 그대로 유지되고 있지만 표면이 온통 **형광 주황색(또는 밝은 마젠타색)**으로 뒤덮여 버린 것입니다.

텍스처가 깨진 것 같기도 하고, 조명 문제인가 싶어 이리저리 설정을 건드려봤지만 게임을 실행해도 여전히 저 눈 아픈 색상은 사라지지 않았습니다. 유니티를 처음 접하는 입장에서 굉장히 당황스러운 순간이었습니다.

2. 원인 분석: 범인은 Mesh Renderer 컴포넌트

구글링과 유니티 문서를 찾아본 결과, 유니티 엔진에서 이 강렬한 마젠타(Magenta) 색상은 “무언가 잘못되었다”는 것을 알리는 디버그 색상이라는 것을 알게 되었습니다.

가장 흔한 원인은 Mesh Renderer(메시 렌더러) 컴포넌트에 재질(Material)이 제대로 연결되지 않았을 때 발생합니다. 즉, 유니티 엔진이 “이 3D 모델의 형태는 알겠는데, 표면에 어떤 색이나 질감을 입혀야 할지 모르겠다”라고 신호를 보내는 것입니다.

문제가 발생한 PlayerTank 오브젝트를 선택하고 인스펙터(Inspector) 창을 확인해 보았습니다.

예상대로 Mesh Renderer 컴포넌트 하위의 Materials 항목을 열어보니, Element 0 자리가 비어있거나(None), 혹은 연결이 끊겨서 ‘Missing Material’ 같은 상태로 표시되고 있었습니다. 프로젝트 폴더를 정리하면서 재질 파일의 경로가 바뀌었거나 실수로 연결을 끊은 것이 원인이었습니다.

3. 해결 방법: 올바른 Material 재할당

원인을 알았으니 해결 방법은 간단합니다. 잃어버린 재질을 다시 찾아 연결해 주면 됩니다.

1. Hierarchy 창에서 색상이 이상하게 나오는 오브젝트(제 경우는 PlayerTank)를 선택합니다.
2. Inspector 창에서 Mesh Renderer 컴포넌트를 찾습니다.
3. Materials 메뉴를 펼쳐서 비어있는 슬롯(Element 0 등)을 확인합니다.
4. 프로젝트(Project) 창의 Assets 폴더에서 해당 오브젝트에 적용할 올바른 Material 파일을 찾습니다.
5. 찾은 Material 파일을 드래그하여 Inspector 창의 비어있는 슬롯에 놓아줍니다. (또는 슬롯 옆의 동그라미 버튼을 눌러서 선택 창에서 골라줍니다.)

재질을 다시 연결하자마자, 아래와 같이 원래의 멋진 탱크 모습으로 돌아왔습니다.

4. 마무리 및 배운 점 (개발 일지)

이번 삽질을 통해 유니티에서 **’강렬한 핑크색/주황색 = 재질(Material) 또는 셰이더(Shader) 오류’**라는 공식을 확실하게 배웠습니다.

백엔드에서 NullPointerException을 만나는 것처럼, 유니티 개발에서 가장 흔하게 마주치는 기초적인 실수 중 하나라고 합니다. 앞으로 에셋을 임포트 하거나 프로젝트 폴더 구조를 변경할 때, 연결 정보가 끊기지 않았는지 꼭 확인하는 습관을 들여야겠습니다.

혹시 저처럼 갑자기 오브젝트가 형광색으로 변해 당황하신 분들이 있다면, 제일 먼저 Mesh Renderer의 Materials 슬롯을 확인해 보시기 바랍니다.

이 글은 “애드센스 승인 노하우”를 말하려는 글이 아니다.
그보다는 실제로 워드프레스를 설치하고, 도메인을 연결하고, 애드센스를 신청하면서 겪었던 시행착오를 정리한 기록에 가깝다.

누군가에게는 별것 아닐 수 있지만, 처음부터 끝까지 직접 해보면서 “아, 여기서 다들 막히겠구나” 싶은 지점들이 분명히 있었다.

---

시작은 단순했다

• 개인 기술 블로그를 하나 만들어보자
• 워드프레스 + 개인 도메인
• 나중에 애드센스까지 연결

요즘은 워드프레스 설치 자체는 정말 쉽다.
카페24의 매니지드 워드프레스를 사용했기 때문에 설치 과정에서 막히는 부분은 거의 없었다.

문제는 그 다음부터였다.

---

첫 번째 삽질: HTTPS가 바로 안 됨

도메인을 연결하고 나면 자연스럽게 HTTPS가 바로 될 거라 생각했다.
하지만 현실은 그렇지 않았다.

• HTTP는 접속되는데
• HTTPS는 ERR_SSL_PROTOCOL_ERROR
• 카페24 무료 SSL 진단에서는 “443 포트 접근 실패”

알고 보니:

• 무료 SSL은 자동 발급이지만
• 도메인 연결 타이밍, 재발급 여부에 따라
• 몇 시간~하루 이상 지연될 수 있었다

결국 SSL 재발급 요청을 한 뒤에야 정상 동작했다.

(이것 때문에 2~3일 동안 매일 틈 날 때마다 접속시도 했다 -_-;;;;, 결과적으로 3일 날려먹음 ㅠ.ㅠ)

👉 교훈:
“무료 SSL 포함”이라는 문구를 너무 그대로 믿지 말 것.
문제 생기면 재발급부터 눌러보는 게 빠르다.

---

두 번째 삽질: ads.txt는 생각보다 까다롭다

애드센스 신청 과정에서 가장 시간을 잡아먹은 건 단연 ads.txt였다.

애드센스에서는 이렇게 말한다:

ads.txt 파일을 사이트 루트에 업로드하세요.

문제는 이 “루트”가
FTP 기준 루트인지,
웹 기준 루트인지
처음엔 감이 잘 안 온다는 점이다.

나는 처음에:

/계정명/ads.txt

에 파일을 만들었고,
브라우저에서 https://도메인/ads.txt는 계속 404였다.

알고 보니 실제 웹 루트는:

/계정명/www/

였다.

ads.txt를 이 위치로 옮기자마자 바로 해결됐다.

👉 교훈:
“.htaccess가 있는 곳 ≠ 웹에서 접근되는 루트일 수 있다.”
반드시 브라우저로 도메인/ads.txt 직접 확인해야 한다.

---

세 번째 삽질: CMP는 승인 조건이 아니다

애드센스 마지막 단계에서 “동의 메시지(CMP)” 설정 화면이 나온다.

처음엔:

• 이걸 지금 꼭 완벽하게 설정해야 하나?
• 쿠키 배너 플러그인부터 설치해야 하나?

라는 고민이 들었다.

결론부터 말하면:

• 지금 단계에서는 간단한 Google CMP 선택만 해도 충분
• 승인 이후에 언제든 수정 가능

괜히 심사 중에 플러그인 잔뜩 설치했다가
사이트 구조를 건드리는 게 더 위험할 수 있다.

👉 교훈:
심사 중에는 ‘완벽’보다 ‘안정’이 중요하다.

---

지금 상태

현재는:

• 도메인 정상 연결
• HTTPS 정상
• ads.txt 통과
• 애드센스 심사 대기 중

이 글은 심사 중에 “사이트가 실제로 운영 중”임을 보여주기 위한
하나의 운영 기록이기도 하다.

---

마무리

워드프레스 + 애드센스 조합은 분명 진입장벽이 낮아졌지만,
여전히 초반에는 자잘한 삽질이 필연적이다.

다만 직접 해보니 느낀 점은 하나다.

“한 번만 제대로 넘기면,
그 다음부터는 꽤 안정적으로 굴러간다.”

이 기록이 나중의 나에게도,
혹은 비슷한 길을 가는 누군가에게도
작은 참고가 되었으면 한다.

워드프레스 블로그를 개설하고 나면
테마 수정이나 파일 관리 때문에
FTP 또는 SFTP 접속이 필요한 순간이 반드시 생깁니다.

backendnote 역시
초기 설정 과정에서 파일을 직접 확인하기 위해
SFTP 접속을 시도했고,
그 과정에서 예상보다 많은 시행착오를 겪었습니다.

이 글은
카페24 워드프레스 환경에서 SFTP 접속을 설정하며
직접 겪었던 문제와 해결 과정을 정리한 기록입니다.

---

처음 시도했던 방식과 문제 상황

일반적인 서버 환경에서는
SSH 키를 생성하고 이를 이용해 SFTP 접속을 설정합니다.
그래서 처음에는 익숙한 방식대로
SSH 키를 생성하고,
FileZilla를 이용해 접속을 시도했습니다.

하지만 접속 과정에서 계속 다음과 같은 문제가 발생했습니다.

• 키 파일을 인식하지 못하는 오류
• 인증은 시도되지만 접속이 거부되는 현상
• 동일한 설정을 반복해도 결과가 바뀌지 않음

설정 자체가 잘못된 것인지,
호스팅 환경의 제약인지 판단하기가 쉽지 않았습니다.

---

시행착오의 원인

문제의 핵심은
카페24 워드프레스 호스팅 환경의 구조를 정확히 이해하지 못한 것이었습니다.

카페24의 워드프레스 호스팅은
일반적인 VPS나 클라우드 서버와 다르게
접근 가능한 계정과 권한이 제한되어 있습니다.

특히 다음 부분에서 혼란이 생겼습니다.

• root 계정은 사용 불가
• SSH 키 방식은 제한적으로만 지원
• 접속 계정은 반드시 호스팅 계정 ID 사용

이 차이를 인지하지 못한 상태에서
일반 서버 기준으로 설정을 시도하다 보니
문제가 반복되었습니다.

---

상태:	backendnote.com에 연결...
상태:	비정상적인 문자열이 수신되어 UTF-8을 해제합니다. UTF-8 강제 사용은 사이트 관리자에서 선택하십시오.
상태:	Unable to use key file "C:\SSH\putty_key_files.ppk" (unable to open file) 
상태:	Using username "root". 
상태:	Server refused our key 
상태:	Access denied 
오류:	인증 실패.
오류:	치명적 오류: 서버에 연결하지 못함
상태:	서버와의 연결이 종료됨

---

해결 방법 정리

문제를 하나씩 정리한 뒤
다음과 같은 방식으로 접근하니 정상적으로 접속할 수 있었습니다.

1. 접속 계정 확인
   • root 계정이 아닌
     카페24에서 제공하는 호스팅 계정 ID 사용
2. 접속 방식 단순화
   • 불필요한 설정 제거
   • 기본 SFTP 접속 방식부터 확인
3. 호스팅 환경 기준으로 재설정
   • 일반 서버 기준 설명이 아닌
     카페24 환경에 맞는 설정 적용

결국 설정 자체는 복잡하지 않았지만,
환경에 대한 이해가 부족했던 것이
가장 큰 원인이었습니다.

---

느낀 점

이번 경험을 통해 다시 한 번 느낀 점은
호스팅 환경마다 전제 조건이 다르다는 사실이었습니다.

온라인에 있는 많은 자료는
VPS나 클라우드 서버 기준으로 작성되어 있기 때문에,
공유 호스팅이나 매니지드 환경에서는
그대로 적용되지 않는 경우도 많습니다.

그래서 문제를 해결할 때는
단순히 설정 값을 복사하기보다는
현재 사용 중인 환경의 구조를 먼저 이해하는 것이
중요하다고 느꼈습니다.

---

마치며

SFTP 접속 문제 자체는
결과적으로 단순한 설정 차이였지만,
그 원인을 찾기까지는 생각보다 시간이 걸렸습니다.

이 글이
카페24 워드프레스 환경에서
비슷한 문제를 겪는 분들에게
조금이라도 도움이 되기를 바랍니다.

앞으로도 backendnote에는
이처럼 실제로 겪은 시행착오와
그 해결 과정을 중심으로 기록해 나갈 예정입니다.

개발 일을 하다 보면
문서 하나, 설정 하나 때문에 몇 시간을 소비하는 경우가 많습니다.
특히 서버 설정, 네트워크, 배포, 보안 같은 영역은
한 번 겪고 나면 다시 겪고 싶지 않은 시행착오가 반복됩니다.

하지만 시간이 지나면
그 경험은 기억에서 흐려지고,
다시 같은 문제를 검색하며 헤매게 됩니다.

이 블로그 backendnote는
그런 반복을 줄이기 위해 시작한 개인 기술 기록 공간입니다.

---

왜 개인 기술 블로그가 필요했는가

최근에는 검색보다
AI 도구를 통해 빠르게 답을 얻는 경우도 많아졌습니다.
하지만 실제 환경에서는
서비스, 호스팅, 설정값에 따라
AI가 제시하는 답이 그대로 적용되지 않는 경우도 많습니다.

특히 다음과 같은 상황에서는
개인 경험을 정리한 기록이 더 도움이 됩니다.

• 특정 호스팅 환경에서만 발생하는 문제
• 공식 문서에는 없는 설정 순서
• 시행착오 끝에 정리된 현실적인 해결 방법

이 블로그는
이론 설명보다는 직접 겪고 정리한 기록을 중심으로 다룰 예정입니다.

---

backendnote에서 다룰 내용

이 블로그에서는 주로 다음과 같은 주제를 다룰 계획입니다.

• 서버 및 호스팅 설정 기록
• 워드프레스, 웹 서비스 운영 경험
• 백엔드 개발 과정에서 겪은 문제와 해결 방법
• 개발 도구 및 환경 구성 노트

모든 글은
“나중에 내가 다시 봐도 이해할 수 있는 기록”을 기준으로 작성합니다.

---

이 블로그의 운영 방향

backendnote는
뉴스형 사이트나 커뮤니티를 목표로 하지 않습니다.

• 개인이 직접 운영하는 기술 블로그
• 광고성 콘텐츠 최소화
• 실무 경험 위주의 정리

불필요한 기능이나 과도한 디자인보다는
글 자체에 집중할 수 있는 구조를 유지하려고 합니다.

---

마치며

개발자는 늘 새로운 기술을 접하고
문제를 해결하며 성장합니다.
하지만 그 과정이 기록으로 남지 않으면
비슷한 실수를 반복하게 됩니다.

이 블로그가
저 자신에게는 정리된 기술 노트가 되고,
누군가에게는 작은 힌트가 될 수 있다면
그 자체로 충분한 의미가 있다고 생각합니다.

앞으로 backendnote에 기록될 내용들이
차분하게 쌓여가길 기대해 봅니다.