Node.js/Express를 현업에서 쓰진 않았지만 어떻게 사용하는지 궁금했다.
해서 Udacity강의를 들어보고 아래 유튜브를 보았다.
고백하자면 Clojure의 웹개발과 아주 비슷하다는 느낌을 받았다. 유튜브 강의에서 나오는 몇몇 기능은 개선을 하면 좀 더 멋지게(생산성있게) 개발할 수 있겠다는 생각도 했다.
2021년 12월 3일 금요일
Clojure를 하다가 Node.js/Express 만져보면서 느낀점.
Javascript는 참으로 특이한 언어이다. 문서를 보지 않아도 대충 보고 쓸 수 있을 정도로 직관적이다. 당연히 공식문서를 우선적으로 읽고 차근차근 문법을 익히고 개발을 진행하겠지만, 이상하게도 자바스크립트를 만질 때는 공식문서를 보지 않고, 기존 코드를 보더니 '음... 이렇게 돌아가는 거군?' 하면서 간단한 코드를 짤 수 있게 되었다. '물론 null이 Object라던가 하는 문제는 그 이후에 하나씩 알아가는 거고'
2021년 11월 27일 토요일
매크로에 대한 글을 적다
https://green-labs.github.io/the-macro
이직한지 6개월이 되는 시점에 드디어 기술블로그를 올리게 되었다. 입문자를 위해 자세한 설명을 적거나 하진 않았지만 최소한 말로 약만 파는 것이 아니라, 나의 코드로 가능하다는 것을 보여주고 싶었다. 개발자는 코드로 말하는 것이 기본이니까.
LISP 매크로는 개발자에게 만지기 어려운 무서운 기술처럼 보이는가보다. 실제로 쉽지는 않다.
주류의 인사들은 '매크로를 쓰는 가장 좋은 방법은 쓰지 않는 것'이라고 한다. 그 만큼 매크로는 과한 기술이라는 평이 지배적이다.
하지만 과한 기술이라고 쓰지말라고 하는 것은 웃기다. 기술에 대한 이해도가 부족할 때 과하게 사용하니까 말이다. 즉, 이 말은 나에게 '넌 잘 모르니까 쓰지마' 라는 말로도 들린다.
매크로를 쓰지 말아야 하는 가장 큰 이유는 제대로 사용할 수 없는 개인의 이해도만이 이유가 되어야 한다고 주장하겠다.
어떤 기술이던 이해하지 못하고 쓰면 화를 면치 못한다. 반복문/조건문을 이해하지 못하고 쓴다면 안전할까? 죽음이 무서운 이유는 우리가 죽음을 모르기 때문이라는 말이 있듯이 매크로가 어둠의 기술처럼 느껴지는 이유는 그 만큼 매크로를 모르기 때문이라고 생각한다. 매크로는 죽음과 다르게 다행스럽게도 관심이 있으면 이해할 수 있다. 즉, 매크로가 두려운 이유는 매크로를 온전히 받아들이려고 하지 않는 나의 마음일 것이다.
난 권위에서 오는 말을 좋아하면서도 싫어한다. 여러 잠언들은 때때로 나를 편안하게 하지만 어떤 문장들은 맞는 말 같으면서도 고개를 갸우뚱하게 만드는 경우가 있다. 이때 '권위자'라는 단어는 그 갸우뚱하던 고개를 끄덕이게 만든다. 알아서 고개를 숙이거나 주위에서 숙이도록 강요하게 하는 힘이 있다.
'매크로를 쓰지말라' 라고 말한다면, 우리는 매크로가 무엇인지 정확히 알 필요가 있다. C, LISP의 매크로는 모두 컴파일러가 미리 만들어놓은 룰을 초월한다.
이 초월하는 힘을 처음 접한 나는 다음과 같은 경험을 하였다.
첫째, 내가 한번 휘두른 이 힘이 어디까지 닿는지 가늠이 되지 않는다.
둘째, 기존의 힘이 무색함을 느낄 수 있다.
셋째, 결국 강력한 이 힘에 집착하게 된다.
아마 구루들은 세번째에 이르는 것에 두려움을 느끼게 하고 싶었다고 생각한다.
그리고 구루들의 "매크로를 잘 쓰는 방법은 쓰지 않는 것이다" 라고 말하는 것에 대한 숨겨진 또다른 의도는 아래와 같다고 생각한다.
"매크로는 어짜피 기어코 위험을 무릎쓰고 자유로운 힘을 얻고자 하는 사람들이 쓰는 기술이다. 쓰지말라고 쓰지 않는 사람들에게는 필요없다. 어짜피 매크로를 쓰고자 하는 사람들은 나의 말이 의미 없다. 이미 쓰고 있을테니"
나는 위처럼 이해를 했다. 나는 그래서 매크로의 강력함과 위험성을 인지하고 자유롭게 쓰려고 한다. 만약에 그분들이 자신들은 그런 의미로 말한 것이 아니라고 말하면 어떤가?
그런 것들은 이미 상관없다.
2021년 11월 22일 월요일
2021년 4월 30일 금요일
컬리에서 작성하는 마지막 기술 블로그
y combinator에 대해서 한번 적어보았다.
마지막에는 종립님께서 글을 다듬어 주시고 javascript 코드를 추가해주셨다.
글이 더 풍부해졌다.
종립님과 함께 기고할 수 있어서 영광이다.
무엇보다
즐거웠다
2021년 3월 14일 일요일
[그런 REST API로 괜찮은가]를 보고
REST API는 무엇일까.
로이 필딩의 논문을 다 읽진 않았지만 그곳에는 client-server 아키텍처 사이에서 완벽하게 독립적으로 개발을 할 수 있도록 하는 API 아키텍처를 상상한 듯 하다.
만약에 할일 목록을 가져왔다면, 그 할일 목록에서 할 수 있는 행위들을 위한 링크를 제공하는 것이다. 그러면 클라이언트에선 특정 uri에 대한 정보를 알 필요도 없을 것이다.
이것이 HATEOS의 중요성인 듯하다. 로이 필딩을 정확히 무엇을 꿈꾼 것일까.
아래 유튜브 비디오를 보면서 고민을 하는 하루가 되었다. 로이 필딩 논문을 한 번 마저 읽어봐야겠다.
2021년 3월 11일 목요일
폴그레이엄은 왜 ycombinator라고 이름을 지었을까
ycombinator는 lambda calculus에서 꽤나 중요하게 여겨지는 아이디어이다.
오랫만에 컬리에 기술블로그로 기고할 겸 공부도하고 정리도 했다.
https://www.notion.so/tombox/Y-combinator-865c9614db0245ce869424a92462406b
취직을 위한 공부만 했다면 달라졌을까
Java/Spring을 많이 사용해왔지만, 솔직하게 Spring을 잘 안다고 할 수는 없겠다.
더 솔직히 말하면, 그동안 너무 쓸데없어 보이는 것들에 신경을 많이 썼던 것 같다.
유펭린의 집합론을 공부하질 않나, 잘 이해도 못하는 Lisp 책이나 보려고 하질 않나...
다 나의 커리어에는 큰 도움을 줄 것같지 않는 것들만 산더미로 공부했다.
그나마 괜찮은건 그래도 공부를 하긴 했다는 점
나만 괜찮다면 그것이 정도가 아니라도 괜찮다고 생각했다.
후회하지 않을 거라고 생각했다.
회사에서 사용하는 기술들을 그때그때 공부하면 되지 라는 알인한 생각을 가져왔다.
왜 그랬을까.
왜 나는 해야하는 공부에는 관심을 갖지 않고, 꼭 필요 없어 보이는 것에만 열중했을까
아쉽고도 아쉽지만, 어쩔 수 없다.
지금에라도 나의 공부 포트폴리오를 바꿔야할 것이다.
평생 이렇게 공부만 할 수는 없을 것이다.
언젠가는 꽃을 피워야 하고, 또 동료들이 내가 동료인 것이 만족할 수 있도록 나는 더 분발해야 한다.
누구를 만나던 그들과의 만남과 헤어짐에서 내가 좋은 동료로 남고 싶으니까...
나는 더 열심히 살아야겠다.
2021년 3월 4일 목요일
[패스트캠퍼스] 강의를 구매했다.
컬리에 있으면서 고민을 하게된 큰 그림을 보는 인사이트를 얻기 위해 구매해보았다.
아래는 관련 강의 링크이다.
https://www.fastcampus.co.kr/dev_red_yjs
윤진석님이 어떤 분인지는 잘 모르겠지만, 나보다 많은 경험을 하신분이니 가격에 맞는 정보를 알려주지 않을까 라는 생각에 구매를 진행했다.
그리고 생각보다 비싸진 않다. (이전에 구매한 clojureScript 강의에 비하면...)
수강을 다 하지 못해서 속단할 수는 없지만, 강의시간이 4시간 정도 된다. 거기에서 intro 관련 내용을 빼면 더 시간이 줄어든다. 가격은 15만원 정도였으니, 약 4시간이라고 치면 한시간에 37500원 정도다.
싼 가격은 아닌 것 같다.
그래도 다 들어보면 생각이 달라질 수 있으니 전부 수강하고 다시 리뷰를 해야겠다.
2021년 3월 1일 월요일
Learn Reagent Pro by Jacek Schae 강의 후기
reagent 란
reagent react를 clojureScript로 개발할 수 있게 해주는 라이브러리다.html을 만들 때는 hiccup라이브러리 처럼 clojure 자료 구조로 표현이 가능하다.
즉 일반적으로 컬렉션을 다루는 함수를 그대로 적용해도 잘 작동한다.
더 특이한 것은 reagent의 atom이다.
clojure에서 atom은 java의 AtomicInteger, AtomicReference와 같은 녀석처럼 병렬 프로그래밍을 할 때 사용한다.
reagent 에서 atom은 react, redux의 조합처럼 값을 변경시키면 저절로 해당 atom을 dereference해서 사용하는 구간이 다시 렌더링 되면서 값이 보여진다.
Learn Reagent Pro
강의는 꽤나 비싼데 reagent를 처음 접하는 사람에게는 유용할 것이다.reagent만 배우는 것이 아니라, shadow-cljs 같이 의존성을 적용하는 방법이나, 일반적으로 reagent를 사용할 때 어떻게 사용하는지 알 수 있다.
현재 5강 정도를 남겨두고 firebase에 올려보기 까지 진행했다.
꽤나 유익했고, 다음 강의 Learn Reframe Pro도 이어서 수강할 예정이다.
2021년 2월 27일 토요일
clojure로 카프카에 이벤트 발행
의존성
[org.apache.kafka/kafka-clients "2.5.0"]
사용코드
(ns kafka-demo2.core
(:import [org.apache.kafka.common.serialization StringSerializer]
[org.apache.kafka.clients.producer KafkaProducer ProducerRecord])
(:gen-class))
(def config
{"bootstrap.servers" "127.0.0.1:9092"
"key.serializer" StringSerializer
"value.serializer" StringSerializer})
(defn publish [topic str]
(let [producer (KafkaProducer. config)
record (ProducerRecord. topic str)]
(try
(.send producer record)
(finally (.close producer)))))
(defn -main
"I don't do a whole lot ... yet."
[& args]
(println "push A")
(publish "yhnam-topic" "A"))
도커
https://github.com/ssisksl77/clojure-breadcrumb 위 깃허브 참고실행
별거 없음 위 깃허브 참고
$ docker-compose up
$ lein uberjar
$ java -jar kafka-demo2-0.1.0-standalone.jar
그외 정리
https://www.notion.so/tombox/db6bc836f25d41948d28f3aff9ec1aff2021년 2월 21일 일요일
[책리뷰] (빅 데이터 세상으로 떠나는 간결한 안내서) NoSQL
이 책은 NoSQL의 개요를 담고있다.
NoSQL의 전체적인 추세가 그때와 지금은 다르지 않은 것 같다.
NoSQL이 어떤 종류가 있으며, 기존 문제들을 어떻게 풀려고 하는지 간결하게 설명한다.
흥미로운 책이었다. MongoDB를 아무생각없이 쓰고 있었는데 조만간 DB 관련된 책을 봐야겠다는 생각을 한다.
MySQL도 아무생각없이 썼던게 아닌가 싶다. 공부해야겠다.
2021년 2월 18일 목요일
Monad 정리
내가 이해하는 모나드에 대한 생각을 잠깐 정리해보려고 한다
1. Monoid
2. Functor
3. Applicative Functor
4. Monad
이 순서를 알아야 한다.
1. Monoid
모노이드는 아주 단순하다.
- 항등원을 가진다
- 결합법칙
- 이항연산
이 셋이 뭔지 모른다면 덧셈을 예로 들겠다. 덧셈은 Monoid다.
1. 항등원을 가진다. (0은 항등원이다)
2. 결합법칙을 가진다 (1 + (2 + 3)) == ((1 + 2) + 3)
3. 이항연산 (덧셈은 두개의 항이 필요하다)
모노이드는 함수형 프로그래밍에서 꽤나 중요한 역할을 한다.
바로 병렬로 fold(fold가 뭔가 모른다면 reduce라고 생각하면 됨)를 할 수 있다는 것이다.
순서가 필요없이 이항연산이 가능하기 때문에, 왼쪽부터 덧셈을 하거나, 오른쪽부터 덧셈을 하거나, 식을 반으로 쪼개서 각자 계산후에 머지를 하더라도 값이 동일하다는 것을 의미한다.
그러므로 모노이드는 꽤나 중요하다.
모노이드면 일단 '이항연산을 안전하게 할 수 있구나' 라는 생각을 하면 된다.
2. Functor
a Functor is a mapping between categories.
두 가지의 카테고리 사이를 이어주는(map) 사상을 말하는 것 같다. (사실 영어는 잘 모르겠다)
하스켈에서 functor는 `fmap` 을 구현한 녀석을 말한다.
`fmap`이란 뭘까?
이건 List 에서 map을 사용하는 것을 생각하면 쉽다.
List에서 map을 사용하면 어떻게 될까? 값이 변경되어도 그것이 List라는 것은 변함이 없다. 즉, Functor는 map이다 라고 생각하는 것이 좀 더 이해하기 쉬울 것 같다.
하스켈 Functor의 fmap의 구조는 아래와 같다.
class Functor f where
fmap :: (a -> b) -> f a -> f b
(<$) :: a -> f b -> f a3. Applicative Functor
중요한 리소스가 있다.
하스켈에서 Functor와 Applicative Functor의 타입차이를 한번 봐보자.
(<$>) :: Functor f => (a -> b) -> f a -> f b(<*>) :: Applicative f => f (a -> b) -> f a -> f b
그러니까 functor는 (a -> b) 이고 Applicative functor는 f (a -> b) 임을 보자.
결국 f (a -> b)에서 이 앞에 붙은 f가 무엇이냐는 것이다. 즉. Applicative Functor는 Functor 안에 함수도 들어갈 수 있는 경우를 말한다.
만약에 즉, 위에서 예를 들었던 List안에 [+1, +2] 이런식의 리스트가 존재하여, 합칠 수도 있다.
만약에 즉, 위에서 예를 들었던 List안에 [+1, +2] 이런식의 리스트가 존재하여, 합칠 수도 있다.
즉, 이런 타입 안에 함수를 넣을 수 있고, 이 함수는 그 타입에서 가지는 컨텍스트가 적용된다.
(여기서 컨텍스트란 그 타입 안에 내포되어 있는 의미를 말한다. 예를 들어 List는 여러개를 가진다를 말할 수도 있을 것 같다)
4. Monad
모나드는 좀 특이한데, 내 생각에 이것은 좀 필요에 의해서 만들어진 것 같다.
최근에 회사 내에서 스칼라 빨간책 스터디를 하면서 monad에 대한 이야기를 했다.
일반적으로 monad에 대한 가장 간단한 설명은 `flatMap`을 말한다고 할 수 있다. 그런데 flatMap이 왜 중요할까?
class Applicative m => Monad m where
(>>=) :: m a -> (a -> m b) -> m b
(>>) :: m a -> m b -> m b
return :: a -> m a
여기서 중요한 것은 >>= 이다
m a -> (a -> m b) -> m b 이 형태를 보면 flatMap임을 알 수 있다. (이것이 이상하다고 생각된다면, 자바나 다른 언어에서 map과 flatMap의 차이를 보면 좋을 것 같다)
flatMap이 왜 map이랑 그렇게 다른 것일까?
왜
-- fmap or map (Functor)-- flatMap (Monad)
(a -> b) -> f a -> f bm a -> (a -> m b) -> m b
이 둘이 뭐가 그렇게 다른 것일까?
아주 조금 다르지만 아주 크게 다르다. 여기서 중요한 것은
(a -> m b) 이다. 이것이 아주 큰 일을 한다.
일단 Monad는 Functor랑 아주 큰 차이는 Type을 생성하는데 주도권이 서로 다르다는 것이다.
당신은 List [1,2,3,4] 에 더하기 1을 하는 함수를 호출했다고 해보자.
var a = [1,2,3]function addOne(x) {return x + 1;}a.map(addOne); // [2,3,4]
여기서 당신은 이런걸 원할 수도 있다.
리스트를 두배로 만드는 거다!
var a = [1,2,3]
function double(x) { return [x,x] }
var b = a.map(double); // [[2,2],[3,3],[4,4]]
b.map(double); // [[[2,2],[2,2]],[[3,3],[3,3]],[[4,4],[4,4]]]이래가지고, 함수를 함성할 수 있을까?
누군가는 이렇게 말할 수 있다. 애초에 왜! 리스트를 리턴하는 함수를 만든거야? 그냥 그 타입에 맞는 것만 리턴하지?!
누군가는 이렇게 말할 수 있다. 애초에 왜! 리스트를 리턴하는 함수를 만든거야? 그냥 그 타입에 맞는 것만 리턴하지?!
말은 쉽지만 그렇지 않다. List를 다루는 곳에는 List를 리턴하는 함수를 많이 사용할 수 밖에 없다.
만약에 리턴하는 것이 IO라면? 그리고 IO를 리턴하는 객체가 계속 겹친다면? 제대로 작동할 수 없다.
자바의 Optional도 마찬가지이다. Optional을 실행했는데 안에 Optional이 있다면 어떻게 할 것인가? 재귀로 호출할 것인가?
이런 함수의 합성에서 예기치 않은 타입의 덮어씌움이 있기에 우리는 flatMap을 쓴다. 여기서 한가지 뇌피셜을 더해서 설명하면
monad는 두 개의 타입을 어떻게 concat을 하냐가 관건이다.
즉 파이썬의 키워드를 빌려서 직관적으로 설명을 시도해보겠다.
[1,2,3] ++ [4,5,6] # [1,2,3,4,5,6]
List를 concat한다면 이렇게 될 것이다. 만약에 다른 타입들에도 이 concat이라는 개념을 녹일 수 있다면(concat을 해서 두 타입 합치는 방식을 약속한다면)
flatMap안에 해당 타입에 어울리는 구현으로 만들어서 flatMap을 만들면 타입을 겹겹이 쌓이지 않을 수 있다. 그때그때 concat으로 합치면 되니까 말이다.
우리가 concat이라는 개념을 생각해보는 것이 중요하다. concat은 1번에서 지칭한 Monoid와 같다. (왼쪽부터 수행하건, 오른쪽부터 수행하건 결과값은 동일해야 한다.)
이상 여기까지가 내가 이해한 Monad의 정리다.
모나딕 뭐 이런 말은 안쓰려고 노력했다. (사실 용어에 대해서 완벽하게 알지 못하면 안쓰는게 나을 것 같아서 쓰지 않았다)
사실 더 디테일한 내용들이 있다. 특히 모나드의 경우 위에 설명한 타입만 맞으면 되는 것은 아니고, 몇가지 조건을 만족해야만 한다.
2021년 2월 11일 목요일
2020년을 생각하며...
2020년이 갔고 2021년이 왔다.
아주 바쁘게 보냈지만, 그렇기에 너무 조용하고, 기억에 남는 것이 없는 한 해를 보낸 것 같다.
피로사회에서 바쁜 삶은 사람을 피로하게 하고 깊은 생각을 못하게 하고 자신을 되돌아볼 시간을 제한하게 한다고 주장한다. 그는 쉬는 시간에 게임을 하거나 여행을 가는 것 같이 `무언가를 하는 방식`으로는 근본적인 해결이 아니라고 한다.
나는 그럼에도 되돌아 보려고 한다.
내가 이번 해에서 무엇을 보았고, 무엇을 느꼈는지.
작년 초를 생각하면 나는 삶의 무료함을 느끼고 있었다.
다들 나와 같지 않은 마음, 안정감있는 삶. 아니 도태되어 가고 있는 삶에 행복감을 누리는 사람들과 몇년을 함께 지내면서 나 자신도 그렇게 변해가는 것에 환멸을 느꼈다.
나는 서울로 상경했으며, 현재 하고 있는 일도 정도를 걸어서 온 길이 아니다. 대학의 전공을 따르지 않고, 선택한 길이기에 나에게는 한계가 명확함을 인지하고 있었다. 누군가는 4년을 준비하고 좋은 회사를 거쳐가겠지만, 나는 작은 회사에서 2400이라는 숫자를 지니고 시작했다.
적은 숫자가 아닐까 라고 생각했지만 당시 나는 서울 고시원에 살고 있었다. 그것도 내창으로 (내창은 창문이 복도에 있는 것을 말한다. 나는 햇빛을 볼 수 없는 방에 살았다) 버는 돈이 없었기에, 나는 2400이라는 숫자를 받으면서 너무 행복했다.
나도 사회의 일원이 되었구나
2400
이것이 나에게 주어진 숫자구나
나는 현재 4,5년차가 되었고 회사는 3번을 이직했다. 마치 서울에 내리는 소나기처럼. 어디 한 곳에 뿌리내려 꽃을 피우는 것이 아니라, 하수구로 내려가 이리저리 더러운 것들을 닦고 묻혀서 결국에는 서울에서 밀려나지는 않을까 걱정한다.
이것은 나의 언더독 성향이 더 이런 경향을 강하게 만든다.
개발을 하면서 Lisp에 빠져버렸을 때, 나의 커리어패스가 뒤틀어질 것을 예언했다.
개발학원에서 SICP마법사책을 읽고, Scheme을 공부하면서, 이걸로 취직을 하겠다고 학원을 수료하지 않고 뛰쳐나왔을 때.
전혀 Scheme이나 Racket을 쓰는 회사를 찾을 수 없었을 때의 그 어둠은 창문이 없는 고시원에 사는 것보다 더 무서웠다.
결국 Spring을 여차여차 공부해보고 취직을 하고, 공부를 다시하고, 일을 하고 버텼던 것 같다.
수학을 공부하고, 함수형 프로그래밍을 공부하지만
내 마음 속에는 Lisp가 항상 있다.
음식 평론가 황교익은 한 때 최고의 음식은 자장면이라고 뽑았다.
어렸을 때, 가난한 시절 부모님과 함께 먹었던 자장면을 기억하며,
최고의 음식은 맛만으로 평가할 수 없다는 그의 말처럼
나에게 Lisp는 그 시절 나의 악몽같던 시절에
희망과 절망을 동시에 준 도구였다.
다시 돌아와서
나는 컬리라는 회사로 이직했다.
처음으로 사람들이 이름을 아는 회사.
사장님의 이름을 연예인처럼 많은 사람들이 기억하고 있는 회사.
사장님의 이름을 연예인처럼 많은 사람들이 기억하고 있는 회사.
부모님이 이름을 안다는 것에 괜히 기분이 좋았다.
그리고 무엇보다 변화를 두려워하기보다 변하지 못하는 것을 두려워 하는 사람들을 만난다는 것은
나에게 신선했고, 내 자신을 움츠려들게 했다.
왜냐하면
결국 가만히 있어도, 그들과 함께 있으면 변하기 때문일지도 모른다.
난 오히려 내가 어떻게 변하는지 소극적으로 바라만 봐야했다.
그동안 나는 해내는 것에 집중했었다.
해야할 것을 바로알고 어떻게 해야 할지, 정말 그들이 잘 쓸 수 있을지를 고민했다.
2400이라는 숫자로 일을 시작했을 때부터
나는 항상 감사했다. 이 감사함은 유저들에게 보답해야 한다고 나는 생각했다.
컬리에서 일하면서 새로운 경험을 하게 되었다.
무엇을 만들어야 한다고 하지만,
그것이 무엇인지 너무 추상적이기에 또 그걸을 알 수 없기에
우리는 개발하기보다는 대화를 하는 사람이 된 것 같다.
신기한 경험이었다.
해야할 일이 있지만 할 수 없는 답답함.
코드 리팩토링, 좋은 코드는 세상을 바꿀까?
컬리에서 일을 하면서 이 말은 좋은 질문이 아니라는 생각을 하게 되었다.
이 말은 그렇기도 하고 그렇지 않기도 하다.
모든 세상은 단순한 말로 표현할 수 없다.
각자의 서비스를 만들기 위해
각자의 팀이 가지는 프로젝트를 마치 자신의 사업처럼 사랑하면서 작업을 해야하며,
서로 함께 만들기 위해
회의하고 언성이 높아지고
회의하고 언성이 낮아지고
회의하고 적막이 흐르고
반복에 반복을 하다보면
개발자는 코드를 만드는 사람이 아니라
꿈을 꾸는 사람들이며
무엇을 만드는지 상상하는 사람들이구나...
라는 생각을 했다.
개념적으로만 존재하던 개념들의 점점 실체화되고 구조과 완성이 되가는 그 시점부터
좋은 코드, 리팩토링에 대한 지식과 경험이 있으신 분들과 함께라면
상상한 구조를 만들어내는 데에는 마치 뻥 뚤린 고속도로가 펼쳐진 것처럼
정신없이 나아간다.
무엇을 만들지도 모르는 곳에 떨어져서
무엇을 어떻게 만들지 고민하는 순간의 고통을 느낄 때
나는 새로운 세상에 들어왔음을 느꼈다.
2021년에는
더 겸손해지고
더 열심히 공부해야겠다.
피드 구독하기:
글 (Atom)