Owl Life

"Can I get"으로 말하는 원어민 표현: 식상한 패턴의 놀라운 변신

Owl Life — Sat, 13 Jun 2026 15:07:48 +0900

많은 영어 학습자들이 해외 여행을 가거나 카페, 식당에 방문했을 때 "Can I get a latte?" 혹은 "Can I get an americano?"와 같은 주문 표현을 자주 사용합니다. 하지만 "Can I get"이라는 패턴은 단순히 음식을 주문할 때만 쓰이는 것이 아닙니다.

영수증이나 환불을 요청할 때, 추가적인 물품을 요구할 때, 심지어 다른 매장의 연락처를 물어볼 때도 원어민들은 "Can you give me" 대신 "Can I get"을 사용하여 아주 자연스럽고 주도적인 표현을 만들어 냅니다. 김재우 선생님의 강의 내용을 바탕으로 이 만능 패턴의 확장 활용법을 완벽하게 마스터해 보겠습니다.

1. 식당 및 카페에서의 추가 요청과 포장

식당에서 식사를 하다가 필요한 물품이 더 생겼거나, 남은 음식을 포장해 가고 싶을 때 "Can I get"을 활용하면 상대방에게 부담을 주지 않으면서도 명확하게 요구를 전달할 수 있습니다.

Can I get an extra fork?
포크 하나 더 주시겠어요?
Can I get some extra napkins?
냅킨 좀 더 주시겠어요?
Can I get this to go?
이것 좀 포장해 주실 수 있나요?

추가 예문

Can I get some ice water for the table, please?
저희 테이블에 얼음물 좀 가져다주실 수 있나요?
Can I get a small box to pack the rest of my pizza?
남은 피자를 포장할 작은 상자 하나 주시겠어요?
Can I get another menu, we need to order one more dish.
메뉴판 하나 더 주시겠어요, 요리를 하나 더 주문해야 해서요.

2. 매장 및 쇼핑 시 결제 관련 요청

물건을 구매하거나 정당한 소비자로서의 권리를 요구할 때, 딱딱하고 직설적인 표현 대신 "Can I get"을 사용하면 정중하면서도 세련된 대화가 가능해집니다.

Can I get a refund?
환불 좀 받을 수 있을까요?
Can I get my receipt, please?
영수증 좀 받을 수 있을까요?

추가 예문

Can I get a discount if I pay in cash instead of using a credit card?
신용카드 대신 현금으로 결제하면 할인 좀 받을 수 있을까요?
Can I get an itemized bill to check the total amount closely?
전체 금액을 자세히 확인해 보게 세부 내역이 나온 영수증을 받을 수 있을까요?
Can I get a paper bag instead of a plastic one for these clothes?
이 옷들을 담아 갈 비닐봉지 대신 종이 쇼핑백으로 받을 수 있을까요?

3. 정보 및 연락처 요청 (실전 대화 확장)

매장에 제고가 없어서 다른 지점의 연락처를 직접 알아내야 하는 상황처럼, 상대방에게 특정 정보나 연락처를 정중하게 물어볼 때도 이 패턴이 아주 유용하게 사용됩니다.

Can I get their number?
그곳(강남점) 전화번호 좀 알 수 있을까요?

추가 예문

Can I get your email address so that I can send the presentation file later?
나중에 발표 자료 파일을 보내드릴 수 있도록 이메일 주소 좀 알려주실 수 있나요?
Can I get the Wi-Fi password for this coffee shop?
이 커피숍 와이파이 비밀번호 좀 알 수 있을까요?
Can I get the directions to the nearest subway station from here?
여기서 가장 가까운 지하철역으로 가는 길 좀 알려주실 수 있나요?

4. [비즈니스 응대 팁] 상대방이 원하는 재고가 없을 때

서비스업이나 직장 생활에서 상대방이 찾는 물건이나 서류가 준비되지 않았을 때, "Sorry, we don't have it."처럼 너무 단정적이고 차가운 표현보다는 완곡하고 공손한 어조를 사용하는 것이 중요합니다.

I don't think we have that item in stock, but the Gangnam branch might.
죄송하지만 그 제품은 현재 저희 매장에 재고가 없는 것 같습니다만, 강남점에는 있을지도 모릅니다.
(상대방이 원치 않는 소식을 전할 때는 문두에 "I don't think~~" 나 "I'm afraid~~"를 사용하여 어조를 부드럽게 톤다운 시키는 것이 원어민들의 대화 방식입니다. 또한 확실하지 않은 가능성을 말할 때는 조동사 'might'를 활용합니다.)

추가 예문

I don't think the manager is available right now, but the assistant might be able to help you.
지금 매니저님이 자리에 계시지 않는 것 같습니다만, 비서분이 도와드릴 수 있을지도 모릅니다.
I'm afraid we don't have any tables open at the moment, but the waiting time might be short.
죄송하지만 현재는 빈 테이블이 없습니다만, 대기 시간은 짧을지도 모릅니다.
I don't think the system is working properly today, but the IT team might fix it soon.
오늘 시스템이 제대로 작동하지 않는 것 같습니다만, IT 팀에서 곧 고칠지도 모릅니다.

원어민처럼 자연스럽고 완성도 높은 문장 표현을 구사하기 위해서는 단순한 단어의 조합을 넘어, 문맥에 맞는 부드러운 패턴 연동 연습이 필요합니다. 오늘 학습한 "Can I get" 패턴의 다양한 확장형 문장들을 입으로 직접 소리 내어 반복해 보시기 바랍니다.

"무례하다" 영어로 rude만 쓰셨나요? 뉘앙스별 6가지 필수 표현 총정리

Owl Life — Fri, 12 Jun 2026 11:06:50 +0900

우리는 보통 누군가가 무례하거나 예의가 없을 때 가장 먼저 'rude'라는 단어를 떠올립니다. 하지만 영어에는 직설적으로 싸가지가 없는 상황, 사회적 통념이나 에티켓에 어긋나는 상황, 혹은 공감 능력이 부족해 남에게 상처를 주는 상황 등 뉘앙스에 따라 완전히 다른 단어들을 사용합니다.

김재우 선생님의 강의를 바탕으로, 상황에 딱 맞는 자연스러운 '무례함' 관련 표현 6가지를 완벽하게 분석해 보겠습니다.

1. Rude : 직설적으로 무례하고 버릇없는

가장 흔히 쓰이는 표현으로, 행동이나 말이 상대방에게 불쾌감을 줄 정도로 대놓고 무례하거나 싸가지가 없을 때 사용하는 직설적인 단어입니다.

Would it be rude if I left your mom's party a little early?
내가 장모님 파티에서 조금 일찍 일어나면 무례한 행동일까?

추가 예문

It is incredibly rude to stare at people like that.
사람을 그런 식으로 쳐다보는 것은 엄청나게 무례한 짓이다.
He slammed the door in my face, which I thought was extremely rude.
그는 내 앞에서 문을 쾅 닫아버렸는데, 나는 그것이 극도로 무례하다고 생각했다.
I don't mean to be rude, but could you please lower your voice?
무례하게 굴려는 건 아닌데, 목소리 좀 낮춰 주시겠어요?

2. Unkind : 정서적 배려나 눈치가 없는 (애가 좀 그런)

사전적으로는 '불친절한'으로 번역되지만, 실제 뉘앙스는 악의가 있다기보다는 정서적 공감 능력이 부족해서 남의 기분을 배려하지 못하고 상처 주는 말이나 행동을 툭툭 던지는 사람에게 자주 쓰입니다. "걔가 나쁜 애는 아닌데 좀 그래"라고 할 때 딱 맞는 표현입니다.

My sister isn't evil. She is just unkind.
우리 여동생이 아주 못된 애는 아니야. 그냥 애가 좀 배려가 없고 그래.

추가 예문

It was unkind of you to bring up his past failures in front of everyone.
모든 사람 앞에서 그의 과거 실패를 꺼낸 것은 네가 좀 생각이 짧고 배려가 없었던 거야.
She didn't mean to hurt you; she can just be a bit unkind sometimes without realizing it.
그녀가 너에게 상처를 주려던 건 아니었어. 그냥 가끔 자신도 모르게 좀 철없고 쌀쌀맞게 굴 때가 있어.
I find it unkind when people ignore someone who is clearly struggling.
나는 사람들이 분명히 힘들어하고 있는 사람을 모른 척하는 것이 참 정이 없고 냉정하다고 생각한다.

3. Impolite : 사회적 에티켓이나 상식에 어긋나는

'rude'보다 훨씬 순화되고 점잖은 단어입니다. 사회적 규범, 상식, 에티켓, 대인관계 예절에 어긋나는 행동을 했을 때 "매너가 좀 없으시네요", "실례가 되는 행동입니다"라는 뉘앙스로 사용됩니다.

It is impolite to ask someone about their salary.
누군가에게 연봉을 묻는 것은 실례이다.

추가 예문

It is considered impolite to keep checking your phone while having dinner with someone.
누군가와 저녁 식사를 하면서 계속 핸드폰을 확인하는 것은 예의에 어긋나는 행동으로 여겨진다.
Interrupting someone in the middle of a sentence is very impolite.
상대방이 말하는 도중에 말을 끊는 것은 매우 무례한 짓이다.
She gave an impolite response to a perfectly reasonable question.
그녀는 지극히 정당한 질문에 무례한 답변을 내놓았다.

4. Ill-mannered : 버릇없고 매너가 잘못된

형용사 앞에 'ill-'이 붙어 '잘못된', '나쁜'의 뜻을 가집니다. 가정 교육을 잘 받지 못했거나 기본적인 공공장소 예절을 전혀 지키지 않는 '버릇없는' 사람을 묘사할 때 자주 쓰입니다.

The ill-mannered boy on the bus was yelling at his mom.
버스에 탄 그 버릇없는 소년은 자기 엄마에게 소리를 지르고 있었다.

추가 예문

I cannot tolerate ill-mannered guests who treat the staff poorly.
나는 직원들을 하대하는 버릇없는 손님들을 용납할 수 없다.
His ill-mannered behavior at the dinner table embarrassed his parents.
식사 자리에서 보인 그의 매너 없는 행동은 부모를 당황스럽게 만들었다.
No one wants to work with such an ill-mannered colleague.
그렇게 예의라곤 찾아볼 수 없는 동료와는 아무도 함께 일하고 싶어 하지 않는다.

5. Have no manners : 매너가 전혀 없는 (버리장머리 없는)

한국어의 "매너 꽝이다", "버릇이 전혀 없다"와 일맥상통하는 표현입니다. 공공장소나 가정에서 지켜야 할 최소한의 도리를 지키지 않는 상태를 뜻합니다.

He has no manners at home but is polite around strangers.
걔는 집에서는 버리장머리가 전혀 없는데, 낯선 사람들 앞에서는 예의 발라.

추가 예문

Chewing with your mouth open shows that you have no manners.
입을 벌린 채 음식을 씹는 것은 네가 매너가 전혀 없다는 것을 보여준다.
Those teenagers yelling in the library clearly have no manners.
도서관에서 고성방가를 지르는 저 10대들은 정말 매너가 꽝이다.
I was shocked by his behavior; it was as if he had no manners at all.
나는 그의 행동에 충격을 받았다. 마치 매너라는 것 자체를 전혀 배우지 못한 사람 같았다.

6. Obnoxious : 불쾌감을 줄 정도로 매너가 꽝인 (민폐인/정신 나간)

단순히 예의가 없는 수준을 넘어, 주변 사람들을 몹시 불쾌하게 만들고 눈살을 찌푸리게 만드는 행동을 할 때 씁니다. 길거리나 공공장소에서 타인에게 막대한 피해를 주는 안하무인 격 행동에 딱 어울리는 강한 표현입니다.

It is so obnoxious to smoke in a park with children nearby.
근처에 아이들이 있는 공원에서 담배를 피우는 것은 정말 매너 꽝이다.

추가 예문

The man next to me was making obnoxious noises while watching the movie.
내 옆자리의 남자는 영화를 보는 동안 아주 불쾌한 소음을 내고 있었다.
I had to leave the restaurant because of an obnoxious customer at the next table.
나는 옆 테이블의 무개념 손님 때문에 식당을 나와야만 했다.
He always boasts about his wealth in the most obnoxious way possible.
그는 항상 가장 꼴불견인 방식으로 자신의 부를 과시한다.

상황에 맞는 정확한 단어 선택은 영어를 훨씬 더 풍성하고 원어민스럽게 만들어 줍니다. 상대방의 무례함의 강도와 맥락에 따라 오늘 배운 6가지 표현을 적재적소에 활용해 보시기 바랍니다.

"내 핸드폰이 죽었다?" 원어민 뇌를 따라잡는 사물 의인화 영어

Owl Life — Thu, 11 Jun 2026 13:05:19 +0900

영어와 한국어의 가장 큰 차이점 중 하나는 바로 주어를 선택하는 방식에 있습니다. 한국어는 주로 사람을 주어로 삼아 대화를 이어 나가는 반면, 영어는 사물이나 개념을 마치 살아있는 사람처럼 주어로 사용하는 '사물 의인화(Personified)'가 매우 발달한 언어입니다.

김재우 선생님의 강의를 바탕으로 원어민들이 일상생활과 비즈니스, 미디어에서 자주 사용하는 가장 실용적이고 자연스러운 사물 주어 표현들을 정리해 드립니다. 과한 표현은 덜어내고 보편적으로 쓰이는 문장들만 엄선했습니다.

1. 일상생활에서 쓰이는 기계 및 사물의 의인화

기계가 말을 듣지 않거나 문이 열리지 않을 때, 원어민들은 사물이 고집을 부리거나 거부하는 것처럼 표현합니다. 컴퓨터나 핸드폰의 기능이 완전히 멈췄을 때 'Dead'라는 표현을 쓰는 것도 같은 맥락입니다.

The computer refuses to turn on.
컴퓨터가 이상하게 안 켜지네요.
(컴퓨터 자체에 문제가 있어서 스스로 안 켜지려고 고집을 부리는 뉘앙스입니다. 반면 컴퓨터는 문제가 없는데 내가 조작법을 모르는 듯한 상황이라면 "I can't seem to turn it on"이 적절합니다.)
The door wouldn't open.
문이 안 열려요.
(문을 아무리 열려고 해도 열리지 않을 때 사용합니다. 차 시동이 안 걸릴 때도 "My car wouldn't start"라고 표현합니다.)

추가 예문

My phone died right after I received your text message.
네 문자 메시지를 받자마자 내 핸드폰 배터리가 나갔어.
The printer refuses to feed the paper properly.
프린터가 이상하게 종이를 제대로 빨아들이지 않네.
The old rusty lock wouldn't turn no matter how hard I tried.
내가 아무리 노력해도 그 낡고 녹슨 자물쇠는 돌아가지 않았다.

2. 자연 및 시간의 의인화

시간이 흘러가거나 날씨가 협조하는 상황을 표현할 때도 사물 주어를 활용하면 문장이 훨씬 생동감 넘치고 영어다워집니다.

Time flew by so quickly during the trip.
여행 동안 시간이 정말 휙 지나가 버렸어.
(새나 비행기가 날아가듯 시간이 빠르게 지나갔음을 뜻하는 아주 자연스러운 표현입니다.)
We might go hiking tomorrow if the weather permits.
날씨가 허락한다면 내일 등산을 갈지도 몰라.
(사람이 허락하듯 날씨가 허락한다는 표현으로, 날씨가 좋으면 가겠다는 의미를 정중하고 자연스럽게 나타냅니다.)

추가 예문

Time flies when you are focusing on something you love.
자신이 좋아하는 것에 집중할 때는 시간이 날아가듯 빨리 간다.
The outdoor concert will begin at 7 PM, weather permitting.
날씨가 허락한다면 야외 콘서트는 오후 7시에 시작될 것입니다.
The years flew by before we even realized how much we had grown.
우리가 얼마나 성장했는지 깨닫기도 전에 수년의 세월이 휙 지나가 버렸다.

3. 음식과 신체의 반응 표현

내 몸에 맞지 않는 음식이나 통증이 심한 상태를 표현할 때도 사람을 주어로 쓰지 않고 음식이나 통증 자체를 주어로 내세울 수 있습니다.

That spicy tteokbokki isn't agreeing with me.
그 매운 떡볶이가 내 입맛(속)에 안 맞네.
('Agree with'는 사람의 의견에 동의할 때도 쓰이지만, 음식을 먹고 속이 불편하거나 체질에 맞지 않을 때 사물을 주어로 하여 빈번하게 사용됩니다.)
My headache is killing me.
두통 때문에 미쳐 버리겠어.
(두통이 나를 죽이고 있다는 뜻의 일상적인 과장 표현으로, 통증이 매우 심함을 생생하게 나타냅니다.)

추가 예문

I love dairy products, but cheese doesn't always agree with me.
나는 유제품을 좋아하지만 치즈는 항상 내 속과 잘 맞지는 않는다.
My feet are killing me after walking around the shopping mall for hours.
쇼핑몰을 몇 시간 동안 걸어 다녔더니 발이 아파 죽겠다.
The greasy food from last night isn't agreeing with his stomach.
어젯밤에 먹은 기름진 음시기 그의 위장과 잘 맞지 않고 있다.

4. 뉴스 및 비즈니스(문어체)에서의 사물 주어

미디어 기사나 기업 보고서 등 격식 있는 자리에서는 사물 주어를 활용하여 문장을 훨씬 명확하고 간결하게 만듭니다. 일상 회화보다는 텍스트나 공식적인 발표에서 힘을 발휘하는 구조입니다.

Last year saw a record high snowfall.
작년은 기록적인 강설량을 보았다. (작년에 역대 최고의 강설량이 기록되었다.)
('작년'이라는 시간이 주어가 되어 특정 현상을 목격했다는 식의 전형적인 뉴스/보고서용 표현입니다.)
My experience taught me that patience is key.
내 경험은 나에게 인내심이 핵심이라는 것을 가르쳐 주었다. (경험을 통해 인내심이 중요하다는 것을 배웠다.)
("Based on my experience"보다 문장을 더 간결하고 힘 있게 만들어 주는 사물 주어 구조입니다.)
A dominant player in the industry
업계 선두 주자 (시장 지배적 기업)
(기업을 'Player(선수)'로 의인화하여 표현하는 비즈니스 영어의 전형적인 방식입니다.)

추가 예문

The third quarter saw a significant turnaround in corporate profits.
3분기는 기업 이익의 상당한 전환점을 보았다. (3분기에 기업 이익이 크게 반등했다.)
Living abroad for five years taught her how to adapt to new cultures.
5년 동안 해외에서 산 것은 그녀에게 새로운 문화에 적응하는 법을 가르쳐 주었다.
Our company aims to become a major player in the renewable energy market.
우리 회사는 신재생 에너지 시장에서 주요 주자가 되는 것을 목표로 하고 있다.

영어식 사고를 기르기 위해서는 한국어의 '나는 ~했다' 패턴에서 벗어나 사물을 주어 자리에 놓는 연습을 의도적으로 해야 합니다. 오늘 배운 문장들을 눈으로만 보지 마시고, 입으로 직접 소리 내어 익혀보시길 바랍니다.

1분 만에 끝내는 Eat, Have, Get 완벽 구분법 (상황별 먹다 동사 총정리)

Owl Life — Wed, 10 Jun 2026 15:02:12 +0900

우리가 영어로 대화할 때 가장 많이 쓰는 표현 중 하나가 바로 '먹다' 혹은 '마시다'입니다. 한국어로는 전부 동일한 단어로 통용되지만, 영어에서는 Eat, Have, Get 세 가지 동사가 가진 뉘앙스가 명확하게 구분됩니다.

많은 학습자들이 기계적으로 Eat만 사용하곤 하지만, 원어민의 일상 대화를 들어보면 상황에 따라 동사를 유연하게 선택합니다. 1분 만에 이 세 가지 동사의 핵심 차이를 마스터하고 실전에 바로 적용할 수 있도록 예문과 함께 정리해 드리겠습니다.

1. Eat: 물리적인 먹는 행위와 양을 강조할 때

동사 Eat은 음식을 입에 넣고 씹어 삼키는 '물리적 행위' 그 자체나 먹는 '양'을 강조할 때 주로 사용합니다. 음식을 섭취했다는 사실이나 대화의 맥락보다는, 무엇을 얼마나 많이 혹은 어떻게 먹었는지가 중요한 정보일 때 가장 적절한 선택이 됩니다.

영상 속 예시: "뷔페에서 너무 많이 먹었어"
I ate too much at the buffet.
나 뷔페에서 너무 많이 먹었어.
- 뷔페라는 공간에서 음식을 과도하게 섭취한 '행위와 양'에 포커스가 맞춰져 있으므로 Ate를 사용하는 것이 자연스럽습니다.

[추가 예문 학습]

You should not eat late at night if you want to stay healthy.
건강을 유지하고 싶다면 밤늦게 음식을 먹지 않는 것이 좋다.
The child refused to eat his dinner because he had too many snacks.
그 아이는 간식을 너무 많이 먹어서 저녁 식사 먹기를 거부했다.
We ate a huge pizza by ourselves while watching the football game.
우리는 축구 경기를 보는 동안 우리끼리 커다란 피자 한 판을 다 먹었다.

2. Have: 일상적인 식사 메뉴 및 루틴을 말할 때

동사 Have는 음식을 씹는 행위 자체보다 '무엇을 먹었다'라는 식사의 내용, 경험, 혹은 평소에 반복하는 루틴을 나타냅니다. 원어민들이 점심이나 저녁 메뉴를 묻고 답할 때 90% 이상 압도적으로 사용하는 동사입니다. 음식뿐만 아니라 음료나 술을 마실 때도 공통으로 사용할 수 있습니다.

영상 속 예시: "나 오늘 점심으로 파스타 먹었어"
I had pasta for lunch today.
나 오늘 점심으로 파스타 먹었어.
- 점심 식사로 파스타라는 메뉴를 선택해 섭취했다는 일상적인 스케줄과 내용을 공유하는 맥락입니다.

[추가 예문 학습]

I usually have a simple salad and a glass of water for dinner.
나는 보통 저녁 식사로 간단한 샐러드와 물 한 잔을 먹는다.
Did you have breakfast before leaving the house this morning?
너 오늘 아침에 집에서 나오기 전에 아침 식사 먹었니?
We had a wonderful dinner at that new Italian restaurant last weekend.
우리는 지난 주말에 그 새로운 이탈리아 레스토랑에서 멋진 저녁 식사를 했다.

3. Get: 식사나 음료를 매개로 사람들과 어울릴 때 (Social Context)

동사 Get이 식사나 음료 명사와 함께 쓰일 때는 단순히 배를 채우거나 섭취하는 행위를 넘어, 사람들과 만나 이야기를 나누고 친목을 도모하는 '사회적 어울림(Socializing)'의 의미가 강하게 내포됩니다. Eat이나 Have보다 훨씬 포괄적이고 구어체적인 느낌을 줍니다.

영상 속 예시: "우리는 같은 동네에 살아서 가끔씩 커피를 마셔"
We live in the same area, so we get coffee every once in a while.
우리는 같은 동네에 살아서 가끔씩 커피를 마셔.
- 단순히 액체를 목구멍으로 넘기는 것이 목적이 아니라, 커피를 한잔 사이에 두고 만나서 근황을 나누고 수다를 떤다는 뉘앙스입니다.

[추가 예문 학습]

Let's get dinner together sometime next week to catch up on each other's lives.
우리 다음 주 중에 같이 저녁 먹으면서 그동안 밀린 이야기나 좀 하자.
Should we get some drinks after finishing this project tonight?
오늘 밤 이 프로젝트를 마친 후에 우리 술이나 한잔하러 갈까?
Why don't we get lunch while you are visiting our office tomorrow afternoon?
내일 오후에 당신이 우리 사무실에 방문하시는 동안 같이 점심 식사 하시는 건 어떻습니까?

한 눈에 정리하는 핵심 요약

