HJH 기술블로그

운영계획 - 2

하루 최대 방문자 수 : 359
주간 방문자 수 변화 : 674 -> 1007

구글 애널리틱스 기준으로는 Direct, Organic Search, Referral, Social을 통한 사용자 획득 경로가 있고 Direct가 드디어 80% 밑으로 내려왔습니다. 78%네요. 티스토리의 일 방문자 수는 9~350 명으로 편차가 매우 심하고 그 주요 원인은 포럼에 글을 쓰고 댓글을 다느냐에 있었습니다. 즉, direct의 100%는 포럼이라고 할 수 있겠네요. 현재는 전체 방문자 수가 적기 때문에 direct에 의지할 수 밖에 없는 상황입니다. 글의 수를 늘여 단어수를 늘여야 하고 Organic Search 를 늘이는 수 밖에 없지요.
다음 일주일 운영 계획은 우선, 만든 블로그 취지에 크게 벗어나지 않도록 개발 관련 내용을 올리는데 집중을 해야겠습니다. 티스토리 설정에서 글 번호로 되어 있는 URL(주소)를 글 제목으로 바꾸었습니다. 구글 애널리틱스에서 방문한 글도 보여주는데 번호로 되어 있으니 제가 다시 번호를 쳐서 어떤 글이 인기 있었는지 확인을 해야 하기 때문입니다.

운영계획  - 1

티스토리에 구글 애널리틱스를 달았습니다. analytics 달아보시면 

친절한 설명이 나옵니다.
메뉴 중 [획득]이 유입 경로 인데요. Direct가 80%가 나오네요.
잘 알려지지도 않은 블로그를 80%나 들어온다는 것은
포럼 밖에는 없는 것 같습니다. -> 꾸준히 댓글 달고, 글을 써야 겠네요! (아직 광고는 없지만... ^^;;)
Orgarnic Search 13.6%로 올랐네요. 3~4%더니 ... 글이 많아지면서 조금씩 검색이 되는 것 같습니다. 총 방문자 1300 정도 인데요. 다음 메인에 글이 한번 노출 되었을 때 글 하나가 하루 12만씩 찍었던 것을 기억해보면 다작보다는 하나 제대로 쓰는게 좋다는 생각입니다. 그 당시는 차를 들고 제주도 가는 방법을 포스팅 했었는데,
며칠 뒤 비슷한 글이 올라오면서 조회수가 1000대 100대로 금방 떨어지더군요. IT쪽 글은 새로 써도 비슷한 글이 있기 힘들지만 검색해 보는 사람 자체가 적기 때문에
조회수가 별로 안됩니다. 대신 다른 글도 함께 보는 경우가 많아서 이탈률은 줄어듭니다. -> 사람들이 관심가지는 분야를 잘 보고 완전히 새로운 글을 잘 써서 포털 메인에 뜨도록 노력해야겠네요. 지금 생각하는 분야는 life(걍 먹고 노는거 찍기), 여행, 언어 교육쪽 입니다. 블로그 성격은 버려지겠으나 직접 유입은 대부부분 작은 포털들이 시장을 먹죠(클리앙이나 인벤 따위의 류, 나쁜 뜻 아님, 사전식)
지금 당장은 아이디어도 없으니 꾸준히 이전 블로그 글을 옮기고 포스팅을 해야겠습니다. 먹거리 올리는 거야 재미있으니 하는거고, 여행의 경우는
조금 신경써서 테마별로 적어야 겠네요.

사랑을 인정하고 아기를 만들 준비가 되어야 해

그게 사랑이거든

처음 태어난 딸아이를 처음 안는 순간

그렇게 작고 연약할 수가 없어

작은 심장 박동은

이 세상에서 그보다 더 사랑스러운 게 없지

딸을 제대로 키우고 늘 곁에서

넘어질 때 잡아 주길 바라게 돼

아무것에도 다치지 않게

팔이 부러지거나

악몽을 꾸거나

상처받지 않게

그 뒤로 일기가 바뀌며 책이 되었다. 이 때부터 책 쓰기 연습 시작

공부의 깊이

2016년. 모든 것에는 시간 개념이 들어간다. 1704년에 우리는 존재하지 않았던 것과 같다. 다른 예로 누군가를 뜨겁게 사랑했고, 만약 지금 사랑하지 않는다면, 그 결과만 보고 "사랑한 적 없다"가 맞는 표현이 아니라. "특정 시간에는 세상 누구보다 사랑했다"가 맞는 표현이다. 그래서 서두에 2016년임을 분명히 밝히고 시작한다.

그레고리 페렐만

현존하는 수학자 중 그 어떤 저명한 수학자라 할지라도 후대에 그레고리 페렐만의 이름보다는 위대하지 못할 것이라고 생각한다. 프로그래머가 공부하다 보면 결국 전기의 법칙, 또 수학에 귀결된다. 그러나 수학을 잘한다고 해서 그레고리 페렐만처럼 될 수는 없다. 결국 공부의 깊이를 정해야 할 때가 온다.

Borland사의 Together

십 년도 더 된 이야기이다. 볼랜드社의 투게더를 이용할 기회가 있었다. 사실 필자의 모든 경험과 지식은 대부분 아버지와 모교의 옥교수님 덕분에 만들어진 것이다. UML을 그리면 바로 코드로 뽑아주는 툴이었다. 난 혁명이라고 생각했는데 주변에서는 여전히 클래스 다이어그램, 시퀀스 다이어 그램을 그리고 있고 Eclipse 쓰는 친구들은 OMONDO가 뭔지도 모른다. 최근에는 UML이 뭔지도 모르는 신입 사원들을 만나기도 한다. 그래서 당당하게 말할 수 있다. 그냥 몰라도 된다.

그림은 그림일 뿐. 뭘 만들어야 하고 어떻게 소통해야 할지 아는 것이 중요하다.

디자인 패턴

디자인 패턴은 대부분 공부하게 될 것인데, 안드로이드 앱을 잘 만들어서 여러 수상 경력이 있는 친구들도 디자인 패턴이 뭔지 모른다. 그런데 이미 그들은 쓰고 있다. 기본 내장 패턴만 해도 MVC, 싱글톤, 팩토리, 빌더, 옵서버 등... 안드로이드에서 구현하는 방식 자체가 패턴을 이용해서 구현하는 방식이다. 앞서 말했듯이 자전거를 타면서 자전거 명칭을 모르는 것과 같다. 몰라도 된다.

알고리즘

필자도 코딩 실력만 믿고 우리나라 최고의 대학을 나와 영어로 강의하시는 교수님께 막말을 한 적이 있다. 물론, 그분은 기초가 뛰어나셔서 단기간에 알고리즘 코딩의 대가가 되셨지만 그때도 결국 "야근"이 답인 것을 알았다. 필자 역시 졸업이 안될 위기를 코딩과 전혀 상관없는 과목인데, 구글링으로 코드가 없는 알고리즘을 3일 밤낮으로 구현하고 사정사정해서 겨우 졸업했다. F -> D 필자가 만난 분들 중에는 암호학이나 알고리즘 관련 과목 전공만으로 박사학위를 받으신 분도 계셨지만 수년간 PM으로만 일하셨다. 지식을 쓸 일이 아예 없었다. 전 직장 대표님의 경우 내가 지금껏 만난 분 중에 가장 기술력이 뛰어나고 개발도 잘하셨었는데 게다가 과학고, 서울대에 해외 석사 극악의 알고리즘의 경우 구현된 라이브러리를 API처럼 당겨서 쓴다고 하셨다. 물론, 그분의 실력으로 분석 못하시진 않겠지만 한 달 수억 버는 프로그램 전체를 혼자 개발하시고 50을 바라보시는 나이에도 라꾸라꾸에서 쪽잠을 주무시며 개발을 하는데 더 이상 어떻게 시간을 낼 것인가?

