nota's story

완전 기초적인건데, 안 써버릇 하니깐 가끔 까먹기도 하는 MySQL 기본 명령문

1. SELECT

SELECT [컬럼명] FROM [테이블명] WHERE [조건]

ex) SELECT * FROM tbl_userinfo WEHRE height > 180 ;

ex) SELECT username FROM tbl_userinfo WHERE height < 180 ;

2. UPDATE

UPDATE [테이블] SET [컬럼]=[값] WHERE [조건]

ex) UPDATE tbl_userinfo SET height = 180 WHERE height > 179.5 ;

3. DELETE

DELETE FROM [테이블] WHERE [조건]

ex) DELETE FROM tbl_userinfo WHERE height < 100 ;

4일차는 코딩 위주로 수업해서 생략

#
URL에 따라서 다른 서블릿을 호출하게 되면 서블릿을 여러개 만들어야 하니까,
DisPpatcher Servlet 하나만 사용하고
URL 자체를 명령어로 인식해서, cmd라는파라미터에 따라 액션을 다르게 한다.
어떤 URL이 어떤 명령어인지는 Handler Mapping이 알아서 해주고,
여기서 어떤 명령어인지를 판단하여 Controller를 부른다.
Controller에서는 직접 코딩하여 모델을 만드는게 아니고,
Controller에서는 의지하는 객체를 가지고 있는거...
의지하고 있는 객체는 모델이 되겠지?
이 모델은 또 구현클래스로 두지 말고,
인터페이스를 만들어 추상화하여 loose coupling을 한다.
=> 결합도가 낮아져서 다형성을 가진다.
이때 단순히 인터페이스만 가지고 있는다고 결합도가 낮아지는건 아니고,
팩토리 패턴을 생성하여 어떤 케이스에 따라 어떤 구현 클래스를 사용할지를 결정.

#
SPRING에서는 forward가 디폴트
forward는 url은 그대로 두고, 버퍼의 내용만 변경
다른 컨트롤러 쪽을 호출하기 위해서는 url이 변경돼야 하기 때문에 redirect를 사용
다시 정리해보자면,
action에서 바로 뷰를 보여줄 때는 forward로 가면 되는데
action에서 다른 action으로 가려면 redirect로 가야한다.

#
ORM, AOP, DI 등의 개념은 확실히 알아둡시다.

#
AOP(Aspect Oriented Programming)
관점 지향 프로그래밍. Aspect가 키워드!!!
OOP를 날려버리자 하고 나온게 AOP가 아님
(AOP가 도입된다고 OOP가 사라지는게 아님)

OOP의 장점은 재사용성(중복코드가 줄어듬)
OOP의 단점은 필요없는거까지 상속받는다.
OOP에서는 재사용하기 위해서는 주종관계로 묶여져야 한다는 단점이 있음.

AOP에서는 바라보는 관점에 따라서 핵심코드와 공통소스가 캡슐화되게 해서,
주종관계를 맺지 않고 재사용이 가능.
이때 관점이라는걸 정의하기 위해서 아키텍쳐가 필요.
핵심과 공통을 분리하기 위함이 AOP의 목적.
분리를 하게 되면 뭐가 뭔지 모르기 때문에 이 핵심코드와 공통소스 캡슐화 등을 알아서 해주는걸 각종 프레임웍에서 문법에 의해 해준다.

운전을 예로 들면, 운전을 하기 위해 차를 빼고 다시 주차하는게 공통소스
운전을 해서 여행을 가든 출퇴근을 하든 하는게 핵심코드
운전자가 원하는건 운전을 하는거지, 차를 빼고 주차하는게 아니다.
이 차를 빼고 주차하는걸 공통소스로 관리.

밥먹는걸 예로 들면, 밥을 먹기 위해 상을 차리고 다먹고나서 설거지를 하는게 공통소스
밥을 어떻게 잘 먹는게 핵심코드
식충이가 원하는건 밥을 먹는거지, 상을 차리고 설거지를 하는게 아니다.
이 상을 차리고 설거지를 하는걸 공통소스로 관리

*advice : what과 when이 결합된 것
공통관심 사항을 핵심로직에 언제 적용할 것인가를 정의

*joinpoint : where의 의미
공통관심사항을 적용할 수 있는 애플리케이션의 실행지점
advice를 적용하는 지점

