차분일기 MVP를 구현하며, 작은 자아실현을 해보는 중

회사를 다니면서 느끼기 어려운 성취감, 그걸 차분일기 페이지를 만드는 과정에서라도 느껴보고 싶었다.

완벽하지 않아도 괜찮고, 의미 있는 결과가 아니어도 괜찮다.

그냥 스케치북에 그림을 그리듯, 쓱쓱 만들어보는 차분일기 MVP.

시작은 ‘나’를 위한 일기였다

A5 사이즈의 노트를 기준으로 구성했다.

• 날짜 / 시간 / 날씨 / 현재 감정

• 감정을 문장으로 쓰고, 한 단어로 정리

특히 감정을 한 문장에서 한 단어로 정리하는 과정에서 “아, 내가 지금 이런 상태구나” 하고 인지하게 되고, 그 순간 마음이 조금 정리되는 느낌이 들도록 기획했다.

‘오늘의 차’ — 일부러 넣은 장치

일기 중간에는 ‘오늘의 차’ 섹션을 넣었다.

솔직히 말하면… 차 한 잔을 강요(?) 하는 구조다 ㅋㅋ

차를 마시기 전 상태, 차를 마신 후 마음가짐을 기록하게 해서

• 차라는 행위가 나에게 어떤 영향을 주는지

• 그게 실제로 도움이 되는지

스스로 체감하게 만드는 것이 목적이다.

귀찮음을 이겨내게 만드는 장치이기도 하고.

기록 + 질문 + 타로의 연결

하단에는 자유 기록 영역을 크게 두고, 그 옆에는 영어 문장을 필사할 수 있는 공간을 만들었다.

총 30페이지 구성으로, 각 페이지마다 다른 문장을 넣을 예정이다.

그리고 ‘오늘 나에게 필요한 말’은 직접 적는 방식뿐 아니라

👉 QR 코드를 통해 👉 타로 카드처럼 선택해서 👉 메시지를 받는 구조로 구현했다

QR → 감정 카드 선택 → 결과 페이지

QR을 찍으면 모바일 화면에서 9개의 감정 카드가 나타난다.

마음에 드는 카드를 하나 선택하면,

👉 메시지 + 질문이 함께 등장한다

단순한 위로 문장이 아니라 기록으로 이어질 수 있는 질문까지 연결되도록 설계했다.

실제 노트 + 웹 연결

QR을 노트에 실제로 붙여봤다.

생각보다 잘 연결돼서 꽤 뿌듯했다.

다만 모바일에서 여백이나 UI는 조금 더 다듬을 필요가 있다.

다음 단계

• 노트 디자인 감도 높이기

• 30개의 영어 문장 + 질문 구성

• 전체 UX 다듬기

그리고

👉 3월 안에 👉 나만을 위한 30장 노트를 실제로 제작해보는 것

목표

나 자신을 테스트베드 삼아 감정 노트를 만들고, 수정하고, 다시 만들어보는 것.

그리고 최종적으로는

👉 텀블벅 펀딩까지 연결해보기

한 줄 정리

완벽한 결과보다, 계속 만들어보는 과정이 더 중요하니까.

화이팅.

쓸데없진 않지만, 쓸데없어 보이는 일들.

행정력을 낭비하는 순간마다 묘한 회의감과 스트레스가 쌓인다.

이 감정을 공부에서 오는 도파민으로 다스릴 수 있을까?

그리고 지금,

마케터로 일하고 있는 내가 AICE Associate 자격증이 과연 필요할까?

내 업무나 커리어에 실질적인 도움이 될까?

답을 미리 정해두기보다는, 약간 실험을 해보는 모드로 공부를 시작해보기로 했다.

AICE Associate, 어떤 시험인가

AICE Associate 자격증은 “AI를 잘 만든다”기보다 “데이터를 다룰 줄 아는 사람인지”를 본다.

시험은 오픈북 형식이며, 아래 7가지 라이브러리를 사용할 수 있다.

• NumPy

• Pandas

• Matplotlib

• Seaborn

• Scikit-learn

• TensorFlow

• XGBoost

시험에서 사용하는 7가지 라이브러리 정리

1️⃣ NumPy

한 줄 요약: 수학적인 계산을 빠르고 깔끔하게 처리하는 기본 체력

• 파이썬에서 숫자 배열(행렬)을 다루는 핵심 라이브러리

• AI, 데이터 분석의 가장 아래에 깔린 뼈대

• 리스트보다 훨씬 빠르고, 수학 연산이 직관적이다

이걸 왜 보냐면

• “데이터를 그냥 리스트로 다루는 사람”인지

• “연산 단위로 사고하는 사람”인지 구분하기 위해서

👉 마케터 관점에서는 수치 기반 리포트나 지표 계산 로직을 이해하는 데 도움이 된다.

2️⃣ Pandas

한 줄 요약: 엑셀을 코드로 다루는 능력

• 표 형태 데이터(DataFrame)를 다룸

• CSV, 엑셀 불러오기 / 정리 / 필터링 / 그룹화까지 가능

• 실무에서 가장 많이 쓰이는 라이브러리

이걸 왜 보냐면 데이터 전처리를 못 하면 머신러닝이고 뭐고 아무것도 할 수 없다.

👉 마케터에게는 솔직히 이 7개 중 가장 실용적이다. (캠페인 성과 데이터, 설문 결과, 로그 데이터 전처리 전부 여기서 한다)

3️⃣ Matplotlib

한 줄 요약: 데이터 시각화의 기본 중 기본

• 그래프를 ‘직접’ 그리는 라이브러리

• 커스터마이징 자유도는 높지만 코드가 다소 투박하다

• 다른 시각화 도구들의 기반이 된다

이걸 왜 보냐면 숫자를 ‘보여줄 수 있는 사람인지’ 보기 위해서다.

👉 보고서·제안서에서 “이 그래프 왜 이렇게 그렸지?”라는 질문에 답할 수 있는 감각을 만들어준다.

4️⃣ Seaborn

한 줄 요약: 보기 좋은 그래프를 빠르게 만드는 도구

• Matplotlib 기반

• 통계적 시각화에 강함

• 기본 디자인이 깔끔하다

이걸 왜 보냐면 데이터의 패턴을 빠르게 읽어낼 수 있는지 확인하기 위해서.

👉 마케터에게는 데이터에서 인사이트를 뽑아내는 연습용으로 좋다.

5️⃣ Scikit-learn

한 줄 요약: 머신러닝 입문자의 표준 교과서

• 분류, 회귀, 군집화 등 전통적인 ML 모델이 모두 포함

• 코드 구조가 일관돼 있어 배우기 쉽다

• 시험에서도 가장 핵심 비중을 차지한다

이걸 왜 보냐면

• “모델을 써본 사람”인지

• “AI라는 단어만 아는 사람”인지 구분하기 위해서다.

👉 마케터 기준으로는

• 추천 로직

• 고객 세그먼트 분류

• 이탈 예측 같은 개념 이해와 직접 연결된다.

6️⃣ TensorFlow

한 줄 요약: 딥러닝 프레임워크 (꽤 무거움)

• 신경망 기반 모델 구현

• 실제 서비스용 AI에 많이 쓰임

• AICE Associate에서는 깊게 묻지 않는다

이걸 왜 넣었냐면 AI 생태계에서 이걸 모르면 말이 안 되기 때문이다.

👉 마케터에게는 “이 모델이 왜 블랙박스인지” 이해하는 정도면 충분하다.

7️⃣ XGBoost

한 줄 요약: 실무에서 성능 잘 나오는 머신러닝 치트키

• 트리 기반 모델

• 데이터가 조금 지저분해도 성능이 잘 나온다

• 캐글과 실무에서 매우 많이 쓰인다

이걸 왜 보냐면 이론보다 결과를 내는 모델을 아는지 보기 위해서다.

👉 마케터 실무에서는 CTR 예측, 전환 예측 같은 사고방식과 연결된다.

그래서, 마케터에게 AICE Associate는 필요할까?

❌ 이런 기대라면 비추천

• 연봉이 오른다

• 이직에서 한 방이 된다

• ‘AI 마케터’ 타이틀을 바로 얻는다

✅ 이런 목적이라면 충분히 의미 있음

• 데이터/AI 용어에 휘둘리지 않고 싶다

• 개발자·데이터팀과 대화할 때 번역기 없이 말하고 싶다

• ‘감으로 기획하는 마케터’에서 ‘구조를 이해하는 마케터’로 넘어가고 싶다

• 지금의 회의감을 성장하고 있다는 감각으로 상쇄하고 싶다

AICE Associate 공부 우선순위 (마케터 기준)

👉 Pandas → Scikit-learn → 시각화(Matplotlib/Seaborn) → NumPy → XGBoost → TensorFlow

🥇 1순위: Pandas

중요도: ★★★★★

시험, 실무, 사고방식 전부 여기서 갈린다.

• 시험 문제의 절반 이상이 데이터 전처리 흐름에서 나온다

• 마케터가 AI를 이해하느냐는 👉 “데이터를 표 단위로 다룰 줄 아느냐”로 결정된다

꼭 익혀야 할 것

• read_csv, head, info, describe

• 조건 필터링 (loc, isin)

• groupby + agg

• 결측치 처리 (fillna, dropna)

• 컬럼 생성 및 변형

👉 Pandas가 안 되면 뒤에 나오는 모든 AI는 공허해진다.

🥈 2순위: Scikit-learn

중요도: ★★★★☆

“AI를 써봤다”의 최소 기준.

• 모델 선택 → 학습 → 평가 흐름 이해가 핵심

• 모델 이름 암기 ❌

• 언제 분류 / 언제 회귀를 쓰는지 이해 ⭕

👉 여기서부터 기획 회의에서 말이 바뀐다.

🥉 3순위: Matplotlib + Seaborn

중요도: ★★★☆☆

데이터를 인사이트로 바꾸는 연결 고리.

• 예쁘게 ❌

• 의미가 보이게 ⭕

4순위: NumPy

중요도: ★★☆☆☆

깊게 파지 말고, 왜 다른 라이브러리들이 이 위에서 돌아가는지만 이해하면 충분.

5순위: XGBoost

중요도: ★★☆☆☆

• 성능 좋은 모델이 있다는 인지

• 실무에서 왜 선호되는지 이유 이해 정도면 충분

6순위: TensorFlow

중요도: ★☆☆☆☆

• Associate 레벨 + 마케터에게는 과함

• 시간 부족하면 과감히 스킵해도 무방

결론적으로 AICE Associate는 ‘AI를 잘 만드는 자격증’이라기보다, 데이터와 모델을 다루는 기본 체력을 확인하는 시험에 가까웠다. 마케터에게 중요한 건 결국 정답을 외우는 것이 아니라, 숫자/표/모델을 두려워하지 않는 감각을 만드는 것 같고.

다음 글에는 내가 실제로 Pandas부터 어떻게 손에 익혔는지, 마케터 업무에 바로 연결되는 예제로 정리해보려고 한다. (아마 여기서부터 도파민이 본격적으로 올라올 듯)

그래서 홍보대행사 AE 입장에서는

“나랑은 상관없는 툴” 이라고 생각하기 쉽다.

하지만 실제로 써보면,

아나콘다는 AE의 시간을 가장 많이 잡아먹는 일을 정리해주는 도구가 될 수 있다.

AE 업무를 한 문장으로 요약하면

데이터를 정리해서 사람들이 이해할 수 있는 말과 문서로 바꾸는 일

• 광고 성과 데이터 정리

• 주간/월간 리포트

• 보고용 PPT

• 내부 공유 문서

• “그래서 이게 잘 된 건가요?”에 대한 답변

문제는 이 과정의 80%가 반복 작업이라는 점이다.

AE의 하루를 갉아먹는 대표적인 반복 작업

• CSV / 엑셀 파일 열어서 정리

• 수치 복붙

• 전주 대비 계산

• 그래프 만들기

• 똑같은 문장 다시 쓰기

• Word → PDF 변환

• “지난주랑 형식 똑같이요” 요청

👉 이걸 사람 손으로 매번 하는 게 비효율이다.

아나콘다는 AE에게 어떤 도구인가?

한 줄로 정리하면 이렇다.

아나콘다 = 반복되는 ‘보고용 노동’을 자동화할 수 있는 환경

코딩을 잘해야 쓰는 도구가 아니다. 실무를 정리하고 싶을 때 쓰는 도구에 가깝다.

AE 관점에서 아나콘다의 핵심 기능 3가지

1️⃣ CSV / 엑셀 자동 정리

광고 데이터, 매체 리포트, 성과 지표 대부분 CSV나 엑셀로 온다.

아나콘다 + 파이썬을 쓰면:

• 여러 CSV 파일 자동 병합

• 날짜 기준 주간/월간 집계

• 전주 대비 증감률 계산

• 불필요한 컬럼 자동 제거

👉 “엑셀로 하던 작업을 한 번의 실행으로”

2️⃣ 숫자를 ‘보고용 문장’으로 바꿔줌

AE가 힘든 이유는 숫자가 아니라 해석을 매번 다시 써야 한다는 것이다.

예를 들면:

“CTR이 올랐습니다” “도달은 감소했지만 효율은 개선됐습니다”

이 문장 구조는 사실 매번 비슷하다.

아나콘다 환경에서는:

• 수치 변화 기준으로

• 문장 템플릿 자동 생성 가능

👉 AE는 ‘이 문장이 맞는지’만 판단하면 된다.

3️⃣ 리포트 초안 자동 생성

• 표

• 차트

• 요약 문장

이걸 자동으로 만든 뒤:

• PPT에 옮기거나

• Word → PDF로 변환

👉 AE의 역할은 ‘초안 제작자’가 아니라 ‘검토자’로 이동

그럼 AE가 개발자가 돼야 하나?

전혀 아니다.

중요한 포인트는 이거다.

❌ 코드를 잘 짜는 것 ⭕ 내 업무 흐름을 코드로 고정하는 것

• “이 리포트는 항상 이 구조”

