제니의 프로덕트 블로그

✨ 작가님을 소개합니다 ✨

Digital Product Design Leader⎥Global Head of Product Design at Fantasy⎥Speaker

1️⃣ Netflix, Google, Facebook, Huawei, Twitter, The Weather Channel, Adobe, Microsoft, British Airways, HP, 23andMe등과 함께 일했으며 20개가 넘는 상을 수상했다고 한다.

2️⃣ 다양한 국제 디자인 축제에서 연설을 하고 있는 연설가이기도 하면서 다수의 책을 출판한 작가이기도 하다.

3️⃣ 디자인을 사용해 50일 동안 50개의 문제를 해결하기 위해 2517miles, 즉 4050km를 여행하기도 했다.

​

오늘의 아티클은 그가 여행했던 50일 간의 여정에서, UX 디자인 과정을 다시 생각하게 만든 경험을 글로 쓴 것이다.

전 최근 50일 동안 50개의 문제를 해결하기 위해 2517마일을 여행했습니다. 이 여정은 제가 생각했던 사용자-경험 디자인 과정을 완전히 다시 생각하게 만들었어요.

​

전 스스로에게 도전을 주었어요. 문제를 해결할 수 있는 디자인의 힘의 한계를 시험해 보고 싶었습니다. 그래서 제 컴퓨터 의자에 편안함을 내려놓고 미지의 세계로 떠났어요. 매일 24시간 동안 문제를 관찰하고, 해결하고 이 해결책을 전달하는 것까지 해야 했습니다.

​

아주 적은 돈으로, 더러운 뒷골목의 호스텔에서 분주한 도심까지, 매일 제가 찾아 낸 다양한 사회적인 문제를 해결하기 위해 유럽을 여행했습니다. 프로젝트 자체는 정말 놀라운 경험이었어요. 내 해결책이 나쁘지 않았을 때도 있었지만, 어느 때는 실패하기도 했어요. 그리고 성공적인 해결책이 나올 때도 있었어요. 하지만 제가 강조하고 싶었던 건, 성공여부가 아니라 매일 밖으로 나가 도전해보는 것 그 자체였습니다. 그 전날 실패를 겪었더라도 말이죠.

​

이 모험은 놀랄 만한 디자인의 힘을 보여주었고, 스스로 디자이너로서의 가능성을 보여주기도 했어요. 더 중요한 건, 문제를 철저히 따져보는 능력과 빠르게 해결하는 능력을 갈고 닦게 해 주었다는 거예요.

​

분주한 런던 지하철에서 토리노(이탈리아 북서부의 산업도시)의 자갈깔린 뒷골목까지의 여정이 디자인 프로세스에 대해 어떤 것들을 가르쳐 주었는지, 그리고 혁신을 만들어 내기 위해 공감의 힘이 얼마나 큰지 알려드릴게요.

혼잡한 지하철

50일 간의 여정 중 19일 째 되는 날이었어요. 지하철을 잡기 위해 서둘렀고, 역에 도착하니 엄청난 인파가 역으로 물밀듯 들어가는 걸 볼 수 있었죠. 라인에 문제가 있었고, 지하철은 연착되고 있었던 거예요. 상황을 찬찬히 보고, 이 문제를 오늘의 문제로 삼아야 겠다고 생각했어요.

잠시 한발짝 물러나서 내 앞에 있는 상황을 분석하고 작업을 진행했어요. 15살에 디자인 컨설턴트를 시작하여 지금 UX 리더로서 컨설팅을 하고 있는 저 였기에, 어떻게 시작해야 할 지 알고 있었어요:

1️⃣ 관찰: 사람들의 흐름, 서로 자리를 차지하기 위해 분투하는 모습, 그리고 사람들이 승하차하는 방법까지 관찰했어요.
2️⃣ 분석: 각 지하철 마다 배차간격을 계산했고, 지하철을 타기위해 기다리는 사람들의 수를 파악했으며, 사람들의 행동 방식 패턴을 파악하려고 했어요.
3️⃣ 인터뷰: 기다리는 사람들에게 기분이 어떤지, 그리고 이 상황을 어떻게 더 개선시킬 수 있을 것인지에 대해 물어봤어요.

