Docker란 무엇인가?
Docker는 애플리케이션을 실행할 때 필요한 모든 것(코드, 라이브러리, 설정)을 하나의 컨테이너라는 "상자"에 담아두는 기술이에요. 이 상자는 개발, 테스트, 배포 등 어디로 가든 동일하게 작동해요. 그러니까 개발 환경과 배포 환경이 달라서 "왜 여기선 작동 안 하지?" 하는 고민이 사라지는 마법 같은 도구예요.
한마디로 Docker는?
"내 컴퓨터에서 잘 돌아가는 걸, 어디서든 잘 돌아가게 해주는 도구!"
왜 Docker를 써야 할까요?
과거의 문제
개발자들이 Docker 없이 개발하던 시절엔 이런 문제가 많았어요:
- "왜 개발 환경에선 되는데 서버에선 안 돼?"
- 개발자는 Windows를 쓰고, 서버는 Linux라서 설정이나 의존성 충돌로 문제가 생김.
- 배포는 너무 복잡했어요.
- 운영팀이 직접 서버에 가서 프로그램 설치하고, 라이브러리 깔고, 설정하고... 실수라도 하면 다시 처음부터.
- 자원 낭비가 심했어요.
- 각 프로그램마다 가상 머신을 만들었는데, 운영 체제(OS)까지 포함돼서 너무 무거움.
Docker가 가져온 변화
이제 Docker 덕분에 이런 문제가 싹 해결됐어요:
- 환경 차이 해결
- 개발 환경에서 만든 Docker 이미지를 그대로 서버에 옮기면 됩니다. 100% 동일한 환경이죠.
- 배포는 단순해졌어요.
- 이미지만 서버에 복사하면 끝! 클릭 몇 번으로 애플리케이션 실행 가능.
- 가볍고 효율적이에요.
- Docker는 운영 체제를 공유하므로 자원 소모가 적어요. 한 서버에서 수십 개의 컨테이너를 실행할 수 있어요.
Docker가 어떻게 일을 바꿨나요?
1. 과거의 문제: 환경 차이
- 문제: 개발자가 만든 프로그램이 서버에서 실행되지 않음. "왜 여긴 Python 3.10 없어요?"
- Docker의 해결책: Python, 라이브러리, 코드 모두 포함된 Docker 이미지를 사용. 환경 차이 문제 끝.
2. 과거의 문제: 복잡한 배포
- 문제: 프로그램 설치가 어렵고 배포가 느림. 운영팀이 일일이 수동 작업.
- Docker의 해결책: Docker 이미지를 빌드하고 서버에 올리면 바로 실행. 배포가 몇 초로 단축됨.
3. 과거의 문제: 확장 어려움
- 문제: 트래픽 폭증 시 새로운 서버 추가에 시간이 오래 걸림.
- Docker의 해결책: 컨테이너는 몇 초 만에 실행 가능. 필요하면 바로 확장 가능.
조금은, 가볍고 이해를 돕기 위해서 친절한 설명을 담아냈다. 이제는 다시 진지하게!
Docker는 컨테이너 기반의 가상화 기술을 제공하는 플랫폼으로, 애플리케이션과 그 실행 환경(라이브러리, 설정 파일 등)을 하나의 컨테이너로 묶어 배포하고 실행할 수 있도록 해줍니다. 이를 통해 애플리케이션을 효율적으로 개발, 배포, 실행할 수 있습니다.
1. Docker란 무엇인가?
Docker는 오픈소스 컨테이너화 플랫폼으로, 애플리케이션을 독립적이고 가벼운 컨테이너에 패키징하고 실행할 수 있도록 설계되었습니다. Docker 컨테이너는 애플리케이션 코드뿐만 아니라 실행에 필요한 모든 것을 포함하기 때문에 개발 환경과 배포 환경 간의 차이로 인한 문제가 줄어듭니다.
주요 구성 요소:
- Docker Engine: 컨테이너를 빌드하고 실행하는 엔진.
- Docker Image: 애플리케이션과 실행 환경을 정의한 템플릿.
- Docker Container: 이미지에서 생성된 실행 가능한 인스턴스.
- Docker Hub: 이미지 저장소로, 이미지를 공유하고 다운로드할 수 있는 플랫폼.
2. 왜 Docker인가?
Docker가 인기 있는 이유는 다음과 같은 특징들 때문입니다:
가벼움 (Lightweight)
- Docker는 기존 가상 머신(VM)보다 훨씬 가볍습니다. VM은 운영 체제(OS)를 포함해야 하지만 Docker는 호스트 OS를 공유하고 필요한 부분만 분리해 사용합니다.
- VM은 기가바이트 단위의 자원이 필요하지만 Docker 컨테이너는 메가바이트 단위로 매우 작습니다.
이식성 (Portability)
- Docker 컨테이너는 "한 번 빌드, 어디서나 실행"을 가능하게 합니다.
- 운영 체제나 하드웨어에 의존하지 않고 동일한 환경을 유지할 수 있습니다.
빠른 시작 (Fast Start)
- 컨테이너는 몇 초 안에 실행이 가능합니다. 이는 VM에 비해 훨씬 빠릅니다.
확장성 (Scalability)
- 애플리케이션을 여러 컨테이너로 분리하여 효율적으로 확장 가능합니다.
- 필요에 따라 컨테이너를 쉽게 추가하거나 제거할 수 있습니다.
3. 왜 Docker를 사용하는가?
개발과 배포의 일관성 보장
- 개발 환경과 배포 환경 간의 차이로 인해 발생하는 "작동하던 코드가 실행되지 않는 문제"를 방지합니다.
- 개발자는 Docker 이미지를 사용해 동일한 환경에서 작업할 수 있습니다.
효율적인 리소스 사용
- Docker 컨테이너는 호스트 OS의 커널을 공유하므로 VM보다 자원 소모가 적습니다.
- 하나의 호스트에서 더 많은 애플리케이션을 실행할 수 있습니다.
DevOps 및 CI/CD 지원
- Docker는 지속적 통합/배포(Continuous Integration/Continuous Deployment)를 쉽게 구현할 수 있습니다.
- Jenkins, GitLab CI/CD 같은 도구와 통합되어 자동화된 빌드와 배포를 지원합니다.
복잡한 애플리케이션의 관리
- 마이크로서비스 아키텍처를 쉽게 구현할 수 있습니다.
- 각 서비스가 독립된 컨테이너에서 실행되므로 문제를 격리하고 수정하기 쉽습니다.
4. 예시: Docker 사용 시의 장점
문제 상황: 개발 환경과 배포 환경의 차이로 인해 애플리케이션이 서버에서 정상적으로 실행되지 않음.
- Docker 없이: 개발 환경에서의 라이브러리 버전과 서버의 라이브러리 버전이 다를 수 있음.
- Docker 사용: 개발 시 사용한 Docker 이미지를 배포 환경에서도 그대로 사용하므로 환경이 동일하게 유지됨.
문제 상황: 대규모 서비스의 확장이 필요함.
- Docker 없이: 물리 서버나 VM을 추가하는 데 시간이 오래 걸림.
- Docker 사용: 컨테이너를 몇 초 만에 추가로 실행해 쉽게 확장 가능.
5. Docker의 한계
- 학습 곡선: Docker 및 컨테이너 개념을 처음 배우는 데 시간이 필요할 수 있음.
- 퍼포먼스 한계: 특정 상황에서는 VM보다 성능이 떨어질 수 있음.
- 운영 관리 도구 필요: Kubernetes와 같은 오케스트레이션 도구가 필요한 경우도 있음.
결론
Docker는 가볍고, 이식성이 뛰어나며, 빠른 배포와 확장을 가능하게 해줍니다. 현대 소프트웨어 개발과 배포 환경에서 필수 도구로 자리 잡았으며, 특히 DevOps 및 마이크로서비스 아키텍처를 채택한 조직에서 널리 사용됩니다. Docker를 배우면 개발부터 배포까지의 과정을 더 효율적이고 신뢰성 있게 관리할 수 있습니다.
Docker 이전과 Docker 이후의 차이
1. Docker 이전의 개발 및 배포 환경
과거에는 애플리케이션을 개발하고 배포하는 과정에서 다음과 같은 문제가 빈번했습니다:
- 환경 차이 문제
- 개발 환경과 운영 환경의 불일치: 개발자 로컬 환경에서 작동하던 코드가 운영 서버에서는 작동하지 않는 경우가 많았습니다.
- 예: 개발자는 Python 3.10을 사용했는데, 운영 서버는 Python 3.8만 지원.
- 라이브러리나 의존성 문제: 서로 다른 버전의 라이브러리가 설치되어 충돌 발생.
- 개발 환경과 운영 환경의 불일치: 개발자 로컬 환경에서 작동하던 코드가 운영 서버에서는 작동하지 않는 경우가 많았습니다.
- 운영 체제 종속성
- 특정 애플리케이션이 Windows에서는 잘 작동하지만 Linux에서는 작동하지 않는 문제.
- 복잡한 배포 프로세스
- 배포를 위해 환경을 수동으로 설정해야 했습니다. 설치해야 하는 소프트웨어나 의존성이 많아 시간이 많이 걸렸습니다.
- 배포 과정에서 버그가 발생하거나 누락되는 경우가 잦았습니다.
- 자원 낭비
- 애플리케이션을 실행하기 위해 가상 머신(VM)을 사용했지만, 각 VM은 자체 운영 체제를 포함하고 있어 자원이 낭비되었습니다.
- 서버 용량이 부족해 확장이 어려웠습니다.
- 협업 문제
- 여러 개발자가 동일한 프로젝트에서 작업할 때, 각자의 개발 환경이 달라 문제 해결이 어려웠습니다.
2. Docker 이후의 변화
Docker를 활용하면서 이러한 문제들이 해결되었고, 다음과 같은 이점을 얻었습니다:
- 환경 차이 해결
- Docker 컨테이너는 애플리케이션 실행에 필요한 모든 것을 포함하기 때문에, 개발 환경과 운영 환경이 동일하게 유지됩니다.
- **"한 번 빌드, 어디서나 실행"**이 가능.
- 예: 개발자가 Docker 이미지를 생성하면, 이 이미지를 운영 서버에서도 그대로 실행 가능.
- Docker 컨테이너는 애플리케이션 실행에 필요한 모든 것을 포함하기 때문에, 개발 환경과 운영 환경이 동일하게 유지됩니다.
- 운영 체제 독립성
- Docker는 컨테이너 내에서 실행 환경을 격리하므로, 운영 체제나 호스트 환경에 의존하지 않음.
- Windows, macOS, Linux 등 어디서나 동일하게 실행 가능.
- 간단한 배포 프로세스
- 컨테이너 이미지를 한 번 생성하면, 이를 다른 서버나 클라우드로 쉽게 전송하고 실행 가능.
- 복잡한 설정 과정이 불필요하며, 배포 시간이 대폭 단축됨.
- 자원 효율성
- Docker 컨테이너는 호스트 OS를 공유하므로 가상 머신보다 훨씬 가벼움.
- 같은 서버에서 더 많은 애플리케이션을 실행 가능.
- 팀 협업 강화
- 모든 팀원이 동일한 Docker 이미지를 사용하므로, 환경 차이로 인한 협업 문제 해결.
- 새로운 팀원이 프로젝트를 시작할 때 환경 설정 시간이 크게 단축.
Docker와 가상머신의 비슷한 점과 차이점을 설명해줄래?
Docker와 가상머신(Virtual Machine, VM)은 모두 애플리케이션을 격리된 환경에서 실행하도록 도와주는 기술입니다. 하지만, 동작 방식과 효율성, 사용 목적에서 큰 차이가 있어요. 아래에서 비슷한 점과 차이점을 각각 정리해 볼게요.
1. Docker와 가상머신의 비슷한 점
- 애플리케이션 실행 환경 격리
- 둘 다 서로 독립적인 환경에서 애플리케이션을 실행할 수 있도록 격리 기능을 제공합니다.
- 여러 애플리케이션이 같은 물리적 머신에서 실행되어도 서로 간섭하지 않습니다.
- 효율적인 리소스 활용
- 서버 리소스를 나눠서 여러 애플리케이션을 실행할 수 있게 해줍니다.
- 단일 물리적 머신에서 여러 워크로드를 실행하기 위한 용도로 사용됩니다.
- 이식성 제공
- 애플리케이션을 특정 환경에 묶어 두지 않고, 다른 시스템에서도 실행할 수 있도록 만들어 줍니다.
- 한 번 구성한 환경을 다른 하드웨어나 서버로 쉽게 옮길 수 있습니다.
2. Docker와 가상머신의 차이점
1) 구조적인 차이
- 가상머신 (VM)
- VM은 하드웨어 수준에서 가상화를 제공합니다.
- VM에는 전체 운영 체제(OS)가 포함되며, 하드웨어를 가상화한 Hypervisor(하이퍼바이저)가 필요합니다.
- 각 VM은 자체 커널과 운영 체제를 실행하므로 무겁고 자원 소모가 큽니다.
- 물리적 머신 → 하이퍼바이저 → VM → 운영 체제 → 애플리케이션
- Docker (컨테이너)
- Docker는 운영 체제 수준에서 가상화를 제공합니다.
- 컨테이너는 호스트 운영 체제의 커널을 공유하며, 필요한 라이브러리와 실행 환경만 포함합니다.
- 컨테이너는 가볍고 빠릅니다.
- 물리적 머신 → 운영 체제 → Docker → 컨테이너 → 애플리케이션
2) 성능 차이
- VM
- 무겁고 부팅 시간이 느립니다. (수십 초 ~ 몇 분)
- VM마다 별도의 운영 체제가 포함되므로 메모리와 디스크 사용량이 큽니다.
- VM 간에 자원 할당이 고정적이어서 유연성이 떨어질 수 있습니다.
- Docker
- 가볍고 실행 속도가 빠릅니다. (몇 초)
- 컨테이너는 운영 체제를 공유하므로 메모리 사용량과 디스크 크기가 작습니다.
- 자원 할당이 동적으로 이루어져 더 유연합니다.
3) 이식성
- VM
- 가상 디스크 이미지(예: .vmdk 파일)를 통해 이식성이 있지만, 파일 크기가 매우 큽니다.
- 하이퍼바이저와의 호환성이 중요합니다.
- Docker
- Docker 이미지는 가볍고 간단하며, 어디서나 실행 가능합니다.
- Docker Hub를 통해 이미지를 쉽게 공유하고 배포할 수 있습니다.
4) 사용 사례
- VM
- 여러 운영 체제를 실행해야 하는 경우 (예: Linux와 Windows를 동시에 실행).
- 운영 체제와 애플리케이션을 모두 격리해야 하는 경우.
- 물리적 서버의 하드웨어 리소스를 분리해야 하는 경우.
- Docker
- 동일한 운영 체제에서 여러 애플리케이션을 독립적으로 실행해야 하는 경우.
- 애플리케이션 개발, 테스트, 배포 환경을 일관되게 유지하려는 경우.
- 가볍고 빠른 배포가 필요한 경우 (예: 마이크로서비스 아키텍처).
5) 관리 편의성
- VM
- 설정 및 유지 관리가 더 복잡합니다.
- 운영 체제 업데이트와 보안 패치를 개별적으로 관리해야 합니다.
- 하드웨어 리소스를 세분화해 관리하려면 고급 설정이 필요합니다.
- Docker
- 설정 및 유지 관리가 간단합니다.
- 컨테이너는 쉽게 삭제, 복제, 배포가 가능하며, 코드 한 줄로 실행할 수 있습니다.
- DevOps와 CI/CD 파이프라인에서 강력한 도구로 사용됩니다.
3. 요약: Docker와 VM의 주요 비교표
항목Docker가상머신 (VM)| 격리 수준 | 운영 체제 수준 | 하드웨어 수준 |
| 운영 체제 포함 여부 | 호스트 OS 공유 | 각각 별도의 OS 포함 |
| 부팅 속도 | 몇 초 | 수십 초 ~ 몇 분 |
| 리소스 사용 | 가볍고 효율적 | 무겁고 자원 소모 큼 |
| 이식성 | 높은 이식성 (작고 가벼움) | 중간 수준 (파일 크기 큼) |
| 사용 사례 | 마이크로서비스, CI/CD, 애플리케이션 테스트 | 서로 다른 운영 체제 실행 필요 시 |
결론: Docker와 VM, 무엇을 선택해야 할까?
- Docker는 애플리케이션 배포와 실행을 간단하게 만들고, 빠르고 가벼운 환경에서 실행하기 적합합니다.
- 개발과 배포 환경을 일치시키고, DevOps를 활용하거나 마이크로서비스 아키텍처를 구현하려는 경우 최고의 선택입니다.
- VM은 강력한 격리 수준이 필요하거나, 여러 운영 체제를 동시에 실행해야 하는 상황에서 유리합니다.
- 하드웨어 수준의 리소스 분리와 안정적인 환경을 제공해야 할 때 VM을 선택하세요.
Docker와 VM 모두 강력한 도구이며, 상황에 맞게 적절히 사용하는 것이 중요합니다. 두 기술의 차이점을 이해하고 나면, 어떤 상황에서 무엇을 써야 할지 명확해질 거예요. 🚀
Docker 구조
[ 하드웨어 (물리적 머신) ]
↓
[ 운영 체제 (OS) ]
↓
[ Docker 엔진 ]
↓
+-------------------------+
| 컨테이너 1 | → 애플리케이션 1
| (라이브러리 + 코드) |
+-------------------------+
↓
+-------------------------+
| 컨테이너 2 | → 애플리케이션 2
| (라이브러리 + 코드) |
+-------------------------+
↓
+-------------------------+
| 컨테이너 3 | → 애플리케이션 3
| (라이브러리 + 코드) |
+-------------------------+- Docker 컨테이너는 운영 체제 커널을 공유하며, 필요한 라이브러리와 애플리케이션 코드만 포함합니다.
- 가볍고 효율적이며, 컨테이너 간의 격리는 Docker 엔진이 관리합니다.
가상머신(VM) 구조
[ 하드웨어 (물리적 머신) ]
↓
[ 하이퍼바이저 ]
↓
+-------------------------+
| VM 1 | → 애플리케이션 1
| [ 게스트 OS ] | → (운영 체제 + 라이브러리 + 코드)
| [ 라이브러리 + 코드 ] |
+-------------------------+
↓
+-------------------------+
| VM 2 | → 애플리케이션 2
| [ 게스트 OS ] | → (운영 체제 + 라이브러리 + 코드)
| [ 라이브러리 + 코드 ] |
+-------------------------+
↓
+-------------------------+
| VM 3 | → 애플리케이션 3
| [ 게스트 OS ] | → (운영 체제 + 라이브러리 + 코드)
| [ 라이브러리 + 코드 ] |
+-------------------------+- 각 가상머신은 **자체 운영 체제(게스트 OS)**를 가지고 있으므로, 메모리와 디스크 사용량이 큽니다.
- 하드웨어를 가상화하는 하이퍼바이저를 통해 VM 간의 격리를 유지합니다.
두 구조의 주요 차이점
- 운영 체제 공유 여부
- Docker: 하나의 운영 체제(OS)를 모든 컨테이너가 공유.
- VM: 각 VM이 개별 운영 체제(OS)를 포함.
- 하이퍼바이저 vs Docker 엔진
- Docker: Docker 엔진으로 컨테이너 관리.
- VM: 하이퍼바이저를 통해 VM 관리.
- 자원 사용
- Docker: 가볍고 빠름. OS를 공유하므로 메모리와 디스크 사용이 적음.
- VM: 무거움. 각 VM이 독립된 OS를 포함하므로 자원 소모가 큼.
이 구조를 머릿속에 그려보면 Docker가 왜 가볍고 빠른지, VM이 왜 무겁지만 강력한 격리 환경을 제공하는지 쉽게 이해하실 수 있을 거예요. 😊
docker 공식 문서에 나와있는 docker install ubuntu 를 진행하면 된다.
docker 설치 완료! (docker version 이라는 명령어)
docker는 기본적으로 패키징을 하는 기술이다. 패키징된 것들을 docker image 라고 부른다.
설치된 image를 볼 수 있는 명령어가 sudo docker images
지금까지 단 한 번도 docker image를 설치한 적이 없으니 아무것도 나오지 않는다.
원래는 docker images 라는 명령어로 볼 수 있는건데, 접근권한이 없다고 해서 sudo docker images 라고 하는 것.
그래서,
접근 권한 group에 나를 집어넣어서, 이제는 그냥 docker images 라고만 명령어 치면 볼 수 있도록.
나는 image가 없지만, 있다고 치고.
이 docker image로부터 docker container를 실행할 수 있다.
프로세스를 실행한다는 것.
간단하게 말해서, docker image들은 프로그램들이고
실행을 하게 되면 프로세스가 된다라고 이해하면 되겠다.
기본적으로 뭘 배울때에는 hello-world가 공식인것처럼, docker 에서도 처음으로 실행시켜볼 image는 hello world이다.
hello world 도커이미지가 없기때문에 가지고 오기도 해야 한다.
docker pull hello-world
(hello-world 라는 name을 가진 유명한 docker image가 있는 것 같다. 그걸 pull 가져오는 docker 명령어다)
이제 저 docker image 를 실행해보자.
docker run hello-world 라고 해보자.
도커로 부터 인사가 왔다.
나도 안녕~ (지금은 새벽 1시50분.. 아내도 자고 아기도 자고 있지만, 나는 지금이 아니면 공부할 시간이 없다는....)
1. The Docker client contacted the Docker daemon.
- Docker 클라이언트가 Docker 데몬에게 요청을 보냈습니다.
- 클라이언트: 터미널에서 실행한 명령어 (docker run hello-world)입니다.
- 데몬: Docker가 동작하도록 백그라운드에서 실행되는 서비스입니다.
2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
- Docker 데몬이 Docker Hub에서 "hello-world" 이미지를 다운로드했습니다.
- Docker Hub는 Docker 이미지를 저장하고 공유하는 공식 저장소입니다.
- "hello-world"는 가장 기본적인 Docker 이미지로, Docker가 제대로 설치되었는지 테스트하기 위한 용도입니다.
3. The Docker daemon created a new container from that image which runs the executable that produces the output you are currently reading.
- Docker 데몬이 "hello-world" 이미지에서 컨테이너를 생성했습니다.
- 이 컨테이너는 메시지를 출력하는 간단한 실행 파일(프로그램)을 포함하고 있습니다.
- 컨테이너가 실행되면서, 터미널에 메시지가 출력됩니다.
4. The Docker daemon streamed that output to the Docker client, which sent it to your terminal.
- 컨테이너가 실행한 프로그램의 출력 결과를 Docker 데몬이 Docker 클라이언트로 전달했고, 그것이 터미널에 표시되었습니다.
라고 말하고 있다.
docker hub 에서 nginx 공식으로 들어가서 nginx image를 가지고 와서 간단한 실습도 진행했다.
다음은 Docker의 핵심 명령어를 명령어와 기능으로 정리한 표입니다:
| 명령어 | 기능 |
| docker pull [이미지명] | Docker Hub에서 이미지를 다운로드. |
| docker images | 로컬에 저장된 Docker 이미지 목록을 확인. |
| docker rmi [이미지명] | 로컬에 저장된 이미지를 삭제. |
| docker run [이미지명] | 컨테이너를 생성하고 실행. |
| docker run -it [이미지명] bash | 컨테이너를 대화형 모드로 실행하고, 터미널에 접속. |
| docker run -d [이미지명] | 컨테이너를 백그라운드 모드로 실행. |
| docker ps | 실행 중인 컨테이너 목록을 확인. |
| docker ps -a | 중지된 컨테이너를 포함한 모든 컨테이너 목록을 확인. |
| docker start [컨테이너ID/이름] | 중지된 컨테이너를 다시 시작. |
| docker stop [컨테이너ID/이름] | 실행 중인 컨테이너를 중지. |
| docker rm [컨테이너ID/이름] | 컨테이너를 삭제. |
| docker exec -it [컨테이너ID/이름] bash | 실행 중인 컨테이너 내부의 터미널에 접속. |
| docker build -t [이미지명] . | Dockerfile을 기반으로 이미지를 빌드. |
| docker logs [컨테이너ID/이름] | 컨테이너의 로그를 확인. |
| docker inspect [컨테이너ID/이름] | 컨테이너 또는 이미지의 상세 정보를 확인. |
| docker network ls | Docker 네트워크 목록을 확인. |
| docker network create [네트워크명] | 새로운 네트워크를 생성. |
| docker-compose up | docker-compose.yml 파일을 기반으로 컨테이너를 생성 및 실행. |
| docker-compose down | docker-compose.yml로 실행된 모든 컨테이너 및 네트워크를 중지하고 제거. |
설명 추가
이 표는 Docker를 처음 배우는 사람들에게 꼭 필요한 기본 명령어들을 포함하고 있습니다.
학습할 때는 이미지 관리 → 컨테이너 실행 → 컨테이너 관리 순으로 차근차근 익히는 것이 좋습니다.