• “이 수치는 항상 이렇게 해석”

• “이 보고서는 이 톤”

이걸 한 번만 정리해두면 다음부터는 실행만 하면 된다.

아나콘다를 쓰면 AE의 역할이 이렇게 바뀐다

솔직한 한계도 있다

아나콘다는 만능이 아니다.

• 클라이언트 감정 읽기

• 정치적인 문장 조율

• “이번엔 다르게 가야 할 것 같은데?” 같은 직감

👉 이건 여전히 사람의 영역이다.

그래서 더더욱 기계가 할 수 있는 건 기계에게 넘기는 게 합리적이다.

마무리

아나콘다는 AE를 개발자로 만들기 위한 도구가 아니다.

AE가 덜 소모되고, 더 중요한 판단에 에너지를 쓰게 해주는 환경이다.

홍보대행사에서 오래 살아남는 AE는 일을 많이 하는 사람이 아니라 일이 돌아가게 만드는 사람이다.

제안서를 잘 쓰는 사람은 결국 자료를 잘 찾는 사람이다.

프로젝트를 시작할 때 가장 먼저 부딪히는 벽은 “무엇부터 찾아야 하지?”라는 막막함이다. 자료조사는 기술이다. 루틴과 방법을 체득하는 것이 중요하다.

아래는 나를 위한.. PR/브랜딩/정책 제안서에서 사용할 수 있는 자료조사 프로세스의 정리본이다.

1. 🎯 조사 전 준비: 목표와 전략 수립

■ 목적 명확화

• 이번 제안서에서 무엇을 증명해야 하는가?

• 누구를 설득해야 하는가?

• RFP(제안요청서)의 핵심 요구사항과 평가 기준을 반드시 분석한다. → 이 단계에서 목적이 명확해지면 자료조사의 방향도 자동으로 잡힌다.

■ 초기 정보 훑기

주제가 생소하다면 20~30분만 시간을 정해

• 키워드

• 개념

• 국내·국외 동향

• 기존 연구

를 빠르게 파악하는 “오리엔테이션 리서치”를 한다. 진짜 심층 조사는 이 다음 단계에서 한다.

2. 🔎 효과적인 자료 수집 방법

자료조사는 출처를 아는 사람이 가장 유리하다. 아래는 PR·정책·브랜딩 실무에서 가장 많이 쓰이는 출처들이다.

① 국내 3대 여론조사 기관(가장 많이 쓰는 핵심 출처)

한국갤럽 (Gallup Korea)

• 기관 신뢰도, 직업 신뢰도

• 정부 신뢰, 사회 이슈 인식 조사

• 매주 업데이트

• PDF 형태로 깔끔하게 제공 → 제안서에 바로 넣기 최고

👉 https://www.gallup.co.kr

한국리서치 (Korea Research)

• 공공기관·정책 인식 조사 대량 보유

• 국가 의뢰 조사 많음

• 국방·안보 관련 데이터도 종종 제공

• 지표 체계가 명확해서 인사이트 뽑기 좋음

👉 https://www.korearesearch.co.kr

리얼미터 (Realmeter)

사회 이슈·정책·정치 관련 여론 흐름 파악할 때 유용 👉 https://www.realmeter.net

② 정책 관련 공공기관 조사 (가장 근거력이 높은 자료)

행정안전부 — 정책고객만족도 조사

공공 서비스 신뢰도, 기관 만족도 등의 데이터를 담고 있어 신뢰도 높음.

한국행정연구원(KIPA)

• 정부 신뢰

• 사회통합·공공정책 인식 조사 → 정책 제안서에서 가장 강력한 레퍼런스

③ 언론·전문기관 기반 조사

신문사와 연구기관이 공동으로 수행하는 여론조사.

• 중앙일보 국민미래여론

• 조선일보 미디어리서치

• 서울대·정치외교학부 공동조사

• 동아일보 × 리서치앤리서치

• 한국보건사회연구원(복지·청년·가족)

언론 기반 조사는 “시의성”이 좋아서 트렌드를 설명할 때 매우 유용하다.

④ 검색 엔진 고급 활용법 (PR 실무자 필수 스킬)

✔ 구글 고급검색 문법

가장 강력한 방법은 아래 두 가지.

1) filetype:pdf → 정부·기관 보고서만 필터링

“군 신뢰도” filetype:pdf “정책 인지도 조사” filetype:pdf

2) site:re.kr / site:go.kr → 연구기관·정부 공식자료만 검색

site:re.kr 군사력 인식 조사 site:go.kr 국방 정책 홍보

✔ 영어 키워드 병행

국제조사 자료가 필요한 경우

“Korea military trust survey” “public confidence institutions 2025”

⑤ 신뢰 가능한 정량·정성 데이터 함께 보기

• 정량: 통계청, 마이크로데이터(MDIS), 한국은행

• 정성: 인터뷰, 포커스 그룹, 관찰, 고객 VOC

두 가지가 결합되어야 ‘진짜 통찰’이 나온다.

⑥ 사례·경쟁사 분석

• 유사 과업의 성공·실패 사례

• 경쟁사의 제안서 포맷

• 해외 사례(이건 특히 차별화할 때 유용)

이 단계에서 “우리 제안이 왜 더 나은가?”의 근거가 잡힌다.

3. 🧩 자료 정리 및 분석

✔ 수집 즉시 요약

자료를 모두 모은 뒤에 정리하는 것은 너무 비효율적이다. 링크 옮길 때마다

• 어떤 내용인지

• 왜 중요한지

• 어디에 활용할지

간단히 메모하는 습관이 중요하다.

✔ 팩트 체크

• 출처 확인

• 표본 수와 조사 방식 확인

• 과장되거나 편향된 수치인지 점검

PR 제안서는 근거의 질이 설득력의 80%를 결정한다.

✔ 스토리텔링 구조화

제안서는 논문이 아니다. “읽히는 구조”가 필요하다.

• 문제 정의

• 핵심 인사이트

• 제안 솔루션

• 기대 효과

• 행동 유도(Call to Action)

이 흐름으로 구조화하면 어떤 제안서든 형태가 잡힌다.

4. 📝 제안서 작성 및 최종 검토

✔ 가독성

• 복잡한 문장은 줄이고

• 그래프·인포그래픽·표는 과감히 활용

• 슬라이드당 메시지 1개 원칙

✔ 음독(소리 내어 읽기)

문장을 소리 내서 읽으면

• 어색한 구문

• 논리적 비약

• 지나치게 긴 문장 을 바로 캐치할 수 있다.

✨ 마무리

자료조사는 단순한 검색 작업이 아니라 전략을 설계하는 시작점이다.

출처를 알고, 검색 공식을 알고, 정리 방식을 알면 누구나 빠르고 정확하게 근거를 확보할 수 있다.

제안서의 완성도는 자료조사의 깊이로 결정된다. 오늘 소개한 방법을 루틴으로 만들면 어떤 프로젝트에서도 흔들리지 않는 기반이 생긴다.

그 와중에 많은 것을 느끼고 배우고 반성했다.

아래는 나의 시행착오와 실수를 경험치로 바꾸기를 소망하며 남기는 기록들.

제안서는 '비우기'의 기술

자료를 많이 넣는 것이 기획이 아니란 걸 이번에 확실히 체감했다. 오히려,

• 덜어내고
• 정리하고
• 핵심 메시지를 하나로 압축하고

그래서 단 하나의 문장으로 설득하는 게 기획의 본질이다.

자료조사를 공유할 때 조차, 수요자 중심으로

처음 자료조사를 나누어 한다고 했을 때, 막막했다. 혼자 기획하고 문서를 작성하는 것에만 익숙했던 나는 정리되기 전의 '자료'를 타인과 어떤식으로 공유해야할지 감 잡기가 쉽지 않았다.

덕분에 이번 첫 시도에서 많은 시행착오와 볼을 벌겋게 붉히는.. 상황들을 마주했다.

모든 홍보 메시지의 기본은 '수요자의 시선에서 출발할 것'일것이다. 함께 힘을 합쳐 제안서를 만들기 위한 '자료조사' 단계에서조차 이 원칙은 유효했다.

자료조사 문서는 나 이만큼 조사했어요 , 이만큼 열심히 알아봤어요, 티내는 문서가 아니다. 나는 그 지점에서 실패했다.

자료조사 문서는 간결하면 간결할 수록 좋다. 망망대해와 같은 정보의 바다 속에서 우리의 제안서에 꼭 필요할만한 핵심 메시지와 그를 뒷받침할 근거의 흐름을 정돈하여 '공유할 자료조사 파일'을 만들어야 한다.

즉, 자료조사 문서라지만, 사실은 자료조사 문서가 아닌 보고문서의 형태로 '가공'해야 한다. 나만 보기 위한 노트가 아니라는 점에 주목해야 한다.

타인이 봤을 때 직관적으로 이해할 수 있고, 내가 얻은 인사이트에 공감할 수 있게끔 정돈한 뒤 공유해야 한다.

① 보고 = 현재 위치를 정확히 알려주는 일

보고는 “일했어요”가 아니라 *“지금 어디에 있고, 어디로 가고 있고, 무엇이 막혔는지” * 알려주는 일이다.

② 좋은 보고는 ‘판단을 덜어주는 것’

상사가 직접 판단해야 할 일을 줄여주는 보고는 그 자체로 신뢰다.

• 선택지를 정리하고

• 리스크를 표시하고

• 선호하는 방향을 1순위로 제시하는 것

이게 바로 ‘좋은 보고’다.

③ 보고는 문장보다 구조가 더 중요하다

잘 정리된 3개의 항목이 10줄짜리 장황한 보고보다 훨씬 압도적이다.

보고의 본질은 ‘명확성’이다.

협업 시 '상대의 문장과 세계를 이해하는 태도'

제안서 작업은 한 문장을 두고도 서로 다른 해석이 나오는 상황의 연속이다. 이때 중요한 건 "내 문장을 고집하는 능력"이 아니라 "상대의 논리를 이해하려는 능력"이었다.

• 내가 왜 이 문장을 썼는지
• 상대는 왜 이 구조를 더 좋아하는지
• 기획자의 우선순위는 무엇인지

이걸 읽어내는 힘이 쌓일수록 협업은 더 수월해진다.

문제를 '누가 맞나'가 아니라 '무엇이 더 설득적인가'로 바라보는 관점이 필요하다.

내가 맡은 '한 페이지'가 전체 설득 구조 안에서 어떤 역할인지 파악하기

제안서는 여러 페이지의 조각이 합쳐진 하나의 설득 스토리다. 하지만 초반엔 내 파트만 보느라 전체 구조를 놓치기 쉽다.

그래서 꼭 필요한 건,

• 이 페이지는 앞 장표의 어떤 내용을 '이어주는 역할'을 하는가?
• 이 페이지의 핵심 문장은 무엇인가?
• 이 페이지가 빠지면 제안서 구조가 어떻게 흔들리는가? 이 질문을 스스로 던져보면서 단순히 '한 장표의 작성자'가 아니라 '전체 내러티브를 만드는 사람'이 되어야 한다는 것이다.

작업 중간 단계에서의 '보고'가 오히려 효율을 높인다.

혼자 완성해서 들고 가는 방식은 헛다리를 짚는 경우가 많다.

보고의 시점을 아래 3단계로 구분해서 챙겨가는 것이 좋다.

• 40% 완성도에서 구조 먼저 확인받기
• 70% 에서 메시지 톤 확인받기
• 100%는 거의 다 정리하고 마지막 다듬기만

이렇게 하면 시간을 훨씬 절약하면서 퀄리티를 높일 수 있다.

보고는 '검토'나 '평가'받는 자리가 아니라 '조율하는 과정' 이라는 것을 명심하자.

AI를 사용하되, 매몰되지 않을 것

자료조사의 단계에서 메시지를 만들어낼 때 종종, 아니 수시로 AI의 도움을 받곤 한다. 하지만 AI가 만들어 낸 메시지를 복사 붙여넣기 하여 그대로 쓰는 것은 지양해야 한다.

AI는 많이 반복되는 문장들을 검수 없이 마치 사실인 것처럼 그럴사하게 내뱉는다.

AI가 제안한 메시지가 실제로 설득력이 있는지 항상 의심하며 판단해야 한다. AI가 제시한 근거 또한 항시 그것이 실제 팩트인지 체크해야 한다.

'감정관리'도 실력이다.

누군가 내 장표를 수정하거나, 아이디어가 빠지거나, 내가 쓴 문장을 그대로 쓰지 않을 때,

그걸 개인적인 감정과 분리시키는 것이 전문가의 태도임을 배웠다.

"수정 = 내 실력 부족"이 아니라, "수정 = 팀이 더 좋은 방향으로 가는 과정"이라는 걸 이해하는 과정이었다.

*하지만 여전히 어려운....

이번 협업 제안서를 통해 느낀 건, 일 잘하는 사람은 결국 '기술'이 아니라 '태도'를 가지고 있다는 점이다.

자료를 정리하는 태도, 협업을 바라보는 태도, 질문하는 태도, 그리고 무엇보다 '내 문장을 내려놓을 줄 아는 태도'.

이 모든 것이 내가 앞으로 더 단단해지기 위해 반드시 배워야 할 것들이었다.

PR/IMC 실무를 준비하면서 반복적으로 마주치는 개념들을 하나씩 정리했다. 기본 개념들을 한 번에 정리해두면, 이후 제안서·기획서 작업에서 큰 뼈대를 잡는 데 도움이 된다.

🟦 1) 이해관계자 리서치(Stakholder Research)란?

정의

캠페인이나 프로젝트에 직접·간접적으로 영향을 주는 모든 당사자를 분석하는 것.

리서치 기본 흐름

① 분류

• 정책 결정자(정부·기관)

• 시민·소비자

• 전문가 집단

• 언론

• 업계/협회

• 비판세력·이슈 메이커

• 파트너·스폰서

• 내부 관계자(클라이언트/의사결정자)

② 니즈/욕구 파악

