만들다 보니, 자꾸 경계를 묻게 된다.
AI 도구를 활용해 G7 CMS로 이것저것 만들어 보면서
기능 사이의 "계약"을 자주 생각하게 된다.
하는 일은 소스코드를 한 줄씩 작성하는 것보다
AI 도구에 필요한 작업을 맡기고,
결과를 실제 적용해 다음 작업을 이어가는 식이다.
처음에는 기능을 만드는 문제였다.
"이 기능을 만들 수 있을까?"
"이 구조로 붙이면 될까?"
AI 도구를 통해 구현하고
G7에 설치해 운영 호스트에서 구동해 본다.
그런데 실제로 사용하기 시작하면
기능을 만드는 것과는 다른 문제가 보인다.
최근 광고 기능을 구현하면서도 그랬다.
광고 SDK를 불러오고
사용자 동의를 확인한 뒤 광고를 실행하는 구조를 구현할 수 있다.
그런데 G7에 붙여보니 다른 문제가 보였다.
외부 스크립트를 동적으로 불러올 때
CSP 환경의 nonce는 어디에서 받아야 할까?
GDPR 플러그인이 사용자 동의 상태를 관리한다면
다른 확장은 그 상태를 어떻게 재사용해야 할까?
로그인과 로그아웃으로 사용자 상태가 바뀌면
기존 동의 상태는 어떻게 무효화하고 다시 확인해야 할까?
기능을 만드는 문제에서
기능 사이의 경계를 확인하는 문제로 넘어가게 된다.
필요한 처리를 각 확장에 따로 구현하도록
AI 도구에 지시할 수도 있다.
당장은 동작한다.
하지만 여러 확장이 같은 문제를 각자의 방식으로 해결하면
서로 다른 규칙이 생긴다.
AI 도구로 필요한 코드를 만드는 것 자체는 어렵지 않다.
그래서 다른 질문을 하게 된다.
"이 코드를 만들 수 있는가?"
보다
"이 코드는 정말 이 확장이 가져야 하는가?"
그리고
"다른 확장이 이 기능을 재사용하려면 어떤 계약이 있어야 하는가?"
올리는 이슈의 성격도 조금 달라진다.
예전에는
"여기서 오류가 납니다."
라는 내용이 많았다면, 요즘은
"현재 구조에서는 여기까지 가능한데,
이 경계를 확장 기능에서 안정적으로 사용하려면
공식적인 전달 경로나 public contract가 필요하지 않을까요?"
라는 질문을 하기도 한다.
정답은 모른다.
코어에 다른 의도가 있을 수도 있고,
조사한 범위에서 기존 구조를 충분히 찾지 못했을 수도 있다.
그래서 먼저 구현하고 검증해 본다.
동작 결과와 관련 소스를 다시 조사하고
어디까지 가능한지 확인한 뒤 upstream에 묻는다.
여기까지는 된다.
여기부터는 애매하다.
여기서부터는 개별 확장이 결정하기보다 공통의 계약이 있는 편이 낫지 않을까.
요구한다
-> AI 도구가 조사하고 구현한다
-> 실제 G7에서 돌려본다
-> 결과를 확인한다
-> 다시 조사한다
-> 경계를 확인한다
-> 필요하면 upstream에 묻는다.
요즘 G7을 사용하면서 반복하는 과정이다.
앞서
"소스코드는 자산이 될 수 있을까?"라는 글을 올렸었다.
AI 도구를 통해 기능을 만들고 연결해 보니
이제는 다른 질문도 하게 된다.
코드를 얼마나 가지고 있는가보다
각 기능이 무엇을 책임지고
서로 어떤 계약으로 연결되는지가 명확한 구조가
더 중요한 개발 자산이 되는 것은 아닐까.
푸념해 봤습니다.
- 💫Glitter Gim
기능 사이의 "계약"을 자주 생각하게 된다.
하는 일은 소스코드를 한 줄씩 작성하는 것보다
AI 도구에 필요한 작업을 맡기고,
결과를 실제 적용해 다음 작업을 이어가는 식이다.
처음에는 기능을 만드는 문제였다.
"이 기능을 만들 수 있을까?"
"이 구조로 붙이면 될까?"
AI 도구를 통해 구현하고
G7에 설치해 운영 호스트에서 구동해 본다.
그런데 실제로 사용하기 시작하면
기능을 만드는 것과는 다른 문제가 보인다.
최근 광고 기능을 구현하면서도 그랬다.
광고 SDK를 불러오고
사용자 동의를 확인한 뒤 광고를 실행하는 구조를 구현할 수 있다.
그런데 G7에 붙여보니 다른 문제가 보였다.
외부 스크립트를 동적으로 불러올 때
CSP 환경의 nonce는 어디에서 받아야 할까?
GDPR 플러그인이 사용자 동의 상태를 관리한다면
다른 확장은 그 상태를 어떻게 재사용해야 할까?
로그인과 로그아웃으로 사용자 상태가 바뀌면
기존 동의 상태는 어떻게 무효화하고 다시 확인해야 할까?
기능을 만드는 문제에서
기능 사이의 경계를 확인하는 문제로 넘어가게 된다.
필요한 처리를 각 확장에 따로 구현하도록
AI 도구에 지시할 수도 있다.
당장은 동작한다.
하지만 여러 확장이 같은 문제를 각자의 방식으로 해결하면
서로 다른 규칙이 생긴다.
AI 도구로 필요한 코드를 만드는 것 자체는 어렵지 않다.
그래서 다른 질문을 하게 된다.
"이 코드를 만들 수 있는가?"
보다
"이 코드는 정말 이 확장이 가져야 하는가?"
그리고
"다른 확장이 이 기능을 재사용하려면 어떤 계약이 있어야 하는가?"
올리는 이슈의 성격도 조금 달라진다.
예전에는
"여기서 오류가 납니다."
라는 내용이 많았다면, 요즘은
"현재 구조에서는 여기까지 가능한데,
이 경계를 확장 기능에서 안정적으로 사용하려면
공식적인 전달 경로나 public contract가 필요하지 않을까요?"
라는 질문을 하기도 한다.
정답은 모른다.
코어에 다른 의도가 있을 수도 있고,
조사한 범위에서 기존 구조를 충분히 찾지 못했을 수도 있다.
그래서 먼저 구현하고 검증해 본다.
동작 결과와 관련 소스를 다시 조사하고
어디까지 가능한지 확인한 뒤 upstream에 묻는다.
여기까지는 된다.
여기부터는 애매하다.
여기서부터는 개별 확장이 결정하기보다 공통의 계약이 있는 편이 낫지 않을까.
요구한다
-> AI 도구가 조사하고 구현한다
-> 실제 G7에서 돌려본다
-> 결과를 확인한다
-> 다시 조사한다
-> 경계를 확인한다
-> 필요하면 upstream에 묻는다.
요즘 G7을 사용하면서 반복하는 과정이다.
앞서
"소스코드는 자산이 될 수 있을까?"라는 글을 올렸었다.
AI 도구를 통해 기능을 만들고 연결해 보니
이제는 다른 질문도 하게 된다.
코드를 얼마나 가지고 있는가보다
각 기능이 무엇을 책임지고
서로 어떤 계약으로 연결되는지가 명확한 구조가
더 중요한 개발 자산이 되는 것은 아닐까.
푸념해 봤습니다.
- 💫Glitter Gim
총 6명이 반응했습니다
|
댓글을 작성하시려면 로그인이 필요합니다.
댓글 9개
쉽게쉽게 기능개발은 G5로 현명할것으로 보입니다.
그런데 개발을 하신다는 분의 의견이라면 적어도 왜 그런지는 기술적으로 설명해 주셨으면 합니다.
이 글은 G5와 G7 중 어느 쪽이 기능 하나 만들기 쉬운지를 이야기한 글이 아닙니다.
실제로 G7의 확장 구조에서 기능을 구현하고 운영 환경에 적용해 보니,
CSP nonce 전달이나 consent state 공유처럼 개별 확장이 제각각 구현하기보다
코어와 확장 사이에 공통 contract가 필요한 경계가 보인다는 이야기입니다.
그런 글에 “G5로 하는 게 현명하다”라고 결론만 붙이면 개발자 글이라고 보기에는 조금 허전합니다.
어떤 구조적 문제 때문에 G7에서는 기능 개발을 피하는 것이 현명한지,
그리고 같은 문제를 G5에서는 어떤 구조로 더 잘 해결할 수 있는지 설명해 주시면 저도 참고하겠습니다.
개발자의 “현명함”이라면 적어도 기술적인 근거 정도는 따라와야 하지 않을까요?
광고 기능 만들면서 없는 기능까지 고려할 필요는 없죠.
sirsoft-gdpr는 이미 동의 상태를 관리하고 있고,
CSP는 적용하는 호스트에서 외부 script loader와 연결되는 문제입니다.
광고 기능을 실제로 붙여보니
이런 기능을 광고 확장이 직접 처리해야 하는지,
기존 기능의 public contract를 통해 사용해야 하는지 경계가 보였다는 이야기입니다.
실제로 CSP nonce 전달 방향은 Maintainer님도 타당하다고 답변했고,
loadScript의 trusted_script_hosts 미적용은 결함으로 확인됐습니다.
이 내용이 나온 실제 구현 과정은 앞서 AdSense 질문에 답변으로 정리해 두었습니다.
[해당 답변 링크]
모든 기능을 코어에 넣자는 이야기가 아니었습니다.
기능은 가능한 한 모듈, 플러그인, 템플릿 같은 확장 영역에 두는 것이 맞다는 생각입니다.
다만 확장들을 실제로 만들어 연결해 보니,
각 확장이 제각각 처리하기보다 공통된 방식이 필요한 부분이 보였습니다.
사용자 동의 상태,
CSP nonce 같은 보안 컨텍스트,
공통 리소스나 상태의 전달 방식 등이 그렇습니다.
CSP를 예로 들면,
CSP는 기본적으로 호스트가 응답에 적용하는 보안 정책입니다.
CSP는 광고 확장이 선택적으로 구현하는 부가기능이 아닙니다.
호스트가 CSP를 적용하고 있다면
그 호스트에서 실행되는 광고 확장 역시 이미 그 보안 정책의 적용 대상입니다.
따라서 광고 확장에서 CSP 기능을 따로 구현하자는 이야기가 아니라,
CSP를 사용하는 호스트에서 확장이 nonce를 필요로 할 때
호스트가 관리하는 보안 컨텍스트를 어떤 공식적인 경로로 전달받을 수 있는지가 문제입니다.
광고처럼 외부 스크립트를 실행하는 확장이라면
호스트의 CSP 정책과 무관하게 동작할 수 있는 것이 아니기 때문입니다.
사용자 동의 상태도 비슷합니다.
이미 다른 플러그인이 동의 상태를 관리하고 있다면
각 확장이 다시 자기 방식으로 동의 상태를 만들기보다,
필요한 확장이 그 상태를 어떤 공통된 방법으로 확인하고 사용할 수 있는지가 중요합니다.
각 확장이 이런 부분까지 자기 방식으로 구현하면
확장이 늘어날수록 서로 다른 규칙도 늘어납니다.
제가 말한 것은 이런 기능까지 코어에서 구현하자는 게 아닙니다.
기능의 구현은 확장에 두되,
여러 확장이 함께 사용할 수 있는 부분에는
공통으로 정해진 방법이 필요하지 않을까,
하는 것이 제가 말하고 싶었던 내용입니다.
이번에도 실제 기능을 만들어 운영 호스트에 돌려보고,
막히는 부분을 조사하고,
필요한 경우 upstream에 확인하면서 이런 경계를 발견했습니다.
제가 원글에서 이야기하고 싶었던 것은 이 정도입니다.
여러 의견 감사합니다. ..