프로덕트

아직 프로덕트가 없습니다.

아티클

전체 보기
김호수

김호수

GitHub는 어떻게 개발 생태계를 디커플링했는가

GitHub는 단순한 코드 저장소가 아니다. 소프트웨어 개발 과정에 깊숙이 통합되어 있던 여러 활동들을 분리해내고, 각 기능을 독립적으로 최적화하며 새로운 협업 구조를 가능하게 만든 플랫폼이다. 이러한 변화는 ‘디커플링(Decoupling)’이라는 전략적 개념으로 설명할 수 있다.

디커플링이란 기존에 하나의 흐름으로 묶여 있던 기능이나 가치 요소를 분리해, 고객이나 사용자에게 더 높은 자유도와 효율을 제공하는 방식이다. 예를 들어, 차량을 소유해야만 이동할 수 있었던 시대에서 우버가 차량 소유와 이동 경험을 분리해낸 것처럼, GitHub는 소프트웨어 개발의 여러 구성 요소를 분해해 누구나 그 일부에 참여할 수 있도록 만들었다.

과거 소프트웨어 개발은 대부분 로컬 환경에서 진행됐다. 코드 작성, 버전 관리, 리뷰, 배포 등이 하나의 팀이나 조직 내부에서 밀접하게 연결된 프로세스였다. 하지만 GitHub는 이러한 흐름을 해체했다. Git이라는 분산 버전 관리 도구를 기반으로 한 이 플랫폼은 버전 관리 기능을 클라우드에서 독립적으로 제공함으로써, 개발자는 자신의 로컬 환경과는 별도로 안정적인 이력 관리와 협업을 할 수 있게 됐다.

협업 구조 역시 크게 달라졌다. 예전에는 동일한 공간에서 함께 일하는 팀이 주요 협업 단위였다면, 이제는 GitHub의 Pull Request 기능을 통해 전 세계 누구나 코드 기여, 리뷰, 토론에 참여할 수 있다. 이는 개발자와 리뷰어의 역할, 그리고 작성과 피드백의 시간적 흐름 자체를 분리해낸 결과다. 덕분에 오픈소스 생태계는 폭발적으로 성장했고, 글로벌 비동기 협업이라는 새로운 문화가 자리를 잡게 되었다.

더 나아가, GitHub는 개발과 운영의 경계도 허물었다. GitHub Actions를 통해 테스트와 배포를 자동화하고, GitHub Pages와 Codespaces는 별도의 인프라 없이 웹사이트 호스팅과 클라우드 개발 환경까지 제공한다. 예전에는 인프라 팀의 지원 없이는 불가능했던 작업들이, 이제는 하나의 플랫폼 내에서 독립적으로 실행 가능해졌다. 이는 인프라 운영과 애플리케이션 개발 사이의 디커플링을 실현한 대표적인 사례다.

최근에는 GitHub Copilot을 통해 사고와 구현의 분리가 본격화되고 있다. 개발자가 단순히 원하는 기능을 설명하면, 실제 코드 작성을 AI가 도와주는 시대가 온 것이다. 이는 프로그래밍이라는 행위에서 ‘코드 작성’이라는 물리적 작업을 제거하고, 창의적 사고나 로직 구성에 집중할 수 있게 해준다. 기술 비전공자도 기본적인 프로덕트를 구현할 수 있는 가능성이 열렸고, 이는 개발의 민주화(democratization)로 이어지고 있다.

이처럼 GitHub는 코드 저장소 이상의 의미를 가진다. 그것은 개발 문화, 협업 방식, 생산 도구, 배포 인프라까지 포함하는 하나의 종합 생태계이며, 기존 개발 프로세스의 통합 구조를 해체해 누구나 접근 가능한 모듈로 재구성한 플랫폼이다. GitHub가 만들어낸 디커플링은 단순한 기능적 혁신이 아니라, 산업 구조를 다시 설계하는 방식이었다.

