<?xml version="1.0" encoding="utf-8"?><feed xmlns="http://www.w3.org/2005/Atom" ><generator uri="https://jekyllrb.com/" version="4.4.1">Jekyll</generator><link href="https://sbeholder32167.github.io/feed.xml" rel="self" type="application/atom+xml" /><link href="https://sbeholder32167.github.io/" rel="alternate" type="text/html" /><updated>2026-11-13T11:29:08+09:00</updated><id>https://sbeholder32167.github.io/feed.xml</id><title type="html">HS Workshop</title><subtitle>Write an awesome description for your new site here. You can edit this line in _config.yml. It will appear in your document head meta (for Google search results) and in your feed.xml site description.</subtitle><author><name>Silent Beholder</name></author><entry><title type="html">Secret Note App 무료화</title><link href="https://sbeholder32167.github.io/posts/2026-11-13-posts-discuss_secretnote/" rel="alternate" type="text/html" title="Secret Note App 무료화" /><published>2026-11-13T10:10:00+09:00</published><updated>2026-11-13T10:10:00+09:00</updated><id>https://sbeholder32167.github.io/posts/posts-discuss_secretnote</id><content type="html" xml:base="https://sbeholder32167.github.io/posts/2026-11-13-posts-discuss_secretnote/"><![CDATA[<p><br />
광고 없이 완전 무료화로 전환하였습니다.
<br /></p>
<hr />

<div style="display: flex; align-items: center; gap: 12px; padding: 12px; border: 1px solid #e1e4e8; border-radius: 20px;background-color:white;">
  <img src="/assets/images/secret_note_icon.jpg" alt="Secret note Icon" style="width: 96px;height: 96px;object-fit: contain;border-radius:30px;margin:0 20px 0 20px;" />
  <div>
    <h4 style="margin: 0 0 4px 0; font-size: 24px; font-weight: 600;">Secret Note</h4>
  </div>
</div>
<p><br /></p>
<div style="font-size:18px;">
오늘은 제 첫 앱인 Secret Note의 무료화 업데이트에 관련하여 포스트를 올립니다.<br />
원래 무료 앱으로 기획하고 출시했지만, 약간의 수익도 추구했습니다.<br />
비밀번호를 관리하는 앱에 무슨 광고 수익이냐 의문을 가지실 수도 있겠지만,<br />
안전한 보관과 그 보관을 위한 동작에 따른 수고비(?) 정도로 생각되었으면 합니다.<br />
기획 자체도, 일반적으로 앱을 사용시마다 광고를 시청하는 것이 아닌,<br /> 
단 시간에 많은 데이터를 저장하고 싶은 사용자만 광고를 시청하도록 했었습니다.<br />
하루에 무료 충전량이 있지만, 더 필요하신 분은 광고를 이용하시라는 취지였습니다.<br />
<br />
<hr />

이번에 광고를 제거한 것은 "구글의 판매자 선언"과 관련이 있습니다.<br />
유럽 지역에서 광고를 포함한 어떠한 수익이라도 얻는 "판매자"로서 앱을 배포하려면,<br />
개발사의 주소와 전화번호등을 모두 낱낱이 공개하라는 것이었습니다.<br />
일반적인 기업이라면, 굳이 큰 영향이 없을 거라고 생각합니다.<br />
어차피 기업 주소와 전화번호는 공개해야하는 데이터들이고,<br />
조직 내 직원들의 '개인정보'가 노출되지는 않습니다.<br />
하지만 저같은 1인 개발자에게는 '개인정보'를 전 세계에 노출하라는 협박으로 들렸습니다.<br />
보안 앱을 만드는 제가, 제 개인정보 노출 하나 방지할 생각하지 않는다면 그것도 말이 안되겠지요.<br />
<br />
<hr />
제 생각에는, 구글도 저같은 1인 개발자의 이런 고충을 알고 있었다고 생각됩니다.<br />
그 근거로서, '유럽 지역에 배포하지 않는 경우, 비판매자로 선언할수 있다'라는 예외조항을 생각해볼수 있습니다.<br />
구글의 안내문에 직접 그 예외의 내용을 '명기'한 것은,<br />
1인 개발자의 이탈을 최소한으로 유지해보겠다는 의도가 있는 것이 아닌가 싶었습니다.<br />
하지만, 그 점에 있어서 AI는 한가지 주의점을 알려주더군요.<br />
지금은 이 정책이 유럽에 국한될지라도, 추후 전세계로 확장되는 것은 시간문제라고 말이죠.<br />
그 이유로, 개인 개발자들의 수익이 구글에게 별로 큰 비율이 되지 않음을 들었습니다.<br />
틀린 의견이 아니라고 생각됩니다.<br />
그러면서 완전히 수익을 내지 않는 무료 앱으로 전환할 것을 제안하더군요.<br />
그것 또한 구글의 바램이 아닐까 싶습니다. 개인 자격으로는 수익낼 생각하지 말라고요.<br />
AI는 그들 기업의 정책과 그들의 성향대로 답변하지 않습니까?<br />
구글 AI가 한 답변의 의미는 곧 구글의 의도로 연결된다고 생각합니다.<br />
<br />
<hr />
그래서 고민하게 되었습니다.<br />
광고 자체를 없애고 완전 무료화로 진행할 것인지,<br /> 
유럽 지역만 배포를 중지하고 추가적인 수정 없이 계속 인앱 광고가 포함된 앱으로 지속할지를 선택해야 했습니다.<br />
아직까지는 예외조항이 효력이 있으니, 유럽지역 배포만 해제하는 것은 코드 로직 변경에 비해 아주 쉬운 일입니다.<br />
광고 수익은 이 판단에 크게 중요하지 않았습니다.<br /> 
제 앱 써보신 분들이라면 아시겠지만, 광고로 돈 벌수있는 기획이 아닙니다.<br />
관리해야할 비밀번호가 갑자기 많이 늘어나서 잔뜩 저장해야 할 상황이 벌어질 빈도가 한해애 얼마나 될까요?<br />
이 판단에 가장 중요한 변수는 저의 공수였다고 생각합니다.<br />
'어차피 수익도 나지 않는데, 굳이 서비스할 필요가 있나?' 라고 생각하여 배포 트랙에서 내려버리는 것도 한 방법이겠지요.<br />
하지만 저는 이 앱을 완전 무료화로 전환하고 광고를 제거한 후 재 배포하는 것으로 결정했습니다.<br />

