블로그

인공지능과 추천 시스템 강의 노트 - 2025.10.4(5주), 2025.10.10(6주)

2025.10.4. / 2025.10.11들어가며학기 초부터 예상을 한 것이긴 하지만, 대체 휴일을 포함하며 매우 긴 추석 연휴가 주어지며, 토요일 수업을 진행하는 입장에서 꽤 난감한 상황이 되었다. 토요일에 수업을 배정할 때부터, 소위 빨간 날인 휴일은 아니지만 그렇다고 열흘 연휴 중 두번이나 여의도에 등교하는 것을 강제하는 게 적절한가 등의 고민이었고.. 나도 개인적으로 명절을 한국에서 보내기 여의치 않은 상황이어서 두 번의 강의를 온라인으로 진행하는 것으로 하기로 하였다.그래도 라이브 유튜브 하는 것처럼 댓글도 달리고 하면 좋겠다는 생각을 했지만, 미국의 금요일 밤 11시나 한국의 오후 3시나 여의치 않은 상황이어 녹화 영상을 송출하는 방식으로 진행했다. 팟캐스트 등의 댓글로 서로 궁금한 걸 나누면 좋을텐데, 이건 내 역량의 한계인가 싶기도 하다.같이 보면서 이야기나눌 수 있는 내용들을, 한편으로는 가볍게 보았으면 하는 마음으로 링크들을 공유했는데, 수업의 특성 상 반강제로 끝까지 보아야 출석 인정이 되게 되었다. 기왕이면 이전에 보지 않은 클립들이면 싶고, 흘려 듣더라도 내가 받았던 감동을 받으면 좋겠다는 생각이다. 이번 글은 나누었다기보다는 그냥 준비한 내용들을 흘려 보낸 에 가깝고, 후속으로 나누고 싶은 이야기들은 언제든지 환영한다. 준비한 내용들 - 5주5주) 강의 updateSearch by GoogleGoogle — 25 Years in Search: The Most Searched ( 2024, 4min )Google — Year in Search 2024 ( 2024, 4min ) The Evolution of Search ( 2011, 6 min )How Google makes improvements to its search algorithm ( 2011, 4 min )Search Quality Meeting: Spelling for Long Queries (Annotated) ( 2012, 8 min ) Google Instant Launch Event ( 2010 , 1h 26m ) - Google Instant ( 15 ~ 52, 37min )Inside Search Event ( 2011, 59 m ) - Google instant pages , ( 0 ~ 23, 10 min ) Google I/O 2015 - Smarter user acquisition with App Indexing, AdWords and Google Analytics (2015, 20 min ) 5번째 주는 구글 검색에 대한 내용들을 모았다. 개인적으로 일에 관련된 모든 것들을 좋아하던 시절의 이야기들이고, 기술적인 챌린지들도 내용도 꽤 아는 이야기들을 press event 로 녹여 내던 시기의 이야기들을 주로 담았다. 개인적으로는 search quality review meeting 이 밖으로 더 널리 알려지면 하는 바람도 있고, 자주는 아니지만 google I/O 에 검색팀이 나가야만 했던 그 시절 상황도 알려지면 하는 생각이다. 이후의 Google I/O 이벤트들은 전문가들의 손길이 다양한 데서 닿았던 거라 그시절의 낭만은 더이상 없는 듯해서인지 그래서 좋은 기억으로 남아 있는 거 같다. 준비한 내용들 - 6주AI until 2025Ted Talk : How we're teaching computers to understand picturesby Fei-Fei Li ( March 2015 , 18 min )Ted Talk : How AI could empower any business by Andrew Ng ( April 2022, 11 min ) Ted Talk : Why AI is incredibly smart and shockingly stupid by Yejin Choi ( April 2023 , 16 min )Building AI for Everyone | Jeff Dean Senior Fellow in Google AI ( 2018, 세바시 강연, 16 min ) The future of computing: a conversation with John Hennessy (Google I/O '18) ( May 2018, 25 min )Jeff Dean (Google): Exciting Trends in Machine Learning ( 2024, 70 min ) 6번째 주는 AI 관련된 몇몇 talk 들을 역시 사심을 담아 공유하였다. AI 쪽으로 발을 디딜 때 접하게 되었던, data driven 의 세상을 접하면서 알게 된 감동을 하나씩 공유하려 주고 싶었지만, 요즈음의 AI 는 그당시 쥐어 짜던 시절의 ML/DL의 조금은 수줍던 접근이 더이상 아닌 거 같아 살짝 아쉬운 부분이 있다.구글에 10여년 다니며, 지금은 전직장 동료(?)가 노벨상을 받았다는 억지스런 자랑거리도 있다지만, 말로만 듣던 대가들을 살짝 가까이에서 볼 수 있었던 것에 대한 감동, 또 그들이 자기자신들의 한계를 넘는 모습을 접할 때 큰 울림이 있어 왔다. 물론 그들의 한계라는 것조차 내가 임의로 그린 것이겠지만… 그 중 몇몇은 지금 보아도 전율이 이는데, 살짝 길지만, 그 중 두명의 이야기를 나누고 싶었다.하나는 2018년 google I/O 때 John Hennessy 옹(? 님?)께서 훑어 주신, 컴퓨터 구조에서 시작한 ML / domain specific programming 에 대한 이야기로, 마치 지금의 transformer 지배적인 세상을 예측한 듯한 대가의 말씀, 그것도 엄청나게 열정적인 자세로… 진정 저렇게 나이 들고 싶다는 생각을 했었다. 다른 하나는 Jeff Dean 의 구글 AI/ML summary. 당시 Brain 팀의 수장이었지만, 그 누가 이토록 꿰뚫는 이야기를 할 수 있을까, 그리고 그걸 듣는 입장에서 수긍할 수 있을까 등의 감정으로 보았던 내용들이라 하겠다. 제품과 기술 둘 중에서 꽤 많이 기술 이야기이긴 하지만, 기술자 identity 인 나의 시각에서 수업에 지장이 안 간다면 꼭 나누어 주고 싶은 이야기들이 클립들에 담겨 있다 하겠다. 약간의 사족구글에 조인할 때 founder, celebrity 들을 보고 선택을 한 건 아니었지만, 이후에 내가 tech 회사를 차린다면 혹은 조인한다면 Jeff Dean 혹은 Craig Silverstein 같은 사람을 회사 내에서의 코드나 업적으로 만나길 바라게 되었다. 이후에 나타난 회사를 옮겨 다니는 네임드들을 접할 때, 이들이 구글에서 이루어 낸 '업적'을 고려해 보게 되는데, 훨씬 더 다양한 일들이 있게 되는 복잡해 진 요즘 세상에, 특히 engagement 를 고민하게 될 때 그 시절의 낭만은 꽤 그립다.

5%의 복잡도로 80%의 성능을 제공하는 DB Router routemate 소개드립니다.

