어떻게 일해야 하는가? (feat. 직관)

본 내용은 사내 강좌에 등장한 내용을 축약하고, 개인적인 소감 위주로 작성한 글입니다.
기술 이야기가 조금 나오지만, 핵심은 직원으로서의 커리어/비즈니스 관점이기에, 기술 언급에 매몰되지 않고 재미로 읽어주시면 감사드리겠습니다.

 

서론

최근에는 더 이상 저녁 7시에 글을 올리는 방식을 유지하기 어렵다고 판단했다.(퇴근하면 9시다.)

그래서 발행 시간을 저녁 10시로 변경했다.

 

또한 현재 기준으로는, 토이 프로젝트를 병행하지 않는 이상 기술 블로그를 지속적으로 쓰는 일이 쉽지 않다고 느낀다.
그 이유는 실무의 기술적 의사결정이 대개 비즈니스 지표, SLA, SLO를 기준으로 이루어지기 때문이다.

 

하지만 이런 수치를 외부에 그대로 공개하는 순간, 내부 상황을 어느 정도 역산할 수 있게 되고, 결국 정보보안 이슈와 맞닿게 된다.
즉, 실무에서 실제로 중요했던 판단을 그대로 풀어내기는 구조적으로 제한이 있다.

 

그래서 당분간은 여러 토이 프로젝트를 직접 진행하면서, 각 프로젝트 안에서 발생한 기술적 선택과 그 근거 위주로 정리해보려 한다.

다만 이런 글들이 과연 유의미한 포트폴리오로 누군가에게 도움이 될 지에 대해서는 아직 확신이 없다.
결국 한동안은 기술 블로그 자체보다,나는 어떻게 일해야 하는가,어떤 기준으로 판단해야 하는가,어떻게 생각을 훈련해야 하는가에 대한 기록이 더 많아질 것 같다.

---

일의 방식

관점	내용
DFS 방식 사고	직접 계산하고 깊이 파고드는 방식은 강력하지만, 시간이 오래 걸린다.
BFS 방식 사고	빠르게 넓게 퍼뜨리고, 우선 말하고, 빠르게 검증하는 방식이다.
핵심	결국 중요한 것은 빠르고 정확하게 소통하는 것이다.

1. DFS 방식 사고: 깊이 파고드는 힘

깊이 들어가서 직접 계산하고 끝까지 따져보는 습관은 분명 필요하다.

다만 이 방식만으로 일하면 속도가 지나치게 느려질 수 있다.

그래서 실무에서는 종종 직관이 계산을 이겨야 한다.

 

여기서 말하는 직관은 근거 없는 감각이 아니라, 다음의 곱으로 만들어지는 판단력에 가깝다.

• 경험
• 생각의 깊이
• 반복
• AI와 함께한 학습
• 확률적인 타율 개선

즉, 직관은 보이는 수준에서 생각을 멈추지 않고, 깊이 있는 사고를 여러 번 반복한 결과로 축적되는 압축된 판단력이다.

2. BFS 방식 사고: 빠르게 뱉고 빠르게 맞추기

비즈니스에서는 대부분 깊이는 기본이다.
급변하는 비즈니스 환경 속에서는 속도가 반드시 확보되어야 한다.
이럴 때는 일단 빠르게 말하고, 빠르게 정리하고, 빠르게 공유해야 한다.

 

실무에서는 생각이 완벽해질 때까지 기다리는 것보다,
현재 시점에서 가장 합리적인 가설을 빠르게 제시하는 능력이 더 중요할 때가 많다.

결국 DFS와 BFS는 대립하는 개념이 아니라, 상황에 따라 전환해야 하는 사고 모드다.

3. 디자인 리뷰와 ADR

이 과정에서 중요한 장치가 바로 디자인 리뷰와 ADR(Architecture Decision Record) 이다.

ADR은 단순히 “무엇을 선택했다”를 기록하는 문서가 아니다.
그보다 더 본질적으로는 다음을 남기는 도구다.

• 왜 이 선택을 했는가
• 무엇을 포기했는가
• 어떤 대안을 검토했는가
• 이 결정이 비즈니스적으로 어떤 의미가 있는가

즉, 좋은 엔지니어링은 코드 이전에 의사결정의 서사를 남기는 일과 연결된다.

---

비즈니스 결정

그렇다면, 과연 모든 결정은 기술적으로 완벽해야 할까?

주제	핵심 질문
데이터 지연	무엇은 늦어져도 되고, 무엇은 늦어지면 안 되는가?
흐름의 분리	데이터의 흐름과 제어의 흐름을 분리할 수 있는가?
정합성	stale read를 줄이기 위해 어디까지 비용을 감수할 것인가?
비용	더 정확해지기 위해 복잡도와 자원을 얼마나 쓸 것인가?

