소고기를 위한 ‘도메인 드리븐’ 실현, 조환 설로인 개발리더

[코딩을 넘어 비즈니스로] #1. 소고기 시장을 코드에 담다, 조환 설로인 개발 리드

코드는 현실 세계를 반영해야 합니다. 비즈니스의 요구 사항과 사람은 컴퓨터의 작동 방식대로 움직이지 않습니다. 현실 세계는 컴퓨터의 작동 방식과는 무관하게 바뀌는 공간이죠. 우리 프로그래머가 현실의 문제를 외면한다면 컴퓨터는 사람의 사고와 행동을 제대로 반영하지 못할 것이고, 고객은 떠나갈 것입니다. 고객이 떠난 자리에는 프로그래머가 설 자리도 없습니다.

그래서 비즈니스를 코드로 구현하기 위해 분투하고 있는 다양한 프로그래머의 고민, 문제 해결, 성장 이야기를 들어보고자 합니다. 앞으로 인터뷰나 에세이 등 다양한 형식을 통해 코딩과 비즈니스의 관계를 톺아보려 합니다. 시리즈 첫 번째로, 소고기 시장을 코드에 담고 있는 조환 설로인 개발 리드를 만나 인터뷰했습니다. 새로운 도메인에서 문제를 풀어가는 프로그래머들, 성장하고 싶으나 무엇을 더 잘해야 할지 고민이었던 프로그래머들, 비즈니스를 진지하게 고민하는 프로그래머들에게 도움이 되길 바랍니다.

소고기 시장을 코드에 담다 - 조환 설로인 개발 리드

시리즈의 첫 번째 인터뷰 대상으로 조환 설로인 개발 리드를 꼽은 이유는 두 가지였습니다. 첫 번째 이유는 기술 교류와 연관한 한 사건에서 비롯합니다. 테스트 코드 정비에 대해 기술 교류를 하려고, 그가 쓰는 방법을 우리 회사 개발자들에게 공유해달라고 요청한 일이 있었습니다. 팀원들과 한글 문장으로 테스트 코드를 작성하는 문화를 소개했는데, 그의 개발에 대한 관점이 제가 좋아하는 책 <도메인 드리븐 디자인Domain Driven Design>을 처음 읽었을 때는 짜릿함을 닮아 있었습니다. 직업인으로서 프로그래머는 기술을 연마해야 하지만, 어디까지나 사회적 가치를 생산해야 하고, 그 과정에서 여러 사람과 인간적으로 함께 일해야 한다는 제 믿음에 굉장히 부합하는 개발 리드라고 생각했습니다. 이것이 그를 인터뷰 대상으로 결정한 첫 번째 이유입니다.

두 번째는 CTO 직무에 대한 그의 철학 때문입니다. 예전에 그와 식사 중에 “40대 중반에 30~50명 규모의 조직에서 CTO를 맡고 싶다”는 개인적 목표를 들은 일이 있었죠. 굉장히 구체적인 점이 인상적이었습니다. 동시에 지금도 충분히 역량이 된다고 생각했기에 ‘왜 지금이 아니냐’고 물었더니, 그는 ‘CTO의 일은 경영이기 때문에 경험과 연륜이 필요하다’며 인문학적 접근을 바탕으로 뚜렷한 자기 생각을 표했습니다. 코딩과 비즈니스의 관계, 즉 코딩을 현실 세계에 구현하는 과정에서는 리더의 자리에 있든 아니든 함께 일하는 사람들의 의견을 조율하고 설득하는 것이 필연적인 일입니다. 그래서 리더십에 대한 생각 또한 중요한 인사이트가 되리라고 생각했습니다.

코딩은 어떻게 고기 장사에 도움을 주는가?

조환식 ‘Domain Driven’ 실현을 어떻게 제3자에게도 보여줄 수 있을지 고민하다가, 소고기 부위명을 코드에서 한글로 작성한 이야기부터 시작하기로 했습니다. 그리고 개발자만을 위한 이야기가 되지 않도록 하기 위해 비개발자 출신인 요즘IT 리더 노희선님이 동석하여 함께 소통하는 방식을 취했습니다.

안영회(이하 안): 지난번에 코드에 소고기 부위명을 한글로 쓴다고 말씀해주신 것이 인상 깊었어요. 코드를 그렇게 작성하게 된 배경을 들려주세요. 그 이야기라면 지금 맡고 계신 비즈니스를 이해하는 데도 도움이 될 것 같습니다.

 

