— 겉핥기 사고에서 벗어나려면

우리는 종종 문제를 눈앞에서 보지만, 그 본질을 깊게 파고들지 못하는 경우를 겪을 수 있습니다.

이런 피상적 사고는 단순히 개인의 능력 부족이 아닙니다. 대부분은 정보 부족이나 사고의 습관화라는, 누구나 빠질 수 있는 흐름 때문입니다.

결국 문제를 진짜로 해결하고 성장하기 위해서는 '사고를 확장하는 방법' 을 배우는 것이 필요합니다.

때문에 이번 글에서는

• 왜 우리는 문제를 깊게 파고들지 못하는지
• 사고를 확장하려면 어떤 훈련이 필요한지

를 함께 살펴보려 합니다.

🚨 피상적 사고의 원인

1. 정보나 관점이 부족해서 ‘생각을 멈춘 상태’

처음 문제를 마주했을 때, 우리는 자신이 알고 있는 정보와 경험 안에서 빠르게 판단하려고 합니다.

하지만 현실은 복잡합니다. 눈앞에 드러난 현상만으로는 문제의 전모를 파악할 수 없습니다. 그런데도 새로운 관점이나 추가 정보를 확보하지 않으면, 생각은 자연스럽게 "여기까지가 한계" 라고 스스로 멈춰버립니다.

결국 우리는 '알고 있는 만큼만' 사고하고, 그 바깥으로 확장하지 못하게 됩니다.

2. 생각하는 방법 자체가 ‘넓거나 깊지 않은 루틴’으로 굳어져 있음

또 다른 이유는 생각하는 패턴 자체가 '얕게 멈추는' 습관으로 굳어졌기 때문입니다.

문제를 보면 당장의 현상만 처리하고, "왜 이런 구조가 생겼을까?", "이 시스템을 만든 조직 문화는 무엇일까?" 같은 질문은 스스로 던지지 않습니다.

결국, 깊은 사고는 의식적인 노력 없이는 자동으로 생기지 않습니다. 우리의 사고가 고착화되지 않기 위해서는 생각을 의도적으로 확장하고, "표면 → 구조 → 원인 → 철학"까지 이어지는 깊은 레이어를 훈련해야 합니다.

✅ 사고 확장하기

문제를 깊게 이해하는 능력은 타고나는 것이 아닙니다. 의식적인 연습과 작은 습관의 반복을 통해 누구나 키워갈 수 있습니다.

1. 다양한 관점을 주입하는 습관 들이기

혼자서 생각하다보면 내가 알고 있는 만큼만 생각 할 수 있기 때문에 한정적이고 고착화되기 쉽습니다. 따라서 의도적으로 다른 사람의 관점을 받아들이는 연습이 필요합니다.

• 팀 동료에게 "왜 이런 일이 생겼다고 생각해?" 질문하기
• 다른 부서, 다른 직무 사람들과 이야기 나누기
• 과거 유사한 사례를 찾아보고, 그때와 이번 문제의 차이 분석하기

핵심은 내 사고의 프레임을 깨고, "내가 몰랐던 시야" 를 받아들이려는 태도입니다.

2. 생각을 단계별로 깊게 내려가는 연습하기

문제를 다룰 때, 한 번에 깊이 들어가는 것은 어렵습니다. 때문에 층층이 생각을 나누는 연습을 통해 사고를 점진적으로 깊게 만들 수 있습니다.

• 이 현상 자체는 무엇인가?
• 이 현상이 나타난 구조는 무엇인가?
• 이 구조가 생긴 근본적인 이유는 무엇인가?

이런 레이어를 따라가다 보면 자연스럽게 생각의 깊이가 달라집니다.

3. ‘구조’를 보는 훈련하기

표면적 사건만 보지 말고, 그 사건을 만든 흐름이나 구조를 찾는 훈련이 필요합니다.

• 요구사항 변경이 잦다 → '요구사항 명확화 프로세스'가 부실한가?
• 운영환경 버그가 반복된다 → '테스트 설계'에 구조적인 문제가 있는가?
• 일정이 자주 밀린다 → '의사결정 체계'나 '우선순위 설정'이 어설픈가?

현상이 아니라, 현상을 만든 시스템을 보는 눈을 키워야 합니다.

마치며

사고를 확장하려면 타인의 관점을 적극적으로 받아들이고, 질문을 통해 사고를 단계별로 깊게 파고들고, 표면 아래 숨겨진 구조를 읽어내는 연습이 필요합니다.

문제를 보는 것과 문제를 파고드는 것은 다릅니다. 파고들기 위해서는 ‘정보’와 ‘관점’을 확장하고, ‘생각하는 방법’ 자체를 조금씩 업그레이드해야 합니다.