1. 데이터 지연을 허용할 것인가

우리가 사용하는 쇼핑몰 시스템을 한번 떠올려보자.

우리는 일반적으로 "어느정도 수준까지" 버그를 허용할까?

 

모든 데이터를 실시간으로 유지하는 것은 매우 비싼 비용이 든다.

일례로, 최고 수준의 DB를 유지하기 위해선 월 억대의 비용이 든다.
하지만, 한 대 만으로는 모든 데이터를 실시간으로 유지하기 어렵다.

 

모든 데이터가 항상 실시간이어야 하는 것은 아니다.
예를 들어 가격 정보는 읽는 시점에 다소 지연되어도 괜찮을 수 있다.
단, 그 전제는 분명하다.

• 모든 사용자가 같은 가격을 본다는 가정
• 비즈니스적으로 허용 가능한 지연 범위가 정의되어 있다는 점

즉, 기술적으로 "의도적으로 버그를 만든다"고 말하기 전엔,
이 지연이 비즈니스적으로 허용되는가를 판단해야 한다.

2. 결국은 생각 비용의 트레이드오프다

좋은 선택이란 언제나 공짜가 아니다.
정확도를 높이려는 시도는 보통 다음 비용을 수반한다.

• 복잡도 증가
• 자원 사용량 증가
• 운영 비용 증가
• 시간 비용 증가

특히 시간 비용은 실무에서 치명적이다.
회사 입장에서는, 오래 고민한다고 더 나은 결과가 보장되지는 않는다.
실무에는 항상 압박이 있고, 의사결정은 대부분 제한된 시간 안에 이루어진다.

그래서 중요한 것은 완벽한 해답이 아니라,
짧은 시간 안에 얼마나 올바른 지점까지 도달했는가다.

---

훈련 방향

1. 고점을 알아야 저점을 안다

성장은 타협에서 시작되지 않는다.
오히려 반대다. 고점을 먼저 알아야, 어디서 타협해야 하는지도 보인다.

도구의 끝을 모르면, 문제를 비효율적으로 푼다.
단순 BFS로 풀 문제에 세그먼트 트리가 도입될 수 있고,
단순 DB로 받아낼 수 있는 문제에 메시지 큐 도입을 만든다.

 

처음부터 “적당히 이 정도면 되지”라고 말하는 사람은,
그 적당함이 정말 적당한지 판단할 기준 자체가 부족할 수 있다.

깊이 탐색해본 사람만이 나중에 적정 지점으로 되돌아올 수 있다.

즉, 끝까지 가본 경험(오버엔지니어링)이 있어야 현실적인 타협도 가능하다.

2. 경험과 자신감은 자산이다

결국 설득력은 말재주에서 나오지 않는다.
설득력은 다음 질문에 답할 수 있을 때 생긴다.

• 이 문제를 끝까지 가본 적이 있는가?
• 직접 부딪혀 본 적이 있는가?
• 선택의 장단점을 몸으로 이해하고 있는가?

많이 해본 사람일수록 더 빠르게 발산하고 더 빠르게 수렴한다.

• 기술적 요구를 받을수록 더 많이 발산해야 한다.
• 비즈니스 요구를 받을수록 더 많이 수렴해야 한다.

즉, 탐색과 결정은 모두 필요하며,
둘 사이의 전환 속도가 실력의 일부다.

3. 좋은 엔지니어는 좋은 내러티브를 만든다

좋은 엔지니어는 단순히 정답을 맞히는 사람이 아니다.
왜 그렇게 판단했는지를 설득력 있게 설명할 수 있는 사람이다.

기술적 선택은 언제나 대안이 존재한다.
따라서 중요한 것은 “이게 맞다”가 아니라,
왜 지금, 이 맥락에서, 이 선택이 가장 적절한가를 이야기하는 능력이다.

---

데이터 기반 설득

개발자는 고객을 만족시키기 위해, SLA와 SLO라는 지표를 사용한다.

아마 모두에게 걸맞는 직군만의 지표가 있을 것이다.

그에 대입해서 읽으면 이해하기 쉽다.

개념	의미
SLA	고객에게 어떤 수준의 서비스를 보장할 것인지에 대한 약속
SLO	그 SLA를 지키기 위해 내부적으로 관리하는 목표
내러티브	기술적 선택을 고객 관점과 비즈니스 언어로 설명하는 능력

1. SLA를 먼저 정의해야 한다

예를 들어 다음과 같은 문장은 매우 강력하다.

우리 시스템은 데이터 전파 지연이 최대 X초 이내임을 보장한다.

