Haonly's Blog

내가 좋아하는 물리학자 김상욱 교수님의 <떨림과 울림>을 읽다가,

스쳐지나가듯 열역학 법칙이 언급되었다.

분명 고등학교 물리시간에 열역학 법칙 배웠고 외웠던 것도 기억이 나는데,

내용이 기억이 안난다.

그래서 정말 스쳐지나가듯 언급된 열역학 법칙이었지만 궁금해서 찾아봤다.

모두 이해하고 정리하긴 귀찮으니 간단 정리 & 링크 투척

열역학 제0법칙: 만약 두개의 계가 다른 세 번째 계와 열적평형상태에 있으면 이 두개의 계는 반드시 서로에 대해 열적 평형상태이어야 한다는 것이다. 이 법칙은 온도를 정의하는 하나의 방법이다.

열역학 제1법칙: 고립된 계의 에너지는 일정하다는 것이다. 에너지는 다른 것으로 전환될 수 있지만 생성되거나 파괴될 수는 없다. 열역학적 의미로는 내부에너지의 변화가 공급된 열에 일을 빼준 값과 동일하다는 말이다. 이 법칙은 제1종 영구 기관이 불가능함을 보인다.

열역학 제2법칙: 만약 어떤 고립 계의 엔트로피가 열적 평형 상태에 있지 않다면 엔트로피는 계속 증가해야 한다는 법칙이다. 닫힌 계는 점차 열적평형상태에 도달하도록 변화한다. 즉 엔트로피를 최대화하기 위해 계속 변화한다. 이 법칙은 제2종 영구 기관이 불가능함을 보인다.

열역학 제3법칙: 온도가 0으로 접근하면, 계의 엔트로피가 일정한 값을 가진다는 법칙이다.

출처: https://ko.wikipedia.org/wiki/열역학_법칙

URI(Uniform Resource Identifier) -> 통합 자원 식별자로 인터넷에 있는 자원을 나타내는 주소

URL(Uniform Resource Locator) -> 네트워크 상에서 웹 페이지, 이미지, 동영상, 등의 파일이 위치한 정보를 나타낸다.

URL(Unifor Resource Name) -> URI의 표준 포맷 중 하나, 이름으로 리소스를 특정한다. 

URL은 URI의 더 일반화된 부류의 부분집합이고 URI는 URL과 URN으로 구성된 종합적인 개념이다.

http는 스킴(어떻게)를 의미하고 ftp, rtsp(비디오) 등의 다른 가용한 프로토콜을 사용할 수 있다.

URL은 동일하게 '스킴://서버위치/경로' 구조로 이루어져 있다.

(항상 까먹어서 내가 보려고 정리!)

1편 토마가 뭐야? -> https://haonly.tistory.com/43?category=929804 

제.. 제가 클럽 회장이요...!?

토마 시작한지 어언 8년 차..? 햇수로만 따지면 9년이다. 진짜 x3 하면 내 나이,,,ㅋㅋㅋㅋ

사실 그중 한 5년 정도는 그냥 시험기간일 때는 잘 못 오는 학생 회원으로 직장인 으른 언니 오빠들 보며 '우왕 ㅇㅅㅇ' 하곤 했다. 

대학교 4학년 때는 그래, 어느 정도 어른(?)이고 딱히 취업에 별 뜻이 없어 매우 한가했으므로 조금 더 토며 들었었다. 처음으로 오피서(운영진) 역할도 해보며 클럽 운영은 이렇게 하는구나도 배웠다.

그냥 회원으로 활동할 때와 운영진으로써 책임을 가지고 역할을 해나갈 때는 확실히 다르다. 조금 더 클럽 Involved 되는 느낌!

그리고 확실히 약간의 소속감도 생긴다.

그러다가 가천대 근처에 모임을 만들게 되면서 나의 활동반경(?)을 조금씩 넓히게 되었다.

한 4~5개의 클럽을 관리하는 Area Director, 3~4개 Area를 관리하는 Division Director까지... 

2년 동안 디렉터 역할을 하다가 아! 우리 클럽에 집중하자 라는 생각이 들어 이번 텀에는 우리 클럽 회장직에 도전해 회장이 되었다.

사실 2년 동안 디렉터 역할을 했으니 좀 쉴까 했다. 