결국 GitHub는 디커플링 전략을 통해 소프트웨어 개발의 문턱을 낮추고, 새로운 사용자층과 개발 문화를 탄생시켰다. 플랫폼의 힘은 단순한 기능의 집합이 아니라, 각각의 기능을 독립적으로 제공하면서도 유기적으로 연결되게 만드는 데서 나온다. GitHub는 바로 그 정교한 분리와 재결합의 과정을 가장 잘 구현한 사례다.


2
1
김호수

김호수

🧬💊Insilico Medicine: 생성형 AI로 신약 개발 프로세스 전반을 혁신하다

제약산업은 원래 많은 자본과 시간이 투입되지만 효율성이 낮아 아주 어려운 산업이다. 그러나 생성형 AI를 도입함으로써 신약 개발 방식의 패러다임을 완전히 바꿀 수 있었다. Insilico Medicine이 아주 좋은 사례이다.

이 회사를 분석해보았다.

회사 소개: Insilico Medicine은 2014년 Alex Zhavoronkov 박사에 의해 설립된 인공지능 기반의 제약 기술 회사이다. 홍콩과 뉴욕에 본사를 두고 있다.

핵심 기술:

생성형 AI, 강화학습, 트랜스포머 등 머신러닝 기술을 활용해

신약 타겟 발굴 및 신규 분자 구조 생성에 특화된 AI 플랫폼 개발

주요 AI 플랫폼

PandaOmics: 멀티 오믹스 타겟 발굴 및 심층 분석

Chemistry42: ML 기반으로 신약 후보 물질을 설계

inClinico: 임상시험 성공률을 예측하고 설계하는 도구

ChatPandaGPT | PandaOmicsMerck KGaA, Darmstadt, Germany to deploy Insilico Medicine's Chemistry42 AI  platform for generative chemistryinClinico


사업 영역:

암, 섬유증, 면역 질환, 중추신경계 질환, 감염병, 자가면역질환, 노화 관련 질환 등의 치료제 개발 

Insilico의 통합 플랫폼 Pharma.AI:  신약 타겟 발굴부터 분자 설계, 임상 시험 예측까지 신약 개발 전 과정을 지원하는 툴


Pharma.AI 구성요소

PandaOmics: 타겟 발굴 및 멀티오믹스 데이터 분석 엔진으로, 유전자 및 경로를 점수화하고 합성하여 인과관계를 추론. NLP로 타겟과 질병 연관성을 평가  

Chemistry42: 분자 설계를 위한 생성형 AI 화학 모듈로, 생성 및 점수화를 통해 약물 유사 분자 구조를 상상하여 생성

inClinico: 임상 시험 결과 예측 엔진으로, GANs를 활용해 약물 발견 및 평가를 하는 딥러닝 아키텍처. druGAN, ORGAN, RANC, GENTRL 등 다양한 모델 존재

기술 개발 타임라인

-2017년에 최초의 end-to-end AI 기반 약물 발견 파이프라인 제시, druGAN, ORGAN, RNN 아키텍처, ACTN, RANC를 포함한 여러 가지 GAN 모델 구축

-2018년에 GENTRL 구축 후 검증

-2019년에 Pharma.AI 플랫폼의 Biology AI 모듈을 사용하여 IPF(특발성 폐섬유증) 치료


기술 특징

-생성형 적대적 네트워크 + 트랜스포머 모델을 포함한 다양한 종류의 딥러닝 신경망 채택

-타사와 달리 생물학&화학 두 분야 모두에 동일한 딥러닝 적용

-NVIDIA의 BioNeMo를 활용해 생성형 AI로 초기 약물 발견 프로세스 가속화

AI 도입 전후 성과 비교

신약 개발 비용

4억 달러 → 4천만 달러 

=> 기존 방법 대비 90% 감소

개발 기간

6년 → 2.5년 

=> 기존 방법 대비 58% 단축

임상 1상 진입 기간

5년 → 18개월 미만

=> 기존 방법 대비 1/3에 불과한 시간

