정말 가치 있는 지식은 왜 말로 설명할 수 없을까 — 암묵지와 개발자 성장

설명할 수 없는 앎이 있다

개발을 몇 년 하다 보면 신기한 경험을 하게 되는데요. 코드를 딱 보면 "이거 뭔가 냄새나는데"라는 감이 오는 순간이 있어요. 어디가 문제라고 콕 집어 말하기는 어려운데, 뭔가 잘못됐다는 걸 직감적으로 아는 거죠. 이런 걸 "코드 스멜을 맡는다"고 표현하기도 하는데, 이 능력은 책에서 배운 게 아니라 수많은 코드를 읽고 디버깅하면서 몸에 밴 거예요.

Dead Neurons 블로그에 올라온 이 글은 바로 이런 종류의 지식에 대해 이야기해요. 제목이 "왜 가장 가치 있는 것들은 말로 표현할 수 없는가"인데요, 철학에서 말하는 "암묵지(tacit knowledge)"라는 개념을 개발과 기술의 맥락에서 풀어낸 글이에요.

암묵지가 뭔가요?

암묵지라는 개념은 원래 마이클 폴라니라는 헝가리 출신 철학자가 정리한 건데요. 쉽게 말해서 "알고 있지만 말로 설명할 수 없는 지식"이에요. 자전거 타는 법을 생각해보면 이해가 빨라요. 자전거를 탈 줄 아는 사람에게 "어떻게 균형을 잡아?"라고 물으면, 대부분 "그냥... 타다 보면 돼"라고 답하거든요. 핸들을 몇 도 꺾고, 무게중심을 어디에 두고, 페달을 어떤 힘으로 밟는지를 정확히 설명하는 건 거의 불가능해요. 그런데 몸은 정확히 알고 있죠.

이 글의 저자는 이런 암묵지가 소프트웨어 개발에서 엄청나게 중요한 역할을 하고 있다고 주장해요. 예를 들어볼게요. 시니어 개발자가 아키텍처를 결정할 때, 명시적인 체크리스트를 하나하나 확인하면서 결정하는 게 아니에요. 과거에 비슷한 규모의 시스템을 만들어본 경험, 특정 패턴이 어떤 상황에서 잘 깨지는지에 대한 감각, 팀의 역량과 프로젝트의 제약 조건을 종합적으로 고려해서 "이게 맞아"라는 판단을 내리는 거예요. 이 과정을 문서화하려고 하면 핵심이 빠져버려요.

AI 시대에 암묵지가 더 중요해지는 이유

여기서 흥미로운 논점이 나오는데요. AI가 발전하면서 명시적으로 표현할 수 있는 지식(형식지)의 가치는 급격히 떨어지고 있어요. 문법 규칙, API 사용법, 알고리즘 구현 방법 같은 건 이제 AI한테 물어보면 바로 답이 나오잖아요. 구글링해서 Stack Overflow 찾던 시절보다 훨씬 빠르게요.

그런데 AI가 대체하지 못하는 영역이 바로 이 암묵지예요. "이 프로젝트에서 마이크로서비스로 쪼개야 할까, 모놀리스로 가야 할까?"라는 질문에 대한 답은 컨텍스트에 따라 완전히 달라지거든요. 팀 규모, 배포 주기, 도메인의 복잡성, 조직의 성숙도 등 수많은 변수가 복합적으로 작용하는데, 이걸 다 형식화해서 규칙으로 만드는 건 불가능에 가까워요. 경험 많은 개발자의 "감"이 필요한 영역이죠.

저자는 이걸 "암묵지의 역설"이라고 부르는데요. 지식을 명시적으로 표현하기 쉬울수록 AI에 의해 대체될 가능성이 높고, 표현하기 어려울수록 인간만이 제공할 수 있는 고유한 가치가 된다는 거예요. 그러니까 아이러니하게도, 가장 가치 있는 지식이 가장 전달하기 어려운 지식이 되는 세상이 온 거죠.

그러면 암묵지는 어떻게 키우나요?

문제는 암묵지를 의도적으로 학습하기가 정말 어렵다는 거예요. 책으로 배울 수 없고, 강의를 들어서도 안 되고, 결국 경험을 통해서만 쌓이거든요. 그래서 이 글의 저자가 제안하는 방법들이 몇 가지 있어요.

첫째, 다양한 프로젝트를 직접 경험하는 거예요. 같은 종류의 프로젝트만 반복하면 암묵지의 범위가 좁아져요. 다른 도메인, 다른 규모, 다른 기술 스택의 프로젝트를 경험할수록 패턴을 인식하는 능력이 넓어지죠.

둘째, 시니어 개발자와 함께 일하면서 페어 프로그래밍이나 모빙(mob programming) 세션을 하는 거예요. 시니어가 코드를 보면서 "음... 이건 좀 그런데"라고 할 때, 그 "좀 그런" 느낌이 뭔지를 옆에서 관찰하면서 자연스럽게 흡수하는 거죠. 도제식 학습이 암묵지 전달에 가장 효과적인 방식이에요.

셋째, 의사결정 일지를 쓰는 거예요. ADR(Architecture Decision Record)이라고도 하는데요, 기술적 결정을 내릴 때 "왜 이 선택을 했는지"를 기록해두는 거예요. 물론 암묵지를 완벽하게 글로 옮기는 건 불가능하지만, 기록하려는 시도 자체가 자신의 사고 과정을 더 선명하게 만들어주거든요.

한국 개발자 커리어에 주는 시사점

이 글이 한국 개발자들에게 특히 와닿을 수 있는 지점이 있는데요. 바로 채용과 성장에 대한 이야기예요.

한국 IT 업계에서 개발자 채용할 때 코딩 테스트를 많이 보잖아요. 알고리즘 문제를 풀어서 형식지를 측정하는 방식인데, 이 글의 관점에서 보면 이건 AI도 잘하는 영역을 평가하는 거예요. 정작 실무에서 중요한 건 "이 상황에서 어떤 아키텍처를 선택할 건가", "이 레거시 코드를 어떻게 점진적으로 개선할 건가" 같은 암묵지 영역인데, 이걸 평가하는 건 면접관에게도 어렵고 지원자에게도 증명하기 어려운 거죠.

그래서 주니어 개발자분들에게 드리고 싶은 조언은, 단순히 새로운 기술을 빨리 배우는 것에만 집중하지 말고, 하나의 프로젝트를 오래 유지보수해보는 경험을 쌓으라는 거예요. 6개월 전 자신이 작성한 코드를 다시 보면서 "아, 이때 왜 이렇게 했지"라는 경험이 쌓여야 진짜 암묵지가 만들어지거든요. 새 프로젝트를 시작하는 것보다 기존 프로젝트를 개선하는 과정에서 배우는 게 훨씬 많아요.