​

사람들이 서비스를 어떻게 이용하고 있는지에 대해 정보를 최대한 많이 모아 봤는데...

​

... 그리고 아무것도 생각이 안 났어요.

​

몇 가지 무난한 해결책이 있긴 했어요. 단순히 운행하는 기차 수를 늘리는 거 였는데, 충분히 좋은 해결책은 아니죠.

좌절한 채, 주저 앉았어요. 다음 지하철이 도착해서 문이 열리고 사람들을 태울 때, 저는 저 멀리서 한 외침을 들었습니다:

​

"움직이세요! 좀! 더 들어가세요!"

​

한 우람한 지하철 직원이 사람들에게 소리치고 있는 것을 찾을 수 있었고, 직원에게 가 문제가 뭔지 물었어요.

​

"기차에 더 많은 사람들이 탈 수 있는데도 안 들어 갑니다!"

​

잠시 생각에 빠졌습니다.

​

다음 지하철이 들어왔어요.

​

승객들이 타기 시작했어요.

​

그리고 저도요.

​갑자기 지하철이 출발했고, 설 자리를 찾으려고 했어요. 갑자기 지하철에 타겠다는 결정을 한 제 자신에게 놀란 채로 말이죠. 계속해서 땀에 절은 많은 사람들 사이에서 설 자리를 찾다가 갑자기 진짜 문제가 뭔지 깨달았어요.

​

각 좌석 사이에는 10명이나 더 들어갈 수 있는 자리가 있었던 거예요. 하지만 사람들은 좌석 사이로 들어가지 않았어요. 그저 내려야 할 역에 내리지 못하게 될까봐 두려워 하며 문 주변에 모여있었습니다.

​

디자인 설계가 실패했을 지라도, 지하철에 탑승했던 것이 진짜 문제를 명확하게 알려주었어요. 깊이 내재 해 있는 문제가 무엇인지 발견했고, 이는 관찰, 분석 그리고 인터뷰를 통한 것이 아니라 제 자신이 스스로 느꼈던 것이었어요.

진심 어린 공감

무엇보다도 50일 동안 50개의 문제를 해결하고자 했던 건, 디자인 프로세스라는 것이 가지고 있는 제약이 우리로 하여금 효과적인 해결책을 만들어 내는데 있어서 중요한 점을 무시하게 한다는 것이었어요. 진심어린 공감을 놓치게 한다는 거죠.

​

진심어린 공감은 Focus Group에서 자연스럽게 나오는게 아니예요. 분석하는 과정에서 나오는 것도 아니죠. Personas, Empathy Maps에서 시작되는 것도 아닙니다.

​

진심어린 공감은 사람에서 부터 시작됩니다.

몰두를 통한 혁신

이 여정은 하나의 디자인 프로세스로서 우리가 어떻게 사람들을 이해하는 지에 대해 근본적으로 이의를 제기했어요. 문제해결의 질은 문제를 이해하는 우리의 능력과 직접적으로 닿아 있어요. 매일 새로운 문제를 해결하려 할 때 마다, 단순히 사람들의 행동과 문제를 분석하는 것 만으로는 충분치 않다는 걸 배웠습니다. 그 문제를 제 문제로 만들어야 했던 거죠.

토리노(42일 째 되던 날)의 한 길에서 노숙자들과 앉았을 때 부터, 안트베르펜(벨기에의 한 도시, 23일 재 되던 날) 길거리에서 길을 잃었을 때, 그리고 취리히(스위스의 가장 큰 도시, 38일 째 되던 날)에서 돈도, 힘도 없었던 때까지 이 여정은 저를 익숙치 않은 상황으로 잠식시켰고 고립 안에서 그 어느 때 보다 더 효과적으로 배우고, 분석하고, 해결하게 만들었습니다.

