문서가 개인 브랜딩이 되는 순간

문서화와 인수인계 시리즈 9/9

기술 블로그를 쓰려고 하면 종종 막막해진다.

무엇을 써야 할지, 어디까지 공개해도 되는지, 이미 다른 사람이 더 잘 설명한 기술을 다시 써도 되는지 고민하게 된다.

그럴 때 가장 좋은 재료 중 하나가 내가 실제로 남긴 실무 문서다.

HANDOVER, 아키텍처 문서, ADR, 용어집, 트러블슈팅 가이드, 배포 가이드에는 내가 어떤 문제를 겪었고 어떻게 판단했는지가 들어 있다.

이 문서들이 쌓이면 단순 기록을 넘어 개인의 일하는 방식을 보여주는 자산이 된다.

기술 블로그는 지식 자랑이 아니다

기술 블로그를 단순히 "내가 아는 것을 설명하는 공간"으로 보면 부담이 커진다.

이미 공식 문서가 있고, 더 깊은 전문가의 글도 많다.

하지만 실무 글의 가치는 다른 곳에 있다.

내가 어떤 조건에서 어떤 선택을 했는지 보여주는 것이다.

예를 들어 API Gateway 자체를 설명하는 글은 많다.

하지만 "작은 운영 콘솔에서 Lambda Function URL 대신 API Gateway를 선택한 이유"는 내 경험에서 나온다.

CORS를 설명하는 글도 많다.

하지만 "실제 운영 콘솔에서 path별 OPTIONS 설정 누락 때문에 겪은 문제와 문서화한 방식"은 실무 경험이다.

블로그의 차별점은 기술 이름이 아니라 판단 맥락이다.

문서가 경험을 보존한다

실무 경험은 생각보다 빨리 희미해진다.

당시에는 분명히 고민했던 결정도 몇 달이 지나면 결과만 남는다.

• 왜 이 구조를 선택했는가
• 어떤 대안을 버렸는가
• 어떤 제약이 있었는가
• 무엇을 얻고 무엇을 포기했는가
• 나중에 어떤 조건이 되면 바꾸기로 했는가

이런 내용은 코드에 잘 남지 않는다.

문서로 남겼을 때만 다시 꺼낼 수 있다.

문서화는 단순한 정리가 아니라 경험을 보존하는 일이다.

내부 문서와 공개 글의 차이

내부 문서는 운영을 위한 것이다.

정확한 리소스명, 배포 명령어, 로그 위치, 환경 변수, 담당자 정보가 필요하다.

공개 글은 다르다.

실제 이름은 제거하고, 판단 구조를 남겨야 한다.

내부 문서:

실제 도메인, 실제 Lambda 함수명, 실제 S3 bucket, 실제 DB명, 실제 장애 맥락

공개 글:

운영 콘솔, API Gateway, Lambda worker, object storage, job table, console.example.com

내부 문서를 그대로 공개하는 것은 위험하다.

하지만 내부 문서에서 판단 기준을 뽑아 공개 글로 재구성하는 것은 좋은 기술 콘텐츠가 된다.

좋은 블로그 글은 판단 과정을 보여준다

실무에서 나온 글은 다음 구조가 좋다.

## 문제 상황

## 선택지

## 최종 결정

## 얻은 것

## 포기한 것

## 다시 설계한다면

이 구조는 ADR과 닮아 있다.

왜냐하면 좋은 기술 글도 결국 의사결정의 기록이기 때문이다.

단순히 "S3와 CloudFront로 배포했다"는 글보다, 다음 질문에 답하는 글이 더 오래 간다.

• 왜 EC2 + Nginx가 아니었는가
• 왜 외부 호스팅 서비스를 쓰지 않았는가
• 왜 CloudFront invalidation을 배포 스크립트에 넣었는가
• 어떤 조건이 되면 다른 선택을 할 것인가

이 질문에 답하면 글은 지식 설명을 넘어 실무 설계 기록이 된다.

문서화는 포트폴리오가 된다

포트폴리오는 결과물만 보여주면 부족하다.

화면 캡처나 코드 저장소만으로는 어떤 생각을 했는지 알기 어렵다.

반면 문서 기반 글은 다음을 보여준다.