*pointcut : advice가 실제로 적용되는 jointpoint

#
오늘 MVC Spring, DB적용
다음시간에 DI적용하여 어플만듬
그다음시간에 AOP 등 마무리

#
ORM은 Object Relation Mapping : 즉, 다른 프레임워크와 연동하는 것.

#
Spring MVC
Model : 모델 자체가 컴퍼넌트, 컴퍼넌트 자체가 자바로 코딩한 비즈니스 로직.
View
Controller
모델과 뷰를 구분하고자 하는 형식이 MVC
여기서 모델이 주코드와 부코드로 나뉘게 됨.

#
<Spring MVC의 큰 흐름>

1.
Client에서 Dispatcher Servlet으로 가는건, web.xml에서 설정
(.do일때 이 서블릿으로 가라는걸 설정.)
서블릿은 요청을 처리해주고, 전체 관리하는 역할을 함.
Dispatcher 서블릿은 Spring에서 제시하는 서블릿.

2.
이때 .do로 통일하면 하나의 서블릿이기 때문에, 어떤 서비스를 해야할지 단서를 붙여서 호출해야 하는데
이걸 해주는게 Handler Mapping(기존 MVC에서는 'list.do?cmd=login' 이런식으로 처리했음)

3.
Dispatcher 서블릿에서 이 호출이 어떤 요청인지 Handler Mapping을 통해서 판단
(커맨드와 비즈니스 로직을 맵핑)

4.
 Controller는 기존MVC의 Action과 같은 역할.
컨트롤러에서 비즈니스 로직 등을 구현.
DI를 적용시켜서 로직, DB 등과 관련된걸 불러오고 처리.

5.
ActionForward를 통해서 ModelAndView를 설정하여 Dispatcher Servlet으로 넘김

6.
Dispatcher Servlet에서 ViewResolver를 불러서 어떤 뷰를 불러올지 결정

#
211.63.89.30

#
샘플로 만든 MVC프로젝트에서,
jsp에서 .do?cmd=login url 이동
=> web.xml에서 읽고 Action Servlet으로 가서 service 메서드 호출
=> ActionServlet에서 cmd를 받아서, getAction 호출
=> Action Factory의 getAction에서 cmd 값에 따라서 어떤 모델을 부를건지 결정
=> 이 받은 action을 가지고 action.execute 실행
=> execute를 ActionForWard가 받아서, true면 sendRedirect// false면 requestDispatcher 호출

#
객체를 속성과 기능과 함께 인스턴스화 할 때(OOP) 한계가 있다
그래서 객체를 만들어서 서로 협업(조립)시킨다 => Framework

설계도(클래스, 객체)를 만드는 이유 : 재사용성을 위함

Spring에서의 협업 : Extend가 아니라, POJO(평범한 자바)로 가지고 있는(haser) 개념으로 가고, 이를 이용해 협업한다. 이때 코드를 분리하고 조립(factory)하게 된다.

메인부에서 객체를 선언하고, 어떤걸 만들지 조립하고, 호출하는게 일반적인 개발의 흐름
근데 이렇게 하면 개발자가 공식대로 다 만들고, 일정한 패턴으로 코딩해야함
프레임워크에서는 IOC 컨테이너를 서비스해서, 얘네 문법만 익히면 기본적인 패턴이나 문법이 적용된 상태로 코드를 분리할 수 있고 조립할 수 있다

Spring 모듈중에 Core가 있고, 그 안에 DI가 있음. 이는 협업하는 객체를 wiring해줌. => 코드의 분리 + 확장성 향상

문법에서 set은 집어넣고, get은 반환하는 건데..
@Required를 하면 반드시 DI를 하도록 한다.
@Autowired를 하면 자동으로 묶어준다.(DI해준다)

xml을 보면 bean으로 객체를 만들고, property를 만듬.
예시에서 person이 book을 가지고 있다.
book이 1개뿐이면 person과 book이 같은 타입이니까 잘 가져오게 되는데(book을 person에 DI시키는데),
book이 2개라면 타입이 겹치니까 이름으로 가져올 수밖에 없음. => annotation으로 해결 가능