조환(이하 조): 저희 팀은 한우 부위명을 한글로 쓰고 있어요. 살치살, 홍두깨살, 같은 단어가 코드에 들어있죠. 이 부위를 정확히 지칭하는 영어 단어가 없어요. 영어의 ‘로인(loin)’은 거의 목 뒤부터 허벅지 위까지 해당하는, 소의 뒷부분 전체라고 할 수 있어요. 그런데 한국은 그 로인 부위만 목심, 등심, 채끝, 우둔 등 네 개 부위로 나뉘죠. 이걸 직역하면 사실 법적인 문제가 발생할 수 있어요. 국내 식품위생법상 정확한 부위 명칭에 따른 제품을 유통, 판매해야 하죠. 다른 걸 주면 사기예요(웃음). 또 저희는 국내 유통을 할 거니 국내 도메인에 맞출 필요도 있었고요. 코드를 짤 때도 일단 이걸 명확히 구분해야 한다는 문제가 있었어요.

 

안: 코드에 한국어를 쓰는 것을 기능적인 문제 때문에 선택하지 않기도 하지만, 정서적으로 꺼리는 분위기도 좀 있었던 것 같아요. 하지만 조환 님의 케이스는 이 선택이 정말 적절한 것 같아요. 우리 시장에서는 홍두깨살을 홍두깨살이라고 하는 게 가장 명확하니까요.

 

조: 저는 제 일을 ‘고기 장사’라고 해요. 고기 장사에서 가장 중요한 일은 잘 파는 것, 팔아서 이윤을 남기는 것이죠. 제가 하는 모든 선택이 판매를 잘하고 이윤을 극대화하는 것을 뒷받침해야 해요. 그런데 이렇게 한글로 코드명을 짓는 것과 같은 요소는 제가 해결해야 할 문제가 100이라면 0.1 정도에 불과한 문제였습니다. 그래서 팀에서도 더 길게 고민하지 말자고 했죠. 우리가 길게 고민해야 하는 것은 우리가 다루는 상품을 제대로 이해하는 것이었습니다.

 

안: 그렇겠네요.

조: 이 회사 오기 전에는 소고기는 그냥 다 소고기인 줄 알았지, 와서 보니 한우 부위가 10개 있고, 소분할하면 39개까지도 나오더군요. 부위가 매년 조금씩 줄거나 늘기도 하고요. 지방마다 부르는 명칭이 다르기도 하죠. 여기에는 자연어가 통일되지 않는다는 이슈도 있지만, 이런 구조를 코드로 구현하는 데도 이슈가 있었어요.

 

개발자들은 이게 대분할, 소분할로 이뤄지니까 트리 구조로 표현하면 되겠다고 생각하기 쉬워요. 내가 등심을 골랐는데, 등심이 없으면 연관된 안심을 보여준다든지, 홍두깨살이 없으면 ‘우둔’에서 다른 걸 보여준다든지, 이런 걸 구현하려면 트리를 만들어야 하잖아요. 그런데 이걸 단순히 트리 구조로 표현하면 순환참조가 생기고, 그 참조를 계속 따라가게 하면 안 되는 거죠. 나는 육회 거리를 찾았는데 뜬금없이 찌개 거리를 추천해준다거나 하는 일이 생기면 소비자가 만족할 수가 없는 거예요. 이런 문제를 푸는 데 더 집중을 해야 한다고 생각했어요.

 

안: 중요한 말씀 같아요. 잘 팔기 위해서 에너지를 어디에 쓸지 판단할 때 내가 파는 상품과 소비자의 입장에 집중해야 한다는 거죠. IT가 어떻게 육가공에 어떤 도움을 주는지 궁금했거든요. 지금 말씀해주신 것에 실마리가 있는 것 같아요.

‘도메인 드리븐 디자인’은 소프트웨어 개발 및 디자인 방식 중 하나입니다. 소프트웨어나 애플리케이션을 개발하기 전에, 개발하고자 하는 결과물이 속한 도메인을 완전히 이해하고 분석하기를 강조하는 방법론이죠. 앞서 언급한 도메인 드리븐 디자인이라는 책에서 그와 같은 내용을 소개하고 있습니다. ‘도메인 드리븐 디자인’의 특징 중 하나는, 도메인을 잘 이해하기 위해 해당 도메인의 전문 지식을 보유한 사람과 긴밀하게 협력해 해당 도메인의 사용자와 비즈니스 프로세스, 핵심 요소의 이해를 높이는 것입니다.