깊게 생각하는 것은 선택이 아니라, 더 나은 문제 해결을 위한 필수 능력입니다.

실제 운영 중인 MongoDB 중 replicaSet 구성 인원을 추가하는 상황에서 primary DB로 부하를 주지 않기 위해 찾아놓은 설정을 정리한 글이다。

settings.chainingAllowed

default: true

true: replica set secondary 구성원은 다른 secondary구성원의 데이터를 복제할 수 있다.

false: secondary 구성원은 primary 구성원에서만 데이터를 복제할 수 있다.

해당 설정이 비활성화 되어도 replSetSyncFrom 옵션이 다른 secondary에서 복제할 수 있도록 지정할 수 있다.

설정 비활성화 하기

cfg = rs.config()
cfg.settings.chainingAllowed = false
rs.reconfig(cfg)

replSetSyncFrom

현재 기본 동기화 대상을 일시적으로 재정의 한다. 다양한 패턴을 테스트하고 집합 구성원이 원하는 호스트에서 복제되지 않는 상황에서 유용하다.

use admin
db.adminCommand({replSetSyncFrom: "hostname:<:port>"})

mongo shell 명령어로도 사용할 수 있다.

rs.syncFrom("hostnmae:<:port>")

_replSetSyncFrom을 실행할 때 초기 동기화 작업이 진행 중인 경우 진행 중인 총기 동기화를 중지하고 새 대상으로 동기화 프로세스를 다시 시작한다. _

Persistence

replSetSyncFrom은 일시적으로 재정의 하는 것으로 다음 상황에서 기본 동기화 동작으로 되돌아간다.

• service mongod가 다시 시작되는 경우
• 동기화 대상 간의 연결이 닫히는 경우
• 동기화 대상이 replica set의 다른 구성원보다 30초 이상 뒤처지는 경우

테스트

settings.chainingAllowed 비활성

비활성

cfg = rs.config()
cfg.settings.chainingAllowed = false
rs.reconfig(cfg)
rs.add("hostname:27017")

rs.status() //  syncSourceHost 는 primary host로 설정된다.

syncFrom으로 복제할 대상 DB 설정

rs.add("hostname:27017")

동기화 대상 서버로 mongo shell 접속
mongo
use admin
db.auth("****", "****")
rs.syncFrom("대상 DB host:27017")

rs.status() //  syncSourceHost、 syncingTo가 설정한 대상 DB로 변경된다。

대상 서버에서 db.currentOp()으로 실제 동기화 작업이 진행 중인 것도 확인 가능하다。

참고 링크 https://www.mongodb.com/docs/manual/tutorial/manage-chained-replication/ https://www.mongodb.com/docs/v4.2/reference/replica-configuration/#rsconf.settings.chainingAllowed https://www.mongodb.com/docs/v4.2/reference/command/replSetSyncFrom/#dbcmd.replSetSyncFrom

MongoDB 설치 Replica set 설정

이번 글은 MongoDB를 사용 중일 때 버전을 업데이트 하는 방법을 정리한 문서이며 설정한 버전은 4.2.24 이기 때문에 해당 문서는 4.4 버전으로 업데이트하는 방법이다.

참고 문서: https://www.mongodb.com/docs/v5.3/release-notes/4.4-upgrade-replica-set/

MongoDB Version Upgrade

MongoDB Upgrade 시 주의사항

• 버전은 순차적으로 Upgrade 해야한다. (ex. 4.2에서 5.0으로 업그레이드 해야 하는 경우 두 단계를 거쳐야 한다. 4.2 → 4.4, 4.4 → 5.0)
• 호환성 변경 문서를 참조하여 애플리케이션 및 배포가 해당 버전과 호환되는지 확인해야 한다.
• 예기치 못한 상황으로 다운그레이드를 하는 상황에서 4.4 → 4.2로 변경하는 경우라면 4.2.6 이상 버전으로 만 다운그레이드 할 수 있다.
• MongoDB 3.0 메타데이터가 포함된 MongoDB 4.2 시리즈 배포를 4.4 시리즈 배포로 업그레이드하는 경우 MongoDB 4.4.1 이상 으로 업그레이드해야 한다 .

4.4 Upgrade 시작 조건

• replica set으로 구성된 모든 NODE들의 버전은 4.2 버전의 최신 버전으로 업그레이드 해야 한다. (https://www.mongodb.com/docs/manual/release-notes/4.2/)
• 구성 노드들의 featureCompatibilityVersion이 설정되어있어야 한다.

Upgrade start

1. featureCompatibilityVersion 4.2로 설정한다.

   # primary mongo shell
   db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )
   db.adminCommand( { setFeatureCompatibilityVersion: "4.2" } )