결국, 디자인 패턴과 알고리즘을 논하기 전에 무엇을 만들 것인가 생각해야 한다. 만들고 싶은 난이도가 미국이라면 비행기라는 방법을 이용해야 하고 가까운 곳이라면 자동차란 방법을 이용해야 한다. 즉, 목적지 설정이 중요하다는 것이다. 공부를 하다가 너무 재미있어서 빠져버리면 학교로 돌아간다. 필자의 멘티들은 대부분 학교로 돌려보냈다. 가족 부양의 이유로 두 번이나 등록하지 못했던 대학원 입학 고지서가 안타까운 마음에 더더욱 그런 방향으로 이끄는 것인지도 모르겠다. - 전면 수정해야 함. -

그러나 이 책에서는 툴과 디자인 패턴과 알고리즘 이야기를 할 것이다.

이유는 이렇다. 그레고리 페렐만을 수천 명 합쳐놓은 천재가 나타났다고 하자. 그럼 그냥 main 문에 원 코딩으로 프로그램을 짜면 된다. 라이브러리도, 개발 방법론도, TDD, 애자일, 구조 설계 방법, UML, 기타 등등 은 IT 용어가 들어가는 대부분 필요가 없다. 그냥 혼자 칩 설계하고 하드웨어 설계해서 모든 펌웨어, 운영체제, 프레임웍, 그리고 그 위에 우리가 사용할 유틸리티와 프로그램 모두 한 번에 짜고 칩에 넣어버리면 된다.

그러나 그런 천재가 없다. 그래서 분업하기로 했다. 소프트웨어 공학이 나왔고, 효율적인 프로그래밍과 개발 방법론, 테스트 케이스나 툴들이 나왔다. 또 상대방에서 설명하기 위해 그림들을 그리기 시작했고 블록 다이어 그램, UML, 시퀀스 다이어그램, 클래스 다이어그램 등을 그리기 시작했다. CVS, SVN, GIT 등도 협업하면서 사람들이 계속 실수하니까 그런 연유로 만들어졌다.

프레임웍도 각자 짜다 보니 사업해서 돈 벌고 싶어 지고, 누구는 오픈소스로 자유를 원해서 다른 노선을 타는 등... 수많은 OS가 생겨났고 어차피 천재가 없는 판국에 경쟁이 붙으면 더 좋은 제품이 나올 거라는 사회적 기대감이 서로 자기 것이 최고라고 말하기 시작했다.

라이브러리로 만들기 껄끄러운 코드 패턴은 디자인 패턴이라고 부르고 서로 맞춰서 쓰며 소통하기로 했고, 만들고 보니 제대로 동작 안 하는 것들이 많아서 수학과 코드의 경계인 알고리즘을 발전시켰다. 그 외 소프트 공학들은 만들어졌다가 이슈화 되었다가 또 사라지고 하는데. facebook이나 youtube처럼 경쟁력 있는 제품이 목표의 root가 아니면 그 아래 노드들은 한 번에 사라지기도 한다.

이 책에서 다루는 것은 프로그래머들끼리 소통의 방법이다. 그런데 입사한 친구들 중에 퀵 소트 바로 짜보라고 했을 때 단박에 짜는 엔지니어가 누가 있으랴? 필자가 알려준 방법대로 매일 코드를 치다 보면 물론, 쉽다. 그러나 그것이 중요한 것은 아니다. 소통의 이유로 배워야 한다. 왜 배워야 하는지 알고 시작하면 좋다.

복면가왕에 나오는 사람들 중 가수들이 모두 오페라 가수는 아니다. 듣기도 괜찮을 정도면 나올 수 있다. 프로그래머도 그런 존재라고 생각한다. 알고리즘의 대가라고 해도 그레고리 페렐만과 이야기할 수 있는 교집합은 얼마 안 될 것이며, 디자인 패턴의 대가라고 해도 안드로이드 같이 성공한 제품을 만들지 않았다면 대중의 공감을 얻기 힘들 것이다.

필자가 지난 5년간 멘토링 해서 얻은 가장 소중한 결실은 민간 한 IT 트렌드를 지속적으로 센싱 하며 특정 개발을 위해 신입이 매력적으로 보일만한 공부의 방향을 정해줄 수 있는 안목을 얻은데 있다. 물론, 이 안목에도 시간의 개념이 들어간다. 한두어 달만 IT 뉴스를 보지 않아도 감각을 잃을 거라 생각한다.

지금 쓸 수 있을 때 쓰려고 하는 것이다. 자연(전기)의 API를 호출해서 만든 CPU 및 하드웨어의 API 위에 만들어진 OS, OS의 API를 써서 만들어지는 프레임웍도 그 프레임웍의 API를 호출해서 만들어지는 애플리케이션들.

어떤 분야가 있는지, 기술이 있는지 집중할 필요는 없다. 어떤 곳의 엔지니어들이 가장 겸손하고 소통이 잘되며, 모르는 것을 모른다고 하면 친절하게 가르쳐 줄 수 있는지 보면 될 것이다. 필자의 안목으로 단편적으로 말하자면 고수층이 가장 투텁고, 같은 것을 짜도 가장 소스가 달라지는 C++ 이 가장 그렇고, 그다음은 JAVA이다. 새로운 언어라 초고수가 없는 SWIFT도 같을 것이다. C를 다루는 사람들은 대부분 하드웨어 종속적이고 사람 목숨이 왔다 갔다 하는 프로젝트들도 더러 있어서 와신상담을 해서 고수 반열에 들지 않으면 소통이 어렵다.

필자 이야기를 잠깐 하자면, 철학 부분에서 자신 있는 필체로 쓰는 것은 겸손해야 하는 논리를 뽑아내기 위함이었다. 필자도 유독 한 선배에게 만은 ㅄ 소리를 들었다. :) 그리고 그 선배 자신도 모르는 것을 간단히 모른다고 말하고 아는 것은 안다고 말했고 또 그렇게 할 줄 알아야 한다고 가르쳐 줬었다. 프로그래머 자존심에 뱅뱅 돌려서 말하거나 과시하거나 이미 했던 결과물을 말하는 것을 싫어했다. 그 선배의 머릿속에서 중요한 것은 항상 뭘 만들까였다. 책을 쓰라고 수없이 권유를 했지만 자신은 늘 만드는 것이 좋다며 날 ㅄ이라고 불러줬던 그 선배가 사실 가장 겸손하고 소통을 잘하는 사람이라는 것은 뒤늦게 알게 되었다.

- 몇 달 만에 수십억을 버신 선배가 가르쳐준 개발자 소통의 정수라 꼭 수정해서 들어가야 할 내용

새로운 것을 창조하기에 개발자라 불리는 프로그래머의 철학은 이것이 전부라고 생각한다. 솔직히 말하면 코드 한 줄 몰라도 된다. 그래도 포인터 정도까지는 알자.

