반응형

SSL 보안서버 인증서를 구매하여 사용하지 않고, Open SSL 인증서를 사용한 경우 git push시 SSL에러가 발생한다.


이를 해결하기 위해 CA에서 인증하는 절차를 무시하는 방법이 있다.

window 사용자는 cmd

mac 사용자는 terminal에서


1
git config --global http.sslVerify false
cs


명령어를 사용하여 global값을 설정한다.



반응형
반응형

프로세스와 스레드에 대해 알아보겠습니다. 간단히 정리하고 제가 공부한 것을 바탕으로 제 스스로 문제를 내서 답변을 달아보았는데 추가적인 내용이 있으니 도움되셨으면 좋겠습니다. 


프로세스

OS로부터 자원을 할당받는 작업의 단위. 즉, 컴퓨터에서 실행중인 프로그램을 의미(실행된 프로그램) 하나 이상의 스레드를 포함합니다. 구체적으로 살펴보면 프로세스는 함수의 매개변수, 복귀 주소와 로컬 변수와 같은 임시 자료를 갖는 프로세스 스택과 전역 변수들을 수록하는 데이터 섹션을 포함합니다. 또한 프로세스는 프로세스 실행 중에 동적으로 할당되는 메모리인 힙을 포함합니다.


스레드

프로세스가 할당받은 자원을 이용하는 실행의 단위.

기본적으로 하나의 프로세스가 생성되면 한개의 스레드가 생성되는데 이를 메인 스레드라고 합니다. 스레드를 추가로 생성되지 않는 한 모든 프로그램은 메인 스레드에서 실행됩니다. 추가로 생성되면 이를 멀티 스레드라 부릅니다. 조금 깊게 살펴보면 스레드는 스레드 ID, 프로그램 카운터, 레지스터 집합, 그리고 스택으로 구성됩니다. 같은 프로세스에 속한 다른 스레드와 코드, 데이터 섹션, 그리고 열린 파일이나 신호와 같은 운영체제 자원들을 공유합니다. 하나의 프로세스를 다수의 실행 단위로 구분하여 자원을 공유하고 자원의 생성과 관리의 중복성을 최소화하여 수행 능력을 향상시키는 것을 멀티스레딩이라고 하며 이 경우 각각의 스레드는 독립적인 작업을 수행해야 하기 때문에 각자의 스택과 PC 레지스터 값을 갖고 있습니다.


정리하면 프로세스는 운영체제로부터 자원을 할당받는 작업의 단위이며 스레드는 프로세스가 할당받은 자원을 이용하는 실행의 단위입니다.


이 정리를 조금 풀어서 설명해보겠습니다.

프로세스는 실행될  때 운영체제로부터 프로세서, 주소 공간, 메로리 등 자원을 할당받습니다. 스레드란 한 프로세스 내에서 동작되는 여러 실행의 흐름으로 프로세스 내의 주소 공간이나 자원들을 같은 프로세스 내에 스레드끼리 공유하면서 실행됩니다. 프로세스와 스레드에 대한 질문은 OS가 자원을 어떤 단위로 할당하고, 프로세스와 스레드는 이 자원을 어떻게 사용하는지 알고있느냐? 이 질문과 같습니다.

프로세스와 스레드의 차이점에 대한 질문의 요지를 곰곰히 생각해보면 다음과 같은 개념과 이해가 있는지에 대해 물은 것 입니다.


즉, 프로세스와 스레드의 차이점에 대한 질문의 요지를 파악해보자면 다음과 같은 개념에 대해 알고 있는지 물어보기 위한 것입니다.


1. 프로세스와 스레드의 차이를 알고 있나요? 어떤 차이점이 있을까요?

2. 운영체제와 어떤 밀접한 관계를 가지고 있고 운영체제가 할당한 자원을 어떻게 사용되는지에 대해서도     알고 있나요?

3. 멀티프로세스와 멀티스레드에 대해 알고 있나요?

4. 위 질문에 이어서 멀티스레드 환경에서 프로그래밍한 경험은 있나요?

5. 그에 대한 장 단점은 자세히 알고 있나요?

