Eunkwang Shin

시제​

• 현재: 사실, 반복
• 현재진행: 동작 강조
• 과거: 과거에 끝난 것
  • was going to: 하려고 했지만 실제론 하지 않은 일
• 과거진행: 과거에 뭘 하고 있었는지 강조
• Used to: 그랬었지~ 해오곤 했었지~ 지금은 안함
• 현재완료
  • 계속 쭉 해오고 있는 것, for/since
  • 경험 해본적이 있는 것
  • 결과 과거의 행동이 현재와 관련이 있는 것, just/already/yet
• 미래
  • will: 예측, 결정한 일
  • be going to:
    • 이미 하기로 결정한 미래의 일
    • 현재 상황을 근거로 미래에 일어날 일을 예측할 때
  • 현재진행: 구체적인 계획/약속/예약
  • 현재: 미래 사실로 시간표/일정 상의 일, 주로 사물 주어
  • be about to: 막 ~하려고 하다, 매우 가까운 미래
• 미래 진행: 미래 특정한 시점에 진행되고 있을 일을 말할 때
• 미래 완료: 미래의 특정한 시점까지는 어떤 일이 완료되었을 것이라고 말할 때
  • by the time: ~할 때쯤 으로 같이 자주 쓴다.
    • By the time the meeting starts, we won't have prepared the sales report.
    • I'll have learend a lot by the time I complete this course.

현재완료​

• ever: 지금까지 (한 번이라도)
  • Have you ever baked muffins?
• never: 해본 적이 전혀 없다.
  • I've never baked muffins.
• have been: 가 본적이 있다.
  • I've been there
  • I haven't been to Paris.
• has gone: 가고 없다.
• 경험의 횟수: once, twice, three times, four times, many times.
  • 이럴 때만 times 를 복수로 씀.
• The best ~ I've ever ~: 지금까지 내가 ~ 해본 최고의 ~
  • That is the best story I've ever heard.
  • It was the best experience I've ever had.

현재완료진행​