Eat: 음식을 입에 넣고 씹어 삼키는 구체적 행위나 양을 강조 (I ate too much)
Have: 점심, 저녁 등 일상적으로 메뉴를 섭취한 내용이나 루틴 (I had pasta for lunch)
Get: 식사나 커피를 매개로 지인들과 만나서 소통하고 어울림 (Let's get coffee)

상황에 맞는 정확한 동사 선택 하나가 여러분의 영어를 훨씬 자연스럽고 원어민스럽게 만들어 줍니다.

원어민이 쉬운 단어로 수천 가지 문장을 만드는 비결, 기본 동사 활용법

Owl Life — Tue, 9 Jun 2026 11:03:22 +0900

영어 스피킹을 잘하고 싶어서 땀을 삐질삐질 흘리며 토플이나 아이엘츠에 나올 법한 어려운 단어부터 무작정 외우고 계시지는 않나요? 특정 시험이나 학술적인 목적이 아니라면, 일상 회화에서 원어민들은 절대 복잡하고 어려운 단어를 쓰지 않습니다. 원어민 아이들이 언어를 배우듯 가장 쉽고 강력한 기본 동사 몇 개만 제대로 다룰 줄 알아도 수백, 수천 가지의 문장을 자유자재로 구사할 수 있습니다.

이번 학습 자료에서는 영상 속 핵심 내용을 바탕으로 만능 동사인 'Get'과 보관과 유지를 나타내는 'Keep'의 원어민 뉘앙스를 명확하게 짚어보고, 실전에 바로 활용할 수 있는 추가 예문까지 완벽하게 정복해 보겠습니다.

1. 핵심 개념 이해하기

① 만능 동사 Get: 획득, 질병, 그리고 정서적 이해

동사 Get은 단순히 '얻다'라는 뜻을 넘어 상태의 변화나 결과의 획득을 나타내는 가장 범용적인 동사입니다.

물건이나 호의를 요청할 때: 무언가를 가져다 달라고 요청할 때 기계적으로 "Can you give/bring me~~" 패턴을 떠올리기 쉽지만, 원어민들은 주어를 자신(I)으로 설정하여 "Can I get~~" 패턴을 압도적으로 많이 사용합니다. [00:03:36]
- can I get some more water please?
  물 좀 더 주실 수 있을까요? [00:02:33]
질병에 걸렸을 때: 구체적이고 학술적인 의학 동사 대신 Get 뒤에 질병 명사를 붙여 표현합니다. [00:04:13]
- I think I got food poisoning.
  아무래도 나 식중독에 걸린 거 같아. [00:04:13]
감정적으로 이해할 때: 상대방의 마음이나 기분을 깊이 알아주고 이해한다고 할 때 understand 대신 Get을 사용합니다. [00:04:30]
- My husband never gets me.
  저희 남편은 절대 제 마음을 몰라줘요. [00:04:49]

② 유지와 보관의 동사 Keep: 상태의 유지 및 소유

동사 Keep은 일시적으로 무언가를 두는 풋(Put)과 달리, 특정 상태를 지속하거나 물건을 버리지 않고 계속 '보관'하고 있을 때 사용합니다. 숨겨두거나 보관하는 행위를 표현할 때 어려운 단어 대신 Keep 하나로 매끄럽게 처리할 수 있습니다. [00:19:31]

물건을 돌려주지 않고 가질 때: [00:19:04]
- Just keep the umbrella.
  우산은 그냥 너 가져 (안 돌려줘도 돼). [00:19:14]
버리지 않고 보관할 때: [00:19:14]
- I keep all my receipts just in case.
  혹시 몰라서 영수증은 안 버리고 다 모아둬. [00:19:22]
특정 장소에 보관(은닉)할 때: [00:19:48]
- My grandpa used to keep alcohol in the bathroom.
  우리 할아버지는 화장실에 술을 숨겨두곤 하셨어. [00:20:01]

2. 상황별 추가 예문 학습

기본 동사의 활용 범위를 넓히고 완전히 내 것으로 만들기 위해, 일상에서 자주 쓰이는 추가 예문들을 학습해 보겠습니다.

[Get] 패턴 A: 식당, 카페 및 일상에서 무언가를 요청할 때

Can I get a menu and a glass of warm water, please?
메뉴판이랑 따뜻한 물 한 잔만 가져다주실 수 있나요?
Could I get a blanket from the flight attendant during the flight?
비행하는 동안 승무원에게 담요 한 장을 얻을 수 있을까요?
Let me get you a fresh cup of coffee while you wait in the lobby.
로비에서 기다리시는 동안 제가 신선한 커피 한 잔 갖다 드릴게요.

[Get] 패턴 B: 신체적 증상이나 질병을 표현할 때

I usually get a severe headache whenever I am under a lot of stress.
나는 스트레스를 많이 받을 때마다 심한 두통이 생긴다.
He got a terrible cold after walking in the heavy rain without an umbrella.
그는 우산 없이 폭우 속을 걸은 후에 심한 감기에 걸렸다.
You might get a stomachache if you eat that street food without washing your hands.
손을 씻지 않고 저 길거리 음식을 먹으면 배탈이 날지도 모른다.

[Get] 패턴 C: 상대방의 의견이나 감정을 온전히 이해할 때

Don't worry about the explanation because I totally get your point now.
이제 당신의 요점을 완전히 이해했으니 설명에 대해 걱정하지 마세요.
Sometimes I feel like my close friends don't really get who I am.
가끔은 내 친한 친구들이 내가 어떤 사람인지 진짜로 몰라준다는 느낌이 든다.
She completely gets why you had to make such a difficult decision at that time.
그녀는 네가 그 당시에 왜 그렇게 어려운 결정을 내려야만 했는지 온전히 이해하고 있어.

[Keep] 패턴 D: 물건의 소유를 넘겨주거나 지속해서 보관할 때

You can keep that book as long as you need it for your project.
프로젝트에 필요한 만큼 그 책은 네가 계속 가지고 있어도 돼.
I always keep a spare tire and emergency tools in the trunk of my car.
나는 항상 내 자동차 트렁크에 예비 타이어와 비상용 공구를 보관해 둔다.
She keeps her old diary hidden inside the desk drawer so nobody can read it.
그녀는 아무도 읽을 수 없도록 오래된 일기장을 책상 서랍 안에 숨겨 보관한다.

3. 한 눈에 정리하는 핵심 요약

Get: 주어를 I나 We로 잡아 요청할 때(Can I get~), 질병에 걸려 상태가 변할 때(Get sick), 마음을 이해할 때(Get me) 쓰이는 만능 치트키 동사
Keep: 물건을 버리지 않고 지속해서 보관하거나(Keep receipts), 상대방에게 소유권을 넘겨줄 때(Keep it) 사용하는 핵심 동사

어려운 단어 위주로 공부하면 독해에는 도움이 될지 몰라도, 막상 스피킹을 하려고 하면 문장이 턱턱 막히게 됩니다. 회화를 유창하게 구사하고 싶다면 오늘 학습한 Get과 Keep처럼 유연하고 범용성이 높은 기본 동사들을 입으로 반복해서 훈련하는 과정이 최우선되어야 합니다. 기초가 튼튼해야 영어에 날개를 달 수 있습니다.

식중독, 감기, 만성질환까지 동사 'Get' 하나로 마스터하는 일상 영어회화

Owl Life — Mon, 8 Jun 2026 15:00:13 +0900

우리가 일상 대화에서 "감기에 걸리다", "식중독에 걸리다", "당뇨병에 걸리다"처럼 어떤 질병이나 질환을 앓게 되었다고 표현할 때가 많습니다. 이때 한국인 학습자들은 '걸리다'라는 한국어 단어에 갇혀 contract나 develop 같은 다소 딱딱하고 학술적인 동사를 먼저 떠올리곤 합니다.

하지만 실제 원어민들은 일상 회화에서 이러한 표현을 할 때 누구나 알고 있는 아주 쉬운 기본 동사인 'Get'을 사용합니다. 이번 학습 자료에서는 질병의 발병을 나타내는 동사 Get의 원어민 뉘앙스와 무언가를 줄인다고 할 때 쓰이는 유용한 구동사 표현을 함께 정리해 보겠습니다.

1. 핵심 개념 이해하기: Get + 질병/질환

① 질병에 걸리는 '시점과 변화'를 나타내는 Get

동사 Get은 기본적으로 '없던 상태에서 있는 상태로의 변화나 획득'을 나타냅니다. 따라서 Get 뒤에 두통, 감기 같은 가벼운 증상부터 식중독, 당뇨병, 암과 같은 만성 및 중증 질환 명사가 오면 "특정 질병에 걸리다", "증상이 생기다"라는 의미를 가장 자연스럽고 직관적으로 전달하게 됩니다. [00:00:04]

영상 속 예시 1: "길거리 가판대 음식을 먹고 식중독에 걸렸어"
I got food poisoning from a street stall.
나 길거리 가판대에서 음식 먹고 식중독에 걸렸어.
- 이때 전치사 From은 질병이 발생하게 된 '원인'이나 '출처'를 명확하게 밝혀주는 역할을 합니다. [00:00:26]
영상 속 예시 2: "설탕(단것)을 줄이지 않으면 당뇨병에 걸릴 거야"
If you don't cut down on sugar, you are going to get diabetes.
너 설탕 안 줄이면 당뇨병 걸릴 거야.
- 당뇨병은 영어로 diabetes라고 하며, 두 번째 음절에 강세가 있습니다. 무언가의 양을 줄인다고 할 때는 구동사 cut down on을 함께 사용하면 좋습니다. [00:01:10]

② 현재 앓고 있는 '상태'를 나타내는 Have와의 비교

질병을 얻게 된 시점이나 변화를 말할 때는 Get을 쓰지만, 이미 그 질병을 가지고 있는 '현재의 상태'를 묘사할 때는 Have 동사를 구별해서 사용해야 합니다. [00:00:46]

I have a cold right now.
나 지금 감기 걸린 상태야 (감기 기운이 있어).

2. 상황별 추가 예문 학습

원어민의 감각을 체득하고 표현의 범위를 넓히기 위해, 일상에서 자주 발생하는 세 가지 질병 상황별 추가 예문을 살펴보겠습니다.

카테고리 A: 감기, 두통, 몸살 등 가벼운 일상 증상

I think I got a cold because I kept sneezing all morning.
아침 내내 재채기가 계속 나오는 걸 보니 감기에 걸린 것 같다.
He got a severe headache after staring at the computer screen for hours.
그는 몇 시간 동안 컴퓨터 화면을 바라본 후 심한 두통이 생겼다.
You might get a sore throat if you sleep with the window open in this weather.
이런 날씨에 창문을 열고 자면 목 감기에 걸릴지도 모른다.

카테고리 B: 식중독, 알레르기 등 외부 요인에 의한 급성 질환

She got a terrible rash from eating seafood at the restaurant last night.
그녀는 어젯밤 레스토랑에서 해산물을 먹고 심한 두드러기가 났다.
Many people get food poisoning during the summer if they consume raw fish.
많은 사람이 여름철에 날생선을 섭취하면 식중독에 걸린다.
He got a stomachache from drinking spoiled milk without checking the expiration date.
그는 유통기한을 확인하지 않고 상한 우유를 마셨다가 배탈이 났다.

카테고리 C: 당뇨, 고혈압 등 식습관 조절이 필요한 만성 질환

If you don't cut down on salty food, you are highly likely to get high blood pressure.
짠 음식을 줄이지 않으면 고혈압에 걸릴 확률이 매우 높다.
He was warned by his doctor that he might get diabetes if he doesn't change his lifestyle.
그는 생활 습관을 바꾸지 않으면 당뇨병에 걸릴 수 있다는 의사의 경고를 받았다.
She decided to cut down on fast food to prevent getting chronic diseases.
그녀는 만성 질환에 걸리는 것을 예방하기 위해 패스트푸드를 줄이기로 결심했다.

3. 한 눈에 정리하는 핵심 요약

Get + 질병 명사: 질병에 걸리다 (상태의 변화를 강조)
Have + 질병 명사: 질병을 앓고 있다 (현재의 상태를 강조)
Cut down on + 명사: ~의 양을 줄이다 (소비나 섭취를 줄일 때 필수 구동사)

어려운 의학 동사를 쓰려고 고민하다가 대화가 끊기는 것보다, 원어민처럼 쉽고 유연한 'Get' 동사를 활용하여 막힘없이 스피킹을 이어가 보시기 바랍니다.

Can you?와 Do you?의 한 끗 차이: 원어민이 상황마다 다르게 쓰는 이유

Owl Life — Sun, 7 Jun 2026 16:58:52 +0900

우리가 상대방에게 무언가를 질문할 때 가장 많이 헷갈려하는 두 가지 패턴이 바로 "Can you ~?"와 "Do you ~?"입니다. 사전적인 의미만 생각하면 무언가를 할 수 있는지 능력을 물을 때 'Can'을 쓰고, 평소에 하는지 여부를 물을 때 'Do'를 쓴다고 기계적으로 외우기 쉽습니다.

하지만 실제 원어민들의 대화를 들어보면 우리의 직관과 다르게 흘러가는 상황이 많습니다. 예를 들어 눈앞에 있는 새가 보이냐고 물을 때 왜 "Can you see?"보다 "Do you see?"를 많이 쓸까요? 그리고 영어 구사 여부를 물을 때 "Can you speak English?"가 자칫 무례하게 들릴 수 있는 이유는 무엇일까요? 이번 학습 자료를 통해 두 표현의 명확한 뉘앙스 차이를 짚어보겠습니다.

1. 핵심 개념 이해하기: Do you와 Can you의 결정적 차이

① Do you: 평소의 습관, 일반적인 사실, 눈앞의 쉬운 상황

'Do you ~?'는 상대방에게 평소에 그렇게 하는지, 혹은 일반적인 사실이나 상태인지를 물을 때 사용합니다. 특히 감각 동사와 결합할 때, 특별한 능력이나 노력이 필요하지 않고 눈만 뜨면 당연히 보이는 상황이라면 원어민들은 'Can you' 대신 'Do you'를 선택합니다.

영상 속 예시: 엄마가 아이에게 "저 나무에 새 보이니?"라고 할 때
Do you see that bird in that tree?
저 나무에 있는 새 보이니?
- 눈앞에 있는 새를 바라보는 것은 특별한 능력이 요구되는 어려운 일이 아니며, 눈에 보이는 것을 인지했는지 묻는 것이기 때문에 'Do you see'가 자연스럽습니다.
영상 속 예시: 외국인에게 "영어 하세요?"라고 물을 때
Do you speak English?
영어 하세요?
- 상대방이 영어를 할 수 있는 지적 능력이 있는지 의심하며 평가하는 뉘앙스를 주지 않고, 평소에 언어를 사용하는지 매끄럽게 묻는 표준적인 표현입니다.

② Can you: 특별한 기술이나 노력이 필요한 '능력'의 검증

반면 'Can you ~?'는 상대방이 후천적으로 습득한 특별한 기술, 지식, 체력적 한계를 극복하고 '해낼 수 있는지' 그 능력의 유무를 직접적으로 물어보는 뉘앙스가 강합니다. 따라서 당연히 할 수 있는 쉬운 일에 이 표현을 쓰면 자칫 상대를 무시하거나 야보는 뉘앙스를 풍길 수 있습니다.

영상 속 예시: 안전 요원이 탑승객에게 "수영할 줄 아세요?"라고 물을 때
Can you swim?
수영할 줄 아십니까?
- 수영은 누구나 당연히 할 수 있는 행동이 아니라 후천적인 노력이 필요한 '능력'의 영역이므로, 안전상의 이유로 능력 여부를 확인할 때는 'Can you'가 완벽하게 어울립니다.

2. 상황별 추가 예문 학습

두 패턴의 범용성을 넓히고 실전에 바로 활용할 수 있도록, 일상 대화에서 자주 쓰이는 추가 예문들을 세 가지 상황으로 나누어 살펴보겠습니다.

상황 1: 감각 및 인지 여부를 물어볼 때 (Do you see / hear / smell)

특별한 노력 없이 주변 환경을 인지하고 있는지 물을 때는 Do를 사용합니다.

Do you hear that strange noise coming from the basement?
지하에서 나는 저 이상한 소리 들리니?
Do you smell something burning in the kitchen right now?
지금 주방에서 무언가 타는 냄새 나지 않아?
Do you notice any difference in my haircut today?
너 오늘 내 헤어스타일 바뀐 거 알아채겠어?

상황 2: 후천적인 기술, 지식, 전문 능력을 물어볼 때 (Can you)

학습이나 훈련을 통해 얻은 능력을 검증하듯 물을 때는 Can을 사용합니다.

Can you play the piano or any other musical instruments?
피아노나 다른 악기 연주할 줄 아세요?
Can you drive a manual transmission car, or only automatic?
수동변속기 차량을 운전할 줄 아시나요, 아니면 자동만 가능하신가요?
Can you speak Spanish fluently enough to conduct a business meeting?
비즈니스 미팅을 진행할 수 있을 정도로 스페인어를 유창하게 하실 수 있습니까?

상황 3: 부탁을 하거나 물리적 가능 여부를 물어볼 때 (Can you)

상대방에게 정중하게 도움을 요청하거나 물리적으로 행동이 가능한 환경인지 물을 때는 Can이 자연스럽습니다.

Can you open this tight jar lid for me?
이 꽉 닫힌 병뚜껑 좀 열어줄 수 있어?
Can you reach the top shelf to get that book?
저 책을 꺼내게 맨 위 선반에 손이 닿으시나요?
Can you read the small text on the screen from where you are sitting?
당신이 앉아 있는 자리에서 화면의 작은 글씨가 읽히나요?

3. 한 눈에 정리하는 핵심 요약

Do you speak English?: 영어라는 언어를 평소에 사용하시나요? (매우 자연스럽고 정중한 질문)
Can you speak English?: 당신은 영어라는 언어를 구사할 수 있는 '능력'이 탑재되어 있습니까? (상황에 따라 상대를 시험하거나 야보는 느낌을 줄 수 있음)
Do you see that?: 특별한 능력이 필요 없는 눈앞의 대상을 인지했는지 물을 때
Can you swim?: 훈련이 필요한 신체적 기술이나 능력을 갖추었는지 물을 때

상대방에게 질문을 던지기 전, 이것이 평소의 습관이나 당연한 인지의 영역인지(Do), 혹은 특별한 능력이나 노력이 필요한 영역인지(Can)를 먼저 떠올려 보세요. 이 기준만 세워도 오해 없는 자연스러운 영어를 구사할 수 있습니다.

영화 볼 때 언제 See를 쓰고 언제 Watch를 쓸까? 3분 만에 마스터하는 뉘앙스 차이

Owl Life — Sat, 6 Jun 2026 10:57:44 +0900

우리가 영어를 공부할 때 '보다'라는 뜻을 가진 동사로 See와 Watch를 가장 먼저 배웁니다. 하지만 막상 일상에서 영화나 스포츠 경기를 보았다고 말할 때, 어떤 상황에서 See를 쓰고 어떤 상황에서 Watch를 써야 하는지 헷갈리는 경우가 많습니다.

"그 영화 봤어?"라고 물어볼 때 습관적으로 "Did you watch the movie?"라고 하기 쉽지만, 상황에 따라 이는 원어민에게 다소 어색하게 들릴 수 있습니다. 이번 학습 자료에서는 See와 Watch의 명확한 개념 차이를 알아보고 실제 대화에 바로 적용할 수 있도록 정리해 보겠습니다.

1. 핵심 개념 이해하기: See vs Watch

① See: 시야에 들어와 자연스럽게 '인지'하는 것

동사 See는 눈을 뜨고 있을 때 의도하지 않아도 시야에 사물이나 사람이 들어와 그것을 발견하거나 인지하는 감각적인 행위입니다. 또한 영화관에 가서 영화라는 전체적인 문화생활을 경험하거나 스크린을 통해 작품을 접했을 때도 See를 사용합니다.

영상 속 예시: "나 어제 공원에서 너 봤어"
I saw you at the park yesterday.
나 어제 공원에서 너 봤어.
- 의도적으로 유심히 관찰한 것이 아니라, 공원에 있다가 우연히 너의 모습이 내 시야에 들어와 인식했다는 의미입니다.
영상 속 예시: "나 대형 스크린으로 그 영화 봤어"
I saw the movie on the big screen.
나 대형 스크린으로 그 영화 봤어.
- 극장이나 대형 스크린이 있는 공간에서 영화를 관람하는 전체적인 경험을 강조할 때는 Saw가 훨씬 자연스럽습니다.

② Watch: 의도를 가지고 움직임을 '주시'하는 것

반면 Watch는 목적이나 의도를 가지고 움직이는 대상, 변화하는 상황을 일정 시간 동안 주의 깊게 지켜보는 행위입니다. 주로 집에서 TV, 넷플릭스, 유튜브처럼 화면 안의 움직이는 영상을 집중해서 시청할 때 사용합니다. 만약 사람에게 수동태나 진행형으로 잘못 사용하면 '감시하다' 혹은 '지켜보다'라는 다소 부담스러운 뉘앙스가 될 수도 있습니다.

영상 속 예시: "나 어제 공원에서 너 지켜봤어"
I watched you at the park yesterday.
나 어제 공원에서 너 지켜봤어.
- 너에게 시선을 고정하고 어떤 행동을 하는지 의도적으로 관찰했다는 뉘앙스이므로 상황에 따라 상대방이 오해할 수 있습니다.
영상 속 예시: "어제저녁에 넷플릭스 다큐멘터리 보는 동안 엄마한테 전화가 왔어"
My mom called while I was watching a Netflix documentary last night.
어제저녁에 넷플릭스 다큐멘터리 보는 동안 엄마한테 전화가 왔어.
- 화면의 영상 콘텐츠를 주의 깊게 시청하고 있던 지속적인 행위의 맥락이므로 Watching이 정확한 표현입니다.

2. 두 동사의 차이를 보여주는 결정적 문장

I saw the game on the TV at the bar but I didn't watch it.
술집 TV에 나오는 경기 화면을 보긴 했는데, 집중해서 시청하지는 않았어.
- 바에 있는 TV 화면 속 경기가 시야에 들어와서 '인지는 했지만(Saw)', 자리에 앉아 본격적으로 경기를 '집중해서 주시하지는 않았다(Didn't watch)'는 두 동사의 차이를 한눈에 보여주는 문장입니다.

3. 상황별 추가 예문 학습

패턴 A: 시야에 들어오거나 관람을 의미하는 See의 추가 예문

Did you see the shooting star that just passed through the night sky?
방금 밤하늘을 지나간 별똥별 봤어?
I want to go see the new musical with my family this coming weekend.
이번 다가오는 주말에 가족들과 함께 그 새로운 뮤지컬을 보러 가고 싶다.
We happened to see our former English teacher at the department store.
우리는 백화점에서 전 영어 선생님을 우연히 뵙게 되었다.

패턴 B: 움직임을 주시하거나 시청을 의미하는 Watch의 추가 예문

Could you watch my luggage for a moment while I go to the restroom?
내가 화장실에 다녀오는 동안 내 짐 좀 잠시 봐줄 수 있어?
The children love to watch the animated series on the tablet computer every afternoon.
아이들은 매일 오후 태블릿 컴퓨터로 애니메이션 시리즈를 시청하는 것을 좋아한다.
I prefer to watch live sports games rather than reading the news articles.
나는 뉴스 기사를 읽는 것보다 라이브 스포츠 경기를 집중해서 보는 것을 선호한다.

4. 한 눈에 정리하는 핵심 요약

See: 눈이 있어서 자연스럽게 보이는 것, 극장에 가서 영화를 관람하는 행위 (Did you see the movie yet?)
Watch: 움직이는 대상을 의도를 가지고 유심히 지켜보는 것, 집에서 영상 매체를 시청하는 행위 (I was watching a Netflix series.)

상황에 따라 두 동사를 올바르게 구분하여 사용하는 것만으로도 원어민과 대화할 때 훨씬 더 자연스러운 뉘앙스를 풍길 수 있습니다.

Have 동사의 숨겨진 진실: 20년 공부보다 강력한 '속성 부여'의 원어민 감각

Owl Life — Fri, 5 Jun 2026 14:56:38 +0900

우리가 영어를 배우면서 가장 먼저 접하는 동사 중 하나는 바로 Have입니다. 학창 시절부터 줄곧 '가지다', '소유하다'라는 뜻으로 기계적으로 암기해 왔기 때문에, 우리는 보통 눈에 보이는 물건을 손에 쥐고 있을 때만 이 동사를 떠올리곤 합니다.

하지만 원어민들의 대화나 미드, 소설을 가만히 들여다보면 100문장 중 20문장 가까이가 우리가 생각하지 못한 방식으로 Have를 사용하고 있습니다. 영어가 유창해지는 가장 빠른 지름길이자, 영어식 사고의 날개를 달아줄 Have 동사의 '주어 속성 표현' 법칙을 자세히 알아보겠습니다.

1. 핵심 개념 이해하기: 주어가 가진 속성과 특징을 나타내는 Have

한국인 학습자들은 대개 상태를 설명할 때 '주어 + Be동사 + 형용사' 구조나 'There is ~' 구조에 갇히는 경향이 있습니다. 반면 원어민들은 특정 대상(사람, 사물, 장소)이 어떤 특징이나 분위기, 성질을 속성으로 품고 있다고 생각하여 "주어 + Have + 명사" 형태로 아주 단순하고 직관적으로 표현합니다.

① 사람의 성격이나 신체적 특징 표현

남자친구가 화를 잘 내는 다혈질이라고 할 때, 한국식으로는 "My boyfriend is easily angry"와 같이 부사나 형용사를 조합하려고 애를 씁니다. 하지만 원어민은 그 사람이 '짧은 성질'을 소유하고 있다고 바라봅니다.

영상 속 예시:
My boyfriend has a short temper.
제 남자친구는 화를 잘 내는 성격이에요.
[00:01:26]

② 사물의 성능이나 특징 표현

"내 핸드폰 배터리가 너무 빨리 닳아" 혹은 "배터리 수명이 짧아"를 영어로 옮길 때 "My phone's battery is short"라고 하기 쉽습니다. 원어민은 핸드폰이라는 주체가 '짧은 배터리 수명'이라는 속성을 가지고 있다고 표현합니다.

영상 속 예시:
My phone has a short battery life.
내 핸드폰은 배터리 수명이 짧아.
[00:02:06]

③ 장소의 분위기나 명성 표현

"홍대는 젊은 에너지가 넘쳐나"를 표현할 때 "Hongdae is full of youthful energy"도 훌륭한 문장이지만, 원어민은 장소 자체를 주어로 잡고 Have를 씁니다. 특정 지역의 분위기나 매력, 빵집의 맛을 묘사할 때도 마찬가지입니다.

영상 속 예시:
Hongdae has a youthful energy.
홍대는 젊은 에너지가 넘쳐나요.
[00:02:44]

That bakery has the best pastries.
그 빵집 페이스트리가 정말 최고야.
[00:03:33]

This cafe has a cozy vibe.
이 카페는 아늑한 분위기가 있어.
[00:04:01]

2. 추가 핵심 예문 학습

원어민들이 Have 동사를 활용해 대상의 속성을 어떻게 표현하는지 세 가지 카테고리로 나누어 추가 예문을 살펴보겠습니다. 영문을 먼저 확인한 후 뜻을 파악해 보세요.

카테고리 A: 사람의 성향 및 신체적 속성 (최소 3개)

She has a heart of gold, always helping people in need.
그녀는 부드럽고 친절한 마음씨를 가지고 있어서 항상 도움이 필요한 사람들을 돕는다.
My supervisor has a sharp eye for detail in every report.
내 상사는 모든 보고서의 세부 사항을 포착하는 예리한 눈을 가지고 있다.
He has a photographic memory and can recall every page he reads.
그는 사진을 찍은 듯 기억하는 명석한 기억력을 가지고 있어 읽은 모든 페이지를 기억해 낼 수 있다.

카테고리 B: 전자기기 및 사물의 기술적 속성 (최소 3개)

This new laptop model has a sleek design and a highly responsive screen.
이 새로운 노트북 모델은 매끄러운 디자인과 반응 속도가 매우 빠른 화면을 갖추고 있다.
The latest electric vehicles have a long driving range on a single charge.
최신 전기차들은 한 번의 충전으로 긴 주행 거리를 달릴 수 있는 성능을 가지고 있다.
This software program has a user-friendly interface for beginners.
이 소프트웨어 프로그램은 초보자들을 위한 사용하기 편한 인터페이스를 가지고 있다.

카테고리 C: 장소, 공간, 매장의 분위기 및 환경적 속성 (최소 3개)

The historic district has a charming atmosphere that attracts many tourists.
그 역사 지구는 많은 관광객을 끌어모으는 매력적인 분위기를 품고 있다.
This restaurant has a reputation for serving authentic Italian cuisine.
이 레스토랑은 정통 이탈리아 요리를 제공하는 것으로 유명한 명성을 가지고 있다.
The library has a quiet study environment perfect for preparation.
그 도서관은 시험 준비에 완벽한 조용한 학습 환경을 갖추고 있다.

3. 한 눈에 정리하는 핵심 요약

그동안 복잡한 형용사구와 Be동사 묶음에만 의존했다면 이제는 Have 동사를 중심에 두는 연습을 해야 합니다.

기존 한국식 사고: [사물/장소]는 ~한 상태이다 (Be동사 + 형용사 위주)
원어민식 사고: [사물/장소]는 [~한 특징/명사]를 내포하고 있다 (Have + 명사 구조)

이 규칙성을 깨닫고 나면 문장을 만드는 속도가 비약적으로 빨라지며, 미드나 영화를 볼 때 원어민의 표현들이 훨씬 선명하게 들리기 시작할 것입니다.

I feel과 It feels는 다릅니다: 한국인 90%가 놓치는 Feel 주어 활용법

Owl Life — Thu, 4 Jun 2026 14:55:38 +0900

우리가 기분이나 감각을 표현할 때 가장 자주 사용하는 동사 중 하나가 바로 Feel입니다. 하지만 많은 영어 학습자들은 Feel을 사용할 때 기계적으로 사람(I, You, We)만을 주어로 삼는 경향이 있습니다.

"추워요"라는 말을 할 때 내가 추운 것인지, 혹은 지금 내가 있는 공간 자체가 추운 것인지에 따라 주어가 완전히 달라져야 합니다. 주어를 사람이 아닌 가주어 It이나 특정 사물/공간으로 바꿨을 때 영어 표현이 얼마나 자연스럽고 원어민스럽게 변하는지 그 결정적인 뉘앙스 차이를 알아보겠습니다.

1. 핵심 개념 이해하기: It feels vs I feel

① It feels + 형용사: '공간이나 환경'의 객관적인 상태

주어가 사람이 아닌 가주어 It이나 공간(this room, this office)일 때는, 내가 느끼는 주관적 감정보다 내가 처한 환경이나 공간 자체가 객관적으로 그러한 상태라는 점을 강조합니다. 즉, "이 방 왜 이렇게 추워?" 혹은 "날씨가 꽤 쌀쌀하네"와 같은 맥락에서는 It feels를 사용해야 자연스럽습니다.

영상 속 예시: "밖이 꽤 춥게 느껴지네(날씨가 춥네)"
It feels pretty cold outside.
밖이 꽤 춥네.
- 밖의 날씨(The weather) 자체가 춥다는 객관적인 사실을 전달하는 표현입니다.

② I feel + 형용사: '개인'의 주관적인 감정 및 신체 상태

반면, 주어가 사람(I)일 때는 주변 환경과 상관없이 철저히 '나 개인이 느끼는 주관적인 신체 감각이나 감정 상태'에 초점이 맞춰집니다. 다른 사람들은 다 따뜻하다고 하는데 나 혼자 오한이 들거나 추울 때는 I feel cold가 정답입니다.

영상 속 예시: "다른 사람들이 다 따뜻하다고 말할 때조차 나는 추위를 느낀다"
I feel cold even when everyone else says it's warm.
다른 사람들이 다 따뜻하다고 할 때도 나는 추워.
- 주변 환경의 상태와 관계없이 화자 본인이 느끼는 주관적 감각을 강조하고 있습니다.

2. 일반적 사실(It feels to-v) vs 주관적 상황(I feel)

어떤 현상이나 사건이 주는 느낌을 전달할 때도 이 법칙은 그대로 적용됩니다. 누구나 그렇게 느낄 만한 보편적이고 일반적인 사실을 말할 때는 'It feels + 형용사 + to부정사' 구조를 쓰며, 내가 직접 겪은 구체적인 감정을 토로할 때는 'I feel + 형용사' 구조를 씁니다.

일반적 사실 표현 (It feels)
It feels awful to lose a job.
직장을 잃는다는 것은 끔찍한 일이다.
- 실직이라는 사건이 일반적으로 누구에게나 끔찍한 느낌을 준다는 보편적 사실을 전달합니다.
주관적 감정 표현 (I feel)
I feel awful because I lost my job.
나 직장을 잃어서 기분이 너무 끔찍해.
- 내가 최근에 실직을 당해서 현재 느끼는 개인적인 괴로움을 직접적으로 표현합니다.

3. 추가 핵심 예문 학습

원어민의 감각을 확실하게 체득할 수 있도록, 일상 대화에서 자주 쓰이는 추가 예문들을 두 가지 패턴으로 나누어 학습해 보겠습니다.

패턴 A: 공간, 환경, 일반적 사실을 나타내는 "It feels / 사물 주어"

It feels incredibly cozy in this small cafe.
이 작은 카페 안은 정말 아늑한 느낌이 든다.
This sofa feels too firm for me to sleep on comfortably.
이 소파는 내가 편안하게 잠을 자기에 너무 딱딱하게 느껴진다.
It feels amazing to finally accomplish a long-term goal.
장기적인 목표를 마침내 달성한다는 것은 정말 멋진 기분이다.
It feels awkward to talk about financial matters with close friends.
친한 친구들과 재정적인 문제에 대해 이야기하는 것은 어색하게 느껴진다.

패턴 B: 개인의 주관적 감각과 마음을 나타내는 "사람 주어 + Feel"

I feel completely exhausted after working on the project all night.
밤새도록 프로젝트 작업을 했더니 지금 완전히 진이 빠진 느낌이다.
We feel much safer living in this neighborhood with great security.
보안이 철저한 이 동네에 살아서 우리는 훨씬 더 안전하다고 느낀다.
He feels deeply frustrated because the client rejected his proposal.
고객이 그의 제안서를 거절했기 때문에 그는 깊은 좌절감을 느끼고 있다.
Do you feel comfortable with the new schedule we discussed earlier?
우리가 아까 논의했던 새로운 일정에 대해 편안하게 느끼시나요?

4. 한 눈에 정리하는 핵심 요약

It feels cold here: 이 방/사무실 자체가 객관적으로 춥다는 의미 (공간 중심 표현)
I feel cold: 주변이 어떻든 내 몸이 주관적으로 춥다고 느낀다는 의미 (사람 중심 표현)
It feels bad to-v: ~하는 것은 (누구에게나) 기분 나쁜 일이다 (보반적 사실)
I feel bad because~: ~ 때문에 (내가 지금) 기분이 나쁘다 (개인적 감정)

이제 무조건 "I feel"로 문장을 시작하기 전에, 내가 말하고자 하는 대상이 나의 주관적 감정인지 혹은 주변 환경이나 일반적 사실인지를 먼저 고민해 보세요. 주어 하나만 올바르게 선택해도 영어의 자연스러움이 확연히 달라집니다.

Eat, Have, Get 원어민은 3초 만에 구분하는 '먹다'의 진짜 차이점

Owl Life — Wed, 3 Jun 2026 14:54:30 +0900

우리가 영어로 대화할 때 가장 흔하게 사용하는 표현 중 하나가 바로 '먹다'입니다. 대부분의 학습자들은 'Eat'을 먼저 떠올리고, 조금 더 자연스러운 표현을 위해 'Have'까지는 섞어서 사용하곤 합니다. 하지만 원어민들은 일상 대화에서 'Get'이라는 동사도 식사와 관련해 정말 자주 사용합니다.

"먹다"라는 의미를 가진 세 가지 핵심 동사인 Eat, Have, Get은 각각 사용되는 상황과 내포하고 있는 뉘앙스가 완전히 다릅니다. 이번 학습 자료를 통해 원어민들이 3초 만에 이 동사들을 구분해서 사용하는 기준을 명확하게 정리해 보겠습니다.

1. Eat: 물리적인 먹는 행위와 대상 자체에 초점

동사 Eat은 입에 음식을 넣고 씹어 삼키는 구체적인 '물리적 행위'를 나타냅니다. 또한 무엇을 먹는지(대상), 얼마나 많이 먹는지(양), 얼마나 급하게 먹는지(속도)를 강조할 때 주로 사용됩니다. [00:03:28]

영상 속 핵심 뉘앙스 정리
- 특징 1: 목적어 없이 단독으로 사용이 가능합니다. [00:05:06]
- 특징 2: 고기만 먹는 아이에게 "채소도 좀 먹어라"라고 훈계하거나 특정 대상을 지정할 때 가장 적절합니다. [00:01:23]

[추가 예문 학습]

You should not eat too fast, or you will get an upset stomach.
음식을 너무 빨리 먹으면 배탈이 날 것이다.
I never eat seafood because I am severely allergic to shrimp.
나는 새우 알레르기가 심해서 해산물은 절대 먹지 않는다.
My cat usually eats twice a day, once in the morning and once at night.
우리 집 고양이는 보통 하루에 두 번, 아침과 밤에 사료를 먹는다.

2. Have: 일상적인 루틴, 습관, 그리고 즐거운 경험

동사 Have는 먹는 구체적인 동작보다는 평소에 가지는 식사 '루틴'이나 '습관'을 말할 때 주로 쓰입니다. Eat과 가장 큰 차이점은 음식뿐만 아니라 음료나 술을 마실 때도 모두 사용할 수 있다는 점입니다. [00:06:19]

영상 속 핵심 뉘앙스 정리
- 특징 1: 반드시 뒤에 목적어(음식이나 음료)가 함께 나와야 문장이 성립합니다. [00:05:06]
- 특징 2: 단순히 음식을 섭취하는 것을 넘어 "근사한 저녁 식사를 하며 즐거운 시간(경험)을 보냈다"고 할 때는 Eat을 쓸 수 없고 반드시 Have를 써야 합니다. [00:07:05]

[추가 예문 학습]

I always have a chicken sandwich and black coffee for breakfast.
나는 아침 식사로 항상 치킨 샌드위치와 블랙커피를 먹는다.
We had a wonderful dinner at a fancy Italian restaurant last night.
우리는 어젯밤에 근사한 이탈리아 레스토랑에서 즐거운 저녁 식사를 했다.
She prefers to have green tea instead of coffee after lunch.
그녀는 점심 식사 후에 커피 대신 녹차를 마시는 것을 선호한다.

3. Get: 식사를 매개로 한 소셜라이징(Socializing)

동사 Get이 식사와 함께 쓰일 때는 단순히 배를 채우는 행위를 넘어, 사람들과 어울려 식사나 술 한잔을 하며 '시간을 보내고 소셜라이징을 하자'는 의미가 강하게 내포되어 있습니다. 오랜만에 만난 친구에게 "우리 언제 밥 한번 먹자"라고 제안할 때 압도적으로 많이 쓰이는 동사입니다. [00:09:21]

영상 속 핵심 뉘앙스 정리
- 특징 1: 음식을 먹는 행위 자체는 수단일 뿐, 본질은 대화를 나누고 친목을 도모하는 것에 있습니다. [00:10:12]
- 특징 2: 식사(lunch/dinner)와 음료/술(drinks)을 묶어서 표현할 때 가장 유연하게 결합합니다. [00:02:43]

[추가 예문 학습]

Let's get dinner and drinks sometime next week to catch up on everything.
밀린 이야기를 나눌 겸 다음 주 중에 만나서 저녁 먹고 술도 한잔하자.
Why don't we get lunch together while you are visiting our office tomorrow?
내일 우리 사무실에 방문하시는 동안 같이 점심 식사 하시는 건 어떻습니까?
Should we get some tacos and beer after the movie finishes tonight?
오늘 밤 영화가 끝난 후에 타코에 맥주 한잔하러 갈까?

한 눈에 정리하는 상황별 핵심 요약

전화 통화 중 상대방이 우물거릴 때: "너 지금 뭐 먹고 있어?" ➔ 구체적 행위이므로 Eat (Are you eating something? [00:11:01])
매일 반복되는 일과를 말할 때: "나 주말마다 팬케이크 먹어." ➔ 루틴이므로 Have (I have pancakes every weekend. [00:10:44])
지인에게 만남을 제안할 때: "다음 주에 타코 먹으러 갈래?" ➔ 소셜라이징이므로 Get (Should we get tacos next week? [00:11:20])

원어민 90%는 Buy 대신 '이 동사'로 물건 구매를 표현합니다

Owl Life — Tue, 2 Jun 2026 14:53:32 +0900

우리가 일상에서 무언가를 새로 샀다고 자랑하거나 언급할 때 가장 먼저 떠올리는 동사는 단연 'Buy(과거형 Bought)'입니다. 하지만 실제 원어민들의 일상 대화를 유심히 들어보면, 돈을 지불하고 물건을 샀다는 맥락에서 'Bought'보다 'Got'을 압도적으로 많이 사용한다는 사실을 알 수 있습니다.

이번 학습 자료에서는 원어민들이 물건을 구매하거나 구했을 때 'Get' 동사를 어떻게 활용하는지, 그리고 전치사에 따라 달라지는 미묘한 뉘앙스의 차이까지 명확하게 짚어보겠습니다.

1. 핵심 개념 이해하기

① 일상적인 구매 표현은 'Bought'보다 'Got'이 대세

"나 지난주에 이 핸드폰 샀어"라는 문장을 영어로 옮길 때, 문법 책에서는 'Buy'를 배우지만 구어체 표현에서는 'Get'의 과거형인 'Got'이 훨씬 더 자연스럽게 쓰입니다. 스마트폰, TV, 냉장고, 컴퓨터 같은 고가의 제품들은 일상적으로 선물 받거나 거저 얻는 경우가 드물기 때문에, 앞뒤 맥락 없이 'Got'만 사용하더라도 원어민들은 90% 이상 '구매했다'는 의미로 이해합니다. [00:00:20]

영상 속 예시: "나 지난주에 이 핸드폰 샀어"
I got this phone last week.
나 지난주에 이 핸드폰 샀어. [00:00:13]

② 전치사에 따른 뉘앙스 변화: In vs From

물건을 구매하거나 구한 장소를 언급할 때 사용하는 전치사에 따라 뉘앙스가 완전히 달라집니다. 장소를 나타내는 전치사 'In'을 쓰면 일반적인 구매의 느낌이 강해지지만, 출처를 나타내는 전치사 'From'을 쓰면 일반적인 구매를 넘어 '어렵게 구했다(획득했다)'는 느낌을 풍기게 됩니다. [00:01:24]

영상 속 예시: "이 신발 이탈리아에서 구했어(샀어)"
I got these shoes from Italy.
이 신발 이탈리아에서 구했어.
- 출처를 강조하는 'From'을 사용함으로써, 단순 구매보다는 한정판이나 구하기 힘든 아이템을 이탈리아 현지에서 어렵게 손에 넣었다는 느낌을 암시합니다. [00:01:35]
- 반면, "I got these shoes in Italy"라고 했다면 이탈리아 여행 중에 일반적인 매장에서 자연스럽게 샀다는 의미에 더 가까워집니다. [00:01:45]

2. 상황별 추가 예문 학습

원어민의 감각을 온전히 내 것으로 만들기 위해, 일상에서 자주 쓰이는 추가 예문들을 학습해 보겠습니다.

상황 1: 일상적인 전자제품 및 가구류를 구매했을 때

I got a new laptop yesterday because my old one broke down completely.
어제 새 노트북을 샀는데, 기존에 쓰던 게 완전히 고장 났기 때문이야.
We got this dining table at a local furniture store nearby.
우리는 이 식탁을 근처에 있는 지역 가구점에서 샀어.
He got a smart TV during the Black Friday sale at a huge discount.
그는 블랙 프라이데이 세일 기간에 아주 큰 할인을 받아 스마트 TV를 샀어.

상황 2: 옷, 신발, 액세서리 등을 구매하거나 구했을 때

She got that beautiful vintage jacket from a small boutique in Paris.
그녀는 파리의 한 작은 부티크에서 저 아름다운 빈티지 재킷을 구했어.
Where did you get those sneakers? I have been looking for them everywhere.
그 운동화 어디서 샀어? 나 그거 찾으려고 온 동네를 다 뒤졌거든.
I got this silver necklace from a local designer during my trip to Bali.
발리 여행 중에 현지 디자이너에게서 이 은목걸이를 구했어.

상황 3: 한정판 아이템이나 티켓 등 구하기 어려운 것을 손에 넣었을 때

I finally got the concert tickets after waiting in an online queue for three hours.
온라인 대기열에서 세 시간을 기다린 끝에 마침내 콘서트 티켓을 구했어.
My brother got a limited-edition figure directly from Japan through an auction website.
내 동생은 경매 사이트를 통해 일본에서 직접 한정판 피규어를 구했어.
It was really hard to find, but I finally got the rare book from an old bookstore downtown.
정말 찾기 힘들었는데, 시내에 있는 오래된 서점에서 마침내 그 희귀한 책을 구했어.

3. 오늘 패턴의 요약

앞으로 일상적인 대화에서 "나 ~ 샀어", "나 ~ 구했어"라는 말을 표현하고 싶을 때는 너무 딱딱한 느낌을 주는 'Bought' 대신, 아래의 직관적이고 유연한 패턴을 사용해 보세요.

일반적인 구매: I got + [물건] + in + [장소] / [시간]
어렵게 구한 출처 강조: I got + [물건] + from + [출처/국가]