6. 멀티스레드 환경에서 동기화 문제를 경험했봤나요? 했다면 어떻게 해결했나요?

7. 프로세스와 쓰레드의 차이점에 대해 설명해주세요.


이 질문 하나로 위 질문들과 같이 다양한 질문이 연이어 나올 수 있기 때문에 프로세스와 쓰레드의 차이점에 대한 질문은 아주 기본적 이지만 핵심적이며 단골 질문입니다.


아래에는 질문과 답변입니다.


1. 프로세스와 쓰레드의 차이점

답변

 메모리 사용에 대한 차이가 존재

프로세스는 독립적으로 실행되며 각각 별개의 메모리를 차지하여 자원을 할당 받았다. 하지만 스레드는 프로세스 내의 자원을 공유해서 사용한다. 즉 스레드는 heap, data, code영역을 공유하고 별도의 stack만을 가지고 있다. 문맥교환시 stack영역만 교환하면 되므로 프로세스 문맥교환보다 빠르다.


2. 멀티 프로세스를 사용하지 않고 하나의 프로세스에서 스레드로 나눠가면서 사용하는 이유

답변

 OS가 시스템 자원을 효율적으로 관리하기 위해 스레드를 사용하는 것. 멀티 프로세스로 실행되는 작업을 멀티 스레드로 실행할 경우, 프로세스를 생성하여 자원을 할당하는 시스템 콜이 줄어들어 효율적으로 관리할 수 있습니다. 또한, 프로세스 간의 통신보다 스레드 간의 통신의 비용이 적으므로 부담이 줄어들게 되므로 스레드로 나눠가면서 사용합니다. 즉, 스레드는 프로세스 내에서 각각의 스택 공간을 제외한 나머지 공간과 자원을 공유합니다. 때문에 프로세스를 이용하여 동시에 처리하던 일을 스레드로 구현할 경우 메모리 공간은 물론 자원 소모도 줄어들게 됩니다. 


3. 스레드의 장점과 단점을 설명

답변

장점 : 시스템의 자원소모가 줄어든다. 프로그램 응답 시간이 단축된다. 프로세스 간 통신 방법에 비해 스레드 통신 방법이 훨씬 간단하다. 하지만 스레드는 통신시 전역 변수를 이용하는데 전역 변수를 여러 스레드가 함께 사용하면 충돌이 발생할 수 있기 때문에 충돌 문제가 발생하지 않도록 동기화 문제를 해결해야 한다.

단점 : 디버깅이 어려움. 단일 프로세서 시스템에서는 효과를 기대하기 어려움.


4. 스택을 스레드마다 독립적으로 할당하는 이유

답변

 스택은 함수 호출 시 전달되는 인자, 되돌아갈 주소값 및 함수 내에서 선언하는 변수 등을 저장하기 위해 사용되는 메모리 공간이므로 스택 메모리 공간이 독립적이라는 것은 독립적인 함수 호출이 가능하다는 것이고 이는 독립적인 실행 흐름이 추가되는 것이다. 따라서 스레드의 정의에 따라 독립적인 실행 흐름을 추가하기 위한 최소 조건으로 독립된 스택을 할당한다.


5. 멀티 스레드와 멀티 프로세스를 비교하여 설명하시오

답변

 멀티 스레드는 멀티 프로세스보다 적은 메모리 공간을 차지하고 문맥 전환이 빠르다는 장점이 있지만, 오류로 인해 하나의 스레드가 종료되면 전체 스레드가 종료될 수 있다는 점과 동기화 문제를 안고 있다. 반면 멀티 프로세스 방식은 하나의 프로세스가 죽더라도 다른 프로세스에는 영향을 끼치지 않고 정상적으로 수행된다는 장점이 있지만, 멀티 스레드보다 많은 메모리 공간과 CPU 시간을 차지한다는 단점이 존재한다. 이 두 가지는 동시에 여러 작업을 수행한다는 점에서 같지만 적용해야 하는 시스템에 따라 적합/부적합이 구분된다. 따라서 대상 시스템의 특징에 따라 적합한 동작 방식을 선택하고 적용해야 한다.



