KTKO 개발 블로그와 여행 일기

Being 사용법 3가지

ktko — Tue, 13 Jul 2021 10:38:02 +0900

1. "왜 저러지" 이 느낌이 들 때 쓰인다.

you're nice. 너는 착해

you're being nice 너 (지금) 착하게 군다.

why are you being so nice to me ?

왜 나한테 잘해줘 ? (갑자기 왜 ?)

you're rude 넌 무례해

you're being rude 넌 무례해(지금 너의 행동들이 무례해)

you're being mean ? 너 지금 되게 못됐다.

why are you being mean to me ? 왜 나한테 모질게 굴어 ?

2. p.p앞에 오는 being 쓰임새 무언가가 그렇게 되고 있을 때

I'm fixing a computer = A computer is being fixed

치킨 & 짜장면 is being delivered. 치킨과 짜장면이 배달 중이다.

My time is being wasted, My money is being wasted

They're attacing us. so, we're being attacked.

그들은 우릴 공격하고, 우리는 공격 받고 있다.

3. 되는 것, 있는 것(동명사로 쓰인다)

being a teacher is my dream 나의 꿈은 선생님이 되는 것이다.

being in an office is boring 사무실에 있는 것은 지루하다

being a doctor is not easy. 의사가 되는 것은 쉽지 않다.

출처 : https://youtu.be/8HdJEUrdo-I

Garbage Collection Part2

ktko — Sun, 6 Dec 2020 23:39:29 +0900

GC (Garbage Collector)의 방식은 무엇이 있을까

"Garbage Collection Part1"에서 기본적인 GC Process 절차에 대해서 알게 되었다.

이번 포스팅은 GC의 종류 및 방식에 대해서 이어서 진행한다.

GC의 종류

GC는 크게 Minor GC와 Major GC 두가지 종류가 있다.

Minor : Young 영역에서 발생하는 GC

Major : Old 영역이나 Perm 영역에서 발생하는 GC

GC가 발생하거나 객체가 다른 영역으로 이동할 때 병목이 발생하여 성능에 영향을 준다.

핫 스팟 JVM에서는 TLABs(Thread-local allocation Buffers)라는 것을 사용한다. 이를 통해 각 스레드 메모리 버퍼를 사용하면 다른 스레드에 영향을 주지 않는 메모리 할당 작업이 가능하다.

- 에덴 내에 있는 한 영역

- 스레드마다 할당되는 객체의 버퍼, 하나의 스레드가 처리할 수 있는 객체의 최대 크기,

- 각 스레드마다 로컬에 할당되므로, 동기화에 신경쓰지 않아도 된다.

- 큰 객체를 많이 할당하는 어플리케이션, 에덴의 크기에 비해 상대적으로 스레드의 개수가 많은 어플리케이션은 TLAB 튜닝으로 상당한 이익을 어들 수 있다.

GC의 방식은 5가지가 있다.

1. Serial GC

2. Parallel GC

3. Parallel Old GC

4. CMS (Concurrent Mark & Sweep GC)

5 G1(Garbage First) GC

https://www.dynatrace.com/resources/ebooks/javabook/reduce-garbage-collection-pause-time/

Serial GC

Java 5, 6에서의 기본 가비지 컬렉트이고, 싱글 스레드로 돌아간다. 위 이미지 첫 번째 이미지를보면 Pause(Stop-the-Wold)시간이 긴 것을 볼 수 있다. 싱글 스레드로 GC를 수행하기 문에 수행 시간이 긴 것을 볼 수 있다.

-XX:+UseSerialGC

Parallel GC

Parallel GC는 Serial GC와 똑같은 원리로 동작하지만 Young 영역의 GC과정을 멀티 스레드로 수행한 다는 점이 차이가 있다. 그래서 Pause시간이 짧은 것을 볼 수 있다.

-XX:+UseParallelGC

Parallel Old GC

위의 의미지에선 언급되진 않았지만 Parallel Old GC는 Old 영역에 대해서도 멀티 스레드로 수행한다.

Mark-Sweap-compact알고리즘에서 Mark-Summary-Compact 알고리즘을 사용한다.

-XX:+UseParallelOldGC

CMS

CMS GC는 Young 영역에 대한 GC는 Parallel과 비슷하다, Old영역의 GC는 4가지 단계를 거친다.

1. Initial Mark : 매우 짧은 시간의 Pause시간 동안 GC Root를 가장 먼저 참조하는 객체들을 식별한다. 이 부분은 싱글스레드로 동작한다.

2. Concurrent Mark : 싱글 스레드로 수행되고, Initial Mark 단계에서 식별한 객체가 참조하고 있는 모든 객체들을 추적, 어플리케이션 실행과 동시에 진행된다.

3. Remark : Concurrent Mark단계에서 식발한 객체를 다시 추적한다. 멀티 스레드로 동작하여 pause가 짧다.

4. Concurrent Sweep : 최종적으로 살아있는 객체를 제외한 객체들을 삭제한다. 싱글 스레드로 수행되며 다른 스레드와 동시에 수행되기 때문에 Stop The World가 발생하지않는다. 하지만 Compact 과정이 존재하지 않기 때문에 메모리 단편화가 생겨 Concurrent Mode Failure(CMF) 가 발생할 수 있다. Concurrent Mode Failure는 Old영역에 더 이상 메모리를 할당할 공간이 없을 때 발생하는데 메모리 단편화로 인해 Old 영역의 빈 공간이 충분히 존재함에도 불구하고 크기가 큰 객체를 할당할 수 없는 경우가 생길 수 있다. CMF가 발생하면 강제적으로 Compaction을 수행하므로 'Stop The World' 시간이 다른 GC보다 길어질 가능성이 있다.

-XX:+UseConcMarkSweepGC

G1GC

G1GC는 CMS를 대체하기 위해 만들어졌다. 일반적으로 Young, Old Generation이라는 영역으로 나누어 지지않았고, Region이라는 영역으로 관리한다. CMS과 다르게 Compaction단계를 통해 메모리 단편화를 업앤다.

G1 GC는 Garbage만 있는 Region을 처음에 수거하기 때문에 Garbage First라는 이름이 붙었다.

G1GC의 프로세스에 대해서는 "Oracle G1Gc Getting started"를 참고하였다.

1. G1 Heap Structure

The heap is one memory area split into many fixed sized regions.

Region size is chosen by the JVM at startup. The JVM generally targets around 2000 regions varying in size from 1 to 32Mb.

Heap을 여러개의 고정된 Region이라는 논리적 단위로 나누어 졌고,

JVM 시작시 Region 사이즈는 결정되고 일반적으로 1~32MB 사이즈에 약 2000개의 리즌으로 나눠진다.

