블로그

한국 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 

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

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