반응형
반응형

REST API란?


WEB API(HTTP API)와 REST API의 구분


먼저 API는 Application Programming Interface의 약자로 ... 다 필요없고 java.sun.com에 있는 API문서를 보면 쉽게 알 수 있습니다. 만약 java에서 우리가 절대값을 어떻게 구해야 하는지 알고 싶다면 java API문서중 Math클래스의 abs()메서드를 사용하면 된다는 것을 알 수 있듯이 프로그래밍을 할 때 필요한 인터페이스를 API라고 합니다.


REST API는 핵심 컨텐츠 및 기능을 외부에서 활용할 수 있도록 제공되는 인터페이스를 뜻합니다. 웹 브라우저 뿐 아니라  다양한 클라이언트가 생기면서 대응하기 위해 REST API가 널리 사용되기 시작되었습니다. 

이런 REST API는 6가지 특징을 반드시 지켜야 합니다.


1. client - server

2. stateless

3. cache

4. uniform interface

5. layered system

6. code-on-demanad(optional)


위와 같은 내용을 반드시 지켜야만 REST하다고 말할 수 있습니다. HTTP프로토콜을 사용하면 client-server, stateless, cache, lared system, code-on-demand와 같은 경우는 쉽게 구현가능합니다. 하지만 uniform interface와 같은 경우는 약간 어렵습니다.

uniform interface는 다음과 같은 특징을 가집니다.

1. 리소스가 URI로 식별되야 한다.

2. 리소스를 생성, 수정, 추가할때 HTTP메시지에 표현을 해서 전송해야 한다.

3. 메세지는 스스로 설명할 수 있어야 한다.

4. 어플리케이션의 상태는 Hyperlink를 이용해 전이되어야 한다.


1번과 2번같은 경우는 어려운 부분은 아니지만 3, 4번은 API로는 쉽지가 않습니다. 응답 결과에 보통 JSON을 사용하게 되는데, 이 JSON메세지가 어디에 전달되는지 그리고 JSON메세지를 구성하는 것이 어떤 의미를 표현해야만 메세지 스스로 설명할 수 있다고 말하는데, 말도 복잡하고 실제로도 어렵습니다.


4번과 같은 경우는 웹 페이지 자체에 링크가 있는 것을 말하는데 API에서 이러한 기능을 제공하는 것도 쉽지 않습니다.


이러한 uniform interface를 지원하는 것이 어렵기 때문에 많은 서비스가 REST에서 바라는 것을 모두 지원하지 않고 API를 만들게 됩니다. 즉, 일반적으로 REST의 특징을 모두 제공하지 않으면서 REST API로 불리는 것, REST의 특징 모두 제공하지 않으면서 Web API, HTTP API 두가지로 나누어 집니다. 

반응형
반응형

미들웨어


클라이언트 쪽에 비즈니스 로직이 많은 경우, 클라이언트 관리(배포..) 로 인해 비용이 많이 발생하는 문제가 있음

비즈니스 로직을 클라이언트와 DBMS사이의 미들웨어 서버에서 동작하도록 하여 클라이언트는 오직 입력과 출력만 담당하도록 함(3-tier)

즉 클라이언트와 DBMS 사이에 또 다른 서버를 두어 이 미들웨어 서버에서 대부분의 로직을 수행하며, 데이터를 조작할 일이 있으면 DBMS에게 부탁하는 방식이다. 때문에 클라이언트에는 복잡한 로직이 사라지고 단순히 화면에 결과만 보여주면 되기 때문에 크기가 작이지게 되며, 프로그램 로직이 변경된다 하더라도 모든 클라이언트에게 배포하지 않고 오직 미들웨어만 변경하면 되는 장점을 가지고 있다.


WAS