성과 정리

  • AI 기반으로 발굴한 폐섬유증 치료제 후보 물질이 임상 2상 진입

  • 2023년 기준 누적 4억 달러 이상의 투자 유치


주요 성공 요인

  • PHARMA.AI 플랫폼을 통해 다양한 AI 모델을 통합하여 end-to-end 신약 개발 프로세스 구축, 최신 인공지능 기술 활용

  • NVIDIA와 파트너십 체결 후 GPU의 컴퓨팅 파워를 통해 연산 능력 극대화

  • 주요 제약회사들과 신약 개발 협력

  • 암, 섬유증, 면역 질환 등 다양한 영역을 커버할 뿐 아니라 희귀질환 및 노화 관련 질환에 대한 다양한 질병을 타겟

  • 30개 이상의 AI 설계 약물 파이프라인 보유

AI 기술의 향후 발전 방향과 사회적 변화

희귀질환 및 난치병 치료제 개발 가속화

AI 기술은 시장성이 낮아 연구가 미진했던 희귀질환 분야에서 큰 변화를 가져올 것으로 보인다. 데이터가 부족한 희귀질환에서도 AI 시뮬레이션을 통해 효과적인 치료법을 발견할 수 있기 때문이다. 2030년까지 현재 치료제가 없는 희귀질환의 30% 이상에서 신약 개발이 이루어질 것으로 전망된다고 한다.


의료 불평등 해소와 글로벌 헬스케어 접근성 향상

인실리코를 비롯한 신약개발과 관련된 AI 기술은 의약품 개발 비용을 낮춰 저개발국의 의약품 접근성이 높아질 것으로 보인다. 장기적으로는 의료 서비스의 글로벌 격차가 감소할 것이다.


윤리적, 법적 도전과 규제 환경 변화

동시에 규제와 관련된 논의도 활발한 상황이다. AI가 설계한 약물의 안전성과 효능을 평가하기 위한 새로운 규제 프레임워크가 필요하기 때문이다. FDA와 EMA 등 규제 기관들은 이미 AI 기반 의약품 평가를 위한 가이드라인을 개발 중이며, 2026년까지는 본격적인 규제 체계가 마련될 것으로 보인다. 특히 AI 알고리즘의 투명성과 데이터 편향성 문제를 해결하는 것이 중요하다.

5
1
김호수

김호수

기능 명세서의 중요성

저번 아티클에서 우리팀이 와이어프레임을 만드는 데 어려움을 겪고 있다고 말한 바 있다. 그 원인을 분석해보니, 크게는 'MVP에 대한 잘못된 이해', 작게는 '기능명세서의 누락'으로 좁힐 수 있었다.

  1. MVP에 대한 잘못된 이해

분명 MVP(Minimum Viable Product)에 대해 이해하고 있다고 생각했으나, 실질적으로 우리가 개발하는 과정은 전혀 mvp를 만드는 과정이 아니었다.

우리의 목표는 '공무원 분들이 보셨을 때 wow할 수 있는 product를 만드는 것'이었다. 미팅을 여러 번 잡을 수 없다보니, 첫 미팅에 신뢰를 확보해야겠다는 생각을 했다. 그 전에 공무원 분들과 미팅을 했을 때 반응이 시큰둥하신 분들도 계셨는데, 제대로 된 프로토타입이 없는 상태에서 뵈러 갔기 때문이라는 결론을 내렸었다. 그래서 더더욱 서비스의 퀄리티를 벌써부터 고려하지 않을 수 없었다. 이게 첫 번째로 빠진 함정인 것 같다.

너무 많은 기능을 초반부터 넣으려고 하다보니, (물론 그것도 줄이고 줄인 핵심적인 기능 위주였지만) 머릿속이 복잡해졌고 와이어프레임을 만들 때 수정사항이 계속해서 생겨났다.

이 유명한 사진을 왜 계속 잊게 되는걸까...

image.png

  1. 기능명세서의 누락