2. 노드들을 한 번에 하나 씩 업그레이드 한다. (secondary부터) a. MongoDB service 종료 후 rs.remove 명령어로 멤버에서 제거한다.

    #secondary mongo shell or linux cli
    service mongod stop // db.shutdownServer()로 대체 가능
   
    # primary mongo shell
    rs.remove("버전업할 서버") // 멤버 제거

   b. MongoDB 설치 repo를 설정해 4.4로 upgrade

    #secondary service cli
    vim /etc/yum.repos.d/mongodb-org-4.4.repo // yum 4.4 repo 생성
   
    [mongodb-org-4.4]
    name=MongoDB Repository
    baseurl=https://repo.mongodb.org/yum/amazon/2/mongodb-org/4.4/x86_64/
    gpgcheck=1
    enabled=1
    gpgkey=https://www.mongodb.org/static/pgp/server-4.4.asc

   repo 설정은 CPU 아키텍처에 따라, 설치된 운영체제에 따라 달라지니 본인에 맞는 설정을 해야한다.

    rm -rf /etc/yum.repos.d/mongodb-org-4.2.repo // 기존 repo 삭제
    yum install -y mongodb-org // mongodb 업그레이드
    service mongod restart // mongodb 재시작

   c. MongoDB service 재시작 후 rs.add로 멤버에 추가한다.

    # primary mongo shell
    rs.add("버전업 진행한 서버")

   d. primary upgrade 시 stepDown() 명령어로 secondary 서버를 primary로 선택하도록 설정한 후 기존 primary가 secondary로 변경되면 2번 작업을 수행한다.

    #primary mongo shell
    rs.stepDown()

3. featureCompatibilityVersion 4.4로 설정

   # primary mongo shell 
   db.adminCommand( { setFeatureCompatibilityVersion: "4.4" } )

전 글 MongoDB 기본 세팅 후 Replica setting을 할 때 참고하기 위한 글이다.

OS: amazon-linux-2 Mongo Version: 4.2.24

참고 링크: Mongo Replication Replica set을 설정하기 전 보안 설정이 필요하다.

MongoDB 인증 설정

• mongo root 권한 유저 만들기

  mongo # mongo-cli 접속
  use admin # admin db로 전환
  db.createUser({user:"유저 이름", pwd: "password", roles: ["root"]}) # root 권한 유저 생성

• 몽고 DB 인증 설정

  openssl rand -base64 756 > /etc/mongo-keyfile
  vim /etc/mongod.conf
  

security: authorization: enabled keyFile: /etc/mongo-keyfile

> Keyfile은 어떠한 방법으로 생성해도 무관한데, base64 character set 로만 이루어진 6-1024자의 파일로 생성해야 한다.

- keyFile 사용 권한 부여

chown mongod /etc/mongo-keyfile chmod 600 /etc/mongo-keyfile

### Replica set 설정하기

vim /etc/mongod.conf

replication: replSetName: "rs0" // replica set 이름은 자유롭게 설정 가능하다.

mongo // mongo-cli 접속 use admin db.auth({user:"유저 이름", pwd: "password"}) // root 권한을 가진 mongo user로 로그인 rs.initiate({_id: "rs0", members: [{_id: 0, host: "{hostname}:27017"}]}) rs.add({hostname:27017}) // secondary 설정 rs.addArb({hostname:27017}) // arbitor 설정

아래 명령어를 통해 replica set이 정상적으로 끝났는지 확인한다.

rs.status() // root user로 로그인 후 진행

## 발생 Error 처리

Error가 발생하면 /var/log/mongod/mongod.log 에서 에러가 발생 로그를 확인한다.

Failed to unlink socket file /tmp/mongodb-27017.sock Operation not permitted

- /tmp/mongodb-27017.sock 파일에 대한 권한이 없는 것으로 삭제하거나 권한을 주면 된다.

각 OS 마다 설치 방법은 MongoDB Documentation에 자세히 나와있으니 설치하려는 OS를 선택 후 설치 해야한다. MongoDB Install

OS : amazon-linux-2 설치 Mongo versino: 4.2

모든 명령어는 user가 root일 경우로 본다.

MongoDB 설치

yum update -y
amazon-linux-extras install epel -y

yum 몽고 패키지 설치 전 yum Repository에 Mongo 패키지를 추가해준다.

vim /etc/yum.repos.d/mongodb-org-4.2.repo

