feat: 개발자 문장력 세미나 글 추가 및 .dockerignore, .gitignore 추가

Author: rha6780

.dockerignore

@@ -0,0 +1,5 @@
+.obsidian
+node_modules
+.git
+vendor
+.bundle

.gitignore

@@ -28,3 +28,11 @@ codekit-config.json
 .sass-cache
 _asset_bundler_cache
 _site
+
+# Obsidian
+.obsidian
+.obsidian/
+.obsidian/workspace/
+.obsidian/workspace/workspace.json
+.obsidian/workspace/workspace.jsonc
+.obsidian/workspace/workspace.jsonc

_posts/docker/2025-09-16-grafana-monitoring.md

@@ -10,23 +10,48 @@ tags:
 
 회사에서 APM TF로 pinpoint, skywalking 등 여러 툴을 써보았지만...결과적으로 돌고 돌아 프로메테우스+그라파나가 대시보드 커스터마이즈 및 데이터 수집에서 압도적으로 좋은 것 같았다.
 
-프로메테우스와 그라파나는 이전 그렙에 있을 때 인프라 상태등을 모니터링하기 위해 도입했었는데, 그당시 보고 나도 한번 해보고 싶다는 생각이 들었던 적이 있다.
-
-2년정도 지난 것 같은데, 지금에서야 하는 이유는 현재 회사에 필요한 것이라고 생각이 들었기 때문이다.
-
+<br>
 
 ### 왜 갑자기 필요하다고 생각하게 되었나...
 
 현재 회사에서는 고객이 전화나 메일 등으로 이슈 제기를 하는 경우에 관련 로그를 찾고 이를 수정하는 형식으로 이뤄졌다. 이렇게 되면 이슈나 문제점을 누군가가 불편을 겪고 나서야 인지를 한다는 문제점이 있다.
 
 <br>
 
-내가 느끼기에는 고객이나 사용자가 이런 불편을 겪지 않는 것이 서비스를 운영 및 개발하는 입장에서 중요하다고 판단이 되며, 단순히 기능 개발 및 테스트 코드를 작성하는 수준이 아니라 지속적인 모니터링이 필요하다고 생각한다.
+내가 느끼기에는 이슈 알림 및 모니터링이 제대로 되어야 고객이나 사용자가 불편을 겪는 경험을 줄일 수 있다고 판단이 되며, 단순히 기능 개발 및 테스트 코드를 작성하는 수준이 아니라 지속적인 모니터링이 필요하다고 생각한다.
 
 <br>
 
 위 문제점을 해결하기 위해서 현재 회사에서 사용중인 센트리에 알림 기능을 슬렉과 연동할 예정이고, 그라파나와 프로메테우스를 통해 인프라 및 서버와 관련된 부분을 확인할 수 있게 개선해 볼 생각이다.
 
+<br>
+
+### 프로메테우스 + 그라파나
+
+프로메테우스 및 그라파나에서 각각 역할을 간단히 정리하자면...
+
+- **프로메테우스** : 데이터 수집 및 메트릭, 시각화 등의 기능을 제공하는 오픈소스 모니터링 시스템이다. 시계열 기반으로 분석이 가능한게 장점이며 다른 것과 달리 pull 방식으로 메트릭을 수집한다.
+- **그라파나** : 오픈소스 시각화 툴로, 대부분의 서비스와 호환성이 좋다. 쿼리 형식으로 데이터를 시각화할 수 있다. 
+
+
+<br>
+
+
+프로메테우스에서 pull 방식으로 수집한다고 하였는데, 이는 프로메테우스에서 대상 서버에서 주기적으로 데이터를 당겨오는 방식이다. 각 서버에 접속하여 메트릭 데이터를 가져오는데, HTTP 엔드포인트를 통해 접근가능하다.
+또한, 데이터를 읽기만 가능하기 때문에 보안적으로 좋을 수 있다. 또한, 분산 시스템 등에서는 확장성을 위해 pull 방식이 이점을 가질 수 있다.
+
+<br>
+
+반대로 push 방식은 모니터링 대상 서버에서 직접 서버로 데이터를 전송하는 방식이다. 주로 agent 를 통해서 데이터 전송을 한다. 물론 실시간성을 보장한다는 장점이 있지만, 관련된 네트워크가 항상 연결 되어야하는 점과 데이터 푸쉬로 인해서 서버에 부하를 줄 수 있다.
+
+
+<br>
+
+
+이런 프로메테우스 및 그라파나로 서버의 상태를 알 수 있으며, 어떤 사용자에 대한 로그 추척 보다는 서버에 이슈가 있는지, 느린 쿼리가 있는 지 정도 파악하는 부분에서 사용할만 한 것 같다.
+
+<br>
+
 
 ### 테스트
 

_posts/event/2025-07-29-developer-devrel-okky.md