1. 이미 형성된 시장에서는 기존 사용자를 포용하는 서비스만이 성공한다. - 경기도 교육청 마소 제품 퇴출기사, 중국 델 40% 이상이 리눅스 배포판 '기린'으로 나간다는 최근 기사, 오래전 우주정거장 OS가 리눅스로 되었고 세계 슈퍼컴퓨터 TOP 500 중 494대가 리눅스 라도 일반 사용자는 기존 운영체제 쓰는 것에 익숙하다는 생각이 있었습니다. 7년전 같이 일할 기회가 있었던... 마소에서 아마존으로 옮긴 엔지니어가 닷넷은 죽었으니 마소 진영을 떠나야 한다고 했었지요. 수긍했지만 상당한 시간이 걸릴것이라 생각했습니다. 여전히 서버 시장이나 데탑 시장을 보면 마소가 건재합니다. 구글이 크롬북 내고 실패, 페북이 폰, 검색서비스 내면서 실패하는 것들을 봐도 더 좋게 만드는 것 보다 기존 사용자를 흡수하면서 나가는 PLAY만이 성공한다는 선입견이 있었습니다. C++ 창시자가 C로 번역하는 툴을 먼저 만들어서 성공했듯이요. 최근 우분투를 써 보면 맥이나 윈도 유저가 쓸 때 전혀 불편함이 없습니다. 물론, 한글 빼구요.

2. 한글... 그리고 서비스에 집중하기 : NSA에서 SELinux를 만드는 엔지니어와 일할 기회가 있었는데... 한글디폴트 우분투를 쓰다가 빡쳐서(현장감UP) 다시 영문 디폴트 우분투로 완전히 새로 세팅을 해 준 적이 있습니다.(폰트에 계속 문제가 생기더군요) 오래도록 리눅스를 봐왔지만 리눅스 배포판들을 보면 자유로운 경쟁이라기 보다는 사실 밥그릇 싸움으로 보입니다. 윈도우, 맥은 한글을 완벽 지원하는데 왜 아직도 리눅스는 한글 하나 제대로 되지 않을까 하는 거죠. 수많은 한국 리눅서들이 있는데도 말이죠. 저도 반성합니다. 그리고 각 플랫폼에 관대해 지려면 집에 맥북프로, 서피스 프로, 리눅스 서버는 가지고 있어야 합니다. 그래야 마소, 애플, 오픈소스 진영 욕을 안하고 어떤 서비스가 더 좋은지에 집중을 하게 됩니다.  

3. 레드햇보다는 우분투 : 제 기억에 레드햇은 항상 비쌌습니다. 와우 리눅스, 레드헷 7.3 그 뒤엔 페도라 유저 였습니다.(그래서 아직도 rpm이 좋고 sudo 쓰는 것을 싫어합니다. 걍 su - ) RHEL이나 자격증 비용, 서버 A/S 비용등을 보면 M$ 보다 더한 애들 같았어요(지금도 비싸지요) 오픈소스 진영에 있던 분이 마소 MVP가 되어 해 주셨던 10년전 세미나의 한 대목이 기억 납니다. "너무 재미있지만... 청춘이 멍들었어요". 그도 그럴것이 M$라 욕하는 사람이라서 MS 제품 크레킹 버전 쓰는 것은 이해가 갔는데 왜 다른 소프트웨어도 모두 크랙 버전을 쓰는지는 이해할 수 없었거든요. 전 중학생 때에도 10달을 모아 Borland Turbo C++ 3.0을 당시 18만원 주고 샀었는데... K-dos나 씨앗 같은 책(소프트웨어 제공되는)도 당연히 돈 주고 사야 된다고 생각했었거든요. 왜 자유가 공짜에 있다고 생각되는지는 사실 지금도 이해가 안되는 부분입니다. 초반에는 CD도 걍 주다가 지금은 다운로드 받으려면 기부 UI를 꼭 거쳐야만하는 우분투도 무조건 공짜를 고집하는 개발자들의 산실이겠지요. 저도 반성합니다. 기부는 FSF에 꾸준히 하고 배포판은 우분투를 쓴다는...(사실 GNU껀 좀 그래요)

4. 서버는 리눅스 : 최근 512기가바이트 메모리의 단일 서버에 윈도우 서버 2012를 깔았는데 메모리 인식이 다 안되더라구요.... 리눅스는 되는데. 그래도 맥처럼 획일화된 시스템의 OS는 아니니 마소의 한계라고 생각이 되진 않지만 리눅스는 왜... 다 인식되는거니 ㅠㅠ. 관리는 윈도우 서버가 편하긴 합니다만. 더군다나 오픈소스 진영의 툴들은 윈도우용이 항상 문제가 많았습니다.(PHP, Mysql, Node.js 등...)

5. VMWARE의 위력 : 사실 서버 돌릴 때도 전 VMWARE 깔아서 돌립니다. 서버 이전이 쉽기 때문입니다. 우분투도 사실 14.04 쓰다가 결국 VMWARE 에 넣어버렸습니다(그놈의 한글 때문에...) VMWARE 덕에 이곳을 찾을 자격이 된 것이죠.

6. 모든 OS는 멈춘다. 왠만한 리눅스 배포판은 다 깔아 본 것 같습니다. 완벽하게 도는 배포판은 없었어요. 맥도 그래요. 멈춤 현상 많습니다. 윈도우도 말할 것 없고. 제가 실력이 있으면 uC/OS 기반의 운영체제를 하나 만들겠지만. 노태상 씨께(지금은 뭐하시는지 궁금하네요) 학창시절 세미나를 들으며 패키징할 때 커널 컴파일만 8000번 하셨다는 이야기를 듣기 전에 방학중 패키지 하나 만들어 보려고 100번 가량 커널 컴파일 해보고 전문가라고 생각했던 제 자신이 너무 초라해 보였습니다. 그 뒤에 개발자 길을 걸으며... "아... 커널은 정말 쉬운게 아닌거구나"했죠. 한중일 SW포럼에서 운좋게 수상하여 리눅스 커널 TCP/IP 메인테이너와 수상할 기회가 있었는데. 지금 가정을 이룬 은행빚 개발자로 돌이켜보면 대학교 교수시니까 그럴수 있지 않았나 생각이 듭니다. FSF 모임은 대부분 하버드 대학교에서 열리고 오픈소스 진영을 보면 소수의 천재들(또 집안에 돈이 많은)이 만드는 것 같아요. 우분투 지원해주는 캐노니컬도 그렇고... 그 천재들도 커널이 너무 방대하니 다 나누어서 만드는 것이죠. 어줍잖은 제 지식으로 살펴보면 토발즈도 학창시절 교수꺼 배낀걸로 아네요.

7. 우분투가 통일할거라는 확신이 들었습니다. - 믓튼... 한동안 밥 먹고 사느라 리눅스를 많이는 못했었는데요.(안드로이드랑 윈도우, 맥 계열만 ㅠㅠ) 최근 여러 정세를 보면 우분투가 15년 내로 OS 통일할 것 같아요. 우선 기업 철학이 인류애인 것과 학교와 업계간의 연계. 구글의 멋진 PLAY 등이죠.

8. 위험요소는? 있지요. 매직립이나 홀로렌즈를 보면 모바일 때문에 죽었던 3D가 다시 이 바닥의 돈의 흐름을 만들 것 같다는 것입니다. 그래서 최근 3D를 다시 공부하게 되었지요. DirectX가 OpenGL보다 빠릅니다. 무적의 GCC가 인텔칩 위에서는 인텔 컴파일러보다 대부분 느린 것과 비슷한 것이지요.(그런데 몇 카테고리는 빠르다는...) 맥의 메탈 역시 더 빠르게 하려고 하겠지요. 그러나 무조건 빠르다고 성공하지는 않습니다.(이 부분은 내용이 많아 언젠가 다시 말해야 겠네요.) 사용자가 많아야 하는데 결국 3D 부분이 걸림돌이 되겠네요. 