​

공감적 연구는 우리가 기능적인 면을 넘어서는 사용자의 진정한 니즈를 이해할 수 있게 해주고, 이에 따라 더 적절한 디자인을 개발해 낼 수 있게 합니다. 사실 공감적 연구는 그 자체로 봤을 때 가장 중요해 보이는 여러 가치있는 디자인 과정과 도구들 중 하나일 뿐이에요. 하지만 좋은 디자이너들이 도구를 이해할 때, 훌륭한 디자이너들은 사람을 이해합니다.

모두를 위한 방법

공감적 연구는 새로나온 개념이 아닙니다. 하지만 이 공감적 연구라는게 대개 새로운 상품을 만들어 내는 일종의 도구로서만 취급되거나, 이런 중요한 조사과정을 감당할 수 있는 예산과 고객을 갖춘 디자인 에이전시의 영역으로만 취급됩니다. 제가 말하는 공감적 연구는 단지 이렇게 취급되어서만도 안되고, 공감적 연구가 이런 것 만도 아닙니다. 작지만 최고의 해결책은 복잡하고 깊이 내재되어 있는 필요성에 대한 진심어린 이해에서 오는 것이니까요.

새로운 프로젝트를 시작할 때 마다 수천 마일이나 되는 거리를 항상 여행할 순 없어요. 그리고 통상의 현실이 우리 프로젝트의 시간과 자원에 제약을 걸죠. 하지만 사람에 대해 깊게 이해하고자 하는 데에는 연구에 방대한 시간이 소요되지도 않고 다른 과정에 피해를 주지도 않습니다.

​

아래의 방법은 제 여정에서 사용하기 시작한 것들이고, 계속해서 새로운 방법들을 터득하기 시작했어요. 이것들을 이용하시고, 발전시키고, 여러분 만의 버전으로 만들어 보세요. 우리의 목표는 사람들을 더 깊게 이해하는 것이고 그렇게 함으로써 그들의 문제를 더 효과적으로 해결해 나가는 것입니다.

식은땀 흘리기

황홀경이거나 무력함이거나 혹은 안도감이거나, 사람들이 느끼는 것을 똑같이 느끼기 위해 뭐든 지 하세요. 여러분이 여행계획을 위한 웹사이트를 만든다고 가정합시다. 원래 존재했던 UX를 사용하려는 유혹이 찾아오죠. 혁신은 기존에 존재해 왔던 것에 대한 불신과, 더 스마트하고 직관적인 경험을 창조해 내고자 하는 열망에서 나오는 것입니다.

​

지금껏 한 번도 가본적이 없던 두 장소를 골라보고 그곳으로 여행을 떠나보세요. 이 때, 어떤 기술도 사용하시면 안됩니다. 당신은 곧장 익숙치 않은 환경에서 길을 잃었다는 불안한 감정을 맞닥뜨리게 될 거예요. 하지만 어느 기술도 사용하지 않고 여행을 떠난다는 건 여러분이 의지했던 기존의 디자인에 가치로운, 아무도 건들지 않은 통찰력을 불어넣어 줄 거예요. 어떻게 길을 찾았나요? 어떤 랜드마크가 여러분을 이끌었죠? 어떤 과정을 사용했나요? 당신이 사용한 과정이 서비스에 어떻게 반영될 수 있을까요? 여러분의 사용자들이 느끼는 감정을 똑같이 느낀다는 건 복잡한 시나리오를 더 잘 이해할 수 있게 해 줄 거예요. 그리고 결과적으로 더 효과적으로 해결할 수 있는 힘을 줄 겁니다.

사람들을 만나세요