조환 식 도메인 드리븐은 조 리더가 자신의 일을 ‘고기 장사’로 정의하고, 그에 따라 업무의 중요도와 코드 구현 방향을 결정해낸 것에서 잘 드러납니다. 고기 시장이라는 도메인을 명확히 이해하고, 그 이해가 그의 개발 방향에 관한 의사 결정에 맥락적으로 녹아 있는 것이죠. 이렇듯 코딩과 비즈니스는 유리된 것이 아닙니다. 고기 시장에서 코딩을 하려면 고기 시장을 이해해야 하고, 그게 우리가 구현하려는 시스템과 어떻게 연관되는지 볼 수 있어야 하죠. 어쩌면 당연한 일이지만, 쉽지는 않다는 것을 알기에 인상적이었습니다.

코딩이 사업의 부가가치 창출에 기여할 수 있는가?

필자는 지난 10여 년간 소위 말하는 디지털 전환 사업에 직간접적으로 참여한 바 있습니다. 디지털 전환이 필요한 기업들을 전통 기업이라고 부른다면, 이 전통 기업들은 대체로 IT를 ‘비용’의 관점에서 바라 봅니다. 비즈니스 기능은 별도로 정의하고 IT가 이를 자동화하거나 효율화한다고 봅니다. 하지만 스마트폰이 우리 생활에 깊이 침투하고 디지털 접점이 생기면서 비즈니스 기능을 수행하는 앱이 늘어나는 장면들을 목도하고 있는 것이 현실입니다. 그런 점에서 IT를 ‘비용’이나 ‘효율’ 관점이 아니라 직접 비즈니스에 기여하는 방향으로 사고하는 일은 중요하다고 생각합니다. 조환님에게서도 이와 관련된 인사이트를 얻고자 질문을 이어갔습니다.

안: 설로인에 도매사업부를 맡는 것으로 합류하셨죠. 앞선 이야기는 소매 관련된 내용인데, 도매 관점에서는, 앞서 말씀하신 표현에 따르자면 ‘잘 파는 데’ 무슨 기여를 하는 건가요?

 

조: 저희 회사가 2018년에 회사를 설립하고, 2022년까지 소매만 했습니다. 도매를 올해 처음 하는 거예요. 소고기가 등심, 안심, 채끝 세 가지로만 이루어져 있다면 고민을 안 할 텐데, 그건 아주 일부분일 뿐이에요. 나머지 부위가 훨씬 많아요.

 

안: 나머지 부위는 저부가가치 부위인 건가요?

 

조: 그렇죠. 그걸 버릴 수는 없잖아요. 사는 사람이야 소의 모든 부위가 필요하지 않지만 파는 사람은 나머지 부위는 처치 곤란이잖아요. 게다가 이 소고기 유통 시장 경쟁이 장난 아니라서, 인기 부위(안심, 등심, 채끝)를 매입하는 가격은 계속 올라요. 그런데 소매 가격을 올릴 수는 없죠. 요즘에는 경기도 안 좋고 사람들이 가격에도 민감하니까 더 그렇고요. 더군다나 심지어 산지 송아지 값은 떨어졌는데 일부 부위 가격은 계속 올라가는 것에도 판매자들은 민감해요. 상황이 이렇다 보니 소의 모든 부위를 활용할 수 있는 상품을 개발하는 것에 관심을 두기 시작했어요. 

소매와 도매는 구입을 결정하는 기준이 달라요. 소매는 품질이나 브랜드 신뢰 측면이 강하지만, 도매는 접근성과 가격이 훨씬 중요해요. 저희가 이 두 가지 접근을 다 할 수 있을 것 같았어요. 특히 저부가가치 부위를 싸게 팔고, 거기서는 이윤을 남기지 않지만, 고부가가치 부위에서 남은 이윤으로 상쇄할 수 있다고 봤어요. 이런 판매 전략을 구사하려고 하죠.

 

안: 매력적이긴 한데 개발자가 사장님에게 제안하기에는 굉장히 대담한 제안인 것 같아요. 직접 제안하신 건가요?

 

조: 아니요. 저는 이 그림이 마련된 상황에서 합류했고 이걸 실제로 실현할 사람들을 모은 거죠. 판매 전략을 다양하게 구사하려고요. 실제로 도매 시장은 복잡하다는 말들이 많아요. 소 부위가 수십 개가 넘고, 잘랐을 경우 갈비 한 짝 가격이 다 똑같은 게 아니거든요. 부위, 자르는 방법, 날짜 등에 따라서 가격이 매일 변해요.

 

