Originally published on tamiz.pro.

화이트보드 인터뷰는 죽어가고 있다. 면접관들이 갑자기 양심을 갖게 되어서가 아니라, 소프트웨어 엔지니어링의 근본 단위 자체가 우리 발밑에서 바뀌었기 때문이다. 지난 20년간 업계는 특정 유형의 인지 부하에 표준화되어 왔다: 데이터 구조를 정신적으로 조작하고 정렬이나 그래프 순회(graph traversal) 알고리즘을 처음부터 구현하는 능력이다. 이것은 모든 로직 라인을 스스로 작성해야 했던 시대에 문제 해결 능력을 측정하는 대리 지표였다.

하지만 우리는 더 이상 모든 라인을 직접 작성하지 않는다. GitHub Copilot, Cursor, Devin과 같은 정교한 AI 코딩 에이전트의 등장으로 병목 현상은 더 이상 _구문(syntax)_이나 _알고리즘 구현_에 있지 않다. 병목 현상은 바로 _판단력(judgment)_이다.

업계는 알고리즘 암기 능력을 평가하는 것을 멈추고, 외부 시스템, API 및 복잡한 통합을 빠르게 흡수하고, 가설을 세우고, 테스트하며, 검증하는 능력인

이는 나쁜 일이 아닙니다. 엔지니어들을 지루한 노동에서 해방시켜 줍니다. 하지만 이는 우리의 채용 및 평가 파이프라인에 위험한 격차를 노출시킵니다. 우리는 여전히 구현 비용이 높았고 알려지지 않은 종속성(dependencies)을 디버깅하는 비용이 낮았던 2010년 기준으로 면접을 보고 있습니다. 오늘날, 구현 비용은 거의 제로에 가깝지만, 알려지지 않은 종속성을 디버깅하는 비용은 거의 무한대에 가깝습니다.

2024년에 만약 당신의 빠른 정렬(quicksort) 코드를 암기하여 작성하는 능력 때문에 고용된다면, 당신은 이미 상품화된 기술에 대해 고용되고 있는 것입니다. 시장이 교정하고 있지만, 느리게 진행되고 있습니다. 이 교정이 완전히 이루어지기 전까지는, 완벽하고 독립적인 코드는 작성할 수 있지만 이를 혼란스럽고 분산된(distributed), AI 지원 워크플로우에 통합할 수 없는 엔지니어가 될 위험을 안게 됩니다.

'코드를 맛본다'는 것은 무엇인가?

'코드를 맛본다(Tasting code)'는 특정 유형의 기술적 직관(technical intuition)을 비유적으로 이르는 말입니다. 이는 블랙박스(black-box) 또는 반투명한 시스템을 빠르게 흡수하고, 그 동작에 대한 가설을 세우며, 최소한의 목표 지향적인 상호작용을 통해 그 가설을 검증하는 능력을 의미합니다.

와인을 시음하는 소믈리에를 생각해 보세요. 그들은 모든 포도의 화학적 구성을 암기하지 않습니다. 대신 프로필, 균형, 산도 그리고 그것이 음식과 어떻게 어울리는지를 이해합니다. 마찬가지로, 현대 엔지니어는 다음을 통해 코드를 '맛봅니다':

1. 논리뿐만 아니라 계약(Contracts) 읽기: 함수나 API의 내부 if/else 문보다는, 그 안팎으로 흐르는 데이터의 형태를 이해하는 것입니다.
2. 엣지 케이스(Edge Cases) 탐색: 문서에 명시적으로 나와 있지 않더라도, API가 타임아웃 시 null을 반환할 수 있다는 것, 또는 데이터베이스 트랜잭션이 높은 동시성(concurrency) 하에서 교착 상태(deadlock)에 빠질 수 있다는 것을 아는 것입니다.
3. 마찰력(Friction) 평가: 라이브러리의 '끈끈함'을 느끼는 것입니다. 문서화가 잘 되어 있는가? 오류 메시지가 상세한가? 특정 런타임과 강하게 결합되어 있는가?
4. 맥락 합성(Synthesizing Context): 시스템의 이질적인 조각들을 연결하는 것입니다. 캐싱 계층은 데이터베이스 라이터와 어떻게 상호작용하는가? AI가 생성한 코드가 여기서 경쟁 조건(race condition)을 유발한다면 어떻게 되는가?

