소프트웨어 엔지니어를 위한 Fusion360 철학

V자로 누르는 암을 설계하기 위해 기존의 Fusion360 실력으로 벽에 부딪혀 다시 제대로 공부하며 배운 철학을 소개한다. 소프트웨어 엔지니어링을 해본 엔지니어 관점에서 설명하기에 3D CAD를 도전하려는 소프트웨어 엔지니어들에게 큰 도움될 것이다!

Variables

잘못된 예시

기존에 이렇게 모델링을 했는데 실제로 프린트하고 길이가 안 맞는 경우 두번째 이미지처럼 관련 부분을 하나하나 다 직접 계산하고 수정하며 맞춰줘야 했다. 실제로 한번에 완벽하게 프린트하기란 매우 어렵기 때문에 모델링하고 프린트하고 조립하는 이터레이션을 3-4번 거치게 되는데 이 때 매번 직접 하나하나 수정하다 보면 또 다른 실수가 나오기 마련이다.

소프트웨어 엔지니어링으로 치면 변수를 하나도 선언하지 않고 매 라인마다 내가 직접 계산하고 값을 직접 입력하는 형태로 코딩하는 꼴이다.

print((87 + 92 + 76 + 81 + 95) / 5)
print((87 + 92 + 76 + 81 + 95) / 5 > 80)
print("총점:", 87 + 92 + 76 + 81 + 95)
print("첫 번째 학생 점수:", 87)
print("두 번째 학생 점수:", 92)
print("세 번째 학생 점수:", 76)
print("네 번째 학생 점수:", 81)
print("다섯 번째 학생 점수:", 95)

마치 이런 식의 코드를 작성하고 있는 느낌이었다.

모든 것을 다 변수화해서 하나로 다 관리하고 중복되는 값을 없애야 한다.

CAD에는 이런 식으로 User Parameter, Model Parameter를 선언할 수 있다.

위에 보이는 것처럼 직관적인 이름을 위해 직접 변수명을 하나씩 다 정해주고 값도 직접 지정해주었다.

Expressions

이러한 변수들을 100% 활용하기 위해서는 expression이 필요하다. 위에 보이는 컬럼처럼 a = gear_module * teeth_count 으로 선언해서 또 다른 변수를 선언할 수도 있다. gear_module을 바꾸면 관련 변수값들이 다 알아서 바뀌게 된다.

이것 외에도 실제 스케치에서도 expression을 표현할 수 있다.

이는 서보모터의 위에서 바라본 화면을 스케치한 것이다.

여기에 보이는 모든 선이 검정색인데 이 뜻은 모든 변수들이 제대로 선언되었다는 뜻이다. 즉 이 그림이 확정적이다. null이 없다. 만약 확정적이지 않다면 해당 부분이 파란 선으로 보여진다.

위에서 먼저 수치 expression을 보자. 빨간 원들이 다른 수치와는 다르게 "fx:"라는 prefix가 붙어있는 것을 알 수 있다. 이 값들은 전부 왼쪽 대칭적인 값들과 같다는 뜻이며 내가 직접 지정해주었다. 이것으로 인해 좌측 숫자를 바꾸면 알아서 우측도 다 바뀌게 되었다

여기에 실제 수치적인 expression도 있지만 기하적인 expression도 있다. 파란 원을 바라보자. 1번은 원과 해당 선이 접한다는 뜻이며 2번은 지나가는 두 선이 직교한다는 뜻이다. 3번은 두 원이 동심원이고 4번째는 해당 점이 위아래 선에서 중점이라는 것을 의미한다. 이런 기하적인 expression을 Fusion360에서 constraints라고 부른다.

Fusion360 스케치 화면에 들어가면 중간에 있는 빨간색 constraints 항목이 이 항목들이다.

constraints를 잘 선언하는 방법은 소프트웨어 엔지니어링과 정확히 같다. 처음에 근본이 되는 변수들을 먼저 선언해야 하고 그 변수들 위에 하나씩 구축해나가야 한다. 위 그림에서 제일 밖에 width, height을 각각 32, 12로 선언한 것을 볼 수 있고 그 밖에 있는 직사각형은 별도 길이 제약 없이 안 직사각형과 2mm 차이 난다는 기호가 있다는 것을 볼 수 있다. 이렇게 한 이유는 안 직사각형이 서보모터 크기와 정확히 일치하는 직사각형이며 2mm offset을 통해 여유를 주고자 함이었기 때문이다. 반대로 했다면 나중에 다른 크기의 서보모터를 쓸 때 분명 헷갈리게 됐을 것이다. 소프트웨어 엔지니어링할 때 많이 쓰는 방법 중 하난데 변수명 짓을 때 어렵지 않아야 한다. 만약 어렵다면 충분히 직관적이고 임팩트 있는 변수가 아니기에 그것을 변수로 선언하는 것이 적합하지 않을 수 있다.