데이터 분석이 아닌, 공감적 이해를 얻기 위해서는 그 사람들이 있는 곳으로 가, 그러니까 우리 연구실이 아닌 그들의 환경 안에서 그 사람들을 만나세요. Focus Group은 사람들의 경험을 잘 이해하게 해 주지만, 진심어린 이해를 하게끔 해주진 않아요. 경험이라는 건 느껴지는 것이라는 걸 우리는 알고 있어요. 경험이라는 건 감정적인 것이지 이성적인 것이 아닙니다. 우리가 설정해 놓은 환경 안에서 사람들의 경험을 듣는 것은 사람들의 스스로의 생각과 행동을 합리화해 달라고 하는 것과 마찬가지예요. 이런 식의 의사소통은 우리로 하여금 정확한 그림을 절대로 그리지 못하게 할 겁니다.

​

사용자 인터뷰만 진행할 것이 아니라, 우리는 사람들을 만나야 합니다. 욕실용품 소매업자를 위해서 인터넷 쇼핑몰을 만들어 보세요. 쇼룸으로 가서 사람들이 상품을 어떻게 대하는지 관찰해 보세요. 사람들의 환경에서 사람들을 만나는 것은 상품에 대한 그 사람들의 생각을 물어볼 수 있게 할 뿐 더러, 그들의 의견을 어떻게 내 보이는지 직접적으로 확인할 수 있게 해 줍니다. 그들이 의사결정을 할 때 어떤 단계를 거치는지? 어디를 바라보는지? 의사결정을 하기 위해 어떤 상품과 비교해 보는지? 이러한 통찰은 더 나은 결정을 하게 해주고, 더 직관적인 결과를 낼 수 있게 해 줍니다.

우리 모두 디자이너 입니다

공감적 연구가 무언가를 가르쳐 준다면, 지구에 있는 모든 사람들이 디자이너라는 걸 깨닫게 되고 겸허해집니다. 심지어 대개의 사람들이 우리보다 훨씬 문제해결을 잘 하기도 해요. 책상 정리하는 방식부터 얼굴을 확인하기 위해 창문을 사용하는 것 까지, 우리 모두는 어떤 문제를 해결하기 위해 신중하게 행동합니다. 공감적 조사는 사람들이 이미 본인에게 주어진 장애물을 어떻게 극복하는지 관찰할 수 있게 해 주고, 우리가 기대했던 것 보다 더 훌륭한 해결책을 알려주기도 합니다.

​

데일리 뉴스 피드앱을 디자인 하고 있나요? 도서관으로 가서 사람들이 정보를 얻기 위해 어떻게 행동하는지 직접 보세요. 책 끝을 접는 것 부터 빠르게 읽기 위해 연필로 밑줄을 긋고, 상호 참조를 잘 하기 위해서 저널을 차례대로 세워두는 것 까지. 직접 보게 되면 사람들의 반쪽 해결책을 더 실용적인 경험과 결합할 수 있게 통찰력을 선사해 줄 거예요.

현장에서 프로토타입 제작하기

 

우리가 배운 것들을 디자인 의사결정에 반영하기 위해서 우리는 주로 작업실에 있는 고품질 스크린을 이용합니다. 펜을 들고 작업실 밖으로 나가 여러분이 만든 서비스를 사용할 것 같은 사람을 찾아가세요. 그 다음 디자인 하세요. 곧 사용자가 맞닥뜨리고 있는 방해, 복잡성, 제한을 해결해야 할 거예요. 이게 여러분의 디자인 의사결정에 어떤 영향을 줄까요?

​

사람들을 사로잡는 더 많은 테크닉들이 있지만, 이것들은 단지 몇 가지 시작 단계에 불과합니다. 궁극적으로 공감적 연구는 사용자들에게 무엇을 원하는지 물어보는 과정이 아니라, 우리 자신을 위해 사용자들의 필요를 이해하기 위한 과정인 거죠.

 

해결책이긴 한데...