• 과거에서 시작해서 지금도 진행 중인 일
• for, since, how long
  • since: 특정 시점 필요 (since noon, since May, since 5 o'clock)
• 과거에서 시작해서 진행되어 오다가 방금 전에 끝난일이 지금까지도 영향을 미치고 있을 때
  • Your eyes are red. Have you been crying?
• 진행으로 못 쓰는 동사들: 동작을 나타내지 않음
  • know, remember, understand, believe, agree
  • want, need, love, like, hate,
  • own, possess, belong, contain

미래​

• 시간, 조건 뒤엔 현재가 온다.
• when, while, before, after, until, if

조동사​

• Can: 동사에 강세
• Can't: Can't 에 강세
• Can I: 해도 될까요?
• Can you: 해줄래요?
  • Could: 능력/허락/가능성/추측
  • was/were able to: 특정 상황에 실제로 성공적으로 어떤 일을 해냈다.
    • Our best player didn't play, but we were able to win the game anyway.
  • have/has been able to ~: 특정 시점 이후로 쭉 할 수 있다.
• Must: 확실한 추측, 규정, 규칙
• Have to: ~해야한다
  • don't have to: 할 필요가 없다.
  • didn't have to: 할 필요가 없었다.
  • Did ~ have to
  • will/might have to
• S should R: R 하는 것이 좋겠다.
• Should I: 하는 것이 좋을까요?
  • I think ... should
  • I don't think ... should
• Would you: 해주시겠어요?
• Would you like N: N를 드릴까요?
• Would you like to R: R 하실래요?
• I would like N: N을 주세요.
• I would like to R: R를 하고 싶어요.

could​

• could belong to S.O.: ~의 것일지도 모른다.
• could R: ~할지도 모른다.
• couldn't R: ~할리 없다. (~하는 것이 사실상 불가능하다.)
• could have p.p.: ~했을지도 모른다. 할 수도 있었지만 하지 않았다.
• couldn't have p.p.: ~했을 리 없다. (사실상 불가능했음.)
  • She finished all of her work in just one day. She couldn't have done it alone.

might​

• might R: ~할지도 모른다.
• might not R: ~하지 않을지도 모른다 (그러나 ~할 가능성도 있다)
• might have p.p.: (과거에) ~했을지도 모른다.
• might not have p.p.: (과거에) ~하지 않았을지도 모른다. (했을 가능성도 있음)

should​

• should: ~하는 것이 좋겠다.
• should I/we ~?: ~하는 것이 좋을까요?
• should have p.p.: (과거에) ~했어야 했다. (그러나 하지 않았다.)
• shouldn't have p.p.: (과거에) ~하지 말았어야 했다. (그러나 했다.)
• We should attend: 참석하는 것이 좋지만 반드시 참석해야하는 건 아님
• All employees must attend: 반드시 참석해야함.

had better​

• you'd better, we'd better: ~하는 것이 좋겠다. (강한 충고)
• had better not: ~하지 않는 것이 좋겠다.
  • You'd better not sit there.
• had better: 어떤 일을하지 않으면 좋지 않은 결과가 생길 것
  • Tickets will be sold out soon. You'd better buy some today.
• should: 반드시 해야하는 건 아니지만 어떤 일을 하는 것이 좋겠다는 의견
  • You should buy those tickets. The seats are closer to the stage.

수동태와 조동사​

• will/can/must + be + p.p.

의문문​

• Which: 제한적으로 주어진 몇 가지 중 선택, 어떤~
• What: 선택 제한이 없는 경우, 무엇~ 몇~
• Where ~ from?: ~ 는 어디에서 왔나요?
• How be동사: ~ 은 어떤가요?
• How 형용사/부사: 얼마나 ~
• Be 동사 뒤에 오는 건 보어, 목적어 아님.

What​

• What ~ for?: ~은 무엇을 위한 건가요?, 뭐 때문에 ~하나요?
  • What's this button for?
  • What did you hit me for?
  • What was the cake for?
• What ~ like?: ~은 어떤가요?
  • What is your boss like?
  • What is it like?
  • What was your first date like?

동명사와 to부정사​

• ~ 는 것, ~ 기
• 주어는 동명사만
• Enjoy 는 동명사가 따라옴

동명사만 따라올 수 있는 경우​

• enjoy
• finish
• keep
• mind
• avoid
• give up
• practice
• suggest

to부정사만 따라올 수 있는 경우​

주로 미래: 기대, 소망, 계획, 제안

• want
• need
• hope
• expect
• decide
• plan
• promise
• offer
• choose
• ask
• learn
• refuse

둘 다 오는 경우​

• like
• love
• prefer
• hate
• start
• begin
• continue

의미가 달라지는 경우​

• stop
  • -ing: ~ 하는 것을 멈추다
  • to R: ~ 하려고 하던 걸 멈추다
• try
  • -ing: 시험삼아 ~ 해보다
  • to R: ~ 하려고 노력하다

사역동사​

• have/make/let + 사람 + R: ~ 가 ~ 하게 하다.
• help + 사람 + R: ~ 가 ~ 하는 것을 돕다.

to부정사​

• ~ 하기 위해 (in order to R), 추가적으로 덧붙힐 때
• N + to R: ~ 할 N

수​

U​

• a glass of water
• music
• snow
• sugar
• air
• time
• money
• news
• a cup of coffee
• a loaf of bread

예외​

단복수 같은 단어​

• a/some fish
• a/two sheep
• a/many deer

항상 복수​

두 개의 부분이 모여서 하나의 시물을 이루는 경우

• pajamas
• scissors
• jeans
• shorts
• glasses
• pants
• headphones

위의 명사의 복수형은 a pair of/two pairs of.

관사​

• a/an: 특별히 정해지지 않은 막연한 사람 또는 사물 하나
• the: 어떤 사람, 사물을 가리키는지 명확할 때, 특정 사람 또는 사물을 말할 때
  • 어떤 대상에 대해 처음 말할 때는 a/an, 반복할 때는 the
  • I got an e-mail from S.O. The e-mail was about today's meeting.

The​

필수​

• 세상에 하나 밖에 없는것: the world, the sun, the moon, the earth
• 자연환경: the sky, the sea, the ocean
• 국가/도시 등에 하나 밖에 없는 것: the army, the police, the government
• 방송, 매체: the radio, the internet
• 악기를 연주한다고 할 때 악기 이름 앞에: the guitar, the piano
• 특정 장소 갈 때
  • go to the movies
  • go to the station
  • go to the bank
  • go to the theater
  • go to the airport
  • go to the post office
• in the past, in the future
• the same, the only, the next, the last

사용 안하는 경우​

• 운동: basketball, football, tennis
• 과목: biology, history, marketing
• 식사: breakfast, lunch, dinner
• 집에 있는 경우: go home, at home
• 출퇴근: go to work, at work

비인칭 주어​

• 시간을 말할 때: It's 5 o`clock.
• 날짜를 말할 때: It's August 8.
• 요일을 말할 때: It's Friday.
• 날씨를 말할 때: It's rainy today.
• 거리를 말할 때: It's about 10 kilometers.
• 계절을 말할 때: It's almost spring.

소유격​

• I my mine
• We our ours
• You your yours
• He his his
• She her her
• They their theirs
• 소유격 뒤에 명사를 쓰지 않음.
• 관사 없음.

재귀대명사​

• by -self: 혼자, 스스로: I've lived by myself since 2015.
• Make yourself at home: 편히 쉬세요.

one​

• 앞서 말한 명사를 다시 말할 때 명사 대신 사용: one, ones
• a(n)/the + ADJ + one
• some/the + ADJ + ones
• Which one(s) ~?: 어느 것(들) ~?

한정사​

some, any​

• some, any: 사람 또는 사물의 불특정한 수나 양에 대해 말할 때 명사 앞
• some: 주로 긍정문, yes를 기대하는 권유/요청하는 의문문
• any: 주로 부정문, 의문문
• someone/somebody, anyone, something, anything, somewhere, anywhere: 누군가, 무언가, 어딘가란 의미로 정확히 알 수 없는 사람, 사물, 장소에 대해 말할 때
• someone, something: 주로 긍정문, 권유/요청하는 의문문
• anyone, anything: 주로 부정문, 의문문

no​

• ~ 이 없다
• no + N = not ~ any + N = none
  • I have no questions. = I don't have any questions.
• none: 대명사라 명사와 함께 사용하지 않음.
• no one/nobody, nothing, nowhere: 아무 ~ 도 ~ 않다.

many, much​

• many + [C] PL: 많은 ~, 긍정문, 부정문, 의문문
• much + [U]: 많은 ~, 주로 부정문, 의문문
• 둘 쓰는거 헷갈리므로 회화에서는 a lot of, lots of 활용하는 게 좋음.
• 대명사로도 사용 가능
  • She grows many.
  • There isn't much.
  • You already have a lot.

few, little​

• a few + [C] PL
• a little + [U]
• few + [C] PL: 거의 없는, 부정문
• little + [U]: 거의 없는, 부정문
• A few people came: 몇 명의 사람들이 왔어.
• Few people came: 거의 안 왔어.
• I have a little time: 약간의 시간이 있어.
• I have little time: 시간이 거의 없어.
• 대명사로도 사용 가능

all, every​

• 모든 ~
• all + [C] PL / [U]
• every + [S]
• all + day, week, month: ~ 종일, ~ 내내
• every + day, week, month: ~ 마다, 매 ~
• everyone/everybody, everything, everhwer: 모든 ~ (사람, 사물, 장소)

Both, either, neither​

• both + [C] PL: 둘 다, 두 ~ 모두
• either + [S]: 둘 중 아무 것이나 하나, 두 ~ 중 아무 것이나 하나
• neither + [S]: 둘 다 아닌, 두 ~ 모두 아닌

all of, most of, some of, none of​

• all of: 전부
• most of: 대부분
• some of: 약간
• none of: 없음
• all/most/some/none of: 특정한 대상에 대해 한정적으로 말할 때
  • the/my/these + N
  • it/us/you/them
  • all of the people --- All people
  • most ot these cars --- Most ccars
  • some of the songs --- some songs
  • none of the books --- No books
• all/most/some/no + N: 일반적인 대상에 대해 말할 때
• both/either/neither of
  • the/my/these + [C] PL
  • us/you/them

지각동사​

• 2형식, 보어(형용사) 필요
• look + ADJ: ~해 보이다
• smell + ADJ: ~한 냄새가 나다
• sound + ADJ: ~하게 들리다
• taste + ADJ: ~한 맛이 나다
• feel + ADJ: ~하게 느끼다

부사​

• 형용사 앞에서 꾸민다.
• 동사 앞 뒤에서 꾸민다.
• ly 패턴이지만 형용사인 것
  • friendly
  • lovely
  • silly
  • ugly
  • lonely
• 형용사는 사람이나 사물이 어떠한지
• 부사는 행동이나 일이 어떻게 일어나는지

형용사면서 부사인 것​

• late: It's late / I got home late.
• long: You have long hair / It doesn't take long.
• hard: He is a hard worker / The baseball team is practicing hard.
• fast: Her car is fast / She talks fast.
• early: I had an early breakfast / Nicole arrived early for her interview.

빈도부사​

• always, usually, often, sometimes, rarely, never
  • rarely, never 는 부정문
• 일반 동사 앞, be동사 뒤, 조동사 뒤, have/has 와 p.p. 사이

too​

• too + ADJ/ADV
• too + ADJ + for + S.O.: ~ 에게 너무 ~ 한
• too + ADJ + to R: ~ 하기에는 너무 ~ 한
• too many + [C] PL: 너무 많은 ~
• too much + **[U]: 너무 많은 ~
• 대명사로도 사용 가능: I spent too much last month.

enough​

• ADJ/ADV + enough: 충분히 ~ 한/ ~하게
  • ADJ + enough + for + S.O: ~ 에게 충분히 ~ 한
  • ADJ + enought + to R: ~ 하기에 충분히 ~ 한
• enough + [C] PL / [U]: 충분한 ~
  • enough + N + for + S.O: ~ 에게 충분한 ~
  • enough + N + to R: ~ 하기에 충분한 ~
• 대명사로도 사용 가능: I have enough.

so​

• so many + [C] PL
• so much + [U]
• There were so many. / I've learned so much from him.

비교​

• 일반적으로 형용사/부사 뒤에 -er
• 비교급 + than ~: ~ 보다 더 ~한 / ~ 하게
• 긴 단어 (3음절 이상): more ADJ/ADV
• 불규칙
  • good / better
  • bad / worse
  • far / farther

최상급​

• 일반적으로 형용사/부사 뒤에 -est
• 2음절 이상 앞에는 most
• 명사 없이 최상급만 사용하는 것도 가능: I'm the youngest in my family, That's the cheapest in the store.

as - as​

• as + ADJ/ADV + as: ~ 만큼 ~ 한 / ~ 하게
• not as + ADJ/ADV + as: ~만큼 ~하지 않은 / ~ 하지 않게
  • 비교 위치 바꿔서 비교급 + Than 도 가능
• as ~ as possible: 가능한 한 ~ 하게

전치사​

장소 전치사​

at​

• 직장, 학교 등: at work, at home, at school, at church, at the doctor's (office), at somebogy's (house)
• 역, 공항: at the station, at the airport
• 행사, 공연, 경기: at a party, at a concert, at a baseball game

in​

• 하늘, 대양 등 자연환경: in the world, in the sky, in the ocean
• 책, 사진 등 인쇄물: in a book, in a picture, in a newspaper
• (어떤 장소에서) ~하는 중인: in bed, in the hospital,, in prison, in jail
• in the car, in the taxi

on​

• 거리: on 2nd Avenue, on Main Street
• 층: on the first floor, on the 3rd floor
• 교통수단: on the train, on the bus, on the plane

방향 전치사​

• form
• to
• up
• down
• into
• out of
• over
• under
• through
• across
• along
• around
• on
• off: ~에서 (떨어져)
• past: 지나서, 지나친 것은
• toward: ~쪽으로

시간 전치사​

at​

• 시각: at 10:30, at noon, at 3 o'clock
• 식사: at breakfast, at lunch, at dinner
• at night

on​

• 요일: on Wednesday, on Friday night
• 평일, 주말: on weekdays, on a weekday, on weekends, on the weekend
• 날짜, 기념일: on May 21, on my birthday, on our anniversary

in​

• 월, 계절: in January, in spring, in the summer
• 세기, 연도: In the 19th century, in 2018
• 오전, 오후, 저녁: in the morning, in the evening

during​

• 언제 일어났는지를 말할 때

for​

• 얼마나 오래 계속되었는지를 말할 때
• p.p. 와 많이 씀

in​

• in + 기간: ~ 후에
• in 10 minutes, in two hours

within​

• within + 기간: ~ 이내에
• within 15 minutes, within four days

since​

• ~ 부터 (계속)
• 특정 시점부터 어떤 행동이나 상황이 계속 될 때
• p.p 와 많이 씀

by​

• (늦어도) ~ 까지
• 늦어도 정해진 시점까지 어떤 행동이나 상황이 끝난다고 할 때

until​

• ~ 까지 계속
• 특정 시점까지 어떤 행동이나 상황이 계속된다고 할 때

-ing​

• 전치사 뒤 -ing
• without saying
• about working
• be good at singing
• by showing

형용사 전치사 패턴​

• about
  • excited about
  • sorry about
  • sure about
• at
  • angry at
  • mad at
  • good at
  • suprised at
• for
  • famous for: ~으로 유명한
• from
  • different from
• in
  • interested in
• of
  • afraid of
  • full of
  • proud of
  • short of: ~이 부족한
  • tired of: ~에 질린, sick and tired
• to
  • married to: ~와 결혼한
  • simillar to: ~와 비슷한
• with
  • busy with: ~로 바쁜
  • careful with: ~을 주의하는
  • familiar with: ~에 익숙한

동사 전치사 패턴​

• about
  • know about: ~에 대해 알고 있다
  • talk about
  • think about
  • worry about
• at
  • look at
  • shout at: ~에게 소리치다
  • work at
• for
  • apply for: ~에 지원하다
  • ask for: ~을 요청하다
  • look for: ~을 찾다, ~을 구하다
  • search for: ~을 찾다
  • wait for: ~을 기다리다
• on
  • deponed on
  • spend ... on: ~에 (돈, 시간) 을 쓰다
• to
  • belong to: ~의 것이다, ~에 속하다
  • happen to: ~에게 일어나다
  • listen to
  • talk to: ~에게 말하다
  • write to: ~에게 편지를 쓰다
• 🚫
  • answer: ~에 답하다
  • call: ~에 전화하다
  • discuss: ~에 대해 논의하다
  • reach: ~에 도착하다, ~에 닿다

구동사​

• on
  • get on: ~에 타다
  • hold on: 기다리다
  • try on: ~을 입어보다, ~을 써보다
  • turn on: ~을 켜다
• out
  • eat out: 외식하다
  • get out of: ~에서 내리다
  • go out: 밖으로 나가다, 외출하다
  • hand out: ~을 나눠주다
  • take out: ~을 꺼내다, ~을 빼다
• up
  • clean up: ~을 청소하다
  • get up: 일어나다
  • wake up: 깨어나다, ~을 깨우다
  • pick up: (전화기 등)을 들다, ~을 사다
• 대명사를 목적어로 쓰는 경우는 동사와 on/off/up 등의 사이에 쓴다.
  • take if off
  • clean them up
• 나머지 경우는 두 패턴으로 사용 가능
  • turn your phone off
  • turn off your phone

접속사​

• 문장에 명사를 덧붙힐 때: 전치사
• 동사를 덧붙힐 떄: to부정사
• 문장을 덧붙힐 때: 접속사
• because + 문장, because of + 명사
• while: ~하는 동안
• when, while 다음에 미래의 일을 말할 때에는 미래 시제가 아니라 현재 시제
  • What do you want to be when you grow up?
  • It'll be warm while we are on vacation.
• before, after 뒤에 명사 또는 -ing 가능
  • before midnight.
  • before signing it.
  • after dinner?
• since: ~ 이후로 지금까지, 이래로
• until: ~할 때까지 (계속)
  • until 다음에 미래의 일을 이야기할 때는 현재 시제 사용
  • Please don't leave your seat until the bus stops.
• since, until 뒤에 명사 가능
  • since thier wedding.
  • until next Thursday.

가정​

• if 현재, will/can + R: ~하면 ~할 것이다.
  • 일어날 가능성이 있는 경우
• if 과거, would/could + R: 만약 ~한다면 ~할 텐데
  • 가능성이 없는 경우
  • 이 경우 were 를 선호함
  • If I were, If she were, If Jerry were

관계대명사​

주격​

• 뒤에 동사가 나오면 주격
• who/which/that

목적격​

• I love the food. she made it
  • I love the food which she made.
  • I love the food she made.
• 뒤에 주어 동사가 나옴
• 생략 가능 (관계대명사를 주어로 쓰지 않는한)

there​

• There + be동사: ~이 있다
• There was/were: ~이 있었다.
• There have/has been: ~가 있던 적이 있다.

4형식 동사​

• give: ~에게 ~를 주다
• make: ~에게 ~를 만들어주다
• send: ~에게 ~를 보내다
• show: ~에게 ~을 보여주다
• buy: ~에게 ~을 사주다
• teach: ~에게 ~을 가르치다
• give/send/show/teach + 사물 + to + 사람
• make/buy + 사물 + for + 사람 (정석적인 느낌)

권유​

• Let's + R: (함께) ~ 하자
• Let's not + R: ~하지 말자

감탄​

• How + ADJ
• What (a/an) + ADJ + N

말 전달​

• said that + 과거
• told 사람 that + 과거

동의​

긍정​

• too: 긍정문
  • I do too.
  • I have too.
• So + V + S: ~도 역시 ~하다.
  • So was I.
  • So did we.
  • So can his brother.

부정​

• either
  • He wasn't either.
  • I haven't either.
• Neither + V + S: ~도 역시 ~하지 않다.
  • Neither do I.
  • Neither have I.

Read replica​

• Support for Read Replicas #172 이슈로 열려있어서 없는 줄 알았다.
• prisma/prisma-read-replica-middleware 미들웨어의 형태로 제공된다.
• 예시: prisma/middleware-examples/prisma-read-replica-middleware

Data sources​

• schema.prisma 파일엔 오직 하나의 datasource 열만 가지고 있을 수 있다.
• 데이터 소스가 바뀌는 경우 migration.lock 파일 삭제 후 마이그레이션부터 다시 실행해야한다.

Polymorphism​

• Support for Polymorphic Associations #1644 현재로선 지원 계획이 없어보인다.
• 다형성 관계는 정규화에서는 필요하지만 비정규화하여 열에 정보를 추가한다.

개요​

• 한 때 redux 로 지친 상태관리를 해결하기 redux-saga 가 멋져보였고, 그 다음엔 원자 상태들의 조합이 그 해결방법으로 보였다.
• 그래서 recoil 을 주로 사용했지만, query 나 swr를 사용한다면 로컬 UI 상태를 관리하는데에 그렇게 복잡한 기능이 필요하지 않다.
• recoil 은 메타에서 버그의 수정만 되는 거의 버려진 프로젝트로 보인다. discussion#2171
• 어차피 로컬 UI 상태는 pub/sub 패턴을 가지고 있기만 하면 된다.
• 2023년의 상태관리 라이브러리의 우승자는 zustand 로 보인다.
  • 이벤트/메세징 기반 시스템을 구성한다면 Flux 패턴을 가진 해당 라이브러리를 사용하는 게 맞다.
  • 프론트엔드의 모든 기능을 액션 기반으로 동작하게 하여 에디터를 개발하던가 채팅시스템에서부터 기능호출 요청을 받아 연동한다던가하는 작업이라면 말이다.
• 하지만 일반적인 유스케이스에서는 계단식 폼, 뱃지, 모달 등을 제외하면 Flux는 과하다.
• 혼자 개발하는데 백엔드와 프론트엔드를 분리하고, Local, Dev, Stage, Prod 스테이지를 분리하면서 DB, 스케쥴러, 큐, API, SSR 스택도 모두 가져가려는 듯한 욕심이다.

atom​

• 번역, 리액트 상태 관리의 새로운 흐름을 보자.
• 원자 단위면서 pub/sub, derived 가 가능하면 된다.
• derived state 를 사용하는 것 또한 id 별로 새로운 상태가 필요한 경우가 아니라면 거의 없었다. 데이터로는 이미 query 가 그 역할을 하고 있다.
• 아토믹 디자인, 아토믹 상태관리는 필수가 되었다.
• 많은 개발자가 비동기적으로 개발하는 상황에서는 어떤 파일이 아톰인지, 뭘 위한 아톰인지를 기록하는 게 중요했다.
• *.atom.ts 파일 서픽스와 *State 변수명 서픽스를 갖게 했다.

valtio​

• jotai/atom, Recoil/atom 모두 아톰기반의 상태를 관리하고 상태를 전파한다.
• valtio/proxy 는 Proxy와 Reflect를 사용해 같은 기능을 구현했다.
• Results for js web frameworks benchmark를 참조해보면 메모리 관리가 최악은 아니다.
• zustand, jotai, valtio 모두 pmndrs 커뮤니티에서 다루는 오픈소스이고 같은 사람이 컨트리뷰터, 메인테이너이다.
• valito/discussion#128 에서의 그의 의견처럼 그냥 작동한다.
• valito/issues#141 Redux, Redux-saga 로 1년, Mobx POC, Recoil 로 2년을 보낸 나에겐 너무나 공감이 되는 코멘트였다.
• 당분간은 여러 프로젝트를 만들어보면서 모두 이 상태관리 라이브러리를 사용해보려고한다.

프로그래머​

프로그래머라는 직업은 뭘까?

• 구분하기 좋아하는 사람들은 코더, 디벨로퍼, 엔지니어로 부를 것이고
• 모르는 사람에겐 돈을 많이 벌게 보이거나, 달라는대로 돈을 줘야하는 직업일 것이고,
• 고용주에겐 mechanic 으로 보일 것이다.

나에게 이 직업은 뭘까?

• 단기기억이 장기기억으로 전환되는 시점에 불현듯 모든 걸 해결할 아이디어가 생각나 키보드를 잡거나
• 경사하강법에 스스로를 던져 아침 새소리가 들릴 때까지 의자에서 일어나지 못하거나
• 코딩이 너무 하고 싶은데 교양과목만 수강해야해서 가질 않았던 전공일 것이다.

요즘 나는 이렇게 이야기를 하고 다닌다.

전 인터넷에 집 짓는 사람이에요.

• 프론트엔드요? 그거 인터리어하는 거에요.
• 백엔드요? 그거 공구리 치고 내장공사 하는 거에요.
• 데브옵스요? 그거 땅파고 철근 박는 거에요.
• 보안이요? 그거 단지 내에 못 들어오게 하는거에요. 복도식 요즘 싫어하잖아요.

프로그래밍은 현실세계의 개념들을 차용해 사람이 하던 걸 자동화하기 위함인데, 이걸 깨닫는데까지 너무 오래 걸린 것 같다.

이제야 왜 많은 교수님들이 현업에서는 짬이 찰수록 기본기가 중요하다. 라고 침이 마르게 이야기를 했는지 알 것 같다.

프로그래밍​

GPT로 모든 게 다 될 것 같은 시대에 프로그래밍 스킬이 중요할까?

내 대답은 아니오였다. 서비스의 아이디어가 기술 스택보다 중요한 시점이 왔다. 클로드 섀넌을 처음 듣는 사람들도 서비스를 만들 수 있게 되었고, 그 코드를 배포할 수 있는 엣지 컴퓨팅이 성행한다.

이렇게 가면 언젠가 무너질거에요 라고 설득할 수 없다. 무너지고 나서 이렇게 될 거라고 했잖아요 라고 불난 집에 기름을 부울 수도 없다.

사회 분위기가 더 그렇게 만들고 있다.

기술 스택​

모든 기술은 트레이드오프이다.

새로운 것은 항상 큰 비용이 발생한다. 구성원의 숙련도와 유지보수의 관점에서 바라봐야한다.

난 여긴 학원이 아니야, 새로운 걸 쓰고 싶다면 개인 시간을 써서 일주일 안에 프로토타입을 보여줘. 라고 말하지만, 지금 누굴 위해 공부하고 있는데 라고 생각하는 사람도 태반이다.

소프트웨어 공학이 중요한 이유이다.

이상향​

그렇다면 내가 싫어했던 건 뭘까, 부실공사인지도 모르는 건 괜찮다. 모를 수도 있지.. 하지만 부실공사라 말하지 못 하게 하는 건 내 몸에 과부하를 준다.

스트레스를 받지 않기 위해서 이상향 체크리스트를 관리하려고 한다.

• 코드 오너 기능이 있는가? 특정 코드를 수정하면 파일별 오너에게 코드리뷰를 받을 수 있는 문화 조성이 되었는가?
• 코드 리뷰의 평균 코멘트 수는 어느정도 되는가?
• 브랜치 전략은 어떻게 되는가?
• 유닛테스트가 파이프라인에서 실행되는가? 그렇다면 커버리지는 몇 퍼센트인가?
• 실제 데이터 기반으로한 통합 테스트가 파이프라인에서 실행되는가? 그렇다면 통합 테스트에 포함하는 기준은 무엇인가?
• E2E 테스트가 주기적으로 실행되는가? 그렇다면 관리 주체는 누구인가?
• 테스트 드리븐으로 가기위해 케이스를 구현할 수 있는 시간을 충분히 주는가?
• 외부 요인에 대한 카오스 테스트를 진행하는가? 재해복구에 대한 필요성을 알고 있는가?
• 오픈소스의 관리는 어떻게 하는가? 소프트웨어의 버전 관리는 특정 사이클로 돌아가고 있는가?
• 도커 파일과 디플로이먼트를 개발자가 직접 관리하는가? 그렇지 않다면 관리 주체는 누구인가?
• Private network 구성을 위한 지원을 시스템팀으로부터 받을 수 있는가? 그렇지 않다면 VPC를 구성가능할 수 있는 환경이 제공되는가?
• 코드의 퀄리티 유지를 위해 기계적으로 어떤 것을 돌리고 있는가? 린트와 정적분석 등을 진행하는가?
• 장애 발생시 해당 장애를 모두에게 공개하고 장애보고서를 작성하는가?
• 구성원 모두가 서비스에 대해 오너쉽을 가지고 있는가?
• 대표하는 서비스의 SLA가 어느정도 되는가? OOM 장애 빈도 또는 500번대 장애 빈도가 어느정도 되는가?
• SLA가 인사고과의 표준이 되는가?
• 오너의 방향성이 모든 구성원에게 공개되는가?
• 데이터 기반의 의사결정이 진행되는가? 로그 수집을 위한 툴은 어느 것을 사용하고 있는가?
• 로깅 포맷은 Open Telemetry로 표준화 되어있는가? 그렇지 않다면 어떤 포맷으로 관리하고 있는가?
• 웹 메트릭을 수집하고 있는가?
• A/B 테스트로 기능 도입이 가능한 기반이 있는가? 그렇지 않다면 기획의 인사고과는 어떻게 하고 있는가?
• 디자인시스템을 사용하고 있는가?
• 스토리북을 같은 레파지토리 내에 관리하고 있는가?

개요​

• Yarn berry 가 최고라고 유행이 돌았다.
• 써본 결과 문제가 상당히 많았고, 결국 pnpm 을 선택하는 이유이다.

문제점​

zipfs​

• 패키지를 모두 저장하고 디프도 모두 기록된다. 레파지토리 사이즈를 올리는 주범이다. 1GB 미만으로 이미지 관리가 어렵다.
• typescript 가 올라가는 경우 yarn berry 버전을 올려줘야한다. 타입스크립트의 최신 문법을 바로 사용하고 싶으나 따라갈 수가 없다.
• typescript, eslint, prettier 를 올릴 때마다 yarn dlx @yarnpkg/sdks vscode로 실행스크립트를 업데이트 해줘야한다.
• 20명 이상의 프론트엔드 개발자가 붙어야하는 프로젝트에서는 이를 일일히 강제하기가 어렵다.
• 패키지 내부 소스를 잠깐 수정해서 테스트해보는 것은 불가능하다.

opensource​

• turbo 와 같은 모노레포 툴과, prism 과 같이 postinstall 훅이 걸려있거나, create-* 과 같이 프리셋을 구성하는 환경은 node_modules 를 직접 참조한다.
• 실행조차 안 되는 경우가 많은데, 그러면 각 레포의 열려있는 이슈를 기다려야한다. yarn berry 의 pnp 스크립트를 분석하려고 쓰는건 아니니까.
• 이럴 경우 nodeLinker를 주고 yarn 1 버전을 쓸 때와 똑같이 사용을 해야하는데, 아무런 어드밴티지가 없다.

workspaces​

• yarn workspaces 기능은 멋지고 yarnpkg/berry 에 그 완벽한 예시가 있다.
• 그러나 node.js 라이브러리만을 개발할 때만 멋지다. 프론트엔드용 라이브러리는 번들러가 필요한데 그 레퍼런스가 없다.

벤치마크​

• 벤치마크 성적은 데일리로 Pnpm 에서 관리한다.
• 파이프라인 캐시랑 락 파일 켜면 감수할만한 느림이다. 일회성 느림이지 요청/응답에 대한 느림이 아니니까 어차피 프로브로 처리 가능하다.

결론​

• yarn berry 의 플러그인 기능들은 멋지지만, 의존성관리에 스트레스가 더 쌓인다.

개요​

• 이제는 질문을 어떻게 하느냐와 그 결과가 맞는지 틀린지 판단을 빨리하는 사람이 살아남을 것 같다.
• 개발 관련된 팁 말고 현장에 바로 쓸만한 레파지토리들을 정리해본다.

aicommits​

• Nutlope/aicommits: 커밋 자동화
• #32 Add support for conventional commits가 해결되면 바로 사용할 예정
• 개인적으로는 아래 프롬프트를 바꿔줘야할 것 같은데, 어떻게 개선할지도 궁금하다.
• #177 feat: enable Conventional Commits standard as flag 곧 머지될 것 같다.

const promptTemplate =
  "Write an insightful but concise Git commit message in a complete sentence in present tense for the following diff without prefacing it with anything:";

• #81 Quick improvement suggestion: Reduce diff size with --ignore-all-space도 흥미롭다.
• Openai API가 토큰 수로 과금이 되니 최대한 디프를 줄일 예정인듯 하다.

node chatgpt​

• transitive-bullshit/chatgpt-api
• openai: docs
• completionParams 를 적절하게 활용해줘야할 것 같다.
• 여러 서드파티를 확인해봤지만 temperature를 1로 주는 경우는 없었다.

const completionParams = {
  temperature: 0.7,
  top_p: 1,
  frequency_penalty: 0,
  presence_penalty: 0,
};

tiktoken​

• openai API를 사용하기위해 정확한 토큰 수를 구해야할 수도 있다.
• openai/tiktoken을 사용해야하지만 파이썬이다.
• dqbd/tiktoken 이미 벌써 노드 래퍼가 나왔다. 3.5 터보도 지원한다.

import { encoding_for_model as encodingForModel } from "@dqbd/tiktoken";

const encoder = encodingForModel("gpt-3.5-turbo");
const tokenLength = encoder.encode("YOUR_CHAT").length;

chatgpt-retrieval-plugin​

openai/chatgpt-retrieval-plugin

• .well-known 경로에 ai-plugin.json 이 manifest.json 의 역할
• 같은 경로의 Openapi.yaml 이 엔드포인트 명세
• 인증은 none | user_http | service_http | oauth 네 종류
• 간단한 서비스는 service_http 정도로 충분해보임, user_http 는 고객이 API key 를 입력해야하고, oauth 는 search:read 와 같은 권한 추가 필요.
• 문서 유사도 비교를 위해 벡터 DB 를 사용하는 것으로 보이나, Node.js 의 마땅한 래퍼가 없어서 레디스로 구현하면 될듯, 하지만 Redisearch 모듈은 필요.
  • datastore/providers/redis_datastore.py
  • services/openai.py

백년허리​

운동하다가 디스크가 고장나고 선물받았는데, 고장나기 전에 많은 분들이 읽어보면 좋을 것 같다. 그랬다면 L5-S1 사이 디스크가 나오기 전에 좋은 자세로 임했을텐데 아쉽다.

전반적인 내용은 척추위생을 지키기 위한 백년허리의 독후감이다.

진단​

• 척추: 경추, 흉추, 요추, 천추, 미추
  • 경추와 요추는 앞으로 휘어지는 경추전만, 요추전만 곡선 형태를 보인다.
• 허리통증의 주인공은 디스크 손상
• 디스크: 수핵, 섬유륜, 종판
  • 후방 섬유륜과 종판이 주로 손상
• 근육은 찢어진 디스크를 보호한다.
  • 디스크가 찢어질 때 근육이 굳는거는 디스크를 보호하기 위한 방어기재
  • 요통은 디스크의 구조신호
• 신전자세가 요추전만이다.
• 건강한 디스크가 요추전만을 곡선을 만들고 요추전만 곡선이 디스크를 보호한다.
• 좌골신경통은 허리디스크의 전형적인 증상이고 디스크가 탈출되었다는 것을 알려준다.

치료​

• 허리 강화운동을 강하게 해서 허리 아픈 것을 낫게해준다는 생각은 팔 부러진 사람이 팔 근육 운동을 해서 낫게한다는거랑 같다.
• 엉덩이 근육과 활배근이 중요하다.
• 운동이 허리에 미치는 영향이 어느정도인지 정확히 알고, 내 허리가 그 부담을 견딜 수 있을지 확실히 알아야한다.
• 허리를 구부리는 스트레칭은 요추전만을 무너뜨리는 아주 나쁜 운동
• 디스크 상처가 아물 때 허리가 뻣뻣해지는 것은 상처가 흉터로 변하는 과정에서 나오는 자연스러운 현상
• 자주자주 일어서서 신전동작을 통해 요추전만을 되찾는 것이 필수적
• 디스크 상처가 아물어갈 때 절대로 다시 찢지 않으려고 노력하는 것이 척추위생
• 24시간 요추전만을 유지하는 것
• 요추전만을 할때 좌골신경통이 있는 경우 신경뿌리염증을 치료하고 척추위생을 열심히하는 것이 좋다.
• 등받이나 쿠션에 기대는 것이 유리하다.
• 척추위생의 기본은 최대 요추전만, 신전동작 필요
• 신전동작을 할 때 아프면 엎드려서 자주, 5분정도씩 팔꿈치는 어깨 아래
• 서고, 앉고, 허리를 구부릴 때 요추전만이 무너지면 안 된다.
• 무릎이 골반보다 약간 낮을 때 허리가 가장 편안하다.
• 운동으로 좋아지는 허리는 없다. 허리는 좋은 자세로 좋아진다.
• 서서하는 요추전만: 허리에 손을 대고 숨 마시며 5초유지
• 당당한 가슴법: 서서 가슴을 들고 견갑을 잡는다. 오리궁둥이는 안됨
• 걷기: 양쪽 견갑을 붙히고 가슴을 열고 턱을 치켜들고,우아한 턱과 당당한 가슴
• 앉기: 골반보다 무릎이 낮아야한다. 당당한 가슴법으로 앉아야한다.
  • 화면의 높이가 충분히 높아야한다.
  • 척추에 좋은 자세로 앉았을 때 허리와 목을 충분히 구부리지 않고도 화면이 눈에 다 들어와야한다.
• 허리배게는 허리끈이 오는 자리 즉, 3번 4번 요추 사이가 좋다.
• 무릎배게는 별로다.

금지 자세​

• 쪼그려앉기
• 오래앉기
• 아빠다리
• 숙이기

개요​

코딩을 해준다라는 과대광고를 집어치우고 실제로 유용하게 사용할 수 있는 유스케이스들을 정리해보았다.

정규식 추출​

보통 정규식을 만드는데에는 박음질하듯이 많은 테스트가 필요하다. 주로 regexr, regex101 사이트에 원하는 텍스트를 넣고 기억에 의존하면서 Negative/Positive Lookahead 를 맞추고, Negative/Positive Lookbehind 를 사용하다가 Negative Lookbehind가 프로그래밍 버전/언어별로 지원여부가 달라 찾게되는 경우가 많다.

이젠 ChatGPT에 물어본다. 아래 패키지 업데이트 내역에서 패키지명을 추출한다고 해보자.

Hello GPT.

Can you give me a regex pattern for getting to-be result?

as-is:
Orignal content


to-be:
Refined string #1
Refined string #2
...and so on.

알아서 가져다 줄 것이다.

코드로 문서 작성​

내 코드의 문서가 쓰고 싶다면 코드를 넣고 README.md 를 만들어달라고 하자.

Can you write a README.md with this code?

알아서 가져다준다.

인터페이스로 Object Validation Schema 만들기​

타입스크립트 인터페이스로 Joi Schema 를 만들어달라고 하자.

Raw SQL로 Query DSL 만들기​

로우 쿼리를 전달하고, 쿼리 DSL, 쿼리 헬퍼 구문을 만들어달라고 하자.

Data 로 DDL 만들기​

쿼리를 전달하고 위의 인터페이스 예시처럼 테이블 스키마 쿼리를 생성해달라고 하자.

참조​

awesome 이 생겼다. https://github.com/f/awesome-chatgpt-prompts

개요​

2016년부터 정들게 쓴 hexo는 플러그인이 많고, 테마가 많아 좋았다. 2019년도부터인가.. 다른 Static Site Generator 가 많아지면서 더 이상 hexo만의 이점이 없어졌고 테마나 플러그인 개발 등 생태계 라이브러리들의 업데이트도 줄어들었다.

ejs -> njk, less -> sass -> stylus 로 테마에 스택이 의존적이였다. 결정적으로 nodejs 기반 코어라 트러블슈팅을 올려도 리소스 낭비랄까..

Docusaurus는 1~2알파 시절 algolia 검색이 제공되지 않아 swizzle 해서 local search 커뮤니티 플러그인을 사용해서 붙혀보는 삽질이 있었고 한글이 정상적으로 동작하지 않았다.

2023년에는 2버전이 런칭했고, React 기반으로 프론트엔드 스택이 일원화되었고 등등 이 작업을 진행해도 될 것 같았다.

트러블슈팅​

SEO​

URI​

• hexo는 front-matter 구문 안에 date: 2023-01-10 09:00:00 로 날짜를 넣어준다.
• docusaurus는 nested folder 구조를 써야한다.
• md 파일의 front-matter.date 를 파싱해서 URL에 /2023/01/10/title 처럼 처리해준다.

Site Verification​

• 큰 문제없이 설정에 넣어줬다.

{
  "themeConfig": {
    "metadata": [
      // ? https://search.google.com/search-console
      {
        "name": "google-site-verification",
        "content": "g"
      }
    ]
  }
}

hexo new​

• hexo new post "title" 이 커맨드를 실행해서 포스트를 만드는데, 호환할 커맨드가 필요했다.
• 오늘날짜로 blog/2023/01/10/title.mdx 로 만들어주게 yarn cmd new title 로 생성했다.
• URL normalize 를 위한 기능으론 import { slugize } from "hexo-util"; 를 사용하면 된다.
  • slugify는 한글도 삭제된다.

archive​

• hexo의 아카이브는 Order by Created DESC 인 방면에, docusaurus는 ASC 정렬이였다.
• 이걸 플러그인 옵션으로 제공하자라는 이슈가 있지만 닫혔고, 알아서 하라가 그 답변이였다.
• 하나 만들어서 기존 컴포넌트 덮고 재정렬해서 연결해줬다.

{
  "presets": [
    "classic",
    {
      "blog": {
        // 실제론 path resolving 필요
        "blogArchiveComponent": "./src/component/BlogArchiveDescendingPage.tsx"
      }
    }
  ]
}

tag​

• docusaurus 태그는 tags: [tag1, tag2] 이 형식을 만족해야한다.
• ChatGPT 에게 정규식 물어봐서 전체치환했다.

github action​

• 타겟 레포, 브랜치 세팅해준다.
• personal access token 발행하고, 두 값 적절하게 넣어준다.
• yarn build, yarn deploy 실행하면 알아서 잘 된다.

{
  "organizationName": "gracefullight",
  "projectName": "gracefullight.github.io",
  "deploymentBranch": "main",
  "trailingSlash": true
}

env:
  GIT_USER: ${{ secrets.GIT_USER }}
  GIT_PASS: ${{ secrets.GIT_PASS }}

dark only​

• 어둡게, 스위치도 삭제했다.

{
  "themeConfig": {
    "colorMode": {
      "defaultMode": "dark",
      "disableSwitch": true
    }
  }
}

code block​

• 형식이 달라서 정규식 치환해주었다.

# hexo
\`\`\`language title

# docusaurus
\`\`\`language title="title"

comment​

• 코멘트 기능은 질답할 시간이 없다.
• 과감하게 삭제하려했으나 커스터마이징해서 gitalk을 연동했다.

search​

• algolia가 오픈소스 개발문서가 아니여서그런지 무료 인덱싱을 요청했으나 티켓 상태가 변경되지 않았다.
• @easyops-cn/docusaurus-search-local를 사용했는데, 이건 모바일 지원이 안 된다.

{
  "themes": [
    "@easyops-cn/docusaurus-search-local",
    /** @type {import("@easyops-cn/docusaurus-search-local").PluginOptions} */
    {
      "indexDocs": false,
      "blogRouteBasePath": "/",
      "hashed": true,
      "language": ["en", "ko"]
    }
  ]
}

• 1주정도 지났을까 algolia 에서 회신이 왔고, 인덱싱도 성공적으로 완료되었다.

결과​

• 만족스럽다.
• 사내 문서로 쓰기엔 typesense 를 먼저 구축해야할 것 같아서 쉽진 않을듯..
• 모바일로 볼 필요가 없으면 위의 플러그인으로도 만족스러울 것 같다.

개요​

• nextjs 13버전에서 app 디렉토리가 생기면서 client/server 컴포넌트를 쉽게 사용할 수 있는 환경이 되었다.
• getStaticProps, getServerSideProps 와 같은 메소드가 사라졌고, 양쪽이 fetch 로 통합이 되었다.
• 페이지별 상태 초기화를 위한 HOC 중첩을 가져가지 않아도 될 것 같았다.

App​

Node.js + React DOM Renderer​

app 내의 모든 로직은 Node.js 이다. 따라서 이런 로직이 가능하다.

import { hostname } from "os";

export default function Main() {
  return <div>{hostname()}</div>;
}

이벤트를 바인딩할 수 없다.

import type { SyntheticEvent } from "react";

export default function Main() {
  const handleSubmit = (event: SyntheticEvent<HTMLFormElement>) => {
    console.log("submitting");
  };

  return (
    <form onSubmit={handleSubmit}>
      <button type="submit">submit</button>
    </form>
  );
}

Error: Event handlers cannot be passed to Client Component props.
<form onSubmit="{function}" children="...">
  ^^^^^^^^^^ If you need interactivity, consider converting part of this to a
  Client Component.
</form>

Design system​

대부분의 디자인 시스템 라이브러리는 ThemeProvider 로 테마 상태를 공유하고 Baseline StyleSheet를 전역에 넣어준다. 스타일시트를 위해 RootStyleRegistry 란 HOC 만들어 Baseline StyleSheet 를 동적으로 넣어주면 초기화는 가능하지만,

문제는 Server Component 내에서 use 을 사용할 수 없으니 ThemeProvider 로 기능동작이 불가능하다. 어찌저찌 'use-client' directive 로 Client Component 로 설정한다고 하여도 Provider 로 인해 하위 모든 컴포넌트가 Client Component 로 동작해야할 것이다.

그래서 문서에서 다음과 같이 표기가 된 것으로 보인다.

If you want to style Server Components, we recommend using CSS Modules or other solutions that output CSS files, like PostCSS or Tailwind CSS.

위 방식으로 mui/material-ui/examples/material-next-app-router-ts 예시가 추가되었지만, 이렇게 쓸바에 pages 폴더 라우트와 다를 게 없다고 생각한다.

결론​

• 아직 app 폴더를 사용하기엔 이르다.
• vercel/app-playground에 충분한 예시가 갖춰지고, 생태계가 React Server Component 를 충분히 지원할 때까지는 프로덕션에서 사용은 불가능하다고 보인다.

사견​

개인적으로는 왜 이렇게 많이 클라이언트에서 렌더링해야해? 그냥 필요한 영역만 클라이언트에서 그려주면 되잖아? 라는 접근방식은 디버깅 관점에서 마음에 들진 않는다. 웹을 하나의 Client 관점에서 본다면, 설치의 유무만 다를 뿐 앱에서 서버에서 렌더링된 HTML을 받고 일정부분만을 Server Driven UI 로 가는거와 마찬가지다. 복잡도가 크게 증가한다.

이러한 시도는 이미 Dotnet, Laravel Livewire 등 다른 언어에서 많이 진행되어왔고, Remix 에서는 이미 잘 동작 중이다. 단지 React 를 서버에서 쓰기 위해 다시 MVC 시절로 회귀하려는지 모르겠다.