잠깐, 구현하기 전에... "생각" 했나요?

오늘도 굉장히 오랜만에 끄적이러 왔다.

한 달 동안 시골살이를 한 이야기는 다음에 길게 풀기로 하고, 오늘은 메일로 온 TLDR을 보다가 간만에 좀 다뤄보고 싶은 글이 있어서 가져왔다.

First Principles Thinking

제목만 보면 읭? 이게 뭔 내용이지…? 하는 듯한 추상적인 제목이었다.

“senior engineer death spiral.” 문장이 상당히 폭력적이다.

원문

자세히 보자

한 줄로 하면 이렇다.

경력이 쌓일수록, 그 경력이 오히려 발목을 잡는다.

시니어 되면… 내가 어떻게 일해야 하는지 다 알고, 이 기술이 왜 안 되는지도 알고, 이 프로젝트가 왜 실패했는지도 안다.

근데 새 문제를 만나면 이미 알고 있는 답부터 꺼내버려서, 이 문제 자체를 처음부터 다시 볼 생각을 안 한다는 거다.

그래서 이 글이 처방으로 제안하는 게 first principles thinking.

한국말로 “제 1원리 사고” 라고 부르는 것 같은데, 뭐 그냥 “지금까지 뭘 배웠든 잠깐 옆에 치워두고, 이 문제 진짜로 처음부터 다시 보자” 정도로 이해했다.

흠… 그런가

Take your experience, what you’ve learned, and what you currently believe is true, and set it aside long enough to look at the problem again.

경험을, 배운 걸, 지금 사실이라고 믿는 걸. 잠깐 옆에 놔둬라.

…

실제로도 회사 생활을 하다보면 그런 경우가 많은 거 같긴하다.

원래 사람이라는게, 자기가 겪어봤던 상황이랑 비슷한 상황이 앞에 있으면 그 기억부터 보니까.

실사례?

회사에서 최근에 퇴사자가 좀 있어서, 백엔드 쪽을 외주 인력으로 굴리기 시작했다.

이 분이 경력이 꽤 되신다. 얘기하다 보니 2G 휴대폰 시절부터 쭉 하신 것 같더라. 그러니까 나보다 못해도 3배 이상은 축적된 짬바인 셈이다.

그러다가 오프라인 → 온라인 전환 시 데이터 동기화 로직 얘기를 하게 됐다.

우리가 짜야 할 그림은 이랬다.

다수의 클라이언트 → 1개의 서비스로 양방향 동기화.

각 기기가 오프라인에서 데이터를 쌓다가, 온라인 되면 서버로 밀어올린다. 서버는 그걸 받고, 다른 기기가 올린 것도 이 기기 쪽으로 다시 내려준다.

이 구조에서 “이 데이터 동기화됐냐?” 플래그는 어디에 있어야 할까?

각 기기의 로컬이다. 기기마다 자기가 뭘 올렸고 뭘 받아왔는지를 알아야 되고, 그 진행 상태는 기기마다 다 다르다. 서버 입장에서는 A 기기 관점의 “동기화됨” 상태랑 B 기기 관점의 “동기화됨” 상태를 하나의 플래그로 표현할 방법이 없다.

근데 그 분이 제안한 게 서버에 플래그를 두자는 거였다.

이유가 좀 뭐랄까… “예전에 가스공사 쪽 검침원들 쓰는 기기 소프트웨어 만들 때 그렇게 했다” 였다.

…?

가스 검침 소프트웨어는 아마 1기기 ↔ 1 서버 계정, 검침원 한 명이 자기 단말만 들고 다니는 구조였을 거다. 그러면 서버에 플래그 둬도 아무 문제 없다. 서버 플래그 = 그 검침원 상태니까.

근데 지금 우리는 다수 클라이언트 ↔ 1 서버다. 서버 플래그 하나에 여러 기기가 물려있으면, A 가 올린 걸 서버가 “동기화됨” 으로 마크하는 순간, 아직 그 데이터를 못 받아온 B 는 자기 관점에선 “동기화 안 됨” 인데 서버는 이미 “됨” 이라고 답한다. 아니 뭐 여기서부터 답이 안 나온다.

한참 얘기했는데… 쉽지 않았다.

돌아서 앉으면서 좀 이상한 기분이 들었다.

이 글이 말하는 게 딱 이거였구나 싶었다.