• 각 이해관계자가 바라는 점

• 불만·고통

• KPI

• 기대효과

• 우려요소

③ 영향력 매핑

• 영향력이 큰 이해관계자

• 여론을 좌우하는 존재

• 의사결정자 vs 수용자

④ 행동 패턴 분석

• 정보 소비 경로

• 신뢰하는 채널

• 감정·행동의 흐름

👉 PR/IMC에서 ‘타겟 정의’의 근간이 되는 작업.

🟦 2) 메시지 매핑(Message Mapping)이란?

정의

“무엇을, 누구에게, 어떤 언어로 전달할지”를 구조화해 놓은 지도.

작성 방식

① 핵심 메시지 1~3개 선정

→ 캠페인이 말하려는 중심 문장

② 서브 메시지 작성

→ 근거, 설명, 사례 등을 계층적으로 정리

③ 타겟별 메시지 변환

• 시민 대상 메시지

• 언론용 메시지

• 정부/기관용 메시지

• 내부관계자용 메시지

④ 위험요소 대응 메시지 준비

→ 위기 상황에서 사용할 공식 메시지

예시(한돈PR)

• 핵심 메시지: “한돈은 가장 신선하고 안전한 국내산 단백질 원천이다.”

• 서브 메시지: 영양·유통기간·지역경제·건강 등

• 타겟 변형: 소비자=‘신선’, 기관=‘식량 안정성’, 업계=‘농가 소득’

👉 캠페인의 언어 체계를 정리하는 프레임워크.

🟦 3) 퍼블릭 커뮤니케이션(Public Communication) 개론

정의

사회·공공의 문제를 대중·언론·정책·시민과 소통하여 해결하는 전략.

핵심 요소

• 여론 분석

• 미디어 관계

• 공공 이해관계자 조율

• 정확한 메시지 설계

• 신뢰 기반 행동 변화 유도

• 시민 참여·커뮤니티 기반 확산

• 위기관리

👉 공익·정책·사회적 의미와 신뢰를 다루는 커뮤니케이션.

🟦 4) 캠페인 IA(Information Architecture)란?

정의

웹/앱 IA와 동일하게 캠페인을 구성하는 전체 흐름과 구조를 정리하는 것.

포함되는 요소 예시

• 메인 메시지

• 참여 방법

• 슬로건 구조

• 온·오프라인 액션 플로우

• 콘텐츠 아키텍처

• 미디어 플랜

• KPI 연결 구조

👉 한 페이지짜리 ‘캠페인 구조 설계도’.

🟦 5) 캠페인 여정맵(Journey Map)이란?

정의

타겟(시민/소비자)이 캠페인을 접하고 행동하기까지의 전체 경험을 시각화한 맵.

기본 흐름 예시

1. 최초 접점(포스터/영상/뉴스)

2. 관심/탐색

3. 참여/행동

4. 공유/확산

5. 후속 행동(재참여·인식 변화)

각 단계에서 기록하는 요소

• 감정

• 행동

• 사용 채널

• 메시지

• 개선점

👉 “타겟의 감정과 행동 이동”을 설계하는 도구.

🟫 8) 브랜드 언어셋(Brand Language Set)

정의

브랜드가 세상과 소통할 때 사용하는 문장 시스템.

구성 요소

• 브랜드 톤(차분·정직·사려 깊음 등)

• 핵심 문장(세계관 요약)

• 반복되는 단어 선택

• 금기어 리스트

• 슬로건 패턴

• 감정의 기본 결

• 메시지 구조

예시(개인 브랜드 버전)

• “감정을 다루는 건 기술이다.”

• “차를 우리는 건 마음을 내리는 일이다.”

• “조금 더 느리고, 조금 더 나답게.”

• “오늘의 감정은 기록될 가치가 있다.”

👉 브랜드의 세계관을 ‘언어’로 구축한 뼈대.

🟧 9) 커뮤니티 기반 캠페인 예시 5가지

① 시민참여형 챌린지

• 다회용기 사용 인증

• 걷기 캠페인

• 건강 리추얼 공유 → UGC 기반 확산

② 지역 커뮤니티 매칭

• 동네 상점·기관 연계

• 자원봉사자 그룹 운영

• 로컬 페스티벌과 연동

③ 스토리 공모·사연 캠페인

• 개인 경험 공유

• 감정 기반 인터뷰

• 영상·카드뉴스 제작

④ 커뮤니티 리더 양성 프로그램

• 서포터즈·앰배서더

• 교육 프로그램

• 시민 리더십 활동

⑤ 행동 변화 아카이브

• 하루 1 행동 등록

• ESG·환경·공공 의제 해결형

• 데이터 기반 인식 변화 추적

👉 핵심: 사람이 직접 참여해 ‘가치’를 만들어낸다.

🟦 10) 메시지 구조화란? (카피라이팅과의 차이)

메시지 구조화

→ 말하고자 하는 메시지를 계층 구조로 설계하는 것

카피라이팅

→ 그 구조화된 메시지를 한 문장으로 압축·극대화하는 기술

예시

메시지 구조화

한돈은 국내산이라 신선함

영양적 우월성

지역경제 기여

안전한 생산·유통 체계

카피라이팅

→ “한돈, 신선함의 기준이 되다.”

👉 구조화가 먼저, 카피는 그 위에서 나온다.

🟫 11) 인사이트 리포트 정리 기술 올리는 방법 4가지

① 팩트 → 해석 → 시사점 구조로 정리

• 데이터/현상

• 왜 이런가? (인사이트)

• 그래서 어떻게? (제안)

② 유형화/분류 능력

• 3개 카테고리로 재정리

• 흐름을 묶는 능력 키우기

③ 슬라이드 1장 1메시지 규칙

→ 핵심이 선명해짐

④ 일주일에 하나 ‘5줄 요약’ 연습

→ 벨로그에 기록하기 좋음

🟪 12) 커뮤니티 운영 이론 (핵심 정리)

커뮤니티는 아래 3요소가 겹칠 때 구축된다.

① 정체성(Identity)

• 왜 모이는가?

• 어떤 감정·가치를 공유하는가?

② 리추얼(Ritual)

• 함께 반복하는 행동

• 매일/매주/매월의 참여 패턴

③ 관계 구조(Roles)

• 운영자

• 코어 멤버

• 기여자

• 관망자

👉 핵심: 참여자를 “기여자”로 설계하는 커뮤니티가 오래 간다.

🟧 13) 커뮤니티 아키텍처란?

정의

커뮤니티라는 ‘세계’를 설계하는 구조도·설계도.

구성 요소

• 커뮤니티 목적(정서/생활/학습 등)

• 정체성·세계관

• 참여 흐름 (가입 → 활동 → 기여 → 리더십)

• 콘텐츠 구조 (포스트/챌린지/리추얼)

• 역할 구조 (운영자·리더·멤버)

• 보상 구조 (명성·뱃지·포인트 등)

• 커뮤니티 규칙

• 온·오프라인 연결

• KPI (활성도·참여도·재방문·기여도)

👉 캠페인 IA가 ‘프로젝트 구조도’라면, 👉 커뮤니티 아키텍처는 ‘사람이 살아가는 세계의 구조도’.

“그렇다면 나는 어디에 전념해야 할까?”

이 질문에 답하고 싶어서, 나는 나 자신에게 7개의 질문을 건넸다. 아주 개인적이고, 동시에 앞으로의 일을 결정짓는 질문들이다.

1) 나는 자연스럽게 어떤 일을 반복하고 있는가?

나는 끊임없이 나의 감정을 들여다보고 돌본다. 차를 마시고, 필사를 하고, 짧은 문장을 쓰고, 오늘의 감정을 정리하고… 나의 일상은 ‘감정관리’라는 축을 중심으로 돌아간다. 이건 취미가 아니라 내 생존 방식이자 세계관이다.

2) 나는 무엇을 기획할 때 가장 행복한가?

나는 누군가의 감정이나 경험에 작은 변화를 줄 수 있는 일을 좋아한다. 누군가가 내가 만든 문장을 읽고, 콘텐츠를 보고, 생각이 달라지거나 작게라도 미소를 짓는 순간— 그게 나에게 가장 큰 보상이다. ‘내 결과물로 인정받는 기쁨’은 나에게 황홀에 가깝다.

3) 사람들은 나에게 어떤 도움을 요청해왔는가?

마지막으로 누군가 나에게 도움을 요청한 건 네이밍과 카피 아이디어였다. 돌이켜보면 나는 예전부터 문장·언어·카피 영역에 욕심이 있었다. 말을 찾아주는 일, 의미를 이야기로 바꾸는 일을 꾸준히 해온 셈이다.

4) 나만의 감각이 있다면 무엇일까?

대단히 특별한 감각은 아닐지 몰라도, 타겟이 ‘재미’를 느낄 수 있는 요소를 자연스럽게 끼워 넣는 능력은 있다. 가볍고 따뜻한 재치. 그런 감각을 지향한다.

5) 내가 만드는 모든 것들은 결국 어디를 향하고 있는가?

감정일기든, 리추얼이든, 서비스 기획이든, 내가 만들고 싶은 건 결국 ‘사람의 행복’에 닿아 있다. 새로운 감정, 작은 깨달음, 안정, 회복… 사람이 조금 더 행복해지는 방향.

6) 나는 어떤 공부를 지루해하지 않는가?

지치지 않는 공부는 없다. 하지만 ‘감정관리’는 지루하지 않다. 왜냐면 이것은 나의 삶과 직결되기 때문이다. 그리고 사람들에게 즐거움·흥미·재미를 주는 기획— 이 역시 오래 붙잡고 있을 수 있다.

7) 미래의 나는 어떤 결과물을 ‘내 작품’이라고 부르고 싶은가?

서비스도 좋지만, 한 번도 해본 적 없는 ‘커뮤니티’를 만들어보고 싶다. 좋은 영향력을 나눌 수 있는 공간. 사람들이 연결되고, 나의 세계관을 함께 체험하고, 서로가 서로에게 작지만 안정과 영감을 주는 곳.

이 7개의 답을 모아보니, 나의 방향성이 선명해졌다

내가 전념해야 할 방향은 이렇게 정리된다.

“감정과 의미를 언어·브랜딩·기획으로 엮어, 사람들에게 작은 변화와 즐거움을 만드는 정서 기반 창작자. 그리고 그 힘으로 커뮤니티를 구축하는 사람.”

이 문장이 지금의 나를 정확하게 설명한다. 이 문장을 기준으로 앞으로의 공부, 일, 기록, 창작을 정렬해도 좋겠다는 확신이 든다.

내가 얻은 결론

나는

• 감정을 돌보고

• 언어로 세계를 만들고

• 사람들에게 작은 변화와 즐거움을 주고

• 그 경험이 모여 ‘커뮤니티’로 확장되길 바라는 사람이다.

그리고 지금 나는 그 방향으로 움직이고 있다. 천천히, 하지만 아주 명확하게.

구조화란?

구조화를 잘 하려면 어떻게 해야 할까?

'구조화'는 PR·브랜딩·기획·퍼블리싱·PT 모두에서 레벨업의 핵심 스킬이다.

다행인 건, 재능이 아닌 기술의 영역이라는 것.

구조화는 '정리'가 아니다.

구조화는 흐름을 '최소 단위 조각'으로 쪼개고, 그 조각을 의미있게 연결하는 기술이다.

정리가 아니라 질문을 던지고, 범주를 나누고, 순서를 만드는 과정이다.

구조화를 잘 하기 위한 5단계 공식

1) 핵심 질문 '단 하나' 설정.

모든 구조화는 질문에서 시작된다.

• 이 프로젝트의 본질은 뭘까?
• 왜 이 일이 필요한가?
• 사용자는 무엇을 원하는가?
• 내가 말하려는 핵심 메시지는 무엇인가?

이 질문을 정해두면 정보가 쏟아져도 핵심에서 벗어나는 것을 방지할 수 있다.

2) 덩어리(Bucket) 만들기

덩어리 만들기는 구조화의 진짜 시작점이라고 말할 수 있다.

예를 들어 차분일기 서비스의 구조를 만든다면,

• 사용자
• 기능
• 감정
• 기술
• 운영
• 성장 등 큰 카테고리 4~6개를 만들 수 있다.

덩어리를 만들면 생각이 정돈되기 시작한다.

3) 덩어리 안의 '핵심 조각' 3개 만들기

각 덩어리마다 3가지의 핵심 조각을 도출한다. 너무 많은 조각들을 덕지덕지 붙이지 않아도 된다. 사람은 3개까지 밖에 구조적으로 이해하지 못하기 때문.

예를 들어, 차분일기의 '사용자' 덩어리 안에 넣는 조각으로는 아래 3가지가 있을 수 있다.

• 1. 첫 사용자 집단 정의(코호트 집단 예측)
• 2. 사용자의 동기(왜 쓸까?)
• 3. 사용자 문제(미해결 pain-point)

구조화 단계에서는, 딱 이 수준이면 충분하다.

4) 흐름(Flow)을 만든다

덩어리끼리 어떤 순서로 이어지면 자연스러운지 스토리라인을 설정한다. 흐름의 대표적인 규칙을 기억해 두면 유용하다.

• 시간 순
• 중요도 순
• 원인 → 결과
• 문제 → 해결

5) 전체를 위에서 아래로 한 줄 요약하기

주의할 점(!) 구조화의 마지막 단계는 요약이 아니다. 전체 구조가 하나의 줄거리처럼 보이는지 확인하는 것이다.

ex) 사용자의 문제를 정의하고 → 그것을 해결하는 핵심 기능을 제시하고 → 실제 사용 흐름과 실행 계획으로 이어진다.

이런 전체 흐름을 담은 문장이 자연스럽다면, 구조화가 잘 됐다고 평가할 수 있다.

구조화 실습하기

최근 재정비한 4가지 구조화 체계

• 자기 브랜딩 구조

• PPT 학습 체계

• PR 기획력 강화 구조

• 불안 관리 구조

