우선 기본 vi 편집기는 가장 기본적인편집 기능만 있어, 여러 기능이 추가되어 향상된 vim(VI iMproved)를 사용하는 편이 낫다.

vim 패키지 설치

• 패키지 정보를 갱신한다.
• vim 패키지를 설치한다.
• 터미널에서 vi를 실행시키면 다음과 같은 화면을 확인할 수 있다.
• 편집기 종료 시 :q 를 입력한 후 엔터 키를 누른다.

vi 모드

vi에는 명령, 입력, ex 세 가지 모드로 텍스트를 편집할 수 있다.

vi 외 다른 편집기

• emacs : 기능이 강력한 텍스트 편집기. 다만 여러 기능을 제공하므로 사용법을 쉽게 익히기 어렵다는 단점이 있다.
• nano : vim이나 emacs보다 사용하기 쉬우며, 우분투에도 기본 설치 되어있다. 방향키를 이용해 커서를 이동하고 ctrl 또는 Alt와 특정 키를 함께 입력하여 텍스트를 편집한다.
• gedit : 우분투 데스크톱에서 사용가능한 그래픽 환경의 텍스트 편집기. 앱 버튼을 누르고 메뉴에서 연필모양의 텍스트 편집키를 클릭하여 실행한다. 터미널에서 gedit [파일명] 형식으로 입력하여 실행도 가능하다.

명령모드에서 사용할 수 있는 키

vi 편집기에서는 글자단위, 단어단위, 줄단위로 커서를 이동할 수 있다.

커서 이동

텍스트 입력

명령모드에서 입력모드로 전환하는 입력 키는 a(append), i(insert), o(open) 이다. 대문자와 소문자 키의 기능이 다르므로 주의한다.

텍스트 삭제

기본적인 삭제 키는 x(backspace), d(delete) 이다.

텍스트 수정

명령모드에서 사용할 수 있는 수정 키는 r(replace), s(subst), c(change) 이다.

텍스트 복사

복사 키는 y(yank), 붙여넣기는 p(paste) 이다.

작업 취소, 반복

작업 취소는 u(undo), 다시 실행은 ctrl + r(redo) 이다. 취소된 작업에 한해서만 재실행이 가능하며 .는 명령을 반복한다.

텍스트 검색

명령모드에서 텍스트를 검색할 수 있는 키는 /와 ?이다. 파일 내에 동일한 텍스트가 더 있는지 찾으려면 n(next)를 사용한다.

영역 선택

명령 모드에서 블록으로 영역을 선택하려면 v(visual)을 누른다. 영역 지정 후 y를 누르면 명령 모드로 돌아오면서 선택한 영역을 복사하며, 명령모드에서 다시 p를 눌러 복사한 내용을 붙여넣기 할 수 있다.

파일 작성하기

vi [파일명] 형식으로 새로 생성하거나 추가할 파일 이름과 함께 vi 편집기를 실행한다.

파일 생성 및 내용 작성

파일을 새로 생성하는 경우 위처럼 파일 명 오른쪽에 새 파일임이 표시된다. 틸트(~) 표시는 줄이 비어있다는 의미이다.

현재 상태는 명령모드이다.

a 또는 i를 누르면 화면 아래 정보가 다음과 같이 변경되며 입력모드로 전환된다.

한글 입력도 가능하나, 입력모드로 전환하는 a 또는 i는 반드시 영문 상태에서 입력해야한다.

파일 저장을 위해서는 다시 명령모드로 전환 후 ex모드로 전환해야한다.

파일 내용을 모두 입력했다면 esc 키를 눌러 명령 모드로 전환한다.

화면 아래 끼워넣기 또는 INSERT 문구가 사라졌다면 :을 눌러 ex모드로 전환하여 명령어를 입력한다. 이때, :wq는 파일을 저장하고 vi를 종료하여 명령행으로 되돌아가는 ex 명령이다.

명령행 프롬프트가 나타나면 ls 또는 cat 명령으로 파일이 제대로 생성되었는지 확인해본다.

파일 내용 복사 붙여넣기

문자열 복사 후 붙여넣기 실습을 해보자. 우선 파일을 다시 vi로 열고, 복사할 단어 앞으로 커서를 옮긴 후 v 키를 누르면 화면 아래 메시지가 비주얼 또는 VISUAL 로 바뀐다.

커서 이동 키를 누르면 텍스트를 블록으로 지정할 수 있다. 오른쪽 화살표를 눌러 문장 마지막까지 이동한 후 y를 누르면 비주얼 표시가 사라지며 다시 명령모드로 돌아온 것을 볼 수 있다.

내용을 붙여넣을 위치에 커서를 위치시키고 p를 누르면 복사한 내용을 불러온다.

dd를 누르면 커서가 있는 줄이 삭제된다.

커서를 가장 아래로 옮긴 후 다시 p를 누르면 삭제했던 줄을 불러온다.

y와 p가 복사, 붙여넣기라면 d와 p는 잘라내기와 붙여넣기로 볼 수 있다.

ex 모드에서 사용할 수 있는 키

ex 명령의 장점은 일반 명령보다 빠르고 효율적으로 처리할 수 있다는 것이다. 한 번 실행으로 동시에 여러 부분을 변경할 수 있다.

파일 저장, 편집기 종료 키

자주 사용하는 ex 명령

아래 명령어는 16번줄을 2번 줄로 옮긴다.

[시작 행 번호],[끝 행 번호] 형태로 명령을 적용할 줄을 선택할 수도 있다. 아래 명령어는 1번줄과 2번줄을 복사하여 3번줄 뒤에 붙인다.

문자열 치환도 가능하다. 파일 전체(%)에서 모든(g) 문자열 ball game을 찾아 BASEBALL GAME으로 바꾼다(s)

set 명령

ex 모드에서 set 명령을 사용하면 vi 환경 설정 내용을 변경할 수 있다.

set 명령을 별도의 설정파일 .vimrc로 홈 디렉토리에 저장해두면 나만의 vim 환경을 만들 수 있다.

systemd : 시스템 관리자

부팅 과정부터 다시 되새겨보자.

• BIOS/UEFI가 파티션 정보를 읽고 부트로더 GRUP를 실행한다.
• GRUB는 저장장치에서 커널을 찾아 메모리에 올리고 시스템 제어 권한을 커널에 넘긴다.
• 커널은 시스템 초기화 이미지인 initrd를 메모리에 마운트한다. (initrd에는 장치드라이버를 비롯한 시스템 초기화 도구들이 들어있다.)
• 커널은 필요한 도구를 실행하고 저장 장치의 진짜 루트 파일 시스템을 마운트한다.
• 리눅스 커널은 모든 프로세스의 부모 역할을 하는 PID 1번 프로세스 init을 실행한다.
  • init은 사용자가 시스템을 사용할 수 있는 환경을 만들어준다. (시스템초기화)
  • ps 1로 1번 프로세스 systemd를 확인할 수 있다.

시스템 관리자 systemd는 부팅 프로세스만 처리하지 않고 시스템을 전반적으로 관리하는 만능 도구로 개발되었다.

systemctl [옵션][명령] : systemd 관리

systemctl로 시스템 상태 조회

systemctl list-units는 유형별 유닛 목록과 상태를 화면에 표시한다. 옵션이나 추가 명령 없이 systemctl 을 실행한 결과와 동일하나, more나 less 처럼 up/down 버튼으로 화면 스크롤이 가능하다. q를 누르면 스크롤을 종료하고 명령 프롬프트로 돌아온다.

• UNIT : 유닛 이름. 유니 ㅅ 이름 뒤에 붙는 접미사(automount, device, service 등)로 어떤 유형의 유닛인지 짐작 가능
• LOAD : systemd가 유닛 설정 파일을 정상적으로 읽어들였는지 확인
• ACTIVE : 유닛이 동작하고 있는지 여부
• SUB : 유닛이 활성(active) 상태라면 추가 상태 정보 표기
• DESCRIPTION : 유닛에 대한 세부 설명

-t 옵션 추가 시 유닛 유형에 따라 결과를 필터링 할 수 있다.

target은 부팅 과정에서 활성화 할 유닛을 결정하는 유닛이다. systemctl list-dependencies 는 의존 관계에 있는 유닛을 보여준다.

systemctl get-default는 현재 기본 target을 보여준다.

systemd의 default.target은 graphical.target의 심볼릭링크이다.

명령 인자 없이 systemctl list-dependencies를 실행하면 기본 target과 관련된 유닛 목록을 보여준다. target 유닛을 기준으로 살펴보면 systemd가 부팅 과정에서 시스템을 초기화하고자 어떤 일을 처리하는지 유추할 수 있다.

systemctl로 서비스 제어하기

status는 서비스 상태를 보여주는 명령이다. status 로 조회 시 순서대로 서비스 이름과 설명, 서비스 유닛 설정파일 상태, 서비스 활성화 여부, 프로세스 정보, 서비스 실행과정에서 발생한 로그가 화면에 표시된다.

is-active 로 서비스가 현재 활성화 상태인지 확인할 수 있다. is-enabled로 부팅과정에서 자동 활성화 되는지 여부를 확인할 수 있다.

stop 명령으로 서비스를 중지할 수 있다. 시스템 상태를 변경하므로 sudo가 필요하다. 중지 후 상태를 확인해보면 inactive로 상태가 변경된 것을 확인해 볼 수 있다.

그 외 상태를 변경하는 명령은 다음과 같다.

journalctl : systemd 로그 정보 조회

systemctl status 로 확인할 수 있는 로그 정보는 systemd-journald가 제공한다. systemd-journald는 부팅부터 발생하는 systemd의 로그 정보를 이진 자료로 저장하므로, journalctl 명령으로만 확인할 수 있다.

-u(--unit) 옵션으로 특정 유닛에 대한 로그 정보를 조회 할 수 있다. 로그 정보는 less로 화면에 출력된다.

-e(--pager-end) 옵션으로 최근 로그정보부터 화면 스크롤을 시작할 수 있다. -u 옵션과 함께 사용이 가능하다.

-p(--priority) 옵션으로 로그 정보를 중요도에 따라 필터링이 가능하다.

예를 들어 다음 명령은 장치 설정 과정에서 발생한 오류를 찾아내고자 systemd-udevd의 오류 로그만 조회한다.

-S(--since)나 -U(--until) 옵션 사용 시 날짜나 시간을 기준으로 로그 필터링이 가능하다. 혼용 또한 가능하다. 연-월-일 시:분:초 형식으로 입력하며, 시간이 생략되면 00:00:00 이 기준이 된다. 날짜대신 yesterday, today, tomorrow를 입력하여 어제, 오늘, 내일을 지정할 수도 있다.

dpkg [옵션][명령] : 기본 패키지 관리

wget 명령으로 우분투 한국 미러 사이트에서 cosway라는 패키지 파일을 내려받는다. 또는 웹 브라우저로 우분투 패키지 저장소에서 내려받는다.

sudo dpkg -i 명령어로 내려받은 deb 파일을 통해 패키지를 설치한다.

설치가 완료되면 다음처럼 명령어를 활용하여 확인할 수 있다.

-L 옵션으로 설치된 패키지 파일 목록을 확인할 수 있다.

-l 옵션으로 시스템에 설치된 패키지 목록을 조회할 수있다.

apt [옵션][명령][패키지] : 향상된 패키지 관리 도구

apt로 패키지 설치

• 패키지 저장소의 주소를 소스 리스트, /etc/apt/sources.list에 추가
• apt update 명령
• 패키지 저장소에서 새로운 패키지 목록 호출
• apt install 명령
• 패키지 설치

패키지 설치 전 sudo apt update로 패키지 목록을 갱신한다.

apt search [패턴] 형식으로 패키지 이름을 검색한다.

apt show 로 설치하려는 패키지 정보를 자세하게 조회할 수 있다.

apt depends 명령으로 설치하려는 패키지와 의존관계에 있는 패키지 목록을 조회할 수 있다. dpkg 와 달리 apt는 의존관계에 있는 패키지를 자동 설치하므로 매번 확인할 필요는 없다.

sudo apt install 명령으로 패키지를 설치한다. 이 때 -y 옵션을 추가하면 패키지를 설치할 지 확인하는 과정을 생략한다.

설치 후 패키지를 실행해보면 프로그램이 실행된다.

apt로 패키지 삭제

sudo apt remove로 패키지를 삭제한다.

패키지 삭제 중 설정파일이나 임시파일이 일부 남겨지기도 한다. sudo apt purge로는 패키지를 완전히 삭제할 수 있다.

앞서 제거한 패키지들과 의존관계에 있어 더이상 필요없게 된 패키지는 sudo apt autoremove로 삭제할 수 있다.

apt로 패키지 업데이트

apt list로 업데이트 가능한 패키지를 확인할 수 있다.

apt upgrade 명령어로 업데이트 가능한 모든 패키지를 새로운 버전으로 갱신한다.

apt 사용 중 락 걸리는 경우

여러 곳에서 원격 호스트에 접속하여 작업 중 패키지를 설치할 때 lock이 걸릴 수 있다. 다른 사용자 또는 다른 프로세스가 동시에 apt를 사용하려고 하여 생기는 문제이다. 이 때, 잠금파일 /var/lib/dpkg/lock 을 삭제하면 다시 apt 명령을 실행할 수 있다.

우분투 설치 시 기본적으로 파일 시스템에 시스템 디렉터리가 생성된다. 시스템 디렉터리는 중요한 의미를 갖기 때문에 함부로 삭제하거나 변경해서는 안된다.

루트 디렉터리 조회 시 시스템 디렉터리 목록을 확인할 수 있다.

폴더 별 역할

• / : 모든 디렉터리가 시작하는 뿌리인 최상위 디렉터리. 루트로 읽는다.
• /boot : 부팅에 필요한 커널, 초기화 이미지, 부트로더 관련 파일
• /dev : 시스템에 설치된 장치(마우스, 모니터, 그래픽카드, 저장장치) 파일
• /etc : 사용자/그룹정보, 파일 시스템테이블, 네트워크 설정파일 등 시스템 설정 파일
• /bin : 사용자가 사용하는 가장 기본적인 명령들의 실행 파일
• /lib : 공유 라이브러리 파일. 시스템 부팅과 응용 프로그램 실행에 필요
• /home : 사용자 계정 별 홈 디렉터리. 사용자 계정 생성 시 사용자 계정 이름과 동일한 홈 디렉터리가 이 경로 아래에 생성된다. 사용자는 각자의 파일을 사용자 홈 디렉터리에 저장한다.
• /root : 루트 계정을 위한 홈 디렉터리. 일반 사용자는 접근하지 못하도록 권한 설정이 되어있다.
• /sbin : 루트 권한이 필요한 시스템 관리 명령
• /tmp : 임시로 파일을 생성/삭제하는 공간. 주로 사용자 프로그램에서 임시로 읽어들여야하는 입출력 파일들을 저장하는 데 사용
• /var : 시스템 운영 중 발생하는 임시 파일(시스템 로그, 웹사이트 콘텐츠, 전자메일 등) 보관. 크기가 계속 변하는 파일을 저장한다.
• /usr : 사용자가 추가로 설치한 응용 프로그램 파일 저장
• /proc : 시스템 정보 제공. 리눅스 커널과 통신하는 가상 파일 시스템 디렉터리로 실제 공간을 차지하지는 않는다. CPU 정보, 인터럽트 목록, 입출력 주소 목록 등 커널이 제공하는 정보가 파일 형태로 저장
• /opt : 외부에서 제공되는 패키지가 설치

디렉터리 다루기

pwd : 현재 작업중인 디렉터리 위치를 화면에 표시

mkdir : 디렉터리 생성

-p(--parent) 옵션을 활용하면 상위 디렉터리를 포함하는 하위 디렉터리를 생성한다. 예를 들어, 현재 작업 디렉터리에 BaseballTeam이라는 디렉터리를 만들고, 다시 그 아래 KBO라는 디렉터리를 생성하려면 mkdir을 두 번 실행해야 하지만, -p 옵션으로 한 번에 생성 가능하다. 옵션 없이 실행하면 오류가 발생하니 주의하자.

cd : 디렉터리 이동

cd [옵션][디렉터리] 형식으로 작성한다. ls -al로 확인 가능한 숨김 폴더 중 . 는 현재 디렉터리, .. 는 현재 디렉터리의 상위 디렉터리를 의미한다.

cd ..를 입력하면 상위 디렉터리로 이동한다.

cd 명령 실행 중 대상 디렉터리를 입력하지 않거나 틸트(~)를 입력하면 해당 사용자 계정의 홈 디렉터리로 바로 이동한다.

상대 경로와 절대 경로를 이용한 이동

📍pwd 명령은 항상 현재 디렉터리를 절대 경로로 표시한다.

• 상대 경로 : 특정 디렉터리를 기준으로 디렉터리 경로를 지정 mkdir 명령으로 사용자 홈 디렉터리 아래에 BasketballTeam/NBA 를 생성 후 상대 경로로 이동해보자. 상대 경로로 최하위 디렉터리 NBA까지 이동하려면 하위 디렉터리 경로만 입력하면 된다.

• 절대 경로 : 최상위 디렉터리인 루트 디렉터리를 기준으로 디렉터리 경로를 지정 다시 홈으로 돌아와 절대 경로로 이동해보자. 절대 경로로 이동 시 모든 경로를 입력해야 한다는 불편함이 있다. 하지만 다음처럼 BasketballTeam/NBA에서 BaseballTeam/KBO로 이동하는것과 같은 상황에서는 절대경로로 이동하는 편이 낫다. 상대 경로로 이동 시 반드시 상위 경로인 사용자 홈 디렉터리를 거쳐야 하기 때문이다.
  * 상대경로로 이동한 경우  * 절대경로로 이동한 경우 

rmdir : 디렉터리 삭제

앞서 만들어둔 빈 디렉터리를 삭제해보자. rmdir은 빈 디렉터리만 삭제하므로, 디렉터리에 파일이 있다면 rm 명령을 사용해야 한다.

파일 다루기

cp [옵션] [원본파일] [사본파일] : 파일 복사

