| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | |||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 |
| 12 | 13 | 14 | 15 | 16 | 17 | 18 |
| 19 | 20 | 21 | 22 | 23 | 24 | 25 |
| 26 | 27 | 28 | 29 | 30 |
- 구조 패턴
- ssh
- AWS 비용 절감
- amazon ecs
- study
- 생성 패턴
- 경로 계획 알고리즘
- Playwright
- Go-lang
- 커머스
- 회고
- MAPF
- 논문 정리
- 신혼 여행
- AWS
- 디자인 패턴
- docker
- 티스토리챌린지
- 실용주의 프로그래머
- 청첩장 모임
- Rust
- DevOps
- PostgreSQL
- 14일 공부
- github
- 지표
- Til
- 오블완
- terraform
- leetcode
- Today
- Total
밤 늦게까지 여는 카페
어떻게 하면 실험을 "잘" 할 수 있을까요? feat. 스타트업 본문
안녕하세요. 어느덧 2023년도 끝을 향해 가고 있는데 안녕하신지요?
저는 팀원분들과 2023년 로드맵을 그리며 으쌰으쌰 했던 것이 엊그제 같은데 벌써 회고를 준비하고 있네요 ㅜ
회고를 준비하면서 올 한 해를 되돌아보니 "실험"이라는 키워드가 눈에 띄더라고요.
길지도 구성 실험, MAPF 알고리즘 실험, 시뮬레이션 실험 등 부서 대내외적으로
새로운 실험이 필요하거나 실험 결과가 필요한 적이 많았습니다.
이러다 보니 어떻게 하면 실험을 "잘"할 수 있을지 고민을 많이 했었는데요.
오늘은 실험을 "잘"하는 방법에 대해서 얘기하면서 저에게 도움이 되었던 글들도 공유드리려고 합니다.
조금이라도 도움이 되었으면 좋겠네요! ㅎㅎ
TL-DR)
- 숫자로 표현할 수 있는 지표를 사용하여 가설을 수립하자.
- 실험 결과에 영향을 줄 수 있는 요소들은 꼭! 꼭! 기록하자.
- 주어진 것에서 최대한 많은 힌트를 찾아내자.
1. 나쁜 실험
실험을 "잘"하는 방법을 알아보기 전에 실험을 "못" 했을 때 발생하는 문제들을 제 경험에서 찾아보도록 하겠습니다.
저는 다음과 같은 상황에서 실험을 진행해야 했습니다.
- 기존 솔루션의 스펙을 알아내야 할 때
- 기존 솔루션의 부족한 점을 개선하기 위해 새로운 솔루션을 도입해야 할 때
- 신규 기능을 개발하기 위해 새로운 알고리즘을 도입해야 할 때
실험을 통해서 원하는 결과를 얻고, 다음 작업으로 부드럽게 이어질 때도 많았지만
1) 결과로부터 확신을 얻기에는 뭔가 하나씩 부족해서 실험을 반복한 적도 있었습니다.
2) 발생한 문제에 대해서 이미 실험을 진행한 적이 있지만 재현되지 않는 결과 때문에 처음부터 다시 실험을 진행한 적도 있습니다.
3) 정확한 실험 결과를 얻었다고 생각했지만 자꾸 변인 통제에 실패하여 실험을 반복한 적도 있었습니다.
어떻게 하면 이 문제들을 줄일 수 있을까요? 이런 저런 고민과 다른 글들을 참고하면서 생각한 것은 다음과 같습니다.
2. 좋은 실험
실험을 "잘" 하기 위해서는 실험이 무엇인지부터 이해해야 합니다.
실험이란 가설을 증명하기 위한 일련의 과정입니다. 따라서 좋은 실험이란 증명 가능한 구체적인 가설과, 재현 가능한 과정으로 서술되어야 합니다.
이제 위에서 언급했던 문제들을 다시 살펴볼까요?
2.1. 구체적인 가설
1번 문제를 조금 더 풀어보면 다음과 같습니다.
1) 결과로부터 확신을 얻기에는 뭔가 하나씩 부족해서 실험을 반복한 적도 있었습니다.
=> 가설이 충분히 구체적이지 않았기에 실험 결과를 해석할 때 모호한 부분이 생깁니다.
=> 모호한 부분을 해소하기 위해서 실험을 더 진행합니다.
=> 반복
어떻게 하면 가설을 구체적으로 만들어서 이 문제를 해소할 수 있을까요?
물론 다양한 방법이 있겠지만 제가 추천드리는 방법은 숫자로 표현할 수 있는 지표를 이용하는 것입니다.
예시를 들어보겠습니다!
1. 가설 수립)
어느 날 Weighted A*(WA*) 알고리즘을 공부한 저는 Dijkstra 알고리즘보다 훨씬 좋다고 판단하여
"WA* 알고리즘이 Dijkstra 알고리즘보다 더 좋다."라는 가설을 세웠습니다.
2. 실험)
이를 검증하기 위해 임의의 실험 환경을 구성하고 두 알고리즘의 결과를 비교했습니다.
3. 실험 결과 검토)
아마 열에 아홉은 실험 결과를 검토하면서 가설을 교정하거나 실험을 교정하게 될 것입니다.
왜나하면 가설 "WA* 알고리즘이 Dijkstra 알고리즘보다 더 좋다."에서 "더 좋다"가 명확하지 않기 때문입니다!
실행 시간, 계획된 경로의 최적성과 같이 숫자로 표현할 수 있는 지표로 가설이 수립되어야 검증하기 쉽습니다.
- 물론 지표로 표현하면서 증명하고 싶었던 내용이 곡해될 수도 있으니 지표를 잘 만들어야겠죠 ㅎㅎ...
그리고 실험 환경과 실험 과정도 의미 있는 실험 결과를 얻기에는 부적합했을 가능성이 높습니다.
무엇을 검증하기 위한 실험인지 명확하지 않았기 때문에 실험 환경도 임의로만 구성했습니다.
그러면 실행 속도라는 지표를 이용해서 가설과 실험 환경을 수정해 보면 다음과 같습니다.
- 가설: WA* 알고리즘이 Dijkstra 알고리즘보다 실행 속도가 더 빠르다.
- 실험 환경: 다음과 같이 구성합니다.
- 문제 도메인에서 찾을 수 있는 일반적인 환경(다른 논문들의 실험 환경을 참고할 수 있음)
- WA*가 A*보다 실행 속도가 빠른 환경
- WA*가 A*보다 실행 속도가 더 느린 환경
위와 같이 실험을 세팅하면 WA*를 우리의 문제 도메인에 적용했을 때 실제로 A*보다 실행 속도가 빠른지 검증할 수 있으며
어떤 환경에서 WA*의 성능이 부족한지도 알 수 있어서 장단점을 분석할 수 있게 됩니다.
2.2. 부정확한 기록
2번 문제는 사실 실험 환경 혹은 실험 과정을 구체적으로 기록하는 것의 중요성을 몰랐기 때문에 발생했다고 생각합니다.
실험을 진행하면서 결과에 영향을 줄 수 있는 작은 발견들을 사소하다고 치부하여 기록하지 않을 수 있습니다.
하지만 이는 해당 실험과 파생 실험들의 신뢰까지 잃게 만드는, 아주 큰 비용을 지불하게 만드는 실수입니다.
실험 결과에 영향을 줄 수 있는 요소라면 되도록 빼놓지 않고 기록해야 합니다!
2.3. 변인 통제의 어려움
사실 3번은 해결하기 어려운 문제라고 생각합니다. 특히나 스타트업처럼 리소스를 많이 투자하기 어려운 환경이라면요.
실험에 있어서 변인 통제는 정말 중요하지만 통제하기 어려운 경우가 많습니다.
물류센터에 로봇을 도입할 때 작업자 수 대비 적절한 로봇 수를 찾아야 하는 상황을 예시로 들어보겠습니다.
하지만 자체적으로 물류센터를 가지고 있지 않은 스타트업이 실험을 여러 번 진행할 수 있을까요? ㅜㅠ
한번 진행된 실험에서 최대한 많은 뽕(?)을 뽑아야 합니다!
이럴 때는 형식에 얽매이지 않는 것이 중요합니다.
실험의 재현 가능성과 수치에만 너무 집중한 나머지 현장 작업자들의 반응을 놓치면 안되겠죠.
이번에 얻은 결과를 통해서 문제를 어떻게 풀 수 있을지
다음 실험 기회가 주어진다면 어떤 요소들을 고려해야 할지 최대한 많은 힌트를 도출해내야 합니다.
우리는 문제를 풀기 위해 실험을 하는 것이지, 실험을 잘하기 위해서 실험을 하는 것이 아니니깐요!
도움이 되었던 자료들 - 카카오 추천팀 김성진님, 29cm 서현직님 감사합니다.
이번에는 어떻게 하면 실험을 잘할 수 있을지 간단하게 생각을 정리해 봤습니다.
학생 때에도 실험을 많이 해봤지만 실무에서 겪어보니 정말 많이 다른 것 같습니다.
정말 연구자분들 존경합니다...!
피드백, 의견 공유는 언제나 환영입니다 :)
'lifehacking > Retrospect' 카테고리의 다른 글
| 글쓰기의 중요성 - 개발자가 왜 글쓰기를 연습해야 할까? (0) | 2024.08.13 |
|---|---|
| 팀장 회고 #2 feat. "개발자를 위한 커리어 관리 핸드북" 인터뷰 글을 기고했다고? (0) | 2024.05.02 |
| 2022.10 & 2022.11 (0) | 2022.11.23 |
| 2022.09 (0) | 2022.10.02 |
| 백엔드팀 팀장 1년 회고 (0) | 2022.09.17 |