setBook에 @Requried만 쓰면 에러가 남(DI를 안 해놨으니까)
거기에 @Autowired를 추가하면 에러가 사라짐(하나하나 bytype으로 DI가 되니까)
참고로, 바로 bean에 접근하는 resource 개념이 있음
그리고 bean에 안 만들어줘도 다른 annotaion을 이용해서 가능하도록 할 수 있다.

내가 primitive 자료형(기본자료형) 혹은 레퍼런스 자료형(오픈 api)를 가지고 있을 수 있는데,
이를 DI시켜서 루즈 커플링해서 사용하는게 spring framework의 핵심

spring에서는, xml뿐만 아니라 java 소스만으로 DI를 시켜줄 수 있도록 제공한다(@bean).
기존의 방식인 xml로 DI시키는 것도 있고, java 소스로 DI시키는 것도 있고 함께 사용할 수 있음.

#
@Qualifier를 사용하면 값을 넣을 수 있음
setBook 메서드 위에다가 쓰면 객체가 하나라면 괜찮은데 여러개일 경우 여러개에 모두 한 value만 들어가게 되니까, 파라미터에다가 하나씩 붙여주면 값을 넣을 순 있음.

# MVC
- 웹은 전부 MVC로 되어있음(Spring, 전자정보 등등)
- 모델과 뷰를 분리함

# Spring MVC
- Client가 Dispatcher Servlet을 호출(요청을 위해)
=> 이때 Spring에서는 url 전체를 command로 본다.
- 서블릿이 호출되면 Handler Mapping이 불러와짐(키, 밸류 형태로 어떤 액션을 할지 맵핑)
- 핸들러맵핑이 확인해서 관련된 컨트롤러를 불러옴
- 컨트롤러가 ModelAndView를 디스패쳐 서블릿에 넘겨줌
- 확인해서 ViewResolver를 불렀다가 View를 볼러옴

#
http://www.springsource.org/download/community
위 링크 통해서
spring-tool-suite-3.1.0.RELEASE-e3.8-win32-installer
spring-framework-3.0.1.RELEASE-A-with-docs
spring-framework-3.0.1.RELEASE-A-dependencies
다운로드

#
framework : 작업환경
spring : 봄 =. 따뜻한 환경에서 공부하라고 로드존스가 만듬
spring framework : 오픈API, 경량의 컨테이터

#
IOC 패턴 : 제어 역행. 프로그램의 흐름이 역으로 변하는 것.
일반적인 흐름 필요한 객체를 생성 -> 조립을 함 -> 호출함
제어역행은 객체를 만들고 조립하는 과정을 위임하는 것(spring framework한테 위임)
http://vandbt.tistory.com/43

#
팩토리 : 객체를 어떻게 생성할 것인가, 어떻게 조립할 것인가, 생성한 객체를 어떻게 돌려줄 것인가를 고민하는 방법

#
POJO(Plain Old Java Object)
: 옛날 자바. Extend Object가 생략되어있고, Action으로부터 상속을 받음.
단일상속을 사용하면 inner class를 사용해야하고 확장성이 적고 등등 여러가지 문제
이저가 아니라 해저로 하자(가지고 있자).
만약에 그 레퍼런스가 없으면 내가 다 만들어야 하잖아
객체가 들어와야 하는데 구현객체가 들어오면 안되니까, 패턴에 의해서 framework로부터 그걸 받는다
포조가 나왔기 때문에 spring이 더 발전하지 않았나...

#
Spring framework 모듈 구조
OOP 기반이고, AOP가 OOP를 도와주는 개념으로 들어옴. AOP는 원래 있던 이론인데, 이를 spring에서 도입해서 개발자에게 서비스 하는 것임
Core에는 IOC 개념이 들어감
ORM에는 객체를 연결해서 매핑. 다른 프레임웤과 연동할 때 사용
DAO는 JDBC 사용을 지원하기 위함.
스프링 MVC 를 알기 위해서는 일반 MVC가 뭔지 알아야 이해가 됨

#
팩토리 패턴

#
스트레이지 패턴

#
커맨드 패턴

#
DI모듈

#
spring-tool-suite-3.1.0.RELEASE-e3.8-win32-installer 설치
STS.exe 실행하여 뉴프로젝트 - 스프링프로젝트 생성함
뉴 패키지, 뉴 클래스 생성
java 파일 안에 private 2개 만든다음에
ctrl + space + o 로 객체 생성
java파일 우클릭 - new - spring configuration.. .눌러서 xml 파일 생성