이 한 문장이 의미하는 바는 크다.
SLA가 먼저 정의되면, 엔지니어링의 범위도 명확해진다.

• 어디까지 최적화해야 하는가
• 어디부터는 과한가
• 어떤 복잡도는 감수할 가치가 있는가
• 어떤 비용은 불필요한가

즉, SLA는 단순한 지표가 아니라 엔지니어링의 경계선이다.

2. 좋은 내러티브란 무엇인가

좋은 내러티브란 기술적 선택의 이유를
고객 관점과 비즈니스 관점으로 설명할 수 있는 상태를 말한다.

예를 들면 이런 설명이 가능해야 한다.

우리는 SLA 기준을 만족하기 때문에 Eventual Consistency를 선택했다.
또한 Strong Consistency를 포기한 이유는, 추가 복잡도와 비용이 비즈니스 가치 대비 과도했기 때문이다.

 

이런 설명은 단순히 개념을 아는 것만으로는 나오지 않는다.
실제로 복잡도의 끝을 어느 정도 탐험해본 사람만이
“여기서 멈추는 것이 합리적이다”라고 말할 수 있다.

3. 오버엔지니어링을 통해 성장하라. 하지만, SLA와 SLO가 암기될 정도로 가까워야 한다

성장하려면 오버엔지니어링을 해봐야 한다.

위에서 말했듯, 끝까지 가봐야 다시 돌아올 수 있따.
다만 동시에, 오버엔지니어링은 실제 비용을 동반한다.

 

그래서 사용해야 하는 것이 SLA와 SLO이다.
자연스럽게 떠올릴 수 있을 정도로 반복해서 사용해야 한다.

그래야 다음이 가능해진다.

• 오버엔지니어링을 감지하기
• 필요한 투자와 불필요한 투자를 구분하기
• 기술적 선택을 수치로 설명하기
• 설득 가능한 내러티브 만들기

따라서 결국 핵심은 SLA와 SLO를 기준으로 설명 가능한 선택을 하는 것이다.

---

커리어 관리: 스위치 온 / 오프

1. 쉬는 날에도 완전히 꺼져 있으면 도태된다.

쉬는 날에 실제로 쉬는 것은 필요하다.
다만 쉬는 것이 "괴로운 일에서의 탈피"가 되고,

아무 긴장도 없이 완전히 손을 놓는 상태가 길어지면,
결국 감각은 무뎌질 수 있다.

 

그래서 어느 정도는 늘 삶에 긴장 상태를 걸어둘 필요가 있다고 느낀다.
아주 작은 것이어도 좋다.
무언가를 만들고, 결과를 내고, 평가를 받아보는 흐름이 끊기지 않아야 한다.

2. 긴장을 거는 방법

긴장을 건다는 것은 무작정 자신을 몰아붙인다는 뜻이 아니다.
오히려 다음과 같이 정리할 수 있다.

오버드라이브

필요한 순간에는 의식적으로 출력을 높여야 한다.
즉, 평소보다 빠르게 판단하고 빠르게 실행해야 한다.

직관으로 빠르게 판단하기

예를 들어 의사가 생명을 다루는 일분 일초가 긴박한 순간,
호기심 때문에 탐구만 하고 있으면 안 된다.
그 순간 필요한 것은 정확한 타이밍의 실행이다.

 

실무도 비슷하다.
항상 모든 것을 다 이해한 뒤 움직일 수는 없다.
필요한 일만 빠르게, 샤프하게 수행해야 한다.

타이밍이 제일 중요하다는 게 이해 가고 납득은 되는데, 솔직히 내가 그걸 잘하진 못한다.
주변 상황에 몰려 급하게 진행할 경우 놓쳐서 후회한 경험도 있었고, 나보다 직관이 더 좋은 사람들과 비교하게 되기도 한다.
항상 이렇게 급하게 몰릴 때, 천천히, 차근차근(Go/Gradually)에만 집중했는데, 마치 이게 내가 회피한 것 뿐인가? 라는 고민도 든다.

 

그래도, 직관을 타고난 감각으로만 보지 않고, 경험의 압축본으로 번역하기 시작하면 자신감이 생긴다.

즉, 준비되어 있어야 한다.
많이 해본 사람만이 빠르게 깊게 생각하고, 또 빠르게 빠져나올 수 있다.

기술이 아닌 비즈니스를 배워야 한다

결국 비즈니스는 타이밍이다.
그래서 중요한 것은 모든 근거를 다 모으는 것이 아니라,
비즈니스적으로 설득에 필요한 최소한의 데이터가 무엇인지 아는 것이다.

필요한 것은 보통 다음 조합이다.