정육점 사장님들은 이 가격에 관해 경험적으로 알고 판단하시는 거예요. 지금 이걸 이 가격에 팔아도 될까 하는 것을요. 어떤 분은 한 번에 5마리 가격을 머릿속에서 계산기 두드려보시더라고요. 저희 목표는 한 달에 소 400~500마리 이상을 판매하는 건데, 단순히 계산하면 사람 100명이 가격을 판단하고 판매 결정을 해야 하는 거잖아요. 현장에서 이걸 이 가격에 팔아도 되는지 즉답이 나오기 어려운 구조예요. ‘시가’니까 이런 일이 생길 수밖에 없어요.

 

안: 저의 질문은 도매에서 고기 잘 파는 데 IT가 무엇을 해줄 수 있냐는 거였는데, 듣다 보니 도매라기보다는 도소매를 병행할 때 이 가격 문제를 합리적으로 해결하는 데 IT가 보조 수단을 마련해줘야 한다는 것 같네요. 시가를 실시간으로 판단하는 사람들이 ‘지금 내가 추정하기에는 이 정도면 괜찮은 것 같아’라고 판단할 수 있는 근거를 줘야 되는 거죠?

 

조: 맞습니다. 그래서 현재 가격 템플릿이란 걸 만들고 있어요. 실시간으로 영업사원에게 적정 가격을 통지해줄 수 있는 시스템이에요. 가격 정보를 최대한 수집해서 분석하는 거죠.

정리하자면, 소매와 도매의 타깃이 다르고, 소매와 도매의 고객의 니즈가 다르기 때문에 발생하는 시장의 구조적 문제를 해결함으로써 부가가치를 창출한다는 이야기입니다. 소매 고객은 특정 부위만 원하는데, 도매 고객은 모든 부위를 잘 팔고 싶어 한다는 시장의 간극이 있고, 그에 따라 도매에서는 가격이 ‘시가’ 형태로 조성돼 시장 참여자들의 직관에 의해 결정되고 있었습니다. 이를 ‘가격 템플릿’이라는 수단을 개발함으로써 시장의 문제를 일부 해결하겠다는 생각입니다.

개발자가 제안한 내용은 아니지만, 시장의 문제를 정확히 이해함으로써 그것을 코딩에 반영하고, 컴퓨터의 힘을 빌려 더 많은 현장 관계자와 소비자에게 혜택이 돌아가도록 시장을 재편하는 것입니다. 이는 코딩이 사업의 부가가치 창출에 어떻게 기여할 수 있는지에 대한 하나의 사례가 됩니다. 더 많은 이들에게 혜택을 준다는 비전은 꽤나 의미 있는 일입니다.

개발 조직을 키우며 리더로 성장하기

화제를 돌려서, 조 리드를 인터뷰하고 싶었던 두 번째 이유였던, ‘개인적인 목표’에 대해서도 질문했습니다. 그런데 대화는 자연스럽게 그가 ‘조직에서 개발팀을 어떻게 안착시키는가’로 흘러갔습니다. 그가 현재 직무에 굉장히 몰입해 있다는 것을 짐작할 수 있었습니다. 그리고 그 과정에서 그가 좋은 리더로 성장하고 있다고 느꼈습니다.

리더십에 대한 철학적 관점을 나름대로 갖고 있었고, 리더로서의 언어와 영향력에도 굉장히 관심이 많았는데요. 그의 이 말이 그런 그의 노력을 대표하는 것 같았습니다.

“소프트웨어 엔지니어들은 아키텍처니 리팩터링이니 이런 이야기를 좋아하는데, 돈줄을 쥐고 있는 사람들은 그런 것에 별로 관심이 없는 사람들이어서, 내가 살아남으려면 그들이 이해하는 화법을 익혀야 되겠다고 생각했어요.”

코딩이 비즈니스에 기여할 수 있으려면, 또 개발자가 코딩만이 아닌 비즈니스적 관점을 가지려면 함께 일하는 사람을 설득하고 영향력을 미치는 방법을 고민해야 한다고 생각합니다. 조환 님의 관점이 이런 고민을 하는 분들께도 도움이 되리라고 생각했습니다.