9. 우분투는 1~8이 별로 중요하지 않습니다. 다만 다른 배포판은 철학이 다르다고 생각합니다. 인류애를 상징하는 우분투라는 이름이 정말 중요하다고 생각합니다. 자유와 오픈소스도 그 이름안에 한정해서 이루어졌으면 합니다. 사실... 이렇게 나누면 GTK 페이지 번역하신 분이나 한글화 해주시는 많은 분들이 짜증나실지도 모르겠지만. 마소와 맥을 보내버리려면 우분투를 앞세우고 정부와 구글을 잘 이용하는 전략을 구사해야 하지 않을까요.

충분히 오래 쓴 것 같아 이제 비교를 할 수 있을 것 같다.

레티나 맥북은 맥북 프로인데 키보드를 가는 수고로움이 있었고 전체적 만족도는 상판에 불 들어오는 구버전 맥북 에어가 더 좋다.(최근 맥북에어가 업글 되면서 구버전이 되었지)

맥북 에어 살 때 뉴 맥북이 이미 나와 있었지만 말도 많고 탈이 많았던 구형 맥북 에어를 산 이유는 키보드 문제가 매우 컸었다.

키보드 문제가 지속적으로 제기 되었고 아니나 다를까 새로 산 맥북 프로도 키보드를 교체하게 되었다. 

해상도의 경우 아무래도 레티나가 나은데, 내가 난시가 있고 워낙 글을 빨리 보다보니 글 차이가 없을 줄 알았다.

그러나 핵심적인 것은 6시간 이상 보고 있을 때 나타난다. 구형 맥북에서 작업을 하고 6시간이 지나면 눈이 뻑뻑해서 잘 안 움직여지는 느낌이 들 정도다.

난 스탠드 쓴지는 오래 되어서 확실히 말할 수 있다. 이걸로는 우리 딸 코딩 교육 못 시킨다고 ㅠㅠ 

맥북에어, 맥북, 맥북 프로, 갖가지 패드들...(아이패드 미니, 아이패드 프로, 삼성 시리즈+)도 있으나 이젠 기준 자체가 IPS냐 아니냐로 구분된다.

아이가 눈이 나빠지고 나서 더욱 내 기준은 해상도만 보게 되는 것 같다.

글을 쓰는 지금도 구형 맥북으로 글을 쓴다. 그러나 난 이 노트북을 10년 이상 쓰게 될 것 같다. 맥북 에어 임에도 불구하고 i7에 512로 맞춰서.

엔지니어 입장에서는 말도 많고 탈도 많았지만 그래도 혁신의 아이콘인 스티브 잡스의 유작이라. 그런 것도 있다.

움푹 패인 키보드 에어리어의 곡선마다 상판 애플 로고에 불을 넣기가 쉽진 않았을텐데 그것에 대한 이유에 대한 생각마다

내구성은 낮지만 포스터치가 아닌 정말로 눌러지는 이 버튼의 누르는 느낌마다 그리고 이 정도 크기로 한 것에는 이유가 있는데 그 이유에 내구성과 누르는 압력이 균일하지 못한 것 뿐만은 아니고 사용자도 충분히 생각했을거라는 그런 잡스의 이미지를 떠올리며 오래도록 쓸 것이다. 사실, 유투브 볼 때는 문자 볼 때만큼 IPS가 의미가 있지 않은 이유도 있다ㅋㅋ

그나저나 맥북에어로 한번 오고 나니 앞으로 구입하는 제품도 에어로 가고 싶은 마음이 든다. 그래도 최상급 맥북 프로는 항상 가지고 싶지 ^^

사업 망한 건 사실 스펙이 안된다. 그러나 경영자의 생각을 알게 된다. 책임감이나 의무 등 좋은 말도 있지만 그것을 를 넘으면 돈을 보게 되고 물불 가리지 않는 것들 등... 이런 잡다한 것들을 묶어서 그냥 "생각"이라고 표현한다.

이렇게 단어를 일반화 하는 것을 제외하고 난 뭐든지 일반화 하는 것이나 뭉뜽그려서 말하는 것을 싫어한다. IT 분야에 오래 있었기에 변하게 하고 싶은 것을 변하게 한 적이 많다. 아마 내가 이 글을 쓰고 난 이 후 몇 년 뒤에는 모두 그렇게 생각할테지만 지금은 과도기 이기에 하나 이야기 해 본다.

네이버나 다음 구글을 말하는 것은 그 시절 , 그 시간에 의사 결정 능력이 있는 사장, 임원, 팀장을 말하는 것이다. 우리 모두는 평등하지 않지만, 물리적으로는 같은 능력과 다 같이 죽음으로 갈 평등을 부여 받았다. 이에, 모든게 사장 잘못이라거나 모든게 대통령 탓이라거나 하는 생각이 있는 것은 아니다. 충분히 신경쓸 수 있었고, 충분히 보고도 받았으나 본인의 의지로 신경 쓰지 않은 사안에 대해서는 책임이 있는 것이다. 삼성 반도체 공장에서 일하다 암으로 죽었던 사람에 대해서 삼성전자가 책임이 있다는 것이 아니라는 것이다. 그 때 회장, 사장, 임원, 팀장급이 문제라는 것. 

신기한 것은 회장이 문제가 없을수도 있다. 왜냐면 문제라는 것을 처리하지 못하고 보고하게 되면 본인의 출세길이 막힌다는 착각 때문에 보고 자체를 하지 않는 경우도 많으니까. 그럴 경우 책임을 져야 하지만 회사 이름으로 책임을 지기 때문에 한번 나쁜 놈은 절대로 교화될 수 없다. 

그래서 우리는 대표 이름인 회사 이름을 쓰더라도 그런 결정을 내리거나 행하는 사람이 누구인지 항상 알아볼 필요가 있는 것이다.

위안부 사건에 대해 성폭행 했었던 군인들은 위에서 시켜서 했기 때문에 잘못이 없을까? 라는 질문을 던져보면 확실히 알 수가 있다.

내가 블로그는 옮기는 것도 매우 큰 사안이다. 만약 카카오에 대해서 말을 한다면 카카오 전체가 아니라는 것이다. 그리고 카카오 쪽에 지인이 몇 있는데, 내가 그런 글을 쓰면 쓸 수록 고급 정보를 얻을 기회가 줄어드는 것이 사실이다. 그러나 정말 "사실"은 글로벌하게 봤을 때 별 대단치도 않은 한국 회사인데 별로 알고 싶지도 않다. 그러나 기술 하나 만큼은 뛰어나다. 몇몇 뛰어난 운동 선수를 제외하고는 대한민국에서 전체적으로 경쟁력있는 분야는 의료, IT라고 생각한다. 왜냐면 내가 다른 분야를 모르기 때문에. 그리고 이제 정말 글로벌 시대라 정에 이끌려 뭘 쓰고 안 쓰고 할게 아니다. 우리나라 대기업이 그런 명분아래 자국민에게 행했던 것을 보면. 예를 들어 현대차는 자국민 차는 안전하지 않도록 해서 번 돈으로 지네들은 외제차를 사는?

이런 것도 내부 고발하는 사람이 많아져서 정화 작용이 일어나는 것이다.