그래서, 지하철에 타고 바쁜 사람들 사이에서 찌그러지고, 사람들의 짜증을 느낀 것에 대한 결과가 뭘까요?

​

처음으로 나온, 나름 실현가능한 해결책이었습니다.

사람들에게 더 가까이 붙어달라고 제안하기 위해 지하철 닫히는 문을 활용했어요. 하지만 이것만으로는 충분치 않다는 생각이 들었죠. 뭔가 효과적인 대안이기 보다는 공공 서비스 차원의 느낌이 나잖아요.

해결책: 놀이

앞의 해결책에 만족하지 못 했기에 더 열심히 생각했고, 내 경험과 직관적인 응답을 떠올리며 스스로에게 질문을 하나 던졌습니다. "이런 조직적인 문제를 사람들이 참여하고 싶어하는 재밌는 경험으로 어떻게 바꿀 수 있을까?"

​

해결책이요? 저는 하나의 "놀이"를 만들었어요. 지하철 바닥을 모노폴리 게임으로 바꿨습니다. 사람들은 감옥에 서있는 것 보다 좌석으로 이동하고 싶어 했죠. 사람들이 참여하고 싶어하는 해결책이었습니다.

'50일 동안 50문제 해결하기'가 출판된 후 정말 많은 관심을 받았고 기대치 못 한 상도 받게 되었습니다. 위의 해결책은 가장 많이 화두에 올랐고, 가장 많이 공유되었습니다.

끝으로,

공감적 이해는 혁신을 일으키기 위한 중요한 도구입니다. 우리의 디자인을 이용할 사람들을 잘 이해한다면, 우리의 의사결정, 디자인 그리고 결과는 훨씬 더 훌륭해 집니다. 2517마일의 여정은 혁신을 일으키길 원한다면 사람들의 경험을 분석하는 것에서 넘어서서, 그 경험을 우리의 것으로 만들어야 한다는 것을 가르쳐 줬어요.

​

사람들을 잘 이해하기 위해서 우리는 밖으로 나가 직접 경험해 보아야 하고, 이로써 더 좋은 분석과 해결을 할 수 있게 해줄 거예요. IDEO의 파트너인 Deogo Rodriguez는 말했습니다.

​

"행동함으로써 알게 된다. 행동하는 것이 알게되는 것의 해결책이다."

출처: https://www.smashingmagazine.com/

리터럴 이란 무엇일까요?  MDN 공식홈페이지를 살펴보면,

Literals represent values in JavaScript. These are fixed values—not variables—that you literally provide in your script.

리터럴이란 개발자가 스크립트에 입력한 value를 보이는 그대로 나타내 주는 표현방식이라 말하고 있습니다.

아래와 같은 data type들은 모두 자신만의 리터럴을 가지고 있습니다.

• Array literals
• Boolean literals
• Floating-point literals
• Numeric Literals
• Object literals 🌸
• RegExp literals
• String literals

그 중 객체 리터럴이란,

An object literal is a list of zero or more pairs of property names and associated values of an object, enclosed in curly braces- { }.

'property - value' 짝을 중괄호( { } )로 묶어 표현하는 리터럴을 가진다고 하네요.

객체 리터럴을 실제 코드에서 어떻게 활용할 수 있을 지 알아보겠습니다!

✨ 객체 리터럴로 이렇게 객체를 만듭니다.

  const objectName = {
    key : value, 
    camelCase : value,
    'kebab-case' : value,
    ['kebab-case-with-brackets'] : value
  };

1. 객체는 다른 data와 같이 변수로 할당될 수 있습니다. 할당 되는 변수명이자 객체명을 정해줍니다.
2. key - value pair은 중괄호 { } 로 감싸지며, 각 pair은 쉼표  ,  로 구분합니다.  
3. key naming은 다양한 형태로 할 수 있지만 camel case🐫로 쓰는게 가장 깔끔해보입니다!