일종의 미들웨어로 웹 클라이언트(보통 웹 브라우저)의 요청 중 웹 애플리케이션이 동작하도록 지원하는 목적을 가지고 있다. 웹이 널리 사용되면서 웹에서 데이터를 입력하고 조회하는 등의 동적인 기능이 요구되었고 이러한 동적인 기능은 프로그래밍을 통해서 가능했습니다. 보통 이러한 기능들은 DBMS와 연관된 경우가 빈번했고, 브라우저를 클라이언트로 생각한다면 브라우저와 DBMS 사이에서 동작하는 미들웨어가 필요하게 된것입니다. 이러한 미들웨어를 WAS라고 합니다. 즉, WAS도 넓게 보면 미들웨어에 포함된다고 할 수 있습니다. WAS는 중요한 3가지 기능을 제공하는데 먼저 첫번째는 프로그램 실행 환경과 데이터베이스 접속 기능을 제공합니다. 두번째는 여러개의 트랜잭션을 관리하고 마지막으로 업무를 처리하는 비즈니스 로직을 처리합니다.

여기서 트랜잭션은 논리적인 작업단위라 생각하시면 되며, 자세한 내용은 데이터베이스 관련 포스팅을 참고하세요. 또한 WAS는 웹서버의 기능도 기본적으로 제공하는데, 웹 프로그래밍을 진행하면 톰캣이라는 WAS를 설치하면 웹서버로 이용할 수 있는 이유는 WAS인 톰캣이 웹 서버의 역할을 충분히 해주기 때문입니다. 



여기서 WAS와 웹 서버의 차이점은 간단하게 웹 서버는 정적인 컨텐츠를 처리하며 WAS는 동적인 컨텐츠를 처리한다고 정리하시면 되겠습니다. 



반응형
반응형

Web에 관련된 자료를 보게 되거나 혹은 API를 보게 되었을 때 가장 많이 보이는 단어가 REST란 단어였다. 하지만 REST란 단어만 알고만 있을 뿐 자세한 의미는 무엇인가.... 사실 알지 못했다. 그래서 이번 기회에 RESTful API에 대해 정리를 시작해보려고 한다.

요약하자면 GET, POST, PUT, DELETE 이 4가지로 요약할 수도 있겠다.


REST는 Representational State Transfer 약자로 웹의 장점을 최대한 활용활 수 있는 아키텍처라고한다...

조금 더 상세히 설명해보면 HTTP URI를 통해 resource를 명시하고! HTTP Method(GET, POST, PUT, DELETE)를 통해 해당 resource에 대한 CRUD operation을 적용하는 것이다. 즉 REST는 HTTP Method를 통해 resource를 처리하도록 설계된 아키텍처를 뜻한다.

즉, RESTful 이란 HTTP와 URI 기반으로 자원에 접근할 수 있도록 제공하는 어플리케이션 개발 인터페이스라고 할 수 있다.


아래 표는 HTTP 메서드와 CRUD operation에 대한 매핑관계이다.


 METHOD

CRUD 

POST 

Create 

GET

Read 

PUT

Update 

DELETE 

Delete 


그럼 간단한 게시판을 구현한다고 생각하고 RESTful 웹서비스 URI와 메서드들을 정의해 보자. 그 전에 기존 웹서비스를 생각하면 로컬기준

localhost:8080/users.jsp?id=1234로 제공되었다. 하지만 RESTful하게 설계한다면 다음과 같이 정의된다. (localhost:8080/users/1234)


Action 

Resource URI 

HTTP Method 

 사용자 목록

/users 

GET 

 사용자 보기

/users/{id} 

GET 

 사용자 등록

/users 

POST 

 사용자 수정

/users/{id} 

PUT 

 사용자 삭제

/users/{id} 

DELETE 


RESTful에서 4개의 HTTP Method만을 사용하는 이유는 가장 추상적인? 동사이기 때문입니다. 예를 들어 우리는 라면을 먹을수는 있고 모니터를 먹을수는 없겠죠. 하지만 라면을 GET할수도 모니터를 GET할수는 있습니다. 이러한 예시처럼 특정한 동사들은 한정적인 경우에 사용할 수 있기 때문입니다. 사실 이 4가지로는 세상을 표현하는게 어려울 수도 있겠지만 앞서 말했듯이 가장 추상적이라고 말씀드렸습니다. 추상화를 잘 한다면 RESTful한 설계를 완성하는 것은 무리가 아닐 것입니다!