• 딱 필요한 만큼의 정량적 데이터
• 딱 필요한 만큼의 정성적 분석
• 최소한의 이해관계자 파악
• 타이밍에 맞는 의사결정

모든 근거를 확보하겠다고 실행이 늦어져서도 안 되고,
근거 없이 찍어서 타율이 너무 낮아져서도 안 된다.

예를 들어,

• Mission critical한 영역이라면
  개발자도 비즈니스 데이터를 받아 SLA와 SLO를 함께 결정해야 한다.
• 반대로 ROI가 높지 않거나 빠르게 실험해야 하는 영역이라면
  기존 데이터를 바탕으로 현실적인 SLA와 SLO를 naive하게 설정할 수 있다.

3. 긴장을 줄일 때 - 깊이 탐구하기

계속 긴장만으로는 오래 버티기 어렵다.

또한, 필요할 때 긴장을 켜기 위해선, 긴장을 꺼뒀을 때 준비해야 한다.

깊이 탐구하기

평소에는 오히려 깊이 파고들어야 한다.
실무에서 단순하고 직관적인 결정을 내리기 위해서는,
그 단순함의 배경에 있는 복잡도를 한 번쯤 끝까지 봐야 한다.

오버엔지니어링 경험하기

오버엔지니어링은 무조건 피해야 할 대상이 아니다.
끝까지 해봐야만 어디서 되돌아와야 하는지 알 수 있다.

즉,

• 끝까지 파고들어 보고
• 기술적인 내러티브를 만들어 보고
• 그 뒤에야 합리적으로 적정 지점을 선택할 수 있다

개념 정리하기

단순히 경험하고 끝내면 안된다.

사용한 개념을 정리해두면, 이후에는 더 빠르게 재탐색할 수 있다.
이 지점에서 다시 BFS식 사고가 중요해진다.

 

깊이 파본 경험을 개념 단위로 정리해두면,
필요할 때 빠르게 꺼내 쓸 수 있기 때문이다.

결국 이 모든 경험은 나중에 직관이 된다.

나는 이 게임을 해봤어요!

 

이 감각이 실제 판단 속도를 바꾼다.

---

결론

솔직히 말하면, 잘할 수 있을지 걱정된다.

지금까지 내가 스스로 유의미하다고 느꼈던 결과들을 떠올려보면 다음과 같다.

• 알고리즘 대회 수상 2회
• 상태 패턴 적용 경험
• DEVS 엔진 이해
• 소프티어 입상
• 카카오 코딩테스트 경험
• 핀잇 개발
• 알림 시스템 최적화
• 최근 진행했던 면접 경험

솔직히 말해서, 지금 내가 돌아봐도 엄밀하게 증명해서 해냈다기 보단, 찍어서 맞춘 순간들이다.

쭉 나열해보니, 해본 적은 있어서 어느정도 안심이 되긴 한다.

 

위 결과는 다음과 같은 과정들을 통해 이루었다.

• 직관으로 찍고, 경험으로 내러티브를 만들어내 포장했다.
• 완벽한 절차를 거치지 않았고, 나의 경험으로 건너뛰었다.
• 일단 만들어놓고, 성능 테스트로 검증했다.

다만 냉정하게 보면, 이런 장면은 늘 자주 오지 않았고, 몇 개월에 한 번씩 찾아오는 희귀한 순간들에 가까웠다.

 

• 그리고 그 사이에는 그보다 훨씬 많은 실패가 있었다.
• 체감상 실패 횟수는 성공보다 두세 배 이상 많았고, 현재의 타율도 30%가 채 안 되는 수준이다.

문제는 그다음이다.
이걸 가끔이 아니라 상시적으로 발동해야 한다고 하니, 부담이 커진다.

왜 부담되는가를 생각해보면 이유는 분명하다.

• 가능한 경우의 수를 최대한 많이 파악하고 싶다
• 안정적으로 운영하고 싶다
• 나보다 더 직관이 좋은 사람들을 많이 봐왔기 때문에 자꾸 비교하게 된다

 

하지만 실무와 비즈니스는 종종 정확성보다 타이밍을 더 크게 요구한다.

 

그래서 아마 한동안은 많이 지적받고, 많이 깨질 가능성이 높다.
그럼에도 진심으로 더 많은 일을 할 수 있게 되고 싶다면, 결국은 계속 시도해야 한다.

 

부담은 분명 존재한다.
그러나 현재로서는 결론이 이렇게 내려진다.

노력해서 만든 서비스는 완벽하게 나오는 것보다 "제때 나오는 것"이 훨씬 중요하다.
우선, 이러한 것들을 배울 수 있음에 감사하자.
계속 기록하며 성공률을 확인하고 추세를 살피며, 피드백을 수행하자.