2.G1 Heap Allocation

In reality, these regions are mapped into logical representations of Eden, Survivor, and old generation spaces.

아래 이미지에서 리전은 Eden, Survivor, Old 이 있다.

The colors in the picture shows which region is associated with which role. Live objects are evacuated (i.e., copied or moved) from one region to another. Regions are designed to be collected in parallel with or without stopping all other application threads.

각 색의 리전들은 각각의 Role(Eden, Suvivor, Old)의 역할이 있다. 이 객체는 다른 리즌에서 또다른 리즌으로 옮겨지며, 어플리케이션 중지 없이 다른 리즌으로 모여지도록 설계되어 있다.

As shown regions can be allocated into Eden, survivor, and old generation regions. In addition, there is a fourth type of object known as Humongous regions. These regions are designed to hold objects that are 50% the size of a standard region or larger. They are stored as a set of contiguous regions. Finally the last type of regions would be the unused areas of the heap.

Eden, survivor, old Region으로 할당되고, Humongous regions이라는 것은 할당된 리즌사이즈보다 클 때 사용되는 4번째 region 타입입니다. 마지막영역 (회색)은 사용하지 않는 공간을 나타낸다.

Note: At the time of this writing, collecting humongous objects has not been optimized. Therefore, you should avoid creating objects of this size.

The heap is split into approximately 2000 regions. Minimum size is 1Mb and maximum size is 32Mb. Blue regions hold old generation objects and green regions hold young generation objects.

대략 2000개의 리즌으로 나눠지고 1~32MB 크기로 사용된다.

Note that the regions are not required to be contiguous like the older garbage collectors.

이전 GC처럼 리전은 인접 또는 연속적일 필요가 없다.

Live objects are evacuated (i.e., copied or moved) to one or more survivor regions. If the aging threshold is met, some of the objects are promoted to old generation regions.

처음 메모리에 올라간 객체들은 1개 이상의 survivor Regions로 복사 또는 옮겨지며 만약 age가 한계점에 도다랐으면 Old Generation Region으로 옮겨진다.

This is a stop the world (STW) pause. Eden size and survivor size is calculated for the next young GC. Accounting information is kept to help calculate the size. Things like the pause time goal are taken into consideration.

이때 Stop-the-World가 발생한다. Eden 그리고 survivor의 크기는 다음 발생할 Young GC를 위해 계산되고, 계산된 정보는 Region Size계산을 위해 저장된다.

This approach makes it very easy to resize regions, making them bigger or smaller as needed.

이런 접근 방식을 통해 리즌 사이즈를 더 크게, 또는 적게 요구에 따라 쉽게 재조정 할 수 있다.

Live objects have been evacuated to survivor regions or to old generation regions.

생성된 객체들은 survivor 영역 또는 Old generation 영역으로 옮겨진다.

Recently promoted objects are shown in dark blue. Survivor regions in green.

최근 promotion(young -> old)된 객체들은 진한 파랑, 새로 young generation으로 옮겨진 객체는 초록 계열로 옮겨진다.

In summary, the following can be said about the young generation in G1:

- The heap is a single memory space split into regions

- Young generation memory is composed of a set of non-contiguous regions. This makes it easy to resize when needed

- Young generation garbage collections, or young GCs, are stop the world events. All application threads are stopped for the operation.

- The young GC is done in parallel using multiple threads.

- Live objects are copied to new survivor or old generation regions.

Young Generation GC는

- Heap은 여러개의 리즌 공간으로 나눠진다.

- young Generation은 연속적이지 않은 region으로 구성된다. 이것은 더 쉽게 사이즈 조정할 할 수 있게 한다.

- Young GC시 Stop-the-world가 일어난다. 모든 어플리케이션 스레드는 종료된다.

- Young GC가 멀티 스레드가 병렬로 실행 된다.

- 살아있는 객체들은 survivor 또는 Old generation 리전으로 옮겨진다.

아래 표는 G1GC에서 Old Generation 단계에 대한 설명을 나타낸다.

Old Generation Collection with G1

CMS와 같이 G1은 Old Generation에서 중지시간을 단축시키기 위해 디자인 되었다. 아래 테이블은 Old Generation에 대해서 G1 Collection의 동작 방법에 대해서 설명한다.

Phase(단계)

Description

1. Initial Mark

Stop the world가 발생한다.

This is a stop the world event. With G1, it is piggybacked on a normal young GC. Mark survivor regions (root regions) which may have references to objects in old generation.

여기서 Stop the world 이벤트가 발생, Old Generation에 있는 객체를 참조하고 있는 Survivor Region을 마킹한다.

2. Root Region Scanning

Scan survivor regions for references into the old generation. This happens while the application continues to run. The phase must be completed before a young GC can occur.

Old Generation으로 참조하는 Survivor 리즌을 조회한다. 이때 어플리케이션은 실행되고 있고, 이 단계가 완료되야 Young GC가 수행될 수 있다.

3. Concurrent Marking

Find live objects over the entire heap. This happens while the application is running. This phase can be interrupted by young generation garbage collections.

Heap 영역에 있는 모든 살아있는 객체를 조회한다. 어플리케이션이 실행되는 동안 실행되며, 이 단계에서Young GC에 의해 중단될 수 있다.

4. Remark

Stop the world가 발생한다

Completes the marking of live object in the heap. Uses an algorithm called snapshot-at-the-beginning (SATB) which is much faster than what was used in the CMS collector.

Heal 영역에 있는 살아있는 객체 마킹을 완료하고, SATP라는 알고리즘을 사용하여 CMS보다 더 빠르게 동작한다.

5. Clean up

Stop the world Event and Concurrent

Performs accounting on live objects and completely free regions. (Stop the world)
Scrubs the Remembered Sets. (Stop the world)
Reset the empty regions and return them to the free list. (Concurrent)

살아있는 객체를 조회하고, 비어있는 Region을 계산합니다. (Stop the world) 발생

Remembered Set을 정리한다.

Reference를 가진 객체가 어떤 Region에 할당되어 있는지 알기 위한 자료구조

비어있는 Region을 정리하고 Free list에 추가한다. (동시에 실행 )

(*) Copying

Stop the world가 발생한다

These are the stop the world pauses to evacuate or copy live objects to new unused regions.
This can be done with young generation regions which are logged as [GC pause (young)].
Or both young and old generation regions which are logged as [GC Pause (mixed)].

사용하지 않은 리즌으로 살아 있는 객체를 복사한다

Young Generation에서는 [GC pause (young) ] 구문으로 로깅된다.

6. Initial Marking Phase

Initial marking of live object is piggybacked on a young generation garbage collection. In the logs this is noted as GC pause (young)(inital-mark).

