코드가 어려운 부분이 아니었다는 말이 왜 그렇게 화를 돋우는가

• 회의에서 그 문장이 나오면 방 온도가 바뀝니다
• 원문이 던진 질문들
• 화를 돋우는 진짜 이유는 범주 바꿔치기입니다
• 그렇다고 반대편이 다 맞는 것도 아닙니다
• 코드를 세 층으로 쪼개면 논쟁이 끝납니다
• 우리 팀이 어느 층에 시간을 쓰는지 재 보기
• 층마다 도구의 값어치가 다릅니다
• 그래서 무엇을 연습할 것인가
• 참고 자료

회의에서 그 문장이 나오면 방 온도가 바뀝니다

분기 계획 회의에서 누군가 이렇게 말합니다. "이제 코드 짜는 건 어려운 부분이 아니니까, 우리는 뭘 만들지에 더 집중하면 됩니다."

말한 사람은 좋은 뜻이었을 겁니다. 그런데 엔지니어 쪽 표정이 굳습니다. 반박하려니 마땅한 문장이 안 떠오릅니다. "코드도 어렵습니다"라고 하면 방어적으로 들리고, 그냥 넘어가면 다음 분기 인력 계획에 그 전제가 그대로 들어갑니다.

원문이 던진 질문들

2026년 8월 8일에 공개되어 Hacker News에서 크게 논의된 글에서 Senko Rašić는 이 문장을 정면으로 받습니다. 그의 방식은 논증이 아니라 질문 던지기입니다.

코딩이 쉽다면 왜 프로그래머 수요가 그렇게 높았고 임금이 그렇게 높았는가. 코딩이 쉽다면 왜 Clean Code나 The Pragmatic Programmer 같은 두꺼운 책들이 존재하는가. 코딩이 쉽다면 왜 사람들은 자기 코드가 복제되는 것에 화를 내는가. 그리고 방향을 뒤집어서, 무엇을 만들지 정하는 것이 어려운 부분이라면 왜 그렇게 많은 제품 담당자가 갈피를 못 잡는 것처럼 보이는가.

결론은 양자택일을 거부하는 쪽입니다. 둘 다여야 한다는 것이고, AI에게 이해와 판단과 공감과 안목을 외주 주지 말라는 문장으로 끝납니다.

화를 돋우는 진짜 이유는 범주 바꿔치기입니다

이 반박에 동의하면서도, 왜 그 문장이 유독 화를 돋우는지는 조금 다르게 설명할 수 있습니다. 문제는 참인지 거짓인지가 아니라 단어가 도중에 뜻을 바꾼다는 데 있습니다.

"코드는 어려운 부분이 아니다"라는 문장에서 코드는 처음에 좁은 뜻으로 등장합니다. 문법을 알고 API를 찾아 타이핑하는 일입니다. 이 뜻이라면 문장은 옳습니다. 그리고 대화가 진행되면서 같은 단어가 슬며시 넓어집니다. 결론에 이를 때쯤이면 코드는 엔지니어링 전체를 가리키고 있고, 그래서 "엔지니어링은 어려운 부분이 아니다"라는 명제가 아무도 증명하지 않은 채 통과합니다.

듣는 사람이 화가 나는 것은 이 통과 때문입니다. 반박하려면 먼저 단어를 되돌려 놓아야 하는데, 회의 중에 그걸 하려면 말이 길어지고 그러는 사이 논의는 다음 안건으로 넘어갑니다.

이 구조는 다른 직군에서도 똑같이 작동합니다. "디자인은 이제 쉽다"는 문장에서 디자인이 처음에는 시안 만들기를 가리키다가 문제 정의까지 삼키고, "글쓰기는 이제 쉽다"에서 글쓰기가 문장 다듬기를 가리키다가 논증 구성까지 삼킵니다. 매번 같은 자리에서 같은 방식으로 논의가 어긋나는데, 어긋나는 지점이 단어에 있다는 사실은 잘 지적되지 않습니다.

그렇다고 반대편이 다 맞는 것도 아닙니다

여기서 균형을 잡아야 합니다. 원래 문장에도 참인 부분이 분명히 있습니다.

무엇을 만들지 정하는 일은 실제로 어렵습니다. 이해관계자마다 다른 것을 원하고, 그들이 말하는 것과 필요한 것이 다르고, 요구는 만드는 도중에 바뀝니다. 이 영역에서의 실패는 코드가 아무리 좋아도 회수되지 않습니다. 잘 만든 필요 없는 기능은 그냥 잘 만든 낭비입니다.

그래서 이 논쟁을 "코드가 어렵다 vs 요구가 어렵다"로 끌고 가면 양쪽 다 절반씩 맞는 자리에서 끝나지 않고, 서로의 절반을 인정하지 않은 채 반복됩니다. 나갈 방법은 단어를 쪼개는 것입니다.

코드를 세 층으로 쪼개면 논쟁이 끝납니다

코딩이라고 뭉뚱그려 부르는 활동은 최소한 세 층으로 나뉩니다.

이 구분을 넣고 나면 두 주장이 각각 어디서 참인지 즉시 보입니다. 코드가 어려운 부분이 아니라는 말은 1층에 대해 강하게 참이고, 2층에 대해 부분적으로 참이며, 3층에 대해서는 근거가 없습니다. 그리고 원래 문장이 화를 돋우는 이유는 1층의 참을 3층까지 끌고 가기 때문입니다.