안녕하세요.최근 개인적으로 사용하기 위해 만들었다가 오픈소스로 공개한 DB Router 라이브러리 routemate를 소개드립니다.왜 만들었나실무에서 다음과 같은 상황을 자주 겪었습니다.Read/Write DB 분리가 필요하지만ShardingSphere, Vitess 같은 솔루션은 도입 비용이 너무 큼단순한 R/W 분기만 필요한데 설정과 학습 비용이 과도함트랜잭션, AOP, ThreadLocal, DataSource 라우팅을 매번 직접 구현결국 매 프로젝트마다“비슷한 코드를 또 만들고, 또 검증하고, 또 사고를 치는” 상황이 반복됐습니다.그래서 목표를 이렇게 잡았습니다.복잡한 기능은 과감히 버리고실무에서 가장 많이 쓰는 80%만 아주 단순하게 제공하자Routemate는 무엇인가Routemate는 Spring 기반 환경에서 사용할 수 있는경량 Read/Write DB Router 라이브러리입니다.Read / Write DataSource 자동 분기Spring Transaction 연동AOP 기반으로 투명하게 동작최소한의 설정Starter 형태로 바로 사용 가능Sharding, 분산 트랜잭션, 멀티 키 라우팅은 지원하지 않습니다.의도적으로 지원하지 않습니다.설계 방향1. 설정은 최대한 줄인다application.yml 몇 줄로 끝복잡한 rule DSL 없음DataSource 개수만 알면 바로 사용 가능2. Spring이 이미 제공하는 걸 최대한 활용한다@Transactional(readOnly = true) 기반 라우팅ThreadLocal 최소 사용Spring AOP 라이프사이클에 자연스럽게 녹임3. “왜 이렇게 동작하는지” 바로 이해 가능해야 한다코드 양이 적음내부 로직이 단순함디버깅 시 추적이 쉬움언제 쓰면 좋은가단일 Master + 다수 Replica 구조Read 부하가 높은 서비스Sharding까지는 필요 없는 서비스언제 쓰면 안 되는가복잡한 샤딩 전략이 필요한 경우멀티 테넌트 기반 라우팅DB 레벨의 강력한 일관성 제어가 필요한 경우이 경우에는 기존 대형 솔루션이 더 적합합니다.현재 상태Maven Central 배포 완료Spring Boot Starter 제공개인 프로젝트 및 토이 프로젝트에서 사용 중문서 및 예제 지속 보완 중GitHubhttps://github.com/KrongDev/routemateREADME에 개념 설명, 설정 방법이 정리되어 있습니다.마무리이 라이브러리는“정답 솔루션”을 만들고 싶어서 시작한 게 아니라,실무에서 반복되던 불편을 조금이라도 줄이기 위해 만들었습니다.혹시 비슷한 문제를 겪고 계셨다면가볍게 한 번 살펴봐 주셔도 좋겠습니다.피드백, 이슈, PR 모두 환영합니다.읽어주셔서 감사합니다.

한국 IT 용어 이야기 (12) - "주석"

REM 이 기억이 났다. 예전의 기억들부터..연식이 나와 버리지만, 꽤나 오래 전 초등학교 아니 국민학교 시절에 컴퓨터를 배웠다. 당시 삼성 SPC-1000 이었고, 뭐 이렇게 생긴 것을 학교에서 접했더랬다. 왼쪽의 플로피 디스크는 공용으로 썼던 기억이다.이후 Apple2 컴퓨터를 접하면서는 이런 것도 했었더랬다.for / if else / print 뭐 이런 것들이 제일 먼저 배우게 된 영어 단어였다. I am a boy 같은 것보다 먼저 배웠던 기억이다.서예 학원을 다녔어서 한자를 꽤 읽을 줄은 알았지만, 어려운 한글/한자인 '주석'을 접하게 되고, REM 이라는 충격적인 단어를 접하게 된다. 오늘의 기억 소재.. 아주 오랫동안 REMOVE , REMEMBER 등의 약자로 오해하고 있었더랬다. 프로그램에 줄 별로 친절한 설명을 달기 위함이였다고 하지만, 안 쳐도 실행에 지장 없고, 손으로 코딩을 하던 시절에는 더더욱 없는 셈 치려 했던 기억이다. 이런 걸 왜 만들었지? 왜 사람들은 주석이라 그랬지? 대학교 시절의 주석남들이 써 놓은 논문들을 제대로 접하면서 각주, 주석, 인용 등의 의미를 알게 되었다. 코영어로는 footnote, cite... REM 은 왜 안 쓰지 ? 미국 사람들은 remark 를 쓰는 건가 ? 코드를 계속 접하면서도 여전히 있으나 마나한 명령어로 인식하고 있었다. 내가 초절정 고수는 아니었지만, 그렇다고 남들한테 일일이 설명해야 하는 상황이 생길 일이 적었기도 했다. 컴파일러 혹은 어셈블러 과목에서 주석 처리는 제일 먼저 해결해야 하는 문제였다. parser 이런 거 처음 만들 때 당연히 잘 안 되고... 실제 주석만 처리하다 꽤 많은 시간들이 날아갔던 경험들이다. 다양한 주석들평생 프로그램/코딩을 가까이에 놓다 보니 다양한 언어들을 접하게 되고, 아주 다양한 comment 방법들을 접하게 된다. 여러 개를 닥치는 대로 쓰다 보니 거꾸로 Java 에서 # 을 쓴다든지 하는 실수들을 접하게 된다. windows shell 에 REM 을 쓰던 시절도 있었고, bash shell 에서 # 인지 // 인지 매번 헷갈려 한다. 최근의 꽤 충격적인 경험들은 -- 을 붙여 쓰던 것들이었다.. C, C++, C#, Java, JavaScript, golang : // , /* */어셈블리어 : ;HTML : <!-- -->Python : # , ''' ''', """ """SQL : -- , /* */CSS : /* */BASIC : REM annotation / comment예전에 배웠던 언어들의 최신 버젼들은 주석도 아닌 것들이 annotation 이라며 코드나 컴파일러에 영향을 주려 한다. Java , Python 에서 종종 보이고. 프레임워크 따라서 이름을 정하거나 외우거나 해야 할 수도 있게 되었다. 함수 이름만 고민하던 시절에 비해 왜인지 모르게 더 복잡해 진 거 같고, 문해력이 더 필요하게 되었다.바이브 코딩 등을 통하다 보면 comment를 통해 꽤 많은 의미를 주려 한다. 구글에서 코드 리뷰 등을 논할 때 여러 가치관을 가지고 함수 앞부분에 이야기를 많이 하라고 했고, 정작 코드 블럭에서는 설명이 필요한 코드들을 만들지 않도록 노력하라는 이야기들을 배웠더랬다. 빅테크에 조인하고 나서야 남에게 읽히기 위한 코드 만들기를 꽤 뒤늦게 시작했으니, 진정한 미국 영어들은 이 comment 들을 리뷰하면서 배웠던 기억들이다. a 냐 the 냐 , 마침표냐 쉼표냐 등등.. 이제 아무도 REM 을 쓰지는 않나 보다.. 그래도 주석이라고는 쓰겠지 ?

어라라 내 머리속 지우개