* bean : IOC 기반의 factory.
bean에 id, name있음. id가 좀 더 제약이 없기 때문에 id를 보통 씀
bean에 class경로 잡아줌 => 실질적으로 일할 땐 어노테이션을 많이 씀(class 일일이 잡아줄 필요 없음)
scope에 있는 prototype : 매번 계속해서 객체가 생성됨, singleton : 한번만 생성됨(static개념). 디폴트는 싱글톤.
property로 넣으려면 getter, setter가 생성되어있어야 함
alt + shift + s => r 누르면 getter .setter 생성
alt + shift + s => s 누르면 toString생성됨

*spring container = ioc container

*bean들만 팩토리하는게 beanFactory

#
플럭시 패턴

#
Dpendency Injection(DI : 의존성 주입)
A클래스와 B클래스가 있을 때 B를 A로 DI하게 되면, B의 소스를 고칠 때 A에 있는 수많은 사용부분을 고쳐야 하게 된다.(결합도가 너무 높다)

#
bean 아래의 constructor 생성 관련 교육

리눅스에서 CPU 정보 및 CPU 코어개수, 물리 CPU 수를 쉽게 확인하는 방법이다.

결론적으로 /proc/cpuinfo 에 모든 정보가 나와있지만, 개수를 확인하고 싶은데 일일이 찾아보기 귀찮을 땐 1~3번 참고.

0. CPU 정보 확인

> cat /proc/cpuinfo

1. CPU 코어 전체 개수 확인

> grep -c processor /proc/cpuinfo

2. 물리 CPU 수 확인

> grep "physical id" /proc/cpuinfo | sort -u | wc -l

3. CPU당 물리 코어 수 확인

> grep "cpu cores" /proc/cpuinfo | tail -1

리눅스를 사용하다 보면, 서버와 관련된 보고서 작성 혹은 검색 등등을 위해 버전을 알아봐야 할 때가 종종 있다.

맨날 까먹어서 간단히 정리!

콘솔에서 아래와 같이 입력하면 현재 사용 중인 OS 버전을 확인할 수 있다.

> uname -a

혹은 아래와 같이 입력해도 확인할 수 있다.

> cat /etc/issue

위 2개 결과가 약간 다른걸 볼 수 있는데, 전자는 Linux 자체의 버전이 나오고, 후자는 CentOS인지 Red Hat인지 등이 나온다.

콘솔에서 아래와 같이 입력하면 현재 사용 중인 Apache의 버전을 확인할 수 있다.

> cd [아파치 경로]

> cd bin

> ./httpd -v

즉, 아파치 경로의 bin 폴더로 들어가서 httpd -v를 실행시키면 된다.

콘솔에서 아래와 같이 입력하면 현재 사용 중인 Tomcat 버전을 확인할 수 있다.

> cd [톰캣 경로]

> cd bin

> ./catalina.sh version

즉, 톰캣 경로의 bin 폴더로 들어가서 catalina.sh version 을 실행시키면 된다.

콘솔에서 아래와 같이 입력하면 현재 사용 중인 MySQL 버전을 확인할 수 있다.

> cd [MySQL 경로]

> cd bin

> ./mysql -V

즉, MySQL 경로의 bin 폴더로 들어가서 mysql -V 를 실행시키면 된다.

일반적으로 MySQL 은 그냥 콘솔에서 mysql 만 입력해도 바로 실행되도록 등록하는데, 그 경우 그냥 mysql -V만 입력해도 된다.

콘솔에서 아래와 같이 입력하면 현재 사용 중인 JAVA 버전을 확인할 수 있다.

> java -version

혹시 java 명령어가 등록이 되지 않은 경우에는 JAVA 설치 경로의 bin 폴더로 찾아가서 java -version 을 실행하면 된다.

정상적으로 jAVA가 설치된 경우 아래와 같이 입력하면 JAVA 결치 경로가 나온다.

>which java

서버에는 전혀 부하도 없고 별다른 문제가 발견되지 않았는데, 웹 접속이 유난히 느리다면

접속을 시도하는 PC에서 해당 서버까지 도달하는 네트워크 회선 중 문제가 있지 않을까 의심을 해볼 수 있다.

(쉽게 말해서, 인터넷이 느릴 때 네트워크 상태를 의심하는 경우)

