수메리안 선생님 안녕하세요.

제 질문의 의도를 어쩜 이리도 잘 캐치해주시나 감동하며 또 글을 읽고 있습니다. 저의 고민에 대한 출발점은 계산속도를 더욱 빠르게 조치하려할 때 저 Cell.Value 접근에 대한 엑셀구동원리를 잘 모르고 있다는 데에 있었습니다. 예를 들어 [ A1 에 입력된 값 7 을 다른 곳에서 참조한다 ] 라는 이 행위에 대한 것을 엑셀의 입장에서 생각하면, 이 사건의 전후관계는…

계산값 7이 도출되었다. (여기까지 의문이 없음) ---->
이 값을 B1셀이 참조한다. (여기까지 의문이 없음)---->
그럴려면 A1 셀에 7이 입력되어 있어야 한다. (여기까지 의문이 없음)---->

왜냐면

Range("B1").Value = Range("A1").Value

이라고 해야할테니까요. 또는 변수 a 에 저장한다 해도

a = Range("A1").Value

이라고 해야할 테니까요. 참조를 할려면 어떤 식으로든 셀에 접근 또는 셀을 터치해야한다는 의미입니다.

그렇다면 이 지점에서 사건의 전후관계를 더욱 정밀하게 파악해보겠습니다. A1셀에 7이 입력되는 사건은 변수에서 변수로, 또는 메모리에서 메모리로 전달되는 상황이 아니므로, 위와 같이 셀입력값을 참조하는 상황이므로, 그렇다면 어떤 상황이라도 A1 셀에 7이 입력되는 사건이 먼저 일어나야한다는 것은 명명백백하다. (맞잖아요? 근데…) ----> 

결과값 7을 도출한 이후, 이를 셀에 입력하는 시간도 엑셀은 분명히 할애해야할 것이다. 이 행위에 찰나가 걸리더라도 어차피 시간이 걸린다는 점은 분명할 것이다. (바로 여기에서 의문이 시작됨)

제가 말씀드린 셀값입력은 셀값업데이트를 의미하는 것이 아닙니다. 3 + 4 = 7 을 도출했다. 이것은 계산행위이고, 계산값으로 도출된 7 을 셀에 할당해줘서 다른 곳에서 참조가 가능하게 하는 행위. 이것을 저는 셀값입력 행위라고 정의하고 싶습니다. 제 의문의 포인트는 셀값 7이 아니라, 이 값 7을 다른곳에서 참조할 수 있게 하기까지 걸리는 시간. 이렇게 [ 속도 ] 를 정의하고 싶은 것이지요.

VBA 변수 a = 7 (메모리) → 엑셀 시트 Range("A1").Value = 7 (셀)
이 과정은 메모리 복사와 COM 인터페이스 통신이 일어나는 "실제 작업 시간"입니다.
단순히 “보여주기 위한 시간”이 아니라,
주방에서 만든 요리를 홀까지 직접 들고 나가는 것과 같아서
손님 눈에 보이든 안 보이든 “이동 시간”이 분명히 존재하는 노동입니다.

선생님께서도 위에서 말씀하셨다시피 셀값입력은 엑셀의 [ 노동 ] 행위에 포함된다는 점입니다. 더 정확히 말하면 [ 시간노동 ] 이라고 해야할 겁니다. 그렇다면 이제 제 고민은 [ 다른 곳에서 이곳을 참조할 때 셀 입력전에도 참조가능할 수도 있는 상황은 어떻게 설명해야 하나 ] 라는 말도 안되는 고민이 생겨버린 겁니다. 분명히 위에서 [ 이 사건의 앞뒤정황상 분명히 셀 입력이 먼저 일어나야 한다 ] 라고 가정했는데, 이 가정이 틀려버려 결국 제가 만든 결론은 참도 아니고 거짓도 아닌 참으로 요상한 상황에 놓여버린 겁니다.