기본 동사인 'Get'의 활용 범위를 넓히는 것만으로도 여러분의 영어 스피킹이 훨씬 더 부드럽고 원어민스럽게 변화하는 것을 경험하실 수 있습니다.

"나이에 비해 동안이시네요"를 영어로 표현할 때 무조건 쓰이는 필수 패턴

Owl Life — Mon, 1 Jun 2026 14:52:15 +0900

우리가 영어 문장을 만들 때 가장 자주 부딪히는 한계 중 하나는 한국어 단어를 있는 그대로 영어 단어로 일대일 매칭하려고 하는 습관입니다.

"그 사람 정치인 치고는 배경이 참 독특해"라는 말을 하려고 할 때, 많은 학습자들은 '배경(Background)'을 문장의 주어로 잡거나 '~치고는'이라는 표현을 만들기 위해 복잡한 접속사를 떠올리곤 합니다.

이번 학습 자료에서는 원어민들이 일상에서 정말 자주 쓰는 '주체 중심의 주어 설정'과 고려의 대상을 나타내는 전치사 'For'의 원어민 뉘앙스를 명확하게 짚어보겠습니다.

1. 핵심 개념 이해하기

① 주체 중심의 주어 설정: 명사 주어 vs 사람 주어

"그 사람 배경이 재밌어"를 직역하면 "His background is interesting"이 됩니다. 이 문장도 문법적으로 존재할 수 있지만, 원어민들은 사람이 가진 속성이나 이력을 표현할 때 그 사람(주체)을 주어로 잡고 동사 'Have'를 사용하는 구조를 훨씬 선호합니다.

영상 속 예시: "그분 정치인 치고는 참 재미난 배경을 가지고 있어"
- He has an interesting background.
- 배경 자체를 주어로 삼기보다, 그 사람이 그러한 배경을 소유하고 있다는 주체 중심의 사고방식입니다. [00:01:13]

② 전치사 For: "치고는", "을 고려해 볼 때"

우리가 알고 있는 전치사 'For'에는 '~~를 위해'라는 뜻 외에도 **'~~라는 기준을 고려해 보았을 때(considering)'**라는 중요한 의미가 있습니다. 어떤 일반적인 기준이나 직업, 나이 등에 비해 의외의 사실을 언급할 때 반드시 쓰이는 전치사입니다.

영상 속 예시: "정치인 치고는"
- for a politician
- 정치인이라는 직업군이 대개 진중하거나 전형적인 이력을 가진다는 일반적인 기준을 고려해 볼 때라는 뉘앙스입니다. [00:01:57]

③ 앞 문장을 받는 맞장구 표현: "He does"

상대방이 "He has ~"로 시작하는 문장을 말했을 때 "맞아, 그래"라고 동의하며 맞장구를 친다면, "Yeah, that's right" 대신 일반동사 'Has'를 받는 대동사 구조를 사용하는 것이 좋습니다.

영상 속 예시: "맞아 (그 사람 그래)"
- He does.
- 원어민들이 대화의 리듬을 살릴 때 지식의 영역이 아닌 습관의 영역으로 자연스럽게 구사하는 축약형 표현입니다. [00:02:29]

2. 영상 속 전체 대화 문장 복습

He has an interesting background for a politician. He does. He used to be an actor and a pro wrestler.
그분 정치인 치고는 참 재미난 배경을 가지고 있어. 맞아. 한때 배우이자 프로레슬링 선수였지. [00:02:07]

3. 추가 핵심 예문 학습

패턴의 범용성을 넓히기 위해 일상과 비즈니스 상황에서 자주 쓰이는 추가 예문을 학습해 보겠습니다. 모든 예문은 전치사 'For'가 "~치고는 / ~을 고려하면"으로 사용된 구조입니다.

상황 1: 사람의 외모, 나이, 경력을 비교하여 말할 때

She looks very young for her age.
그녀는 나이에 비해서 무척 젊어 보인다.
He is quite mature for a nine-year-old boy.
그는 아홉 살짜리 아이치고는 꽤 성숙하다.
The new employee is doing an excellent job for a beginner.
그 신입 사원은 초보자 치고는 일을 아주 훌륭하게 해내고 있다.

상황 2: 날씨, 가격, 가치 등 조건에 따른 의외성을 표현할 때

It is quite warm for a January afternoon.
1월 오후 날씨치고는 꽤 따뜻하다.
This smartphone has a great camera for a budget phone.
이 스마트폰은 보급형 휴대전화 치고는 카메라 성능이 훌륭하다.
The restaurant was relatively quiet for a Friday night.
그 레스토랑은 금요일 밤 치고는 비교적 한산했다.

상황 3: 역량, 크기, 범위에 대한 기준을 나타낼 때

He speaks English fluently for someone who has never lived abroad.
그는 외국에 살다 온 적이 없는 사람치고는 영어를 유창하게 잘한다.
This apartment is spacious for a one-bedroom unit.
이 아파트는 방이 하나짜리인 집치고는 공간이 넓다.
The player has a short reach for a heavyweight boxer.
그 선수는 헤비급 복서치고는 리치가 짧은 편이다.

4. 한 눈에 정리하는 핵심 요약

기본 패턴: 주어 + Have + 특징/명사 + For + 기준명사
의미: [기준명사] 치고는 / [기준명사]을 고려해 볼 때 [주어]는 [특징]을 가지고 있다.
주의할 점: 한국어 구문 형태에 속아 특징명사(예: 나이, 배경, 외모)를 무조건 주어 자리로 보내지 말고, 사람을 주어로 설정하여 문장을 전개하는 훈련을 지속해야 합니다.

원어민이 밥 먹을 때 Eat 대신 Have를 더 자주 쓰는 진짜 이유

Owl Life — Sun, 31 May 2026 14:41:14 +0900

우리가 영어를 처음 배울 때 '먹다'라는 단어로 가장 먼저 접하는 동사는 단연 'Eat'입니다. 하지만 막상 원어민들의 대화를 듣다 보면 'Eat'보다 'Have'를 훨씬 더 자주 사용한다는 느낌을 받으셨을 겁니다.

"점심 먹자"라고 할 때 "Let's eat lunch"가 완전히 틀린 표현은 아니지만, 왜 원어민들은 "Let's have lunch"를 더 자연스럽게 느낄까요? 이번 학습 자료에서는 'Eat'과 'Have'의 명확한 뉘앙스 차이를 알아보고, 원어민처럼 자연스럽게 구사할 수 있도록 예문과 함께 살펴보겠습니다.

1. 핵심 개념 이해하기: Eat vs Have

① Eat: '먹는 행위(동작)' 자체에 초점

동사 'Eat'은 음식을 입에 넣고 씹어서 삼키는 직설적인 구체적 '행위'나 '동작'에 초점이 맞춰져 있습니다. 그렇기 때문에 상대방에게 특정 음식을 섭취하라고 직접적으로 훈계하거나 지시할 때 자연스럽게 사용됩니다.

영상 속 예시: 식사 자리에서 채소를 먹지 않는 아이에게 엄마가 "채소 좀 먹어라"라고 할 때
- Eat your vegetables.
  채소 좀 먹으렴.
- 이 상황에서 "Have your vegetables"라고 하면 직설적으로 훈계하는 뉘앙스가 살지 않고 자연스럽지 않습니다. [00:00:21]

② Have: '음식을 포함한 식사 내용'에 초점

반면 'Have'는 음식을 씹어 삼키는 동작보다는 '무엇을 먹었다'라는 식사의 전체적인 내용이나 상태, 혹은 하나의 의미 덩어리로서 정보를 전달할 때 사용됩니다. 먹는 동작 자체를 강조할 필요가 없는 대부분의 일상적인 식사 표현에서는 'Have'가 훨씬 더 자연스러운 선택(Better option)이 됩니다.

영상 속 예시: "나 오늘 점심으로 샐러드 먹었어"라고 할 때
- I had a salad for lunch today.
  나 오늘 점심으로 샐러드 먹었어.
- 샐러드를 입에 넣고 씹는 행위가 아니라, 점심 메뉴로 샐러드를 선택해 먹었다는 '내용'이 중요한 정보이기 때문에 'Had'가 자연스럽습니다. [00:00:42]

2. 상황별 원어민 뉘앙스 비교

"나 방금 간식 먹어서 배 안 고파"라는 말을 영어로 할 때도 마찬가지입니다. [00:01:03]

자연스러운 표현 (Have)
I just had a snack, so I'm not hungry.
나 방금 간식 먹어서 배 안 고파.
- 간식을 입에 넣고 씹어 먹는 동작이 중요한 것이 아니라, 간식을 먹은 상태이기 때문에 '배가 고프지 않다'는 결과를 말하고 싶으므로 'Had'가 우선합니다. [00:01:12]
동작을 강조하는 표현 (Eat)
I'm eating something.
나 지금 뭐 좀 먹고 있어.
- 친구와 전화 통화를 하거나 대화를 할 때 "나 지금 한창 입에 뭘 넣고 우물우물 먹는 중이라 말하기 힘들어"와 같이 구체적인 먹는 동작을 강조할 때는 'Eating'이 자연스럽습니다. [00:01:31]

3. 추가 핵심 예문 학습

원어민의 감각을 확실히 익히기 위해 일상에서 자주 쓰이는 추가 예문을 통해 복습해 보겠습니다.

Have를 사용하는 자연스러운 일상 식사 표현

Let's have a quick bite before the movie starts.
영화 시작하기 전에 간단하게 뭐 좀 먹자.
What did you have for breakfast this morning?
너 오늘 아침으로 뭐 먹었어?
I usually have dinner with my family around 7 PM.
나는 보통 오후 7시쯤에 가족들과 저녁을 먹는다.

Eat을 사용하는 구체적 행위 및 강조 표현

Don't talk with your mouth full when you eat.
음식을 먹을 때는 입에 음식을 가득 문 채로 말하지 마라.
You should eat more fiber for your health.
건강을 위해서 섬유질을 더 많이 섭취해야 합니다.
My dog refuses to eat his food today.
우리 집 강아지가 오늘 사료를 먹으려고 하지 않는다.

4. 한 눈에 정리하는 핵심 요약

Eat: 씹고 삼키는 '행위/동작' 그 자체 (예: 편식하는 아이에게 골고루 먹으라고 할 때, 음식을 삼키는 모습을 묘사할 때)
Have: 식사를 하거나 음식을 섭취했다는 '사실/내용' (예: 점심, 저녁 메뉴를 말할 때, 식사 약속을 잡을 때)

이제 "점심 먹자!"라고 말할 때는 "Let's eat lunch" 대신 훨씬 자연스러운 "Let's have lunch!"를 사용해 보세요.

Get, Take, Do... 기본 동사 5개로 영어 스피킹 끝내는 원어민식 훈련법

Owl Life — Sat, 30 May 2026 14:39:04 +0900

많은 영어 학습자들이 스피킹을 할 때 더 어렵고 아카데믹한 단어를 찾아 헤매곤 합니다. 하지만 원어민들의 실제 일상 대화를 살펴보면, 복잡한 단어 대신 누구나 알고 있는 쉬운 동사 5가지로 수백 가지의 상황을 완벽하게 표현합니다.

이러한 동사들을 '큰 동사(Core verbs)'라고 부릅니다. 유연하고 다방면으로 활용이 가능한 5대 핵심 동사(Get, Have, Make, Do, Take)의 숨겨진 뉘앙스와 실제 원어민들이 사용하는 방식을 정리해 드리겠습니다.

1. Get: 질병, 수술, 획득을 아우르는 만능 동사

어려운 학술적 동사인 undergo(겪다/받다)나 contract(질병에 걸리다) 대신 일상 회화에서는 Get 하나로 상황이 정리됩니다. 질병에 걸리거나, 수술을 받거나, 구하기 힘든 물건을 손에 넣는 상황 모두 Get의 영역입니다.

영상 속 예시 1: "너 당뇨 걸릴 수도 있어"라고 경고할 때 [00:02:18]
If you don't cut down on sugar, you are going to get diabetes.
당분을 줄이지 않으면 당뇨병에 걸릴 거야.
영상 속 예시 2: "우리 동네에 새 병원이 생긴대"라고 일정을 말할 때 [00:04:53]
My neighborhood is getting a new hospital next year.
우리 동네에 내년에 새 병원이 들어선대.
영상 속 예시 3: 무릎 인공 관절 수술을 받았다고 할 때 [00:03:32]
I got a knee implant.
나 무릎 인공 관절 수술을 받았어.

[추가 예문 학습]

I think I'm getting a cold because my throat feels sore.
목이 따끔거리는 걸 보니 감기에 걸리려는 것 같다.
We had to wait in line for an hour to get the concert tickets.
우리는 콘서트 티켓을 구하기 위해 한 시간 동안 줄을 서서 기다려야 했다.
Our company is getting a new office building downtown next month.
우리 회사는 다음 달에 시내에 새로운 사옥이 생긴다.

2. Have: 소유를 넘어 감정과 스케줄을 나타내는 동사

Have를 단순히 '가지다'로만 암기하면 스피킹에 한계가 옵니다. 원어민들은 생각의 차이, 미묘한 감정 상태, 겪었던 스케줄의 고단함을 Have 동사로 표현합니다.

영상 속 예시 1: "제 생각은 좀 다릅니다"라고 부드럽게 의견을 낼 때 [00:06:26]
I had a different idea.
저는 다른 생각을 가지고 있었습니다.
영상 속 예시 2: 퇴사나 졸업을 앞두고 "시원섭섭하다"라고 말할 때 [00:07:40]
I have mixed feelings.
시원섭섭한 기분이 드네요.
영상 속 예시 3: 조카가 거북이를 키운다고 할 때 (raise 대신 사용) [00:07:27]
My nephew has a turtle.
내 조카는 거북이를 키워.

[추가 예문 학습]

I had a rough week at work, so I just want to relax this weekend.
이번 주에 회사에서 힘든 한 주를 보내서 이번 주말에는 그냥 쉬고 싶다.
He couldn't attend the morning meeting because he had a long flight.
그는 장시간 비행을 해서 아침 회의에 참석할 수 없었다.
Do you have any pets that you are currently taking care of?
당신은 현재 돌보고 있는 반려동물이 있습니까?

3. Make: 약속 이행과 관계의 어울림을 표현하는 동사

Make는 단순히 무언가를 제조하는 것 외에, 특정 장소나 일정에 '참석하다/시간 맞춰 가다(make it)'의 의미와 어떤 결과나 자격을 '이루어 내다'의 의미를 가집니다.

영상 속 예시 1: 점심 약속에 갑자기 못 가게 되었을 때 [00:09:26]
I don't think I can make it to lunch.
오늘 점심 약속에는 못 갈 것 같습니다.
영상 속 예시 2: 우리 팀이 결승에 진출했다고 할 때 (advance 대신 사용) [00:10:09]
They made it to the final.
그들은 결승 진출에 성공했어.
영상 속 예시 3: 두 사람이 정말 잘 어울리는 커플이 될 거라고 할 때 [00:10:52]
Those two would make a great couple.
저 두 사람은 정말 잘 어울리는 커플이 될 거야.

[추가 예문 학습]

I am so glad that everyone could make it to my birthday party tonight.
오늘 밤 내 생일 파티에 모두가 올 수 있어서 정말 기쁘다.
After years of hard work, she finally made it to the executive position.
수년간의 노력 끝에 그녀는 마침내 임원 자리에 올랐다.
I believe that your extensive experience will make you a great leader.
당신의 풍부한 경험이 당신을 훌륭한 리더로 만들어 줄 것이라 믿는다.

4. Do: 일상적인 가사, 전공, 세금 처리를 위한 동사

Major in(전공하다), File taxes(세금 신고하다) 같은 딱딱하고 전문적인 단어들은 리딩에는 유용하지만 스피킹에서는 입을 멈추게 만듭니다. 일상적인 대화에서는 Do 동사가 가장 자연스럽습니다.

영상 속 예시 1: 대학 시절 전공을 가볍게 대화로 나눌 때 [00:11:49]
My brother did engineering and I did math.
내 동생은 공학을 전공했고 나는 수학을 전공했어.
영상 속 예시 2: 매년 하는 종합소득세 신고가 귀찮다고 할 때 [00:12:42]
I hate doing my taxes.
나는 세금 신고 처리하는 게 정말 싫어.
영상 속 예시 3: 아내가 아침마다 머리 손질을 오래 걸려 할 때 [00:13:26]
She spends an hour doing her hair in the morning.
아내는 아침에 머리 모양을 가다듬는 데 한 시간을 쓴다.

[추가 예문 학습]

I usually do the grocery shopping on Saturdays while my husband cleans the house.
남편이 집안 청소를 하는 동안 나는 보통 토요일에 장을 본다.
Can you wait for a moment? I just need to do my makeup before we leave.
잠시만 기다려 줄래? 우리 출발하기 전에 화장만 좀 고치면 돼.
He decided to do business administration because he wanted to start his own company.
그는 자신의 회사를 차리고 싶었기 때문에 경영학을 공부하기로 결정했다.

5. Take: 수용, 예약, 수수료 차감을 묘사하는 동사

Take는 내 영역 안으로 무언가를 '가져오고 수용하는' 그림을 가집니다. 예약 수락, 워크인 손님 응대, 플랫폼의 수수료 차감 등의 비즈니스 맥락에서도 유연하게 활용됩니다.

영상 속 예시 1: 예약 없이 오는 워크인 손님은 안 받는다고 할 때 [00:14:04]
We don't take walk-ins.
저희는 예약 없이 오시는 손님은 받지 않습니다.
영상 속 예시 2: 특정 테이블은 따로 예약을 받지 않는다고 설명할 때 [00:14:47]
We don't take reservations for those tables.
저쪽 테이블들은 예약을 받지 않습니다.
영상 속 예시 3: 앱이나 플랫폼에서 매출 수수료를 떼어갈 때 [00:15:35]
The app takes 20% of my sales.
그 앱은 내 매출의 20%를 수수료로 가져가.

[추가 예문 학습]

Does this cafe take credit cards, or do they only accept cash?
이 카페는 신용카드를 받습니까, 아니면 현금만 받습니까?
The online platform takes a huge cut of the profit from individual sellers.
그 온라인 플랫폼은 개인 판매자들로부터 막대한 이익 수수료를 차감한다.
I need to take a break because I have been staring at the computer screen all day.
하루 종일 컴퓨터 화면을 바라보고 있었기 때문에 지금은 휴식을 취해야 한다.

학습 요약: 기본 동사의 마스터가 스피킹의 완성

학습 효능감을 채워주는 어려운 단어 암기에만 치중하다 보면 실제 회화에서 문장이 뚝뚝 막히는 현상이 발생합니다. 일상의 스피킹을 유창하게 구사하고 싶다면 오늘 학습한 5가지 핵심 동사(Get, Have, Make, Do, Take)의 범용성을 온전히 이해하고 입으로 반복해서 훈련하는 과정이 우선되어야 합니다.

"I have to attend" 대신 원어민이 매일 쓰는 '일정 공유' 영어 표현

Owl Life — Fri, 29 May 2026 14:01:49 +0900

상대방이 특정 날짜나 시간에 시간이 되는지 물었을 때, 우리는 보통 선약이 있거나 해야 할 일이 있다는 핑계를 대며 거절하곤 합니다. 이때 한국인 학습자들이 가장 먼저 떠올리는 패턴은 "I need to verb" 혹은 "I have to verb" 형태입니다.

하지만 원어민들과 일정을 공유하거나 내 스케줄을 설명하는 상황에서는 "Have + 목적어 + to부정사" 형태를 압도적으로 많이 사용합니다. 이 패턴이 왜 더 자연스러운지, 그리고 어떻게 활용해야 하는지 명확하게 짚어보겠습니다.

1. 핵심 개념 이해하기: 일정을 공유할 때는 "Have + 목적어 + to부정사"

우리가 의무나 필요성을 나타낼 때 문법 책에서 배우는 "I need to do something"은 완전히 틀린 문장은 아닙니다. 하지만 상대방과 시간을 조율하거나 내 하루 스케줄, 처리해야 하는 일과를 공유하는 맥락에서는 뉘앙스 차이가 발생합니다.

"Have + 목적어 + to-v"는 내 스케줄 표 위에 '내가 소화해야 하는 특정 일정이나 책임, 의무'가 이미 존재하고 있다는 뉘앙스를 전달합니다. 따라서 상대방의 제안을 부드럽고 자연스럽게 거절하거나 내 상황을 설명할 때 원어민들이 가장 선호하는 방식입니다.

영상 속 상황 예시 1: 7월 21일에 만나자는 친구의 제안에 "그날 워크숍 참석해야 해"라고 답할 때
- I have a workshop to attend on July 21st.
  7월 21일에는 참석해야 할 워크숍 일정이 있어. [00:00:22]
- 이 상황에서 "I need to attend a workshop"이라고 해도 뜻은 통하지만, 원어민들은 일정을 설명하는 느낌을 주는 'have a workshop to attend'를 훨씬 더 자주 씁니다. [00:00:43]
영상 속 상황 예시 2: "오늘 오후에 뭐 해?"라는 질문에 "오후에 집안일 좀 해야 해"라고 답할 때
- I have some chores to do in the afternoon.
  오후에는 해야 할 집안일들이 좀 있어. [00:01:05]
- 내 오늘 오후 일정에 '집안일'이라는 항목이 들어가 있음을 자연스럽게 보여주는 표현입니다. [00:01:28]

2. 상황별 추가 예문 학습

원어민의 스케줄 공유 감각을 완전히 내 것으로 만들기 위해, 일상에서 정말 자주 쓰이는 예문들을 세 가지 상황으로 나누어 학습해보겠습니다.

① 소화해야 할 업무 및 미팅 일정이 있을 때

I have a lot of emails to reply to this morning.
오늘 아침에는 답장해야 할 이메일이 아주 많아.
She has a presentation to prepare for tomorrow's meeting.
그녀는 내일 회의를 위해 준비해야 할 발표가 있어.
We have several clients to meet in the afternoon.
우리는 오후에 만나야 할 고객들이 몇 명 있어.

② 개인적인 볼일이나 약속이 있을 때

I have a doctor's appointment to go to at 3 PM.
오후 3시에 가야 할 병원 진료 예약이 있어.
I have a package to pick up from the post office before it closes.
우체국이 문을 닫기 전에 찾아야 할 택배가 있어.
He has some errands to run on his way home.
그는 집으로 가는 길에 처리해야 할 볼일들이 좀 있어.

③ 공부, 과제 및 가사 노동 일정이 있을 때

I have an exam to study for this weekend, so I can't go out.
이번 주말에는 공부해야 할 시험이 있어서 나갈 수가 없어.
The kids have a lot of homework to finish before bedtime.
아이들은 자기 전에 끝내야 할 숙제가 많아.
I have some laundry to do before the weekend starts.
주말이 시작되기 전에 해야 할 빨래가 좀 있어.

3. 오늘 패턴의 요약

상대방에게 "나 ~해야 해"라고 나의 일정, 의무, 책임을 공유할 때는 기계적으로 "I need to"나 "I have to"만 사용하기보다, 아래의 패턴을 머릿속에 기억하고 입으로 연습해보세요.

I have + [내가 처리해야 할 일/일정] + to + [동사]

이 구조를 활용하면 영어식 사고에 한 걸음 더 가까워진, 훨씬 더 자연스럽고 매끄러운 원어민 표현을 구사할 수 있습니다.

헷갈리는 영어 동사 구별하기: Notice, Realize, Recognize 뉘앙스 차이 완벽 정리

Owl Life — Thu, 28 May 2026 12:58:33 +0900

많은 영어 학습자들이 영단어를 우리말 일대일 매칭 방식으로 외우곤 합니다. 대표적인 예가 바로 recognize를 단순히 '인식하다'로 외우는 것입니다. 하지만 실제 원어민의 뉘앙스를 이해하지 못하면 상황에 전혀 맞지 않는 어색한 영어를 구사하게 됩니다.

이번 글에서는 겉보기에는 비슷해 보이지만 실제로는 전혀 다른 성격을 가진 세 가지 동사 Notice, Realize, Recognize의 명확한 차이점과 올바른 사용법을 자세히 알아보겠습니다.

1. Notice : 오감을 통해 자연스럽게 알아차리다

Notice는 인간의 오감(시각, 청각, 후각, 미각, 촉각)을 통해 무언가를 인지하거나, 시간의 흐름 속에서 어떤 사실이나 변화를 자연스럽게 눈치챌 때 사용합니다. 의도적으로 관찰하려고 한 것이 아니더라도 직관적으로 알게 되는 상황에 쓰입니다.

영상 속 대표 예문

I noticed a dent in the car.
단어 뜻 그대로 자동차에 찌그러진 부분이 있는 것을 알아차렸다는 의미입니다.
I noticed the burning smell coming from the kitchen.
부엌에서 무언가 타는 냄새가 올라오는 것을 알아차렸습니다.
Did you notice that Jeff never brushes his teeth after lunch?
제프가 점심 먹고 양치를 전혀 안 한다는 걸 너는 눈치챘니?

추가 학습 예문

I noticed that she changed her hairstyle as soon as she walked into the room.
그녀가 방으로 걸어 들어오자마자 그녀의 헤어스타일이 바뀐 것을 알아차렸습니다.
Did you notice any difference in his voice when he called you?
그가 너에게 전화했을 때 그의 목소리에서 어떤 변화를 눈치챘니?
We didn't notice the time passing because we were having so much fun.
우리는 너무 즐겁게 노느라 시간이 가는 줄도 몰랐습니다.

2. Realize : 논리적 사고를 통해 깨닫다

Realize는 앞선 두 단어보다 한 단계 높은 차원의 인지 과정을 나타냅니다. 감각기관으로 느끼는 것이 아니라, 머릿속으로 논리적인 생각이나 사고 과정을 거쳐 '아, 그렇구나!' 하고 무언가를 깨닫거나 알게 되는 상황에 쓰입니다.

영상 속 대표 예문

After I smelled smoke from the kitchen, I realized I had left the oven on for 2 hours.
부엌에서 연기 냄새를 맡고 나서야, 내가 오븐을 2시간 동안 켜두었다는 사실을 깨달았습니다.
I realized that the tall man in the office was the president.
사무실에 있던 키 큰 남성분이 사장님이라는 사실을 알게 되었습니다.

추가 학습 예문

It took me a long time to realize how important my family is to me.
가족이 나에게 얼마나 중요한지 깨닫는 데 오랜 시간이 걸렸습니다.
I suddenly realized that I had left my wallet on the dining table.
나는 식탁 위에 지갑을 두고 왔다는 사실을 문득 깨달았습니다.
She didn't realize she was making a huge mistake until it was too late.
그녀는 너무 늦을 때까지 자신이 큰 실수를 저지르고 있다는 것을 알지 못했습니다.

3. Recognize : 이전의 경험과 기억을 바탕으로 알아보기

Recognize의 핵심은 '이전의 경험이나 기억'입니다. 이전에 이미 알고 있던 사람, 사물, 소리, 냄새 등을 다시 마주했을 때, 과거의 기억을 되살려 그것이 무엇인지 혹은 누구인지 '알아보는' 것을 의미합니다. 오랜만에 만난 친구에게 "너 나 알아보겠어?"라고 할 때 바로 이 동사를 사용합니다.

영상 속 대표 예문

Did you buy the Calvin Klein cologne? I recognize the smell.
너 캘빈클라인 향수 샀니? 내가 그 냄새를 알아보겠네.
A guy approached me at the bar, but I didn't recognize him at all.
술집에서 어떤 남자가 나에게 다가왔지만, 나는 그를 전혀 알아보지 못했습니다.

추가 학습 예문

Can you recognize this song? We used to listen to it all the time in high school.
이 노래 알아들을 수 있겠어? 우리 고등학교 때 맨날 듣던 노래잖아.
I couldn't recognize him at first because he had lost so much weight.
그가 살이 너무 많이 빠져서 처음에는 알아보지 못했습니다.
The system uses advanced technology to recognize human faces in the dark.
그 시스템은 어둠 속에서 사람의 얼굴을 인식하기 위해 첨단 기술을 사용합니다.

핵심 요약

Notice: 눈, 코, 귀 등 감각으로 자연스럽게 알아차릴 때
Realize: 머리를 써서 논리적으로 깨닫거나 알게 될 때
Recognize: 과거의 기억을 바탕으로 대상을 알아볼 때

단어의 한글 뜻만 외우기보다는 이러한 상황적 맥락과 뉘앙스를 기억하며 문장을 구성해 보는 연습을 해보시기 바랍니다.

특수문자, 기호 및 이모지 모음

Owl Life — Wed, 6 May 2026 17:18:12 +0900

문서 작성하다가 갑자기 →, ℃, ½, €, ✓ 같은 문자가 필요할 때,
검색창을 오가며 복사/붙여넣기 하느라 흐름이 끊긴 경험 있으시죠?

AllThatConverter의 special-characters 메뉴는 이런 불편을 줄이기 위해 만든 브라우저 기반 특수문자/심볼 도구입니다.

지금 사용해보기
https://allthatconverter.web.app/en/tools/symbols/special-characters

특수문자, 기호, 이모지 모음

왜 이 메뉴가 편할까요?

special-characters는 자주 쓰는 기호를 빠르게 찾고, 터치(클릭) 한 번으로 복사할 수 있게 설계되어 있습니다.

카테고리 정리: 구두점, 괄호, 수학기호, 단위, 도형, 숫자/분수, 화살표, 통화, 이모지까지
이모지 서브탭 제공: 필요한 분위기의 이모지를 더 빠르게 탐색
한 번 탭하면 즉시 복사: 반복 작업 속도 개선
셀 크기 조절(20~100px): 보기 편한 크기로 맞춤 사용
최근 사용 문자 로컬 저장: 자주 쓰는 기호 재사용이 쉬움

Special Characters & Symbols | AllThatConverter

Use AllThatConverter to special characters & symbols in your browser. Free, no signup.

allthatconverter.web.app

Free Json Formatter (Beautify)

Owl Life — Thu, 9 Apr 2026 00:43:49 +0900

개발하다 보면 API 응답, 설정 파일, 로그에 섞인 JSON을 한눈에 읽기 좋게 만들고 싶을 때가 많습니다.

AllThatConverter의 JSON 포맷터(Beautify)는 브라우저에서 바로 JSON을 정리하고, 필요하면 로그에 끼어든 JSON까지 전처리한 뒤 포맷할 수 있는 무료 도구입니다.

이럴 때 쓰면 좋아요

- API로 받은 한 줄짜리(minified) JSON를 들여쓰기해서 보고 싶을 때
- 에디터/메모에 붙여 넣은 JSON이 따옴표·쉼표만으로는 읽기 어려울 때
- 로그 한 줄마다 앞에 타임스탬프·[body] 같은 접두어가 붙어 있어, 진짜 JSON만 이어 붙여야 할 때
- 정리된 JSON을 트리 구조로 펼쳐 보고 싶을 때

핵심 기능

1. Beautify — JSON 정리
붙여 넣은 문자열을 파싱한 뒤, 일정한 들여쓰기로 다시 출력합니다. 서버로 파일을 올리지 않고 브라우저 안에서만 처리됩니다.

2. (선택) 전처리 — 로그·특수 포맷 대응
로그처럼 줄마다 앞부분이 다른 경우, 정규식 프리셋으로 앞쪽 노이즈를 제거한 다음 포맷할 수 있습니다. 자주 쓰는 패턴은 저장해 두고, 필요할 때만 켜면 됩니다.

3. 트리 뷰어
포맷이 성공하면 Tree viewer로 객체·배열 구조를 펼쳐 볼 수 있습니다.

4. 샘플 불러오기
동작을 확인하고 싶을 때 일반 JSON 샘플과 로그에 감싼 JSON 샘플을 불러올 수 있습니다.

바로가기

https://allthatconverter.web.app/tools/json/beautify-json

Beautify Json | AllThatConverter

Use AllThatConverter to beautify json in your browser. Free, no signup.

allthatconverter.web.app

Tree Viewer & Search

Coroutines & Flows - 다섯가지 안티 패턴

Owl Life — Sat, 14 Jun 2025 20:32:52 +0900

1. UI 업데이트를 메인 스레드에서 하면 안 되는 이유

여러분 앱의 화면(UI)은 마치 상점의 간판처럼 항상 손님(사용자)에게 최신 정보를 보여줘야 합니다.
그런데 이 간판을 업데이트하는 작업이 너무 복잡하고 오래 걸리면(CPU를 많이 사용하면), 간판이 잠시 멈춰버리겠죠?
- 이처럼 뷰 모델에서 UI 상태를 업데이트하는 복잡한 로직을 실행할 때, 기본적으로는 메인 스레드라는 중요한 길에서 작업하게 됩니다.
- 이 길이 막히면 앱 화면 전체가 멈추는 것처럼 느껴져서 사용자가 불편함을 느낍니다.
이 문제를 해결하려면 복잡한 UI 업데이트 작업은 Default Dispatcher라는 다른 작업자에게 맡겨야 합니다.
- 이렇게 하면 메인 스레드가 막히지 않고, UI는 계속 부드럽게 움직일 수 있습니다.

2. 화면 이동 시 데이터 저장이 날아가 버리는 문제

앱에서 화면을 이동할 때(예: 노트 작성 화면에서 목록 화면으로 돌아갈 때), 현재 화면과 연결된 View Model Scope에서 실행 중인 코루틴은 자동으로 취소됩니다.
만약 이 코루틴안에서 데이터를 저장하거나 서버와 동기화하는 중요한 작업을 하고 있었다면, 화면을 이동하는 순간 그 작업이 중간에 멈춰버릴 수 있습니다.
- 예를 들어, 작성 중인 노트를 저장 버튼을 눌러 저장하고 바로 이전 화면으로 돌아갔는데, View Model Scope가 취소되면서 서버에 저장되지 않는 문제가 발생할 수 있습니다.
이 문제를 막으려면 두 가지 방법이 있습니다.
- 첫째, 데이터 저장이 완료될 때까지 UI에게 기다리라고 알려주고, 저장이 끝난 후에 화면 이동을 시킵니다.
- 둘째, View Model Scope 대신 앱이 살아있는 동안 계속 유지되는 Application Scope를 사용해서 중요한 백그라운드 작업을 실행합니다.

3. 병렬로 할 수 있는 일을 순서대로 시키는 문제

