best bet would be to segregate the EJB interfaces (client code) into a separate folder/module. that way you can reduce the opportunities of direct reference to objects that are run-time bound.
the server side code could then consume the resulting jar of the stubs as if it were a third-party library when you compile/build your war/ear/jar file.
something like
/web - client collateral (images, jsps, style sheets, etc.)
/eeclient - client side java (stubs, interfaces, etc.)
/eeserver - server side java (ejb realizations, middleware, etc.)
obviously there are many ways to skin this cat, but at the very least you want to isolate the representation layer, client code, and server code. more granularity will help if your build system is sane and works on a "consumption" mechanism rather than just building a huge pool of .java files that reference each other willy-nilly.
== sfisque