위 언급한 시간노동을 엑셀이 무시하도록 설계해놓았다면 값이 셀에 입력되기도 전에 참조가능할 수도 있다는 결론을 만들 수 있습니다. 맞잖아요? 쉽게 말해 엑셀은 7을 이미 도출했다. 그러면 이를 셀에 입력하는 노동시간을 무시한다면 바로 재계산하러 출발할 수도 있다. 셀입력이라는 노동은 셀계산값이 무엇인가에는 영향을 끼치지 않으므로 충분히 그렇게 설계되었을 수도 있다. 이게 마치 [ 광명역에 도착한 KTX 를 보고 광명역 전광판은 기차가 접근하고 있다고 안내할 때, 정작 KTX 는 광명승객도 순식간에 태워버리고 이미 대전역에 도착하여 대전승객까지도 태우고 있다 ] 는 상황과 유사하게 변해 있는 것이지요. KTX 는 스스로 매우 속력이 빠르다는 기능을 이미 가지고 있으므로, 전광판에서 뭐라고 안내하던 말던 지는 지 일을 하러(대전승객 태우러 = 재계산하러) 떠날 수 있다는 말입니다. 느린 전광판때문에 KTX가 광명역에서 정차 대기해야한다는 제한을 철도청에서는 만들어 놓지 않았겠죠. 마찬가지로 엑셀도 이렇게 설계되어 있지 않았을테구요.

제 질문이 좀 뜬금없어서 죄송합니다. 닭이 먼저냐? 알이 먼저냐? 이 문제는 앞뒤 사건의 정황을 알 수 없으므로 순환논증의 오류로 끝나버릴 수 밖에 없지만, 셀값 참조는 앞뒤 사건의 정황이 명확한데도 불구하고 순환논증의 오류로 빠져버리는 아주 황당한 경우라고 봐야하지 않을까요? 셀값입력이 먼저 되어야 한다. 그래야 참조가 가능하니까. 셀값입력이 아직 안되어 있다. 그런데 참조는 가능하다. 뭔가 앞뒤가 안맞는 이야기입니다.

이상 이 이슈는 여기까지만 하는 것이 낫겠습니다. 안그러면 엑셀질문이 추상화, 관념화되어 자못 선문답으로 흘러버릴 것 같네요. 엑셀이라는 배가 뜬금없이 산으로 향하는 상황이 나올 것 같습니다.  

제가 배열을 사용할 수 없었던 이유 :

네. 저도 배열을 사용하는 것이 최상이라고 생각은 했지만 제가 맞닥뜨린 문제의 파일은 각각의 셀들이 자기만의 소소한 계산을 하고 이렇게 도출된 값들이 서로서로 동시성없이 수천, 수만 개가 있다는 사실입니다. 예를 들어 A1 셀에는

=testB(B2,C2)

와 같은 수식이 입력되어 있다면, B1 셀에도 유사한 수식이 입력되어 있습니다. 그런데 testC, testD 등이라서 기능은 셀마다 서로 서로 다릅니다. 그런데 이런 사소한 계산을 하는 셀들이 수천, 수만 개라는 점이 제가 속도를 고민하게 된 이유인데요. 각각의 셀들에서 발생한 지연들은 시냇물처럼 모여서 나중엔 거대한 물결로 지연을 발생시키는 큰 강이 될 것이라는 걱정을 하는 것이지요. 저런 간단함수들이 셀 여기저기에 적재적소에 배치되어 있고 동시다발적으로 계산을 하고, 또한 이 계산값들을 다른곳에서 또 재참조하고, 이런 논리로 셀들끼리 서로 영향을 받기도 하고 영향을 주기도하며 쉼없이 계산하는 상황에서, 각 셀들의 계산방식을 개선하면 엑셀 전체계산 속도가 획기적으로 빨라질 것이라는 필요성이 생긴 겁니다. 이 파일에서 가장 흔한 방식이 바로 제가 질문에서 제시한 A, B 두 가지입니다. Sub 로도 해보고 Function 으로도 해보고, 급기야 될 수 있는 한 셀입력이 필요한 상황이 아니라면 변수에서 변수로 바로 계산값을 넘겨주는 방식으로 하여 셀접근 부담을 줄이기도 하였습니다.

배열도 생각해봤지만 저 수많은 셀들을 다 변수화 또는 배열화하기 위해서는 또 셀에 접근해야 하는데 이 또한 부하가 걸리는 일이라면 과연 의미가 있나? 그런 의문이 들었구요. 그러니까..

For i = 1 To eRow
arrOutput(i, 1) = arrInput(i, 1) + arrInput(i, 2)
Next i