7. Concurrent Marking Phase

If empty regions are found (as denoted by the "X"), they are removed immediately in the Remark phase. Also, "accounting" information that determines liveness is calculated.

비어있는 Region이 발견되면, 그 리즌은 Remark 단계에서 삭제된다.

8. Remark Phase

Empty regions are removed and reclaimed. Region liveness is now calculated for all regions.
비어 있는 리즌들은 제거되고 반환되며, 모든 Region에 대한 liveness가 계산된다.

9.Copying/Cleanup Phase

G1 selects the regions with the lowest "liveness", those regions which can be collected the fastest. Then those regions are collected at the same time as a young GC. This is denoted in the logs as [GC pause (mixed)]. So both young and old generations are collected at the same time.

G1 "liveness"가 낮은 리전을 선택하고 모아서 young GC를 수행하고, 리전들을 모아서 수집합니다(compact)

이 부분은 Young, Old Generation이 동시해 수행됩니다.

10. After Copying/Cleanup Phase

The regions selected have been collected and compacted into the dark blue region and the dark green region shown in the diagram.

GC가 일어난 이후에 진한 녹색(최근 Young generation으로 compact), 진한 파랑(최근 Old Generation) Region으로 이동하고 Compact

Summary of Old Generation GC

In summary, there are a few key points we can make about the G1 garbage collection on the old generation.

Concurrent Marking Phase

Liveness information is calculated concurrently while the application is running.
This liveness information identifies which regions will be best to reclaim during an evacuation pause.
There is no sweeping phase like in CMS.

Remark Phase

Uses the Snapshot-at-the-Beginning (SATB) algorithm which is much faster then what was used with CMS.
Completely empty regions are reclaimed.

Copying/Cleanup Phase

Young generation and old generation are reclaimed at the same time.
Old generation regions are selected based on their liveness.

Old Generation GC 요약

- Concurrent Marking Phase
Liveness(활성) 정보는 어플리케이션이 실행되는 동안 동시에 계산된다.

각 리전의 활성 정보가 evacuation pause(young gc) 진행되는 동안 최적화가 될 수 있도록 reclaim 한다.

CMS와 같은 sweeping 단계가 존재하지 않는다.

- Remark Phase

CMS에서 사용하고 있는 알고리즘보다 더 빠른 SATP를 사용한다.

완벽하게 비어있는 리즌은 반환된다.

- Copying/Cleanup Phase

Old generation 리전은 활성(liveness) 상태에 따라서 지정된다.

Young generation과 Old generation은 동시에 reclaim 된다.

	Serial	Parallel	CMS	G1
병렬 수행 (Parallel)	X	O	O	O
동시 수행(Concurrency)	X	X	O	O
Young GC	Serial	Parallel	Parallel	Parallel
Old Gc	Serial	Parallel	Parallel & Conc	Parallel & Conc

참조..

주요 정리 블로그

https://www.slipp.net/wiki/pages/viewpage.action?pageId=30770051

https://12bme.tistory.com/57

https://javabom.tistory.com/7?category=835783

https://johngrib.github.io/wiki/jvm-memory/

//g1gc 설명

https://imp51.tistory.com/entry/G1-GC-Garbage-First-Garbage-Collector-Tuning

//로그 분석 설명

https://b.luavis.kr/server/g1-gc

https://blog.naver.com/PostView.nhn?blogId=bumsukoh&logNo=110119881124&parentCategoryNo=&categoryNo=22&viewDate=&isShowPopularPosts=false&from=postView

// perm 과 메타스페이스 설명

https://mirinae312.github.io/develop/2018/06/04/jvm_memory.html

// java DNS TTL 관리

https://skysince.tistory.com/16

http://kwon37xi.egloos.com/4455415

// TLAB이란 무엇인가

https://m.blog.naver.com/PostView.nhn?blogId=kbh3983&logNo=220995694888&proxyReferer=https:%2F%2Fwww.google.com%2F

Garbage Collection Part1

ktko — Sun, 6 Dec 2020 23:39:08 +0900

최근 메모리 관련 문제라고 생각되는 이슈가 있어서, GC 로그를 보게 되었고, 로그 분석을 하다가 GC에 관해서 다시 공부하고 재정립하는 시간을 갖게 되었다. 이 내용을 공유하고자 오랫만에 블로그에 글을 올린다.\

GC종류에 대해서 설명하기 전에 알아야 할 개념 몇 가지가 있다.

1. Stop-the-world

GC를 실행하기 위해 어플리케이션 실행을 멈춘다. 효율적인 GC 알고리즘을 작성하는 것은 Stop-the-world의 시간을 줄이는 것이다.

2. Reachable와 Unreachable

GC에 의해 사용하지 않는 객체는 삭제되는데, 어떤 방식으로 유효한건지 판별하는걸까 ?

아래에서 그림에서 GC Roots를 참조할 수 있는 모든 객체를 Reachable, GC Roots 참조할 수 없는 객체를 Unreachable이라고 한다. 참조 트리에서 유효한 객체인지 확인하기 위해서 항상 유효한 최초의 객체가 존재해야 하는데 이를 GC Root라고 한다.

자세한 설명은 우하한 테크톡 "엘리의 GC"편을 보면 좋을 것 같다.

3. Mark, Sweap, Compact

http://www.cs.columbia.edu/~aho/cs6998/Lectures/14-10-27_Li_GarbageCollection.pdf

GC의 기본 프로세스는 Mark and Sweap 이라고 할 수 있다.

참조되지 않는 객체를 실벽하는 Mark, Marking된 객체를 삭제하는 Sweap, Sweap 후 발생한 메모리 단편화 문제를 해결하기 위한 Compact

4. JVM 메모리 구조에 대해

JVM 메모리 구조에 대해서는 "JVM 메모리 구조 이해하기" 편에 정리를 해 놓았다.

여기 까지 내가 아는 기본적인 용어와 배경 지식에 대해서 정리를 해놓았다.

이제 GC종류에 대해서 알아보자.

5. 왜 Young Generation, Old Generation, Minor GC, Major GC가 나왔을까, 그냥 한번에 모든 메모리를 통합하는 GC를 사용하는게 좋지 않을까 ?

https://www.oracle.com/webfolder/technetwork/tutorials/obe/java/gc01/index.html

위의 질문은 누구나 생각하고 의문을 표할 수 있다고 생각되고, 왜 이렇게 나눠놨는지 오라클 GC 튜토리얼에 씌여있다.

As stated earlier, having to mark and compact all the objects in a JVM is inefficient. As more and more objects are allocated, the list of objects grows and grows leading to longer and longer garbage collection time. However, empirical analysis of applications has shown that most objects are short lived.

