ITSelfer

- 시행기관 : 한국데이터베이스진흥원

* 출처 : https://blog.naver.com/sbj622/221838444533

ITIL의 구성

1. Service Support (운영, Day-to-Day, User)

: IT 서비스 User가 안정적이고 향상된 IT 서비스를 보장받는 것에 있어 필요한 Process

 1) Service Desk (SD)

 2) Configuration Management (CfM)

 3) Incident Management (IcM)

 4) Problem Management (PbM)

 5) Change Management (ChM)

 6) Release Management (RM)

2. Service Delivery (전략, Year/Time 별, Business 주체 -> Customer)

: IT 서비스 제공자가 User에게 충분히 만족할 만한 지원을 제공하기 위해 필요한 Process

 1) Service Level Management (SLM)

 2) Availability Management (AvM)

 3) Capacity Management (CpM)

 4) IT Service Continuity Management (ITSCM)

 5) Financial Management For IT Services (FnM)

※ ITIL Process Model

[Service Delivery] - 전략, Year/Time

* Customer <-- "SLA" --> {SLM} - {AvM, CpM, SCM} - {FnM}

[Service Support] - 운영, Day-to-Day

* User --> "장애, 서비스요구" - CMDB

{SD  - SPOC, 기록} - {IcM - 빠른 복구} - {PbM - 원인 규명} - {ChM - 변경 승인} - {RM - 배포/구현, CfM - CI 관리}

※ Deming's Quality Cycle - Quality Assurance (품질 보증)

{A -> B -> C -> D}

 A. Plan (Chm) - 새로운 변경에 대한 기획

 B. Do (RM) - 계획을 구축/구현

 C. Check (IcM) - 새로운 환경에서 발생된 새로운 장애 감지

 D. Act (PbM) - 새로운 장애의 원인 파악

출처 - https://blog.naver.com/gkgkrmek/221455378168

ITSM / ITIL

* 용어 정리

- ITSM (Information Technology T Service Management)

: 사내의 IT 서비스가 안정적이고 지속적인 공급을 목표로 관리한다는 방법입니다.

- ITIL (Information Technology Infrastructure Library)

: ITSM process에 의해 검증된, OGC가 집대성한 Best Practice(최선의 책략, 방법) 모음집입니다.

* 자격증

> ITIL Foundation

 - 자격: X

 - 학점: 2

 - 출제방식: 1시간, 객관식 40문항

> ITIL Practitioner

 - 자격: ITIL Foundation 취득, 공인된 교육 프로그램 이수

 - 학점: 15~16

 - 출제방식: 2시간, 케이스 스터디 형식의 객관식 40문항

> ITIL Manager

 - 자격: ITIL Foundation 취득, 12일 코스의 모든 IT 서비스 관리 프로세스에 대한 전문 교육

 - 출제방식: 6시간 (서비스 공급 - 3시간, 서비스 지원 - 3시간), 케이스 스터디 형식의 주관식 논술형 약 20 여 문제

출처 - ITIL 서비스관리 핸드북; 저자-김명식

대중 음악의 구성 요소에 따른 진행의 순서를 알아보았습니다.

더불어, Studio One 4의 'Loops' 기능을 통해 악기 별로 제공되는 샘플들을 조합해 보았습니다.

1. Critical Listening(크리티컬 리스닝)

1-1. 대중 음악의 구성 요소에 따른 진행 순서

1) 음악의 구성 요소

- Intro(인트로) : 장르, 분위기 조성

- Verse(벌스) : 곡의 배경, 스토리 전개

- PreChorus(프리코러스) : 분위기 고조

- Chorus(코러스) : 절정, 곡의 주제

- Interlude(인털루드) : 연속성, 분위기 유지

- Bridge(브릿지) : 극적인 분위기 준비

- Outro(아웃트로) : 맺음, 분위기 정리

- Vamp : 밸런스, 구간 반복

1-2. 대중 음악의 진행 순서 예시

ex)

1) 이예준 - 중얼거린다