우리 팀이 어느 층에 시간을 쓰는지 재 보기

이 구분이 유용한 이유는 잴 수 있기 때문입니다. 논쟁을 감으로 하지 않으려면 자기 팀의 분포를 알아야 합니다.

2주 실험: 완료한 작업마다 태그 하나를 붙인다

L1  대부분의 시간을 문법, API, 정형화된 변환에 썼다
L2  대부분의 시간을 구조와 경계와 제약을 정하는 데 썼다
L3  대부분의 시간을 불변식, 실패 양상, 마이그레이션을 따지는 데 썼다
RQ  대부분의 시간을 무엇을 만들지 알아내는 데 썼다

2주 뒤 네 숫자를 본다. 논쟁 대신 이 분포를 놓고 이야기한다.

해 보면 대개 팀마다 결과가 크게 다릅니다. 신규 서비스를 만드는 팀은 L1과 RQ가 높고, 10년 된 시스템을 유지하는 팀은 L3가 압도적입니다. 그리고 이 분포가 다르기 때문에 두 팀은 같은 문장을 듣고도 전혀 다르게 반응합니다. 한쪽에게는 그 문장이 사실이고, 다른 쪽에게는 자기 일이 통째로 지워진 소리로 들립니다.

태그는 작업 하나에 하나만 붙이는 것이 중요합니다. 여러 개를 허용하면 전부 세 개씩 붙어서 분포가 사라집니다. 어느 층에 시간을 가장 많이 썼는지 하나만 고르게 하면, 애매한 작업일수록 고르는 과정에서 스스로 무슨 일을 했는지 정리하게 되는 효과도 생깁니다. 2주로 부족하면 4주로 늘리되, 결과를 사람별 평가에 쓰지 않는다는 것을 먼저 약속해야 숫자가 정직해집니다.

층마다 도구의 값어치가 다릅니다

분포를 알고 나면 다음 결정이 쉬워집니다. AI 도구의 값어치도 층마다 다르기 때문입니다.

1층에서는 값어치가 큽니다. 이건 논쟁의 여지가 별로 없고, 실제로 대부분의 생산성 향상 체감이 여기서 나옵니다. 2층에서는 값어치가 조건부입니다. 제약을 명시적으로 줄 수 있으면 좋은 안을 여럿 받을 수 있지만, 제약을 말로 못 옮기면 무난한 기본값이 돌아옵니다. 3층에서는 값어치가 가장 작습니다. 불변식과 실패 양상의 상당 부분이 어디에도 적혀 있지 않고 사람의 머릿속에만 있기 때문입니다.

그래서 3층이 두꺼운 조직에서 "코드는 이제 쉽다"를 전제로 인력 계획을 세우면 정확히 그 조직이 가장 크게 다칩니다. 반대로 1층이 두꺼운 조직에서 도구 도입을 미루는 것도 손해입니다. 같은 문장이 조직마다 다른 처방으로 이어져야 합니다.

그래서 무엇을 연습할 것인가

원문의 결론은 이해와 판단과 공감과 안목을 외주 주지 말라는 것이었습니다. 층 구분을 얹으면 이 조언이 더 구체적인 행동이 됩니다.

3층은 문서화로 옮길 수 있는 부분이 생각보다 많습니다. 불변식을 코드 주석이 아니라 실행 가능한 검사로 만들고, 알려진 실패 양상을 런북에 적고, 마이그레이션 경로를 결정할 때 버린 대안을 남깁니다. 이건 도구를 위해서가 아니라 사람을 위해서입니다. 머릿속에만 있는 지식은 그 사람이 팀을 떠나면 사라지고, 그 순간 조직의 3층은 정말로 비어 버립니다.

2층은 연습 방법이 조금 다릅니다. 이 층의 실력은 제약을 말로 옮기는 능력과 거의 같기 때문에, 구현을 시작하기 전에 지켜야 할 조건을 목록으로 적어 보는 습관이 그대로 훈련이 됩니다. 조건을 못 적겠다면 아직 문제를 이해하지 못한 것이고, 그 상태에서 나온 결과물은 누가 만들었든 검토가 불가능합니다.

그리고 회의로 돌아가서, 다음에 그 문장이 나오면 이렇게 되물으면 됩니다. 어느 층을 말씀하시는 건가요. 이 질문 하나로 대화는 감정 문제에서 계획 문제로 바뀌고, 방 안의 누구도 자기 일을 변호할 필요가 없어집니다.

참고 자료

• "Code was never the hard part" is an insult to all programmers — Senko Rašić, 2026-08-08 — 본문에 인용한 질문들과 결론이 이 글의 내용입니다.
• Hacker News 토론 — 반대편 의견이 상당히 많이 달렸고, 그 반론들도 함께 읽을 가치가 있습니다.
• 이 블로그의 관련 글: 마찰이 사라지면 안목이 남는 게 아니라 안목을 기를 길이 사라집니다
• 세 층 구분과 2주 실험은 원문에 나오는 것이 아니라 제가 정리한 틀입니다.