<hr />
유럽의 사용자들에게 '갑자기 정책때문에 배포를 중지합니다'는 공지만 띄우고 배포를 중단하고 싶지는 않았습니다.<br />
제 앱 사용자 분들이 많지는 않습니다만, 그 중에 유럽 사용자 분들도 있습니다.<br />
제 보잘것 없는 작은 앱을 이용해 주시는 분들이지요.<br />
처음에 사용자 한분 한분 늘어나는 것이 참 만족스럽고 즐거운 경험이었습니다.<br />
갑자기 제가 배포를 저런 정책때문에 중단한다면, 사용자 분들은 이해는 하면서도 한편으로는 배신감을 느낄수 있다고 생각합니다.<br />
이 앱은 비밀번호를 관리하는 앱입니다.<br />
앱의 특성상, 이 앱이 아니면 다른 앱에서는 데이터를 복호화 할수 없도록 되어 있지요.<br />
그런데 정책때문에 배포를 갑자기 중단한다는 것은, 이 앱을 사용하는 유럽 사용자분들의 가용성을 망치는 행위라고 판단되었습니다.<br />
제 앱에 저장한 사용자분들의 비밀번호는 어떻게 하나요? 제 앱이 아니면 백업 파일은 읽을수조차 없습니다.<br />
갑작스러운 배포 중단은 곧 사용자분들에 대한 배신이라고 생각합니다.<br />
어쩔수 없이 배포를 중단할 생각이라면, 관련 공지와 함께,<br />
지금까지 앱에 저장된 비밀번호를 사용자 분들이 읽을 수 있도록 조치하는 것이 필요하다고 생각합니다.<br />
그래서 먼저 광고를 제거하고 완전 무료 앱으로 전환하였습니다.<br />
배포를 중단하지 않게 조치했던 것이지요.<br />
<hr />
그리고, 평문 파일로의 Export 기능을 준비중에 있습니다. <br />
위에 언급한 바와 같이, 이 정책은 전 세계로 확장될 가능성이 충분하다고 생각됩니다.<br />
갑자기 없던 규제를 만들어 개인 개발자들을 언제든지 얼마든지 스토어에서 쫒아낼 수도 있습니다.<br />
그것은 각국의 의회 마음이고, 빅테크 마음이지요. 개인 개발자들은 언제든지 스토어에서 쫒겨날수 있는 존재라고 봅니다.<br />
쫒겨날때는 쫒겨나더라도, 제 앱을 사용하는 사용자들의 비밀번호에 접근할수 있는 방법은 제공해야 한다고 생각합니다.<br />
배포가 중단되어도, 제 앱에 저장되었던 비밀번호를 다른 앱으로 이관할 때 용이하도록,<br />
평문 Text File Export 기능을 제공할 예정입니다.<br />
이 기능까지 구현되면, 배포가 언제든지 중단되어도 사용자 분들은 비밀번호에 대한 접근권한을 잃지 않을 것으로 생각합니다.<br />
그렇게 되면 저는 안심하고 쫒겨날수 있겠네요.
<hr />
Export 기능 추가 업데이트는 좀 시간이 걸릴 것으로 생각됩니다.<br />
저를 빨리 쫒아낸다면, 우선도를 높여 빨리 진행해야겠지만요.<br />
이 업데이트가 진행되면 그때 포스트로 올리겠습니다.<br />
감사합니다.<br />
</div>]]></content><author><name>Silent Beholder</name></author><summary type="html"><![CDATA[광고 없이 완전 무료화로 전환하였습니다.]]></summary></entry><entry><title type="html">왜 최신 Keycloak을 적용하려 하세요?</title><link href="https://sbeholder32167.github.io/posts/2026-11-05-posts-discuss/" rel="alternate" type="text/html" title="왜 최신 Keycloak을 적용하려 하세요?" /><published>2026-11-05T08:10:00+09:00</published><updated>2026-11-05T08:10:00+09:00</updated><id>https://sbeholder32167.github.io/posts/posts-discuss</id><content type="html" xml:base="https://sbeholder32167.github.io/posts/2026-11-05-posts-discuss/"><![CDATA[<p><br />
오래된 구형 애플리케이션에 왜 최신 Keycloak을 연동하려 하시나요?
<br /></p>
<hr />

<div style="font-size:18px;">
원론적인 질문입니다만, 여기서부터 시작을 해야할 것 같습니다.<br />
생각해보면, 굳이 레거시 애플리케이션에 최신의 Keycloak을 연동할 이유가 있을지요?<br />
잘 동작하는 애플리케이션을 건드려 이슈 만들일은 없어야 하겠지요.<br />
<br />
OIDC Template code를 만들고 보니, 용도가 그리 크지 않다는 생각이 들었습니다.<br />
뭐하러 레거시 애플리케이션과 최신 Keycloak을 연동할까 하는 생각이 들었습니다.<br />
<br />
AI(LLM)에게 물어보니, 이것 저것 가져와 답변해주더군요.<br />
보안 심사와 그에따른 권고사항일수도 있고,<br />
MSA로의 전환에 따른 과도기에 사용될수도 있다고 하더군요.<br />
제가 봐도 위 두가지 이유가 아니고서야 굳이 잘 동작하고 있는 애플리케이션의 인증을 건드릴 일은 없겠다 싶었습니다.<br />
메뉴 한가지에 영향을 미치는 로직이 아닌 인증과 세션등 애플리케이션 전체에 영향을 미치는 작업이 Keycloak 연동일텐데,그런 임팩트가 큰 작업을 굳이 억지로 할 이유는 크지 않다고 생각됩니다.<br />
<br />
<hr />
그러다 보니, 저 또한 MSA로의 전환에 자연스레 관심을 갖게 되었습니다.<br />
MSA로의 전환은 보통 일이 아니라고 생각합니다. 그게 제가 관심갖지 않은 가장 큰 이유였습니다.<br />
모놀리식 프로세스 하나 분리한다고 해서 MSA가 완료되었다고 생각하지 않습니다.<br />
DB도 각 마이크로서비스에 맞게 분리하고, 애플리케이션 단은 물론 분리하고, 관리 / 운영의 패러다임 또한 바뀌는 것이 MSA 전환이라고 생각합니다.<br />
그 MSA로 전환하는 과도기에 레거시 애플리케이션과 최신 Keycloak이 연동되어야 하더군요.<br />
MSA로 전환 중이더라도, 레거시 애플리케이션을 사용하는데 있어서 인증 문제는 없어야 하니까요.<br />
그래서 제 나름대로 절차를 구상해 봤습니다.<br />
실무에서 안해봤냐고요? 네. 안해봤습니다.<br />
해봤다면 OIDC Template Code는 이미 그 업체의 자산이 되어있을지도 모르는 일입니다.<br />
<br />
<hr />
대략적인 절차는 아래와 같습니다.<br />
<ul>
<li>최신 Keycloak 서버와 레거시 애플리케이션 연동. (사용자 계정 Migration 포함)</li>
<li>API Gateway 설치 및 하나의 리소스 서버를 생성하여 레거시 애플리케이션과 연동.</li>
<li>점진적으로 레거시 애플리케이션에서 비지니스 로직을 분리하여 새로운 리소스 서버로 제작하여 추가.</li>
<li>최종적으로 리소스 서버에 데이터를 요청하여 화면에 출력하는 레거시 Client의 재작성 또는 Migration.</li>
</ul>
<br />

