“혼성 기술들 속에서 방향과 질서 부여하기”

이해일(이밸리사람들 이사)

아키텍트로서 갖춰야 할 소양은 어떤 게 있을까요.
아키텍트는 많은 사람을 만나 그 사이에서 무언가를 결정해야 하므로 결단력이 있어야 합니다. 잘못된 결정을 내렸을 때는 잘못을 빨리 인정하고 그 대안을 찾을 용기도 필요하고요. 또 프로젝트 단계마다 아키텍트가 집중해야 할 부분이 다른데 그에 맞게 일을 진행하는 요령도 필요합니다. 시스템이 잘못되는 건 작은 한 부분 때문인 경우가 많으므로 시스템 전반을 세심하게 살필 수도 있어야 합니다.

대부분의 개발자가 기본기를 스스로 갖출 수밖에 없는 여건에서 시행착오를 줄이는 방법은 무엇일까요.
Software Engineering Body of Knowledge(http://www.swebok.org/)를 보기를 권합니다. 소프트웨어 공학 각 분야에 필요한 지식이 정리되어 있는 것인데 자신이 하고자 하는 분야를 정해 해당 분야 지식을 공부하면 도움이 될 것입니다. 또 자신이 공부한 내용을 다른 사람들 앞에서 발표해 보기를 권하고 싶습니다. 개발자의 일이란 것이 혼자서 공부하고 그걸로 개발만 하는 것이 아니라 그 내용을 남에게 설명해야 할 때가 종종 있는데 그 과정에서 얻는 것이 많습니다.

‘화려하고 새로운 아키텍처가 유혹이 되는’ 이유는 무엇일까요.
많은 사람이 최신 기술을 적용하고 싶어하는데 그게 능사는 아닙니다. 아키텍트라면 기술 동향을 잘 따라가야 하지만 그러한 기술을 실제 적용할 것인지에 대해서는 좀 더 냉정해져야 합니다. EJB와 관련된 시행 착오들이 그 예일 것입니다. 개인적으로는 2.0이 되지 않은 기술들은 잘 쓰지 않으려 합니다.(웃음) 기업 시스템에서는 보수성을 견지해야 필요가 생길 때가 있습니다. 기술이 충분히 성숙되고 그 내부에 대해 확실히 이해하고 검토를 거친 후 적용하는 것이 좋습니다. 실례로 최근에 제조업체 프로젝트를 하나 하면서 그와 같은 과정을 거쳐 스프링을 도입했습니다. 정리하자면 최신 기술을 쓰지 말자는 것이 아니라 상황에 맞게 써야 한다는 것입니다.

공부했던 아키텍처 중에서 가장 인상 깊었던 것은 무엇인가요.
책에 나오는 사례들은 국내 현실과 좀 동떨어져 있습니다. 전투기 제어 시스템 같은 것들이 예로 나오거든요. 좀 현실성 있는 것을 꼽자면 자바 EE를 들고 싶습니다. 자바 EE가 나온 사상이나 철학을 살펴보면 배울 점이 많습니다.

직접 해오신 프로젝트 중에 기억에 남는 것이 있다면.
앞서 말한 3년 간의 모 은행 국외 CRM 구축 프로젝트입니다. 프로젝트 시작부터 이행, 시스템 자체가 진화해 가는 과정까지 참여해서 애착이 많이 가는 시스템입니다. 나라마다 법규, 로직, 언어, 로케일 등 가변성이 큰데 그것들을 대응할 수 있는 시스템을 개발하는 프로젝트였습니다. 아키텍처적으로 큰 도전이었는데 특히 다국어 처리 같은 국제화에 대해 더 깊이 이해하게 됐습니다. 시스템 운영 개시 후에 일어나는 문제들을 해결하고 개선하는 일도 했는데 즐거운 경험이었습니다.

'아키텍처건 글이건 꼭 필요한 부분만 남았을 때 가장 아름다운 법'이라고 하셨는데 구체적으로 어떤 모습이어야 할까요.
미학적인 측면의 아름다움이라기보다는 공학적인 측면에서 시스템을 유지보수하는 사람과 시스템 사용자 모두에게 이해하기 쉬운 모습이어야 한다고 봅니다. 실제로 시스템 개발 기간보다 더 오랜 시간을 유지보수를 해야 하므로 그 점을 고려해야 합니다. 각종 디자인 패턴과 첨단 기법으로 시스템을 구현해 놓았더라도 남아 있는 유지보수 인력에게 그것을 제대로 알려줄 수 없다는 문제가 있다고 봅니다. 그래서 기술을 선택할 때도 유지보수를 맡은 사람들이 넘어야 할 학습 곡선 등을 감안해 결정해야 합니다.

불필요하지만 피치 못하게 뺄 수 없는 일들도 있을 것 같은데….
마틴 파울러가 했던 말 같은데 비즈니스 ’illogic’이란 표현이 있습니다. 비즈니스 로직이란 게 얼핏 보면 제멋대로인 것처럼 보이고 그만큼 예측하기 어려운 부분이 많다는 뜻이겠죠. 결국 구현하는 사람이 시스템을 최대한 유연하게 만들어야 할 필요가 있습니다.

프로젝트를 하면서 중시하는 점이 있다면.
아키텍트가 프로젝트에 끝까지 함께 하는 것입니다. 만약 아키텍트가 초기에만 참여하고 빠졌는데 개발이 매끄럽게 진행되지 않으면 아키텍처에 문제가 있는 것 아니냐는 불만이 나올 수도 있고 시스템이 망가질 위험도 있으니까요. 그러다 보니 운영 단계까지 참여하게 되고 시스템 아키텍처를 잡을 때 향후 운영과 유지보수 단계까지 고려하려 합니다.

‘온고지신’을 강조하셨는데 옛 것에서 무엇을 배워야 할까요.
옛 시스템에 녹아 있는 설계 사상을 배워야 합니다. 어떤 기술을 쓰든 소프트웨어 공학에서 추구하는 가치는 같다고 봅니다. 모듈화라든지, 명확한 인터페이스 정의라든지, 높은 응집력이라든지 하는 원칙들이 그 예입니다. 옛 기술로도 이런 원칙들을 지킬 수 있습니다. 옛 시스템들을 보면서 왜 그렇게 했는지, 그 안에 반영된 업무 특성이 무엇인지, 잘못된 부분이 무엇인지에 대한 지식을 뽑아내야 하고 그 중에서 필요한 부분은 앞으로 만들 시스템에 적용해야 하고요.

앞으로 만들어 보고 싶은 아키텍처가 있다면.
단기적으로는 금융권의 차세대 시스템 같은 것이 있고 그 다음에는 기회가 된다면 국내에서는 아직까지는 미개척 분야인 공항 관제 시스템 개발에 참여해 보고 싶습니다. 더 크게는 비즈니스나 사회 자체를 시스템으로 보고 그것들을 분석해 보는 일에 관심이 있습니다.

[이해일 소개] 저절로 되는 학문(化學)으로 공부하다가 창조자의 기분을 느끼고 싶어 만드는 학문(工學)을 업으로 삼았다. 세상을 설계하는 아키텍트가 꿈이다.

[지난 인터뷰 보기]