예전 문제의 답이 지금 문제의 답으로 자동으로 딱 떠오르는건데… 문제는 “이게 진짜로 지금 뭐 하려는 거지” 를 다시 안 열어본게 만든다는 것이다.

내… 얘긴가?

실사례로 남의 이야기를 하긴 했지만, 곱씹어 생각해보면 나도 그런 적이 없었나? 하고 단언할 수는 없을 거 같다.

새 프로젝트를 시작하고 기획을 할 때나 데이터 구조를 잡을 때나… 이런 상황에는 어떻게 짜야 제일 괜찮을까? 에 대한 답을 자꾸만 과거 기억에서 찾으려고 할 때가 있다.

이거 만들 때는 이렇게 했지, 저렇게 했지.

사실 뭐, 안 그런 사람은 없을 거 같긴한데 그것도 잘 맞는 상황에는 결국 잘한 공부가 되는거니까 난 나쁘게만은 보지 않는다.

agent 시대라 더 그렇다

이 얘기 왜 하필 지금 나왔나 하면.

The engineers I see keeping up with what’s possible are willing to put what they know in a box for a while as they work with agents.

agent 랑 같이 굴리는 사람들, 그러니까 뭐가 되는지 안 되는지 잘 따라가는 사람들은 다 자기가 아는 걸 잠깐 옆에 치워두는 사람들라고 한다.

맞나…? 난 사실 그냥 공부한 것보다 에이전트에게 물어보는게 더 확실하니까 그랬던 거 같긴 하다..ㅋㅋㅋ

심지어 요즘 AI판은 2주에 하나씩 버전업이 되는 판이라…

거기다 Claude Code 앞에 앉으면 뭐 하나 해볼 때 사이클이 진짜 빨라졌다.

예전 같으면 이거 될까 이틀은 붙어서 알아봐야 했던 걸, 지금은 대충 5분이면 답이 나오는 편이니까.

…근데 5분 만에 결과 나온다고, 내 판단이 5분 안에 좋아지는 건 아니다.

내가 뭘 만들지 자체가 얕으면, agent 는 그 얕은 걸 5분 안에 뚝딱 만들어놓고 끝낸다. 얕은 판단이 진짜 코드까지 굳는 데 5분이면 되는 시대인 거고.

가스공사 케이스도 그래서 좀 더 무섭게 느껴졌다. 예전 답 자동으로 꺼내놓은 게, 이제는 5분에 진짜 코드까지 뽑혀버리니까.

재밌는 사이드 노트

읽다가 좀 재밌었던 부분.

Some of the best I’ve worked with came from customer support or services. Others taught themselves to code or started as designers or entrepreneurs.

자기가 같이 일해봤던 훌륭한 시니어들이 CS 정통이 아니라 고객 지원이나 서비스 부서에서 넘어온 사람, 독학한 사람, 디자이너나 창업자 출신이었다는 것.

공통점이 “뭘 만들려는지” 를 이해하고 있었다고.

당연할 것 같기도 하다.

요즘은 더더욱, 어떻게 코드를 짜야하나…! 에 대한 “정답지”들이 질문 몇 번이면 나오니까.

유저 경험에 대한 디테일을 더 잘 잡을 수 있는 사람들이 더욱 선호되는 거 같다.

마치며

글이 이 한 줄로 끝난다.

Long Live Human Thinking.

사실 따지고 보면 그렇게 놀랄 일도 아니다.

우린 모두 그러니까.

내가 잠을 잘못 잤나봐요. 목이 좀 아프네요..ㅎㅎ 라고 이야기 했을 때,

“어떻게 아픈데” 가 아니가 “아, 그거? 나도 그랬는데 목이 아니라 어깨 문제래.” 라고 자기 경험부터 말하는 사람들처럼 사람은 원래 본인의 기억부터 꺼내고 보는 게 디폴트다.

10년, 20년의 경력 상관 없이 앞에 있는 문제를 진짜로 새로 열어보는 건 원래부터 사람한테 잘 안 되는 일이었다.

근데 그게 어려우니까 관두자는 게 결론일 리는 없고. 오히려 agent 시대엔 판단을 잘 못하면 프로토타입이 10분만에 나오니, 프로토타입을 20개 만들고 싶은게 아니라면 코딩 뉴비로 돌아가서 지금 이 상황에 주관적인 내용 다 빼고 객관적으로 이렇게 하는 게 맞는지 한 번 살펴봐야 한다는 거 같다.

사실 그냥 짧아서 가져와봤다.

제에발 글 좀 쓰자 영준아.

마침.