Intro ~ Verse1 ~ PreChorus ~ Chorus ~ Interlude ~ Verse2 ~ PreChorus ~ Chorus ~ Bridge ~ Chorus ~ Outro

2) 에일리 - 첫눈처럼 너에게 가겠다

Intro ~ Verse1 ~ Chorus ~ Interlude ~ Verse2 ~ Chorus ~ Bridge ~ Chorus ~ Outro

3) 장덕철 - 그날처럼

Verse1 ~ PreChorus ~ Chorus ~ Interlude ~ PreChorus ~ Bridge ~ Chorus ~ Outro

2. Studio One 4 - Loops

2-1. 실행 순서

[Create a new Song] - [Empty Song] - [Loops] - {장르 선택} - 각 장르에 맞게 제공된 샘플 조합

2-2. 예제

1) POP

2) DupStep

3) Blues

평소 음악을 들을 때, 습관처럼 Critical Listening을 하고,

음악을 구성하는 요소와 그것들을 조각하는 순서, 방식을 충분히 생각하자...!!

 

Studio One 4를 통해 기본적인 구성 요소 이름들을 알아보았고, 간단한 비트를 만들어보았습니다.

1. 드럼의 구성 요소 이름

 - Snare, Kick, Hihat(HH), Symbol, Tom(High, Mid, Low) 등

2. 비트 예제

2-1. 실행 순서

[Create a new Song] - [Empty Song] - [Instruments] - {PreSonus - impact 삽입} - IMPACT XT에서 드럼 종류 선택

2-2. 예제

1) (HH + Kick + Snare)

2) (HH + Kick + Snare)

3) (HH + Kick + Snare), Fill in

드럼의 비트를 토대로 곡의 속도를 조절하고 분위기를 조성하고,

필인(Fill in)의 적절한 인입과 조합을 통해 곡의 진행 순서를 정하자...!

 

객체 지향적 설계 원칙 : SOLID

- 앞서 포스팅했던 객체 지향적 사고를 5가지 원칙으로 정의.

- 5가지 항목이 서로 연관되어있어 특정 원칙을 나눠 이해하기보단 종합적으로 이해하는 것이 도움이 됨.

(1) 단일 책임 원칙 (Single responsibility principle; SRP) | 클래스는 단 한 가지의 책임만을 가져야 한다.

* 미 적용 시 문제점 : 하나의 클래스가 여러가지 책임을 가지고 있다면, 수 많은 커스터마이징을 필요로 하는 유지보수 작업들을 처리할 때 이곳 저곳 소스를 헤집어 여러 군데를 수정해야 하는 상황을 초래할 수 있음.

 -> 비효율적인 커스터마이징 업무.

* 적용 방안 : 구현 할 당시에는 기능(함수)을 수행하는 역할 별로 세분화하여 코딩하고(ex, MVC), 각 기능에 상세한 명세를 주석으로 추가.

(2) 개방-폐쇄 원칙 (Open-closed principle; OCP) | 기능을 변경하거나 확장할 수 있으면서, 그 기능을 사용하는 코드는 수정하지 않는다.

* 미 적용 시 문제점

 1) 다운 캐스팅(이미 캐스팅된 객체를 다시 원래의 상태로 캐스팅하는 작업)을 하게됨.

 -> 캐스팅된 객체의 자료형이 모호해짐.

 2) 단위 별 수정 사항이 들어왔을 때 마다 실제 기능을 수행하는 함수에서의 수정이 불가피해짐.

 -> 수정되야할 부분이 중구난방식이 됨.

* 적용 방안 : 결국은 코드 수정의 유연함을 담아야 하기 때문에, 변화가 예상되는 기능을 추상화(오버로딩, 오버라이딩 등)하여야 함.

(3) 리스코프 치환 원칙 (Liskov substitution principle; LSP) | 상위 타입의 객체를 하위 타입의 객체로 치환해도 상위 타입을 사용하는 프로그램은 정상적으로 동작해야 한다.