위 절차들을 보시면, 가장 먼저 인증과 세션부터 확립하려는 것을 보실 수 있습니다.<br />
그 후, 토큰 인가를 통해 리소스 서버로의 접근 통제가 진행되기에,<br /> 
Keycloak통제 하의 안전한 환경에서 점진적으로 MSA로의 전환이 가능하다고 생각합니다.<br />
<br />
<hr />
하지만 실무에서는 위의 절차처럼 쉽게 진행되지 않는다고 생각합니다.<br />
제가 다른 실무를 겪으면서 지금까지 느껴본 바로는 그렇습니다.<br />
회의실에서는 금방금방 바로 될것 같은 일들이, 직접 진행해보면 지뢰와 암초가 곳곳에 널려있지요.<br />
저 또한 위의 절차들이 쉽게 진행되리라 생각하지는 않습니다.<br />
하지만, 저 절차들이 신속한 의사결정이 가능해지고, 부분적으로라도 쉽게 진행될수 있도록,<br />
각 단계에 따른 PoC를 진행해보는 것이 답이라고 생각합니다.<br />
말 만으로 된다고 하는 것보다, PoC 결과물과 레퍼런스 코드의 제시 한번으로 의사결정이 끝나는 경우가 많지 않던가요?<br />
그래서, Template Code의 개선 방향을 MSA전환에 필요한 쪽으로 잡게 되었습니다.<br />
단순 Keycloak 연동의 이유보다는, MSA로의 전환을 목적으로 하는 경우가 많을 거라고 생각하기 때문입니다.<br />
<br />
<hr />
현재 위 절차의 1단계에서, 일반적인 RBAC 연동이 동작함을 시연 영상으로 보여드렸습니다. <br />
하지만 사용자 계정 이관등의 이슈에 대해서는 따로 언급을 안했지요.<br />
네. 제 OIDC Template Code-Client는 레거시 애플리케이션을 OIDC Client로서 연동하는데 도움이 되는 코드입니다만, 사용자 계정의 이관에는 도움이 되지 못하지요.<br />
때문에, 현재 사용자 계정의 이관 이슈에 대응하기 위한 방책을 알아보고 PoC를 진행하고 있습니다.<br />
JSON Import 방식과, User Storage SPI방식이 그것입니다.<br />
각자 장단점이 있는 방식입니다.<br />
특히, 실시간 인가 질의 및 검증 기능에 있어서, Fetch Roles 기능의 적용여부가 갈리게 됩니다.<br />
<br />
<hr />
앞으로는 위에 언급한 로드맵 절차에 대해 하나씩 PoC를 진행해볼 생각입니다.<br />
2단계까지만 PoC를 진행해볼 생각입니다. 
그 이후 비지니스 로직 분리시켜 리소스 서버 만드는 것은 인증/인가의 영역이 아니라고 생각합니다.<br />
3단계까지 진행된 상황이라면, 리소스 서버의 인가를 어떻게 진행하고 검증할지 이미 확정된 시점이 아닐까요?<br />
2단계까지라고 하더라도, MSA전환과 구성 솔루션들(Spring Cloud Gateway등)에 대한 지식과 경험을 상당량 습득할수 있다고 봅니다.<br />
<br />
감사합니다<br />
</div>]]></content><author><name>Silent Beholder</name></author><summary type="html"><![CDATA[오래된 구형 애플리케이션에 왜 최신 Keycloak을 연동하려 하시나요?]]></summary></entry><entry><title type="html">‘다중 인가 검증’ 시연 영상</title><link href="https://sbeholder32167.github.io/posts/2026-10-31-posts-progress/" rel="alternate" type="text/html" title="‘다중 인가 검증’ 시연 영상" /><published>2026-10-31T10:30:00+09:00</published><updated>2026-10-31T10:30:00+09:00</updated><id>https://sbeholder32167.github.io/posts/posts-progress</id><content type="html" xml:base="https://sbeholder32167.github.io/posts/2026-10-31-posts-progress/"><![CDATA[<p><br /></p>

<p><br /></p>
<hr />

<div style="font-size:18px;">
Keycloak을 이용한 Legacy 전자정부 프레임워크 애플리케이션의 '다중 인가 검증' 시연 영상
</div>
<p><a href="https://www.youtube.com/watch?v=sDxP_-guY3U"><img src="https://img.shields.io/badge/YouTube-%23FF0000.svg?style=for-the-badge&amp;logo=YouTube&amp;logoColor=white" alt="YouTube" /></a></p>

<hr />