기획·디자인·콘텐츠·실행을 함께 다루는 사람에게 이 네 가지는 결국 하나의 흐름으로 연결된다.

나는 이걸 ‘구조화 5단계 공식’으로 정리했해봤다:

질문 설정 → 덩어리 만들기 → 조각 3개씩 → 흐름 구성 → 한 줄 줄거리

아래는 각각의 구조를 이 공식을 그대로 적용한 버전이다.

1️⃣ 자기 브랜딩 구조: 하이브리드 크리에이터로 보이기

🔸 핵심 질문

“내 브랜드를 보고 사람들이 어떤 인상을 즉시 받아야 할까?”

🔸 덩어리

• Identity(정체성)

• 포트폴리오

• 커뮤니케이션 채널

• 증거자료(Performance)

• 톤 & 내러티브

🔸 각 항목 3조각

1) Identity

• PR/브랜딩 기반의 기획력

• 디지털·퍼블리싱·개발 실행

• 감각 기반의 스토리텔링

2) 포트폴리오

• VS코드 테마 메인 사이트

• 프로젝트 3개(브랜딩/기획/웹)

• 문·비주얼·코드의 결합 구조

3) 커뮤니케이션

• Velog: 기술 + 기록

• Instagram: 라이프 + 스토리

• Notion Super: 레퍼런스 아카이브

*4) 증거자료 *

• 성과 지표: 287% 협찬 등

• PR 실무 경험

• HTML·CSS·JS·React 데모

5) 톤 & 내러티브

• “브랜드 본질을 구조화해 실행까지 하는 사람”

• “감성과 기술을 연결하는 하이브리드 크리에이터”

• “브랜딩 디렉터에서 프론트엔드까지 확장 중”

🔸 한 줄 정리

“브랜드를 구조화해 디지털 경험으로 구현하는 사람.”

2️⃣ PPT 강의 따라잡기 체계: 실무형 스킬 독학 방식

🔸 핵심 질문

“짧은 시간에 PPT 실력의 핵심만 빠르게 익히려면?”

🔸 덩어리

• 기본기

• 디자인 룰

• 템플릿 제작

• 모방 학습

• 주간 루틴

🔸 각 항목 3조각

1) 기본기

• 마스터·레이아웃 구조 이해

• 정렬·여백·텍스트 그리드

• 1슬라이드 1메시지 원칙

*2) 디자인 룰 *

• 컬러 2~3개 제한

• 폰트 계층 구조

• 일관된 아이콘/도형 사용

3) 템플릿 제작

• 타이틀/비주얼/목차/데이터 4종

• 레이아웃 10개 사전 제작

• 브랜드 고유 템플릿 1세트

4) 모방 학습

• 레퍼런스 3개 선정

• 1:1 리디자인

• 흐름·구성 패턴 분석

5) 주간 루틴

• 월: 템플릿 재정비

• 수: 레퍼런스 리디자인 1건

• 금: 5장 미니 슬라이드 실습

🔸 한 줄 정리

“기본기 → 룰 → 템플릿 → 모방 → 루틴의 흐름으로 빠르게 실무형 PPT 습득.”

3️⃣ PR 기획력 강화 구조: 대행사 실전 버전

🔸 핵심 질문

“실무에서 바로 신뢰감을 주는 기획은 어떤 구조인가?”

🔸 덩어리

• 정보 구조화

• 인사이트

• 전략 구성

• 실행·예산

• 리스크 관리

🔸 각 항목 3조각

1) 정보 구조화

• 자료 요약(팩트 기반)

• 문제/현상/기회 분류

• 핵심 메시지 추출

2) 인사이트

• 타깃 분석(Persona)

• 채널·소셜 트렌드

• 브랜드 맥락 연결

3) 전략 구성

• 문제 → 해결 구조

• 캠페인 스토리라인

• KPI 설정

4) 실행·예산

• 채널 믹스

• 일정 시퀀스

• 예산 구조

5) 리스크 관리

• 일정 지연 요소

• 이해관계자 충돌

• 산출물 톤 불일치

🔸 한 줄 정리

“자료 → 인사이트 → 전략 → 실행 → 리스크까지 이어지는 5단계 구조가 곧 기획력이다.”

4️⃣ 불안 관리 구조: 나를 잃지 않기 위한 시스템

🔸 핵심 질문

“내가 흔들려도, 내가 원하는 행동을 유지하려면?”

🔸 덩어리

• 초기 감지

• 안정

• 원인 분석

• 행동 선택

• 지속 관리

🔸 각 항목 3조각

1) 초기 감지

• 심박·어깨 긴장

• ‘망할 것 같다’는 생각 패턴

• 회피·멍해짐 등 초기 징후

2) 안정

• 4-2-6 호흡

• 시선 이동

• 감정 라벨링(“불안을 느끼는 중”)

3) 원인 분석

• 지금 무엇이 두렵지?

• 이건 사실인가, 예측인가?

• 내가 통제할 수 있는 범위는?

4) 행동 선택

• 가장 작은 단위로 쪼개기

• 10분 타이머로 착수

• 결과 아닌 ‘착수’에 의미 두기

5) 지속 관리

• 데일리 루틴(요가·차·정리)

• 주간 감정 로그 3줄

• 회복 행동 반복

🔸 한 줄 정리

“감지 → 안정 → 분석 → 행동 → 유지라는 구조가 불안을 다루는 가장 현실적인 방법.”

🔮 마무리

이 네 가지 구조는 따로 떨어져 있는 것 같지만 결국 연결되어 있다.

• 브랜딩은 나를 외부에 설명하는 구조

• PPT는 생각을 시각화하는 구조

• PR 기획력은 문제를 해결하는 구조

• 불안 관리는 나를 지키는 내부 구조

결국 “구조화 능력”은 나의 실력, 일, 감정, 브랜딩 전부를 정돈하는 핵심 기술이라는 걸 체감한다.

얼마 전 니체의 문장을 발견하고 필사했다.

“이상으로 향하는 지름길을 파악하라.”

그러고 나서 스스로에게 물었다.

내 이상으로 향하는 지름길이 있을까? 있다면 뭘까?

결론: 지름길은 있다

사람은 보통 "내 이상으로 가려면 완전히 새로운 뭔가를 해야 한다"고 생각한다.

나도 그랬던 적이 종종 있다. 하지만 실제로는 반대다.

내가 이미 가진 방향성을 좁혀서, 더 자주, 더 작게 쓰는 것이 지름길이다

즉, 지름길은 완전히 새로운 길이 아니라, 이미 있는 길을 더 뚜렷하게 만드는 것이다.

그래서 내게 맞는 지름길은?

1) 정확히 잘하는 걸 '꾸준한 루틴'으로 만들기

내가 유난히 잘하는 것들:

• 정보/인사이트 흡수하기
• 정보/생각을 정리하고 구조화하기
• 스토리로 엮기
• 꾸준한 루틴 유지(요가, 리셋, 공부, 작업)
• 몰입하면 오래가는 집중력
• 미적 감각과 일관성
• 사람의 마음과 감정의 흐름 읽기

문제는 ‘잘하는 것’을 어쩌다 한 번만 쓸 때는 힘이 약하다는 것.

이걸 주기적 루틴으로 만들면 이 능력들이 나를 원하는 방향으로 계속 끌고 간다.

예를 들어,

• 매일 15분 인사이트 스크랩하기
• 매일 30분 코딩/포폴 작업하기
• 요가/호흡 10분 이상 하기

등등...

이런 작은 반복이 결국 가장 큰 차이를 만든다.

2) 지름길은 '정교함'이 아니라 '안정성'에서부터

성장곡선이 가장 빠른 사람은 '열심히 하는 사람'이 아니라 "정서가 안정된 사람"이다.

난 감정이 흔들릴 때마다 성장이 끊기는 것을 경험했다. 하지만 요가, 차, 정리, 기록 같은 루틴을 통해서 정신적인 진동폭을 줄이고부터는 성장에 가속도가 붙고 있다.

이게 바로 나의 지름길이다.

감정 회복력이 강화되고 안정되면, 지금의 노력들이 10배 속도로 반응하기 시작한다.

3) '나다운 기록'이 방향을 또렷하게 만든다.

나는 "생각하면서 쓰는 사람"이 아니라 **"쓰면서 길을 여는 사람"이다.

내가 진짜 성장하는 순간은 언제냐면,

• 일기에 정리할 때
• 프로젝트 회고할 때
• 노션에 기록할 때
• 요가 후 마음을 기록할 때
• 포트폴리오 정리할 때
• 루틴 체크할 때

기록이 방향을 만든다. 방향이 또렷해지면 불안이 줄고, 불안이 줄면 성장이 빨라진다.

그래서, 사실 지름길은 단순하다: 기록하면 길이 열린다.

기록은 감정을 안정시키고, 성장을 가속한다.

나의 지름길 요약

1) 내가 이미 잘 하는 걸 루틴화하기 2) 불안을 줄여 마음의 파도 폭 낮추기 3) 기록으로 방향성 강화하기

아주 거창한 변화가 아니라 내가 이미 잘하는 걸 내 하루 일상으로 조금 더 자주 끌어들이는 것.

그게 나를 가장 빠르게 이상으로 데려간다.

이상으로 가는 지름길을 파악하라. 어떤 이상을 단지 가지는 것만으로는 부족하다. 우선은, 어떻게 해서든 이상을 향한 지름길을 나름대로 발견하는 것이 중요하다. 그렇지 않으면 자신의 행동과 삶의 방식이 전혀 정해지지 않은 채로 머물게 된다. 이상이라는 것을 멀리 있는 별처럼, 자신과 상관없는 듯 멀거니 바라보며 자신이 걸어야 할 길을 알지 못하는 것은 비참한 결과를 낳는다. 최악의 경우에는 이상을 가지지 못하고 살아가는 사람보다 훨씬 지리멸렬한 삶을 살게 된다.

🔎 1. “축제 홈페이지=편해야 한다”는 진리를 정확히 잡아냈다

축제 홈페이지의 목적은 단순하다.

사용자가 길을 잃지 않게 하는 것. 필요한 정보를 최소 클릭으로 제공하는 것.

UE17 홈페이지는 이 기본을 압도적으로 잘 이해하고 있다.

🗺 2. ‘축제 지도’를 UI로 가져온 용기

첫 화면부터 기존 축제 홈페이지의 틀을 완전히 깨버린다. 축제 맵 자체를 인터페이스로 활용했다는 점, 그리고 그 UI가 새롭지만 아주 직관적이라는 점.

이 접근은 쉽지 않은 선택이다. 지도 기반 UI는 잘못 만들면 혼란을 야기하기 때문이다. 그런데 UE17은 “시각적 재미 + 정보의 구조화”를 모두 잡았다.

📌 3. 첫 화면에 필요한 기능이 전부 있다

• 축제 소개

• 일정 / 장소

• 프레스킷 다운로드 버튼까지 “원클릭”

보통 프레스킷과 행사장 맵은 2~3단계 탐색을 거쳐야 찾을 수 있는데, UE17은 첫 화면에서 바로 접근 가능하다. (홍보 담당자 입장에서 정말 세심하다고 느낀 부분)

📱 4. 모바일 UX는 더 놀라웠다

모바일을 열어보고 더 감탄했다.

✦ 꼭 필요한 기능만 상단에 모아둠

화장실, 물품보관함, 카페, 엘리베이터 등 관람객 기준의 핵심 버튼이 위에 고정되어 있다.

클릭하면 지도에 자연스럽게 핀이 꽂히면서 위치가 표시된다. 이건 정말 관람객 경험 중심 UX 다.

✦ 1층·2층 토글 구조

전체 지도를 한 화면에 표현했지만, 사용자가 구조를 정확히 이해하기는 어렵다. 그래서 층별 토글 기능을 UX 보완 요소로 배치해놨다. 작지만 중요한 개선이다.

🔍 5. 검색 UX의 디테일

검색창에 포커스를 두는 순간,

• 공식부스

• 프로그램룸

• 신간의전당

• 잠깐낭독회

축제의 주요 카테고리가 자동으로 노출된다.

즉, 검색창을 ‘탐색’의 출발점으로 재구성한 UX다. 관람객에게 자연스럽게 축제의 핵심 프로그램을 소개하는 역할도 한다.

🗂 6. 프로그램 정보 구조의 완성도

모바일에서는 ‘위로 올리는 바(bar)’ 형태로 프로그램 설명이 뜬다.

• 날짜별 정렬

• 프로그램별 설명 제공

• 운영 주체와 부스 위치를 지도에서 바로 확인 가능

이 UX는 “현장 이동이 많은 축제 사용자”를 100% 이해한 설계다.

🌿 7. 정보 섹션의 미니멀리즘

‘더 즐길 것’, ‘관람 안내’ 등 모든 부가 정보도 가볍고 간결하게 정리되어 있다.

과하게 꾸미지 않아서 좋다. 행동의 방해요소를 모두 제거한 디자인.

📧 8. 뉴스레터도 훌륭하다

UE17 뉴스레터는 스티비로 제작되었는데 사전 안내 콘텐츠 구성도 인상적이었다.

• 행사 소개

• 참가팀 소개

• 올해 특징

• 먹을거리 가이드

• 현장 스케치

축제 톤앤매너와 잘 맞고, 정보 조합도 매우 좋다.

✨ 마무리: 웹퍼블리싱을 배우는 입장에서 느낀 점

UE17 홈페이지는 “디자인이 아름다운 축제 홈페이지”가 아니라,

사용자 경험의 문제를 정확하게 해결한 UX의 정답이다.

언젠가 축제나 대형 이벤트의 홈페이지를 기획할 기회가 온다면, 나도 이 사이트처럼 사용자의 ‘행동’을 기준으로 레이아웃을 설계하는 방식을 반드시 적용해보고 싶다.

주말에 가보고 싶었지만… 아쉽게도 이번엔 화면으로만 감상해야 할 것 같다. 그래도 배우는 건 많았다.

• 연간 성과보고서

• 차년도 업무계획

• 정책 추진결과

