내가 떠난 뒤에도
이어지는
소프트웨어를
만듭니다.

펌웨어와 SI·SM에서 시작해 B2C 서비스, 레거시 개편, 기술 리딩까지 경험했습니다. 기술은 바뀌었지만 맡는 일은 계속 넓어졌습니다. 기능을 구현하고, 운영 문제를 끝까지 추적하고, 기술과 비즈니스 사이의 비용을 설명하고, 팀에 다음 사람이 쓸 수 있는 맥락을 남기는 일입니다.

판단하는 방식

먼저 누가 어떤 문제를 겪는지, 왜 해결해야 하는지 묻습니다. 아키텍처를 고르기 전에 현재 규모와 팀의 역량, 일정, 실패 비용, 실제 운영할 사람을 함께 봅니다.

대체로 지금 문제를 푸는 가장 작은 구조에서 시작합니다. 단순함을 대충 만드는 것과 같게 보지 않습니다. 테스트할 수 있고, 읽을 수 있고, 운영할 수 있으며, 다른 사람이 고칠 수 있어야 합니다.

작업을 검토 가능한 단위로 나누고 직접 검증합니다. 장애와 측정값, 사용자 행동은 처음 계획에서 놓친 것을 드러냅니다. 현실이 달라지면 과거에 세운 원칙도 다시 고칩니다.

중요하게 생각하는 것

회사에서 만든 소프트웨어는 조직의 자산이자 사용자와 동료에게 한 약속입니다. 선택의 비용에는 구현 시간뿐 아니라 학습, 리뷰, 채용, 온보딩, 배포, 장애, 복구, 인수인계가 들어갑니다.

비즈니스와 엔지니어링을 서로 반대편에 두지 않습니다. 기술적 위험을 사업 비용으로 설명하고, 사업의 긴급함을 팀이 안전하게 전달할 수 있는 작업으로 나누는 것이 엔지니어링의 역할이라고 봅니다.

AI는 코드와 테스트, 문서, 반복 작업에 적극적으로 사용합니다. 생성량이 늘었다고 생산성이 높아진 것은 아닙니다. 문제를 정의하고, 빠진 맥락을 채우고, 잘못된 결과를 거부하고, 검증하고, 실패를 책임지는 일은 여전히 사람에게 남습니다.

결론을 강하게 말하는 편이지만 모든 상황의 정답이라고 생각하지는 않습니다. 맥락이 바뀌면 답도 바뀝니다. 나 역시 일을 과하게 떠안고, 성급하게 결론을 내리거나, 맥락보다 결론을 먼저 말할 때가 있습니다. 그래서 판단의 전제와 비용을 드러내고, 현실이 다르면 기준을 고치려 합니다.