* 미 적용 시 문제점 : 상위 타입의 객체 자체가 가지고 있는 기능이 하위 타입으로 인해 변경되어 상위 타입의 객체를 사용하던 기능들이 전체적으로 변경되는 에러가 발생.

 -> 기능 변경에 있어 유연함이 떨어져 '개발-폐쇄 원칙'과 같이 중구난방적으로 수정이 필요한 상황을 초래함.

* 적용 방안 : 상위 타입의 객체를 사용하는 기능들을 확인하고나서 고정시켜야 할 공통적인 기능은 상위 타입에 세팅하고 나머지 세부적인 변경 사항들은 하위 타입을 여러 케이스로 만듦. 하위 타입의 세부적인 기능들을 세팅 할 하나의 기준을 잡아 상위 타입에 세팅하는 방법도 있음.

(4) 인터페이스 분리 원칙 (Interface segregation principle; ISP) | 인터페이스는 그 인터페이스를 사용하는 클라이언트를 기준으로 분리해야 한다.

* 미 적용 시 문제점 : Java에선 .class 파일을 로딩하는 과정에 동적으로 링크 과정을 발생시키지만, C/C++ 에서는 링크시키는 과정을 컴파일 시 항상 거치기 때문에, 인터페이스가 분리되어 있지 않으면 하나의 인터페이스에 링크되어있는 소스들 전부가 재 컴파일을 해야하는 상황이 발생.

 -> 재 컴파일이 될 필요가 없는 클래스들의 지속적인 재 컴파일로 인한 컴파일 속도 이슈와 '단일 책임 원칙'을 거슬러 각 인터페이스의 책임에 대한 정의가 모호해짐.

* 적용 방안 : '단일 책임 원칙'을 인터페이스에 부여해 각 클래스(클라이언트)의 역활에 따라 인터페이스를 만들어줌.

(5) 의존 역전 원칙 (Dependency inversion principle; DIP) | 고 수준 모듈은 저 수준 모듈의 구현에 의존해서는 안 된다. 저 수준 모듈이 고 수준 모듈에서 정의한 추상 타입에 의존해야 한다.

* 미 적용 시 문제점 : 일정 수준 안정화가 된 프로그램에서의 수정에 있어서 고 수준 모듈(상위 타입, 큰 틀에서의 프로세스)은 최대한 변경을 피하고 저 수준 모듈(하위 타입, 실제 기능을 동작시키는 프로세스)을 변경하여 대처해야 '리스코프 치환 원칙'을 위배하는 경우를 줄이고 변경 범위가 작아질텐데 '의존 역전 원칙'을 어길 시, 개발 수정 범위가 다양한 범위로 늘어남.

 -> '리스코프 치환 원칙'과 마찬가지로 개발 수정 범위가 중구난방식으로 유연함이 떨어지고, 작은 단위의 수정 사항에도 패키지 단위로 확장되어 배포해야할 상황의 소프트웨어를 만들어내게 됨.

* 적용 방안 : '리스코프 치환 원칙'을 따라 설계하여 상위 타입은 수정없이 기능을 고정하되, 기능 변경에 대한 요청 사항이 있을 시 하위 타입의 수정을 통해 유연한 기능 변경을 할 수 있도록 추상화를 적절히 사용할 수 있도록 설계해야 함.

※ "코드 변화에 있어 유연한 대처가 가능하도록 설계를 해야한다." - SOLID 원칙

다음 포스트에서는 SOLID 원칙과 더불어 사용되는 DI와 서비스 로케이터에 대해 알아보도록 하자.

출처: 최범균, 『개발자가 반드시 정복해야 할 객체 지향과 디자인 패턴』, 인투북스(2014)

객체 지향(Object Oriented) 이란?

1) 객체 | 기능(Operation)과 함수(Method)로 구성.

ex) 식당 주문 Process.

2) 인터페이스와 클래스 | 객체가 제공하는 기능(Operation)을 명세하는 인터페이스. 실제 객체의 구성의 집합은 클래스.

ex)