구글이 잘해서 오래도록 구글 플랫폼 제품만 썼었고 애널리틱스나 애드센스는 확실히 메리트가 있다. 그러나 블로그는 확실히 티스토리가 낫다. 아직은 개인이 만든 블로거 앱보다 뒤쳐지지만(앱에서 쓴 글만 편집할 수 있는 등) 앱도 무료도, 다른 부분은 확실히 더 좋을 것을 느낀다. 그리고 모든 면에 의해서 더 좋아질 것을 기대한다. 서버 유지 비용으로 애드센스 수익을 몇%를 나누는 등의 방법을 통해서 금전적으로도 지속 가능한 서비스가 될거라 생각한다. 

술도 한잔했고, 잡썰이 길었네.

새로운 공간에서 일기를 쓰니 기분이 묘하다. 아쉬운 점은 이전 블로그 글을 옮기는 과정에서 1/3은 버려지게 되는 것 같다. 모두 어릴적 생각들이라... 남겨둬야 하는데 부끄러운 것도 있고. 어차피 부끄러울 일은 어른이 되어서도 많은데 굳이 지난 날 생각이나 추억을 지울 필요가 있는지도 잘 모르겠다. 그래서 아쉽다. 다 옮기지는 못하고 지워야 하니... 아까운 것은 프린트를 하는데. 이미 A4지 한박스를 쓰고 한박스 더 주문했다. 삼천포로 빠지면(이제 사천시) 종이는 확실히 80g 이상을 써야 한다. 너무 좋다. 그리고 어른이 되어서 부끄러운 것은 우리 아이들에게 미세먼지 많은 대한민국을 물려주게 되어서 정말 미안한 마음 뿐이다. 아이들에게 뭐라고할 자격도 없다.

암튼 블로그 발전하고, 카카오랑 네이버랑 합병해서 국내에서 그만 경쟁하고 카카오 세계로 뻗어 나가서 다 먹어 버렷. 아니면 위쳇, 라인, 페북 메신저 등과 호환되는 notice 시스템을 만들어서 국가 재난시 알림이 가도록 했으면 좋겠다. 우주인이 침공할 것 같아... 왠지. 느낌이 그래.

사족으로 배터리 싸이클

중고 맥북 살 때 배터리 사이클은 보지 말아야 겠다. 4개월째 사용중인데 (31일에 만 4개월) 15회 밖에 안되네.

그것도 키보드 갈았더니 1로 초기화됨... 하판 다 갈아준 듯. 상판 디스플레이는 수명이 없나? 중소로 팔기 전에 키보드 바꿔서 비싸게 팔아도 되겠네라는 망상? (귀찮아서 그럴 위인 못되지만. 알고는 있어야지) 키보드 수리비가 50만원이라 큰 이득은 없어 보이지만.

네이버와 국내 경찰청은 연계되어 있다. 즉, 국가 기관과 연계되어 있다는 뜻.

그런데 국내 검색창은 아직 이런 상태다. 찾고 싶은게 없다. 도저히 없다. 국민 청원 빼고는 어느 국내 정부 기관 사이트 가도 제대로 동작하는게 없다. 성범죄자 알림 서비스도 가끔 이용하는데 너무너무 불편하다.

구글 이용할 때의 느낌은 없다. 내가 원하는 것을 찾아 주었으면 좋겠다.

다른 건 잘 된다고 변명하고 싶어도 국가와 짜고 진실을 왜곡한 적이 있어서 그러지 못하는거 알아서 쓴다.

그래도 어쩌겠나, 해외 도둑놈 보다는 국내 도둑놈이 더 잘되었으면 좋겠다는 마음.

LLM(Large Language Models)에 대해 배우고 싶으시다면, 기초부터 차근차근 시작하는 것이 좋습니다. LLM은 자연어 처리(Natural Language Processing, NLP)의 한 분야로, 대량의 텍스트 데이터를 기반으로 언어를 이해하고 생성하는 모델을 말합니다. 여기 몇 가지 단계로 나누어서 공부할 수 있는 프로젝트를 제안드립니다:

1. 자연어 처리(NLP) 기초 이해하기

• 텍스트 데이터 전처리: 정규 표현식을 사용한 텍스트 클리닝, 토큰화, 스톱워드 제거, 어간 추출 및 표제어 추출 등의 기초적인 NLP 전처리 방법을 학습합니다.
• Python과 NLTK 라이브러리 사용: Python의 NLTK(Natural Language Toolkit) 라이브러리를 사용하여 기본적인 텍스트 분석을 수행해봅니다.

2. 머신러닝과 NLP의 결합

• 기본적인 머신러닝 모델 학습: 머신러닝의 기초를 다진 후, 텍스트 분류나 감성 분석과 같은 간단한 NLP 태스크를 수행해 보는 프로젝트를 시작합니다. Scikit-learn 라이브러리를 활용한 분류 모델을 만들어 보세요.
• Word Embedding 이해하기: Word2Vec이나 GloVe와 같은 워드 임베딩 모델을 학습하고, 이를 사용해 텍스트 데이터를 벡터 공간에 매핑하는 방법을 학습합니다.

3. 딥러닝과 NLP

• TensorFlow나 PyTorch 학습: 딥러닝 프레임워크인 TensorFlow나 PyTorch를 사용하여 기본적인 신경망을 구축하는 방법을 학습합니다.
• RNN과 LSTM을 사용한 텍스트 생성: 순환 신경망(RNN)과 장단기 메모리(LSTM) 네트워크를 사용하여 간단한 텍스트 생성 모델을 만들어봅니다.

4. 대형 언어 모델(Large Language Models) 탐구

• Transformer 모델 학습: Transformer 아키텍처의 기초를 이해하고, 이를 기반으로 한 모델(BERT, GPT 등)에 대해 학습합니다.
• Hugging Face의 Transformers 라이브러리 사용: Hugging Face의 Transformers 라이브러리를 사용하여 사전 훈련된 LLM을 탐색하고, 다양한 NLP 태스크에 적용해보는 프로젝트를 진행합니다.

5. 실제 프로젝트 수행

• Fine-tuning 사전 훈련된 모델: 특정 태스크에 맞게 사전 훈련된 LLM을 Fine-tuning하는 방법을 학습하고, 실제 데이터셋에 적용해봅니다.
• 자체 LLM 프로젝트: 배운 지식을 토대로 자신만의 LLM을 설계하고, 구현해보는 프로젝트를 진행합니다.

이 과정들은 LLM에 대한 이해를 넓히고, 실제로 어플리케이션을 만들어보는 데 도움이 될 것입니다. 또한, 이러한 프로젝트를 진행하면서 발생하는 문제들을 해결하는 과정에서 더 깊은 지식을 쌓을 수 있습니다.

============================================================================화사첨족.

집에서 일하는 것이 회사 사무실에서 일하는 것보다 더 편하다고 느끼는 이유는 여러 가지가 있을 수 있습니다. 개인적인 선호도나 작업 환경에 대한 요구 사항이 다르기 때문에, 각자의 이유는 조금씩 다를 수 있습니다. 여기 몇 가지 공통적인 이유를 소개합니다:

