치즈네컷이 왜 우리의 북극성 지표인가

유저의 행동 로그를 분석하며 특정 기능의 경험 유무가 재방문율과 강력한 상관관계를 보인다는 점을 발견했습니다. 특히 '치즈네컷' 기능은 유저 리텐션에 있어 핵심적인 역할을 하고 있었습니다.

북극성 지표(North Star Metric)란? 서비스가 제공하는 핵심 가치를 가장 잘 드러내며, 제품이 올바른 방향으로 성장하고 있는지를 판단하는 기준이 되는 단 하나의 지표입니다.

예를 들어, 페이스북의 초기 성장 단계에서 핵심 북극성 지표는 10일 안에 7명과 친구를 맺는 사용자 수로 알려져 있습니다.

우리 서비스에서, 치즈네컷을 한 번이라도 경험한 유저는 그렇지 않은 유저에 비해 재방문 비율이 2~3배 높았습니다. 시간이 지나더라도 이 격차는 유의했고요.

시간 변화에 따른 재방문률

• 1시간 이후 재방문: 미경험자(21.8%) vs 경험자(64.7%)

• 3시간 이후 재방문: 미경험자(19.4%) vs 경험자(60.7%)
• 24시간 이후 재방문: 미경험자(14.1%) vs 경험자(45.1%) (팀원 등 관계자이거나, 비이상적으로 큰 활동량을 보이는 데이터 이상치를 제거하였습니다)

치즈네컷은 유저를 서비스에 안착시키는 북극성 지표로 설정하기에 충분한 가치를 지니고 있다고 판단하였습니다.

그러나 낮은 진입률. 혹시, 부담스럽기 때문일까?

하지만 데이터 상으로 치즈네컷의 중요성에 비해 실제 기능 진입률(확인율)은 기대보다 낮게 나타났습니다. 유저들에게 가장 중요한 가치를 제공하는 지점임에도 불구하고, 많은 유저가 입구에서 발길을 돌리고 있었습니다.

우리는 일차 원인을 CTA(Call To Action) 버튼의 라이팅에서 찾았습니다.

(참고) 서비스 플로우 상, 앨범에 입장한 유저는 버튼을 눌러 앨범 치즈네컷 페이지로 이동할 수 있습니다.

가설 설정: '만들기'라는 단어는 너무 Demanding하다. _치즈네컷 만들기'는 유저에게 '창작'이나 '결과물 완성'이라는 과업의 부담을 준다.

당시 버튼 라이팅이었던 '치즈네컷 만들기'가 유저에게 지나치게 많은 노력을 요구하는 느낌을 준다는 가설을 세웠습니다.

에어비앤비(Airbnb)의 사례를 참고했었는데요, '지금 예약하기(Book Now)'보다 '숙소 둘러보기'나 '예약 가능 여부 확인'처럼 유저에게 낮은 행동 강도를 요구할 때 전환율이 높아졌었다고 합니다.

'미리보기' 동사만 바꿨을 뿐인데, 결과는?

우리는 버튼 문구를 더 가볍고 탐색적인 언어로 변경하여 테스트를 진행했습니다.

• 대조군(A): '치즈네컷 만들기' (기존안)
• 실험군(B): '치즈네컷 미리보기' (심리적 허들 낮춤)
• 라이팅에 따른 단일가설만을 명확히 측정하기 위해, '잠깐! 귀여운데 한 번만 보고가요'라는 툴팁은 두 쪽 모두에 위치시켰습니다.*

[최종 결과] 치즈네컷 조회 전환율: A 그룹(약 7.6%) vs B 그룹(약 29.2%)

• 전환율: 약 29.2% (기존 대비 약 +21.5%p 차이)
• 통계 검정: Proportion Z-test 결과 p-value < 0.001로 통계적 유의성 확보.

'미리보기'라는 라이팅은 유저가 이 버튼을 눌렀을 때 "내가 무엇을 보게 될지"를 명확하면서도 가볍게 전달했습니다. 결과적으로 이 작은 라이팅 하나는 실제 기능 진입으로 이어지는 전환율의 비약적인 상승을 이끌어냈습니다.

(번외) 참고로, '미리보기'라는 라이팅이 최종 전환율에도 기여할 뿐 아니라 *처음 앨범 진입 후 지체 없이 치즈네컷을 보도록 유도**하는 데에도 기여한 것으로 확인됩니다.

결론 및 인사이트

이번 분석과 실험을 통해 얻은 결론은 명확합니다.

• 핵심 경험의 발견: 치즈네컷은 유저 행동 변화를 동반하는 서비스의 핵심 경험이다.
• 라이팅의 중요성: 유저에게 요구하는 행동의 무게를 조절하는 것만으로도 핵심 기능으로의 진입을 크게 개선할 수 있다.

결과는 전달했고, 이번 달 이내에 '미리보기'로 통일할 예정입니다. 다만 아직도 A/B 분기를 유지 중이어서, 여러분께서 서비스에 들어오면 '치즈네컷 만들기' 내지는 '치즈네컷 미리보기' 중 하나를 보게 되실 겁니다.

https://say-cheese.me/album/entry/1f13b0b2-cbeb-6cd0-9a59-254db8d7dd3b 앨범을 만들어두었으니 참여하셔도 재밌을 것 같아요 :)

치이이즈 팀은 앞으로도 데이터를 바탕으로 유저의 심리적 허들을 낮추고, 치즈네컷과 같은 핵심 가치를 더 많은 유저가 경험할 수 있도록 서비스를 최적화해 나갈 예정입니다.

[분석 참고]

• 유저 A/B 분류는 프론트 단에서 무작위로 이루어졌습니다.
• 앨범 단위가 아닌 유저 단위로 A/B에 배치되었습니다.
• 3월 26일 이후 데이터를 이용하였습니다.
• 유저 총 251명의 데이터를 이용하였습니다(A 그룹은 131명, B 그룹은 120명으로 구성되었습니다)
• 팀원의 데이터는 제외했으며, 95%를 넘는 이상치는 제거하였습니다)

치이이즈에서도 그동안 우선순위에 밀려 백로그에만 잠들어 있던 랜딩페이지에 대한 고민을 이번 기획단에서 정식으로 꺼내게 되어 소개하려고 합니다.

랜딩페이지란

잠재 고객이 광고나 링크를 통해 처음 도착하여, 서비스의 가치를 확인하고 특정 행동(가입, 구매 등)을 하도록 설득하는 단일 페이지예요.

웹페이지는 그 목적에 따라 수많은 형태로 존재하지만, 그중 랜딩페이지는 '전환'이라는 단일 목표를 위해 탄생한 가장 전략적인 도구입니다.

사용자의 특정 행동(CTA, Call to Action)을 이끌어내기 위해 시각적 흐름을 하나로 설계하기 때문이에요.

	채용 / 기업 소개 페이지	B2B SaaS 서비스	커머스 상세 페이지
이미지
설명	기업의 비전과 컬쳐를 긴 호흡으로 설명하며 사용자를 설득하고, 지원 / 합류하기로 안내	페인 포인트 → 핵심 기능 → 검증된 고객사 순으로 신뢰를 쌓아 문의하기 / 데모 신청으로 전환	CTA가 상단에 먼저 노출되는 리버스 구조로, 제품 설명과 후기를 통해 구매 결정을 강화

서비스의 성격에 따라 정보의 순서와 강조점은 달라질지언정, 사용자의 심리적 허들을 낮추고 약속된 행동(CTA)을 유도한다는 본질만큼은 모두 같아요.

과거 인턴 시 법률사무소 웹디자인을 했었는데, 그때도 핵심 지표는 결국 상담 신청 전환율이었어요. 판례나 변호인단 이력 같은 정보는 신뢰를 쌓기 위한 요소일 뿐, CTA 클릭을 유도하지 못한다면 효용이 없다고 판단하였습니다.

치이이즈의 랜딩페이지

치이이즈는 v1.0에서 ‘앨범 만들기’ CTA를 유도하는 세로형 랜딩페이지를 채택했지만, 실제 사용자 맥락에 맞는 구조나 내용이 아님은 인지하고 있었어요.

[현 랜딩페이지의 한계점]

• 서비스를 대표하지 않는 화면의 목업이 재생돼요
• '7일만 열린다'는 점은 서비스의 넛지 장치일 뿐, 사용자의 사용/비사용을 일단락하는 효용적 기능은 아니예요
• '앨범 만들기'와 '로그인'이라는 기능적으로 MECE하지 않은 두 라우팅 기능이 존재했어요

그럼에도 치이이즈에서 해당 구조를 선택했던 이유는요,

첫째, 대부분의 유입 경로는 랜딩페이지를 통하지 않기 때문이다

어차피 우리 유저는 앨범 링크 타고 바로 들어오는 참여자가 대부분이에요. 프로젝트 두 달 내에는 랜딩페이지를 가꿀 시간에 앨범에 리소스를 더 투여하는 의사결정을 진행했었어요.

둘째, 확률적으로 대부분 유저의 상태로는 랜딩페이지를 볼 수 없다

서비스 주소(say-cheese.me/main)가 곧 마이페이지 경로와 같았어서, 로그인한 유저는 랜딩을 볼 새도 없이 자기 사진첩으로 직행합니다.

그래서 기존 랜딩은 '우리가 누구인지는 알려줄게' 정도의 구색 맞추기에 가까웠어요.

👌 '알면 알수록 좋은 서비스네요', 칭찬일까?

그런데 서비스 배포 후, 랜딩페이지를 개선해야겠다는 생각이 점점 커졌어요 2월 초에 해결할 백로그라 생각하진 않았는데, 우선순위가 '최상'으로 올라갔습니다.

랜딩페이지의 문제를 잡아내 말한 사람이 있지는 않았지만, 여러 피드백을 종합했을 때 더 친절한 랜딩페이지가 있었다면 없었을 문제가 많았어요

*1. 떨어지는 서비스 가치 전달력 *

UIBOWL 디자이너분이 '뭘 하는 서비스인지도 모르겠는데 로그인부터 하라고 유도하는 것 같았다'는 피드백을 주셨어요.

팀 내에서 전부터 회원 전환율에 대한 걱정이 컸어요. 로그인 기능이 내재적으로 갖는 허들감이라고 생각했었는데, (내지는 로그인 과정 이후 추가 정보를 받을 때에 이탈한다-는 가설을 세웠었는데) 회원가입하며 로그인의 허들을 넘을 가치를 보여주지 않아서라는 새로운 가설을 세우게 되었습니다.

*2. 킥 기능까지 도달하지 않는 스크롤 *

비로그인 유저의 스크롤 길이는(기존 유저 제외) 킥 기능 스크롤 위치만큼 도달하지 못하고 있었어요.

3. 이런 기능이 있었어요?

베타테스터들의 반응이 결정적 근거였어요. "와, 써보니까 진짜 편하고 좋은 기능이 많네요!" 이 말은 즉, 써보기 전엔 뭐가 좋은지 전혀 몰랐다는 뜻으로 들렸습니다.

우리는 '기능'을 숨겨놓았었네요. 유저가 우리 서비스의 매력을 발견할 때까지 인내심을 갖고 기다려줄 리 만무했습니다.

🤩 온보딩형 랜딩페이지로의 전환

우리는 페인포인트나 사용 맥락을 넣으며 길게 늘어지는 스크롤 방식 대신, 앱 온보딩처럼 한 장씩 넘기며 핵심만 쏙쏙 박아넣는 '온보딩형 랜딩페이지'를 새로 구상했습니다.

온보딩형 랜딩페이지란? 스크롤의 지루함 없이, 서비스 요약 1장 + 핵심 기능 소개 3장 + 가입 유도(CTA) 1장 정도로 구성된 슬라이드 방식

넷플릭스는 '영화를 본다!'는 목적이 명확하고, 사용해보지 않아도 플로우가 직관적으로 다가오는 서비스예요.

UX플로우에 대한 납득을 시킬 필요가 적기 때문에 기능으로 딱딱 떨어지는 온보딩형 페이지를 선택하고 있답니다.

이때, '오프라인으로도 다운받아 볼 수 있다', '넷플릭스 오리지날이 있다' 등 여기서의 킥들이 있는데, 그게 온보딩에 들어가요. 'No pesky contracts'라는, 언제든 떠날 수 있다는 것은 기능은 아니지만 허들을 낮추는 유의한 정책일 거구요.

치이이즈에서도 '7일만 열리는 앨범', '띱', '치즈네컷' 같은 독특한 킥이 있기에 한 화면에 하나씩 임팩트 있게 보여주도록 기획했습니다.

디자인적으로 표지와 내부 사진 무드에 대한 논의를 진행중입니다만, (실사진이 들어가기 어렵고 예쁘지 않아, 어떤 목 이미지를 사용할 것인지에 대한 숙고) 이런 방향으로 얼라인이 되어 2월 17일 중으로 화면에 반영이 될 것 같습니다.

해당 변화가 서비스에 긍정적 영향이 되기를 바라며 .. 😎🤍

• 치이이즈가 시도한 4가지 대표 프로모션 전략

• 각 방식에 대한 KPT
• 프로모션의 효과를 정량적으로 판단하며 매몰 비용을 수렴시켜 나가는 유의성 검증 과정 을 해당 포스트에서 공유해보려 합니다.

우리에게는 로그를 만들어낼 유저가 필요해요

개발자들이 1월 21일까지 로그 환경 세팅을 위해 달릴 때 치이이즈 기획자와 디자이너의 생각은 하나였습니다.

어떻게든 서비스에 유저를 데려와야 한다 🫡

사이드 프로젝트의 동기부여에는 서비스에 대한 애정과 개인 성장도 중요하지만, '내가 하고 있는 일이 누군가에게 닿고 있다'는 효능감이 가장 강력한 동력이기 때문입니다.

저희는 로그가 찍히기 시작할 22일에 맞추어 유저를 들일 세 가지 프로모션 전략이 있었습니다.

🌍 치이이즈 세 갈래의 유입 설계

*1. [유료집행형] 베타테스터 모집 *

각자의 약속에서 서비스를 사용해 줄 10여팀의 베타테스터를 모집했습니다. 사용 후에 서비스에서 인지된 기능, 좋았던 점, 아쉬웠던 점에 대한 설문을 작성하게 해서 로그로 행동 데이터를 추적할 수 있을 뿐 아니라, 질적 VoC 또한 받아볼 수 있었습니다.

💡 [ 베타테스트 사용 후기 설문 항목 ]

- 이번에 만든 이벤트 이름이 무엇인가요?
- 이번에 치이이즈를 사용한 이벤트의 유형은 무엇인가요?
- 치이이즈 서비스를 제안한 후, 모임 채팅방의 반응이 어땠나요?
- 아래 기능 중, 사용하면서 인지된 기능을 모두 선택해주세요
- 치이이즈에 대해 좋았던 점이 있으면 알려주세요
- 치이이즈에 대해 불편했거나 아쉬웠던 점이 있다면 알려주세요!
- 이후에도 치이이즈를 사용할 의향이 있나요?
- (어떤 경우에 사용할 것 같나요? or 왜 사용하고 싶지 않을 것 같나요?)
- 치이이즈를 지인에게 추천하고 싶은 정도를 표시해주세요
- 추가로 건의하고 싶은 점이나, 자유롭게 남기고 싶은 의견이 있다면 적어주세요

베타테스트 후, 느낀 점을 회고하자면 아래와 같습니다:

🔎 설계 중 유의했던 점

(1) 정보 누출을 경계했습니다
테스터들이 사용법을 완벽히 숙지하고 들어오면,
우리 서비스가 얼마나 직관적인지 혹은 어떤 지점에서 기능을 인지하지 못하는지라는 핵심 가설을 확인할 수 없습니다.
그래서 실사용자와 동일한 눈높이를 맞추기 위해 따로 사용법이나 가이드를 제공하지 않고 서비스에 던져두었습니다.

(2) 운영의 묘: 확실한 보상과 검증
VoC 구글폼으로 이벤트 이름을 직접 받아 실제 참여 여부를 대조하며 보상의 투명성을 높였습니다.
참여자 전원 보상과 더불어 '베스트 리뷰어 3만 원'이라는 강력한 트리거를 제공하니, 유저들이 훨씬 더 열정적으로 피드백에 참여해 주었습니다.

✨ 좋았던 점

(1) 네트워크 효과의 확인
테스터 한 명을 보상했을 뿐인데, 그와 연결된 3~4명의 지인 행동 데이터까지 덤으로 수집되었습니다. 효율적인 유입 구조를 실감한 순간이었습니다.

(2) 고품질의 피드백
행동 데이터뿐 아니라 UI/UX에 관심 있는 유저들이 개인적으로 장문의 QA 리스트를 보내주는 등 질 높은 VoC를 확보할 수 있었습니다.

🤕 아쉬웠던 점

노쇼의 발생: 신청만 해두고 실제 사용이나 후기 작성까지 이어지지 않는 인원이 존재했습니다.
다행히 전원 보상 정책 덕분에 큰 이탈은 막았지만, 참여 허들을 더 정교하게 설계할 필요를 느꼈습니다.

비용의 압박: 전원 보상에 상금까지 합치니 최대 10만 원 정도의 지출이 예상되었습니다.
팀원들의 사비로 진행되는 만큼, 이 비용을 상쇄할 만큼의 유의미한 지표를 뽑아내야 한다는 책임감이 더 커졌습니다.

최종적으로 베타테스트 방식은 초기 VoC를 수집하고 서비스를 알리는 데는 유의미했지만, 회차가 반복될수록 얻을 수 있는 정보의 밀도가 낮아질 것이라는 판단이 들었습니다. (이번 VoC에서 개선 제안을 받은 많은 부분도, 인지하고 있지만 리소스 상 후순위로 밀린 백로그들이 많아 이 이상 받는 것은 팀에 피로감이 높아질 것 같습니다)

너무 도움 되는 방식이었지만, 앞으로 치이이즈에서는 지속 가능한 유입을 위해 유료 집행보다는! 더 유기적인 홍보 방식을 찾을 것 같습니다.

갠톡으로 의견준 사람들도 감사합니다 :)

2. [관계기반형] 현장 침투

팀원들이 참여하는 여행, LT, 번개 모임 등 현장에 서비스를 사용하는 방식입니다. 고품질의 UGC 또한 확보할 수 있었고, 일부는 인스타그램 홍보물로도 사용할 예정입니다.

해당 방식은 좋았지만, 지인들이다보니 어느정도 이염이 존재했어요(귀찮더라도 귀찮다고 말 못함 등) 사적 관계가 아닌 당근 경찰과 도둑이나 감튀모임, 혹은 언어교환 모임에서 이용해도 너무 좋을 것 같아, 개인적으로 앞으로 그런 모임에도 주도적으로 참여해볼 예정입니다.

3. [경험제공형] 이벤트 주최

모임의 '말단'에서 사용되는 서비스라면, 아예 우리가 모임을 열어 사용 환경을 제공해 보기로 했습니다. 상영회 등 컨셉츄얼한 모임을 직접 기획하여 유저들에게 차별화된 가치를 제공함과 동시에 치이이즈를 자연스럽게 경험하게 했습니다. 특히 이벤트를 열고 모집하는 서두 서비스인 무비부키와 적극적으로 협력 중에 있습니다.

며칠 전에는 환승연애4 막화 단체관람을 주최하며 무비부키와 치이이즈를 사용했었습니다. 이번 환승연애4 단체관람은 팀원들끼리의 행사였다면 2월 중으로는 외부 인원들을 위한 이벤트를 기획 중에 있습니다.

4. 커뮤니티를 활용한 서비스 홍보

동시에 UIBOWL, UI/UX 오픈채팅방 등에 컨택하며 사이드 프로젝트 경험 공유와 함께 홍보를 요청했고 예상보다 높은 관심과 자연 유입으로 이어졌습니다.

특히나 UIBOWL 사이트에 inspire로 올라가며 직접 디자이너분들께서 개선안을 언급해주시기도 하셨습니다.

유입 효과가 매우 크고, 개선 방향에 대한 조언도 질 높게 들을 수 있었지만 커뮤니티 개수가 무한하지는 않은 점, 그리고 최초 유입(Acquire)은 높을 수 있지만 핵심 사용자로 전환이 굉장히 낮을 것이기에 여러 번 사용할 수 있는 프로모션 전략은 아닌 것 같습니다.

다른 커뮤니티에는 보다 디자인적으로 완성된 이후에 한 번 더 (4-5월 경) 크게 컨택드릴 예정입니다.

➕ 이제 퍼포먼스 마케팅 성과 책정이 필요한 시점

하지만 유저가 늘어나는 즐거움 뒤에는 PM으로서 피할 수 없는 부채의식이 자리 잡고 있었습니다. 서버비와 프로모션 비용을 팀원 7명이 사비로 부담하고 있었기 때문입니다. 현재로서 수익 모델이 힘을 쓸 수 없는 상황에서 동료들의 자원을 쓰는 것은 늘 무거운 마음을 동반했습니다.

저는 팀원들에게 두 가지를 약속했습니다.

첫째, 모든 지출은 유입 목적이 명확한 곳에만 집행하며, 이벤트 주최의 경우 협찬 등을 통해 개인 부담 비용을 0으로 수렴시키겠다. 둘째, 각 채널별 CPC(Click Per Cost)와 전환 비용을 산출하여 가장 효율적인 지점을 찾아내겠다.

현 시점에서는 여러 채널을 두드리고, 닿는 지점을 넓히는 것이 비용보다 중요하지만 점점 홍보 데이터베이스가 쌓여갈수록 효과 낮은 채널을 버리고 효율성을 찾겠다는 뜻이었습니다.

이에 집행했던 홍보 방식을 기록하고, 비용과 이에 대한 실 유입 인원, 유의성을 기록하며 데이터를 쌓고 있습니다.

결국 PM인 제가 할 수 있는 최고의 보답은 팀원들의 지출이 아깝지 않은 '성과'를 숫자로 증명해내는 것이었고, 이 지점이 퍼포먼스 마케터 직무가 존재하는 이유이지 않을까 생각했던 것 같습니다.

🤔 그렇다면 유의성은 어떻게 측정할 것인가? 올랐다, 아니다로만 충분할까?

1월 22일부터 베타테스트 시행과 인스타그램 게시글 마케팅을 통해 사용자들이 유입되었고, 1월 28일을 기점으로 지표가 눈에 띄게 상승하기 시작했습니다. 그래프가 우상향하는 것을 확인한 짜릿한 순간이었지만, 상당히 어려운 논제가 생겼습니다.

그래서, 이 상승은 정확히 어떤 프로모션의 결과인가?

1/28일 결과를 분석해야하던 1/29일 당시 상황은 꽤 복잡했습니다.

- 전날의 인스타그램 홍보
- 당일 유입된 베타 테스터들
- 서비스 큐레이션 사이트인 UIBOWL 게재 효과까지

