bgl gwyng

@bgl@hackers.pub · 81 following · 89 followers

슈티를 함께 만들 팀을 만들고 있습니다. 관심 있으신 분, 또는 잘 모르겠지만 이야기를 나눠보고 싶은 분도 bgl@gwyng.com으로 편하게 연락주세요.

GitHub
@bglgwyng
shootee
www.shootee.io

예전에(혹시 지금도?) 신문 컬럼에서 흔히 볼수 있는 글 구조가 있는데, 우선 뜬금없는 주제로 서문을 연다. 가령, '고대 그리스에는 이러저러한 풍습이 있었다' 하는 식으로.

이러고 글의 3/4 정도 지점까지 고대 그리스의 어떤 풍습에 대해 설명한다. 소재가 흥미로운데다가 기본적인 글솜씨는 있기에 술술 재미있게 익힌다. 이제 유익하고 흥미로운 내용이 끝나면 '하지만 작금의 대한민국의 현실은 어떠한가'며 갑자기 핸들을 꺽는다. 그리고 자기 하고싶은 말로 나머지 분량을 채우고 글이 마무리된다.

앞부분 3/4의 시사교양정보와 뒷부분 1/4의 아무말대잔치의 연관성을 찾아내는것은 오롯이 독자의 몫이다. 아마 수십년간 이 황금(?)패턴으로만 글을 수백편 써온 소위 평론가/칼럼니스트 등등이 상당수 있을것이다.

6

React Native 라이브러리 쓸때 제일 (충분한 까닭없이) 고통받는 경우가 JS 단에 노출되어야할 API가 쓸데없이 한번 래핑되서 네이티브 단에 숨어있는 경우인거 같다. 오히려 래핑을 안했으면 JS 단에서 알아서 쇼부를 볼텐데, 쓸수있는 인터페이스가 충분히 원자적이지 않아서 네이티브단 코드를 까거나 아니면 꼼수를 써야한다.

5
3
2

React 컴포넌트 디자인중에

<Container>
  <Header>...</Header>
  <Content>...</Content>
  <Footer>...</Footer>
</Container>

이런식으로 Header, Content 등의 컴포넌트는 Container 아래에서만 유효하게 동작하는 방식이 있는데, 이게 진짜 장점이 있는지 궁금하다. 차라리 header, content 등의 props로 뚫어놓는게 낫지않나.

3

에디터가 하스켈의 타입 에러메시지를 보여줄땐 호버링으로 뜨는 창으로는 부족한거 같다. 별도의 뷰를 만들어서 크게 보여주고 또 rich한 기능(메시지에 포함된 심볼로의 navigation 등)을 제공하면 좋겠다.

3

애플이 liquid glass로 사방에서 욕을 먹고있는데, 스샷들을 보면 그럴만하다 싶다. 근데 반투명한 배경의 창이 가지는 시맨틱이 뭘까? 언제 써야하고 언제 쓰면 안될지를 어떻게 구분해야하지.

2
2
4

인스타 클론 코딩 만만하지 않은것으로 밝혀져...

3

요즘 유튜브 쇼츠에 3초면 다 보고 이해할 내용을 한심한 AI 더빙을 얹어서 30초로 늘린 동영상이 범람하고 있다. 유튜브 Shorters가 필요하다.

3
3

코딩중에 동작을 disable시키기 위해 주석을 많이 쓰는데, 이런것도 그냥 기본 문법에 Disable같은 키워드로 넣어 주면 좋겠다. 또 콘솔에 메시지를 찍을때 현재 소스 코드 위치를 찍는 것도 기본 기능으로 넣었으면 좋겠다.

이런 제안에 대해 거부감이 든다면(나도 듬), 그건 프로그래밍 언어의 문법이 완성된 코드라는 정적인 정보를 묘사하기 위함이라는 생각 때문일 거라고 짐작한다. 중간에 나오는 못난 코드들을 보조할 필요는 없다는 입장? 근데 사실은 못난 코드 보고 있는 시간이 코딩하는 시간의 99%다.

4
2