{매장 클래스에 명세된 Interface 목록}

 - 날짜 및 영수증 번호 등.

 - 결제 수단 집합 배열.

 - 주문을 받는 Method.

 - 결제 Method.

 - 상품을 건네주는 Method.

3) 메세지 | 클래스에서 인터페이스의 명령에 따라 객체의 기능(책임)을 전달하는 매개체.

ex)

 (1) 매장의 환경 설정 값을 확인한다.

 (2) 손님이 들어오면 주문을 받는다.

 (3) 해당 상품에 대해 결제를 진행한다.

 (4) 결제가 정상적으로 완료되면 상품을 제조하여 손님에게 건네준다.

4) 의존 | 각 객체가 서로를 생성하거나, 서로의 기능(Operation, Method)을 사용해야하는 흐름에 따른 이념.

ex)

{매장 클래스에서 발생된 결제에 대해서 산술 클래스에 의존하여 산술을 처리하는 방식}

...

#include "clsCalc.h"

...

double clsStore::CalcProcess(short snType) {

clsCalc objCalc = new clsCalc();

if(snType == CASH)

objCalc.CalcCash();

else if(snType == CARD)

objCalc.CalcCredit();

delete objCalc;

}

...

1. 캡슐화(Encapsulation) | 클래스를 모듈화하여 코드 은닉 및 내부 구조 변경의 유연성을 증진시키는 기법을 사용하는 과정.

ex) 공통 모듈화

 - 상품 결제 시 결제 금액, 부가세, 봉사료 등을 계산하는 클래스.

 - 매장 멤버십 고객 포인트 처리에 대해 계산하는 클래스.

 - 직원 출, 퇴근 관련 인사 관리를 담당하는 클래스.

** 데미테르의 법칙(Law of Demeter) 준수 **

 (1) 메서드에서 생성한 객체의 메서드만 호출.

 (2) 파라미터로 받은 객체의 메서드만 호출.

 (3) 필드로 참조하는 객체의 메서드만 호출.

2. 다형성(Polymorphism)과 상속(Inheritance)

[ 다형성 | 한 객체(혹은 메소드, 기능(Operation))를 재사용 필요에 의해 여러 타입으로 변경하여 사용하는 기법. ]

[ 상속 | 상속해주는 클래스(부모(super))가 상속받는 클래스(자식(parent))에게 자신의 기능(Operation)의 권한을 위임시켜주는 기법. ]

 -> 인터페이스 상속 | 추상 함수만을 가지는 추상 클래스를 상속시키는 기법.

 -> 구현(Class) 상속 | 기능 재사용을 목적으로 하는 일반 클래스를 상속시키는 기법.

ex)

 (1) 오버라이딩(Overriding)

  - 부모 클래스에게 상속받은 메소드를 자식 클래스에서 이름과 인자, 반환 값을 모두 같게 재 선언하되, 다른 기능(Operation)을 부여하는 기법.

 (2) 오버로딩(Overloading)

  - 부모 클래스에게 상속받은 메소드를 자식 클래스에서 이름은 같되 인자의 구조는 달라야하며, 반환 값은 제한받지 않는 방식으로 기능(Operation)을
부여하는 기법.

** 상속 기법의 사용에 있어 드러날 수 있는 문제점 **

 1) 부모 클래스의 변경으로 인해 해당 부모 클래스에게 상속을 받은 자식 클래스들의 수정이 불가피해질 수 있음.

 2) 다중 상속이 불가능한 환경에서는 클래스의 불 필요한 증가가 불가피해질 수 있음.

 3) 유사하지만 전혀 다른 기능을 가지는 각기 다른 클래스 구현 시 혼란을 야기시킬 수 있음.

 --> 상속보다는 각 클래스의 조립을 통해 기능을 엮는 방법도 고려하기에 충분하다.

3. 추상화 | 데이터나 프로세스 등을 의미가 비슷한 개념이나 표현으로 정의하는 과정.