1. 통근 시간의 절약: 집에서 일할 때는 출퇴근을 위해 시간을 소비하지 않아도 됩니다. 이 시간을 다른 개인적인 일이나 추가적인 업무에 할애할 수 있어서, 일과 생활의 균형을 더 잘 맞출 수 있습니다.
2. 유연한 근무 환경: 집에서 근무하면 자신의 근무 환경을 자유롭게 조정할 수 있습니다. 예를 들어, 음악을 들으면서 일하거나, 원하는 시간에 휴식을 취할 수 있습니다.
3. 소음 및 방해 요소 감소: 사무실 환경은 때때로 시끄럽거나, 동료들로부터의 방해를 받을 수 있습니다. 집에서는 이러한 외부 요소들을 더 잘 통제할 수 있어, 집중력을 유지하기가 더 쉬울 수 있습니다.
4. 개인적인 안락함: 집은 개인적인 공간이므로, 자신이 가장 편안하게 느끼는 환경을 만들 수 있습니다. 예를 들어, 의자나 책상과 같은 사무용 가구를 자신의 선호에 맞게 선택할 수 있습니다.
5. 건강 및 웰빙: 집에서 일하면 식사 준비나 운동과 같은 개인적인 건강 관리를 더 잘 할 수 있습니다. 사무실에서는 이러한 활동을 위한 시간을 찾기 어려울 수 있습니다.
6. 기술의 발전: 클라우드 기반 도구와 커뮤니케이션 플랫폼의 발전으로 집에서도 팀원들과 효과적으로 협업할 수 있습니다.

물론, 집에서 일하는 것이 모든 사람에게 장점만 있는 것은 아닙니다. 집중력 유지, 업무와 개인 생활의 경계 설정, 사회적 고립감 등의 도전도 있을 수 있습니다. 하지만 많은 사람들이 위에서 언급한 이유들로 인해 집에서 일하는 것을 선호합니다.

집에서 일하는 것이 더 편하다고 느끼는 이유는 개인마다 다를 수 있지만, 일반적으로 다음과 같은 요인들이 작용할 수 있습니다.

1. 출퇴근 시간 절약: 집에서 일하면 출퇴근에 소요되는 시간과 에너지를 절약할 수 있습니다. 이는 더 많은 자유 시간과 편안함을 제공합니다.
2. 유연한 근무 환경: 집에서는 자신에게 가장 편안하고 생산적인 환경을 조성할 수 있습니다. 원하는 대로 작업 공간을 구성하고, 선호하는 조명이나 온도 등을 조절할 수 있습니다.
3. 자율성과 집중력 향상: 사무실의 잡음, 동료와의 대화, 회의 등의 방해 요소가 줄어들어 업무에 더 집중할 수 있습니다. 또한, 자신의 페이스에 맞춰 일할 수 있어 자율성이 높아집니다.
4. 가정생활과의 조화: 집에서 일하면서 가족과 더 많은 시간을 보낼 수 있고, 육아나 가사 등 개인적인 일과 업무를 더 유연하게 병행할 수 있습니다.
5. 비용 절감: 출퇴근 비용, 식비 등을 아낄 수 있고, 회사에서 제공하는 자원 대신 이미 가지고 있는 개인 물품을 사용할 수 있습니다.
6. 스트레스 감소: 직장에서의 人間關係, 업무 환경에 대한 스트레스가 줄어들 수 있습니다. 익숙하고 편안한 공간인 집에서 일하는 것이 정신적 안정에 도움이 될 수 있습니다.

다만, 재택근무가 모든 사람에게 적합한 것은 아닙니다. 업무 특성, 개인의 성향과 역량, 가정 환경 등에 따라 사무실에서 일하는 것이 더 효과적일 수도 있습니다. 개인의 선호도와 상황을 고려하여 최적의 근무 방식을 선택하는 것이 중요합니다.

1. 저자는 SNS를 브런치와 트위터로 제한하기로 했습니다.
2. 브런치에서는 기존의 콘셉트를 유지하되, 기술 블로그 형식으로 운영할 계획입니다.
3. 기술 블로그를 하려는 이유는 저자의 경험과 연결되어 있습니다. 저자는 오랜 기간 교육 활동을 해왔고, 한국의 코딩 교육 상황을 개선하고자 하는 목표가 있습니다.
4. 현재 한국의 코딩 교육은 학교가 감당하기 어려운 상황이며, 학원이나 온라인 교육도 한계가 있다고 봅니다. 이를 개선하기 위해서는 해외에서 성공한 교육자들의 노하우가 필요하다고 생각합니다.
5. 한국 사회의 전반적인 문제점과 한계에 대해서도 언급하였습니다. 저자는 현재의 상황을 부정적으로 인식하고 있습니다.
6. 자본주의 사회에서 돈과 성공이 인간을 변화시키는 현상, 그리고 불평등한 현실에 대한 고민도 드러냈습니다.
7. 미래 세대인 코딩 영재들에 대한 기대감을 표현하면서도, 잘못된 방향의 교육에 대한 경계심도 나타냈습니다.

• Transformer 아키텍처는 강력한 문맥 이해 능력과 병렬 처리를 통해 텍스트의 의미를 잘 파악할 수 있게 해줍니다.
• 자기 회귀 언어 모델은 이전에 생성된 단어들을 바탕으로 다음 단어를 예측하여 텍스트를 생성하는 방식입니다.
• GPT와 같은 모델은 Transformer 아키텍처를 활용한 자기 회귀 언어 모델로, Transformer로 문맥을 이해하고 자기 회귀 방식으로 텍스트를 생성합니다.
• 이런 조합을 통해 효율적이면서도 자연스러운 텍스트 생성이 가능해집니다.

Transformer와 자기 회귀 언어 모델이 시너지를 내며 발전하고 있고, 앞으로도 자연어 처리 분야에 큰 영향을 미칠 것 같습니다. ChatGPT나 Claude 같은 대화형 AI들이 이런 기술들을 바탕으로 점점 더 사람과 자연스럽게 소통할 수 있게 될 거라 기대되네요.

이런 흐름에 맞춰 우리도 계속 공부하고 발전해 나가는 것이 중요할 것 같아요. 자연어 처리 기술의 동향을 놓치지 않고 꾸준히 따라가려 노력해야겠어요.

Transformer 아키텍처와 자기 회귀 언어 모델의 결합은 자연어 처리(NLP) 분야에서 혁신적인 발전을 이루었습니다. 이러한 기술들은 텍스트의 문맥을 더 깊이 이해하고, 자연스럽게 텍스트를 생성하는 데 중요한 역할을 합니다. GPT와 같은 모델들은 이 두 기술의 장점을 결합하여 텍스트 생성의 질을 크게 향상시켰고, ChatGPT나 Claude와 같은 대화형 AI 개발에 있어 중요한 기반 기술이 되었습니다.

이러한 모델들은 뛰어난 언어 이해 능력과 생성 능력을 통해 다양한 언어 기반 작업에서 놀라운 결과를 보여주고 있습니다. 예를 들어, 기계 번역, 요약, 질문 응답(Q&A), 창의적인 글쓰기 등 다양한 분야에서 활용되고 있습니다. 또한, 이 기술들은 사용자와의 자연스러운 대화를 가능하게 함으로써, 사용자 경험을 극대화하는 데에도 기여하고 있습니다.

미래 전망

• 개인화와 맞춤형 서비스: Transformer와 자기 회귀 모델을 활용한 AI 시스템은 사용자의 언어 사용 스타일과 선호도를 학습하여, 더 개인화된 대화와 정보 제공이 가능해질 것입니다.
• 다양한 언어와 방언의 지원 확대: 이 기술들의 발전은 다양한 언어와 방언에 대한 이해를 깊게 하여, 전 세계 많은 사람들에게 접근성을 높일 것입니다.
• 보다 진보된 상호 작용: 대화형 AI가 사용자의 의도와 감정을 더 잘 이해하게 되면서, 기계와의 상호 작용이 더 자연스럽고 인간 같은 형태로 발전할 것입니다.

지속적인 학습의 중요성