JVM에 있는 모든 Object를 GC하는 것은 비효율 적이다, 더 많은 객체들이 메모리에 할당 됨으로써 GC의 시간이 길어지게 될 뿐이다. Application의 분석에 따르면 대부분의 객체의 생명주기는 매우 짧다.

As you can see, fewer and fewer objects remain allocated over time. In fact most objects have a very short life as shown by the higher values on the left side of the graph.

위의 표를 보면 알 수 있다. 시간이 지날 수록 객체들은 할당되고, 실질적으로, 대부분의 객체는 매우 짧은 수명을 갖고 있고 그래프의 왼쪽 부분을 보면 알 수 있다.

"weak generational hypothesis"라는 가설이 있다.

1. 대부분의 객체는 금방 접근 불가능한 상태가 된다.

대부분의 객체는 중괄호 안에서 생성된다. 이 객체들은 괄호가 끝나면 사용되지 않습니다.

2. 오래된 객체에서 젊은 객체로의 참조는 적다

일반적으로 대부분의 비지니스 로직은 순차적으로 객체가 생성되고 사용됩니다.

앞에서 생성된 객체는 다음 로직에서 사용된 이후 대부분 사용되지 않습니다.

GC Process

GC가 일어나는 과정에 대해서 살펴본다. 모든 이미지와 설명은 Oracle 사이트를 참조하였다.

First, any new objects are allocated to the eden space. Both survivor spaces start out empty.

새로 생긴 객체는 eden 영역에 생성되고, 두개의 survior space는 비어있는 상태로 시작된다.

s0에 있는 3,1은 s0에서 s1로 옮겨진다라는 걸 보여주기 위해 표현된 것 같다.

When the eden space fills up, a minor garbage collection is triggered.

Eden 영역이 꽉 찼을 때 minow GC가 시작된다.

Referenced objects are moved to the first survivor space. Unreferenced objects are deleted when the eden space is cleared.

참조된 객체 (여기서는 Reachable 가능한 객체를 의미하는 것 같다.) 는 survivor space 영역으로 옮겨지고 참조불가능한 객체들은 eden 영역에서 삭제된다

At the next minor GC, the same thing happens for the eden space. Unreferenced objects are deleted and referenced objects are moved to a survivor space. However, in this case, they are moved to the second survivor space (S1). In addition, objects from the last minor GC on the first survivor space (S0) have their age incremented and get moved to S1. Once all surviving objects have been moved to S1, both S0 and eden are cleared. Notice we now have differently aged object in the survivor space.

첫 번째 GC가 일어난 다음에 Eden영역에 객체가 생성되고 꽉차게 되면 minor GC가 일어난다. 똑같이 참조불가능한 객체는 삭제되고, 참조가능한 객체는 survivor영역으로 옮겨지는데 s0이 아닌 s1영역으로 옮겨진다. 그리고 s0에서 s1로 옮겨진 객체들의 age는 1씩증가된다.

여기서 주의할 점은 s0 그리고 s1 둘중에 하나는 무조건 비어져 있어야 한다.

At the next minor GC, the same process repeats. However this time the survivor spaces switch. Referenced objects are moved to S0. Surviving objects are aged. Eden and S1 are cleared.

다시 Minor GC가 발생했을 때 똑같이 반복한다. 아래 사진을 보면 s1-> s0영역으로 다시 옮겨지고 age가 1씩증가하며 Eden과 S1영역이 비어진다.

This slide demonstrates promotion. After a minor GC, when aged objects reach a certain age threshold (8 in this example) they are promoted from young generation to old generation.

위의 과정을 끊임없이 반복하면서 특정 객체의 age는 한계점에 도달한다 (아래 이미지에서는 한계점이 8로 설정) age가 8이 넘어가면 Old Generation으로 옮겨진다. Young Generation -> Old Generation으로 넘어가는 넘어가는 것을 Promotion이라 한다.

As minor GCs continue to occure objects will continue to be promoted to the old generation space.

Minor GC가 계속해서 발생함으로써, Old Generation 으로 계속해서 promoted 하게 된다.

위에서 설명한 promotion이 계속해서 발생한다는 뜻이다.

So that pretty much covers the entire process with the young generation. Eventually, a major GC will be performed on the old generation which cleans up and compacts that space.

Young Generation에 대한 전반적인 프로세스 절차에 대해서 다루었다. 마지막으로 Major GC는 Old Beneration영역에서 수행되고 사용하지 않은 객체는 사라지고 Compacts 과정이 일어난다.

전반적인 GC 절차에 대해서 살펴보았다.

다음편에는 GC종류 그리고 Java 8로 인해 바뀐 JVM 구조에 대해서 설명한다.

자바 콜백 패턴 구현해보기

ktko — Tue, 21 Apr 2020 15:48:38 +0900

잠깐 reactive document를 보다가 콜백, 비동기 등등 얘기가 나와서 자바에서는 콜백을 어떻게 구현하는지 한번 정리해보고자 글을 써본다.(reactive document는 내가 영어가 딸려서 번역이 안된다.... 때려침...)

일반적으로 함수 호출을 할 때에는 함수를 호출하는 함수(Caller)와 호출당하는 함수(Callee)가 있다.

쉽게 말해서 A클래스와 B클래스가 존재하고, A클래스에는 a함수가, B클래스에는 b함수가 있다.

A클래스의 a함수가 B클래스의 b함수를 호출한다면 a함수는 Caller이 되고, b함수는 Callee가 된다.

콜백(Callback)은 일반적인 함수 호출의 흐름과 다르게 동작을 한다. 호출을 당한 함수(Callee)에서 호출을 한 함수(Caller)을 호출할 수 있다.

1. 먼저 콜백 interface를 정의하였다.

인터페이스에는 숫자를 더하는 addCount, 숫자를 빼는 subtractCount메서드가 있고, 이게 0보다 작은지 확인하는 isLessZero 메서드가 있다.

1
2
3
4
5
public interface callback {
    void addCount();
    void subtractCount();
    boolean isLessZero();
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
class Callee {
    private int count;
    private callback callBack;
 
    public Callee() { count = 0; }
 
    public void setCallBack(callback callBack) {
        this.callBack = callBack;
    }
 
    public int getCount() {
        return count;
    }
 
    public void addCount() {
        this.count++;
    }
 
    public void subtractCount() {
        this.count--;
    }
 