이걸 활용해보고 싶어도, 참조할 앞도출값을 셀에서 받아와야 한다면,

arrInput = Range("A1:B" & eRow).Value

와 같은 상황이므로 또 셀접근부담을 져야 하잖아요. 각각의 셀들은 동시성없이 자기계산만을 수시로 하는 상황입니다. 어느 타임에 이를 수집해야하냐도 관건이지만 시시때때로 변하는 데이터를 왜 하필 이때 수집해야 하나 그것도 의문이 듭니다. 이처럼 수집비용과 신뢰도 이슈가 생기는 상황에서 굳이 배열을 이용하는 것은 의미가 없다고 봐야겠죠. 그렇게 결론내면 결국 셀단위 계산으로 넘어가서 이야기를 다시 해야합니다.

즉, 두 방식의 진짜 차이는 단순한 연산 속도가 아니라,
엑셀이 그 값을 “다시 계산해야 하는 객체로 보느냐”에도 있습니다.

Dependency Tree(의존성 트리)에 대한 설명은 저번에 선생님께서 너무 자세히 알려주셔서 충분히 이해하고 있습니다. Function 으로 도출한 값은 고정값으로 인식하지 않고 휘발성으로 인식하여 엑셀은 늘 긴장상태를 가지고 Dependency Tree 를 재구성할 준비를 해야하니 어차피 A, B 가 3 + 4 = 7 과 같이 동일한 기능을 하는 계산이더라도 엑셀은 Function 에 대해 느끼는 피로도가 더 높다는 것으로 저는 해석하고 있습니다. 결국 엑셀이 느끼는 이 긴장감은 메모리 자원을 쓸데없이 낭비할 요인이 될 수도 있다는 걱정도 생기네요.

위 모든 의견들을 종합해보면 A, B 중 제가 선택해야 할 것은 A 라는 결론에 이르는군요. 무엇보다 엑셀은 휘발성없는 고정값을 선호한다는 메리트를 엑셀이 선택할 수 있게 해줘야할 것 같습니다. 매크로를 다시 실행해서 값들을 새로 갱신해 주는 부담은 없습니다. 질문용 예제파일에 만들었던 값입력 매크로는 제가 질문용으로 만든 것이고 실제의 파일에서 이 값들은 앞 계산에서 받아와야 하는데 그 값들은 셀에 저장되어 있고, 그것을 변수로 읽어서 저장하던지, 또는 Function 으로 도출한 자체입력된 값들이거나, 이 값들이 서로서로 유기적으로 영향을 끼치기도 하고, 영향을 받기도 하는 상태입니다. 어차피 갱신해줘야할 값들은 스스로 셀에서 갱신되고 있는 상황입니다.

선생님의 자세하고 차원높은 설명에 또 감사드립니다. 매번 주말마다 찾아뵙고 뜬금없는 질문을 드려 죄송합니다. 그리고 매번 주말마다 곧장 답변을 달아주시고 궁금증을 해소해 주셔서 감사드립니다. 엑셀에 대한 성격을 한가지 한가지 알아갈 때마다 희열을 느낄만큼 재밌습니다. 이게 다 선생님께서 너무 좋은 설명을 해주신 덕분이라고 생각합니다. 좋은 일요일 아침 되시고 늘 건강하세요. 감사합니다.

선생님 안녕하세요.

네. 제가 처한 상황은....

기존 자료를 받아서 계산을 하고, 시트에 기재하고 이어서 Excel이 계산을 진행하고, 다시 VBA가 계산된 결과를 받아서 다음 처리를 해야 하는 구조라면 Excel의 내장 수식을 사용하도록 하는 게 더 좋을 것 같습니다.

과 같습니다. VBA로 일괄처리하고 싶어도 셀들마다 계산방식과 값들이 별개라서 사정상 여의치 못한 측면이 있습니다. 그래서 결국 셀수식으로 해결할 때 어떤 방식이 더 유리할까 그것을 궁리하게 된 이유이고요. 간혹 VBA로 부분 일괄처리해야할 곳들은 또 그 방식에 맞게 처리하게끔 합니다. 그런데 자꾸 모자람을 느끼니 무엇이 더 빠른 방식인가에 대한 고민을 하게 됐습니다.