@@ -0,0 +1,92 @@
+---
+title: "[Event]OKKY 개발자 문장력 세미나"
+date: 2025-07-29
+categories:
+  - event
+---
+
+### 협업을 위한 세미나 참가
+
+
+
+작년(2024) 8월 부터 현재까지 회사와 관련하여 새로운 고객사와 CS 혹은 기획에 대한 이야기를 나누는 경우가 많이 생기게 되었다. 또한, 다양한 팀을 이끄는 경험을 하게 되면서 같은 개발자끼리도 소통하다보면 오해나 착오가 생기는 경우가 많아 세미나 참가를 하게 되었다. 
+
+<br>
+
+구두로 이야기 하기 보다는 문서나 기록으로 남기는 것이 필수가 맞긴 하지만, 어떤 내용을 어떻게 작성하느냐도 업무에 있어서 중요한 포인트인것 같다고 느낄때가 많다. 기록을 해두어도 추후 다른 사람이 보았을 때 이해하지 못하는 글이나 기록은 가치가 상실한다고 생각되기 때문이다... 특히 인수인계... 예전 히스토리를 찾을 때에도 느끼지만, 정작 지난주 업무 내용만 봐도 기억나지 않고, 이해되지 않는 경우가 많다.
+
+<br>
+
+단지 내 습관을 고치는 것 외에도 우리 팀에도 큰 영향을 줄 수 있을 것 같아 세미나를 참가했다.
+
+<br>
+
+<img width="600" alt="세미나모집공고-1" src="/assets/images/okky-devrel.png" style="display: block; margin: auto">
+
+<img width="600" alt="세미나모집공고-2" src="/assets/images/okky-devrel-02.png" style="display: block; margin: auto">
+
+<br>
+
+
+
+문제는 우리 회사가 증미역(9호선) -> 역삼까지 7시까지 가야하는데... 6시 칼퇴를 하더라도 조금 늦는 불상사가 있었다. 여름이라 더 더웠지만, 그래도 큰 꿀팁을 얻어가는 시간이었다. 이번 세미나에서는 현재 올리브영에서 근무중인 최가인 매니저님이 진행하였다.
+
+<br>
+
+
+
+**최가인 DevRel Specialist (CJ올리브영)**
+
+> 최연사는 42서울, 뤼이드, CJ올리브영 등에서 개발자 경험과 협업 문화를 개선해온 실전형 DevRel
+> 올리브영이라는 대규모 리테일 조직에서 복잡한 협업 환경을 개선하며 소통을 ‘시스템’으로 설계하는 방식을
+> 개발하고 적용해왔습니다.
+
+
+<br>
+
+약 1시간 30분정도 발표를 진행하고 추후 QnA 를 가진 뒤 마치게 되었다.
+
+
+<img width="500" alt="세미나현장사진" src="/assets/images/okky-devrel-03.jpeg" style="display: block; margin: auto">
+
+
+
+<br>
+
+
+### 감상평
+
+세미나에서 다룬 소통의 중심 목표는 우선 크게 2가지였고, 해당 목표를 이루기 위해서 어떤 방식으로 글을 작성하고 공유하면 좋은 지를 설명하였다.
+
+1. 기록으로 소통할 것
+2. 상대방이 이해할 수 있도록 작성할 것
+
+
+
+<br>
+
+
+가장 인상 깊은 것은 대화의 5가지 기법 등등 말고도 단어/문장의 위치로도 상대가 바로 포인트를 찾을 수 있게 할 수 있다는 점이다. 한국어 특징 상 단어를 어디로 두더라도 말이 안되는 케이스는 별로 없지만, 단어에 위치에 따라서 느낌이 확연히 다르다는 것을 느끼게 되었다. 좋았던 점은 개발 및 업무에서 일어날 수 있는 예시와 함께 이야기하여 이해하기 쉬웠다.
+
+
+<br>
+
+무엇보다 중요한건... 이과 문과 그런걸 떠나서 커뮤니케이션에 대해서는 문맥 파악 및 언어 능력이 중요하다는 사실을 다시한번 깨닫는다. 그런 생각에 있어서 블로그에 이렇게 정리해나가는 글들도 일회성으로 끝나는 것이아니라 주기적으로 읽으며 이해 안되는 부분을 수정해 보려고 한다.
+
+
+<br>
+
+
+아무튼 결론적으로... 이번 세미나에서 얻은 내용을 시간이 된다면 하나씩 실천해 가면서 내 것으로 만들어가야겠다. 관련 내용을 조금 정리하여 관련 팀원 분들께도 공유된다면 더 좋겠지만.... 앞으로 또 새로운 프로젝트에 투입되면서 정신이 없기에.. 추후 시간이 된다면 짧게 맛보기로 정리해볼 예정이다. 
+
+
+
+<br>
+<br>
+
+
+
+
+
+
+

_posts/terraform/2024-02-17-terraform_actions_for_pr.md

@@ -44,6 +44,7 @@ PR을 열고 push 마다 액션이 돈다.. 그러면 아래 사진과 같이 
 
 일단 결론 부터 말하자면... 아래와 같은 코드로 생성하였다.
 
+{% raw %}
 ```yaml
 name: "Terraform Plan"
 
@@ -178,6 +179,8 @@ jobs:
               body: output
             })
 ```
+{% endraw %}
+
 
 <br>
 
@@ -247,6 +250,8 @@ PR당 변경되는 서비스가 적으면 상관없지만...
 
 우선 하나의 커맨트로 만드는 것은 파일을 이용하였다. actions/upload-artifact 를 이용해서 해당 결과를 파일에 각각 파일로 작성하고, 마지막 job에서 해당 아티팩트 내부 내용을 모두 출력하는 것이다.
 
+{% raw %}
+
 ```
 name: "Terraform Plan"
 
@@ -430,6 +435,8 @@ jobs:
               body: output
             })
 ```
+{% endraw %}
+
 
 <br>