✨ 객체외부에서 key-value 값에 접근하기 위해선 아래 두 가지 방법을 상황에 따라 선택하여 사용할 수 있습니다.

• dot notation(마침표 표기법)
• bracket notation(대괄호 표기법)

✨ 객체를 다뤄보겠습니다.

1️⃣ {key : value} 만들기

• objectName.key = 'value';
  ➡️ 객체의 특정 key에 value를 할당해요.

2️⃣ {key : value} 지우기

• delete objectName.key;
  ➡️ delete keyword를 사용해서 객체의 특정 key-value pair를 삭제할 수 있어요.

3️⃣ 객체들의 value 값 만 모두 뽑아내기

• Object.values() 
  ➡️ Object.values() method를 사용해서 객체의 value만 array로 추출할 수 있어요.

4️⃣ key-value pair를 모두 뽑아내기

• Object.entries()
  ➡️ Object.entries() method를 사용해서 객체의 key-value pair 묶음을 배열로 받을 수 있어요.

🎁 객체 리터럴을 이용해 크리스마스 선물 리스트를 뽑아보았습니다. 

// My Christmas Gift List for My Friends
let christmasGiftList = { 
	Harry : 'Umbridge Tea Pot Set',
	Ron : 'Bottled Butterbeer',
	Hermione : 'Crookshanks Soft Toys',
	Dobby : 'A pair of socks',
	'Draco-Voldmort' : "Bertie Bott's Every Flavour Beans"
};

console.log(`We need '${christmasGiftList.Harry}' for Harry, '${christmasGiftList.Ron}' for Ron, '${christmasGiftList.Hermione}' for Hermione, and '${christmasGiftList.Dobby}' for Dobby! 🎁 \nAnd for Draco and Voldmort... '${christmasGiftList['Draco-Voldmort']}' will be fair enough!`);


// Oh I forgot Neville!
christmasGiftList.Neville = 'Chocolate Frog';

console.log(`And for Neville, '${christmasGiftList.Neville}' would be fine...?`);


// Definitely, I don't wanna buy gifts for Draco and Voldmort
delete christmasGiftList['Draco-Voldmort'];

// Finally...!
console.log(`Finally, I need to buy ${Object.values(christmasGiftList)}!`);

// I need correct list.
console.log(`My Christmas Gift List: ${Object.entries(christmasGiftList)}`)

✨ 객체 외부에서 {key : value} 에 접근하기 위해선 dot notation 과 bracket notation을 사용할 수 있었는데요.

특히나 bracket notation을 사용해야만 하는 때가 있습니다.

1. 동적으로 값을 전달 받아 리턴할 때
2. 동적으로 값을 삭제할 때
3. 동적으로 값을 추가할 때

🍷 저녁식사를 정하며 bracket notation을 이용해 동적으로 값을 리턴 · 삭제 · 추가 해봅시다.

const dinner = {
	appetizer : 'dark chocolate',
	mainDish : 'chocolate fudge',
	dessert : 'chocolate pudding'
};

// bracket notation을 사용해 값을 리턴
function whatDoYouWantForMainDish(obj, key) {
	return obj[key];
};
console.log(`I wanna eat ${whatDoYouWantForMainDish(dinner, 'mainDish')} for main dish today :)`);

// bracket notation을 사용해 값을 추가
function iWantMoreDessert(obj, key, value) {
	obj[key] = value;
};
iWantMoreDessert(dinner, 'dessert2', 'Fondant au chocolat');
console.log(dinner);

// bracket notation을 사용해 값을 삭제
function noMoreDessert(obj, key, value) {
	delete obj[key];
};
noMoreDessert(dinner, 'dessert2', 'Fondant au chocolat')
console.log(dinner);

✨ 위에서 Object.values(), Object.entries() 두 가지 method를 알아 보았는데요.

이 ❓method❓ 라는 개념이 좀 헷갈리더라구요. 한 번 짚고 넘어 갈게요.

