ActivityPub 도입 해볼만할까요? 정보
ActivityPub 도입 해볼만할까요?
본문
가끔 한국에서 개발되는 CMS(그누보드, 제로보드 등)이 최신 개발 동향은 하나도 안따른다고 까이는(...) 경우를 종종 보는데 특히 그누보드가 심하게 비판받는 것 같더군요... (Wordpress는 더 심한 것 같은데 면죄부인거냐...?)
제가 보기엔 이정도면 매우 훌륭한거 아닌가 싶은데...? 마음이 아플때가 많습니다. ㅠㅠ
아무튼 여기에 대항할만한 괜찮은 무기가 없을까 고민하고 있던 참입니다.
고민하던 중 ActivityPub 라는 프로토콜을 찾았습니다. 프로토콜만 맞추면 마스토돈(Mastodon) 같은 분산형 소셜 미디어하고도 통신도 되고, 나름 최신 SEO 기술 넣었다고 우기기에도 좋을 것 같더군요.
틈틈히 문서보면서 작성을 해볼까하는데 그누보드의 컨텐츠가 다른 플랫폼에도 그대로 연동되는 기반이 마련된다면 좋은 점이 있을까요..?
추천
2
2
베스트댓글
기술의 종류나 어떤 기술이 새롭거나 우위에 있는지는 중요하지 않습니다.
저도 관련 내용을 몇 번 업급했는데 그 구현 방법이 REST API이든 GraphQL이든 상관은 없지만 그걸 구현할 환경을 마련하는데 많은 비용이 든다는게 문제입니다.
그누보드는 대부분 지극히 절차지향적인 코드로 구성되어있습니다. 약간의 경험과 모험만하면 비개발자도 어렵지 않게 찾아서 뭔가를 고쳐쓰기는 좋은편이죠.
다만, 뷰와 로직이 너무 결합되어있습니다. 이건 절차향적 프로그램의 특성은 아니지만 쉽게 뷰와 로직이 뒤섞여 버리는 문제를 만들기는 합니다. 특히 웹용 소프트웨어 특히 PHP에서는 더욱 그렇죠.
rest든 graphql이든 말씀하신 activitypub이든 그누보드에서 뷰와 로직의 결합을 풀어내지 않으면 구현이 어렵습니다. 몇몇 분들이 공개한 그누보드 API 지원 솔루션들이 그누보드와는 별개로 로직을 복사해가서 디비와 직접 통신하는 방법을 주로 사용합니다.
그누보드의 뷰와 로직의 분리를하려면 그누보드의 많은 부분을 수정해야하는데 수정 방법을 코드로 하나하나 알려줄수도 없고 냑의 그누보드 패치도 따라가야하고 완전히 별개의 프로그램이라서 기존의 플러그인도 사용할수 없죠.
지금도 공개된 몇가지의 API 지원 코드 저장소가 깃허브에 있어서 당장 사용 가능하지만 보안취약점이나 오류 등 패치를 따라가고 있지도 않고 해당 개발자 또한 그런 노력을 계속해야할 이유는 찾지 못할것 같습니다.
결국은 냑의 의지에 달렸다고 생각합니다.
점진적 향상을 통해 호환성을 지켜내면서 할수있는 것들을 하면서 다소 호환성은 깨지더라도 다음 세대를 준비해야겠죠.
하지만 그누보드를 이용하는 대다수의 성향에 맞지않죠. 어려움이 있죠. 당장 뭘 어떻게 변화를 주기는 어렵고 반발도 매우 클거라 봅니다. 이러한 이슈들이 자게에 나오면 그누에 애정을 비치며 변화를 바라지 않는 다는 의견이 대다수를 차지하니까요. 하지만 호환성을 유지하며 점진적으로 개선해 나갈 방법은 보이며 그누보드를 더 잘아는 개발자 분들에게는 저보다 많은게 보일거라고 봅니다.
그누보드의 코드는 낡았습니다.
낡았다고 그저 흉만보려는것도 아니고 최신 기술들을 다 갖다 붙이라는 것도 아닙니다.
잘 돌아가는 코드를 건드리는건 쉽지도 않고 어쩌면 개발자들에겐 불문율이기 때문에 쉽지는 않죠.
현재 그누보드에 없는 기술들을 죄다 도입할 필요도 없고 그럴수도 없겠죠. 다만, 환경은 마련해줘야할 필요는 있습니다. 하나씩 개선되면 누군가에게 필요한 무언가를 완전히 별개가 아닌 플러그인 형태로도 만들어 낼수 있을겁니다.
지금은 로직 분리의 미흡으로 사실상 어려운 상태죠. 말씀하신 기술의 도입 또한 같은 문제를 겪을수밖에 없는 상황이고요.
저도 관련 내용을 몇 번 업급했는데 그 구현 방법이 REST API이든 GraphQL이든 상관은 없지만 그걸 구현할 환경을 마련하는데 많은 비용이 든다는게 문제입니다.
그누보드는 대부분 지극히 절차지향적인 코드로 구성되어있습니다. 약간의 경험과 모험만하면 비개발자도 어렵지 않게 찾아서 뭔가를 고쳐쓰기는 좋은편이죠.
다만, 뷰와 로직이 너무 결합되어있습니다. 이건 절차향적 프로그램의 특성은 아니지만 쉽게 뷰와 로직이 뒤섞여 버리는 문제를 만들기는 합니다. 특히 웹용 소프트웨어 특히 PHP에서는 더욱 그렇죠.
rest든 graphql이든 말씀하신 activitypub이든 그누보드에서 뷰와 로직의 결합을 풀어내지 않으면 구현이 어렵습니다. 몇몇 분들이 공개한 그누보드 API 지원 솔루션들이 그누보드와는 별개로 로직을 복사해가서 디비와 직접 통신하는 방법을 주로 사용합니다.
그누보드의 뷰와 로직의 분리를하려면 그누보드의 많은 부분을 수정해야하는데 수정 방법을 코드로 하나하나 알려줄수도 없고 냑의 그누보드 패치도 따라가야하고 완전히 별개의 프로그램이라서 기존의 플러그인도 사용할수 없죠.
지금도 공개된 몇가지의 API 지원 코드 저장소가 깃허브에 있어서 당장 사용 가능하지만 보안취약점이나 오류 등 패치를 따라가고 있지도 않고 해당 개발자 또한 그런 노력을 계속해야할 이유는 찾지 못할것 같습니다.
결국은 냑의 의지에 달렸다고 생각합니다.
점진적 향상을 통해 호환성을 지켜내면서 할수있는 것들을 하면서 다소 호환성은 깨지더라도 다음 세대를 준비해야겠죠.
하지만 그누보드를 이용하는 대다수의 성향에 맞지않죠. 어려움이 있죠. 당장 뭘 어떻게 변화를 주기는 어렵고 반발도 매우 클거라 봅니다. 이러한 이슈들이 자게에 나오면 그누에 애정을 비치며 변화를 바라지 않는 다는 의견이 대다수를 차지하니까요. 하지만 호환성을 유지하며 점진적으로 개선해 나갈 방법은 보이며 그누보드를 더 잘아는 개발자 분들에게는 저보다 많은게 보일거라고 봅니다.
그누보드의 코드는 낡았습니다.
낡았다고 그저 흉만보려는것도 아니고 최신 기술들을 다 갖다 붙이라는 것도 아닙니다.
잘 돌아가는 코드를 건드리는건 쉽지도 않고 어쩌면 개발자들에겐 불문율이기 때문에 쉽지는 않죠.
현재 그누보드에 없는 기술들을 죄다 도입할 필요도 없고 그럴수도 없겠죠. 다만, 환경은 마련해줘야할 필요는 있습니다. 하나씩 개선되면 누군가에게 필요한 무언가를 완전히 별개가 아닌 플러그인 형태로도 만들어 낼수 있을겁니다.
지금은 로직 분리의 미흡으로 사실상 어려운 상태죠. 말씀하신 기술의 도입 또한 같은 문제를 겪을수밖에 없는 상황이고요.
마스토돈 인스턴스인 애니워크 네트워크 인스턴스를 운영하고 있습니다.
저는 액펍 도입에는 긍정적인 입장이지만,
그누보드가 액펍을 도전하기엔 과제가 많습니다.
노드js나 파이썬, 스프링 처럼 직접 데몬이 돌아가지 않는 구조가 이상 힘듭니다.
그리고 타 연합과의 호환성도 고려해야하는데, 이게 참 애매하네요.
그 외엔 글과 사진 등의 간단한 마이크로블로깅에는 괜찮다고 봅니다.
저도 마스토돈을 버리고 액펍을 개인적으로 도입할까 생각 많이 했습니다.
저는 액펍 도입에는 긍정적인 입장이지만,
그누보드가 액펍을 도전하기엔 과제가 많습니다.
노드js나 파이썬, 스프링 처럼 직접 데몬이 돌아가지 않는 구조가 이상 힘듭니다.
그리고 타 연합과의 호환성도 고려해야하는데, 이게 참 애매하네요.
그 외엔 글과 사진 등의 간단한 마이크로블로깅에는 괜찮다고 봅니다.
저도 마스토돈을 버리고 액펍을 개인적으로 도입할까 생각 많이 했습니다.
@투엑스비 기술문서 읽는 법? 방법이 따로있다기보단 많이 읽는게 중요하죠 ㅎㅎ
댓글 6개
기술의 종류나 어떤 기술이 새롭거나 우위에 있는지는 중요하지 않습니다.
저도 관련 내용을 몇 번 업급했는데 그 구현 방법이 REST API이든 GraphQL이든 상관은 없지만 그걸 구현할 환경을 마련하는데 많은 비용이 든다는게 문제입니다.
그누보드는 대부분 지극히 절차지향적인 코드로 구성되어있습니다. 약간의 경험과 모험만하면 비개발자도 어렵지 않게 찾아서 뭔가를 고쳐쓰기는 좋은편이죠.
다만, 뷰와 로직이 너무 결합되어있습니다. 이건 절차향적 프로그램의 특성은 아니지만 쉽게 뷰와 로직이 뒤섞여 버리는 문제를 만들기는 합니다. 특히 웹용 소프트웨어 특히 PHP에서는 더욱 그렇죠.
rest든 graphql이든 말씀하신 activitypub이든 그누보드에서 뷰와 로직의 결합을 풀어내지 않으면 구현이 어렵습니다. 몇몇 분들이 공개한 그누보드 API 지원 솔루션들이 그누보드와는 별개로 로직을 복사해가서 디비와 직접 통신하는 방법을 주로 사용합니다.
그누보드의 뷰와 로직의 분리를하려면 그누보드의 많은 부분을 수정해야하는데 수정 방법을 코드로 하나하나 알려줄수도 없고 냑의 그누보드 패치도 따라가야하고 완전히 별개의 프로그램이라서 기존의 플러그인도 사용할수 없죠.
지금도 공개된 몇가지의 API 지원 코드 저장소가 깃허브에 있어서 당장 사용 가능하지만 보안취약점이나 오류 등 패치를 따라가고 있지도 않고 해당 개발자 또한 그런 노력을 계속해야할 이유는 찾지 못할것 같습니다.
결국은 냑의 의지에 달렸다고 생각합니다.
점진적 향상을 통해 호환성을 지켜내면서 할수있는 것들을 하면서 다소 호환성은 깨지더라도 다음 세대를 준비해야겠죠.
하지만 그누보드를 이용하는 대다수의 성향에 맞지않죠. 어려움이 있죠. 당장 뭘 어떻게 변화를 주기는 어렵고 반발도 매우 클거라 봅니다. 이러한 이슈들이 자게에 나오면 그누에 애정을 비치며 변화를 바라지 않는 다는 의견이 대다수를 차지하니까요. 하지만 호환성을 유지하며 점진적으로 개선해 나갈 방법은 보이며 그누보드를 더 잘아는 개발자 분들에게는 저보다 많은게 보일거라고 봅니다.
그누보드의 코드는 낡았습니다.
낡았다고 그저 흉만보려는것도 아니고 최신 기술들을 다 갖다 붙이라는 것도 아닙니다.
잘 돌아가는 코드를 건드리는건 쉽지도 않고 어쩌면 개발자들에겐 불문율이기 때문에 쉽지는 않죠.
현재 그누보드에 없는 기술들을 죄다 도입할 필요도 없고 그럴수도 없겠죠. 다만, 환경은 마련해줘야할 필요는 있습니다. 하나씩 개선되면 누군가에게 필요한 무언가를 완전히 별개가 아닌 플러그인 형태로도 만들어 낼수 있을겁니다.
지금은 로직 분리의 미흡으로 사실상 어려운 상태죠. 말씀하신 기술의 도입 또한 같은 문제를 겪을수밖에 없는 상황이고요.
저도 관련 내용을 몇 번 업급했는데 그 구현 방법이 REST API이든 GraphQL이든 상관은 없지만 그걸 구현할 환경을 마련하는데 많은 비용이 든다는게 문제입니다.
그누보드는 대부분 지극히 절차지향적인 코드로 구성되어있습니다. 약간의 경험과 모험만하면 비개발자도 어렵지 않게 찾아서 뭔가를 고쳐쓰기는 좋은편이죠.
다만, 뷰와 로직이 너무 결합되어있습니다. 이건 절차향적 프로그램의 특성은 아니지만 쉽게 뷰와 로직이 뒤섞여 버리는 문제를 만들기는 합니다. 특히 웹용 소프트웨어 특히 PHP에서는 더욱 그렇죠.
rest든 graphql이든 말씀하신 activitypub이든 그누보드에서 뷰와 로직의 결합을 풀어내지 않으면 구현이 어렵습니다. 몇몇 분들이 공개한 그누보드 API 지원 솔루션들이 그누보드와는 별개로 로직을 복사해가서 디비와 직접 통신하는 방법을 주로 사용합니다.
그누보드의 뷰와 로직의 분리를하려면 그누보드의 많은 부분을 수정해야하는데 수정 방법을 코드로 하나하나 알려줄수도 없고 냑의 그누보드 패치도 따라가야하고 완전히 별개의 프로그램이라서 기존의 플러그인도 사용할수 없죠.
지금도 공개된 몇가지의 API 지원 코드 저장소가 깃허브에 있어서 당장 사용 가능하지만 보안취약점이나 오류 등 패치를 따라가고 있지도 않고 해당 개발자 또한 그런 노력을 계속해야할 이유는 찾지 못할것 같습니다.
결국은 냑의 의지에 달렸다고 생각합니다.
점진적 향상을 통해 호환성을 지켜내면서 할수있는 것들을 하면서 다소 호환성은 깨지더라도 다음 세대를 준비해야겠죠.
하지만 그누보드를 이용하는 대다수의 성향에 맞지않죠. 어려움이 있죠. 당장 뭘 어떻게 변화를 주기는 어렵고 반발도 매우 클거라 봅니다. 이러한 이슈들이 자게에 나오면 그누에 애정을 비치며 변화를 바라지 않는 다는 의견이 대다수를 차지하니까요. 하지만 호환성을 유지하며 점진적으로 개선해 나갈 방법은 보이며 그누보드를 더 잘아는 개발자 분들에게는 저보다 많은게 보일거라고 봅니다.
그누보드의 코드는 낡았습니다.
낡았다고 그저 흉만보려는것도 아니고 최신 기술들을 다 갖다 붙이라는 것도 아닙니다.
잘 돌아가는 코드를 건드리는건 쉽지도 않고 어쩌면 개발자들에겐 불문율이기 때문에 쉽지는 않죠.
현재 그누보드에 없는 기술들을 죄다 도입할 필요도 없고 그럴수도 없겠죠. 다만, 환경은 마련해줘야할 필요는 있습니다. 하나씩 개선되면 누군가에게 필요한 무언가를 완전히 별개가 아닌 플러그인 형태로도 만들어 낼수 있을겁니다.
지금은 로직 분리의 미흡으로 사실상 어려운 상태죠. 말씀하신 기술의 도입 또한 같은 문제를 겪을수밖에 없는 상황이고요.
마스토돈 인스턴스인 애니워크 네트워크 인스턴스를 운영하고 있습니다.
저는 액펍 도입에는 긍정적인 입장이지만,
그누보드가 액펍을 도전하기엔 과제가 많습니다.
노드js나 파이썬, 스프링 처럼 직접 데몬이 돌아가지 않는 구조가 이상 힘듭니다.
그리고 타 연합과의 호환성도 고려해야하는데, 이게 참 애매하네요.
그 외엔 글과 사진 등의 간단한 마이크로블로깅에는 괜찮다고 봅니다.
저도 마스토돈을 버리고 액펍을 개인적으로 도입할까 생각 많이 했습니다.
저는 액펍 도입에는 긍정적인 입장이지만,
그누보드가 액펍을 도전하기엔 과제가 많습니다.
노드js나 파이썬, 스프링 처럼 직접 데몬이 돌아가지 않는 구조가 이상 힘듭니다.
그리고 타 연합과의 호환성도 고려해야하는데, 이게 참 애매하네요.
그 외엔 글과 사진 등의 간단한 마이크로블로깅에는 괜찮다고 봅니다.
저도 마스토돈을 버리고 액펍을 개인적으로 도입할까 생각 많이 했습니다.
@한빛가람 저도 원래 마스토돈을 밀어보려고 했다가 UX 자체가 우리나라 사람들한테는 친근하지 않은 느낌이라... 이미 우리나라에서 익숙한 기반을 사용하되 액펍 프로토콜만 가져올 방법에 대해 생각하게 되더군요...
액펍을 별도의 게이트웨이 서버로 만든다고 하면 문제는 아닐 수도 있을겁니다. 한창 블록체인 뜰 때 그누보드에 이 더러움(?) 컨트랙트 연동도 그렇게 했었던 기억이 있어서....
문제는... AcvitityPub 정도 규모의 프로토콜이면 적은 스크립트로도 가능할 것도 같은데 굳이 클라우드 서버까지 별도로 파서 그렇게 거창하게 해야되나?? 하는 의문이... 들더군요. 데몬 방식이 아니여도 가능하지 않을까라는 막연한 긍정?
명확해지려면 더 살펴봐야할 것 같습니다. ㅠㅠ 이미 어쩔 수 없이 뿌리깊게 박힌 한국적인 시스템을 (장점을 살리는 쪽으로) 그대로 가져가되 거기에 더해서 국외 시스템과 호환성 측면에서도 밀리지 않는 방법이 무엇일까 고민되네요.
문제는... AcvitityPub 정도 규모의 프로토콜이면 적은 스크립트로도 가능할 것도 같은데 굳이 클라우드 서버까지 별도로 파서 그렇게 거창하게 해야되나?? 하는 의문이... 들더군요. 데몬 방식이 아니여도 가능하지 않을까라는 막연한 긍정?
명확해지려면 더 살펴봐야할 것 같습니다. ㅠㅠ 이미 어쩔 수 없이 뿌리깊게 박힌 한국적인 시스템을 (장점을 살리는 쪽으로) 그대로 가져가되 거기에 더해서 국외 시스템과 호환성 측면에서도 밀리지 않는 방법이 무엇일까 고민되네요.
그런걸 알려면 뭐부터 배워야하나요
@투엑스비 기술문서 읽는 법? 방법이 따로있다기보단 많이 읽는게 중요하죠 ㅎㅎ