안티 패턴	문제점	올바른 해결 방법	예시
병렬 작업 순차 실행	여러 코루틴 작업을 병렬로 실행하여 시간을 단축할 수 있음에도 불구하고, 순서대로 실행하게 만듦.	모든 코루틴 작업을 먼저 시작(launch)시킨 후, 마지막에 모든 코루틴이 완료될 때까지 한꺼번에 기다림(join).	프로필 사진 업로드와 프로필 정보 업데이트를 동시에 진행.
`launch` 사용 후 바로 `join` 호출	코루틴을 시작하고 바로 완료될 때까지 기다리므로, 다음 작업이 시작되기 전에 현재 작업이 끝나야 함.	모든 `launch` 호출을 먼저 완료한 후, 마지막에 모든 `join` 호출을 수행.	`launch { 작업1() }; launch { 작업2() }; 작업1.join(); 작업2.join()` (잘못된 방식) vs `launch { 작업1() }; launch { 작업2() }; joinAll()` (올바른 방식)
`async` 사용 후 바로 `await` 호출	비동기 작업을 시작하고 바로 결과를 기다리므로, 비동기 작업의 이점을 살리지 못하고 순차적으로 실행됨.	모든 `async` 호출을 먼저 완료한 후, 마지막에 모든 `await` 호출을 수행.	`val 결과1 = async { 작업1() }.await(); val 결과2 = async { 작업2() }.await()` (잘못된 방식) vs `val 작업1 = async { 작업1() }; val 작업2 = async { 작업2() }; val 결과1 = 작업1.await(); val 결과2 = 작업2.await()` (올바른 방식)

여러 코루틴작업을 동시에(병렬로) 실행하면 전체 작업 시간을 크게 줄일 수 있습니다. 예를 들어, 프로필 사진 업로드와 프로필 정보 업데이트는 서로 기다릴 필요 없이 동시에 진행될 수 있습니다.
하지만 launch를 사용해서 코루틴을 시작하자마자 바로 join을 호출하거나, async를 사용하고 바로 await를 호출하면, 마치 한 사람씩 줄 서서 일을 처리하는 것처럼 순서대로 실행되게 만들어 버립니다.
- launch는 코루틴을 시작하라는 명령이고, join은 그 코루틴이 끝날 때까지 기다리라는 명령입니다.
- launch 다음에 바로 join을 쓰면, 첫 번째 작업이 끝날 때까지 기다렸다가 두 번째 작업을 시작하게 됩니다.
올바르게 병렬 실행을 하려면, 모든 코루틴작업을 먼저 다 시작( launch)시켜 놓습니다.
- 그리고 마지막에 모든 코루틴이 완료될 때까지 한꺼번에 기다리도록( join) 하면 됩니다. 이렇게 해야 비로소 여러 작업이 동시에 착착 진행됩니다.

4. while true 반복문에서 취소 요청이 무시되는 문제

데이터를 주기적으로 가져오는 작업처럼 while true 무한 반복문 안에서 코루틴을 실행할 때 주의해야 할 점이 있습니다.
만약 이 반복문 안에 try-catch 블록을 사용하여 일반적인 예외를 잡도록 코드를 작성하면 문제가 생길 수 있습니다.
- 코루틴이 취소될 때 발생하는 취소 예외(Cancellation Exception)는 try-catch 블록에 의해 일반 예외처럼 잡혀버릴 수 있습니다.
- 이렇게 되면 코루틴은 사실상 취소된 상태인데, 반복문은 취소 사실을 인지하지 못하고 계속 돌게 됩니다. 마치 "취소됐는데 취소 안 된 척"하며 무한 루프에 빠지는 거죠.
이 문제를 해결하려면 try-catch 블록 안에서 예외를 잡은 후, coroutineContext.ensureActive()를 호출하여 현재 코루틴이 활성 상태인지 다시 확인해야 합니다.
- 이 함수는 만약 코루틴이 취소된 상태라면 취소 예외를 다시 발생시켜서 반복문이 제대로 종료되도록 돕습니다.

5. Supervisor Job을 잘못 사용하는 문제

안티 패턴	문제점	올바른 사용법	설명
Supervisor Job을 launch 함수에 직접 전달	자식 코루틴들이 Supervisor Job의 독립적인 실패 처리 혜택을 받지 못하고 부모의 실패에 영향을 받음	`supervisorScope` 블록 안에서 코루틴 실행	`supervisorScope` 안에서 시작된 코루틴은 서로 독립적으로 실패 처리됨

supervisor job은 특정 코루틴이 실패하더라도 다른 자식 코루틴들이 영향받지 않고 계속 실행될 수 있도록 해주는 특별한 Job입니다.
하지만 launch 함수에 Supervisor Job을 직접 인자로 전달하는 것은 올바른 사용법이 아닙니다.
- 코루틴의 Job은 자식 코루틴에게 상속되지 않는 유일한 컨텍스트 요소입니다.
- 그래서 launch에 Supervisor Job을 직접 넘겨주면, 코틀린 내부적으로 이상한 계층 구조가 만들어져서, 자식 코루틴들이 supervisor job의 혜택(실패 시 독립적인 실행)을 제대로 받지 못합니다. 즉, 따로 놀아야 할 자식들이 부모 때문에 같이 실패하게 되는 거죠.
supervisor job의 기능을 제대로 사용하려면 supervisorScope라는 특별한 함수 블록 안에서 코루틴을 실행해야 합니다.
- supervisorScope 안에서 launch로 시작된 코루틴들은 서로 독립적으로 실패할 수 있게 됩니다. 마치 각자 알아서 책임지고 실패하는 자식들처럼 말이죠.

출처 : https://youtu.be/JyBq76N4Zc4?si=OEGCPCf9D0_37NTY

GRASP

Owl Life — Wed, 21 Dec 2022 23:57:41 +0900

GRASP Pattern

General Responsibility Assignment Software Pattern

**OO 디자인의 핵심은 각 객체에 책임을 부여 하는것** **책임을 부여하는 원칙을 말하는 패턴**

Informatoin Expert (제일 중요)

책임을 수행할 수 있는 데이터를 가지고 있는 객체에 책임을 부여하는 것. 객체는 데이터와 처리로직이 함께 묶여 있는것. 정보 은닉을 통해 자신의 데이터를 감추고 오직 메서드로만 데이터를 처리하고, 외부에는 그 기능(책임)만을 제공.

Creator

객체의 생성은 생성되는 객체의 컨텍스트를 알고 있는 다른 객체가 있다면, 컨텍스트를 알고 있는 객체에 부여.

Controller

시스템 이벤트(사용자의 요청)을 맞이할 객체를 만들자. 처리 하는것이 아님.

<UseCaseName>Handler,
<UseCaseName>Coordinator,
<UseCaseName>Session

Low Coupling

객체들간, 서브 시스템들간의 상호의존도가 낮게 책임을 부여.

High Cohesion

각 객체가 밀접하게 연관된 책임들만 가지도록 구성.

Polymorphism

객체의 종류에 따라 행동양식이 바뀐다면, Polymorphism 기능을 사용하자. Object-Oriented 시스템은 상속과 Polymorphism(다형성)을 지원한다. 만약 객체의 종류에 따라 행동이 바뀐다면 객체의 종류를 체크하는 조건문을 사용하지 말고, Object-Oriented 시스템의 Polymorphism 기능을 사용하라.

Pure Fabrication

**Information Expert 패턴을 적용하면 Low Coupling과 High Cohesion의 원칙이 깨어진다면, 기능적인 역할을 별도로 한 곳으로 모으자.** 데이터베이스 정보를 저장하거나, 로그 정보를 기록하는 역할에 대해 생각해 보자. 각 정보는 각각의 객체들이 가지고 있을 것이다. 이 때 Information Expert 패턴을 적용하면, 각 객체들이 정보를 저장하고, 로그를 기록하는 역할을 담당해야 하지만, 실제로 그렇게 사용하는 사람들은 없다. 이것은 그 기능들이 시스템 전반적으로 사용되고 있기 때문에 각 객체에 그 기능을 부여하는 것은 각 객체들이 특정 데이터베이스에 종속을 가져오거나, 로그을 기록하는 매커니즘을 수정할 경우, 모든 객체를 수정해야 하는 결과를 가져온다. 즉 Low Coupling의 원칙이 깨어지게 된다. 이럴 경우에는 공통적인 기능을 제공하는 역할을 한 곳으로 모아서 가상의 객체, 서브시스템을 만들어라.

Indirection

두 객체 사이의 직접적인 Coupling을 피하고 싶으면, 그 사이에 다른 객체를 사용하라. 여기서 말하는 다른 객체란 인터페이스가 될 수 있고, 주로 인터페이스인 경우가 많다. 그런 특별한 경우는 아래에 설명된 Protected Variations 패턴이라고 부를 수 있다.

Protected Variations

변경될 여지가 있는 곳에 안정된 인터페이스를 정의해서 사용하자. JDBC에 대해서 생각해 보자. JDBC는 일련의 인터페이스들로 구성되어 있으며, 각 데이터베이스 벤더들이 인터페이스를 구현한 Concrete 클래스를 제공하고 있다. 데이터베이스 기능을 사용하는 시스템의 입장에선 각 벤더들이 구현방식을 바꾸었을 때, 자신의 코드를 수정하고 싶지 않을 것이다. 그래서 Driver를 로딩하는 코드를 제외하고는 모두 인터페이스를 사용함으로서 데이터베이스의 변경시에도 Driver 로딩만 바꾸어 주면 되도록 데이터베이스 관련 작업이 필요한 곳에는 안정된 JDBC 인터페이스를 사용한 것이다.

11. Re-engineering / Refactoring

Owl Life — Sun, 4 Dec 2022 17:56:37 +0900

Reverse Engineering 무엇인가요?

제품의 유지보수, 개선 또는 교체를 돕기 위해 제품에 대한 설계 수준의 충분한 이해 를 얻는 프로세스.
재문서화, 설계 복구

Reengineering 무엇인가요?

리엔지니어링은 일반적으로 일부 형태의 리버스 엔지니어링(보다 추상적인 설명을 달성하 기 위해)에 이어 일부 형태의 순방향 엔지니어링 또는 구조 조정을 포함합니다.

Reengineering 방식은?

리팩토링 대상을 선정한다
선정된 대상을 테스트 코드 작성한다.
코드를 분해한 후 재조립한다.
재조립 코드를 테스트한다.
위 과정을 반복한다.

Test Driven Refactoring 무엇인가요?

1 실패한 단위 테스트를 만듭니다.
2. 해당 테스트를 통과하는 프로덕션 코드를 작성합니다
3. 방금 만든 혼란을 정리하십시오.

Golden Master Test

프로세스를 수행한 다음 저장된 "골드 마스터"와 향후 실행을 비교하여 예기치 않은 변경 사항을 발견합니다.

리팩토링이란?

리팩토링 또는 전체 코드 리팩토링은 새로운 기능을 도입하거나 대상 소프트웨어의 기본 작업을 변경하지 않고 이전에 빌드된 소스 코드를 수정하는 체계적인 프로세스.

소프트웨어의 원래 기능을 방해하지 않고 기본 코드의 구조, 정의 및 구현을 최적화하기 위한 사소한 프로그래밍 조정이라고 생각할 수 있습니다. 최종 결과는 일반적으로 소프트웨어의 가독성, 유지 관리성 및 확장성에 대한 개선입니다.

리팩토링 중에 소프트웨어 개발 팀이 일반적으로 수행하는 몇 가지 조치는 다음과 같습니다.

코드 크기 줄이기
혼란스러운 코드를 더 간단한 코드로 재구성
코드를 정리하여 더 깔끔하게 만들기
중복되고 사용되지 않는 코드 및 주석 제거
불필요한 반복 없애기
유사한 코드 결합
재사용 가능한 코드 생성
긴 기능을 더 간단하고 관리하기 쉬운 비트로 나누기

리팩토링 이점

가독성 향상
유지 보수성, 확장성 증가
성능 개선
시간/돈 절약

리팩토링 몇가지 테크닉

Red-Green Refactoring
Extract Method
Simplifying Methods
Composing Method
Abstraction

Process

리팩토링이 필요한 부분을 찾아서 진행한다?

Instructions

Re-engineering for Different Paradigms

From C Programs to Object-Oriented Design

도메인 엔티티를 식별해내고 그것을 객체로 만듭니다
Procedure에 있던 책임을 GRASP 원칙을 지키면서 객체들에 옮겨줍니다
Procedure을 Usecase라고 본다면 Loose coupling, high cohesion으로 묶어서 객체화, Component화 합니다.
Abstraction, Encapsulation하여 객체를 만들어야합니다.

10. Architecture Evaluation

Owl Life — Sun, 4 Dec 2022 17:56:00 +0900

ATAM

Architecture Tradeoff Analysis Method

아키텍처가 품질 목표를 만족하는지 여부와 품질 목표간에 발생하는 충돌에 대해서도 분석함.

CBAM

Cost Benefit Analysis Method

ATAM에 경제적 평가를 보강함

요구사항과 투자에 관한 의사 결정을 지원함

투자 비용 대비 이득

9. Tactics for NFR

Owl Life — Sun, 4 Dec 2022 17:54:42 +0900

Architecture Design for Conventional NFRs

SRS에 공통으로 나타나는 NFR

결국, Quality Attribute 가 됨.

Tactics for common NFRs: Available

Architecture Design for Non-Conventional NFRs

타겟 시스템에 특정됨

Tactics to be devised by Architectures

Impact of Tactics on Views

NFR Design 과정

Identify Facts and Policies
Define Criteria for Tactics
Define Candidate Tactics
Evaluate Candidate Tactics
Benefit, Cost, Decision
Analyze Impacts of Tactics on Views
각 뷰에서 어떤 영향을 미치는지 표로 만듬
Apply Tactics on Views
각 뷰에 택틱을 적용
Validate Conformance
Traceability 검증

8. Architecture Viewpoints

Owl Life — Sun, 4 Dec 2022 17:54:13 +0900

View 란?

시스템을 이루는 SW요소들의 집합 과 SW요소들의 연관 관계를 추상적 으로 표현한 것

Module View 무엇인가요?

Module간의 상호 연결 관계

Runtime View = Component and Connector View(C&C View)

예를 들어 뭐가 있을까요?
split lower upper merge 등

파이프-필터 스타일(Pipe-and-Filter Style)
공유-데이터 스타일(Shared-Data Style)
게시-구독 스타일(Publish-Subscribe Style)
클라이언트-서버 스타일(Client-Server Style)
피어 투 피어 스타일(Peer-to-Peer Style)

Allocation View 무엇인가요?

Software Architecture와 환경을 매핑시키는 역할을 한다. 우선 Deployment Style와 Work Assignment Style을 살펴 보자. Deployment Style은 Software Element가 어떤 물리적 장치에 탑재되는지 보여 준다. 시스템 동작 시, Deployment 내용이 변경 될 수 있으므로 할당은 동적일 수 있다. Work Assignment Style은 Module View의 내용 중 구현 책임이 있는 개인이나 그룹에 할당하는 것이다. 즉, 구조와 작업하는 개발 그룹간의 관계를 보여 주는 모습이라고 할 수 있다.

4+1 View

Logical View
Process View
Development View
Physical View
+Use Cases/Scenarios

유스케이스 뷰

(Usecase View)
다른 뷰를 검증하는데 사용
사용자, 설계자, 개발자, 테스트 관점
유스케이스 다이어그램

논리 뷰
(Logical View)
시스템 기능 적인 요구사항이 어떻게 제공되는지
클래스나 컴포넌트의 종류와 관계를 설명하고 설계가 실제로 구현 되는지 설명
설계자 관점 (순서도나 UML 그리는 시점)
클래스/시퀀스 다이어그램

프로세스 뷰
(Process View)
시스템의 비기능적인 속성으로 자원의 효율적인 사용, 병행 실행, 비동기, 이벤트 처리 등을 표현한 뷰
성능, 확장성, 효율성 관련
시스템 통합자의 관점
시퀀스/협력 다이어그램

Development 뷰
개발 환경 안에서 정적인 소프트웨어 모듈의 구성을 보여주는 뷰
컴포넌트 구조와 의존성을 보여주고 컴포넌트에 관한 부가적인 정보 정의
실제 구현할 수 있는지 여부를 확인
직접 만드는 개발자의 관점
컴포넌트 다이어그램

Physical 뷰
컴포넌트가 물리적 환경에서 배치 연결 작업이 어떻게 실행 되는지를 매핑해서 보여주는 뷰
배치(배포) 다이어그램

Context View 무엇인가요?

시스템과 환경사이의 상호작용과 의존성 관계를 표현한다

DFD - Data Flow Diagram 무엇인가요?

특정 기능을 나타냅니다. 레벨 0 DFD에서는 전체 대상 시스템을 나타냅니다
공통 터미널 - .사용자, 외부 시스템, 하드웨어 장치
데이터 저장소
데이터 흐름 정의

DFD의 터미널에 유스케이스 액터가 안되는 경우가 있는지

DFD에서 터미널이란 입력 정보를 주는 주체, 인풋 아웃풋
usecase에서 엑터는 특정 기능을 인보크하는 주체 또는 인보크를 당하는 주체
= 터미널에 있었다고 해서 전부 액터로 쓸필요는 없다

Functional Viewpoints

시스템의 기능을 정의

Functional Characteristics를 관찰
Skeleton Architecture로부터 UseCase Diagram을 정제
Functional Components를 도출
- 유즈케이스를 Functional Components 단위로 할당
- Functional Components 테이블 도출.
Tier로 Functional Components를 할당하기 위하여 정제
Tier별로 Functional Components를 할당

각각의 Functional Components를 디테일하게 디자인
Criterion 1. Visibility of Functional Component
Whitebox Component or Blackbox Component

Criterion 2. Type of Interface (for Blackbox Components)
Façade-type or Mediator-type

facade-type

각각의 객체들을 숨긴 Representative API set
API에 50개의 기능이 있을 때, 다 사용 위해서는 50개의 request가 필요하다.
Component의 Method 수가 많다.
Workflow가 가변적이다.

mediator type

각각의 객체들을 숨긴 Representative API set + Workflow automation 제공
Workflow는 재사용 가능하며, 자동적이다. (공통)
API에 50개의 기능이 있을 때, 한 번의 요청으로 사용 가능
상대적으로 적은 Method 수

Criterion 3. Variability of Functional Component
Closed Component or Open Component

Criterion 4. Variation Points (for Open Component)
Variation point where the variability occurs.
Functional Component의 인터페이스 정의
provided interface, required interface 정의

Information Viewpoints

Architecture design for Information View is to make decisions about persistent datasets, properties and their management. This activity includes a number of tasks including identifying data components, allocating data components, defining their data contents, ownership, data distribution, replication, migration, data security, and data timeliness.

타겟 시스템의 Informational Characteristics 을 관찰
Skeleton Architecture로부터 Persistent Object Model 을 정제
Data Components 를 도출
클래스간의 상호 작용이 강한 경우, data component의 그룹으로 도출.
Tier로 Data Components를 할당하기 위하여 정제
Data Components 를 tier에 할당.
Design Data Components
Data Component의 내부 상세를 디자인한다. persistent attribute 정의.
Data Components의 인터페이스 정의
각각의 Data Component의 인터페이스를 정의. 대부분 CRUD가 됨.

Behavioral Viewpoints

아키텍처의 Behavioral View는 시스템의 런타임 동작에 초점을 맞춘 시스템의 동적 측면을 설명한다.

Behavioral Characteristics 관찰
Explicit Invocation, Event-driven, Parallel Processing, Closed-loop control flow, time based invocation, etc...
전체 시스템에 대한 Control Flow 를 정제
상세한 Control Flow를 정의

Deployment Viewpoints

아키텍처의 Deployment View는 물리적 계층의 소프트웨어 구성 요소 토폴로지와 이러한 구성 요소 간의 물리적 연결에 관한 것입니다.

Deployment Characteristics 관찰
Nodes 정의
Network Connectivity 정의
티어간의 http, https 등
배포할 Artifacts 정의
노드별로 Artifacts를 할당
Deployment Diagram 활용

7. Skeleton / Core Architecture

Owl Life — Sun, 4 Dec 2022 17:53:39 +0900

Architect란?

Architect : 한정된 자원 내에서 기능 및 품질 요구사항을 최대한 끌어올릴수 있도록 균형을 맞추는 사람, Concern을 잘 포착하고 이것을 설계에 반영함
통찰력, 추상화, 설득력 필요

Architecture Style Pattern 적용 효과

안정성, 의사소통, 생산성, 재사용, 접근성
디자인 패턴에서는 솔루션이 들어가야한다.
아키텍쳐스타일에선 유형이 들어가야한다.

Architecture 설득 방법.

ATAM, Trade off, Risk 등을 분석 설득, 판단의 근거를 Tracebility하게 남겨두어야 근거로 쓸 수 있다.
Architecture: Definition

Architecture Style & Pattern 차이?

Architecture Description의 세 가지는?

Skeleton Architecture - Architecture Styles
Design for NFRs - Architecture Tactics for NFRs
Design for Views - Architecture Viewpoints

Skeleton Architecture Design

A skeleton architecture is a description of the structural aspect of the target system without fully describing the key components and their properties. It can be effectively derived by applying architectural style(s). Each architectural style is a named collection of architectural decisions that are applicable in a given development context.

How to evaluate the Applicability of Architect Styles?

Situation, 장점, 단점

어떤 상황에서 쓰여질 수 있는지를 명시합니다. 그리고 각각에 대하여 장점과 단점을 나열합니다.

그 후에 적용하기에 적합한지를 판단합니다.

How to Derive(도출하는가?) Skeleton Architecture from Styles?

Instantiating each selected Style, Merging Styles

선택된 스타일들을 하나씩 그려가면서 합칩니다.

Defining Interfactions among Components in the Architecture

Q) Why we do define Interactions among components?

Interaction Path를 정의한다. Interaction Path는 casual dependency 나 persistent relationship 일 수 있다.

함수 호출하는 Path를 제공하거나 컴포넌트들간의 통신을 위한 메시지를 보냅니다.

Skeleton Architecture Design, Step 말하세요.

요구사항 정제 (incompleteness, ambiguity, etc)

정제된 SRS 산출물 생성

시스템 컨텍스트 분석

- 시스템 바운더리 컨텍스트

- 기능적 컨텍스트

- 정보 컨텍스트

- 행위 컨텍스트

스켈레톤 아키텍트 디자인

- 아키텍트 특징 관찰

- 아키텍트 스타일 후보 선정 및 각각의 장,단점 명시

- 아키텍트 스타일 통합

아키텍처 스타일 통합 순서

1. Tiers 관련된 스타일
- Tier-based Architecture Styles
- Client Server architecture style
- N-tier architecture style
- Peer-to-Peer architecture style
- Load-balancing Architecture Styles
- Broker architecture style
- Dispatcher architecture style
- Master Slave architecture style•
- Edge-based architecture style

2. 서비스 관련 스타일
- Microservice architecture style
- Service-Oriented Architecture (SOA) style

3 레이어드 스타일
- Layered architecture Style
- MVC architecture style

4. 행동 스타일
- Batch Sequential architecture style
- Pipe-n-Filter architecture style
- Event-Driven architecture style
- Publish-and-Subscriber architecture style

5. 가변성 있는 스타일
- Micro Kernel architecture style
- Microservice architecture style
- Blackboard architecture style
Component간의 Interactions

6. Software Architecture Styles

Owl Life — Sun, 4 Dec 2022 17:51:04 +0900

각 스타일별 주요 포인트

언제 사용하는가? 컴포넌트와 연결자는 어떻게 되는가? 장단점은?

Batch Sequential

타겟 시스템의 기능이 dataset를 조작하기 위하여 독립적인 구성 요소로 decompose 된다.

구성 요소는 일련의 데이터 변환을 순차적 및 배치 방식으로 수행합니다.

사용자는 모든 배치 처리가 완료 되기전까지 interact 할 수 없고, 끝날때까지 기다려야 합니다.

대용량 처리에 용이. 각 서브 시스템을 독립적으로 처리하는 프로그램이 될 수 있음.

Pipe and Filter

필터는 데이터 세트를 조작하는 구성 요소를 나타내고,

파이프는 데이터 세트를 필터 간에 스트림 모드로 전송하는 데이터 버스를 나타낸다.

이는 Batch Sequential Architecture Style로 한 번에 전체 데이터 세트를 전송하는 것과 대조된다.

Benefits

Concurrency: It provides high overall throughput for excessive data processing.
Reusability: Encapsulation of filters makes it easy to plug and play, and to substitute.
Modifiability: It feature low coupling between filters, less impact, from adding new filters and modifying the implementation of any existing filters as long as the I/O interfaces are unchanged.
Simplicity: It offers clear division between any two filters connected by a pipe.
Flexibility: It supports both sequential and parallel execution.

Drawbacks

It is not suitable for dynamic interactions.
A low common denominator is required for data transmission in the ASCIII formats since filters may need to handle data streams in different formats, such as record type or XML type rather than character type.
Overhead of data transformation among filters such as parsing is repeated in two consecutive filters.
It can be difficult to configure a pipe and filter system dynamically.

Layered

‘관심사에 분리(Separation of concerns)’에 따라 시스템을 유사한 책임(관심)을 지닌 Layer로 분해하고

각각의 Layer가 하위 Layer에만 의존하도록 구성하는 아키텍처 패턴 (Organized Vertically)

각 레이어는 인터페이스를 가진 가상 머신. 가상 머신은 엄격한 순서 관계에 따라 상호작용.

각 계층에는 시스템에서 고유한 역할이 부여되며, 바로 아래 계층에서 제공하는 서비스를 호출한다.

하위 레이어는 상위 레이어 사용 불가.

가상 머신

레이어의 목적은 가상 머신의 제공
이식성(portability) 향상이 목적.

장점

전체적인 시스템의 결합도를 낮추고,

개발자의 인지 과부하를 방지하며,

재사용성을 높이고 유지보수성을 향상.

프로젝트 도메인이 복잡하 논리를 포함하지 않거나,

확장성보다는 일관성을 가져가는 것이 목표이거나,

소규모로 구성된 팀인 경우에는 적용하기 좋다고 생각.

단점

프로젝트 규모가 커질수록, 확장성이 떨어짐.

레이어로 분리된 관심사 외에 다른 관심사가 발견된 경우, 패키지 분리 및 코드 배치가 난감한 경우가 발생.

복잡한 비즈니스 논리를 해결하고 성능적 이점을 얻기는 어려움.

MVC

GUI가 있는 시스템을 모델, 뷰, 컨트롤러의 세개의 컴포넌트로 구분하는 아키텍처.

유저 인터페이스와 비즈니스 로직들을 서로 분리하여 개발하는 방법

MVC 모델 작동 순서

Controller로 사용자의 입력이 들어옴
Controller로 Model에 데이터를 업데이트
Model은 해당 데이터로 보여줄 View를 업데이트하여 화면에 보여 주게 됨

장점

Separation of Concern 달성 (재사용성, 유지 보수성)
동일한 모델로부터 다양한 View들을 표현할 수 있음
View의 추가, 변경, 삭제가 자유로움. model과 decouple 되어 있으므로.
View들의 동기화
모델의 변경전파 메커니즘에 의하여 데이터 변경사항 통지.
뷰와 모델에 영향을 끼치지 않고 워크플로우를 수정하는게 수월함.
Persistent 데이터 스토어가 view, control에 영향을 미치지 않음.

단점

간단한 애플리케이션에 적용하기에는 복잡성만 증가.
View와 Controller는 밀접히 관련되어 있음.
View와 Controller는 모델에 의존.
모델의 인터페이스를 변경하면 View와 Controller도 변경 되어야 함.

Blackboard

Shared data, database와 같은 데이터 중심 패턴 중에 하나
명확히 정의된 문제 해법이 없을 때 문제를 풀어가는 하나의 방식을 정의한 패턴
대략적으로 해법을 수립하기 위해 특수한 서비스 시스템의 지식을 조합하는 패턴

그 다음 단계의 결과가 실행할때마다 다르게 나올 수 있는 알고리즘을 구현하는데 사용되는 스타일

ex) 음성인식, 차량식별, 신호해석

블랙보드(blackboard) : 솔루션의 객체를 포함하는 구조화된 전역 메모리
지식 소스(knowledge source): 자체 표현을 가진 특수 모듈
제어 컴포넌트 (control component) : 모듈 선택, 설정 및 실행을 담당
KS는 타 문제 도메인에 재사용될 수 있음
계산 결과가 항상 동일하지 않아 테스트가 어려움
어떤 좋은 해법도 완벽하다고 장담할 수 없음

Shared Repository

공유 데이터는 central data repo에 저장됨. 이 repo는 여기에 관련된 모든 client app에 의해서 접근이 가능.

Client app들은 데이터를 읽고 쓰기 위하여 pulling을 사용

장점

Efficient way of sharing datasets among applications
Efficient way of storing a large amount of datasets
Separating data storage concern from data manupulation concern
Allowing concurrent accesses to the datasets.

단점

Difficulty to manage the data scheme of the repository
Potential performance overhead due to the remote access
Concern on Availability
Concern on Security

Micro Kernel

시스템의 요구사항이 변할때, 이를 쉽게 시스템에 반영하기 위한 패턴

일반적인 시스템의 기능에서 최소 핵심 기능은 공통으로 두고 변경이 가능한 확장 부분을 플러그인 방식으로 추가할 수 있는 패턴.

장점

이식성이 보장 (시스템을 새로운 환경으로 이동 시, Microkernel만 수정하면 됨)
유연성과 교환가능성이 확보 (Internal/External Server를 수정하거나 확장)
유지보수성과 가변성을 향상 (정책과 메커니즘을 분리)
확장성 확보, 신뢰성 지원, 투명성을 제공

단점

시스템 설계가 복잡하고 개발이 어려움.
성능이 떨어짐. internal server와 external server에 대한 호출로 인하여, 하나의 애플리케이션에서 훨씬 많은 프로세스 간 통신이 필요함.

Micro Service

대형 소프트웨어 프로젝트의 기능들을 작고 독립적이며 느슨하게 결합된 모듈로 분해하여 서비스를 제공하는 아키텍처

도메인은 공통 REST 기반 웹 인터페이스 서비스를 독립적으로 배포할 수 있습니다

장점

확장성, 탄력성, 진화성
복잡한 애플리케이션의 지속적 배포, 배치가 가능
상대적으로 작아서 이해하기 쉽고 생산적일 수 있음
오류의 고립(Fault Isolation)을 도움
ex) 메모리 릭이 있다면, 해당 서비스만 진행을 멈추고 다른 서비스는 지속 운영 가능.
새로운 기술을 도입, 적용하기가 용이

단점

성능, 단순성, 비용
개발자는 분산 시스템에서 나오는 추가적인 문제들을 다루어야 함.
여러 서비스를 배치 하는것이 좀 더 복잡해 짐.
메모리 사용량이 증가. (예를 들어 각 서비스가 각자 VM을 사용하는 경우)

Dispatcher

Client에게 QoS가 높은 서버를 연결하기 위하여 중간에 속해 있는 서버.

QoS가 높은 서버 정보를 클라이언트에 넘겨주면, Client가 직접 서버에 연결됨.

Broker보다 성능이 좋음.

Broker

서로 다른 기종의 머신에 분산되어 있는 서비스(객체 혹은 컴포넌트)간에 어떻게 협력을 잘 할지 고민하다 나온 패턴.

분산 시스템이나 RPC를 구현할 때 많이 사용됨.

브로커가 해야 할일은 server locating, request를 포워딩, 결과와 예외처리를 클라이언트 측에 전달하는 것.

언제 사용?

실제 시스템 컴포넌트를 사용하는 사용자로부터, 서비스의 구체적인 구현을 감추어야 할때(캡슐화)
런타임에, 시스템 컴포넌트들을 교체 할 수 있습니다.
시스템 컴포넌트가 어디에 위치해있던지 신경쓰지 않고 호출 가능합니다.

명령어 예

0x5001|semtax|22

0x5001은 어떠한 방법으로 요청을 처리하라는 일종의 커맨드이고, 나머지 부분이 데이터의 역할을 하게 됨.
Broker에서는 이 명령어를 파싱하여 서버에 요청 및 응답을 받아서 다시 리턴.

Client Server

서버 티어는 클라이어트 티어를 위한 공통 서비스를 제공. 클라이언트 티어는 사용자와 소통.

복수개의 클라이언트 앱은 서버 티어의 기능을 공유 할 수 있음.

장점

responsbility 분리, 서버 components 재사용

단점

이기종 인프라에 대해 요구 만족 어려움, 보안취약,
server availability and reliability, testability and scalability 어려움

Publish and Subscribe

이벤트 기반의 아키텍트 스타일.

Subscriber들은 특정 이벤트를 받기 위하여 등록/해제

Publisher들은 매시지를 브로드캐스팅. (동기/비동기 형태로)

옵저버 패턴과 유사.

언제 사용?

There is a need for decoupling content producers from content consumers.

There is a need to deliver the same content to multiple consumers.

There is a need to deliver the content when it is available.

There is a need to avoid polling for the content.

장점

Flexibility to add new subscribers dynamically.
Loose coupling between publisher and subscribers
Increased Efficiency due to Reduced Polling / Pulling

단점

Overhead of Distributing Events
With broker, publishers have no control on the delivery ordering

5. Requirement Engineering

Owl Life — Sun, 4 Dec 2022 17:50:12 +0900

Definition of SW Quality

주어진 요구사항을 만족시킬 수 있는 소프트웨어의 기능 및 특성.

Conventional NFRs in ISO 9126

Types of Quality Aspects

Process Quality

Quality of Life-cycle Process

Internal Quality

Quality of Intermediate Artifacts

External Quality

Quality of Implementation Code

Quality in Use

소프트웨어가 동작하는 환경에서의 사용자 관점에서의 퀄리티
ex) 실행 속도 등

소프트웨어 실행하면서 발생되는 결과로부터 평가

Quality Model of ISO 9126

6 Main Factors(FRUMPE) and Sub-Factors for each

Quality Model은 크게 External, Internal Quality로 나뉠 수 있음.

Functionality

기능 적합성. 소프트웨어가 사용자의 요구기능을 충족 시키는가? 목적했던 기능이 정확히 동작하는가?

Reliability

기능이 오차나 오류 없이 동작하는가? 일관된 결과가 도출되는가?

Maturity (성숙성)
소프트웨어의 결함으로 인한 실패를 방지하는 소프트웨어 제품의 기능.
Fault Tolerance (결함 허용성)
소프트웨어 결함 또는 지정된 인터페이스 침해의 경우에 특정 수준의 성능을 유지하는 소프트웨어 제품의 기능.
Recoverability (복구성)
소프트웨어 제품이 지정된 수준의 성능을 재설정하고 장애 발생 시 직접 영향을 받는 데이터를 복구하는 기능
Reliability Compliance (신뢰성 준수)
신뢰성과 관련된 표준, 규약 또는 규정을 준수하는 소프트웨어 제품의 능력

Usability

쉽게 배우고 사용할 수 있는가?

Efficiency

기능을 수행하는데 적절한 자원이 소요되는가? 기능이 필요한만큼 빠르게 수해오디는가?

Maintainability

변경 및 오류 교정 시 쉽게 수정할 수 있는가?

Portability

다양한 플랫폼 및 하드웨어에서도 동작하는가?

Process of Requirement Engineering (REP)