Method란, MDN 공식홈페이지에선, 아래와 같이 정의하고 있습니다.

A method is a function which is a property of an object. There are two kinds of methods: instance methods which are built-in tasks performed by an object instance, or static methods which are tasks that are called directly on an object constructor.

객체 안의 함수를 method라 하며, 객체의 동작을 정의하고 객체와 관련된 작업을 수행하는 역할을 하는 함수라 볼 수 있겠습니다.

1️⃣ instance method

• 개발자가 객체 안에서 정의한 함수를 instance method라 합니다.

class Car {
  start() {
    console.log("The car is started.");
  }
}

const myCar = new Car();
myCar.start(); // "The car is started."

✅ car 라는 객체로 하여금, console에 "The car is started." 라는 문구를 출력 하게끔 하는 start() 함수를 개발자가 정의했죠! 이 start() 함수를 Instance method 라 하는 것입니다.

위 코드는 Class 문법으로 객체를 만든 경우입니다. Class 문법으로 만든 객체는 object라고도 하지만, 특별히 instance라고 부릅니다. 

2️⃣ static method

• ECMAScript에서 정한 JS 내장객체 안의 함수를 static method라 합니다.

let randomNumber = Math.random(); 
// Math 클래스의 static 메서드 random을 호출합니다.

✅ 코드 내에서 Math라는 객체를 정의하지 않았음에도, random한 숫자가 randomNumber 변수에 할당되는데요. 사실 JS 내 Math 라는 객체가 이미 존재하기 때문에, 따로 정의할 필요없이 바로 사용할 수 있는 거랍니다. 편리하죠?

✅ 이런 내장객체를 빌트인 객체라고도 부르는데요. 이에 대해서도 곧 포스팅 할 예정이랍니다.

 ECMAScript란, JavaScript의 표준화를 담당하는 기구인데요.
JavaScript 코드가 여러 플랫폼에서 동일하게 작동하도록 보장하고, 개발자들이 효율적이고 표준화된 방식으로 작업할 수 있도록 도와주기 위해 여러 표준 코드를 정합니다. 이로써 호환성과 코드 품질을 향상시킬 수 있다네요.

객체 정도 만들어보니 이제 슬슬 프로그래밍 하는 느낌이 듭니다.

다음 편엔 생성자 함수로 객체를 만들어 보겠습니다 *^^*🖐️

JS는 객체지향 프로그래밍 언어입니다. MDN 공식홈페이지의 JS 참고서를 살펴보면:

In JavaScript, most things are objects, from core JavaScript features like arrays to the browser APIs built on top of JavaScript.

JS에서 아주 중요한 개념인 '배열'부터 '브라우저 API'까지 대부분의 것들이 '객체'라고 하니, 짚고 넘어가지 않을 수 없겠네요.

객체 문법을 본격적으로 공부하기 전, JS에서는 왜 모든 걸 객체로 만드는 건지, 왜 이 객체 문법을 공부해야 하는 건지 궁금해졌습니다!

✨ 객체지향 프로그래밍이란 무엇일까요?

객체지향 프로그래밍은, 자동차를 만드는 공장과 같습니다.

자동차 공장에서는 자동차 도면(class)을 만들어 둘 수 있는데요. 그 도면에 따라 자동차(object)를 여러 대 만들 수 있습니다.

이 자동차들은 같은 도면으로 만들었기에 도면에서 정의한 '자동차라면 갖춰야 할 필수 속성(property)과 기능(method)'을 모두 동일하게 가지고 있을 거예요.

✨ 그럼 왜 '객체'라는 개념으로 데이터를 묶어서 프로그래밍 하는 걸까요?

코드의 재사용성을 높이기 위해서요.

같은 코드를 여기저기 반복해서 작성하면 코드가 엄청 지저분해지고 길어지겠죠!

자주 쓰이는 코드를 미리 모듈화 해 두고 필요할 때 간단히 호출할 수 있도록 하면, 전체적으로 코드가 깔끔해 지고 결국 유지보수 하기 좋아집니다.