테스트를 위해 현재 디렉터리에 touch 명령으로 teamdata라는 빈 파일을 만들어 해당 파일을 복사해보자. 원본(teamdata)와 사본(lions)의 권한, 소유권, 변경 시각이 동일하다.

원본 또는 사본의 경로를 구체적 지정도 가능하다. 아래 명령은 teamdata의 파일을 BaseballTeam/KBO에 twins라는 파일명으로 복사한다.

옵션 활용

• -r(--recursive) : 하위 디렉터리에 존재하는 디렉터리와 파일 모두를 복사
• -a(--archive) : 파일 복사 과정에서 접근 권한, 소유자, 그룹, 파일 수정시간 정보를 그대로 보존

아래 명령은 KBO 디렉터리를 MLB 디렉터리로 복사하며 하위 디렉터리의 접근권한, 소유권, 변경시각을 그대로 유지한다.

mv [옵션] [원본파일] [사본파일] : 파일 이동

mv 명령어는 cp 명령어와 다르게 원본 파일이 삭제되므로 주의해야한다. 아까 생성한 lions 파일을 BaseballTeam/KBO로 옮겨보면 기존 경로에서는 삭제되었고 지정한 경로에 파일이 생성됨을 확인할 수 있다.

원본 파일을 여러개 옮기는 것도 가능하다. KBO 디렉터리에서 MLB 디렉터리로 두 파일을 한 번에 이동시켜보자.

mv 명령어로 디렉터리도 옮길 수 있다. MLB 디렉터리를 MajorLeagueBaseball로 옮겨보자.

rm [옵션] [파일명] : 파일 삭제

touch 명령어로 빈 파일을 여러개 생성할 수 도 있다. rm 명령어로 파일을 삭제한다. 동시에 여러 파일을 삭제할 수도 있다.

옵션 활용

-rf 옵션을 붙이면 하위 디렉터리를 포함한 모든 파일을 삭제할 수 있다.

• -r : 재귀 옵션. 하위 디렉터리에 영향을 미친다.
• -f : 삭제하려는 파일이 있는지 확인하지 않고 강제로 삭제한다.

이 때, 대상 파일을 삭제할 권한이 없다면 오류 메시지가 나타난다. rm -rf 명령을 실행하기 전에는 반드시 삭제 대상과 권한을 확인해야한다. 특히, 루트 디렉터리를 대상으로 삭제 명령을 실행한다면 시스템 파일들이 순식간에 제거되어 복구 불가능한 상태가 되므로, 삭제 대상 파일의 권한 때문에 sudo 명령으로 루트 권한을 얻어야 한다면 rm 명령을 실행하기 전 다시 한 번 삭제 대상을 확인해야 한다.

파일 내용 확인하기

cat : 파일 내용 화면에 표시

cat 명령은 파일의 내용을 조회한다. /usr/share/common-licenses/GPL 파일을 조회해보자. 이 파일은 리눅스 커널에 적용된 GPL 라이선스 정보이다.

옵션 활용

• -n(--number) : 줄번호 추가

• > : 출력 재지정. 출력 결과를 화면 대신 파일로 보내 새로운 파일을 생성할 수 있다. cat > [파일명] 을 실행하면 빈 줄이 나오고 여기에 파일 내용을 입력한 후 ctrl + d를 눌러 종료하면 다시 명령행으로 나간다. 내용을 다시 조회해보면 위에서 입력한 내용이 정상 저장됨을 확인할 수 있다.

  입출력 재지정

  리눅스의 표준 입력 장치는 키보드, 표준 출력 장치는 모니터 화면이다. > 또는 < 로 표준 입력 및 출력을 다른 대상으로 바꿀 수 있다. 배시가 제공하는 입출력 재지정 기능이다.

  
  

  • 출력 재지정 > 출력 재지정 기호를 이용해 ls 명령의 결과를 표준 출력 장치인 모니터가 아닌 homelist 파일로 출력한다. homelist 파일에는 ls 명령 결과인 홈 디렉터리의 파일 목록이 저장되어 있다. 이 때, 해당 파일이 존재하지 않는다면 자동 생성하여 표기한다.
    
  • 입력 재지정 < 입력 재지정 기호를 이용하면 표준 입력 장치인 키보드 입력 대신 파일에서 입력받아 처리할 수 있다. sort 는 결과를 순서대로 정렬하는 명령인데, -r 옵션을 활용하면 결과를 역으로 정렬할 수 있다. 표준 입력을 재지정하여 앞서 만든 homelist 파일의 내용을 sort 명령으로 넘긴다. 명령 결과 파일 목록을 알파벳 역순으로 정렬하여 화면에 표시한다.

more, less : 한 화면씩 스크롤하여 파일 내용 조회

cat 은 파일 내용을 끝까지 한 번에 다 보여주기 때문에 화면에 표시할 내용이 많다면 모두 확인하기는 어렵다. 분량이 많은 파일은 more나 less로 한 화면씩 스크롤 하는 편이 낫다.

화면 전환 키

아까 열었던 GPL 파일을 more 명령으로 호출해보자. 화면 아래에 표시되는 정보로 스크롤의 위치를 가늠할 수 있다.

less를 활용해도 동일한 키로 파일 내용을 조회할 수 있다. less 명령어는 more 명령어보다 더 많은 키를 활용할 수 있다.

키	동작
g	첫 화면으로 이동
G (shift + g)	마지막 화면으로 이동
/	문자열 검색 ex) /GNU 명령어 실행 시 해당 단어가 하이라이트 된다. 이 때, n과 N(shift+n)을 눌러 검색된 문자열을 건너뛰며 이동할 수 있다.

head, tail : 파일의 처음(head) 또는 미지막(tail)을 기준으로 파일 내용 출력

/var/log/syslog는 시스템이 남기는 로그 파일로 운영 과정에서 발생하는 이벤트 기록을 저장한다. 일반적으로 로그 파일은 용량이 크고 내용이 자주 바뀌므로 일부만 모니터링하는 것이 유용하다.

head : 파일의 처음을 기준으로 파일 출력

특별히 옵션을 사용하지 않으면 파일의 첫번째 줄 부터 열번째 줄 까지 출력한다. 특정 줄까지 출력하고 싶다면 -n(--lines) 옵션을 사용한다. 다음 명령어는 처음부터 15번째 줄까지 출력한다.

tail : 파일의 마지막을 기준으로 파일 출력

head와 마찬가지로 옵션을 지정하지 않으면 파일의 마지막 줄 부터 열번째 줄 까지 출력하며, -n 옵션을 추가해 보고싶은 줄의 범위를 지정할 수 있다.

-f(--follow) 옵션은 실시간으로 파일을 모니터링 한다. 명령을 실행하면 명령 프롬프트를 반환하지 않고 지속적으로 시스템이 변하는 상황을 보여주며, ctrl+c를 누르면 명령행으로 되돌아온다.

파일 검색하기

find [탐색경로] [옵션] [표현식] : 파일 찾기

탐색 경로를 생략하면 현재 작업 중인 디렉터리부터 검색을 시작한다. 이 때, 읽기 권한이 없는 디렉터리는 검색을 건너뛴다. sudo로 루트 권한을 얻으면 모든 디렉터리를 대상으로 검색할 수 있는데, 루트 디렉터리부터 시작해서 모든 파일을 검색하려면 탐색 경로에 루트 디렉터리를 명시한다. 다만, 파일 시스템 전체의 파일을 검색하므로 시간이 오래걸린다.

옵션 목록

옵션 활용 예제

• -name : 파일 명으로 검색

• -type : 파일 종류를 지정하여 검색 다음 명령어에서 d는 디렉터리를 의미한다.

• -mtime : 특정 기간 동안 내용이 변경된 파일 검색 인자로 변경된 기간을 받는데, -는 미만, +는 초과를 의미한다. 예를 들어, -mtime +7은 수정한지 일주일이 넘은 파일들을 대상으로 한다. 아래 명령어는 현재 디렉터리(.)를 기준으로 수정한지 하루가 되지 않은(-mtime -1) 파일들을 검색한다.

• 검색 옵션 중복 사용

  • 상위 디렉터리(..)부터 100MB가 넘는(-size +100M) 일반 파일(-type f)을 검색

  • 루트 디렉터리(/)부터 시작해서 두 단계의 하위 디렉터리(-maxdepth 2)까지 bin이란 이름을 가진(-name bin) 파일 또는 디렉터리를 검색 검색 결과 /bin, /usr/bin은 포함하지만 /usr/local/bin은 제외함을 볼 수 있다.

  • /etc 디렉터리에서 대소문자 구분 없이(-i) conf로 끝나는(-name *conf) 파일(-type f)을 검색

파일 명을 대체하는 메타문자

• * : 모든 문자 대체. find -name a*b 형태로 사용 ex) a*b : a로 시작하여 b로 끝나는 모든 이름. aannbb, anb 등 모두 조회
  
• ? : 정확히 1개의 문자만 대체. find -name a?b 형태로 사용 ex) a?b : a로 시작하고 중간에 임의의 문자 하나가 있으며 b로 끝나는 이름. anb 형태만 조회, aannbb는 조회 불가
  
• [문자] : 괄호 안에 있는 문자를 대체. find -name [A,B,C]_number 형태로 사용 ex) [A,B,C]_number : A나 B또는 C로 시작하고 _number로 끝나는 파일 이름. A_number, B_number, C_number가 검색됨
  이 케이스는 표준식처럼 -를 이용해 대체할 영문자나 숫자의 범위를 지정할 수 있다. 예를 들어, _number[0-9]_는 number로 시작해서 0부터 9까지 숫자가 붙는 문자인 number0, number1, ... number9에 대응한다. 같은 원리로 _[A-C]number_는 [A,B,C]number와 동일한 검색 결과를 도출한다.
  다만 이 경우, 범위를 지정할 때 a-Z처럼 대/소문자를 섞어쓰거나 숫자와 영문자를 섞어 범위를 지정할 수 없다. [] 안에는 동일한 성질의 문자 범위만 지정할 수 있다.

echo : PATH 내용 확인

명령 행에서 명령을 입력하면 셸은 환경변수 PATH에 정의된 디렉터리들을 검색하여 실행한다. 각 디렉터리는 콜론(:)으로 구분하며, 왼쪽에서 오른쪽으로 검색한다.

which [파일명] : 명령의 절대 경로 호출

which 명령어는 PATH 변수의 디렉터리를 검색해 명령의 절대 경로를 찾아 보여준다.

whereis : 명령과 해당 명령의 소스파일, 매뉴얼 페이지 경로 검색

whereis 명령어는 설정 파일을 찾을 때 유용하다.

grep [옵션] [표현식] [파일명] : 파일 내용 검색

아무 옵션 없이 명령을 실행하면 지정한 파일에서 검색된 문자열을 포함하는 행을 보여준다. 터미널에서는 검색어가 붉게 표시되어 보인다.

파일 명 대신 *를 쓰면 현재 디렉터리에 있는 파일들을 모두 검색한다.

옵션 활용

• -r(--recursive) : 현재 디렉터리부터 하위 디렉터리를 포함한 모든 파일에서 문자열 검색

• -c(--count) : 해당 문자열이 포함된 행 수 출력

• -n(--line-number) : 해당 문자열이 포함된 행과 행 번호를 함께 출력

• -i(--ignore-case) : 대,소문자 구분 없이 문자 검색

파이프(|)를 활용한 검색

파이프는 여러 명령을 동시에 사용하는 도구로, 프로세스 사이에 정보를 전달하는 통로 역할을 수행한다. grep 명령은 단독으로 사용하기보다 파이프로 다른 명령과 조합하여 결과를 얻는데 유용하게 쓴다.
예를 들어, 파일 목록을 출력하는 ls -l 결과에 grep을 사용하면 파일 목록에서 data라는 문자열을 포함한 결과만 표시한다. 파이프는 일괄적으로 출력을 입력으로 보내 처리하므로, 명령A|명령B로 입력하면 명령A의 출력을 명령B의 입력으로 보내버린다.
홈 디렉터리에서 ls -l 명령을 실행하면 숨김파일까지 모두 표시하므로 출력 결과가 한 화면을 넘는 결과가 일반적이다. 이 때, more나 less와 조합하여 사용하면 훨씬 조회가 수월하다. 명령A|명령B|명령C 형태로도 사용이 가능한데, 명령 A의 출력을 명령 B의 입력으로, 다시 명령 B의 출력을 명령 C의 입력으로 전달한다.
다음과 같은 형태로 활용할 수 있다.
- 파일 목록을 조회(-ls -l)하여 역순으로 정렬(sort -r)하고 화면 단위로 결과를 출력(more)

리눅스에서 파일이란?

리눅스에서는 모든 것이 파일이다. 텍스트, 이미지, 영상 뿐 아니라 파일을 묶는 디렉터리, 네트워크 소켓 등 자료 흐름과 시스템 장치까지 파일로 처리한다. 리눅스에서는 파일의 대·소문자를 엄격하게 구분하여 서로 다른 파일로 간주한다. 파일 이름은 최대 256자까지 가능하며, 공백을 포함한 특수문자를 사용할 수 는 있으나 되도록 사용하지 않는 편이 좋다.

ls : 파일 목록 화면에 표시하기

ls [옵션] [파일] : 파일 목록을 화면에 표시한다. 아무 옵션 없이 명령을 실행하면 파일과 디렉터리 명만 출력한다.

• 아무 옵션, 인자 없이 ls만 호출 : 현재 작업중인 디렉터리 표시
• 인자로 디렉터리 경로 지정하는 경우 : 해당 디렉터리의 하위 디렉터리와 파일 목록 표시

그 외 자주 사용되는 옵션 별 기능과 예시 화면이다.

옵션	설명	예시
-l	파일 세부 정보 표시
-lh	-h : 파일 용량 단위를 MB, GB로 변환하여 표기. -l 옵션과 붙여 -lh 형식으로 사용 가능
-a	숨은 파일 까지 표기. 모든 디렉터리에는 현재 디렉터리를 의미하는 .와 상위 디렉터리를 의미하는 ..이 포함되어있다. 이 외에 .으로 시작하는 파일들은 모두 숨긴 파일임을 의미한다.
-al	현재 디렉터리에 있는 모든 파일의 세부 정보 표기. -a와 -l 옵션을 붙여 사용하는 형태

파일 정보를 조회할 때 다음과 같이 표시된다.

이 중 접근권한은 다음과 같은 기준으로 표기된다.

• 첫번째 자리: 디렉토리(d), 일반파일(-)
• 2~4번째 자리 : 소유자에 대한 읽기(r), 쓰기(w), 실행(x) 권한 유무
• 5~7번째 자리 : 소유그룹에 대한 읽기(r), 쓰기(w), 실행(x) 권한 유무
• 8~10번째 자리 : 다른 모든 사용자에 대한 읽기(r), 쓰기(w), 실행(x) 권한 유무

첫번째 자리를 제외한 각 권한은 r, w, x 순으로 표기되며, 해당 권한이 없을 경우 -로 표기된다. 위 이미지에서의 권한 부여 상태를 분석하면, 현재 조회된 음악 파일은 디렉토리 이며, 소유자는 읽기, 쓰기, 실행을 모두 할 수 있고, 소유그룹과 다른 모든 사용자는 읽기, 실행을 할 수 있다.

chown, chmod : 파일 소유권 및 접근 권한 설정

touch : 파일의 날짜와 시간 정보를 '건드려 바꾸기'

touch [옵션] [파일명] 형태로 사용하며, 파일의 날짜/시간정보를 바꿀 수 있다. 아무 옵션 없이 새로운 파일 이름을 지정하면 비어있는 파일을 생성할 수 있다.

chown : 파일 소유권 설정

기본적으로 파일 소유권은 파일을 생성한 사용자와 사용자가 속해있는 그룹에 있다. 파일의 소유권을 변경하려면 반드시 시스템관리자 권한으로 실행해야하므로 sudo 명령을 붙여야 한다. touch 로 빈 파일을 하나 생성하여 정보를 조회하면 해당 파일의 권한을 확인할 수 있다. 권한이 rs-rs-r-- 로 소유자와 그룹에 속한 사용자가 읽고 쓸 수 있으며, 그 외 사용자는 읽기만 가능하도록 설정되어있음을 확인할 수 있다.

1) touch 명령 시 sudo -u [사용자명] 명령을 앞에 덧붙여 파일 생성부터 소유권 설정하기

위처럼 /tmp 경로에 임시 파일을 생성할 때 tester라는 계정에 소유권을 부여한 후 ls -l 명령어로 해당 파일의 상세정보를 조회해 보면 소유권이 명령을 실행한 시스템 관리자인 user가 아닌 tester로 잡혀있음을 확인할 수 있다.

2) chown [옵션] [사용자 계정 및 그룹] [파일]으로 이미 생성된 파일의 소유권 변경하기

• 파일 소유자만 변경하기
• 파일 소유자, 그룹 정보 동시 변경하기 사용자 계정과 그룹 사이에 . 또는 :를 넣어 소유자와 그룹을 동시에 변경할 수 있다.
• 디렉토리 소유권 변경하기 실습을 위해 /tmp 디렉토리에 /inventory라는 디렉토리를 생성(mkdir)여 빈 파일 phone과 picture를 생성(touch)하였다. 이 때 권한은 tester로 설정하였으며, ls -l 명령어로 조회 시 tester 계정으로 권한이 잘 설정되어있음을 확인할 수 있다.
  • chown 으로 디렉토리만 소유권 변경 단순히 chown만 사용하면 디렉토리의 소유권만 변경되고, 하위 파일들의 소유권은 기존과 동일하게 tester로 설정되어있음을 확인할 수 있다.
  • chown -R 으로 해당 디렉토리 + 하위 디렉토리 및 파일까지 모두 소유권 변경 재귀를 뜻하는 -R 옵션을 추가하면 해당 디렉토리와 디렉토리 하위에 있는 파일 및 디렉토리들의 소유권까지 모두 한번에 변경할 수 있다.

chmod : 파일의 접근권한 변경하기

chown과 달리 파일 소유자도 명령을 내릴 수 있다.

1) chmod [레퍼런스][연산자][접근권한] [파일] 형식