요구사항을 정의, 문서화 및 유지 관리하는 프로세스. 시스템에서 제공하는 서비스를 모으고 정의하는 과정.

주요 과정

요구사항 추출
요구사항 모델링과 분석
요구사항 우선순위화
요구 명세
품질 요구
요구 검증과 변경 관리

요구사항 추출

프로젝트 도메인 및 요구 사항에 대한 지식을 얻는 데 사용되는 다양한 방법과 관련이 있음.

사용되는 기술에는 인터뷰, 브레인스토밍, 작업 분석, 프로토타이핑 등이 포함되어 있음.

이 단계는 이해된 요구사항의 공식 모델을 생성하지 않음. 대신 분석가의 도메인 지식을 넓히고 다음 단계에 입력을 제공하는데 도움이 됨.

요구사항 모델링과 분석

공식적인 소프트웨어 요구 사항 모델을 생성하는데 사용. 추상적 요구사항을 정확하고 상세하게 정의.

시스템 기능, 성능 및 인터페이스 등을 정의. 고객의 needs가 충족됨을 확인

이 단계에서 사용되는 모델로는 Enterprise Modeling, Data Modeling(DFD), Behavioural Modeling, Domain Modeling, NFR Modeling 등이 있다.

요구사항 우선순위화

고객의 Needs와 요구사항 사이의 match가 성공을 결정.

단계

Define Priority classes
High / Medium / Low // 1~10 score
Assess Priority Data
모든 참여자가 Priority Scale에 따라 분류
Resolve Differences
우선순위에 대한 Informal Agreement 확보
Create schedules based on priorities
각 요구사항의 작업 시작과 종료 시점

요구 명세

요구문서는 완전하고, 일관성이 있어야 한다.

명세는 모든 필요로 하는 요소를 포함하고 있어야 한다.

명세에 포함된 요소들 간에는 모순이나 충돌이 없어야 한다.

품질 요구

품질 속성은 기능, 비기능 관점을 모두 포함.

"Quality Model of ISO 9126" 참고

품질 속성 시나리오 활용. (Source, Stimulus, Artifacts, Environment, Response, Response Measure)

요구검증과 변경관리

변경을 이해하고, 관리하라.

요구사항 관리를 위한 커뮤니케이션을 제공.

요구사항 변경으로 개발에 대한 영향을 최소화.

Agile하게 고객의 Needs 변화를 요구사항 변경으로 반영

Agile Constructs for Requirement Management

요구사항 변경은 필연적임.

→ 개발 초기에 고객은 원하는 요구사항을 정확히 표현하지 못함.

그러므로 변경을 이해하고, 관리하라.

Agile하게 고객의 Needs 변화를 요구사항 변경으로 반영

Requirements for Platform Software

Q) How do you define / refine requirements for Platform Software?

비기능이기 때문에 Non Functional Requirements에 명세합니다.

Non-Functional Requirements (NFRs)

소프트웨어 기능들에 대한 조건(시스템의 속성)과 제약사항에 관한 요구사항

기능적 요구사항보다 더 결정적인 부분이 될 수 있다.
why? 이부분이 충족되지 않으면 시스템 이용가치 X

각각의 특징과 서비스보다는 전체적인 시스템에 적용

비기능적 요구사항
제품 요구사항 (Product Requirement)	사용성(Usability) : 사용자가 어떻게 쉽게 사용할 수 있는가
	효율성(Efficiency)	성능(Performance) : 특정 기능이 특정시간 내에 실행
		공간 (Space) : 특정 기능 수행시 메모리를 최대 얼마까지 사용할 수 있는가
	신뢰성(Reliableility) : 특정 기능 실행시 실패할 가능성이 몇 %보다 낮아야 하는가
	이식성 (Portability) : 다양한 플랫폼 위에서 작동하는가
조직 요구사항 (Organizational Requirement)	배포(Delivery) : 소프트 웨어를 어떻게 배포할 것인가
	구현(Implement) : 소프트웨어 구현 ; 어떤 방법론? 어떤 프로그래밍 언어?
	표준(Standard) : 소프트웨어 개발 시 어떤 표준을 따를 것인가
외부 요구사항 (External Requirement)	상호 운용성 (Interoperability) 구현할 소프트웨어가 다른 소프트웨어와 어떻게 연동할지 정의
	윤리적 (Ethical) : 소프트 웨어의 내용의 윤리적 범위을 정의 ex) 성인용 게임 19세 이상
	법적 (Legislative)	사생활(privacy) ex) 공개범위 선택
		안전성(safety) ex) 자료 저장방식, DBMS 어떤것? 자료의 암호화 여부

GOF - Software Design Pattern

Owl Life — Sun, 4 Dec 2022 13:24:36 +0900

왜 디자인 패턴을 사용하나?

재사용 가능하고, 유연한 구조를 가지는 소프트웨어 개발
커뮤니케이션 : 구체적인 설명 없이 구조화된 패턴에 대한 사전 지식으로 커뮤니케이션에 드는 비용, 비용 절약.
설계 과정의 속도를 높일 수 있음. 이미 검증되고 테스트된 구조이기 때문.
구현이 아닌 인터페이스에 맞춰서 프로그래밍
바뀌는 부분은 따로 뽑아서 캡슐화.
상속 보다는 구성을 활용. → 구성을 활용하면 유연성을 크게 향상 시킴.

Principles of Design Patterns

Interface Separated from implementation
Substitution with various implementation
Open Closed Principle (OCP)

Classification of Design Patterns

Creation Patterns

객체 생성에 관련된 패턴. 객체의 생성과 조합을 캡슐화해 특정 객체가 생성되거나 변경되어도 프로그램 구조에 영향을 크게 받지 않도록 유연성을 제공한다.

Structure Patterns

클래스나 객체를 조합해 더 큰 구조를 만드는 패턴

예를 들어 서로 다른 인터페이스를 지닌 2개의 객체를 묶어 단일 인터페이스를 제공하거나 객체들을 서로 묶어 새로운 기능을 제공하는 패턴이다.

Behavioral Patterns

객체나 클래스 사이의 알고리즘이나 책임 분배에 관련된 패턴 한 객체가 혼자 수행할 수 없는 작업을 여러 개의 객체로 어떻게 분배하는지, 또 그렇게 하면서도 객체 사이의 결합도를 최소화하는 것에 중점을 둔다.

생성 패턴

Factory Method : 객체를 생성하기 위해 인터페이스를 정의하지만, 어떤 클래스의 인스턴스를 생성할지에 대해서는 하위

클래스에서 결정 -> 클래스의 상속 이용, 인터페이스의 다형성

Abstract Factory : 구체적 클래스를 정의하지 않고도 서로 관련성이 있거나 독립적인 여러 객체의 군을 생성하기 위한 인터

페이스 제공

Builder : 데이터의 순서에 상관없이 객체 생성 가능. setter 메서드가 없으므로 변경 불가능한 객체 생성 가능. 한번에 객체

를 생성하므로 객체 일관성이 깨지지 않음.

Prototype : 객체를 생성하는데 비용이 들고, 이미 유사한 객체가 존재하는 경우에 사용. Client에 Map 형태로 생성될 객체

를 등록해놓고, 타입에 따라 객체를 clone 하는 형태로 객체 생성. ex) DB로부터 읽어온 객체 등록 후 복사.

Singleton : 클래스에서 만들 수 있는 인스턴스가 오직 하나일 경우. 어디에서 접근 하든지 하나로만 통일하여 제공.

구조 패턴

Adapter : 클래스의 인터페이스를 클라이언트가 기대하는 형태의 인터페이스로 변환. 기존의 클래스를 사용해야 하나 인터페이스가 수정되어야 하는 경우에 사용. adapter 클래스의 멤버로 타겟 클래스를 가짐. (has a) Adaptee 클래스의 하위 클래스기 때문에 곧바로 Adaptee의 멤버 함수들을 override 할 수 있다.

Bridge : 구현부에서 추상층을 분리하여 각자 독립적으로 변형이 가능하고 확장이 가능하도록 합니다. 즉 기능과 구현에 대

해서 두 개를 별도의 클래스로 구현을 합니다. 런타임 시 구현 방법을 선택하거나 구현 내용을 변경하고 싶은 경우 사용.

Composite : 부분과 전체의 계층을 표현하기 위해 복합 객체를 트리 구조로 만드는 패턴. 복합 객체와 단일 객체의 처리 방법이 다르지 않을 경우, 전체-부분 관계로 정의. Directory-File 존재. SRP를 깨는 대신 투명성을 확보하는 패턴. 투명성(transparency)란 Component 인터페이스에 자식들을 관리하는 기능과 leaf으로써의 기능을 전부 넣어서 클라이언트가 복합 객체와 잎을 똑같은 방식으로 처리할 수 있도록 만들 수 있다.

Decorator : 객체에 동적으로 새로운 서비스를 추가 할 수 있게 한다. 기능의 추가를 위해서 하위 클래스를 생성하는것보다 융통성 있는 방법을 제공. (상속보다 위임을 통하여 제공)

Flyweight : 어떤 클래스의 인스턴스 한개만 가지고 여러 개의 "가상 인스턴스"를 제공하고 싶을때 사용하는 패턴. 즉 인스

턴스를 가능한 대로 공유시켜 쓸데없는 new 연산자를 통한 메모리 낭비를 줄이는 방식. 대규모의 미세한 객체들을 효과적

으로 사용하기 위해서 공유 개념 도입.

Facade : 복잡한 서브시스템에 대한 단순한 인터페이스 제공이 필요할때. 클라이언트와 구현 클래스 간에 너무 많은 종속

성이 존재하여 클라이언트와 다른 서브 시스템 간의 결합도를 낮추고 싶을 때.

Proxy : 프록시에게 일을 대신 시킴. 어떤 객체 사용할때, 직접 참조하는것이 아닌 해당 객체를 대항하는 객체를 통해 대상

객체에 접근하는 방식을 사용하면 해당 객체가 메모리에 존재하지 않아도 기본적인 정보를 참조하거나 설정할 수 있고, 실

제 객체의 기능이 필요한 시점까지 객체의 생성을 미룰 수 있음. 사이즈가 큰 객체가 로딩되기전에 프록시를 통해 참조 가

능. 객체 생서이 한단계 거치게 되므로 빈번한 객체 생성시에 성능 저하.

행위 패턴

Template Method : 알고리즘의 변하지 않는 부분을 한 번 정의하고 다양해질 수 있는 부분을 하위 클래스에서 정의할 수 있

도록 구현하고자 할 때. 훅을 사용하여 하위 클래스 확장을 제어 가능. 코드 재사용을 위한 기본 기술.

Strategy : 다양한 알고리즘이 존재하면 이들 각각을 하나의 클래스로 캡슐화하여 알고리즘의 대체가 가능하도록 함. 행위

들이 조금씩 다를 뿐 개념적으로 관련된 많은 클래스들이 존재하는 경우.

State : 객체 내부의 상태에 따라 행위를 변경하도록 함.상태에 따른 행위를 국지화하여 서로 다른 상태에 대한 행위를 별도

의 객체로 관리함. 상태 전이 규칙을 명확하게 만듬. 상태 객체는 공유 될 수 있음.

Command : 요청 자체를 객체화 하는것. 서로 다른 요청을 객체화하여 클라이언트에게 파라미터로 넘겨 줄 수 있게 한다.

Chain of Responsibility : 메시지를 보내는 객체와 이를 받아 처리하는 객체들 간의 결합도를 없애기 위한 패턴. 메시지를

수신하여 처리를 담당하는 객체들을 하나의 연결 고리로 만들고 실제로 요청을 처리하는 객체를 만날 때까지 계속 요청을

전달. 메시지를 받을 객체를 명시하지 않은 채 여러 객체 중 하나에게 처리를 요청하고 싶을때 사용.

Memento : 캡슐화를 위배하지 않으면서 객체의 내부 상태를 파악하고 표현함으로써 객체의 상태를 저장해 둔 상태로 다시

복귀할 수 있게 함. 각 시점에서의 객체 상태를 저장한 후 나중에 이 상태로 복구해야 할 때 활용.

Observer : 일대다의 관련성을 갖는 객체들의 경우 한 객체의 상태가 변하면 다른 모든 객체에 그 사항을 알리고 필요한 수

정이 자동으로 이루어지도록 할 때. 프로그래머는 얼마나 많은 객체들이 변경되어야 하는지 몰라도 됨.

Iterator : 복합 객체 요소들의 내부 표현 방식을 공개하지 않고도 순차적으로 접근할 수 있는 방법을 제공. (구현과 순회 분

리)

Visitor : 데이터 구조와 처리를 분리. 데이터 구조 안을 돌아다니는 주체인 방문자를 나타내는 클래스를 준비해서 처리를

맡긴다. 새로운 처리를 추가하고 싶을 땐 새로운 방문자를 만들고 데이터 구조는 방문자를 받아들이면 됨. OCP적용. 새로

운 concreteelement 클래스 추가하기는 어려움.

Mediator :클래스 간의 복잡한 관계를 캡슐화하여 하나의 클래스에서 관리하도록 처리하는 패턴. M:N 관계를 M:1 관계로

만들어 복잡도를 내리므로 유지 보수 및 확장성에 유리.

Interpretor : 간단한 언어의 문법을 정의하고 싶을 때

Facade 패턴과 Mediator 패턴

Mediator의 역할은 Colleague 역할의 중재자로서 주고받기를 수행함 -> 양방향
Facade 역할은 일방적으로 다른 역할을 이용해서 높은 레벨의 인터페이스(API)를 만듦 -> 단방향
퍼사드가 자신의 정책을 가시적이고 강제적으로 적용하는 반면, 미디에이터는 자신의 정책을 은밀하고 강제적이지 않은 방식으로 적용한다.
퍼사드 패턴은 클래스 라이브러리와 같은 어떤 소프트웨어의 다른 커다란 코드 부분에 대한 Unified Interface를 제공하며, 퍼사드는 그러한 인터페이스를 제공하는 객체다.
미디에이터 패턴은 객체들의 집합이 상호작용하는 방법을 함축해놓은 객체를 정의한다. 객체 간 통신은 미디에이터 객체 안에 함축된다. 객체들은 서로 직접 통신하지 않으며, 미디에이터를 통해 통신한다. 이를 통해 객체 간 의존성을 줄여 결합도를 감소시킬 수 있다.

Observer 패턴과 Mediator 패턴

옵저버 패턴은 1개의 publisher에 대해 N개의 subscriber가 존재. 옵저버는 pulling이나 push 방식을 통해 관리.
중재자 패턴은 M개의 publisher와 N개의 subscriber 사이에서 1개의 중재자를 통해 통신하는 방식.

Prototype 패턴과 Flyweight 패턴

Prototype은 복제를 하는 것이고 Flyweight는 있는것 그대로 쓴다.

Strategy Pattern

알고리즘을 정의하고 각각을 캡슐화하여 교환해서 사용할 수 있도록 만든다. Strategy를 활용하면 알고리즘을 사용하는 클라이언트와 독립적으로 알고리즘을 변경할 수 있다.

특징

관련 알고리즘의 군을 형성함
서브클래싱을 사용하지 않른 방법.
사용자는 서로 다른 전략을 알고 있어야 함
Strategy와 Context 클래스 사이에 과다한 메시지가 전송됨
객체 수가 증가

Observer Pattern

한 객체의 상태가 바뀌면 그 객체에 의존하는 다른 객체들에게 연락이 가고 자동으로 내용이 갱신되는 방식으로 일대다(one to many) 의존성을 정의.

일반적으로, Subject 인터페이스와 Observer 인터페이스가 들어있는 클래스 디자인을 바탕으로 구현.

Subject와 Observer가 Loose coupling 되어 있는 개체 디자인을 제공

데이터 가져오는 방식

pulling : 루프를 돌면서 계속 호출

pushing : 등록하면, 변경되었을때 통지

observe : 항상 필요X, 선택적으로 필요, notification만 전달받고, data는 전달받지 않음.

특징

Subject가 Observer에 대하여 아는것은 Observer가 특정 인터페이스를 구현한다는 것뿐.
Observer는 언제든지 새로 추가 가능.
새로운 형식의 Observer를 추가하려고 할 때도 Subject를 전혀 변경 할 필요가 없음.
Subject, Observer 는 서로 독립적으로 재사용 가능. 서로 영향을 미치지 않음.

서로 상호작용을 하는 객체 사이에서는 가능하면 느슨하게 결합하는 디자인을 사용해야 한다.

Decorator Pattern

객체에 추가적인 요건을 동적으로 첨가한다. 데코레이터는 서브클래스를 만드는 것을 통해서 기능을 유연하게 확장 할 수 있는 방법을 제공.

예) 카페에서 음료 제조시, 첨가물을 데코로 표현.

Open Closed Principle

"클래스는 확장에 대해서는 열려 있어야 하지만 코드 변경에 대해서는 닫혀 있어야 한다."

Class Diagram

특징

기존 코드는 건드리지 않은 채로 확장을 통해서 새로운 행동을 간단하게 추가할 수 있음
이 목표를 달성했을 때 새로운 기능을 추가하는데 있어서 매우 유연해서 새로 급변하는 주변 환경에 잘 적응할 수 있으면서도 강하고 튼튼한 디자인을 만들 수 있음.
데코레이터의 슈퍼 클래스는 자신이 장식하고 있는 객체의 슈퍼클래스와 같음.
한 객체를 여러 개의 데코레이터로 감쌀 수 있음.
데코레이터는 자신이 감싸고 있는 객체와 같은 슈퍼클래스를 가지고 있기 때문에 원래 객체가 들어갈 자리에 데코레이터 객체를 집어넣어도 상관없음.
데코레이터는 자신이 장식하고 있는 객체에게 어떤 행동을 위임(Delegate)하는 것 외에 원하는 추가적인 작업을 수행할 수 있음. – 키 포인트
객체는 언제든지 감쌀 수 있기 때문에 실행 중에 필요한 데코레이터를 마음대로 적용할 수 있음.

데코레이터를 사용하는 목적은 컴파잉리할 때 모든 서비스의 객체를 다 결정할 수 없는 상황에서 적절하게 대응하기 위해서임.

Factory method pattern

모든 팩토리 패턴에서는 객체 생성을 캡슐화.

팩토리 메소드 패턴에서는 서브클래스에서 어떤 클래스를 만들지를 결정함으로써 객체 생성을 캡슐화.

예제 ) 피자 가게에서 피자 생성

Dependency Inversion Principle

추상화된 것(Abstract or Interface)에 의존하도록 만들어라. Concrete Class에 의존하지 않도록 한다.

Class Diagram

특징

어떤 변수에도 구상 클래스에 대한 레퍼런스를 저장하지 말 것.
클라이언트에서 New 연산자를 사용하면 구상 클래스에 대한 레퍼런스를 사용하게 되는 것.
이 패턴을 사용하여 구상 클래스에 대한 레퍼런스를 변수에 저장하는 일을 미리 방지.
"New" 연산자를 캡슐화

Abstract Factory Method Pattern

추상 팩토리 패턴에서는 인터페이스를 이용하여 서로 연관된, 또는 의존하는 객체를 구상 클래스를 지정하지 않고도 생성 가능.

Class Diagram

Factory Method vs Abstract Factory Method

공통 : 둘다 객체 생성 패턴. 객체 생성을 캡슐화해서 Client와의 결합을 느슨하게 하고, 특정 구현에 덜 의존하도록 만듬.
차이점 : Factory Method는 상속을 통해서 객체를 생성. Abstract Factory Method는 객체 구성(Composition)을 통해 생성.
팩토리 메서드 패턴을 통해 객체 생성시에는 클래스를 확장하고 팩토리 메서드를 오버라이딩 해야 함.
팩토리 메서드 패턴을 사용한다는것은 서브 클래스를 통해서 객체를 만들기 위한 것. 클라이언트에서는 자신이 사용할 추상 형식만 알면 되고, 구상 형식은 서브클래스에서 처리해 줌. 즉, 클라이언트와 구상 형식을 분리해주는 역할

Singleton Pattern

해당 클래스의 인스턴스가 하나만 만들어지고, 어디서든지 그 인스턴스에 접근할 수 있도록 하기 위한 패턴.

Double Checked Locking 에서 volatile 키워드 관련 알고 있을것.

특징

한 앱에 들어 있는 어떤 객체에서도 똑같은 자원을 활용할 수 있도록 함.
예) 쓰레드 풀, 연결 풀 등 자원 풀을 관리하는게 유용함.
단순 싱글턴 패턴 적용시 멀티 쓰레딩에 따른 문제가 발생할 수 있음. synchronized, volatile 등 사용 할 것

Command Pattern

어떤 작업을 요청한 쪽과 그 작업을 처리하는 쪽을 분리 시킬 수 있음. 커맨드 객체는 특정 객체에 대한 요청을 캡슐화 시켜줌.

Class Diagram

특징

오퍼레이션을 호출하는 객체와 오퍼레이션을 수행 방법을 구현하는 객체를 분리.
요구사항을 캡슐화.
Command 자체도 클래스로서 다른 객체와 같은 방식으로 조작되고 확장될 수 있음.
명령어를 조합해서 다른 명령어를 만들 수 있음. (Composite 패턴 활용)
새로운 명령어를 쉽게 추가 할 수 있음.

Adapter Pattern

한 클래스의 인터페이스를 클라이언트에서 사용하고자 하는 다른 인터페이스로 변환합니다. 어댑터를 이용하면 인터페이스 호환성 문제 때문에 같이 쓸 수 없는 클래스들을 연결해서 쓸 수 있습니다.

클라이언트 : 타겟 인터페이스에 맞게 구현되어 있음.

어댑터 : 타겟 인터페이스를 구현하며, 여기에는 어댑티 클래스가 들어 있음.

클라이언트에서 어댑터 사용하는 방법

클라이언트에서 타겟 인터페이스를 사용하여 메소드를 호출함으로써 어댑터에 요청
어댑터에서는 어댑티 인터페이스를 사용하여 그 요청을 어댑티에 대한 (하나 이상의) 메소드 호출로 변환
클라이언트에서는 호출 결과를 받긴 하지만 중간에 어댑터가 껴 있는지는 전혀 알지 못함.

Class Diagram

Client는 Target 인터페이스를 구현한 Adaptee가 필요하다.
Adaptee는 Target인터페이스를 구현하지 않고 있다.
- Adaptee는 이미 개발이 완료되어 사용중이다.
- Adaptee를 변경하는 것이 적절하지 않은 상황이다.

특징

어댑티를 새로 바뀐 인터페이스로 감쌀 때는 composition을 사용합니다. 이런 접근법을 쓰면 어댑티의 어떤 서브 클래스에 대해서도 어댑터를 쓸 수 있다는 장점이 있음.

Façade Pattern

어떤 서브 시스템의 일련의 인터페이스에 대한 통합된 인터페이스를 제공. 퍼사드에서 고수준 인터페이스를 정의하기 때문에 서브 시스템을 더 쉽게 사용 가능.

Class Diagram

Principle of Least Knowledge

정말 친한 친구와 얘기하라.

특징

서브시스템의 구성 요소를 보호 할 수 있다.
서브시스템과 클라이언트 코드 간의 결합도를 줄일 수 있다.
서브시스템 클래스를 사용하는 것을 완전히 막지는 않는다.

Template Method Pattern

알고리즘의 각 단계들을 정의하며, 그 중 한 개 이상의 단계가 서브클래스에 의해 제공되는 경우에 사용.

AbstractClass에서 알고리즘의 골격을 정하고, 서브클래스에서 특정 메서드를 구현.

Hook

알고리즘의 특정 부분이 선택적으로 적용된다는가 하는 경우에 사용.

Class Diagram

Hollywood Principle

먼저 연락하지 마세요. 저희가 연락 드리겠습니다.

이를 활용하면, 의존성 부패를 방지 할 수 있음.

Iterator Pattern

Collection 구현 방법을 노출시키지 않으면서도 그 집합체 안에 들어있는 모든 항목에 접근할 수 있는 방법을 제공.

모든 항목에 일일이 접근하는 작업을 컬렉션 객체가 아닌 반복자 객체에서 맡게 된다. 이렇게 하면 집합체의 인터페이스 및 구현이 간단해질뿐 아니라, 집합체에서는 반복작업에서 손을 떼고 원래 자신이 할 일에만 전념할 수 있음.

Class Diagram

Single Responsibility Principle

클래스를 변경하는 목적은 단 하나여야 한다.

Composite Pattern

객체들을 트리 구조로 구성하여 부분과 전체를 나타내는 계층구조로 만들 수 있음.

Class Diagram

특징

클라이언트에서 단일 객체와 복합 객체를 똑같은 방법으로 다룰 수 있음.
메뉴와 메뉴 항목을 같은 구조에 집어 넣어서 부분-전체 계증구조를 생성 할 수 있음. 컴포지트를 따르는 디자인을 사용하면 간단한 코드만 가지고도 똑 같은 작업을 전체 메뉴 구조에 대해서 반복해서 적용할 수 있음.
단일 책임 원칙을 깨면서 대신에 투명성을 확보
가장 큰 장점 : Client를 단순화시킬 수 있음

State Pattern

OCP, 위임, DIP
객체의 내부상태에 따라 스스로 행동을 변경할 수 있게끔 허가하는 패턴.
상태가 변할 때마다 서브클래스 중 하나의 인스턴스로 변경함.

장점으로는 한 State와 관계된 모든 동작들이 하나의 Object 안에 모두 모인다.
State 추가 시 다른 Object에 대한 수정 없이 하나의 Object만 추가되면 된다.
따라서 State에 따른 조건문 없이 관리가 가능하다.
단점으로는 State 수만큼 Object가 관리되어야 함으로 Object가 늘어나고,
State 안에 동작이 추가될 경우 모든 Object들에 대해서 추가되어야 해서 수정범위가 늘어나게 된다.

Proxy Pattern

어떤 다른 객체로 접근하는 것을 통제하기 위해서 그 객체의 대리자(Surrogate) 또는 Placeholder를 제공하는 패턴.

Proxy pattern의 활용되는 방식

Real subject가 필요한 경우에 생성될 수 있도록 컨트롤 하거나 생성되기 전까지 대리인 역할을 한다. Real subject가 생성되면 Client로부터의 요청사항을 Real subject로 전달한다.
Client와 Real subject가 서로 다른 주소체계에 있거나 Real subject가 생성하는데 오래걸리거나 비싸거나, Real subject에 접근하는 권한의 관리가 필요할 경우 활용된다.

- remote proxy : responsible for encoding a request and its arguments and for sending the encoded request to the real subject in a different address space –
- virtual proxy : may cache additional information about the real subject so that they can postpone accessing it –
- protection proxy : checks that the caller has the access permissions required to perform a request

원격 프록시 : 요청과 해당 인수를 인코딩하고 인코딩된 요청을 다른 주소 공간의 실제 주체에게 보내는 역할을 합니다.
- 가상 프록시 : 실제 주제에 대한 추가 정보를 캐시에 저장하여 액세스를 연기할 수 있습니다.
- 보호 프록시 : 호출자가 요청을 수행하는 데 필요한 액세스 권한이 있는지 확인합니다.

Visitor Pattern

객체 구조를 이루는 원소에 대해 수행할 연산을 표현하는 패턴.
연산을 적용할 원소의 클래스를 변경하지 않고도(구조 변경 없이) 새로운 연산을 정의(새로운 기능 추가)할 수 있게 합니다. 다양한 객체에 새로운 기능을 추가해야 하는데 캡슐화가 별로 중요하지 않은 경우에 사용.
데이터 구조와 처리를 분리하자.
– 데이터 구조를 돌아다니는 “방문자”를 정의해서, 이 방문자가 “처리”를 담당하도록 하자.
– 새로운 처리를 추가하고 싶을 때는, 새로운 “방문자”를 만든다.

Mediator Pattern

중재자가 복잡하게 얽혀있는 객체들 간의 상호 통신을 중재시키고, 객체들 간의 상호 작용 로직을 Mediator에 집중시킴으로써 처리를 원할하게 한다.

중재자 패턴은
복잡한 M개의 객체 사이에 N개의 관계가 형성되어 있을 때
M개의 객체 사이에 중재자를 하나 넣어서
이를 M:1 관계로 바꿔준다.

주요 컴포넌트

Mediator

Colleague 역할들과의 통신을 조정하기 위한 인터페이스를 정하는 역할

ConcreteMediator

Mediator 구체 클래스.

Colleague

Mediator 역할과 통신을 할 인터페이스를 정함

ConcreteColleague

Colleague 구체 클래스.
ex) ColleagueButton, ColleagueTextField

Builder Pattern

Composition
복잡한 객체의 생성 과정과 표현 방법을 분리하여 동일한 생성 절차에서 서로 다른 표현 결과를 만들 수 있게 하는 패턴.

Bridge Pattern

구현부에서 추상층을 분리하여 각자 독립적으로 변형할 수 있게 하는 패턴.
추상적 개념과 이에 대한 구현 사이의 지속적인 종속 관계를 피하고 싶을 때 사용. 추상적 개념과 구현 모두가 독립적으로 서브클래싱을 통해 확장되어야 할때 사용.

Chain of Responsibility Pattern

책임 떠넘기기 패턴.

어떤 요구가 발생했을 때 그 요구를 처리할 객체를 바로 결정할 수 없는 경우에는 다수의 객체를 사슬처럼 연결해 두고 객체의 사슬을 차례로 돌아다니면서 목적에 맞는 객체를 결 정하는 경우

요구하는 사람과 요구를 처리하는 사람을 느슨하게 연결

Client 는 맨 처음 사람에게만 요구를 한다
그 요구가 처리자들을 연결한 사슬을 돌아다니다가 적절한 처리자에 의해 처리된다
이 패턴을 사용하지 않으면 , 이 요구는 이 처리자가 처리해야 한다 라는 지식을 누군가 중앙 집중적으로 가지고 있어야 한다. 이 지식을 요구자에게 맡기는 것은 현명하지 않다.

동적으로 처리자들의 순서를 바꿀 수 있다.

자신의 일에 집중할 수 있다.

유연성은 높지만, 처리 속도는 느린 단점.

Flyweight Pattern

크기가 큰 객체가 여러 개 있을 때, 공유를 통해 이들을 효율적으로 지원하는 패턴. 해쉬 테이블에 자주 사용되고 반복적이며 메모리가 큰 것을 저장해두고 재사용하는것

인스턴스를 가능한 한 공유시켜서, 쓸데없이 new를 하지 않도록 한다. – 인스턴스가 필요할 때 마다 new를 하는 것이 아니라, 이미 만들어져 있는 인스턴스를 이용할 수 있으면 공유하자.
Prototype은 복제를 하는 것이고 Flyweight는 있는것 그대로 쓴다.

Prototype Pattern

생성할 객체의 종류를 명시하는 데에 원형이 되는(Prototypical) 인스턴스를 이용하고, 그 원형을 복사함으로써 새로운 객체를 생성하는 패턴.
클래스로부터 인스턴스를 새로 만드는 것이 아니라, 현재 존재 하는 인스턴스를 복사(복제)해서 새로운 인스턴스를 만들 필요 가 있을 때, 이 작업을 편하게 하기 위해 사용한다

pros : 인스턴스를 만드는 복잡한 과정을 몰라도 되고 속도가 빠르다
cons : 복사본 자체를 만드는일 자체가 복잡할 수 있다.

객체를 빨리 생성하는 패턴

Memento Pattern

현재 객체의 상태를 기록하여 보존하기 위한 Memento 패턴
– Caretaker 역할은 중간 중간 Originator 역할에게 부탁하여 ‘현 재의 상태’를 표현하는 Memento 역할을 만든다.
– Caretaker 역할은 필요할 때 서랍 안에서 Memento 역할을 꺼 내서 Originator 역할에게 건네주면, 그 상태로 복원이 된다.

3. Principles of SW Design

Owl Life — Thu, 1 Dec 2022 22:46:00 +0900

SOLID

In computer programming, the term SOLID is a mnemonic acronym for five design principles intended to make software designs more understandable, flexible and maintainable. The principles are a subset of many principles promoted by Robert C.Martin. Though they apply to any object-oriented design, the SOLID principles can also form a core philosophy for methodologies such as agile development or Adaptive Software Development. The SOLID acronym was introduced by Michael Feathers.

SRP

A class should have only a single responsibility (i.e. changes to only one part of the software’s specification should be able to affect the specification of the class)

OCP

확장에는 열려 있어야 하고, 변경에는 닫혀 있어야 한다.

Don’t modify code, just extend class using inheritance, composition.

LSP

상속을 얼마나 잘 사용하고 있는가에 대한 원칙

상위 타입의 객체를 하위 타입의 객체로 치환해도 상위 타입을 사용하는 프로그램은 정상적으로 동작해야 한다.

상위 타입 : Base 클래스, 하위 타입 : 구체 클래스

class apple extends Item {}

// 메서드 인자로 item 대신에 apple을 넘기더라도 동작해야 함.
// 여기서 리스코프 치환 원칙이 지켜지지 않는다면, 다형성에 기반한 개방 폐쇄 원칙 역시 위반하는것.
// instanceof를 통하여 하위 클래스의 존재를 알아야 하는 순간 잘못 사용하고 있는것.
public int calculate(final Item item) {
	return item.calculate();
}

ISP

클라이언트는 자신이 사용하는 메서드에만 의존해야 한다.

인터페이스는 그 인터페이스를 사용하는 클라이언트를 기준으로 분리함으로써,

클라이언트로부터 발생하는 인터페이스의 여파가 다른 클라이언트에 미치는 영향을 최소화 하는것을 목표로 한다.

ISP 미적용	ISP 적용
User2 코드 수정시, User1도 새로 컴파일 해야 할 수 있음.

DIP

고수준 모듈은 저수준 모듈의 구현에 의존해서는 안 된다.

저수준 모듈이 고수준 모듈에서 정의한 추상 타입에 의존해야 한다. 즉, 자신보다 변하기 쉬운 것에 의존하지 마라.

Example

자동차가 스노우타이어에 의존. 즉, 고수준 모듈인 자동차가 저수준 모듈인 스노우타이어에 의존.

이런 경우, 타이어 변경시 자동차의 부속품도 변경 해야 함. → OCP 위배

이슈 해결 위하여, DIP는 추상화를 활용하여 아래처럼 설계

Separaction of Concerns

개발 및 유지관리를 단순하게 해준다.

잘 나뉘어 있는 관심사(concern)는 개별 섹션을 재사용 할 수 있을 뿐 아니라 다른 섹션의 세부 사항을 알지도 변경하지 않고도 개발된 코드를 재사용할 수 있게 함.

Q) Give examples of applying Separation of Concerns.

A) Internet protocol stack, MVC, Microservice 등

Modularity, Functional Independence

Cohesion : Indication of the relative functional strength of a module

Coupling : Indication of the relative interdependance among modules.

2. OO Analysis and Design (OOAD)

Owl Life — Thu, 1 Dec 2022 22:21:16 +0900

