URL -> Uniform Resouce Locator
인터넷에 존재하는 자원의 위치와 그 접근방법을 지원하기 위한 것.
은 사전적인 뜻이고 흠, 그냥 위치. 로케이션 이렇게 이해하면 편할듯 하다.
인터넷에 존재하는 위치. 또는 경로. 말 그대로 URL..
html -> hyper text markup language
요건 이제 웹 문서를 만들기 위해 사용하는 기본적인 웹 언어의 한 종류.
인터넷에서 웹을 통해 접근되는 대부분의 웹페이지들은 이 HTML 로 작성된다고 할 수 있다.
HTML로 작성된 문서를 HTML 문서라고 하고 이 HTML로 작성된 문서를 웹 브라우저가 해석하여
이용자에게 보여주게 된다.
브라우저가 뭐임? -> 크롬, 웨일, 파이어폭스, 사파리 등과 같은 우리에게 웹페이지를 보고, 검색하고 등등을 하게 해주는 것을 말함.
HTML -> 국제표준 SGML의 부분 집합으로 정의되었음.
SGML? 그건 또 뭐임.. -> Standard generalized Markup Language.
이게 HTML 보다 .. 가장 먼저 나온 " 마크업 언어 " 라고 한다. 마크업 언어라고 해서 말인데 마크업 언어는 또 뭘까?
우선 SGML 은 IBM 사내에서 문서를 쉽게 교환하고자 만든 것이라고 한다. 1986년에 ISO 표준으로 정의되었다고 함.
SGML 의 특징은 특정 문서를 정의하는데 필요한 태그를 임의로 생성하여 문서 구조를 정의할 수 있었다고 하는데
이게 너무 복잡하고 활용하기 어려워서 이를 지원하는 소프트웨어를 개발하기 어려운 문제가 어렵다는 문제가 있다.
-> HTML은 완전한 파생형은 아니지만 SGML의 영향을 강하게 받았다고 최초 제안자였던 팀 버너스리 아재가 말했다고 한다.
아무래도 HTML의 기본 베이스가 SGML 이었나보다. ( 야생의 숨결같은 포지션이었나 )
그럼 XML은? -> ( eXtensible Markup Language ) = extensible 펼칠 수 있는, 늘릴 수 있는.
1996년에 w3c가 제안한 웹 문서 표준 형식으로 sgml의 하위셋이라고 볼 수 있다.
인터넷 환경에 적합하도록 간결성, 보편성, 활용성에 중점을 두고 설계.
그래서 무슨 차이가 있나? -> HTML은 디자인에 조금 제한되어있는데
XML은 독자적인 애플리케이션을 갖는다.
그게 무슨 소리냐? -> 애플리케이션에서도 쉽게 구현될 수 있도록 만든 것이라고 보면 됨.
html은 태그가 정해져있는데, xml은 sgml처럼 어느정도 문서의 내용에 관련된 태그를 사용자가 직접 정의할 수 있고
그 태그를 또 다른 사람들이 사용할 수 있게 할 수 있다.
Markup language? -> 프로그래밍 언어는 아니다. ( 나무위키 설명 참조 )
책에 볼펜으로 밑줄을 긋거나 볼펜으로 필기를 하는 행위는 마크업의 일종이다.
책 표지 이렇게 해주시고~ 볼펜에다가 이렇게 그려주시고~ 제목은 어떻게 해주시고~ 크기는 어떻게 어떻게~
이렇게 말하는 것 또한 마크업 언어라고 할 수 있다.
프로그래밍 언어가 아닌 이유 -> 프로그래밍 언어였다면 이제 책을 펼칠 때 마다 내용이 달라지거나 했겠지.
다만 현실에선 그게 불가능하다.
마크업 언어는 현실의 아날로그적인 기록매체와 유사한 역할을 한다고 볼 수 있다.
-> 일단 한번 작성하면 누가 언제보든 동일한 모습을 보여준다는 점이 같다.
그럼 프로그래밍 언어는 뭔데? -> 배워야할 자바스크립트가 그 대표적 예이다.
지금은 제이쿼리를 쓰고 있지만 내일 또는 내일 모래에 자바스크립트 기초도 다시 공부해두어야 한다.
( 자바스크립트가 없었으면 웹 페이지의 동적인 설계가 불가능 )
아날로그, 언제 어디서든? 은 웹표준과 웹접근성과 관련이 깊다. 이 또한 기본이니 복기해두자.
웹 표준이 뭔데? -> WWW( 월드 와이드 웹 ) 을 구현하기 위해 따라야할 표준 또는 규격.
= 웹에서 표준적으로 사용되는 기술이나 규칙
( HTML, CSS, Javascript 등의 규칙이 담겨있음 )
-> 실제로 마크업을 다 하고 W3C 벨리데이터로 검사를 하거나 테스트를 해서 마크를 받아보면 매우 도움이 많이 됨. ( 오류를 잡아줌 )
w3c -> ( 국제 표준화 기구 )
왜 쓰는거임? 왜 필요한거임? -> 웹 표준을 지키지 않으면 말 그대로 엉망이 되어버림.
특정 브라우저에서만 호환이 된다거나.. ( 공인인증서..옛 인터넷 익스플로러 엑티브 x... 등등 )
여기선 호환되고 저기선 호환안되고 이런 문제들을 막고자 웹 표준이 있음 ( 웹 개발자도 좋고 유저들도 좋고 )
= 어떤 운영체제를 쓰든 어떤 브라우저를 쓰든 동일하게 보여야한다는 의미
웹 표준 -> 너가 닌텐도를 하든 윈도우 pc를 하든 아이폰으로 하든 원신을 플레이하면 동일하게 보여야 한다.
너무 당연하지만 웹 표준 지켰을 때의 장점 -> 우선 개발자들이 좋다.
개발 및 운영을 할 때 아무래도 공통된 소스들이 있다보니 유지보수하기에도 훨씬 더 효율적이다.
그리고 웹 접근성과도 관련이 깊다. 그리고 코드의 양도 줄어서 파일 크기가 줄고 서버 부담 감소로 이어지기까지도 한다.
++ CSS와 HTML이 분리가 되어서 유지보수에 들어가는 시간이 단축되고 +로 불필요한 마크업이 줄어들어
페이지가 로딩되는 시간까지 줄여줄 수 있다.
+ 로 오래된 브라우저에서도 컨텐츠가 적절하게 표시되고 호환성과 운용성이 확보된다.
+로 검색 봇을 통한 효율적 노출과 검색 엔진 최적화(seo)가 가능하다.
웹 표준 기술 -> XHTML, CSS, XML, DOM, 등 등 . . .
웹 접근성 -> 차별 없이 누구나 다 웹을 이용할 수 있어야 한다.
모든 사용자가 신체적, 환경적 조건에 관계없이 웹에 접근하여 이용할 수 있도록 보장하는 것!
( 일반인, 장애자, 고령자 ) 어떤 브라우저, 어떤 운영체제에서도 어려움 없이 접근하고 이용할 수 있는 것이 웹 접근성,
웹 접근성의 예시 -> 시각장애인의 경우 화면을 눈으로 볼 수 없기 때문이 이 ' 스크린 리더 ' 라는 별도의 소프트웨어를
컴퓨터에 설치해서 음성으로 웹페이지를 이해한다.
그래서 이제 이미지같은 경우 그 이미지의 소스코드에 이미지에 대한 설명 내용을 담아주는 것이다.
<img src="img/login.png" alt="로그인"/>
web => 장애에 구애없이 모든 사람들이 손쉽게 정보를 공유할 수 있는 공간 ( feat. 팀 버너스 리 )
웹 콘텐츠 접근성 지침 ( WCAG ) = Web content Accesibillity Guidlines
1. 인지성 ( Perceivable ) -> 정보와 사용자 인터페이스 요소는 그들이 인지할 수 있도록 사용자에게 표시될 수 있어야 한다.
-> 쉽게 이해하면 모든 사람이 이 웹을 " 인지 " 할 수 있게끔 하는 수단을 모두 제공해야 한다라는 뜻.
ex) 대체 텍스트, 점자, 음성, 기호, 등등 . .
2. 운용성 ( Operable ) -> 사용자 인터페이스 요소와 탐색은 운용 가능해야 한다.
-> 키보드로 모든 기능을 사용할 수 있도록 해야 한다.
탭 키를 이용하여 마우스를 대체할 수 있게끔. 모든 웹페이지의 주요 요소들을 탭으로 이동 및 클릭이 가능할 수 있게끔.
+ 읽기 및 콘텐츠를 사용하는 사용자에게 충분한 시간을 제공해야 한다. -> 한번에 싹 사라지고 멋대로 굴러가는 웹페이지는 x.
+ 발작을 일으킬 수 있는 콘텐츠는 절대 x
+ 사용자가 탐색하고, 컨텐츠를 찾고, 그들이 스스로 현재 어디에 위치하고 있는지를 알 수 있도록 도와주는 방법 제공해야함!
3. 이해성 ( Understandable )
-> 정보와 사용자 인터페이스 운용은 이해할 수 있어야 한다.
텍스트 컨텐츠를 판독하고 이해할 수 있도록 만들어야 한다.
웹 페이지의 탑재와 운용을 예측 가능한 방법으로 제작해야 한다.
사용자의 실수를 방지하고 수정할 수 있도록 도와야 한다.
=> 이해 가능한, 상식적으로 납득이 가능한, 웹 페이지를 제작.
4. 내구성 ( Robust )
- 콘텐츠는 이제 보조 기술을 포함한 넓고 다양한 사용자 에이전트에 의존하여 해석될 수 있도록 충분히 내구성을 가져야 한다.
-- 구조에 대한 이야기이기도함. 툭 하면 툭하고 부러지는 웹페이지는 x.
웹 접근성을 위해 사용되는 보조기기 ? -> 자막, 스크린리더, 자동완성기능, 마우스스틱, 색상대비 디자인 등 등 ..
Validator -> 웹 문서가 표준안에 따라 만들어졌는지, 접근성에 대한 고려가 이루어졌는지에 대한 유효성을 검사해주는 도구 ( w3c )
DTD -> Document Type definition -> 브라우저에 어떤 문서형 정의를 적용할 것인가를 선언.
= DTD 같은 경우 이제 HTML 처음 맨 위에 선언을 해주는 Doctype에 이에 속한다.
현재는 HTML5를 사용하고 있기 때문에 Doctype 선언! HTML5!! 이런 식으로 선언을 해준다.
( 이걸 선언해주지 않으면 쿼크 모드로 진입을 하게된다. 선언을 하게 되면 일반 표준 모드로 진행이 된다. 둘은 분명 차이가 있다. )
- 브라우저는 선언된 독타입에 따라 렌더링할 모드를 선택하게 되는데 이 과정을 doctype sniffing 또는 doctype switching 이라고함.
그럼 쿼크 모드는 또 뭐임? -> 쿼크모드 ( Quirks mode )
오~래된 웹페이지들이 최신의 브라우저에서 깨져보이지 않게 하려고 쓰임. ( 이전 세대의 브라우저에 맞는 CSS 방법 적용 )
그럼 UI가 무엇인가?
-> UI는 이제 User Interface의 약자. 유저 인터페이스. 사용자 인터페이스를 뜻한다.
사용자 인터페이스가 그래서 뭔데?
-> 사용하는 환경. 이라고 해석하면 이해하기 편하다.
사용자가 제품이나 서비스를 마주할 때 보고 조작하는 모든 화면.
버거킹에 들어가서 키오스크를 보면 각종 UI들이 있다. 이를 UI 라고 하며,
그리고 이를 API라고도 할 수 있다.
API란 application programming Interface.
응용프로그램 프로그래밍 인터페이스.
* API와 라이브러리는 무슨 차이가 있을까? 서로 비슷하긴 하다.
* API가 왜 버거킹의 키오스크인가? 그렇다면 라이브러리는 뭐지?
* API가 사용되는 또 다른 예시는 무엇이 있는가?
* 그것이 왜 UI와 관련이 있는가?
* 그렇다면 프레임워크는 무엇이며 그것들과는 어떠한 차이가 있는가?
--
음, API와 라이브러리는 구현체냐 아니냐로 차이가 조금 나뉜다고 볼 수 있다.
API는 어느정도 추상적인 개념이 있지만 라이브러리는 이런 API들을 기반으로 개발자에게 기능을 제공할 수 있도록
실제로 구현된 구현체라고 볼 수 있다 ( 나무위키 참조 )
API는 일종의 약속된 시스템. 라이브러리는 실제로 이를 바탕으로 구현된 결과물.
더 정확한 이해를 위해 예시들을 검색해서 생각해보도록 하자. 둘이 정확히 무엇이며 어떠한 차이가 있는지.
API -> 프론트엔드와 백엔드와의 약속. ( 계약서 꽝! 처럼 정해진 것이 아니며 이는 프론트엔드 개발자와 백엔드 개발자가 서로 정한 것 )
( * 컴포넌트 -> 소프트웨어 개발을 마치 레고 블록을 쌓듯이 쉽게 할 수 있도록 하는 기술을 말한다. 기존의 코딩방식에 의한
개발에서 벗어나 소프트웨어 구성단위를 미리 만든 뒤 필요한 응용 기술을 개발할 때 이 모듈을 조립하는 기술을 말한다.
소프트웨어? 모듈? 하드웨어?
소프트웨어 -> 아이스크림
하드웨어 -> 그 아이스크림을 담는 콘과 컵.
아이폰 -> 하드웨어
IOS -> 소프트웨어
* 아니 그럼 왜 둘이 나눔?
-> 그게 바로 소프트웨어의 존재 이유이자 장점.
콘에 아이스크림 담았다가 마음에 안들면 다른 맛 아이스크림으로 언제든 교체가 가능하니까.
( ex IOS 업데이트, 게임 업데이트, 인공위성 업데이트 .. ) 모두 소프트웨어가 있기 때문에 가능한 것.
그리고 그 것을 담는 하드웨어가 존재.
모듈은 말 그대로 그냥 모듈. 모니터 받침대 모듈 모니터 본체 모듈.
API -> 일종의 매개체같은 역할이라고 보면 된다. 버거킹에 간다.
햄버거를 주문한다. 키오스크에 가서 내가 먹을 햄버거를 입력한다. 여기에서 API란 키오스크에 속한다.
키오스크가 나와 주방을 연결해주는 일종의 매개체역할을 하는 것이다. ( 이는 어느정도 추상적인 개념에 속한다. )
API는 사전적으로는 응용 프로그램을 작성할 때 꼭 필요한 매개체이다.
매개체가 왜 필요한걸까?
실무 개발에서 하나를 만들어서 완성하려면 그 크기가 너무 크다. 그래서 서로간의 협업을 통해 따로 따로 나누어서 작업을 하거나
이미 만들어진 컴포넌트를 결합해서 만드는데, 이 때 라이브러리도 그 중 하나라고 볼 수 있다.
그러한 컴포넌트를 결합하기 위한 매개체가 바로 API이다.
여기서 바로 차이점. -> 라이브러리는 이러한 컴포넌트 그 자체를 뜻하고, ( 라이브러리가 있으면 개발이 편하다는 말 )
API는 이 컴포넌트를 활용하는 규약. 이라고 보면 된다. ( 일종의 약속 )
ex ) 구글 클라우드에서 제공하는 Speech API.
-> 음성 데이터를 넣으면 그 데이터를 원하는 언어의 텍스트로 인식해서 돌려주는 방식.
기계 학습을 이용한 인공지능 기술로 해당 기능을 구현했다고 함. 내부적인 동작은 공개하지 않고 있다.
여튼, 요청 / 응답 포맷 역시 API이며, 개발자의 로컬 컴퓨터에 설치된 라이브러리를 통해 제공받는 방식이 아니다.
외부 원격에 있는 서버에서 부터 이러한 음성 인식 서비스를 제공받는 것이다.
이 경우는 라이브러리가 아니지만 API를 제공한다.
API -> 도구 주세요~
라이브러리 -> 도구 자체
프레임 워크 -> 프레임워크과 라이브러리가 조금 헷갈릴 수 있음. 직역하면 뼈대. 골조라는 뜻이고 SW분야 이외에도 많이 쓰인다고함.
다른 분야에서는 이걸 " 문제를 바라보는 툴 " 혹은 " 대상을 바라보는 시각과 관점 " 뭐 다양한 의미를 지니고 있다고 함.
공통되는 부분은 바로 이 " 툴 " 이라는 점이다.
무언가를 하기 위한 " 툴 " 에 해당 된다.
틀이 있어서 좋은 점은 이 틀에 맞추어서 행동을 하면 누구나 쉽게 따라하면서 해결해 나갈 수 있다.
단점으로는 그 틀에 맞지 않는 무언가는 해결할 수 없다는 점이 있다.
SW 프레임 워크도 마찬가지 -> 어떠한 문제를 해결하기 위한 소프트웨어적 툴에 해당한다.
ex ) 안드로이드 프레임 워크
얘는 안드로이드 시스템에서 구동이 가능한 안드로이드 앱을 만들 수 있는 API들을 제공한다.
API대로만 구현을 하면 앱 내부적으로는 어떠한 최적화나 연산을 하는지는 알 수 없지만,
원하는 대로 동작한다는 것만 알 수 있다.
안드로이드 프레임워크는 안드로이드 앱을 만들기 위한 정해진 툴이라고 볼 수 있다.
하지만 안드로이드 프레임 워크로는 웹 서버를 만들 수 없다. 왜냐하면 안드로이드 프레임워크는
안드로이드 앱을 만들기 위한 툴이므로 툴의 원래 목적과 다른 웹서버를 만들 순 없다.
라이브러리는 도구이고, 프레임워크는 일종의 도움을 주는 툴. 둘이 뭐가 다른걸까?
- 일반적으로 프레임워크 안에 라이브러리가 포함되는 경우가 많다고 한다.
SW 프레임워크는 보통 어떤 거-대한 응용프로그램 등을 만들기 위한 " 툴 " 인 경우가 많은데
이를 위해서 미리 코딩된 코드 조각들은 거의 당연히 들어가있다고 볼 수 있다.
이 " 미리 코딩된 코드조각 " 들은 라이브러리에 해당된다고 볼 수 있다.
-> 라이브러리만 가져다 쓰면 프로그램의 메인은 개발자가 쓰고 중간 중간 필요한 부분만 라이브러리로 가져와서
쓰는 형태인 반면에, 프레임워크를 가져다 쓰면 그 프레임 워크와 본디 다른 목적의 프로그램은 만들 수 없는 것이다.
( 이는 프레임워크의 매우 엄밀한 정의는 아니다. 그러나 적어도 이런 것이다 정도의 기본적인 개념 정도는 숙지해둘 필요가 있다 )
라이브러리 : 내가 만드는데 이걸 쓴다
프레임워크 : 용이 내가 된다
API : 일종의 약속이다. 도구를 주세요~ 요청하는 것.
UI : User interface
이제 웹에서 API를 사용하는 경우라면 이렇다.
다음이나 카카도 지도 API를 웹에 가져와서 표현하는 것이다.
그리고 그 위에 UI를 입히는 것이지. ( 버튼이라든가 아이콘이라든가 )
그게 바로 UI 이다.
어떻게 보면 API보단 UI 쪽이 키오스크에 가깝다.
버거킹 키오스크엔 햄버거를 주문할 수 있는 각종 버튼들이 존재한다.
그 버튼들이 바로 UI 디자인에 속한다고 볼 수 있다.
보니까 이게 UI는 뭐다 UX는 뭐다 API는 뭐다 이런 것들이 사실 크게 의미가 없는 것 같다.
UI는 버거킹 키오스크다. ( 유저가 사용하는 부분의 인터페이스 )
UX는 버거킹을 이용할 때 사람들이 줄 서서 기다리는 것을 방지하는 것이다. ( 사용자 경험 )
그리고 API는 일종의 도구 요청인 셈이다.
둘 다 키오스크인데, UI랑 API랑 그래서 무슨 차이가 있는가?
UI는 사람과 컴퓨터 사이에 존재한다고 볼 수 있다.
사용자를 대면하는 접점이 되는 지점을 포괄적으로 UI라고 부른다.
예를 들면 웹에서의 버튼, 스크롤바, 등 등.
API는 프로그램들이 서로 상호작용할 수 있게 도와주는 일종의 매개체이다. ( + 요청 )
---
float -> 뜨다, 라는 의미. 요소에 부유 속성을 줘서 배치할 수 있는 방법이다.
보통 left , right 를 사용하여 배치하고 아무래도 문서는 왼쪽에서 오른쪽으로 읽다보니 주로 left를 더 많이 쓰긴 한다.
그리고 이 float 를 사용하게 되면 주 배치가 와르르 무너지는 편이 잦은데 그 것을 해결할 수 있는 방법은
크게 2가지 정도가 있다. ( 원래 4가지가 있지만 주로 쓰는 것은 2가지 방법이다. )
1. 부모 요소에 overflow : hidden 을 넣는 방법.
2. 부모 요소에 가상요소 ( Pseudo elements ) 를 넣어 clear를 해주는 방법. ( 흔히들 클리어:픽스 라고도 부른다. )
가상요소를 넣고 ::after,
display:block, content:"", 그 다음 clear:both 를 해준다. ( clear 태그는 이전에 적용한 float를 클리어, 즉 해제하겠다는 뜻의 태그이다 )
-> 부모 요소에 오버플로우 : 히든을 조져서 float 구조 깨짐을 해결할 수도 있지만 완벽하진 않다. 해당 내용을 넘어서게 되면 뭔가 또 같이
안보이는 문제가 발생할 수도 있기 때문. 그래서 막상 쓰면 1번 보단 2번을 주로 많이 사용하게 된다.
* 아주 아주 아주 html 기본기. 블럭와 인라인블럭의 개념 ( 재상기 )
필기 테스트를 대비하여 다시한번 개념을 상기해보도록 하자.
html 블럭요소의 특징.
-> 우선 부모 요소의 100% 가로 크기를 가진다.
-> 직사각형의 모형을 가진다.
-> + 자동 줄바꿈!
줄바꿈이 뭔 뜻이냐 -> 다음 마크업을 하면 이제 옆으로 안 쌓이고 다음 다음 다음 이런 식으로 자동으로 줄바꿈 된다는 뜻이다.
블럭 ( block ) 들은 주로 줄바꿈이 들어가기 때문에 줄 전체를 차지하게 된다.
옆으로 나열이 안되고 층층이 쌓인다. 그렇기 때문에 width 값, height 값, 마진값, 패딩값 전부 들어간다.
+로 구성된 대상의 요소의 높이를 자동으로 가진다. ( 코딩하면서 따로 높이 안줘도 자동으로 들어가는 경우를 자주 보았을 것이다 )
주로 레이아웃 구성할 때 쓰인다. 그리고 이 블럭들은 블럭과 인라인을 품을 수 있다.
그냥 쉽게 생각하면 높이 값이랑 가로 값을 줄 수 있고 특별한 태그 말고는 거의 디폴트 값이며 줄바꿈이 들어가는.
그러니까 옆으로 가로 방향으로 쌓이는 방식이 아닌 층층이 쌓이는 그런 방식이 바로 block 이라고 보면 된다.
( 더 쉽게 생각하면 그냥 테트리스라고 생각하면 쉬울듯? 어차피 레이아웃 설계할 때 그런 식으로 하기도 하니까. )
그래서 그냥 블락은 뭐다? 응 테트리스다. 끝.
html 요소들은 주로 블락 태그와 인라인 태그가 있다.
블락은 층층이 테트리스고 인라인은 인라인 스케이트처럼 옆으로 슥 슥 나간다 -> -> 가로 방향으로 쌓이다는 말.
즉 내가 쓰는 이 글 처럼 말이다.
* 왜 줄바꿈이 일어나는거임? 왜 층층이 테트리스마냥 쌓이는 거임?
- 이유인 즉슨 이 블락 얘네들은 가로 사이즈를 화면 전체 전부 다 차지해버리거든.
글자는 치면 그 친 만큼만 공간을 차지하잖아 근데 블락인 애들은 뭐 하나 글자를 쓰면
가로 사이즈 전체를 다 차지해버리기 때문에 층층이 쌓이는 거임.