• 시스템을 전체적으로 이해하는 능력
• 기술 선택의 이유를 설명하는 능력
• 운영 중 발생할 문제를 예상하는 능력
• 장애와 배포를 문서화하는 습관
• 보안상 공개할 것과 숨길 것을 구분하는 판단
• 다음 개선 방향을 남기는 태도

이것은 단순한 개발 결과물보다 더 강한 신뢰를 준다.

특히 내부 도구나 운영 콘솔처럼 공개 화면을 보여주기 어려운 작업에서는 문서화된 의사결정이 포트폴리오 역할을 한다.

면접 답변도 문서에서 나온다

면접에서 자주 받는 질문이 있다.

• 왜 그 기술을 선택했나요?
• 다른 대안은 없었나요?
• 장애가 나면 어떻게 확인하나요?
• 확장되면 무엇을 바꾸겠나요?
• 보안은 어떻게 고려했나요?
• 운영 비용은 어떻게 봤나요?

이 질문들은 모두 ADR, HANDOVER, 트러블슈팅 문서에 이미 답이 있다.

문서를 잘 써두면 면접 답변을 외울 필요가 줄어든다.

실제로 고민했던 내용을 다시 말하면 된다.

좋은 답변은 멋진 용어보다 구체적인 판단에서 나온다.

개인 브랜딩은 꾸미는 것이 아니다

개인 브랜딩이라는 말은 가끔 과하게 들린다.

하지만 여기서 말하는 브랜딩은 자신을 포장하는 일이 아니다.

내가 어떤 문제를 중요하게 보고, 어떻게 정리하고, 어떤 기준으로 결정하는지 꾸준히 보여주는 일이다.

운영 문서를 블로그 글로 바꾸면 이런 신호가 쌓인다.

• 나는 시스템을 운영 관점으로 본다.
• 나는 결정의 이유를 남긴다.
• 나는 자동화와 복구 경로를 함께 생각한다.
• 나는 보안과 공개 범위를 구분한다.
• 나는 작은 도구도 책임 경계를 나눠 설계한다.

이런 신호가 반복되면 블로그는 단순 글 모음이 아니라 일하는 방식의 기록이 된다.

바로 공개하지 않아도 된다

모든 문서를 바로 블로그에 올릴 필요는 없다.

먼저 내부 문서를 잘 남기면 된다.

그다음 공개 가능한 주제를 골라 익명화하고, 하나씩 글로 바꾸면 된다.

순서는 이렇게 잡을 수 있다.

1. 운영을 위해 문서를 쓴다.
2. 문서에서 의사결정을 뽑는다.
3. 식별 정보를 제거한다.
4. 문제와 선택지 중심으로 재구성한다.
5. 블로그 글로 발행한다.
6. 시리즈로 묶어 자산화한다.

처음부터 보여주기 위한 글을 쓰면 힘이 빠진다.

실제로 운영하기 위해 쓴 문서에서 출발하면 글에 밀도가 생긴다.

시리즈의 마무리

이 시리즈는 문서화 자체를 다뤘다.

• HANDOVER는 운영 지도다.
• README, 아키텍처 문서, HANDOVER는 역할이 다르다.
• ADR은 의사결정의 이유를 남긴다.
• 용어집은 프로젝트 맥락을 보존한다.
• 트러블슈팅 문서는 장애 대응 시간을 줄인다.
• 배포 가이드는 명령어가 아니라 안전 절차다.
• 내부 문서는 익명화를 거쳐 공개 글이 된다.

이 모든 문서는 결국 같은 방향을 가진다.

나중의 누군가가 시스템을 이해하고, 운영하고, 바꾸고, 설명할 수 있게 만드는 것이다.

그 누군가는 동료일 수도 있고, 미래의 나일 수도 있다.

그리고 때로는 블로그 독자나 면접관일 수도 있다.

정리

문서를 잘 남기면 블로그 글이 된다.

블로그 글이 쌓이면 포트폴리오가 된다.

포트폴리오가 쌓이면 내가 어떻게 일하는지 보여주는 개인 브랜딩이 된다.

하지만 출발점은 브랜딩이 아니다.

출발점은 일을 잘 이어가기 위한 기록이다.

실무 문서는 운영을 돕고, 공개 글은 그 판단을 공유한다.

그 사이에 익명화와 재구성이 있다.

이 흐름을 만들 수 있다면, 매일의 업무 기록은 시간이 지나도 사라지지 않는 기술 자산이 된다.

---

관련 자료: Ops Console Documentation Kit