ex)

 (1) 계산에 대한 로직 추상화

  - 현금, 카드 및 기타 결제 수단 관련 클래스.

  - 멤버십 포인트 사용 관련 클래스.

  - 할인 수단 관련 클래스.

 (2) 직원 인사에 대한 로직 추상화

  - 출, 퇴근 관련 클래스.

  - 각 직원 별 매출 집계 관련 클래스.

이제 다음 포스트에서 위의 객체 지향적 사고를 바탕으로 구성된 설계 원칙(SOLID) 기법에 대해 알아보도록 하자.

출처: 최범균, 『개발자가 반드시 정복해야 할 객체 지향과 디자인 패턴』, 인투북스(2014)

 디자인 패턴 (Design Pattern) 이란?

- "초기에는 새로운 요구 사항을 빠르게 개발해 주었는데, 시간이 지날수록 간단한 요구 사항 조차도 제 때 개발이 안되는 상황"을 방지.

- 요구 사항의 적용에 있어 유연함(Flexibility)를 얻을 수 있음.

위와 같은 객체 지향적 소프트웨어 개발 방법론이다.

* 절차 지향 (Procedural Oriented) | 데이터를 조작하는 프로시저(혹은 함수)로 프로그램을 구성하는 기법.

장점 : 절차적으로 수행되는 코드에 의한 시간 단축.

 -> 하드웨어의 발전이 더딘 과거 개발 환경에서의 큰 이점으로 작용.

단점 : 수정 사항 반영 시 기존 개발된 절차에 영향을 받는 부분을 전반적으로 수정해야 하기 때문에 효율성 저하.

 -> 하드웨어 사양의 발전으로 인하여 절차적 수행에서의 시간 단축은 큰 의미가 없어짐.

* 객체 지향 (Object Oriented) | 데이터와 프로시저를 객체(Object)로 묶어 관리. 객체 구조에 의존된 기법.

장점 : 객체 구조에서 데이터와 프로시저의 독립성과 프로젝트의 유연성을 동시에 갖출 수 있음.

 -> 거대한 솔루션 급 소프트웨어의 추가 개발과 유지 보수, 커스터마이징까지를 생각한다면 비용을 고려했을때 절차 지향 기법보다 효율적.

 -> 대다수의 소프트웨어 업체의 퀄리티가 이러한 객체 지향적 설계에 대한 노력에 의해 평가됨.

단점 : 초기 설계 단계가 매우 중요한만큼 절차 지향보다 더 많은 시간과 노력이 소모됨.

 -> 초기 단계에서는 더딜 수 있으나 추후 안정성을 고려한다면 반드시 사용되어야 할 기법 중 하나.

디자인 패턴은 객체 지향적 기법을 적용한 소프트웨어에서의 효율적이라고 정형화된 어떠한 규칙을 나타낸다고 볼 수 있다.

디자인 패턴을 들어가기에 앞서, 객체 지향에 대해 더욱 알아보도록 하자.

출처: 최범균, 『개발자가 반드시 정복해야 할 객체 지향과 디자인 패턴』, 인투북스(2014)

WE BOUGHT A ZOO (2011)

| MATT DAMON, SCARLETT JOHANSSON

실화를 바탕으로 제작된 영화라서 그런지 몰라도, 인물 배경과 환경이 다른 영화에 비해 더 사실적으로 표현되어지는 것 같았다.

I think, because of based on true stroy, surrounding environment and people relation was expressed like more reality life compared to the other movie.

아내를 잃은 슬픔을 가진 한 가족이 도심에서 어떠한 이유로 인해 시골 동물원에 포함돼있는 집으로 이사를 가면서 이야기는 시작된다.

A one family, have a sadness losing their's her, has starting the story move out house included the country zoo on account of something reason.

맷 데이먼과 스칼렛 요한슨은 주로 액션 영화에 많이 출연한 누구나 알고있는 배우이지만 이 영화에서는 가족적인 모습을 다분히 보여준다.

Anyone knows thier, Matt Damon, Scarlett Johansson, mostly starred in famous action movie. But, this movie has seen feature of typical family.