*여러 이벤트가 지층처럼 겹쳐진 경첩 상태였기 때문입니다. * 지표는 올랐지만 정작 어떤 채널이 핵심이었는지 알 수 없는 상황에서 운이 좋았다고 말하는 것은 의미 있는 결론은 아니었습니다.

중첩된 데이터 속에서 각 프로모션의 기여도를 정교하게 발라내야 했습니다.

1. source, medium, page_referrer 기반으로 판단하기

WITH user_first_log AS (
    -- 유저별로 가장 처음 발생한 이벤트 로그 하나만 추출
    SELECT 
        user_pseudo_id,
        ts_source,
        ts_medium,
        page_referrer,
        page_location,
        event_ts,
        ROW_NUMBER() OVER (PARTITION BY user_pseudo_id ORDER BY event_ts ASC) as rn
    FROM `saycheese-484314.analytics_517953491.event_base`
),
refined_channels AS (
    -- 규칙에 따라 경로 재분류
    SELECT
        user_pseudo_id,
        CASE 
            WHEN ts_source LIKE '%kusitms%' THEN 'kusitms'
            WHEN ts_source LIKE '%instagram%' OR ts_source = 'ig' THEN 'instagram'
            WHEN ts_source LIKE '%google%' THEN 'google'
            WHEN ts_source LIKE '%facebook%' THEN 'facebook'
            WHEN ts_source = '(direct)' THEN 
                CASE 
                    -- Direct일 경우 접속 주소(page_location)로 세분화
                    WHEN page_location LIKE '%/album/%' THEN 'direct_album_link'
                    WHEN page_location LIKE '%say-cheese.me/' THEN 'direct_homepage'
                    ELSE 'direct_others'
                END
            ELSE 'others'
        END AS final_source,
        page_referrer,
        event_ts
    FROM user_first_log
    WHERE rn = 1 -- 유저별 최초 유입 시점만 남김
)
-- 3. 최종 분류된 소스별로 유저 수 카운트
SELECT 
    final_source,
    COUNT(DISTINCT user_pseudo_id) AS new_user_count
FROM refined_channels
GROUP BY 1
ORDER BY 2 DESC;

가장 처음 해본 것은 GA에서 추적하는 source, medium, 그리고 page_referrer를 기반으로 유입 매체를 파악하는 것이었습니다. 다만 UIBOWL과 인스타그램 모두 홈페이지 링크를 바로 연결해 둔 경우가 많아, 실제로는 외부 채널을 통해 유입되었음에도 direct로 집계되는 한계가 존재했습니다.

이에 저는 어디에서 유입되었는가가 아닌, 특정 시점을 기준으로 유입 패턴이 유의미하게 변화했는지를 중심으로 살펴보았습니다.

채널 식별보다는 시간 기반의 인과 추정과 잔류 효과에 초점을 둔 것이었는데요, 구체적인 분석 구조와 SQL을 통한 가설 검증 과정은 다음 글에서 자세히 정리하겠습니다.

12월 중반, 9학기의 기말고사가 끝남과 동시에 처음으로 인턴 준비를 시작해 한 달 간 수많은 이력서를 만들고 면접을 보며 치열하게 달렸습니다.

결국 인턴 합격 소식을 얻었지만, 그 과정에서 겪은 적지 않은 서류 탈락은 간간히 고민을 남겼습니다.

내 이력서는 왜 읽히지 않았을까?

합격 이후, 제가 고집했던 이전 이력서들을 냉철하게 복기하며 대대적인 수술을 진행했습니다. 저와 같은 고민을 하는 분들을 위해 7가지 회고 포인트를 공유합니다.

초기 준비생에게 도움이 되었으면 좋겠지만, 결코 답은 아니며 더 좋은 방향이 있다면 남겨주시어요!

결과물

Before

After

* 피그마로 제작하였습니다
* 기본으로 제공하는 프레임이 아닙니다
* 후킹 멘트나 발표자료 링크는 모자이크 처리해 두었습니다
* 서비스기획자 및 데이터 분석가 지원자입니다 
(Figma 사용 능력을 우대하는 경우도 많아 미적 감각이 어느정도 필요하다고 판단해, 더욱 디자인에 신경썼습니다)

1. 분량과 내용은 나를 딱 궁금해할 정도까지

토스에 재직 중인 친구가 제 이력서를 보더니 "포트폴리오 같다, 내용을 과감히 걷어내라"고 조언해 주었습니다. 하루 만에 6페이지의 방대한 분량을 2페이지로 압축했습니다.

점점 이 준비과정에 매몰되면 매몰될수록 양을 늘리고 불필요한 내용까지도 덧대어가며 내가 얼마나 대단한 사람인지를 증명하는 것이 목적이라고 오해하게 되는 것 같습니다.

지금 생각해보면 학교 동아리에서는 그런 과시가 먹힐 수도 있겠지만, 실제 일을 하는 입장에서는 '대단하다'라고 생각하기보다는 '과하다'고 생각할 수 있을 것 같습니다.

이 사람이 궁금해지고 면접에 왔으면 좋겠다고 생각들게 하는 것이 목표임을, 썸타는 것처럼 살짝! 자극하는 것이 목표임을 자각하면 좋았었을 것 같습니다.

2. '예민함'이라는 단어

'예민함을 성공 공식으로 풀어내는 PM, 이유정입니다'

예민함은 나름 '후킹'을 위해 사용했던 단어였지만, 그만큼 부정적인 인상을 줄 수 있습니다.

실제로 면접관 입장에서 특정 단어에 꽂히면 이후의 말들이 부정적으로 들렸던 제 경험을 떠올렸습니다. 닫힌 인상을 줄 수 있는 단어들을 걷어내고, 협업하기 좋은 긍정적인 언어로 교체했습니다.

💡 Tip! '형용사'하는 '명사형'같은 지원자, 000입니다

라고 표현하면, 같은 정도의 후킹으로 감정적이지 않게 들리는 것 같습니다. ex. 어떤 자리에도 어울리는 토트백 같은 지원자, 이유정입니다 굳이 예를 들자면 에이블리에 지원하는 이런 느낌 ...?

2.1. 나는 'PM'인가, '지원자'인가?

회고를 하며 가장 크게 깨달은 것 중 하나는, 신입/인턴의 위치에서 스스로를 특정 직무(PM, DA 등)로 과하게 정의하는 것이 오히려 독이 될 수 있다는 점이었습니다.

물론 프로젝트에서 PM 역할을 수행했겠지만, 회사 입장에서는 이제 막 시작하는 단계의 지원자가 본인의 역할을 확정 지어버리는 모습이 다소 경직되게 느껴질 수 있겠더라고요.

실제로 서비스 기획 면접에서 "기획이 무엇이라 생각하냐"는 질문을 받았을 때, 저는 "회사마다 정의가 다르기에 하나로 정의하기 조심스럽지만"을 붙였습니다. 그 답변을 내뱉는 순간 깨달았죠.

'아, 그렇다면 내 이력서에서도 나를 기획자로 규정하기보다, 유연하게 배우고 기여할 준비가 된 지원자로 표현하는 게 맞겠구나.'

이력서는 내 경험을 증명하는 곳이지, 성급하게 결론을 내리는 곳이 아니라는 점. 내 역할은 내가 정하는 것이 아니라, 현업에서 부딪히며 증명해 나가는 것이라는 유연한 태도를 이력서에 담으려 노력했습니다.

💡 이 포인트가 중요한 이유
- 메타인지
- 유연함: "저는 이런 경험을 했고, 귀사의 환경에 맞춰 기여할 준비가 됐습니다"라는 메시지를 줍니다.
- 현업의 시각: 실제 채용 담당자들은 '다 안다'고 생각하는 신입보다 '무엇이든 배울 준비가 된' 사람을 훨씬 선호합니다.

(업무가 비교적 확실한 개발자나 디자이너는 해당하지 않을 수 있습니다)

3. 미(美)보다 정보의 우선순위

레퍼런스를 참고하며 세로로 길게 나열된 구성을 선택했었는데, 공간 효율이 너무 떨어졌습니다. 디자인적 욕심 때문에 정작 중요한 내용보다 여백과 툴 부분이 차지하는 비중을 오히려 만들게 되었습니다.

내용을 먼저 확정하고 디자인을 맞추니 훨씬 밀도 높은 이력서가 되었습니다.

4. 학력 사항: 호기심만 자극할 것

"왜 이 전공을 선택했는지"에 대한 구구절절한 설명은 과감히 뺐습니다. 제 이력서의 주인공은 '경험'과 '프로젝트'여야 하니까요. 정말 궁금하다면 면접에서 물어볼 것이고, 그저 면접관의 호기심을 자극하는 정도면 충분합니다.

5. 자잘한 수상 내역의 과감한 생략

채우는 것에 급급해 학회 내부 대회 같은 작은 성과까지 다 넣었었습니다. 하지만 이제는 모수가 컸던 대회, 기여도가 높았던 것, 그리고 '면접에서 질문이 나왔을 때 자신 있게 답할 수 있는 상' 위주로 재배치했습니다.

6. 기술 스택: 깔끔한 배치가 핵심

텍스트가 너무 많아 보일까 봐 사용했던 칩 형태의 디자인이 오히려 가독성을 해치고 있었습니다. 의미 없는 디자인 요소를 걷어내고, 기술 스택을 훨씬 직관적이고 깔끔하게 한눈에 들어오도록 수정했습니다.

내용적으로도 너무 올드한 기술이나, 실무에서 사용하지 않을 것 같은 기술을 제외했습니다.

7. 프로젝트 설명: "3줄의 마법"

프로젝트의 상세 기능이나 소개는 포트폴리오나 URL(Github, 보고서)로 넘겼습니다. 이력서에는 핵심 성과 위주의 3줄 정도로 줄였습니다. 읽는 사람의 에너지를 아껴주는 것이 이력서의 예의라는 것을 배웠습니다.

💡 회고를 마치며

결국 좋은 이력서란 '내가 하고 싶은 말'이 아니라 '상대가 듣고 싶은 말'을 적는 것인 것 같습니다.

인턴 합격은 끝이 아니라 새로운 시작이기에, 다음 경험을 정리하고 성장을 담기 위해 계속 이력서를 업데이트할 것 같습니다.

1장 정리 끝.

아직 치이이즈..를 모른다구요? 그렇다면 치이이즈 구경하러 가기 ✌🏻

고새 큐시즘 인스타에도 올라왔죠 ㅎㅎ

🧀 근황토크

큐시즘 32기를 마무리하고 ! 마지막 학기도 마무리하고 (유예지만) ! 상황이 너무 많이 바뀌면서 개인적으로 마음이 싱숭생숭한 상태로 한동안은 굴러가는 것들만 붙잡고 ... 유지하는 상태로 지냈던 것 같습니다람쥐 ..,

그러다 이제 겨우 정신을 차리고 일들을 쳐내기 시작했는데 마주한 ..! 바로바로

정말 Raw 그대로의 유저 로그 데이터!

경외롭구나 ...

보자마자 뇌가 돌기 시작해서, SQL 쿼리 짜고 스케쥴링 하는 거에 심취해서 오늘 앉은 자리 4시간이 바싹 지나갔던 것 같아요.

서비스 기획 일 자체로도 너무! 가끔은 더욱! 즐겁게 하고 있었지만 애초에 기획을 시작했던 것은 데이터 분석가를 꿈꾸는 사람으로서 실 유저 행동 데이터를 받아보고, 의사결정하는 경험을 얻고 싶기 때문이었거든요.

🧀 유지보수 단계에 온 치이이즈

특히나 우리 팀 기획자랑 디자이너가 '왜 이래야 해?'라는 질문을 많이 하는 사람들이라 이때까지 무수한 '굳이 이렇게 해야 해?', '다른 방법은 없어?' 의 자체 검증을 거쳐왔기 때문에

지금 상태에서 무언가를 바꿔야 한다면 사용자가 이유여야 한다-고 생각했어요. ㅡ 마치 ... 흑백조커를 이길 수 있는 건 컬러조커밖에 없다...

그래서 12월 말부터 지금 1월 20일까지는 새로운 기능을 완전히 디벨롭하거나, 있던 플로우를 완전히 바꾸기보다도 사용자 데이터를 수집할 수 있는 환경 세팅을 위주로 했어요 ! 😎 다들 고생해 준 덕에 이렇게 환경도 세팅이 된 것 같습니다

큐시즘 밋업을 떠나 사이드 프로젝트를 시작하며 정리한 목표(~2/25) 중 일부

크게 1. 큐시즘 멘토링 이후 받았던 피드백에 대한 수정, 2. 로그 수집 환경세팅, 3. 프로모션 위주의 한 달을 보냈어요. 나중에 JIRA 어떻게 사용하고 있는지도 글 써서 남길게요 ㅎㅎ

🧀 이벤트 로그 추적하기

백엔드 쪽에서는 이미 매일매일 로그가 생성되었고 앨범 생성이나 사진 업로드, 다운로드 같은 주요 액션들이 서버 로그로 남아 S3에 적재된 뒤 BigQuery로 바로 확인할 수 있는 상태입니다.

백엔드에 수집을 요청한 이벤트 로그들 종류

프론트 쪽도 마찬가지로 Google Tag Manager를 통해 이벤트를 보내고 있었고, GA4를 거쳐 BigQuery로 export 되는 구조는 이미 만들어져 있었어요.

다만 실제로 바로 분석을 하고, 보기에 좋은 상태는 아니었어요 프론트 이벤트는 GA4 특성상 하루 단위로 테이블이 나뉘어 쌓이고 있었고, 백엔드 로그는 또 다른 테이블에 있었기에 테이블을 조인하고 붙이기에 번거로웠어요.

이 상태로 계속 가면 분석을 할 때마다 준비 작업부터 반복하게 될 것 같아서, 분석용으로 바로 볼 수 있는 테이블을 하나 따로 만들어두는 게 낫겠다고 판단했었어요. 원본 데이터는 그대로 두고, 프론트 로그를 정리해서 이벤트 단위로 한 줄씩 볼 수 있는 staging 테이블을 만드는 방식을 참조했어요.

CREATE OR REPLACE TABLE `saycheese-484314.analytics_517953491.staging_events_base` AS
SELECT
  PARSE_DATE('%Y%m%d', event_date) AS event_date,
  TIMESTAMP_MICROS(event_timestamp) AS event_ts,
  event_name,

  user_id,
  user_pseudo_id,
  COALESCE(user_id, user_pseudo_id) AS unified_user_key,

  -- session
  (SELECT value.int_value
   FROM UNNEST(event_params)
   WHERE key = 'ga_session_id') AS ga_session_id,

  (SELECT value.int_value
   FROM UNNEST(event_params)
   WHERE key = 'ga_session_number') AS ga_session_number,

  -- page / custom
  (SELECT value.string_value
   FROM UNNEST(event_params)
   WHERE key = 'page_location') AS page_location,

  (SELECT value.string_value
   FROM UNNEST(event_params)
   WHERE key = 'entry_source') AS entry_source,

  -- device / geo
  device.category AS device_category,
  device.operating_system AS operating_system,
  geo.region AS region

FROM `saycheese-484314.analytics_517953491.events_*`
WHERE event_name IN (
  'view_landing',
  'view_login',
  'click_login',
  'complete_login',
  'complete_album_joined'
);

그럼 이제 테이블명을 바꾸지 않고도 같은 쿼리를 계속해서 써서 분석하기 편한 환경이 되겠죠!

이 과정에서 COALESCE를 썼어요 로그인을 하기 전과 후를 기준으로 로그인 전의 유저들은 pseudo_id를 받고, 로그인을 한 뒤에는 user_id가 생기거든요. (로그인을 하지 않고 이탈한 유저들은 pseudo_id만 있고, user_id가 null이에요.)

user_id, user_key, user_pseudo_id 같은 값들을 하나의 대표 컬럼으로 묶어줬고, 이벤트 이름도 마찬가지로 하나로 정리했었어요. 이렇게 해두니까 이벤트가 어디서 들어왔는지를 크게 신경 쓰지 않아도 바로 쿼리를 시작할 수 있었어요.

🧀 데이터 분석의 시작은 '무엇을 볼지 정하는 것'

애초에 이벤트 수집을 요청한 게 기획자였기에 깔끔하게 시작할 수 있었지만 데이터 풀이 확정된 상황에서도 가장 먼저 해야하는 질문은 '그래서 무엇을 보고 싶은가?'예요.

1. Metadata로 수집된 피쳐를 확인한다 (너무 발산하지 않도록 Anchoring)
2. 확인하고 싶은 문제에 대한 가설을 만든다
3. 가설을 피쳐를 이용해서 표현한다

의 과정이랄까요. 다다익선이 아니거든요.

GA4 raw 테이블에는 생각보다 컬럼이 정말 많았는데, 지금 단계에서 바로 쓰지 않을 정보들은 staging 테이블에서는 아예 제외했었어요. 어차피 확인하고자 했던 가설은 명확했어서, 골라내는 것도 쉬웠던 것 같습니다 (thx to 민서 ..)

🧀 최종 데이터의 모습!

언제 발생했는지, 누가 어떤 행동을 했는지, 어떤 앨범이나 사진과 관련된 이벤트인지 정도만 남기고 나머지는 과감하게 덜어냈어요. 원본은 그대로 남아 있으니까, 나중에 필요해지면 다시 원본을 참조하면 됩니다.

즉, 이때까지 한 걸 정리하자면

1. 이벤트 테이블을 UNION한다 (아래로 길게 늘여 붙인다)
2. 원하는 피쳐를 선택하고 정제한다 인거죠.

마지막으로 이 정리 과정을 BigQuery의 Scheduled Query로 설정해서 매일 자동으로 돌아가게 만들어두었어요.

이제는 프론트로부터 새 로그가 자정에 들어오면, 새벽 2시에 같은 테이블로 UPDATE가 그때그때 되기 때문에 테이블을 변경할 필요 없이, 같은 쿼리를 통해 매일의 결과를 낼 수 있답니다 :)

다음 글에서는 이 테이블을 기준으로 실제로 퍼널을 어떻게 짜봤는지, 어떤 질문들을 던질 수 있었는지 정리해보려고 해요. 그럼 빠빠이 ~~

저희가 이번 KUSITMS 32기 밋업 프로젝트로 준비한 치이이즈는 모임 이후 사진이 흩어지고 방치되는 경험에서 출발한 서비스입니다. 대부분의 사진 공유는 촬영 직후에 이루어져 시간이 지나면 원본은 다시 찾아보지 않는 경우가 많다고 느꼈습니다. 계속 남는다는 사실은 사진을 올리는 것도 민망하게 만들고요.

이에 치이이즈는 앨범 접근 기간을 7일로 제한하고, 그 안에서 사진을 업로드하고 반응하며, 최종적으로 의미 있는 사진 4장만 남기는 ‘치즈네컷’ 경험을 제공하는 구조로 기획되었습니다.

본 프로젝트는 KUSITMS 32기 밋업 프로젝트 활동으로 시작되었으며, 현재는 활동 종료 이후에도 1.0 사이클 운영 단계로 실제 사용자를 대상으로 서비스를 운영하고 있습니다. 서비스 운영을 위해 서버, DB, 스토리지 환경은 Naver Cloud Platform 기반으로 구축하여 사용 중입니다.

• 서비스 URL: https://say-cheese.me
• Frontend Repository: https://github.com/Say-Cheeeese/FE
• Backend Repository: https://github.com/Say-Cheeeese/BE

Q2. Ncloud에서 어떤 서비스를 활용하셨나요?

Cheeeese 프로젝트에서는 다음과 같은 Naver Cloud Platform 서비스를 활용하고 있습니다.

• Server (Compute)
• VPC / Subnet
• Object Storage
• Cloud DB for MySQL
• Redis (Cache)
• Docker 기반 배포 환경
• GitHub Actions 연계 CI/CD 구성

또한 다음 사이클에서는 (~2/25) CLOVA Studio의 이미지 분석 기능을 치즈네컷 섹션에서 활용할 계획을 염두에 두고 기획을 진행 중에 있습니다.

Q3. Ncloud 서비스를 어떻게 적용하였나요?

백엔드 서버는 Spring Boot 기반 애플리케이션을 Docker 컨테이너로 구성하여 배포하였고, GitHub Actions를 통해 코드 푸시 시 자동 빌드·배포가 이루어지도록 CI/CD 파이프라인을 구성했습니다. 이를 통해 개발 환경과 운영 환경의 차이를 줄이고 안정적인 배포 흐름을 유지하고 있습니다.

사진 업로드는 Presigned URL 방식을 사용해 대용량 파일 업로드 시 서버 부하를 최소화하고, 사용자가 Object Storage에 직접 업로드하도록 설계했습니다. 앨범, 사진, 사용자 정보 등 핵심 메타데이터는 Cloud DB for MySQL에서 관리하며, 빈번하게 조회되는 데이터는 Redis 캐시를 활용해 응답 성능을 개선하고 있습니다.

Q4. Ncloud 사용 중 특히 만족했던 점과, 아쉬웠던 점은 무엇인가요?

만족했던 점은 국내 환경에 최적화된 안정적인 인프라와 낮은 레이턴시입니다. 학생 프로젝트임에도 실제 서비스 운영을 전제로 한 서버·DB·스토리지 구성을 경험할 수 있었고, 비용 부담 없이 인프라 구조를 실험하고 개선할 수 있었습니다.

또한 어렵지 않게 로그 대시보드 또한 구현할 수 있었습니다.

아쉬웠던 점은 초기에 서비스 종류가 많아 각 서비스의 역할과 선택 기준을 이해하는 데 시간이 필요했다는 점입니다. 다만 공식 문서와 가이드맵을 참고하며 점차 구조를 이해할 수 있었고, 이 과정 자체가 클라우드 인프라에 대한 이해를 높이는 데 도움이 되었습니다.

Q5. Green Developers 프로그램 참여 소감 말씀 부탁 드립니다.

Green Developers 프로그램을 통해 단순한 기능 구현이 아닌 실제 서비스 운영 관점에서의 개발 경험을 할 수 있었습니다. 특히 Ncloud 크레딧 지원 덕분에 인프라 비용에 대한 부담 없이 서비스 구조와 확장 가능성을 충분히 고민할 수 있었습니다.

치이이즈는 현재 기본적인 서비스 구조를 안정화하는 단계에 있으며, 다음 사이클에서는 AI 기능을 제한적으로 도입해 사용자 경험의 밀도를 높이는 방향을 고민하고 있습니다.

특히 모든 사진에 AI를 적용하기보다는, 최종 결과물인 ‘치즈네컷’ 4장에만 CLOVA 이미지 분석을 적용하여 사진의 분위기나 순간을 설명하는 텍스트를 제공하는 방식을 실험해보고자 합니다.

이를 통해 사용자가 7일이 지난 이후에도 앨범을 다시 떠올리고 서비스를 재방문할 수 있는 계기를 만드는 것이 목표입니다.

저번주 토요일! 5월 31일 너무너무 고대하고 고대하던 밋업 발표와 전시회를 모두 끝내고 후련한 마음으로 일상을 보내다, 이 기억이 잊히기 전에 얼른 다시 왔어요 ( ˙ ‧̮ ˙ )