✨ 절차지향 프로그래밍과 객체지향 프로그래밍은 어떻게 다를까요?

절차지향 프로그래밍에서는 단계적인 명령문 실행을 중점으로 코드가 구성 됩니다.

// 파스타 레시피 
function makePasta() {
  console.log('물 끓이기');
  console.log('파스타 삶기');
  console.log('재료 섞기');
  console.log('접시에 담기');
}

// 샐러드 레시피 
function makeSalad() {
  console.log('야채 썰기');
  console.log('재료 섞기');
  console.log('접시에 담기');
}

// 파스타랑 샐러드 만들기
makePasta();
makeSalad();

❓ 만약, makeCreamPasta() 라는 함수를 만들고 싶다면, 다시 물끓이기 부터 새로 함수를 정의해야 할까요? 기존에 있었던 makePasta() 라는 함수와 레시피가 모두 겹치는데요?

객체지향 프로그래밍에서는 먼저 객체를 만들고 이 객체들이 서로 상호작용하며 문제를 해결 할 수 있도록 코드가 구성 됩니다.

// 파스타 레시피
class makePasta {
  boilWater() {
    console.log('물 끓이기');
  }

  boilPasta() {
    console.log('파스타 삶기');
  }
  
  mixIngredients() {
    console.log('재료 섞기');
  }
  
  serve() {
    console.log('접시에 담기');
  }
}

// 크림파스타 레시피
class makeCreamPasta extends makePasta {
  addCreamSauce() {
    console.log('크림소스 추가하기');
  }
}

const pasta = new makePasta();
const creamPasta = new makeCreamPasta();

// 기존에 있었던 파스타 레시피를 이용해 크림파스타 만들기
creamPasta.boilWater(); // 물 끓이기
creamPasta.boilPasta(); // 파스타 삶기
creamPasta.mixIngredients(); // 재료 섞기
creamPasta.addCreamSauce(); // 크림소스 추가하기
creamPasta.serve(); // 접시에 담기

✅ 기존에 있었던 makePasta()의 레시피를 모두 받아와 makeCreamPasta()를 간단하게 정의했고, 이제 다른 파스타 레시피도 makePasta()를 활용해서 쉽게 추가할 수 있을 거예요.

✨ 이제 객체를 만들어 봅시다. 4가지 방법이 있습니다.

1. 객체 리터럴(Object Literal)
   : 중괄호 {}를 사용하여 객체를 직접 만드는 방법입니다. 이 방법은 간단하고 빠르게 객체를 생성할 수 있어요.
2. 생성자 함수(Constructor Function)
   : new 키워드와 함께 함수를 사용하여 객체를 만드는 방법입니다. 함수 내부에서 this를 사용하여 속성을 정의하고 객체를 생성합니다.
3. Class
   : ES6부터 도입된 클래스 문법을 사용하여 객체를 만드는 방법입니다. 클래스는 생성자와 메서드를 포함하는 객체를 쉽게 만들 수 있도록 도와줘요.
4. Object.create() 메서드
   : 기존 객체를 프로토타입으로 활용하여 새로운 객체를 만드는 방법입니다.

다양한 상황과 개발자의 선호도에 따라 방법은 다를 수 있습니다. 하지만, 요즘엔 ES6(ECMAScript 2015)부터 도입된 class 문법을 가장 많이 사용합니다.

class 기반의 객체 생성 방법은 객체지향 프로그래밍 개념을 더 명확하게 표현하고, 코드를 구성하는 데 도움을 주기 때문에 많은 개발자들이 선호한다고 하지만,,

전 아직 이해 못했기 때문에 🤷🏼‍♀️ 앞으로 공부를 해 나가며 답을 알아 가보도록 하겠습니다,,^^;

답을 알게 되면 이 포스트에 추가 해 둘게요!