@hollo 같은 얘기입니다ㅋㅋ근데 하스켈에서 '요청을 보내되 응답은 다른 쓰레드에서 받기'란 이펙트를 구분할수가 없지 않나요? 새 쓰레드를 띄울수있는 이펙트랑은 좀 다르다고 생각합니다. 새로 쓰레드를 띄우면 거기서 무제한으로 요청/응답을 할수있는데 그걸 바라진 않아서요.

1

평소에 함수형 언어 매니아들이 주장하는만큼 이펙트를 엄격하게 구분하는게 중요하다곤 생각안했는데, local first 앱을 만들다가 네트워크 요청을 포함한 IO와 그렇지 않은 IO를 구분해야하는 이유를 찾았다. 앱의 초기화 로직에 네트워크 요청이 숨어있으면 API 서버 장애시 앱이 아예 안켜지는 문제가 있다. 방금 이거랑 관련된 버그 찾느라 시간을 많이 썼다.

8

다들 그렇듯 나도 나이먹으면서 점점 관심없는 주제로 별로 안친한 사람들과 스몰토크하는 것에 익숙해졌는데, 여전히 사주팔자/점술 이런 얘기가 나오면 도저히 뭐라고 맞장구를 쳐야할지 모르겠다. 이야기하는 그룹에 그런거 좋아하는 사람이 여러명 있을땐 그들끼린 너무 즐겁게 그 주제로 꺄르르르호호호 하는데, 주제가 좋고 싫고를 떠나서 진짜 한마디도 할 마디도 거들수가 없더라. 그나마 비꼬지 않고 닥치고 있는게 철든 결과물인듯하다.

7
3
2

유려한 애니메이션과 화면 전환을 갖춘 앱을 만들려면 실행중에 요소의 크기를 측정하는 등의 동작이 필수란걸 점점 깨닫고 있다. 또는, 정적으로 레이아웃 정보를 미리 알수있는 방법이 있다면 더 좋겠다만.

1

대학생때 친구(컴알못)가 노트북 견적 짜달라고 한적이 있는데, 성능 상관없고 최대한 싸게만 해달라고 했다. 그래서 운영체제 미포함 기기에 우분투 깔아서 30만원으로 맞춰줬다. 우분투를 영업하려는 의도는 전혀 없었고 싸게 해달라는 요구를 최대한 맞춘 결과였다. 걔가 그때 형편이 안 좋아서 한푼이라도 아끼는게 중요했고, 나는 나름 목적을 달성했다는 것에 뿌듯해했다. 리브레 오피스 깔아주면서 한글, 엑셀 대신에 이거 쓰면 된다고 설명했던 기억이 난다.

그리고 이 일을 까맣게 잊고 살다가 1년후 쯤에 그 친구를 다시 만났는데, 보자마자 반응이

나 너무 많은 일이 있었어
12
1
0

예전에 게임 회사에서 상점 시스템(게임 머니로 아이템 구입/선물을 처리하는거)을 개발하는 팀에서 일한적이 있다. 그때도 퇴사하기 직전에 취약점을 발견했었는데, 다행히 외부인은 쓸수없고 직원만 쓸수있는 취약점이긴 했다. 상점 시스템이 게임 머니를 관리하는 시스템과, 실제로 아이템을 인벤토리에 넣는 시스템이 분리가 되있어서 생긴 문제였는데, 가령 잡템을 100원에 구입하는척하며 실제론 인벤토리에 전설의 무기가 들어가게끔 할수 있었다. 그러니까 MSA인데 각 서비스가 서로를 100% 신뢰하고 있어서 생긴 문제? 어떤 직원이 마음먹고 그런 짓을 했다면 본격적으로 abnormarly detection을 하지 않는이상 적발하기가 매우 어려웠을 것이다.

4
0
1
1

잘 모르는데 불안정한 라이브러리를 쓸때의 디버깅은, 코드의 일부를 disable하고 버그가 재현되는지 보고 맞으면 범위를 좁히고 이런식으로 무지성 이진탐색을 수행하는 식으로 하게된다. 전혀 모르는 라이브러리에 대해서도 쓸수있는게 장점이긴한데, 반대로 이런건 하고나서 배우는게 진짜 1도 없다.

6
4