사실 깊게 들어가면 RESTful하기 위해서는 ROA속성과 연관되기 때문에 ROA에 대해 잘 이해한 후 디자인해야 한다.

하지만 RESTful한 것은 HTTP 메소드와 응답코드가 모호하기 때문에 그 뜻이 정확히 뭘 의미하는지 사람마다 다르게 인식하기 때문에 (물론 따지고보면 그걸 모르는 사람의 문제라고 생각한다) 탄생?된것처럼 정답은 없다고 생각한다.(개인적 생각)

RESTful은 모든 것을 만족해야 하는게 아니라 그 중 쓰고 싶은 개념을 가져다 쓰면 된다고 생각한다. 어쨋든 REST에 대해 간략히 정리해 보았지만 부족한 내용이라는 것은 인정하고 넘어가야겠다.(추가적으로 학습 후 수정하겠습니다 ㅠ)

반응형
반응형

객체 지향의 4대 특성

캡 - 캡슐화 : 정보 은닉

상 - 상속 : 재사용 

추 - 추상화 : 모델링

다 - 다형성 : 사용 편의

객체 지향에서 Inheritance 즉 상속은 가장 중요하고 강력한 특성임은 분명하다.

지금까지 객체지향을 한번쯤이라도 공부한 사람이라면 클래스와 객체의 관계를 붕어빵틀과 붕어빵 이라는 비유를 많이 봤을 것이다. 하지만 이 비유가 적절한 지 생각해보자(이러한 개념을 일단 버려라!)


클래스 객체명 = new 클래스();

일반적 객체를 생성하는 문법이다 이 문법을 붕어빵틀과 붕어빵에 적용시켜 보자

붕어빵틀 붕어빵 = new 붕어빵틀();

!!!! 위 논리가 맞다고 생각되는가? 붕어빵틀을 생산하는 기계가 있다고 하자. 그럼 붕어빵틀이 붕어빵을 찍어내서 클래스라고 한다면! 같은 논리로 기계는 붕어빵틀을 찍어내는 클래스가 된다.

기계 붕어빵틀 = new 기계(); => 새로운 기계를 만들었는데 붕어빵틀이 되었다.


붕어빵틀은 붕어빵을 만드는 팩토리일 뿐이였던 것이다. 


클래스는 분류에 대한 개념이지 실체가 아니다. 하지만 객체는 실체다.


추상화 : 모델링

공통되는 특성이나 속성 따위를 추출하여 파악하는 것! 즉 추상화란 구체적인 것을 분해해서 관찰자가 관심있는 특성만 가지고 재조합하는 것이며 이는 곧 모델링이라고 할 수 있다.


객체 - 세상에 존재하는 유일무이한 사물

클래스 - 분류, 집합, 같은 속성과 기능을 가진 객체를 총칭하는 개념


세상에 존재하는 유일무이한 객체를 특성(속성 + 기능) 에 따라 분류해 보니 객체를 통칭할 수 있는 집합적 개념, 즉 클래스가 나오게 된다. 따라서 클래스는 같은 특성을 지닌 여러 객체를 총칭하는 집합의 개념이다.


애플리케이션 경계 - Context

내가 만들고자 하는 애플리케이션은 어디에서 사용될 것인가?에 대한 답이 바로 Context다.

즉 Context에 따라 클래스의 설계가 달라질 수 있다는 것이다. 


여기까지 다시 개념정리를 했다면 추상화를 다시 정의해 보도록 하겠다.

추상화란 구체적인 것을 분해해서 관심 영영(Context) 있는 특성만 가지고 재조합하는 것이다. == 모델링


이러한 모델링은 실제 사물을 정확히 복제하는 것이 아니라 목적에 맞게 관심있는 특성만을 추출해서 표현하는 것이다. 클래스를 설계하거나 데이터베이스 테이블을 설계할 때 필요한 기법이기도 하다.


자바에서는 이러한 추상화를 class 키워드를 통해 지원하고 있다. 

추상화 = 모델링 = class키워드


반응형

+ Recent posts