소프트웨어 엔지니어링과 다른 것 중 하나는 기하에 대한 이해가 있어야 한다. 정말 간단한 예시로 정사각형을 그리기 위해서는 네 변의 길이가 같은 것뿐만 아니라 한 각의 각도가 90도여야 한다. 여기에서 다른 각 하나도 90도로 선언하면 over-constraint 알림을 준다.

이런 식으로 설계를 잘 했다면! 나중에 값을 하나만 바꿔도 알아서 모든 것이 다 깔끔하게 바뀌는 마법을 경험할 수 있다.

Lines

마지막으로 Fusion360에는 맨 밑에 feature list가 있다. 이 feature는 나의 타임라인을 보여주는 것이다. 이 feature를 잘 관리하는 것이 나의 스트레스 지수에 매우매우 큰 영향을 미친다. 걸핏 보면 git commit history 같은 느낌이 들지만 실제로는 코드 라인 한줄한줄이라고 보면 된다.

현재 이 예시는 총 25줄 코드이며 이것은 어떠한 환경에서 실행시켜도 같은 결과를 만들어낸다. 코드는 보통 매번 처음부터 다시 실행시키지만 CAD에서는 최종 결과만을 띄워놓고 진행한다. 그래서 굳이 비유하자면 pdb를 항상 켜놓고 코딩하는 느낌이다.

pdb를 항상 켜놓고 하는데 중간에 내가 이전 라인에서 잘못 한 걸 깨달았다면?

a += 5를 해야 하는데 a += 10을 했다고 생각해보자.

a += 10 라인을 찾아가 10을 5로 바꿀 것인가! 아니면 a -= 5 라인을 추가할 것인가!

당연하게도 전자인데 저번주의 나는 이 feature 개념을 몰랐기 때문에 이 타임라인이 더러워지는 것에 대한 생각을 하나도 안 하고 a -= 5 라인을 추가했다. 지금은 이전 라인으로 돌아가 해당 라인을 수정하고 다시 현재로 온다. pdb로 치면 이전 체크포인트로 계속 돌아가는 느낌이다.

이 feature들은 순서를 바꿀 수도 있다. 물론 서로 의존성이 있기에 해당 의존성을 역전하도록 순서를 바꾸는 것은 안된다.

a = 3
b = 5
a *= b

a *= b
a = 3
b = 5

위 코드를 아래 코드처럼 바꾸면 안된다는 뜻이다.

우리가 코드를 짤 때 항상 클린한 상태를 유지하듯이 이 타임라인은 항상 최대한으로 깔끔하게 관리해야 한다. 그래야 내가 무언가를 바꾸고 싶을 때 해당 라인을 바로 찾아가서 원하는 것을 바로 바꿀 수 있게 된다.

Functions

라인이 있으면 당연히 함수도 있다!

위에서 + 버튼을 누르면 아래처럼 해당 feature가 아래처럼 확장된다. 하나가 마치 함수와 같은 역할이다.

위 예시는 spur gear를 선언하는 함수로써 8개의 feature로 이루어져 있다. 4번째에 있는 스케치는 아래처럼 기어 톱니를 스케치하는 feature이다.

위 함수는 이미 라이브러리에 존재하는 함수여서 갖다썼지만 추후에 얼마든지 내가 커스텀으로 함수를 선언해둘 수도 있다.

Final

결국 모든 엔지니어링은 이어진다. 소프트웨어 엔지니어링을 하며 배우고 깨달았던 철학들이 결국은 근본적인 엔지니어링 철학들인 것 같고 덕분에 3D CAD에서 이런 개념들을 이해하기가 수월했다.

코딩할 때 매번 타이핑하고 린팅하고 리팩토링하는 것이 내가 시간이 남아서가 아니다. 이것이 시간을 아껴주기 때문이다. Fusion360에서도 그렇다. 변수명 귀찮지만 하나하나 직접 지어줘야 내가 해당 변수를 불러서 다른 값을 선언할 때 바로 변수를 작성할 수 있고, constraints를 잘 걸어줘야 내가 변수 하나를 수정했을 때 이후 모든 것이 내 생각대로 변경된다. 또한 라인 하나하나 항상 리팩토링하고 나중에 내가 다시 돌아오더라도 바로 기억할 수 있게끔 가독성 좋은 feature list를 관리하고 있어야 한다. 마지막으로 반복적으로 내가 사용하는 것들은 함수화해서 효율을 올리자.