이러한 기술은 45분짜리 LeetCode 세션에서는 가르치기 어렵습니다. 이는 무언가를 망가뜨려 보고, 새벽 3시에 에러 로그(error logs)를 읽고, 엉망진창인 제3자 SDK(third-party SDKs)를 통합하며 배우는 것입니다.

새로운 주니어 개발자로서의 AI 에이전트 (AI Agent)

AI 에이전트를 사용하는 엔지니어의 워크플로(workflow)를 생각해 보십시오. 이제 AI는 당신의 주니어 개발자입니다. AI가 보일러플레이트(boilerplate)를 작성합니다. AI가 단위 테스트(unit tests)를 작성합니다. AI가 유틸리티 함수(utility functions)를 리팩터링(refactor)합니다.

당신의 업무는 더 이상 코드를 작성하는 것이 아닙니다. 당신의 업무는 **검토(review), 지시(direct), 그리고 통합(integrate)**하는 것입니다.

만약 당신이 AI가 생성한 코드를 "맛볼" 수 없다면, 당신은 위험한 존재입니다. 구문론적으로는 완벽하지만 의미론적으로는 결함이 있는 AI 생성 솔루션을 수용할 수도 있기 때문입니다. 예를 들어, AI는 당신이 알고 있는 인덱스(index)를 무시한 채, 1,000만 개의 행이 있는 데이터셋에서 O(N) 시간 복잡도로 실행되는 완벽하게 유효한 SQL 쿼리를 생성할 수 있습니다. 겉보기에는 올바르고 실행도 됩니다. 하지만 운영 환경(production)을 다운시켜 버립니다.

"맛보는 사람(taster)"은 이를 알아챕니다. 그들은 작업의 무게감을 느낍니다. 그들은 "이 쿼리가 테이블을 잠그게(lock) 될까?"라고 질문합니다. 그들은 EXPLAIN ANALYZE를 실행하여 순차 스캔(sequential scan)을 찾아냅니다. 그들은 B-트리(B-trees)가 어떻게 구현되는지 알 필요는 없습니다. 그들에게 필요한 것은 부하(load) 상황에서 데이터베이스의 _동작(behavior)_을 이해하는 것입니다.

이러한 변화는 새로운 종류의 멘탈 모델(mental model)을 요구합니다. 당신은 더 이상 빌더(builder)가 아닙니다. 당신은 아키텍트(architect)이자 품질 보증(quality assurance) 엔진입니다. AI가 벽돌을 제공한다면, 당신은 집이 무너지지 않도록 보장해야 합니다.

새로운 기술 면접

암기가 쓸모없어졌다면, 무엇이 그 자리를 대신할까요? 면접 프로세스는 서서히 적응하고 있지만, 여전히 뒤처져 있습니다. 효과적이고 현대적인 기술 평가의 모습은 다음과 같습니다:

1. 시스템 디자인 심층 분석 (System Design Deep Dive)

"Twitter를 설계하라" 대신, "사용자의 편지함을 압도하지 않으면서 전달을 보장하는 알림 시스템을 설계하라"고 질문하십시오. 이는 큐(queues), 백프레셔(backpressure), 사용자 경험(user experience), 그리고 에지 케이스(edge cases)에 대한 이해도를 테스트합니다. 또한 일관성(consistency)과 가용성(availability) 사이의 트레이드오프(trade-offs)를 맛보는 능력을 요구합니다.

2. 디버깅 시나리오 (The Debugging Scenario)

후보자에게 오류가 포함된 코드 스니펫이나 알려진 병목 현상이 있는 시스템 다이어그램을 제공하고, 문제를 식별하도록 요청합니다. 예를 들어 다음과 같습니다:

