면접 질문에서 두 사람이 이메일로 스프레드시트를 주고받는 상황을 제시받았음
나는 Google Sheets로 옮기겠다고 답했는데, 면접관은 내가 직접 도구를 설계하길 원했던 것 같음
그때는 어색했지만, 지금도 어떤 교훈을 얻어야 할지 잘 모르겠음
이런 상황은 면접관 교육 실패라고 생각함
좋은 답변을 인정하고, 그다음에 “이건 기술 설계 평가를 위한 가상 상황이니 새 시스템을 설계해보자”고 유도했어야 함
지원자가 그 설정을 받아들이지 못하면 그건 또 다른 신호로 평가하면 됨
나 같으면 “기존 솔루션이 없다고 가정하고 새로 설계할까요?”라고 물어볼 것임
이건 면접관이 자신이 원하는 답만 듣고 싶어 하는 시스템 설계 버전의 알고리즘 논쟁과 같음
내 공동창업자가 Stripe 인수 논의 중에 시스템 설계 면접을 봤는데, 요구사항을 듣고 “그냥 Postgres에 넣겠다”고 답했음
실제로 그게 맞는 판단이었지만, Patrick Collison이 직접 전화해서 “면접은 통과 못 했지만, 취지는 이해하냐”고 물었음
결국 다시 면접을 보고 통과했음 면접의 목적을 이해하는 게 중요함을 보여주는 일화였음
친구와 이 주제로 토론한 적 있음
어떤 대형 페리 회사가 Google Sheets로 선박 위치와 직원 배정을 관리하는데, 친구는 “이건 대기업이 할 일이 아니다”라고 했음
하지만 나는 이미 검증된 도구로 문제를 해결한 게 훌륭하다고 생각함
덕분에 사내 개발팀이나 비싼 외주 없이 운영 가능함
내 자만심을 깊이 묻어두게 된 경험이었음
이런 면접 질문이라면, 먼저 “왜 이게 문제인가요?”라고 되묻는 게 좋다고 생각함
상대가 구체적으로 어떤 점이 안 맞는지 설명하게 한 뒤, 그제야 기술적 설계를 시작해야 함
올바른 답은 “왜 Google Sheets를 안 쓰고 이메일로 주고받고 있나요?”라고 묻는 것임
Sheets를 못 쓰는 이유는 다양함 — 기능 제약, 중국 내 접근 제한, 회사 정책, 네트워크 문제 등
고객이 이미 이런 이유로 커스텀 솔루션을 원할 수도 있음
즉, 단순히 “Google Sheets 쓰세요”가 아니라 고객의 맥락을 이해하는 것이 개발자의 역할임
AI 코딩 도구가 문제를 더 미묘하게 악화시키고 있음
이제는 복잡한 아키텍처를 5분 만에 생성할 수 있지만, 유지보수 비용은 그대로임
결과적으로 더 화려한 구조가 빠르게 만들어지고, 승진용 문서도 금세 완성됨
하지만 실제로는 아무도 그 코드를 완전히 이해하지 못함
진짜 단순함의 기준은 “다음 사람이 질문 없이 이해할 수 있는가”인데, AI 생성 코드는 그 시험을 완전히 통과하지 못함
사실 LLM 이전에도 새벽 3시에 호출된 온콜 담당자들이 시스템을 잘 모르는 경우가 많았음
이제는 그게 더 심해질 뿐임
그래서 나는 조직의 코드 이해 문화가 얼마나 강한지를 커리어 선택의 기준으로 삼고 있음
아무도 시스템을 모르는 상황은 다시 겪고 싶지 않음
이런 이유로 앞으로는 소프트웨어 제품 자체의 가치가 줄어들 것 같음
문제 해결이 목표라면, AI로 만든 도구든 구매한 도구든 결국 문제를 해결해야 함
하지만 기성 제품이 맞지 않으면 결국 직접 생성한 커스텀 솔루션이 늘어날 것임
다만 그걸 아무도 이해하지 못하면, 다음 사람이 또 새로 만들겠지
그래도 사용자와 제작자가 가까워지는 점에서는 개선일 수도 있음
AI 도구를 쓸 때 유지보수성 원칙을 문서화하는 게 중요함
예를 들어 AGENTS.md에 “KISS”, “YAGNI” 같은 지침을 명시해두면 도움이 됨
나도 AI로 코딩하면서 단순함을 유지하려고 노력함
문제는 “다음 사람”이 결국 6개월 뒤의 나 자신이라는 점임
AI도 context window 한계로 같은 문제를 겪음
AI가 만들어낸 코드의 운영 비용도 무시 못함
많은 개발자가 인기 스택만 좇고, 운영 용이성은 고려하지 않음
AI도 “이건 과한 설계야”라고 말해주지 않음
Kubernetes와 ElasticSearch를 원하면, 그대로 만들어줄 뿐임
FAANG과 스타트업을 모두 경험한 입장에서, 복잡성과 단순성의 균형이 핵심임
대기업에서는 임시방편식 해킹이 수천 명의 생산성을 해칠 수 있고,
스타트업에서는 과도한 인프라가 회사를 망칠 수 있음
진짜 숙련된 엔지니어는 두 상황을 구분하고, 경험으로 적절한 트레이드오프를 선택할 줄 아는 사람임
팀 규모가 5명일 때와 500명일 때의 결함 발생률은 완전히 다름
자기 관리형 프로젝트 매니징 능력은 정말 배우기 어려운 기술임
Amazon(2005~2008) 근무 시절, 회사 문화의 상징이었던 두 가지 상이 있었음
“Just Do It” 상은 자발적 문제 해결, “Door Desk” 상은 절약과 단순함을 상징했음
실제로 쓸모없는 TV를 치운 직원이 상을 받았는데, 보상으로 그 TV를 줬던 일화가 있음
하지만 그 문짝 책상은 사실 Ikea보다 비싸고 조립도 어려웠음
은유로서의 단순함이 현실에서는 좀 모호했음
지금도 “Just Do It” 상은 여전히 수여되고 있음
단순함을 주장하려면 비즈니스 언어로 표현해야 함
“사건 80% 감소”, “비용 40% 절감”, “성능 33% 향상” 같은 식으로
단순함 자체는 평가받지 못하지만, 그 결과는 높이 평가받음
하지만 “복잡한 걸 만들지 않은 덕분”의 효과는 측정하기 어려움
처음부터 빠른 시스템을 설계해도, 느린 걸 만든 뒤 80% 개선한 사람보다 덜 인정받음
단순함은 P&L에 보이지 않기 때문에 승진으로 이어지기 어려움
나는 리팩터링을 비용 모델로 전환해 KPI를 계측하고, MTTR을 60% 줄였음
이런 수치를 직접 보여줘야 인정받음
나이가 들수록 복잡성에 저항하게 됨
하지만 리더십은 종종 “이해 못 해서 반대한다”고 오해함
가장 오래 살아남은 프로젝트는 단순하고 교체가 쉬운 것들이었음
AI 도구는 이런 접근을 더 쉽게 만들어줌 — 독립된 샘플 프로젝트로 컴포넌트를 실험하고, 검증된 코드를 본 프로젝트에 통합함
내부망 환경이라 AI를 직접 연결하진 않지만, 이 방식은 매우 유용함
리더십은 종종 단순한 접근을 게으름으로 오해함
그래서 나는 “복잡한 것도 만들 수 있지만, 먼저 간단한 버전으로 시작하자”고 제안함
대부분 그 단순한 버전이 결국 수년간 운영되는 프로덕션 코드가 됨
이런 교훈은 결국 직접 고생해봐야 배움
단순한 솔루션을 빠르게 내놓은 개발자는 남은 시간에 여러 기능을 더 구현할 수 있음
반면 복잡한 솔루션에 매달린 사람은 한 기능에 몇 주를 쏟음
결국 생산성 지표에서는 단순한 접근이 더 매력적으로 보임
나 역시 “큰 아이디어”보다 꾸준히 결과를 내는 사람으로 커리어를 쌓아왔음
하지만 너무 단순하면 “작은 기능만 한 사람”처럼 보일 위험도 있음
또 어떤 사람은 “남성 중심적 표현”을 문제 삼았지만, 핵심은 결과 중심의 문화였음
우리 회사 면접 중 하나는 공공 도서관 시스템 설계 문제임
처음엔 작은 마을 도서관 규모로 시작해, 전국 단위로 확장하는 시나리오임
최고의 답변은 “최대 규모여도 중간급 서버와 Postgres면 충분하다”였음
하지만 어떤 면접관은 “초당 10,000 요청” 같은 비현실적 스케일을 요구함
현실적으로는 10이나 10,000이나 큰 차이 없는데, 경험 없는 면접관이 프롬프트만 읽는 경우가 많음
“모든 회사가 Spotify급 시스템을 설계하진 않는다”는 걸 잊지 말아야 함
초기 웹은 서버실 한 구석의 장비로도 수백 요청을 처리했음
이후 과도한 인프라와 이력서 중심 개발이 문제를 키웠음
AI는 결국 사용자의 역량을 증폭시키는 도구라고 생각함
숙련된 개발자에게는 생산성을 높여주지만, 미숙한 사람에게는 혼란을 빠르게 확산시키는 도구가 됨
나는 단순함을 선호하는 엔지니어인데, AI가 코드를 더 단순하게 만들지는 못했음
오히려 불필요한 래퍼 함수와 타입 변환을 추가하는 경향이 있음
AI는 “코드를 더 추가하는 쪽”에 가깝다고 느낌
하지만 경험이 부족해도 비판적으로 학습하려는 태도로 AI를 사용하면, PR 전에 스스로 코드를 개선하는 데 도움이 될 수 있음
나도 ChatGPT Codex로 시작하기 어려웠던 작업을 착수하게 된 경험이 있음
다만 깊이 없는 “vibe coding”이 늘어나는 건 우려스러움
Hacker News 의견들
면접 질문에서 두 사람이 이메일로 스프레드시트를 주고받는 상황을 제시받았음
나는 Google Sheets로 옮기겠다고 답했는데, 면접관은 내가 직접 도구를 설계하길 원했던 것 같음
그때는 어색했지만, 지금도 어떤 교훈을 얻어야 할지 잘 모르겠음
좋은 답변을 인정하고, 그다음에 “이건 기술 설계 평가를 위한 가상 상황이니 새 시스템을 설계해보자”고 유도했어야 함
지원자가 그 설정을 받아들이지 못하면 그건 또 다른 신호로 평가하면 됨
나 같으면 “기존 솔루션이 없다고 가정하고 새로 설계할까요?”라고 물어볼 것임
이건 면접관이 자신이 원하는 답만 듣고 싶어 하는 시스템 설계 버전의 알고리즘 논쟁과 같음
실제로 그게 맞는 판단이었지만, Patrick Collison이 직접 전화해서 “면접은 통과 못 했지만, 취지는 이해하냐”고 물었음
결국 다시 면접을 보고 통과했음
면접의 목적을 이해하는 게 중요함을 보여주는 일화였음
어떤 대형 페리 회사가 Google Sheets로 선박 위치와 직원 배정을 관리하는데, 친구는 “이건 대기업이 할 일이 아니다”라고 했음
하지만 나는 이미 검증된 도구로 문제를 해결한 게 훌륭하다고 생각함
덕분에 사내 개발팀이나 비싼 외주 없이 운영 가능함
내 자만심을 깊이 묻어두게 된 경험이었음
상대가 구체적으로 어떤 점이 안 맞는지 설명하게 한 뒤, 그제야 기술적 설계를 시작해야 함
Sheets를 못 쓰는 이유는 다양함 — 기능 제약, 중국 내 접근 제한, 회사 정책, 네트워크 문제 등
고객이 이미 이런 이유로 커스텀 솔루션을 원할 수도 있음
즉, 단순히 “Google Sheets 쓰세요”가 아니라 고객의 맥락을 이해하는 것이 개발자의 역할임
AI 코딩 도구가 문제를 더 미묘하게 악화시키고 있음
이제는 복잡한 아키텍처를 5분 만에 생성할 수 있지만, 유지보수 비용은 그대로임
결과적으로 더 화려한 구조가 빠르게 만들어지고, 승진용 문서도 금세 완성됨
하지만 실제로는 아무도 그 코드를 완전히 이해하지 못함
진짜 단순함의 기준은 “다음 사람이 질문 없이 이해할 수 있는가”인데, AI 생성 코드는 그 시험을 완전히 통과하지 못함
이제는 그게 더 심해질 뿐임
그래서 나는 조직의 코드 이해 문화가 얼마나 강한지를 커리어 선택의 기준으로 삼고 있음
아무도 시스템을 모르는 상황은 다시 겪고 싶지 않음
문제 해결이 목표라면, AI로 만든 도구든 구매한 도구든 결국 문제를 해결해야 함
하지만 기성 제품이 맞지 않으면 결국 직접 생성한 커스텀 솔루션이 늘어날 것임
다만 그걸 아무도 이해하지 못하면, 다음 사람이 또 새로 만들겠지
그래도 사용자와 제작자가 가까워지는 점에서는 개선일 수도 있음
예를 들어
AGENTS.md에 “KISS”, “YAGNI” 같은 지침을 명시해두면 도움이 됨문제는 “다음 사람”이 결국 6개월 뒤의 나 자신이라는 점임
AI도 context window 한계로 같은 문제를 겪음
많은 개발자가 인기 스택만 좇고, 운영 용이성은 고려하지 않음
AI도 “이건 과한 설계야”라고 말해주지 않음
Kubernetes와 ElasticSearch를 원하면, 그대로 만들어줄 뿐임
FAANG과 스타트업을 모두 경험한 입장에서, 복잡성과 단순성의 균형이 핵심임
대기업에서는 임시방편식 해킹이 수천 명의 생산성을 해칠 수 있고,
스타트업에서는 과도한 인프라가 회사를 망칠 수 있음
진짜 숙련된 엔지니어는 두 상황을 구분하고, 경험으로 적절한 트레이드오프를 선택할 줄 아는 사람임
Amazon(2005~2008) 근무 시절, 회사 문화의 상징이었던 두 가지 상이 있었음
“Just Do It” 상은 자발적 문제 해결, “Door Desk” 상은 절약과 단순함을 상징했음
실제로 쓸모없는 TV를 치운 직원이 상을 받았는데, 보상으로 그 TV를 줬던 일화가 있음
은유로서의 단순함이 현실에서는 좀 모호했음
단순함을 주장하려면 비즈니스 언어로 표현해야 함
“사건 80% 감소”, “비용 40% 절감”, “성능 33% 향상” 같은 식으로
단순함 자체는 평가받지 못하지만, 그 결과는 높이 평가받음
나는 리팩터링을 비용 모델로 전환해 KPI를 계측하고, MTTR을 60% 줄였음
이런 수치를 직접 보여줘야 인정받음
관리자로서 나는 단순한 코드를 선호했음
하지만 팀이 숙련된 인원으로 구성되어 있었기 때문임
경험이 적은 팀에서는 The Parable of The Toaster 같은 일이 벌어짐
나이가 들수록 복잡성에 저항하게 됨
하지만 리더십은 종종 “이해 못 해서 반대한다”고 오해함
가장 오래 살아남은 프로젝트는 단순하고 교체가 쉬운 것들이었음
AI 도구는 이런 접근을 더 쉽게 만들어줌 — 독립된 샘플 프로젝트로 컴포넌트를 실험하고, 검증된 코드를 본 프로젝트에 통합함
내부망 환경이라 AI를 직접 연결하진 않지만, 이 방식은 매우 유용함
그래서 나는 “복잡한 것도 만들 수 있지만, 먼저 간단한 버전으로 시작하자”고 제안함
대부분 그 단순한 버전이 결국 수년간 운영되는 프로덕션 코드가 됨
단순한 솔루션을 빠르게 내놓은 개발자는 남은 시간에 여러 기능을 더 구현할 수 있음
반면 복잡한 솔루션에 매달린 사람은 한 기능에 몇 주를 쏟음
결국 생산성 지표에서는 단순한 접근이 더 매력적으로 보임
나 역시 “큰 아이디어”보다 꾸준히 결과를 내는 사람으로 커리어를 쌓아왔음
우리 회사 면접 중 하나는 공공 도서관 시스템 설계 문제임
처음엔 작은 마을 도서관 규모로 시작해, 전국 단위로 확장하는 시나리오임
최고의 답변은 “최대 규모여도 중간급 서버와 Postgres면 충분하다”였음
현실적으로는 10이나 10,000이나 큰 차이 없는데, 경험 없는 면접관이 프롬프트만 읽는 경우가 많음
이후 과도한 인프라와 이력서 중심 개발이 문제를 키웠음
AI는 결국 사용자의 역량을 증폭시키는 도구라고 생각함
숙련된 개발자에게는 생산성을 높여주지만, 미숙한 사람에게는 혼란을 빠르게 확산시키는 도구가 됨
오히려 불필요한 래퍼 함수와 타입 변환을 추가하는 경향이 있음
AI는 “코드를 더 추가하는 쪽”에 가깝다고 느낌
다만 깊이 없는 “vibe coding”이 늘어나는 건 우려스러움