다행히 VBA가 배열을 임의로 1을 base로 쓸수 있어서, Cell주소와 거의 같은 배열을 만들 수 있으므로, 심한 경우는 필요한 시트를 Arr1, Arr2, Arr3 ...배열에 몽땅 읽어와서, 필요한 계산을 한 다음 다시 모든 시트로 돌려주는 방식도 어렵지 않게 사용할 수 있습니다.

제가 차후에 정말 질문하고 싶었던 것이 바로 이거인데요. 아직은 이르다고 판단되어 이 질문을 못드리고 있는 상태입니다. 좋은 답변을 얻을려면 의도가 명확한 예제파일도 만들어야 하고 질문을 잘하는 것도 간단치 않은 문제가 있잖아요. 제가 차후에라도 궁극적으로 질문하고 싶은 것에 대해 지금 미리 몇마디로 요약하면 [ 속도향상을 위하여, 극단적으로 단 1번도 셀접근없이, 모든 값들을 메모리에서 메모리상으로만 저장/참조/이동 시키며 계산체인을 구성하는 방법은 무엇인가 ] 라는 점인데요. 그것이 구현된다면 엑셀을 열 때 아래와 같이 될 겁니다.

네. 빈 공백뿐입니다. 그러나 무대 뒤 VBA상에서는 열심히 일을 하고 있겠죠.

저는 계산 도중의 시각화를 필요로 하지 않습니다. 결과값만 잘 도출하면 되잖아요. 그 수천 개의 셀들에 무슨 값이 생겼다 사라지고, 그 다음 계산을 수행하러 갈 때 또 무엇이 입력되어 있냐를 따지는 것도 눈으로 확인하는 건 무의미합니다. 대부분의 엑셀파일들이 그렇잖아요. 그 과정을 인간의 눈으로 읽지도 못하지만 읽을 필요도 없잖아요. 그런데 문제는 [ 계산값들에 대한 시각화는 필요없다해도, 계산로직 구현시 도중의 값들이 어느정도는 시각화되어야 그것을 어디에서 참조해야할 지를 즉흥적으로 알게 되잖아요. A1셀을 B1셀에서 참조하고, 그 결과값을 또 C1셀에서 참조하고, 이런 로직이 수백개 있을 때, 셀 그 자체가 지도가 되어 우리는 그 주소를 찍어주기만 하면 되는데, 이걸 메모리상에서 변수에서 변수로만 저장/참조/이동 시킨다면, 지도가 없기 때문에 마치 국어사전 찾듯이 수백개 변수명을 찾아서 작업을 해야하잖아요. 국어사전은 시각화된 지도가 아니라는 점이 우리 뇌를 힘들게 만들구요. 바로 이점 때문에 결국 시각화할 것은 시각화하면서 계산로직을 짤 수 밖에 없을 것이다 ] 라고 느낍니다.

그래서 제가 곰곰 생각했던 점이 [ 아마 저와 같은 빈공백 페이지(오직 VBA상 계산만 있는 페이지) 를 만들고 싶어하는 사람이 분명 있을 것이다. 시각화는 건너뛰어버리구요. 그렇다면 그걸 한방에 변환시켜주는 앱이 있지 않을까? ] 그런 생각도 해봤습니다. 이름을 짓는다면 [ 엑셀계산로직 VBA 시각화도구 ] 또는 [ 엑셀 셀주소를 변수화/배열화시키는 도구 ] 쯤 될려나요. 분명 이런 것이 필요했던 사람이 있었을 것이고, 그렇다면 이 필요는 실제로 이걸 앱으로 짠 사람이 있을 것이라는 예상입니다. 혹시 정말 있을까요?

예: 문자열 [ 엑샐 ] 을 [ 엑셀 ] 로 치환하는 것은 어렵지 않습니다. 인간은 이 작업을 하는 것이 힘들지만 앱은 한방에 끝냅니다. 마찬가지로 각각의 셀 주소를 배열화된 주소 A1 = Arr(1.1) 로 한방에 치환시켜 버려 종국에는 셀수식이 단 1개도 없고 VBA 상에서만 변수/배열/메모리상에서만 계산이 이루어지게, 이처럼 VBA 코딩화시켜주는 앱이 분명히 어딘가에는 있을 것 같은데요. 

답글달아주셔서 감사드립니다. 편안한 일요일 저녁 보내세요. 감사합니다.