"이 API 엔드포인트는 부하 상태에서 시간 초과(timing out)됩니다. 여기 로그가 있습니다. 데이터베이스 CPU는 낮습니다. 네트워크 지연 시간은 정상입니다. 가설은 무엇입니까?"

이는 정렬 알고리즘을 작성하는 능력이 아니라, 가설을 세우고 데이터를 수집하는 능력을 테스트합니다.

3. 코드 리뷰 시뮬레이션 (The Code Review Simulation)

미묘한 버그가 포함된 PR(Pull Request)을 제공합니다: 경쟁 조건(race condition), 메모리 누수(memory leak), 또는 안전하지 않은 API 호출 등입니다. 후보자에게 이를 검토하도록 요청합니다. 그들은 보안 취약점을 발견합니까? 비효율적인 루프를 알아차립니까? 이는 코드 냄새(code smell)와 시스템적 위험에 대한 민감도, 즉 '맛보는' 능력을 테스트합니다.

4. 통합 과제 (The Integration Challenge)

후보자에게 제3자 API(예: Stripe, Twilio)를 간단한 애플리케이션에 통합하도록 요청합니다. 그들은 오류를 우아하게 처리합니까?멱등성(idempotent) 요청을 작성합니까? 웹훅(webhook)의 개념을 이해하고 있습니까? 이는 여러분이 작성하는 코드가 문제의 20%밖에 되지 않는 실제 엔지니어링 능력을 테스트합니다.

'코드 맛보기' 능력 개발 방법

엔지니어라면, 어떻게 이 능력을 배양할 수 있을까요? 책을 읽는다고 해서 배울 수는 없습니다. 실제 시스템의 복잡성(messiness)에 참여해야 합니다.

블랙박스 받아들이기 (Embrace the Black Box)

라이브러리 코드의 모든 줄을 읽으려고 노력하는 것을 멈추세요. 대신 경계면(boundaries)에 집중하세요. 새로운 라이브러리를 사용할 때는 그것을 극한까지 밀어붙이는 작은 테스트를 작성하세요. 형식이 잘못된 입력(malformed input)을 보내면 어떻게 될까요? 거대한 페이로드(huge payloads)를 보내면 어떻게 될까요? 오류 메시지를 맛보세요. 실패 모드(failure modes)를 이해하세요.

운영 로그 읽기 (Read Production Logs)

조직의 로그 집계 시스템(Datadog, Splunk, CloudWatch)에서 시간을 보내세요. 오류를 찾으세요. 느린 쿼리를 찾으세요. 시간 초과를 찾으세요. 증상과 원인을 연관시키려고 노력하세요. 이는 시스템이 스트레스 하에서 어떻게 작동하는지에 대한 직관을 쌓아줍니다.

통합 테스트 작성 (Write Integration Tests)

유닛 테스트는 가짜로 만들기 쉽습니다. 통합 테스트는 어렵습니다. 데이터베이스를 구동하고, 외부 서비스를 모킹(mock)하며, 네트워크 장애를 처리해야 합니다. 통합 테스트를 작성하고 유지 관리하는 과정은 단순히 고립된 함수들의 집합이 아니라 시스템 전체로서 이해하도록 강제합니다.

오픈 소스에 기여하기 (Contribute to Open Source)

오픈 소스 코드는 지저분합니다. 문서화는 종종 오래되었고, API는 예고 없이 변경됩니다. 이러한 혼란을 헤쳐나가는 것이 궁극적인 '맛보기' 연습입니다. 자신이 작성하지 않은 코드를 읽고, 주석과 커밋 기록에서 의도를 추론하며, 기존 기능을 망가뜨리지 않으면서 의미 있게 기여하는 방법을 배웁니다.

AI 시대의 인간적 요소 (The Human Element in an AI World)