우린 맨땅에 헤딩하듯 제대로 된 레퍼런스 조사도 없이 유저플로우+와이어프레임부터 만들기 시작했다. 그러다보니 의견이 발산형으로 계속 나왔고, 수렴되는 데에 시간이 매우 오래 걸렸다. 와이어프레임을 만들다가 누락된 기능이 계속 발견되었다. 이런 문제점에 대해 y-startup week4 세션 때 멘토님께 공유해드렸더니, 기능명세서를 누락한 것에 대해 지적해주셨다. 정말 한 발 앞선 창업가 분들이 핵심적이고 결정적인 부분을 짚어주실 수 있다는 것을 다시금 느낄 수 있었던 부분이었다.

그래서 기능명세서를 만들었다. 보통 notion이나 구글 스프레드 시트를 사용한다고 한다.

image.png

기능명세서에 더해, 요즘 뼈저리게 느끼고 있는 것 중 하나는

내가 겪은 모든 시행착오는 이미 대부분의 사람들이 겪었을 시행착오라는 것이다.

그렇기 때문에 빠르게 lean하게 무언가 시작하고 달성하려면,

과거 사례들을 많이, 다양하게 찾아보는 것이 무조건 선행되어야 한다는 점...

물론 그걸 또 적용하고 실행하는 것은 나의 몫이지만

와이어프레임 만들 때도 레퍼런스 찾아볼 생각은 안하고

제로베이스에서부터 하나하나 만들려고 했는데, 다소 무지하지 않았나 싶다.

여전히 부족하고 더디지만.. 한 주 한 주 더 나아가고 있다고 느낀다.

어서 종강하고 제품 개발과 유저 인터뷰에만 신경쓸 수 있으면 좋겠다.

2
0
김호수

김호수

공공기관 보고서 작성 보조 AI 와이어프레임 만들기 진짜 너무 어렵다 ...

우리 팀의 아이템은 '공공기관 보고서 작성 보조 AI' 이다.

B2G 사업 특성상, 공공기관 상급자 분들께 설득력 있는 MVP를 보여드리는 것이 이번 달의 KPI였다. 이를 위해 우리 팀 셋이 꽁꽁 뭉쳐 여러 방면으로 와이어프레임 구체화에 열을 올렸는데, 단순한 앱이나 플랫폼을 만드는 것이 아니라 웹 기반 워드 프로세서를 만들어야 하다보니 문제점 여러 개에 봉착하게 되었다.

  1. 유저 플로우를 구체화하는 것이 어렵다

    워드나 한컴을 당연히 써봤으니 알테지만, 자유도(?)가 너무 높다. 보고서 결과물을 만들어내는 과정에서 수정이 굉장히 빈번하게 이뤄지는데, 수정 과정까지 반영해 유저플로우를 짜려니까 머리가 터질 것 같았다.

    그렇다고 자잘자잘한 수정 과정을 배제하고 유저 플로우를 짜려니, 너무 단순해져서 와이어프레임을 만들기에 부족한 유저 플로우가 나오게 되었다.

    여러 가지 플로우를 짜봤지만, 다 너무 부족해보였다. 그래도 어찌저찌 결과물이 나왔다. 보고서는 형식이 맞춰져야 하는데, 그 부분을 반영하니까 목차 생성 / 내용 생성 두 측면으로 나뉘게되었다.

    image.png

    여전히 부족하지만.. 점점 고도화를 해야겠다. 여기서 궁금한 것.

    유저 플로우는 어느 정도로 구체적이어야 하는가? 어느 정도 뎁스로 짜야 하는가?

    계속 답을 찾아가야 할 질문이다.

  2. 와이어프레임 어떻게 만들어야 개발과 얼라인이 잘 될까?

    image.png

    image.pngimage.png

    우리팀 디자인 담당이 예쁘게 와이어프레임을 뽑아주셨다. 그러나 내 기획이 너무 부족한 탓에, 아직도 구체화가 필요한데... 솔직히 개발할 때 어떤 요소가 갖춰져야 나중에 불필요한 소통이 덜할지에 대한 고민이 많이 부족한 것 같다. 공부가 더 필요하다.

  3. 개발 현황 공유

    이런 집이 다 무너져가는듯한 ㅠㅠ 상황 속에서도 우리 똑똑한 개발자는 차근차근 개발 환경을 마련해두고 있는데!! 다음과 같은 사항은 얼추 마무리된 상황이다.

    (1) 데이터베이스, 서버, 프론트엔드 연결

    (2) 기본 기능: 로그인: 보안이 중요한만큼 authentication, authorization 신경 쓰는 중. JWT, type validation,CORS 등 implement

    (3) 프론트랑 openAI API 연결 및 prompt engineering 환경 셋업

    2번에 대한 고민 때문에 나도 개발 환경이나 백엔드 전체적인 플로우를 이해해야겠다는 생각이 많이 들었다. 그래야만 실질적인 기획, 효율적인 기획을 할 수 있기 때문이다.

