2024.11.17 전문가로서의 LLM

Q. 과거의 대화로부터 추측해 알 수도 있겠지만, 저는 스타트업을 창업할 준비를 하고 있습니다. 이미 저번의 창업에서 성공을 경험했지만 새롭게 다시 창업을 하려고 생각하니 많은 것이 두렵습니다. 실패할 확률이 높다는 것을 알지만 그래서 실패할 것이 두렵습니다. 사업을 하는 과정에서 다른 사람들에게 실망하고 배신당할 것이 두렵습니다. 내가 최선을 다한 결과가 만족스럽지 않을 것이 두렵습니다. 어떤 마음가짐을 가지면 좋을까요? 조언도 위로도 어떤 말도 좋습니다. LLM은 어떤 이야기를 해 줄 수 있는지 궁금합니다. --- A. 스타트업 창업을 준비하면서 느끼는 두려움과 불안은 매우 자연스러운 감정입니다. 당신이 과거의 성공 경험을 가지고 있음에도 불구하고, 새롭게 도전하는 길에 대한 부담감은 오히려 당신이 얼마나 진지하게 이 일을 고민하고 있는지를 보여줍니다. 그 마음 자체가 이미 당신이 진정성을 가지고 임하고 있다는 증거입니다. 다음의 생각과 마음가짐이 조금이라도 도움이 되길 바랍니다. --- ### 1. 두려움을 인정하세요 두려움은 실패를 피하려는 인간의 본능적인 반응입니다. 이를 부정하거나 억누르기보다는, "내가 두려워하는 이유는 무엇인가?"를 솔직히 탐구해보세요. 두려움을 명확히 정의하면 그 감정을 다루기가 훨씬 수월해집니다. **예:** - 실패가 두렵다면, 실패를...

요 며칠 쿠버네티스 컨트롤 플레인을 이런저런 방식으로 한 50번쯤 새로 구축한 것 같다. 여러가지 설정이나 배포판이나 구성들도 시험해 보고, 바닐라 상태로 자유롭게 설정하는 것도 실험해 보면서 또 몰랐던 것도 많이 배우고 있다. 회사 이름인 'keeban'은 '기반'에서 따온 것인데, 기반의 기반을 만드는 일이라 생각하니 신중해지는 것 같다. 아마도 이것이 서비스에 가장 중요한 요소라는 판단이 들어서일텐데, 또 이 고민을 꼭 지금 해야 하는가, 지금 적당히 해 놓고 나중에 언젠가 시간과 인력이 좀 더 충원되면 할 수도 있지 않을까 싶어서 내일까지만 해볼까 싶다.

코드 스멜이 좀 있어서 전반적으로 리팩토링을 하는데 생각보다 길어져서 하루만에 못끝냈다. 초벌을 작성할 때는 오히려 코파일럿이 도와줄만한 부분이 훨씬 많다고 보는데, 좀 길어진 함수나 클래스를 리팩토링하는건 LLM에게 시켜봐도 뭔가 삐걱삐걱하고 영 미덥지가 못하다. 제일 흔한 패턴은 긴 컨텍스트를 주었을 때 뒷부분을 좀 빼먹거나 뒤로 갈수록 코드의 해상도(?)가 약간 흐려지는 현상이 있는데, 결국 리팩토링될 대상을 또 눈으로 검증하고 테스트도 그에 맞춰서 좀 잡아주고 해야 해서 그냥 손으로 하는 것보다 딱히 빠르다는 느낌이 들지 않았고.. 또 리팩토링을 하는 과정에서 API 포맷이 묘하게 바뀌어 창작되는 경우도 있었다. 특히 다른 파일로 넘어가면 컨텍스트 유지가 되는듯 마는듯 잘 안되고.. 계속 써 보면서 느끼는 것은, LLM이 가장 실수를 많이 하는 경우는 주로 마이너한 언어나 라이브러리를 사용할 때 자꾸만 API 형식을 지 맘대로 창작하는 경향이 있는데, 이걸 그냥 공식문서 전체 링크를 읽으라고 던져놓고 참고하게 하는 방법은 없을까 궁금했는데, 블스에 올렸더니 어떤 분이 답을 주셨다. https://docs.github.com/en/copilot/building-copilot-extensions/about-building-copilot-extensions 이런 식으로 서드파티들이 알아서 문서 먹여서 만들 수 있는 인터페이스를 주는 방식인 것 같은데, 올해 5월에 처음 발표되고 9월에 베타로 들어갔으니 곧 혜택을 볼 수 있는 여지가 있을 것 같다. 서드파티들이 안움직이면 좀 곤란하지만..

쿠버네티스는 클러스터의 데이터나 상태를 저장하기 위해서 내부적으로 etcd라는 DB를 쓰는데, 내가 원하는 전체적인 시스템 설계를 이리저리 그려보다가 etcd에 데이터를 저장할거면 왜 쿠버네티스 클러스터 노드 안에 있어야 하지? 시스템이 죽으면 etcd를 이용해서 살려야 할거고 etcd가 죽으면 클러스터가 죽어버려서 서로 강결합 되어 있는데, 밖에 있는게 맞는게 아닌가? 이런 생각을 하고 찾아 보니 문서에 'High Availability 구성을 하기 위해서는 etcd를 밖으로 뺄 수도 있어요'라는 대목을 찾았다. 한편 fault-tolerant한 시스템을 만들기 위한 여러 가지 재료들이 있는데 분산처리도 그 중 하나이다. 노드를 세대 ...

쿠버네티스를 좀 여유를 가지고 뜯어보고 있다. 원래 사용할 때는 주로 현업에 급해서 좀 피상적으로 쓰면서 쓸데없는 의문을 갖지 않고 쭉쭉 구현하기에 급급했었는데, 이번에는 쿠버네티스에 대한 이해가 제품 성패에 바로 연결될 것 같아서 허투루 넘기지 않고 문서나 책들을 찬찬히 보고 있다. 보통 새로운 기술을 공부할 때 내가 신경쓰는건, 이 기술을 개발한 사람들은 1) 어떤 문제를 풀고 싶은가, 2) 어떤 방식으로 풀고 싶은가, 3) 그렇게 결정한 배경이나 이유는 무엇인가 이다. 그래서 API 설계든 아키텍쳐든 보다 보면 처음 쿠버네티스를 만든 사람이 왜 이런 설계에 이런 선택을 한 것인지, 중간에 어떤 컴포넌트를 아예 갈아엎고 deprecate 시킨 역사가 있다면 처음엔 어떤 생각이었고 어떤 실패를 겪은 것인지, 그리고 어떻게 해결해야 한다고 생각했는지 이런 것들을 볼 수 있어서 좋은 것 같다. 학계에 있는 사람들은 주로 마지막 최종_진짜최종_진짜진짜최종 결과물들을 접하게 될 경우가 많은데, 이 업계는 그런 히스토리들이 문서로 계속 공개되고 남아있다는 점에서 좀 더 좋은 것 같다.