개발자 99% 커뮤니티에서 수다 떨어요!
오늘 TIL 3줄 요약
잡학사전 마지막 에피소드들을 읽는 챌린지 날!
복붙이 난무하는 디지털 세상속에서 NFT의 가치는 더 반짝일거다.
멀웨어 너무 무섭다. 여러분들 좋은 기술로 평화로운 세상을 만드는 것에 더 관심을 두지 않으시겠어요?
TIL (Today I Learned) 날짜
2023.09.06
오늘 읽은 범위
에피소드39. 인공지능, 머신러닝, 딥러닝, 아직도 구분하기 힘들다고?
에피소드40. REST API라니, 휴식 API인가? 이게 대체 뭐죠?
에피소드41. 도커가 뭐지? 왜 필요할까?
에피소드42. 암호화폐의 진실
에피소드43. 하이브리드…앱? 뭐라고요?
에피소드44. NFT가 도대체 뭐길래?
에피소드45. 멀웨어, 바이러스, 웜 개념 몽땅 정리
책에서 기억하고 싶은 내용을 써보세요.
인공지능의 두 갈래: 좁은 인공지능, 일반 인공지능
일반 인공지능(general AI): 강한 인공지능(strong AI)이라고도 한다. 영화에 주로 등장하는 개념으로 인간의 행동을 대부분 하거나 그 이상의 능력을 발휘하는 인공지능. 현실에는 없음.
좁은 인공지능(narrow AI): 약한 인공지능(weak AI)이라고도 한다. 현실에서 주로 다루는 인공지능. 몇가지 일을 탁월하게 수행함. 예) 페이스북 얼굴 인식 기능, 스마트폰 음성 인식 비서
인공지능이 학습하는 방식, 인공지능을 학습시키는 방식 -> 머신러닝 / 딥러닝
머신러닝: 인공지능을 학습하는 방식
기계를 가르치는 2가지 방법: 지도 학습(supervised learning), 비지도 학습(unsupervised learning)
지도 학습: 인간이 기계에게 준 ‘라벨’을 토대로 학습해서 대답하는 경우. 어떤 사물의 특징을 미리 알려주고 학습시킨다. 예) 음악 추천 시스템
비지도 학습: 라벨이 없는 데이터를 주는 것. 라벨 없이 사물의 여러 모습을 주고 기계가 스스로 학습하도록 하는 방법.
딥러닝: 머신러닝을 달성하기 위한 방법. 머신러닝의 하위 개념. 대표 알고리즘: 뉴럴 네트워크(neural network). 엄청나게 많은 층으로 구성돼 있는 머신러닝의 한 종류.
텐서플로: 인공지능을 개발하는 도구로 가장 유명한 프레임워크. 파이썬으로 다루기 좋은 프레임워크지만 C++이나 Go등 다른 언어로도 다룰 수 있다.
REST API
API의 한 종류. Representational state transfer(REST: 설계 철학). REST 방식으로 설계한 API.
URL에서 동사 제외하고, HTTP 메서드(GET/POST/DELETE/UPDATE 등)를 접목하고, 쿼리를 이용해 세부 조건을 가지고 올 수 있도록 한다.
동사를 사용하지 않는 것만으로도 URL이 단순하게 바뀌는 장점이 있다.
도커는 개발 환경이 맞지 않은 상황 또는 개발환경이 변경되었을 때 유연하게 대처할 수 있게 해준다. 어떤 컴퓨터에서도 같은 개발환경을 제공한다.
컨테이너: 도커가 준비한 프로그래밍 언어가 동작하는 환경
모바일 애플리케이션 만드는 3가지 방식: 하이브리드 방식(앱), 크로스 플랫폼 방식(앱), 네이티브 방식(앱)
하이브리드 앱
웹 사이트를 보여주는 웹 뷰(브라우저의 윈도우 부분 - 웹 브라우저에서 주소창을 제외한 나머지 부분).
HCJ로 개발한 웹 앱을 iOS/안드로이드에서도 쓸 수 있도록 하이브리드로 만들어 앱을 판매하는 곳에 보내는 것.
장점: 네이티브 앱 개발 지식이 필요 없음
단점: UI를 한 땀 한 땀 짜야한다. 스마트폰 성능을 온전히 활용하지 못한다.(고급 하드웨어 기능 활용 힘듦)
아파치 코르도바: 니토비가 만들고 어도비 시스템즈가 인수한 모바일 개발 프레임워크. 소프트웨어 프로그래머들이 오브젝티브-C처럼 기기에 특화된 언어들 대신 자바스크립트, HTML5, CSS3를 이용하여 모바일 기기를 위한 응용 프로그램들을 만들 수 있게 한다. (From 위키)
크로스 플랫폼 앱
특정 언어로 코딩하면 나중에 iOS, 안드로이드가 이해할 수 있는 코드로 변환해서 만듦.(네이티브 코드로 변환된다)
Ex. 플러터: 다트라는 언어로 코딩한 코드가 c나 c++과 같이 iOS, 안드로이드에서 이해할 수 있는 언어로 변환된다.
장점: 1)개발자가 익숙한 코드로 한번만 작성해도 iOS, 안드로이드 두 환경에서 실행할 수 있다. 2)다양한 배경의 개발자 풀로 인해 커뮤니티 발전이 크다.
단점: 네이티브 언어로 변환하는 과정에서 네이티브 앱에 비해 성능이 떨어진다.
네이티브 앱
iOS 또는 안드로이드만을 위한 언어로 코드를 작성해서 개발한 앱. (iOS: 스위프트 / 안드로이드: 자바 또는 코틀린)
장점: 스마트폰 성능을 최대로 사용할 수 있다.
단점: 학습에 배의 시간이 든다. (iOS, 안드로이드를 위한 언어를 몽땅 배워야한다. 유지보수도 생각하면 더 그렇다.)
NFT: non fungible token. 대체 불가능한 토큰.
토큰: 블록체인으로 발생. 핵심 기능 1)돈을 받는 기능 + 2)돈을 받고 토큰을 보내주는 기능 = 스마트 계약(smart contract)
예) 코인
코인은 여러개 있을 수 있지만, 토큰을 딱 하나만 발행할 수 있도록 스마트 계약을 만들고 그 안에 이미지, 영상, 노래 전세 계약서 등 컨텐츠를 넣는다. => NFT의 탄생.
NFT를 보면 실제로 돈을 주고 재화를 산다기 보다, 돈을 주고 ‘단 한 번만 발행된 토큰’을 산다고 이해하면 된다.
유일한 원본, 진짜라는 사실이 가치를 높여준다. NFT는 유일함을 증명하는 기술.
예시들)
트위터 창업자 잭 도시는 트위터 역사 시작을 알린 첫째 트윗을 NFT에 담은 채로 판매.
액시 인피니티(게임) 캐릭터.
멀웨어(malware)
Malicious + software -> 악성 소프트웨어
컴퓨터를 감시하거나 파괴하는 녀석
많이 알려진 것: 바이러스, 웜
바이러스와 웜의 공통점: 복제돼서 전파됨
바이러스와 웜의 차이점: 숙주 필요 유무의 차이(바이러스는 숙주가 필요하지만 웜(자기 자신 복제)은 아니다)
웜
미사일(missile)을 통해 컴퓨터로 침투하고, 그 순간 페이로드(payload)를 배포해 컴퓨터를 장악한다.
감염 경로: 감염된 컴퓨터에 존재 -> usb 연결한 순간 usb를 탑승 -> usb가 다른 컴퓨터에 연결되면 암호화 된 상태로 컴퓨터에 도착해 스스로 암호를 해제하고 웜을 만든 본부에 연락(?!)한다.
웜은 컴퓨터의 루트에 설치된다. 백신보다 더 우위에서 진두지휘가 가능함.
제로데이(zero day) 취약점: 아직 아무도 발견하지 못한 프로그램의 취약점
스턱스넷 웜: 제로 데이를 4개나 가지고 있었음.
오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요
RESTful, RESTful 엄청 많이 듣고 REST API도 많이 들었는데, 책 읽으면서 이제서야 좀 더 확실하게 이해가 됐다. 설계 방식, 철학이었구나. 설계 예시를 좀 더 살펴보았다.
URI는 동사보다는 명사를, 대문자보다는 소문자를 사용하여야 한다.
마지막에 슬래시를 포함하지 않는다.
언더바(_) 대신 하이픈(_)를 사용한다.
파일 확장자는 URI에 포함하지 않는다. (어찌보면 당연한 거라고 생각했는데?!)
행위를 포함하지 않는다.(책에서 말한 getPost, deletePost 같은 걸 하지 말라는 이야기, 동사를 쓰지 말라는 의미와 일맥상통 하는 듯 하다.)
REST의 단점도 짧게라도 함께 서술 됐다면 더 좋았을 에피소드 같다.
암호화폐 시장은 기술 자체만 봤을땐 이상적이고 획기적인데 규모는 커가는 한편 불안정하다는 느낌을 지울 수가 없어 쉽게 관심이 가지 않는다. 이번 에피소드에서 코인의 가치를 제대로 알아볼 수 있을 몇가지 방법들을 알려준 점이 좋았다. 책에서 언급된 것처럼 아무리 이런 방법들을 알아도 속일 사람이 끝까지 속이고자 한다면 어쩔 수 없는 거겠지만… 그런데 사기 감별 노하우 4번째에서 나온 ‘탈중화된 코인인지 살펴라’ 부분은 너무 의외다. 나는 코인의 기본 원칙이 탈중앙화라고 생각했고 당연히 모든 코인이 그럴 줄 알았는데 창립자나 회사에 속해있기만 할 수도 있구나. 이런건 정말 조심해야겠네.
재택 근무를 떠올리면 가장 먼저 드는 생각이 ‘원룸은 힘들다’이다 ㅠㅠ 물론 사람마다 다를 수 있겠지만, 원룸은 특히나 공간 분리가 없어서 쉽게 다른 것으로 새기도 쉽고 일과 생활간의 구분의 필요성에서 오는 스트레스도 크다. 원룸에서 지내면서 재택을 해본 경험을 하고 나니 이 조건은 더 나에게는 맞지 않았던 것 같다. 결국 그 당시에는 가까운 곳이라도 나가서 하는 게 환경 구성에 좋았고 쓰지 않아도 될 비용이 생기기도 했다. 코로나를 겪으면서 재택이 좀 더 각광받는 근무 스타일로 떠오르긴 했지만 나에게는 ‘자택’에서 하는 것보다는 근무 환경지가 따로 있는 조건에서 선호하게 되는 것 같다.
NFT가 궁금해서 책을 사두기만 하고 코인과 같은 느낌이라 쉽사리 손이 가질 않았는데, 이번 NFT 에피소드를 읽으면서 좀 더 관심이 생겼다. 복붙이 넘쳐나는 디지털 세상에 하나뿐인 어떤 것, 그리고 그것을 증명할 수 있는 기술이라. 확실히 점점 더 그 가치가 커질 것 같다. 공부하면서 인터넷의 블로그, 웹사이트 등에서 정보를 많이 찾는데, 같은 내용의 글이 여기저기서 발견될 때가 많다. 출처라도 있으면 어디서 부터 시작한 글인지 알 수 있지만, 그렇지 않은 경우에는 누가 최초 기술자이고 그 지식을 소유하고 있는지 알 수 없다. 만약 누군가가 그 내용을 영리목적으로 쓴다면? 원작자가 찾아내면 그에 대한 요구를 할 수 있겠지만, 그렇지 않다면 모르고 지나가겠지? NFT가 이런 작은 부분까지 쓰일지는 모르겠지만, 디지털 세상에 소유권을 주장할 수 있는 기술이라는 것이 생겼다는 것만으로 그 사용 범위는 점점 넓혀질 수 있는 가능성이 있지 않을까?
와…스턱스넷 이야기 한편의 영화같다. 라고 생각하고 찾아봤더니 2016년에 ‘제로 데이즈’라는 실화 바탕 다큐멘터리도 있었다. 그 어떤 에피소드보다 몰입감 있게 읽어나가다가 ‘핵 원심 분리기를 노린 스턱스넷’에서 순간 눈을 껌벅였다. ‘뭐라고? 내가 제대로 읽은 것 맞나?’하고…ㅋㅋㅋㅋㅋ 정말 위험하게도 사용했구나… 물리적 접근이 아니고서야 얻을 수 없는 정보에 노리고 있던 목표까지 생각하면 이 웜의 배후에 엄청난 집단이 있었다고밖에 해석이 되지 않는다. (심지어 책에서는 제로데이가 4개 있었다고 하는데, 나중에 알게 된 바로 1개 더 많은 5개나 있었다고 한다!) 기술은 양날의 검이라지만 이런식으로 기술이 사용되는 사례는 너무 충격적이다. 특히나 대의를 위해서라기 보단 우위에 있기 위해… 유용한 기술로 세상을 좀 더 살기 좋게 만드는 것만 생각했는데 왜이렇게 무섭게 사는거야 ㅠㅠ 상상만 해도 스트레스다. 멀웨어로 사회에 해악을 끼쳐 원하는 걸 얻고자 하는 사람들 다 천벌 받았으면 ㅠㅠ (갑자기 감상적이어졌다ㅋㅋ) 조만간 ‘제로 데이즈’를 읽고 감상글을 꼭 써봐야지. 다큐멘터리니만큼 더 자세한 내막을 알 수 있을거 같다!
책 다 읽었다! 오늘 마지막 남은 책 챕터를 다 읽는 것이다보니 읽을 에피소드가 많았지만, 접해보지 못한 정보가 많은 에피소드라 집중해서 물 흐르듯 술술 읽어내려갔다. 에피소드가 많아서 기록한 것도 비교적 더 길어졌다. 마지막 날에는 책 다 읽은 소감을 쓸 것 같으니까 오늘은 조금 말을 아껴둬야지 ㅎㅎ 책을 다 읽었다니 뿌듯하다! 읽은 책을 기록해두는 앱이 있는데 다 읽자마자 거기에 기록해 한권 더 쌓았다!
궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.
찾아본 REST (API)의 단점
HTTP 메소드의 형태가 제한적이다: REST는 HTTP 메소드를 사용해 URI를 표현하는데 형태가 제한적이라는 이유로 모든 부분에서 해결책을 제공하는데는 한계가 있다고 한다.
예) 메일 보내는 기능을 작성할때: 단순히 보내는 기능 외 누구한테, 얼마나 많이, 예약여부 등 다양한 세부기능이 있을 때 이를 구현하는데 제한이 있을 수 있다.
표준의 부재
표준이 존재하지 않는다고 한다. (아 ?!) 공식화 된 API 디자인 가이드가 존재하지 않는다고.
이거는 생각도 못한 부분이다. 보통 어떤 기술이 있으면 다들 공식 문서는 있으니까 당연히 REST도 설계 방식, 철학이니 있을거라고 생각해서 그런거 같다. 모두들 많이 쓰고 있어서 암묵적으로 정해진 약속들이 있겠지만, 이 부분은 조금 큰 단점.. 단어가 단점 말고 더 어울리는 게 있을 거 같은데 시원한 단어가 안떠오른다.
263p에 ‘어떤 프로그램을 개발할 때는 늘 취약점이 남기 마련이거든? 그런데 그 취약점은 발견되는 날까지는 고칠 수 있는 시간이 아예 없는 거나 마찬가지잖아?’ 이 부분 문장이 조금 이해가 가지 않았다. ‘그런데 그 취약점은 발견되기 전까지는 고칠 수 없는 거나 마찬가지잖아?’라는 의미를 전하고 싶으셨던 걸까?
웜은 컴퓨터 루트에 설치되고 백신도 이를 파악하지 못한다고 하는데, 그럼 웜에 감염됐는지 아는 방법은 정령 없는 것인가? 너무 불안한디ㅠㅠ
오늘 읽은 다른사람의 TIL
‘오늘도 blueseo님의 정리는 깔끔하구나’하고 읽다가 ‘개체 지향’에서 눈이 멈췄다. 이때까지 당연히 ‘객체 지향’이라고 배워왔고 그렇게 알고 있어서 의문을 던진적도 없는 부분인데, blueseo님의 TIL을 보다가 ‘개체 지향’이라는 말이 오역으로 ‘객체 지향’이 됐다는 부분을 보고 어리둥절해 찾아보게 됐다. 커뮤니티에서도 의견이 분분한데 정말 생각도 못한 부분이라 충격이었다. 누군가는 ‘객체 지향’이라고도 충분히 불릴 수 있어서 문제가 없다고 하고, 누군가는 ‘개체 지향’일 수 밖에 없는 이유를 설명하고, 누군가는 이러면 어떻고 저러면 어떻냐고 하고…(ㅋㅋ) 와 어렵다. 하긴 우리가 쓰는 프로그래밍 단어는 영어에서 온 것이라 오역이 분명 있을수도 있겠구나. 검색해보면 ‘개체 지향’이라는 글은 많이 나오지도 않는데, 대부분 나처럼 공부할 때 ‘객체 지향’이라고 배우며 시작하니 아무도 의문을 던지지 않아서 그런가 싶기도 하다. 이걸 이렇게 처음 번역한 사람한테 잘못을 따져야하나?! 새롭게 충격적인 사실을 알게 돼서 너무 기억에 남는 TIL이 됐다.
이번 에피소드로 올라온 TIL을 읽고 올리고 싶어서 TIL들이 올라오면 읽고 늦지 않게 좀 더 추가하겠습니다 :)이라고 했지만 생각해보니 중간부터는 다른분들의 TIL을 열심히 읽었는데 초반부터는 많이 읽지 못해서 TIL 남기는 첫일차 챌린지부터 찾아 조금이라도 글을 남기고 싶거나 공감가는 TIL이 있으면 가져왔습니다...ㅎㅎ 이렇게 다른 사람 TIL 읽고 남기는 것도 마지막일 수 있으니...ㅎㅎ '최애틸'이라기 보다는 '생각하게 하는 틸'...이랄까요? 이래도 괜찮죠? ㅋㅋ버그가 생겼을 때 기록을 하는 것에 대해 어떨지 남기셨는데, 매우 하시는 것이 좋다고 생각한다! 사실 나는 엄청 큰 버그 (내가 충격먹은 버그나 코드)가 아니면 남기지 않고 넘어가거나, 남기더라도 개인 메모장에 수기로 남기는 편인데, 나중에 가서 조금 아쉬워졌다. 어떤 것이든 '기록'해두는 건 큰 자산이 된다. 온라인에 누군가와 공유하기 위해 글을 쓰는 건 아무래도 정리도 잘 돼야할 것 같고 시간도 드는 것 같아 더 잘 안하게 되는데, 만약 이런 마음이라면 개인적으로 한 공간에 정리해두는 것도 좋은 방법인 것 같다. (이 틸들도 기록이니 큰 자산이 되겠지!)
두분이 써주신 소감에서 기술의 변화가 빠르다는 점에 매우 공감한다... 나는 특히 프론트엔드에 관심이 많아서 프론트엔드 기술을 비교적 많이 접하곤 하는데, 친구들이랑 이야기하다보면 정말 별별 프레임워크, 기술들이 다 있다. 내가 쓰는 건 고작 잘 알려진 몇개 뿐인데, 이거 익숙해지려면 아직 갈 길이 먼데, 또 저런 기술들도 있네 하면서 이마를 짚는다 🤦♀️ 선택지가 많고 다양한 기술들이 있다는 건 장점이자 단점일테다. 그만큼 계속 기술에 예민해야되고 트렌드를 잘 읽어야 한다. (얼마전 인스타그램에서 프론트앤드 개발자이자 웹에 유용한 인스타그램 컨텐츠를 만드는 인플루언서가 최근 릴스에 유용한 기능이라고 3가지를 소개했는데 바로 '이건 유행지난지 오래고, 이거보단 이게 좋고, 이거는 평균정도는 하겠네'라고 댓글이 달린 걸 보고 '하... 이런 컨텐츠 만드는 사람도 힘들겠다...'라는 생각을 했다. 변화가 너무 빨라!)
3줄 요약이 인상 깊어서 가지고 왔다. ㅎㅎ 글을 클릭하고 순간 갑자기 많은 양의 정보가 눈에 들어와서 어어어? 하다가 이해하고 '아 그렇지 이렇게도 쓸 수 있겠지!'라는 생각이 들었다. 스크롤 내리지 않고 본론을 바로 볼 수 있어서 매우 효율적인 vndnsla12님의 3줄 요약👍
이 틸은 역시나 blueseo님의 틸 답게 정리가 깔끔하고 보기 좋아서 담아뒀다. 다른 분들도 blueseo님의 틸 보고 가세요!ㅎㅎ 소감에 '미래까지 계산하여 코드를 짤 수 있는 실력'은 어떻게 언제 나타날까... 완벽하진 않아도 제대로 깔끔하게 짰다고 생각한 코드도 한 6개월 뒤에 보면 '이거 누가 짰어? #$%#$$%^' 하고 보면 내 코드인데 ^^; 연습에 실습에 또 연습이 필요한 것...
에피소드명만 본문 스타일로 지정해 중간 정렬하니 틸이 확실히 더 정리된 느낌이라 눈에 쏙쏙 들어오는 틸이다. 25.skywalker님의 소감에서 '개발자와 성향이 맞는 것 같다'라고 자신감 있게 써주신 부분이 매우 부러워서 가지고 왔다. 제게도 저런 확신이 있었으면 좋겠어요!!! 프로그래밍을 배우고 코드를 하는 매 순간이 스스로를 의심하는 시간...ㅠㅠ하하하
이 틸은 중간에 erin님이 '언어 이름은 왜 그렇게 지었을까' 에피소드를 읽고 각 언어 기원을 적은 부분이 마치 시같아서 가지고 왔다ㅎㅎ 특히나 저렇게 한 언어마다 줄을 나눠놓으니 개인적으로 윤동주의 하늘과 바람과 별과 시의 구절 (별 하나에 추억과 별 하나에 사랑과 별 하나에 쓸쓸함과 ...) 이 떠오르는 것 같은 느낌이 들었다. 프로그래밍의 언어 이름 기원이 이렇게 시적일 줄이야 😆
chacha님이 틸 마지막에 '여러 언어를 다 방면으로 개발하는 개발자가 좋은 개발자 일까요? 하나를 제대로 잘하는 개발자가 잘하는 개발자 일까요?' 라고 적어주신 걸 보고 예전 같았으면 고민을 많이 했겠지만, 지금은 '하나를 제대로 잘하는 개발자'에 좀 더 무게를 두고 싶다. 프로그래밍 언어는 비슷하게 생기기도 다르게 생기기도 했지만, 비슷한 방법으로 사용되고 좀 더 세분화 된다고 느꼈다. 그래서 여러개 배워보는 것도 좋지만, 맘에 드는 혹은 어떤 계기든 한 언어를 골라서 좀 더 자세하게 배우면 그 언어에 대한 이해가 깊어지고, 그 언어를 바탕으로 해서 다른 언어를 해야할 때도 좀 더 쉽게 접근이 가능하다고 생각한다. 오히려 한 언어를 깊게 배우는 게 배움의 유연성에도 도움이 되는 것 같기도... 다른 사람들의 의견도 궁금합니다 :)