OOA 단계객체지향 분석 (Object Oriented Analysis)

- 문제를 정의하고 이 정의로부터 개념 모델(객체에 대한 추상적 정의)을 사용하여 객체, 관계 및 동작을 식별한다.

사물이나 컨셉을 설명하거나 찾아내는 것.

즉, 요구사항을 찾아내고, 그 속의 객체들의 목록을 찾아내는 것

OOA 단계

1. 요구사항 도출

- 소프트웨어가 수행해야 하는 작업과 해결하려는 문제를 정의

2. 요구사항 지정

- 일반적으로 사용사례 및 시나리오 또는 사용자 스토리를 사용하여 요구사항 설명

3. 개념 모델(Conceptual model)

- 중요한 객체를 식별하고 다듬고 관계와 동작을 정의하여 간단한 도표로 표현

개념 모델의 종류

1. 객체 모형 (Object Model)

- 객체들과 그 특성을 식별하여 객체들의 정적 구조(static structure)와 그들과의 관계(Interface)를 보여주는 객체 다이어그램(Object Diagram)을 작성한다.

2. 동적 모형 (Dynamic Model)

- 시간 흐름에 따른 시스템의 변화를 보여주는 상태 다이어그램(State Diagram)을 작성한다. 실시간(real-time) 시스템에서는 반드시 필요하다.

3. 기능 모형 (Function Model)

- 시스템 내에서 데이터 값이 변하는 과정을 보여주는 것으로 잘 알려진 자료 흐름도(DFD)가 사용된다.

객체지향 설계 (Object Oriented Design)

- 설계 단계에서는 객체와 그들의 속성(attribute), 동작(behavior), 상호작용(interaction)을 설명한다.

즉, OOA를 통해 찾아진 객체들 간의 관계를 설정하는 것.

설계 단계에서는...

올바른 요구에 맞는 다양한 다이어그램을 선택하는 것이 중요하다.

1. 클래스 다이어그램를 사용하여 클래스와 클래스의 관계를 설명
- 필요한 클래스를 시각적으로 나타낸다. 이 단계에서 유전성(Inheritance)이나 다형성(Polymorphism)과 같은 객체 지향적인 원칙에 대해서 구체적으로 알게 된다.

2. 시퀀스 다이어그램를 사용하여 개체 간의 상호작용을 설명

3. 그 외에도 객체간의 상호작용, 시스템의 구조, 시스템의 동작, 어떻게 이벤트에 반응하는지에 대해 표현할 수 있는 다이어그램이 많다.

그리고 소프트웨어 설계 원칙 및 설계 패턴을 적용하여 설계한다.

객체지향 설계의 종류

1. 시스템 설계(System Design)

- 시스템의 구조를 서브시스템으로 분해한다. 이 과정중에서 성능 최적 방안, 문제 해결 전략, 자원 분배 등이 확정된다.

2. 객체 설계(Object Design)

- 구현에 필요한 상세한 내역을 설계 모형으로 제작하고 상세화된다. 구체적인 자료구조와 알고리즘 들이 정의된다.

Q) When would you use X Diagram?

Use Case Diagram

사용자의 요구를 기능적인 측면에서 명시하며, 시스템이 제공해야 하는 서비스의 목록을 얻기 위해 사용.
또한, 특정 기능이 동작 후에 어떤 기능이 추가로 실행되는지, 또는 어떤 조건 하에 후속 기능이 수행되는지를 검토해보면서 공통 기능을 추출해 볼 수 있고, 유사 기능 분류를 통해 기능 단위로 Encapsulation을 수행해 볼 수 있다.
"시스템이 제공하고 있는 기능 및 그와 관련된 외부요소를 사용자의 관점에서 표현하는 다이어그램"
"시스템 외의 요소와 기능적 요구사항을 Actor와 Use case, Relationship으로 표현"

Relationships

연관(Association): Use Case와 Actor의 관계를 표현(실선)
확장(Extend): 기본 Use Case 수행 시 특별한 조건을 만족할 때 수행하는 Use Case
포함(Include): 시스템의 기능이 별도의 기능을 포함(점선)
일반화(Generalization): 하위 Use Case/Actor가 상위 Use Case/Actor에게 기능/역할을 상속 받음
그룹화(Grouping): 여러 개의 Use Case를 단순화 하는 방법

Granularity of Use Case

Use Case의 적당한 크기는 Use Case의 정의에 충실하게 되어 있고, 개발과 관리에 용이한가를 만족하면 된다.

Use Case Description / Scenario

사용자 중심 접근 (story와 예제 중심의 형식으로 기술)

사용자가 시나리오를 사용하여 요구사항 분석 지원

Class Diagram

도출한 Class들 간의 관계를 정의하고 검증함으로써 Persistence한 Dataset과 그들의 관계, 속성들을 결정한다.
Entity type의 class와 그들의 관계 및 cardinality, 그리고 몇개의 key 속성을 보여준다.
시스템을 구성하는 클래스의 구성 (Attribute, Operation)과 클래스 간의 관계를 표현하기위해 사용
Class Name, Attribute, Operation, Relationship을 가지고 있음.

5 Types of Relationship

Q) Order the strengths of 5 relationship types. Justify the ordering.

Inheritance : 상속 (Strong)
Composition : 생명 주기 함께
Aggregation : 레퍼런스 객체 가지고 있음.
Associate : 지속적 호출 (보통 한 클래스 내에서만 사용) / 한 객체가 다른 객체와 연결되어 있음을 나타낼때 사용.
Dependency : 잠깐 호출 (보통 한 메서드 내에서만 사용) (Weak)

Sequence Diagram

"Workflow related to Use Case Description"

"Applying MVC style paradigm in drawing Sequence Diagram"

Use case에 대해서 어떻게 Sequence적으로 동작하는지 설명

외부 사용자 또는 Actor가 발생시키는 이벤트, 메시지 호출의 순서 등을 이용하여 기능적인 요소들이 실시간에 어떤 메시지를 주고 받는지를 설계하기 위한 다이어그램.
시간의 흐름에 따라 여러 Object간의 상호작용을 구성 요소 간의 메시지 전달로 표현.

State Machine Diagram

목표 시스템이 State 종속적으로 실행되는 Behavior를 가지고 있을 때, 상태와 상태 간에 전이에 관련된 설계.

State Machine이 이벤트에 따라 어떠한 상태변화가 있는지를 모델링하는 다이어그램.

Transition, Event, Guard, Action

Event가 발생하면 현재 상태에 따라 상태 Transition이 발생한다.

Guard를 만족하지 못하면 이벤트가 발생하지 않는다.

State가 변경되면 entry, exit, do에 명시된 Action이 발생한다.

Final State는 실제로 존재할 수 있는 State이지만 Terminated Node는 아예 State Machine이 종료.

Timing Diagram

타이밍 다이어그램은 시퀀스 다이어그램 의 특수한 형태입니다 . 타이밍 다이어그램과 시퀀스 다이어그램의 차이점은 축이 반대로 되어 왼쪽에서 오른쪽으로 시간이 증가하고 생명선이 수직으로 배열된 별도의 구획에 표시된다는 것입니다.

Activity Diagram

여러 Action들이 순차 병행 방식 등을 수행하는 상황을 표현.

복잡한 Workflow나 병행 처리, 시간 제약이 있는 중요한 알고리즘에 대한 설계.

Action을 묶어 Activity로 나타낼 수 있음.

설계 단계에서는 클래스나 컴포넌트의 알고리즘을 Activity Diagram을 통해서 표현할 수도 있음.

Component Diagram

컴포넌트란 시스템을 구성하는 임의의 물리적인 요소를 의미
물리적인 요소란 가상의 모델을 실제로 구현하여 나타낸 것
객체지향 원리에서 컴포넌트는 인터페이스에 의해서 기능이 정의된 독립적으로 개발, 배포, 조립이 가능한 시스템의 구성 단위 (Ex. JAR, DLL)
컴포넌트 다이어그램의 구성요소는 컴포넌트, 인터페이스, 의존관계, 지원관계로 나뉨
의존관계는 컴포넌트와 컴포넌트 사이의 관계이고 지원관계는 인터페이스와 컴포넌트의 관계
컴포넌트들은 서로간 loosely coupled 해야 함.

Provided Interface

다른 컴포넌트가 사용할 수 있는 서비스를 명시하는것.

Required Interface

플러그인 컴포넌트가 구현해야 하는 프로토콜을 명시하는것.

Q) Why is required interface essential in designinig platform SW?

A) 컴포넌트는 하나의 구성 요소. S/W 디자인의 SRP에 따라 모든 인터페이스를 하나의 컴포넌트에 구현하는 것은 불가능함. 따라서 필요한 인터페이스는 외부의 다른 컴포넌트에서 얻어와야 할 수 있으며, 그렇기에 필수적이라 생각.

Deployment Diagram

이 다이어그램은 노드, 노드 간 네트워크 연결 및 노드에 배포된 소프트웨어 아티팩트를 지정.

UML Constructs for Parallel Processing

Activity Diagrm에서 fork & join 을 활용하여 표현 할 수 있습니다.

Consistency

Among Use Case Model, Class Diagram, & Sequence Diagram

Between State Machine Diagram & Class Diagram

Between Activity Diagram & Use Case Diagram

Q) How do you check the consistency between <X diagram> & <Y diagram>

객체지향 프로그래밍 / OOP란?

Owl Life — Thu, 1 Dec 2022 21:47:00 +0900

Object-Oriented Paradigm

객체 지향 패러다임을 설명할때 절차지향 프로그래밍과 비교하여 설명하곤 합니다.

아래 표를 통해 잠깐 살펴 보겠습니다. ^^

Procedural Programming	Object Oriented Programming
- 위에서 아래로 순서대로 수행되는 개발 방법 (C언어) - 컴퓨터 작업 처리 방식과 유사하기 때문에 실행 속도가 빠름 - 유지보수가 힘들고 시간이 많이 소요됨 - 수정시 모든 절차에 영향을 줄 수 있음	- 실제 세계를 모델링. - 데이터와 절차를 하나의 덩어리로 묶어서 표현. - Encapsulation, Inheritance, Polymorphism이 있음. - 프로그램을 유연하고 변경이 용이하게 만들기 때문에 대규모 소프트웨어 개발에 사용. - increase the flexibility and maintainability

Class and Objects

An object is an instance of a class. Objects are unit of abstraction. An object can communicate with other using messages. An object passes a message to another object, which results in the invocation of a method. Objects then perform the actions that are required to get a response from the system.

Real world objects all share two characteristics; they all have state and behavior. One-way to begin thinking in an object oriented way is to identify the state and behavior of real world objects. The complexity of objects can differ, some object have more states and more complex behaviors than other object. Compare the state and behavior of a television to the states and behaviors of a car.

Software objects are conceptually similar to real world objects. An object stores its state in fields, and it exposes its behaviors through its methods.

Encapsulation

하나의 객체에 대해 그 객체가 특정한 목적을 위해 필요한 변수나 메소드를 하나로 묶는 것.

데이터와 코드의 형태를 외부로부터 알 수 없게 은닉.

Cohesion 증가, Coupling 감소
SoC 달성
외부의 변화에 영향을 덜 받음

Inheritance

"is-a" 관계. 부모 객체의 속성과 메서드를 자식이 물려 받는 것.

객체들 간의 관계를 구축하는 방법 중 하나.

상속을 통해 부모 클래스의 기능을 자식 클래스가 재사용할 수 있고 기능을 확장 할 수 있음.

Polymorphism

상속을 통해 기능을 확장하거나 변경하는 것을 가능하게 해 줌.

즉, 형태가 같은데 다른 기능을 하는 것을 의미. 자바의 오버라이딩, 오버로딩이 대표적인 예.

1. Overloading

메서드의 이름은 같고 매개변수의 갯수나 타입이 다른 함수를 정의하는 것.

2. Overriding

상속 받은 하위 클래스가 메서드의 내용만 변경(재정의) 하는 것.

3. Dynamic Binding

객체의 성격이 컴파일 타임이 아닌 런타임에 결정됨. 다형성을 사용하고 OCP를 가능하게 하는 장치.

장점 : 유연성 (런타임까지 타입에 대한 결정을 끌고 갈 수 있기 때문에 많은 선택의 여지가 있음)
단점 : 안정성 (실행 도중에 예상치 못한 타입이 들어와서 타입 에러를 발생시키는 경우가 발생)
반면, 정적 바인딩은 컴파일 타임에 결정됨.
Q) Why is Dynamic Binding essential in object-oriented programming?

4. Substitutability (대체 가능성)

특정 타입을 사용해야 하는 곳이 있다면, 이 타입의 서브타입을 대신 쓸 수 있다는 원칙.

Abstraction

객체의 공통적인 속성과 기능을 추출하여 정의하는 것. 실제로 존재하는 객체들을 프로그램으로 만들기 위한 공통적인 특성을 파악해서 필요 없는 특성을 제거하는 과정

장점
- 재사용성 : 상속을 통해 프로그래밍시 코드의 재사용을 높일 수 있음.
- 생산성 향상 : 잘 설계된 클래스를 만들어서 독립적인 객체를 사용함으로써 개발의 생산성을 향상할 수 있음.
- 유지보수 우수성 : 프로그램 수정 시 캡슐화를 통해 주변 영향이 적기 때문에 유지보수가 쉬워서 매우 경제적이라고 할 수 있음.
단점
- 느린 개발 속도, 느린 실행 속도, 높은 난이도.

Information Hiding

코드 내부의 data와 method를 숨기고 공개된 Interface를 통해서만 접근이 가능하도록 하는 개념이다. 공개범위는 접근지시자로 지정 합니다.

Visibility(접근성)
Public, Protected, Private같은 접근 지시자를 이용해 데이터나 메소드에 대한 접근 권한을 제어하는 키워드

Encapsulation은 관련된 요소를 묶어 캡슐 내부와 외부를 구별지는 장치이고 Information Hiding은 캡슐 내부요소들에 대한 세부 구현사항을 외부에 숨기는 장치이다. 따라서 캡슐화 했다고 해서 반드시 Hide 되는 것은 아니다.

모듈간 의존도를 낮춰서 Coupling이 낮아지고 Modularity가 좋아진다. 모듈내에 변경해도 외부에 미치는 영향을 최소화 할 수 있다.

Abstract Class & Interface

Q) What is the difference between Abstract Class and Interface?

Abstract Class

추상 클래스를 상속 받아 기능을 이용하고 확장 시키기 위함
추상 메소드가 하나 이상 포함되면 반드시 추상 클래스로 선언되어야 함.
반드시 추상 클래스를 상속하는 자식 클래스에서 부모가 가진 추상 메소드를 모두 Overriding해야 함.
추상 클래스에서 추상 메소드가 아닌 일반 메소드를 포함시킬 수 있다.
추상 메소드는 몸체가 없고 선언부만 존재한다.
다중 상속 불가능

Interface

구현 객체의 같은 동작을 보장하기 위함
오로지 추상 메소드와 상수만을 가집니다. 즉 로직을 작성할 수 없습니다.
인터페이스 내에 존재하는 메소드는 무조건 public abstract로 선언됩니다.
인터페이스 내에 존재하는 변수는 무조건 public static final로 선언됩니다.
인터페이스는 다중 상속과 비슷한 기능을 제공합니다.
다중 상속 가능

Generic Class & Template

형식 매개 변수

- 사용자가 전달하는 “형식”을 매개변수로 사용하여 형식 내부에서 형식 매개 변수로 정의된 (주로 단일 형식 매개 변수에서는 T를 사용합니다.) 형식을 교체하는 것입니다.

- 클래스를 정의할 때, 구체적인 타입(type)을 적지 않고 변수 형태로 적어 놓는 것이다.

자음 한자 특수문자

Owl Life — Fri, 14 Oct 2022 22:53:44 +0900

https://allthatconverter.web.app/ko/special-characters/

특수문자 및 기호 모음 | AllThatConverter

AllThatConverter에서 편리하게 특수문자 및 기호 모음 기능을 이용해 보세요. 가입 없는 100% 무료 온라인 도구입니다.

allthatconverter.web.app

문장 부호
	1	2	3	4	5	6	7	8	9
ㄱ		！	＇	，	．	／	：	；	？
	＾	＿	｀	｜	￣	、	。	·	‥
	…	¨	〃		―	∥	＼	∼	´
	～	ˇ	˘	˝	˚	˙	¸	˛	¡
	¿	ː
괄호
	1	2	3	4	5	6	7	8	9
ㄴ	＂	（	）	［	］	｛	｝	‘	’
	“	”	〔	〕	〈	〉	《	》	「
	」	『	』	【	】
수학 기호
	1	2	3	4	5	6	7	8	9
ㄷ	＋	－	＜	＝	＞	±	×	÷	≠
	≤	≥	∞	∴	♂	♀	∠	⊥	⌒
	∂	∇	≡	≒	≪	≫	√	∽	∝
	∵	∫	∬	∈	∋	⊆	⊇	⊂	⊃
	∪	∩	∧	∨	￢	⇒	⇔	∀	∃
	∮	∑	∏

단위 기호
	1	2	3	4	5	6	7	8	9
ㄹ	＄	％	￦	Ｆ	′	″	℃	Å	￠
	￡	￥	¤	℉	‰	€	㎕	㎖	㎗
	ℓ	㎘	㏄	㎣	㎤	㎥	㎦	㎙	㎚
	㎛	㎜	㎝	㎞	㎟	㎠	㎡	㎢	㏊
	㎍	㎎	㎏	㏏	㎈	㎉	㏈	㎧	㎨
	㎰	㎱	㎲	㎳	㎴	㎵	㎶	㎷	㎸
	㎹	㎀	㎁	㎂	㎃	㎄	㎺	㎻	㎼
	㎽	㎾	㎿	㎐	㎑	㎒	㎓	㎔	Ω
	㏀	㏁	㎊	㎋	㎌	㏖	㏅	㎭	㎮
	㎯	㏛	㎩	㎪	㎫	㎬	㏝	㏐	㏓
	㏃	㏉	㏜	㏆
도형 문자
	1	2	3	4	5	6	7	8	9
ㅁ	＃	＆	＊	＠	§	※	☆	★	○
	●	◎	◇	◆	□	■	△	▲	▽
	▼	→	←	↑	↓	↔	〓	◁	◀
	▷	▶	♤	♠	♡	♥	♧	♣	⊙
	◈	▣	◐	◑	▒	▤	▥	▨	▧
	▦	▩	♨	☏	☎	☜	☞	¶	†
	‡	↕	↗	↙	↖	↘	♭	♩	♪
	♬	㉿	㈜	№	㏇	™	㏂	㏘	℡
	®	ª	º	㉾
괘선 문자
	1	2	3	4	5	6	7	8	9
ㅂ	─	│	┌	┐	┘	└	├	┬	┤
	┴	┼	━	┃	┏	┓	┛	┗	┣
	┳	┫	┻	╋	┠	┯	┨	┷	┿
	┝	┰	┥	┸	╂	┒	┑	┚	┙
	┖	┕	┎	┍	┞	┟	┡	┢	┦
	┧	┩	┪	┭	┮	┱	┲	┵	┶
	┹	┺	┽	┾	╀	╁	╃	╄	╅
	╆	╇	╈	╉	╊

원 문자/괄호 문자(한글)
	1	2	3	4	5	6	7	8	9
ㅅ	㉠	㉡	㉢	㉣	㉤	㉥	㉦	㉧	㉨
	㉩	㉪	㉫	㉬	㉭	㉮	㉯	㉰	㉱
	㉲	㉳	㉴	㉵	㉶	㉷	㉸	㉹	㉺
	㉻	㈀	㈁	㈂	㈃	㈄	㈅	㈆	㈇
	㈈	㈉	㈊	㈋	㈌	㈍	㈎	㈏	㈐
	㈑	㈒	㈓	㈔	㈕	㈖	㈗	㈘	㈙
	㈚	㈛
원 문자/괄호 문자(영/숫자)
	1	2	3	4	5	6	7	8	9
ㅇ	ⓐ	ⓑ	ⓒ	ⓓ	ⓔ	ⓕ	ⓖ	ⓗ	ⓘ
	ⓙ	ⓚ	ⓛ	ⓜ	ⓝ	ⓞ	ⓟ	ⓠ	ⓡ
	ⓢ	ⓣ	ⓤ	ⓥ	ⓦ	ⓧ	ⓨ	ⓩ	①
	②	③	④	⑤	⑥	⑦	⑧	⑨	⑩
	⑪	⑫	⑬	⑭	⑮	⒜	⒝	⒞	⒟
	⒠	⒡	⒢	⒣	⒤	⒥	⒦	⒧	⒨
	⒩	⒪	⒫	⒬	⒭	⒮	⒯	⒰	⒱
	⒲	⒳	⒴	⒵	⑴	⑵	⑶	⑷	⑸
	⑹	⑺	⑻	⑼	⑽	⑾	⑿	⒀	⒁
	⒂
전각 숫자(아라비아/로마)
	1	2	3	4	5	6	7	8	9
ㅈ	０	１	２	３	４	５	６	７	８
	９	ⅰ	ⅱ	ⅲ	ⅳ	ⅴ	ⅵ	ⅶ	ⅷ
	ⅸ	ⅹ	Ⅰ	Ⅱ	Ⅲ	Ⅳ	Ⅴ	Ⅵ	Ⅶ
	Ⅷ	Ⅸ	Ⅹ

분수/첨자
	1	2	3	4	5	6	7	8	9
ㅊ	½	⅓	⅔	¼	¾	⅛	⅜	⅝	⅞
ㅊ	¹	²	³	⁴	ⁿ	₁	₂	₃	₄
현대 한글 낱자
	1	2	3	4	5	6	7	8	9
ㅋ	ㄱ	ㄲ	ㄳ	ㄴ	ㄵ	ㄶ	ㄷ	ㄸ	ㄹ
	ㄺ	ㄻ	ㄼ	ㄽ	ㄾ	ㄿ	ㅀ	ㅁ	ㅂ
	ㅃ	ㅄ	ㅅ	ㅆ	ㅇ	ㅈ	ㅉ	ㅊ	ㅋ
	ㅌ	ㅍ	ㅎ	ㅏ	ㅐ	ㅑ	ㅒ	ㅓ	ㅔ
	ㅕ	ㅖ	ㅗ	ㅘ	ㅙ	ㅚ	ㅛ	ㅜ	ㅝ
	ㅞ	ㅟ	ㅠ	ㅡ	ㅢ	ㅣ
옛한글 낱자
	1	2	3	4	5	6	7	8	9
ㅌ	ㅥ	ㅦ	ㅧ	ㅨ	ㅩ	ㅪ	ㅫ	ㅬ	ㅭ
	ㅮ	ㅯ	ㅰ	ㅱ	ㅲ	ㅳ	ㅴ	ㅵ	ㅶ
	ㅷ	ㅸ	ㅹ	ㅺ	ㅻ	ㅼ	ㅽ	ㅾ	ㅿ
	ㆀ	ㆁ	ㆂ	ㆃ	ㆄ	ㆅ	ㆆ	ㆇ	ㆈ
	ㆉ	ㆊ	ㆋ	ㆌ	ㆍ	ㆎ
전각 로마자
	1	2	3	4	5	6	7	8	9
ㅍ	Ａ	Ｂ	Ｃ	Ｄ	Ｅ	Ｆ	Ｇ	Ｈ	Ｉ
	Ｊ	Ｋ	Ｌ	Ｍ	Ｎ	Ｏ	Ｐ	Ｑ	Ｒ
	Ｓ	Ｔ	Ｕ	Ｖ	Ｗ	Ｘ	Ｙ	Ｚ	ａ
	ｂ	ｃ	ｄ	ｅ	ｆ	ｇ	ｈ	ｉ	ｊ
	ｋ	ｌ	ｍ	ｎ	ｏ	ｐ	ｑ	ｒ	ｓ
	ｔ	ｕ	ｖ	ｗ	ｘ	ｙ	ｚ
그리스 문자
	1	2	3	4	5	6	7	8	9
ㅎ	Α	Β	Γ	Δ	Ε	Ζ	Η	Θ	Ι
	Κ	Λ	Μ	Ν	Ξ	Ο	Π	Ρ	Σ
	Τ	Υ	Φ	Χ	Ψ	Ω	α	β	γ
	δ	ε	ζ	η	θ	ι	κ	λ	μ
	ν	ξ	ο	π	ρ	σ	τ	υ	φ
	χ	ψ	ω

확장 라틴 문자
	1	2	3	4	5	6	7	8	9
ㄲ	Æ	Ð	Ħ	Ĳ	Ŀ	Ł	Ø	Œ	Þ
	Ŧ	Ŋ	æ	đ	ð	ħ	ı	ĳ	ĸ
	ŀ	ł	ø	œ	ß	þ	ŧ	ŋ	ŉ
히라가나
	1	2	3	4	5	6	7	8	9
ㄸ	ぁ	あ	ぃ	い	ぅ	う	ぇ	え	ぉ
	お	か	が	き	ぎ	く	ぐ	け	げ
	こ	ご	さ	ざ	し	じ	す	ず	せ
	ぜ	そ	ぞ	た	だ	ち	ぢ	っ	つ
	づ	て	で	と	ど	な	に	ぬ	ね
	の	は	ば	ぱ	ひ	び	ぴ	ふ	ぶ
	ぷ	へ	べ	ぺ	ほ	ぼ	ぽ	ま	み
	む	め	も	ゃ	や	ゅ	ゆ	ょ	よ
	ら	り	る	れ	ろ	ゎ	わ	ゐ	ゑ
	を	ん
가타카나
	1	2	3	4	5	6	7	8	9
ㅃ	ァ	ア	ィ	イ	ゥ	ウ	ェ	エ	ォ
	オ	カ	ガ	キ	ギ	ク	グ	ケ	ゲ
	コ	ゴ	サ	ザ	シ	ジ	ス	ズ	セ
	ゼ	ソ	ゾ	タ	ダ	チ	ヂ	ッ	ツ
	ヅ	テ	デ	ト	ド	ナ	ニ	ヌ	ネ
	ノ	ハ	バ	パ	ヒ	ビ	ピ	フ	ブ
	プ	ヘ	ベ	ペ	ホ	ボ	ポ	マ	ミ
	ム	メ	モ	ャ	ヤ	ュ	ユ	ョ	ヨ
	ラ	リ	ル	レ	ロ	ヮ	ワ	ヰ	ヱ
	ヲ	ン	ヴ	ヵ	ヶ
키릴 문자
	1	2	3	4	5	6	7	8	9
ㅆ	А	Б	В	Г	Д	Е	Ё	Ж	З
	И	Й	К	Л	М	Н	О	П	Р
	С	Т	У	Ф	Х	Ц	Ч	Ш	Щ
	Ъ	Ы	Ь	Э	Ю	Я	а	б	в
	г	д	е	ё	ж	з	и	й	к
	л	м	н	о	п	р	с	т	у
	ф	х	ц	ч	ш	щ	ъ	ы	ь
	э	ю	я

예쁜 특수문자 이모티콘 (바로 복붙 가능)

Owl Life — Tue, 30 Aug 2022 00:01:44 +0900

https://allthatconverter.web.app/ko/special-characters/

특수문자 및 기호 모음 | AllThatConverter

AllThatConverter에서 편리하게 특수문자 및 기호 모음 기능을 이용해 보세요. 가입 없는 100% 무료 온라인 도구입니다.

allthatconverter.web.app

"하트 특수문자 이모티콘"
( ღ'ᴗ'ღ )

◟( ˘ ³˘)◞ ♡

(•ө•)♡

(ฅ•ω•ฅ)♡

( ்́ꇴ ்̀)♡

ღ'ᴗ'ღ

๑❤‿❤๑

(๑˃̵ᴗ˂̵)و ♡

꒰◍ˊ◡ˋ꒱੭ु⁾⁾♡

(*ฅ́˘ฅ̀*)♡

( ˇ͈ᵕˇ͈ ) ¨̮♡⃛

(*ˊૢᵕˋૢ*)ෆ

( ˃̆ૢ௰˂̆ૢഃ ) ლ

٩(๑• ₃ -๑)۶♥

(๑˃̵ᴗ˂̵)و ♡

ʕ•ﻌ•ʔ ♡

ღ˘‿˘ற꒱

ෆ╹ .̮ ╹ෆ

ლ|'ー'ლ|

ლ( ╹ ◡ ╹ ლ)

₍₍ ( ๑॔˃̶◡˂̶๑॓)◞♡⁰

(✿◖◡◗)❤

"웃는 표정 이모티콘"
( ⁼̴̤̆◡̶͂⁼̴̤̆ )

(❁´▽`❁)

(❀╹◡╹)

(๑･̑◡･̑๑)

❛◡ુ❛

'◡'✿

✦‿✦

๑･̑◡･̑๑

๑❛◡ુ❛๑

꒰( ˵¯͒ꇴ¯͒˵ )꒱

◕‿◕✿

๑•‿•๑

๑◕‿‿◕๑

✪‿✪

✿˘◡˘✿

ღ˘‿˘ற꒱

(▰˘◡˘▰)

˘◡˘

✿˘◡˘✿

(๑′ᴗ‵๑)

(∗❛⌄❛∗)

(๑´◡ુ`๑)

p(´∇｀)q

๑•‿•๑

(*´ ワ `*)“

ξ(✿ ❛‿❛)ξ

(๑・‿・๑)

"신나는 표정 이모티콘"

♪(´ε｀*)

♪(*´θ｀)ノ

°˖✧◝(⁰▿⁰)◜✧˖°

٩(ˊᗜˋ*)و
҉ ٩(๑>ω<๑)۶҉

o(*'▽'*)/☆ﾟ’

٩(๑>∀<๑)۶

( ๑˃̶ ꇴ ˂̶)♪⁺

✧*.◟(ˊᗨˋ)◞.*✧

⁽⁽◝( ˙ ꒳ ˙ )◜⁾⁾

( ˃⍨˂̥̥ )

✺◟(∗❛ัᴗ❛ั∗)◞✺

(๑˃̵ᴗ˂̵)و

ᕕ( ᐛ )ᕗ

"귀여운 특수문자 이모티콘"(๑˃̵ᴗ˂̵)و

(╹౪╹*๑)

(˃̶᷄‧̫ ˂̶᷅๑ )

(✪ິັ໌໋໊ ꆚ ✪ິັ໌໋໊)

⁽⁽ૢ(⁎❝ົཽω❝ົཽ⁎)✧

₍₍ ◝(・ω・)◟ ⁾⁾

❛˓◞˂̵✧

( °ټ°)

(๑･̑◡･̑๑)

⁰▿⁰

(๑′ᴗ‵๑)

*❀्꒰⋆ᶿ̴͈᷇⌣ᶿ̴͈᷆⋆꒱ఇ

(๑╹∀╹๑)

❛ε ❛♪
p`>ω<´q)

(づ￣ ³￣)づ

(*ૂ❛ัᴗ❛ั*ૂ)

"화이팅 이모티콘"

ᕙ(•̀‸•́‶)ᕗ

٩( 'ω' )و

(ง •̀_•́)ง

(๑و•̀Δ•́)و

٩(๑•̀o•́๑)و

(๑ •̀ω•́)۶

