명령어 꼭 외워야 할까요

제 결론은 외우면 좋다입니다.
왜 좋은지, 명령어를 외우는 행동을 분석해 볼게요.

1. 테라폼 명령어를 외우다.

제 사례를 하나 공유드릴게요. 저는 오랜 기간 동안 테라폼 명령어를 외우지 않고 쓴 경험이 있어요.

terraform init 은 알았지만
terraform init -reconfigure 나 -migrate-state는 에러메시지에서 나오면 사용했고
terraform init -backend-config 같은 명령어는 노트패드에서 복붙 해서 쓰는 식이었어요.

terraform plan은 알았지만
terraform plan -var-file은 또 저장해 놓은 명령어 모음에서 복사해서 쓰는 식이었죠.

무슨 명령어를 쳐야 하는지 알고, 그 명령어가 어디 있는지 알지만, 명령어 자체를 외우지는 않았어요. 그러다가 내 작업 환경이 아닌 상황에서 명령어를 써야 하는데 기억이 안 나는 거예요. 다른 분을 도와주다가 "제 컴퓨터에 저장된 명령어 좀 확인하고 오겠습니다." 하는 건 좀 별로잖아요. 그래서 그냥 외워버렸어요. 못 외울 길이도 아니고, 자주 쓰기도 했어요.

 

2. 외우면 뭐가 좋을까

첫 번째 장점은 context switch가 줄어든다는 점이에요.
context switch는 컴퓨터 운영체제에서 주로 쓰는 단어예요. 컴퓨터나 사람이 한 작업에서 다른 작업으로 전환하는 것을 의미하고 당연히 비용이 들어요.

작업 중에 새로운 탭을 켜고 검색해서 한 번에 원하는 결과를 찾아도 작업 흐름은 이미 바뀐 거예요. 제 상황은 저장된 텍스트파일을 열어서 명령어를 검색, 복사, 붙여넣기 하는 과정이죠. 검색이나 copy&paste도 숨겨진 비용이 있는 거죠. 검색을 하기 위해 mental shift가 일어나고, 복사해서 붙여 넣는 과정에서 다시 mental shift가 필요해요. 전체 과정은 겉보기에 1분도 걸리지 않을 수 있지만, 실제로는 꽤 인지적 비용이 들어요. 명령어를 외우면 작업 흐름이 깨지는 상황을 막아줘요.

두 번째 장점은 소요 시간도 대부분의 상황에서 더 빠르다는 점이었어요.

세 번째 장점은 환경에 영향을 받지 않는 점이에요.

탭을 눌러 자동완성을 해주는 툴을 쓰고 있다가 없는 곳에 던져졌다고 생각해 봐요. 생각만 해도 불편함이 느껴진다면 한 번쯤 외워볼 만한 거죠. 우리는 어떤 환경에서도 같은 동작을 한다는 게 얼마나 중요한 기능인지 알아요. 저장소를 컴퓨터에 두면 특정 환경에서는 복사해 올 수 없지만, 우리의 뇌를 쓰면 어떤 환경에서도 명령어를 쓸 수 있어요.

네 번째는 외웠다가 까먹더라도 도움이 돼요.

curl 명령어를 예로 들면 모든 옵션을 다 외워서 암기하려고 했다고 하면 나중에 필요한 옵션이 있을때, 기억이 날 수도 있고, 검색해서 찾기도 쉬울 거예요.뭘 모르는지 아는 것과, 뭘 모르는지도 모르는 것은 다르잖아요. 모든 옵션을 한번이라도 본 사람은 그중에서 몇 개는 기억을 할 것이고, 그중에서 자주 쓰는 몇 개는 의도적으로 외울 필요가 있다는 거죠.

 

3. 개발자와 명령어

개발자와 명령어는 떼려야 뗄 수 없는 관계죠. 물론 모든 명령어를 다 외우라는 뜻은 아니에요.

내가 어떤 명령어를 자주 쓰는지 식별하는 것도 중요해요. 하루에 몇 번씩 쓰는 명령어를 이전 명령어에서 나올 때까지 찾아보고, 안 나오면 검색하는 건 비효율적이에요.

그 명령어가 어딨더라... (방향키 위쪽을 누르며)

docker 빌드는 할 줄 알지만, docker buildx build 명령어에 --cache-from이나 --no-cache 가 있는 건 모르고 넘어갈 수 있어요. 명령어를 정리한 블로그에는 안 나오고 공식 문서에만 나오는 옵션들도 많죠.

의미 연결을 통해 암기하는 건 널리 알려진 방법이죠.
curl -v에서 v는 verbose 필요 이상으로 말을 많이 한다는 뜻이에요.
ssh 명령어에서 포트는 -p이고 mysql 명령어에서 포트는 -P 에요.

help 명령어나 man 명령어로 가이드를 읽어 보는 것도 좋아요.

짧은 버전의 옵션만 쓰고 있었다면, 긴 버전은 원래 뭐였을까 알아보는 것도 좋아요.

반대로 풀네임의 축약어를 외우는 것도 좋은 방법이에요.

kubernetes에서는 다양한 리소스 타입이 있어요.
kubectl 명령어를 쓸 때는 이 리소스들의 축약어를 알아두면 편해요.
전체 리소스의 반 이상이 shortnames를 가지고 있는 걸 볼 수 있어요.