어제 하스켈러들과 얘기하다가 느꼈는데, Linear Type이 얘기는 오래전부터 나왔지만 실제로 개발에 써본사람은 많지 않아서 약간 떡밥화?가 된거 같다. 나도 Linear Type에 대해선 예전에 Idris로 쓰여진 튜토리얼을 보고 흥미롭다고 생각한게 전부다. 근데 함수형 언어에 대해 GC가 필수라느니 C처럼 성능 최적화를 못한다느니 같은 이야기를 들을때 Linear Type을 언급하며 킹론상 가능하다능...이라고 하게된다(나말고도 많이들 그럴듯?) 하지만 정작 구체적으로 어떻게 구현하는지 공부해본적은 없다ㅋㅋIdris2가 궤도에 오르면 떡밥에서 벗어나려나.

2

React Native에 Portal이 없어서 좀 고생을 했는데, 일단 지원하는게 맞다곤 생각한다. 근데 Portal이 필요한 경우는 상태 트리랑 뷰 트리가 순서가 어긋나있을 때인데(non-monotone?) 이런 설계 자체가 문제일 수 있다. 보통 개발할때 뷰 트리 기준으로 생각하기 때문에 그런데, 상태 트리를 먼저 다 설계하고 렌더링은 최대한 단순하게 하면 될거 같긴한데, 음 이거 Redux잖아ㅋㅋㅋ

3

많은 언어에서 배열이 primitive로 주어지기 때문에 간과하기 쉬운데, 실제로 배열은 Binary Trie이다. 인덱스 0b01101010로 어떤 배열을 접근한다는건 왼오오왼오왼오왼으로 트리를 타고 내려가는 것이다. 실제로 칩에서 어떻게 동작할지를 상상해보면 좋다.

3
4

DeepWiki는 자체는 참 좋은데 이번에도 인간이 문제다. 문서를 한번 잘 뽑으놨으면 그걸 찬찬히 읽을 생각을해야지, 밑에 AI와의 채팅창을 달아놨더니 거기다가 게으르게 질문을 하고 앉았다. 원래 취지대로면 에너지도 절약하고 참 좋은데 말이다.

3
6

다른 페디버스 서버에서 온 메시지라 그런가, 약간 외계인이 보낸 전파 신호를 감지한 느낌이 든다.

5

통신사 해킹 사태 등의 보안 사고에 대해 IT쪽으로 조금이라도 지식이 있는 사람과 아닌 사람(e.g. 우리 엄마 아빠)의 통신사의 잘못에 대한 분노의 크기가 다른거 같다. 가령 나는 해커가 RSA2048를 해독하는 알고리즘이라도 발명해서 해킹했다면 크게 화가 안날것이다. 굿잡, 어쩔수없지 정도? 근데 이번 사고의 디테일은 몰라도 그런거랑은 전~혀 관련 없다는건 당연하다.

근데 우리 엄마도 이게 통신사의 인재라는건 아는데, 동시에 해커들도 뭔가 방어하기 어려운 첨단 기술 그런걸 썼다고 막연히 생각하는거 같다. 그래서 나처럼 통신사들이 한방에 골로 가도 할말 없을 만큼의 잘못을 저질렀다고까지 생각하고 분노하진 않는듯...

8

jules한테 시킨일을 확인했는데 건질만한 리팩토링은 한 건 이었다. 사실 TODO에 설명을 잘 써놓은게 드물어서 큰 기대를 하면 안되긴 했다(내 자신이 봐도 뭘고치라는건지 헷갈리는거 천지다)

재밌는건, 내가 예외처리를 꼼꼼하게 못한것에 대해 TODO 남겨 놓은것들이 있었는데, jules가 그것들을 많이 고쳤다. 문제는 저게 TS가 예외를 exhaustive하게 처리못하다보니 대충 넘어간건건데, jules가 올린 PR도 같은 이유로 믿고 머지할수가 없었다. 케이스가 보강되긴 했는데 완벽하게 처리한건지는 타입체커 도움 없이는 알수가 없다. AI/타입시스템의 보완적 관계에 대해서 자주 생각했는데, 정말로 구체적인 예시를 이리 쉽게 만날줄이야.

5