• 레퍼런스 : 변경할 대상 소유자(user), 그룹(group), 다른 모든 사용자_(other)_를 뜻하며 차례로 u,g,o로 표시한다. a는 소유자와 그룹, 다른 사용자 모두를 의미한다.
• 연산자 : 권한 부여 시 +, 권한 해제 시 -를 사용한다.
• 접근권한 : 읽기(read), 쓰기(write), 실행_(execute)_을 뜻하며 각각 r,w,x로 표기한다.

예제로 아까 생성한 /tmp/tempfile 의 권한을 모든 사용자와 그룹에게 rwx권한을 전부 부여한다. 이 결과로 시스템에 존재하는 모든 사용자가 이 파일을 읽고 쓰고 실행할 수 있다.

반대로 다음처럼 o-rwx를 사용하여 다른 사용자들에게서만 권한을 해제할 수도 있다. 다른 사용자들은 파일을 읽거나 쓰거나 실행할 수 없는 상태(rwxrwx---)로 변경됨을 확인할 수 있다.

2) chmod [8진수] [파일] 형식

[레퍼런스][연산자][접근권한] 대신 8진수의 숫자 표현을 사용할 수 있다. 익숙해지면 이 방식이 훨씬 편리하다. 파일의 소유자, 그룹 사용자, 기타 사용자의 읽기, 쓰기, 실행 권한은 다음과 같이 8진수 값이 부여되어있다.

부여 할 접근 권한에 따라 각 값을 더한다.

모든 사용자에게 읽기 권한만 부여하고 싶다면 접근 권한을 r--r--r-- 로 변경해야 한다. 이 때, 파일 소유자 읽기권한 400 + *그룹 읽기 권한 *40 + *다른 사용자 읽기 권한 *4를 더하여 444로 표현할 수 있다.

접근 권한을 처음 처럼 되돌려보자. 파일 소유자 읽기(400), 쓰기(200)와 그룹 읽기(40), 쓰기(20)가 가능해야하고 다른 사용자는 읽기(4)만 가능해야 한다. 결과를 계산하면 400+200+40+20+4 = 664 이다.

이 때, 파일의 소유자가 아니라면 chmod 명령을 실행할 수 없다. chown으로 파일 소유권을 변경한 후 명령을 실행해보면 권한이 없음을 확인할 수 있다.

※ 권한번호 777은 모든 사용자에게 읽기, 쓰기, 실행 권한을 부여하는 번호이다.

반대로 권한이 없을 때, sudo 명령을 사용하여 루트 권한을 획득하면 다른 사용자 소유의 파일 접근 권한을 변경할 수 있다.

ps, top : 프로세스 목록 조회

ps 명령어 옵션 목록

옵션	설명
-a	다른 사용자의 프로세스 상태도 표시
-x	화면에 보이지 않는 프로세스까지 표시
-u	프로세스를 사용한 사용자와 실행시간 표시
-ax	현재 실행 중인 모든 프로세스 표시
-aux	프로세스의 시스템 자원 사용률 표시
-e	실행 중인 모든 프로세스를 대상으로 프로세스 목록 출력
-f	완전한 형식으로 프로세스 목록 출력
-ef	PID로 정렬되어 있는 프로세스 목록 출력
f	프로세스 사이 상속 관계를 시각적으로 표현. -f 옵션과 다르다.
* ps 명령만 입력(옵션 미사용) : 현재 로그인 한 사용자가 실행하는 프로세스만 표시
* ps -ax : 현재 실행중인 모든 프로세스 조회. 이 때, 프로세스 목록 중 대괄호로 둘러싸인 프로세스는 커널이 생성한 프로세스이다.
* ps -aux : 프로세스의 시스템 자원 사용률

• user : 프로세스 소유자 이름
• PID : 프로세스 식별 번호
• %CPU : 프로세스가 CPU를 차지하는 비율
• %MEM : 프로세스가 메모리를 점유하는 비율
• VSZ (Virtual Set siZe) : 리눅스가 프로세스에 할당한 가상 메모리 크기(실제 프로세스가 할당한 가상 메모리를 모두 사용하지는 않음)
• RSS (Resident Set Size) : 프로세스가 현재 사용하는 메모리 크기(프로세스 사이에 공유되는 메모리 정보는 제외)
• STAT : 프로세스의 현재 상태
• START : 프로세스가 시작된 시간
• TIME : 프로세스의 총 사용 시간
• COMMAND : 프로세스를 실행한 명령

프로세스 상태 값

표기	상태
R (Run/Runnable)	CPU를 사용하는 상태 / 대기하는 상태
D (in Disk wait)	입출력이 완료될 때 까지 대기. 깨울 수 없는 수면 상태. 입출력 완료 시 다시 실행 대기(R)로 전환
S (Sleeping)	스스로 대기 중인 수면 상태. 시간이 경과하거나 특정 이벤트가 발생하면 다시 실행 대기(R)로 전환
T (sTopped)	외부 신호로 일시 정지된 상태. 또 다른 외부 신호를 수신하면 다시 실행 대기로 전환.
Z (Zombie)	실행 완료한 프로세스는 부모 프로세스에 종료 신호를 보내고, 부모 프로세스에서 종료 신호를 받아들이면 프로세스가 소멸된다. 이 때 부모 프로세스에 문제가 있어 신호를 수신하지 못하면 좀비 상태로 남아있게 된다.

• ps -ef : PID로 정렬되어 있는 프로세스 목록 출력

  • PPID : 부모 프로세스의 PID
  • C : 프로세스의 CPU 점유 상태
  • STIME : 프로세스가 시작된 시간
  • TTY : 프로세스가 시작되고 있는 터미널
  • 그 외 항목은 -aux 옵션과 동일하다.

• ps -f : 프로세스 목록 상세 조회. 현재 실행 중인 배시 셸과 셸에서 실행시킨 ps 명령 사이의 관계를 확인할 수 있다. ps명령의 PPID가 배시 셸의 PID와 동일하므로 ps는 배시 셸의 자식 프로세스이다. 따라서 명령 행에서 입력하여 실행하는 명령은 배시 셸의 자식 프로세스라는 사실을 알 수 있다.

• ps f : 프로세스 사이의 상속 관계 표시. 여러 프로세스 사이의 관계를 한눈에 파악하는데 도움이 된다.

  top : 실시간 메모리 점유율, CPU 사용률 확인

  실시간 메모리 점유율, CPU 사용률 확인에는 ps -aux보다 top이 더 유용하다. ps는 개별 프로세스 상태를 보여주지만, top은 전체적인 프로세스를 알아볼 때 사용한다.

• 윗부분은 시스템 가동 시간, 평균 부하, 전체 프로세스 정보, 메모리 정보 등 시스템 상태를 요약하여 보여준다.

• 아래는 각 프로세스 정보를 CPU를 가장 많이 점유하는 순서대로 출력한다.

  • 약 5초마다 내용이 업데이트 되며, Space 또는 Enter키를 누르면 프로세스 목록이 바로 갱신된다.

  • 필요 시 단축키를 통해 프로세스 목록을 다양한 순서로 정렬할 수 있다.

    • Shift + p : CPU 사용량(%CPU) 순
    • Shift + m : 메모리 사용량(%MEM) 순
    • Shift + n : PID 순
    • Shift + t : CPU 사용 시간별(TIME+)
    • < 또는 > : 정렬 순서 결정
    • q : top 종료

  • PID : 프로세스ID

  • USER : 프로세스 소유자

  • PR : 프로세스의 우선순위

  • NI : 우선순위를 지정하는 nice값

  • VIRT : 프로세스가 점유하는 가상 메모리 양(KB)

  • RES : 스왑되지 않은 물리 메모리양(KB)

  • SHR : 공유 메모리양(KB)

  • S : 프로세스 상태

  • %CPU : CPU 점유율

  • %MEM : 메모리 점유율

  • TIME+ : 프로세스가 CPU를 사용한 누적 시간

  • COMMAND : 프로세스를 실행한 명령

lsof : 열린 파일 목록 조회

리눅스 커널은 파일을 파일 기술자라는 숫자 값으로 구분한다. 리눅스는 모든 것을 파일로 추상화해서 다루기 때문에 일반 파일뿐만 아니라 입출력 장치, 네트워크 소켓, 파이프 같은 실행 중인 프로세스와 관련 된 시스템 장치를 파일 기술자로 관리한다. 이중 0은 표준 입력, 1은 표준 출력, 2는 표준 오류로 예약되어있다.

• lsof : 열린 파일 목록을 화면에 표시. 사용자 명령 또는 시스템 프로세스로 사용중인 파일 목록 조회. 이 때 일부 파일은 로그인 해 있는 사용자 권한으로 조회할 수 없어 표시되지 않지만, sudo명령을 붙이면 루트 권한으로 시스템 파일까지 확인할 수 있다.

  • 필드 목록

    • COMMAND : 실행한 명령
    • PID : 프로세스 식별 번호
    • USER : 사용자
    • FD : 파일 기술자. 숫자 외에 cwd(현재 작업 디렉터리), rtd(루트 디렉터리), txt(텍스트 파일), mem(메모리 매핑 파일)으로 표시
    • TYPE : 파일 종류. DIR(디렉터리), REG(일반파일), CHR(문자 장치 파일), FIFO(파이프나 소켓), IPv4(네트워크 연결)로 표시
    • DEVICE : 장치 번호
    • SIZE/OFF : 파일 크기
    • NODE : 노드 번호
    • NAME : 파일 이름

  • lsof -i : 네트워크 연결 정보 조회. 연결 정보는 NAME 필드에서 확인할 수 있으며, 연결된 상태의 TCP정보는 [호스트명]:[포트번호]->[원격호스트명]:[포트번호] 형식으로 표기된다.

    -i 옵션 뒤에 프로토콜과 포트 번호를 명시하여 결과를 필터링 할 수 있다. 예를 들어 lsof -i TCP:80은 네트워크 연결 중 TCP 80번 포트(http)와 연결 정보만 보여준다.

• lsof -u [사용자명] : 사용자 소유의 열린 파일 목록 조회

• lsof -c [명령] : 특정 명령으로 사용되는 파일 목록 조회

• lsof -p [PID] : 프로세스가 사용하는 파일 목록 조회. 시스템 파일 조회 시 루트 권한이 필요하다.

작업 제어하기

여러 작업을 동시에 처리하는 데 작업 제어 명령을 사용한다.

프로세스를 하나 실행시켰다가 중지시키며 작업을 제어해보자.

• wget [옵션] [url링크]은 네트워크를 사용하여 파일을 받아오는 명령이다.
• 우분투 서버 iso 이미지를 내려받는 중에 ctrl + z를 눌러 작업을 중단한다.
• 하단 [1]은 작업을 제어하는 작업ID(job ID)이다.

jobs : 목록을 화면에 표시하는 작업 제어 명령

• jobs -l : 해당 프로세스의 PID를 함께 출력

bg [작업ID] 또는 & 추가: 중단된 프로세스를 백그라운드에서 실행

PID와 달리 작업ID는 퍼센트(%)를 붙여서 구분한다. 아까 중지시킨 wget 명령을 백그라운드에서 실행한 후 jobs로 확인해보면 작업이 진행중인 상태로 변경됨을 볼 수 있다.

fg [작업ID] : 백그라운드에서 진행중인 작업을 다시 포그라운드로 실행

작업을 포그라운드로 가져오면 작업이 끝날때까지 대기하거나 ctrl + c로 작업을 강제 종료할 수 밖에 없다.

sleep [시간] : 지정한 시간만큼 대기

백그라운드에서 실행되는 작업을 대기 시키려면 &를 붙이면 된다. ex) sleep 30& : 30초 대기

언제든 jobs -l 명령으로 진행 중인 프로세스의 작업ID와 PID를 확인할 수 있다.

kill : 프로세스 상태 변경

kill 명령은 실행 중인 프로세스에 시스템 신호를 보내 프로세스 상태를 변경한다. 신호 종류는 kill -l로 확인할 수 있다.

• kill [옵션] [PID] 형태로 입력한다. 아무 옵션이 없으면 15번 SIGTERM 신호를 보내 프로세스를 종료한다.

  자주 사용되는 옵션

• kill -9 [PID] : SIGKILL. 프로세스 강제 종료. 대부분의 프로세스는 SIGTERM 신호로 종료되지만, 종료되지 않는 경우 SIGKILL을 사용하여 강제 종료시킨다.
• kill -1 [PID] : SIGHUP. 프로세스를 멈추지 않고 다시 실행 환경설정을 변경하여 서비스를 다시 실행할 때 사용가능하여 서버를 운영하는데 유용하다.

쉬운 입력을 위한 배시의 명령 히스토리

• 커서 이동키 ↑를 누르면 이전에 자신이 내렸던 명령을 불러올 수 있다.
• 명령 행에서 history 명령을 내리면 이전에 자신이 실행했던 명령 목록을 조회할 수 있다.
  • 이전에 실행했던 명령을 검색하고자 history명령 결과를 파이프를 이용해서 grep 명령으로 넘기는 방식을 자주 사용한다. ex) history | grep [명령]
• !!라고 입력하면 바로 전에 실행한 명령을 다시 실행한다.
• history 명령 결과는 [번호] [명령] 형식이다. ![번호]를 입력하면 번호에 해당하는 명령을 다시 실행한다.

실행중인 작업 목록에서 PID 알아내기

wget 명령을 백그라운드 실행 후 PID를 찾아보자.

• jobs -l : 백그라운드에서 실행중인 작업목록에서 PID를 알아낼 수 있다.
• ps -ef | grep wget : ps -ef 결과 중에서 grep으로 문자열 wget을 검색하여 화면에 표시한다.

whoami, who, w : 로그인한 사용자 정보 조회하기

• whoami : 현재 로그인 한 사용자 계정 조회

• who : 로그인한 사용자 계정, 접속한 터미널 정보, 로그인 시각, 접속한 IP 주소를 차례로 보여준다. 접속자가 여럿이면 각각의 접속정보가 표시된다.

  • :0 : 그래픽 환경에서 생성된 첫번째 터미널임을 의미한다.
  • tty : 기본 터미널 장치. 우분투 서버에 직접 접속하는 콘솔 환경인 경우 tty1로 표시된다.
  • pts : 의사 터미널 장치. ssh를 이용해 원격 접속하면 터미널 정보가 pts/0으로 표시된다,

• w : 현재 접속해 있는 사용자 정보와 함께 시스템 정보를 화면에 출력한다. 시스템 시간 정보, 부팅 이후 경과한 시간, 접속한 사용자 수, 시스템의 평균 부하율이 차례로 표시된다. uptime 명령 결과와 동일하다.

  • USER : 접속한 사용자 계정
  • TTY : 터미널
  • FROM : IP주소
  • IDLE JCPU PCPU : 사용자가 사용하고 있는 CPU 점유율 정보
  • WHAT : 접속자가 현재 사용하고 있는 명령

sudo : 루트 권한 획득하기

리눅스는 여러 사용자가 동시에 사용 가능한 다중 사용자 운영체제이다. 사용자는 권한에 따라 시스템 자원에 대한 접근, 사용여부가 결정된다.

일반적으로 리눅스는 사용자 실수로 시스템에 돌이킬 수 없는 문제가 발생하는 사고를 방지하고자 루트 사용자의 로그인을 제한한다. 시스템 관리자도 일반 사용자 계정으로 로그인해야하며, 루트 권한이 필요할 때 루트 권한을 획득하는 과정을 거친다.

루트 권한이 없어 허가 거부 오류 메시지가 보이는 경우

루트 권한 부여 후 명령 처리

• apt update : 패키지 저장소에서 새로운 패키지 목록을 가져오는 명령. 실행 시 루트 권한이 필요하다.
• sudo 로 획득한 루트 권한은 일정 기간 유지되므로 명령을 실행할 때마다 매번 패스워드를 입력할 필요는 없다.

useradd : 사용자 계정 추가하기

useradd [옵션] [사용자 계정] 형식으로 입력한다.

• 옵션 -m(--create-home)을 사용하면 사용자 계정을 추가함과 동시에 홈 디렉터리를 함께 생성한다.
• ls 명령으로 새로 생성된 홈 디렉터리를 확인할 수 있다.
  

passwd : 사용자 계정의 패스워드를 변경한다.

• 다른 사용자의 패스워드를 변경하려면 루트 권한이 필요하므로 sudo를 함께 쓴다.

• 새로 설정할 패스워드를 입력 후 확인을 위해 재입력한다.

• 현재 로그인 해 있는 사용자 계정의 패스워드를 변경할 때는 sudo 없이 passwd만 입력해도 된다.

  
  

cat etc/passwd 로 사용자 계정 목록을 확인할 수 있다.

• cat : 파일 내용을 화면에 표시한다.
• 파일의 각 행은 사용자 계정 정보를 의미한다. 콜론(:)으로 구분해둔 필드는 왼쪽부터 [사용자계정]:[패스워드]:[UID]:[GID]:[추가정보]:[홈디렉터리]:[로그인셸] 을 의미한다.
  • 사용자 계정 : 시스템 운영을 위해 자동으로 생성된 사용자 계정이 대부분이며, 설치 과정에서 등록한 사용자, useradd로 추가한 사용자 계정을 확인할 수 있다.
  • 패스워드 : 아주 오래된 리눅스 시스템은 사용자 패스워드를 passwd 파일에 평문으로 저장했지만, 지금은 모든 패스워드를 x로 표시한다. 누구도 알아보지 못하도록 암호화하여 저장된다.
  • UID : 사용자 계정을 식별하는 고유번호(User ID)이다.
  • GID : 사용자가 속해있는 그룹 식별번호(Group ID)이다. UID와 GID가 동일한 이유는 일반적으로 사용자 계정이 만들어지면 계정 이름과 동일한 그룹이 자동 생성되기 때문이다.
  • 추가정보 : 설치 과정에서 사용자 실제 이름을 입력했다면 추가 정보로 저장된다. adduser 명령에서 입력하는 정보들이 여기에 저장된다.
  • 홈 디렉터리 : 로그인 후 사용하는 기본 작업 디렉터리 경로이다.
  • 로그인 셸 : 로그인 후 사용할 기본 셸을 지정한다.

adduser : useradd 와 passwd를 한번에 사용한다.