    public boolean execute() {
        Scanner scanner = new Scanner(System.in);
        System.out.println("Input Data : ");
        int condition = scanner.nextInt();
 
        switch (condition) {
            case 1:
                this.callBack.addCount();
                break;
            case 2:
                this.callBack.subtractCount();
                break;
        }
 
        return callBack.isLessZero();
    }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
public class Caller {
    public static void main(String[] args) {
        Callee callee = new Callee();
        callee.setCallBack(new callback() {
            @Override
            public void addCount() {
                callee.addCount();
                System.out.println(callee.getCount());
            }
 
            @Override
            public void subtractCount() {
                callee.subtractCount();
                System.out.println(callee.getCount());
            }
 
            @Override
            public boolean isLessZero() {
                if (callee.getCount() < 0) return true;
 
                return false;
            }
        });
 
        while(true) {
            if (callee.execute()) break;
        }
    }
}

Spring Boot에 WireMock 적용해보자

ktko — Mon, 2 Mar 2020 01:10:02 +0900

아래 내용 보다는 코드를 보고 테스트를 실행하는 게 더 좋다.

https://github.com/ko-theo/Spring-WireMock

개발 환경
Spring Boot(v2.2.4), Junit5, Gradle, Java 11, Kotlin,

대부분의 사이트 및 블로그는 Junit4 기준으로 설명이 되어있지만(WireMock Document에서도 Junit4를 기준으로 설명하고 있다.) 현재 사내에서 Junit5를 사용하고 있고, 실제로도 Junit5를 많이 사용하고 있기에 Junit5를 기준으로 설명을 작성하였다.

Wiremock 은 다양한 기능(Proxy, Record and Playback.. 등등) 을 제공하고 있으며, 더 자세한 내용은 사이트 방문을 통하여 보는 것을 추천한다. 작성된 내용은 기본적인 내용 그리고 간단하게 작성된 코드에 Wiremock이 적용된 샘플 예제를 첨부하였다.

WireMock

WireMock은 테스트 목적으로 사용할 수 있는 웹 서버이다. WireMock을 사용하면서 특정 포트로 지정한 규칙과 매칭된 HTTP 요청이 들어오면 지정한 응답을 전송한다. 따라서, 실제 웹 서버가 존재하지 않더라도 HTTP 클라이언트를 테스트할 수가 있다.

장점

Avoid rate limits and server cost

실제 서버 테스트를 진행할 경우 발생할 수 있는 서버 비용 및 제한된 조건을 피할 수 있다.

Cover edge cases and error scenarios

다양한 테스트 케이스 및 Error 발생시 시나리오를 테스트 해볼 수 있다.

Speed

컴퓨터 내부에 서버를 사용함으로써 테스트에 사용되는 네트워크 속도가 빠르다.

WireMock을 사용하기 앞서, Mock과 Stub 용어와 의미를 아는 것이 좋을 것 같아 간단하게 정리하였다.

테스트 더블이란 테스트를 진행할 때 실제 객체를 대신해서 사용되는 모든 방법들을 호칭하는 것으로 Stub, Mock 또한 테스트 더블에 속한다고 할 수 있다.

Dummy, Spy, Mock, Fake, Stub과 같은 용어들 또한 테스트 더블에 속한다고 할 수 있다.

자세한 내용은 요기 블로그 에 잘 정리되어 있으니 꼭 보는 것을 추천한다.

stub : 테스트에서 호출된 요청에 대한 결과를 미리 준비하여 제공을 한다.

mock : 호출에 대한 기대를 명세하고, 해당 내용에 따라 동작하도록 코드로 작성된 프로그래밍 된 객체(MockMvc)

Stand Alone 적용 방법

WireMock 라이브러리 .jar파일만 가지고 있어도 별도의 MockServer을 만들 수 있다.

http://wiremock.org/docs/download-and-installation/ 링크에서 jar파일을 다운로드 한다.

1
java -jar wiremock-standalone-2.26.0.jar --verbose

위의 명령어를 실행하면, 해당 jar파일 경로에 __files와 mappings 디렉토리가 생성되며 로컬호스트:8080으로 접속하면 서버가 실행되었음을 알 수 있다.

stub 설정을 진행한다.

1
2
3
4
5
6
7
8
9
10
11
12
13
{
   "request":{
      "urlPattern":"/product/p0001",
      "method":"GET"
   },
   "response":{
      "status":200,
      "headers":{
         "Content-Type":"application/json"
      },
      "body":"{ \"_id\" : \"p0001\", \"product_display_name\" : \"Brother - MFC-J4320DW Wireless All-In-One Printer - Black/Gray\", \"category_ids\" : [ \"pcmcat247400050001\" ], \"is_active\" : true, \"on_sale\" : true, \"price\" : { \"list_price\" : 149.99, \"sale_price\" : 123.99 }, \"upc\" : \"012502637677\", \"mpn\" : \"MFC-J4320DW\", \"manufacturer\" : \"Brother\", \"product_short_description\" : \"4-in-1 functionalityBuilt-in wireless LAN (802.11b/g/n)Prints up to 20 ISO ppm in black, up to 18 ISO ppm in color (Print speeds vary with use. See mfg. for info on print speeds.)150-sheet tray2.7\\\"\" }"
   }
}

위의 JSON은 /product/p0001을 요청했을 경우, 200Status에 header에는 "application/json", body에는 요청 응답값 정보가 담겨져 있다. product.json으로 파일을 저정한 후, WireMock서버를 다시 실행한다.

위에 json에서 정의한대로 응답받을 수 있다.

jar파일 실행시 command 옵션으로 포트, https 포트 설정, Address 바인딩 등등 다양한 옵션을 정의할 수 있으며, 위의 JSON 예제처럼 1개의 요청이 아닌 여러개의 stub을 등록하여 서버를 세팅할 수 있다. 아래 예제를 보면 2개의 Request와 Response의 응답값을 등록하여 사용하는 것을 볼 수 있다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
{
  "mappings": [
    {
      "request": {
        "method": "GET",
        "url": "/one"
      },
      "response": {
        "status": 200
      }
    },
    {
      "request": {
        "url": "/two"
      },
      "response": {
        "body": "Updated"
      }
    }
  ]
}

Spring Boot 적용 방법

Spring Boot에서는 spring-cloud-starter-contract-stub-runner 를 ClassPath에 추가함으로써 WireMock를 사용할 수 있다.

Spring initializer에서 WireMock을 검색하면 아래의 라이브러리를 선택할 수 있다.

선택하면 아래와 같이 Gradle에 dependencies를 추가된다.

testImplementation("org.springframework.cloud:spring-cloud-starter-contract-stub-runner")

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
@SpringBootTest(webEnvironment = WebEnvironment.RANDOM_PORT)
@AutoConfigureWireMock(port = 0)
public class WiremockForDocsTests {
 
    // A service that calls out over HTTP
    @Autowired
    private Service service;
 
    @BeforeEach
    public void setup() {
        this.service.setBase("http://localhost:"
                + this.environment.getProperty("wiremock.server.port"));
    }
 