• 예산안

• 감사보고서

같은 방대한 문서를 한꺼번에 공개하는 시기.

문제는… 이 문서들이 너무 길고, 시간이 없다는 것.

그래서 이번 글에서는 Lilys.ai를 이용한 ‘입찰 예측(Pre-bidding Insight)’ 방법을 정리한다.

AI가 잘하는 건 요약이고, AE가 잘하는 건 맥락을 읽어 “과업의 씨앗”을 발견하는 것. 이 둘을 결합하면, 실무 속도가 빨라질 수 있다.

왜 Lilys를 입찰 예측에 활용하는가?

Lilys는 단순한 요약툴이 아니라 정책 자료 → 논리 구조 → 요약 → 인사이트 추출에 특화된 AI다.

특히 공공기관 문서처럼

• 길고
• 정책 언어로 되어 있고
• 핵심 파악이 어려운 자료들 요약에 정말 잘 맞는다.

즉, AE가 연말 보고서를 3시간 들여 읽을 걸 3분 안에 80% 파악 가능하다는 뜻.

AI에게 맡길 부분은 맡기고, 사람(AE)은 판단·예측·기획에 집중하면 효율이 극대화된다.

어떤 문서를 Lilys에 넣어야 할까?

연말/연초에 공공기관들이 올리는 문서 중, 아래 5가지가 특히 중요하다.

✅ 1) 연간 홍보성과 보고서

홍보 Pain Point를 파악하는 데 가장 직접적이다.

✅ 2) 차년도 업무계획

이 문서에 “홍보 강화” 문구가 등장하면 과업으로 이어질 확율이 높다.

✅ 3) 정책 추진백서 · 주요사업 성과보고서

홍보가 부족했던 영역이 명확히 드러난다.

✅ 4) 예산안(사업별 예산 증감)

예산 증가 → 신규 홍보 사업 신설 가능성 높음.

✅ 5) 감사보고서

“대국민 소통 필요”, “인지도 개선 필요” 등의 문구는 사실상 입찰 예고편.

실전 시뮬레이션 — Lilys로 어떻게 입찰 예측할까?

0) 보건복지부 공개자료 확보

(누구나 다운로드 가능한, 2025년+보건복지부+주요업무+추진계획)

아래는 Lilys에 입력한 실전 프롬프트

1. 과업 가능성 탐지

이 보고서에서 향후 홍보 대행 과업으로 연계될 가능성이 높은 항목만 뽑아줘.
근거가 되는 문장도 함께 제시해줘.

2. 홍보 강화 영역 추출

이 문서에서 '홍보가 부족한 부분', '행동 변화가 필요한 부분' 또는 '대국민 소통이 필요한 영역'을 5가지로 정리해줘.
왜 그렇게 판단했는지도 설명해줘.

3. RFP 예상 요구조건 도출

올해 홍보 과업의 RFP에서 포함될 가능성이 높은 요구사항을 항목별로 예측해줘.
기관의 정책 방향과 연계해서 정리해줘.

4. 예산 흐름 분석

예산 증가/감소 항목 중, 대국민 홍보 사업과 직접 연결될 가능성이 있는 항목을 알려줘.
그 이유도 설명해줘.

5. 핵심 사업만 자동 요약

보고서 전체에서 핵심 추진사업만 10줄 정도로 요약해줘.
특히 홍보와 관련된 사업은 강조해서 보여줘.

6. RFP 예상 항목 5개만 재정리

이 문서 기반으로 '홍보 대행사가 실제로 수행할 가능성이 높은 과업'을
정확한 문구로 5개만 뽑아줘.

Lilys를 써보니 — 느낀 점

이건 단순한 자동화가 아니라, AE의 판단력을 강화하는 “지적 보조장치”처럼 느껴졌다.

릴리스를 사용하면서 가장 크게 느낀 점은 두 가지였다.

1) 방대한 자료를 “읽을 수 있는 양”으로 축소해 준다

처음부터 끝까지 다 읽는 것이 아니라, ‘핵심만 남긴 상태’로 판단할 수 있다는 점이 압도적으로 편했다.

2) AE의 핵심역량—빠른 파악·인사이트 추출—이 더 날카로워진다

AI는 문서를 요약하고 구조를 잡아준다. 그 위에서 AE는 정책 방향 → 문제 → 기회 → 과업 이 흐름을 빠르게 연결할 수 있다.

결국, AI는 ‘읽어주는 도구’이고 AE는 ‘읽고 이해하는 사람’이라는 역할이 훨씬 분명해졌다.

레인보우 입사를 앞두고, 실무 감각을 조금이라도 빨리 되찾고 싶어서 KOCCA(한국콘텐츠진흥원) 2025년 3~4월 입찰 공고를 훑어보며 홍보대행사가 실제로 수행할 수 있는 사업들만 직접 선별해봤다.

KOCCA 입찰은 매년 유형이 크게 변하지 않지만, 2025 공고에는 유난히 뚜렷한 흐름이 보였다.

이 글은 단순한 목록 정리가 아니라 홍보AE가 KOCCA 입찰을 읽을 때 ‘무엇을 먼저 봐야 하는지’ 그리고 2025 트렌드에서 발견되는 시사점까지 기록한 나의 분석 노트다.

🟡 1. 이번 분석의 기준

전체 입찰 중 아래 유형만 선별했다.

✅ 포함한 과업

• 행사 운영

• 콘텐츠 제작

• SNS 운영

• 스타트업/IR/뮤직 프로그램 운영

• 캠페인 운영

• 홍보 패키지

→ 레인보우가 실제로 수주할 수 있는 과업들.

✅ 제외한 과업

• 정책 연구

• 재무/분석 중심 연구용역

• 법·정책 기반 조사

• → 전문 연구기관 담당이라 홍보대행사는 잘 하지 않는 영역.*

🟢 2. 2025 KOCCA ‘홍보·행사·콘텐츠’ 관련 입찰 전체 리스트

아래는 2025년 3~4월 KOCCA 공고 중 홍보대행사가 수행 가능한 사업만 모아서 정리한 목록이다.

내가 직접 정리한 엑셀 버전 그대로 가져왔다.

📌 [긴급], [변경공고] 등의 문구는 모두 제거했다. 📌 전체는 행사 중심, SNS/영상 제작 중심, 글로벌/IR 중심으로 분류된다.

🎤 행사 & 공연 운영 중심

• 2025년 멀티턴 쇼케이스 운영 위탁용역

• 2025년 시리즈 온 보드 행사 운영

• 2025 콘텐츠 스타트업 주요행사 통합 운영 및 비즈니스 지원 (투자유치·PoC 포함)

• 2025 콘텐츠 공정문화 확산 캠페인 운영 용역

🌏 글로벌·IR·스타트업 지원 프로그램

• U-KNOCK 해외권역 운영

• 2025 해외 방송마켓 한국공동관 운영

• 2025 콘텐츠 스타트업 글로벌 진출지원 프로그램 운영

🎮 게임·체험·전시 운영

• 2025년 신기술융합콘텐츠 체험거점 운영

• 2025년 게임더하기(성과창출형) 운영 및 관리

• 2025년 게임더하기(초기진입형) 운영 및 관리

🎵 음악·SNS·영상 콘텐츠

• 2025 KOCCA뮤직스튜디오 운영

• 2025 KOCCA MUSIC SNS채널 운영

• 2025 하이브리드 음악 영상 제작 위탁용역

• 2025년 플랫폼 기반 뮤지션 육성지원(뮤즈온)

🎓 교육·아카데미 운영 + 홍보

• 2025 뉴콘텐츠아카데미 단기과정 운영 및 홍보

🎤 포럼·세미나 운영

• 2025년 방송영상 리더스포럼 운영 위탁용역

🧱 콘텐츠 제작·홍보 패키지

• 방송영상콘텐츠 기획개발 사업화지원

• 2025~2026 스토리숲 운영 및 콘텐츠 관리

• KNOCK 투자유치 지원 위탁용역

총 19개 사업. 여기에 연구용역까지 포함하면 40개가 넘지만, 홍보AE 입장에서는 이 정도만 보면 충분하다.

🔵 3. KOCCA 2025 입찰에서 보인 3가지 큰 흐름 (AE 실무 인사이트)

🟣 ➊ “행사 운영 + 홍보 패키징”이 기본 구조가 됨

예전에는 행사, 홍보, 영상 제작이 따로 발주됐는데 2025년 공고는 대부분 ‘한 대행사가 통합 운영하는 구조’로 바뀌었다.

예:

• 행사 운영 + SNS 콘텐츠 + 영상 기록 + 보도자료

• 현장 운영 + 홍보 캠페인

• 프로그램 운영 + 성과 홍보

➡ 기관은 “한 번에 맡길 수 있는 파트너”를 원한다. ➡ AE는 운영·콘텐츠·홍보를 한 흐름으로 설계하는 역량이 필요.

🟢 ➋ 음악·스타트업·글로벌 등 “전문 프로그램 운영”이 강화

뮤즈온, 뮤직스튜디오, 글로벌 진출 프로그램, IR 지원 사업 등 각 영역별 전문성 기반 프로그램 운영이 늘었다.

즉,

단순 홍보대행이 아니라 프로그램 매니지먼트(PM) 역량을 가진 AE가 훨씬 유리한 구조.

🔵 ➌ ‘성과 기반 운영’이 필수가 됨

비록 연구용역은 제외했지만, 행사·지원 프로그램에서도 성과 보고서의 수준이 강화되고 있다.

• 데이터 기반 운영

• 참여자 만족도

• 콘텐츠 성과

• SNS 지표

• IR 매칭 결과

➡ AE는 성과를 설명하는 구조화 능력을 갖춰야 한다.

🟡 4. 트렌드코리아 2026과 연결해 본 시사점

KOCCA 입찰을 트렌드코리아 2026 키워드와 연결해서 보면 이 세 가지 키워드가 특히 선명하게 보인다.

🔎 Zero-click

→ 콘텐츠·행사 정보도 “요약형·짧은 형식”으로 요구됨 → 사업 제안서도 “한눈에 보이는 구조”가 강점

🔎 Feel-conomy

→ 행사·캠페인 기획 시 감정 동기 요소가 더 중요 → 공정문화·청년 프로그램·콘텐츠 체험 등이 이 흐름과 맞물림

🔎 AX 조직

→ AI × 경험 설계 기반 조직 형태 확산 → AE도 운영/콘텐츠/데이터를 모두 다루는 방향으로 변함

🟣 5. 결론

KOCCA 입찰을 한번에 훑어보니, 2025년의 핵심은 다음 한 문장으로 요약된다.

“행사와 콘텐츠 운영을 통합적으로 다룰 수 있는 홍보대행사가 필요하다.”

2025 KOCCA 공고 흐름을 보면 기관이 원하는 건 “기획-운영-홍보-성과측정”의 통합 패키지다. 그래서 AE가 PT하거나 제안서를 만들 때 다음 요소를 고려해야 한다.

① “통합 운영 역량” → KOCCA가 가장 중요하게 보는 지점

2025 입찰은 전부 행사 + 홍보 + 콘텐츠 제작 + 프로그램 운영을 묶어서 발주한다.

🔥 PT에서 강조할 문장 예시

• “이번 사업은 운영·콘텐츠·홍보·성과를 하나의 흐름으로 설계합니다.”

• “단순 운영이 아니라 프로그램 매니지먼트 기반 운영을 제안합니다.”

🔧 준비해야 할 것

• 운영 → 홍보 → 콘텐츠 → 성과의 원페이지 흐름도

• 운영/콘텐츠/홍보가 각각 따로가 아니라 “하나의 스토리”임을 보여주는 구조

② “프로그램 PM 역량” → 단순 AE가 아니라 Program Manager여야 함

뮤즈온, 글로벌 IR, 스타트업 프로그램, 뮤직 스튜디오 등 전문 분야 프로그램 운영 경험이 중요해지고 있음.

🔥 PT 포인트

• “OO 분야 운영 경험 기반으로, 프로그램 단위 설계가 가능합니다.”

• “홍보AE가 아닌 PM 관점에서 운영합니다.”

🔧 준비할 것

• 과거 실무에서 했던 PM 요소들 재정의해서 포트폴리오화 (일정 운영, 참여자 관리, 매칭 프로그램 설계, KPI 관리 등)

③ “콘텐츠·SNS의 다층 구조” → 행사 홍보는 콘텐츠 제작력에서 결정남

행사 홍보의 실체는 콘텐츠 패키징 능력이다.

🔥 PT에서 강조할 요소

• 숏폼 구조

• 하이라이트 영상

• SNS 이벤트 설계

• 보도자료 패키지

• 인터뷰 콘텐츠

🔧 준비해야 할 것

• 포트폴리오에 넣을 콘텐츠 템플릿 3종 (예: ‘행사 숏폼’, ‘참여자 인터뷰’, ‘요약 카드뉴스’)

• 벨로그에 콘텐츠 제작 프로세스 정리해두기

④ “데이터·성과 기반 운영” → KOCCA가 점점 더 ‘수치 기반 레포트’를 요구

2025 공고 대부분이 결과보고서와 성과지표 항목이 강화됨.

🔥 PT 문구

• “성과 중심 운영을 제안합니다.”

• “데이터 기반 운영으로 사업의 재발주 가능성을 높입니다.”

🔧 준비해야 할 것

• 지표 정의 템플릿 (참여자 수/만족도/SNS도달률/영상조회수/IR매칭 등)

• 샘플 성과 보고서 1장짜리

⑤ “제안서의 Zero-click 구조” → 기관 담당자가 5초 안에 이해하게 만들어야 함

2025 트렌드에서 Zero-click은 KOCCA 제안서에도 그대로 적용된다.

🔥 PT 문구

• “제안서가 한 눈에 구조를 이해할 수 있도록 설계했습니다.”

🔧 준비해야 할 것

• 핵심 요약표 (문장 X → 키워드형)

• ‘한 눈에 보는 제안 정리’ 1장 슬라이드