• adduser의 인자로 추가할 사용자 계정을 넘겨 실행한다
• 패스워드를 설정한다.
• 사용자 추가 정보를 입력한다. 여기서는 사용자 이름만 입력했다.
• 입력이 끝나면 Y를 눌러 사용자를 등록한다.

사용자 등록 후 cat /etc/passwd로 파일을 조회하면 새로 등록한 사용자 정보를 확인할 수 있다.

userdel [옵션] [사용자 계정] : 사용자 계정 삭제

• -r(--remove) : 사용자 홈 디렉터리까지 함께 제거한다.

• -r 옵션을 사용하지 않은 경우 계정 삭제 후에도 홈 디렉터리가 남아있다. 이 때 rm -rf로 디렉터리를 삭제할 수 있다.

사용자 계정 전환하기

sudo를 실행할 수 있는 권한은 sudo 설정 파일인 /etc/sudoers에서 지정한다. 사용자 계정 root, 그룹 admin(%admin), 그룹 sudo(%sudo)에 속하는 사용자는 모든 명령에 대해 sudo로 루트 권한을 얻을 수 있다.

su [옵션] [사용자 계정] : 사용자 계정 전환

• whoami로는 su명령으로 전환한 사용자 계정이 표시된다.
• who로는 로그인한 사용자 계정 정보를 보여준다.
• su 명령을 자주 사용할 때 처음 로그인한 사용자 계정을 확인하기위해 who가 쓰인다.

groups : 사용자가 속한 그룹 조회

계정을 생성할 때 자동으로 같은 이름의 사용자 그룹이 생성된다.

새로 추가한 사용자와 달리 우분투를 설치하면서 등록한 사용자는 다양한 시스템 그룹에 속해있다. sudoers에서 살펴보았듯이 sudo 그룹에 속한 사용자는 sudo 명령을 사용할 수 있다.

루트 권한이 없는 사용자는 sudo를 사용할 수 없다.

exit : su 명령 전 원래 사용자 계정으로 복귀

usermod [옵션] [사용자 계정] : 사용자 계정 정보 변경

루트 권한을 가진 시스템 관리자는 sudo 로 다른 사용자 계정 정보를 변경할 수 있다. 다음 명령은 사용자 계정을 sudo 그룹에 포함시킨다.

• -a(--append) : 변경 대신 정보를 추가하는 옵션 -a 없이 명령을 실행하면 사용자 계정의 정보는 '추가'가 아니라 '변경' 되어버린다. 즉, 기존 정보가 모두 삭제되므로 주의해야 한다.
• -G(--groups) : 사용자 계정의 그룹을 대상으로 한다.

아까 tester 계정은 사용자 권한이 없어 sudo 명령을 실행할 수 없었다. sudo 그룹에 추가된 후 sudo 명령을 실행할 수 있음을 확인할 수 있다.

새로운 사용자 계정 추가 시 -G 옵션을 사용하여 바로 그룹을 지정할 수도 있다.

sudo useradd -m -G sudo testuser

위 명령어는 새로 testuser라는 계정을 생성할 때 바로 sudo 그룹에 포함시킨다.

sudo 그룹 권한을 해지할 수도 있다.

• -G 옵션으로 사용자 그룹 정보를 재지정한다.
• 해당 사용자 계정으로 로그인(su)하여 그룹 정보를 확인해보면 sudo 그룹 권한이 사라져있음을 확인할 수 있다.
• 단순히 그룹 사용자를 삭제하려면 그룹 관리 명령인 gpasswd를 사용하는 것이 더 편리하다.

그룹 관리하기

groupadd [옵션] [그룹] : 새로운 그룹 생성

• -a(--add) : 그룹에 사용자 추가 (단건)

  sudo gpasswd -a [사용자 계정] [그룹]

  

• -M(--members) : 그룹에 사용자 추가 (다건)

  sudo gpasswd -M [사용자 계정],[사용자 계정],[사용자 계정] [그룹]

  

• groups [사용자 계정] : 해당 사용자가 속해있는 그룹을 화면에 표시한다.

• /etc/grouop에서 그룹 정보를 조회할 수 있다. 각 필드는 [그룹]:[패스워드]:[GID]:[사용자 목록] 을 의미한다.

• -d(--delete) : 그룹에서 사용자 삭제

  sudo gpasswd -d [사용자 계정] [그룹]

  groups로 삭제됨을 확인할 수 있다.

• groupdel : 그룹을 삭제 /etc/group 파일에서 salesA 그룹이 삭제됨을 확인할 수 있다.

사용자가 키보드로 문자열 명령을 입력하고 컴퓨터가 처리한 결과를 화면에서 확인하는 상호작용이다. 명령행 인터페이스는 시스템 자원을 덜 소모하고 효율적으로 시스템을 관리할 수 있다. 특히 서비스를 빠르고 안정적으로 제공하는 일 이더 중요한 서버 컴퓨터에서는 그래픽 사용자 인터페이스(GUI)보다 명령행 인터페이스를 선호한다. 서버 서비스에 꼭 필요한 패키지만 제공하는 우분투 서버도 명령행으로 제어한다. 그러므로 우분투 데스크톱을 사용하더라도 명령행 인터페이스를 익혀야 한다.

Bash 셸에서 명령행 인터페이스 사용해보기

Bash 셸에서 HelloBash라는 텍스트를 입력해보자.

• 터미널 실행 후 HelloBash 문자열 입력
  • 1행: 셸이 사용자에게서 명령을 받을 준비가 되었음을 의미한다.
  • 2행: 출력할 텍스트를 바로 입력하고 엔터를 누르면 셸이 해석을 시도한다.
  • 3행: 해당 문자열은 셸이 해석할 수 없는 아무 의미 없는 명령이므로 오류 메세지를 출력한다.
  • 4행: 명령 실행이 끝나고 다음 사용자 입력을 받고자 새로운 프롬프트가 나타난다.
• echo HelloBash 문자열 입력 이 때 셸은 입력된 문자열을 echo 와 HelloBash로 나누어 처리한다. echo는 배시가 제공하는 문자열 출력 명령으로, 뒤에 오는 문자열은 echo 명령이 출력할 문자열 인자로 분석한다.
  • 1행: 명령어 echo와 문자열 HelloBash를 입력 후 엔터를 누른다.
  • 2행: echo 명령의 결과로 사용자가 입력한 문자열 HelloBash를 화면에 출력한다. (정상적 명령 수행으로 오류가 발생하지 않는다.)
  • 3행: 새로운 프롬프트가 나타나며 셸이 다시 준비가 되었음을 알 수 있다.

셸 명령 옵션

어떤 명령들은 세부 기능을 선택할 수 있도록 옵션을 제공한다.

• 옵션은 기호 --나 -로 시작하며 영문 대/소문자로 입력한다. 일반적으로 --로 시작하는 옵션은 이름으로 의미를 알기 쉽지만 여러 문자를 입력해야하며, -로 시작하는 축약형 옵션은 짧게 입력할 수 있어 사용에는 편리하지만 어느정도 암기가 필요하다.
  예를 들어 사용자를 추가하는 useradd 명령은 사용법을 알려주는 --help와 -h 옵션을 모두 지원한다.

  useradd --help
  useradd -h

• 여러 옵션을 붙여 쓰는 것도 가능하다. 예를 들어 파일 목록을 화면에 보여주는 ls 명령은 숨김 파일까지 모두 표시하는 -a 옵션과 파일 정보를 함께 출력하는 -l 옵션을 제공하는데, 두 옵션을 동시에 사용해서 적용할 수 있다.

  #옵션을 붙여 쓰는 경우 순서와 상관없이 명령을 처리한다.
  ls -al
  ls -la 

시스템 시작, 종료하기

시스템을 시작하고 종료하는 명령어는 다음과 같다.

셸 시작하기

• 우분투 데스크톱 : 터미널 앱 실행. 한글 입출력 가능, 명령어 logout 실행 시 터미널 종료

• 우분투 서버 : 기본 콘솔 환경. 계정 로그인 시 활용 가능. 한글 입출력 불가능. 명령어 logout 실행 시 첫화면으로 돌아가 로그인 대기

셸 환경변수

printenv

printenv는 현재 설정된 모든 환경변수를 출력한다.

이 중 핵심 내용만 몇 가지 정리하였다.

기본 변수 등록

[변수명]=[값]의 형식으로 입력하여 셸에서 사용할 변수를 정의한다. 이 때, 변수 이름, 등호, 값 사이에 공백이 없어야한다. 변수를 사용할 때는 변수이름 앞에 $를 붙여야 한다.

export

사용자가 실행하는 명령은 셸의 자식 프로세스로 동작하므로, 방금 등록한 VAR 변수는 자식 프로세스에서 동작할 수 없어 사용에 제약이 있다. 환경변수를 조회해도 해당 변수는 찾아볼 수 없다.

export 명령은 변수를 환경변수로 내보낸다. VAR을 export 명령으로 등록 후 환경변수를 확인하면 VAR 변수가 등록됨을 확인할 수 있다.

export VAR=1

❗export 로 내보낸 환경변수는 로그인 상태에서만 유지된다. 터미널을 닫거나 로그아웃 이후 환경변수는 모두 초기화된다. 환경변수를 유지하려면 환경 설정 파일에 등록해야 한다. 현재 로그인 한 사용자에 해당하는 환경변수는 홈 디렉터리의 배시 환경 설정 파일 .bashsrc에 export명령으로 등록할 수 있다. 시스템 전체 등록 시 /etc/environment에 등록하면 된다.

unset

unset 명령은 환경변수를 삭제한다.

unset VAR

시스템 종료하기

shutdown 명령은 시스템을 종료한다. 우분투 서버, 우분투 데스크톱 터미널 모두에서 동일하게 동작한다. shutdown은 루트권한이 필요하므로 앞에 sudo 명령을 붙여야 한다.

sudo shutdown -h now

• shutdown [옵션][시간] 형식으로 입력한다.
• -h는 명령을 실행한 이후 전원을 차단하는 옵션이다.
• now는 지금 즉시 명령을 실행한다.

  예약 종료

• 몇 분 후에 종료할 지 옵션 지정 시 now 자리에 15 를 입력하면 된다.

  sudo shutdown -h 15

• 종료 시각을 지정할 수 있다. 3시 30분에 종료하고 싶다면 03:30을 입력하면 된다.

  sudo shutdown -h 03:30

• 예약 종료를 취소하려면 옵션 -c를 사용한다.

  sudo shutdown -c

• 재부팅 시 옵션 -r을 사용하거나 reboot 명령어를 사용한다.

  sudo shutdown -r now
  sudo reboot        #shutdown -r과 동일한 동작

ip 설정 확인

ip a 명령어로 네트워크 인터페이스 enp1s0의 inet 항목에서 받아온 IP주소를 확인할 수 있다. 주소 정보는 사용자별로 다를 수 있다.

언어 설정 확인

locale 명령어로 en_US.UTF-8로 잘 설정되었는지 확인한다.

혹시 로케일 설정이 잘못되었다면 sudo dpkg-reconfigure locales 명령어로 재설정할 수 있다.

시간대 설정

서버 설치 과정에서 시간대 선택이 생략되었으므로 설치후 반드시 시간대 설정을 변경해야한다.

1) date 명령어로 현재 서버 시간대 확인

국제 표준 협정시계시(UTC)로 설정되어있음을 확인할 수 있다.

2) timedatectl set-timezone 명령으로 시간대 변경

우리나라에 해당하는 'Asia/Seoul'로 입력한다. 변경 후 date 명령어를 실행하면 한국 표준시(KST)로 변경되었음을 확인할 수 있다.

패키지 저장소 주소 변경

기본 패키지 저장소는 우분투 공식 패키지 저장소의 미러링 서버인 kr.archive.ubuntu.com으로 설정되어있다. 이 주소를 KAIST 미러링 서버 ftp.kaist.ac.kr 또는 카카오의 미러링 서버 mirror.kakao.com로 변경하면 더 빠른 패키지 설치가 가능하다.

1) vi 명령으로 소스 리스트 파일 수정

• sudo vi /etc/apt/sources.list.d/ubuntu.sources 로 수정할 파일 열기

• :%s/kr.archive.ubuntu.com/mirror.kakao.com/g 로 텍스트 일괄 치환

• :wq 로 파일 변경내용 저장 및 편집기 종료

  3) 패키지 저장소 목록 갱신

  sudo apt update

• VMware 설치 주소 : https://www.vmware.com/products/desktop-hypervisor/workstation-and-fusion

• Ubuntu 설치 주소 : https://ubuntu.com/download/server
• Ubuntu 설치 버전 : 24.04.3 LTS
• Ubuntu 설치 환경
  • VMware Workstation 17 Player

테스트와 실습 위주로 진행할 예정이고, 이후 원활한 화면 캡처를 위해 VMware에서 사용을 위해 VMware에 설치를 진행한다. VMware가 이미 설치되었다는 전제 하에 Ubuntu Server 설치과정만 포스팅하였다.

VMware에 Ubuntu24.04 설치

1. VMware 실행 및 가상머신 생성 선택

Create a New Virtual Machine 을 선택한다.

2. 하드웨어 용량 확인 및 사용자 설정

1) 설치 할 iso 이미지 선택

• Installer disc image file 을 선택한 후 Browse를 클릭하여 내려받은 Ubuntu iso 파일을 선택한다.
• Next 를 클릭하여 다음 단계로 이동한다.

2) 서버 명 설정

• VMware에 표기 될 서버 명과 설치 위치를 설정한다.

3) 저장공간 크기 설정

4) 설정 정보 확인 및 설치

• 설정된 정보가 맞는지 확인 후 Finish를 클릭하면 가상머신 환경이 구축된다.

3. Ubuntu Server 실행

설치가 완료되면 자동으로 Ubuntu가 실행된다. 자동실행 되지 않는 경우 메인화면에서 Ubuntu를 선택하여 실행하면 된다.

1) Try or install Ubuntu Server 선택 및 언어 선택

• 한국어 미지원이므로 영어 선택 후 엔터를 누른다.

2) 설치도구 업데이트 및 키보드 설정

• 인터넷이 연결된 경우 설치도구 업데이트 여부를 선택할 수 있다. 필자는 업데이트 없이 설치를 진행한다.
• 키보드 배열을 선택한다. Layout, Variant 모두 기본값인 'English (US)' 선택 후 'Done'을 선택한다.

3) 인스톨 타입 설정

• 인스톨 타입을 선택한다.

4) 네트워크 설정

• enp1s0는 시스템에 설치된 이더넷 네트워크 인터페이스 명이다. 일반적으로 DHCP를 이용해 IP주소를 자동으로 받아오는 환경에서는 DHCPv4항목에 자동으로 IP주소가 할당된다.
• 프록시 정보를 입력한다. 프록시 없이 연결 가능한 환경에서는 주소를 비워두고 'Done'을 선택한다.

5) 패키지 저장소 설정

• 우분투 패키지를 받아올 저장소 주소를 선택한다. 기본적으로 설정되어있는데, 아래 국내 사이트를 이용하면 속도가 더 빠르다는 장점이 있다.
  • 카카오 : http://mirror.kakao.com/
  • 카이스트 : http://ftp.kaist.ac.kr/

6) Storage 설정

• storage를 설정한다. 기본값으로 진행하였다.

7) 시스템 정보 입력

• Ubuntu 로그인할 때 사용하는 정보로 서버 이름 및 비밀번호 설정한다.
• Upgrage관련해서는 Skip for now를 선택한다.

8) SSH 설정

• OpenSSH 서버 패키지를 설치할 지 결정한다. 이 때 OpenSSH 서버를 설치하면 우분투 서버 설치가 끝난 직후 콘솔 로그인 대신 원격 접속이 가능하다. 서버 설치 이후에도 설치할 수 있다.

9) 설치할 패키지 선택

• 우분투 서버는 서버 서비스에 꼭 필요한 패키지만 제공한다. 추가적으로 필요한 패키지가 있는 경우 선택한다. 불필요한 도구는 되도록 설치하지 않는 편이 보안 유지를 위해 바람직하다는 점을 참고하자.

10) 설치 종료

• 설치가 종료되면 선택 화면이 보인다. 'Reboot Now'를 선택하여 재기동한다.

우분투 서버 기본 설정

ip 설정 확인

ip a 명령어로 네트워크 인터페이스 enp1s0의 inet 항목에서 받아온 IP주소를 확인할 수 있다. 주소 정보는 사용자별로 다를 수 있다.

언어 설정 확인

locale 명령어로 en_US.UTF-8로 잘 설정되었는지 확인한다.

혹시 로케일 설정이 잘못되었다면 sudo dpkg-reconfigure locales 명령어로 재설정할 수 있다.

시간대 설정

서버 설치 과정에서 시간대 선택이 생략되었으므로 설치후 반드시 시간대 설정을 변경해야한다.

1) date 명령어로 현재 서버 시간대 확인

국제 표준 협정시계시(UTC)로 설정되어있음을 확인할 수 있다.

2) timedatectl set-timezone 명령으로 시간대 변경

우리나라에 해당하는 'Asia/Seoul'로 입력한다.

• VMware 설치 주소 : https://www.vmware.com/products/desktop-hypervisor/workstation-and-fusion

• Ubuntu 설치 주소 : https://ubuntu.com/download/desktop
• Ubuntu 설치 버전 : 24.04.2 LTS
• Ubuntu 설치 환경
  • VMware Workstation 16 Player

테스트와 실습 위주로 진행할 예정이고, 이후 원활한 화면 캡처를 위해 VMware에서 사용을 위해 VMware에 설치를 진행한다. VMware가 이미 설치되었다는 전제 하에 Ubuntu 설치과정만 포스팅하였다.

VMware에 Ubuntu24.04 설치

1. VMware 실행 및 가상머신 생성 선택

Create a New Virtual Machine 을 선택한다.

2. 하드웨어 용량 확인 및 사용자 설정

1) 설치 할 iso 이미지 선택

• Installer disc image file 을 선택한 후 Browse를 클릭하여 내려받은 Ubuntu iso 파일을 선택한다.
• Next 를 클릭하여 다음 단계로 이동한다.

2) 사용자 정보 세팅

사용자 명, 패스워드를 설정 한 후 Next 버튼을 클릭한다.