방금 청약홈으로 아파트 청약을 했는데, 사이트가 좀 덜컹거리긴 하지만 어쨌건 필요한 문서도 알아서 긁어와서 확인해주는등 편리하게 만들어져있었다. 맨날 불평하면서 쓰긴 하지만, 우리나라의 이런 행정전산의 수준이 세계에서 손꼽히지 않을까? 다른 나라에서 필요한서류 프린트해서 동사무소 찾아다니고 이럴거 생각하면 깜깜하다.

2

AI직원의 출근거부사태에 이어, 업데이트가 몇분째 없길래 뭐하고 있냐고 물으니까 황급하게 다시 일하기 시작했다(아마 이용자가 몰려서인것으로 예상). 졸기까지하고 사람 다 됐구만.

6
3
3

각 개인이 GPT로 지브리 스타일 프사 만드는걸 뭐라고 하고싶진 않다. 오히려 수백만명이 그걸 했다는건 미야자키 하야오가 창조한 스타일의 우수성을 직접적으로 증명한다. 미야자기 하야오 본인이 원한 방식은 아니었지만.

근데 샘 알트만이 저 기능을 광고하는 행동은 정말 꼴보기 싫었다. 일단 미야자키 하야오 본인이 그걸 매우 싫어할거란걸 몰랐을리 없는데도 그냥 강행했다. 여기선 일종의 트롤링 내지는 악의가 느껴지는데, 등산객들이 쌓아놓은 소원돌탑 무너뜨리는 행동과 비슷하다. '미신이나 믿는 멍청이들ㅎㅎ'이 '예술에 인간의 영혼 어쩌고가 들어있다고 믿는 멍청이들ㅎㅎ' 로 바뀐 것이다. 샘 알트만의 메시지는, 우리 OpenAI가 예술의 가치를 재정의했으니 너희들은 거기 적응하라는 거다.

물론 미신도 구라고 인간의 영혼 어쩌고도 구라지만, 그래도 좀 덜 asshole이 될 방법은 언제나 존재한다. 심지어 이미 이룰거 다이루고 돈도 많은 사람에겐 더 선택하기 쉽기까지 하다.

8

Nix에 GUI 툴이 부실한게 laziness를 적극적으로 쓰다보니 그런거 같다. 작은일을 하는 nix파일도 실제로 설정을 까보면 사실상 nixpkgs를 통째로 export하고 있고, 이런걸 GUI로 잘 보여주긴 힘들 것이다. public export랑 shy(?) export를 구분할수 있으면 해결되려나?

2

농담이 아니라, 어려운 문제 때문에 너무 손이 안가는 상황을 타파하려고, 어제는 일부러 autocompletion 정도만 쓰면서 손맛을 느끼며 잡다구리한 리팩토링을 했다. 그다음 설계 개선해야하는 부분을 20분 정도 하고 잤다.

2

리눅스에서 파일의 리비전을 정확하게 구할 방법이 없는거 같다. 혹시 있나요? mtime과 달리 변경될때마다 1씩 증가하는 믿을수있는 값을 원하는데, 알려진 파일시스템 중에서 이 기능을 바로 제공하는게 없어 보인다. 이런게 되면 incremental build를 정확하게 구현할수 있을텐데, 지금은 비슷한 경우에 해시 아니면 mtime 쓰는걸까.

3

사이드 프로젝트에 LLM이 쉬운 문제는 다 해치워주는 바람에 이제 머리 아픈 문제밖에 안남아서 그래서 오히려 진도가 안나가고 있다;; 아직 아무도 이 현상에 이름을 붙이지 않았다면 미리 'bgl의 역설'이란 명칭을 선점하고 싶다.

8
4

최근에 마주친 문제/주제들이 우연히 다들 '양방향' 이란 개념과 관련이 있다. 아래는 거기 관련된 러프/나이브한 생각들이다.

세션 타입

이건 노골적인 예시인데, 말그대로 서버/클라가 양방향으로 통신하는걸 기술하게 해준다.

Propagator

대부분의 프로그래밍 언어에서 x = 3 + 2과 같은 우변을 계산해서 좌변의 기호에 할당하는 기능을 제공한다.

그런데 3 = x + 2 라고 썼을때 x = 1을 해주는 언어는 거~의 없다. 이런 기능이 왜 필요하냐는 의문이 들 수 있지만, 이런 방식을 간접적으로 다들 매일 쓰고 있다. 예컨데 패키지 버전 관리를 생각해보자.