요즘에는.. 더닝크루거 효과의 우매함의 봉우리를 지나 끝도 안 보이는 골짜기로 내려왔다는 생각이 든다.

image.png

그야말로 절망의 계곡이다. 자존감도 많이 떨어지고 내 스스로가 작아지는 느낌을 많이 받는다. 그렇지만 이럴 때일수록 더 열심히 해야겠다는 생각이 든다. 오늘부터 다시 달려봐야겠다! 파이팅!

2
0
김호수

김호수

스타트업 문제 정의의 시작은 '유저 인터뷰'다

얼마 전 EO의 김중철 PO님의 세미나를 듣고 유저 인터뷰의 중요성에 대해서 알게 됐다. 우리 팀이 만들어진지 고작 하루가 지난 시점이었다. 그리고 팀빌딩으로부터 5일이 지난 저번 주 금요일, 첫 유저 인터뷰가 진행됐다. 몰아치듯이 진행되어 셋 다 정신이 없었지만 굉장히 뜻깊은 시간이었다. (나는 벌써 4일째 밤을 새고 있다...)

오늘 쓸 메이커로그에는 그 이야기를 담아볼까 한다.

우선 우리의 아이템은 공문서 보조 작성 AI이다. 수많은 아이템이 있지만 이를 선정하게 된 건, 우리 셋의 공통된 비전은 '실질적으로 사회에 기여하고 싶다' 였기 때문이다. 공무원 분들이 가장 시간을 많이 쏟고 어려움을 겪는 분야인 '공문서'를 좀 더 쉽게 쓰고 퇴고할 수 있게 도와드리는 점이 해당 비전과 일치한다고 느꼈다.

0930-크리에이트-발표_page-0002.jpg

일단 아이템이 정해지고 난 뒤, 이 아이템이 실질적으로 공무원 분들에게 도움이 될지 유저 인터뷰를 진행하기로 했다. 우리가 처음에 생각했던 이 서비스의 핵심 유저는 교육청에 근무하고 계시는 공무원 분들이었다.

0930-크리에이트-발표_page-0003.jpg

마침 팀원 중 실제 친분 있는 공무원 및 교원 분들이 있어 그 분들께 1차적으로 연락을 돌렸다. 이후 친분 있는 공무원 분들까지 총 3분 유저 인터뷰를 진행하게 됐다. 선뜻 인터뷰에 응해주셔서, 정말 감사했다.

질문지도 열심히 작성해서 갔다. 예상 질문, 서비스를 기획 및 개발하며 궁금할 점들을 최대한 자세하게 정리해서 갔다. 우리는 이 질문들에 공무원 분들이 성실히 답변해주시리라 기대하며 인터뷰를 진행했다.

0930-크리에이트-발표_page-0004.jpg

그러나 인터뷰는 예상과 달랐다! 이 지점에서 유저 인터뷰의 중요성을 절실히 깨달았다.