3) 서버 명 설정

VMware에 표기 될 서버 명과 설치 위치를 설정한다.

4) 저장공간 크기 설정

5) 설정 정보 확인 및 설치

설정된 정보가 맞는지 확인 후 Finish를 클릭하면 가상머신 환경이 구축된다.

3. Ubuntu Server 실행

설치가 완료되면 자동으로 Ubuntu가 실행된다. 자동실행 되지 않는 경우 메인화면에서 Ubuntu를 선택하여 실행하면 된다.

1) Try or install Ubuntu Server 선택 및 언어 선택

• 한국어 미지원이므로 영어 선택 후 엔터를 누른다.

2) 설치도구 업데이트 및 키보드 설정

• 인터넷이 연결된 경우 설치도구 업데이트 여부를 선택할 수 있다. 필자는 업데이트 없이 설치를 진행한다.
• 키보드 배열을 선택한다. Layout, Variant 모두 기본값인 'English (US)' 선택 후 'Done'을 선택한다.

3) 키보드 설정

• 사용중인 키보드 유형을 설정한다.

4) 와이파이 설정

5) 우분투 설치

6) 세부 설정

7) 세부 설정할 항목 선택

기본 사양으로 선택하여 설정한다.

8) 추가 프로그램 설정

모두 선택한다.

9) 설치 방법 선택

디스크 지우고 우분투 설치를 선택한다. 듀얼부팅과 달리 가상환경이므로 이 방법을 선택해도 안전하다.

10) 계정 정보 설정

11) 시간대 설정

서울로 설정한다. 기본적으로 자동 서울 설정이 된다.

12) 시스템 재시작

설치 완료 시 시스템을 재시작한다.

• Ubuntu 설치 주소 : https://ubuntu.com/download/desktop

• Ubuntu 설치 버전 : 24.04.2 LTS
• Ubuntu 설치 환경
  • OS : Window10
  • CPU : 2GHz 듀얼코어 프로세서
  • RAM : 8GB

지난 포스팅에 이어 우분투OS를 설치한다. 설치를 위한 사전 작업은 지난 포스팅을 참고하면 된다.

4. 우분투OS 설치

1) BIOS 부팅 순서 변경

우분투OS 설치용 USB를 연결하고 컴퓨터를 재부팅하여 BIOS/UEFI 설정도구로 진입한다. 재부팅 시 로고 출력될 때 BIOS 진입 키를 연타하면 설정 페이지로 진입할 수 있다.

메인보드 제조사별 상세 BIOS 진입키

• HP 메인보드: F10
• ASRock 메인보드: F2 or DEL
• ASUS 메인보드: F2 or DEL
• Intel 메인보드: DEL
• ECS(ELITEGROUP) 메인보드: DEL
• SONY 메인보드: F2
• LG, TG삼보, DELL 메인보드: F2 or DEL
• Lenovo 메인보드: F1 (데스크탑), F2(노트북)
• GIGABYTE 메인보드: F2 or DEL
• Acer, Samsung 메인보드: F2 or DEL

제조사별로 방법이 다르나, 부팅 순서(boot order, boot sequence), 부팅 옵션(boot option), 부팅 우선순위(boot priority)와 같은 부팅 관련 메뉴를 찾아 USB를 가장 먼저 부팅하도록 변경한다. 부팅 순서를 바꾸었으면 변경한 내용을 저장하고 설정 도구를 종료 및 재부팅한다.

📌나중에 우분투 설치 끝난 이후에 USB를 제거하고 부팅 순서를 우분투가 설치된 저장 장치로 변경하여 부팅해야한다.

2) 우분투 설치

• Install Ubuntu 선택
• 타 소프트웨어 설치 선택 인터넷이 연결되어 있고 엔비디아 지포스 그래픽 카드가 설치되어 있다면, Other Option 항목들을 모두 설치해주면 편하다.
• 설치 형식에서 기타를 선택한다.
• 앞 포스팅에서 우분투 설치를 위해 비워둔 미할당 영역에 우분투를 설치한다.
  • 남은 공간 클릭
  • 좌측 하단의 + 버튼 클릭
  • 파티션 종류 논리 파티션 선택
  • 파티션 위치 이 공간이 시작하는 지점
  • 용도 EXT4 저널링 파일 시스템
  • 마운트 위치 / 로 설정
  • OK 버튼 클릭
• 지금 설치 클릭하여 설치 진행 📌 바뀐 점을 디스크에 쓰시겠습니까 라는 경고 창이 뜨면 계속 버튼을 눌러 진행한다.
• 지역 설정 : 서울
• 로그인 계정 및 암호 설정 📌 우분투os로 부팅 시에 자동으로 바탕화면까지 진입하게 하려면,
• 자동으로 로그인* 을 체크, 로그인 암호를 쳐야 바탕화면까지 진입하게 하려면, 로그인할 때 암호 입력 을 체크한다.
• 설치 완료 시 지금 재시작 선택
• 듀얼 부팅 선택 검은 화면에서 부팅 할 OS를 선택할 수 있다. Ubuntu로 실행 할 경우 Ubuntu를 선택하거나 10초이상 그대로 놓아두면 자동으로 Ubuntu로 실행된다. Window로 실행 할 경우 하단의 Window Boot Manager를 선택하면 Window로 실행된다.

• Ubuntu 설치 주소 : https://ubuntu.com/download/desktop

• Ubuntu 설치 버전 : 24.04.2 LTS
• Ubuntu 설치 환경
  • OS : Window10
  • CPU : 2GHz 듀얼코어 프로세서
  • RAM : 8GB

윈도우 PC에 Ubuntu24.04 듀얼부팅 설치

1. 우분투 iso 이미지 다운로드

https://ubuntu.com/download/desktop 에서 download버튼을 클릭하여 iso 이미지를 내려받는다.

2. 우분투 설치(부팅) usb 디스크 만들기

과거에는 내려받은 iso를 CD나 DVD로 옮겨야 했으나, 현재는 USB에서 실행하게 할 수 있다. 우분투로 부팅 가능한 USB 저장 장치를 만들어보자.

1) 루퍼스(Rufus) 설치

https://rufus.ie/ko/ 에서 사양에 맞는 파일을 선택하여 내려받는다. 표준은 설치 방식이고 포터블은 무설치 방식으로 동작한다. 둘 다 작동상의 차이는 없으니 어떤 것을 받던 무방하다. 필자는 포터블 방식으로 받았다.

2) USB 설정

• OS 설치를 위해 빈 usb를 PC에 연결한다.
• 내려받은 Rufus 프로그램을 실행한다.
• 프로그램에서 usb에 세팅할 부팅 디스크 속성을 설정한다.
  • 장치에서 연결한 usb를 선택한다.
  • 부팅 선택 란에서 선택 버튼을 클릭하여 내려받은 우분투 데스크톱 iso 이미지를 선택한다.
  • 파티션 방식을 GPT로 선택한다.
  • 시작 버튼을 클릭한다.

📌유의사항 : 설치 환경의 펌웨어가 BIOS라면 파티션 방식을 MBR로 선택해야 한다. 파티션 방식을 잘못 선택하면 USB 저장 장치로 부팅할 수 없으며, 다시 루퍼스로 우분투 설치 매체를 생성해야 한다.

3) ISO 이미지 모드로 쓰기 선택 및 OK 버튼 클릭

4) 설치 시작

설치가 시작되면 USB 저장 장치의 모든 자료가 삭제된다. 설치 완료 시 닫기 버튼을 클릭한다.

5) USB에 복사된 파일 확인

3. 우분투 설치 공간 마련 (파티션 조정)

윈도우 디스크 관리 도구로 새로운 파티션을 생성하여 우분투 OS가 설치될 공간을 마련해보자.

1) 디스크 관리 도구 접근

2) 볼륨 축소

줄이려는 볼륨(보통 C: 또는 주 파티션으로 가장 용량이 많은 파티션)을 마우스 우클릭 한 뒤, 볼륨 축소를 클릭한다. 지금 할당하는 공간에 우분투OS가 설치되고 우분투 환경의 저장공간으로 활용된다. 사용할 공간 만큼 축소한다. 다음과 같이 할당되지 않은 공간이 생긴다.

우분투 설치를 위한 사전작업은 모두 완료되었다. 다음 포스팅에서는 실제 설치를 진행해보자.

SerialDate는 날짜를 표현하는 자바 클래스이다. 하지만 자바는 이미 java.util.Date, java.util.Calendar와 같은 클래스를 제공하는데, 왜 하필 SerialDate를 써야할까?

첫째, 돌려보자

클린코드 교재의 473쪽 B-2의 코드를 참고하고 진행한다. 우선, 클로버(코드커버리지 분석도구)를 통해 SerialDateTests 클래스를 검사한다. 검사결과 이 클래스는 50%정도만 테스트를 진행하고 있다는 사실을 확인할 수 있다. 따라서 더 높은 코드 커버리지를 위해 단위 테스트 케이스를 구현하고, 해당 단위 테스트에서 실패한 경우(주석 처리한 부분)를 성공시킬 수 있도록 원본 클래스를 리팩터링한다.

• 23~63행 주석부분 통과하도록 수정
  • SerialDate 설계 상 불통이 옳으나, 저자 기준 통과해야 함
  • 대소문자 구분 없이 모두 통과해야할 것으로 추정

  • 259행, 263행 equalsIgnoreCase로 변경

• 32행, 45행 주석 유지
  • 'tues', 'thurs' 약어 지원 여부 불분명
• 153~154행 불통 -> 통과해야함
• 163~213행 stringToMonthCode 메서드 수정

  if  ((result < 1) || result > 12) {
    result = -1;
    for (int i = 0; i < maonthNames.length; i++) {
        if (s.equalsIgnoreCase(shortMonthNames[i])) {
            result = i + 1;
            break;
        }
        if (s.equalsIgnoreCase(monthNames[i])) {
            result = i + 1;
            break;
        }
    }
  }