⑥ “피지컬 행사·체험·공정문화 등 감정형 설계” → 컨셉과 스토리텔링의 시대

Feel-conomy 트렌드와 맞물려서 행사에서도 ‘감정 설계’가 중요한 경쟁 포인트.

🔥 PT 문구

• “참여자의 경험을 감정 기반으로 설계합니다.”

• “행사가 끝나도 기억되는 감정 포인트를 제공합니다.”

🔧 준비해야 할 것

• 체험형 프로그램 설계 템플릿

• 참여자 동선 기반 감정곡선 맵 (Emotion journey map)

⑦ “AX(Experience × AI) 기반 운영” → 2025년 이후의 기본 역량

콘텐츠 운영 + 데이터 설계 + AI 기반 고도화가 하나의 패키지로 요구됨.

🔥 PT 문구

• “AI 기반 모니터링 및 콘텐츠 생성으로 효율·완성도를 높입니다.”

• “데이터 기반 의사결정(AX) 체계를 적용합니다.”

🔧 준비해야 할 것

• AI 활용 홍보 실습 예시 (요약·콘텐츠 제작·모니터링 등)

• 자동 리포트 생성 흐름도 1장

⑧ “리스크 관리 + 시나리오 운영” → 워낙 행사·운영형 사업이 많아 리스크 관리 능력이 중요해짐

🔥 PT 문구

• “운영 리스크 10가지 요소를 사전 관리합니다.”

• “시나리오 기반 행사 운영 체계를 적용합니다.”

🔧 준비할 것

• 비상상황 대응 시나리오

• 행사 운영 3단계 체크리스트 (준비–운영–마무리)

입사 전 워밍업으로 시작한 작업이지만 실무에서 바로 쓸 수 있는 정리라 기록해둔다.

• 올해의 핵심 화두는 단연 AI와 행동 변화(Behavior Shift).

• 아래는 10개 키워드를 공공PR 시각에서 재해석한 인사이트 노트

제로클릭 (Zero-click)

“검색→클릭→탐색” 없는 시대. 정보는 ‘자동으로 도달’해야 한다.

검색→클릭 방식이 점점 사라지고, 추천/자동화/AI 응답으로 소비가 빠르게 이루어진다는 트렌드.

마케팅 설계나 웹디자인 시 "사용자가 최소한의 클릭으로 원하는 정보에 도달" 하도록 흐름을 짜야 함. SEO 뿐 아니라 AI 추천/자동완성 등도 고려해야 한다. GEO라고 했었나? **GEO — Generative Engine Optimization, 생성AI 중심 검색최적화 패턴

🔎 공공 PR 적용

국민들이 정부 사이트·보도자료를 찾아 읽지 않는다.

요약형/자동 추천/한눈에 정보 구조가 필요.

• 기관 발표자료에 “제로 클릭 기반 국민경험 개선”이라는 키워드 활용 검토

• 카드형 요약, 핵심 3초 요약, 한 페이지 완결형 정보 구조

• SNS 콘텐츠도 “1카드에 메시지 하나”

• 복잡한 제도 설명을 앱 알림·리마인더·AI 요약 기반으로 간단히

필코노미 (Feel-conomy)

공공도 감정 기반 커뮤니케이션이 필요하다

감정·기분이 소비의 중심이 된다—이성적 기능이나 가격보다 ‘느낌’이 구매를 움직이는 요소로.

사용자의 감정을 자극하는 UI/UX, 브랜드 메시지, 콘텐츠 기획이 중요.

🔎 공공 PR 적용

공공기관은 ‘객관·사실·절차’ 중심 메시지를 반복하는 경향

하지만 국민을 움직이는 건 감정적 공감→행동 변화

• 보건, 환경, 안전 캠페인에서
• “정보 전달”보단 “감정 스토리텔링”*이 행동 변화를 더 잘 만든다는 인사이트로 기획안 설득

예:

- 재활용 캠페인 → “내가 버린 하나로 누구의 하루가 달라질까?”

- 고독사 예방 → ‘당신이 생각보다 중요한 사람입니다’ 감정선 메시지

휴먼 인 더 루프 (Human-in-the-loop)

AI 시대일수록, '사람의 개입'이 신뢰를 만든다.

AI가 기능을 대체해도 ‘사람’이 개입하고 질문하고 판단하는 단계가 중요해진다는 개념.

디자인, 웹 개발시 AI 도구를 활용하는데, '어디까지 자동'이고, '어디서 어떻게 사람이 개입'하는지가 관건.

🔎 공공 PR 적용

공공기관의 중요한 가치:** 신뢰, 투명성, 책임성**

AI가 정보 요약·자동 응답을 도와도, 최종 메시지는 ‘사람의 눈’으로 검증된다는 스토리를 강조

• “공공서비스 안내 챗봇 + 실무자 점검 프로세스”를 홍보 메시지로 구성
• “AI가 바꾸는 행정, 그러나 최종 검증은 사람” 같은 캠페인 슬로건 제안
• 홍보자료 제작 시, AI 도구 활용 + 최종 인간 편집 과정을 투명하게 설명 (→ 기관의 책임성과 신뢰 확보에 아주 적합한 키워드라서 발표 때 쓰기 좋음.)

레디코어 (Ready-core)

불확실성 시대에 스스로 대비하고 준비하는 역량이 중요하다는 의미.

포트폴리오나 브랜딩 구축할 때 ‘변화에 빠르게 대응할 수 있도록 준비됐다’는 인상이 중요.

• “레디코어 기반의 안정적 수행체계 구축”
  1. 리스크 사전 감지 시스템
  2. 다중 대응 시나리오 구축
  3. 즉시 실행 가능한 비상 커뮤니케이션 프로토콜

AX조직 (AX Organization)

AI 전환 시대의 유연 조직 구조

AI 전환(Automation / eXperience) 시대의 조직 형태—유연하고 프로젝트 중심적 조직 구조.

내게 있어서.. 이 트렌드는 “개발 + 마케팅” 교차 역할을 맡을 유연 조직에서 강점

🔎 공공기관 PR에서의 의미

공공기관은 느리고 복잡하다는 이미지

그래서 “AX”는 기관에게 매우 매력적인 변화의 언어

• 기획안에서 "AX 전환" → AI 리포트 자동화, 챗GPT 기반 질의응답, 반복형 디자인 자동화
• “작은 실험 → 빠른 피드백 → 반복 개선” 방식 제안 → 기존의 느린 PR문화와 대비되어 신선.

픽셀 라이프 (Pixelated Life)

작은 경험, 작은 과업, 짧은 콘텐츠가 중심.

크고 길게 계획하기보다 작고 빠르게, 미니 경험을 중심으로 한 삶의 방식. 트렌드가 매우 빠르게 지나간다. 웹/앱 설계 시 ‘마이크로 인터랙션’, ‘짧은 집중 경험’, ‘모바일 기기 최적화’ 등을 강하게 고려

🔎 공공 PR 적용

공공은 ‘대형 캠페인’ 위주 → 그런데 요즘은 짧은 반복 콘텐츠가 더 효과적

• “대형 캠페인 1개 + 피드형 마이크로 콘텐츠 20개” 구성
  • 하루 1분 보건 안내
  • 10초 국민안전 팁
  • 카드뉴스 1장짜리 행정 정보

프라이스 디코딩 (Price Decoding)

국민은 세금이 어디에 어떻게 쓰였는지를 “정확히 알고 싶어한다."

소비자가 가격구조를 해독하고 ‘납득 가능한 가격’에만 지갑을 연다는 흐름.

마케팅 메시지에서 “왜 이 가격인가”, “어떤 가치인가”를 명확히 전달하는 전략이 더 중요 가격 숨기기보다 설명, 설득, 납득시키는 것이 중요.

🔎 공공 PR에서 핵심

세금 사용 정당성 확보

비용 구조의 투명성 전달

• 프로젝트 제안 시 "비용 사용 투명성 콘텐츠 패키지" 설계
• 00사업 홍보 시 -"예산 대비 얼마나 효율/성과 발생했는가" -"비용 구조를 쉽게 풀어 설명" → 신뢰 강화

건강지능 (HQ = Health Quotient)

건강은 행동을 설계하는 중심 가치

단순히 IQ/EQ 넘어서 ‘건강’을 어떻게 관리하고 응용하느냐가 핵심 역량으로 떠오름.

웰니스 관련 마케팅, 프로젝트 기획에서 이 흐름을 잡을 것.

🔎 공공 PR 적용

보건·식품·정신건강 분야 캠페인에 활용 가능

“건강을 돕는 행동 설계”가 요점

• 복지부/지자체 건강 프로그램 홍보
• 건강한 식습관 행동유도 콘텐츠

1.5가구 (1.5 Household)

완전한 1인도, 전통 가족도 아닌 유연 결합형 생활단위

전통적 가족 형태(2인 부모+자녀)도, 완전 독립 1인 가구도 아닌 ‘유연 결합형 생활단위’가 증가한다는 개념. 타겟 층 설정 시 “나 혼자이지만 완전 1인이 아니다”, “유연하게 구성된 생활” 이런 라이프스타일 세그먼트를 고려하면 마케팅 타당성이 높아..질수도?

🔎 공공 PR 적용

정책 타겟을 세분화할 때 매우 유용

청년정책, 복지정책 공공 캠페인에서 중요해짐

• “1인 가구=혼자 사는 사람”이라는 오래된 프레임을 깨고 다양한 생활 단위를 이해하는 기획 제안
• 정책 수혜자 정의할 때 새로운 시각 제시 가능

근본이즘 (Fundamental-ism)

‘진짜’ ‘원조’ ‘근본 있는’ 것에 대한 회귀

복잡하고 빠른 변화 속에서 ‘원조’, ‘진짜’, ‘근본 있는 것’에 대한 회귀 현상이 커진다는 흐름. 브랜드 스토리텔링에서 “진짜”, “기원”, “유래”, “근본 깊이” 같은 키워드를 강화하면 신뢰감과 차별화 생길 수 있다.

🔎 공공 PR 적용

전통, 역사, 지역 유산 캠페인에 딱 맞음

기관의 권위·정통성 홍보에도 효과적

• 지역 축제, 역사 정책, 전통주·문화 콘텐츠 홍보
• “유래·기원·근본” 스토리텔링 구조 개발
• 공공 브랜딩에서 “오래되고 신뢰할 수 있는 정체성” 강조

개인적으로는 개발(Frontend)과 PR 경험 양쪽을 이해하는 입장에서, AX 조직과 AI 기반 협업 구조는 앞으로 AE가 경쟁력을 가지는 핵심 영역이라고 판단한다.

게시판 구현하는 걸 firestore Database로 실습했다.

index.html (게시판 목록) 페이지

index 페이지 만드는 것부터가 어려웠는데...

list라는 클래스를 부여한 div 태그 안에 데이터를 만드는 것부터 시작이다.

import { collection, getDocs, query, orderBy } from "…/firebase-firestore.js"; 파이어스토어에서 쿼리 만들고 문서 묶음 읽는 함수들 로드.

const q = query(collection(db, "posts"), orderBy("createdAt","desc"));

• posts 컬렉션을 대상으로,
• createdAt 필드를 기준으로 내림차순(desc) 정렬하는 쿼리를 생성.

const snap = await getDocs(q);

• 위 쿼리를 실행해서 스냅샷(문서 모음)을 받아옴.

• 목록을 비워서 중복 렌더링 방지(새로고침 느낌).
• 결과에 담긴 각 문서마다 반복
• const d = docSnap.data(); →문서 실제 데이터 객체
• const id = docSnap.id; →문서 ID(문서 식별자).
• const li = document.greateElement('a'); →목록 아이템으로 쓸 <a>생성.
• 읽기 페이지로 이동하도록 링크 설정(쿼리스트링으로 문서 ID 전달)

• 제목 표시. ??(null 병합 연산자): d.title이 null/undefined면 “(제목 없음)”로 대체.
• 날짜 표시. ?.(옵셔널 체이닝): createdAt이 없거나 타입이 달라도 에러 없이 건너뜀.
• Firestore Timestamp라면 toDate()로 JS Date로 바꾸고, toLocaleString()으로 지역 시간 문자열로 변환.

• 완성된 링크를 목록 컨테이너에 추가.

write.html 뜯어보기

불러온 함수들 :

• collection : 컬렉션 선택
• addDoc : 새 문서 추가.
• serverTimestamp: 서버 시간 자동 입력.

• doc : 특정 문서 지정.

• getDoc : 문서 읽기.

• updateDoc: 문서 수정.

url에서 글 ID 읽어오기

• 주소창 ?id=xxxxxx에서 글 ID추출.
• postId 값이 있으면 "수정모드", 없으면 "새 글쓰기 모드."

DOM 요소 변수

• 입력칸, 버튼, 제목 DOM을 변수로 잡아 둠.

수정모드 처리 (then 방식)

• postId가 있으면 글 수정모드 진입.
• Firestore에서 해당 문서 불러와서 제목·내용 입력칸에 채워 넣음.
• ?? "" →값이 없으면 빈칸으로 처리

수정모드 처리 (await 방식)

• await는 async 함수 안에서만 쓸 수 있음.

• Promise가 끝날 때까지 “잠깐 기다렸다가” 결과를 변수에 바로 담아 줌.
• 코드가 위에서 아래로 동기 코드처럼 읽혀서 직관적임.

--

read.html 살펴보기

글 목록에서 항목을 클릭하면 read.html?id=문서ID로 이동한다.
이 페이지에서는 URL에서 id를 꺼내 Firestore에서 해당 문서를 불러오고,
제목/내용/날짜를 DOM에 표시해준다.

• const ref = doc(db, "posts", postId); → 특정 문서 참조
• const snap = await getDoc(ref); → 데이터 가져오기
• 가져온 snap.data()를 화면에 출력

또한 “수정하기” 버튼을 누르면 write.html?id=문서ID로 이동해서
글 수정 모드로 진입할 수 있다.

전체 흐름 정리 (CRUD)