    // Using the WireMock APIs in the normal way:
    @Test
    public void contextLoads() throws Exception {
        // Stubbing WireMock
        stubFor(get(urlEqualTo("/resource")).willReturn(aResponse()
                .withHeader("Content-Type", "text/plain").withBody("Hello World!")));
        // We're asserting if WireMock responded properly
        assertThat(this.service.go()).isEqualTo("Hello World!");
    }
}

Stub 서버를 실행할 때 포트를 다르게 하려면 @AutoConfigureWireMock(port = 8090) 과 같이 port를 설정할 수 있다, 만약 랜덤으로 포트를 설정하려면 0으로 설정한다.

Stub 서버의 포트는 또한 Test Application Context의 wiremock.server.port 프로퍼티로 바인딩 되는데 관련된 내용의 코드는 12Line에서 볼 수 있다.

@AutoConfigureWireMock을 사용하는 것은 WireMockConfiuration을 테스트 환경에 빈으로 설정하는 것과 동일하다.

@AutoConfigureWireMock 을 선언하여 classpath에 Json stub을 등록할 수 있다(default : src/test/resources/mappings).

stub 속성을 사용하여 JSON 위치를 변경할 수 있다.

1
2
3
4
5
6
7
8
9
10
11
12
13
@ExtendWith(SpringExtension::class)
@SpringBootTest
@AutoConfigureWireMock(stubs="classpath:/stubs")
public class WiremockImportApplicationTests {
 
    @Autowired
    private Service service;
 
