[一日30分 인생승리의 학습법] 명령형 vs 선언형 프로그래밍
[一日30分 인생승리의 학습법] 명령형 vs 선언형 프로그래밍
명령형 프로그래밍은 절차적 프로그래밍이라고도 하는데,
최근에 우테코 미션을 하다가 요런 말을 들은 적이 있다.
전반적으로, 너무 절차적 프로그래밍으로 코드를 작성하는 경향이 있습니다.
좀 더 선언적으로 기능을 구현할 수 있게 사고 전환을 해보시면 나중에 큰 도움이 될 거예요.
처음에는 무슨 말인지 정확히 감이 잡히질 않아서 여기저기 찾아보다가
ui.dev라는 사이트에서 Tyler McGinnis라는 분이 작성한 글을 보고 조금씩 이해가 되기 시작했다.
그래서 기분이 좋아져서 번역이나 해봐야겠다 싶었다.
나는 언젠가 분명 ‘명령적(Imperative) 프로그래밍 vs 선언적(Declarative) 프로그래밍’에 대해 들어본 적이 있다.
저게 무엇을 의미하는지를 당연히 검색해봤지만, 그 때마다 요런 정의 정도만 접해볼 수 있었다.
명령형(절차적) 프로그래밍은 당신이 어떤 일을 어떻게 할 것인가에 관한 것이고,
선언적 프로그래밍은 당신이 무엇을 할 것인가에 관한 것입니다.
만약 내가 명령형과 선언형의 차이를 이미 알고 있었더라면 이 정의가 명확하게 다가왔겠지만 나는 그렇지 않았다.
사실 나 뿐만 아니라 많은 사람들이 이 주제에 대해 어려움을 느끼는데,
아마 직관적으로는 무슨 말인지 알지만, 누군가에게 설명할 만큼 명확하지는 않기 때문일 것이다.
많은 개발자들이 여기기에 가장 효과적인 방법은 비유와 실제 코드를 조합해서 설명해주는 것이었다고 하니,
해당 방법으로 ‘명령형 vs 선언적 프로그래밍’이라는 주제를 다뤄보도록 하자.
우선, 위에서 언급했던 저 ‘어떻게, 무엇을’에 관한 정의는
사실 ‘명령형 vs 선언형’의 핵심을 담고있다고 봐도 무방하다.
이를 이해하기 위해, 프로그래밍의 관점에서 잠깐 벗어나 현실에서의 예시를 들어보도록 하자.
■ Red Lobster
당신은 회사에서 너무 오랜 시간 자바스크립트를 다루느라 피곤해졌습니다.
그리고 이를 달래기 위해 퇴근 후에 아내와 함께 ‘Red Lobster’ 식당에 근사한 데이트를 하러 갔습니다.
당신은 Red Lobster에 도착했고, 프론트 데스크에 가서 다음과 같이 말했습니다.
- 명령형 접근(HOW): “저기 Gone Fishin’ 이라고 적힌 표지판 아래에 있는 테이블이 비어있네요.
우리는 저기로 걸어가서 저 테이블에 앉도록 하겠습니다.” - 선언형 접근(WHAT): “2명 자리 주세요.”
명령형 방식은 내가 실제로 자리에 어떻게 앉을지에 관심이 있다.
이를 위해 나는 내가 어떻게 테이블을 잡아서 자리에 앉을지에 관해, 필요한 단계들을 하나하나 나열해야 한다.
반면, 선언형 방식은 오로지 내가 무엇을 원하는지에 관심이 있다. 여기서 말한 ‘두 명을 위한 테이블’ 처럼.
■ Wal-Mart
친구가 당신의 집에 집들이를 오기 위해 Wal-Mart에서 선물을 샀습니다.
현재 친구는 Wal-Mart 바로 옆에 있으며, 당신의 집에 어떻게 도달해야 하는지를 전화로 물어봅니다.
이에 관한 명령형 대답과 선언형 대답을 모두 생각해보세요.
- 명령형 접근(HOW): “주차장 북쪽 출구로 나와서 좌회전을 해. 12번가 출구에 도착할 때까지
I-15 북쪽 도로를 타고 와야 해. 거기서 IKEA에 가는 것처럼 출구에서 우회전을 해. 그리고 거기서
직진하다가 첫 번째 신호등에서 우회전을 해. 그 다음에 나오는 신호등을 통과한 후에 좌회전을 하면 돼.
우리 집은 #298 이야.” - 선언형 접근(WHAT): “우리 집 주소는 298 West Immutable Alley, Eden, Utah 84310 이야.”
추가로 한 가지 비유를 더 하자면, 수동 스틱 자동차와 오토 스틱 자동차를 예로 들 수 있다.
친구가 ‘우리 집에 어떻게 도착하는가’ 와는 별개로, 친구가 어떤 차를 운전하느냐에 관한 이야기이다.
수동 스틱(1종)은 명령형 방식이고 오토 스틱(2종)은 선언적 방식이다.
만약 당신이라면 어떤 차를 운전하겠는가?
실제 코드로 예시를 들기 전에, “자리에 앉는 방법은 누가 알지?”,
“주소는 아는데, 집에 가는 방법은 누가 알지?”와 같은 의문이 생길 수 있을거라 생각한다.
이에 대한 대답은, 선언적 방식의 접근을 위해서는 명령형 방식으로
‘어떻게 접근하는가’에 관한 내용이 먼저 추상화 되어있어야 한다 라는 것.
- Red Lobster 직원에게 사용했던 선언형 접근(“2명 자리 주세요.”)에는, Red Lobster 직원이
‘테이블에 어떻게 앉는가’에 관한 모든 명령형(절차적) 단계들을 알고 있다는 가정이 뒷받침되어 있다. - 친구에게 우리 집의 주소를 알려주는 것도, 친구가 ‘우리 집에 어떻게 도착할 수 있는가’에 관한 명령적 절차들을
모두 알고있는 일종의 GPS 같은 것을 가지고 있다는 것을 전제로 한다. - 오토 스틱(2종) 자동차는 변속 기어에 대해 일종의 추상화 계층(Layer)을 가지고 있다.
위의 내용들을 다음의 문장으로 다시 한 번 정리할 수 있다.
많은 선언적(Declarative) 접근 방식들의 기반에는 일종의 ‘명령적(Imperative) 추상화’가 존재한다.
이제, 여러가지 비유로 떡칠된 예시들을 졸업하고 현실 세계의 코드 예시를 살펴볼 차례이다.
그 전에, ‘선언적 프로그래밍 언어’와 ‘명령적 프로그래밍 언어’에는 어떤 것들이 있는지 간단히 살펴보자.
- 명령적 언어: C, C++, Java
- 선언적 언어: SQL, HTML
- (Can be) Mix: Javascript, C#, Python
우선, 대표적인 선언형 언어인 SQL과 HTML의 코드를 살펴보자.
SELECT * FROM Users WHERE Country='Mexico';
<article>
<header>
<h1>Declarative Programming</h1>
<p>Sprinkle Declarative in your verbiage to sound smart</p>
</header>
</article>이 두 가지 예시 모두 문법만 알고 있다면, 어떤 일이 일어나고 있는지 명확히 알 수 있다.
이 둘은 모두 선언형 프로그래밍이며, 어떤 일을 어떻게 수행하는가 보다는 무엇을 수행하는가에 관심이 있다.
즉, 우리가 무엇을 얻고자 하는가에 관해서만 묘사하고 있고, 그것을 어떻게 얻는가에 관해서는 알려주지 않는다.
SQL 예시에서는 멕시코에 거주하는 모든 유저들을 선택하는 ‘방법에 대한 구현’은 우리에게서 추상화되어있다.
HTML 예시에서는 ‘웹 브라우저가 어떻게 article 엘리먼트를 파싱해서 화면에 보여주는가’는 고려하지 않는다.
우리의 WHAT은 오직 ‘멕시코 유저들‘과 웹사이트의 ‘header와 paragraph‘이다.
지금까지는 충분히 알아먹을 수 있을 것 같다.
이제, 조금 더 실전적인 자바스크립트 예제로 들어가보자.
■ 기술 면접
당신은 현재 기술 면접을 보는 중이고, 나는 해당 기술 면접의 interviewer입니다.
콘솔창을 열고, 제가 묻는 질문에 해당하는 답을 작성해보세요.
1. 숫자 배열을 받아서, 해당 배열의 모든 원소들을 두 배 시킨
새로운 배열을 리턴하는 ‘double’이라는 이름의 함수를 작성하세요.
ex) double([1, 2, 3]) // [2, 4, 6]
2. 숫자 배열을 받아서, 해당 배열의 모든 원소들을 더한 값을 리턴하는 ‘add’라는 함수를 작성하세요.
ex) add([1, 2, 3]) // 6
3. jQuery나 Vanilla Javascript를 이용해서, btn이라는 id를 가진 엘리먼트에 이벤트 리스너를 달아보세요.
해당 버튼을 클릭했을 때 highlight라는 class를 toggle(add or remove)해야 하고,
엘리먼트의 현재 상태에 따라 버튼의 텍스트를 ‘Add Highlight’와 ‘Remove Highlight’로 바꿔야 합니다.
이 문제들에 대해, 가장 흔히들 작성하는 ‘명령적’ 코드들을 먼저 살펴보자.
function double (arr) {
let results = []
for (let i = 0; i < arr.length; i++){
results.push(arr[i] * 2)
}
return results
}
function add (arr) {
let result = 0
for (let i = 0; i < arr.length; i++){
result += arr[i]
}
return result
}
$("#btn").click(function() {
$(this).toggleClass("highlight")
$(this).text() === 'Add Highlight'
? $(this).text('Remove Highlight')
: $(this).text('Add Highlight')
})
무엇이 이 코드들을 명령적으로 만드는지 알기 위해서는, 이 세 가지 코드들에서 공통점을 뽑아내야 한다.
1. 가장 명백한 공통점은 이들이 어떤 일을 어떻게 처리하는지에 관해 묘사하고 있다는 것.
각각의 예시에서, 우리는 명시적으로 배열을 반복하거나(for 문),
우리가 원하는 기능을 수행하기 위한 단계들을 명시적으로 나열하고 있다.
2. 각각의 예시에서 우리는 ‘상태(state)의 일부’를 변경하고 있다.
(상태: 메모리에 저장되어 있는 것들에 대한 정보. 변수와 비슷하다고 생각하면 됨)
처음 두 예시에서는 ‘results’라는 변수를 만들어 그것을 계속해서 수정하고 있다.
세 번째 예시에서는 아무런 변수도 없지만, 여전히 DOM 자체에 state가 존재하고 있다.
그리고 해당 코드는 DOM의 state를 수정하고있다.
3. 약간 주관적이지만, 위의 코드들은 가독성이 떨어진다.
위의 코드들을 한 번 슥 훑어보고 어떤 일이 일어나고 있는지 바로 알아채기는 쉽지 않을 것이다.
우리의 뇌는 코드가 존재하는 맥락을 고려해가며, 해당 코드들을 인터프리터처럼 차근차근 살펴봐야 한다.
이런 똥쓰레기같은 코드들은 이제 그만 보고, 이제 선언적 예시들을 살펴보자.
선언적 예시들의 목적은 위에서 봤던 예시들의 문제점들을 모두 해결하는 것이다.
그러기 위해서 이 코드들은 무엇이 일어나는지에 관해 묘사해야 하고,
state를 변경해선 안되며, 한 눈에 파악할 수 있어야 한다(가독성이 좋아야 한다).
function double (arr) {
return arr.map((item) => item * 2)
}
function add (arr) {
return arr.reduce((prev, current) => prev + current, 0)
}
<Btn
onToggleHighlight={this.handleToggleHighlight}
highlight={this.state.highlight}>
{this.state.buttonText}
</Btn>
처음 두 예제에서, 자바스크립트의 내장 함수인 map과 reduce를 활용한 레버리징에 주목하자.
이는 이 글 내내 반복해서 언급했던,
‘가장 효율적인 선언적 프로그래밍 방법은 명령적으로 작성된 코드를 추상화하는 것이다‘
라는 것에 관한 내용이다.
해당 예제들은 우리가 어떻게 처리할지보다, 무엇을 원하는지를 설명한다.
(우리는 map과 reduce가 어떻게 구현되어있는지는 전혀 알지도 못하고, 관심도 없다)
우리는 아무런 state도 변경하지 않는다. 모든 변경들은 map과 reduce 내부에 추상화되어있다.
그리고 당신이 map과 reduce에 익숙하다는 가정 하에, 훨씬 더 가독성이 좋다.
이제, 마지막 예제를 살펴보자.
여기서는 약간의 편법으로 리액트를 사용했다.
그러나 중요한 것은 명령형의 세 가지 문제점들이 모두 해결이 되었다는 것.
리액트의 진정한 강점은 이러한 선언적인 방식으로 UI를 작성할 수 있다는 것이다.
우리의 Btn 컴포넌트를 보면, 해당 UI가 어떤 식으로 보일지를 빠르게 알아챌 수 있다.
또 다른 강점은 state가 DOM에 존재하는 대신, 우리가 만든 리액트 컴포넌트 자체에 존재한다는 것.
선언적 프로그래밍의 또 다른, 덜 알려진 장점 중의 하나는
우리의 프로그램이 context-independent 해질 수 있다는 것이다.
(전체적인 맥락, 상황에 좀 더 독립적이다)
선언적 코드들은 최종적인 목표가 무엇인지에 대해서만 관심이 있지,
해당 목표를 이루기 위한 세부적인 단계들(해당 목표에 의존적인 과정들)에는 관심이 없다는 것.
그래서 동일한 코드들이 다른 프로그램에 쓰이더라도 정상적으로 동작할 수 있게 된다.
당장 위의 세 예시만 보더라도, 저 함수들이나 컴포넌트는
우리가 만들고자 하는 어떤 프로그램에 갖다붙여도 정상적으로 동작한다.
저들은 현재 어떤 프로그램에 속해있는가 하는 것에 전혀 구애받지 않는다.
명령형 코드들은 그렇지 못한 경우가 많은데, 그 이유는 대부분의 경우
명령형 코드들이 현재 상태의 컨텍스트에 의존적이기 때문이다.
(그래서 다른 곳에서 재사용하기가 어렵다)
이 글의 저자는, 선언적 프로그래밍에서 더 나아가 함수형 프로그래밍까지 다뤄보라고 권유하고 있다.
map, reduce, filter를 사용해보면서 차근차근 시작하라고 하는데, 함수형 프로그래밍에 관해서도
조만간 한 번 알아보는 시간을 가지면 좋을 듯.
개인적으로 가장 와닿았던 부분은, 선언적 프로그래밍은 절차적 구현을 추상화함으로써 이루어진다는 것.
선언적 프로그래밍을 어떻게 해야 하는가에 대해 좀 더 감을 잡을 수 있게 해준 내용인 듯.
리뷰어분들께서 말씀하시는 ‘재사용성’이나 ‘순수 함수’에 관한 것들이 약간 일맥상통하는 부분이 아닌가 싶다.
최대한 독립적이고 재사용성이 높은 함수들을 구현하여, 해당 함수들의 조합으로 프로그래밍을 구성하면
전체 코드의 유지보수가 쉬워지고 가독성도 훨씬 높아지겠지. 그게 말처럼 쉽겠냐마는..
아래는 저자가 웹을 돌아다니며 발견한 선언적 프로그래밍의 또 다른 정의들.
Declarative programming is “the act of programming in languages that conform to the mental model of the developer rather than the operational model of the machine.”
선언적 프로그래밍은 “기계의 동작을 모델로 하는 것이 아닌, 개발자의 두뇌(정신, 생각)를 모델로 본딴 언어를 가지고 프로그래밍 하는 것” 이다.
Declarative Programming is programming with declarations, i.e., declarative sentences.
선언적 프로그래밍은 선언(선언적 문장, 선언문)들을 사용해서 프로그래밍하는 것이다.
?
The declarative property is where there can exist only one possible set of statements that can express each specific modular semantic. The imperative property is the dual, where semantics are inconsistent under composition and/or can be expressed with variations of sets of statements.
선언적 속성이란, 특정 모듈을 설명하는 문장 집합이 단 하나만 존재할 수 있다는 것을 의미한다. 명령적 속성은 이중적이고, 이는 의미들의 구성에 일관성이 없고 여러 가지 문장 집합들로 표현될 수 있다는 것을 의미한다.
Declarative languages contrast with imperative languages which specify explicit manipulation of the computer’s internal state; or procedural languages which specify an explicit sequence of steps to follow.
선언적 언어는 컴퓨터의 내부 상태를 명시적으로 조작하는 명령형 언어, 또는 밟아야 하는 일련의 절차들을 명시적으로 지정하는 절차적 언어와 반대된다.
In computer science, declarative programming is a programming paradigm that expresses the logic of a computation without describing its control flow.
CS에서 선언적 언어는 제어 흐름을 설명하지 않고, 계산 로직을 표현하는 패러다임(개념)이다.
I draw the line between declarative and non-declarative at whether you can trace the code as it runs. Regex is 100% declarative, as it’s untraceable while the pattern is being executed.
나는 코드의 실행을 추적할 수 있는지 여부에 따라 선언형과 비선언형을 구분한다.
정규표현식(Regex)은 패턴이 실행되는 동안 그것을 전혀 추적할 수 없기 때문에 100% 선언적이라고 할 수 있다.
+ Zereight’s Blog에서 본 인상적인 설명
명령형 프로그래밍은 문제를 어떻게 해결해야하는지 컴퓨터에게 명시적으로 명령을 내리는 방법을 의미하고,
선언형 프로그래밍은 무엇을 해결할 것인지에 보다 집중하여 어떻게 문제를 해결하는지에 대해서는
컴퓨터에게 위임하는 방법이다.
처음 프로그래밍이라는 개념이 등장했을 떄부터, 지금까지도 컴퓨터에게 명시적으로 명령을 내리는 방법인
명령형 프로그래밍을 주로 사용했지만, 함수형 프로그래밍은 문제를 해결하는 방법에 더 집중하고
사소한 작업은 컴퓨터에게 넘겨버리는 선언형 프로그래밍의 일종이다.
즉, 컴퓨터에게 사소한 작업들을 위임해버리는 패러다임의 특성 상
선언형 프로그래밍에는 필연적으로 높은 수준의 추상화라는 키워드가 붙는다.
추상화 수준이 낮다면 저 사소한 작업들을 개발자가 일일이 다 컨트롤해야한다는 의미이기 때문이다.
[출처] https://iborymagic.tistory.com/73
){kind=link}