ㄴ 너무너무 수고한 우리 ... +현지 정민

다들 건강 갈아가며 새벽까지 열심히 작업했는데. 내일이 되면 드디어 건강한 유림이 언니를 볼 수 있겠죠?

ㄴ 새벽 5시, QA 중 갑자기 펼쳐진 인형 자랑 쇼 ㅋㅋ

발표, 어땠나요?

일단 먼저 발표에 대해 회고하겠어요! 제가 발표 순서가 6번째로, 조금 후반대였어서 정신이 조금 가 있던 나머지 다른 조의 발표에 엄청 귀를 기울이지 못해서 아쉬웠어요.

그래도 다들 멋지게 발표해주신 덕에 흐름을 놓치지 않았어요 ´︶`)ﾉ"

사회문제인지, 우리처럼 엔터테인계인지 등등 타겟에 따라 그리고 문제배경에 따라 발표 흐름도 강조하고자 하는 부분도 달라 신기했습니다.

스케치는 아래 유튜브에 열심히 편집되어 올려주셨더라구요 요기 눌러보면 영상이 나옵니다

저희의 경우에는 레터링케이크 관련이기에 듣는 청중 분들이 이 문제에 공감하기까지의 시간이 오래 걸리거나 납득이 절대적으로 어려울거라고 생각되지는 않았어요. 장벽이 낮다는 것, 그게 장점이었다면 장점일텐데요.

그런데 누구나 경험해보고, 문제를 인식하고, 액티브한 분들의 경우에는 해결 방안까지 생각하시기 쉽기 때문에 이 문제 도출 과정이 절대 얕지 않았다는 걸 (실제로) 드러내는 게 중요했고, 따라서 의외인 점에 강조를 둬야 겠다고 판단했어요.

특히나 디자인에 대해 고민하는 시간이 길지만, 그 긴 시간 자체가 불편함으로 작용하고 있지 않다는 것이 저희의 포인트였죠.

감사하게도 발표 끝내자마자 너무 좋은 반응을 해 주셔서 조금 시간이 타이트했다는 게 아쉬웠지만 후회는 없습니댜

고마워 디어케이 > <_

고마워 코바쾨 > _ <

핵심 내용이 들어간 비핸스는 아래 링크로 접속이 가능합니다 behance

전시회는 어땠나요?

원래는 밋업 발표를 끝내고, 전시회까지 한 주의 시간이 더 주어진다는데 겹쳐서 PT 준비부터 전시 준비까지 바빴을텐데도 너무 야물딱지게 준비해준 정민과 수아 덕에

우리가 제일 예쁜 명찰 메고, 제곧내 케이크 보여주면서 아기자기한 부스 활동 했어용 히히 다들 왜케 설명을 잘 하는거야 ~~ ♪٩(٩ •'ᵕ'• ) "✧♪( •'ᵕ'•و(و "✧

그리고 내 친구와 친구의 친구분~ 와주셔서 너무 감사해용 시간 부족할 정도로 다른 부스도 재밌었다던데 재밌게 해 줘서 다행이댯 히히히

끝나고 완전 맛있는 숯불고기와 케이크 먹음요.

아니 여기 아이스크림도 레전드 .. 배불러서 안 먹으려 했는데 진짜 인생 두고두고 후회할 뻔 ?!

사랑하는 오케잌으로 마무리 다들 지금 일하고 싶어 미치는 것 같은데...... 나 기말만 잘 마무리하고 돌아올게 🥰

벨로그는 정말 정말 오랜만이에요!

부트캠프 때 이래로 처음 게시글을 올리게 되었는데, 그 간격이 1년이 훌쩍 지나버렸다는 것이 놀랍기만 합니다 이제 4개월만 지나면 2년 전이 되어 버리네요.

며칠 전에 서초, 교대 일대를 돌아다녔었는데 그맘때가 생각나더군요 과거를 잘 떠올리는 성격은 아닌데, 작년, 딱 추워지던 타이밍에서 한 번 생각이 났고, 가끔 혼자 밥을 먹고 산책을 오던 서초 뒷골목이 보이고 서이초 쪽이 보이면 그 곳 생각이 나더랍니다.

그때 진지하지 않았고, 철이 없었고, 무모했던 덕인지 어려움과 막막함이 아니라 재미를 봤던 개발과 데이터 분석으로 1년 반이 넘게 지난 지금까지 진로가 바뀐 적은 없던 것 같아요 정말 좋은 시기였고, 그렇게 적합했던 타이밍이 없었다는 생각이 듭니다.

그럼에도 변화는 있다

데이터 분석을 생각하던 저는 최근, 서비스 기획에 대해 알아가고 있어요. 1년동안 열심히 분석을 하면서도 그 결과가 보통 서비스의 제언이나 알고리즘의 개선 제안으로 이어지기 때문에, 크고 작은 서비스 개발 대회에 나가 좋은 경험을 하면서 재미를 얻었었습니다.

개발을 하면서도, 우리에게는 코드가 제대로 굴러가게 만드는 것, 그리고 더욱 좋은 기술을 사용하는 것이 더욱 중요했기 때문에 항상 '이 서비스가 정말 생기고 좋다고 해서 사람들이 사용할까?'라고 하는 본질적인 질문은 간과하고 살았던 것 같습니다. '아냐, 일단 우선 구현하고 보자'라는 마인드였죠. 그러나 서비스를 사랑하고, 더욱 열정적으로 만들기 위해서는 이에 대한 확신과 근거가 있어야 한다는, 그런 선순환 관계를 알게 된 것이 지난 겨울이었습니다.

탄탄한 기획이 하고 싶어졌어요

이 서비스를 정말로 사용할까?라는 물음은 서비스가 시장에 나오기 전까지 모르는 것이라고 생각했어요. 무작정 피그마를 하게 되고 싶다!는 생각에 친구들과 같이 나간 대회에서 피그마라는 툴도 배우고, 시장 조사의 메소드를 짧은 시간동안 익히며 이 서비스 기획을 정말 진지하게 하고 싶어졌고 큐시즘에 지원해 (사실 원래부터 하고 싶기는 했어요) 너무 좋게 봐 주신 덕에 붙어, 열심히 하고 있답니다

기업 프로젝트와 나

그리고 큐시즘 활동의 시작! 심신미약 이슈로 인해 많이 부족한 면접이었어서 집에 와서도 회고하며 아쉬움만 가득했었는데, 함께하게 되어 너무 행복했답니다.

처음 들어와서 시작한 기업프로젝트. 너무 좋은 PM과 팀, 익숙했던 NLP 그리고 하이퍼클로바X를 기반으로 말로 형용할 수 없게 많은 것을 배우고, 많이 성장하지 않았나 싶습니다.

좋은 본보기와 함께였지만, 그때의 나는 너무 부족하고 나에 대한 자신이 없었기에 미안함밖에 없었던 코바쾨 그럼에도 불구하고 뭐라고 그립답니다

ㄴ 현수쨩 장발파 손들어 ...

PM분이 알던 갓생 광고홍보학과 학생분들과 UT도 진행하고, 자주자주 만나서 얘기하고. 너무 뛰어난 디자이너들의 가이드 덕에 UX writing 통일과 직관성의 중요성, 그리고 제가 너무 좋아하게 된 단어인 '위계'까지 알게 된 너무 소중한 시간이었던 것 같습니다. 정말 오래 알았으면 좋겠어요 🩷

서비스와 PM

기업프로젝트를 진행하면서 팔로워의 입장에서 '어떤 리더가 좋은 리더인가?'에 대한 물음을 스스로 끊임없이 하던 저였답니다.

기획에 대해서 공부하는 것에서 나아가 "개발자와 디자이너와의 소통을 주도한다는 것은 어떨까?" "그리고 전체 프로젝트의 일정 조율을 어떻게 하면 현명하게 할 수 있을까?" PM이 되어 진지하게 고민하고 싶었어요. 저는 자리가 사람을 만든다고 생각하거든요.

하고 싶은 서비스가 물론 있던 상태였지만, 무엇보다도 PM의 자리가 너무 궁금했던 욕심쟁이인 저였기에 매일 열심히 발제했고, 제 서비스에 대해 매력적으로 느껴주신 분들 덕분에 디어케이 서비스를 발제하며 PM이 되었습니다. 그리고 오케잌 팀을 꾸리게 되었지요 ...

우리 오-케잌 팀 ... 말을 하기에 너무 입이 아픕니다.

PM으로서 처음 맞이한 팀이고, 리더십이 대단한 많은 언니 친구 동생들로 구성되어 내가 이 사람들을 이끄는 것이 맞는 것인가- 라는 생각에 많이 걱정되고, 가끔은 울고 싶던 날도 있었어요. (가끔은 욺)

어떤 직책에 대해서 이렇게 강한 책임감을 가지고, (긍정적인) 부담을 가지고, 배우려고 노력한 적은 없었던 것 같아요.

ㄴ 처음 회의를 준비하던 나와 아현 첫 만남은 너무 어려워!

처음에는 '다들 이 서비스를 준비함에 있어 너무 부담갖지 않았으면, 눈치보지 않았으면 좋겠다!', '내가 부탁하고, 시키는 것이 아니라 하고 싶어서 하는 좋은 팀을 만들었으면 좋겠다!' 하는 생각에, 어떻게 하면 '부담을 주지 않을까'에 핀트를 꽂았던 것 같아요.

그런데 이미 열심히 하고자 하는 팀원들을 만나 보다 고차원적인 고민을 할 수 있었고, 내가 열심히, 꾸준히 소통하고, 더욱 사랑하는 것이 유일한 답이겠구나- 알게 되었던 것 같습니다.

사기를 북돋는 법을 고민했는데, 모두가 이미 사기로웠기에 저만 잘하고, 노력하는 모습을 보여주고, 믿는 것 그것 뿐이 할 게 없어 거저먹고 있습니다.

학교 프로젝트와 PM 고민

최근에는 학교 프로젝트에서 AI와 프론트 개발을 조금씩 하고 있습니다. 되게 길게 하는 거기도 하고, 뎁스가 깊은 서비스가 아니기에 심심할 때마다 조금씩 1일 1커밋을 목표로 하고 있는데요.

그곳에서도 제가 큐시즘에서 냈던 아이디어 중 하나로 발제를 했지만(스파크업 짱입니다), PM을 나서서 하지는 않았었어요. 팔로워의 입장도 되어, 어떤 생각이 드는지 고민하고 싶었거든요.

친절하고 경험이 있는 PM 아래에서 개발자의 포지션에 있으며 "나의 편의를 봐주는 것도 고맙지만 데드라인 일정을 정해주는 것이 오히려 편하구나-" 하는 생각이 들었습니다.

그 외에도 개발자와의 소통에서의 팁과 일정 잡기, 그리고 팀 일정 관리 방법을 두루 배우고 있습니다.

그래서 5월 중반인 지금

1. AS 기획자

전체 그림을 보게 되고, 기획자로서는 ‘내가 어떤 이유로 이 대안을 주장했었는지'를 적극적으로 이야기할 수 있고, 다른 팀원들의 이야기를 한발짝 떨어져서 생각하고 받아들일 수 있는 여유가 생긴 것이 스스로의 발전이 너무 마음에 드는 요즘입니다.

그리고 'UI/UX를 고려한다면 어떤 대안이 좋은지'를 볼 수 있는 눈이 생긴 것 같아(!) (어제 디자인 파트에게 한 마디만으로 인정받아 혼자 조용히 너무 기뻤어요) 너무너무 자기효능감이 생기고, 사랑할 자유가 생긴 지금입니다. (조금만 늦었으면 탈모 올 뻔 했어요!)

와이어프레임도 뚝딱뚝딱 만들고, 어플을 볼 때도 그런 인지적 스키마 하에서 생각하다보니 어떤 UI에 대한 레퍼런스도 금방금방 생각나는 게 참 좋은 것 같아요.!

ㄴ 이때 나는 정리란 걸 모르는 사람이었을까 ...

2. AS 사람(?) 계획적인 사람이 되기에는 조금 시간이 더 들 것 같은데, 수시로 확인하고, 어떤 것이 필요할지 미리미리 생각해 준비하는 꾸준한 사람은 된 것 같아 좋습니다.

특히나 기획자는 제일 초석-이기에,

1) 빨리 진행해야 할 것에 우선순위를 정하고 2) 체계적으로 수행해서 전달해야 하는 입장에 있습니다. 그것의 판단 스키마가 만들어져, '쳐낼 건 쳐내고' 집중해야 할 것에 집중해서 완수한 밀도 있는 경험이 쌓이고 있습니다.

그리고, 소통하는 사람이 된 것 같아요! 저는 원래 혼자하는 것이 편한 사람이었어요. 그냥 그런 사람이다-라고 생각했는데, 이제 생각해보면 '남에게 설명하는 것이 어려워서, 내가 해서 결과를 보여주는 것이 편한 사람' 이었던 것 같어요.

그러나 기획은 혼자 하는 것보다 무조건 둘이 좋거든요! 다른 눈으로 바라봐 서로를 보완하고, 같은 생각이면 안정감을 얻고 더 큰 그림을 그릴 수 있거든요.

ㄴ 아현이랑 데이트 간 고양이 카페 고앵이 ..

그래서 우리 같은 파트인 아현이랑 대화를 자주 많이 하며 내 생각을 조리있게, 무겁지 않고, 어렵지 않게 잘 전달하는 법을 조금씩 체득하는 중인 것 같아요. 그 과정을 함께 해준 아현이에게 항상 감사합니다 ❤️

** 3. AS 리더 ** 저는 정말 아직은 부족하지만, 그래도 아주 눈곱만큼 좋아진 것 같아요. 늘었다기보다는, 여유가 생겨 조금 말랑해진 느낌 ...

'리더가 해야하는 것과 기획자가 해야하는 것이 다르다', 그리고 '리더는 소통을 잘하고, 일정 잘 짜고, 조율을 하는 것이 제일 중요하다!' 천성이 대변하지 못하는, 후천적으로 발달시킬 수 있는 부분이 많음을 알게 되어 노력할 수 있는 부분을 노력하려 하고 있습니다.

결론적으로, 큐시즘이 사람 하나 만들었죠 !

앞으로 밋업을 2주 앞두고 있어요. 이 2주 동안, 포기하지 않고, 집중할 수 있도록 노력하겠습니다 우리 오케잌 ... 항상 감사하고, 우리 소중한 만남 오래오래 이어가요 ‼️ 제가 잘할게요 ✉️

🎆 팀 README https://github.com/PlaydataFinal/Final_project/blob/main/README.md 저는 팀에서 파생변수 생성과 함께 모델링을 맡아 진행하고 있고, OCR 모델 구성, 추천모델 파생변수 생성을 위한 모델, 챗봇 모델을 만들고 있습니다.

준비하며 적었던 개인 메모와 회고록을 공유합니다.

일별 메모

🎈 2/14

1. FINAL PROJECT

• 챗봇 GEMINI 파인튜~닝
• EDA

2. 재무회계에서 머신러닝 / 딥러닝 사용 공부
3. AWS 공부

Alpaca나 gpt 다양한 챗봇 api에 접근을 해 봤는데 역량 문제인지 ... 일단 alpaca는 기본적으로, 주지 않은 정보에 대해서 알고 있지 않았었고 gpt는 과금이었기 때문에 ^^ 구글의 Gemini를 사용해보기로 했는데요.

저희가 이용할 챗봇은 제주도 관광지에 대한 네이버(타사) 정보들을 알고 있어야 했기 때문에, 파인튜닝이 꼭 필요한 상황이었습니다.

완전 공짜는 아니지만, 저는 상윤님의 api key를 사용했기 때문에 질문을 막 했답니다. 사실 어느 수준까지는 공짜랩니다.

코드 리뷰를 잠깐 해보겠습니다.

#설치 %pip install -U --quiet langchain-google-genai

#임포트 from langchain_google_genai import ChatGoogleGenerativeAI

#인스턴스화 llm = ChatGoogleGenerativeAI(model="gemini-pro")

result = llm.invoke("헬로키티아일랜드의 장소가 어디야?") Markdown(result.content)

질문을 해 봤는데요.

넹? 아주 멀쩡히. 운영중인 헬로키티 아일랜드를 없애다닛.

(참고: 강남역은 2호선과 신분당선이 지나갑니다.)

이렇게 AI가 아는 것처럼 이야기하는 것을 '환각현상'이라고 하죠. https://www.donga.com/news/Opinion/article/all/20230319/118420844/1

그래서 예전 경진대회에서 챗봇을 학습시킬 때에도, 엄격한 프롬프팅을 진행해서 경고를 해 줬답니다. 강의 내용에 없는 건 없다고 햇! 이렇게.

프롬프팅에 관해서는 내일 알아보겠습니다. 프롬프팅 전에, 저희가 가진 정보들로 학습을 시켜야겠죠. 우선 우리가 가진 파일은 csv 파일입니다.

그리고 가장 처음, GEMINI 사용 방법 예제 코드는 pdf 로드였어요. 우선, 인풋 데이터들을 pdf 형식으로 변경하기보다 코드 자체를 txt를 로드하도록 바꾸는 게 나을 것 같아 텍스트를 로드할 수 있는 형태로 변경했습니다.

또 csv를 그대로 학습시키자니, 로우와 컬럼의 관계를 (당연히) 이해하지 못하기에, csv 파일을 전처리 과정으로 txt 파일로 변환했습니다.

from langchain.vectorstores import Chroma from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain.embeddings import HuggingFaceEmbeddings

#파일에서 텍스트 읽기 file_path = "/content/drive/MyDrive/placetest.txt" # 파일 경로를 적절히 수정하세요. with open(file_path, "r", encoding="utf-8") as file: text_data = file.read()

#텍스트를 적절한 크기로 분리 text_splitter = RecursiveCharacterTextSplitter(chunk_size=500, chunk_overlap=50) texts = text_splitter.split_text(text_data)

#HuggingFace의 S-BERT 모델을 사용하여 임베딩 생성 model_name = "jhgan/ko-sbert-nli" model_kwargs = {'device': 'cpu'} encode_kwargs = {'normalize_embeddings': True} hf = HuggingFaceEmbeddings( model_name=model_name, model_kwargs=model_kwargs, encode_kwargs=encode_kwargs )

#문서 객체 생성 (딕셔너리 형태) documents = [{"text": text, "metadata": {"page_number": i + 1}} for i, text in enumerate(texts)]

#Chroma 인덱스 생성 docsearch = Chroma.from_texts([doc["text"] for doc in documents], hf)

loader = PyPDFLoader("/content/drive/MyDrive/outputfile.pdf") pages = loader.load_and_split()

text_splitter = RecursiveCharacterTextSplitter(chunk_size=500, chunk_overlap=50) texts = text_splitter.split_documents(pages)

from langchain.embeddings import HuggingFaceEmbeddings

model_name = "jhgan/ko-sbert-nli" model_kwargs = {'device': 'cpu'} encode_kwargs = {'normalize_embeddings': True} hf = HuggingFaceEmbeddings( model_name=model_name, model_kwargs=model_kwargs, encode_kwargs=encode_kwargs )

docsearch = Chroma.from_documents(texts, hf) from langchain.prompts import ChatPromptTemplate from langchain.schema.runnable import RunnableMap

template = """Answer the question as based only on the following context: {context}

Question: {question} """

prompt = ChatPromptTemplate.from_template(template) gemini = ChatGoogleGenerativeAI(model="gemini-pro", temperature = 0)

chain = RunnableMap({ "context": lambda x: retriever.get_relevant_documents(x['question']), "question": lambda x: x['question'] }) | prompt | gemini

Markdown(chain.invoke({'question': "제주별빛누리공원이 무슨 분류야?"}).content)

와! 대답이 잘 나왔네요. 아까는 폐쇄되었다더니 크크

추가했던 sector 정보도 잘 나옵니다.

지금 기입한 정보는 관광지명, 분류, PLACE ID, 링크, 마트 정보, 주소 뿐이지만, 우선 리뷰에서 뽑아낸 인덱스 단어들을 추가하고 나중에 시간이 남고 성능이 괜찮으면 네이버 리뷰 정보 전체를 다 추가해보는 것으로 합시다.

그런데 문제가 있다면... 다른 테이블들에는 place_ids만 있고, 가게명은 없어요. 그럼 가게명이 있는 테이블과 조인을 해야 할 것 같은데, 생각보다 조인이 많이 일어나고 있어서 이럴거면 왜 테이블을 분리해놨지 싶기도 합니다. ERD를 다시 한 번 짜봐야 할 것 같습니다.

2. 인덱스!

회원가입을 했을 때 저희는 MBTI처럼 마음에 더 드는 쪽을 선택하는 간단한 테스트로 유저 취향을 파악할 예정인데요. 어떻게 분류를 나눌까 싶어서 자주 들어가는 인덱스 단어들과 섹터들을 확인해보려 했습니다.

워드클라우드를 그려보니!

아니 재밌어가 왜 명사냐고 ㅋㅋ 저는 OKT의 함수인 NOUNS (OKT는 형태소 분류 기능 포함)를 이용해 분명 명사만 추출했거든요? 그런데 저 밌 애들은 무엇인가. 형태소분석기의 문제인가싶어 MECAB과 HANNANUM을 다 사용해봤는데 결과는 다 비슷했고, 더 심했으면 심했습니다.

그래서 자세히 살펴보니까, 오히려 작은 글자들, 그리고 '밌' 빼고는 다 괜찮더라구요. 아이스크림, 해변, 경험, 금연, 마을, 돌고래, 걷기, 관람, 작품, 자전거, 강아지, 모래, 쇠소깍, 해안, 아기 ... 저희가 딱 원했던 단어들이었습니다.

그래서 자세히 들여다봤죠.

제일 위, 즉 오래되고 리뷰가 많은 데이터들은 아주 명사들이 잘 출력이 된 반면에 최근에 올라오고 리뷰가 적은 관광지들은 아주 형편이 없더군요. 코드를 '꼭 10개!'라고 정해뒀더니, 어쩔 수 없이 나온 것 같습니다.

리뷰가 N개 이하면 탈락-이라고 하기 보다는, 가중치에 제한을 두는 게 나을 것 같습니다. 내일은 이렇게 어떤 제한을 걸어두는 코드를 짜 보겠습니다.

Finance & Statistics 전공으로 ph.D를 가고 싶어서 3학년 2학기부터는 준비를 해 보려고 합니당 마침 진로 관련으로 써 낼 게 있어서 적어봤죵 ...

아직 안 해 봐서 말은 거창함.

2/15 모델팀 우리의 목표 !!

*1. 전처리: *

1) 한 테이블 내 칼럼명 통일 (place_ids Place ID 등) 2) Sector 분류 nunique해서 묶을 수 있는 거 묶기 (하드코딩) 3) 테이블 조인

2. 버스 노선 학습

• 질문 받을 만한 거 (비짓제주 참고) 생각하기

• 텍스트 파일로 바꾸기

• 길찾기 API

3. 시간 남으면 컬럼 추가

4. 추천 모델 구상

나는 오늘 전처리를 위해서 ! 우선 과자를 좀 먹었다.

어제 생각했던 건, 지금 불필요하게 나뉜 테이블이 많은 것 같아서 테이블을 나눠 둔 건 빠른 검색을 위해서였는데 조인을 하느라 더 오랜 시간과 불필요한 코드가 생긴다는 거였다. 그리고 일대다 관계가 아니면 정리하고자, 일단 우리가 가진 테이블들과 컬럼들을 쭉 써 보았다.

우리는 place, food, sleep (단순한 이름 ㅈㅅ...) 즉 관광지, 숙소, 식당을 분류해서 띄우는 것을 목표로 한다.

데이터소스는 visitjeju와 네이버 사이트였는데, 네이버사이트에서 긁어온 데이터 테이블, 리뷰와 이미지, 키워드, 평점은 모두 place_ids라는 primary key로 묶일 수 있는 것과 다르게 tour_food, tour_sleep, tour_place는 place_ids 값을 가지고 있지 않았기에 어떻게 통일할지 걱정이 되었다.

visitjeju 것들을 사용하지 않을 수도 있었지만, 관광공사가 더 많은 관광지들을 보유하고 있었고 (네이버에 비해서 약 3천여개 더 많다) 다른 소스에서 가져온 데이터를 조인하는 경험도 필요할 것 같아서, 포기말고 방법을 생각했다.

EDA로 데이터들을 비교해봤다. 우선 tour_place라는, 가게명을 기준으로 본 결과 예상 외로 겹치지 않는 것이 많았다. 자세히 뜯어 확인해보니,

동일한 가게가 다른 이름으로 들어있는 경우가 있었다. 여기서 하드코딩을 사용하는 건 좀 아닌 것 같고, 중복되지 않아 primary key로 쓸 수 있으면서 두 개 테이블에 모두 들어있는 칼럼을 확인했다.

겹치는 게 없었다. 그래서 tour_place를 가져온 소스 페이지를 가 봤는데,

크롤링팀에서 가져온 데이터들은 상세정보 클릭 전이고, 클릭해서 들어가봤을 때

쓸 수 있는 데이터들이 훨씬 더 많았다.

그럼 크롤링 코드를 다시 짜서, 연락처(근데 visitjeju에는 (+82)가 붙어있어서 그걸 제거하고 써야겠지)나 주소를 primary key로 써서, 같은 것들을 묶어줘야겠다고 생각했다. 그런데 연락처가 없는 경우(길거리 등)면 어떡하지. ... 그런 생각은 드는 군. 결측치를 생각해봐야지 뭐. 일단 이름에 대해서 join을 한 다음에, 남은 것 중에 전화번호로 join을 하고, 그 다음 주소로 join을 하고 ... 하는 것은 어떨까.

일단 데이터를 가져와보자!

크롤링 코드로 대표사진과 이름, 태그, 설명, 기본정보 중 주소, 연락처, 찜하기, 좋아요, 리뷰, 상세정보, 이용 시간, 요금 정보, 장소 특성, 주요 목적, 주요목적 기타, 평균 소요 시간, 경사도(난이도)에 해당하는 데이터들을 모두 가져와야겠다.

크롤링을 하면서 느낀 점은, 안 쓰면 나중에 드랍하면 되니까 일단 긁어올 수 있는 건 모두 긁어오자는 것이다.

그런데 이 페이지는 정적 페이지가 아니라, '이용안내'를 눌러야 나타나는 동적 페이지이기 때문에 Selenium 라이브러리를 써야 할 것 같다.

크롤링을 해 보자!

[코드리뷰]

from selenium import webdriver from selenium.webdriver.common.by import By import pandas as pd from tqdm import tqdm

#에러 발생 횟수를 체크할 변수 error_count = 0

#시작 페이지 번호 start_page = 1 #종료 페이지 번호 end_page = 9999

#데이터를 저장할 데이터프레임 생성 columns = ['tour_place', 'tour_place_tag', 'tour_place_score', 'tour_place_addr', 'tour_place_tel', 'tour_place_detail', 'tour_place_side', 'tour_place_zzim', 'tour_place_review_count', 'tour_place_view_count', 'tour_place_visit_count', 'tour_place_share_count', 'tour_place_contentsid'] tour_place_df = pd.DataFrame(columns=columns)

#driver_path = '/path/to/chromedriver' driver = webdriver.Chrome()

for page_number in tqdm(range(start_page, end_page + 1), desc='Pages'): formatted_page_number = f"{page_number:04d}" url = f"https://www.visitjeju.net/kr/detail/view?contentsid=CONT_00000000050{formatted_page_number}&menuId=DOM_000001718000000000#" driver.get(url)

# 에러 페이지인지 확인
if 'visitjeju.net/kr/common/errorPage' in driver.current_url:
    error_count += 1
    # 연속된 300번의 에러가 발생하면 중단
    if error_count == 300:
        print("20 consecutive errors. Stopping.")
        break
    continue
else:
    # 에러가 아니라면 에러 카운트 초기화
    error_count = 0

# 페이지 로드를 기다림
driver.implicitly_wait(5)

# 필요한 요소 추출
sub_info_title_elements = driver.find_elements(By.CLASS_NAME, 'sub_info_title')
tag_area_elements = driver.find_elements(By.CLASS_NAME, 'tag_area')
score_area_l_elements = driver.find_elements(By.CLASS_NAME, 'score_area_l')
addr_elements = driver.find_elements(By.CSS_SELECTOR, "#content > div.cont.detail_page.detail_style > div.sub_visual_wrap > div.inner_wrap > div.sub_info_area > div.basic_information > div:nth-child(2)")
tel_elements = driver.find_elements(By.CSS_SELECTOR, "#content > div.cont.detail_page.detail_style > div.sub_visual_wrap > div.inner_wrap > div.sub_info_area > div.basic_information > div:nth-child(3)")
detail_box_elements = driver.find_elements(By.CLASS_NAME, 'add2020_detail_box_in')
detail_box_side_elements = driver.find_elements(By.CLASS_NAME, 'add2020_detail_side_info')
zzim_elements = driver.find_elements(By.CSS_SELECTOR, '#content > div.cont.detail_page.detail_style > div.cont_wrap.sub_visual > ul > li:nth-child(2) > button > p.appraisal_cnt')
like_elements = driver.find_elements(By.CSS_SELECTOR, '#content > div.cont.detail_page.detail_style > div.cont_wrap.sub_visual > ul > li:nth-child(1) > button > p.appraisal_cnt')
reviewcount_elements = driver.find_elements(By.CSS_SELECTOR, '#content > div.cont.detail_page.detail_style > div.cont_wrap.sub_visual > ul > li:nth-child(3) > p.appraisal_cnt')
viewcount_elements = driver.find_elements(By.CSS_SELECTOR, '#content > div.cont.detail_page.detail_style > div.cont_wrap.sub_visual > ul > li:nth-child(6) > p.appraisal_cnt')
visitcount_elements = driver.find_elements(By.CSS_SELECTOR, '#content > div.cont.detail_page.detail_style > div.cont_wrap.sub_visual > ul > li:nth-child(5) > p.appraisal_cnt')
sharecount_elements = driver.find_elements(By.CSS_SELECTOR, '#content > div.cont.detail_page.detail_style > div.cont_wrap.sub_visual > ul > li:nth-child(7) > p.appraisal_cnt')

# 추출한 요소를 데이터프레임에 추가
data = {
    'tour_place': [element.text.strip() for element in sub_info_title_elements],
    'tour_place_tag': [element.text.strip() for element in tag_area_elements],
    'tour_place_score': [element.text.strip() for element in score_area_l_elements],
    'tour_place_addr': [element.text.strip() for element in addr_elements],
    'tour_place_tel': [element.text.strip() for element in tel_elements],
    'tour_place_detail': [element.text.strip() for element in detail_box_elements],
    'tour_place_side': [element.text.strip() for element in detail_box_side_elements],
    'tour_place_zzim': [element.text.strip() for element in zzim_elements],
    'tour_place_like_count' : [element.text.strip() for element in like_elements],
    'tour_place_review_count' : [element.text.strip() for element in reviewcount_elements],
    'tour_place_view_count' : [element.text.strip() for element in viewcount_elements],
    'tour_place_visit_count' : [element.text.strip() for element in visitcount_elements],
    'tour_place_share_count' : [element.text.strip() for element in sharecount_elements],
    'tour_place_contentsid': [f"CONT_00000000050{formatted_page_number}" for _ in range(len(sub_info_title_elements))]
}
page_df = pd.DataFrame(data)
tour_place_df = pd.concat([tour_place_df, page_df])

#모든 값을 '없음'으로 인코딩 tour_place_df.replace("", "없음", inplace=True) tour_place_df.replace(" ", "없음", inplace=True)

#CSV 파일로 저장 tour_place_df.to_csv('tour_places_data.csv', index=False)

#데이터프레임 출력 print(tour_place_df)

#WebDriver 종료 driver.quit()

오랜만의 크롤링. 내가 컴퓨터를 부려먹는건지 컴퓨터가 나를 부려먹는건지 ...

잘 되고 있는 거 확인하고 벨로그 정리 중임.

원래보다 훨씬 많은 정보들을 가져오기로 했다! 주소, 전화번호, 디테일 정보, 공유 개수, 조회수 등도 같이 가져오기로 했걸랑. 그리고 트레이닝 데이터에 넣기 좋을 것 같은

이용안내 부분도 추가해서 가져오기로 했다.

그래서 primary key로 쓰일 수 있는지 파악하기 위해서 주소랑 전화번호 정보가 table 내에 중복되지는 않는지부터 먼저 확인하고 결측치 개수를 센다.

nunique를 세었을 때 전체 컬럼 개수랑 같으면 문제 없이 merge될 것이다. 그 다음 나오는 교집합 외 부분에 대해서는 또 ... 눈으로 보면서 비교해야겠지? 그냥 내일 크롤링이 완전히 잘 되길 바랄 뿐이다.

3. 어제 하기로 했던.

리뷰에서 명사가 아니었던 것들이 나온 이유를 분석해봤다. 일단 리뷰 수가 적은 순으로 place_ids를 출력한 다음, 그들의 핵심 단어들을 보았다. 그러니까 문제가 됐었던 힝힝, 밌었던, 밌다, 밌어들이 있었다.

리뷰 수가 n개 이상인 경우 유의미하다고 판단한다 ... 뭐 그런 기준도 좋지만 리뷰가 1개여도 아주 퀄리티가 좋을 수도 있고. 많아도 핵심 단어가 10개 이상이 아닐 수도 있다. 그래서, 가중치가 n 이상인 경우에만 고려-로 하는 게 낫겠다고 생각했다.

가중치가 0.1 이상인 것만 출력하도록 가중치 코드를 수정했다.

그런 후에 확인하니! 확실히 너무너무 나아진 결과를 보인다. 이건 완전히 끝났으니! 새로운 CSV 파일로 저장하고 마무리. 또, 내일 크롤링 돌리는 동안에는 낮/밤 컬럼을 생각해야겠다. 코드가 이미 있으니까 어렵지 않을 것 같다.

예전에는 컬럼 추가 아이디어 구상이 제일 먼저였는데, 일단 전체 구조를 다 짜 둔 다음에 디테일로 추가하는 게 더 나음이 ... 실감나는 요즘이다.

내일은 크롤링 된 비짓제주와 네이버를 머지시키고, 데이터 전처리 작업을 이어가야겠다.

엔지니어 분 오시면 자동 새 크롤링하기로 한 부분이 컬럼 명 바꿔서 머지된 후에도 괜찮을지도 다음 주에 여쭤봐야겠다. (리뷰, 이미지 업로드는 영향 없는데 관광지가 업로드되는 경우)

🎈 2/16 금 ~ 2/19 월

ADsP 공부와 동시에 멘토님께 질문사항을 공유드리면서 모델팀끼리 회의도 진행해보았습니다. 사실 2/19에 중간발표를 진행하면서 제가 맡지 않은 부분에 대한 이해가 부족하다고 생각해 소통이 필요하다고 생각했던 참이었기에, 팀원분과 이야기를 나눠보며 서로 겪는 어려움을 공유해 정리해보았습니다.

1) 추천시스템 과 2) 챗봇 모델을 학습 중입니다. 가지고 있는 데이터는 전화번호, 위치, 분류와 같은 사실 데이터와 리뷰 데이터들입니다. 리뷰 데이터에서 파생 변수를 생성해서(성별, 나이, 실내/실외 여부, 계절 등) 모델링에 사용할 예정입니다. 넷플릭스와 같이, 처음 회원가입을 할 때 이미지 여러 개 중 사용자 취향에 맞는 n개(4개로 생각 중)를 선택하면, 해당 관광지의 중심 단어들(태그)을 모아올 것입니다. 취향 단어 리스트와 전체 관광지 태그들에 유사도 검사를 진행하여 추천 예측을 할 예정입니다. 다만, 그렇게 되면 리뷰 텍스트에서 가져온 중심 단어 데이터들만 추천에 고려하게 됩니다. 저희가 고려하고 싶으면서 유의미할 것으로 예측되는 피쳐(나이, 성별, 계절, 실내/실외 여부 등)를 같이 사용하고 싶은데, 데이터의 형태가 달라 같이 사용하는 방법이 궁금합니다. (함께 인코딩하기가 어렵습니다..) 또, 지금 visitjeju 사이트와 네이버 사이트, 그리고 AIHUB의 데이터를 함께 사용하려던 도중, 데이터 merge에 어려움을 겪고 있습니다. 명시적인 primary key가 없을 때 다른 소스 자료들을 사용하는 법을 알고 싶습니다. 넷플릭스 등 대기업 추천 모델에서는 협업필터링과 내용 기반 필터링을 같이 쓰는 하이브리드 모델을 이용하는 것으로 알고 있습니다. 사용자 로그에 대한 정보가 없기 때문에 협업필터링을 사용할 수 없다고 판단하나, 이런 상황에서도 사용이 가능한지와, 상용화 후 어떻게 할 수 있는지에 대한 아이디어를 들어보고 싶습니다. 또, 챗봇 모델에 대해 문의 말씀을 드립니다. LLM과 RAG 모델(LANGCHAIN)을 함께 사용하려고 하는데, RAG에 CSV 형태의 저희 데이터를 학습시키는 과정에서 어려움을 겪고 하드코딩을 통해 TXT 파일로 바꾸어 학습시켰습니다. 그런데 저희는 리뷰데이터와 관광지 데이터를 주기적으로 업데이트할 것이므로, 현재처럼 RAG에 TXT 파일을 학습하는 경우 번거로워 csv로 학습하는 법을 알면 좋을 것 같습니다.

--

정리하고보니 이제 어떤 작업이 필요한지가 보여 좋았습니다. 이에 대한 멘토님의 답변을 듣고 진전이 좀 났으면 좋겠습니다.

회고

🎍 잘했던 점 모델을 뜯어보고 공부하고, 직접 모델 구조를 구성한다는 것에 그래도 익숙해짐을 느꼈습니다. 앞으로도 대충 써보고 안돼서 머리 쥐어 뜯기보다는 리드미를 좀 읽어보는 습관을... 그리고 꽤 생산적인 일주일을 보냈습니다.

🎃 아쉬운 점

저번주부터 크롤링에 개입했는데, 로컬환경에서의 크롤링, out of memory를 중간에 신경쓰면서 하는 게 번거롭고 크롤링하는 동안에는 다른 작업에 완전 집중이 될 수 없어 아쉬웠습니다.

일단 기본 데이터는 다 보유하고 있기 때문에, 이 정도로 돌아갈 수 있도록 코드를 짜 두고 복학 후에 데이터를 추가함과 동시에 피쳐도 추가하며 코드를 수정하는 방향으로, 구동할 수 있는 모델을 서빙하는 걸 목적으로 해야겠습니다.

🎀 개선 방안

막막함에 포기하지 않기 할 수 있는 만큼만 계획하고 실행하기 내일 해야 할 일 적어놓고 귀가하기 내가 지금 어느 수준에 있는지 파악하기 검색을 두려워하지 않기 우선순위를 고려하기

🎡 다음 주(2/21~2/27)

• OCR 모델 서빙 실험
• 챗봇 모델 저장, 실험
• 피쳐 추가 생성 (연령, 나이, 실내/실외, 계절)
• ERD 제대로 그리기 (날짜, 날씨 고려)

I. 배운 점 및 알게 된 점

먼저 미니프로젝트는 이번에 프론트엔드 백엔드 쪽으로 배우고 있어요. 예전에 Oracle 수업을 학교에서 들으면서 한 번 해 봤지만 ... 2학년 아깅이던 저는 발표랑 flow 구현만 맡고 ... 워낙 오라클이 쉽기두 했구엽. 아예 처음 시작해서 수업 듣는 동안에도 '이게 지금 어느 단계지?'하는 기분이었어요. 미리 말씀드리자면 지금 회고록 적고 뒤에서부터 돌아가니까 예전에 했던 것들이 새록새록 기억나면서 도움이 되네요.

꽤나 많이 배운 것 같죠? 만들어진 폴더가 ㅋㅋㅋ. 그럼 하나하나씩 정리해봐요! 사실 이번에 해커톤 경진대회 나가면서도 느꼈지만, 이게 언어인지 라이브러린지 뭔지 아는게... 단어가 좀 달라서 힘들더라구요. 제일 마지막 폴더를 보며 알아보겠습니다! (사실 이 날에 오진 않았어서 모르는 내용이지만 같이 해 봐요)

먼저, 웹개발의 시작은 프론트엔드와 백엔드 개발로 나뉩니다. 프론트엔드 개발은 사용자가 직접 상호작용하는 부분을 다루며, 주로 HTML, CSS, JavaScript를 사용하여 웹 페이지의 구조, 스타일, 동적 기능을 구현합니다. 사용자가 웹사이트를 열면 눈에 보이는 부분이 프론트엔드에서 생성된 것입니다.

이 파일은 벡앤드 개발이 없습니다. 페이지에 html, js, md, css 파일이 있네요.

1. HTML (HyperText Markup Language):

HTML은 웹페이지의 기본 구조를 정의하는 마크업 언어입니다. 웹 문서의 뼈대를 형성하며, 텍스트, 이미지, 링크, 표 등을 구조화하여 표현합니다. 예를 들어, div, p, h1과 같은 태그들을 사용하여 웹 페이지의 구조를 정의합니다.

특히 이 사진을 참고하면 도움이 많이 됩니다 ... 어떤 구조로 이루어져 있는지 러프하게 정해두는 거죠

2. CSS (Cascading Style Sheets):

CSS는 HTML로 작성된 웹페이지의 스타일과 레이아웃을 정의하는 스타일 시트 언어입니다. HTML이 문서의 구조를 담당한다면, CSS는 해당 구조를 꾸며주어 시각적인 디자인을 구현합니다. 색상, 글꼴, 간격, 배치 등의 스타일을 정의하고, 클래스 및 ID 선택자를 통해 특정 요소에 스타일을 적용합니다. 예를 들어, color, font-size, margin과 같은 속성들을 사용하여 스타일을 지정합니다.

특히나 모양을 바꾸고 싶다면 인터넷을 열심히 찾아 원하는 스타일을 찾으면 되겠네요 :)

• 이 페이지를 참고하면 css 스타일을 많이 알 수 있답니다 ~! https://www.freecodecamp.org/korean/news/css-beoteun-seutail-hover-color-background/

3. JavaScript

JavaScript는 동적이고 상호작용하는 웹페이지를 만들기 위한 스크립트 언어입니다. 클라이언트 측에서 실행되며, 웹 브라우저에서 사용자와 상호작용하면서 페이지를 업데이트할 수 있는 기능을 제공합니다. 이벤트 처리, DOM 조작, AJAX 통신, 애니메이션 등을 통해 사용자 경험을 향상시키고, 웹페이지를 동적으로 만듭니다. 예를 들어, 버튼 클릭에 반응하여 내용을 변경하거나, 사용자 입력을 받아 처리하는 등의 작업을 JavaScript를 통해 구현할 수 있습니다.

이렇게 되어 있네요. 함수를 실행시키는 코드들이 나와 있습니다.

백엔드 개발은 웹사이트의 뒷단을 다룹니다. 데이터베이스와의 상호작용, 사용자 정보의 처리, 비즈니스 로직의 실행 등을 포함합니다. 주로 서버 측 언어와 프레임워크를 사용하여 서버를 구축하고, 클라이언트 측과의 원활한 통신을 유지합니다. 이를 통해 사용자에게 제공되는 동적인 콘텐츠와 서비스를 가능케 합니다.

웹개발에서는 여러 도구와 기술이 사용됩니다. 프론트엔드 개발에서는 React, Angular, Vue와 같은 프레임워크를 사용하여 효율적인 사용자 인터페이스를 구현합니다. 백엔드에서는 Node.js, Django, Ruby on Rails 등의 프레임워크를 활용하여 데이터 처리와 비즈니스 로직을 구현합니다.

이번에 다녀온 캠프에서는 React 프레임워크랑 Node 백엔드 프레임워크를 사용하셨고, python이면 Django도 자주 쓰시는 것 같아요.

또한, 웹 개발에서는 데이터베이스 관리 시스템(DBMS)을 사용하여 데이터를 효과적으로 저장하고 관리합니다. MySQL, PostgreSQL, MongoDB 등의 데이터베이스가 흔히 사용되며, 이를 통해 사용자 정보, 콘텐츠, 트랜잭션 데이터 등을 안전하게 보관합니다. 저희는 그 중 MySQL을 이용해보았었습니다.

웹의 발전과 함께 모바일 플랫폼에 대한 대응도 중요해졌습니다. 반응형 웹 디자인이나 모바일 앱 개발을 통해 다양한 디바이스에서 웹사이트나 애플리케이션을 효과적으로 이용할 수 있도록 합니다.

마지막으로, 웹 개발은 보안과 성능 최적화에도 매우 민감합니다. SSL 인증서를 통한 암호화, 사용자 인증 및 권한 관리, 코드 최적화 등을 통해 웹사이트의 안전성과 성능을 유지하며 사용자에게 최상의 경험을 제공합니다.

III. 느낀 점 지금 정리하기 전까지는 왜 각 부분이 필요한지가 확실하진 않았어요. 그리고 그래서 팀프로젝트를 할 때 내가 부분만 맡으면 그래서 뭐가 뭐에 필요한 건지 끝까지 알지 못할 것 같아, 혼자 했던 것도 있습니다. 미니프로젝트 시행착오를 겪으며 잘 잘 해 나가겠습니다앗.

J인 척 계획을 좀 세워볼게요.

14일(목) / flow 설정, 벤치마킹 15일(금) / (지각) 16일(토) / 17일(일) / 18일(월) / 추가 기능 구현

어떤 순서로 진행돼야할지부터, 강사님께 잘 여쭤가며 마무리해보겠습니다!!

화이팅이요 >_<

root는 모든 데이터를 관리할 수 있는 계정 우리는 MySQL에 있는 데이터베이스와 각 table을 사용할 수 있다.

이제껏 우리는 모두가 같은 파일(.csv 등)을 다운받아 작업을 해왔었다. 그 중에서는 불필요한 테이블들도 있었을 것이고, 모든 컴퓨터가 같은 파일을 다운받아야한다는 불편함도 있었다.

그런 한계를 개선하기 위해 MySQL을 사용할 수 있고, 우리는 MySQL을 포함해서 여러 데이터베이스 관리 프로그램에 접근할 수 있는, Connect 연결프로그램인 DBeaver를 통해서 계정을 이용해 접근한다.

귀여운 비버

계정은 DBA가 지정해주며, 우리는 root@MySQL, test@MySQL, urstory@MySQL 등 각 데이터프레임과 테이블에 접근 권한이 있는 계정을 받게 된다. 그걸 이용해서 테이블을 만들면 됨. 그 권한들은 DBA가 지정한다.

root 계정은 다른 권한들이 있고, 데이터를 바꿀 수 있기도 해서 무섭쟈나. 그래서 권한이 제한되어있는 test 계정을 이용해서 데이터베이스에 접근할 예정이다.

(일단 이 script도 필요함. test에 권한 부여하기 위해서 ...)

순서가 조금 헷갈리는데, 일단

상단 플러그를 클릭해 새로 오브젝트를 생성하고,

Connection Setting(즉, DBeaver에서 MySQL 저장창고로 향하는 것)을 해 준다. 이때 다른 건 바꿀 필요 없지만, Authentication (Database Native)에 지정된 Username, Password를 입력해야한다.

그런 다음에는, Test Connection을 해 주는데, 아마

allowPublicKeyRetrieval이 true가 아니라면 오류가 뜰 것이다. 그럼 우리는 true로 직접 입력하고, Test Connection을 해 주면

Connected 될 것이다! 야호

그럼 이 계정에서 접근할 수 있는 데이터베이스들이 뜨는데, 우리는 'classicmodels'를 쓸 것이다.

편집기라고 쓰이는 이 곳이 바로 Script 생성기와 똑같은 말이라고 보면 되겠다. 여기서 코드를 짤 것이다 .

짠 이렇게 빈 공간이 뜬다. 그래서 'show databases'나 show tables를 하면 되는데,

봐. tables 안 불러오잖아. 뭐야!

이건 데이터베이스가 지정되지 않았기 때문이다. 여기 위를 꼭! 들여다보는 습관을 들여야 한다.

하나밖에 없는 소듕한 classicmodels를 두 번 클릭해보쟈.

이젠 되지롱. 몇개의 테이블이 소환되었다!!

어머 이렇게 한 코드 당 Query에 따른 표가 쫙 구분돼서 펼쳐지니까 너무 좋다.

꼭 표로 표시될 필요가 없는 건데도 표로 표시되는군.

이건 컬럼을 뽑은 것.

이건 컬럼명을 변경한 것.

그럼 이번 과제를 풀어보려고 한다.

위는 customer table을 가져왔다고 하면, 이제는 employee table을 이용해보자는 것.

똑같은 틀을 사용했다! use classicmodels;와 show tables;는 꼭 하고,

아래에서 데이터를 한 번 스윽- 확인해준다.

1. officeCode가 1이거나 2인 경우
2. lastName이 B로 시작하는 사람
3. 조회할 컬럼들은 lastName, firstName, email, officeCode
4. 각 조회되는 컬럼들 이름변경...

이었다.

이게 전부였다!

UI가 파이썬보다 훨씬 나은 듯 했다. 앞으로도 간바레..

이유정입니다. 요즘 날씨가 많이 쌀쌀해졌네요. 회고록 시작하겠습니다.

1. 일주일 동안 배운 점:

딥러닝을 배우고 있다. 저번 주, 머신러닝에 빠져 있어 딥러닝 공부를 잘 해야겠다고 생각한 이후 앞자리에서 수업을 들으며 대답도 잘 하고 딥러닝의 재미를 조금씩 알아가는 중이다. 특히나 NLP(Natural Language Processing, 자연어 처리) 방법을 배우는데, 자연어 처리나 주식 예측, 이미지 내 글자 처리 등 지금 배우고 있는 부분들이 새로운 모델을 구축하기에 한계가 있고 실무에서 사용하기 힘들지도 모르겠지만 충분히 이용할 부분이 많다고 생각된다.

코드를 직접 짜야 하는 부분이 많아 수업 관련 노션을 적지 않게 된 지 오래되었다. 어제는 오랜만에 남아 공부하며 내용을 벨로그로 정리해보았다. 이미 있는 코드에 주석을 다는 것보다 복습 과정에서는 이 부분에서는 이 코드가 필요하다-라는 정도로 내가 외울 수 있는 액기스만 외우는 것이 좋아보인다. 그런 걸 할 수 있게 만드는 게 벨로그 작성과 함께 공부하는 것. 핵심을 잡고 내가 약한 부분을 파악하고 맥락을 갖게 만들어주는 과정을 오랜만에 다시 시작하며, 다시 제대로 공부한 느낌이다. 딥러닝을 끝내기 전에, 이번 주말에는 꼭 딥러닝 전 범위를 이렇게 해석할 수 있었으면 한다.

[링크텍스트] (https://velog.io/@yous_rchive/11%EC%9B%94-1%EC%A3%BC%EC%B0%A8) ▲ 3회분 정리 링크. 나머지 부분도 이번 주 내로 업로드 예정.

2. 잘한 점

저번에 수업시간에 집중하자 했던 약속을 잘 수행하고 있음. 딥러닝을 포기하지 않고 하고 있음. 핵심을 잘 잡음. 난 생각보다 공부를 꾸준하게 성실히 하는 편은 아니지만 말하는 사람이 어디에 강조점을 두는지 파악을 잘 하는 것 같음.

그런데 요즘 잠을 잘 못 자서 그런지 ... 수업 시간에 자꾸 조는데 정신 차리고 들으슈 유정

3. 개선점

이론 공부를 잘 안 듣다가 코드 다룰 때만 수업을 듣는 편이었다. 왜냐면 우리가 사용할 모델은 우리가 정의할 게 아니라 긁어 쓸 거고, 임포트 할 것이기 때문.. 우리가 왜 이걸 알아야 하는지? 잘 이해하지 못했었다. 그런데 모델은 너~어무 많고 그 중에서 뭘 써야할지, 뭐가 내 상황에 좋은지, 그리고 가장 중요하게 어떤 변수가 정해져야 하는지를 알기 위해서는 모델의 구성을 이해할 필요가 있다. 뭣보다 맥락을 위해서는 이론으로 다져두는 게 필요함. (문과 특: 때려 외우는 거 이해 안 됨.) 따라서, 어차피 코드만 보고 모를거면 이론 열심히 해라. 반이라도 간다. (내가 그렇더라)

머신러닝 부분을 정리하고 넘어가자고 했었는데, 새로 들어오는 것도 누적되는 차에 잡을 수가 없다. Dacon 대회도 나가게 된 거, 새로운 걸 많이 검색하고 ... 자료를 다시 찾아보며 다시 공부해볼 수 있었으면 좋겠다 이번 대회 혼자 나가는 게 아닌 이상 책임감을 갖고 다음주 월요일까지 잘 해결하도록 하자. 화이팅 유정.

(힘들어서 이번 회고록은 쫌 짧게 쓰겠습니닷. ㅎㅎ)

0. NLP(Natural Language Processing) 개요

자연어 처리

인코딩: 컴퓨터가 인지하는 형태로 문자열을 처리하는 방법. 인코딩한다는 의미는 유니코드를 utf-8, euc-kr, ascii 형식의 byte 코드로 변환함을 의미함. 디코딩: byte 코드를 유니코드로 변환하여 문자열로 표시하는 방법.

(인코딩하고자 하는 변수명).encode('형태(utf-8, euc-kr, ascii 등)') (디코딩하고자 하는 변수명).decode('형태(utf-8, euc-kr, ascii 등)')

그 중 가장 좋은 정규화 방법? ASCII, Unicode ... etc utf-8(가변길이 인코딩): 현재 아스키코드가 표현하는 알파벳, 숫자, 특수기호의 한계를 인지하고 uft-8을 사용함. 운영체제, 프록그램, 언어에 관계 없이 문자마다 고유 코드 값 제공하는 의의 있음.

(※ 한글 영어만 추출할 때 데이터가 None이 되는 경우는 아스키 코드가 달라서 발생함 -> 유니코드 정규화 필요)

unicodedata 임포트 -> normalize('NFC', '문자열') -> 문자열 반환해서 표시

=> 중요하지만, 한계를 경험하지 못해 아직 필요성을 잘 모르겠음.

CLEANING

처리 대상: 대문자, 소문자 처리 / 출현 횟수 적은 단어 제거 / 노이즈 제거

1) 대문자, 소문자 처리: US, us 등 대문자 소문자의 뜻이 다른 경우 변경해서는 안됨.

2) 출현 횟수: 출현 횟수 적음에도 중요한 단어는 제거하면 안됨.

3) 노이즈: 관사, 대명사 등 의미 없는 글자 제거

=> 중요. 특히, 대문자, 소문자 처리에 있어 미리 데이터 검토 필요하다는 생각. (set으로 중복 검사 후 VOCAB 확인하며)

STEMMING

추출 대상: 어간 추출(문법<), 표제어(원형) 추출

1) 어간 추출 ing, s(복수), ness 등 품사를 바꿔주는 접사들을 제거하여 중복성을 낮추고 의미 극대화

2) 표제어 추출 is, are -> be, having -> have 등 품사 정보를 제거

Stopwords 불용어 제거

분석에 도움 되지 않는 단어들 제거

Tokenization 의미 부여 단위

신경망은 훈련 중에 문자 의미와 단어의 문장 형성 과정 이해. Word level, Char level(문자, 글자 단위) 등 다양한 접근 방식 존재.

token: 텍스트의 원자 조각 Tokenize: 텍스트를 토큰으로 변화하는 과정 Vectorize: 토큰을 신경망 공급 가능한 숫자에 할당 (Vocab: 토큰 어휘 구축해 Vectorize에 이용) Word Embedding: Vectorize의 과정, 토큰을 공급 가능한 숫자에 할당하는 과정

Vocabulary 어휘집

중복을 제거한 어휘와 index가 정의된 집합. 문자를 숫자로 변환 가능

Encoding 문자 숫자 처리

Encoding의 한계: 1) Out of Vocabulary: 단어장에 없는 경우 손실 2) Order: 순서 정보 손실

Encoding의 방법:

• Integer Encoding

Bag of Words(빈도 값), Count Encoding(단어 토큰 생성, BOW 인코딩 벡터 생성), TF-IDF Encoding(전체 문서의 공통 단어의 가중치 축소) 등 방법들이 있음.

다른 임포트가 없는 경우, 해당 문서 내 공통 정보 축소 이용하는 TF-IDF가 좋아보임.

단어 사이의 연관성을 파악하기 어렵다는 단점이 있다.

-One Hot Encoding

벡터를 단어 개수만큼(index + 1) 만들어 표현하고자 하는 단어의 인덱스를 1, 나머지는 0으로 표시. 다만, 0으로 표시되는 vector가 많아 낭비가 심하다는 sparse vector, 희소 벡터의 단점이 있다.

-Word2vec Encoding

분산 가설, 비슷한 위치의 단어는 비슷한 의미를 가진다-는 가설을 이용하여 비슷한 위치에 존재하는 단어는 단어 간 유사도를 크게 파악. 의미상보다는 문장구조상 특질을 이용

단어의 유사성을 반영할 수 있음. 단어의 모든 의미 구분 못하고, 다른 뜻을 갖는 한 단어에 대한 여러 의미를 묶을 수 있음. (왜? 의미적 유사성에 관심이 없음)

Word Embedding with neutral network

word Embedding에 신경망을 사용함! -> 벡터화에 학습 사용 LSA, Word2Vec, FastText, Glove 등이 있으나 보편적 Embedding은 단어를 벡터로 변환한 후 가중치를 학습하는 것처럼 단어 벡터를 학습시킴. 단어를 실수 형태 벡터로 표현하고, 신경망에 임베딩 레이어를 추가하여 임베딩 얻음.

Padding

서로 길이가 다른 각 문장, 문서에 대해 길이를 임의로 동일하게 맞춰주는 작업

Similarity 유사도

Euclidean Similarty: 거리 기반 유사도 (L2 distance) Cosine Similarity: 지향 방향 기반 유사도 (-1 ~ 1 존재)

6. deep learning
7. NLP pytorch

1-1. Integer Encoding

from torchtext.vocab import build_vocab_from_iterator

1) DictVectorizer - with BOW

from sklearn.feature_extraction import DictVectorizer vect = DictVectorizer(sparse=False) data = [{'A': 1, 'B': 2}, {'B': 3, 'C': 1}] X = vect.fit_transform(data) # 인코딩 수치 벡터로 변환(X)

{'A': 1, 'B': 2} -> [1, 2, 0] {'B': 3, 'C': 1} -> [0, 3, 1]

이때까지 입력받은 값에 대해 빈도 값 부여해 피쳐 값 추출. 또한, 자동으로 단어를 추출.

2) CountVectorizer

vect.vocabulary_에 vocabulary가 존재하니, 학습 후 확인이 가능함. 객체화, fit 후에 vect.transform('확인하고자 하는 문자열').toarray()을 통해 vocabulary에 대한 빈도 값 확인이 가능함.

0: negative, 1: positive가 아니라 빈도 수를 기반으로 노출

[사용 가능한 메소드]

1 stop_words

vect = CountVectorizer(stop_words=["and", "is", "the", "this"]).fit(corpus) vect.vocabulary_

메소드 stop_words = []를 이용해서 무시할 수 있는 관사, 접속사, 조사 등을 설정 가능함.

2 analyzer, tokenizer

vect = CountVectorizer(analyzer="char").fit(corpus) vect.vocabulary_

analyzer="char"이면, 글자 단위로

◆ 'punkt' 데이터는 문장 및 단어 토큰화에 사용되는 모델과 데이터 파일을 제공 ◆ 이 객체는 문서 집합(corpus)을 기반으로 단어 빈도수를 계산함. tokenizer 매개변수에 nltk.word_tokenize 함수를 사용하여 텍스트를 토큰화하도록 설정함. nltk 라이브러리의 단어 토큰화 함수를 사용하여 문서를 단어로 분할함. -> nltk는 이미 있는 토큰화 모델 중 1, 언제나 이용 가능함.

3 N-gram

개수 설정해서, 토큰 크기 결정함. '연결된' (잘 안 쓸 듯.)

4 Frequency

max_df, min_df인수를 사용하여 문서에서 토큰이 나타난 횟수를 기준으로 단어장을 구성. 토큰의 빈도가 max_df로 지장한 값을 초과 하거나 min_df로 지정한 값보다 작은 경우에는 무시한다.

vect = CountVectorizer(max_df=4, min_df=2).fit(corpus) # 단어별 빈도수: 최대 4개, 최소 2개 vect.vocabulary_, vect.stop_words_

({'this': 3, 'is': 2, 'first': 1, 'document': 0}, #index 기반 vocabulary 노출 {'and', 'last', 'one', 'second', 'the', 'third'}) #stop_words을 자동으로 지정

-> stop_words를 frequency 기반으로 미리 지정해두고 쓸 수도 있을 듯.

ex. a = vect.stop_words_ (stop_words = a) 그런데 CountVectorize를 안 쓰는거지.

TfidfVectorizer

CountVectorizer와 비슷하지만 TF-IDF 방식으로 단어의 가중치를 조정한 BOW 인코딩 벡터를 만든다.

from sklearn.feature_extraction.text import TfidfVectorizer

tfidv = TfidfVectorizer().fit(corpus) #객체화 및 학습 tfidv.transform(corpus).toarray() #corpus에 대해 변형시켜 array로 노출

pd.DataFrame(tfidv.transform(corpus).toarray(), columns = tfidv.get_feature_names_out()) #tfidv 객체의 메소드 get_feature_names_out를 이용해서 columns로 지정하여 데이터 프레임 생성, to array 만들기.

+ WordCloud(필요하다면)

[만드는 과정 분석]

!pip install wordcloud from wordcloud import WordCloud

wc = WordCloud(background_color="white",width=500,height=500) #객체화

corpus = 데이터 리스트

vect = CountVectorizer() tdm = vect.fit_transform(corpus) #vectorizer를 통해서 인코딩 벡터를 만든다. (겹치지 않도록 단어장 형성, 빈도 세리기)

df_tdm = pd.DataFrame(tdm.toarray(),columns=vect.get_feature_names_out()) #tdm(corpus로 data가 개수를 반영해서 만들어진 리스트)를 array로 변환한 값을 기준, 그 중에서 columns는 feature에 해당되는 열으로 지정.

df_tdm.sum().to_dict() df_tdm의 합, 그러니 전체 document에 대한 값들을 더해서 dict의 형식으로 만들기. {}에 피쳐와 개수(빈도)가 함께 담긴다.

변수 = wc(객체화).generate_from_frequencies(df_tdm.sum().to_dict()) 변수.to_image()

그 합의 값들에 대해서 we.generate_from_frequencies 함수를 사용하면 담긴다. 그걸 to_image()로 이미지로 표시하기.

그럼 표시하기 전, dictionary 형태로 표시하는 게 필요해보인다. 벡터는 2개로, 하나는 feature(각 단어), 하나는 빈도. 또, array 형태일 필요가 있다.

※ df = pd.DataFrame(data, columns=columns) pandas의 DataFrame 만드는 메소드 사용을 위해서는 데이터와 columns 지정이 필수적이다.

6. deep learning
7. NLP pytorch

1-2. 형태소 분석

import nltk

nltk.download("punkt") nltk.download("averaged_perceptron_tagger")

sentence = """ At eight o'clock on Thursday morning Arthur didn't feel very good.""" #토큰화 원하는 document

tokens = nltk.word_tokenize(sentence) tokens #형태소 단위로 분석, (개수 안 세리고) 리스트로 만듦

nltk pos_tag: 품사 적용

tagged = nltk.pos_tag(tokens) tagged (튜플 형태 구성)

spacy

영어:

한국어:

Okt 형태소 분석

띄어쓰기 유무에 따라 정확도의 차이가 있지만, 띄어쓰기가 없는 경우에도 형태소 단위로 분석할 수 있음.

(Okt를 사용하되 word_min, max를 위처럼 설정해놓으면 좋을 것 같음.)

Mecab

(chatgpt: 따라서 선택지는 사용하려는 언어 및 목적에 따라 다릅니다. MeCab는 일본어에 최적화되어 있고, Okt는 한국어 자연어 처리를 간편하게 수행할 수 있는 좋은 선택입니다.)

어쨌든 둘 다 형태소 분석 툴킷 및 라이브러리임.

KIWI (추천!)

from kiwipiepy import Kiwi kiwi = Kiwi() #객체화 result = kiwi.analyze('텍스트',top_n=3) #kiwi의 analyze 메소드 사용, 분석하는 문장과 몇개의 가능한 선택지 제공할 것인지 선택하는 변수 top_n 지정

가능한 여러 개의 가능성들을 열어두고 제시함. (chat GPT: -27, -31.23612403869629, -57.53723907470703와 같은 숫자는 해당 형태소 분석 결과의 신뢰도나 가중치를 나타내며, 이를 기반으로 최적의 형태소 분석 결과를 선택)

[ token.form for token in result1[0][0]] 우리가 선택할 수도 있지만, [0] 이렇게 가장 신뢰도 높은 걸 선택할 수도 있지.

kiwi.tokenize() 메소드를 사용하면, Token(form=, tag=, start=, len=)의 형태로 나온다. result의 각 개체들을 변수에 저장하고, 변수.form, 변수.tag, 변수.start, 변수.len 등으로 따로 나누는 것도 가능하다.

• stopwords 불용어 메소드 from kiwipiepy.utils import Stopwords stopwords = Stopwords() #stopwords 인스턴스화. result = kiwi.tokenize(txt_list, stopwords=stopwords) # 토큰화 & 불용어

for tokens in result: print(tokens)

tokenize로 txt_list를 토큰화하는 것도, stopword를 지정하는 것도 가능하다.

stopwords.add("NLP") stopwords.stopwords #이런 식으로 stopwords.add() 함수를 추가할 수도 있다.

stopwords.remove(["NLP"]) stopwords.stopwords #이런 식으로 stopwords.remove() 제거할 수도 있다. (단, 추가할 때에는 단어만 추가해도 됐지만 튜플 형태로 되어있기에... 제거할 때에는 [] 리스트 형태로 표시해야 함)

6. deep learning
7. NLP pytorch

1. Word2Vec word embedding을 위한 방법 중 하나, 단어의 유사성을 문장 구조 상 위치로 봄 같은 문장의 인접 단어 간 의미 유사도를 전제함. 다음에 단어가 나올 확률을 계산함.

[이용 과정]

tokenizing -> vocabulary sliding window size(한 단어의 영향력 범위 설정) -> 입출력 쌍 구성 행렬연산 및 유사성 파악 One-hot encoder를 했을 때 차원 수 = 단어 수 == 5 input layer, output layer node 개수 5 Softmax W1, W2, x를 곱한 결과에 softmax 취해 0과 1 사이 확률로 나타내기 y값과 차이 구해 loss를 줄이기

Bag of Words 방식으로 벡터화하는 것은 유사도, 순서를 나타낼 수 없다. 따라서 CBOW나 skip-gram을 사용한다. CBOW: 한 단어를 주변 단어의 문맥을 이용해 예측 SKIP-GRAM: 어떤 단어를 이용해 주변 단어를 예측 (상관없을 듯? 어쨌든 단어의 주변 환경 고려한 의미를 받아들이기에 사전적 의미[0] 사용보다는 맥락 중심이라 좋을 듯.)

[학습 방법]

import nltk

nltk.download("punkt") nltk.download("averaged_perceptron_tagger") #품사 태깅 모델 제공 from tqdm import tqdm

#DICT 비워두기 tokenized_data = [] #DF의 REVIEW열의 각 값들을 SENTENCE라고 치고, for sentence in tqdm(df['review']): sentence = sentence.lower() # 대문자를 소문자로 변환 sentence = sentence.replace('
', '') # 필요없는 문자 제거 tokenized_sentence = nltk.word_tokenize(sentence) # 토큰화 tokenized_data.append(tokenized_sentence)

점점 비워둔 'TOKENIZED_DATA'에 추가해나감. 그럼 '단어' 형태의 리스트로 저장이 됨. 소문자화, REPLACE 이후 TOKENIZE 실행

자체 데이터만 가지고 단어 맥락 예측하는 건 일반화 가능! -> Pre-trained Word2Vec을 사용하는 것은 어떨까여.

word2vec_model = gensim.models.KeyedVectors.load_word2vec_format(dataframe) #.similarity 메소드 존재 : 단어를 입력하면 유사도 노출해줌. word2vec_model.similarity('', '') #.most_similar('') 메소드 존재: 단어를 입력하면 의미적 유사한 단어 노출해줌

6. deep learning
7. NLP pytorch

2. CNN 1D

1 결측치 데이터 확인, 데이터 제거

2 Text Preprocessing

Cleaning 앞뒤 공백 제거, 불필요 부분 없애기

with df_ko['document'] = df_ko['document'].map(lambda x: x.strip()) df_ko['document'] = df_ko['document'].map(lambda x: x.replace("..", " "))

3 Tokenization (유의미한 단위로 자르기)

1) with Mecab from konlpy.tag import Mecab mecab = Mecab() #인스턴스화 result = mecab.pos(text) #.pos() 메소드에 텍스트 넣어 결과 추출

2) with Kiwi(권장) from kiwipiepy import Kiwi from kiwipiepy.utils import Stopwords

stopwords = Stopwords() # 불용어 kiwi = Kiwi() # 형태소 분석기 객체화 text = df_ko["document"] result = kiwi.tokenize(text, stopwords=stopwords)

4 Stemming / Stopword tokenizer를 통해 나눈 곳에서 의미있는 어간 등으로 추출하기 Stopword를 통해 !, ~ 등 제거 (같은 의미인데 품사가 달라 달리 카운트되면 비효율적임)

*def tokenizer(text): tokens = kiwi.tokenize(text, stopwords=stopwords) # 토큰화 return [ t.form for t in tokens if t.tag[0] in "NJMV" ] *

애초에 tokenizer를 정의할 때, tokenize 과정에서 token의 form, tag도 확인이 가능함. 특정 단어를 Stopword로 지정할 수도 있지만, form, tag의 원하는 종류에 해당하는 token만 선정해 뽑을 수 있음. return(#우리한테 보이게 해라) t.form for t in tokens (token의 내용들을 t로 선정하고, 그것의 t.form을 노출해라) if t.tag in "NJMV" (만약 그 t.tag가 NJMV 중 있으면.)

tokenizer def 하는 코드에서 사용 가능~!

def yield_tokens(data, tokenizer): for text in tqdm(data): yield tokenizer(text)

얘는 yield_tokens(data, tokenizer)를 정의하는 것. 넣으면 tokenizer(text)를 산출함.

결국! yield_tokens를 산출해서 데이터셋을 만들기 위해서는 yield_tokens를 정의해야하고, 정제 과정에서의 tokenizer도 정의해야하고 tokenizer는 kiwi.tokenize의 툴에 불용어와 허용 품사를 정해 넣을 것임.

5 vocabulary 그래서. 지금 정리해서 의미 있는 단어들만 추출했음! 그 단어들을 담아 이 dataframe의 단어들과 index를 노출하는 단어집을 만들겠음.

(패딩): 0 (정의되지 않은 문자): 1

gen = yield_tokens(df_ko["document"],tokenizer) # 토큰화

역시 yield_tokens에 데이터와 tokenizer를 넣는군. 실제로 data 값을 넣는 작업을 시작함. (앞엔 인스턴스와 변수를 정의한 것일 뿐이져~)

vocab = build_vocab_from_iterator(gen, specials=["",""]) # 어휘집 (gen은 데이터구요, build_vocab_from_iterator(data, specials = [지정])) 그럼 data를 기반으로 specials = []를 지정해서 special + 정제된 데이터 토큰화된 것을 이용해 vocabulary를 만들어내고, 그것을 vocab에 담는다.

vocab.set_default_index(vocab[""]) unk가 vocab에 있잖앙. 그걸 default로 지정한다 => vocab에 없는 단어들은 unknown으로 지정 어 근데 data를 그대로 이용해서 vocab을 만들었잖아용?? 근데 왜 단어가 없을 수 있죵? 왜냐면 NJMV에 해당하는 유의미한 어간들만 냈자나여! 의미 없는 것들이 unk에 저장됐을 거에엽.

그럼 이제 어휘집에서

1) len 전체 길이를 산출해낼 수 있다. 2) lookup_tokens : index를 NLP로 바꿈 3) vocab(['', '']) : NLP를 index로 바꿈

features = [ vocab(tokenizer(text)) for text in tqdm(df_ko["document"].tolist()) ] features = [vocab(tokenizer(text)) for text in df_ko["document"].tolist()]

features는 text를 tokenizer한 것을 vocab에 담음.

#1. 토큰화가된 결과 데이터를 담을 변수 선언

#2. 데이터 프레임에서 for문으로 돌린다.

#3. tokenizer()함수를 이용해서 데이터를 토큰화(글자)

#4. vocab()함수를 이용해서 토큰화(글자)를 토큰화(숫자) 변환

#5. 변수에 해당 결과(토큰화(숫자))를 담음

6 Padding

max_len = max(len(lst) for lst in features) max_len

**features = [ lst + [0] * (max_len - len(lst)) if len(lst) < max_len for lst in tqdm(features) ]**

features = np.array(features) features.shape # 10000.48 max_len == len(features[0])

                        7
                                                                      Dataset
                                                                      6- padding을 통해 feature를 형성한 다음, dataset을 만들어보자.
                                                                      target = df_ko["label"].to_numpy()

target.shape 지금은 (10000,)이니까 (10000,1)로 변형시키기 위해 target = target.reshape(-1,1) target.shape

저는 앤코아 플레이데이터에서 데이터 엔지니어링 트랙을 밟고 있습니다. 총 6개월, 9월 말부터 3월 말까지 진행되는 과정입니다. 플레이데이터와 함께 한 지가 벌써 1달이 넘었네요. 약 20%가 지나간 셈입니다. 지나간 시간들이 뿌듯하기도, 아쉽고 후회되기도 하지만 초반인 만큼 회고록을 작성하여 돌아보고 남은 시간을 효율적으로 보내기 위한 계획을 세워보겠습니다.

목차

1) 수업 2) 책 3) 유튜브 4) 경진대회 참여 5) PT 스터디

I. 수업에 관하여

지금까지 파이썬 프로그래밍 언어를 배우고, 머신러닝 및 딥러닝 분야로 나아가고 있습니다. 각 분야에 대해서는 다소 짧고 빠른 배움의 시간이지만, 그럼에도 나아가고 있습니다.

수업에서 저희는 완성된 코드를 받아 이해하고 조금씩 더 나은 모델로, 내가 원하는 기능을 추가하고 수정해갑니다. 이미 돌아가는 모델을 받았기에 바로 결과를 볼 수 있고, 보다 결과를 높이기 위한 방법들을 시도하며 trial & error를 통해 배워가고 있습니다.

다만 이미 있는 코드를 수정하는 것이다보니, 그 이미 있는 코드를 짠 사람의 의도와 목적을 이해하는 것도 하나의 일입니다. 강사님께서 이 어려움을 아시고 수업 시간에

_ "하나하나 꼭꼭 씹어먹도록" _도와주셔서, 큰 어려움은 없습니다.

[엔지니어링 트랙 커리큘럼]

이 과정에서 9개 중에 벌써 3개를 다룬 것입니다. 앞으로 어느 분야로 나가게 될지는 모르겠지만, 뭐든지 할 수 있는 사람이 도움이 되는 세상. 국한되게 공부하지 않아야 한다고 되뇌입니다.

II. 책에 관하여

[혼자 공부하는 머신러닝 + 딥러닝]

플레이데이터로부터 지원받은 책입니다. 이 책이 어린 친구들도 이해하기 쉽게 잘 되어 있는 것 같습니다. 본질적인 앎을 돕는 느낌이라, 여러 번 가볍게 읽어야겠다고 생각하고 있습니다. 전체 500여 페이지 중, 350페이지를 읽었습니다. 머신러닝과 딥러닝 부분으로 나뉘어 있는데, 딥러닝을 수업 시간에 배우면서 함께 읽어 시너지 효과를 내도록 해야겠습니다.

비즈니스를 위한 데이터과학 비즈니스 애널리틱스 with Python + Tensorflow

이 책은 제가 들었던 교수님이 쓰신 책인데, 완전히 이해하지는 못해서 집에 짱박혀 있습니다. 이제는 코드를 이해할 수 있는! 조금은 대단해진 저로서 ㅋ 이 책도 씹어먹어 보겠습니다.

III. 유튜브에 관하여

아직 시작은 못했지만, 강사님과 동기분들께서 추천해주신 유튜버들이 있습니다. 시간이 뜰 때 보면, 실제 실무자들의 코드 구현 방식을 배울 수 있어 좋겠습니다.

IV. 경진대회에 관하여

저희 반 자체 경진대회가 열렸었고, 이 경진대회를 준비하며 머신러닝에 큰 재미가 붙었습니다. '돌아가면 됐지!'라는 생각에서, 다른 사람들이랑 비교하며 예측 스코어를 올리려고 하고, 외부에서 도구를 끌어다쓰고 쓰기 위해서 또 배우고... 더 좋은 모델을 공유하고... 선순환이 일어나는 걸 느꼈습니다.

이제 수업에서는 떠나보낸 머신러닝이지만, 그 감을 잃지 않기 위해 다양한 경진대회에 출전하고, 끝난 대회이더라도 데이터를 받아 뒤에 나올 '스터디'에서 함께 분석하며 데이터 분석가로서의 기틀을 다지고자 합니다. (결국 저의 목적은 데이터 분석가이기 때문이죠.)

주말에 준비하여 위 경진대회에도 나가볼 예정입니다.

V. PT 스터디

일주일 전부터 민철님과 민환님과 함께 PT 스터디를 하고 있습니다.

(https://velog.io/@yous_rchive/%ED%94%8C%EB%A0%88%EC%9D%B4%EB%8D%B0%EC%9D%B4%ED%84%B0-%EB%8D%B0%EC%9D%B4%ED%84%B0-%EC%97%94%EC%A7%80%EB%8B%88%EC%96%B4%EB%A7%81-28%EA%B8%B0-%EC%8A%A4%ED%84%B0%EB%94%94-%EC%9A%94%EC%95%BD 여기서 project_1 결과물/느낀점을 볼 수 있습니다.)

▲ project_1 발표 후 느낀 점

같은 데이터셋에서 다른 면에 집중하고, 서로 좋은 점과 부족한 점을 잘 파악해주는 느낌이라 좋았습니다. 다만 앞으로 '좋은 인사이트다!'만 내고 넘어가는 게 아니라, 데이터 분석 및 시각화에 대한 오류도 지적해보고 함께 생각하는 시간을 가지면 좋겠습니다.

사실 저렇게 그래프화하면 멋져보이지만, 제 코드도 근거 없이 짜여진 게 많거든요. 예를 들어, 다른 것들은 EA 단위지만 가스가 L 단위라 엄청난 이상치가 나와서(10000이 넘어가기도 함ㅋ) SALES_VALUES를 QUANTITY로 나누면 가스를 포함할 때에 값이 작아질 수밖에 없는데, 그걸 그대로 갖다 썼거든요.

1달을 열심히 보낸 나 ~~

원래는 '왜 이 코드가 필요하지?'라는 질문에 답을 찾지 못하던 나에게, 이 강의는 그 질문에 대한 이해를 주었습니다. 코드가 왜 필요한지, 어떻게 작동하는지를 파악하면서, 이제는 프로그래밍을 더 깊이 이해하고 있어 보입니다.

모든 사람들이 열심히 노력하는 것을 보며, 가끔은 성실하지 못한 순간이 있더라도 나 역시 조금은 덜 성실하지만 어찌저찌 따라가며 발전하고 있습니다. 중요한 것은 포기하지 않고 계속 학습하고 발전하려는 의지인 듯 싶습니다.

앞으로는 더 나아가기 위한 각오를 다지고 싶네요. 데이터 엔지니어링 분야에서 나 자신을 더 발전시키며, 데이터 처리와 분석에 더욱 전념하고 싶습니다. 어려움을 극복하며 끈기 있게 학습하고 발전하는 나 자신을 믿고, 미래에는 높은 성과를 이루겠다는 다짐을 쓰고자 합니다.

앞으로도 전 날에 5시간 이상 자고 비콘 잘 찍고 출석 열심히 하고 도시락 잘 싸서 다니고 수업 잘 듣고 화이팅 하자구만요.

9월 말부터 3월 말까지 약 6개월, 120일 동안 PLAYDATA에서 데이터 엔지니어링 수업을 듣는 중입니다 (｡･∀･)ﾉﾞ

어느새 10월의 마지막 날이 되었네요! 여기에서도 1달이 조금 넘게 지났다는 이야기겠네요. 쌀쌀하고 아름다운 11월입니다.

이제는 사뭇 익숙해진 나머지 비콘 출첵!도 아주 잘 하고 있고 💨 (사실 맨날 까먹어서 새 짝이 알려줌)

도시락도 잘 싸서 다니고 있습니당 🤍🎈

I. 일주일동안 한 일

1) 수업

요즘은 머신러닝을 정리하고, 딥러닝을 배우고 있습니다.

딥러닝은 Pytorch를 이용하기 때문에 새로 배워야 할 코드 작성법이 많아 당황스러운 최근입니다.

아래는 공부를 위해 적어둔 VELOG를 회고록체에 맞춰 좀 변형한 ..^^ 버전.

인공 신경망은 생물학적 뉴런의 학습 방식을 본받아 만든 네트워크로, w(가중치)와 b(편향) 값을 반영하여 input을 활성함수에 맞게 학습하게 됩니다. 인간의 뇌도 사람마다 같은 자극을 다르게 받아들이고, 또 같은 사람이라도 다른 자극을 다르게 받아들이죠?

텐서플로는 구글이 만든 딥러닝 라이브러리로, cpu와 gpu를 사용해 인공 신경망 모델을 효율적으로 훈련하며 도구를 제공하고 있습니다.

그렇기 때문에 이렇게 항상 지정해주고는 합니다.

객체(클래스)를 정의하여 디바이스에 적용합니다.

객체에는 여러 모델이 있는데, CNN 모델은 아래와 같습니다.

그래서 정의된 CNNModelV1에 은닉층과 결과값 출력 상태를 결정한 이후 객체에 담습니다.

그리고 위에 block_1, block_2, classifier에 해당하는 애들도 정의합니다.

아래의 evaluation은 머신러닝과 비슷하네요.

내용이 궁금해서 회고록을 보는 건 아니시죠?

무튼 이런 딥러닝에 대해서 배우고 있는 요즘입니다.

2) companion

어제, 같은 반 동기 두 분과 함께 새 데이터 EDA를 진행해보았습니다.

[코드와 Visualization] https://velog.io/@yous_rchive/%ED%94%8C%EB%A0%88%EC%9D%B4%EB%8D%B0%EC%9D%B4%ED%84%B0-%EB%8D%B0%EC%9D%B4%ED%84%B0-%EC%97%94%EC%A7%80%EB%8B%88%EC%96%B4%EB%A7%81-28%EA%B8%B0-4%EC%A3%BC%EC%B0%A8-%EC%A3%BC%EB%A7%90

[Presented Insight] https://velog.io/@yous_rchive/%ED%94%8C%EB%A0%88%EC%9D%B4%EB%8D%B0%EC%9D%B4%ED%84%B0-%EB%8D%B0%EC%9D%B4%ED%84%B0-%EC%97%94%EC%A7%80%EB%8B%88%EC%96%B4%EB%A7%81-28%EA%B8%B0-%EC%8A%A4%ED%84%B0%EB%94%94-%EC%9A%94%EC%95%BD

이전 벨로그에 세부 진행 상황이랑 느낀 점이 있습니다 ㅎ.

머신러닝에 문외한이었을 때 꼭 풀고 싶었던 과제를 동기분들과 함께 해석하기로 했었고, 각자 준비하여 어제 PT를 진행했었습니다.

아래는 PT에 쓴 자료입니다:

*II. 좋았던 점 *

1) 수업 수업시간에 강사님께서 한 줄 한 줄 해석해주시는 것. 사실 요즘 코드는 GPT가 다 짜주기 때문에, 다른 사람과 협업할 때 무슨 용도로 이 코드를 짰는지 분석하고, 내 의도대로 짜졌는지를 확인하는 용도만 알면 된다고 생각해요.

손 놓고 있어야 한다는 건 아니지만, 오류가 안 나게 다 써내려가야 한다는 강박을 가질 필요 없이, 인간이라면 본질을 기억하는게 중요하다고 생각합니다.

강사님께서도 그렇다는 걸 강조하시고, 그 방향으로 수업을 진행해주시는 것 같아서 좋습니다.

2) 스터디 동기 두 분과 함께 머신러닝 스터디를 진행하며, PPT를 만들어 진행하니 준비 시간은 따로 걸리지만 전달 능력도 높아지고 따로 기록이 생겨서 너무 좋았던 것 같아요.

3) 공부 방법 새 짝이 딥러닝 코드 해석 법으로 뒤에서부터 읽기-를 추천해주었습니다. 그럼 왜 [이 변수]가 필요한지를 알 수 있고(결국 어떤 용도로 쓰이는지를 먼저 알 수 있으니), 이게 언제 정의되어야 하는지를 볼 수 있으니까요. 정말 획기적인 방법인 것 같습니다.

4) 나 요즘 빨리 자고 잘 안 좁니다. 아주 칭찬하는 바입니다.

III. 아쉬웠던 점

1) 나 스스로에게 아쉬운 점은 선택과 집중에서 오류를 범하고 있다는 점입니다. 머신러닝의 여운을 아직 버리지 못해 수업시간에 집중을 못 하고 있습니다. 그런데 학원에 다니며 좋은 퀄리티의 강의를 받는데, 그 앞에서 나중에 혼자라도 할 수 있는 것에 목을 매는 게 조금은 바보스럽다는 것을 잊지 않았으면 싶습니다.

2) 수업 딥러닝 수업에 대해서 아쉬운 점은, 어려운 것도 어려운 거지만, 저번에는 경진대회라는 목표가 있어서 더 열심히 배우려는 각오가 있었다면, 그리고 해가면서 되려 알게 되는 게 있었다면, 지금 배우는 딥러닝은 그렇지 못해 아쉬운 점도 있습니다.

IV. (내가) 개선할 점

[1] '딥러닝이 나랑은 거리가 멀다'고 생각하고, 자꾸 머신러닝에만 갇혀 있는 것 같습니다. 수업 중에는 수업에 따라갈 수 있도록 노력할 것.

[2] 또 수업 외에 유튜브, 책을 참고해서 내 것으로 만들기.

[3] 내가 모르는 게 나오면 '어차피 안 쓸거다'고 생각하며 넘기지 말고 아득바득 알아내고 넘어가기. 지금 모르는 게 있으면 뒤에서 언젠가 막히니까 꼭 내 것으로 만들기.

[4] 이왕 하는 거 제대로 하기.

V. 다음주 계획

1. 딥러닝 / 머신러닝 책 다 읽기

'혼자 공부하는 머신러닝 + 딥러닝' 이라는 책이 굉장히 도움이 많이 되더라구요. 강사님께 배운 단어들이 머릿 속에 떠돌고 있었다면 그걸 꽉 잡아 눌러주는 느낌이었습니다. 코드를 구현할 때 '이걸 왜 써야하는지'를 이해하고 있어야 지속 가능한 배움이라고 생각을 하는데, 책에서는 원래 기본적인 모델에서, 하나 하나 변경하고 추가해가며 더 좋아지는 모습을 보여주니 직관적으로 다가와 좋았습니다.

그렇다고 강의를 소홀히 할 순 없으니, 월수금 저녁에 남고 주말을 써가며 공부해야겠습니다.

2. 국민대 AI빅데이터 분석 경진대회

요즘 저희 반 동기분들이 관심이 많은 경진대회인데요. 저는 상금, 우승보다는 성장해가는 모습이 담긴 포트폴리오를 만드는 게 목적이라 잘 되지 않더라도 참여하고, 결과와 공부 과정에서 새로 알게 된 점들을 기록으로 남기도록 하겠습니다.

3. 남아서 공부하며 하루 배웠던 내용 정리하기

4. 쫄지 않기.

금방 또 다음 회고로 돌아오겠습니다 ~ (｡･∀･)ﾉﾞ

아래는 내 발표 자료(3시간 만에 만듦):

킹받게 지우지 않은 'MIRIWORKS COMPANY' ^^

목표와 찾고 싶은 자료가 정해져 있었기에 빨리 수월히 마무리할 수 있던 프로젝트였다. 다만, 중간에 불필요한 자료를 DROP하거나 합치는 과정에서 여러 데이터프레임을 사용하며, 중복되어 비효율적인 업무를 많이 한다거나 나중에 필요할 자료를 DROP시켜 또 다시 프레임을 카피해야 하는 일이 생겼었다. 보다 계획적이게 설계를 해야 할 것 같았다.

또, 이번엔 'KIOSK-GAS'라는 자료가 QUANTITY 세리는 데 있어서 단위가 달랐다. 1EA가 아니라 1L 단위라 다른 것보다 QUANTITY가 훨씬 컸다. 그럼 이걸 SCALING을 미리 해 두고 생각하는 건 어땠을까? 싶은 ... 혹은 아예 DROP 하는 것도 괜찮았을 것 같다.

이런 면에서 민철님처럼 엑셀을 훑어보면서 이상한 값들을 미리 찾아내면 이렇게 다 끝내고 나서 나처럼 무너지는 일이 없을 것 같다.

민환님의 발표를 듣고 나서는, 데이터만을 사용하기보다 해당 시대, 나라, 문화의 맥락을 발표와 함께 이용하면 좋을 것 같다고 생각했다.

어제 셋 다 느꼈지만 같은 자료에서도 주안점이 달랐다. 1달 넘게 봐 오면서도 각자 잘 하는 점이 다르다는 걸 느껴왔어서 좋은 영향을 줄 수 있을 것 같다! (내가 아직 부족해서 많이 노력해야겠지만) 앞으로 1달에 두번씩 이런 발표 과제를 우리끼리 하기로 했다. 1번은 각자 데이터, 다른 1번은 공통 데이터를 갖고 분석해서 PT 형식으로 발표 예정이다. (꼭 마지막까지 ^^) 추후 다른 분들도 함께 할 수 있길 ~~

내가 생각하던 데이터 애널리스트의 역할이 여기서 다 끝나버린 것 같아 지금 수업 듣는 딥러닝이 들어오지가 않는다.... 아직 딥러닝을 배우지 않고도 머신러닝이 더 맞는다고 생각하는 나의 안일함. 제대로 해보지도 않았는데 어떻게 안 맞다는 걸 아느냐고 일단 꾸역꾸역 해 봐야겠당. 꿑.

INTRO

이번 주말! 공부한다고 얘기하고 저번 4주차 회고록을 마무리했었는데 아주 멋지게도 주말에 공부를 이어가고 있는 거 있죠 ㅎㅎ. 자랑할 겸, 다른 데이터셋을 맞이하는 저의 오늘 일과를 소개하도록 하겠습니다.

저는 올해 초, 학교 데이터 분석 학회에 지원해서 서류합격 후 사전과제를 받았었는데요, 물론 관련 수업을 들었었지만 이해하지 못했던 터라 결국 사전과제를 해결하지 못하고 면접 전 '꼭 더 성장해서 다시 지원하겠다'며 끝을 흐렸던 적이 있어요.

다른 중요한 활동 지원이 겹쳤기도 했었지만, 이 사전과제에 발을 딛는 것조차 못하는데 앞으로 학회 생활을 하더라도 잘 해낼 수 있을까 의구심이 들었습니다. 가서 배우면 되지 않냐! 하셔도, 잘 모르는 상태에서 갔다가 자존감만 낮아질 것 같기도 했네요. 그 학회는 대회에 나가는 게 목적이었지, 양성이 목적이 아니었으니까요.

나중에 분석을 공부하고나면 꼭 이 데이터 분석을 해 보고 싶었는데 이제 그럴 때가 된 것 같아서 반 년 동안 묵혀둔 파일을 열었습니다.

과제는 EDA를 통한 인사이트가 전부였어요.

과제 소개

'TITANIC'과 차이점이 있는 데이터셋이었어요.

#목적 SURVIVED == 0, 1로 나누어져 예측을 하거나 MODEL을 개발하는게 아니었습니다. 분류, 예측모델이 아니라 정말 EDA, insight 확보만을 위한 데이터셋이었어요.

구매한 사람들만을 대상으로 'BASKET_ID', 'EVENT_DATE', 'TRANS_TIME', 'STORE_ID', 'PRODUCT_ID','QUANTITY', 'RETAIL_DISC', 'COUPON_DISC', 'COUPON_MATCH_DISC', 'SALES_VALUE', 'product_price_per_unit', 'HOUSEHOLD_KEY', 'AGE', 'INCOME', 'HH_COMP', 'HOUSEHOLD_SIZE', 'KID_CATEGORY', 'DEPARTMENT', 'COMMODITY'라는 COLUMN들을 비교했습니다.

#답하고자 하는 질문을 직접 만들어야 함

우선 칼럼이 되게 많았어요. 목표에 따라 어떤 칼럼을 사용할지, 어떤 칼럼의 값으로 groupby 할 것인지 등 전체 설계가 되기 때문에 미리 구상을 할 필요가 있었습니다. 저는 참을성이 없는 편이라 얼른 결과를 보고 싶어서 이 시간이 지루하게만 느껴졌어요.

#모든 COLUMN이 동일선상에 있지 않음 사실 titanic 문제는 feature, target이 명확히 정해져있었기 때문에 feature들이 함께 survived 예측이라는 하나의 공통 목표를 공유했었죠. 그런데 위에서 언급한 바처럼 답하고자 하는 질문이 여러 개 만들어지다보니 문제마다 필요한 feature이 따로 있었습니다.

#date 데이터 사용 강사님께서 titanic 데이터에 없다고 아쉬워하셨던 시간 개념 데이터가 있었습니다.

#구간화된 데이터 AGE, INCOME 등 몇 칼럼들이 구간화되어 있었습니다.

본격! 데이터 분석

무결성 확인

먼저, TITANIC의 PASSENGER_ID는 무결성 확인을 위해 사용했었는데, 여기 BASKET_ID는 충분히 동일 인물이 중복구매할 수 있다는 점을 고려해야겠어요. 그래서 DROP하지 않고 다음 절차로 이동했습니다.

데이터 확인

전체 칼럼명들과 결측치들을 확인해주었습니다. AGE, INCOME, HH_COMP, HOUSEHOLD_SIZE, KID_CATEGORY 등, 구매와 관련되기보다 회원정보와 관련된 내용들은 공통 ROW에서 결측치가 발생해 있었습니다. 전체 37만개 데이터 중 16만개정도이니, 1/2 좀 안되는 정도가 결측치로 있었던 것입니다. 이 결측치를 어떻게 사용할 것인지는 각 질문에 따라 다르겠지만, 예측, 분류모델도 아니고 FACT를 기반으로 분류하는 것이 맞기에 따로 결측치를 채워주지 않았습니다.

EDA

EVENT DATE

먼저, EVENT를 며칠동안 유지하는 게 좋을지에 대한 고민입니다. 저는 이벤트 데이트가 이렇게 길 줄 몰랐는데, 1일부터 91일까지도 있더라구요. QUANTITY를 기준으로 그래프를 그려줘봤습니다.

지금 봐서는 0~20일 중간에 솟은 타이밍을 이용하는 것이 좋아보이지만, 이벤트를 며칠동안 유지할지 추천할 목적으로 사용하는 건 PREVIOUS DATE의 값들도 ACCUMULATED 되는 그래프가 더 좋을 것 같다고 생각했습니다.

그려보았는데, 이 20과 30 사이에 솟아있는 구간이 기존 증가량보다 높으면서, 그때를 기점으로 해서 증가량이 낮은 지점이 있더라구요. 이 부분을 표현할 수 있는 방법으로 미분을 고려했습니다. 가장 큰 미분값(즉, 기울기)을 갖는 index를 찾고, 그 미분값을 출력하는 기울기를 표시했습니다.

미리 정해둔 'accumulated_quantity' 변수에 .diff를 해서, idxmax()로 max인 index를 찾아줬지요. 그리고 그 index인 값의 diff 값을 출력했습니다. 그런데 아쉬웠던 점이, 딱 해당 시점의 기울기가 높다고 event를 6n일 동안 끌어야 하나? 직전 y값이 낮았다는 이유로도 slope 자체는 높은 거잖아요. 그럼 그건 이상적인 DATE를 알고자 하는 목적과 멀어지니까, 다른 방법을 생각해봤습니다.

현실도 고려해서, 절대적인 Y값 또한 고려해야겠다고 생각해서 사용한 방법이, (y value / event_date)를 동시에 이용하는 방법입니다.

누적 평균값을 구하고, 누적 평균값 자체가 유의하게 높아지는 곳을 찾아본 것이죠. accumulated_quantity_per_date라는 변수를 이때까지 y의 평균으로 정해주면서, accumulated quantity_per_date 자체를 증가시키는 지점을 찾아주기 위해서 미분을 계산했습니다. 아까 그래프에서 보였던 그 위치와 유사해보이는 27일이 인덱스 답으로 나왔습니다.

만약 계속 기울기인 미분값만 찾고 있었다면 제가 원하는 값이 나오지 않았을 겁니다. SLOPE가 높은 값들이 후반부에 있더라구요. 27일 부근은 SALES_VALUE가 지속적으로 증가하고 있어왔으므로 후반부와 달리 단기 증가율은 크지 않아서로 보입니다.

비슷한 맥락에서 EVENT_DATE를 계산하기 위하여 QUANTITY가 아닌 SALES_VALUE도 계산해보았는데요,

accumulated_SALES_VALUE는 QUANTITY와 비슷한 그래프를 보이네요.

EVENT COMMODITY

저는 올리브영에서 아르바이트를 하며, 한번에 모든 제품들을 동시에 할인하는 게 아니라 3달 정도 로테이션이 돌아가도록 한 상품에 세일과 비세일을 섞는 것이 영리하다고 생각했습니다. 사실 다들 할인이라고 해서 가서 구매하는거라 자기가 사는 상품들이 세일 들어가는지 아닌지 모르는 경우도 많은데, 아닌 경우도 많거든요. 그래서 그렇게 세일인 줄 알고 비세일인 상품 구매하면 좋은거죠. 섞어놔야 하는 이유입니다.

그럼 어떤 상품이 할인할 때 가치를 느끼는지를 계산해보았습니다.

RETAIL STORE

어떤 가게에 납품할 것인지도, 그 수량도 중요하겠죠. nunique() 함수를 통해서 STORE_ID 값 개수를 세려보니 236, 총 236개의 소매업체에 납품하고 있는 것 같습니다. 혹시 줄이는 것이 좋을까?싶어 구매 빈도수가 높은 STORE_ID와 낮은 STORE_ID들을 찍어보았습니다.

그래서 가장 구매 빈도수가 높은 STORE_ID를 검색해봤습니다. (QUANTITY, SALES 기준 X, INDEX 기준)

되게 큰 편차를 보이는 것을 알 수 있습니다. 여기서 어떤 건의를 할 수 있을까요?

1) 버리기 굳이 10개 미만 판매하는 RETAIL STORE과의 관계를 유지해야하나 ...

2) 높은 STORE들과 FEATURE 차이를 제시하기 SALES_VALUE, RETAIL_DISC, COUPON_DISC, COUPON_MATCH_DISC 값을 비교하였는데, 상위 가게들이 하위 가게들보다 할인이 많이 적용되었다는 걸 확인할 수 있죠. 할인이 가게 인기의

또 궁금해지는 건 그 RETAIL STORE이 어떤 상품을 주로 파는지입니다. 특히 top 5 store들이 주로 판매하는 제품군을 확인하니, grocery, drug gm, meat, produce, kiosk-gas, meat-pckgd 6개가 올라와있었습니다. KIOSK-GAS가 무엇인지 검색했는데 나오지 않고, 그럼 'commodity'에 해당하는 values들을 찾아보니 COUPON/MISC ITEMS가 속해있었습니다. 로또 등이 아닌가 싶네요...!

여기서 상위 5개, 하위 5개 가게들의 인기 상품군들을 보면 확실히 다름을 알 수 있습니다. 판매 주력 상품군을 추가하거나 수정하는 것도 함께 건의할 수 있겠습니다.

customer analysis

가구마다 가구 대표 나이대가 있었어요. 이에 따른 Sales_Value를 구해보았습니다.

먼저, 가구대표 나이 구간을 X값으로, SALES_VALUE를 Y로 한 그래프입니다. 45-54의 가구대표 주문자가 가장 많았습니다.

자주 구매하는 PRODUCT_ID와 COMMODITY(소분류)도 함께 구해보았습니다.

SALES가 나오면 QUANTITY도 같이 나와야겠죠.

사실은 QUANTITY보다 SALES/QUANTITY를 나눈 값이 더 유의미합니다. 제품 당 가격이 높은 것에 개의치 않는 정도를 나타낼 수도 있으니까요. 다르게 얘기하면, 여기서 막대그래프가 낮은 축에 속할수록 낮은 가격에 더 현혹된다고 볼 수 있겠습니다.

다음은 SALES_VALUE, 총 매출을 HOUSEHOLD_SIZE에 대해서 나누어보았습니다. 이는 4인 가구 구매를 45-54세가 맡았을 때 모든 매출이 그 쪽으로 카운트되는 오류를 수정하려는 시도였습니다. 1인 당 지출을 AGE별로 구분한 그래프로 볼 수 있을 것 같습니다. 45-54세로 나왔던 전과 다르게, 25-34세가 매출에 기여를 많이 하고 있었네요.

ADVERTISING HOUR

시간 데이터를 다루어보았는데, 함수를 사용하면 크게 특별할 건 아니었네요. SALES_VALUE를 기준으로 사람들이 많이 구매하는 시간과 각 시간대별(HOUR 기준) MAX QUANTITY, PRODUCT_ID, DEPARTMENT, STORE_ID를 조사해봤습니다.

확실히 5시~6시 반 경에 구매율이 높은 것을 확인할 수 있었습니다.

31782 STORE에서 새벽대에 구매율이 높다는 것도 특이해고, 31862 STORE에서는 DAYTIME에 높았네요.

추가 목표

또한 AGE별로 TRANS_TIME을 계산하는 것도 좋아보입니다. 더 하고 싶은 EDA들이 많지만, 10/23 분석은 이 정도로 마치도록 하겠습니당.

intro

안녕하세용 유정입니다 (｡･∀･)ﾉﾞ

오늘은 자체 경진대회를 마무리하며 느낀 소감을, 제 경진대회 제출 레포트와 함께 정리해보도록 하겠습니다!

경진대회 리뷰

저번 회고록에서 언급했듯, 저희 반은 이번주까지 강사님께서 만드신 자체 경진대회를 준비하고 있어요. 그리고 오늘(금요일), 딱 제출을 하고 Private Score가 떴답니다.

리더보드 12등 / 28등 !! 다만 등수는 중요하지 않아요 ..🐱‍👓🐱‍🐉 저도 처음에 '반 이상만 하자!' 싶었는데 그렇게 상대적으로 '이정도만 하면 되겠지' 생각하는 저 자신이 좋지는 않아서 '1등과 2점 차이나자!'라는 걸 목표로 정했습니다. 나름 괜찮은 goal setting법 아닌가요?

결과적으로 1등인 분이 91.8%로, 90.01%인 저와 아슬아슬하게 2%p 차이가 안 났습니다! 마지막에 cross validation도 하고, hyper parameter도 조절했기 때문에 극적인 차이가 있을 줄 알았는데 그러지는 못해 아쉽네요.

그럼 코드랑 분석 좀 들어가보고, 본격 4주차 느낀점을 정리하겠습니다.

경진대회 개요

▲ 이름 이렇게 저장하면 안되지요 ^^

저희는 수정된 'titanic' dataset으로, 'survived' 분류모델을 제작하였습니다.

과정은 다음과 같았습니다.

1 EDA 데이터 간의 관계를 시각화, 통계화 등 기법을 통해 유의미한 가치를 발견하는 EDA 작업

2 Data Cleansing 필요하지 않은 데이터를 없애거나 뒤이은 작업들을 불가능하게 만드는 결측값(Nan, Null 값)을 제거하는 Data Cleansing

3 Feature Extraction 유의미하다고 생각되는 요인을 지정하거나 무의미하다고 생각될 요인들을 함께 묶어 하나의 특성으로 생성해내는 feature extraction

4 Encoding 또 features 중 수로 표현되지 않거나, 수로 표현되더라도 순서, 지정, 이름, index의 느낌이 강한 경우에는 encoding을 통해 feature을 정제하고

5 Scaling 진정 int/float 수의 개념인 feature는, 같은 수가 단위 또는 평균에 따라 다르게 느껴질 필요가 있기에 scaling 작업에 들어갑니다.

6 Training 모델을 train 시키는 과정에서 model의 선정, model의 accuracy를 높이는 hyperparameter 결정, hyperparameter도 컴퓨터에게 시켜 가장 이상적인 값을 찾으라고 지시하는 과정,

7 Evaluation 잇따른 모델과 피쳐의 평가까지

거치며, 하나의 모델이 완성됩니다. 그리고 저는 그런 모델들을, 이때까지 10개 이상 만들어냈어요. 저의 경우 주요한 차이점은,

• null replacement
• feature extraction
• ensemble model
• parameter model

에서 나왔습니다.

encoding과 scaling 방식은 다 동일했어요. 그 이유 또한 같이 말씀드리겠습니다.

presentation

1. EDA (ETA 아님)

저는 pivot table보다 그래프를 보는 게 익숙한 사람이라, 인사이트도 그래프를 통해 많이 얻을 수 있었습니다. 그 중, 유의미했던 코드와 그래프는 다음과 같았어요.

1) 'has_cabin'

fare이 survived와 관련이 깊은 feature이라는 걸 알고 있는 상황에서 null 값이 꽤 있던 cabin을, lambda 함수를 사용해서 값이 있는 그룹과 없는 그룹으로만 분할해 보았는데, fare과 유의미하게 관련이 있어 기억해뒀습니다. 추후, 'has_cabin'이라는 컬럼으로 새로 정의해 하나의 feature로 사용하게 됩니다.

2) cabin letter 한편, cabin_letter는 영어 한 스펠링에 숫자 조합으로 이루어져 있는데요, (ex. B029) 영어끼리의 공통점이 있을지를 분석해보았는데, 큰 연관성은 얻을 수 없었습니다. fare과도 그렇지만, cabin letter는 다른 feature들과의 연관성도 찾기 어려웠어요. 그래서 아예 drop하고, 'has_cabin'만 남겨두기로 결정했죠.

3) family size

survived ratio를 살펴 보았는데요, family size의 크기와 survival ratio 간의 관계가 있어 보였지만, 그게 일관적으로 증가하거나 감소하는 모양새를 보이고 있지는 않았기에 groupby를 시도했습니다.

family = sibsp + parch 로 규정하고, family 구성원의 수 0~3까지를 'low_family'로, 4 이상을 'high_family'로 정의하여 새 컬럼을 만들었어요. (마찬가지로 lambda 함수를 사용했습니다)

4) age와 survived

다른 급우분들께서는 age를 5, 10 단위로 쪼개서 groupby하시거나, 아예 drop 하시기도 했는데, 저는 age와 survived의 관계에서 정규분포의 모양을 보았기 때문에 따로 가르지 않고 함께 사용했었습니다.

5) embarked, pclass

embarked 한 곳에 따라, pclass와 age로 분류해보았는데요. 물론 S, C, Q 각각 사람 분포 정도가 다르기는 하지만 pclass 별 인구 분포도 자체가 의미가 있어 보였습니다.

2. train_test_split

우리의 target은 ['survived'] 입니다. ori_train dataframe에 담겨 있던 데이터들을 y축에 평행되게 분리하여, 'survived'를 제외하고는 X, 그리고 survived만을 y에 담았습니다. 또, 그 중에서도 학습을 위한 train data와, 검증을 위한 test data를 분리하였습니다. 총 4개의 X_tr, X_te, y_tr, y_te를 생성할 수 있었습니다.

[코드 확대] X_tr, X_te, y_tr, y_te = train_test_split(X, y, test_size=0.3, stratify=ori_train['survived'], random_state=args.random_state) #train data 0.7 / test data 0.3, #random split

특히 stratify는 ['survived'] == 0 혹은 1인 값이 train에 몰려있으면 정확한 학습이 되지 않기 때문에, target 값을 기준으로 고르게 분배되도록 설정하기 위함입니다.

따라서 stratify를 사용하면 overfitting을 막을 수 있습니다.

3. Data Cleansing

• age
• fare
• embarked

에 null 값이 있었어요.

*** age - mean, std 고려해서 정규분포 만든 후, random 값 도출

• fare - pclass가 같은 사람들의 fare 값에서 mean 값 도출
• embarked - 각 그룹의 fare 평균을 계산하여, 결측치의 fare 값에서 가장 가까운 평균값을 찾아 그 embarked 값으로 대체**

embarked 값이 유의미하게 쓰이지 않았지만, null 값이 많았던 만큼 보다 이성적인 이유가 있었다면 좋았을 것 같다는 아쉬움이 있습니다. embarked의 S, C, Q fare이 다른 table을 봤지만, mean만 차이나는 거였지 visualization을 해보니, 이상치나 표본 부족의 문제 때문에 편향되었습니다.

만약 지금 embarked를 고친다면, 어떻게 고칠 수 있을지 고민이 됩니다. mode로 하지 않을까 싶습니다.

4. Feature Extraction

결국 저는 마지막에 'pclass', 'gender', 'age', 'fare', 'embarked', 'has_cabin', 'new_family'로 마무리했습니다.

이때까지 pclass와 embarked를 엮어 p_embarked도 만들어봤었고, name에서 두번째 title(Mr. Miss. 등)을 이용해서 designation dictionary도 만들었었고, age // 5, age를 5살씩 끊어서 만들어봤었고, pclass, gender를 엮어 p_g도 만들어보는 등 새로운 feature 형성을 많이 했었지만, 결국 중복되는 내용이 되어 인위적인 가중치가 너무 들어가, 결국 cabin 대신에 has_cabin, sibsp, parch 대신에 new_family처럼 drop한 column들을 엮거나 그 속에서 의미를 찾아 분류하는 것이 가장 옳다고 생각했습니다. 그 결과 정확도도 높게 나왔구요.

역시 튜닝의 끝은 순정 😎

4. encoding

수치로 표현되는 값 중에서도 ordinal number가 있습니다. 예컨대 pclass가 해당될 수 있겠는데요. 그런 값들에 scaling을 줄지, encoding을 줄지 구분이 필요합니다.

encoding이 하나의 column을 values의 수(n)만큼 나누어 결국 이진으로 이루어진 n개의 column을 만드는 것이기 때문에 비효율적이고, 만약 gender랑 같이 True와 False가 비슷한 수치로 떨어지는 feature이 아니라 Mr.라고 불리는 사람인지 아닌지처럼 균등하지 않은 feature이라면, 없는 것이 낫다고 생각했습니다. 그런 이유로 encoding 과정을 고려하면서 아예 drop된 column들이 많았습니다. 해보지 않은 것에 대해 후회하지는 않습니다.

인코딩은 OneHotEncoder로 진행하였습니다. chat gpt는 레이블 인코딩, 카테고리컬 인코딩도 함께 추천하였는데 다른 인코더도 사용해보면 어떨까 싶었습니다. 아직 원리와 용도를 알지 못해서 이번 주말에 공부해야 할 것 같습니다.

결국 위 모양으로 인코딩이 되었고, 남은 age, fare는 스케일링하도록 하겠습니다.

5. Scaling

age와 fare가 어느 정도 정규분포를 이루고 있었고, 이상치가 크지 않기 때문에 StandardScaler를 사용하였습니다. 그리고 scaled 된 데이터와 enc 데이터를 concat을 이용해 다시 같은 dataframe으로 모았습니다.

다만, Robust Scaler도 median을 사용하는 건데 저는 결측값 대체 때도 mean보다 median을 신뢰하는 터라 다음에 Robust Scaler도 사용해보고 싶습니다.

스케일링은 위처럼, x의 차이가 작고 편향되어 있는 집단에서 평균과 표준편차를 기준으로 value 값을 재정의하는 것을 의미합니다. 엄청난 결과적 차이가 있지는 않지만 저는 scaling 작업의 가치를 높게 사는 편입니다.

6. Training

이제 training model을 선정할 단계입니다. 결론적으로는 앙상블 모델 중 cat boost를 사용했습니다.

단일 분류 모델도 물론 있지만, 여러 개의 분류기를 생성해서 예측을 결합해 보다 정확한 예측을 도출하는 앙상블 모델을 사용하기로 했습니다.

decision tree classifier를 먼저 사용했다가 randomforestClassifier 사용한 이후로 점수가 급격히 올라갔고, 다른 model들끼리는 유의미한 차이를 보이지 않았지만 catboost가 그 중에서도 조금 더 test의 accuracy가 높았습니다.

다 training 정도가 높은 편이었고, 오히려 그 중에서 cat은 낮은 편이었습니다. 다만, train 정확도와 test 정확도 간의 차이가 거의 나지 않는 모델이었어서 overfitting 가능성이 낮아 골랐습니다.

stacking이 다른 모델들도 같이 고려하는 거라 제일 높을 줄 알았는데, cat boost 단일 모델이 제일 높아 의아했습니다.

이때 들어가는 변수는 제가 임의로 지정한 건데, 이것도 시간을 내서 Randomized Search CV 이용해 hyperparameter를 찾아봐야겠어요.

7. Evaluation

결국 이렇게 test의 auc가 90%인 모델이 나왔습니다.

히트맵을 만들었고, pred == 0이지만 실제값은 ==1인 데이터, 실제값 == 0, pred == 1인 데이터들을 추출해서 보려 했는데 제가 코딩을 중간에 이상하게 했는지, survived인데 float으로 나오고 이진으로 나오지 않더라구요. 이 이유도 여쭤봐야 할 것 같아요.

지금 다시 해 봤는데 결론이 다르게 나오네요 ?! Norway는 RandomForestClassifier를 사용했고, cat은 Norway에서 model만 cat으로 바꾼 거라 다른 것들은 다 똑같아요. 두개가 엎치락뒤치락 하고 있네요.

수고했다고 해 줫 !

그래서 이거 한 건 알겠는데! 배운 건 뭐냐고! 하신다면, 이게 모두 다 새로 배운 겁니다. 4번째주, 8일동안 배운 것들로 이걸 다 만든 거에요 ..ㅎㅎ

많이 많이 배웠죠?

오늘 강사님 옆에서 같이 점심을 먹었는데, 너무 똑같은 데이터셋으로 계속 하니 질린다-는 말이 나오자 실무에서는 더 오래 들여다보고 있어야 한다고 ㅋㅋㅋ. 아찔하지만, 계속 인내하고 슬로우-다운 할수록 끈기있어지는 것 같아요. 제가 끈기가 좀 없어서 그런 면에서도 인격적 성장 중...

아주 다이나믹했던 4주차

벌써 4주차가 마무리되어가고 있네요. 어제 어머니랑 통화하는데 "이번 학기가 네 인생에서 제일 힘든 시간인가보다" 말씀하셨어요.

너무 열심히, 잘 하시는 분들 옆에서 열정이 못 따라가서 힘들고, 집에 와서 녹초가 되어 쓰러지고 그러고 또 아침에 출근길 지하철에 떠밀리는 하루를 보내고 있지만 그럼에도 이곳에는 분명 자존감을 채워주는 순간들이 있고, 아니 아주 많고, 교실을 크게 조망하면 한숨이 나오다가도 어제 이해 안 되던 코드가 오늘 풀리고, 어제 별표 쳤던 부분이 오늘 '왜 내가 이걸 몰랐지?' 싶은 순간이 오면 소생해서 다시 콧노래를 부르고 있는 항상 재밌는 롤러코스터를 타고 있습니다.

애초에 누군가를 이겨야지, 잘나야지- 생각을 하면 조금 도태되었다 싶은 즉시 포기하게 되는 것 같아서, 꾸준히 걷는 것 자체를 한 순간의 건빵처럼 아주 미묘한 단맛을 느끼는 것을 목표로 잡고 보내고 있습니다. 다들 그러고 계시겠죠?

어쩌면 제가 비전공자이고, 취업이 급하지 않아서 더 그런 마인드를 가지고 있을 수도 있어요. 그래서 가끔 '난 그렇게 열심히 할 필요 없어'라는 악마의 유혹이 있지만 그렇게 살게 되면 나중에 그게 절실한 상태가 되었을 때 (즉 취업이 닥쳐왔을 때) 이제는 피할 수 없다는 생각에 더 좌절스럽더라구요. 그래서 할 수 있을 때 하려고 노력 중입니다. 마치 제 밀려버린 설거지처럼요...

최근 눈치를 챘는데, 제가 원래 잘 조는 사람이라기 보다는 이해가 안 될 때 포기하고 졸더라구요. 그래서 뭔가 졸리다! 싶으면, 아 내가 이해가 안 되는구나!라고 스스로를 이해하고 얼른 위를 올라가보거나 옆 동기분에게 물어보며 저를 다루는 법도 배워가고 있습니다.

피드백

1. 피쳐끼리의 유사도를 보고, 하나로 합쳐 대체하거나 혹은 하나의 삭제가 필요할 수 있다. 같은 의미를 가진 feature들을 중복 적용할수록 overfitting이 발생한다.

2. data cross-validation나 evaluation 등에서 y값이 필요할 때 '그' 인덱스를 정확히 정의하기 어려울 수 있다.

3. 명확히 설계하고, 이유를 갖고 성적을 받자.

4. log를 사용하여 한 쪽으로 몰려 있는 수치형 데이터를 완화할 수 있다. 사용해보자.

5. 지금 여러 모델을 배웠는데, 내게 유익한 모델만 공부해서 쓰고 있지만, 나중에 스스로 뭐가 좋은지 판단할 수 있으려면 더 많은 모델과 적용 상황을 알아야 한다. 이제는 바쁘지 않으니까 천천히 예시를 들며 공부하자.

6. .values, .columns, .info, type, .describe, .shape를 이용해서 data type, row x column, dataframe 모양새를 보는 것을 두려워하지 말자!

7. copy하여 사용할 때 그 의미를 알고, 변수를 정의할 때 그 변수가 어떤 데이터를 담고 있는지를 명확히 이해하고 넓게 보자.

이제 머신러닝은 수업에서 잘 다루지 않을테니까, 잊어버리기 전에 이번 주말 가기 전에 공부하자. 화이팅 유정 (๑•̀ㅂ•́)و✧

연휴가 끼었던 터라 벌써 주수로는 3주차가 되었네요! 이번 주차에서는 강사님께서 만드신 반 내 자체 대회에 참여하기 위해, 조금 각색이 된 데이터를 갖고 각자의 모델을 빌드업 해 보는 시간을 가졌습니다.

저번에 강사님께서 여기에 대회 많이 올라온다고, 참여 권장하셨는데, 마침 직접 이 홈페이지랑 채점 시스템에 적응할 수 있게 좋은 기회를 마련해 주셨어요. 그래서 여기 submission해서 최강자가 되는 것을 목표로, 단계를 차근차근 밟아갔지요!

(1) 내용 이번주에는 NUMPY, PANDAS에서 나아가 SEABORN, MATPLOTLIB 등 다양한 라이브러리를 이용했고, 머신러닝을 위주로 다루었습니다. 결국에는 머신러닝에서 라이브러리가 사용되니까 딱히 다른 얘기도 아니죠?

다들 머신러닝이라는 단어 들어보셨을텐데, 저는 학교 다니며 KNN, 의사결정모델 배웠는데도 그게 머신러닝이라는 걸 ㅋㅋㅋㅋ 모르고 했을 정도로 개념은 잘 안 잡혀있던 것 같아요. 세세한 코드와 모델, 뭐 라이브러리를 배우는 것도 필요하지만, 내가 지금 어느 단계에 와 있는지, 그리고 어떤 목적을 위해 이 과정을 거치는 건지를 아는 것이 장기적인 관점에서 중요한 만큼, 강사님께서 그 부분을 빼놓지 않고 언급해주셔서 좋았습니다.

(2) 느낀 점

쉽게 가르쳐주셨지만 생각보다 오래 허둥댔던 것 같아요 (‾◡◝)

표현하고 싶은 것들은 많은데 생각을 따라가기에는 실력이 부족한게 느껴져서 누군가 내가 말로 표현하면 코드를 짜 줬으면 좋겠다 ... 싶었습니다. 그래서 평일에는 강사님께, 주말에는 반 내 스터디를 하며 질문봇이 되었던 것 같아요.. o(￣▽￣)ブ

강사님께 '이런 식으로 코드를 짜고 싶다!'고 말씀드렸더니 힌트를 많이 주셨어요.

그런데 제가 남에게 짐 지우고 물어보는 게 편치 않은 사람이라 이번주에는 개인적으로 시간을 많이 투자해서 공부했었습니다. 대개는 제가 고난을 겪었던 부분이 몰려있더라구요. 제가 특히나 map, lambda 부분 때 이해를 못하고 넘어갔었는데 그 함수로 해결할 수 있었고, map을 더 잘 사용할 수 있으면 내가 하고 싶은 말을 더 잘 표현할 수 있겠구나 - 한 줄기의 빛을 봤습니다. 결국에는 복습과 검색이 답이라는 결론.

(3) 개선 방향 이번 주차동안에는 조금만 뒤쳐지면 마음껏 뒤쳐지는 느낌인데다가, 저번처럼 서로의 코드를 보고 힌트를 자주 얻을 수 있는 게 아니었어서 혼자 공부하기가 어렵다고 생각했어요.

다행히 마지막 날이었던 금요일에 강사님이 붙여주신 다른 동기분의 말을 들으면서, 제가 빼먹었던 부분들, 너무너무 비효율적으로 하고 있었던 부분들을 다시 바로잡고 알고 있었던 뒷 부분까지 결합하니까 그렇게 어렵지는 않더라구요.

그래도, 도움이 없었다면 정말 끝까지 따라가기 힘들었을 것 같아요. 동시에 강사님 말씀도 하나하나 잘 들어야겠다는 생각이 들었답니다.

저도 얼른 은혜를 갚고 도움을 주는 사람이 되어야겠지요.

저는 이 내용을 아주 조금은 알고 있었기 때문에, 응용이 어렵지 이해하기 힘들지는 않았는데, 정말 아예 비전공자이신 분들도 저처럼 힘들 것 같아요. 음, 제가 점점 익숙해져가면서 느낀 건 '생각보다 컴퓨터가 알아서 잘 해주는구나!' 였어요. 내가 그렇게 적극적으로 생각하지 않아도 괜찮고, 다만 내 역할은 컴퓨터가 인지하기 쉽게, 오류가 나지 않게 다잡아주고 컴퓨터 언어로 풀어내는 정도인 것 같네요.

아무튼, 오늘도 내일의 수업을 위해 조금 더 공부하다가 내일의 수업을 위해 빨리 잠에 들어야겠습니다! 내일부터도 최상의 컨디션으로 더 나은, 멋진 내가 될 수 있게 화이팅 🥰✊🏻🍘

▲ 주말동안 도움 많이 줬던 친구!

▲ 코드 짜는 자체가 어렵고, 오류가 너무 자주 나서 재미를 잃어버리고 있던 참에 chat gpt를 사용하면서 재미를 다시 찾게 됐어요..!!

▲ 어찌저찌 성적은 잘 받았지만 남는 건 1도 없었던 ... 다만 거품 낀 자신감..?

오늘은 강의를 들으며 좋았던 점, 아쉬운 점, 앞으로 계획 등을 작성하는 회고록으로 1주 간의 수업을 정리해보려 합니다 <3 좋은 점은 잘 이용하고, 아쉬운 점은 잘 해결해보자구요!

I. 일주일동안 한 일

1) 적응

플레이데이터와 국비지원 프로그램의 운영 방식, 시스템, 분위기, 그리고 주위 교통망과 강의가 들어온 일상에 적응하는 시간을 가졌습니다. 1교시 수업 잘 안 잡는 내가 주 5일 7시 반 기상이라니... 처음에는 너무 피곤했지만 열심히 하는 다른 분들 옆에서 조는 내가 부끄러워서, 라이프 사이클을 보다 성실하게 바꾸어 놓았습니다! 어차피 나중에 출근하면 9시 기상할텐데 이렇게 미리 습관을 들여놓는 것도 필요할 것 같아요. 이제는 좀 정착한 것 같네요 ;-)

일정 때문에 OT에 참석하지 못했어서 우당탕탕대기도 했지만, OT 자료를 전달받고 매니저님들께서도 잘 알려주신 덕에 꽤 빨리 적응할 수 있었습니다.

2) 수업 팔로우업

첫 날에는 가상환경 설정 방법을 배웠고, 자료구조, pandas, numpy, seaborn, matplotlib 원리와 이용방법, 기능 등을 배웠습니다. 이 내용은 너무 너무 많아서, 정리가 잘 된 부분만 notion으로 링크를 달아두겠습니다!

● 9/26(화) 2회차 수업 https://rare-buffer-0e6.notion.site/9-26-c1c2ddbb635d42c9b8be8b882e5a36da?pvs=4

● 10/4(수) 4회차 수업 https://rare-buffer-0e6.notion.site/10-4-TUE-b781f0c4d3c44b3caec806507345dbd0?pvs=4

● 10/5(목) 5회차 수업 https://rare-buffer-0e6.notion.site/10-5-24d04d740a3d492f8332ff246d646824?pvs=4

● 10/6(금) 6회차 수업 https://rare-buffer-0e6.notion.site/10-6-587849328d8540d599a6cdc9618311bf?pvs=4

후반부로 갈수록 따라잡느라 화면을 캡쳐하고, 내용을 옮겨 담을 시간이 없어져서 중간에 내용이 끊어지는 경우가 많습니다. 실제로는 더 많은 내용을 배웠는데, 보통 코드가 주된 내용이라 colab의 주석에 다 기입해두기에 notion, blog를 이용하는 일이 적어졌습니다. 그런데 아직 모르는 게 있으면 자주 노션에 돌아가 확인하는 걸로 보면, 앞으로도 소홀히 하지 않고 열심히 적어야 할 것 같네요.

▲ 레퍼런스가 편하더라구요.

II. 좋았던 점: 시간과 공간, 도구, 자료, 그리고 도움 제공

1) companion

학교에서 수업을 듣고나서 질문을 들고 교수님을 찾아가려하면 다른 학생들도 줄줄이 대기하고 있었기에, 질문하기를 미루다 점점 안 풀리는 경우가 많아져 쉽게 도태되었어요. 그렇게 시간이 흐르다보면 나중에는 너무 기본 지식을 묻는 느낌에 부끄러워서, 계속 물어보지 못하고 무지를 묻어두고 회피하기를 선택했던 것 같습니다.

그런데 9시부터 6시까지 강사님과 보내는 시간 동안 질문의 기회가 매우 많고, 강사님께서는 저녁까지 남아 질문을 돌봐주셔서 놓치지 않고 계속 배우려는 의지가 유지될 수 있었어요 ㅎㅎ.

그리고 'SLACK'이라는 어플리케이션으로 동기분들과 소통하면서 답을 참고할 수 있어서 그것도 많은 도움이 돼요. 어쩌다 한 번 놓쳐도, 동기분들 코드를 해석해가며 귀납적으로 답을 찾아갈 수 있었습니다.

▲ 다들 답을 공유하는 열정적인 모습. 이제 많이 배워서 상위에 답 다는 재미를 느끼고 있다.

2) PC 제공 저장위치가 중요한데, 저는 결코 PC를 잘 정리하는 편이 아니예요..ㅎ🤔 개인 컴퓨터를 사용하면 메모리 문제도 있고, 다른 파일과 헷갈려 예전에는 파일 저장 위치때문에 꼭 한 번씩은 오류가 나고는 했었답니다. 플레이데이터에서 제공해주는 PC를 사용하며, 딱 코딩으로서만 컴퓨터를 이용할 수 있고 파일 찾기가 쉬워서 정말 좋았습니다 🌹

▲ 깨끗하죠?

3) 강사님의 실무자로서의 꿀팁 제공

강사님께서 가르쳐주신 데이터 관련 공모전 페이지를 참고해서 혼자 공부하고도 있는데 수업과는 같고도 또 다른 면으로 많이 배우고 있어요. 모든 코드를 구현은 무슨 아직 이해하지도 못하지만, 실제로 어떻게 사용되는지를 미리 어깨너머로 보고 나면 '이거 알고 싶다!' '나도 쓰고 얼른 싶다!'라는 생각이 들고, 수업 중에 배우면 '어 저거!'하면서 더 열심히 듣게 돼요..ㅎㅎ

그 외에도 혼자 블로그 정리해보라, 나만의 책을 정리해보라는 말씀을 듣고 정리하고 있는데, 모르는 거 있을 때 찾아보면 과거의 내가 친절히 설명해준답니다 .. 😊

III. 아쉬웠던 점

-굳이 떠올려보자면? 일정이 타이트하다는 점

양날의 검이에요! 오히려 타이트한 덕분에 더 열심히 빨리 해야겠다, 내 개인 시간도 쓰면서 공부해야겠다! 동기부여가 됩니다. 그래도 강사님께서 촉박한 스케쥴에 걱정을 많이 하시지만, 그러시지 않아도 될 것 같다는 한낱 일개 학생의 생각..?

IV. (내가) 개선할 점

♥ 지각하지 않기 !! 출, 퇴근시간이 정말 정확히 겹치다보니 사람이 너무 많아요... 이제는 좀 요령이 생겨 서 있던 칸에 사람이 많아보이면 냅다 가장자리로 뛰긴 하지만 사람들에게 밀려 매번 5분씩 늦는 것 같네요. 그런 변수를 고려해서 아예 8시 20분에는 출발해야겠습니다!

10분까지는 지각이 카운트되지 않지만 그것과 별개로 딱 정갈한 마음으로 사물함에서 필요한 거 꺼내고 충전하고 프로그램 작동시키고 미리 어제 내용 복습하는 건 하루의 품질을 바꿔주는 것 같아요. 오늘은 처음으로 시작 전에 도착해서 그렇게 준비를 해 봤는데, 더 여유롭고 좋더라구요. 그리고 거기 더해서 빨리 자도록 해야겠죠 ?!

그래서 매일 출석, 퇴실 확인하는 표에 기입 중! (실수로 출석 안 찍은 적 한 번, 퇴실 못 찍은 적 한 번이라 결석, 지각이 한 번 씩 늘었어요 ㅠㅡㅠ 다시는 그런 일 없어야 한다.)

♥ 매번 오늘 배운 건 오늘 복습하고 자기! 화, 목요일에는 과외에 다녀와서 집에 들어오면 10시 반이라, 복습이 쉽지 않지만 그런 날이 아니라면, 그리고 특히 주말에는 복습에 시간을 투자해야함을 항상 감안해야겠어요! 혼자 집에서 하지 못할 것 같다면 남아서 강사님과 동기분들과 함께 하고 가는 것도 좋아보이더라구요.

V. 다음주 계획

♥ 복습, 강사님께 더 많이 여쭤보기 이제 월, 수, 금이 비는데 일주일 중 이틀만큼은 남아서 꼭 하고 가려고 합니다! 집에 가서 컴퓨터로 하면 좋지만 집에서는 제 정신을 놓게 하는 것들도 많고 visual code도 안 깔려 있는데, 코딩은 직접 해야 정말 늘거든요. 보기만 하고 코드 외우기만 한다고 늘지 않는 것 같아요.

♥ ** '이렇게 바뀌면 어떻게 될까?' 궁금해하기**

강사님께서 주시는 코드, 동기 분들이 만드는 코드들을 '그렇구나'하고 지나가는게 아니라, 왜 방법을 여러 개 배웠는데 내 코드는 틀리고 저건 맞는지, 그런 궁금증을 꼭 해결하고 가는 게 중요한 것 같아요. 지금 내가 모르는 게 뭔지를 확실히 짚고 다시는 그런 실수를 하지 않도록 근본적으로 고쳐야 해요.

예를 들어, lambda 함수로 연산이나 조건문과 함께 새로운 데이터프레임 내지는 컬럼을 만들고, 추가하는 과정에서 apply와 map을 이용하는 두 가지 방법을 배웠었는데요.

처음 제가 map을 사용해서 코드를 만들었더니 오류가 났고, apply를 사용하라는 거에요! 그때 그냥 어~ apply를 사용해야하는구나 - 하고 지나가는 게 아니라 그 차이를 파악하는 게 중요합니다.

알아 본 결과, map은 단일컬럼의 경우, apply는 다중컬럼인 경우 사용한다고 해요.

여기서는 원래 type이 number(not object)였던 column, 'pclass'를 이용해서 조건문을 달아, 조건에 해당되면 새로 만들어진 'new_pclass' 칼럼에 True로서 담는 코드를 만들었어야 했는데요. 처음에 저는 pclass가 1, 2, 3이 아니라 first, second, third의 object로 이루어진 column이라고 생각해서 어떻게 풀지 고민을 했어요.

그런데 알고보니 제 생각보다 쉽게, 원래 number 상태였던거죠. 문제가 너무 쉬워졌으니 다행스럽게 넘어갈 게 아니라, 그럼 진짜 object로 나오면 어떻게 변환하지? 고민이 되었어요. 이 과정에서 늘게 되는 듯 해요.

이건 오늘 했던 부분이었는데, 위에서 사용했던 'age'에 관한 조건이 아래에서도 그대로 반복되기에, 혹시 교집합을 사용할 수 있을까? 궁금했어요. 전 이런 질문을 자주 하는 편인데, 비효율적인 부분을 해결하기 위해 실무에서 쓰는 팁이 있는지 여쭤보는 것도 좋아요.

♥ 작게 재미 요소를 만들기 세 번째 시간에 추석 결석을 한 관계로 네 번째 시간, 따라잡으면서 다음 진도 나가는 게 힘들었었어요. 멘붕 직전이었는데 한 문제를 만나면서 상황이 역전되었습니다!

따라가지를 못해서 다른 분 코드를 그대로 따라썼었답니다. 그러다가 왕창 틀리더라도 재미요소를 추가해봤어요.

이 과정에서 '어? attribute에 if절을 이용해서 다른 attribute를 또 연결할 수 있을까?' 추가적인 고민을 했습니다. 이러면서 정말 제가 생각했던 코드가 실행되는 짜릿함을 경험했어요.

♥ 끝까지 다시 보기 저는 계속 지나갔던 강의 자료도 되돌아봐요. 뒤를 배우면서 오히려 앞에 배웠던 것들에 있던 의문이 너무 쉽게 풀리는! 경험을 하게 되기도 하고, 따라가기 급급해서 떠올리지 못했던 또 다른 해결 방법을 발견하는 계기가 되거든요.

검증 부분, loc 부분 등 자주 헷갈리는 건 여러 번 보고 지나갔다 다시 와서 보고 또 보고...

♥ 주석, 댓글 달기 예전에는 코드를 따라치는 데에 급급했는데, colab을 사용하면서 여유가 생겼으므로 더 사고하고, 이해하는 데에 시간을 쓸 수 있게 되었죠! 그래서 나중에 복습할 나를 위해서 주석으로 헨젤과 그레텔 빵을 남겨두기도 좋을 것 같아요! 또 처음 봤을 때 이해 못 한 점은 댓글로 표시해두어도 좋아요.

▲ 주석을 사용하는 모습

♥ 내가 교수라면? 어떤 문제 내고 싶은지 생각하며 더 적극적으로 임하기 예전에 코딩 수업을 들으며 시험이 좀 지엽적이다! 생각했었어요. 반면 지금 강의를 들으면서 '이렇게 시험내면 정말 근본적인 테스트를 할 수 있을 것 같은데' 싶은 부분들이 있었단 말이죠? 그렇게 생각하면서 수업을 들으니 졸릴 틈이 없었습니다!

merge에서 left, right 줘 놓고 상황 별 result 예측하게 하기.. 처럼요!

이렇게 9월~10월에 걸친 회고록을 작성해보았습니다 ~! 생각보다 길어졌는데 얼른 마무리하고 오늘 배운 코딩 복습하러 갈게요 ㅎ.ㅎ