이야기의 큰 틀은 아버지(Matt Damon)와 아들(Colin Ford)의 갈등에서부터 맷 데이먼과 스칼렛 요한슨의 사랑으로 마무리 되어짐을 볼 수 있다.

Big outline of this story was seen ended from problem between dad and son (often saw that) to love for Matt Damon and Scarlett Johansson.

전체적으로 여러 이야기가 나타나지만 옴니버스의 형식은 아닌 서로 다른 갈등 사이의 조화를 가족이라는 구성 요소를 통해 잘 이뤄냈다.

That have a many story, not feature of omnibus movie, was came true through balance using family component of between the other story.

"We bought a zoo"에서 'zoo'는 어원 그대로는 동물원이라는 뜻이 있지만, 영화 문맥 상 가족 간의 애정이 될 수 있고 사람과 동물과의 교감의 어떤 형태가 될 수도 있다고 생각한다.

In "We bought a zoo", a 'zoo' have a mean literally zoo but, i think a zoo could have a means a love of family, something feature of consensus between people and animal in scenario.

불현듯, 우리도 주변의 얘기를 귀 기울여 들어보면 다중적인 표현을 사용하는 경우가 많다는 것을 알 수 있다.

Unexpectedly, we could have know that there are many multiple expression in out contury. if we do listen attentively around of us talks.

마찬가지로 이 영화에서도 감정표현에 서투른 아버지와 아들의 대화 속에서 이런 다중적인 표현을 자주 확인할 수 있었다.

Likewise, this movie also could have recognize these multiple expression in thier awkward conversation.

아들이 진정 원하는 것은 모른 채 본인의 입장에서 최선의 애정을 아들에게 주지만 아들의 입장에서는 그것은 아버지의 최선의 애정이라고 느끼지 못했기에 늘 불만을 가진 표정을 짓고 있는 것을 화면 곳곳에서 확인할 수 있었다.

Father gave affection his do the best without knowing what his son really want. But his son couldn't have a feel his father's enough affection inner his circumstance. that's reason is not consider for the other typically. We can saw dissatisfied face on his son in all over the screen.

우리의 주변에도 사실 봉사, 선교단체 등 비영리 단체의 이름으로 도움을 주는 사람들, 혹은 타인에게 베풀기를 주저하지 않는 사람들을 종종 볼 수 있다.

Around of us, we can find so easily people who help us have named by the Mission Organization, Servant or do not hesitate person.

그들이 잘못된 건 아니지만 우리가 스스로 타인에게 필요할 것 같다고 생각하는 도움이 아닌, 정말 타인이 진정으로 원하는 도움(미안한 마음에 말을 하지 못하는)을 베풀어주는 것이 효율적으로 보인다.

Their's help is not fault. However, i think more efficient method that give a real solution problem out of their mouth not in out of our thinking(don't express on account of sorry heart).

그렇게 된다면, 도움을 주는 사람이 하고 싶은 비효율적 봉사가 아닌 받는 사람에게 맞춘 도움을 통해 베푼 도움에 대비해 몇 배 이상의 감동을 선사할 수 있는 효율적인 도움이 될 수 있을 것이다.

If so, we could have a help the most efficient assistant on several tims more. Not assistant just we want.

이 영화의 색체와 동물들의 모습을 묘사한 장면은 다큐멘터리라고 해도 무방할 정도로 아름답다.

Scenes in this movie, we could have a see beauty colors and animal in wild enough saying like a National Geographic Documentary.

하지만, 그 안에 속해 이야기를 만들어내는 사람들 사이의 갈등과 해결, 관계의 모습은 그 이상으로 아름답다.

However, we can have find out a beauty things more than that in shape of harmony, have a solution to occured conflict in relation among people.

때때로 우리는 주위의 자연에 감탄하며 도심과 멀어진 삶을 동경하곤 한다.

Sometimes, we would used to yearn for life away from the city for admiring around of ours background.

하지만 그것이 항상 답은 아니라는 것을 이 영화를 통해 다시 한 번 확인할 수 있었다.

However, we could have understand these background is not always answer through this screen.