• 318행 : 672행의 getFollowingDayOfWeek 메서드 버그 표시됨
  • 메서드 버그 수정 if(baserDOW >= targetWeekday) {
• 719행 실행 오류 : 718행 if문 항상 거짓으로 처리됨
  • 버그 수정

    int delta = targetDOW = base.getDayOfWeek();
    int positiveDelta = delta + 7;
    int adjust = positiveDelta % 7;
    if (adjust > 3)
        adjust -= 7;
    return SerialDate.addDays(adjust, base);

• 417행, 429행 : weekInMonthToString, relativeToString 오류 문자열 대신 IllegalArgumentException으로 테스트 통과 처리

둘째, 고쳐보자

위와 같이 변경한 SerialDate는 모든 테스트 케이스를 통과한다. 이제 SerialDate를 올바로 고쳐보자. 코드 변경 시 마다 JCommon 단위테스트와 자체 단위테스트를 모두 실행하였다.

• 초반 선언부 주석은 너무 오래되었다. 법적 정보()만 남겨두고 나머지는 제거한다.
• enum을 모두 독자적인 소스 파일로 이동.
• 정적 변수(dateFormatSymbols)와 정적 메서드(getMonthNames, isLeapYear, lastDayOfMonth)는 새 클래스로 이동
• 일부 추상 메서드는 DayDate.java로 이동
• Month.make를 Month.fromInt로 변경. 다른 enum도 똑같이 변경하고 모든 enum에 toInt() 접근자를 생성, index 필드를 private로 정의.
• plusYears와 plusMonths의 중복을 correctLastDayOfMonth라는 새 메서드를 통해 제거
• 사용하던 숫자 1 대신 모두 Month.JANUARY.toInt() 혹은 Day.SUNDAY.toInt()로 적절히 변경. SpreadsheetDate 코드를 살펴보고 알고리즘을 조금 손봤다.

결론

위 처럼 수정 결과, DayDate 코드 커버리지는 84.9%로 감소하였다. 테스트하는 코드가 줄어서가 아니라 클래스 크기가 작아지는 바람에 테스트하지 않는 코드의 비중이 커졌기 때문이다. 테스트하지 않는 코드는 너무 사소해 테스트할 필요도 없는 코드만 남았다.

JUnit 프레임워크

JUnit의 다양한 모듈 중 ComparisonCompactor 모듈을 살펴보자. 문자열 비교 오류를 파악할 때 유용하다. ABCDE와 ABXDE를 받아 <...B[X]D...> 를 반환한다.

테스트 케이스

package junit.tests.framework;

import junit.framework.ComparisonCompactor;
import junit.framework.TestCase;

public class ComparisonCompactorTest extends TestCase {

    public void testMessage() {
        String failure = new ComparisonCompactor(0, "b", "c").compact("a");
        assertTrue("a expected:<[b]> but was:<[c]>".equals(failure));
    }

    public void testStartSame() {
        String failure = new ComparisonCompactor(1, "ba", "bc").compact(null);
        assertEquals("expected:<b[a]> but was:<b[c]>", failure);
    }

    public void testEndSame() {
        String failure = new ComparisonCompactor(1, "ab", "cb").compact(null);
        assertEquals("expected:<[a]b> but was:<[c]b>", failure);
    }

    public void testSame() {
        String failure = new ComparisonCompactor(1, "ab", "ab").compact(null);
        assertEquals("expected:<ab> but was:<ab>", failure);
    }

    public void testNoContextStartAndEndSame() {
        String failure = new ComparisonCompactor(0, "abc", "adc").compact(null);
        assertEquals("expected:<...[b]...> but was:<...[d]...>", failure);
    }

    public void testStartAndEndContext() {
        String failure = new ComparisonCompactor(1, "abc", "adc").compact(null);
        assertEquals("expected:<a[b]c> but was:<a[d]c>", failure);
    }

    public void testStartAndEndContextWithEllipses() {
        String failure = new ComparisonCompactor(1, "abcde", "abfde").compact(null);
        assertEquals("expected:<...b[c]d...> but was:<...b[f]d...>", failure);
    }

    public void testComparisonErrorStartSameComplete() {
        String failure = new ComparisonCompactor(2, "ab", "abc").compact(null);
        assertEquals("expected:<ab[]> but was:<ab[c]>", failure);
    }

    public void testComparisonErrorEndSameComplete() {
        String failure = new ComparisonCompactor(0, "bc", "abc").compact(null);
        assertEquals("expected:<[]...> but was:<[a]...>", failure);
    }

    public void testComparisonErrorEndSameCompleteContext() {
        String failure = new ComparisonCompactor(2, "bc", "abc").compact(null);
        assertEquals("expected:<[]bc> but was:<[a]bc>", failure);
    }

    public void testComparisonErrorOverlappingMatches() {
        String failure = new ComparisonCompactor(0, "abc", "abbc").compact(null);
        assertEquals("expected:<...[]...> but was:<...[b]...>", failure);
    }

    public void testComparisonErrorOverlappingMatchesContext() {
        String failure = new ComparisonCompactor(2, "abc", "abbc").compact(null);
        assertEquals("expected:<ab[]c> but was:<ab[b]c>", failure);
    }

    public void testComparisonErrorOverlappingMatches2() {
        String failure = new ComparisonCompactor(0, "abcdde", "abcde").compact(null);
        assertEquals("expected:<...[d]...> but was:<...[]...>", failure);
    }

    public void testComparisonErrorOverlappingMatches2Context() {
        String failure = new ComparisonCompactor(2, "abcdde", "abcde").compact(null);
        assertEquals("expected:<...cd[d]e> but was:<...cd[]e>", failure);
    }

    public void testComparisonErrorWithActualNull() {
        String failure = new ComparisonCompactor(0, "a", null).compact(null);
        assertEquals("expected:<a> but was:<null>", failure);
    }

    public void testComparisonErrorWithActualNullContext() {
        String failure = new ComparisonCompactor(2, "a", null).compact(null);
        assertEquals("expected:<a> but was:<null>", failure);
    }

    public void testComparisonErrorWithExpectedNull() {
        String failure = new ComparisonCompactor(0, null, "a").compact(null);
        assertEquals("expected:<null> but was:<a>", failure);
    }

    public void testComparisonErrorWithExpectedNullContext() {
        String failure = new ComparisonCompactor(2, null, "a").compact(null);
        assertEquals("expected:<null> but was:<a>", failure);
    }

    public void testBug609972() {
        String failure = new ComparisonCompactor(10, "S&P500", "0").compact(null);
        assertEquals("expected:<[S&P50]0> but was:<[]0>", failure);
    }
}

위와 같은 방식으로 테스트 케이스를 작성하여 ComparisonCompactor 모듈에 대한 코드 커버리지 분석을 수행하여 테스트케이스가 모든 행, 모든 if문, 모든 for문을 실행할 수 있도록 하였다.

ComparisonCompactor.java 원본

public class ComparisonCompactor {

    private static final String ELLIPSIS = "...";
    private static final String DELTA_END = "]";
    private static final String DELTA_START = "[";

    private int fContextLength;
    private String fExpected;
    private String fActual;
    private int fPrefix;
    private int fSuffix;

    public ComparisonCompactor(int contextLength, String expected, String actual) {
        fContextLength = contextLength;
        fExpected = expected;
        fActual = actual;
    }

    public String compact(String message) {
        if (fExpected == null || fActual == null || areStringsEqual()) {
            return Assert.format(message, fExpected, fActual);
        }

        findCommonPrefix();
        findCommonSuffix();
        String expected = compactString(fExpected);
        String actual = compactString(fActual);
        return Assert.format(message, expected, actual);
    }

    private String compactString(String source) {
        String result = DELTA_START + source.substring(fPrefix, source.length() - fSuffix + 1) + DELTA_END;
        if (fPrefix > 0) {
            result = computeCommonPrefix() + result;
        }
        if (fSuffix > 0) {
            result = result + computeCommonSuffix();
        }
        return result;
    }

    private void findCommonPrefix() {
        fPrefix = 0;
        int end = Math.min(fExpected.length(), fActual.length());
        for (; fPrefix < end; fPrefix++) {
            if (fExpected.charAt(fPrefix) != fActual.charAt(fPrefix)) {
                break;
            }
        }
    }

    private void findCommonSuffix() {
        int expectedSuffix = fExpected.length() - 1;
        int actualSuffix = fActual.length() - 1;
        for (; actualSuffix >= fPrefix && expectedSuffix >= fPrefix; actualSuffix--, expectedSuffix--) {
            if (fExpected.charAt(expectedSuffix) != fActual.charAt(actualSuffix)) {
                break;
            }
        }
        fSuffix = fExpected.length() - expectedSuffix;
    }

    private String computeCommonPrefix() {
        return (fPrefix > fContextLength ? ELLIPSIS : "") + fExpected.substring(Math.max(0, fPrefix - fContextLength), fPrefix);
    }

    private String computeCommonSuffix() {
        int end = Math.min(fExpected.length() - fSuffix + 1 + fContextLength, fExpected.length());
        return fExpected.substring(fExpected.length() - fSuffix + 1, end) + (fExpected.length() - fSuffix + 1 < fExpected.length() - fContextLength ? ELLIPSIS : "");
    }

    private boolean areStringsEqual() {
        return fExpected.equals(fActual);
    }
}

ComparisonCompactor.java 리팩터링

저자들이 아주 좋은 상태로 모듈을 남겨 두었지만 우리는 보이스카우트 규칙에 따라 처음 왔을 때 보다 더 깨끗하게 해 놓고 떠나야한다. 개선 방법들은 다음과 같다.

접두어 f 제거[N6]

가장 먼저 거슬리는 부분은 멤버 변수 앞에 붙인 접두어 f다. 오늘날 사용하는 개발 환경에서는 이처럼 변수 이름에 범위를 명시할 필요가 없다.

private int contextLength;
private String expected;
private String actual;
private int prefix;
private int suffix;

조건문 캡슐화[G28]

compact 함수 시작부에 캡슐화되지 않은 조건문이 있다. 의도를 명확히 표현하려면 조건문을 메서드로 뽑아내 적절한 이름을 붙여 캡슐화해야 한다.

//개선 전
public String compact(String message) {
    if (expected == null || actual == null || areStringsEqual()) {
        return Assert.format(message, expected, actual);
    }

    findCommonPrefix();
    findCommonSuffix();
    String expected = compactString(this.expected);
    String actual = compactString(this.actual);
    return Assert.format(message, expected, actual);
}

//개선 후
public String compact(String message) {
    if (shouldNotCompact()) {
        return Assert.format(message, expected, actual);
    }

    findCommonPrefix();
    findCommonSuffix();
    String expected = compactString(this.expected);
    String actual = compactString(this.actual);
    return Assert.format(message, expected, actual);
}

private boolean shouldNotCompact() {
    return expected == null || actual == null || areStringsEqual();
}

명확한 이름 사용[N4]

함수에 이미 expected라는 지역 변수가 있는데 fExpected에서 f를 빼버리는 바람에 this.expected라는 식으로 사용하게 되었다. 멤버변수와 이름이 같은 변수를 사용할 이유가 없다.

String compactExpected = compactString(expected);
String compactActual = compactString(actual);

부정 조건 미사용[G29]

부정문은 긍정문보다 이해하기 약간 더 어렵다. 그러므로 첫 문장 if를 긍정으로 만들어 조건문을 반전한다.

public String compact(String message) {
    if (canBeCompacted()) {
        findCommonPrefix();
        findCommonSuffix();
        String compactExpected = compactString(expected);
        String compactActual = compactString(actual);
        return Assert.format(message, compactExpected, compactActual);
    } else {
        return Assert.format(message, expected, actual);
    }
}

private boolean canBeCompacted() {
    return expected != null && actual != null && !areStringsEqual();
}

이름으로 부수 효과 설명[N7]

문자열을 압축하는 함수라지만 실제로 canBeCompacted가 false이면 압축하지 않는다. 그리고 단순한 압축 문자열이 아닌 형식이 갖춰진 문자열을 반환한다. 인수를 고려하면 가독성이 훨씬 좋아진다.

public String formatCompactedComparison(String message) {

함수는 한 가지 업무만 수행[G30]

if 문 안에서 예상 문자열과 실제 문자열을 진짜로 압축한다. 이 부분을 분리하여 형식을 맞추는 작업은 formatCompactedComparison, 압축은 compacteExpectedAndActual이 수행하도록 변경한다.

...

private String compactExpected;
private String compactActual;

...

public String formatCompactedComparison(String message) {
    if (canBeCompacted()) {
        compactExpectedAndActual();
        return Assert.format(message, compactExpected, compactActual);
    } else {
        return Assert.format(message, expected, actual);
    }       
}

private compactExpectedAndActual() {
    findCommonPrefix();
    findCommonSuffix();
    compactExpected = compactString(expected);
    compactActual = compactString(actual);
}

일관적 함수 사용[G11]

새 함수에서 마지막 두 줄은 변수를 반환하지만 첫째 줄과 둘째 줄은 반환값이 없다. 함수 사용 방식이 일관적이지 못하므로 findCommonPrefix와 findCommonSuffix를 변경해 접두어 값과 접미어 값을 반환한다.

    prefixIndex = findCommonPrefix();
    suffixIndex = findCommonSuffix();
    String compactExpected = compactString(expected);
    String compactActual = compactString(actual);
}

private int findCommonPrefix() {
    int prefixIndex = 0;
    int end = Math.min(expected.length(), actual.length());
    for (; prefixIndex < end; prefixIndex++) {
        if (expected.charAt(prefixIndex) != actual.charAt(prefixIndex)) {
            break;
        }
    }
    return prefixIndex;
}

private int findCommonSuffix() {
    int expectedSuffix = expected.length() - 1;
    int actualSuffix = actual.length() - 1;
    for (; actualSuffix >= prefixIndex && expectedSuffix >= prefix; actualSuffix--, expectedSuffix--) {
        if (expected.charAt(expectedSuffix) != actual.charAt(actualSuffix)) {
            break;
        }
    }
    return expected.length() - expectedSuffix;
}

정확한 이름 사용[N1]

변수가 하는 일과 관련되는 정확한 이름으로 다시 명명한다.

private int prefixIndex;
private int suffixIndex;

숨겨진 시각적인 결합 없애기[G31][G32]

공통되는 문자열을 앞에서부터 찾은 다음 뒤에서부터 찾도록 만들어져 있지만 호출자가 알기 어렵다. 따라서 다음과 같이 내용을 수정한다.

• findCommonPrefix 호출
• findCommonSuffix 호출하는 메소드 생성
• findCommonSuffixAndSuffix();

  private void findCommonPrefixAndSuffix() {
    findCommonPrefix();
    int suffixLength = 1;
    for (; suffixOverlapsPrefix(suffixLength); suffixLength++) {
        if (charFromEnd(expected, suffixLength) != charFromEnd(actual, suffixLength)) {
            break;
        }
    }
    suffixIndex = suffixLength;
  }
  

private char charFromEnd(String s, int i) { return s.charAt(s.length() - i); }

private boolean suffixOverlapsPrefix(int suffixLength) { return actual.length() = suffixLength < prefixLength || expected.length() - suffixLength < prefixLength; }

#### 정확한 이름 사용[G33]
변수가 하는 일과 관련되는 정확한 이름으로 다시 명명한다.
```java
private int suffixLength;

중간 점검

public class ComparisonCompactor {
    ...
    private int suffixLength;
    ...

    private void findCommonPrefixAndSuffix() {
        findCommonPrefix();
        suffixLength = 0;
        for (; suffixOverlapsPrefix(suffixLength); suffixLength++) {
            if (charFromEnd(expected, suffixLength) != charFromEnd(actual, suffixLength)) {
                break;
            }
        }
    }

    private char charFromEnd(String s, int i) {
        return s.charAt(s.length() - i - 1);
    }

    private boolean suffixOverlapsPrefix(int suffixLength) {
        return actual.length() = suffixLength <= prefixLength || expected.length() - suffixLength <= prefixLength;
    }

    ...
    private String compactString(String source) {
        String result = DELTA_START + source.substring(prefixLength, source.length() - suffixLength) + DELTA_END;
        if (prefixLength > 0) {
            result = computeCommonPrefix() + result;
        }
        if (suffixLength > 0) {
            result = result + computeCommonSuffix();
        }
        return result;
    }

    ...
    private String computeCommonSuffix() {
        int end = Math.min(expected.length() - suffixLength + contextLength, expected.length());
        return expected.substring(expected.length() - suffixLength, end) + (expected.length() - suffixLength < expected.length() - contextLength ? ELLIPSIS : "");
    }
}

불필요한 코드 제거[G9]

불필요한 if문들을 제거하고, compactString 구조를 다듬어 좀 더 깔끔하게 만든다.

private String compactString(String source) {
        return computeCommonPrefix() + DELTA_START +  source.substring(prefixLength, source.length() - suffixLength) + DELTA_END + computeCommonSuffix();
}

ComparisonCompactor.java 최종본

모듈은 일련의 분석 함수와 일련의 조합 함수로 나뉘고, 전체 함수는 위상적으로 정렬했으므로 각 함수가 사용된 직후에 정의된다. 분석 함수가 먼저 나오고 조합 함수가 그 뒤를 이어서 나온다.

public class ComparisonCompactor {

    private static final String ELLIPSIS = "...";
    private static final String DELTA_END = "]";
    private static final String DELTA_START = "[";

    private int contextLength;
    private String expected;
    private String actual;
    private int prefixLength;
    private int suffixLength;

    public ComparisonCompactor(int contextLength, String expected, String actual) {
        this.contextLength = contextLength;
        this.expected = expected;
        this.actual = actual;
    }

    public String formatCompactedComparison(String message) {
        String compactExpected = expected;
        String compactactual = actual;
        if (shouldBeCompacted()) {
            findCommonPrefixAndSuffix();
            compactExpected = comapct(expected);
            compactActual = comapct(actual);
        }         
        return Assert.format(message, compactExpected, compactActual);      
    }

    private boolean shouldBeCompacted() {
        return !shouldNotBeCompacted();
    }

    private boolean shouldNotBeCompacted() {
        return expected == null && actual == null && expected.equals(actual);
    }

    private void findCommonPrefixAndSuffix() {
        findCommonPrefix();
        suffixLength = 0;
        for (; suffixOverlapsPrefix(suffixLength); suffixLength++) {
            if (charFromEnd(expected, suffixLength) != charFromEnd(actual, suffixLength)) {
                break;
            }
        }
    }

    private boolean suffixOverlapsPrefix(int suffixLength) {
        return actual.length() = suffixLength <= prefixLength || expected.length() - suffixLength <= prefixLength;
    }

    private void findCommonPrefix() {
        int prefixIndex = 0;
        int end = Math.min(expected.length(), actual.length());
        for (; prefixLength < end; prefixLength++) {
            if (expected.charAt(prefixLength) != actual.charAt(prefixLength)) {
                break;
            }
        }
    }

    private String compact(String s) {
        return new StringBuilder()
            .append(startingEllipsis())
            .append(startingContext())
            .append(DELTA_START)
            .append(delta(s))
            .append(DELTA_END)
            .append(endingContext())
            .append(endingEllipsis())
            .toString();
    }

    private String startingEllipsis() {
        prefixIndex > contextLength ? ELLIPSIS : ""
    }

    private String startingContext() {
        int contextStart = Math.max(0, prefixLength = contextLength);
        int contextEnd = prefixLength;
        return expected.substring(contextStart, contextEnd);
    }

    private String delta(String s) {
        int deltaStart = prefixLength;
        int deltaend = s.length() = suffixLength;
        return s.substring(deltaStart, deltaEnd);
    }

    private String endingContext() {
        int contextStart = expected.length() = suffixLength;
        int contextEnd = Math.min(contextStart + contextLength, expected.length());
        return expected.substring(contextStart, contextEnd);
    }

    private String endingEllipsis() {
        return (suffixLength > contextLength ? ELLIPSIS : "");
    }
}

결론

저자들은 우수한 모듈을 만들었다. 하지만 세상에 개선이 불필요한 모듈은 없다. 코드를 처음보다 조금 더 깨끗하게 만드는 책임은 우리 모두에게 있다.

간단한 Args 사용법

Args 클래스는 (형식 또는 스키마 지정, 명령행 인수 배열) 형태로 선언한다.

• 명령행 인수 정의 : 부울인수 l / 정수인수 p / 문자열인수 d

  public static void main(String[] args) {
    try {
        Args arg = new Args("l,p#,d*", args);
        boolean logging = arg.getBoolean('l');
        int port = arg.getInt('p');
        String directory = arg.getString('d');
        executeApplication(logging, port, directory);
  
    } catch(ArgsException e) {
        System.out.printf("Argument error: %s\n", e.errorMessage());
    }
  }

  
  

Args: 1차 초안

돌아는 가지만, 상당히 길고 복잡하다. 인수 유형이 늘어날수록 코드가 지저분해지고 복잡해진다.

public class Args {
    private String schema;
    private String[] args;
    private boolean valid = true;
    private Set<Character> unexpectedArguments = new TreeSet<Character>();
    private Map<Character, Boolean> booleanArgs = new HashMap<Character, Boolean>();
    private int numberOfArguments = 0;

    public Args(String schema, String[] args) throws ParseException {
        this.schema = schema;
        this.args = args;
        valid = parse();
    }

    public boolean isValid() {
        return valid;
    }

    private boolean parse() throws ParseException {
        if(schema.length() == 0 && args.length == 0)
            return true;
        parseSchema();
        parseArguments();
        return unexpectedArguments.size() == 0;
    }

    private boolean parseSchema() throws ParseException {
        for(String element : schema.split(",")) {
            parseSchemaElement(element);
        }
        return true;
    }

    private void parseSchemaElement(String element) throws ParseException {
        if(element.length() == 1) {
            parseBooleanSchemaElement(element);
        }
    }

    private void parseBooleanSchemaElement(char elementId) {
        char c = element.charAt(0);
        if(Character.isLetter(c)) {
            booleanArgs.put(c, false);
        }
    }

    private boolean parseArguments() {
        for (String arg : args) {
            parseArgument(arg);
        }
        return true;
    }

    private void parseArgument(String arg) {
        if(arg.startsWith("-"))
            parseElements(arg);
    }

    private void parseElements(String arg) {
        for(ing i = 1; i < arg.length(); i++)
            parseElement(arg.charAt(i));
    }

    private void parseElement(char argChar) {
        if(isBoolean(argChar)) {
            numberOfArguments++;
            setBooleanArg(argChar, true);
        } else
            unexpectedArguments.add(argChar);
    }

    private void setBooleanArg(char argChar, boolean value) {
        booleanArgs.put(argChar, value);
    }

    private boolean isBoolean(char argChar) {
        return booleanArgs.containKey(argChar);
    }

    public int cardinality() {
        return numberOfArguments;
    }

    public String usage() {
        if(schema.length)( > 0)
            return "-["+schema+"]";
        else
            return "";
    }

    public String errorMessage() {
        if(unexpectedArguments.size() > 0) {
            return unexpectedArgumentMessage();
        } else
            return "";
    }

    private String unexpectedArgumentMessage() {
        StringBuffer message = new StringBuffer("Argument(s) -");
        for (char c : unexpectedArguments) {
            message.append(c);
        }
        message.append(" unexpected.");

        return message.toString();
    }

    public boolean getBoolean(char arg) {
        return booleanArgs.get(arg);
    }

}

위 코드는 크게 세 가지 기능을 제공한다.

• 인수 유형에 해당하는 HashMap을 선택하기 위해 스키마 요소의 구문 분석
• 명령행 인수에서 인수 유형을 분석해 진짜 유형으로 변환
• getXXX 메서드를 구현해 호출자에게 진짜 유형을 반환

인수 유형은 다양하지만 모두 유사한 메서드를 제공하므로 한 클래스에 담는것이 적합하다. 그래서 ArgumentMarshaler를 생성하였다.

점진적 개선

• 기존 코드에 ArgumentMarshaler 클래스 골격 추가

  private class ArgumentMarshaler {
    private boolean booleanVlaue = false;
  
    public void setBoolean(boolean value) {
        booleanVlaue = value;
    }
  
    public boolean getBoolean() {return booleanValue;}
  }
  

private class BooleanArgumentMarshaler extends ArgumentMarshaler { }

private class StringArgumentMarshaler extends ArgumentMarshaler { }

private class IntegerArgumentMarshaler extends ArgumentMarshaler { }

* 구체적으로 인수를 저장하는 HashMap에서 Boolean -> ArgumentMarshaler로 인수 유형 변경
```java
private Map<Character, ArgumentMarshaler> booleanArgs = new HashMap<Character, ArgumentMarshaler>();

• 깨지는 코드 수정

  ...
    private void parseBooleanSchemaElement(char elementId) {
        booleanArgs.put(elementId, new BooleanArgumentMarshaler());
    }
  ..
    private void setBooleanArg(char argChar, boolean value) {
        booleanArgs.get(argChar).setBoolean(value);
    }
  ...
    private boolean getBoolean(char arg) {
        return falseIfNumm(booleanArgs.get(arg).getBoolean());
    }

• 테스트 케이스 가동 및 오류 수정

    public boolean getBoolean(char arg) {
        Args.ArgumentMarshaler am = booleanArgs.get(arg);
        return am != null && am.getBoolean();
    }

• 같은 방법으로 String, int 등 인수 유형 추가 (모든 논리를 ArgumentMarshaler로 이동)
• 파생 클래스 생성으로 기능 분산

추상 메서드 화

• setBoolean 함수 BooleanArgumentMarshaler로 옮긴 후 정상 호출 확인

• ArgumentMarshaler 클래스에 추상 메서드 set 생성

  private abstract class ArgumentMarshaler {
    protected boolean booleanValue = false;
    private String stringValue;
    private int integerValue;
  
    public void setBoolean(boolean value) {
        booleanValue = value;
    }
  
    public boolean getBoolean() {
        return booleanValue;
    }
  
    public abstract void set(String s);
  }

  추상 set 함수는 String 인수를 받아들이나 BooleanArgumentMarshaler는 인수를 사용하지 않는다. 여기서 인수를 정의한 이유는 StringArgumentMarshaler와 IntegerArgumentMarshaler에서 필요하기 때문이다.

• BooleanArgumentMarshaler 클래스에 set 메서드 구현

  private class BooleanArgumentMarshaler extends ArgumentMarshaler {
    public void set(String s) {
        booleanValue = true;
    }
  }

• setBoolean 호출을 set 호출로 변경

  private void setBooleanArg(char argChar, boolean value) {
    booleanArgs.get(argChar).set("true");
  }

• ArgumentMarshaler에서 setBoolean 메서드 제거

• get 메서드 BooleanArgumentMarshaler로 이동

  public boolean getBoolean(char arg) {
    Args.ArgumentMarshaler am = booleanArgs.get(arg);
    return am != null && (Boolean)am.get();
  }

• 위 코드 컴파일을 위해 ArgumentMarshaler에 get 함수 추가

  private abstract class ArgumentMarshaler {
    ...
    public Object get() {
        return null;
    }
  }

• 테스트 실패로 ArgumentMarshaler에 get 추상메서드로 변경 및 BooleanArgumentMarshaler에 get 구현

  private abstract class ArgumentMarshaler {
    protected boolean booleanValue = false;
    ...
  
    public abstract Object get();
  }
  

private class BooleanArgumentMarshaler extends ArgumentMarshaler { public void set(String s) { booleanValue = true; }

public Object get() {
    return booleanValue;
}

}

```

• ArgumentMarshaler에서 getBoolean 함수 제거
• ArgumentMarshaler의 booleanValue를 BooleanArgumentMarshaler로 내리고 private 변수로 선언
• 같은 방법으로 string, int 실행

결론

그저 돌아가는 코드만으로는 부족하다. 돌아가는 코드가 심하게 망가지는 사례는 흔하다. 단순히 돌아가는 코드에 만족하지 말고 처음부터 코드를 최대한 깔끔하고 단순하게 정리하자.

이 시리즈에서는 JPA 예시 코드를 기반으로, 실제 운영 환경에서 각기 다른 도메인끼리의 통신을 가정한 RESTful API로 디벨롭한다. * 기본 웹 프로젝트 세팅 완료된 상태에서 시작, 테스트는 POSTMAN 활용

디벨롭 단계

• Interceptor 생성 및 적용
• API Key 검증 로직 구현
• JWT 발급, 인증/인가 로직 구현
  • 서버용 JWT 발급 로직 구현
  • 서버 인터셉터 내 검증 구현
    • JWT의 형식 검증
    • JWT의 서명(Signature) 검증
    • 클레임(예: iss, exp, scope) 검증.
  • 클라이언트 용 인증 로직 구현
• OAuth 2.0 기반 인증/인가 로직 구현
  • 클라이언트 용 Access Token 발급 로직 구현
  • 서버 인터셉터 내 검증 구현
    • Access Token의 형식 검증
    • 인증 서버에 검증 요청(옵션, 원격 검증)
    • Access Token의 클레임(예: scope, exp) 검증

서버 측 코드 수정

Gradle 의존성 추가

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-security'
    implementation 'io.jsonwebtoken:jjwt-api:0.11.5'    
    runtimeOnly   'io.jsonwebtoken:jjwt-impl:0.11.5'  
    runtimeOnly   'io.jsonwebtoken:jjwt-jackson:0.11.5'
}

JwtUtil 생성

@Component
public class JwtUtil {
    @Value("${jwt.secret}")
    private String secretKey;
    @Value("${jwt.expiration-ms}")
    private long expirationMs;

    public String generateToken(UserDetails user) {
        Map<String, Object> claims = new HashMap<>();
        claims.put("roles", user.getAuthorities().stream()
                .map(GrantedAuthority::getAuthority).toList());

        return Jwts.builder()
            .setIssuer("my-company")   // issuer 클레임 설정, iss(발급자) 설정
            .setSubject(user.getUsername())
            .claim("roles", user.getAuthorities().stream()
                    .map(GrantedAuthority::getAuthority).toList())
            .claim("scope", "read write")    // scope 클레임 설정, scope(권한 범위) 설정
            .setIssuedAt(now)
            .setExpiration(new Date(now.getTime() + expirationMs))
            .signWith(Keys.hmacShaKeyFor(secretKey.getBytes()),
                      SignatureAlgorithm.HS256)
            .compact();
    }

    public String extractUsername(String token) {
        return Jwts.parserBuilder()
                .setSigningKey(secretKey.getBytes())
                .build()
                .parseClaimsJws(token)
                .getBody()
                .getSubject();
    }

    public boolean validateToken(String token, UserDetails user) {
        Claims claims = Jwts.parserBuilder()
            .setSigningKey(secretKey.getBytes())
            .build()
            .parseClaimsJws(token)
            .getBody();

        boolean subjectOk   = claims.getSubject().equals(user.getUsername());
        boolean notExpired  = claims.getExpiration().after(new Date());
        boolean issuerOk    = "my-company".equals(claims.getIssuer());          // iss(발급자) 검증
        boolean scopeOk     = Arrays.stream(claims.get("scope", String.class)
                                         .split(" "))
                                  .collect(Collectors.toSet())
                                  .containsAll(/* requiredScopes */);         // scope(권한 범위) 검증

        return subjectOk && notExpired && issuerOk && scopeOk;
}

UserDetailsService 구현 클래스 생성

@Service
public class CustomUserDetailsService implements UserDetailsService {
    private final MemberRepository memberRepository; // JPA 리포 사용

    public CustomUserDetailsService(MemberRepository memberRepository) {
        this.memberRepository = memberRepository;
    }

    @Override
    public UserDetails loadUserByUsername(String username) {
        Member member = memberRepository.findByUsername(username)
            .orElseThrow(() -> new UsernameNotFoundException("User not found: " + username));
        return org.springframework.security.core.userdetails.User.builder()
            .username(member.getUsername())
            .password(member.getPassword())
            .roles(member.getRoles().toArray(new String[0]))
            .build();
    }
}

인터셉터 preHandle 수정

@Component
public class AuthenticationInterceptor implements HandlerInterceptor {
    private final JwtUtil jwtUtil;         
    private final UserDetailsService userDetailsService;

    public AuthenticationInterceptor(JwtUtil jwtUtil,
                                     UserDetailsService userDetailsService) {
        this.jwtUtil = jwtUtil;
        this.userDetailsService = userDetailsService;
    }

    @Override
    public boolean preHandle(HttpServletRequest request,
                             HttpServletResponse response,
                             Object handler) throws Exception {
        String header = request.getHeader("Authorization");
        if (header == null || !header.startsWith("Bearer ")) {
            response.setStatus(HttpServletResponse.SC_UNAUTHORIZED);
            response.getWriter().write("Unauthorized");
            return false;
        }
        String token = header.substring(7);
        String username = jwtUtil.extractUsername(token);
        if (username != null && SecurityContextHolder.getContext().getAuthentication() == null) {
            UserDetails user = userDetailsService.loadUserByUsername(username);
            if (jwtUtil.validateToken(token, user)) {
                UsernamePasswordAuthenticationToken auth =
                  new UsernamePasswordAuthenticationToken(user, null, user.getAuthorities());
                SecurityContextHolder.getContext().setAuthentication(auth);
                return true;
            }
        }
        response.setStatus(HttpServletResponse.SC_FORBIDDEN);
        response.getWriter().write("Invalid or expired token");
        return false;
    }

    ...
}

클라이언트 측 코드 수정

public class ApiClient {
    private final RestTemplate rest;
    private String jwt; 

    public ApiClient(RestTemplateBuilder b) {
        this.rest = b.build();
    }

    public void login(String user, String pass) {
        AuthRequest req = new AuthRequest(user, pass);
        AuthResponse resp = rest.postForObject("/api/auth/login", req, AuthResponse.class);
        this.jwt = resp.getToken();
    }

    public <T> T get(String url, Class<T> cls) {
        HttpHeaders h = new HttpHeaders();
        h.setBearerAuth(jwt);
        HttpEntity<?> e = new HttpEntity<>(h);
        return rest.exchange(url, GET, e, cls).getBody();
    }
}

동시성이 필요한 이유

동시성은 무엇과 언제를 분리하는, 결합을 없애는 전략이다.

다음은 반드시 동시성이 필요한 상황이다.

• 구조적 관점: 프로그램은 거대한 루프 하나가 아닌, 작은 협력 프로그램 여럿으로 보이게 되어 시스템을 이해하기 쉽고, 문제를 분리하기도 쉽다.
• 응답시간과 작업처리량 개선의 경우 동시성 구현 필요 _ex) 웹 정보 수집기 -> 한번에 한 사이트만 방문하는 경우 _
• 정보를 대량으로 분석하는 시스템

미신과 오해

• 동시성은 항상 성능을 높여준다. (X) 동시성은 대기시간이 아주 길어 여러 스레드가 프로세서를 공유할 수 있거나, 여러 프로세서가 동시에 처리할 독립적인 계산이 충분히 많은 경우에만 성능이 높아진다.
• 동시성을 구현해도 설계는 변하지 않는다. (X) 단일 스레드 시스템과 다중 스레드 시스템은 설계가 판이하게 다르다. 일반적으로 무엇과 언제를 분리하면 시스템 구조가 크게 달라진다.
• 웹 또는 EJB 컨테이너를 사용하면 동시성을 이해할 필요가 없다. (X) 컨테이너가 어떻게 동작하는지, 어떻게 동시수정, 데드락 등과 같은 문제를 피할 수 있는지를 알아야만 한다.
• 동시성은 다소 부하를 유발한다. (O) 성능 측면에서 부하가 걸리며, 코드도 더 짜야한다.
• 동시성은 복잡하다. (O)
• 일반적으로 동시성 버그는 재현하기 어렵다. (O) 따라서 진짜 결함으로 간주되지 않고 일회성 문제로 여겨 무시하기 쉽다.
• 동시성을 구현하려면 흔히 근본적인 설계 전략을 재고해야 한다. (O)

난관

동시성을 구현하기 어려운 이유는 무엇일까? 다음 예시에서 알아보자.

public class X {
    private int lastIdUsed;

    public int getNextId() {
        return ++lastIdUsed;
    }
}

위 코드에서 인스턴스 X를 생성하고 lastIdUsed필드를 42로 설정한 다음, 두 스레드가 해당 인스턴스를 공유한다. 이제 두 스레드가 getNextId();를 호출하는 경우 결과는 다음 셋 중 하나이다.

• 한 스레드는 43을 받는다. 다른 스레드는 44를 받는다. lastIdUsed는 44가 된다.
• 한 스레드는 44을 받는다. 다른 스레드는 43를 받는다. lastIdUsed는 44가 된다.
• 한 스레드는 43을 받는다. 다른 스레드는 43를 받는다. lastIdUsed는 43가 된다. 두 스레드가 같은 변수를 동시에 참조하는 경우 자바 코드 한 줄을 거쳐가는 경로는 수없이 많은데, 그 중 일부 경로가 세 번째와 같은 잘못된 결과를 내놓을 수 있다.

동시성 방어 원칙

동시성 코드가 일으키는 문제로부터 시스템을 방어하는 원칙과 기술을 소개한다.

단일 책임 원칙 _Single Responsibility Principle, SRP_

주어진 메서드/클래스/컴포넌트를 변경할 이유는 하나여야 한다. 동시성 복잡성 하나만으로도 따로 분리할 이유가 충분하다. 동시성 관련 코드는 다른 코드와 분리해야 한다.

동시성 구현 시 고려할 점

• 동시성 코드는 독자적인 개발, 변경, 조율 주기가 있다.
• 동시성 코드에는 독자적인 난관이 있다. 다른 코드에서 겪는 난관과 다르며 훨씬 어렵다.
• 잘못 구현한 동시성 코드는 별의별 방식으로 실패한다. 주변에 있는 다른 코드가 발목을 잡지 않더라도 동시성 하나만으로도 충분히 어렵다. 동시성 코드는 다른 코드와 분리하라

따름 정리: 자료 범위를 제한하라

앞선 예시처럼, 객체 하나를 공유한 후 동일 필드를 수정하던 두 스레드가 서로 간섭하므로 예상치 못한 결과를 내놓는다. 이러한 문제의 해결 방안으로 공유 객체를 사용하는 코드 내 임계영역을 synchronized 키워드로 보호하라고 권장한다.**

공유 자료를 수정하는 위치가 많은 경우 발생할 수 있는 가능성

• 보호할 임계영역을 빼먹는다. 그래서 공유자료를 수정하는 모든 코드를 망가뜨린다.
• 모든 임계영역을 올바르게 보호했는지 확인하느라 똑같은 노력과 수고를 반복한다.
• 그렇지않아도 찾아내기 어려운 버그가 더욱 찾기 어려워진다. 자료를 캡슐화 하라. 공유 자료를 최대한 줄여라.

따름 정리: 자료 사본을 사용하라

공유 자료를 줄이려면 처음부터 공유하지 않는 방법이 제일 좋다. 객체를 복사해 읽기 전용으로 사용하거나 각 스레드가 객체를 복사해 사용한 후 한 스레드가 해당 사본에서 결과를 가져오는 방법도 가능하다.

따름 정리: 스레드는 가능한 독립적으로 구현하라

다른 스레드와 자료를 공유하지 않는다. 각 스레드는 클라이언트 욫청 하나를 처리한다. 모든 정보는 비공유 출처에서 가져오며 로컬 변수에 저장한다. 그러면 다른 스레드와 동기화 할 필요가 없어, 독립적으로 돌아간다. 독자적인 스레드로, 가능하면 다른 프로세서에서, 돌려도 괜찮도록 자료를 독립적인 단위로 분할하라

라이브러리를 이해하라

• 스레드 환경에 안전한 컬렉션을 사용한다. 자바 5부터 제공한다.
• 서로 무관한 작업을 수행할 때는 executor 프레임워크를 사용한다.
• 가능하다면 스레드가 차단되지 않는 방법을 사용한다.
• 일부 클래스 라이브러리는 스레드에 안전하지 못하다.

  스레드 환경에 안전한 컬렉션

  java.util.concurrent 패키지가 제공하는 클래스는 다중 스레드 환경에서 사용해도 안전하며 성능도 좋다. 실제로 ConcurrentHashMap은 거의 모든 상황에서 HashMap보다 빠르다. 동시 읽기/쓰기를 지원하며, 보통 다중 스레드 환경에서 문제가 생기는 자주 사용하는 복합 연산을 다중 스레드 상에서 안전하게 만든 메서드로 제공한다. *언어가 제공하는 클래스를 검토하라. 자바에서는 java.util.concurrent, java.util.concurrent.atomic, java.util.concurrent.locks 를 익혀라 *

실행 모델을 이해하라

다중 스레드 애플리케이션을 분류하는 방식은 여러 가지이다.

동기화하는 메서드 사이에 존재하는 의존성을 이해하라

공유 객체 하나에는 메서드 하나만 사용하라. 공유 객체 하나에 여러 메서드가 필요한 경우, 다음 세 가지 방법을 고려한다.

• 클라이언트에서 잠금 : 클라이언트에서 첫 번째 메서드를 호출하기 전 서버를 잠근다. 마지막 메서드를 호출할 때까지 잠금을 유지한다.
• 서버에서 잠금 : 서버에 서버를 잠그고 모든 메서드를 호출한 후 잠금을 해제하는 메서드를 구현한다. 클라이언트는 이 메서드를 호출한다.
• 연결서버 : 잠금을 수행하는 중간 단계를 생성한다. '서버에서 잠금'방식과 유사하지만 원래 서버는 변경하지 않는다.

동기화하는 부분을 작게 만들어라

동기화하는 부분을 최대한 작게 만들어라. 자바에서 synchronized 키워드를 사용하면 락을 설정한다. 같은 락으로 감싼 모든 코드 영역은 한 번에 한 스레드만 실행이 가능하다. 락은 스레드를 지연시키고 부하를 가중시키므로 여기저기서 synchronized를 남발하는 코드는 바람직하지 않다. 반면, 임계영역은 반드시 보호해야 한다. 따라서, 코드를 짤 때는 임계영역 수를 최대한 줄여야 한다.

올바른 종료 코드는 구현하기 어렵다

영구적으로 돌아가는 시스템을 구현하는 방법과 잠시 둘다 깔끔하게 종료하는 시스템을 구현하는 방법은 다르다. 깔끔하게 종료하는 코드는 올바로 구현하기 어렵다. 가장 흔히 발생하는 문제가 데드락이다. 즉, 스레드가 절대 오지 않을 시그널을 기다린다. 종료 코드를 개발 초기부터 고민하고 동작하게 초기부터 구현하라. 생각보다 어려우므로 이미 나온 알고리즘을 검토하라.

스레드 코드 테스트하기

문제를 노출하는 테스트 케이스를 작성하라. 프로그램 설정과 시스템 설정과 부하를 바꿔가며 자주 돌려라. 테스트가 실패하면 원인을 추적하라. 다시 돌렸더니 통과하더라는 이유로 그냥 넘어가면 절대로 안된다. 고려할 사항이 아주 많다는 뜻이다. 아래 몇 가지 구체적인 지침을 제시한다.

말이 안되는 실패는 잠정적인 스레드 문제로 취급하라.

시스템 실패를 '일회성'이라 치부하지 마라 다중 스레드 코드는 때때로 말이 안되는 오류를 일으킨다. 스레드 코드에 잠입한 버그는 실패를 재현하기가 아주 어려워 일회성 문제로 치부하고 무시한다. 일회성 문제를 계속 무시한다면 잘못된 코드 위에 코드가 계속 쌓인다.

다중 스레드를 고려하지 순차 코드부터 제대로 돌게 만들자.

스레드 환경 밖에서 생기는 버그와 스레드 환경에서 생기는 버그를 동시에 디버깅 하지 마라. 먼저 스레드 환경 밖에서 코드를 올바로 돌려라.

다중 스레드를 쓰는 코드 부분을 다양한 환경에 쉽게 끼워 넣을 수 있도록 스레드 코드를 구현하라.

다중 스레드를 쓰는 코드를 다양한 설정으로 실행하기 쉽게 구현하라.

• 한 스레드로 실행하거나, 여러 스레드로 실행하거나, 실행 중 스레드 수를 바꿔본다.
• 스레드 코드를 실제 환경이나 테스트 환경에서 돌려본다.
• 테스트 코드를 빨리, 천천히, 다양한 속도로 돌려본다.
• 반복 테스트가 가능하도록 테스트 케이스를 작성한다. 다양한 설정에서 실행할 목적으로 다른 환경에 쉽게 끼워 넣을 수 있게 코드를 구현하라

다중 스레드를 쓰는 코드 부분을 상황에 맞춰 조정할 수 있게 작성하라.

스레드 개수를 조율하기 쉽게 코드를 구현한다. 프로그램이 돌아가는 도중에 스레드 개수를 변경하는 방법도 고려한다. 프로그램 처리율과 효율에 따라 스스로 스레드 개수를 조율하는 코드도 고민한다.

프로세서 수보다 많은 스레드를 돌려보라.

시스템이 스레드를 스와핑할때도 문제가 발생한다. 스와핑을 일으키려면 프로세서 수보다 많은 스레드를 돌린다. 스와핑이 잦을수록 임계영역을 빼먹은 코드나 데드락을 일으키는 코드를 찾기 쉬워진다.

다른 플랫폼에서 돌려보라.

다중 스레드 코드는 플랫폼에 따라 다르게 돌아간다. 따라서 코드가 돌아갈 가능성이 있는 플랫폼 전부에서 테스트를 수행해야 마땅하다. 처음부터 그리고 자주 모든 목표 플랫폼에서 코드를 돌려라.

코드에 보조 코드를 넣어 돌려라. 강제로 실패를 일으키게 해보라.

흔히 스레드 코드는 오류를 찾기가 쉽지 않다. 간단한 테스트로는 버그가 드러나지 않는다. 스레드 버그가 산발적, 우발적, 재현이 어려운 이유는 코드가 실행되는 수천가지 경로 중 아주 소수만 실패하기 때문이다. 즉, 실패하는 경로가 실행될 확률은 극도로 저조하다. 이렇게 드물게 발생하는 오류를 좀 더 자주 일으키기 위해 보조 코드를 추가해 코드가 실행되는 순서를 바꿔준다. 각 메서드는 스레드가 실행되는 순서에 영향을 미친다. 가능한 초반, 가능한 자주 실패하는 편이 좋다. 코드에 보조코드를 추가하는 방법은 두 가지이다.

• 직접 구현하기 코드에 직접 wait(), sleep(), yield(), priority() 함수를 추가한다. 특별히 까다로운 코드를 테스트할 때 적합하다. 다만 이 방법에는 다음과 같은 문제가 있다.

  • 보조 코드를 삽입할 적정 위치 직접 찾아야 함
  • 어떤 함수를 어디서 호출해야 적당한 지 어떻게 알까?
  • 배포 환경에 보조 코드를 그대로 남겨두면 프로그램 성능 하향
  • 무작위적. 오류가 드러나지 않을 확률이 더 높다.

• 자동화 보조 코드를 자동으로 추가하려면 AOF, CGLIB, ASM 등과 같은 도구를 사용한다. 흔들기 기법을 사용해 오류를 찾아내라. 코드를 흔드는 이유는 스레드를 매번 다른 순서로 실행하기 위해서다. 좋은 테스트 케이스와 흔들기 기법은 오류가 드러날 확률을 크게 높여준다.

결론

다중 스레드 코드는 올바로 구현하기 어렵다. 다중 스레드 코드를 작성한다면 각별히 깨끗하게 코드를 짜야한다.

• SRP를 준수한다. 스레드 코드는 최대한 집약되고 작아야 한다.
• 동시성 오류를 일으키는 잠정적인 원인을 철저히 이해한다.
• 사용하는 라이브러리와 기본 알고리즘을 이해한다.
• 보호할 코드 영역을 찾아내는 방법과 특정 코드 영역을 잠그는 방법을 이해한다.
• 스레드 코드는 많은 플랫폼에서 많은 설정으로 반복해서 계속 테스트해야 한다.
• 스레드 코드는 출시 전까지 최대한 오랫동안 돌려봐야 한다.

창발성이란?

• 작은 요소들이 모였을 때, 개별 요소에서는 볼 수 없는 새로운 특성이나 행동이 나타나는 현상
• 복잡한 시스템에서 자발적으로 새로운 질서나 패턴이 생기는 것
• 프로그램 개발에서는 여러 단순한 모듈, 함수, 알고리즘들이 상호작용하면서, 설계자가 의도하지 않았거나 예상하지 못한 복잡한 동작이나 시스템 특성이 자연스럽게 나타나는 것

착실하게 따르기만 하면 우수한 설계가 나오는 간단한 규칙 네 가지가 있다. 다음은 해당 규칙을 중요도 순으로 나열하였다.

• 모든 테스트를 실행한다.
• 중복을 없앤다.
• 프로그래머 의도를 표현한다.
• 클래스와 메서드 수를 최소로 줄인다.

1. 모든 테스트를 실행하라

테스트 케이스를 만들고 계속 테스트하라는 규칙을 따르면 시스템은 낮은 결합도와 높은 응집력이라는, 객체지향방법론이 지향하는 목표를 저절로 달성한다. 테스트 케이스를 작성하면 설계 품질이 높아진다.

테스트 가능한 시스템

• 테스트를 철저히 거쳐 모든 테스트 케이스를 항상 통과하는 시스템
• 테스트 가능한 시스템 만들기
  • 작은 크기, 한 가지 목적만 수행하는 클래스 생성
    • SRP(단일책임원칙) 준수하는 클래스는 테스트가 쉽다.
  • 테스트 케이스가 많을수록 개발자는 테스트가 쉽도록 코드 작성
    • DIP(의존관계역전원칙) 적용
    • 의존성 주입, 인터페이스, 추상화 등의 도구를 사용해 결합도 낮춤
    • 설계 품질 향상

2~4. 리팩터링

테스트 케이스 작성 후 코드와 클래스를 정리한다. 구체적으로, 코드를 점진적으로 리팩터링한다. 테스트 케이스가 있으니 코드를 정리하며 시스템이 깨질 걱정을 할 필요는 없다.

리팩터링 단계

• 소프트웨어 설계 품질 높이는 기법 적용
  • 응집도 높이기
  • 결합도 낮추기
  • 관심사 분리하기
  • 시스템 관심사 모듈로 나누기
  • 함수와 클래스 크기 줄이기
  • 더 나은 이름 선택하기 등
• 중복 제거
• 프로그래머 의도 표현
• 클래스, 메서드 수 최소로 줄이기

2. 중복을 없애라

비슷한 코드는 더 비슷하게 고쳐주면 리팩터링이 쉬워진다. 아래 예시에서는 두 메서드에서 일부 코드가 동일하다.

public void scaleToOneDimension(
    float desiredDimension, float imageDimension) {
    if (Math.abs(desiredDimension - imageDimension) < errorThreshold)
        return;
    float scalingFactor = desiredDimension / imageDimension;
    scalingFactor = (float) (Math.floor(scalingFactor * 100) * 0.01f);

    RenderedOp newImage = ImageUtilities.getScaledImage(
        image, scalingFactor, scalingFactor);
    image.dispose();
    System.gc();
    image = newImage;
}

public synchronized void rotate(int degrees) {
    RenderedOp newImage = ImageUtilities.getRotatedImage(
        image, degrees);
    image.dispose();
    System.gc();
    image = newImage;
}

위 코드에서 동일한 코드를 정리해 중복을 제거한다.

public void scaleToOneDimension(
    float desiredDimension, float imageDimension) {
    if (Math.abs(desiredDimension - imageDimension) < errorThreshold)
        return;
    float scalingFactor = desiredDimension / imageDimension;
    scalingFactor = (float) (Math.floor(scalingFactor * 100) * 0.01f);
    replaceImage(ImageUtilities.getScaledImage(image, scalingFactor, scalingFactor));
}

public synchronized void rotate(int degrees) {
    replaceImage(ImageUtilities.getScaledImage(image, degrees));
}

private void relplaceImage(RenderedOp newImage) {
    image.dispose();
    System.gc();
    image = newImage;
}

중복 제거 후에는 클래스가 SRP를 위반한다. 그러므로 새로 만든 relplaceImage메서드를 다른 클래스로 옮긴다. 그러면 새 메서드의 가시성이 높아지고, 추가적인 추상화를 통해 다른 맥락에서 재사용 역시 가능하다. 이러한 소규모 재사용은 시스템 복잡도를 극적으로 줄여준다. 소규모 재사용을 제대로 익히면 대규모 재사용이 가능하다.

3. 표현하라

코드는 개발자의 의도를 분명히 표현해야 한다. 개발자가 코드를 명백하게 짤수록 다른 사람이 그 코드를 이해하기 쉬워지며, 결함이 줄어들고 유지보수 비용이 줄어든다.

• 좋은 이름 선택 : 이름과 기능을 일치하도록 이름을 정한다.
• 함수와 클래스 크기를 가능한 줄이기 : 작은 클래스와 작은 함수는 이름 짓기도 쉽고, 구현하기도 쉽고, 이해하기도 쉽다.
• 표준 명칭 사용 : 클래스가 command나 visitor와 같은 표준 패턴을 사용해 구현된다면 클래스 이름에 패턴 이름을 넣어준다. 그러면 다른 개발자가 클래스 설계 의도를 이해하기 쉬워진다.
• 단위 테스트 케이스 꼼꼼히 작성 : 테스트 케이스는 예제로 보여주는 문서이다. 잘 만든 테스트 케이스를 읽어보면 클래스 기능이 한눈에 들어온다.

4. 클래스와 메서드 수를 최소로 줄여라

중복 제거, 의도 표현, SRP 준수라는 기본 개념도 극단으로 치달으면 득보다 실이 많다. 함수와 클래스 크기는 작게 유지하면서, 시스템 크기도 작게 유지하는 것이 궁극적인 목표이다. 그러므로 클래스와 함수 수를 줄이는 작업도 중요하지만, 테스트 케이스를 만들고 중복을 제거하고 의도를 표현하는 작업이 더 중요하다.

시스템 제작과 시스템 사용의 분리

소프트웨어 시스템은 애플리케이션 객체를 제작하고 의존성을 서로 연결하는 준비 과정과, 준비 과정 이후에 이어지는 런타임 로직을 분리해야 한다.

초기화 지연(계산 지연)

준비 과정 코드와 런타임 로직이 뒤섞인 기법이다. 전형적인 코드는 다음과 같

public Service getService() {
    if (service == null)
        service = new MyServiceImpl(...);    //모든 상황에 적합한 기본값인지 확인 필요
    return service;
}

• 장점
  • 실제로 필요시 까지 객체 미생성 -> 불필요한 부하 X -> 애플리케이션 시작 시간 단축
  • 널포인터 반환X
• 단점
  • getService메서드가 MyServiceImpl과 생성자 인수에 명시적으로 의존
  • 런타임 로직에서 MyServiceImpl 객체를 미사용하더라도 의존성 해결 전까지 컴파일 불가
  • MyServiceImpl가 무거운 경우 테스트 시 단일 책임 원칙 미달성
  • MyServiceImpl이 모든 상황에 적합한 객체인지 판별 불가

체계적이고 탄탄한 시스템을 위해서는 모듈성을 깨서는 안된다. 설정 논리는 일반 실행 논리와 분리해야 모듈성이 높아지며, 주요 의존성을 해결하기 위한 일관적인 방식도 사용해야 한다.

Main 분리

시스템의 생성과 사용을 분리하는 방법. 생성 관련 코드는 모두 main이나 main이 호출하는 모듈로 옮기면, main 호출 시 객체가 자동적으로 생성된다. 따라서 나머지 시스템은 모든 객체가 생성되었고 모든 의존성이 연결되었다고 가정한다. 애플리케이션(나머지 시스템)은 그저 객체를 사용하기만 하면 된다.

팩토리

ABSTRACT FACTORY를 활용하면 객체 생성 시점은 애플리케이션이 결정하지만, 객체를 생성하는 코드는 애플리케이션이 알지 못한다. 이 경우도 모든 의존성이 main에서 애플리케이션으로 향하지만, 애플리케이션은 객체가 생성되는 시점을 완벽히 통제한다. 필요한 경우 특정 애플리케이션에서만 사용하는 생성자 인수도 넘길 수 있다.

의존성 주입

의존성 주입은 제어 역전 기법을 의존성 관리에 적용한 매커니즘이다.

• 제어 역전: 한 객체가 맡은 보조 책임을 새로운 객체에게 전적으로 떠넘긴다. 새로운 객체는 넘겨받은 책임만 수행하므로 단일 책임 원칙을 지킨다.

의존성 관리 맥락에서 객체는 의존성 자체를 인스턴스로 만드는 책임은 지지 않는 대신, 이 책임을 다른 전담 매커니즘에 넘기는 방식으로 제어를 역전한다. 진정한 의존성 주입은 여기서 더 발전시켜, 클래스가 의존성을 해결하려 시도하지 않는 대신, 설정자 메서드나 생성자 인수를 제공한다.

확장

테스트 주도 개발 (TDD), 리팩토링, 깨끗한 코드는 코드 수준에서 시스템을 조정하고 확장하기 쉽게 만든다. 하지만 시스템은 단순한 아키텍처를 복잡한 아키텍처로 조금씩 키우기는 어렵다. 다만, 소프트웨어 시스템은 물리적인 시스템과 달리, 관심사 별로 적절히 분리해 관리한다면 점진적으로 발전시킬 수 있다.

횡단(cross-cutting) 관심사

영속성과 같은 관심사는 애플리케이션의 자연스러운 객체 경계를 넘나드는 경향이 있다. 원론적으로는 모듈화, 캡슐화 된 방식으로 영속성 방식을 구상할 수 있지만, 현실적으로는 영속성 방식을 구현한 코드가 온갖 객체로 흩어진다. 이 때, 횡단 관심사를 활용하면 도메인 논리도 독자적으로 모듈화 할 수 있다. AOP는 횡단 관심사에 대처해 모듈성을 확보하는 일반적인 방법론이다.

• 프로그래머가 영속적으로 저장할 객체와 속성 선언
• 영속성 책임을 영속성 프레임워크에 위임
• AOP프레임워크가 대상 코드에 영향을 미치지 않는 상태로 동작방식 변경

아래에서 자바에서 사용하는 관점 혹은 관점과 유사한 매커니즘 세 개를 알아본다.

자바 프록시

개별 객체나 클래스에서 메서드 호출을 감싸는 것처럼 단순한 상황에 적합하다. 다만, JDK에서 제공하는 동적 프록시는 인터페이스만 지원한다. 클래스 프록시 사용을 위해서는 CGLIB, ASM, Javassist등의 바이트 코드 처리 라이브러리가 필요하다.

• 단점
  • 코드의 양이 방대하고 복잡하여 깨끗한 코드를 사용하기 어렵다.
  • 시스템 단위로 실행 지점을 명시하는 매커니즘을 제공하지 않는다.

순수 자바 AOP 프레임워크

대부분의 프록시 코드는 비슷하여 도구로 자동화할 수 있다. 순수 자바 관점을 구현하는 스프링 AOP, JBoss AOP등 여러 자바 프레임워크는 내부적으로 프록시를 사용한다.

• 프로그래머는 설정 파일이나 API를 사용해 필수적인 애플리케이션 기반 구조 구현
  • 영속성, 트랜잭션, 보안, 캐시, 장애조치 등 횡단 관심사 포함
  • 대다수 실제 스프링이나 JBoss 라이브러리 관점 명시
    • 이때 프레임워크가 사용자 모르게 프록시 or 바이트코드 라이브러리 활용해 이를 구현
  • 이러한 선언들이 요청에 따라 주요 객체를 생성하고 서로 연결하는 등 DI 컨테이너의 구체적인 동작 제어

AspectJ 관점

AspectJ는 언어 차원에서 관점을 모듈화 구성으로 지원하는 자바 언어 확장으로, 관심사를 관점으로 분리하는 가장 강력한 도구이다.

• 장점 : 관점을 분리하는 강력하고 풍부한 도구 집합 제공
• 단점 : 새 도구를 사용하고 새 언어 문법과 사용법을 익혀야 한다

테스트 주도 시스템 아키텍처 구축

최선의 시스템 구조는 각기 POJO(Plain Old Java Object: 순수한 객체) 또는 다른 객체로 구현되는 모듈화된 관심사 영역(도메인)으로 구성된다. 이렇게 서로 다른 영역은 해당 영역 코드에 최소한의 영향을 미치는 관점이나 유사한 도구를 사용해 통합한다. 이런 구조 역시 코드와 마찬가지로 테스트 주도 기법을 적용할 수 있다.

의사 결정을 최적화 하라

관심사를 모듈로 분리한 POJO 시스템은 기민함을 제공한다. 이러한 기민함 덕에 최신 정보에 기반해 최선의 시점에 최적의 결정을 내리기가 쉬워진다. 또한 결정의 복잡성도 줄어든다.

명백한 가치가 있을 때 표준을 현명하게 사용하라

표준을 사용하면 아이디어와 컴포넌트를 재사용하기 쉽고, 적절한 경험을 가진 사람을 구하기 쉬우며, 좋은 아이디어를 캡슐화하기 쉽고, 컴포넌트를 엮기 쉽다. 하지만 때로는 표준을 만드는 시간이 너무 오래 걸려 업계가 기다리지 못한다. 어떤 표준은 원래 표준을 제정한 목적을 잊어버리기도 한다.

시스템은 도메인 특화 언어가 필요하다

도메인 특화 언어(Domain-Specific Language, DSL)를 사용하면 고차원 정책에서 저차원 세부사항에 이르기까지 모든 추상화 수준과 모든 도메인을 POJO로 표현할 수 있다.

• 코드처럼 시스템 역시 깨끗해야 한다. 깨끗하지 못한 아키텍처는 버그가 숨어들기 쉬워지고 스토리를 구현하기 어려워져 도메인 논리를 흐리고 제품의 품질을 떨어뜨린다.

• 모든 추상화 단계에서 의도는 명확히 표현해야한다. 그러려면 POJO를 작성하고, 관점 또는 관점과 유사한 매커니즘을 사용해 각 구현 관심사를 분리해야한다.
• 시스템을 설계하든 개별 모듈을 설계하든, 실제로 돌아가는 가장 단순한 수단을 사용해야 한다.