    @Test
    public void contextLoads() throws Exception {
        assertThat(this.service.go()).isEqualTo("Hello World!");
    }
}

WireMock 코드 작성

게시글을 등록, 조회, 게시글의 댓글얼 조회하는 Rest API가 있고, 요청 및 응답 데이터는 아래와 같다.

No	METHOD	URL	Description
1	GET	/post/{id}	게시물 검색
2	GET	/comments?postId={id}	게시물에 있는 댓글 검색
3	POST	/post	게시물 등록

1. 게시글 조회

1
2
3
4
5
6
{
    "userId": 1,
    "id": 1,
    "title": "sunt aut facere repellat provident occaecati excepturi optio reprehenderit",
    "completed": false
}

2. 댓글 조회

1
2
3
4
5
6
7
8
9
[
    {
        "postId": 1,
        "id": 1,
        "name": "id labore ex et quam laborum",
        "email": "Eliseo@gardner.biz",
        "body": "laudantium enim quasi est quidem magnam voluptate ipsam eos\ntempora quo necessitatibus\ndolor quam autem quasi\nreiciendis et nam sapiente accusantium"
    }
]

3. 게시글 등록

1
2
3
4
5
6
7
8
9
10
11
12
13
14
/** 요청 **/
{
    "userId" : 1,
    "title" : "THEO",
    "body" : "foo"
}
 
/** 응답 **/
{
    "id": 101,
    "userId": 1,
    "title": "THEO",
    "body": "foo"
}

자바코드"만" 사용해서 테스트 코드 작성

WireMock은 자바 코드로 요청 및 응답에 대한 테스트 데이터를 작성할 수 있다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
class PostServiceTest @Autowired constructor(
    val postService: PostService,
    val postClient: PostClient
) : BaseSpringTest() {
 
    @BeforeEach
    fun init() {
        wireMockServer = WireMockServer()
        wireMockServer.start()
    }
 
    @AfterEach
    fun shutDown() {
        wireMockServer.stop()
    }
 
    @Test
    fun getPost() {
        stubFor(
            WireMock.get(WireMock.urlEqualTo("/posts/1"))
                .willReturn(
                    WireMock.aResponse()
                        .withStatus(HttpStatus.OK)
                        .withHeader("Content-Type", "application/json")
                        .withBody(getBody)
                )
        )
 
        assertThat(postService.getPost(1).title).isEqualTo("delectus aut autem")
        verify(getRequestedFor(urlEqualTo("/posts/1")))
    }
 
    @Test
    fun getComments() {
        stubFor(
            WireMock.get(WireMock.urlEqualTo("/comments?postId=1"))
                .willReturn(
                    WireMock.aResponse()
                        .withStatus(HttpStatus.OK)
                        .withHeader("Content-Type", "application/json")
                        .withBody(commentBody)
                )
        )
 
        assertThat(postService.getComments(1).size).isEqualTo(1)
    }
 
    @Test
    fun createPost() {
        stubFor(WireMock.post(WireMock.urlEqualTo("/posts"))
                .withRequestBody(
                    equalToJson("{ \"userId\" : 1, \"title\" : \"THEO\", \"body\" : \"GAMEHUB\"}")
                )
                .willReturn(
                    WireMock.aResponse()
                        .withStatus(HttpStatus.OK)
                        .withHeader("Content-Type", "application/json")
                        .withBody(postBody)
                )
        )
 
        assertThat(postService.createPost(todoRequest).title).isEqualTo("THEO")
    }
}
 
Colored by Color Scripter
cs

JSON 파일을 이용한 테스트 코드 작성

위의 예제에서는 stubFor을 이용해서 요청 및 응답 데이터를 작성했다면, 아래 예제는 요청 및 응답 정보를 포함하는 json파일을 이용하여 테스트를 작성한다.

WireMock은 Default로 resources/mappings 디렉토리에 있는 Json 들을 import 한다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
/** getPost **/
{
  "request": {
    "method": "GET",
    "url": "/posts/1"
  },
  "response": {
    "headers": {
      "Content-Type": "application/json"
    },
    "status": 200,
    "body": "{\"userId\" : \"1\", \"id\" : \"1\", \"title\" : \"delectus aut autem\", \"completed\": \"false\"}"
  }
}
 
/** getComments**/
{
  "request": {
    "method": "GET",
    "url": "/comments?postId=1"
  },
  "response": {
    "headers": {
      "Content-Type": "application/json"
    },
    "status": 200,
    "body": "[{\"postId\" : \"1\", \"id\" : \"1\", \"name\" : \"id labore ex et quam laborum\", \"email\": \"Eliseo@gardner.biz\", \"body\": \"laudantium enim quasi est quidem magnam voluptate ipsam eos tempora quo necessitatibus dolor quam autem quasi reiciendis et nam sapiente accusantium\"}]"
  }
}
 
/** createPost **/
{
  "request": {
    "method": "POST",
    "url": "/posts",
    "bodyPatterns" : [
      { "equalToJson" :  "{ \"userId\" : 1, \"title\" : \"THEO\", \"body\" : \"GAMEHUB\"}"}
    ]
  },
  "response": {
    "status":200,
    "headers":{
      "Content-Type":"application/json"
    },
    "body" : "{ \"id\" : \"1\", \"userId\" : \"1\", \"title\" : \"THEO\", \"body\" : \"GAMEHUB\" }"
  }
}
Colored by Color Scripter
cs

Request Matching

WireMock에서는 Attribute 사용하여 stub 또는 검증을 진행한다.

내용이 너무 많아 중요한 몇개(URL, HTTP Method[GET, POST], Query Parameters, Header, Request Body)만 설명을 진행한다.

java	json	Description
urlEqualTo	url	Equality matching on path and query
urlMatching	urlPattern	Regex matching on path and query
urlPathEqualTo	urlPath	Equality matching on the path only
urlPathMatching	urlPathPattern	Regex matching on the path only

HTTP Method(GET, POST, PUT, DELETE 등
Query parameters
Headers

1
.withHeader("Content-Type", equalTo("application/json"))

1
2
3
4
5
6
7
8
9
10
11
12
{
  "request": {
    ...
    "headers": {
      "Content-Type": {
        "equalTo": "application/json"
      }
    }
    ...
  },
  ...
}

ㅈ

Request body

1
.withRequestBody(equalToJson("{ \"total_results\": 4 }"))

1
2
3
4
5
6
7
8
9
10
{
  "request": {
    ...
    "bodyPatterns" : [ {
      "equalToJson" : { "total_results": 4 }
    } ]
    ...
  },
  ...
}
 b

다른 속성들은 아래와 같고, 사용 방법은 http://wiremock.org/docs/request-matching/를 확인한다.

Basic authentication (a special case of header matching)
Cookies
Multipart/form-data

검증(Verifying)

WireMock은 수신한 모든 요청을 Memory에 기록하며, 실제 서버에 요청이 되었는지 확인할 수 있다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
fun getPost() {
    stubFor(
        WireMock.get(WireMock.urlEqualTo("/posts/1"))
            .willReturn(
                WireMock.aResponse()
                    .withStatus(HttpStatus.OK)
                    .withHeader("Content-Type", "application/json")
                    .withBody(getBody)
            )
    )
 
    assertThat(postService.getPost(1).title).isEqualTo("delectus aut autem")
    verify(getRequestedFor(urlEqualTo("/posts/2")))
}
Colored by Color Scripter
cs

WireMock and Spring MVC Mocks

Spring Cloud Contract에서는 WireMock를 좀 더 편리하게 사용할 수 있는 MockRestServiceServer을 제공한다.

아래는 예제 코드이며, 관련 링크를 첨부한다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
@SpringBootTest(webEnvironment = WebEnvironment.NONE)
public class WiremockForDocsMockServerApplicationTests {
 
    @Autowired
    private RestTemplate restTemplate;
 
    @Autowired
    private Service service;
 
    @Test
    public void contextLoads() throws Exception {
        // will read stubs classpath
        MockRestServiceServer server = WireMockRestServiceServer.with(this.restTemplate)
                .baseUrl("https://example.org").stubs("classpath:/stubs/resource.json")
                .build();
        // We're asserting if WireMock responded properly
        assertThat(this.service.go()).isEqualTo("Hello World");
        server.verify();
    }
 
}
Colored by Color Scripter
cs

** 참고

json 제공 : https://jsonplaceholder.typicode.com/

stub : https://m.blog.naver.com/PostView.nhn?blogId=suresofttech&logNo=221204092938&proxyReferer=https%3A%2F%2Fwww.google.com%2F

wiremock :

https://cloud.spring.io/spring-cloud-contract/reference/html/project-features.html#features-build-tools

https://www.baeldung.com/introduction-to-wiremock

http://wiremock.org/docs/getting-started/

https://www.youtube.com/watch?v=pPtTz6X0yRE&t=3s

https://dzone.com/articles/mocking-rest-api-with-wiremock-using-recording-mod

/** Stand alone 사용 방법 **/

https://dzone.com/articles/wiremock-mock-your-rest-apis

used to / be used to 동사 / be used to 명사 or 동명사 정리

ktko — Thu, 16 Jan 2020 12:50:53 +0900

use는 주로 사용하다 라고 해석이 많이 되지만 used는 과거형이 아닌 익숙한 이란 형용사로 해석이 된다.

이 형용사를 알면 해석하는데 많은 도움이 된다.

used to 동사원형

~ 하곤 했다. 과거 시제로만 사용되며 현재는 그렇지 않다는 것을 말한다.

동사 use의 뜻이 사용된다.

be used to 동사원형

~ 하는데 사용되다, ~ 하는데 쓰여지다.

수동태로 사용되며 동사 use의 뜻이 사용된다.

be used to 명사 / 동명사

~ 하는데 익숙하다, ~에 익숙하다.
형용사 used의 익숙한 뜻을 알게되면 해석하기 쉽다.

used to 예문

I didn't used to listen to my father.

나는 아빠 말을 잘 안 듣곤 했어(지금은 잘 듣는다)

My brother often used to pick on me.

우리형은 날 자주 괴롭히곤 했어(지금은 안 괴롭힌다)

be used to 명사 / 동명사 예문

This is used to make a bread

빵 만드는데 사용된다.

What is this used to do?

뭐 하는데 사용되?

be used to 동사원형 예문

I'm used to getting up early.

일찍 일어나는데 익숙하다.

I'm used to cooking.

나는 요리하는데 익숙하다.

감각동사와 지각동사

ktko — Tue, 14 Jan 2020 00:31:32 +0900

감각동사는 사람의 오감을 나타내는 동사를 말한다.

감각동사 종류(2형식)

look(~처럼 보이다)

sound(~처럼 들리다)

smell(~한 냄새가 나다)

taste(~한 맛이 나다)

feel(~하게 느껴지다)

사용법 : 감각동사 + 형용사

이렇게 5개의 단어가 감각동사로 많이 쓰이며 look, sound는 지각동사로는 쓰이지 않고 감각동사로만 사용 된다.

감각동사는 2형식으로 주격보어가 나오며, 주격보어로 형용사가 제일 많이 나온다.

Theo looks happy

테오는 행복해 보인다.

The bread smells good.

그 빵은 좋은 냄새가 난다.

The story sound good.

그 이야기가 좋다.

The bread taste good.

그 빵은 맛이 좋다.

The cloth felt smooth.

그 천은 부드럽게 느껴졌다.

지각동사는 사람의 감각기관을 통해 인식하는 동사를 말한다.

지각동사 종류

시각	see	3, 5형식	~을 보다 인지하다
	watch
	notice
	observe
	look at	3형식
청각	hear	3, 5형식	~을 듣다
청각	listen to	3 형식	~을 듣다
촉각	feel	3,5형식	~을 느끼다.

이 외에도 smell, taste 등등이 있다.

지각동사 뒤에는 목적어와 목적어 보충 설명을 해주는 5형식이 많이 쓰여진다.

I saw her dance.

나는 그녀가 춤추는 것을 보았다.

I saw him enter the house.

나는 너가 집에 들어가는 것을 보았다.

I heard her play the piano.

나는 그녀가 피아노 치는 것을 들었다.

I felt my room shake last night.

나는 내 방이 흔들리는 것을 느꼈다.

I saw him run.

그가 달리는 것을 보았다.

복습을 하기 위해 5형식을 다시 정리해보자면 아래와 같다.

주어 + 동사 + 목적어 + (목적격)보어

I saw her dance

주어 동사 목적어 (목적격)보어

블로그 설명중에 지각동사로 5형식을 사용할 때 목적격 보어에 동사원형이 되어 있다고 했는데 찾아보니 형태가 다양하게 들어올 수 있다.

주어 + 동사 + 목적어 + (목적격) 보어

명사

형용사

과거분사

현재분사

동사원형(원형부정사)

I saw her dancing. (현재분사)

그녀가 춤추고 있는 것을 보았다.

I saw him entering the house. (현재분사)

그가 집에 들어가고 있는 것을 보았다.

I heard her playing the piano. (현재분사)

그녀가 피아노 치고 있는 것을 들었다.

I felt my room shaking last night. (현재분사)

나는 내 방이 흔들리고 있는 것을 느꼈다.

I heard my name called (과거분사)

나는 내이름이 불린 것을 들었다.

I saw her dead. (형용사)

나는 그녀가 죽은 것을 보았다.

영어 5형식 구조

ktko — Mon, 13 Jan 2020 00:17:34 +0900

문장 성분으로 본 5형식 구조

1형식 : 주어 + (자)동사

2형식 : 주어 + (자)동사 + 보어

3형식 : 주어 + (타)동사 + 목적어

4형식 : 주어 + (타)동사 + 간접목적어 + 직접목적어

5형식 : 주어 + (타)동사 + 목적어 + 보어

자동사는 동사가 주어에게 영향을 준다.

반면에 타동사는 동사가 목적어 등에 영향을 준다.

품사로 본 5형식 구조

1형식 : 명사 + (자)동사

2형식 : 명사 + (자)동사 + 명사/형용사

3형식 : 명사 + (타)동사 + 명사

4형식 : 명사 + 동사 + 명사 + 명사

5형식 : 명사 + 동사 + 명사 + 명사/형용사

5형식 해석하기

1형식 : ~은,는,이,가 + ~다

I sleep

나는 잔다

2형식 : ~은,는,이,가 + ~다 + ~인,~한 등

She is beautiful

그녀는 아름답다.

Theo is Programmer

테오는 프로그래머다.

3형식 : ~은,는,이,가 + ~다 + ~을, 를

I love you

나는 너를 사랑한다.

I ate an apple

나는 사과를 먹었다.

4형식 : ~은,는,이,가 + ~다 + ~에게 + ~을,를

He made me cookies

그는 나에게 쿠키를 만들어주었다.
me는 간접목적어, cookies는 직접목적어가 된다.

5형식 : ~은,는,이,가 + ~다 + ~를 + ~하도록,~하게 등

He made me crazy
그는 나를 미치게 만들었다.

5형식은 사역동사/지각동사를 더 공부해야되는데, 공부해서 포스팅해야겠다.

as 해석 쉽게 해보기

ktko — Sun, 12 Jan 2020 19:14:37 +0900

부사, 전치사, 접속사로 사용되는 as는 8가지의 뜻을 가지고 있는데 쉽게 해석할 수 있는 방법이 있다.

그 방법은.. as를 해석할 때 (equal), = 이라는 큰 틀을 가지고 생각하자.

~ 처럼 (전치사)

Theo was dressed as Diablo

테오는 옷을 입었다. 디아블로처럼

Theo = Diablo

~ 로서 (전치사)

As your friend, Can I give you advice ?

친구로서, 내가 너에게 충고를 해도 될까 ?

Your friend = I

~ 듯이 (부사)

Theo worked hard today as always

테오는 항상 열심히 일했다 늘 그랬듯이.

worked hard = always

항상 열심히 일한 것 = 항상

~ 만큼 ~한 (부사)

I am as handsome as Saru

나는 사루 만큼 잘생겼다.

I = handsome = Saru

~ 하는 동안에 (접속사)

Theo studied english as saru cleaned the house

사루가 집을 청소하는 동안에 테오는 영어 공부를 했다.

여기서는 theo와 saru가 같다는 의미가 아니다.

시간대의 동등함을 나타내고 있다. 즉 공부했던 시간과 청소했던 시간이 동등함을 나타낸다.

~ 대로 (접속사)

please do as I say

내가 말하는 대로 해주세요.

내가 말하는(I say)와 해달라는(do)의 동등함을 나타낸다.

~ 듯이 (접속사)

As you know. we need to finish this project soon.

너가 알고 있듯이, 우리는 이 프로젝트를 빨리 끝내야 한다.

you know = to finish this project soon.

~ 때문에 (접속사)

I had to pay for the repairs as it was my fault.

내가 한 실수 때문에 치료비를 지불해야 한다.

원인과 결과가 한 묶음으로서 표현되었다.

내가 한 실수는 = 수리비의 지불

shoud, have to 차이에 대해서

ktko — Thu, 9 Jan 2020 13:50:27 +0900

I should go to work this saturday.

이번주 토요일에 출근해야 돼라고 번역하면 should를 잘못 이해하는 것이다.

have to(의무) : ~해야되 / 해야된다는

should(권장의 의미) : ~ 하는게 좋겠어, ~하는게 좋을거야

I should go to work this saturday.

나 이번주 토요일에 출근해야겠어/해야되겠어/하는게 좋을거야/하는게 좋겠어

I have to go work this saturday.

나 이번주 토요일에 출근해야돼

don't have to

안해도 된다, 할 필요가 없다.

you don't have to come early

일찍 오지 않아도 된다.

I don't have to get up early tomorrow

내일 일찍 일어나지 않아도 된다. 내일 일찍 일어날 필요가 없다.

You don't have to worry about that

걱정할 필요가 없다. 걱정 안해도 된다.

shouldn't(개인적인 충고/조언)

~하지 않는게 좋겠다.

~하면 안된다.

~ 하지마

You shouldn't carry so much cash.

많은 돈을 가지고 다니면 안된다.

You shouldn't take those vitamins so often

그 비타민을 자주 먹으면 안된다.

참고 : https://www.youtube.com/watch?v=UUTnXGIHi4c