진정 도심을 떠난 행복은 사람들사이의 관계속에서 더욱 쉽게 찾을 수 있고, 그러한 사람들 사이의 아름다움은 뉴질랜드 폭포를 DSLR로 찍은 사진보다도 더 아름답다는 것을.

We can understand a real happiness in life far away from city is relation around of people. These real happiness is beauty more than taking pictures for DSLR camera.

마음이 편안해지고 훈훈한 미소가 남는 영화였다.

Feel comfotable, leave a wram smile.

<이미지 출처 - 네이버 영화, https://movie.naver.com/movie/bi/mi/basic.nhn?code=76627>

Music & Lyrics (2007)

| HUGH GRANT, DREW BERRYMORE

보통 해외에 다녀온 경험이 없는 사람들은 외국의 2007년 화면을 보고 큰 이질감을 느끼지 못할 수 있다.

Nomarlly, people who have not been going to abroad, maybe don't feel a huge difference that before 10 years feature of street.

나 또한 그렇다.

Me, either.

해외에 나가본 적이 없어서 그런지 영화 속 배경인 2007년의 모습은 내가 느끼는 한국의 2007년의 옛 모습과 다르게 11년이나 지난 옛 모습이라고 느껴지진 않았다.

Maybe, i don't feel like that i felt before 11 years feature of korea in this movie. Because of i'm not going to aborad.

이런 점은 휴 그랜트와 드류 베리모어의 영화 속 표정 하나하나가 어색해보이지 않을 수 있다는 장점 또한 있는 것 같아 개인적으로는 좋았다.

Because of these reason, i think it is very atrractive. Main characters does not looked awakward between at current generation to me.

영화 속 나오는 유머러스한 부분과 휴 그랜트의 비유적 표현은 또다른 재미를 주기에 충분했고, 드류 베리모어 또한 굉장히 사랑스러웠다.

figurative expression by Hugh Grant have a qualified of take a funny and gentle. And Drew Berrymore so lovely too.

내가 가장 감명깊게 봤던 장면들은 감성으로 작사를 하는 드류 베리모어가 이성적인 판단으로 작곡을 하려는 휴 그랜트에게 감성을 불어넣어주고, 드류 베리모어 또한 휴 그랜트의 숨겨졌던 감성적인 모습에 감동을 받아 서로의 마음을 공유하는 부분들이었다.

A impressively scenes in my mind is Drew Berrymore firing emotions to Hugh Grant try to make a song depend on rational judgment,
Then, Drew Berrymore also get impressed he's hidden thoughtful emotions.
This scenes save in my heart. I have no choice.

서로가 서로의 깊은 상처를 들어주고 이해해주면서 음악이라는 작품을 만드는 과정안에서 서로의 감정을 공유하고, 그 과정 사이에 서로를 비판하는 감정과 사랑하는 감정이 생겨난 것을 보면서, 우리 주변에서도 어떤 수단으로 인해 감정을 공유하게 될 사건이 발생하면, 그 것이 애정으로 도출될 수도 있고 불신으로도 나타날 수 있다는 것을 느끼게 되었다.

Listening and understanding to pain in the heart each other, i saw that criticize and a falling in love foward to each other in the process by making music.
That was a masterpiece of sharing each heart.
Even around us, when we have shared emotion from somthing means, can feel that  was driven not only tender emotion but also distrusting.

사람 사이의 관계에 있어서 무엇보다도 경청해주는 것이 상대를 위한 큰 배려라고들 말하는 이유는 공감에 있다는 것을 다시 한 번 생각할 수 있게 되었다.

People say, a listen is a great consideration into relationship with each other. Now, i knew why people say that. In addition, i became much more thinking about that.

친근한 주제로 무거운 남, 녀 뿐만 아닌 사람들과의 관계를 다시 한 번 생각하게 만드는 감명깊은 영화였다.

Thanks to this impressed movie, i was thinking about heavy subject using friendly approach.

<이미지 출처 - 네이버 영화, https://movie.naver.com/movie/bi/mi/photoView.nhn?code=65769>