좌표계Local 좌표계 : 특정 물체를 기준으로 한 좌표계World 좌표계 : 게임 세상의 좌표계 (세상을 기준으로)Viewport 좌표계 : 카메라가 촬영하는 화면의 좌표계 (비율로 표시가 된다. 0.0f ~ 1.0f)Screen 좌표계 : 카메라가 촬영하는 화면의 좌표계 (픽셀 좌표 수치를 알려준다) Input.mousePosition : 현재 마우스 좌표를 픽셀 좌표(스크린 좌표)로 가져온다Camera.main.ScreenToViewportPoint(Input.mousePosition : 픽셀 좌표(스크린 좌표)를 비율로서 좌표를 가져온다2. Raycast원하는 지점을 기준으로 레이저를 쏴서 가장 먼저 닿는 오브젝트의 정보를 가져온다.혹은 Physics.RaycastAll 함수를 이용하여 레이저에 닿는 모든 오브젝트의 정보를 가져온다. (배열로)예) RaycastHit[] 변수명변수명 = Physics.RaycastAll()foreach(RaycastHit hit in 변수명) + Raycast는 무거운 작업이고 신중하게 써야하는 작업 제네릭 타입public T Load<T>(string path) where T : Object리소스 폴더에서 리소스를 로드할때 사용하던 코드T는 제네릭 타입이라 하여 메서드가 실행된 후 반환할 데이터 타입이다where T : Object를 제네릭 제약 조건이라 하고, T에 들어올 타입을 제한한다.4. Prefabs의 코드 생성 (프리팹 코드 생성)Instantiate 함수를 이용한다.프리팹을 생성 혹은 부모 객체 아래에 붙혀서 생성 할 수 있다.예) GameObject prefab = Load<GameObject>($"Prefabs/{path}");Object.Instantiate(prefab)5. 문자열 보간 $ { }$"문자열 : { 값 } " 을 이용하여 직관적으로 코드를 작성 할 수 있다.Nested Prefab Prefab에 Prefab을 붙여서 새로운 Prefab을 만드는것3D 실제 거리를 구할때 (magnitude)Mathf.Sqrt를 이용하여 어떤 수의 제곱인지 알 수 있다(x* x + y * y + z * z) 3D 방향을 구하고 싶을때 (normalized)x / magnitude, y / magnitude, z / magnitude 마우스 클릭 (Input.GetMouseButtonDown(0)) 마우스를 클릭하면 실행 마우스 위치 Vector3 mousPos = Camera.main.ScreenToWorldPoint(new Vector3(Input.mousePosition.x, y, z)Vector3 dir = mousPos - Camara.main.transform.positiondir = dir.normalized 월드 좌표계에서 마우스의 위치를 구한 뒤 방향을 구하고 크기를 1로 변환 의 기능을 모두 가진 Ray ray = Camera.main.ScreenPointToRay(Input.mousePosition)ray.direction 방향 정보도 가지고 있다Physics.Raycast(ray, out hit) 10. 충돌 지점에 프리팹 생성 Raycast를 이용하여 충돌하는 오브젝트의 정보를 알 수 있다면, 충돌 지점에 대한 정보도 있지 않을까?그 지점에 내가 원하는 프리팹을 생성할 수도 있지 않을까? 라는 생각이 문득 들어서 찾아봤다RaycastHit hitPhysics.Raycast(ray, out hit, 100.0f)hit.point가 충돌 지점 좌표였다 이걸 사용해 내가 원하는 프리팹을Instantiate(prefeb, hit.point, Quaternion.identity)로 생성함   

구글 SEO의 비기 티어 링크 빌딩의 완벽한 설계와 운용 전략

구글 검색엔진 최적화 의 세계는 끝없는 창과 방패의 싸움입니다 알고리즘은 더욱 정교해지고 경쟁자들은 더욱 스마트해지고 있습니다 단순히 좋은 콘텐츠를 쓰고 백링크 몇 개를 다는 것만으로는 더 이상 1페이지 상단을 보장할 수 없는 시대가 되었습니다 남들이 범접할 수 없는 압도적인 권위와 순위를 차지하기 위해서는 기존의 선형적인 링크 구조를 탈피해야 합니다 바로 여기서 등장하는 것이 SEO 전문가들의 비밀 병기라고 불리는 티어 링크 빌딩 전략입니다 이는 단일 계층의 링크가 아닌 다층적인 피라미드 구조를 통해 링크의 힘을 증폭시키고 메인 사이트를 알고리즘의 위협으로부터 보호하는 고도의 전술입니다 이 글에서는 티어 링크 빌딩의 메커니즘과 각 계층별 구축 전략 그리고 실패하지 않는 운용 노하우를 여러분의 웹사이트를 난공불락의 요새로 만드는 방법을 제시합니다 티어 링크 빌딩의 정의와 링크 주스 증폭의 공학적 원리 티어 링크 빌딩이란 백링크 를 여러 단계의 계층으로 나누어 구조화하는 전략을 말합니다 우리의 최종 목표인 메인 사이트 즉 머니 사이트를 정점에 두고 그 아래로 피라미드처럼 링크 그룹을 배치하여 하위 단계의 링크 주스가 상위 단계로 모이고 농축되어 최종적으로 머니 사이트에 폭발적인 에너지를 전달하는 방식입니다 이를 이해하기 위해서는 링크 주스의 흐름을 물리적으로 시각화해 볼 필요가 있습니다일반적인 링크 빌딩이 여러 개의 작은 호스를 메인 사이트에 직접 연결하는 것이라면 티어 링크 빌딩은 수천 개의 작은 물줄기를 모아 거대한 댐에 저장한 뒤 그 댐의 수문을 열어 메인 사이트로 엄청난 수압의 물을 쏟아붓는 것과 같습니다 하위 티어인 티어 3과 티어 2에서 생성된 방대한 양의 링크 주스는 필터링 과정을 거치며 강력한 권위로 변환되어 티어 1을 통해 머니 사이트로 전달됩니다 이 과정에서 링크의 양은 질로 전환됩니다 또한 이 다층 구조는 필터 역할을 수행합니다 하위 티어에 섞여 있을 수 있는 저품질 링크의 독성이 상위 티어를 거치며 희석되거나 차단되어 메인 사이트에는 오직 정제된 순수한 권위만이 도달하게 됩니다 즉 티어 링크 빌딩은 파워와 안전이라는 두 마리 토끼를 동시에 잡는 가장 진보된 SEO 엔지니어링입니다 최정예 부대 티어 1 링크의 구축 조건과 전략 티어 1은 여러분의 소중한 머니 사이트로 직접 연결되는 최상위 계층의 백링크 그룹입니다 이들은 피라미드의 꼭대기 바로 아래 위치하며 머니 사이트의 운명을 직접적으로 결정짓는 황실 근위대와 같습니다 따라서 티어 1의 핵심 철학은 타협 없는 품질입니다티어 1 링크는 반드시 구글의 웹마스터 가이드라인 을 준수하는 화이트햇 방식에 가까워야 합니다 높은 도메인 권한을 가진 뉴스 사이트 업계 최고의 권위를 가진 블로그의 게스트 포스팅 그리고 엄격하게 관리되는 고품질 웹 2.0 블로그 등이 여기에 해당합니다 여기서 중요한 것은 콘텐츠의 질입니다 티어 1에 게시되는 글은 머니 사이트의 글만큼이나 훌륭해야 합니다 독자에게 가치를 제공하고 문맥적으로 완벽하게 연관되어 있어야 합니다 구글의 검열관이 직접 눈으로 확인해도 흠잡을 데 없는 자연스러운 링크여야 합니다 티어 1에서는 앵커 텍스트 또한 신중하게 사용해야 합니다 과도한 키워드 최적화를 피하고 브랜드명이나 URL 주소 위주로 자연스럽게 구성하여 알고리즘의 의심을 피하는 것이 상책입니다 티어 1이 무너지면 머니 사이트가 위험해지므로 이곳은 철저한 관리와 투자가 필요한 영역입니다 권위의 증폭기 티어 2 링크의 역할과 운용법 티어 1이 품질의 영역이라면 티어 2는 품질과 물량의 조화를 추구하는 영역입니다 티어 2의 존재 목적은 단 하나 티어 1 사이트들의 권위를 높여주는 것입니다 아무리 좋은 게스트 포스팅이라도 외부에서 링크가 들어오지 않으면 그 페이지 자체의 힘은 미약할 수 있습니다 이때 티어 2 링크들이 티어 1 페이지를 지지해주면 티어 1의 페이지 권한이 상승하고 그 힘은 고스란히 머니 사이트로 전달됩니다티어 2 링크를 구축할 때는 티어 1보다는 조금 더 유연한 기준을 적용할 수 있습니다 도메인 권한이 아주 높지 않아도 되며 텀블러나 워드프레스 같은 웹 2.0 블로그 소셜 북마크 기사 디렉토리 위키 페이지 등을 광범위하게 활용합니다 이곳에서는 콘텐츠의 양이 중요해집니다 티어 1을 밀어주기 위해서는 상당한 수의 링크가 필요하기 때문입니다 하지만 그렇다고 해서 스팸성 글을 올려서는 안 됩니다 최소한의 가독성을 갖춘 글이어야 하며 주제의 연관성을 유지해야 합니다 앵커 텍스트 전략에서도 조금 더 공격적일 수 있습니다 티어 1이 머니 사이트를 보호하고 있으므로 티어 2에서는 타겟 키워드를 포함한 롱테일 키워드를 적극적으로 사용하여 특정 주제에 대한 신호를 강하게 보낼 수 있습니다 티어 2는 머니 사이트와 직접 연결되지 않기 때문에 상대적으로 리스크는 적으면서도 강력한 부스팅 효과를 낼 수 있는 전략적 요충지입니다 물량 공세의 시작 티어 3 링크와 인덱싱 전략 티어 3은 피라미드의 가장 밑바닥을 지탱하는 거대한 기반입니다 이곳의 역할은 티어 2 링크들이 구글에 빠르게 색인되도록 만들고 링크 주스의 원천 소스를 공급하는 것입니다 티어 2 페이지들이 구글에 인덱싱되지 않으면 그 상위 단계로 힘을 전달할 수 없습니다 티어 3은 바로 이 인덱싱을 강제하는 역할을 합니다티어 3에서는 품질보다는 물량이 절대적인 기준이 됩니다 포럼 프로필 댓글 블로그 방명록 핑백 등 생성하기 쉽고 양을 늘리기 좋은 링크들이 주로 사용됩니다 자동화 도구를 활용하는 영역이기도 합니다 하지만 주의할 점은 아무리 티어 3이라도 무분별한 스팸은 지양해야 한다는 것입니다 티어 2가 필터 역할을 하지만 너무 많은 독성 링크는 결국 시스템 전체를 오염시킬 수 있습니다 티어 3 전략의 핵심은 속도 조절입니다 너무 짧은 시간에 수만 개의 링크를 쏟아부으면 구글의 감시망에 걸릴 수 있습니다 드립 피드 방식으로 천천히 꾸준하게 링크를 공급하여 자연스러운 성장의 모습을 연출해야 합니다 티어 3의 링크 주스는 개별적으로는 미미하지만 수천수만 개가 모여 티어 2로 흘러들어 가면 거대한 강물이 되어 상위 티어를 강력하게 밀어 올리는 원동력이 됩니다 티어 링크 빌딩에서의 리스크 관리와 풋프린트 제거 티어 링크 빌딩은 강력한 만큼 리스크도 존재합니다 가장 큰 위험은 구글에게 이 모든 구조가 한 사람에 의해 조작되었다는 사실을 들키는 것입니다 이를 풋프린트라고 합니다 발자국을 남기지 않는 것이 티어 전략의 성공을 좌우합니다첫째 서로 다른 티어 간의 교차 링크를 피해야 합니다 티어 3에서 티어 1로 직접 링크를 걸거나 티어 2에서 머니 사이트로 바로 연결하는 실수를 범해서는 안 됩니다 계층 구조를 철저히 지켜야만 필터링 효과를 볼 수 있습니다 둘째 다양한 플랫폼과 IP를 사용해야 합니다 모든 티어 링크가 동일한 호스팅 업체나 동일한 IP 대역에서 나온다면 구글은 이를 즉시 PBN으로 간주하고 페널티를 부과할 것입니다 분산 호스팅을 사용하고 다양한 블로그 플랫폼을 섞어서 사용하여 마치 전 세계의 서로 다른 사용자들이 링크를 건 것처럼 위장해야 합니다 셋째 콘텐츠의 중복을 막아야 합니다 동일한 글을 모든 티어에 복사해서 붙여넣는 것은 자살 행위입니다 스피닝 툴을 사용하여 글을 변형하거나 각 티어별로 다른 주제의 글을 작성하여 독창성을 유지해야 합니다 완벽한 범죄가 증거를 남기지 않듯 완벽한 티어 빌딩은 운영자의 흔적을 남기지 않습니다 티어 링크의 효과를 극대화하는 시간차 공격 전략 티어 링크 빌딩은 하루아침에 완성되는 것이 아닙니다 시간차를 둔 공격 즉 드립 피드 전략이 필수적입니다 머니 사이트를 오픈하자마자 티어 1 2 3을 동시에 구축하면 구글 샌드박스에 갇힐 확률이 매우 높습니다가장 이상적인 시나리오는 다음과 같습니다 먼저 머니 사이트에 고품질 콘텐츠를 채워 넣습니다 그 후 2주에서 한 달 정도의 시간을 두고 티어 1 링크를 하나씩 구축합니다 티어 1이 구글에 인덱싱되고 자리를 잡은 것을 확인한 후 다시 2주 정도 뒤에 티어 2 링크 작업을 시작합니다 티어 2가 어느 정도 쌓이면 그때 티어 3을 통해 힘을 실어줍니다 이렇게 시간차를 두고 링크가 생성되면 구글은 이를 사이트의 인기가 점진적으로 상승하면서 자연스럽게 확산되는 과정으로 인식합니다 또한 링크의 인덱싱 속도를 조절하여 링크 주스가 한꺼번에 몰려오는 것이 아니라 꾸준히 유입되도록 만들어야 합니다 지속적인 링크 주스의 공급은 순위의 등락폭을 줄이고 오랫동안 상위권을 유지하게 만드는 비결입니다 자세한내용은 더상승마케팅 에서 확인하실 수 있습니다 결론 난공불락의 SEO 요새를 건설하라 지금까지 티어 링크 빌딩의 원리와 구축 전략에 대해 심도 있게 살펴보았습니다 티어 링크 빌딩은 단순한 링크 늘리기가 아니라 웹사이트의 권위를 체계적으로 설계하고 홈페이지 상위노출 에 더욱 가까워집니다티어 1의 정교함 티어 2의 확장성 티어 3의 폭발력을 조화롭게 운용할 때 여러분의 머니 사이트는 그 어떤 경쟁자도 넘볼 수 없는 강력한 힘을 갖게 됩니다 물론 이 과정은 많은 시간과 노력이 필요하며 고도의 기술적 이해를 요구합니다 하지만 쉬운 길에는 항상 경쟁자가 붐비지만 어려운 길에는 경쟁자가 드물다는 사실을 기억하십시오 티어 링크 빌딩이라는 강력한 무기를 장착하고 인내심을 가지고 시스템을 구축해 나간다면 여러분은 구글 검색 결과라는 전쟁터에서 불패의 신화를 쓰게 될 것입니다 지금 바로 여러분만의 링크 제국을 건설하십시오 왕관의 무게를 견디는 자만이 최고의 자리에 오를 수 있습니다

구글 seo 백링크 상위노출로 가는 지름길

구글 에스이오의 심장부인 백링크의 본질과 필승 전략구글 검색 엔진이 태동하던 시기부터 지금까지 변하지 않는 단 하나의 진리는 바로 백링크가 웹페이지의 가치를 증명하는 가장 강력한 수단이라는 사실입니다 지난 십 년간 구글의 알고리즘은 수천 번 업데이트되었지만 페이지랭크라고 불리는 링크 기반의 평가 시스템은 여전히 검색 순위를 결정하는 핵심 엔진으로 작동하고 있습니다 다만 그 방식이 과거의 단순한 숫자 싸움에서 고도화된 신뢰도 평가로 진화했을 뿐입니다 구글 홈페이지 상위노출 을 목표로 하는 마케터와 사이트 운영자들을 위해 구글이 진짜 사랑하는 백링크 전략이 무엇인지 그리고 어떻게 설계해야 검색 결과 일 페이지를 장악할 수 있는지 그 정수를 담아 정리해 드립니다페이지랭크 알고리즘의 진화와 신뢰도 기반의 평가초창기 구글은 링크의 개수가 많은 페이지를 무조건 좋은 문서로 판단했습니다 하지만 이를 악용한 스팸 사이트들이 기승을 부리자 구글은 펭귄 알고리즘을 도입하여 링크의 질을 따지기 시작했습니다 이제 구글은 누가 링크를 걸어주었는지를 봅니다 서울대학교 홈페이지에서 걸어준 링크 하나가 이름 없는 블로그 천 개에서 받은 링크보다 훨씬 더 높은 점수를 받는 이유가 바로 여기에 있습니다 구글 seo 백링크 전략의 첫 단추는 내 사이트를 지지해 주는 추천인이 얼마나 공신력 있고 믿을 수 있는 곳인지를 파악하는 것에서 시작되어야 합니다 신뢰는 전이된다는 원칙이 구글 검색의 기본 철학입니다주제 연관성이 만드는 문맥적 가치의 중요성구글의 인공지능은 문맥을 완벽하게 이해합니다 내 사이트가 요리 레시피를 다루는데 자동차 정비 사이트에서 백링크가 들어온다면 구글은 이를 매우 수상하게 여깁니다 반면에 유명한 요리 블로그나 식품 관련 뉴스 사이트에서 내 글을 인용하며 링크를 걸었다면 이는 매우 자연스럽고 가치 있는 추천으로 받아들여집니다 따라서 무작정 도메인 점수가 높은 곳을 찾아다닐 것이 아니라 나와 같은 산업군에 있거나 내 콘텐츠를 필요로 하는 연관 분야의 사이트를 발굴하는 것이 핵심입니다 문맥이 맞는 곳에서의 링크는 검색 순위뿐만 아니라 구매 전환율이 높은 진성 방문자를 데려오는 일석이조의 효과를 냅니다다양성과 자연스러움을 추구하는 링크 프로필 구축건강한 숲에는 큰 나무와 작은 풀 그리고 다양한 꽃들이 어우러져 있듯이 건강한 웹사이트의 백링크 프로필 또한 다양해야 합니다 특정 유형의 사이트에서만 링크가 쏟아지거나 모든 링크의 앵커 텍스트가 똑같다면 이는 인위적인 조작의 증거가 됩니다 뉴스 기사 블로그 포럼 소셜 미디어 위키 등 다양한 출처에서 링크가 발생해야 하며 앵커 텍스트 또한 브랜드명 유알엘 주소 일반적인 단어 키워드가 적절한 비율로 섞여 있어야 합니다 구글은 가장 자연스러운 상태를 좋아합니다 인위적으로 패턴을 만들려고 하지 말고 다양한 경로를 통해 내 콘텐츠가 확산되도록 유도하는 것이 가장 안전하고 확실한 전략입니다양질의 콘텐츠가 스스로 링크를 부르는 링크 베이트 전략억지로 링크를 만들러 다니는 것은 하수입니다 고수는 남들이 자발적으로 내 글에 링크를 걸게 만듭니다 이를 링크 베이트 즉 링크 미끼 전략이라고 합니다 다른 사람들이 글을 쓸 때 인용하고 싶어질 만한 독보적인 콘텐츠를 만드는 것입니다 예를 들어 업계 현황을 분석한 통계 자료나 복잡한 개념을 알기 쉽게 정리한 가이드북 혹은 직접 실험을 통해 얻은 데이터 등은 다른 창작자들에게 훌륭한 참고 자료가 됩니다 이렇게 콘텐츠의 힘으로 얻은 자연 발생적 백링크 는 구글이 가장 높은 점수를 부여하는 최상급 링크이며 시간이 지날수록 그 가치가 기하급수적으로 늘어나는 자산이 됩니다지속 가능한 성장을 위한 화이트햇 방식의 고수구글 에스이오에는 지름길이 없습니다 단기간에 순위를 올리기 위해 링크를 사거나 프로그램을 돌리는 블랙햇 방식은 결국 구글의 징계를 피할 수 없습니다 십 년 동안 롱런하는 사이트들의 공통점은 시간이 걸리더라도 정석대로 가는 화이트햇 방식을 고수했다는 점입니다 직접 발로 뛰어 관계를 맺고 게스트 포스팅을 통해 양질의 정보를 제공하며 커뮤니티에서 진정성 있게 소통하는 과정이 필요합니다 이러한 노력들이 차곡차곡 쌓여 도메인의 권위 가 되고 그 권위는 어떤 알고리즘 변화에도 흔들리지 않는 강력한 방패가 되어줍니다 백링크는 기술이 아니라 정성이며 요행이 아니라 노력의 산물입니다정기적인 백링크 감사와 리스크 관리마지막으로 백링크는 구축하는 것만큼 관리하는 것도 중요합니다 경쟁사의 악의적인 공격으로 인해 저질 링크가 내 사이트에 붙을 수도 있고 기존에 좋았던 사이트가 스팸 사이트로 변질될 수도 있습니다 따라서 구글 서치 콘솔과 같은 도구를 활용하여 정기적으로 내 사이트의 백링크 상태를 점검해야 합니다 품질이 낮은 링크가 발견되면 구글에 거부 신청을 하여 내 사이트와 연결을 끊어야 합니다 끊임없이 잡초를 뽑아주고 물을 주는 정원사처럼 내 사이트의 링크 환경을 청정하게 유지하는 것이야말로 구글 상위노출을 오랫동안 유지하는 비결입니다 구글은 관리받는 사이트를 좋아하며 그 노력에 반드시 트래픽으로 보답합니다 더상승마케팅 은 보다 완벽하고 체계적인 디자인으로 상위노출에 더욱 최적화 되어있습니다 자세한 내용은 링크를 통해 확인해보세요

백링크 마케팅 전략에 대해서 알려드리겠습니다

백링크 마케팅 전략이 필요한 이유백링크는 단순한 SEO 기술이 아니라 마케팅 전략의 일부입니다 많은 사람들이 백링크를 검색엔진 을 속이기 위한 기술로 오해하지만 실제로 장기간 상위에 노출되는 사이트들을 분석해보면 백링크는 철저히 브랜드 신뢰와 노출 확장을 위한 마케팅 수단으로 활용되고 있습니다 검색엔진은 결국 사용자의 선택을 대신해주는 필터 역할을 하며 이때 외부에서 얼마나 많이 얼마나 자연스럽게 언급되는지가 핵심 판단 기준이 됩니다 따라서 백링크 마케팅 전략이란 링크를 많이 만드는 방법이 아니라 어떤 메시지를 어떤 경로를 통해 어떤 타이밍에 전달할 것인지를 설계하는 과정이라고 보는 것이 맞습니다백링크 마케팅의 출발점은 목표 설정백링크 마케팅을 시작하기 전에 반드시 정리해야 할 것은 목표입니다 단순히 순위를 올리고 싶은지 특정 키워드를 장악하고 싶은지 아니면 브랜드 인지도를 키우고 싶은지에 따라 전략은 완전히 달라집니다 예를 들어 단기적인 키워드 상승이 목적이라면 공격적인 링크 배치가 필요할 수 있지만 장기적인 브랜드 구축이 목적이라면 안정성과 자연스러움이 최우선이 됩니다 목표 없이 진행되는 백링크 작업은 방향 없는 비용 소모에 불과하며 결과 역시 일관되지 않습니다 지난 10년간 실패한 프로젝트들의 공통점은 명확한 목표 없이 링크만 늘렸다는 점이었습니다사이트 단계별 백링크 마케팅 전략백링크 전략은 사이트의 성장 단계에 따라 달라져야 합니다 신규 사이트는 무엇보다 신뢰의 기초를 쌓는 것이 중요합니다 이 단계에서는 웹 2점 0 백링크 디렉토리 등록 소셜 시그널과 같은 안전한 링크를 통해 검색엔진에게 사이트의 존재를 알리는 것이 우선입니다 어느 정도 색인과 노출이 안정화된 이후에는 게스트 포스팅이나 에디토리얼 백링크를 통해 주제 전문성을 강화해야 합니다 이후 경쟁 키워드 구간에 진입했을 때 비로소 PBN과 같은 고급 전략을 제한적으로 활용하는 것이 이상적인 흐름입니다 이 순서를 무시하고 초기에 강한 링크를 사용하는 것은 매우 위험합니다키워드 중심 백링크 설계 전략백링크 마케팅에서 가장 중요한 설계 기준은 키워드입니다 모든 페이지에 동일한 방식으로 링크를 보내는 것은 효과적이지 않습니다 핵심 키워드는 집중적으로 관리하고 보조 키워드는 자연스럽게 확장시키는 구조가 필요합니다 이를 위해서는 페이지별 역할 분리가 선행되어야 합니다 유입용 콘텐츠 페이지 전환용 페이지 브랜드 신뢰 페이지를 구분하고 각 페이지에 맞는 백링크 유형을 배치해야 합니다 예를 들어 정보성 콘텐츠에는 자연스러운 에디토리얼 링크를 전환 페이지에는 신중하게 설계된 고품질 링크를 사용하는 것이 효과적입니다백링크 마케팅에서 콘텐츠의 역할콘텐츠는 백링크 마케팅의 토대입니다 아무리 좋은 링크를 만들어도 연결되는 페이지의 콘텐츠가 부실하다면 효과는 제한적입니다 반대로 콘텐츠가 탄탄할수록 동일한 링크도 훨씬 큰 힘을 발휘합니다 백링크 마케팅을 성공적으로 운영하는 사이트들은 콘텐츠를 단순한 글이 아니라 링크를 받을 수 있는 자산으로 설계합니다 다른 사이트에서 인용하고 싶어질 만큼 정리된 정보 데이터 사례 분석이 포함된 콘텐츠는 자연스럽게 링크를 끌어당깁니다 이것이 가장 이상적인 백링크 마케팅 형태입니다 콘텐츠는 홈페이지 상위노출 에 있어서 가장 중요한 요소 중 하나입니다백링크 유형별 마케팅 활용 전략에디토리얼 백링크는 브랜드 신뢰와 권위 구축에 사용됩니다 이는 마케팅 메시지를 간접적으로 전달하는 역할을 하며 장기적인 자산이 됩니다 게스트 포스팅 백링크는 특정 키워드에 대한 전문성을 강화하는 데 효과적이며 콘텐츠 마케팅과 결합했을 때 시너지가 큽니다 PBN 백링크는 경쟁이 치열한 구간에서 순위를 밀어올리는 전략 카드로 활용되며 반드시 다른 자연 링크 구조 위에 얹어야 합니다 웹 2점 0과 소셜 링크는 전체 링크 구조의 자연스러움을 보완하고 확산 속도를 높이는 역할을 합니다 각 링크 유형은 목적이 다르며 이를 혼합하는 것이 백링크 마케팅의 핵심입니다백링크 마케팅에서 타이밍의 중요성백링크는 언제 만드느냐에 따라 효과가 달라집니다 콘텐츠가 발행된 직후 적절한 외부 링크가 연결되면 검색엔진은 해당 페이지를 중요 콘텐츠로 빠르게 인식합니다 반면 오랫동안 방치되던 페이지에 갑자기 많은 링크가 몰리면 부자연스러운 신호로 해석될 수 있습니다 따라서 백링크 마케팅은 콘텐츠 발행 일정과 연동되어야 하며 일정한 리듬을 유지하는 것이 중요합니다 자연스러운 성장 곡선을 그리는 링크 증가 패턴이 가장 안정적인 결과를 만듭니다백링크 마케팅 성과를 측정하는 기준백링크 마케팅의 성과는 단순히 순위 하나로 판단해서는 안 됩니다 키워드 노출 범위 트래픽 변화 색인 속도 브랜드 검색량 사용자 행동 지표까지 함께 분석해야 합니다 특히 브랜드 검색량이 증가하고 직접 유입이 늘어난다면 이는 백링크 마케팅이 검색엔진뿐 아니라 사용자 인식에도 영향을 주고 있다는 증거입니다 이러한 변화는 장기적인 경쟁력을 의미합니다백링크 마케팅에서 피해야 할 전략가장 피해야 할 전략은 단기 성과에 집착하는 것입니다 저가형 대량 링크 자동 생성 프로그램 무작위 디렉토리 등록은 일시적인 변화를 만들 수는 있어도 장기적으로는 반드시 문제를 일으킵니다 또한 모든 키워드에 동일한 앵커 텍스트를 사용하는 것도 위험합니다 검색엔진은 이러한 패턴을 조작으로 인식하며 신뢰도를 낮춥니다 백링크 마케팅은 항상 절제와 균형이 필요합니다장기적인 백링크 마케팅 전략의 핵심장기적으로 성공하는 백링크 마케팅의 핵심은 지속성 자연스러움 그리고 연관성입니다 검색엔진 알고리즘은 계속 변하지만 이 세 가지 원칙은 변하지 않습니다 꾸준히 콘텐츠를 만들고 그에 맞는 링크를 자연스럽게 연결하며 사용자에게 실제 가치를 제공하는 사이트는 어떤 업데이트에도 크게 흔들리지 않습니다 지난 10년간 안정적으로 상위에 머무른 사이트들은 모두 이 원칙을 지켜왔습니다백링크 마케팅 전략의 최종 정리백링크 마케팅은 단순한 링크 작업이 아니라 브랜드를 키우는 전략입니다 검색엔진을 설득하는 동시에 사용자의 신뢰를 얻는 과정이며 이 두 가지가 함께 작동할 때 폭발적인 성과가 만들어집니다 단기적인 순위 상승에만 집중하기보다 장기적인 시장 점유를 목표로 백링크를 설계해야 합니다 지금 이 순간에도 경쟁자들은 백링크를 통해 신뢰를 쌓고 있습니다 더 늦기 전에 전략적으로 접근해야 하며 제대로 설계된 백링크 마케팅은 시간이 지날수록 여러분의 가장 강력한 무기가 될 것입니다 더 자세한 내용은 더상승마케팅 에서 확인 할 수 있습니다

한국 IT 용어 이야기 (11) - "플랫폼"

내가 쓰는 플랫폼은 어떤 걸까..? 지금 돌이켜 보면 거짓말같은데, 빅테크에 있던 10여년 동안 딱히 신경 쓰지 않았었더랬지만, 밖에 나오면서 꽤 많이 '플랫폼' 이라는 말을 접하게 된다. 살짝 생각해 보면, 바깥이기도 하고 한국이라서 더 그랬던 거 같기도 하다. 플랫폼 기업이라는 말도 꽤 들리고, 국가 과제로 혹은 제안서 등에서 무슨무슨 플랫폼을 만들겠다고 하는 건 특히 많다. 회사마다 사내에 데이터 플랫폼이라는 걸 여러 곳에서 만들고, 뭔가 비슷비슷해서 또 다른 식의 구체화가 되는 등... 살짝 삐뚤게 보면, 뭔가 조금 더 있어 보이는 목적으로 꽤 남용되고 있는 단어라는 개인적인 생각이다.일단 10여년 전의 김수보 선배님의 글이 발견됨..https://subokim.wordpress.com/2013/01/31/platform-story/ 플랫폼 - 기차 / 터미널일반적인 사전적 의미부터... (누군가가) 플랫폼에는 길을 닦아 놓았으니 이 위에 운송 서비스를 하시오.. 버스든 기차든 어디로 가는 거든 등... 기본적으로 여행객과 운송 업체가 연결될 것이고, 사람이 아니고 물건들끼리 '자유로이' 서비스들을 운영하고, 아마도 수수료를 철도 유지비로 내는 등의 것들이 고려될 수 있겠다. 쉽게는 직행, 완행 등 다양한 서비스들이 구현될 수 있겠고. '쉽게' 라는 게 키워드이기도 하겠다. 그래서 플랫폼의 일부인 기차역은 도심에 대개 위치하게 되고, 주변의 숙박업, 외식업 등의 간접적인 효과를 끼치게 한다.여기서 일단 짚고 싶은 건 보이지 않는 곳에서 많은 일들이 벌어지고 정의되어야 한다는 부분이다. 최소 도시 혹은 나라 스케일의 판단이 있어야 하고, 땅을 사서 길을 만들고 광고나 운영비 등이 담보되거나 혹은 세금으로 처리되거나 등등의 일들이 있겠다. 기관차의 유지 보수는 해당 사업자들이 하겠지만, 철로의 유지 보수, 설계 등은 플랫폼 업체의 담당이고 이를 쓰는 사용자들에게는 보이지 않는 영역이어야 하겠다. 여기까지가 아주 원초적인 의미의 플랫폼. 모바일 플랫폼하드웨어 플랫폼이라는 걸로 살짝 지나간 기억이 있긴 한데, 리눅스냐 윈도우즈냐, OS 가 뭐냐 GUI 가 뭐냐 정도가 간단한 논의거리였더랬고, Symbian OS, S60 Platform 이라는 정도로 처음 제대로 접하게 된다. OS 위에 GUI layer, system layer, 각종 middleware 등이 깔린 상태를 다 담당하고, 그 위에 application 만 만들면 되게 해 놓은 상태까지..이 연장선 상에 아이폰과 안드로이드가 세상에 나왔을 때 모바일 플랫폼이라는 걸로 정리되었더랬다. 이름이 주는 오해가 있지만, S60 의 소멸 이후에 iOS 와 Android 는 꽤 오랫동안 모바일 플랫폼으로 불렸다. 모바일 장치를 구매한 사용자, 앱의 형태로 서비스를 제공하고 싶어 하는 개발사, 하드웨어를 만드는 업체들 등이 플랫폼을 만든 구글 혹은 애플이 이미 만들어 놓은 것들 위에 할 수 있게 한 것일테다. 플랫폼 을 담당하는 업체들은 아래의 것들을 모두 담당해야 하겠다.운영체제 + RuntimeApplication framework + APIs개발 도구들앱을 배포할 수 있게 만드는 장터 + 인스톨러들하드웨어 폼팩터 + 에코시스템 플랫폼 - 배달 앱살짝 놀랐지만, 쿠팡, 배달 음식 서비스에서 배달을 업으로 삼는 분들을 플랫폼 노동자들이라고 부르고 있었다. 우버 드라이버 = 플랫폼 노동자 의 개념이었던 것도 놓치고 있었던 부분이고, 개별 노동자들의 일감을 '쉽게' 만들어 줄 수 있게 하는 역할을 하고 있고, 우버와 쿠팡 등은 그 의미에서 플랫폼 기업이 맞겠고, 그 위에 차량 이용 서비스 , 차량 제공 서비스 등이 구현되는 모습이겠다. 살짝 까칠하게 엄밀하게 이야기하자면, 회사에 고용이 되어 버리게 되면 그건 '플랫폼'으로서의 의미가 아니겠다는 생각이다.위의 기찻길 플랫폼 만큼 일반적이거나 공공의 성격이 굳이 있진 않지만, 서로 제공하려는 서비스와 돈의 흐름들을 되게 만들어 주는 영향이 있다 하겠다. 우버 등의 경우 차량 이용자, 차량 제공자가 참여할 수 있게 하고, 배달 앱들의 경우, 식당 주인, 음식 주문자, 배달 서비스 제공자 들이 연결되겠다. 그 사이에서 필요한 배차, 물류, 주문 등등을 플랫폼 기업들이 담당하고 있겠다. 플랫폼 노동자 = 배달업 종사자 로 지나치게 일반화되는 건 많이 불편한데, 배달업 뿐 아니라 프리랜서, 가사도우미 등 불완전한 고용 형태들을 가진 사람들이 일을 찾는 곳들은 여러 의미로 플랫폼 노동자로 불리고 있다. 데이터 플랫폼 / 데이터 플랫폼 서비스 ?기업들 내부에 하나씩 있는 팀 혹은 프로젝트들 혹은 ### 구축 으로 불리는 여러 과제들의 경우 scope 들이 많이 달라진다. 요구 사항 특히 기대치가 다른 경우들이 대개 여기에 해당하는데, database 에 테이블 하나만 운영해도 되는 경우부터 UI 를 가지고 현란한 대시보드들을 자유자재로 만들 수 있게 기대하는 것까지 다양하다. 게다가 큰 꿈들을 가지고 사내에 모든 데이터들을, 혹은 버티컬/도메인 상관 없이 다 어떻게 해 주겠다.. 라고 하지만 실제 사용자들이 필요한 건 주문형으로 만들어 진 채팅 서비스이지 플랫폼이 아닌 경우가 꽤 많다. 앞의 플랫폼들을 참고한다면 공급자가 할 수 있는 것들, 수요자가 필요한 것들 혹은 수요자를 위해 누군가가 이 위에해야 하는 것들이 있는 경우 등 오해가 많이 생기는 영역이겠다.지난 사례들을 통해서 DX, AX 고민들을 할 때 꽤 나타나는데, 기껏 복잡한 걸 다 만들어 놓아도 결국 excel 로 다운로드 받기 위해 전용 화면들이 필요하다든지, 주문형 대시보드를 만들기 위해 현장에 있는 사람들이 새로운 교육들을 배워야 하는 일들이 벌어진다든지, 어차피 새로운 데이터들이 들어올 때 수동으로 할 거면서 뭔가 저절로 될 것처럼 포장되어 있다든지 등... 특히 플랫폼과 서비스가 동시에 보일 때 많이 불편함을 느낀다. 기억을 더듬어 보면 marketplace , framework , library , solution 등의 이름들이 꽤 많이 섞여서 나오게 된다. 서로 같은 이야기를 하고 있는 건가?상대적으로 서비스라고 하는 것도 사실 꽤 최근에 쓰이는 개념이리라.. 예를 들면 구글 검색은 서비스이고 유튜브는 플랫폼이고, 광고는 플랫폼이고 등등... 굳이 여기서 말 가르기를 해야 하나 싶다가도 서비스가 주는 명확함이 대화들을 이끌어 나가는 걸 지지하는는 편인데, 그래서인지 개인적으로는 플랫폼 자체는 실체가 없는 것이라는 선입견이 꽤 있다. 맨 처음 예제로 간다고 하면 플랫폼 사업의 근간은 도로 깔고 철도 연결하는 업인데, 서울에서 부산에 그래서 언제 뭘 타고 가야 하느냐와의 대화를 하고 있는 셈일테다. 용어들의 간극이줄어드면 하는 바램이다. 부록 : AWS / GCPAmazon은 Amazon Web Service로 쓰는데, Google은 Google Cloud Platform 으로 쓴다. 두 회사 솔루션의 경우 platform 도 맞고, service 도 맞을 거 같은데, MS 는 아예 Azure 라고 피해 간다. 다만 cli 의 경우 아래처럼 다른데, AWS 가 세련되어 보인다.$ aws login$ gcloud auth login$ az login 구글의 경우 Google Web Service 는 오래전부터 구글 검색 프론트엔드가 쓰던 이름이어서 GWS 를 쓰지 못했을 것 같은데, 지금은 GWS = Google Workspace 로 쓰이고 있다. Google Cloud Service 라고 쓰고 싶을 수도 있었겠으나 Google Cloud Storage 가 꽤 오래 전부터 GCS 를 잡고 있었을 테니... 밖에서는 gs:// 로 쓰고 있는 걸 보면... 이름 짓는 건 매우 어렵겠다. 특히 쓸만한 이름들은 이미 다 누군가가 쓰고 있어서 더 어려운 것도 그러하겠다.나를 포함한 엔터프라이즈에서 몇몇 주관적인 평가들로는 service 를 사용하는 고객의 만족도가 platform 을 사용하는 고객의 만족도가 높다 한다. 특히 뭔가가 잘 안 될 때 service 는 도움을 청할 곳이 있고, platform 의 경우 내가 스스로 풀어야 하나 등의 간극이 있다. 

wikipedia 25주년을 맞이하며 - 나의 첫번째 백과 사전

Wikimedia 가 창립 25주년을 맞이하며( https://wikimediafoundation.org/wikipedia25/ ) 주요 BigTech 들과의 협업을 뉴스로 접하게 되었다. ( https://news.nate.com/view/20260116n08571 ). 주로 위키피디아지만, 검색 현업에 있을 때, 혹은 그 이전부터 접했으니 나도 20년 정도는 열혈 사용자였던 거 같고 여러 가지 연관된 생각과 이야기들. 사용자의 시각에서먼저 꽤 오랫동안 접속할 때마다 donation 을 강요(?)하는 배너를 보며 한편으로 마음이 많이 불편했는데, 먼저 그 걱정은 덜게 되어 다행이라는 생각이다.초기 미국 이민자의 삶을 살 때 가장 믿고 의지했던 사이트. 구글에서 검색을 하고, 그럴 듯한 위키피디아 페이지가 결과에 보이면 많이 안심하며 무조건 읽으면서 배워 나갔다. 연예계 소식, 역사 이야기, 각종 수학 공식들까지. 어린 시절 집 어딘가에 있었던 백과사전이 이런 것이었겠군 싶었던 내용들. 영어 공부도 이걸로 했었고, 인용된 링크들이 믿음직하던 것들도 덤.2026년 현재 여전히 방문자 수 세계 10위 이내에 드는 초대형 사이트. 사람들이 좋아하는 만큼 AI 들이 좋아하는 것도 당연하겠고, 아마도 나 같은 사용자 덕에 구글 같은 검색 엔진의 도움도 있었을 테니 그것도 당연함. 광고 없이 파트너십과 재단으로 운영된다는 것이 여전히 믿기지 않는다. 몇몇 예민한 내용들은 가짜뉴스의 소재로 사용되기도 한다지만, 특별한 정치적 소재가 아니고서는 믿고 보던 사이트. 개발자의 시각에서web page , dump , API 접근 , database export 지원까지.. 이렇게까지 친절해도 될 일인가 싶을 정도로 완벽한 방법들을 제공한다. 일단 영어권에 필요한 내용들은 다 있고, flat 한 directory 구조이지만 URL 과 문서의 제목을 잘 찾아 내기만 하면 자연스레 navigate 할 수 있다. 웹 페이지 펼쳐 놓고, 터미널 비교하기도 너무 수월하고.. 페이지 자체가 보통 너무 길지도 너무 짧지도 않게 되어 있는데, 이건 내가 훈련이 되어서 그렇다고 하겠다.구글 검색 현업에 있을 때 사내에 daily dump 가 있어서 공공재로 사용했던 기억들이 있고, 저 flat 한 구조는 freebase 와 엮이면서 시너지를 내고, 구글의 knowledge base / knowledge panel 에 근간으로 쓰였더랬다. 사이트 자체의 정보들이 다들 쓸모 있는 것들이어서 몇몇 버티컬을 같이 디자인하며 열심히도 들여다 본 기억이다. 물론 지금도 LLM 들 pretrain 에 commoncrawl 에 더해 제일 먼저 참조되는 소스로 이용된다. 별도의 유사 검색 엔진을 만든다고 한다면 당연히 처음으로 사용해야 할 데이터임에 틀림 없다. 구글 선수 시절 기억들정보들이 충돌이 날 때 그를 해결하는 source of truth 로 자주 이용되었고, '잘 된' 영어의 참조로 이용하였더랬다. no wikipedia index 는 좋은 baseline index 로 이용되었고, 뭔가 잘 모르겠다 싶으면 구글 검색에 물어 보거나 wikipedia dump 에서 찾는 방식으로 많이 이용되었다. 인용된 링크들도 의미가 있었고, 잘 만들어 진 고품질의 문서, 사이트에 해당했다.당연하게 App indexing 과제에서 처음으로 커버한 100개의 사이트에 포함되어 있었고, 웹 세상과 다르게, 모바일 세상에서 많이 쓰이지 않는 wikipedia 앱을 어떻게 다루어야 하는 고민을 했더랬다. 웹이 너무 잘 만들어져 있어서 앱이 쓸모없어진 그런 경우라 하겠다. 당시 검색 팀에서 경쟁적인 위치에 있던 mobile rendering , progressive web app 등도 앞다투어 제일 먼저 다루던 사이트였다.꽤 오래 만졌던 영화 같은 몇몇 도메인들의 경우에는 공공의 적으로 위치하기도 했던 기억이다. 제일 많이 쳤던 "Tom Hanks" , "Forrest Gump" 등의 쿼리에 대해 마음으로는 imdb.com 이 올라와 주기를 기대하며 어떻게 하면 저 wikipedia 를 이길 수 있을까 고민도 많이 했었더랬다. 한편으로는 그런 실험들을 돌리면, 여지없이 사용자들은 wikipedia 를 더 좋아했더랬다. 참고로 한국의 경우 나무위키와 시네 싸이드들이 더 위에 올라와 있다. 한글에 대한 아쉬움들눈높이가 영어에 있어 더 그렇겠지만, 한글 contents 는 많이 부족해 왔다. 위키피디아가 한국 사용자들에게 알려져 쓰였으면 하는 시기에 네이버 검색이 네이버 지식인과 네이버 원박스 들과 함께 흥했고, 당시에 구글 스타일의 검색이 고전을 하게 된 이유와도 닿아 있다. 당시에는 선수로 참여하면서 승부에서 진 셈이기에 아쉬운 마음이 많다. 당시 방법론으로 번역 품질을 고민하기에도 같은 내용을 여러 언어로 설명하기에 제일 표본이 되는 게 위키피디아였고, 그래서 EN-JA 가 EN-KO 보다 번역 품질이 높았던 것들도 연관이 있었다 하겠다.이후 살짝 다르지만 나무위키가 이 포지션을 잡게 되며, 거친 단어들이었지만 구글 검색의 품질이 올라가고, 그에 맞추어 한글 위키피디아 내용들도 좋아진 기억이다. 다행이기도 하고, 이제 원박스나 쇼핑 관련된 게 아닌 경우 검색 결과 페이지가 밀린다는 평가는 거의 없는 거 같다. 참고로 나무위키는 라이센스가 다르고 위의 개발자 친화적인 방법들이 제공되지 않는 일종의 민간 기업에 해당한다. 언제 어떻게 사라질 지 모르는... 아슬아슬하달까..최근 소버린 논의 등에서 '한글로 잘 정리된 문서' 영역에 대한 아쉬움이 많다. 영어의 경우 너무나 손쉽게 wikipedia dump, 한 달에 한 번씩 업데이트 되는 commoncrawl dump 등 공들여 만든 믿을 만한 데이터들이 너무 쉽게 접근 가능한데, 한글에 대해서는 '네이버에 있으니까', '블로그에 있다니까' 등에 synthetic 으로 만들어 낸 데이터들에 대한 이야기들만 조금씩 이야기하게 된다. language model 을 만든 이후 agent 나 RAG 등이 어딘가에 검색을 시도하려 한다 하면 그건 또 그것대로 같은 사이클을 돌게 되며 아쉬운 상황들이 벌어질 거 같다. 재단이 안 되면 세금/연구 기관들이나 기업들이 챙길 수 있을까..? 

[혼공클로드] 커스트마이즈

[혼공클로드] 1장 확인 문제

p33바이브 코딩 도구의 유형 웹 기반 챗봇: ChatGPT, Claude, Gemini Web UI모델 선택형: Cursor, Replit, Windsurf전용 모델형: Claude Code, Gemini CLI개념(용어)1) 바이브 코딩2) AI 어시스턴트3) 모델 선택형 도구4) 전용 모델형 도구 p54~p55242게시Customize 

[혼공클로드] 나의 첫 페이지 만들기

클로드 코드를 실행하여 "나의 첫 페이지 만들기" 실행