하기 전에는 하기 싫지만 이왕 맡은 거 우리 클럽 잘 키워서 다음 회장에게 넘겨줘야겠다는 생각이다.

동네 회원들도 모집하고 학생들도 모집해서 이왕 회장 된 김에! 토마가 이렇게 좋다는 걸 모두 모두에게 알려야겠다!

ㅎㅎㅎㅎㅎ 그래서 토마 하면 좋은 점을 소개하자면!

1. 영어 공부를 지루하게 가 아닌 즐겁게!
2. 외국인 친구들을 사귈 수 있다(GGLTM(나의 클럽!) 에는 외국인 유학생들과 교수님이 있어서 특장점!)
3. 모임 역할들을 통해 다양한 영어&리더십 기술을 기를 수 있다.
4. 나의 이야기를 할 수 있는 공간
5. 다른 사람의 이야기로 자극받기

열심히 사는 게 귀찮거나 지칠 수 있지만 하루 토마하고 나면 그렇게 뿌듯하고 동기부여가 된다.

내가 실수해도 아무도 비난하지 않는다. 실수는 토마에서 하고 현생에서는 토마에서 배운 걸로 멋있는 구성원이 되자는 게 나의 생각!

내가 다니는 클럽은 가천대학교 근처에서 시작해서 클럽 이름이 Gachon Global Leaders 이다! ㅎㅎ 내가 charter 한 '첫' 클럽이라 애정이 많이 간다.

Toastmasters International에 올라가 있는 우리 클럽 소개 페이지이다.

https://www.toastmasters.org/Find-a-Club/07535536-gachon-global-leaders-toastmasters

성남에서 영어 공부하고 새로운 친구를 만나고 싶으시다면...! 조용히 저에게 연락을 주세요 ㅇㅅㅇ!!!!

일상 속 사물이 알려주는 웹 API 디자인이라는 책을 읽으며 정리한 내용입니다. 

프로그래밍 인터페이스 디자인하기

내용

• API 목표를 프로그래밍 인터페이스로 변형하기
• REST 리소스와 액션을 식별하고 매핑하기
• 컨셉으로 API 데이터 디자인하기
• REST API와 REST 아키텍처 스타일의 차이점
• API 디자인에서 REST 아키텍처 스타일이 중요한 이유

REST: Representational State Transfer

GET, /products/{productId}, 200 OK 라는 용어들의 의미를 이해해야 프로그래밍 인터페이스를 디자인할 수 있다.

REST API는 REST 아키펙처 스타일에서 기반하고 있다.

REST API 소개

REST API 호출 분석

p123이라는 상품 카탈로그 정보를 REST 쇼핑 API를 통해 가져오고자 한다면 HTTP 프로토콜을 이용하여 커뮤니케이션해야 한다.

이 목표가 GET /products/{productId} 로 표현되므로 컨슈머가 위와 같이 리퀘스트를 보내야 하며 서버가 HTTP response로 응답(200 OK)을 반환한다.

경로: 서버상의 리소스를 식별할 수 있는 주소

HTTP 상태코드: request에 대한 응답

response 바디: 응답에 대한 콘텐츠

응답은 JSON 형태이나 단순히 JSON 데이터를 가져오려는 목적으로만 만들어진 것이 아님

HTTP의 기초사항

HTTP는 World Wide Web의 기초.

다양한 상황에서 HTTP 프로토콜을 사용한다. - GET/POST/DELETE 등

HTTP 요청에는 목적이 무엇이든 HTTP 메서드와 리소스 경로가 포함된다.

• HTTP 메서드: GET / POST / DELETE / 등
• 리소스 경로: 어떤 리소스에 접근하는지

REST API의 기초원리

상품 정보를 가져오는 목표를 실행하는 REST 쇼핑 API의 예에서, 

컨슈머는 HTTP 리퀘스트를 API 호스팅 서버에 보내야 한다.

이 리퀘스트는 GET HTTP 메서드를 사용해, /products/{productId} 경로로 식별되는 상품을 찾는다.

서버는 상품 데이터와 이를 나타내는 HTTP 상태 코드가 포함된 response를 함께 리턴한다.

결국! REST API는 HTTP 호출 그 이상의 행위를 하지 않는다. 

API 목표를 REST API로 변형하는 과정

(to be continued..)