이러한 발전을 따라가기 위해서는 기술의 최신 동향을 꾸준히 학습하고, 새로운 도전을 시도하는 것이 중요합니다. 온라인 코스, 학술 논문, 오픈 소스 프로젝트 참여 등을 통해 지식을 넓히고, 실제 프로젝트에 적용해보는 경험을 쌓는 것이 좋습니다.

또한, 이러한 기술들의 윤리적 사용과 개인 정보 보호에 대한 고민도 함께 이루어져야 합니다. AI 기술의 발전은 사회에 긍정적인 영향을 많이 미칠 수 있지만, 잘못된 사용으로 인한 부작용을 최소화하기 위한 지속적인 노력이 필요합니다.

자연어 처리 분야는 계속해서 발전하고 있으며, 이러한 기술의 발전은 우리가 상상하는 것 이상으로 빠르게 진행될 수 있습니다. 그러므로 지금 이 순간에도 새로운 지식을 탐구하고, 학습하는 자세가 중요합니다.

2019년 아마존 오로라 사용기 

RDS를 쓰는 회사에서 개발하는 제품에 물리 서버를 이용하지 않는다면 아마존이 최선이 선택일 것이다. 전력량, 온/습도, 하드디스크 수명 관리 등을 안해도 될거라 생각하니 좋았다. NoSQL이던 RDBMS던 CRUD(Create, Read, Update, Delete)가 전부인 DB 세상이고 로드벨런싱과 보안계획/실행, 스케일링은 혼자 하기 힘드니까 계속해서 서버 구축하지 말자는 판단. 서버실 공간도 없고, 추가 전기 공사에 회사 이전 계획까지 겹친 것도 한 몫. 우선 DB 서버 부터... 초창기에는 비용도 저렴한 클라우드로 가자고 생각했다. 다들 따져보면 결국, 선택은 AWS RDS. 애저와 구글 클라우드를 이용해 보았으나, 수년 뒤 2018년에 결국 아마존으로 가게 되어 있다고 생각한다. AWS EC2에 우분투가 아닌 아마존 리눅스 기반에 mysql 설치하고 서비스를 만들고 잘 사용했으나, DB 서버는 분리하는게 당연한 지라 AWS RDS로 갈 수 밖엔.

우선 RDS로 오로라를 쓰는 이유 MySQL로 하고 싶지만 아래 AWS RDS 소개글을 보면 Aurora를 쓸 수 밖에 없게 만든다. 물론, 앞으로도 자사 솔루션을 더욱 강화할 것임은 당연지사 MySQL & Aurora MySQL은 전 세계에서 가장 많이 사용되는 오픈 소스 데이터베이스입니다. RDS에서 MySQL은 데이터베이스의 컴퓨팅 리소스 또는 스토리지 용량을 쉽게 확장할 수 있는 유연성을 갖춘 MySQL 커뮤니티 에디션의 풍부한 기능을 제공합니다. 최대 16TiB 크기의 데이터베이스를 지원 Amazon Aurora Amazon Aurora는 MySQL 및 PostgreSQL 호환 엔터프라이즈급 데이터베이스입니다($1/일 미만부터 시작). MySQL의 최대 5배 처리량, PostgreSQL의 최대 3배 처리량

자세한 정보는

https://aws.amazon.com/ko/blogs/korea/databaseintroducing-the-aurora-storage-engine/

Amazon Aurora Storage 엔진 소개 | Amazon Web Services

Amazon Aurora는 re:Invent 2014에서 발표한 이후, 2015년 7월에 정식으로 출시 및 2016년 4월 1일 서울 리전에 출시함으로써 국내외 많은 고객들이 RDBMS가 필요한 워크로드에 이미 도입을 하였거나 현재 도입을 고려하고 있습니다. Amazon Aurora는 AWS 역사상 가장 빠른 성장세를 보이고 있는 서비스 입니다. Amazon Aurora의 빠른 성능과 안정성을 지원하는 핵심인 Aurora 스토리지 엔진에 대한 좋은 블로그

aws.amazon.com

Aurora에서 개발용으로 MySQL 5.6.10a와 호환 가능 으로 하여 t2.small로 맞추었다. 개발용으로 만든 EC2 t2.large 인스턴스가 한달에 30만원씩 나오는 것을 보면 AWS 계산기가 제대로 동작 안하는 것 같다.

https://calculator.s3.amazonaws.com/index.html

Amazon Web Services Simple Monthly Calculator


calculator.s3.amazonaws.com

Estimate of your Monthly Bill ($ 45.90)월별 추정 요금 인데 RDS 생성 메뉴에 나오는 가격은 DB 인스턴스 45.99 USD 합계

45.99 USD 이다. 다르다. 0.09라도 다른 것은 다르다. 네트웍 I/O던 내부 I/O 던 관련이 없어 보이는데 말이다.

게다가 Storage 를 20->10으로 바꾸면 비용이 줄어야 할 텐데 오히려 는다. Estimate of your Monthly Bill ($ 46.01) 40으로 늘이면 당연히 는다. Estimate of your Monthly Bill ($ 48.30) 삼성전자 재적시절 유럽시장 SEAndroid 텍스트 로그만 받는데 월 300 만원씩 나간 것을 보면, 추정은 추정일 뿐 일단 사용해 보는 것이 정답임을 이미 알고 있기에 비용 딴지는 그만. 믓튼, 월 5만원에 개발용 서버 사용이 가능하다. 역추척은 서비스는 켜야 한다. $ 4.42 USD/월 추가된다. 만들고 나서 mysql workbench로 접속해 본다.

https://dev.mysql.com/downloads/workbench/

MySQL :: Download MySQL Workbench



dev.mysql.com

https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/CHAP_GettingStarted.CreatingConnecting.Aurora.html#CHAP_GettingStarted.Aurora.Connect

DB 클러스터 생성 후 Amazon Aurora DB 인스턴스의 데이터베이스에 연결하기 - Amazon Relational Database Service



docs.aws.amazon.com

카싼드라가 사용자 편의성을 위해 CQL로 추상화 했듯이,

AWS 오로라 DB도 그냥 mysql 이라고 생각하고 쓰면 되겠다.

2. 마이그레이션

기존 데이터를 가져오는 것도 자료가 많아 좋았다.

https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/MySQL.Procedural.Importing.External.Repl.html

Replication with a MySQL or MariaDB Instance Running External to Amazon RDS - Amazon Relational Database Service


docs.aws.amazon.com

https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/MySQL.Procedural.Importing.html

Restoring a Backup into an Amazon RDS MySQL DB Instance - Amazon Relational Database Service



docs.aws.amazon.com

https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/MySQL.Procedural.Importing.External.Repl.html

Replication with a MySQL or MariaDB Instance Running External to Amazon RDS - Amazon Relational Database Service



docs.aws.amazon.com

물리서버가 아니라 마음이 참 편하다. 결론은 돈이 좋다고 해야 하는 건가.

사전 학습(Pre-training)과 미세 조정(Fine-tuning)은 트랜스포머 기반 언어 모델을 개발할 때 널리 사용되는 중요한 기법들입니다. 이 두 단계를 통해 모델은 방대한 양의 텍스트 데이터로부터 일반적인 언어 지식을 습득한 후, 특정 태스크에 맞게 조정되어 최적의 성능을 발휘할 수 있게 됩니다. 

사전 학습 단계에서는 대규모의 텍스트 데이터를 사용하여 모델이 언어의 기본 구조와 문맥을 배우게 합니다. 가령 위키피디아나 책, 웹 문서 등 다양한 도메인의 방대한 코퍼스를 활용하죠. 이 단계에서 모델은 텍스트의 통계적 패턴을 파악하고 단어 간의 관계를 이해하는 법을 스스로 학습합니다. 엄청난 양의 데이터를 사용하기 때문에 시간과 자원이 많이 소모되지만, 한 번 학습된 모델은 여러 하위 태스크에 공통적으로 활용될 수 있다는 장점이 있습니다.