• Create: addDoc()으로 새 글쓰기
• Read: getDocs() / getDoc()으로 목록과 읽기
• Update: updateDoc()으로 수정
• Delete: deleteDoc()으로 삭제 (추가 구현 가능)

배운 점과 회고

이번 실습에서 가장 헷갈렸던 건 then()과 await 차이였다.
처음엔 getDoc(...).then(...) 방식이 익숙했는데,
await로 바꾸고 나니 코드가 위에서 아래로 읽혀서 훨씬 직관적이었다.

또한 ??(null 병합)과 ?.(옵셔널 체이닝)을 사용하면
Firestore에서 값이 없을 때도 페이지가 깨지지 않는다는 점이 인상 깊었다.

마지막으로 serverTimestamp()를 활용하면
글 작성/수정 시점을 서버 기준으로 정확하게 기록하고,
정렬할 때 안정적으로 동작한다는 것도 알게 되었다.

부드럽게 일정한 속도로 흘러가는 스폰서 배너를 만들고 싶었다..

부산국제영화제 클론의 마지막 과제, 푸터 직전 스폰서 로고 슬라이드를 만들었다. 요즘 축제/행사 사이트에서 자주 쓰는 패턴이고, 로고가 딱딱하지 않게 율동감을 주는 장점이 있다.

슬라이더 무한루프 버그 발생...

처음엔 간단해 보였는데… autoplay + loop 조합이 의외로 까다로웠다. 증상은 두 가지:

1. 시간이 지날수록 속도가 둔화

2. 무한루프가 끊김(티끌 같은 멈칫/튐)

원인은 예상 밖이었다. 내가 안전용으로 넣었던 loopedSlides / loopAdditionalSlides가 오히려 문제였다.

왜 문제가 됐나?

• Swiper는 loop:true면 내부적으로 복제 슬라이드를 자동 관리한다.

• 여기에 loopedSlides/loopAdditionalSlides를 과하게 주면,

  • 복제본이 과다 생성 → DOM 재계산/관찰(observer)와 충돌,
  • slidesPerView:'auto'일 때 폭 계산이 흔들려 루프 경계에서 속도 ‘꿀렁’.

결론: 이 두 옵션을 아예 빼거나 아주 작게 두는 게 안정적이었다.

최종 디버깅 (마키 느낌, 부드럽게 무한 흘러가기)

window.addEventListener('load', () => {
  if (window.sponsorSwiper?.destroy) window.sponsorSwiper.destroy(true, true);

  window.sponsorSwiper = new Swiper('.spon-Swiper', {
    slidesPerView: 'auto',
    spaceBetween: 30,
    loop: true,
    watchOverflow: false,     // 슬라이드 수가 적어도 강제 활성

    // ❌ 문제 원인: 과도한 복제 생성
    // loopedSlides: 14,
    // loopAdditionalSlides: 2,

    speed: 6000,              // 한 번 이동 트랜지션 시간(ms)
    autoplay: {
      delay: 0,               // 지연 없이 연속
      disableOnInteraction: false,
      pauseOnMouseEnter: false
    },

    observer: true,
    observeParents: true,
    observeSlideChildren: true,

    on: {
      init(sw) {
        const wrap = document.querySelector('.spon-Swiper .swiper-wrapper');
        console.log('duplicate count:',
          wrap.querySelectorAll('.swiper-slide-duplicate').length);
      }
    }
  });
});

CSS 한 줄로 더 매끈하게:

.spon-Swiper .swiper-wrapper { transition-timing-function: linear; }

옵션 요약:

• loop만 신뢰하고, 복제 개수는 Swiper의 자동 계산에 맡긴다.
• delay:0 + speed로 마키(끊김 없는 흐름) 연출.
• slidesPerView:'auto' + spaceBetween 으로 로고 폭에 맞춰 자연 배치.
• 필요 시 allowTouchMove:false로 사용자 드래그에 영향 받지 않게 할 수 있다.

마크업/이미지 팁(실무 안정성)

• 각 로고 <img>에 width/height 속성을 넣어** CLS(레이아웃 흔들림)** 방지.

• loading="lazy" decoding="async" 사용.

• WebP/AVIF로 용량↓. 흑백→호버컬러 전환도 깔끔:

.sponsor img { filter: grayscale(1); opacity:.7; transition:.2s; }
.sponsor img:hover { filter:none; opacity:1; }

• 로고 링크에 aria-label(스폰서명) 달아 접근성 챙기기.

디버깅 메모(나중에 또 삽질 안 하게)

• 루프가 끊기거나 속도가 흔들리면 먼저 복제 슬라이드 수 확인.

• slidesPerView:'auto' + 이미지 로딩 타이밍 → 가능한 load 이후 초기화.

• 옵션을 더하기보다 빼서 기본 동작을 신뢰.

또한, 디버깅 씨름의 원인은 아니였지만 기억해야 할 지점!

스와이퍼 css 설정 시 주의사항

• 스와이퍼 슬라이더 내 플렉스 설정 시 스와이퍼 자체의 높이값 설정이 필요!! (높이값 설정이 없으면 플렉스가 안먹을 수 있음)
• 스와이퍼랩퍼에는 플렉스 금지!! (자체 설정이랑 충돌나서 오류남)

사실 처음에 firebase가 뭔지 그 개념을 모르는 상태에서 수업을 들었는데,

백엔드, 서버의 mvp 버전이라고 이해하게 됐다.

Firestore는 Firebase에서 제공하는 클라우드 NoSQL 데이터베이스로, 실시간 동기화와 간단한 CRUD 구현이 가능하다.

시작은 init.js 설정

다른 여타 firebase 기능 사용법과 마찬가지로 firestore 또한 init 설정이 필요하다.

firebaseConfig 를 파이어베이스 웹 앱 설정에서 가지고 와 맞춰줘야 한다.

그리고 파이어베이스 서버에서 initializeApp``getFirestore를 import 한다.

export 값은 db (데이터베이스)

firestore 이해하기 - 게시판의 기본 원리

firestore 기본 기능을 이해하기 위한 html 파일이다.

문서를 생성하고, 읽고, 업데이트하고, 삭제하고, 병합하는 기능을 버튼으로 구현했다.

또한 상황체크와 디버깅을 위한 상태출력 영역도 마련했다.

js파일 연결하기

init.js 파일에서 export한 db를 연결시켜주고, 파이어스토어에서 제공하는 함수 또한 import 해준다.

** 각 함수 기능 설명 **

이러한 함수들은 파이어베이스의 내장 함수임으로 from 값을 아래와 같이 설정하면 된다.

DOM 설정

간단하게 DOM을 설정하기 위해 선택자를 const 했다. $ 안에 document.querySelector() 구문을 삽입하는 것. 단, 이 다음 정의 때는 '#' 을 빼뜨리면 안된다는 것에 유의해야 한다.

상황체크를 위한 setStatus

try-catch 구문에서 버그가 났는지 안났는지 직관적으로 알 수 있도록 setStatus값을 변수로 만들어주고~

문서를 읽어왔을 때 화면에 보일 수 있도록 JSON.stringify() 도 활용한다.

문서 생성하기 (setDoc)

버튼을 클릭하면 async 으로 try-catch 구문이 실행된다.

setDoc() 내장함수로 타이틀과 카운트, 태그, 그리고 생성일시(createdAT) 를 설정했다. 이러한 과정이 진행되면 setStatus 변수에 "문서 생성 요청 보냄" 메시지(m)가 출력된다.

생성된 문서 읽어오기 (getDoc)

btnRead 를 클릭하면 getDoc 내장함수를 통해 데이터가 snap 된다.

JSON 문법으로 출력되는 것을 확인할 수 있다.

문서 업데이트하기 (updateDoc)

업데이트 버튼을 누르면 updateDoc() 와 increment() 내장함수를 통해 카운트가 올라간다.

또한 프로필-닉네임 속성과 테스터라는 값이 추가된다. 업데이트 시간 또한 serverTimestamp()를 통해 남겨진다.

업데이트 버튼을 8번 눌러서 ㅋㅋ 카운트 숫자가 8이 됐다.

필드 병합하기 (merge: true 옵션)

필드를 병합하는것은 setDoc 함수 안에 merge: ture를 적용하면 된다.

이러한 방식과 updateDoc의 차이는, updateDoc의 경우 업데이트 할 문서가 없으면 에러가 나지만 이 경우 문서가 없더라도 오류가 나지 않고 생성되며, 있다면 일부만 수정된다.

문서 삭제하기

삭제 버튼을 누르면 뭔저 컨펌창으로 "정말 삭제하시겠습니까?" 확인한다. 컨펌창에서 '취소' 즉, false 값이 반환되면 리턴하고, 만약 그렇지 않다면 deleteDoc() 함수가 실행된다.

그러고 나면 setStatus 메시지에 "삭제 완료(요청 보냄)"이 출력되고, 실제로 문서가 파이어베이스 데이터베이스 상에서도 삭제된 것을 확인할 수 있다.

느낀점

게시판의 기본 원리를 이해할 수 있었다는 점에서 고무적이였다.

단순히 게시판의 디자인만 공부하는 게 아니라, 이렇게 동작 원리까지 알고 있는 것이 향후 서비스 기획이나 디자인을 진행할 때 도움이 될 것이라고 생각한다.

또한, 작은 CRUD 게시판을 직접 만들어보는 것도 좋은 연습이 될 것 같다

유료 옵션이나 서버 연동 방식도 있지만, 연습용/포트폴리오용 프로젝트라면 부담스러운 게 사실..

그래서 이번 글에서는 카카오 JavaScript SDK를 이용해 ‘가짜 로그인 흐름’을 만들어 본 과정을 기록해봤다.

카카오 '가짜'로그인 흐름 구현해보기

1. kakao-init.js 설정

시작은 카카오 데벨로퍼 페이지에서 친절하게 설명된 것 그대로 따라한 init.js 만들기!

그리고 login.html에 카카오 로그인 JavaScript SDK 파일을 포함시켰다.

• ${VERSION} 은 v1으로 적용했다
• 참고로 v2도 나왔다고 한다.

v1 vs v2: 카카오 SDK v2는 v1을 개선한 최신 버전으로, ES6+ 환경에 맞춰 코드 구조가 단순해졌다고 한다. (신규 프로젝트는 v2 권장)

** integrity...?** 브라우저가 리소스를 변조되지 않은 상태로 받았는지 확인하기 위한 SRI(Subresource Integrity) 값입니다. (보안 강화를 위해 제공됨)

crossorigin="anonymous": 다른 도메인에서 불러온 리소스라도 쿠키나 인증 정보를 포함하지 않고 가져오는 설정. (역시 보안 목적)

카카오 로그인 버튼 만들기

카카오 로그인 버튼 삽입하기. 카카오 데벨로퍼 사이트에서는 디자인 가이드도 제공하고 있다.

리소스도 다운로드 받을 수 있어서, 간단하게 png로 다운받았다.

버튼 높이값이 좀 아쉽긴 하지만 ㅠ 지금은 기능 구현이 우선이니까~~

콜백용 html 만들기

실제 서비스라면 받은 토큰을 서버에서 검증 → 세션/DB에 저장 → 사용자 인증 관리 단계까지 거쳐야 한다.

하지만 이번 연습에서는 단순히 로그인 성공! 메시지를 띄우는 정도로, 프론트엔드에서만 동작하는 가짜 로그인 흐름을 구현했다.

때문에, 로그인 토큰을 받을 서버가 없으니 callback용 html을 따로 만들어야 했다.

그리고 그 html에 진짜 서버 연동은 없지만 페이지에서는 로그인 된것처럼 처리할 수 있다.

• 카카오데벨로퍼 사이트에서 앱 키를 다운받아서 맞춰줘야 한다.

페이지가 여러개라 생각보다 이것저것 맞춰줘야 할 게 많았음. 카카오 데벨로퍼 사이트에서 사이트 도메인도 등록해줘야 하고, 리다이렉트 uri가 특히 헷갈리고 할 것들이 많았다.

✅ 리다이렉트 URI 설정 시 체크할 것

1. 카카오 개발자 사이트 → 앱 설정에서 리다이렉트 URI 등록
2. init.js → redirectUri 값 동일하게 지정
3. callback.html → 해당 파일 경로가 일치해야 정상 작동

카카오 데벨로퍼 사이트에서도 맞춰주고~

이닛 파일에서도,

콜백화면에서도 맞춰줘야 함.

여차저차 맞춰주니까,

제대로 작동한다 ㅎㅎ

마무리로 깃허브 업데이트 푸시까지 완료!

👉정리

Firebase에서는 카카오 로그인을 기본 지원하지 않는다.

• JavaScript SDK를 이용하면 포폴용 가짜 로그인 흐름 정도는 구현할 수 있다.
• 리다이렉트 URI, 앱 키 설정 등 여러 곳을 꼼꼼히 맞추는 게 핵심 포인트다.

이후 실무 프로젝트에서는 서버 검증/토큰 관리까지 붙여야 하니, 이번 경험이 좋은 디딤돌이 될 듯하다.

오늘 하루 고생했습니다 나 자신~

Firebase Authentication UI를 만들면서, CSS는 Tailwind CSS 를 활용했다. 이번 글에서는 Tailwind CSS가 뭔지, 그리고 왜 쓰면 편한지 직접 느낀 경험을 기록해둔다.

Tailwind CSS란?

• Tailwind CSS = “디자인용 레고 블록”
• 기존 방식: CSS 파일에 .button { color: red; } 이런 식으로 직접 스타일 정의
• Tailwind 방식: HTML 태그 안에 바로 class="bg-red-500 text-white p-4 rounded" 처럼 클래스 이름만 붙여서 스타일 완성

👉 즉, 미리 준비된 “스타일 조각”들을 가져다가 조립하는 느낌이다.

일반 CSS VS Tailwind CSS 예시 비교

<!-- 일반 CSS -->
<button class="btn">회원가입</button>

<style>
  .btn {
    background: blue;
    color: white;
    padding: 8px 16px;
    border-radius: 8px;
  }
