Richard Hamming의 You and Your Research를 7년차 백엔드·AI 엔지니어의 다음 성장 구간에 맞춰 다시 읽었다. 더 열심히 일하라는 글이 아니라, 어디에 힘을 쓰고 어떤 결과를 남길지 묻는 글이다. > 중요한 문제는 단순히 큰 문제가 아니다. 지금 가진 관찰과 수단으로 진전시킬 수 있고, 해결했을 때 다음 여러 문제의 비용까지 낮...
Richard Hamming의 You and Your Research를 7년차 백엔드·AI 엔지니어의 다음 성장 구간에 맞춰 다시 읽었다. 더 열심히 일하라는 글이 아니라, 어디에 힘을 쓰고 어떤 결과를 남길지 묻는 글이다.
중요한 문제는 단순히 큰 문제가 아니다. 지금 가진 관찰과 수단으로 진전시킬 수 있고, 해결했을 때 다음 여러 문제의 비용까지 낮추는 문제다.
이 글은 원문 전체 번역이 아니다. 강연의 핵심 논지를 선별해 해설하고, 지금의 엔지니어링 환경에 맞춘 적용 예시와 비판을 덧붙였다.
주니어에게는 "어떻게 구현하는가"가 큰 문제다. 7년차쯤 되면 구현 자체보다 어떤 문제를 골라 어떤 형태로 남기는가가 성장 폭을 가른다.
백엔드 운영, 아키텍처 개선, RAG, AI 제품과 개발 자동화를 이미 경험했다면 다음 병목은 기술 목록이 아니다. 흩어진 경험을 하나의 문제의식으로 연결하고, 반복 가능한 방식으로 바꾸며, 조직이 사용할 수 있게 전달하는 능력이다.
Hamming은 뛰어난 연구자와 그렇지 못한 연구자의 차이를 40년 넘게 관찰했다. 그의 질문은 단순하다. 능력이 충분한 사람도 왜 오랫동안 기억될 만한 일을 하지 못하는가?
그가 찾은 답은 천재성 하나가 아니었다.
여기서 "연구"는 논문에만 한정하지 않는다. 아직 답이 없고, 해결하면 다음 여러 문제의 비용까지 낮아지는 엔지니어링 작업으로 넓혀 읽을 수 있다. 새로운 장애 복구 체계, 평가 가능한 AI 파이프라인, 팀 전체가 재사용하는 개발 도구도 충분히 연구적인 일이다.
영향이 크기만 한 문제가 아니라, 지금 가진 수단으로 진전시킬 수 있는 문제를 고른다.
운은 사건을 정하지만, 준비된 문제 목록과 축적된 관찰은 그 사건을 성과로 바꾼다.
오늘의 요청만 닫지 않고 내년의 비슷한 요청이 더 싸지는 구조를 남긴다.
깊게 만드는 시간과 무엇을 만들지 감지하는 시간을 의도적으로 분리한다.
코드, 문서, 발표와 비공식 대화를 통해 다른 사람이 발견하고 사용할 수 있게 만든다.
의지력만 믿지 않고 약점과 환경을 이용해 중요한 일에 머무를 확률을 높인다.
이 글의 중심은 "위대한 사람이 되라"는 영웅주의가 아니다. 중요하다고 말하는 방향과 실제 캘린더가 일치하는지 확인하라는 운영 원칙에 가깝다.
Hamming이 말한 중요한 문제는 세상을 뒤집을 만큼 거대한 문제만을 뜻하지 않는다. 결과의 가치가 크면서도 현재의 지식, 위치와 도구로 유의미한 공격 경로가 보이는 문제다. 해결 가능성이 전혀 없는 거대 담론은 야심일 수는 있어도 좋은 작업 항목은 아니다.
중요한 문제는 다음 세 요소를 함께 만족한다.
이 관점은 백로그 우선순위와 다르다. 긴급한 업무는 오늘 처리해야 할 수 있지만, 중요한 문제는 앞으로 여러 분기의 비용 구조를 바꾼다. 둘을 같은 큐에 넣으면 긴급한 일이 항상 이긴다.
| 당장 닫는 문제 | 중요한 문제로 다시 묻기 |
|---|---|
| AI 응답 JSON이 또 깨졌다 | 모든 모델 호출에서 구조 계약과 실패 분류를 어떻게 강제할까? |
| 에이전트가 없는 클래스를 만들었다 | 도메인 컨텍스트와 검증 절차를 실행 계약으로 어떻게 만들까? |
| 운영 요청을 다시 수작업으로 처리했다 | 사람과 에이전트가 함께 쓰는 안전한 CLI 경계는 무엇일까? |
| 장애 한 건의 원인을 찾았다 | 같은 종류의 실패를 먼저 드러내는 관측 신호는 무엇일까? |
Hamming은 뛰어난 연구자들이 중요한 문제를 여러 개 품고 있다가 새로운 단서가 나타나면 연결한다고 보았다. 엔지니어에게는 거창한 연구 목록보다 5개 안팎의 문제 레이더가 현실적이다.
백엔드와 AI를 각각 별도 경력으로 늘어놓기보다 불확실한 결과를 검증 가능한 시스템으로 바꾸는 문제처럼 두 경험을 관통하는 질문을 잡는 편이 강하다. 그러면 RAG 평가, 구조화 출력, 에이전트 검토, 장애 관측과 운영 자동화가 한 방향으로 축적된다.
Hamming은 지식과 생산성이 복리처럼 쌓인다고 설명한다. 이 말을 야근의 정당화로 읽으면 핵심을 놓친다. 진짜 차이는 한 시간을 더 쓰는 데 있지 않고, 오늘의 한 시간이 내일의 학습과 실행 속도를 높이는 구조에 있다.
| 단리형 작업 | 복리형 작업 |
|---|---|
| 문제 한 건을 직접 처리하고 끝낸다 | 판단 기준과 자동화 도구를 남겨 다음 처리 시간을 줄인다 |
| 새 기술을 많이 읽고 북마크한다 | 현재 문제에 연결해 작은 실험과 의사결정 기록을 남긴다 |
| 개인만 이해하는 빠른 구현을 만든다 | 인터페이스를 좁히고 다른 사람이 확장할 수 있게 만든다 |
| 매번 좋은 프롬프트를 새로 쓴다 | 컨텍스트, 실행, 검토를 재사용 가능한 하네스로 만든다 |
이미 다양한 시스템을 경험한 단계에서는 새 키워드를 하나 더 배우는 것보다 기존 경험 사이의 공통 구조를 추출하는 편이 더 큰 복리를 만든다. 문서화도 산출물의 포장이 아니라 기억을 재사용 가능한 판단 기준으로 바꾸는 작업이 된다.
원문은 문을 닫고 일하는 사람이 단기 생산성은 높지만, 시간이 지나면 약간 빗나간 문제를 열심히 풀 위험이 있다고 말한다. 반대로 문을 열어 둔 사람은 방해를 받지만 중요한 문제가 어디에 있는지 알게 된다.
오늘의 원격·메신저 환경에서 이를 문자 그대로 적용할 필요는 없다. 핵심은 집중 생산과 문제 탐색이 서로 다른 모드라는 점이다. 알림을 항상 켜 두는 것은 열린 문이 아니라 주의력 누수다.
설계, 구현, 글쓰기와 실험처럼 연속된 사고가 필요한 작업을 90분에서 2시간 보호한다.
운영 문의, 사용자 관찰, 타 직군 대화와 리뷰에서 반복되는 마찰을 수집한다.
깊게 일하는 능력만으로는 충분하지 않다. 깊게 팔 곳을 계속 보정하는 감각이 함께 있어야 한다.
Hamming의 가장 엔지니어링다운 조언은 고립된 문제를 그대로 풀지 말라는 것이다. 눈앞의 사례를 더 넓은 문제군의 표본으로 보면, 해법은 코드 한 줄에서 인터페이스·도구·운영 방식으로 확장된다.
다만 모든 것을 플랫폼으로 만들라는 뜻은 아니다. 성급한 일반화는 사용 사례보다 추상화가 먼저 자라는 병을 만든다. 좋은 일반화는 반복 증거가 있고, 변하는 부분과 고정되는 부분이 보일 때 시작한다.
수작업 운영을 CLI로 바꾸고, AI 코딩의 시행착오를 컨텍스트와 검토 워크플로로 바꾸고, 개별 모델 응답을 구조화된 파이프라인으로 다뤄 온 경험은 이 원칙과 맞닿아 있다. 다음 단계는 각각을 "내가 만든 것"으로 나열하기보다 반복되는 불확실성을 실행 가능한 계약으로 바꾸는 방식으로 명명하는 것이다.
이 관점은 사람용 CLI와 AI 에이전트용 CLI는 설계가 다르다와 하네스 엔지니어링에서 더 구체적인 설계 문제로 이어진다.
원문은 다소 거칠게 "일을 했으면 팔아야 한다"고 말한다. 여기서 판매는 과장이나 자기 홍보가 아니다. 바쁜 사람이 왜 이 결과를 봐야 하는지 이해하고, 신뢰하고, 실제로 쓸 수 있도록 전달 비용을 대신 치르는 일이다.
| 형식 | 해야 하는 일 | 흔한 실패 |
|---|---|---|
| PR | 문제, 선택 이유, 위험과 검증 근거를 짧게 연결한다 | diff가 스스로 설명할 것이라 기대한다 |
| 설계 문서 | 결론보다 판단을 바꾼 제약과 trade-off를 남긴다 | 구현 상세를 길게 복제한다 |
| 데모 | 기능 목록보다 전후 행동과 실패 경로를 보여준다 | 행복 경로만 빠르게 통과한다 |
| 비공식 대화 | 결정이 굳기 전에 짧고 명확하게 문제를 제기한다 | 결정 후 긴 문서로 뒤늦게 반대한다 |
Hamming은 기술 발표가 세부로 너무 빨리 들어가는 문제도 지적한다. 시니어 엔지니어의 설명은 "무엇을 만들었는가"보다 "왜 이 문제가 중요하고, 기존에는 어디서 비용이 났으며, 무엇이 달라졌는가"에서 시작해야 한다. 세부 구현은 그 그림을 납득시키는 만큼만 보여준다.
Hamming은 좋은 조건이 반드시 좋은 결과를 만들지 않으며, 제약을 관점 전환의 재료로 사용하라고 말한다. 인력 부족은 자동화의 계기가 될 수 있고, 계산 자원 부족은 더 작은 해법을 찾게 할 수 있다. 중요한 것은 고통을 미화하는 일이 아니라 제약이 강제하는 질문을 발견하는 일이다.
원문은 약 7년마다 인접 분야로 이동해 낡은 성공 공식을 반복하지 말라고 조언한다. 정확한 주기는 중요하지 않다. 한 분야에서 얻은 평판이 새로운 초보자 상태를 피하게 만들 때 의도적으로 경계를 넘으라는 뜻에 가깝다.
백엔드에서 AI 서비스와 에이전트 워크플로로 이동한 것은 단절이 아니라 좋은 인접 이동이다. 분산 시스템의 계약, 검증, 관측과 실패 처리를 확률적인 AI 결과에 적용할 수 있기 때문이다. 새 분야에서 강점은 유지하되, 기존 해법을 억지로 투사하지 않는 균형이 필요하다.
이 강연은 강력하지만 특정 시대, 조직과 성공한 남성 연구자의 관찰에서 나왔다. 오늘 읽을 때는 다음 한계를 분명히 해야 한다.
원문은 가족과 건강의 희생, 높은 스트레스를 상당 부분 당연하게 취급한다. 이는 지속 가능한 성과의 보편 법칙이 아니다. 수면과 회복을 깎으면 판단력, 창의성, 관계와 장기 생산성이 함께 무너질 수 있다. 몰입은 필요하지만 자기 파괴는 전략이 아니다.
사소한 관료주의와 싸우느라 에너지를 모두 쓰지 말라는 조언은 유효하다. 하지만 차별, 안전, 괴롭힘과 공익 문제까지 "일에 집중하라"는 이유로 넘길 수는 없다. 마찰 비용을 줄이는 적응과 잘못된 구조를 묵인하는 순응은 다르다.
현대 소프트웨어와 AI 시스템은 팀, 운영, 데이터, 보안과 제품 판단이 엮인 결과다. 개인의 문제 선택은 중요하지만, 크레딧 배분과 협업 구조도 성과의 일부다. 다른 사람이 올라설 수 있는 어깨를 만든다는 원문의 표현은 개인 이름보다 공유 기반을 남긴다는 쪽으로 읽는 편이 낫다.
새로운 생산성 시스템을 크게 만들 필요는 없다. 한 달 동안 문제 선택과 실제 시간 사용을 연결해 보는 정도면 충분하다.
반복 비용이 크고 접근 경로가 보이는 문제를 5개 적는다. 각 문제마다 지금 아는 단서와 모르는 것을 한 줄씩 붙인다.
주 90분을 확보해 "어디가 변하고 있는가, 내가 가진 경험은 어디에 연결되는가"만 검토한다. 이 시간에는 구현하지 않는다.
최근 해결한 건 하나를 골라 사건, 반복 패턴, 재사용 가능한 레버리지로 다시 쓴다. 추상화가 아니라 다음 한 건의 비용 감소로 검증한다.
동료 한 명에게 10분 설명한 뒤 질문을 기록한다. 지난 4주 캘린더가 중요하다고 말한 방향과 실제로 일치했는지 확인한다.
내 분야에서 지금 정말 중요한 문제는 무엇인가? 그중 내가 실제로 접근할 수 있는 문제는 무엇인가? 이번 주 캘린더는 그 답을 믿고 있다는 증거인가?
Hamming의 강연이 오래 살아남은 이유는 성공 공식을 제공해서가 아니다. 능력이나 환경을 핑계 삼기 전에 자신의 문제 선택을 정직하게 보게 만들기 때문이다. 좋은 일을 꾸준히 해온 사람에게 이 질문은 더 날카롭다. 이제 필요한 것은 일을 더 많이 잡는 것이 아니라, 이미 가진 힘이 한 방향으로 축적되게 만드는 선택일 수 있다.
원문은 1986년 3월 7일 Bell Communications Research Colloquium에서 진행된 강연의 전사본이다. 이 글의 경력 맥락에 맞춘 적용 예시와 비판적 보정은 편집자의 해석이며 Hamming의 원문 주장과 구분된다.