이때 단순히 내부 네트워크망이 문제일 수도 있지만, 중간에 여러 경로를 거치는 과정에서 문제가 있을 수도 있는데,

어떤 경로에서 문제가 있는지를 체크할 수 있는 명령어가 바로 tracert이다.

tracert는 trace route의 줄인 말로, 영어 뜻 그대로 'route를 추적한다'는 의미를 가지고 있다.

위키피디아(http://ko.wikipedia.org/wiki/Traceroute)에 나온 정의는 아래와 같다.

traceroute 혹은 tracert는 인터넷을 통해 거친 경로를 표시하고 그 구간의 정보를 기록하고 인터넷 프로토콜 네트워크를 통해 패킷의 전송 지연을 측정하기 위한 컴퓨터 네트워크 진단 유틸리티이다.

그렇다면 라우터는 무엇인가? 라우터 역시 위키피디아(http://ko.wikipedia.org/wiki/%EB%9D%BC%EC%9A%B0%ED%84%B0)에서 정의를 찾아보면 아래와 같다.

라우터(router, 문화어: 경로기)는 패킷의 위치를 추출하여 그 위치에 대한 최상의 경로를 지정하며 이 경로를 따라 데이터 패킷을 다음 장치로 전향시키는 장치이다.

같은 말이지만 좀 더 쉽게 표현하자면, 라우터는 데이터 패킷이 목적지까지 갈 수 있는 길을 검사하고, 어떤 길로 가는 것이 가장 적절한 것인지를 결정한 뒤 그 길로 데이터 패킷을 스위칭해주는 장비이다.

총정리 하자면, 네트워크를 통해 클라이언트에서 서버로 접속하기 위해서는 라우터라는 장비를 꼭 거치게 되는데, tracert 명령어는 이 과정에 있어서 어떤 라우터까지 데이터가 도달하였는지, 그리고 그 구간별 속도를 알려주는 명령어이다.

tracert 명령어 사용법은 아주 간단하다. 콘솔 창에서(윈도우라면 시작-실행-cmd를 실행하면 콘솔 창을 열 수 있다) 아래와 같은 명령어를 입력하면 된다.

tracert [IP주소 혹은 도메인주소]

예를 들어 nota.tistory.com를 접속할 때 거치는 네트워크 경로와 각 구간별 속도를 확인하고 싶다면 아래와 같이 입력하면 된다.

>> tracert nota.tistory.com

그러면 각 라우터의 IP나 이름이 나오고, 구간별 속도가 나온다.

(보안 상 막혀있는 경우는 '*'로 나오게 된다.)

tracert 명령어에 줄 수 있는 옵션들은 아래 표와 같다.

(콘솔 창에서 tracert -/? 라고 입력하면 나온다.) 

MySQL에서 백업, 복사, 복구 등에 자주 쓰이는 mysqldump에 대해 알게되어, 이것저것 찾아보다가 공부할 겸 메모.

윈도우 서버에서는 어떻게 하는지, sql스크립트로 가능한건지 등등은 아직 잘 모르겠음.

나의 경우 리눅스 서버에서 mysql 설치폴더의 bin 안에서 ./mysqldump 를 사용해 옵션을 주어 사용했다.

http://dev.mysql.com/doc/refman/5.1/en/mysqldump.html

이 글에서 설명할 것은 mysqldump로 스키마만 백업받는 방법이다.

데이터 자체도 mysqldump로 백업받을 수 있다고 하는데

위 링크에 들어가면 MySQL에 대한 매뉴얼이 아주 자세히(영문) 있으니 참고.

mysqldump -u [아이디] -p [패스워드] -d [DB명] > [파일명:ex. dbbackup.sql]

위와 같이 실행하면 된다.

예를 들어 계정이 root에 패스워드가 없고, shop이라는 DB의 모든 테이블을 shop_1205.sql 이라는 파일로 백업 받으려면

./mysqldump -u root -p -d shop > shop_1205.sql

이런 식으로 실행하면 된다.

mysqldump -u [아이디] -p [패스워드] -d [DB명] [테이블명] > [파일명]

3번에서 설명한 방법에서, 백업받으려고 하는 테이블명만 추가해주면 된다.

아직도 나에게 멀기만 한 리눅스..ㅠ

아직 아는 명령어는 몇 개 없지만, 다시 공부도 해볼 겸 기본적인 리눅스 명령어들을 정리해본다.

(혹시 틀린 내용이나 추가해야할 내용이 있으면 댓글 부탁해요)

cd [경로]

- 해당 경로로 이동한다.

- "."은 현재 경로를, ".."은 상위 경로를 의미한다.

- 상대경로 혹은 절대경로를 이용해 이동 가능하다.

- ex) cd /          : 루트 경로로 이동.

        cd conf      : 현 위치의 conf 폴더로 이동

        cd ..          : 상위 경로로 이동.

        cd ../conf  : 상위 경로의 conf 폴더로 이동

        cd /apache/conf : 루트 경로의 apache폴더 내의 conf 폴더로 이동

pwd

- 현 위치를 나타낸다.

mkdir [폴더명]

** 이건 경로 이동은 아니지만 어디에 넣어야 할지 애매해서 여기다 그냥 씁니다 ㅎㅎ

- 현 경로에 폴더를 생성한다.

- ex) mkdir example : 현재 경로에 example이라는 이름의 폴더를 생성

        mkdir /apache/conf/example : /apache/conf/ 경로에 example이라는 이름의 폴더를 생성