</style>

<!-- Tailwind CSS -->
<button class="bg-blue-500 text-white px-4 py-2 rounded-lg">
  회원가입
</button>

✅ 차이점: CSS 따로 안 쓰고, HTML 클래스만으로 바로 스타일링 가능!

Tailwind CSS 장점

1. 빠르다

• CSS 새 파일 열고, 클래스명 고민할 필요 없음

• 그냥 필요한 스타일을 class 안에 적으면 끝

2. 일관성 유지

• 팀에서 쓰면, 다들 같은 색상/여백 단위를 공유하게 됨

• text-gray-600, p-4, rounded-lg 같은 표준화된 규칙

3. 반응형도 손쉽게

<div class="w-full sm:w-1/2 lg:w-1/3">내용</div>

→ 화면 크기별로 자동 스타일 적용 (sm, md, lg 같은 prefix 사용)

반응형 프리픽스(sm:, md:, lg: …)가 뭔데?

Tailwind는 모바일 우선(Mobile-first) 이라서, 기본 클래스는 작은 화면에 적용되고, sm:, md:, lg: 같은 프리픽스(prefix) 를 붙이면 그 너비 이상에서 덮어써서 적용된다.

기본 브레이크포인트(기본값)

✅ 해석: lg:w-1/3 → 화면이 1024px 이상일 때 너비를 1/3로.

예제 해부

<div class="w-full sm:w-1/2 lg:w-1/3">내용</div>

• 기본(모바일, < 640px): w-full → 가로 100%
• 태블릿(≥ 640px): sm:w-1/2 → 가로 1/2 (2열 레이아웃처럼 보임)
• 데스크탑(≥ 1024px): lg:w-1/3 → 가로 1/3 (3열 레이아웃)

즉, 화면이 커질수록 더 구체적인 규칙이 다음 규칙을 덮어쓴다고 보면 된다.

자주쓰는 클래스 정리

레이아웃/디스플레이

간격(Spacing)

타이포그래피

배경/테두리/모서리/그림자

상태(hover/focus/disabled 등)

위치/기타

실제 사용 시 느낀 점(Firebase 인증 페이지에 적용해보니…)

• 로그인 박스를 만들 때, bg-white shadow-lg rounded-lg p-6만 붙여도 바로 예쁜 카드 완성
• 버튼도 bg-blue-600 hover:bg-blue-700 text-white px-4 py-2 rounded-lg만 쓰면 즉시 현대적인 느낌

👉 디자인 감각 없어도 깔끔한 UI를 만들 수 있었다.

📝 이번에 배운 점

• Tailwind CSS는 “디자인 초보도 안전하게 쓸 수 있는 스타일 사전” 같은 존재다.

• Utility-first 개념 이해: Tailwind는 “작은 유틸리티 클래스 조합”으로 스타일링한다는 철학.

• ** 모듈성:** 같은 컴포넌트를 다른 페이지에서 재사용할 때도, 별도 CSS 수정 없이 그대로 가져다 쓸 수 있다는 점.

• CSS를 따로 작성하지 않아도 되니, 개발 속도가 확실히 빨라진다.

• 반응형 레이아웃까지 클래스 하나로 해결 가능하다.

• Firebase 같은 MVP 개발에서는 Tailwind가 특히 빛을 발한다 ✨

포스팅에 이어 firebase-auth.js 구조를 좀 더 뜯어보면서 복습하고자 한다.

firebase-auth.js는 무슨 역할을 할까?

• firebase-init.js에서 Firebase를 연결해두면, firebase-auth.js는 그 연결된 auth 객체를 기반으로 사용자 인증 관련 기능을 모아둔 파일이다.
• 즉, init이 "Wi-Fi 연결", auth.js는 "인터넷 서비스 사용" 단계.

함수 분류 정리 (회원가입 / 로그인 / 비밀번호 / 로그아웃 / 탈퇴)

✅ Firebase 함수 이름만 봐도 대부분 역할을 직관적으로 알 수 있다.

async / await 다시 짚기

• Firebase 함수들은 서버랑 통신하는 비동기 작업이 많음.
• 그래서 async/await을 붙여야 순서대로 잘 처리 가능.

• async : "이 함수 안에는 기다려야 하는 작업이 있어요" 라고 표시

• await : "이 작업이 끝날 때까지 잠깐 멈춰!" → 치킨 주문 후, 배달 오기 전까지는 먹을 수 없는 것과 같음.

• await 덕분에 "계정 생성 → 프로필 업데이트 → 이메일 발송"이 순차적으로 실행됨.

• 만약 await이 없으면 서버 응답이 오기 전에 다음 코드가 실행되어 에러 발생 가능.

1️⃣ "비동기(async)"라는 말의 뜻

• 동기(Synchronous): 일이 한 줄로 차례차례 진행되는 것. 👉 예: 편의점에서 계산대 줄 서기. 앞사람이 끝나야 내가 계산 가능.

• 비동기(Asynchronous): 동시에 여러 일을 처리할 수 있는 것. 👉 예: 배달 주문하기. 치킨 시키고, 치킨이 올 때까지 공부도 하고 빨래도 할 수 있음. 치킨이 다 와야 먹을 수 있듯이, "결과는 나중에" 옴.

✔️ 자바스크립트에서 서버랑 통신하는 대부분의 작업은 비동기다. 왜냐면 서버 응답이 언제 올지 모르니까, 기다리는 동안 프로그램이 멈추면 안 되기 때문.

2️⃣ 왜 await라는 단어를 쓸까?

• await 은 "이 비동기 함수가 끝나서 결과를 돌려줄 때까지 멈춰라"라는 의미
• 그 동안 아래 줄 코드들은 실행되지 않고 기다린다.
• createUserWithEmailAndPassword 같은 파이어베이스 내장 함수는 실행되고 나면 Promise(결과 약속)를 돌려준다.
• await 덕분에, 이 약속값이 돌아오기 전까지 아랫줄의 코드들은 실행되지 않고 오류를 막을 수 있다.

3️⃣ try/catch 라는 표현은 왜 쓸까?

• "에러가 날 수도 있는 코드를 시도해보고, 에러가 나면 그걸 잡아서 처리하겠다"는 의미.

try {
  const user = await createUserWithEmailAndPassword(auth, email, password);
  console.log("회원가입 성공:", user);
} catch (error) {
  console.log("회원가입 실패:", error.message);
}

• try = 유저한테 이메일이랑 비밀번호 받아서 회원정보 생성하는 것 시도
• catch = 만약 정보가 안 오거나, 오류가 생기면 그 상황을 잡아서 알려줘.
• *try / catch 구문 덕분에 프로그램이 중간에 뻗어버리고 나머지 코드가 실행 안 되는 상황을 방지할 수 있다. *

이 js파일에서도 마찬가지로 임포트를 했으니 익스포트를 한다.

export는 왜 할까?

• firebase-auth.js에서 만든 함수를 다른 파일에서 쓸 수 있도록 공개하는 역할.
• 예시:

  // firebase-auth.js
  export const logout = async () => {
  await signOut(auth);
  };
  

// dashboard.js import { logout } from './firebase/firebase-auth.js';

👉 **"auth.js에서 정의한 기능을 dashboard.js에서도 재사용 가능"**

---

## 이번에 배운 점 ✨

- Firebase Authentication 함수는 이름만 봐도 역할이 직관적이다.

- 모든 함수가 **비동기(async)**라서 await과 try/catch로 에러 처리를 해주는 게 안정적이다.

- export/import 구조를 활용하면, 인증 관련 코드를 모듈화해서 깔끔하게 관리할 수 있다.

🚀 Firebase Authentication 기초 다지기

오늘의 공부 주제는 Firebase, 그중에서도 Authentication(인증) 기능이었다. Firebase를 활용하면 별도의 백엔드 서버를 직접 구축하지 않고도 회원가입부터 로그인, 로그아웃까지 기본적인 사용자 인증 흐름을 손쉽게 구현할 수 있다.

📌 오늘 구현한 인증 워크플로우

• 회원가입 (Sign Up) 이메일·비밀번호로 계정을 생성하고, updateProfile을 이용해 닉네임을 저장했다.

• 이메일 인증 (Email Verification) 가입 직후 인증 메일을 발송해 실제 사용자인지 확인.

• 로그인 (Sign In) signInWithEmailAndPassword를 사용해 로그인 처리. 로그인 상태는 onAuthStateChanged로 실시간 감지했다.

• 로그아웃 (Sign Out) signOut(auth) 호출로 세션 종료 후 로그인 페이지로 리다이렉트.

• 비밀번호 재설정 (Password Reset) sendPasswordResetEmail을 통해 비밀번호 재설정 링크를 사용자 이메일로 전송.

• 회원탈퇴 (Delete User) deleteUser를 호출해 현재 로그인한 계정을 삭제하는 기능까지 추가.

[회원가입] - [이메일인증] - [로그인] - [로그아웃] - [비밀번호 재설정] - [회원탈퇴]

위 워크플로우를 담고 있는 페이지를 만들어 gitHube로 배포했다 -> 클릭시 배포된 데모사이트로 이동됨

🔧 Firebase 프로젝트 생성

Firebase Authentication을 쓰려면 *프로젝트 생성 → 앱 등록 → SDK 설정(init 파일 생성) * 순서가 필요하다.

그다음 firebase-init.js에 initializeApp과 getAuth를 설정해두면, 다른 파일에서 auth 객체를 가져다 쓸 수 있다.

Firebase 프로젝트 생성, 왜 필요한 걸까?

우리가 만든 웹사이트가 Firebase(구글이 제공하는 서버)랑 대화하려면, 먼저 “내 사이트가 Firebase랑 연결돼 있어요” ** 하고 알려줘야 한다. 이걸 **프로젝트 만들기 + 앱 등록하기라고 표현하는 것.

init 파일(firebase-init.js)은 뭐야?

firebase-init.js 는 쉽게 말하면 “우리 집 Wi-Fi 비밀번호 메모” 같은 것이다.

• Firebase에 접속할 때 필요한 열쇠(설정값들: apiKey, projectId 등)를 적어둔 파일.
• 그 덕분에 다른 JS 파일에서 그냥 auth라고 불러오면 → “아, 얘는 이미 Firebase랑 연결돼 있구나!” 하고 바로 로그인/회원가입 기능을 쓸 수 있다.

코드로보면

// firebase-init.js
import { initializeApp } from "firebase/app";
import { getAuth } from "firebase/auth";

const firebaseConfig = {
  apiKey: "열쇠1",
  authDomain: "열쇠2",
  projectId: "열쇠3",
  // ... 등등 Firebase가 준 열쇠들
};

// Firebase랑 연결 시작
const app = initializeApp(firebaseConfig);

// 인증(auth) 기능 꺼내오기
const auth = getAuth(app);

export { auth };

• 프로젝트 생성 = "내 이름으로 구글 서버(파이어베이스)에 계정 만들기

• 앱 등록 = "내 핸드폰(웹사이트)도 내 계정이랑 연결하기"
• firebase-init.js = “Wi-Fi 비밀번호를 적어둔 메모장”
• auth 객체 = “이제 이 비밀번호로 인터넷(Firebase 인증 기능)을 쓸 수 있음”

👉 그래서 결론: firebase-init.js 파일이 있어야, 다른 파일에서 회원가입·로그인 코드를 쓸 때 Firebase가 “아, 이 앱은 이미 연결돼 있으니까 인증 기능 써도 돼” 하고 허락해준다.

firebase.. 어디서 뭘 가져오는거지?

1. from "https://www.gstatic.com/firebasejs/..." 이 주소는 뭐야?

• 이 부분은 Firebase 팀이 제공하는 공식 CDN 주소
• CDN(Content Delivery Network) = 인터넷에서 바로 가져다 쓸 수 있는 라이브러리 저장소.
• 즉, 이 주소에서 firebase-app.js나 firebase-auth.js 같은 파일을 내려받아, 내 코드에서 바로 쓸 수 있다.

👉 쉽게 말해: “내 컴퓨터에 firebase 라이브러리를 설치하지 않고, 구글이 올려둔 서버 주소에서 직접 가져온다.”

2. { initializeApp }, { getAuth } 이건 뭐야?

• 이건 Firebase 라이브러리 안에 이미 정의되어 있는 특정 기능(함수) 의 이름!
• initializeApp → Firebase 앱을 시작하는 함수
• getAuth → 인증 기능(auth 객체)을 꺼내오는 함수

export { app, auth } 의 역할

• 하는 일: 현재 파일(firebase-init.js) 밖에서도 app과 auth를 가져다 쓸 수 있게 공개(export) 한다.

• 왜 필요? 이 파일에서 만든 걸 다른 파일에서 쓰려면 export → import가 필요하다. (안 내보내면 다른 파일에서 접근 불가)

다른 파일에서 쓰는 법:

// 예: dashboard.js
import { auth } from './firebase/firebase-init.js';
import { signInWithEmailAndPassword, signOut } from
  'https://www.gstatic.com/firebasejs/11.2.0/firebase-auth.js';

await signInWithEmailAndPassword(auth, email, password);
await signOut(auth);

** 추가로 기억해야 할 점: 브라우저에서 import/export를 쓰려면 <script type="module"> 로 로드해야 한다.

📝 배운 점

• ** Firebase는 서버리스(Serverless) 구조다** → 백엔드 직접 구축 없이 인증, DB, 스토리지 등을 바로 활용 가능.

• 보안 인식: API 키는 주소표일 뿐 → 진짜 보안은 Firebase Security Rules에서 관리.

• 상태 감지: 로그인 상태는 자동 저장 + onAuthStateChanged로 항상 동기화.

• Firebase는 MVP(최소기능제품) 개발에 특히 유용하다.

• async/await와 try…catch 구문을 적절히 사용해야 안정적인 인증 흐름을 만들 수 있다.

• onAuthStateChanged를 활용하면 로그인/로그아웃 상태에 따라 UI를 동적으로 제어할 수 있다.