<div style="font-size:18px;">
이번 영상에서는 이전 포스트들에서 언급한 바와 같이 Scope 기반의 Permission이 사용되었습니다.<br />
Scope 기반의 접근제어 또는 Resource-Scope를 이용한 접근 통제 라고 보시면 되겠습니다.<br />
Permission 안에 Resource와 Scope가 모두 적용되니까요.<br />
이전 포스트에 언급되었던 내용보다 약간 기능을 추가한후 시연 영상을 녹화하게 되었습니다.<br />
인가 포인트를 설정하는 방식을 하나 더 추가했기 때문에 조금 늦어졌습니다.<br />
추가하고 보니, 참 잘했다는 생각이 듭니다. <br />
실무에서는 재빌드 / 재배포 또한 번거롭고 업무 부하를 유발하는 요인 일테니까요.<br />
왜 Keycloak-policy-enforcer등의 패키지에서 별도의 설정 파일로 인가 정보를 설정하게 했는지 알것도 같습니다. <br />
네. Best Practice는 벤치마킹하는게 좋다고 생각합니다. policy-enforcer의 외부 파일 설정 방식을 참조했습니다.<br />
<hr />
이번 영상에서는 두가지 기능을 예시로 시연을 진행했습니다. <br />
'품목상세조회' 화면의 '입찰 대기'와 '바로 입찰' 버튼의 기능을 대상으로 시연했습니다.<br />
겹겹이 계층적으로 동작한다는 것을 시연하기위해, 일부러 차단 정책을 모두 적용하고, 해제하면서 동작을 시연했습니다.<br />
시연 영상처럼, 단계적으로 동작하는 것을 보여주기는 아주 좋은 시나리오입니다만, 실무에서 이처럼 각 계층별로 모두 같은 정책을 적용한다면 심층 방어의 의미가 없다고 생각합니다.<br />
각 Permission(Resource와 Scope의 조합) 별로 각기 다른 기준과 정책으로 사용자 요청을 검증하여, 이전 단계를 우회하고 침투하더라도 다음 단계에서 차단될수 있는 정책의 설정이 매우 중요한 요소라고 생각합니다.<br />
실무에서는 반드시 각기 다른 정책과 기준이 각 단계별로 적용되어야 한다고 생각합니다.<br />
이 중요한 내용이 시연 영상에서는 누락되었네요.<br />
<hr />
Resource 정보의 Cache 또는 인가 포인트 정보의 Cache를 Refresh하는 Endpoint에 대해 고민한다는 내용을 이전 영상에서 언급한 적이 있습니다. 하지만 아직까지 구현할 계획을 잡지 않고 있습니다.<br />
이유는 '또 다른 케어 포인트의 추가'입니다. <br />
애플리케이션의 재시작에 따른 Downtime을 방지하기 위해 Cache Refresh하는 Endpoint는 무엇으로 보호할수 있을까요?<br />
이번에 소개한 '다중 인가 검증'을 적용하는 것이 나을까요?<br />
만약 작성한다면 Filter나 Controller에 작성되어야 할텐데, 추가적인 코드 침습은 없을까요?<br />
이 기능은 OIDC Template Code-Client가 아닌 Authz의 기능입니다.<br />
이 기능을 추가하기 위해서 추가적인 Filter나 Controller코드의 작성이 필수가 될수 있습니다.<br />
그래서 아직도 고민중입니다.<br />
<br />

<hr />
다음 내용은, OIDC Template Code를 사용하는 목적과 또다른 용도에 대한 것입니다.<br />
이번의 '다중 인가 검증'은, 최신 Keycloak을 이용하여 Legacy Spring / 전자정부 애플리케이션과 연동하고,그 애플리케이션의 보안을 더욱 강화시키는 방향이었다고 생각합니다. <br />
트레이드오프는 있지만요.<br />
다음엔, 최신 Keycloak을 이용하여 왜 Legacy Spring / 전자정부 어플리케이션과 연동하는지, 이 목적에 따른 내용을 소개해드릴까 합니다.<br />
<br />
감사합니다<br />
</div>]]></content><author><name>Silent Beholder</name></author><summary type="html"><![CDATA[]]></summary></entry><entry><title type="html">Keycloak 인가 기능을 이용한 심층 방어?</title><link href="https://sbeholder32167.github.io/posts/2026-10-12-posts-progres/" rel="alternate" type="text/html" title="Keycloak 인가 기능을 이용한 심층 방어?" /><published>2026-10-12T11:30:00+09:00</published><updated>2026-10-12T11:30:00+09:00</updated><id>https://sbeholder32167.github.io/posts/posts-progres</id><content type="html" xml:base="https://sbeholder32167.github.io/posts/2026-10-12-posts-progres/"><![CDATA[<p><br /></p>

<p><br /></p>
<hr />

<div style="font-size:18px;">
제목만 보면 매우 거창하게 생각될수 있습니다.<br />
하지만, 한번의 사용자 요청에 "인가 질의가 여러번 진행되고 여러번 검증된다"고 해석할수 있습니다.<br />
RPT Cache는 필수적이 되겠네요.<br />
<br />
<hr />
현재 "Keycloak 인가 기능을 이용한 Scope 기반 접근 제어" 시연 영상을 준비하고 있습니다.<br />
원래는 ABAC에 대한 시연 영상을 생각했었습니다만, Scope의 사용 시연이 더 먼저라고 생각됩니다.<br />
이 Scope와, 각 Method에 부착되는 Annotation 기능을 이용하면 심층 방어가 가능하다고도 생각됩니다.<br />
현재 이것에 대해 어느정도 테스트가 진행된 상황입니다.<br />
직전 포스트에 언급했던 두가지 방법에 대한 내용과 같은 내용입니다만,<br />
그 두가지 방법을 따로 이용하며 하나를 선택하는 것이 아닌, 두가지 방법을 모두 혼용하는 방법입니다.<br />
각자 장단점이 있으며, 그것들을 언급할까 합니다.<br />

<hr />