충분히 사전 학습된 모델은 미세 조정을 통해 특정 태스크에 맞게 튜닝됩니다. 사전 학습 때보다는 적은 양의 태스크 특화 데이터를 사용하여, 기존에 학습된 가중치들을 조금씩 업데이트하는 거죠. 이를 통해 모델이 해당 태스크에서 최상의 성능을 낼 수 있도록 보정하는 것입니다. 이렇게 사전 학습된 언어 지식을 토대로 태스크에 맞게 모델을 미세 조정하는 전략은 매우 효과적인 것으로 알려져 있습니다.

사전 학습과 미세 조정이 중요한 이유는 이 방법론 덕분에 좋은 성능의 모델을 더 적은 시간과 비용으로 만들 수 있기 때문입니다. 처음부터 태스크 특화 데이터로만 학습을 하려면 많은 양의 레이블링된 데이터가 필요하고 오랜 학습 시간이 걸리겠지만, 사전 학습 모델을 활용하면 상대적으로 쉽고 빠르게 좋은 결과를 얻을 수 있습니다. 그래서 요즘에는 BERT나 GPT 같이 대규모 사전 학습 모델들이 많이 개발되고 있는 추세입니다. 

앞으로도 사전 학습과 미세 조정은 트랜스포머 기반 모델들의 성능을 극대화하는 핵심 기법으로 널리 활용될 것 같습니다. 더 크고 강력한 사전 학습 모델들이 계속해서 등장하고 있고, 이를 다양한 태스크에 적용하는 사례도 증가하는 추세니까요. 우리도 이런 흐름을 잘 이해하고 활용한다면 자연어 처리 분야에서 많은 성과를 낼 수 있을 것입니다.

사전 학습(Pre-training)과 미세 조정(Fine-tuning)은 딥러닝 모델, 특히 자연어 처리(NLP)와 컴퓨터 비전 분야에서 널리 사용되는 학습 방법론입니다. 이 방법론은 높은 성능의 모델을 효율적으로 개발하기 위해 설계되었습니다. 여기서 사전 학습과 미세 조정의 과정을 각각 살펴보겠습니다.

사전 학습(Pre-training)

사전 학습은 대규모 데이터셋에서 모델을 훈련시키는 초기 학습 단계입니다. 이 단계의 목적은 모델이 일반적인 지식을 습득하게 하는 것이며, 이러한 지식은 언어의 기본 구조, 문법, 단어 간의 관계, 이미지의 기본 패턴 등이 될 수 있습니다. 사전 학습을 통해 모델은 실제 작업과는 독립적인 광범위한 지식을 습득하게 되며, 이는 후속 작업에서의 성능 향상에 기여합니다.

• NLP에서의 사전 학습: NLP 분야에서 사전 학습은 주로 대규모 텍스트 코퍼스(위키백과, 책, 웹 텍스트 등)를 사용하여 수행됩니다. 예를 들어, GPT나 BERT와 같은 모델은 다양한 언어 모델링 작업을 통해 사전 학습됩니다.
• 컴퓨터 비전에서의 사전 학습: 컴퓨터 비전 분야에서는 ImageNet과 같은 대규모 이미지 데이터셋을 사용하여 모델이 기본적인 시각적 패턴과 객체를 인식하도록 합니다.

미세 조정(Fine-tuning)

미세 조정은 사전 학습된 모델을 특정 작업에 맞게 조정하는 과정입니다. 이 단계에서는 사전 학습된 모델의 가중치를 초기값으로 사용하고, 작업 관련 데이터셋을 사용하여 추가 학습을 수행합니다. 미세 조정을 통해 모델은 특정 작업에 필요한 지식을 습득하게 되며, 이는 작업의 성능을 크게 향상시킬 수 있습니다.

미세 조정의 주요 장점은 다음과 같습니다:

• 효율성: 사전 학습된 모델을 사용함으로써, 작은 데이터셋으로도 높은 성능을 달성할 수 있습니다. 이는 모델이 이미 일반적인 지식을 습득했기 때문입니다.
• 속도: 사전 학습된 가중치를 사용함으로써, 학습이 더 빠르게 수행됩니다. 모델은 무작위 가중치에서 시작하는 것이 아니라 이미 어느 정도 최적화된 상태에서 학습을 시작하기 때문입니다.
• 융통성: 미세 조정을 통해 다양한 작업에 쉽게 적용할 수 있으며, 특정 작업에 대한 모델의 성능을 최적화할 수 있습니다.

사전 학습과 미세 조정의 조합은 현대 딥러닝 연구와 응용에서 중요한 전략이 되었습니다. 이 방법론을 통해 개발자와 연구자들은 제한된 리소스와 데이터로도 복잡한 문제를 해결할 수 있는 강력한 모델을 개발할 수 있습니다. 이러한 접근 방식은 특히 자연어 처리(NLP)와 컴퓨터 비전 분야에서 큰 성공을 거두었으며, 이제는 음성 인식, 의료 이미지 분석, 그리고 다양한 종류의 예측 모델링 작업에도 널리 적용되고 있습니다.

사전 학습된 모델을 미세 조정하는 과정은 특히 데이터가 부족한 상황에서 그 가치가 빛납니다. 작은 데이터셋만으로도 고성능의 모델을 개발할 수 있기 때문에, 데이터 수집의 어려움이나 비용 문제를 상당 부분 해결할 수 있습니다. 또한, 미세 조정을 통해 하나의 사전 학습된 모델을 다양한 작업에 재활용할 수 있으므로, 모델 개발 시간을 크게 단축시키고 효율성을 높일 수 있습니다.

사전 학습과 미세 조정의 구체적인 절차

1. 사전 학습(Pre-training):
   • 대규모 데이터셋에서 모델을 학습시켜 일반적인 지식을 습득합니다.
   • NLP에서는 언어 모델링, 컴퓨터 비전에서는 이미지 분류 등의 일반적인 작업을 수행합니다.
2. 미세 조정(Fine-tuning):
   • 사전 학습된 모델을 기반으로, 특정 작업을 위한 작은 데이터셋을 사용하여 추가 학습을 수행합니다.
   • 이 과정에서는 학습률을 낮추고, 특정 작업에 맞게 모델의 일부를 조정합니다.

사전 학습과 미세 조정의 성공 사례

• NLP에서의 BERT와 GPT: 이 모델들은 다양한 NLP 작업에서 뛰어난 성능을 보여주며, 자연어 이해(NLU)와 생성(NLG) 분야에서 혁신을 이끌었습니다.
• 컴퓨터 비전에서의 ResNet과 EfficientNet: 이러한 네트워크는 ImageNet 같은 대규모 이미지 데이터셋에서 사전 학습된 후, 다양한 이미지 관련 작업에 미세 조정되어 뛰어난 성능을 나타냈습니다.

사전 학습과 미세 조정 기법의 발전은 앞으로도 계속될 것이며, 더 많은 분야에서의 응용이 기대됩니다. 이러한 접근 방식은 머신 러닝 모델의 효율성과 범용성을 높이는 데 크게 기여하며, 딥러닝 기술의 발전을 가속화할 것입니다. 따라서 이러한 기법을 이해하고 활용할 수 있는 능력은 머신 러닝과 인공 지능 분야에서 매우 중요합니다.