안: 이제 화제를 좀 바꿔볼게요. 예전에 사석에서 “40대 중반에 30~50명 규모의 조직에서 CTO를 맡고 싶다”는 말씀을 하셨던 게 인상 깊었어요. 그때는 그 이유를 충분히 여쭙지 못했는데, 왜 이런 목표를 갖게 되셨는지 궁금해요.

 

조: 젊은 시절에는 CTO가 그저 멋있어서 해보고 싶다는 생각을 했었는데요, 이제 그건 정말 아닌 것 같아요.(웃음) 경력이 쌓이면서 CTO가 도대체 뭐 하는 사람인지를 곰곰이 생각해봤어요. 그랬더니 결국 ‘경영’이더군요. 냉정하게 말하자면, 코딩을 잘하는 사람, 뛰어난 프로그래머가 아니라 소프트웨어 관련 능력이 밝은 경영자라고 결론 내렸어요. NASA 국장도 문과 출신이 꽤 많아요. 정치적으로 관리해야 할 일이 많아서 그렇다고 하더군요. 그러니까 그 자리는 과학자들도 인솔을 잘 하면서도 정치적으로 영향력을 행사할 수도 있어야 하는 거죠. 그 사람이 물리학을 가장 잘 아는 건 아닌 거예요. 제가 생각하는 CTO도 그런 거였어요.

 

안: 조환 님은 전공이 뭔가요?

 

조: 전자과입니다.

 

안: 문과 출신 같은 CTO가 되겠다는 뉘앙스가 있으신 것 같아요.

 

조: 경영은 결국 사람 경영과 돈 경영 모두를 하는 일이기 때문이에요. 전자과 출신인 것만 생각하면 돈 경영만 하는 게 쉽죠. 그런데 돈만 관리하는 건 경영이 아니에요.

 

제가 요즘 트로피코라는 도시 경영 시뮬레이션 게임을 즐겨 하는데요, 도시를 경영한다는 컨셉이다 보니 도시에 사는 사람들이 폭동도 일으키고 전쟁도 나고 그래요. 그런데 게임에서는 제가 운영하는 정부에 대해 쿠데타를 일으킨 세력을 정신병원에 감금할 수도 있고 나한테 불만 있는 사람을 매수하거나 어용 방송국을 세울 수도 있어요. 하지만 현실에서는 이런 게 전혀 불가능하죠. 사람 경영이 빠지면 경영이 아닌 거예요.

그럼 돈 경영과 사람 경영 둘 중 무엇을 더 중요시하면 될지 생각해보면, 결국 사람을 써야 돈이 있더라고요. 그러니까 결과적으로는 경영이란 사람 경영인 거죠. 사람 경영을 하려면 말도 잘해야 하고, 내가 전달하고자 하는 바를 명확하게 ‘찰떡처럼’ 얘기해서 사람들이 알아들을 수 있게 해야 하죠. 또 정치가 필요한 거예요. 저는 서로의 패를 까면서 서로가 동의하는 결과가 나올 때까지 토론을 반복하는 것을 정치라고 생각해요. CTO에게 필요한 게 이런 능력인 것 같아서 소규모로 시작해보고 싶었습니다.

 

안: CTO라는 직책에 관해 조환 님의 가치관이나 철학적 관점에 관해서는 이해했습니다. 그렇다면 ‘CTO라면 이런 일은 챙겨야 한다’라는 기준은 혹시 갖고 계시나요?

 

조: ROI를 무조건 높게 나오도록 유지해야 한다는 것입니다.

 

안: 개발 결과를 중시해야 한다는 말씀하시는 걸까요?

 

조: 아직 여기에 대해 구체적인 답을 내리지는 않았어요. 현재까지는 그냥 결국 돈을 벌어오는 거라고 생각해요. IT가 고기 파는 데 기여해야 하는 거죠. 그런데 매출만을 기준으로 ROI를 생각하면 안 돼요. 그렇게 하면 특히 R&D 조직은 가장 손해를 볼 수밖에 없는 구조잖아요. 여기서 R&D 조직이 매출에 어떻게 기여했는지를 도출해내는 게 정치의 영역이라고 생각해요. 이런 건 사실 수치화가 어렵죠.

 

안: 개발자 개인이 정치를 할 수는 없으니, CTO가 정치를 해줘야 하고, 그래야 R&D 조직도 살아남는다는 말씀이네요.

 