첫번째로, Resource와 그에 따른 기능들을 Scope로 연결하고 매핑하여 사용하는 방법입니다.<br />
Keycloak-policy-enforcer에서는 특정 설정 파일을 만들고, 그 파일 내부에 인가 정보를 넣어 매핑하여 사용하는 것으로 알고 있습니다.<br />
제가 작성한 OIDC Template Code-Authz에서는, 소스 코드의 Method에 인가 정보 Annotation을 부착하는 것으로 적용했습니다.<br />
<br />
장점으로는, Keycloak 인가 체계에서의 Resource - Scope 컨셉의 준수라고 생각합니다. <br />
하나의 Endpoint를 하나의 Resource로 매핑하고, 그 Resource에 가하는 행위(동작)를 Scope로 보는 개념을 그대로 인가에 적용할수 있다고 생각합니다.<br />
제가 작성한 OIDC Template Code-Authz에서는, 인가 검증을 적용할 Method에 Annotation만 추가하면 됩니다.<br />
그 Annotation에 Resource명과 Scope같은 인가 정보가 기입되므로, 이를 이용하여 바로 인가 질의를 진행합니다.<br />
Controller Method(Endpoint) 뿐만이 아닌, 내부의 각종 Component 또는 Service의 Method 또는 DB에 접근하는 Method에도 적용할수 있습니다.<br />
<br />
단점으로는, 설정 파일이든 코딩이든 뭔가 Client의 파일을 변경할 필요가 있다는 것입니다.<br />
제가 작성한 OIDC Template Code-Authz에서도, 인가 검증을 적용할 Method로의 Annotation 추가는 필수적입니다.<br />
설정 파일만 변경하면 Re-Build할 필요는 없겠지만, 파일의 변경은 피할수 없다고 생각됩니다.<br />
Keycloak-policy-enforcer가 설정 파일 매핑 방식을 사용한 것은 Re-Build를 피하기 위한 방법이 아니었을까 예상도 해봅니다.<br />
<br />
<hr />
두번째는, Scope를 아예 사용하지 않고, Resource 만으로 등록하여 사용하는 방법입니다.<br />
이 방법은 현재 Controller Method(Endpoint) 접근 시 활용되고 있습니다.<br />
<br />
장점으로는, 설정 파일이나 소스 코드의 변경이 필요 없다는 것입니다.<br />
제가 작성한 OIDC Template Code-Authz에서는, Client를 재시작하면 Keycloak 서버에 Resource 정보를 요청합니다.<br />
Resource 정보에서 Resource명과 URI 쌍을 받아 이를 Cache에 저장합니다.<br />
이렇게 저장된 Cache는 사용자 요청 시 인가 질의 검증을 위해 활용됩니다.<br />
즉, Keycloak 관리자 콘솔에서 URI가 명기된 Resource를 등록해준후, Client 만 재시작 해주면 적용됩니다.<br />
<br />
단점으로는, 이 방법은 Scope를 사용할수가 없습니다.<br />
Keycloak 관리자 콘솔에서는 Resource와 URI간의 관계만 정의될수 있습니다. Scope와 URI간 관계는 정의되지 않습니다.<br />
이로 인하여, URI를 참조하여 Resource명을 찾아서 인가질의에 반영하는 기능에서는 Scope를 반영할수가 없어서 Keycloak의 Scope를 사용할수가 없었습니다.<br />
Http Method를 Scope로 명시할수도 있습니다만, 모든 Client들이 RestAPI의 표준을 완벽하게 준수하여 구현되었다고 보기는 어렵습니다.<br />
POST로만 작성되었다면, 모든 Method의 Scope가 Create로만 질의할수도 있으니까요.<br />
<br />
<hr />
위 두가지 방법을 어느 하나를 선택하지 않고, 두 가지를 모두 혼용하는 방법을 이용하면 심층 방어가 가능하다고 생각합니다.<br />
처음 사용자 요청을 받는 Controller 단계에서는 두번째 방법을 이용하여 인가 검증을 진행합니다.<br />
(물론 Annotation을 Controller Method에 부착하여 처리할수도 있습니다.)<br />
이때는 Resource에 대한 인가 검증만이 진행됩니다.<br />
그 Controller에서 내부 Service의 특정 Method를 호출하는 부분에는, 첫번째 방법을 이용하여 인가 검증을 진행하는 것입니다.<br />
그때는 Resource 뿐만 아니라 Scope도 적용되어 인가 검증이 진행됩니다.<br />
<br />
<hr />
현재 이와같은 방법으로 테스트를 진행중입니다.<br />
(현재 의도된 모든 동작이 확인되지는 않았습니다. 이점 참고하시기 바랍니다.)<br /><br />
테스트용 게시판을 예를 들어 설명해드리자면,<br />
1. 사용자가 게시판에 접근합니다.<br /> 
<ul>
   <li>/board/viewBoard.do라는 Endpoint로 접근한다고 가정하겠습니다.</li>
   <li>이때는 /board/*.do로 매핑된 board Resource로 확인되고, OIDC Template Code-Authz 패키지는 board라는 Resource로 인가질의를 진행합니다.</li>
</ul>
2. 첫번째 인가 질의가 허용되면, BoardController로 진입하게 된다고 가정합니다.<br />
<ul>
   <li>그 Endpoint 코드에서 게시판의 내용을 DB에서 읽어오는 BoardService.selectBoardList라는 Method를 호출합니다.</li>
   <li>이 Method에는 (ResourceName='board', scopes={'Read'})라는 Annotation이 적용되어 있습니다.</li>
   <li>OIDC Template Code-Authz 패키지는 여기서 board라는 Resource의 Read라는 Scope로 인가 질의를 진행합니다.</li>
</ul>
3. 두번째 인가 질의가 허용되면, BoardService로 진입하게 된다고 가정합니다.<br />
<ul>
   <li>이 Class에서 게시판의 내용을 읽기위해 DB에 접근하는 BoardDAO.selectBoardList라는 Method를 호출합니다.</li>
   <li>이 Method에는 (ResourceName='boardTable', scopes={'Read'})라는 Annotation이 적용되어 있습니다.</li>
   <li>OIDC Template Code-Authz 패키지는 여기서 boardTable이라는 Resource의 Read라는 Scope로 인가 질의를 진행합니다.</li>
</ul>
<br />
게시판에 한번 접근하여 내용을 불러오는 데 3회의 인가 질의가 진행되었습니다.<br />
3회의 인가 질의중, 한번이라도 Deny 판정 결과가 도출되면 사용자는 게시판 내용을 볼수 없습니다.<br />
위에 언급해드린 두가지 방법을 이렇게 같이 적용한다면,<br />
Keycloak의 인가 기능을 이용한 심층 방어가 가능하지 않을까 생각됩니다.<br />
3회의 인가 질의는, 곧 3개의 Permission을 받아야 한다는 것이며, 3개의 Permission에 적용된 정책들을 모두 준수해야 합니다.<br />
각자 다른 정책으로 꼼꼼히 여러번 검증하는 것이 심층 방어의 기본이 아닐까 생각합니다.<br />
하지만, 한번의 사용자 요청에 3회의 인가 질의는 심각한 병목 현상을 초래할 수 있습니다.<br />
RPT Cache로 어느정도 완화시킬수 있겠으나, 만능 해결사라고 볼수는 없다고 생각합니다.<br />
이 Trade-off가 고려되어야 하겠습니다.<br />
<hr />
위 내용은 "Keycloak 인가 기능을 이용한 Scope 기반 접근 제어" 시연 영상에서 다룰 생각입니다.<br />
<br />
감사합니다<br />
</div>]]></content><author><name>Silent Beholder</name></author><summary type="html"><![CDATA[]]></summary></entry><entry><title type="html">Scope에 대한 고민</title><link href="https://sbeholder32167.github.io/posts/2026-10-05-posts-discuss_scopes/" rel="alternate" type="text/html" title="Scope에 대한 고민" /><published>2026-10-05T11:15:00+09:00</published><updated>2026-10-05T11:15:00+09:00</updated><id>https://sbeholder32167.github.io/posts/posts-discuss_scopes</id><content type="html" xml:base="https://sbeholder32167.github.io/posts/2026-10-05-posts-discuss_scopes/"><![CDATA[<p><br /></p>

<p><br /></p>
<hr />

<div style="font-size:18px;">
얼마전에 업로드한 "Keycloak 인가 기능을 이용한 RBAC" 시연 영상에서는,<br />
Resource만을 대상으로 인가 기능을 시연했습니다.<br />
Resource에 연결된 Scope에 대해서는 시연을 하지 않았습니다.<br />
Scope를 쓸줄 몰라서 쓰지 않았다기 보다는,<br />
Scope를 어떻게 적용해야 인가 기능을 제공함에 있어서 가장 적절한지를 판단하지 못했습니다.<br />
아래의 예시를 들어 설명드릴까 합니다.<br />

<hr />

첫번째로, Resource와 그에 따른 기능들을 Scope로 연결하고 매핑하여 사용하는 방법입니다.<br />
이 방법은 Keycloak-policy-enforcer에서도 사용되었던 방법으로 알고 있습니다.<br />
Resource 하나당 각 Endpoint 하나로 연결되고, 그 Endpoint에 정의된 Http Method를 각각의 Scope로 보는 개념입니다.<br />
Keycloak 인가 체계에서의 Resource - Scope 컨셉에 맞는 방법이라고 생각합니다. <br />
하나의 Endpoint가 하나의 Resource라면, 그 Resource에 접근하는 Method인 Scope는 각각 Create, Read, Update, Delete등 동사에 대응됩니다.<br />
<br />
이 방법은 Keycloak 인가 컨셉을 준수한다고 생각합니다만, 설정 / 코드의 추가 또는 수정을 수반한다는 단점 또한 존재한다고 생각합니다.<br />
간단한 게시판을 예로 생각해 보겠습니다.<br />
그 게시판의 내용 조회 API에 대해서는 Board Resource의 Read Scope가 해당됩니다<br />
그렇다면 게시판의 내용을 가져오기 위해 API를 호출할 때마다 Keycloak에게 Board#Read 형식으로 인가 질의가 진행되어야 합니다.<br />
그리고 게시판에 내용을 저장하기위한 Endpoint를 실행하면 Keycloak에게 Board#Create 형식으로 인가 질의가 진행되어야 합니다.<br />
이 '인가 질의' 동작을 어떠한 방식으로든 코드로 Client에 적용해야 한다는 단점이 있다고 생각됩니다.<br />
<br />
게다가, Rest API의 CRUD에 대한 Http Method를 정확하게 GET, POST, PUT, DELETE를 이용하도록 개발되었다면 문제가 없으나,<br />
편의성 및 보안등을 이유로, 모두 POST로만 사용하는 곳도 있을 것으로 생각됩니다.<br />
그러한 경우에는 Http Method등을 이용한 Scope 매핑등은 사용하기 어렵습니다.<br />
그러한 곳에서 Keycloak의 인가 기능을 다른 Resource에 추가로 적용하고 싶다면,<br />
오로지 특정 단계에서 코드를 추가하거나, 설정 파일의 내용을 추가해 주어야만 할 것입니다.<br />

<hr />

두번째는, Scope를 아예 사용하지 않고, Resource 만으로 등록하여 사용하는 방법입니다.<br />
이 방법은 직전 시연 영상에서 사용했던 방법입니다.<br />
하나의 Endpoint가 하나의 Resource에 대응이 됩니다만, Endpoint 자체가 어떤 "동작"을 하는 경우도 많습니다<br />
대표적인 경우로 게시판에 글을 저장하는데 사용되는 /api/v1/insertBoard.do 같은 Endpoint가 해당됩니다.<br />
그렇다면, 이를 insert_board라는 또 다른 Resource로 생성하여 관리하는 방법입니다.<br />
<br />
이 방법은 Keycloak의 Resource-Scope 컨셉에는 맞지 않는다고 생각됩니다.<br />
하지만, 특정 API를 추가로 보호하기 위해 Client 코드를 수정하거나 추가할 필요가 없습니다.<br />
새로운 Resource를 Keycloak 서버에 추가한 후, Client만 재시작 해주면 추가된 Resource 정보까지 모두 Client가 읽어서 인가 질의에 반영합니다.<br />
그 다음부터는 그 Resource에 특정 정책을 적용하여 얼마든지 접근통제를 할수 있습니다.<br />
사용자가 새로운 Resource에 접근하려고 하면 바로 Client에서 그 Resource에 할당된 Endpoint에 진입하기 직전에 인가 질의가 수행될 테니까요.<br />
<hr />
이것을 Board Resource의 Create Scope로 판단해야 할까요? 아니면 insert_board라는 Resource를 새로 생성해야 할까요?<br />
즉, Board#Create 로 인가 질의를 해야 할까요? 아니면 insert_board 로 인가 질의를 해야 할까요?<br />
실무에서는 보안 / 운영팀의 경우, 개발팀의 협조를 구하여 신속하게 업무가 처리되기가 쉽지 않다고 알고 있습니다.<br />
타 부서의 업무 협조를 얻어 일을 진행하기는 팀 내부적으로 처리하는 것에 비해 번거롭고 쉽지 않지요.<br />
Keycloak의 인가 컨셉을 준수하는 것보다 실무적인 편리함을 추구하신다면, 두번째 방법도 고려해볼 가치가 있다고 생각됩니다.<br />
<hr />
Keycloak의 Resource-Scope 컨셉을 준수하며, 코드를 이용한 Scope 인가를 이용할 것인지,<br />
그 컨셉을 준수하지 않고 Resource 만 사용하되, 모든 접근 통제를 UI상에서 처리하도록 할 것인지.<br />
일단 위 두가지 중 어떤 것을 선택해도 가능한 방향으로 개선중에 있습니다.<br />
<br />
지난 포스트에서, 'Controller Endpoint Method에 추가 가능한 인가 기능 적용 Annotation 제공.'이라고 Authz 패키지 기능을 나열했는데,<br />
그게 첫번째 방법을 적용하기 위한 기능입니다.<br />
인가 기능을 Method에 적용할수 있도록 Annotation을 제공하는데,<br />
이것은 Controller Method 뿐만 아닌, Method 자체에 적용할수 있게 개선하는 것을 검토 중입니다.<br />
사용자 요청에 대한 Controller 접근을 통제하는 것 뿐만 아니라, <br />
더욱 내부의 서비스 단계에 대한 접근 통제 혹은 DB Access 단계에 대한 접근 통제를 필요로 하는 곳도 있을 것으로 생각되니까요. <br />
Method Annotation은 이를 구현하기 용이하게 해줄 방법이라고 생각됩니다.<br />
하지만, 인가를 적용하고 싶은 Method마다 Annotation을 추가해야하는 '코딩'은 피할수 없습니다.<br />
이 기능들을 개선하고 난 후에 'Resource-Scope를 이용한 접근통제 시연 영상'을 추가로 제작할 예정입니다.<br />
<hr />
위 작업은 Kakao Provider를 작성한 이후의 작업이 될것 같습니다.<br />
<br />
감사합니다<br />
</div>]]></content><author><name>Silent Beholder</name></author><summary type="html"><![CDATA[]]></summary></entry><entry><title type="html">인가 기능을 이용한 RBAC 영상</title><link href="https://sbeholder32167.github.io/posts/2026-10-01-posts-progress/" rel="alternate" type="text/html" title="인가 기능을 이용한 RBAC 영상" /><published>2026-10-01T11:53:00+09:00</published><updated>2026-10-01T11:53:00+09:00</updated><id>https://sbeholder32167.github.io/posts/posts-progress</id><content type="html" xml:base="https://sbeholder32167.github.io/posts/2026-10-01-posts-progress/"><![CDATA[<p><br /></p>

<p><br /></p>
<hr />

<div style="font-size:18px;">
Keycloak의 인가 기능을 이용한 Legacy 전자정부 프레임워크 실행환경 통합예제 RBAC 연동 시연 영상
</div>
<p><a href="https://www.youtube.com/watch?v=mgiVfoCt6gc"><img src="https://img.shields.io/badge/YouTube-%23FF0000.svg?style=for-the-badge&amp;logo=YouTube&amp;logoColor=white" alt="YouTube" /></a></p>

<p><br /></p>
<hr />

<div style="font-size:18px;">
영상 녹화한지 일주일이 지난 어제야 업로드를 완료했습니다.<br />
더 보기 설명란에도 약간 언급했습니다만,<br />
제가 작성한 OIDC Template Code-Authz는 Keycloak-policy-enforcer와 기능이 매우 유사합니다.<br />
누가보면 오픈소스 코드 긁어다가 약간 수정하여 만든줄 알수도 있겠다 싶었습니다.<br />
<br />
하지만 저는 지금까지 Keycloak-policy-enforcer 패키지를 사용해본 적이 없습니다.<br />
Keycloak-authz 패키지는 사용해본적 있습니다. 인가 질의에 특화된 패키지라고 생각됩니다.<br />
그러나, Keycloak-policy-enforcer는 사용 경험이 없음에도 불구하고, 기능적으로 유사하게 설계되고 동작하게 되었습니다.<br />

<br />
구현된 기능은 다음과 같습니다.<br />
</div>
<ul style="font-size:18px;">
   <li>Client 시작 시 Keycloak에 Resource 등록 정보를 요청하여 그 정보를 Resource Info. Cache에 저장.</li>
   <li>사용자 요청 유입시 URI를 확인하여 Cache와 비교한 후 대응되는 Resource Name 정보를 이용하여 Keycloak에 인가 질의를 수행</li>
   <li>인가 질의의 결과에 따라 사용자 요청의 진입을 허용 또는 차단</li>
   <li>Resource의 URI의 패턴에 따라 우선 순위를 두어, *가 추가되지 않은 순수 URI에 우선적으로 매칭하고, 없을경우 *가 적용된 URI들을 순회하여 확인.</li>
   <li>Controller Endpoint Method에 추가 가능한  인가 기능 적용 Annotation 제공. (우선도는 Keycloak Resource 정보가 높음)</li>
   <li>Annotation의 인가 정보를 추가적으로 Resource Info. Cache에 저장하는 기능 구현.</li>
   <li>모든 사용자 요청에 의한 인가 질의로 인한 네트워크 부하를 방지하도록, RPT의 만료시각까지 사용되는 RPT Cache 구현.</li>
</ul>
<p><br /></p>
<div style="font-size:18px;">
OIDC Template Code-Client가 OIDC 인증과 기본 RBAC의 연동이 가능하게 해준다면,<br />
OIDC Template Code-Authz는 그 환경을 기반으로 추가적인 인가 기능을 위해 작성된 패키지라고 말씀드릴 수 있습니다. <br />
추가적으로 구현되는 것은 없다고 영상에 언급했습니다만,<br />
인가 질의에 따른 결과를 커스터마이징할 필요가 있는 만큼, 예외처리 클래스 하나는 구현이 필요하다고 생각됩니다.<br />
없다고 에러나지는 않지만, 기본 동작만으로 만족할 사용자는 없기에, 필요한 요소라고 생각됩니다.<br />
<br />
이전 포스트에서 언급드린바와 같이, Kakao Provider를 제작할 예정에 있습니다.<br />
이렇게 소셜로그인 기능을 조금씩 추가하다 보면, 올인원 소셜 로그인 모듈로서 사용할수도 있을 것 같습니다.<br />
그렇게 사용하려면 약간 설계 구조를 변경해야 할지도 모르겠네요.<br />
접근 시각 또는 사용자 속성을 정책에 적용하는 ABAC 시연 영상은 그 다음 작업이 될 것으로 보입니다.<br />

</div>
<p><br /></p>

<p>감사합니다<br /></p>]]></content><author><name>Silent Beholder</name></author><summary type="html"><![CDATA[]]></summary></entry><entry><title type="html">인가 기능을 이용한 RBAC</title><link href="https://sbeholder32167.github.io/posts/2026-09-14-posts-progress/" rel="alternate" type="text/html" title="인가 기능을 이용한 RBAC" /><published>2026-09-14T11:21:56+09:00</published><updated>2026-09-14T11:21:56+09:00</updated><id>https://sbeholder32167.github.io/posts/posts-progress</id><content type="html" xml:base="https://sbeholder32167.github.io/posts/2026-09-14-posts-progress/"><![CDATA[<p><br /></p>

<p><br /></p>
<hr />

<div style="font-size:18px;">
위 제목의 이름으로 시연 영상을 준비중입니다.<br />
제목 그대로, 이전의 Code 구현을 이용하여 Keycloak Role에 따라 Client의 권한을 지정하고 동작시키는 방식이 아니고,<br />
Keycloak의 인가 기능 중 역할 기반 정책(Role Based Policy)만을 이용하여 접근을 통제하는 방식입니다.<br />
Client(Legacy Application)의 권한을 고려하지 않고, 어떤 Resource에 접근하려는 사용자가 접근하기에 충분한 Role을 보유하고 있는지를 보고 접근 여부를 판단합니다.<br />
요구사항의 변경에 따라 특정 정책을 변경할 때, 전통적인 Code 방식에 비해 Client의 Code 수정이 줄어들 것으로 예상합니다만, 대신 인가 질의에 대한 오버헤드가 발생합니다.<br />
이 오버헤드를 줄이기 위해 RPT Cache가 구현되어 있습니다만, 처음에 제가 영상으로 보여드렸던 전통적인 RBAC에 비해서 인가 질의 트래픽의 추가는 불가피합니다.<br />
이 Trade-off가 잘 고려되었으면 합니다.<br />
여기서 정책만 속성 기반 정책들로 바꾸면 ABAC가 되겠네요.<br />
</div>
<p><br /></p>

<div style="font-size:18px;">
하지만 그 전에 Keycloak의 인가(Authorization) 기능을 동작시키는 데 있어서 고민해야 할 사안이 좀 있네요.<br />
인가 패키지는 이미 작성되었으나, 좀 더 나은 기능을 수행할수 있도록 개선중입니다.<br />
제가 이미 업로드한 OIDC Template Code-Client가 먼저 적용되어야만 이 인가 패키지를 사용할수 있습니다.<br />
OIDC Session 측면에서 공유하는 Bean이 조금 있기 때문입니다.<br />
<br />
Client를 기동 시, Keycloak에서 Resource의 속성 정보를 받아와 적재해야(Cache) 합니다.<br />
그렇게 해야 Client에서 요청 URL을 보고 그와 매칭되는 Resource 명을 확인하여 Keycloak에 질의할수 있기 때문이지요.<br />
이 방법은 Keycloak 인가 UI의 Resource 탭에서 입력된, URI 속성을 사용하는 것입니다.<br />
정석적인 방법이라고 생각하지만, URI속성이 입력되지 않은 Resource에 대해서는 동작이 되지 않는다는 단점이 있습니다.<br />
URI 속성은 필수 항목이 아니니까요.<br />
또한 Keycloak의 Resource 정보가 매우 많다면 첫 기동 시 수많은 데이터를 적재해야 하니 메모리 Cache 용량 이슈도 있을것 같습니다.<br />
Cache를 사용하게 된다면, 이 이슈가 인프라 영역까지 연결되겠네요. <br />
많이 사용되는 K8S 환경이라면 Redis등의 공유 저장소를 사용할 확률도 높다고 생각되니까요.<br />
의도치는 않았지만, 인가 기능에 Resource 정보, RPT 두가지의 Cache를 사용해야 하는 꼴이 되어버렸습니다.<br />
<br />
현재는 첫 동작 시 Resource 정보를 Cache하는 기능을 Bean 설정으로 세팅할수 있게 구현한 상황입니다.<br />
Cache를 사용할지, Cache를 사용하되 Resource 정보의 초기 Cache를 수행할지는 Bean 설정 시 설정하도록 구현하였습니다.<br />
또한, 이 기능을 사용하지 않아도, Client 내부적으로 인가 기능이 적용된 메서드들에 접근할 때마다 Cache가 동작하게 구현하였습니다.<br />
이 Cache기능 또한 Bean을 인가 처리 Bean에 설정해줘야만 동작하도록 했고, Cache를 적용해주지 않으면 오로지 Client에서 인가 기능이 적용된 메서드에 접근할 때마다 Keycloak에 질의하도록 구현하였습니다.<br />
조금 무식한 방법이지만, 요청 URI의 Endpoint를 Resource 명으로 박아넣고 동작시켜도 잘 동작하게 했습니다.<br />
이것이 올바른 방향인지는 확신할수 없습니다만, AI는 맞다고는 하네요. "진짜야?" 하고 되물어보면 바로 다른 답변이 나올것 같습니다.<br />
<br />
이 이슈에 대해 조금 더 코드를 개선한 후 "Keycloak 인가 기능을 이용한 RBAC" 영상을 제작하여 업로드할 예정입니다.<br />
Kakao Provider는 이번 이슈 처리 이후의 작업이 되겠네요.<br />
이번 인가 기능 이슈와 무관한 인가 질의 동작은 이미 구현이 되어있기에, 접근 시각 또는 사용자 속성을 정책에 적용하는 ABAC 및 Java Policy 동작도 시연할수 있습니다만, 그 시연 영상은 조금 시일이 걸릴 것 같습니다.<br />

</div>
<p><br /></p>

<p>감사합니다<br /></p>]]></content><author><name>Silent Beholder</name></author><summary type="html"><![CDATA[]]></summary></entry><entry><title type="html">Github Pages를 오픈했습니다</title><link href="https://sbeholder32167.github.io/posts/2026-08-30-posts-test/" rel="alternate" type="text/html" title="Github Pages를 오픈했습니다" /><published>2026-08-30T10:21:56+09:00</published><updated>2026-08-30T10:21:56+09:00</updated><id>https://sbeholder32167.github.io/posts/posts-test</id><content type="html" xml:base="https://sbeholder32167.github.io/posts/2026-08-30-posts-test/"><![CDATA[<p><br /></p>

<p><br /></p>
<hr />

<div style="font-size:18px;">
Github Pages도 처음이고, Jekyll도 처음이다 보니 엉성한 부분이 많습니다<br />
하지만 지금까지 누구나 쉽게 사용할수 있었던 채널들보다는 달리 새로운 방법을 이용하고 싶었습니다<br />
다른 사람들과 뭔가 차별점도 보이고 싶었습니다<br />
이렇게 작성하고 보니 용도 측면에서는 만족스럽습니다<br />
약간 까다롭다는 생각도 들지만 오히려 각 페이지에 대한 커스터마이징의 한계가 거의 없으니, 자유로움 측면에서는 포털 사이트 블로그들에 비해 압도적이라고 생각합니다<br />
</div>
<p><br /></p>

<div style="font-size:18px;">
추후 제 작품들에 대한 마일스톤이나 실험 내용을 공지하려면 여기가 가장 나을 것 같습니다.<br />
X에 비해서 한 페이지에 많이 게시할 수 있다는 장점이 있네요.<br />
하지만 댓글등을 이용한 소통 기능은 X가 더 낫다고 생각합니다.<br />
문의 사항은 좌측 패널의 X 또는 Email을 이용하여 주시기 바랍니다.<br />
</div>
<p><br /></p>

<p>감사합니다<br /></p>]]></content><author><name>Silent Beholder</name></author><summary type="html"><![CDATA[]]></summary></entry></feed>