NAME	SHORTNAMES	KIND
componentstatuses	cs	ComponentStatus
configmaps	cm	ConfigMap
endpoints	ep	Endpoints
events	ev	Event
limitranges	limits	LimitRange
namespaces	ns	Namespace
nodes	no	Node
persistentvolumeclaims	pvc	PersistentVolumeClaim
persistentvolumes	pv	PersistentVolume
pods	po	Pod
replicationcontrollers	rc	ReplicationController
resourcequotas	quota	ResourceQuota
serviceaccounts	sa	ServiceAccount
services	svc	Service
customresourcedefinitions	crd, crds	CustomResourceDefinition
daemonsets	ds	DaemonSet
deployments	deploy	Deployment
replicasets	rs	ReplicaSet
statefulsets	sts	StatefulSet
horizontalpodautoscalers	hpa	HorizontalPodAutoscaler
cronjobs	cj	CronJob
networkpolicies	netpol	NetworkPolicy
poddisruptionbudgets	pdb	PodDisruptionBudget
priorityclasses	pc	PriorityClass
storageclasses	sc	StorageClass

https://kubernetes.io/ko/docs/reference/kubectl/#%EB%A6%AC%EC%86%8C%EC%8A%A4-%ED%83%80%EC%9E%85

 

 

4. 명령어 사용의 새로운 관점

최근에 curl --resolve 명령어를 쓰게 된 경험이 있어요. vdi 환경에서 메모장을 못 여는 상황이었어요. 보통은 hosts 파일을 수정해서 테스트를 하거나, header에 Host를 써서 해결을 했어요. 하지만 복잡한 구성에서 테스트가 필요하게 되었고, 찾아보니 --resolve라는 옵션을 발견하고 사용했어요.

SNS에서 본 다른 사례도 있어요. 어떤 개발자분이 macOS 터미널에서 디렉터리를 만드는 작업을 ai에게 물어보았어요. mkdir {1..n} 이런 명령어로 된다는 결과를 보고 놀랐다고 하셨어요. 보자마자 '터미널에서 brace expansion이 돼?'라고 생각하셨겠죠?

암기와는 조금 다르지만 내가 아무렇지 않게 하는 작업이 사실 더 쉽고 간단한 방법이 있는지 확인하는 것도 좋은 자세예요.어제는 최선의 방법이었지만, 내일은 아닐 수도 있잖아요.

 

5. 명령어 실행 전에 결과를 예측해 봐요

명령어를 치기 전에 결과를 예상해 보는 것도 좋아요. 저는 최근에 이런 실수를 했어요.

curl -v telnet://test.com 명령어로 네트워크 테스트를 했어요. connection이 뜨고 아무 반응이 없길래 실패했다고 팀장님에게 말한 거예요.

사실 connection이 된 것 자체가 성공인데, 너무 급한 나머지 결과를 잘못 판단해 버린 거죠.
초록색으로 CONNECTIONS SUCCESS 라고 안 띄워줘서 그랬을까요?

명령어를 치기 전에 몇 가지 결과를 예측해 보고 실제 결과와 비교해 보는 작업을 했었다면, 이런 실수를 안 했을 것 같아요. 네트워크 작업 중에 연결이 안 되고, 실패하고, 응답이 없고 하는 경우만 너무 많이 봐서 그렇기도 해요. 잘 작동하는 환경에서도 명령어를 써봐야겠어요. 성공 결과가 이렇게 낯설 줄은 몰랐거든요.

그리고 커뮤니케이션에도 도움이 돼요. 그냥 안 돼요. 하는 것보다는"어떤 명령어를 입력해서, 어떤 결과가 나올 줄 알았는데, 이런 결과가 나오면서 안된다."라고 공유하면 소통이 더 쉬워지죠.

 

6. 결론

자주 쓰는 명령어를 암기하는 것은 단순히 시간을 절약하는 것을 넘어 작업 효율과 사고 흐름의 일관성을 유지하게 도와줘요. 명령어를 외우는 과정에서 자연스럽게 해당 기능에 대한 이해도 깊어지고, 장기적으로는 문제 해결 능력과 개발자로서의 역량을 강화하는 데 도움이 될 거예요.

물론 모든 명령어를 외우는 것은 비효율적일 수 있죠. 대신 자주 사용하는 명령어가 무엇인지 파악하여 암기하고, 가끔 사용하는 명령어라면 개념을 이해하고 필요할 때 적절히 찾아서 활용하는 균형 있는 접근법이 필요해요.

더 나아가, 내가 알고 있는 명령어를 주기적으로 돌아보고, 새로운 방법이나 옵션을 배우려는 태도는 좋아요. 오늘의 최선이 내일의 최선은 아닐 수 있으니까요. 단순히 암기에 머무르지 않고, 새로운 관점에서 효율성을 개선하려는 노력은 성장을 이끌어줄 거예요.

결국 중요한 것은, 우리가 도구(명령어)를 다룰 때 그것이 우리의 목표를 얼마나 효과적으로 지원하는가예요. 암기는 단순히 그 도구를 더 잘 다루기 위한 하나의 방법일 뿐, 궁극적으로 더 나은 작업 환경과 성과를 위함이죠.

명령어 암기는 끊임없이 개선하려는 태도의 한 예시일 뿐일 수도 있고요.