0930-크리에이트-발표_page-0006.jpg

우선 공무원 분들의 AI 활용가능성에 대한 인지도가 매우 낮았다. 그러다보니 도입의 필요성도 딱히 느끼고 계시지 못했다. 그 간극을 메우려다보니 구구절절 설명하는 시간이 매우 길어졌는데, 이 시간이 다소 불필요하게 느껴졌다. 다음 유저 인터뷰부터는 구체적인 프로토타입을 제시해서, 시각적으로 직관적이게 이해할 수 있게끔 도와야겠다는 생각을 했다.

다음으로 우리가 유저 타겟팅 자체에서 오류를 냈다는 것을 깨달았다. 오히려 학교 일선에서는 보고서가 딱히 쓰이지 않았다. 그러다보니 인터뷰 과정 중 보고서 관련 질문을 할 때마다 인터뷰이가 당혹스러워 하는 모습을 발견할 수밖에 없었다. 그 분들은 도무지 AI가 왜 필요한지 모르겠다며 갸우뚱 거리는 모습을 보였다.

마지막으로 인터뷰이 성향마다 인터뷰지 형식을 다르게 가져가야겠다는 생각을 했다. 우리가 세 분밖에 진행하지 않았음에도, 성향에 따라 인터뷰 양상이 확연하게 달랐다. 물꼬를 조금만 터줘도 본인의 커리어 여정을 비롯해 보고서 작성 프로세스를 상세하게 구술해주시는 분이 있는 반면, 아무리 구체적으로 꼬리 질문을 해도 질문에 걸맞는 답을 명쾌하게 하지 않는 분이 계셨다. 각 유형에 따른 유연한 대처가 필요하다고 느끼는 지점이었다.

0930-크리에이트-발표_page-0005.jpg

그렇다고 유저 인터뷰를 통해 우리 아이템이 별로 매력적이지 않다고 확인사살당한 것만은 아니었다. 오히려 그 분들의 구체적인 커리어 여정과 공무원 사회 자체에 대한 인사이트를 통해 여러가지 BM을 발견했다. 유저 인터뷰를 통해 찾아낸 아이템은 우리가 처음에 생각해낸 AI서비스보다 훨씬 매력적이고, 직관적이고, 타겟팅이 명확했다. 이번주는 이 아이템을 좀 더 구체화하고 기획 및 개발 계획을 세우는 데 집중할 예정이다.

앞으로도 유저 인터뷰를 지속적으로 하며 '장기간 꾸준히 지속적으로 고객을 만나는', EO 김중철 PO님이 말씀하셨던 D유형을 지향해야겠다.

비로소 이제 몸으로, 피부로 알겠다.

스타트업 문제 정의의 시작은, '유저 인터뷰'다.

3
0

포스트

전체 보기
김호수

김호수

"논술 첨삭 AI" VS "공문서 작성 보조 AI" 아이디어 평가

1. 창업자-시장 적합성이 있는가? (아이디어 실행에 적합한 팀인가)

논술 알바 3년차, 타겟 고객층으로 삼은 학원/선생님들과 네트워크 존재, 피드백 가능

공공기관 1년 6개월 간 공익 복무하며 공무원들이 어떤 부분에서 어려움 겪는지 알게 됨, 공무원들과 네트워크 존재, 피드백.홍보.정보제공 가능

2. 얼마나 절실한 문제인가? (사람들이 별로 신경쓰지 않는 문제는 아닌지? 대안이 없을 때 가장 좋은 문제이다)

솔직히 아주 절실한 문제는 아니다. 편리성을 제고한다는 개념에 불과. 이미 사람 채용만으로 충분히 시장이 돌아가고 있기 때문.

1. 공무원들은 보고서 작성에 시간 소모 큼. (연간 분원장님 90건, 일부 행정담당자 300건 작성) 2. 보고서가 상급자 또는 타 기관이랑 소통하는 매체라 보고서의 퀄리티도 중요하게 여김

1
0