foo: >= 2.0.0
bar: =< 3.1.0 

이런 식의 설정 파일을 만지작 거릴텐데, 사실 foo >= 2.0.0, bar =< 3.1.0, ... 같은 부등식을 기술하고 있는 셈이다. 여기서 barfoo를 의존성으로 가지면 문제가 좀더 복잡해진다. 패키지 매니저는 조건을 만족하는 foo, bar의 값을 알아서 계산해준다.

요지는, 구체적인 값 대신에 조건을 나열하는 방식은 이미 다들 쓰고 있다는 얘기다. 그리고 패키지 매니징이 아닌 다른 문제에서도 이 방식이 좋은 경우는 흔하지만, 조건을 풀어서 값을 구하는 부분을 짜는게 까다로워서 도입하기 쉽지 않다.

여기서 양방향과 관련된 부분은 좌변과 우변의 정보 교환이다. x = 3 + 2x <= 3 + 2로, 우변의 정보가 일방적으로 좌변으로 간다고 볼수 있다. 반면 3 = x + 2는 좌변의 정보가 우변으로 가야한다.

x + 1 = y - 3란 예시를 보자. 이 식만 가지고는 x, y의 값을 구할 수 없다. 하지만 x = 3이란 정보가 들어오면 y = 4란걸 알 수 있고, 반대로 y = 5란 정보가 들어오면 x = 1인걸 알 수 있다. 이런 양방향 정보교환을 기술할수 있게 해주는것이 Propagator 패턴이다. Propagator 자체도 세션 타입과 뭔가 관련이 있을거 같은데, 뭐 찾아보면 오히려 서로 관련 없는게 없으니 일단 패쓰.

프로그래밍에서의 타입

모든 프로그래밍 언어는 메타프로그래밍이 가능하고, 대부분의 프로그래밍 언어는 메타프로그래밍을 할 자격이 없다. 나는 그중에서도 특히 자격이 없는 언어인 Nix로 메타프로그래밍을 하는 상황에 쳐해있다. Nix의 특성상 나뿐 아니라 다른 많은 Nix 유저들이 자연스레 이 토끼굴에 빠진다.

Nix의 에러메시지는 읽기가 참 힘든데, 기능이 매우 부족한 언어에다가 여러 개념을 새로 구현해서 얹어놔가지고, 긴 스택트레이스 중에 내가 관심있는 부분은 끝의 일부인데 거기까지의 흐름을 따라가려면 앞의 상관없는 코드도 대충은 이해해야한다. 이게 양방향 정보 교환이 잘 안되고 있는 부분이다.

알다시피 함수 자체는 단방향 정보이다. 스택트레이스는 함수를 통한 단방향 정보의 전달 과정을 보여준다. 그리고 개발자는 그걸 반대로 뒤집은 형태를 분석해야 하는 상황에 놓인다. 이게 개발자 <=> 코드 의 양방향 정보교환의 수단이 제공되지 않아서 생기는 문제다.

개발자 <=> 코드의 양방향 정보코드의 대표적인 수단은 타입이다. 타입은 코드가 스스로를 변호하고, 개발자의 잘못된 변경으로부터 방어하도록 해준다. 대부분의 언어가 메타프로그래밍을 할 자격이 없다는 얘기가, 코드 생성이라는 개발자 -> 코드의 단방향 정보전달만 기술하고 반대로 코드 -> 개발자 방향의 정보를 모조리 잃어버리는 형태로 이루어지기 때문이다.

그런데 타입안전한 메타프로그래밍은 그자체로 어려운 문제이고 아직은 연구주제에 가깝다고 알고있다. 혹시 그냥 개발자에게 뭔가 알려줄수있는 방법 자체를 primitive로 가질 순 없나? 그게 결국 타입이랑 똑같은 것일까? 여기에 TypeScript에서의(역시!) 무근본한 트릭이 소개되어있는데, 약간 관련있을지도 모른다.

7

정기적으로 하는 미니 컨퍼런스 같은게 있으면 좋겠다. 돌아가면서 각자 최근에 발견/발명한걸 부담없이(뭐 공들여 ppt만들고 이러지 말고) 발표하고 치킨 먹고 헤어지는?

8