[mongodb-org-4.2]
name=MongoDB Repository
baseurl=https://repo.mongodb.org/yum/amazon/2/mongodb-org/4.2/aarch64/
gpgcheck=1
enabled=1
gpgkey=https://www.mongodb.org/static/pgp/server-4.2.asc

x86을 사용하고 있다면 baseurl = https://repo.mongodb.org/yum/amazon/2/mongodb-org/4.2/x86_64/로 설정한다.

version이 다르다면 파일 이름 및 baseurl, title에 version이 들어간 부분을 수정한다.

안전한 최신 버전의 MongoDB 설치

yum install -y mongodb-org

MongoDB의 특정 릴리스를 설치하려면 아래와 같이 각 구성 요소 패키지를 개별적으로 지정해야한다.

sudo yum install -y mongodb-org-4.2.24 mongodb-org-database-4.2.24 mongodb-org-server-4.2.24 mongodb-org-mongos-4.2.24 mongodb-org-tools-4.2.24

설치가 완료될 경우 /etc/mongod.conf 파일이 생성된다. 해당 파일에서 데이터가 저장되는 path, log path 등 변경할 수 있다.

지금은 외부에서 접속할 수 있도록 bindIp를 설정해준다.

vim /etc/mongod.conf

# network interfaces
net:
  port: 27017
  bindIp: 0.0.0.0

Mongo DB 실행

systemctl start mongod
or service mongod start

코드상에서 접근 시도

Axios로 요청하기

await axios.get('https://ipinfo.io/');

처음은 단순히 axios로 요청을 날린다. 만약 크롤링 시 반드시 Proxy를 통해야 한다면 이 단계에서 성공을 해도 Proxy 서버를 통해서 요청하는 것이 좋다.

Axios로 Proxy 서버를 통해서 요청하기

await axios.get('https://ipinfo.io/', {
  proxy: {
    host: proxy host (public IP),
    port: proxy port
  },
  timeout: 30000
});

Axios로 GET 요청을 보낼 때 config에 proxy 설정을 하게되면 해당 서버를 통해서 요청할 수 있다.

만약에 이 방법으로도 Error가 발생하면 Proxy가 차단을 당한 것인지 headers에 문제가 있는 것인지 확인하기 위해 아래 단계를 수행해야한다.

1 단계: Proxy 확인

2 단계: Headers 확인

위 단계를 수행할 때 브라우저나 Fiddler, postMan을 사용할 경우 쿠키와 세션을 전부 삭제하면서 확인하는 것이 중요하다.

1단계: Proxy 확인

Proxy 서버로 curl을 날려보기

proxy server로 들어가서 curl을 날려보자

curl https://ipinfo.io/

만약 차단을 당했다면 아래와 같이 Access Denied가 확인된다.

FireFox로 Proxy 설정하여 접근하기

FireFox로는 수동 Proxy를 설정하는 것이 가능하다. FireFox에서 홈페이지에서 접근이 가능하다면 헤더가 잘못되있을 확률이 크다.

수동 Proxy 설정 방법

1. FireFox 설정 → 일반 → 네트워크 설정에서 설정 버튼을 누른다.

2. 수동 프록시 설정을 체크한 후 HTTP 프록시에 Proxy host(public IP, public DNS), 포트에 Proxy port를 적어준다. (proxy 서버가 열려있는 포트) HTTPS에도 이 프록시를 사용에도 체크한다.

2단계: Headers 확인

무슨 헤더가 필수적으로 필요한지 확인이 필요하다.

Cookie가 필수적으로 필요하다면 만료가 되는지 확인해본다. 만료가 된다면 재발급 받는 방법을 찾아야한다.

FireFox, Chrome 등 웹 브라우저 사용하기

네트워크 탭을 열면 각 HTTP 요청 정보를 볼 수 있다. Axios 헤더에 페이지를 불러오는 요청 헤더의 값을 똑같이 넣어서 요청을 해보면 된다. 한번에 복사를 하고 싶다면 해당 요청에 우클릭을 해서 Fetch로 복사나 요청 헤더 복사를 한다.

Fetch 복사의 경우 Cookie까지 복사가 되지 않기 때문에 요청 헤더를 권장한다.

Fiddler 사용하기

Fiddler를 사용하면 HTTP 패킷을 바로 볼 수 있다. 또한 Composer에서 요청을 할 수도 있다.

단 Composer에서 요청을 했을 때 처음에는 잘 요청되다가 시간이 지나서 Cookie나 인증 부분이 만료될 경우 오류가 발생할 수 있으므로 코드에서 시도하는 것을 추천 → 이 경우 인증을 위해 다른 페이지 호출이 필요할 수도 있다.