ls

- 현재 경로의 파일 및 하위폴더 목록을 보여준다.

- ex) ls        : 그냥 현재 경로의 파일 및 하위폴더 목록을 보여줌

        ls -l     : 현재 경로의 파일 및 하위폴더 목록을 자세히 보여줌

        ls -al   : 현재 경로의 파일 및 하위폴더 목록(숨김 파일 포함)을 자세히 보여줌

        ls -altr : 현재 경로의 파일 및 하위폴더 목록(숨김 파일 포함)을 파일 변경 시간 내림차순으로 보여줌(오래된 순으로)

** 개인적으론 보통 ls나 ls -altr을 많이 사용합니다.

cp [소스] [목적지]

- 소스에 있는 파일을 목적지로 복사한다.

** 심볼릭 링크 : 윈도우의 바로가기와 같은 역할을 한다. 심볼릭 링크가 걸어진 파일을 수정시, 원본 파일은 수정되지 않는다.

    하드 링크    : 심볼릭 링크과 형태는 같은데, 하드링크에서 파일을 수정하면 원본파일도 함께 수정된다.

- ex) cp test1 test2                      : 현 위치의 test1이라는 파일을 현위치에 test2라는 이름으로 복사한다.

        cp test1 /apache/conf/test2 : 현 위치의 test1이라는 파일을 /apache/conf/에 test2라는 이름으로 복사한다.

        cp -rp test1 /apache/conf/ : 현 위치의 test1이라는 폴더와 폴더 내의 모든 파일을 /apache/conf/에

                                                 test2라는 이름으로 복사한다(소유, 그룹, 권한, 허용 시간 등을 보존한 채로)

** 실제 서비스에 사용되는 폴더, 파일의 경우 소유권이나 권한이 바뀌게 되면 정상적으로 작동하지 않을 수 있으므로, 중요한 설정 파일 등을 복사할 때는 -p 옵션을 사용하는 것이 좋다.

mv [소스] [목적지]

- 소스에 있는 파일을 목적지로 이동한다.

- ex) mv test1 ../                                : 현 위치의 test1이라는 파일을 상위 경로로 이동한다.

        mv test1 /apache/conf/              : 현 위치의 test1이라는 파일을 /apache/conf/로 이동한다.

        mv /apache/test1 /apache/conf/ : /apache/의 test1이라는 파일을 /apache/conf/로 이동한다.

** 경로는 적어주지 않고 파일명만을 입력하여(mv test1 test2 와 같은 식으로), 파일명 수정처럼 사용할 수도 있다.

rm [파일명]

- 파일을 삭제한다.

- ex) rm test1     : 현 위치의 test1이라는 파일을 삭제한다.

        rm -rf test1 : 현 위치의 test1이라는 폴더와 하위 디렉토리를 포함한 파일들을 모두 바로 삭제한다.

** 명령어를 치기 전에 충분한 검토 후에 rm -f 혹은 rm -rf로 손쉽게 삭제할 수 있다.

이 외에도 시스템 상태를 체크하는 명령어들, vi편집기 명령어들 등 엄청나게 많지만 일단 기본적인 명령어는 여기까지 :)