아주 찰나와 같은 시간동안 집중적으로 Go언어와 함께하고 있는 아마추어가 글을 남겨도 될까 싶습니다만... Go언어는 장점과 단점이 정말 명확해서 선택하시는 분들도, 피하시는 분들도 분명한 이유가 있어 보입니다. 개인적으로 Rust 언어와 비교할 건 아닌 거 같고 Kotlin(Java)과 비교하는 게 맞는 거 같습니다.
Go의 고루틴은 정말 훌륭하지만, 마법은 아닙니다. 특히 백엔드에서 MySQL을 하나만 쓰는 작은 프로젝트에서는 이 동시성이라는 게 관리하기 정말 까다롭습니다. JS/TS런타임에서는 크게 신경 안써도 되는 MySQL 자원 고갈 현상이나 풀 관리가 생각보다 어렵거든요. 결국 이 상황에서는 DB가 병목이 되므로 Go언어의 동시성에 대한 장점이 일부 퇴색됩니다. (JS/TS 런타임의 비동기 I/O나 이벤트 루프가 오히려 더 적절할 수도 있음) 당장 hey 같은 도구로 -c 100 이렇게 때려넣어보면 알 수 있습니다.
그리고 훌륭한 GC가 있지만, 그렇다고 함부로 객체를 포인터만 넘겨서 쓰다가 뒤처리는 나몰라라 해선 안됩니다. 모든 게 트레이트오프가 있지만, Go언어도 가능하면 작은 객체들은 그냥 값 복사로 넘겨서 사용하고 함수가 끝나면 바로 처리되도록 하는게 낫습니다. 제가 낡은 사고에 같혀 있는 걸지도 모르겠지만, C/C++ 언어처럼 효율의 관점으로 포인터를 쉽게 접근하면 안되었습니다.
error 를 함수 리턴할 때 거의 매번 리턴하고 그걸 매번 if err != nil {} 로 검사해야 하는 건 정말 귀찮지만, 이건 장점입니다. try catch 보다 비용이 저렴하니까요. 그리고 finally {} 와 같은 역할을 해주는 defer 키워드도 훌륭합니다. 자원 해제 시점을 고민할 필요가 없으니 좋습니다. 표준 라이브러리만으로 훌륭한 백엔드 서버 구성이 바로 가능한 점도 좋구요 (1.23 이상) 무엇보다 타켓 OS에 맞춰 빌드하면 다른 런타임이나 사전 설치가 필요하지 읺다는 점이 가장 좋습니다.
Go언어를 길게 쓰진 않았는데 너무 개인적인 의견으로 길게 쓰는 것 같아 이만 줄입니다. ㅎㅎ 저는 Go언어도 좋고 다른 언어도 좋습니다!
비유를 들자면, 온라인 게임 롤의 캐릭터 아지르는 스플릿 운영과 한타에서의 지역장악력, 그리고 궁 밸류가 압도적으로 좋은 고티어 챔프라는 인식이 있는데, 이건 고도로 숙련된 프로 경기에서나 통하는 얘기고, 일반인 레벨에선 라인전도 너무 약하고 체급도 약해서 그저 최하티어 챔피언일 뿐이죠.
아사히 리나처럼 상위 10% 이상의 프로그래밍 및 운영체제 지식이 있는 사람들의 입장에선 RAII 이외의 안이 당연히 좋겠지만, 나머지 90%가 다루는 부분에선 RAII나 Rust만한게 없다고 생각합니다.
다만 메모리 안정성/안전성을 보장해야 하는 큰 이유 중 하나에 보안 문제가 있기 때문에... tradeoff는 불가피하다고 봅니다.
제가 Mono-repo 경험이 없어서 궁금한게 하나 있는데요. Mono Repo로 할 때, 여러 프로젝트나 서비스에 공통적인 모듈(ex. 디자인 시스템)은 각각 Mono Repo에 들어가는 식이 되나요? 아니면 얘는 어쩔 수 없이 별도의 Repo로 빠져서 참조하는 식으로 하나요?
사용해주셔서 감사합니다!
코파일럿 메인 사이트 같은 경우는 저는 잘되는데 혹시 안되시나요?
말씀하신 것처럼 피그마처럼 url 이 수시로 변하는 사이트의 경우에는 무한로딩이 일어날 수 있고,
스토어의 서비스 설명 글에 적어놓긴 했는데, 구글이 제공하는 서비스 들(gmail, drive)에서도 작동하지 않는거 같아요. 스크롤 이벤트가 감지되지 않는다든가 등의 이유 같은데, 아직 파악은 안되서 적용하지 못했습니다!
저는 회사에서나 개인 프로젝트에서느 프론트 백엔드 배치 등 구분하지 않고 하나의 git으로 관리하고 있습니다.
하위호환을 지키기보다 둘을 같이 수정하면 편한 경우도 있고요. 둘 다 팀 규모가 작아서 괜히 나눠서 좋을 게 없다고 할지... 깃허브 액션은 변경된 부분만 돌게 설정해두는 수고 정도는 감수할 만 했습니다. 무엇보다도 백엔드 프론트 구분보다는 서로가 서로에게 기여할 수 있는 게 좋다고 할까요. (프롬트 작업하다가 백엔드에 필요한 게 있으면 직접 추가하거나, 에러도 직접 고치는 등...)
요즘도 그러나요?
???: 저는 AI 가 필요하지 않았고, 여러분도 아마 필요하지 않을겁니다.
어떤 제품이건 트레이드오프가 되는 부분들이 있을텐데
아, 이거 좋네요
Cursor가 다 편한데 지금 하던거 다른 PC에서 옮겨서 하려니 답이 안나오더군요
인덱싱 해둔 Docs들, 참조용으로 작성한 Notebooks, API 키 뭐하나 동기화 되는게 없어서...
저희 회사의 경우에는 프로젝트 당 팀원이 적고 프론트엔드와 백엔드의 언어와 기술스택이 분리되어있어서 직무간 교차 기여는 거의 없었습니다. 모든 IT 시스템과 마찬가지로 결국 조직 구성을 따라가는 것 같네요
아주 찰나와 같은 시간동안 집중적으로 Go언어와 함께하고 있는 아마추어가 글을 남겨도 될까 싶습니다만... Go언어는 장점과 단점이 정말 명확해서 선택하시는 분들도, 피하시는 분들도 분명한 이유가 있어 보입니다. 개인적으로 Rust 언어와 비교할 건 아닌 거 같고 Kotlin(Java)과 비교하는 게 맞는 거 같습니다.
Go의 고루틴은 정말 훌륭하지만, 마법은 아닙니다. 특히 백엔드에서 MySQL을 하나만 쓰는 작은 프로젝트에서는 이 동시성이라는 게 관리하기 정말 까다롭습니다. JS/TS런타임에서는 크게 신경 안써도 되는 MySQL 자원 고갈 현상이나 풀 관리가 생각보다 어렵거든요. 결국 이 상황에서는 DB가 병목이 되므로 Go언어의 동시성에 대한 장점이 일부 퇴색됩니다. (JS/TS 런타임의 비동기 I/O나 이벤트 루프가 오히려 더 적절할 수도 있음) 당장 hey 같은 도구로 -c 100 이렇게 때려넣어보면 알 수 있습니다.
그리고 훌륭한 GC가 있지만, 그렇다고 함부로 객체를 포인터만 넘겨서 쓰다가 뒤처리는 나몰라라 해선 안됩니다. 모든 게 트레이트오프가 있지만, Go언어도 가능하면 작은 객체들은 그냥 값 복사로 넘겨서 사용하고 함수가 끝나면 바로 처리되도록 하는게 낫습니다. 제가 낡은 사고에 같혀 있는 걸지도 모르겠지만, C/C++ 언어처럼 효율의 관점으로 포인터를 쉽게 접근하면 안되었습니다.
error 를 함수 리턴할 때 거의 매번 리턴하고 그걸 매번 if err != nil {} 로 검사해야 하는 건 정말 귀찮지만, 이건 장점입니다. try catch 보다 비용이 저렴하니까요. 그리고 finally {} 와 같은 역할을 해주는 defer 키워드도 훌륭합니다. 자원 해제 시점을 고민할 필요가 없으니 좋습니다. 표준 라이브러리만으로 훌륭한 백엔드 서버 구성이 바로 가능한 점도 좋구요 (1.23 이상) 무엇보다 타켓 OS에 맞춰 빌드하면 다른 런타임이나 사전 설치가 필요하지 읺다는 점이 가장 좋습니다.
Go언어를 길게 쓰진 않았는데 너무 개인적인 의견으로 길게 쓰는 것 같아 이만 줄입니다. ㅎㅎ 저는 Go언어도 좋고 다른 언어도 좋습니다!
managed 서비스를 쓰면 딱히 관리에 어려움을 느끼진 못했어서,,
어떤 도구든 적당한 선에서 사용하면 유용한데 쿠버네티스는 유독 '복잡한 설정이 가능함'이 주로 비판되는 것 같다는 생각이 드네요.
클로드는 개인 계정으로는 유료로 API 못쓰게 되어 있어서 openrouter 쓰고 있는데, 커스텀 설정으로 적용하니 잘 됩니다.
약간 긴가민가 했는데, 오픈라우터도 지원한다고 안내가 있으면 자신있게 설정을 할 수 있었을 것 같습니다. ^^;
와... 이건 진짜 멋집니다!
ChatGPT MD, Obsidian Copilot, Smart Connections 등등 AI 관련 확장은 여러가지 많이 써봤는데 이 확장이 정말 좋네요!
제가 예전에 IVR 쪽 일을 했어서 그런지 이쪽에 관심이 많네요 ㅎ
a16z가 정리한 AI Voice 에이전트에 대한 모든 것 글도 함께 보세요
양쪽 다 맞는 말을 하고 있습니다.
비유를 들자면, 온라인 게임 롤의 캐릭터 아지르는 스플릿 운영과 한타에서의 지역장악력, 그리고 궁 밸류가 압도적으로 좋은 고티어 챔프라는 인식이 있는데, 이건 고도로 숙련된 프로 경기에서나 통하는 얘기고, 일반인 레벨에선 라인전도 너무 약하고 체급도 약해서 그저 최하티어 챔피언일 뿐이죠.
아사히 리나처럼 상위 10% 이상의 프로그래밍 및 운영체제 지식이 있는 사람들의 입장에선 RAII 이외의 안이 당연히 좋겠지만, 나머지 90%가 다루는 부분에선 RAII나 Rust만한게 없다고 생각합니다.
다만 메모리 안정성/안전성을 보장해야 하는 큰 이유 중 하나에 보안 문제가 있기 때문에... tradeoff는 불가피하다고 봅니다.
rn은 꾸준히 업데이트 하는데 메이저 버전은 언제 나올런지..
제가 Mono-repo 경험이 없어서 궁금한게 하나 있는데요. Mono Repo로 할 때, 여러 프로젝트나 서비스에 공통적인 모듈(ex. 디자인 시스템)은 각각 Mono Repo에 들어가는 식이 되나요? 아니면 얘는 어쩔 수 없이 별도의 Repo로 빠져서 참조하는 식으로 하나요?
오 이건 꼭 써보고 싶네요
개발하시느라 고생하셧습니다
사용해주셔서 감사합니다!
코파일럿 메인 사이트 같은 경우는 저는 잘되는데 혹시 안되시나요?
말씀하신 것처럼 피그마처럼 url 이 수시로 변하는 사이트의 경우에는 무한로딩이 일어날 수 있고,
스토어의 서비스 설명 글에 적어놓긴 했는데, 구글이 제공하는 서비스 들(gmail, drive)에서도 작동하지 않는거 같아요. 스크롤 이벤트가 감지되지 않는다든가 등의 이유 같은데, 아직 파악은 안되서 적용하지 못했습니다!
World of Warcraft 기반으로 만들라고 했더니, 아는 캐릭터들로 주요 말들을 생성해주네요.
그러고는 상대방은 자동으로 League of Legends 테마를 잡아서 싸우게 합니다 ㅎㅎ
사용해주셔서 감사합니다~
맞아요 저도 그런 경험 때문에 만들게 된게 커요!
한국인이 직접 번역한게 아니면 아직 자연스럽지가 않더라고요, 아직 gpt 의 번역을 크롬번역이 따라가지도 못하는거 같구요
저는 회사에서나 개인 프로젝트에서느 프론트 백엔드 배치 등 구분하지 않고 하나의 git으로 관리하고 있습니다.
하위호환을 지키기보다 둘을 같이 수정하면 편한 경우도 있고요. 둘 다 팀 규모가 작아서 괜히 나눠서 좋을 게 없다고 할지... 깃허브 액션은 변경된 부분만 돌게 설정해두는 수고 정도는 감수할 만 했습니다. 무엇보다도 백엔드 프론트 구분보다는 서로가 서로에게 기여할 수 있는 게 좋다고 할까요. (프롬트 작업하다가 백엔드에 필요한 게 있으면 직접 추가하거나, 에러도 직접 고치는 등...)
raii 가 없이는 경험이 상대적으로 부족한 개발자는 버그를 양산하게 될것 같음
os말고 응용프로그램 수준에서는 적어도...