٩(`･ω･´)و ҉*

\(`•ω•´)/*҉

٩( 'ω' )و ٩( 'ω' )و

✧ ☆ ٩(`･ω･´)و

"시무룩한 삐진 표정 이모티콘"

Σ(￣□￣;)

へ(￣∇￣へ)

( ｰ̀εｰ́ )✧*⁎

꒰⑅ᵕ̆‧̯ᵕ̆⑅꒱

(￣(ｴ)￣)ﾉ

(*￣(ｴ)￣*)

( •́ ̯•̀ )

ಡ ̯ ಡ

ｰ̀εｰ́

๑ŐεŐ๑

￣□￣

(´･ʖ̫･`)

๑°⌓°๑

(ㅇ︿ㅇ)

( •᷄⌓•᷅ )

(｡•́︿•̀｡)

๑°⌓°๑

(ﾟヘﾟ)？

(๑ӦㅅӦ๑)

(•ε•；)

"슬픈 표정 이모티콘"

⁺◟( ᵒ̴̶̷̥́ ·̫ ᵒ̴̶̷̣̥̀ )

o̴̶̷᷄﹏o̴̶̷̥᷅

(｡•́︿•̀｡)

ಡ︷ಡ)

(｡･ˇ_ˇ･｡)

( Ĭ ^ Ĭ )

(´°̥̥̥̥̥̥̥̥ω°̥̥̥̥̥̥̥̥｀)

"놀란 표정 이모티콘"

(ఠ ̥̆ ఠ)

(๑ŏ╻ŏ๑)

(๑°ㅁ°๑)‼✧

ŏ̥̥̥̥םŏ̥̥̥̥

(๑⊙ﾛ⊙๑)

(๑•́o•̀๑)

(оﾟдﾟо)

(╬☉д⊙)

(；◔д◔）

๑•̀ㅁ•́ฅ✧

"화난 표정 이모티콘"

٩(๑`^´๑)۶

☄ฺ◣д◢)☄ฺ

(╬◣д◢)

"특수문자 이모티콘 공유"

(͒ ˊ• ૢ·̫•ˋૢ)

(՟ິͫઘ ՟ິͫ)

( •̀.̫•́)✧

❛ัᴗ❛

(｡♋‸♋｡)

( ͡° ͜ʖ ͡°)

(ɔ ˘⌣˘)˘⌣˘ c)

₍₍ (ง ˙ω˙)ว ⁾⁾

( ･ิϖ･ิ)

( ⌯᷄௰⌯᷅ )

( ⁎ᵕᴗᵕ⁎ )

( °ټ°)

(๑ᵕ⌓ᵕ̤)

(⚭◡⚭ )

( ˇ͈ᵕˇ͈ )

(｡･ω･｡)o"

˘◡˘

(´͈ ᵕ `͈ )

ʅ（´◔౪◔）ʃ

(◔ิω◔ิ)

(〃･ิ‿･ิ)ゞ

(๑ᵕ⌓ᵕ̤)

(･ิω･ิ)

Ubuntu 16.04에서 Python 3.7 설치

Owl Life — Tue, 28 Jan 2020 21:25:30 +0900

들어가며...

django를 사용하려면 Python이 최소 3.7 버전이 설치 되어 있어야 합니다. 하지만 우분투 16.04에서 지원하는 버전은 3.5이기 때문에 추가로 설치를 하여야 합니다.

본인의 PC에 설치되어 있는 버전을 먼저 확인 해보겠습니다.

owllife@owllife-ubuntu:~$ python3
Python 3.5.2 (default, Oct  8 2019, 13:06:37) 
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>

3.5가 설치 되어 있는것을 확인하였습니다.

3.7 버전을 설치 할 때 한가지 유의 해야 할 점은,

우분투 16.04의 많은 시스템 프로그램(터미널, 프로그램 업데이트 등)에서 파이썬 3.5를 사용하고 있습니다.

만약, 파이썬3 default 버전을 현재처럼 3.5가 아닌 3.7로 변경하게 되면 시스템 프로그램등이 제대로 동작하지 않을 수 있습니다.

시스템 재부팅 후 갑자기 프로그램이 동작되지 않는 상황을 맞이 할 수 있기 때문에 "update-alternatives" 를 이용하여 강제로 변경하지 않도록 유의하여야 합니다.

파이썬 3.7 설치

아래 명령어를 통하여 설치를 할 수 있습니다.

$ sudo apt update
$ sudo apt install software-properties-common

$ sudo add-apt-repository ppa:deadsnakes/ppa

$ sudo apt update
$ sudo apt install python3.7

python3.7이 설치 되었지만, 파이썬3의 기본 버전으로 변경되지 않았는지 확인을 하기 위하여 터미널에서 확인을 해보겠습니다.

owllife@owllife-ubuntu:~$ python3
Python 3.5.2 (default, Oct  8 2019, 13:06:37) 
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>

파이썬 3.7이 설치 되었지만, 디폴트 버전은 여전히 3.5로 표시되는것을 확인하였습니다. 즉, 시스템 응용 프로그램들은 이전과 마찬가지로 정상적으로 동작하게 됩니다.

venv 설치

파이썬으로 개발하다보면 별도의 고립된 공통의 환경을 만들어두고 개발하는 경우가 많이 있습니다.

venv를 많이 사용하는데 이 역시 3.7 버전에 맞추어 설치하도록 하겠습니다. 터미널에서 아래 명령어를 입력합니다.

$ sudo apt-get install python3.7-venv

만약, python3.7-venv로 설치하지 않고 python3-venv 명령어로 설치하게 되면, 현재 시스템 디폴트 버전으로 잡혀 있는 python3.5 버전에 맞추어서 설치 되기 때문에 사용 할때 django와 같이 그 이상의 파이썬 버전이 필요한 경우에는 정상적으로 동작하지 않게 됩니다.

예를 들어 아래와 같은 에러 메시지를 보게 됩니다.

$ python3.7 -m venv my_common_env

Error: Command '['/home/owllife/PycharmProjects/my_common_env/bin/python3.7', 
       '-Im', 'ensurepip', '--upgrade', '--default-pip']' 
       returned non-zero exit status 1.

정상적으로 python3.7 및 venv가 설치 되었다면 아래 명령어를 통하여 가상 환경을 생성 할 수 있습니다.

$ python3.7 -m venv my_common_env

venv 활성화

이제 activate 명령어를 실행하고 파이썬 3.7이 사용 중인지 확인 해보겠습니다.

위 이미지의 명령어대로 방금 생성한 env를 활성화 시키면 명령어 프롬프트 앞쪽에 (my_common_env)와 같이 prefix가 붙게 됩니다. 이후에는 python 명령어만 입력 했을뿐인데 3.7 버전으로 실행 되는것을 확인 할 수 있습니다. django를 사용한다면 이 상태에서 django를 설치하고 기본 프로젝트 등을 생성하여 진행하시면 됩니다.

pip 버전 확인

(my_common_env) owllife@owllife-ubuntu:~/PycharmProjects$ pip -V
pip 19.2.3 from /home/owllife/PycharmProjects/my_common_env/lib/python3.7/site-packages/pip (python 3.7)

파이썬의 여러 라이브러리르 설치 하기 위하여 pip를 사용하는데 pip가 파이썬 3.7 버전을 정확히 매핑하고 있는지 확인하였습니다.

우분투 16.04 LTS 설치 후 초기 설정작업

Owl Life — Tue, 28 Jan 2020 11:18:53 +0900

개인적으로 설정하는 항목들을 정리하기 위하여 포스팅 하는 글입니다.

프록시나 고정IP를 사용하는 회사망이 아닌 홈환경입니다.

ROOT 비밀번호 설정

터미널을 열고
$ sudo passwd

apt-get 패키지 다운로드 서버 변경하기

# 파일은 /etc/apt/sources.list

# 터미널 열고
$ sudo vi /etc/apt/sources.list

# 우분투 설치시 한국으로 설정하시고 한국어 언어를 설정하였다면 
# http://kr.archive.ubuntu.com/ubuntu/ 가 보일텐데 이를 다음 카카오 서버로 변경.
# 콜론 입력 후 아래 명령어 입력 후 저장.
:%s/kr.archive.ubuntu.com/ftp.daumkakao.com

# 동작 확인
$ sudo apt-get update

# 업그레이드 원하면
$ sudo apt-get upgrade -y

완료 된 화면

언어 지원

윈도우 키 눌러서 "언어 지원" 입력 후 실행합니다. 필수 언어를 다운로드 진행하고, 키보드 입력기는 fcitx 로 합니다.

우분투 설치시 키보드 설정하는 단계에서 한국어를 선택하지 않고, 영문으로 선택하게 되면 한/영 전환 키보드가 매핑되지 않아서 한영키가 동작하지 않습니다. 한/영키가 동작하지 않고 좌측 쉬프트+스페이스로 동작되기 때문에 별도로 설정해야 하는데 이 부분은 구글링을 통해 해결책을 찾을수 있습니다.

D2 Coding 글꼴 설치

https://softwaree.tistory.com/22

우분투 업데이트 및 그래픽 드라이브 설치

AMD나 NVIDIA 홈페이지에서 직접 다운로드 받아서 설치하게 되면 조금 번거롭습니다. 하지만, 소프트웨어 업데이트 도구를 이용하면 매우 쉽게 업데이트 할 수 있습니다. "소프트웨어 업데이트 도구" 를 선택 후 설정을 누르면 아래 두번째 창이 보이는데 "추가 드라이버" 탭으로 이동해보겠습니다.

사용가능한 여러 드라이브들이 버전별로 나오는데 그 중에서 본인 그래픽 드라이브와 호환 가능한 안정화 된 버전을 선택 후 적용을 선택하면 됩니다. 적용 후 꼭 재부팅을 하고 다시 위 화면으로 진입해서 정상적으로 적용되었는지 확인을 해 보는것을 권장합니다.

추가로, 안정화를 위하여 우분투 업데이트를 한번 진행 하는것을 권장한다. (첫번째 팝업의 지금 설치 버튼)

키보드 설정

키보드의 반복키 입력 간격을 줄이기 위하여 설정합니다. 지연 시간을 좀 짧게 설정하면 타이핑할때 딜레이 없이 입력이 가능합니다.

마우스 속도 설정

마우스 포인트 속도가 너무 빠르거나 느릴 경우에 아래처럼 설정 할 수 있습니다.

먼저 아래 명령어를 통하여 마우스의 input id를 알아야 합니다.

$ xinput --list --short

저는 MX Master 마우스를 사용하는데 id가 9번인 것을 확인 할 수 있습니다.

이제 터미널에 아래 명령어를 통하여 마우스 감도를 설정합니다.

$ xinput -set-prop 9 'Device Accel Constant Deceleration' 1.5

마지막 인자인 1.5가 감도인데, 제 환경에서는 1.5가 가장 적당하여 이렇게 설정하였습니다. 숫자가 낮을수록 포인트 속도는 빨라지고, 숫자가 커질수록 포인트 속도는 느려집니다. 각자의 환경에 맞추어 실험 후 최적의 값을 찾으면 됩니다.

xinput 변경값은 시스템이 재부팅되면 다시 리셋이 되어 또 다시 설정을 해 주어야 합니다. 이런 번거로움을 없애기 위해서는 "시작 프로그램"을 통하여 재부팅 될때마다 자동으로 스크립트를 실행 하도록 합니다.

VIM 설치

다른 글에서 작성한 링크로 대신합니다. vim 설치 및 vimrc 설정도 포함하고 있습니다.

https://softwaree.tistory.com/20?category=729597

터미널 설정

터미널을 열고 '편집'의 '프로파일 기본 설정'을 선택합니다. 최초 터미널 크기를 좀 더 키우고, 터미널 삑소리는 disable 하였습니다.

'색' 탭으로 이동 후 '투명한 배경 사용' 을 활성화 시키고 적당히 투명 감도를 조절해줍니다. 개인적으로 투명 배경을 매우 선호하기 때문에 꼭 설정하는 부분입니다.

마지막으로 '스크롤' 탭으로 이동 후 스크롤 막대 표시를 없애고, 제한 범위를 *10배로 상향시켰습니다. 콘솔로 개발 작업을 많이 하다보니 히스토리창을 꽤 이전것까지 참고하는 경우가 많아서 상당히 버퍼를 높여서 사용하는 편입니다.

Unity Tweak Tool 설치 및 설정

Ubuntu Gnome Tweak과 마찬가지로 Unity에도 Tweak 툴이 있는데 상세한 부분까지 설정이 가능한 추천 프로그램입니다. 런처를 상하좌우로 이동하는것부터, 테마/아이콘/font 까지 설정하고 virtual desktop의 배치 또한 설정이 가능합니다.

설치는 터미널에서 명령어로 가능합니다.

$ sudo apt-get install unity-tweak-tool

실행하면 아래 화면처럼 다양한 메뉴가 나타납니다.

런처 설정

Launcher 메뉴에서는 런쳐의 위치를 설정하거나 아이콘의 사이즈 등을 변경 할 수 있습니다.

테마 설정

Tweak Tool을 사용하는 가장 큰 이유이기도 합니다. 개인적으로 Numix 테마를 선호하기 때문에 설치하는 방법을 설명하겠습니다.

# 터미널을 열고

$ sudo add-apt-repository ppa:numix/ppa
$ sudo apt-get update
$ sudo apt-get install numix-*

테마에서 방금 설치 한 Numix를 선택합니다.

아이콘은 Numix-circle을 선택합니다. 개인적으로 가장 심플하면서 마음에 드는 스타일입니다.

폰트는 위와같이 설정하였습니다. Ubuntu 16.04 에서는 기본적으로 Noto Sans 폰트를 포함하고 있기 때문에 해당 폰트를 기본으로 설정하였고, monospace 또한 Noto Sans Mono로 변경하였습니다.

배경화면

개인적으로 심플한 배경화면을 좋아해서 아래 웹페이지에서 주로 다운로드를 합니다.

https://wallpaperplay.com/board/4k-minimalist-wallpapers

참고로, 만약 Tweak Tool을 이용해서 테마를 사용하고 있다면, 로그인 화면에 보이는 배경화면은 현재 설정한 배경 화면이 그대로 보이게 됩니다.

GIT 설치

$ sudo apt-get install git

이미지 뷰어 설치

개인적으로 PhotoQT Image Viewer을 선호합니다. UI가 매우 직관적이고 속도도 빨라서 다른 프로그램을 설치하더라도 결국엔 PhotoQT만 사용하게 되었습니다.

$ sudo apt-add-repository ppa:lumas/photoqt
$ sudo apt update && sudo apt install photoqt

Ctrl+O 입력을 통해 Folder 선택을 할 수 있고 선택을 하면 두번째 스크린샷 처럼 하단에 폴더 이미지가 모두 보여집니다. 기타 상세한 정보나 view 스타일 또한 메인 화면에서 설정 할 수 있습니다.

우분투 18.04 자바 설치

Owl Life — Tue, 26 Nov 2019 21:08:12 +0900

버전 확인

$ java -version
openjdk version "1.8.0_222"
OpenJDK Runtime Environment (build 1.8.0_222-8u222-b10-1ubuntu1~18.04.1-b10)
OpenJDK 64-Bit Server VM (build 25.222-b10, mixed mode)

자바가 설치되지 않았다면 1.8을 설치
- Oracle : https://www.oracle.com/java/technologies/jdk8-downloads.html

- Bell-sw : https://bell-sw.com/pages/java-8u222/

* Oracle은 로그인해야 하는 번거로움이 있음.

* Bell-sw에서 빠르게 다운로드 받을수 있으니 참고.

빌드 할 때 아래와 같은 에러 발생시에는 제대로 된 JDK 가 설치되어 있지 않았으므로 위의 링크를 통해 다시 설치 필요.

* What went wrong: Execution failed for task ':app:compileDebugJavaWithJavac'. 
  > Could not find tools.jar. Please check that /usr/lib/jvm/java-8-openjdk-amd64 contains a valid JDK installation.

* 여러개의 자바 버전이 설치되어 있는 경우에 선택해서 타겟팅 해야 함.

$ update-alternatives --config java

대체 항목 java에 대해 (/usr/bin/java 제공) 2개 선택이 있습니다.

  선택       경로                                                 우선순위   상태
----------------------------------------------------------------------------------
* 0            /usr/lib/jvm/bellsoft-java8-amd64/jre/bin/java   2080222   자동 모드
  1            /usr/lib/jvm/bellsoft-java8-amd64/jre/bin/java   2080222   수동 모드
  2            /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java   1081      수동 모드

Press <enter> to keep the current choice[*], or type selection number: 0

우분투 18.04 테마 변경하기

Owl Life — Sun, 17 Nov 2019 22:17:26 +0900

개인) 아래 링크 참고해서 셋팅.

[Linux] Ubuntu 18.04 테마 설정하기

안녕하세요~ 이번 포스팅에서는 우분투 환경에서 테마를 적용하는 방법에 대해 알아보도록 하겠습니다! 우분투의 기본 테마는 아래와 같습니다. (이미지 출처: 구글) 이전의 16.xx 버전보다는 많이 깔끔해졌는데..

codevkr.tistory.com

특수문자 유니코드표 - 이모지, 이모티콘, 지도기호

Owl Life — Sun, 17 Nov 2019 21:50:33 +0900

https://allthatconverter.web.app/ko/special-characters/

특수문자 및 기호 모음 | AllThatConverter

AllThatConverter에서 편리하게 특수문자 및 기호 모음 기능을 이용해 보세요. 가입 없는 100% 무료 온라인 도구입니다.

allthatconverter.web.app

이모지

이모티콘

지도 기호

파이썬 Django DB 초기화

Owl Life — Sun, 17 Nov 2019 21:04:24 +0900

Django로 개발을 하다보면 DB 초기화를 종종 해야 할 경우가 있습니다.

migration 하다가 DB가 꼬이는 경우 에러가 빈번하게 발생될 수 있기 때문에 어떻게 초기화 하는지에 대하여 한번 알아보겠습니다.

migrations 파일 삭제

$ find . -path "*/migrations/*.py" -not -name "__init__.py" -delete
$ find . -path "*/migrations/*.pyc"  -delete

프로젝트의 root 위치에서 위와 같이 세 줄이면 DB 초기화가 완료되고 작성한 model의 스키마까지 적용이 완료됩니다. DB 관련 앱의 하위 폴더를 보면 migrations 폴더가 있을텐데 그 폴더에 존재하는 __init__.py 파일을 제외하고 폴더 내의 모든 파일을 삭제 합니다. 또한 파이썬 바이트코드인 pyc 파일들도 모두 제거합니다.

db.sqlite3

프로젝트의 root 디렉토리에 위치한 db.sqlite3 파일을 삭제합니다.

migration

$ python manage.py migrate

django 로 DB 생성할때 최초에 한번 migration 하는것처럼 위와 같은 명령어로 동일하게 수행합니다.

Trouble shooting - Python3: UnicodeEncodeError: 'ascii' codec can't encode character

Owl Life — Thu, 14 Nov 2019 23:54:12 +0900

print() 메서드를 이용하여 문자열을 출력할때 이러한 에러를 가끔씩 만날수 있습니다.

UnicodeEncodeError: 'ascii' codec can't encode character u'\xa1' 
in position 0: ordinal not in range(128)

해결책으로, 아래처럼 encoding 타입을 utf-8로 설정하면 수정이 가능합니다.

$ export PYTHONIOENCODING=utf-8

파이썬으로 웹페이지 크롤링을 해보자. (2) 텔레그램으로 메시지 보내기

Owl Life — Tue, 12 Nov 2019 00:40:44 +0900

이번 시간에는 앞서 구현한 크롤링 모듈을 일정 시간마다 시스템에서 자동으로 실행 하도록 실습 해보겠습니다. 그리고 새로운 글을 찾았을때 텔레그램과 연동해서 메시지를 전달 하는 기능을 구현해보도록 하겠습니다.

크롤링 실행 주기 설정

주기적으로 어떤 프로그램이나 스크립트를 실행 할 때에는 crontab 을 많이 사용합니다. 본 포스팅에서도 이 서비스를 이용하여 주기적으로 앞에서 만든 크롤링 모듈을 실행 해보도록 하겠습니다.

주기적으로 실행 되었다는것을 나타내기 위하여 clien_crawler.py 파일의 main 메서드에 현재의 시간을 기록하는 코드를 추가하겠습니다.

from datetime import datetime

if __name__ == '__main__':
    print('start - ' + datetime.now().strftime('%Y-%m-%d %H:%M:%S'))
    crawled_data = fetch_clien_latest_data()
    add_new_items(crawled_data)

또한, fetch_clien_latest_data() 메서드의 print(title) 코드도 더이상 불필요하기 때문에 삭제하였습니다.

자동 실행될 스크립트 파일 생성

crontab에 의하여 실행될 스크립트 파일을 root project에 위치시킵니다. 필자는 start_crawling.sh 파일명으로 아래처럼 코드를 작성하였습니다.

#!/bin/bash

source ~/PycharmProjects/MyVirtualEnv/bin/activate
python3 ~/PycharmProjects/a/ClienCrawlingDjango/clien_crawler.py

MyVirtualEnv라는 별도의 가상 환경을 사용하고 있기 때문에 액티베이션 시키는 코드를 첫줄에 추가하였습니다. 그 이후에 python3 로 clien_crawler.py 파일을 실행 시키는 코드를 작성하였습니다. 만약 가상 환경을 사용하지 않는다면 'source~' 줄은 추가하지 않아도 됩니다.

이제 이 스크립트를 실행하기 위하여 crontab 을 편집해보겠습니다. 터미널에서 crontab -e 명령어를 입력합니다. 그러면 에디터 창이 보이는데, 그 창에 crontab 관련 규칙과 실행할 명령어를 입력합니다.

$ crontab -e

#여기부터 에디터 입력창
*/1 * * * * ~/PycharmProjects/a/ClienCrawlingDjango/start_crawling.sh >> ~/PycharmProjects/a/ClienCrawlingDjango/crontab_log.txt 2>&1

crontab 의 주기 설정 방법은 링크를 참고 부탁드립니다. 위 코드는 1분마다 크롤링을 하는 코드를 작성하였기 때문에 가장 앞쪽에 '분' 단위 룰을 나타내는곳에 */1 을 설정하였습니다. 5분마다 설정하고 싶다면 */5 라고 설정하시면 됩니다.

'>>' 오퍼레이터는 print되는 문자들을 별도의 로그 파일에 기록하기 위함입니다. '>'는 덮어쓰기 작업이고, '>>'는 파일에 추가하는 작업입니다. 오랜 시간이 지나면 파일의 크기가 커지기 때문에 주기적으로 삭제해야 합니다.

입력을 완료 하였으면 저장 후 터미널로 돌아옵니다. 정상적으로 추가 되었는지 확인하려면 crontab -l 명령어를 입력해보면 리스트를 확인 할 수 있습니다.

$ crontab -l
*/1 * * * * ~/PycharmProjects/a/ClienCrawlingDjango/start_crawling.sh >> ~/PycharmProjects/a/ClienCrawlingDjango/crontab_log.txt 2>&1

몇분 정도의 시간 뒤에 로그 파일을 열어 보았습니다. 아래처럼 정상적으로 스크립트 파일이 실행되었고, 정확히 1분 간격으로 크롤링이 진행 되었음을 확인 할 수 있습니다.

start - 2019-11-11 13:26:00
start - 2019-11-11 13:27:01
start - 2019-11-11 13:28:02
start - 2019-11-11 13:29:03

텔레그램으로 메세지 전송하기

텔레그램으로 메시지를 전송하는 코드를 먼저 살펴보겠습니다. clien_crawler.py 파일에 추가하였습니다.

def send_noti_to_telegram(items):
    if len(items) == 0:
        return

    bot_token = '1034490xxxxxx'
    bot_chat_id = '-10010000000'

    for item in items:
        bot_message = "\[클리앙] " + item['title'] + \
                      "\n" + item['link']

        send_text = 'https://api.telegram.org/bot' + bot_token + \
                    '/sendMessage?chat_id=' + bot_chat_id + \
                    '&parse_mode=Markdown&text=' + bot_message

        requests.get(send_text)
        sleep(1)
        
        
if __name__ == '__main__':
    print('start - ' + datetime.now().strftime('%Y-%m-%d %H:%M:%S'))
    crawled_data = fetch_clien_latest_data()
    db_inserted_items = add_new_items(crawled_data)
    send_noti_to_telegram(db_inserted_items)

main 함수를 보면 디비에 추가된 항목을 리스트로 전달받고 send_noti_to_telegram() 메서드를 호출하고 있습니다. 이 메서드에서는 텔레그램으로 전달할 메시지를 빌드하고, requests 를 통하여 전달하고 있습니다.

여기에서 필요한게 bot token과 bot chat id 입니다. 어떻게 획득 할 수 있는지 한번 살펴보겠습니다.

텔레그램 bot token / bot chat id 획득하기

텔레그램을 실행 후 검색창에서 'BotFather'를 입력합니다.

선택 후 대화를 시작합니다. 대화 창에서 /newbot 을 입력합니다. 그러면 새로운 봇 이름을 입력하라는 메시지가 전달됩니다. 새로운 봇 이름을 입력합니다.

본 포스팅에서 사용할 예제에서는 'clien_test_bot' 으로 입력하겠습니다. 정상적으로 입력이 되면 이제 'bot'으로 끝나는 사용자 이름을 입력하라는 메시지가 전달됩니다. 똑같이 'clien_test_bot' 으로 입력하겠습니다. 완료되면 bot token 을 받을 수 있습니다.

숫자 9953으로 시작하는게 bot token 입니다.

이제 새로운 채널을 하나 생성해야 합니다. 아래처럼 아이콘을 클릭 후 "New Channel"을 선택합니다.

채널 이름은 "clien_test_channel" 로 입력하였습니다. 원하시는 채널 이름을 입력하시면 됩니다.

입력을 완료하면 우측 상단에 있는 "Next" 버튼을 클릭합니다. 완료되면 채널이 하나 생성되는것을 확인 할 수 있습니다.

생성한 채널의 관리자로 텔레그램 봇을 추가하기

bot chat id을 알기 위해서는 봇을 채널의 관리자로 추가 하여야 합니다. 관리자로 추가 하는 방법은 채널의 우측의 Info 에서 관리자 또는 Administrators를 클릭합니다.

Add Admin 을 클릭 후, 조금전에 생성한 clien_test_bot 을 검색 후 추가 해줍니다.

선택 후 추가 권한을 선택하는 창이 한번 더 보이는데 "Add Subscribers"를 FALSE 로 선택 하여야 합니다. 완료하면 아래처럼 관리자가 두명인것을 확인 할 수 있습니다. Shun은 본인 계정이고, clien_test_bot은 관리자 권한을 위임받은 봇입니다.

bot chat id 받기

이제 bot chat id 를 알아보도록 하겠습니다.

아래 URL 에 API 내용을 붙여 넣기 하여 인터넷 주소창에 입력하고 이동 해 봅니다.

https://api.telegram.org/bot[이부분]/getUpdates

위와 같이 입력을 하면 봇과 관련된 여러 정보들이 보여집니다. 만약 result에 아무런 정보가 보이지 않는다면 좀 기다렸다가 다시 시도 해보시기 바랍니다. bot chat id는 -1001173133632라는 것을 알 수 있습니다.

텔레그램으로 메시지 보내기

주소창에 아래처럼 입력을 해보겠습니다.

https://api.telegram.org/bot995398932:AAHsc4J34GC1UY59oUX0HrX6tcxs7sCTXjI/sendMessage?chat_id=-1001173133632&text=Hello

그러면 텔레그램 채널로 Hello가 입력 되는것을 확인 할 수 있습니다.

이제 저 URL을 python 코드상에서 적절히 조합을 하면 텔레그램으로 메시지를 손쉽게 전송 할 수 있습니다.

bot token과 bot chat id 둘다 알았으니 코드를 업데이트하고 실행해보겠습니다.

def send_noti_to_telegram(items):
    if len(items) == 0:
        return

    bot_token = '995398932:AAHsc4J34GC1UY59oUX0HrX6tcxs7sCTXjI'
    bot_chat_id = '-1001173133632'

    for item in items:
        bot_message = "\[클리앙] " + item['title'] + \
                      "\n" + item['link']

        send_text = 'https://api.telegram.org/bot' + bot_token + \
                    '/sendMessage?chat_id=' + bot_chat_id + \
                    '&parse_mode=Markdown&text=' + bot_message

        requests.get(send_text)
        sleep(1)

실행을 해보니 새로운 글이 2건 등록되었습니다.(PyCharm Console에서 확인)

해당 2건은 DB에 추가 후 텔레그램으로 푸쉬가 오는것을 확인 할 수 있습니다. (텔레그램 채널 확인)

TIP

만약, bot_message에 & 문자를 가진 url을 포함한다면 그대로 전송할시에 정상적으로 노출이 되지 않을수 있습니다.

이럴 경우에는 아래처럼 UTF-8 문자로 변경하면 정상적으로 전송이 됩니다.

bot_message.replace('&', '%26')

여기까지 텔레그램으로 메시지를 보내는 기능을 살펴보았습니다.

파이썬으로 웹페이지 크롤링을 해보자. (1) Django 프로젝트 만들기

Owl Life — Mon, 11 Nov 2019 19:14:50 +0900

들어가며...

파이썬으로 웹페이지의 새로운 게시글을 크롤링하고, Django를 이용해서 DB에 저장하는 실습을 해보도록 하겠습니다.

crontab을 이용해서 주기적으로 크롤링을 실행되도록 하고, 새로운 글이 크롤링 되었을때 텔레그렘이나 슬랙으로 전송하는 기능과 VPS 에서 실행되도록 하는 실습을 진행해보겠습니다.

이번 첫 시간에는 Django 프로젝트를 생성 해보겠습니다. Django 프로젝트와 앱을 만들고, Model을 통해 DB를 생성하고 크롤링 된 데이터를 저장 및 관리자 페이지를 섿업하는것까지 진행해보겠습니다. 만약, Django가 처음이라면 이 링크를 참고 하시면 많은 도움이 될 것입니다.

Python 3.7 버전 설치

Django 설치를 위한 파이썬 최소 버전은 3.7입니다. 만약, 본인의 개발 환경(우분투)에 3.7 버전이 설치되어 있지 않다면 아래 링크를 통하여 설치 후 진행을 권합니다. 만약, 본인이 초급자라면 venv도 설치를 권합니다. 설치 방법은 역시 링크에 포함되어 있습니다.

https://softwaree.tistory.com/85

Ubuntu 16.04에서 Python 3.7 설치

들어가며... django를 사용하려면 Python이 최소 3.7 버전이 설치 되어 있어야 합니다. 하지만 우분투 16.04에서 지원하는 버전은 3.5이기 때문에 추가로 설치를 하여야 합니다. 본인의 PC에 설치되어 있는 버전을..

softwaree.tistory.com

Django 설치하기

python 3.7버전 이상이 설치 되어 있다면 간단한 명령어로 Django를 설치 할 수 있습니다.

$ pip install django

Django 프로젝트 생성하기

django가 성공적으로 설치되면 django-admin 이라는 명령어로 장고 프로젝트를 생성 할 수 있습니다.

이번 포스트에서는 제가 좋아하는 '클리앙' 이라는 커뮤니티의 크롤링을 위하여 ClienCrawlingDjango 라는 이름으로 프로젝트를 만들어보겠습니다.

$ django-admin startproject ClienCrawlingDjango

생성을 완료하면 아래와 같은 폴더 트리를 볼 수 있습니다. (IDE는 PyCharm CE)

장고 앱 생성하기

Django는 프로젝트와 그 안의 앱으로 관리됩니다. 이 앱은 하나의 기능을 담당하는 컴포넌트로 보면 될것 같습니다. 앱은 manage.py 파일을 통해서 startapp이라는 명령어로 생성이 가능합니다. crawled_data라는 이름의 앱을 만들어보겠습니다.

$ python manage.py startapp crawled_data

정상적으로 생성이 되었다면 아래 스크린샷처럼 프로젝트의 구조를 볼 수 있습니다.

생성만으로 끝난게 아니라 이 앱을 Django가 관리하도록 수정 작업을 해야 합니다.

ClienCrawlingDjango 폴더 안의 settings.py 파일의 INSTALLED_APPS에 추가 하여야 합니다.

# Application definition
INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'crawled_data'
]

DB 첫 마이그레이션

DB를 사용하기 위하여 최초 1회 마이그레이션을 진행 하여야 합니다. 명령어는 python manage.py migrate 입니다.

$ python manage.py migrate
Operations to perform:
  Apply all migrations: admin, auth, contenttypes, sessions
Running migrations:
  Applying contenttypes.0001_initial... OK
  Applying auth.0001_initial... OK
  Applying admin.0001_initial... OK
  Applying admin.0002_logentry_remove_auto_add... OK
  Applying admin.0003_logentry_add_action_flag_choices... OK
  Applying contenttypes.0002_remove_content_type_name... OK
  Applying auth.0002_alter_permission_name_max_length... OK
  Applying auth.0003_alter_user_email_max_length... OK
  Applying auth.0004_alter_user_username_opts... OK
  Applying auth.0005_alter_user_last_login_null... OK
  Applying auth.0006_require_contenttypes_0002... OK
  Applying auth.0007_alter_validators_add_error_messages... OK
  Applying auth.0008_alter_user_username_max_length... OK
  Applying auth.0009_alter_user_last_name_max_length... OK
  Applying auth.0010_alter_group_name_max_length... OK
  Applying auth.0011_update_proxy_permissions... OK
  Applying sessions.0001_initial... OK

crawled_data 앱의 모델 생성하기

DB에 데이터를 저장할 모델을 만들어 보겠습니다. Django에서 모델은 앱 단위로 만들어지고 구성이 됩니다. 앞에서 만든 앱 단위인 crawled_data 안에 있는 models.py파일을 수정해줘야 합니다.

이 모델 파일은 크롤링한 데이터를 필드별로 저장하는것이 목적입니다. 따라서 크롤링한 데이터의 추출할 부분을 미리 파악해서 객체로 만들어주어야 합니다. Django는 NoSQL이 아닌 SQL DB이기 때문에 스키마 정의를 해 주어야 하는데 이 스키마 정의를 별도의 object 클래스로 정의하여야 합니다.

본 실습 프로젝트에서는 requests 라이브러리와 BeautifulSoup4(bs4) 라이브러리를 주로 활용할 계획입니다.

DB에 저장할 데이터는 타이틀과 링크, 고유 ID로 구성하겠습니다. BoardData라는 이름의 Table을 DB에 만들도록 하겠습니다.

django models의 class는 DB의 Table로 변환이 됩니다.

from django.db import models


# Create your models here.
class BoardData(models.Model):
    title = models.CharField(max_length=300)
    link = models.URLField()
    specific_id = models.CharField(max_length=15)

이렇게 만들면 title은 최대 300글자 제한의 CharField로, link는 URLField로, specific_id 는 15글자의 제한의 CharField로 생성됩니다. specific id는 클리앙 게시글에 부여되는 고유 ID로서 최신 데이터인지를 판단하는 기준으로 사용됩니다.

DB Migration

새로운 DB가 추가되었으니 db migration을 진행하여야 합니다. 아래처럼 명령어를 입력하면 DB의 변경 정보를 정리하고, 실제 DB에 반영하는 과정을 진행하게 됩니다.

$ python manage.py makemigrations crawled_data
Migrations for 'crawled_data':
  crawled_data/migrations/0001_initial.py
    - Create model BoardData
(common_env) owllife in ~/PycharmProjects/a/ClienCrawlingDjango
$ python manage.py migrate crawled_data
Operations to perform:
  Apply all migrations: crawled_data
Running migrations:
  Applying crawled_data.0001_initial... OK

마이그레이션을 할 때마다 crawled_data 앱 폴더의 하위에 있는 migrations 폴더를 보면 버전순으로 어떤점들이 변경되었는지를 볼 수 있습니다.

최초로 DB 테이블을 생성하였기 때문에 _initial라는 suffix가 붙어 있습니다. 이 파일들은 makemigrations라는 명령어를 통해 생성이 되고, 실제로 DB에 적용을 할 때에는 migrate라는 명령어를 사용하게 됩니다. 바로 이전에 실행한 명령어들입니다.

클리앙 커뮤니티 크롤링 함수 구현

클리앙의 "모두의 공원" 이라는 게시물에서 "쿠팡"이라는 키워드로 검색후, 새로운 키워드가 있는 경우에만 DB에 추가 해보도록 하겠습니다. ~~(쿠팡 직원 아님)~~

해당 링크와 게시판을 스크린샷으로 살펴보겠습니다.

링크

https://www.clien.net/service/search/board/park?sk=title&sv=%EC%BF%A0%ED%8C%A1

스크린샷

이제 코드를 살펴보겠습니다.

필요한 라이브러리를 설치하겠습니다. 웹페이지의 http 통신을 위해 requests 와 웹페이지를 파싱하는데 유용한 라이브러리인 bs4를 설치하겠습니다.

pip install requests
pip install bs4

프로젝트의 root 디렉토리에 clien_crawler.py 파일을 생성 후 아래와 같이 코딩합니다.

import os
from urllib.parse import urlparse

import requests
from bs4 import BeautifulSoup


def fetch_clien_latest_data():
    result = []

    url = 'https://www.clien.net/service/search/board/park?sk=title&sv=%EC%BF%A0%ED%8C%A1'
    response = requests.get(url)
    html = response.text
    soup = BeautifulSoup(html, 'html.parser')

    web_page_link_root = "https://clien.net"
    list_items = soup.find_all("div", "list_item symph_row")

    for item in list_items:
        # title
        title = item.find("span", "subject_fixed")["title"]

        # link
        page_link_raw = web_page_link_root + item.find("div", "list_title").find("a")["href"]
        page_link_parts = urlparse(page_link_raw)
        normalized_page_link = page_link_parts.scheme + '://' + page_link_parts.hostname + page_link_parts.path

        # specific id
        specific_id = page_link_parts.path.split('/')[-1]

        item_obj = {
            'title': title,
            'link': normalized_page_link,
            'specific_id': specific_id,
        }

        print(title)
        result.append(item_obj)

    return result

링크의 데이터를 soup에서 받아오고, 그 데이터를 파싱 후 리스로 만들고, 루프를 돌면서 title, link 및 specific id 등을 얻어옵니다. specific id는 link에서 파싱을 해서 얻어오는데 게시글에 부여되는 고유 id로 생각하시면 될것 같습니다. DB에 저장 후 계속해서 크롤링을 하게 될텐데 이미 저장된 데이터인지 판단하는 기준으로 사용됩니다.