사용자를 위한 웹 API 디자인하기

주제

• 어떤 관점으로 API를 디자인해야 하는가?
• 사용자 인터페이스를 디자인하듯 API 디자인하는 법
• API의 실제 목표를 정확하게 결정하는 법

API를 사용하는 사람들이 원하는 것이 무엇인지의 관점.

소셜 네트워크의 API는 사진 공유, 친구 추가, 친구 리스트 표시 등이 API의 목표이며 이러한 목표들이 효과적인 API를 디자인하는데 필요한 기능적 청사진 역할을 함

그렇기 때문에 목표 식별이 중요하며 서로 연관된 포괄적인 요구사항들을 정리할 수 있도록 컨슈머의 관점에 중점을 두어야 한다.

사용자가 얻을 결과에만 집중하는 것이 중요하다. 즉, 컨슈머 관점에서 사용하기 쉽도록 개발해야 한다.

API의 목표 식별 과정

API를 디자인할 때 고려해야 하는 점

• 누가 API를 사용하는가?
• 무엇을 할 수 있는가?
• 어떻게 하는가?
• 하기 위해서 무엇이 필요한가?
• 끝나면 무엇을 반환하는가?

-> 사용자들의 요구사항을 수집하고, 그 요구사항을 깊이 파고 들어가 정확히 이해하며, 마침내 그 목표를 조금이라도 효율적이며 정확하게 달성해야 한다.

이때 누락된 목표나 사용자는 없는지 잘 확인해야 한다.

API 목표 캔버스를 사용하여 "누가", "무엇을", "어떻게", "입력", "출력" 목표"를 설정.

누가 사용자인지와 흐름들로부터 새로운 목표를 찾아내는 과정들이 중요하다.

API 디자인에서 피해야 할 프로바이더 관점

API는 근본적으로는 컨슈머와 프로바이더라는 두 개의 다른 소프트웨어 간의 데이터를 교환하는 방법을 의미한다.

프로바이더 관점에서 데이터의 체계와 이름을 그대로 API 목표와 데이터에 매핑하는 실수를 하기도 하는데, 이는 이해하기도 어렵고 사용하기도 어렵게 만든다.

데이터 모델과 조작에 관한 내용은 노출되면 안 된다.

내부 비즈니스 로직의 노출은 API의 컨슈머가 이해하기도 어렵게 하며 프로바이더에게도 위험하다.

숨겨야 하는 인적 조직을 API 디자인에 매핑시키지 않아야 한다.

요약

API 목표 목록은 포괄적이고 컨슈머 지향적이어야 하며 프로바이더 관점이 드어가서는 안된다.

카프카 아키텍처 생각해 보다가 갑자기 궁금한 점이 생겼다.

카프카는 같은 파티션 안에서 순서를 보장해주며 여러 파티션을 분산 처리할 수 있는 장점을 가지고 있기 때문에 사용한다.

근데 "같은 파티션 안에서 순서를 보장해준다면 같은 토픽의 다른 파티션 간의 순서는?" 이라는 의문이 들었다.

마침 우아한형제들에서 진행하는 우아한테크세미나에서 이 의문에 대해 의외로 간단한 답변으로 답을 듣게 되었다.

다른 파티션 간의 순서는 보장 안한다.

물론 아주 복잡하게 순서가 뒤바뀌어 들어와 처리 순서가 많이 뒤바뀌진 않기도 하겠지만, 다른 파티션 간의 순서까지 보장하려면 FIFO 쓰지 왜 카프카 쓰겠느냐는 것이다. 

음식 주문의 예시로 생각해보면 1분에 1000개 주문이 들어온다고 할 때, 그 안에서의 순서는 크게 서비스에 영향을 미치지 않는다는 것 같다.

파티션이 4개라면 그 안에서 250개의 주문들은 각 파티션 안에서 순서가 지켜질 것이다.

카프카를 나름 잘 안다고 생각하고 있는데, 공부하면 할수록 공부할 것들이 많다...!

카프카 스트림즈라는 카프카 내의 새로운 개념까지 최근에 알아버려 공부할 게 또 생겼다.

재미있기는 한데 나는 왜이리 모르는 게 많은 건지ㅠㅠ ㅋㅋㅋ 시간을 쪼개어 공부를 열심히 해야겠다!