비평가들은 인공지능(AI) 역시 결국 코드를 '맛볼' 수 있게 될 것이라고 주장할 수 있습니다. 그들은 테스트를 실행하고, 문서를 읽고, 심지어 자체적으로 코드를 디버깅할 수 있는 AI 에이전트를 지적합니다. 이는 어느 정도 사실입니다. AI는 이 분야에서 점점 더 발전하고 있습니다.

하지만 판단력은 여전히 인간의 기술입니다. AI는 오류가 _무엇_인지 알려줄 수는 있지만, 그것이 사용자의 특정 비즈니스 목표와 관련하여 왜 중요한지 항상 알려주지는 못합니다. 기술 부채(technical debt)와 출시 속도 사이의 상충 관계를 항상 저울질할 수는 없습니다. 사용자 경험에 공감하는 것 역시 항상 할 수 있는 것은 아닙니다.

코드를 '맛보는' 엔지니어는 이러한 미묘한 결정을 내릴 수 있는 사람입니다. 그들은 언제 리팩토링(refactor)해야 하고, 언제 패치(patch)해야 하며, 언제 버그를 그냥 넘어가야 하는지 아는 사람들입니다. 그들은 코드가 단순히 논리일 뿐만 아니라 소통이며, 비즈니스 가치이고, 위험이라는 것을 이해하는 사람들입니다.

결론: 큐레이터로서의 엔지니어 (Conclusion: The Engineer as Curator)

소프트웨어 엔지니어링의 미래는 더 많은 코드를 작성하는 것이 아닙니다. 더 나은 코드를 큐레이션(curating)하는 것입니다. 올바한 제약 조건 하에서, 올바한 방식으로, 올바한 문제를 해결하도록 AI 에이전트를 지시하는 것입니다.

이는 사고방식의 전환을 요구합니다. 연결 리스트를 역전시키는 능력을 자랑하는 것을 멈추고, 분산 트랜잭션을 디버깅하거나, 복원력 있는 API를 설계하거나, 복잡한 타사 시스템을 통합하고, 유지보수 가능하며 안전하고 비즈니스 목표에 부합하는 코드를 작성하는 능력을 자랑하기 시작해야 합니다.

암기 시대는 끝났습니다. '맛보는' 시대가 시작되었습니다. 만약 자신의 코드를 '맛볼' 수 없다면, 당신은 AI 시대를 맞이할 준비가 되지 않은 것입니다. 당신은 그저 발생하기를 기다리는 구문 오류(syntax error)일 뿐입니다.

자주 묻는 질문 (FAQ)

LeetCode가 완전히 쓸모없나요?
아닙니다. LeetCode는 컴퓨터 과학의 기초를 형성하는 자료 구조와 알고리즘을 학습하는 데 매우 훌륭합니다. 하지만 이는 일상적인 엔지니어링 기술의 나쁜 대용품(poor proxy)입니다. 기본기를 배우는 용도로 사용하되, 그것에 의존하여 자신의 역량을 측정해서는 안 됩니다.

단위 테스트만 작성한다면 어떻게 '맛보기'를 시작할 수 있나요?
사용하는 라이브러리의 문서를 읽는 것부터 시작하되, 거기서 멈추지 마십시오. 문서화된 제약 조건을 위반하는 테스트를 작성해 보세요. 무슨 일이 일어나는지 살펴보세요. 의존하는 라이브러리의 소스 코드를 탐색하여 오류 처리(error handling)와 엣지 케이스(edge cases)를 이해하세요.

알고리즘을 모르는 엔지니어는 AI에게 대체될까요?
AI는 비판적으로 생각할 수 없는 엔지니어를 대체할 것입니다. 알고리즘을 아는 것보다 그것들을 어떻게 사용할지, 언제 사용할지, 그리고 더 큰 시스템에 어떻게 통합할지를 아는 것이 더 중요합니다. 만약 당신이 오직 알고리즘만 암기할 수 있다면, AI가 당신을 대체할 것입니다. 하지만 시스템을 설계하고 판단을 내릴 수 있다면, 당신이 AI를 지휘하게 될 것입니다.