Depending on the design, macros may also be expanded already; the compiler works with macro-expanded code.
The easiest approach, from a boostrapping point of view, is to write an interpreter in some host language. Get macro expansion and read macros working in the interpreter, and then add a compiler.
On Lisp Ch 17, page 224: https://sep.turbifycdn.com/ty/cdn/paulgraham/onlisp.pdf
CLTL2 Section 22.1.1: https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node188.html#... - Goes into a lot of detail on how the reader works.
The macros most people mean when they talk about Lisp macros are discussed in CLTL2 Ch 8. They are expanded during evaluation or compilation.
CLTL2 CH 8: https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node97.html
Read macros are able to produce (or not produce) lisp objects by taking control of the stream processing for some period of time.
The compiler/interpreter gets as input Lisp data. Let's use READ, DESCRIBE and EVAL to see that working:
CL-USER 17 > (defun example (&aux input result)
(terpri) ; newline
(write-string "Input> ")
(finish-output)
(terpri)
(setf input (read)) ; reading from input stream
(terpri)
(describe input) ; what did we read?
(terpri)
(write-string "Output>")
(setf result (eval input)) ; evaluation
(terpri)
(write-string "Result>")
(print result) ; printing the result
(values)) ; return nothing
EXAMPLE
CL-USER 18 > (example)
Input>
(progn
(print (+ 1 3))
(print 'done))
(PROGN (PRINT (+ 1 3)) (PRINT (QUOTE DONE))) is a LIST
0 PROGN
1 (PRINT (+ 1 3))
2 (PRINT (QUOTE DONE))
Output>
4
DONE
Result>
DONE
EVAL is then taking code as a list and evaluates it to a value, as side effects there might be printed output of the program.