조: 네 맞습니다. 장부만 보면 R&D조직은 전부 돈을 쓰는 조직이에요. 그런데 저는 개발 조직이 기본적으로 다 R&D 조직이라고 생각해요. 예를 들어 사이트가 안정화됐다고 이제 그 사이트를 구축해온 이들을 자른다는 말이 회사에서 나온다면 어떨까요. 코드는 시간이 지나면 썩어요. 그런데 당장 비용을 아끼겠다고 사람들을 내보내면, 소프트웨어 유지 보수가 제대로 안 되고 썩어 버리는 거죠. 평소에 집을 계속 유지, 보수를 해주면 관리 비용이 적게 드는데, 수 십 년 방치해놓은 집을 고친다고 생각하면, 새로 짓는 게 낫다는 생각이 저절로 들 겁니다.

 

안: ROI로 평가할 수 없는 다른 태스크도 있다고 보시나요?

 

조: 저는 냉정하게 말하자면, 궁극적으로는 모든 게 다 ROI를 위한 행동이라고 봅니다. 제가 처음에 설로인 도매사업부를 맡게 됐을 때, 팀에 저 혼자밖에 없었어요. 그래서 채용부터 해야 했는데, 인재를 뽑는 게 쉽지 않았어요. 저는 탑티어 개발자를 모시고 싶은데, 몇 십억 버는 작은 기업에는 안 오실 거고, 지원하신 분들 중에는 일하신 기간은 긴데 실제 하신 일은 기간에 맞지 않는 분들도 많았어요. 초반에 2주 정도 경력직을 뽑으려 했으나 잘 안돼서, 주니어를 뽑아서 교육해야겠다 생각했죠. 국비지원 교육생들 중 5명을 뽑아서 가르치면서 일했어요. 이런 것도 ROI 측면에서 전략적 판단일 수 있다고 봐요.

안: 앞서 CTO가 정치를 해줘야 하고, 그래야 R&D 조직이 살아남는다고 말씀하신 것과 관련해서는 구체적으로 어떤 일을 하고 계시나요?

 

조: 임금 상승률을 조직에 역으로 어필하는 거죠. 직원 한 명이, 일 한 지 8개월 만에 다른 회사에 합격을 했다고 상담을 왔더라고요. 일단 연봉이 조금 오르는 것도 중요하지만, 돈만 보고 움직이기보다는 그 팀에서 무슨 일을 할 수 있을지 충분히 그림이 그려지는 곳을 가라, 지금과 비슷한 일을 한다면 제가 어지간한 사람보다 더 잘 알려줄 수 있다고 말했어요. 그러면서 회사에서 다시 역오퍼를 하면서 같이 채용한 주니어들 임금을 모두 올렸죠. 이것도 정치의 영역에서 논리를 세워서 ROI로 어필할 수 있었어요. 이만큼의 퍼포먼스를 낸 사람들이 지금보다 적은 연봉으로 이 결과를 낸 거라면, 비용을 절감한 거라는 논리였죠. 이게 늘 먹힌다고 보지는 않아요. 제가 운이 좋았죠. 하지만 하다 보면 이런 포인트를 계속 발견할 수 있지 않을까 합니다.

마치며

이번 인터뷰를 통해 현실의 문제, 비즈니스 문제를 풀어가는 개발 리드로서의 조환님의 면모를 더 잘 이해할 수 있었습니다. 앞서도 썼지만, 저는 오랫동안 직업인으로서 프로그래머는 기술을 연마해야 하지만 그걸 통해 사회적 가치를 생산해야 하고, 그 과정에서 함께 일하는 이들과 인간적인 협력을 해나가야 한다고 생각해왔습니다. 그래서 프로그래머가 현실 세계, 즉 내가 종사하는 도메인에 깊은 관심을 갖고 그걸 구현해나가야 한다고 생각합니다. 그 과정에서 조직에 대한 영향력을 바람직하게 구축하는 것도 중요하다고 생각합니다.

조환 님도 소고기 시장이라는 도메인을 알지 못한 채로 시작했습니다. 하지만 시장에 대한 깊은 이해와 자신만의 관점을 바탕으로 코드부터 전략, 조직 운영까지 구축해나가고 있었습니다. 인터뷰를 하고 다시 글로 정리하면서 저에게도 많은 배움이 되었지만, 무엇보다 새로운 도메인에서 개발을 시작하게 된 프로그래머와 리더들에게 좋은 레퍼런스가 되길 바랍니다.

요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.