얻어온 데이터는 item_obj에 dictionary 형태로 저장하고, 리스트로 생성해줍니다. 생성된 리스트는 리턴해서 db에 저장 할 수 있는 상태로 만들어줍니다.

파싱할 규칙은 크롬 브라우저의 '검사' 메뉴를 통해 소스를 볼 수 있으니 알맞은 규칙을 찾아서 파싱 할 수 있습니다. BeautifulSoup4에 대하여 자세히 알아보시려면 따로 구글링을 통해 찾을 수 있습니다.

파싱 메서드가 제대로 동작하는지 확인하려면 해당 메서드에 메인 메서드를 만들어서 호출해서 테스트 할 수 있습니다.

if __name__ == '__main__':
    fetch_clien_latest_data()

실행해보면 아래처럼 출력이 됩니다. 파싱 메서드에 타이틀을 출력하는 코드가 있습니다. '쿠팡' 이라는 키워드로 검색 후 나온 결과물을 그대로 보여준 것을 알 수 있습니다.

오늘 쿠팡이츠 알바뛸껄 그랬어요.ㅋㅋㅋㅋ
쿠팡맨 게임 ㅠㅠ
쿠팡, 더 힘들어 질 듯 합니다...
쿠팡에 이어팟(3.5파이버전) 16950원이네요
쿠팡 로켓배송은 제가 집 앞에 편의점 가는 것보다 빠르네요.
쿠팡 추천상품 보다가...
쿠팡 누적 적자가 3조라는군요
달려라 쿠팡맨 ost는 좋네요
어제 결제한 쿠팡 12% 캐시백 행사 아이폰이 왔습니다
전 이제 쿠팡없으면 못삽니다
자급제 아이폰11% 쿠팡 12% 캐시백에 24개월 무이자할부 떴네요
쿠팡 아이폰11취소했습니다.
미밴드4 정발(쿠팡판) 업데이트 되네요
쿠팡 아이폰 사전예약 무섭게 품절이네요
쿠팡에서 결국 맥북 질렀네요
쿠팡 아이폰이 왔는데
쿠팡 아이폰 내일 도착 확정!
쿠팡 새벽 아이폰프로맥스
쿠팡 로켓직구 쓰면서 불편했던 점
쿠팡이 판매자에게 돈이 바로 안가는지는 몰랐네요...
다른분들은 쿠팡 아이폰 일찍 받으신다는데 저는 그대로네요
쿠팡 아이뻐 내일 온데요
쿠팡 아이폰 제발 내일 ㅠㅠㅠㅠ
쿠팡 아이폰 새벽배송으로 오네요.
쿠팡아이폰이 예정보다 일찍 오네요
쿠팡 상품 가격 히스토리 / 설정가격 알림 / 상품추천 사이트를 제작해봤습니다
쿠팡 로켓프레시 배송은 사랑입니다.
쿠팡 리뷰 보다가 어떤 분이 영양제 테이블 사진을 찍어 놓았는데..
쿠팡 아이폰11 분실건 오늘 연락 안오네요 ㄷㄷ
쿠팡 로켓와우 멤버십이 또 무료체험이네요...?

하지만, 이 함수는 아직 Django에 저장하는 기능을 갖고 있지 않습니다. 따라서 코드를 조금 더 추가 해 주어야 합니다.

실행시 Trouble shooting
문자 encoding 이슈

Django 환경 불러오기

import os
from urllib.parse import urlparse

import requests
from bs4 import BeautifulSoup

os.environ.setdefault('DJANGO_SETTINGS_MODULE', "ClienCrawlingDjango.settings")
import django

django.setup()

os 를 import하고, environ을 설정 후 django를 불러와서 섿업을 하였습니다.

이렇게 추가 후 컴파일 에러가 없다면 정상적으로 Django DB에 저장할 준비가 되었습니다.

Django ORM으로 데이터 저장

이제 models에서 우리가 만들었던 BoardData를 import해 보겠습니다.

django.setup()
from crawled_data.models import BoardData

한가지 주의해야 할점은 django.setup() 이후에 호출하여야 합니다. 그렇지 않으면 django가 초기화 되지 않은 상황에서 model을 불러오려고 해서 에러가 발생합니다.

이제 DB 에 저장하는 코드를 살펴보겠습니다.

def add_new_items(crawled_items):
    last_inserted_items = BoardData.objects.last()
    if last_inserted_items is None:
        last_inserted_specific_id = ""
    else:
        last_inserted_specific_id = getattr(last_inserted_items, 'specific_id')

    items_to_insert_into_db = []
    for item in crawled_items:
        if item['specific_id'] == last_inserted_specific_id:
            break
        items_to_insert_into_db.append(item)
    items_to_insert_into_db.reverse()

    for item in items_to_insert_into_db:
        print("new item added!! : " + item['title'])

        BoardData(specific_id=item['specific_id'],
                  title=item['title'],
                  link=item['link']).save()

    return items_to_insert_into_db

크롤링한 리스트 데이터를 인자로 넘겨 받는 add_new_items라는 메서드입니다. 세 부분으로 나뉘어서 설명해보도록 하겠습니다.

    last_inserted_items = BoardData.objects.last()
    if last_inserted_items is None:
        last_inserted_specific_id = ""
    else:
        last_inserted_specific_id = getattr(last_inserted_items, 'specific_id')

처음에 BoardData 로부터 마지막에 추가된 항목을 불러옵니다. 아무런 데이터가 없다면 "" 로 초기화를 시켜주고, 그렇지 않다면 'specific_id'를 가져옵니다.

    items_to_insert_into_db = []
    for item in crawled_items:
        if item['specific_id'] == last_inserted_specific_id:
            break
        items_to_insert_into_db.append(item)
    items_to_insert_into_db.reverse()

크롤링한 리스트 데이터의 루프를 돌면서 만약 DB에 추가된 specific_id와 동일한 id를 가졌다면 바로 break를 시켜서 루프를 나옵니다. 그렇지 않다면 새로운 항목이므로 DB에 추가할 리스트에 추가를 합니다. 모든 체크가 끝난 이후에 reverse()로 리스트를 뒤집습니다. 오래된 항목부터 DB에 추가하여야 하기 때문에 오래된 항목을 리스트의 가장 앞쪽에 위치시킵니다. DB의 가장 최신 row에는 항상 최신 데이터가 오도록 합니다.

    for item in items_to_insert_into_db:
        print("new item added!! : " + item['title'])

        BoardData(specific_id=item['specific_id'],
                  title=item['title'],
                  link=item['link']).save()

BoardData라는 ORM에 데이터를 추가하는 코드입니다. save() 호출을 하면 정상적으로 DB에 추가가 됩니다.

이제 한번 실행해보겠습니다.

$ python clien_crawler.py

크롤링한 데이터의 제목과 "new item added!! : [title]" 이 쭈욱 보여지면 정상적으로 DB에 추가가 된 상태입니다.

저장된 데이터를 Django Admin에서 확인하기

관리자계정 만들기

Django는 Django Admin이라는 강력한 기능을 제공합니다.

우선 Admin 계정을 하나 생성해야 합니다. createsuperuser 명령어로 생성 할 수 있습니다.

$ python manage.py createsuperuser
Username (leave blank to use 'root'): owllife
Email address: 
Password: 
Password (again): 
Superuser created successfully.

ID 입력 후 email은 입력하지 않아도 됩니다. 비밀번호 두번 입력 완료하면 정상적으로 계정이 생성됩니다.

앱에 Admin 등록하기

Django가 어떤 앱을 admin에서 관리하도록 하려면 앱 폴더(crawled_data) 안에 있는 admin.py 파일을 수정해 주어야 합니다.

from django.contrib import admin

# Register your models here.
from crawled_data.models import BoardData

admin.site.register(BoardData)

Django 서버 실행하기

이제 manage.py 가 있는 위치에서 runserver 명령어로 장고 개발 서버를 실행해 보겠습니다.

$ python manage.py runserver

만약, 특정 port 번호로 실행시키려면 아래처럼 IP:PORT 를 마지막에 추가로 입력하면 됩니다.

$ python manage.py runserver 127.0.0.1:8080

아래와 같이 로그가 출력된다면 정상적으로 서버가 실행된 상태입니다.

$ python manage.py runserver
Watching for file changes with StatReloader
Performing system checks...

System check identified no issues (0 silenced).
November 10, 2019 - 15:48:21
Django version 2.2.7, using settings 'ClienCrawlingDjango.settings'
Starting development server at http://127.0.0.1:8000/
Quit the server with CONTROL-C.

이제 http://localhost:8000/admin/ 으로 들어가 보겠습니다.

로그인을 하면 아래와 같은 화면을 볼 수 있습니다.

이전에 생성한 crawled_data 라는 앱 모듈이 보이고 그 아래에 위치한 BoardData라는 테이블이 보입니다. Board datas라고 적힌 테이블을 선택해서 들어가보면 아래와 같이 이미 추가된 항목들을 볼 수 있습니다.

리스트가 보이고 가장 최근에 추가된 항목을 선택하면 아래처럼 추가된 데이터를 확인 할 수 있습니다. BoardData 라는 model에서 추가한 속성들의 값을 여기에서 모두 확인 할 수 있습니다.

TIP

BoardData의 리스트를 보면 이름이 BoardData object (숫자) 와 같이 보여지기 때문에 가독성이 매우 떨어집니다. BoardData model 파일을 조금만 수정하면 아래와 같이 보기 좋게 바꿀수 있습니다.

코드 수정

from django.db import models


# Create your models here.
class BoardData(models.Model):
    title = models.CharField(max_length=300)
    link = models.URLField()
    specific_id = models.CharField(max_length=15)

    def __str__(self):
        return self.title

models.py 파일을 열어서 위와 같이 __str__ 메서드를 오버라이딩 해줍니다. __str__ 메서드의 디폴트는 ClassName + object라는 값을 반환하기 때문에 위와 같이 재정의를 통하여 좀 더 보기좋게 관리자 페이지에서 읽을 수 있습니다.

참고로, models.py 파일을 수정하였지만 DB 테이블 구조가 변경되는 사항이 아니기 때문에 makemigrations나 migrate를 해 줄 필요가 없습니다.

파이썬 버전과 pip 버전 호환이 되지 않아서 발생되는 문제 해결. ImportError: cannot import name 'main'

Owl Life — Thu, 31 Oct 2019 22:38:00 +0900

Traceback (most recent call last):
  File "/usr/bin/pip3", line 9, in <module>
    from pip import main
ImportError: cannot import name 'main'

위 에러 때문에 잠깐 삽질을 하였습니다.

Pycharm IDE에 설정된 python 버전은 3.6인데 콘솔에서 패키지 설치를 위하여 실행한 명령어는 pip 로 하니, 패키지가 제대로 설치되지도 않고 설치 되었다 하더라도 위와 같은 에러가 발생하면서 더이상 실행 조차 되지 않았습니다.

python3-pip를 다시 설치 하였지만 뭔가 버전이 꼬인건지 해결이 안되어서 검색을 좀 해보니 아래 명령어로 해결하였습니다.

python3 -m pip uninstall pip && sudo apt install python3-pip --reinstall

출처 : Stackoverflow

Gradle의 root gradle file에서 멀티 프로젝트 관리. subprojects를 이용한 코드 공용화 작업.

Owl Life — Wed, 30 Oct 2019 23:32:56 +0900

안드로이드 앱 개발을 하다보면 모듈화를 위하여 "com.android.library" plugin이 적용된 여러 sub proejct들을 생성하게 됩니다. 그로 인해 build.gradle 파일이 계속해서 추가가 되고 조금만 신경쓰지 않으면 boilerplate code가 기하급수적으로 늘어나게 됩니다. 또한, 같은 외부 라이브러리를 버전만 다르게 각 모듈에서 적용하여 사용하는 경우도 발생하게 되는데 예기치 못한 컴파일 또는 런타임 에러가 종종 발생되기도 합니다.

관리 포인트가 늘어나게되면 유지보수 비용도 증가하게 되므로 최대한 중복 코드를 제거하여 중앙에서 컨트롤 할 수 있도록 빌드스크립트를 구성하여야 합니다. 본 포스팅에서는 프로젝트의 root에 위치한 build.gradle 파일을 수정하여 중복 코드를 삭제 하는 방법에 대하여 설명하고자 합니다.

예제에 사용된 샘플 프로젝트는 총 3개의 library module과 하나의 application module로 구성되어 있습니다.

common_module

view_module

usecase_module

app

module간의 의존 관계는 아래와 같습니다.

view_module과 usecase_module은 common_module에 의존하고 있습니다.

app은 view_module과 usecase_module을 의존하고 있습니다.

common_module - build.gradle

apply plugin: 'com.android.library'

println project.name + " sub project"

단 두줄로 구성되어 있습니다. plugin을 적용하고, task configuration 순서를 보기 위하여 콘솔에 프로젝트명을 보여주는 디버기용 코드입니다.

view_module과 usecase_module의 - build.gradle (동일)

apply plugin: 'com.android.library'

println project.name + " sub project"

dependencies {
    implementation project(':common_module')
}

common_module과 큰 차이는 없습니다. dependencies {}에 common_module을 의존하고 있다는 것을 나타내는 코드 한줄이 추가되어 있습니다.

app - build.gradle

apply plugin: 'com.android.application'

android {
    defaultConfig {
        applicationId "com.owllife.jenkinstestproject"
        versionCode 1
        versionName "1.0"
    }

    buildTypes {
        release {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
        }
    }
}

dependencies {
    implementation project(':usecase_module')
    implementation project(':view_module')

    implementation 'androidx.constraintlayout:constraintlayout:1.1.3'
}

application module로서 defaultConfig, buildTypes 등이 추가되어있고, 이 모듈에서만 사용하고 있는 constraintlayout lib 또한 의존성을 두고 있습니다.

각 sub module의 빌드 스크립트 코드가 매우 간결한 것을 볼 수 있습니다. 이제 root에 위치한 빌드 스크립트 파일은 어떻게 구성되어 있는지 한번 살펴보겠습니다.

buildscript {
    repositories {
        google()
        jcenter()
        maven { url "https://plugins.gradle.org/m2/" }
    }
    dependencies {
        classpath 'com.android.tools.build:gradle:3.5.1'
    }
}

subprojects {

    if (project.name == 'app') {
        apply plugin: 'com.android.application'
    } else {
        apply plugin: 'com.android.library'
    }

    repositories {
        google()
        jcenter()
    }

    apply plugin: 'checkstyle'
    task checkstyle(type: Checkstyle) {
        showViolations true
        ignoreFailures true
        configFile file(rootDir.path + "/checkstyle.xml")

        source 'src/main/java'
        include '**/*.java'
        exclude '**/gen/**'
        exclude '**/R.java'
        exclude '**/BuildConfig.java'

        classpath = files()
    }

    println project.name + " - root project"

    android {
        compileSdkVersion 29
        buildToolsVersion "29.0.2"
        defaultConfig {
            minSdkVersion 23
            targetSdkVersion 29
            testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
        }

        lintOptions {
            abortOnError false
        }
    }

    dependencies {
        implementation 'androidx.appcompat:appcompat:1.1.0'
        testImplementation 'junit:junit:4.12'
        androidTestImplementation 'androidx.test.ext:junit:1.1.1'
        androidTestImplementation 'androidx.test.espresso:espresso-core:3.2.0'
    }
}

task clean(type: Delete) {
    delete rootProject.buildDir
}

subprojects scope를 보시면 일반적으로 많이 보던 코드들이 위치한 것을 확인 할 수 있습니다.

    if (project.name == 'app') {
        apply plugin: 'com.android.application'
    } else {
        apply plugin: 'com.android.library'
    }

이 코드는 android{}와 같은 closure를 읽기 위하여 필수적으로 추가 되어야 plugin입니다.

추가하지 않으면 이런 에러가 발생하게 됩니다.

> Could not find method android() for arguments [build_cl71o7g9m073cw0qlbvvkp09h$_run_closure1$_closure5@13e29c6c] on project ':app' of type org.gradle.api.Project.

plugin 적용 이후부터는 각 sub module에서 사용중인 boilerplate code 성격을 띄는것들을 추가하면 됩니다. 위 샘플에서는 defaultConfig나 lintOptions, dependencies 등을 추가하고 있습니다.

Task Configuration 순서는 어떻게 될까?

task를 configuration하는 순서를 보면 root gradle file에서 subproject 대상 갯수만큼 호출되고, 그 이후에 각 모듈별로 configuration을 진행하게 됩니다. module layer 관점에서 common_module이 가장 상단에 위치한다고 해서 root 와 sub project를 먼저 configuration 하지는 않습니다. 참고로 알아두시면 좋을것 같습니다. 무조건 root가 우선이고 그 다음에 차례대로 sub project의 configuration을 실행합니다.

> Configure project :
app - root project
common_module - root project
usecase_module - root project
view_module - root project

> Configure project :common_module
common_module sub project

> Configure project :usecase_module
usecase_module sub project

> Configure project :view_module
view_module sub project

allprojects와 subprojects 차이점?

일반적으로 대부분의 프로젝트는 subprojects closure를 사용 하면 됩니다.

allprojects closure는 root에 해당하는 프로젝트의 build.gradle 도 함께 실행 시킨다는 의미로 사용이 됩니다.

보통 같은 모듈의 성격을 가지는 여러 library module을 하나의 folder을 만들고 그 하단에 위치시키기도 합니다. 이 때 그 새로 생성한 folder에 build.gradle 파일을 추가하는 경우는 거의 없을 것입니다. (현업에서 한번도 보지 못했고, 필요성을 느끼지 못함)

만약, 이 폴더에 build.gradle 파일을 추가하여 별도의 동작을 수행해야 한다면 allprojects closure에 추가하면 됩니다.

자세한 차이점을 알고 싶다면 권남님의 위키 페이지를 참고 바랍니다.

권남님 위키 : https://kwonnam.pe.kr/wiki/gradle/multiproject

.gitignore 가 정상적으로 동작하지 않을때 해결책

Owl Life — Wed, 30 Oct 2019 01:16:52 +0900

Android Studio로 개발하다보면 파일을 추가하거나 수정할때 .gitignore에 적용된 대상임에도 changes에 자꾸 나오는 경우가 있습니다. git의 캐시가 문제가 되는것이라서 아래처럼 terminal 명령어로 수정할 수 있습니다. git 캐시 문제이기 때문에 android studio IDE 대상 이슈가 아닌 git 사용하는 전체 프로젝트에 해당 될 수 있을것 같습니다.

~~gitignore가 git에 의하여 ignore 되고 있는 아이러니한 상황~~

git rm -r --cached .

// 변경 파일들 다시 추가 후 commit.
git add .
git commit -m "fixed untracked files"

출처 : Stackoverflow

젠킨스의 build description을 커스텀 해보자. [description setter plugin]

Owl Life — Tue, 29 Oct 2019 22:18:39 +0900

젠킨스의 빌드 히스토리에 보여지는 설명 부분을 어떻게 커스텀 하는지 알아보도록 하겠습니다.

사용 용도에 따라 다양한 정보들을 노출 시킬수 있겠지만, 본 포스팅에서는 빌드된 apk 파일명과 용량. 그리고 이전 빌드 산출물 대비 용량이 어떻게 변하였는지를 노출 시켜보도록 하겠습니다.

description setter plugin 설치

플러그인 관리 페이지에 접근 후 "Available" 탭에서 description setter plugin을 검색 후 설치합니다. 젠킨스 재시작까지 완료 하셔야 합니다.

워크스페이스 Configure

워크스페이스의 Configure 메뉴로 진입 후 execute shell에 새로운 항목을 추가해줍니다. 이미 추가된 execute shell 항목이 있다면 그 하단에 추가하여 마지막에 수행 될 수 있도록 합니다.

본 예제 사용한 샘플 스크립트를 첨부하니 참고 바랍니다.

#!/bin/bash -xe
set +x

APK_NAME="app-debug.apk"
FILE_NAME_FOR_APK_SIZE="prev_apk_size.tmp"

# 현재 빌드된 APK 사이즈 계산 (in KB)
CUR_APK_SIZE=$(ls -lk app/build/outputs/apk/debug/$APK_NAME | tr -s " " | cut -d " " -f5)
CUR_APK_SIZE_IN_KB="$(($CUR_APK_SIZE/1024))"

# 이전에 빌드된 APK 사이즈와 비교 후 차이 계산
PREV_APK_SIZE=0
DIFF_APK_SIZE_IN_KB=0
if [ -f "$FILE_NAME_FOR_APK_SIZE" ]; then
    PREV_APK_SIZE=`cat $FILE_NAME_FOR_APK_SIZE`
    PREV_APK_SIZE_IN_KB="$(($PREV_APK_SIZE/1024))"
    
    DIFF_APK_SIZE_IN_KB="$(($CUR_APK_SIZE_IN_KB-$PREV_APK_SIZE_IN_KB))"
fi
echo cur $CUR_APK_SIZE byte
echo prev $PREV_APK_SIZE byte

# 현재 APK 사이즈를 파일에 저장. (in byte)
echo $CUR_APK_SIZE > $FILE_NAME_FOR_APK_SIZE

# Description setter
echo [BUILD_DESCRIPTION] "$APK_NAME $CUR_APK_SIZE_IN_KB"KB "("$DIFF_APK_SIZE_IN_KB"KB)"

다음과 같은 과정으로 스크립트가 실행됩니다.

1. 빌드된 산출물의 apk size를 읽어옵니다. byte 단위로 가져온 후 KB로 치환해줍니다.

2. 이전에 빌드된 산출물의 사이즈가 파일에 저장되어 있다면 사이즈를 읽어온 후에 diff 값을 계산해줍니다.

3. 다음 빌드에 사용하기 위하여 현재 산출물의 사이즈는 다시 "prev_apk_size.tmp" 라는 파일에 저장시켜줍니다.

4. 빌드 히스토리에 보여줄 description을 콘솔에 출력합니다.

콘솔에 출력하는 이유는, 적용된 플러그인이 콘솔에 출력된 텍스트로부터 정규식을 통하여 조건에 해당하는 텍스트를 가져와서 그대로 빌드 히스토리에 보여주도록 되어 있기 때문입니다. "[BUILD_DESCRIPTION]"라는 prefix를 붙인 이유도 정규식에서 이용하기 위함입니다.

이제, Add post-build action 으로부터 Set build description을 선택 후 항목을 추가해줍니다.

정규식 입력란에 아래와 같이 입력해줍니다. 띄워쓰기가 맞지 않아도 제대로 값을 읽어올수가 없으니 주의하셔야 합니다.

\[BUILD_DESCRIPTION\] (.*)

Description은 몇개의 라인을 표시할것인지를 나타냅니다. \1\2\3 과 같이 사용이 가능하며 본 샘플은 한줄만 표시하기에 \1을 입력하였습니다.

저장 후 빌드를 하면 APK 사이즈의 증감을 한눈에 알아 볼 수 있습니다.

단순한 문자 뿐만 아니라 html 태그도 적용 가능한데 이 부분은 추가로 포스팅 하도록 하겠습니다.

Jenkins에 checkstyle plugin 적용하기

Owl Life — Fri, 25 Oct 2019 23:15:06 +0900

프로그래밍하면서 코드 스타일을 체크해주는 유용한 플러그인으로 많은 개발자들이 사용하고 있습니다. 본 포스팅에서는 Android Project에 checkstyle plugin을 적용 후 젠킨스에도 결과를 보여주도록 적용해보겠습니다.

Lint 그래프 아래쪽에 Checkstyle Trend가 표시되는것을 볼 수 있습니다.

차트를 클릭하면 상세 내용을 확인 할 수 있습니다.

해당 항목을 클릭하면 어떤 부분 때문에 검출이 되었는지 확인 할 수 있습니다. 본 검출 내용은 메서드 이름은 소문자로 시작하여야 하는데 대문자로 시작했기 때문에 발생된 에러입니다.

Android 프로젝트에 checkstyle 적용

프로젝트가 한개일 경우에는 app/build.gradle 파일에 적용하면 되고, 여러개의 멀티 프로젝트를 운용하고 있다면 root build.gradle 파일에 아래처럼 추가합니다. checkstyle이라는 태스크를 모든 프로젝트에 적용한다는 의미로 allprojects scope에 추가하였습니다.

apply plugin: 'checkstyle'
allprojects {
    repositories {
        google()
        jcenter()
    }

    task checkstyle(type: Checkstyle) {
        showViolations true
        ignoreFailures true
        configFile file(rootDir.path + "/checkstyle.xml")

        source 'src/main/java'
        include '**/*.java'
        exclude '**/gen/**'
        exclude '**/R.java'
        exclude '**/BuildConfig.java'

        classpath = files()
    }
}

lint와 마찬가지로 checkstyle을 커스텀하여 어떤 항목들을 검출할지 수정이 가능합니다. checkstyle.xml 이라는 파일을 생성후 프로젝트 root에 위치시킵니다. 해당 파일은 이전에 추가한 task의 "configFile file(rootDir.path + "/checkstyle.xml")" 에서 읽어옵니다.

<?xml version="1.0"?><!DOCTYPE module PUBLIC
    "-//Puppy Crawl//DTD Check Configuration 1.2//EN"
    "http://www.puppycrawl.com/dtds/configuration_1_2.dtd">

<module name="Checker">
    <module name="NewlineAtEndOfFile" />
    <module name="FileLength" />
    <module name="FileTabCharacter" />

    <module name="RegexpSingleline">
        <property name="format" value="\s+$" />
        <property name="message" value="Line has trailing spaces." />
    </module>

    <module name="TreeWalker">
        <module name="JavadocStyle" />
        <module name="ConstantName" />
        <module name="LocalFinalVariableName" />
        <module name="LocalVariableName" />
        <module name="MemberName" />
        <module name="MethodName" />
        <module name="PackageName" />
        <module name="ParameterName" />
        <module name="StaticVariableName" />
        <module name="TypeName" />
    </module>
</module>

checkstyle에서 제공하는 모든 규칙들은 아래 페이지에서 확인 가능합니다.

https://checkstyle.sourceforge.io/checks.html

실행

checkstyle task 를 실행하여 바로 결과를 확인 할 수 있습니다.

~/AndroidStudioProjects/JenkinsTestProject2$ ./gradlew clean checkstyle

> Task :app:checkstyle
[ant:checkstyle] [ERROR] /home/allsoft/AndroidStudioProjects/JenkinsTestProject2/app/src/main/java/com/owllife/jenkinstestproject/MainActivity.java:15:18: Name 'TestCheckStyle' must match pattern '^[a-z][a-zA-Z0-9]*$'. [MethodName]
Checkstyle rule violations were found. See the report at: file:///home/allsoft/AndroidStudioProjects/JenkinsTestProject2/app/build/reports/checkstyle/checkstyle.html
Checkstyle files with violations: 1
Checkstyle violations by severity: [error:1]

Jenkins에 checkstyle plugin 적용

젠킨스 홈에서 관리 페이지에 접근 후 plugin 관리쪽으로 진입합니다. 상단에서 "Checkstyle Plug-in" 으로 검색 후 설치하고 젠킨스를 재시작합니다. 그 다음 워크스페이스의 설정 화면으로 진입후 하단에 위치한 Post-build Actions 섹션에서 "Publish checkstyle ...." 항목을 선택하고 report 파일의 경로를 작성해줍니다. html은 안되고 꼭 xml 파일 형식으로만 작성하여야 합니다.

현재 기점으로 해당 액션은 deprecated 되었고, Report Violation 을 사용하여야 하는데 이 부분은 차후에 다시 다루어 보도록 하겠습니다.

Jenkins에 lint plugin 적용하기

Owl Life — Thu, 24 Oct 2019 23:19:39 +0900

정적 분석툴 중에 하나인 lint plugin을 Jenkins에 적용 하는 방법에 대하여 알아보려고 합니다.

Android 프로젝트는 기본적으로 lint task를 지원하고 있기 때문에 별도로 추가를 하지 않아도 사용이 가능합니다.

아래처럼 터미널에 명령어를 입력하면 lint task를 수행 후 report 파일까지 생성해서 결과를 제공해주고 있습니다.

이러한 report file을 jenkins에서 보여주도록 설정만 해주면 손쉽게 사용이 가능합니다.

$ ./gradlew lintDebug

> Task :app:lintDebug
Wrote HTML report to file:///JenkinsTestProject2/app/build/reports/lint-results-debug.html
Wrote XML report to file:///JenkinsTestProject2/app/build/reports/lint-results-debug.xml

Jenkins에 lint plugin 설치

jenkins에서는 plugin을 따로 설치 하여야 합니다.

Manage Jenkins 메뉴로 진입 후 Manage Plugins 화면으로 진입합니다. 그러면 상단에 몇개의 탭이 나오는데 "Available" 탭을 선택 후 "lint" 키워드로 검색을 합니다. 검색 결과에서 "Android Lint Plugin" 을 선택 후 설치를 합니다. 설치 후 jenkins server 재시작까지 한번 하도록 합니다.

Workspace에서 설정

Jenkins의 workspace에서 좌측에 있는 Configure 메뉴를 선택하여 설정 화면으로 진입합니다. gradle task 입력하는 섹션 (Execute shell) 에서 "./gradlew clean assembleDebug lintDebug" 처럼 lintDebug를 마지막에 입력합니다.

그리고 아래쪽에 있는 "Add post-build action" 메뉴 선택 후 Publish Android Lint Results"를 선택합니다.

위 스크린샷처럼 Lint files 에 lint 파일명을 입력합니다. 정확한 경로를 입력하여도 되지만 정규식 표현으로 대략적으로 입력하여도 표시가 가능하니 참고 바랍니다. 위와같이 입력 후 저장하고 빌드를 수행하면 lint task 수행 후 workspace 메인 화면에 그래프 형태로 결과를 보여주게 됩니다. 수정사항을 반영할때마다 lint 결과 갯수에 바로 반영이 되므로 지속적으로 관리하기에 용이합니다.

빌드 에러 발생시?

lint task 수행중에 이슈가 발견되어 빌드가 중지되는 경우에는 아래처럼 옵션을 설정합니다. build.gradle 파일의 android scope에 추가하면 정상적으로 빌드가 진행됩니다.

android {

    .... 중략

    lintOptions {
        abortOnError false
    }
}

lint option 설명 페이지 참고
http://google.github.io/android-gradle-dsl/current/com.android.build.gradle.internal.dsl.LintOptions.html

Lint 룰 적용

lint의 많은 rule중에서 필요한 부분만 적용하고 그 이외에는 ignore 시킬수가 있습니다.

app이나 library 프로젝트 내부의 build.gradle 파일이 위치한 곳에 lint.xml 이라는 파일을 아래처럼 작성하면 lint task가 실행될때 lint.xml 파일을 읽은 후 rule대로 처리하게 됩니다.

<lint>
    <issue id="AllowBackup" severity="ignore" />
    <issue id="AaptCrash" severity="ignore" />
    <issue id="AccidentalOctal" severity="ignore" />
    <issue id="AdapterViewChildren" severity="ignore" />
    <issue id="AddJavascriptInterface" severity="ignore" />
    <issue id="AllowBackup" severity="ignore" />
    <issue id="AlwaysShowAction" severity="ignore" />

    ... 생략
</lint>

Lint task 구조

소스 코드 파일과 lint.xml 룰을 이용하여 툴이 동작.

상세 설명 페이지
https://developer.android.com/studio/build/index.html

Jenkins Publickey 에러로 repository 접근할 때 error 발생하는 이슈 해결. (ssh 키 생성 및 등록)

Owl Life — Thu, 24 Oct 2019 00:59:08 +0900

에러 내용

Failed to connect to repository.

Permission denied (publickey).

fatal: 리모트 저장소에서 읽을 수 없습니다.

정상적으로 저장소에 접근이 가능한 경우

원인

public repository라면 url만 입력해도 바로 연동이 되지만 private repository인 경우에는 ssh key를 등록하여야 정상적으로 git 반영이 가능합니다. ssh 키 생성 및 repository에 등록하는 과정을 알아보도록 하겠습니다.

인증키 만들기

인증키는 ssh-keygen으로 생성한다.

$ cd ~/.ssh
$ ls

만약 id_rsa / id_rsa.pub 와 같은 키 쌍이 존재한다면 키 생성없이 바로 등록 과정을 거쳐도 됩니다.

// 없는 경우에는 키 생성
:~/.ssh$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/allsoft/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/allsoft/.ssh/id_rsa.
Your public key has been saved in /home/allsoft/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:KxoQ6MNVJZh3pWqUsbObfl9d4zavt6ruK2+D5jIO4q0 allsoft@allsoft-ubuntu
The key's randomart image is:
+---[RSA 2048]----+
|    o+....       |
| . o..=..        |
|. ...=..         |
|o ... +          |
| +.  +  S      o |
|  ... o  .  . o .|
|   ..+. . .. . + |
|  . +o.= +.o  . +|
|   Eooo.*o**+.o+o|
+----[SHA256]-----+

// 키 생성시 비밀번호는 입력하지 않아도 됩니다.

인증키를 메모리에 상주 시키고 키 등록

~/.ssh$ eval $(ssh-agent -s)
Agent pid 9071
~/.ssh$ ssh-add ~/.ssh/id_rsa
Identity added: /home/allsoft/.ssh/id_rsa (/home/allsoft/.ssh/id_rsa)

ssh-agent 를 이용하여 인증키를 메모리에 상주시켜두면 한번만 인증키 암호를 입력하면 다음부터는 입력하지 않아도 같은 인증키를 사용하는 모든 서버들에 접속 할 수 있습니다.

private repository의 설정에 ssh 키 등록

방금 생성한 public key를 repository의 설정에 등록합니다. 등록하면 젠킨스에서 바로 접근이 가능합니다.

본 예제의 경우에는 gitlab에서 테스트를 하였기 때문에 gitlab의 settings에서 키를 등록해줍니다.

gitlab.com의 User settings(profile) 진입 후 SSH Keys 선택

입력할 public key는 아래처럼 command로 확인 가능. 복사 해서 붙여넣기 후 저장합니다.

allsoft@allsoft-ubuntu:~/.ssh$ cat id_rsa.pub 
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC........ allsoft@allsoft-ubuntu

Jenkins Credentials 추가

jenkins 워크스페이스 설정에서 repository url 입력시 private key를 선택하도록 합니다.

- Kind에서 SSH Username with private key 를 선택

- ID 및 username는 입력하지 않음.

- Description은 키 이름 입력

- Private Key에서 직접 입력을 선택 하고 Add Key 버튼 선택 후 private key를 직접 입력합니다.

- Passphrase는 키 생성시 입력하지 않았으므로 빈칸으로 비워둡니다.

- Add 버튼 클릭

Credentials 선택

위에서 생성한 키를 선택후 잠시 기다리면 정상적으로 접근이 가능하다는 표시로 에러 문구가 사라집니다.

이제부터 정상적으로 저장소에 접근이 가능합니다.